control de acceso - eva.fing.edu.uy file4.3-bloques de hardware ..... 11 4.3.1-entradas
TRANSCRIPT
1
UNIVERSIDAD DE LA REPUBLICA
Facultad de Ingeniería Instituto de Ingeniería Eléctrica
Control de Acceso
Documentación final
Sistemas embebidos para tiempo real 2013
Florencia Blasina, Gonzalo Finozzi, Nicolás Marquez
Tutor: Conrado Rossi
Montevideo,Uruguay 8 de julio 2013
2
3
Tabla de contenido 1-Introducción .............................................................................................................................. 6
1.1-Descripción del problema .................................................................................................... 6
1.2-Antecedentes ...................................................................................................................... 6
2-Objetivos del proyecto ............................................................................................................ 7
3-Alcance ...................................................................................................................................... 7
4-Diseño de hardware ................................................................................................................. 8
4.1-Plataforma de hardware ...................................................................................................... 8
4.2-Consideraciones previas ..................................................................................................... 9
4.2.1-Protocolo Wiegand ....................................................................................................... 9
4.2.2-Modo físico de transmisión de la información .............................................................. 9
4.2.3-Interpretación numérica de la información ................................................................. 10
4.2.4-Ejemplo de interpretación de la información .............................................................. 11
4.3-Bloques de hardware ........................................................................................................ 11
4.3.1-Entradas ..................................................................................................................... 12
4.3.2-Salidas ........................................................................................................................ 14
5-Diseño de software ................................................................................................................ 14
5.1-Introducción ....................................................................................................................... 14
5.2-Diagrama funcional ........................................................................................................... 15
5.3-Máquinas de estado concurrentes .................................................................................... 16
5.4-Máquina lectura y validación ............................................................................................. 17
5.5-Máquina cerrojo ................................................................................................................ 18
5.6-Máquina estado de puerta ................................................................................................ 18
5.8-Módulos e interfaces ......................................................................................................... 20
5.9-Módulo hardware .............................................................................................................. 21
5.10-Módulo lectura ................................................................................................................. 22
5.11-Módulo procesamiento .................................................................................................... 24
5.12-Módulo base de datos ..................................................................................................... 25
5.13-Módulo logs ..................................................................................................................... 26
5.14-Módulo menú .................................................................................................................. 29
4
5.14.1-Pantalla principal ...................................................................................................... 30
5.14.2-Pantalla “Agregar nuevo usuario” ............................................................................ 31
5.14.3-Pantalla “Editar un usuario”...................................................................................... 32
5.14.5-Pantalla “Ver franjas horarias” ................................................................................. 33
5.14.6-Pantalla “Obtener registros” ..................................................................................... 34
5.14.7-Pantalla “Establecer fecha y hora” ........................................................................... 35
5.14.8-Pantalla “Ver usuarios registrados” .......................................................................... 36
6-Conclusiones .......................................................................................................................... 37
7-Anexos .................................................................................................................................... 38
7.1-Conceptos del curso aplicados al proyecto ...................................................................... 38
7.2-Planificación del proyecto ................................................................................................. 38
7.3-Especificación del proyecto............................................................................................... 39
7.4-Datasheet del lector de proximidad .................................................................................. 46
7.5-Archivos fuente ................................................................................................................. 46
Tabla de figuras Figura 1 : Módulo TinyNode .......................................................................................................... 8
Figura 2 : Extension board ............................................................................................................ 8
Figura 3 : Transmisión de bits ..................................................................................................... 10
Figura 4 : Formato de Wiegand 26.............................................................................................. 11
Figura 5 : Bloques de hardware .................................................................................................. 12
Figura 6 : Diseño de entradas digitales ....................................................................................... 12
Figura 7 : Entrada DATA 1 .......................................................................................................... 13
Figura 8 : Entrada DATA 0 .......................................................................................................... 13
Figura 9 : Diagrama funcional ..................................................................................................... 15
Figura 10 : Máquinas de estado concurrentes ............................................................................ 16
Figura 11 : Máquina estados lectura y validación ....................................................................... 17
Figura 12 : Máquina estados cerrojo ........................................................................................... 18
Figura 13 : Máquina estados puerta ........................................................................................... 19
Figura 14 : Modularización .......................................................................................................... 20
Figura 15 : Módulo lectura ........................................................................................................... 23
Figura 16 : Secuencia almacenar logs ........................................................................................ 27
Figura 17 : Máquina estados del menú ....................................................................................... 29
5
Resumen
El Proyecto consiste en una maqueta de un sistema de control del ingreso de personas a áreas
restringidas que identifica los usuarios autorizados mediante un lector de tarjetas de
proximidad.
El egreso se habilita al pulsar un botón ubicado en la zona restringida. Un detector del estado
de la puerta permite disparar una alarma si la puerta permanece abierta demasiado tiempo.
El sistema guarda registros de eventos con su fecha, hora y usuario asociado en los casos en
que es identificable.
La configuración de usuarios autorizados, horarios habilitados y otros parámetros se realiza a
través de una terminal serie mediante menús sencillos desplegados por el sistema. Así mismo
pueden ser descargados los registros de actividad.
La maqueta tiene una capacidad limitada en la cantidad de personas autorizadas y otras
funcionalidades auxiliares a fin de adecuar el proyecto a la asignatura
6
1-Introducción
1.1-Descripción del problema
En muchas actividades cotidianas es necesario tener un control sobre el ingreso/egreso de
personas en determinadas áreas, las cuales pueden ser oficinas, recintos laborales,
instituciones de estudio, bancos o salas de procesamiento de datos. También existen
problemas concretos con el uso compartido de electrodomésticos, medicación o instrumentos
de laboratorio de alto valor. Para resolver este problema se emplean sistemas que
implementan dicho control permitiendo o no el acceso a las áreas descriptas.
Entre las aplicaciones que un control de acceso puede tener, ejemplificamos algunas
situaciones:
• Las instituciones necesitan tener un control de horarios de entrada/salida del personal
para liquidación de sueldos y/o control de inasistencias.
• Por seguridad se puede querer restringir a un selecto grupo de usuarios el acceso a
determinados bienes o áreas específicas de una empresa, hogar o local de trabajo.
Control de Acceso resuelve esta problemática debido a que realiza el control descripto
anteriormente logrando el nivel de seguridad necesario para este tipo de aplicaciones.
Este proyecto es una maqueta con funcionalidad limitada, pero que con algunos cambios
podría adaptarse a un control de acceso más real.
1.2-Antecedentes
En el curso de Sistemas Embebidos para Tiempo Real no existe una versión previa a esta
solución, sí existen en el mercado muchas marcas que comercializan este producto con
diversas implementaciones.
Existe un protocolo de comunicación estándar entre lectores (proximidad, pin, biométrico, etc.)
y el micro controlador (UC) llamado Wiegand, el cual se tomará como base para la
implementación.1
1 Los textos de referencia que se utilizaron para comprender el funcionamiento del lector de
proximidad fueron:
http://www.scattech.com/en/san-pham/372_pr-200-proximity-card-reader-.html
http://www.jantek.com.tw/jan-pr-200-e.htm
7
2-Objetivos del proyecto
Desarrollar un sistema que implemente un control de acceso de una puerta utilizando un micro
controlador y un lector de tarjetas de proximidad.
Implementar la comunicación con el usuario para configuración como para mostrar el registro
de logs.
Simular su funcionamiento en una maqueta, la misma tendrá cuatro entradas: dos para el lector
de proximidad y dos digitales para simular el estado de la puerta y el pulsador de egreso.
Además tendrá dos salidas las cuales simularan el estado del cerrojo y la alarma de puerta
abierta respectivamente.
3-Alcance
Para la realización del proyecto será necesario diseñar e implementar el hardware extra
necesario para la implementación de las entradas digitales y la comunicación con el lector de
proximidad.
La comunicación con el usuario se realizara a través de la hyperterminal del PC emulando
comandos VT100, desplegando un menú que también se implementará en software.
El menú tendrá capacidades para ingresar, editar y eliminar usuarios, desplegar usuarios y
franjas registradas y bajar el listado de registros guardados en memoria registrados a partir de
eventos del sistema, también tendrá capacidad de establecer fecha y hora desde la terminal.
El sistema permitirá el ingreso de hasta diez usuarios, con cuatro franjas horarias pres
configuradas.
Control de Acceso deberá permitir controlar el acceso a un recinto mediante la lectura del
código de una tarjeta con el lector de proximidad y permitir egresar al pulsar un botón. Deberá
incluir una alarma de puerta abierta en condiciones anormales de operación.
Una vez configurado el sistema deberá funcionar standalone.
8
4-Diseño de hardware
4.1-Plataforma de hardware
El módulo hardware que se utilizará para la implementación del sistema es el TinyNode 184 el
cual tiene como micro controlador el MSP430F2417 de Texas Instruments (TI).
Figura 1 : Módulo TinyNode
Además del módulo, se utilizará la placa de expansión estándar de TI que incluye los puertos
para grabación del firmware y la comunicación serial entre otros. Esta placa se conecta con la
anterior por un conector de 30 pines para este propósito.
Figura 2 : Extension board
9
4.2-Consideraciones previas
4.2.1-Protocolo Wiegand
El inicio del protocolo Wiegand nace a partir del conocido efecto Wiegand, que “es un concepto
físico en el que intervienen las distintas formas de reaccionar magnéticamente distintas áreas
de un hilo conductor ante la influencia de un campo magnético.”2
En base a éste efecto se crean tarjetas de identificación con sus lectores para sistemas de
control de accesos o de presencia. Como es de suponer los lectores se deben conectar de
alguna forma a los sistemas de control de accesos para poder comunicarlos; por ello es que se
crea el protocolo de comunicación Wiegand.
El término del interface Wiegand es una marca de la sociedad “Sensor Engineering Company”
y fue diseñado para conseguir una tecnología que permitiera transmitir datos de un identificador
(tarjeta) entre dos dispositivos alejados entre sí, como, por ejemplo, un lector y la central de
control de accesos. El protocolo Wiegand es ampliamente utilizado por la mayor parte de los
fabricantes porque permite la transmisión de información a través de un par de cobre que se
acompaña de la alimentación para el dispositivo de lectura sin afectar por ello a los datos.
4.2.2-Modo físico de transmisión de la información
Es una transmisión de modo asincrónico, la cual se realiza por intermedio de tres hilos. Los
niveles con los que trabajan son nivel bajo que está a nivel de tierra (GND), y nivel alto a +5(V).
El envío de datos por los tres hilos es el siguiente:
- DATA 0: Línea que envía los ceros lógicos.
- DATA 1: Línea que envía los unos lógicos.
- GND: Línea a masa de referencia de DATA 0 y DATA 1.
Existen tres estados:
- Estado de reposo: no se trasmite, la línea GND está en bajo y las líneas DATA 0 y DATA 1
están en alto.
- Para trasmitir un bit 1 se debe enviar un pulso a nivel bajo con una duración de 250 us por la
línea de DATA 1, mientras la línea DATA 0 se mantiene en alto.
2 http://en.wikipedia.org/wiki/Wiegand_effect
10
- Para transmitir un bit 0 se produce el proceso contrario ya que ahora se envía un pulso a bajo
por la línea de DATA 0 con duración de 250 us, mientras la línea de DATA 1 se mantiene en
alto.
El tiempo de duración entre el comienzo de un pulso y el siguiente es de 2ms.
En la figura 3 se puede ver la representación de la transmisión de la secuencia de bits 1010.
Figura 3 : Transmisión de bits
4.2.3-Interpretación numérica de la información
Mediante el modo de transmisión físico que se indicó con anterioridad se pueden trasmitir
tantos bits como se requieran. Los estándares son de: 26, 32, 44 ó 128 bits, siendo el Wiegand
de 26 bits el más utilizado y el que se lo interpreta de una sola forma, ya que los otros modos
son interpretados de muchas formas por lo distintos fabricantes que manejan éste protocolo. La
mayoría de los fabricantes (OEM3) tiene una estructura de bits propia en protocolo Wiegand.
Con la versión genérica de 26 bits existe un pequeño riesgo de duplicación a diferencia de un
protocolo de 36 bits; por lo tanto, el nivel de seguridad es un poco más bajo que los formatos
únicos.
En la figura 4 se muestra el formato del Wiegand de 26 bits. El primer bit es la paridad par de
los próximos 12 bits. A los siguientes 8 bits se los llama “Facility Code” y representan un
número que va desde 0 hasta 255; a los siguientes 16 bits se los llama Identificación, que
pueden valer entre 0 y 65535. El último bit es la paridad impar de los últimos 12 bits excluyendo
al de paridad.
3 Original Equipment Manufacturer
11
Figura 4 : Formato de Wiegand 26
4.2.4-Ejemplo de interpretación de la información
Supongamos una tarjeta que genera un código como el siguiente:
11010111001011001101001101.
Si lo separamos en los campos lógicos quedará así: 1 10101110 0101100110100110 1
Donde:
FC = 10101110 = 0xAE (Hexadecimal) = 174 (decimal)
ID = 0101100110100110 = 0x59A6 = 22950
Para entender el cálculo de las paridades reescribimos la cadena coloreando el lugar de
cálculo 11010111001011001101001101. La paridad par se calculó sobre los 101011100101 y
dado que contiene 7 “1“ (porque hay una cantidad impar de “1”, entonces se agrega otro para
que quede par), la paridad debe valer “1”. La paridad impar del final se calcula sobre
100110100110 y como se trata de 6 “1”, la paridad también vale 1 (porque hay una cantidad
par de “1”, entonces se agrega otro para que quede impar).
4.3-Bloques de hardware
Para llevar a cabo el proyecto fue necesario diseñar e implementar una etapa de hardware que
permita la interacción entre el usuario y el módulo uC.
El diagrama de la figura 5 indica los bloques intervinientes así como los pines dedicados a la
interconexión entre los periféricos y el módulo principal, los mismos lo dividiremos en entradas
y salidas.
12
Figura 5 : Bloques de hardware
4.3.1-Entradas
1- Estado de puerta y pulsador de egreso
Para las entradas digitales se incluyó una resistencia de pull-up de 100k
Figura 6 : Diseño de entradas digitales
2- Lector de proximidad
Como se explicó anteriormente, la comunicación al exterior del lector se hace a través de
dos líneas de datos D1 y D0 las mismas funcionan con 0 y 6VDC (nivel bajo y alto
respectivamente), pero el módulo uC funciona con niveles de tensión nominales de
GND TINY Y FUENTE EXT
R100k
ESTADO PUERTA
VCC
Pin 6.0
PULSADOR
GND TINY Y FUENTE EXT
R1100k
VCC
Pin 6.1
13
3.3VDC. Por ésto último fue necesario diseñar una etapa de adaptación de niveles de
tensión y una etapa de filtrado para poder conectar ambos bloques.
Figura 7 : Entrada DATA 1
Figura 8 : Entrada DATA 0
Criterio de diseño:
Para el divisor resistivo se consideró que la corriente que se tome del lector sea como
máximo 100uA y que el voltaje de salida sea la mitad de el de entrada (aprox. 6VDC).
Para la etapa de filtrado se considero que cinco constantes de tiempo del circuito RC sea
mucho menor que el tiempo de bit (250 us), por lo tanto se tiene:
1 = −
100 =6 − 3
100 → 1 = 30Ω
1 = 33Ω
=1
1 + 2=
2↔ 1 = 2
5# = 5(1||2) ≪ 250( = )*+, → ≪ 3.03./011231 = 224/
GND TINY Y FUENTE EXT
R2
Pin 1.2 TinynodeR1
C
DATA 1
GND TINY Y FUENTE EXT
R2
Pin 2.6 Extension boardR1
C
DATA 0
14
4.3.2-Salidas
Cerrojo y alarma
Ambas salidas se implementarán con LEDs que están en la placa de expansión, el verde
representa el cerrojo (encendido representa energizado, apagado desenergizado) y el rojo
la alarma (apagado o encendido según si la misma lo está), los pines de salida del uC son
2.3 y 1.6 respectivamente.
5-Diseño de software
5.1-Introducción
Para el diseño del software se partió de un diagrama funcional del sistema, luego se plantearon
los posibles módulos necesarios y sus respectivas funciones.
A medida que se avanzó en el diseño se fue modificando los módulos y funciones para lograr la
solución al problema.
Se decidió realizar abstracción de hardware de los módulos por lo que se diseñó un módulo de
hardware el cual incluye funciones que operan sobre él directamente, permitiendo un eventual
cambio de la plataforma con poca recodificación.
La arquitectura seleccionada fue Round Robin con interrupciones.
15
5.2-Diagrama funcional
Para el diseño del software, se parte de un diagrama funcional del flujo del sistema en donde
se indican los bloques intervinientes y cómo interactúan entre sí.
Figura 9 : Diagrama funcional
Para simplificar el problema se diseñó el sistema de forma tal que cuando se esté operando el
menú no se acepte una lectura, solamente se permitirá la apertura del cerrojo desde el interior
del recinto o la activación de la alarma por puerta abierta. Esto se hace para evitar problemas
de datos compartidos.
Para resolver éste problema se implementaron máquinas de estado concurrentes que
funcionan en paralelo y atienden todos los requerimientos del sistema.
16
5.3-Máquinas de estado concurrentes
Como se explicó anteriormente la división en máquinas de estado facilitó la implementación del
conjunto del problema, como se aprecia en la figura se implementaron tres máquinas de
estado:
-Máquina de menú, lectura y validación
-Máquina de cerrojo
-Máquina de puerta y alarma
Luego de un init() las tres máquinas operan de forma independiente, para facilitar aún más la
codificación se dividió la máquina de menú, lectura y validación en dos sub máquinas, de forma
que una se encarga únicamente de las funcionalidad del menú y la otra de la lectura y
validación, ambas comparten el estado de espera.
Figura 10 : Máquinas de estado concurrentes
17
5.4-Máquina lectura y validación
La figura 11 describe el funcionamiento de la máquina que se encarga de obtener una lectura
válida.
Luego de iniciar el sistema se queda en el estado ESPERA hasta que la bandera hay_bit sea
igual a uno, para que esto último suceda el uC recibe una interrupción por las líneas de
Wiegand y llama a la función lectura_wiegand () que se encargara de ir “guardando” uno a uno
los siguientes bits, tarea que se realiza en el estado LECTURA.
Para salir de LECTURA hay dos opciones, o se completa la trama de 26 bits y se pasa al
estado PARIDAD o si por alguna razón se pierden bits y se demora mas de 250ms se da un
time_out por el cual se regresa al estado ESPERA.
En el estado PARIDAD se chequea la paridad de la trama de bits, si es correcta se pasa al
estado VALIDACION y como salida se llama a la función decodificar_tarjeta() que devuelve un
unsigned int con el número de tarjeta leído o si la paridad es incorrecta se vuelve el estado
ESPERA.
Por último desde el estado VALIDACION siempre se vuelve a ESPERA con una salida que es
invocar a la función validación_final_usuario() que devuelve 1 si el usuario es admitido o cero
en caso contrario, esta bandera es utilizada por otros módulos para el log.
Figura 11 : Máquina estados lectura y validación
18
5.5-Máquina cerrojo
La figura 12 describe el funcionamiento de la máquina que controla el estado del cerrojo.
Esta máquina implementa los estados posibles del cerrojo, como se aprecia en la figura luego
de la inicialización pasa al estado ENERGIZADO, estado que permanece hasta que se setea la
bandera to_cerrojo_activo, la misma se activa por un ingreso valido o por pulsar el botón de
egreso, pasando al estado DESENERGIZADO el cual permanece un tiempo preseteado.
En la transición se resetea la salida del cerrojo o sea se des energiza el cerrojo y se logea el
evento, luego que expira el tiempo vuelve a el estado ENERGIZADO dando como salida
energizar el cerrojo y logear el evento
Figura 12 : Máquina estados cerrojo
5.6-Máquina estado de puerta
La figura 13 describe el funcionamiento de la máquina que controla la alarma según el estado
de la puerta.
La máquina del estado de puerta y alarma es la encargada de controlar y activar una alarma si
se detecta que la puerta permanece abierta un determinado tiempo, sin importar el origen de la
apertura (pulsador egreso, usuario valido, puerta forzada).
19
Como se aprecia en la figura, luego de la inicialización queda en el estado REPOSO, si se
setea la bandera to_puerta_activo, avanza al estado CUENTA_T, estado en el cual se
decrementa un contador, si la puerta se cierra antes de expirar el tiempo vuelve al estado
REPOSO de lo contrario avanza al estado ALARMA encendiendo el LED de alarma y
logueando el evento.
Permanece en este estado ALARMA hasta que se cierre la puerta y vuelve al estado REPOSO
apagando el LED y logueando nuevamente el evento.
Figura 13 : Máquina estados puerta y alarma
20
5.8-Módulos e interfaces
En la figura 14 se aprecian todos los módulos implementados y sus interconexiones.
Figura 14 : Modularización
21
5.9-Módulo hardware
El módulo Hardware es el encargado de suministrar las funcionalidades del hardware a todo
módulo que las necesite.
Tanto para desplegar el menú como para permitir la interacción entre el administrador y las
posibilidades que brinda el menú, Control de Acceso necesitaba el uso de la UART para
comunicar a éste con un PC y que se observe el menú vía hyperterminal.
Para ésto, el módulo hardware posee las siguientes funciones:
• void init_UART (): inicializa la UART para que interrumpa tanto para transmitir como para
recibir datos
• void transmitir_UART (): quita un carácter de la cola de transmisión y lo coloca en el
registro indicado para transmitir.
• char recibir_UART (): lee el registro de recepción como carácter y lo devuelve.
• __interrupt void ISR_RX (): Subrutina de atención a interrupción para la recepción vía
UART. Llama a recibir_UART para poder leer el carácter recibido y controla si se recibió
un string completo mediante un enter. También se encarga de reiniciar el tiempo de time
out del menú.
• __interrupt void ISR_TX (): Subrutina de atención a interrupción para la transmisión vía
UART. Saca de la cola de transmisión un carácter y lo coloca en el registro indicado para
transmitir. También se encarga de reiniciar el tiempo de timeout del menú.
Se diseñó un reloj interno de tiempo real para poder llevar a cabo el control de franjas horarias
y para registrar logs. Con éste fin, existía la necesidad de usar el timer A del módulo TinyNode.
Para configurarlo y hacer uso de éste, el módulo hardware posee la función “init_timer_A” la
cual inicializa interrupciones del timer A cada 250 milisegundos aproximadamente.
La función de atención a interrupción del timer A, no solo se encarga de incrementar el reloj del
sistema en 250ms, sino que también maneja los tiempos de timeout del menú, del cerrojo y de
puerta abierta.
Para poder controlar los tiempos de lectura del lector de proximidad Wiegand, en el módulo
hardware se configuró el timer B del módulo TinyNode mediante la función “init_timer_B”. En
ésta función se configuró el timer B para que éste interrumpa cada 250ms. A diferencia del
timer A, timer B sólo es utilizado cuando hay lecturas por parte del lector de proximidad, y
22
cuando no debe ser más utilizado se deshabilita mediante la función del módulo hardware
“stop_timer_B”.
En caso de que un determinado usuario halla ingresado/egresado al/del recinto y haya dejado
la puerta abierta luego de cierto tiempo, se debe encender la alarma del sistema. Cómo Control
de Acceso sólo es una maqueta, la alarma se mostrará mediante encender un LED. Para ésto,
en el módulo hardware se encuentra la función “encender_alarma” cuya única acción es
encender el LED rojo del módulo TinyNode.
Para apagar dicha alarma, la función “apagar_alarma” apagará dicho LED. Para conocer el
estado de la puerta simplemente se consulta el estado del puerto por el que va un pulsador
conectado, mediante la función “leer_estado_puerta”.
Cuando se habilite un usuario a ingresar o egresar del recinto, es necesario desenergizar el
cerrojo de la puerta. Reiterando, como lo que se ha creado es una maqueta, para demostrar
que se desenergiza un cerrojo o se energiza el mismo, las funciones “desenergizar_cerrojo” y
“energizar_cerrojo” apagan y prenden respectivamente el LED verde del módulo.
Para indicar que hay una lectura de una tarjeta mediante el lector de proximidad, se
implementó en el módulo hardware la función “comienzo_lectura_wiegand”.
Para que éste interrumpa cuando se haya producido una lectura, se lo configura mediante la
función “init_puertos”. El lector interrumpe enviando bits de información. Cuando interrumpe
para enviar un 0, se atiende mediante la función “__interrupt void ISR_D0”, mientras que si es
por un 1, mediante la función “__interrupt void ISR_D1”.
5.10-Módulo lectura
Cuando se describió la máquina de estados de lectura y validación se explicó que en el estado
lectura se invoca sucesivamente la función lectura_wiegand, aquí se describe el diagrama de
flujo que implementa la función.
23
Figura 15 : Módulo lectura
Como se explicó anteriormente los datos desde el lector ingresan a través de los pines del
módulo con capacidad de interrumpir o sea por interrupciones.
Cada vez que llega un “0” o “1” se enciende una bandera en la ISR correspondiente a la
recepción de “0” o “1”, esta bandera indica al programa principal que hay un dato listo y hay
que procesarlo.
La forma de ir guardando los bits recibidos en un registro es mediante un shift register con una
máscara dinámica (1<<i) que varía en cada pasada ya que varia el entero i.
Para guardar un uno lógico: lectura=lectura OR mascara
Para guardar un cero lógico: lectura=lectura AND NOT (mascara)
Existe una limitante a la hora de usar el operador “<<” y es que el mismo es de 16 bits por lo
que se debió implementar la lectura en dos partes definidas como lectura_hi y lectura_low,
24
cuando inicia la recepción de datos se comienza a guardar en lectura_hi luego que se completa
se carga en lectura_low, este control se realiza con la variable i, si la misma llega a 16 se
resetea la variable hi.
En cada paso que se guarda un dato se resetea la bandera correspondiente de la ISR, leo_1 o
leo_0 según corresponda.
Si el contador de datos (variable j) llega a 26 se enciende la bandera hay_lectura y se
inicializan las variables para la próxima lectura, si transcurren mas de 250ms (se cuenta un tick
con timer B) y no hay una lectura completa se setea la bandera time_out y se sale de la función
dejándola lista para la próxima lectura.
5.11-Módulo procesamiento
El módulo “procesamiento” es un nexo entre la base de datos y el resto del sistema, aunque
también posee funciones para convertir ciertos tipos de datos.
Para poder validar un usuario, éste módulo posee la función “validación_final_usuario”, a la
cual se le pasa un código de tarjeta. En primera instancia ésta función utiliza la función
“búsqueda usuario” de la base de datos para consultar si el código de tarjeta ingresado se
corresponde con el de algún usuario registrado.
En caso desfavorable, la función retorna un 0 y genera el log correspondiente. En caso de que
el código de tarjeta ingresado se corresponda con el de algún usuario registrado, se llama a la
función “devuelve_franja_actual” para consultar la/s franja/s horaria/s para la hora en la que se
llama a la función.
Si el usuario está habilitado para alguna de ellas, ésta función retorna un 1, y en caso
desfavorable retorna un 0 y genera el log correspondiente. (Véase descripción del módulo
“logs”).
También este módulo posee funciones que dado un número en forma de string lo convierte a
unsigned int o viceversa, las cuales son utilizadas para la recepción o transmisión de datos a
través de la UART.
25
5.12-Módulo base de datos
El módulo “base de datos”, como su nombre lo dice, es módulo de almacenamiento de datos.
No solo almacena los usuarios registrados y las franjas horarias establecidas, sino que también
posee funciones para agregar usuarios, editar usuarios o eliminar usuarios. Como éste
proyecto es una maqueta limitada, las franjas horarias son preestablecidas y no pueden ser
editadas. Dichas franjas son las siguientes:
• Franja 0: las 24horas del día
• Franja 1: desde las 8hs hasta las 15:59 hs
• Franja 2: desde las 16hs hasta las 23:59hs
• Franja 3: desde las 12hs hasta las 19:59hs
Para ingresar un usuario, éste módulo posee la función “ingresar_usuario”, la cual recibe el
código de la tarjeta y una franja horaria para la cual el usuario va a ser permitido ingresar al
recinto. Ésta función crea una variable de tipo usuario con las características indicadas y lo
guarda en un arreglo con tope nombrado “registrados”.
Para poder buscar un usuario y poder determinar si el mismo está registrado, “base de datos”
posee la función “búsqueda_usuario” a la cual se le pasa un código de tarjeta y busca si a
algún usuario en el arreglo “registrados” le corresponde. Retorna 1 si efectivamente esta
registrado dicho usuario y 0 en caso contrario.
Para poder editar un usuario ya registrado, éste módulo posee la función “editar_usuario” a la
cual se le pasa un código de tarjeta y una franja horaria.
La idea de editar un usuario es simplemente cambiarle la franja horaria, así que ésta función
busca el usuario al cual le corresponda el código de tarjeta ingresado, y le cambia la franja
horaria por la ingresada. En caso de que el código de tarjeta ingresado no es de ningún usuario
registrado, no produce cambio alguno.
Para proveer a los módulos que sea necesario de los datos como los usuarios registrados,
franjas horarias establecidas, o la cantidad de usuarios registrados (tope del arreglo), “base de
datos” posee funciones que devuelven esta información: “franjas_defs()”,
“get_cantidad_ingresados()”, “get_registrados()”.
26
5.13-Módulo logs
El módulo “logs” es el que tiene toda la información que permite crear registros de la actividad.
Se define el tipo log, el cual es una estructura que contiene un número de usuario de tipo
unsigned short int, la hora de tipo t_actual y un char llamado tipo_log.
El tipo t_actual fue definido en el módulo “reloj”, siendo una estructura de siete unsigned short
int, para llevar la cuenta de milisegundos, segundos, minutos, horas, días, meses y años.
Se puso especial énfasis en utilizar tipos que necesiten la menor cantidad posible de espacio
en memoria, ya que el mismo es restrictivo y para un proyecto de éstas características es
deseable poder guardar en RAM la mayor cantidad posible de registros sin que los mismos se
sobrescriban antes de ser descargados.
Todos los logs son guardados en un arreglo con tope en memoria RAM. Para probar la
funcionalidad de la maqueta, se le dio a la constante MAX_LOGS, que es la que define el
tamaño de dicho arreglo, el tamaño 50. Si éste proyecto se llevara a la realidad, se le debería
dar el tamaño máximo que permita la memoria disponible, ya que sería deseable que el
sistema de control de acceso funcionara standalone durante por lo menos una semana sin
riesgo de que los registros se sobrescriban. Empero, para probar el correcto funcionamiento de
la maqueta, era más adecuado trabajar con el tamaño que se le dio al arreglo, de forma de, por
ejemplo, poder corroborar que se estuvieran sobrescribiendo de forma correcta.
El tope del arreglo permite saber dónde se encuentra el último lugar ocupado del mismo hasta
el momento. Un nuevo log se guardará en el lugar siguiente a dónde se encontraba el tope al
momento en que el log se generó. También se lo utiliza para saber dónde está el último log al
momento de transmitirlos por hyperterminal para que el administrador los descargue.
Como el arreglo se maneja de forma circular, no siempre existe una relación directa entre el
tope del arreglo y la cantidad de logs almacenados en él. Al momento de transmitir los logs, se
desea recorrer únicamente los índices del arreglo en lo que hay un log almacenado, ya que los
otros índices contienen basura. Es por esto que se creó otra variable que indica la cantidad de
logs almacenados en el arreglo. El valor de ésta variable es mayor o igual que 0 y menor o
igual que MAX_LOGS.
27
Pseudocódigo de la función que agrega un nuevo log al arreglo:
void agregar_log()
aumento tope, si supera MAX_LOGS pasa a valer 0;
guardo ultimo_log en la posición tope del arreglo;
si cantidad_logs distinto de MAX_LOGS
aumento cantidad_logs;
// si fuera igual a MAX_LOGS significa que el nuevo log que //agregué está
sobrescribiendo a uno viejo, por lo tanto la //cantidad no aumenta
Observar que ésta función no recibe parámetros. Esto se debe a que todo nuevo log se genera
en la misma variable, llamada ultimo_log y una vez creado el mismo se ejecuta la función
agregar_log.
El proceso para guardar un log nuevo en el arreglo es el de la figura 16.
Figura 16 : Secuencia almacenar logs
Se hubiera podido implementar también una función guardar_log que recibiera el tipo de
acontecimiento que se registra como parámetro y el número de usuario o cero en caso de ser
el mismo desconocido. Esta implementación permitiría tener menos funciones para hacer lo
mismo. Si bien se reconoce que es una implementación más eficiente, el tiempo antes de
devolver el micro controlador debió emplearse para pulir otros detalles que afectaban la
Ocurre un
acontecimiento que
debe ser registrado
Se ejecuta la función
guardar_log_x,
siendo x el tipo de
acontecimiento
guardar_log_x ejecuta la
función generar_log, que da
a ultimo_log valores según
el tipo de log, fecha y hora y
pone el usuario en 0
En caso de que se conozca el
usuario que generó el
acontecimiento,
guardar_log_x asigna su
número al atributo usuario
guardar_log_x llama
a la función
agregar_log
28
funcionalidad del proyecto y luego de haber entregado el micro controlador preferimos no
modificar el código ya que podría generarse algún error de funcionamiento que no sea
detectado por el grupo.
Es importante observar que los logs deben generarse en la transición de un estado a otro, ya
que de generarse en el mismo estado, se almacenarían logs repetidos, lo que no tiene utilidad
y entorpece la lectura de los mismos.
Hay 8 tipos de acontecimientos que se registran:
1. Un usuario inválido quiso entrar al recinto y se le denegó el permiso
2. Un usuario válido quiso entrar al recinto y se le denegó el permiso por estar fuera de su
franja horaria
3. Se desenergizó el cerrojo porque se pulso el botón de salida
4. Se desenergizó el cerrojo porque un usuario válido quiso entrar al recinto dentro de su
franja horaria
5. Se energizó el cerrojo
6. Se activó la alarma
7. Se apagó la alarma
8. Se accedió al menú
Tanto el arreglo de logs guardados como su tope y la cantidad de elementos que contiene son
variables que pueden modificarse únicamente desde el mismo módulo.
Se crearon las funciones “ver_log”, “get_tope_log”, y “get_cant_logs” para poder ver un log en
determinada posición del arreglo y conocer el tope y la cantidad de logs guardados. Esto
protege las variables, evitando que otros módulos corrompan sus valores.
Se tiene una función “borrar_logs”. Visto desde el punto de vista del administrador, se puede
llamar a ésta función, que borra todos los logs guardados, desde una opción en la pantalla ver
registros del menú. Desde el punto de vista de la implementación, ésta función no borra
realmente los logs, sino que setea el tope del arreglo y la cantidad de logs guardados a cero,
de forma tal que todos los logs que haya guardados pasan a ser basura.
29
5.14-Módulo menú
El menú se manejó como un conjunto de estados dentro de la máquina de estados principal,
que se representan en la figura 17. Al ser ésta la misma máquina de estados que contiene la
validación de las tarjetas, no se podrá permitir el ingreso a un usuario desde el exterior del
recinto mientras que se está manejando el menú. No ocurre lo mismo con el pulsador de
egreso y la alarma, ya que su estado se controla en otra máquina de estados, que funciona de
forma concurrente con la del menú.
Figura 17 : Máquina estados del menú
Hay 8 pantallas dentro del menú, que permiten tomar acciones que se detallan más adelante.
Las mismas de despliegan en la hyperterminal de Windows a través de la UART del micro
controlador. El usuario indicará sus opciones escribiéndolas también en hyperterminal. Para
ello se debe configurar una conexión que interprete VT100 y se comunique a 1200bits/seg.
Luego de cada opción indicará que la misma se envíe pulsando la tecla ENTER.
La interpretación de VT100 es importante ya que se utilizan las secuencias de comandos
correspondientes a limpiar pantalla, subrayar y quitar atributos, ésta última para dejar de
30
subrayar. Se limpia la pantalla siempre antes de presentar una nueva pantalla y también al salir
del menú. Se subrayan algunas letras para indicar que son las que se deben enviar para elegir
una determinada opción. Por ejemplo, para indicar que la letra ‘S’ es la que se debe enviar si
se desea elegir la opción <Salir>.
Dado que se trata de una maqueta, se asume que todo usuario que intente acceder al menú
tiene permiso de administrador y por lo tanto no se pide contraseña o comprobante de que se
tenga éste permiso. Es por esto que en adelante se le llamará al usuario que maneja el menú
“el administrador”, para diferenciarlo de los otros usuarios.
5.14.1-Pantalla principal
Para acceder al menú, el usuario administrador conecta la UART a un PC y envía el carácter
‘M’, escribiendo ‘M’ + ENTER. Se despliega entonces la pantalla principal, con el siguiente
mensaje:
Bienvenido al menú del sistema Control de Acceso
Usted puede:
<1> Agregar nuevo usuario
<2> Editar un usuario
<3> Borrar un usuario
<4> Ver las franjas horarias
<5> Obtener registros
<6> Establecer fecha y hora
<7> Ver usuarios registrados
Elija su opción y a continuación ingrese <ENTER>.
<Salir>
En todas las pantallas se encuentra la opción Salir. Al tener la letra “S” subrayada, se está
indicando que al enviar “S” + ENTER se saldrá del menú. Esto limpia la pantalla y hace que se
vuelva al estado de espera, permitiéndose nuevamente la validación de usuarios por medio del
lector de tarjetas magnéticas. Ésta acción se desencadena también al acabarse el tiempo de
timeout del menú. El tiempo de timeout del menú es fijo y de un minuto. En otra versión del
proyecto el mismo podría ser configurado desde el menú por el administrador. Éste tiempo se
refresca cada ver que se interactúa por UART con el micro controlador, ya sea por transmisión
o por recepción.
31
5.14.2-Pantalla “Agregar nuevo usuario”
Si el administrador desea agregar usuarios escribe “1” + ENTER
Se despliega entonces la pantalla siguiente:
Para agregar un nuevo usuario indique:
<N> <Ultimos 4 digitos del numero de tarjeta><ENTER>
<F> <Franja horaria para la que se lo habilita><ENTER>
<Salir>
<Volver a pantalla principal>
Por un lado se debe ingresar un número de usuario de cuatro dígitos precedido por una “N”.
Como éste proyecto se trata de una maqueta, se toma como número de usuario únicamente
los últimos 4 números de la tarjeta de proximidad. Observando de cerca el protocolo Wiegand,
esos 4 números representan el ID en formato BCD (Binary-Coded Decimal). Los dos primeros
números, que se ignoran en ésta maqueta, representan el Facility Code en BCD.
La forma de manejar los números de usuario de ésta maqueta permitiría de ésta forma tener
cualquier usuario cuyo ID esté entre 0001 y 9999 en BDC. Es importante notar que no se
puede tener un usuario con ID 0000, esto se debe a que éste ID se reserva en los registros
para el usuario desconocido.
Por otro lado se debe ingresar una franja horaria para asignarle a éste usuario, en la que será
admitido para abrir la puerta. El número de franja debe estar precedido por una F y tener un
formato de dos dígitos correspondientes a números decimales. Esto se hizo pensando que en
una futura versión del proyecto, las franjas podrían ser editables y sería razonable poder tener
hasta 100 franjas. En éste caso se consideró que para una maqueta era suficiente tener franjas
predeterminadas, las cuales van desde la 00 hasta la 03. No se chequea que la franja que
ingresa el administrador se encuentre definida, por lo tanto si se asignara a un usuario una
franja no definida, esto pasará desapercibido y el mismo no será admitido nunca. Éste error se
puede corregir editando el usuario.
Para que se ejecute la función de agregar un usuario, el administrador debe haber ingresado
un par usuario franja sin salir de la pantalla. En caso de que se salga de la pantalla, todos los
datos deberán ser ingresados de nuevo. El orden en que éste par sea ingresado es indistinto.
En caso de ingresar nuevamente uno de los datos sin haber ingresado el otro correspondiente
al par, el mismo se sobrescribirá. Se puede asignar más de un usuario sin tener que volver a
ingresar a la pantalla.
32
Siempre que se ejecute una función que no implica un cambio de estado en la máquina de
estados del menú, por ejemplo el ingreso de un nuevo usuario, se imprimirá en la pantalla
“OK.”, a modo de confirmación.
En todo el menú se mantiene que, de ingresar accidentalmente un dato que no corresponde a
una opción de la pantalla, el mismo se desecha al pulsar la tecla ENTER.
En todas las pantallas derivadas de la principal existe la opción “Volver a la pantalla principal”.
Esto implica que al transmitir la opción “V” se volverá a desplegar la pantalla principal y las
opciones que podrá escoger el administrador serán las de la misma.
De lo anterior se deduce que si luego de ingresar a la pantalla “ingresar usuario” se ingresan
los siguientes datos:
“N9945” + ENTER
“N9988” + ENTER
“H01” + ENTER
“F01” + ENTER
“F00” + ENTER
“N9900” + ENTER
Los usuarios ingresados finalmente serán el 9988 admitido en la franja 01 y el 9900 admitido
en la franja 00.
5.14.3-Pantalla “Editar un usuario”
En ésta pantalla se despliega el siguiente mensaje:
Para editar un usuario existente indique:
<N> <Ultimos 4 digitos del numero de tarjeta><ENTER>
<F> <Franja horaria para la que se lo habilita><ENTER>
<Salir>
<Volver a pantalla principal>
El procedimiento para editar usuarios es el mismo que para agregar uno, con todas las
restricciones y posibilidades.
En éste caso se buscará en la base de datos el número de usuario indicado y se le sustituirá la
franja horaria por la nueva. En caso de que se indicara editar un usuario inexistente, se
consumirá el par usuario – franja, se recibirá la confirmación, pero no se realizará ninguna
acción en la base de datos. Esto se debe a que la función de editar un usuario se ejecuta, pero
33
al no encontrarse el usuario a editar, no realiza ninguna acción. En otra versión del proyecto
esto podría mejorarse transmitiendo una advertencia de que el usuario indicado no existe, pero
cómo en éste caso se trata de una maqueta, el administrador deberá tener la precaución de
que esto no desencadene situaciones indeseadas.
5.14.4-Pantalla “Borrar un usuario”
En ésta pantalla se despliega el siguiente mensaje:
Para borrar un usuario existente indique:
<N> <Ultimos 4 digitos del numero de tarjeta><ENTER>
<Salir>
<Volver a pantalla principal>
De la misma forma que en las pantallas anteriores, se indicará el número del usuario a borrar.
En éste caso no se debe indicar una franja horaria, por lo tanto la función que borra el usuario
se ejecuta automáticamente. En caso de que el mismo no exista, el comportamiento es
análogo a cuando se pide editar un usuario inexistente.
5.14.5-Pantalla “Ver franjas horarias”
En ésta pantalla es en la que más se nota la restricción de que estamos ante una maqueta. Es
por eso que las franjas horarias se pueden ver pero no modificar. Al tener franjas horarias fijas,
el mensaje que se verá siempre será:
Las franjas horarias actuales son:
Franja 00: hora de inicio 00:00 hora de fin 23:59
Franja 01: hora de inicio 08:00 hora de fin 15:59
Franja 02: hora de inicio 16:00 hora de fin 23:59
Franja 03: hora de inicio 12:00 hora de fin 19:59
<Salir>
<Volver a pantalla principal>
Es importante observar que las franjas se superponen, por lo tanto a un momento del día
determinado no corresponde necesariamente una única franja horaria. La franja 00 comprende
todo el día, ya que todas las franjas horarias comprenden también los bordes del conjunto
horario y la precesión de las mismas es de un minuto.
34
Otras restricciones debidas a la condición de maqueta del sistema son que no se controlan los
días de la semana, por lo tanto las franjas horarias se aplican tanto a días laborables como no
laborables y tampoco hay forma de configurar que se le deniegue el acceso a los usuarios en
días particulares tales como feriados.
5.14.6-Pantalla “Obtener registros”
Uno de los aspectos principales de este sistema de control de acceso es que registra
acontecimientos importantes, de forma que luego se los puede descargar de forma amigable
con el usuario administrador.
Los detalles sobre los registros y como se almacenan se describen en la sección “Registros”.
En ésta sección se describe la pantalla que permite al usuario administrador descargar los
mismos.
Al ingresar a la pantalla se despliega el mensaje:
Estos son los ultimos registros:
// Se despliegan todos los registros comenzando por el más reciente
<Borrar todos los registros>
<Salir>
<Volver a pantalla principal>
Se desplegarán tantos registros como haya almacenados, existiendo una cantidad máxima de
registros que se pueden almacenar. Cada registro se separa del anterior y siguiente por una
línea libre, de forma tal de facilitar la legibilidad.
El formato general de los registros es:
Fecha y hora:
01/01/2014 15:37:00
<Tipo de log indicando usuario si es relevante>
Dónde los mensajes posibles para cada tipo de log son:
• Usuario invalido <nº de usuario> quiso acceder y fue rechazado.
• Usuario <nº de usuario> quiso acceder fuera de su horario permitido.
• Se pulso el boton de salida.
• Se le permitio acceso a usuario <nº de usuario>.
35
• Se energizo el cerrojo.
• Se activo la alarma.
• Se apago la alarma.
• Se accedio al menu.
Una vez desplegados los registros en hyperterminal, el administrador puede guardarlos en un
archivo de texto. Asimismo, puede borrar todos los registros mediante la opción señalada. No
hay forma de eliminar los registros uno por uno. Si los registros no son borrados
explícitamente, se conservan hasta que se supere el tamaño del buffer en que se los almacena
y el mismo se sobrescriba de forma circular. Esto significa que si se excede el tamaño del
buffer, los registros más antiguos serán sustituidos a medida que lleguen nuevos registros.
Se deja al administrador la interpretación de los datos, por ejemplo, si se le permite acceder a
un usuario (cuyo número queda registrado) y segundos después comienza a sonar la alarma,
lo más probable es que haya sido éste usuario quien dejó la puerta abierta. Si en cambio
comienza a sonar la alarma y no existe un registro de que segundos antes se permitiera
acceso o salida a algún usuario, entonces la puerta fue forzada.
5.14.7-Pantalla “Establecer fecha y hora”
La fecha y hora se inicializan por defecto en la inicialización del programa. De todas formas,
ésta fecha y hora por defecto (01/01/2014 00:00:00) serán lógicamente distintas a las reales.
Es por esto que es altamente recomendado para el administrador establecer la fecha y hora
desde el menú inmediatamente luego de inicializado el sistema de control de acceso y luego
borrar los registros, para que no queden registros anteriores con la fecha y hora por defecto,
que podrían llevar a confusiones.
Al ingresar a ésta pantalla se verá el mensaje:
Para establecer la fecha y hora indique:
<F> <Fecha con el formato: DDMMAAAA> <ENTER>
<H> <Hora con el formato: HHMMSS> <ENTER>
Los registros que se encuentren guardados actualmente quedaran segun la fecha y hora
anteriores.
<Salir>
<Volver a pantalla principal>
36
De la misma forma que en la pantalla Agregar nuevo usuario, se ingresan la fecha y la hora por
separado, con el formato indicado, por ejemplo, ingresar
“F11072013” + ENTER
“H145600” + ENTER
Inicializará el reloj en el día 11 del mes 7 del año 2013 a la hora 14:56:00.
Si bien el reloj tiene una precisión de 250ms, la cantidad de milisegundos al inicializar el reloj
será siempre 0 por defecto.
Para que la fecha funcione adecuadamente se controla la cantidad de días máximos
correspondiente a cada mes y años bisiestos.
5.14.8-Pantalla “Ver usuarios registrados”
En ésta pantalla se muestra una lista de los usuarios registrados y la franja horaria a la que
tienen permitido el ingreso. Se recomienda al administrador revisarla luego de realizar cambios
en el registro de usuarios para confirmar que se hayan realizado de forma satisfactoria.
A continuación se muestra un ejemplo de cómo podría verse ésta pantalla si los usuarios
admitidos al momento de consultarla son el 9988 admitido en la franja 01 y el 9900 admitido en
la franja 00:
Estos son los usuarios que se encuentran admitidos actualmente:
9988 admitido en franja 01
9900 admitido en franja 00
<Salir>
<Volver a pantalla principal>
37
6-Conclusiones
Si bien este proyecto es una maqueta, el grupo de trabajo observó que perfectamente es
extrapolable a un control de acceso real.
Observamos que haber dedicado la primera semana entera a planificación con el tutor del
proyecto fue una decisión clave y muy satisfactoria puesto que nos liberó de demoras a la hora
de implementar código.
Se logró implementar la comunicación entre el módulo UC y el lector de tarjetas de proximidad
Wiegand y el módulo UC con las entradas y las salidas digitales.
Se logró implementar de forma satisfactoria la comunicación vía hiperterminal emulando VT100
para el uso del menú.
Para poder realizar el funcionamiento de Control de Acceso, se logró implementar tres
máquinas de estado funcionando en paralelo, y la arquitectura aplicada fue Round Robin con
interrupciones.
Tal cual se pensó al comenzar el proyecto, la memoria disponible del micro controlador no fue
un problema en ninguna etapa de realización del mismo. Esto se debe a que el código del
programa no es muy extenso y que también todas las variables destinadas a almacenar
información fueron pensadas para que ocupen la menor cantidad de bytes posibles en memoria
RAM.
Tras testear la funcionalidad del código, notamos la necesidad de proteger ciertas variables
modificables por interrupciones (problema de datos compartidos), los cuales fueron
solucionados mediante las funciones __disable_interrupt () y __enable_interrupt () en las líneas
de código donde corresponda.
Durante la realización del proyecto, notamos que fue de gran utilidad lo trabajado en los
laboratorios, puesto que el reciclado del código utilizado en los mismos para este proyecto nos
permitió ganar algo más de tiempo.
Analizando las complicaciones que se tuvieron para la realización del proyecto, concluimos que
no se tuvieron demasiadas. El procesamiento de la información brindada por el lector de
proximidad no fue un problema y que las medidas realizadas con el osciloscopio de su
comportamiento fueron muy precisas. De nuevo es preciso resaltar que la ausencia de
complicaciones se debe a la buena planificación del trabajo.
38
La conclusión más contundente es afirmar que se logró finalizar el proyecto de forma
satisfactoria en tiempo y forma, como también que el mismo posee todas las funcionalidades
deseadas y hasta algunas más de las que se planificó inicialmente.
7-Anexos
7.1-Conceptos del curso aplicados al proyecto
Los conceptos aplicados del curso al proyecto son variados, podemos dividirlos en tres grandes
aspectos, a saber:
-herramientas de desarrollo
-plataforma de hardware
-arquitectura de software
En cuanto a las herramientas de desarrollo podemos resaltar la programación en lenguaje C y
el uso del software IAR y principalmente su herramienta Debugger; herramienta fundamental
para testear los módulos en todas las etapas del diseño.
A lo largo del curso se estudio en los laboratorios, el uso de registros específicos para utilizar
Timers, Uart y puertos de E/S de propósito general y con capacidad de interrumpir, a través del
entendimiento de las hojas de datos del modulo hardware.
Este aprendizaje fue útil ya que facilito la implementación de los módulos que utilizan las
caracteristicas descriptas.
Por último y no menos importante, se aplico los conocimientos adquiridos de arquitectura de
software específicamente Round Robin con interrupciones y el estudio del problema de datos
compartidos y las posibles soluciones.
7.2-Planificación del proyecto
La planificación previa difiere levemente de la definitiva ya que a priori es muy difícil saber
exactamente que módulos se deberán implementar y cuanto tiempo insumirá cada uno.
De todas formas al inicio del proyecto se dedico tiempo a la modularización y la
implementación en maquinas de estado lo que a futuro fue clave a la hora de cumplir con la
planificación y los objetivos del proyecto.
39
En cuanto a las horas dedicadas al proyecto, podemos afirmar que fueron largamente
superiores a lo que se especifica, pensamos que esto se atribuye a la poca experiencia en
realizar un proyecto de mediano porte y no saber delimitarlo para que se realice en el tiempo
estipulado. Pensamos que otro factor determinante fue la poca experiencia previa adquirida en
el lenguaje de programación C.
7.3-Especificación del proyecto
Control de Acceso
especificación final
Sistemas embebidos para tiempo real 2013
Florencia Blasina, Gonzalo Finozzi, Nicolás Marquez
Tutor: Conrado Rossi
Índice
Descripción del problema a ser resuelto ..................................................................................... 40
Antecedentes............................................................................................................................... 40
Objetivo general .......................................................................................................................... 40
Objetivos específicos .................................................................................................................. 41
Alcance ........................................................................................................................................ 41
Descripción funcional .................................................................................................................. 42
Diagrama de bloques .................................................................................................................. 43
Requerimientos y restricciones ................................................................................................... 44
Diseño preliminar......................................................................................................................... 44
Planificación ................................................................................................................................ 44
40
Descripción del problema a ser resuelto
En muchas actividades cotidianas es necesario tener un control sobre el ingreso/egreso de personas en determinadas áreas, estas pueden ser oficinas, recintos laborales, instituciones de estudio, bancos o salas de procesamiento de datos. También existen problemas concretos con el uso compartido de electrodomésticos, medicación o instrumentos de laboratorio de alto valor. Para resolver este problema se emplean sistemas que implementan dicho control permitiendo o no el acceso a las áreas descriptas. Entre las aplicaciones que un control de acceso puede tener, ejemplificamos algunas situaciones:
• Las instituciones necesitan tener un control de horarios de entrada/salida del personal para liquidación de sueldos y/o control de inasistencias.
• Por seguridad se puede querer restringir a un selecto grupo de usuarios el acceso a determinados bienes o áreas específicas de una empresa, hogar o local de trabajo.
Control de Acceso resuelve esta problemática debido a que realiza el control descripto anteriormente logrando el nivel de seguridad necesario para este tipo de aplicaciones.
Antecedentes
En el curso de Sistemas Embebidos para Tiempo Real no existe una versión previa a esta solución, sí existen en el mercado muchas marcas que comercializan este producto con diversas implementaciones. Existe un protocolo de comunicación estándar entre lectores (proximidad, pin, biométrico, etc.) y el micro controlador (UC) llamado Wiegand, el cual se tomara como base para la implementación.
Objetivo general
Desarrollar un sistema que implemente un control de acceso de una puerta utilizando un UC y un lector de tarjetas proximidad. Simular su funcionamiento en una maqueta que además del módulo UC tendrá tres entradas: el lector, una que indique al UC el estado (abierto o cerrado) de la puerta y un pulsador que permitirá abrir la puerta desde el interior del recinto. Tendrá dos salidas digitales (LEDs), uno que simule una alarma sonora, que se encenderá cuando el cerrojo esté magnetizado y la puerta abierta y el otro que indique el estado del cerrojo: LED encendido - cerrojo desmagnetizado, LED apagado - cerrojo magnetizado.
41
Objetivos específicos
Para cumplir el objetivo general, se deberán cumplir los siguientes objetivos específicos:
• Implementar la comunicación entre el módulo UC y el lector de tarjetas de proximidad Wiegand y el módulo UC con las entradas y las salidas digitales.
• Implementar la comunicación con el usuario ya sea para configuración o para obtener reportes. Esta comunicación se realizara vía hyperterminal a través de un menú que se implementara emulando una terminal grafica del tipo VT100.
• El UC se comunicará con la hyperterminal de un PC a través de su UART.
Alcance
Estudiar el funcionamiento del protocolo Wiegand corroborando el mismo con mediciones en las líneas de datos del lector. A nivel de hardware y para implementar la comunicación con el lector, se desarrollara una etapa de adaptación de niveles de tensión, también se implementara el conexionado de las entradas y salidas digitales. Se implementara un reloj de tiempo real que lleve la cuenta de años, meses, días, horas, minutos y segundos. Para el menú se utilizará esquema básico brindado por los docentes, el cual se modificará para obtener la funcionalidad necesaria. El menú permitirá el alta y baja de usuarios, seteos de parámetros básicos de funcionamiento como ser fecha y hora, tiempo de desmagnetización del cerrojo y franjas horarias. Una vez configurado el sistema deberá funcionar standalone. Para implementar el software del sistema y el menú para la configuración y gestión, se tendrán en cuenta las siguientes características:
• Seteo desde la terminal de fecha y hora. • Único nivel de acceso sin password. • Seteo del tiempo de apertura de puerta, es el tiempo en segundos durante el cual el
cerrojo permanece desenergizado luego de una lectura válida (entrada al recinto) o luego de pulsar el switch de salida (salida del recinto).
• Deberá tener al menos dos franjas horarias preconfiguradas de acceso, una que permita acceso sin restricciones de horario y otra que permita acceso en horario de oficina únicamente.
• El sistema admitirá al menos dos usuarios distintos, cada uno de ellos con su respectivo número de identificación asociado a una tarjeta de acceso.
• Los datos personales de cada usuario serán al menos: nombre, apellido, fecha de ingreso a la empresa, fecha de validez del permiso para ingreso. Luego de expirada la fecha de validez, el usuario no podrá ingresar hasta que se renueve la misma.
• A cada usuario se le deberá asignar una franja horaria preconfigurada. • Para la gestión del sistema se deberá almacenar en memoria RAM un listado con los
accesos válidos e inválidos indicando la fecha y hora de lectura de la tarjeta y titular de la misma. También se registrará fecha y hora de las salidas, si bien no se podrá reconocer el usuario en éste caso. La escritura en este espacio de memoria será cíclico es decir que cuando se complete se sobrescribirá desde el inicio.
• La memoria definida para almacenar los logs, podrá ser borrada desde a través de un omando ingresado en el menú.
42
Descripción funcional
Luego de configurar los parámetros de uso, la operativa para el ingreso se ejemplifica en el siguiente diagrama.
En base a la operativa descripta anteriormente se definen los bloques o módulos de software para implementar la solución.
43
Diagrama de bloques
Diagrama conceptual de los bloques a implementar indicando la interacción entre ellos, en la etapa de diseño se describirán las funciones que pertenecen a cada bloque y se especificara detalladamente cómo interactúan entre ellos.
El módulo de manejo de hardware se implementara para agrupar los módulos que interactúan directamente con los periféricos del UC logrando independizar el hardware del software, facilitando la programación para futuros cambios de plataformas de hardware. Los módulos marcados con asterisco utilizaran funciones implementadas en el módulo de
manejo de hardware.
44
Requerimientos y restricciones
Memoria: se desea que la memoria flash alcance para guardar el programa a ejecutar y la información de los usuarios y que la memoria RAM alcance para guardar por lo menos 100 logs de eventos y/o alarmas. Tiempos de respuesta: sabemos que el tiempo entre interrupciones una vez comenzada a leer una tarjeta es de 2ms nominales, se debe cuidar de no perder bits de ésta lectura. Se nos ofreció el uso de un módulo Tinynode 184 con una Standard Extension Board (SEB), éste módulo utiliza un UC MSP430F2417 y cuenta con 8kB de memoria RAM, 92kB de memoria flash y un oscilador de cuarzo de frecuencia 32,768kHz. En el conector de expansión de SEB contamos con 30 pines de entrada/salida, de los cuales 5 pueden ser utilizados para recibir interrupciones externas (necesarias para las lecturas del lector de proximidad).
Diseño preliminar
Plataforma de hardware: utilizamos el módulo Tinynode 184 con una Standard Extension Board.
Para adaptar niveles de tensión, se realizará un divisor resistivo y un filtro de entrada con frecuencia de corte a determinar.
Arquitectura de software: se utilizará Round Robin con interrupciones y de ser necesario encolado funciones.
Nos apoyaremos en un diseño de módulos en base a bloques conceptuales. Una vez determinados los módulos se verá qué funciones se deben implementar y sus encabezados, así como las interfaces de los módulos.
Planificación En la planilla se adjunta la información de las tareas a realizar (color azul), hitos, presentaciones, avance y entrega final (color rojo). Los módulos a implementar en la primera parte son:
- lectura (lector de proximidad) - menú - manejo de memoria RAM - búsqueda en base de datos - validación de usuario/franja - bases de datos Usuarios, parámetros - manejo de HW
y los módulos a implementar en le segunda parte son:
- reloj - alarma - lectura entrada digital - manejo de salidas
45
46
7.4-Datasheet del lector de proximidad PR-200 Proximity Card Reader de Jantek Frequency is 125KHZ Maximum reading range from 14~20cm Highly reliable operation with consistent reader range and performance Water resistant for indoor/outdoor use Built-in watch dog, the system never hang. Built-in tamper switch detects if case is forced open or destroy Multicolor LED with internal or host control Available with Wiegand interface, TTL or RS485 is in option.
Dimensions : 13.0(L) x 8.6(W) X 2.5(H)cm
Power requirements : DC 12V 1A
Environment : Operating temperature Humidity
: 0°C~50°C : 0~90%RH
Current requirements : 50~160mA
Relay 2 relay contact (Max. DC 12V 1Amp)
6.5-Archivos fuente Los archivos están adjuntos en la documentación entregada, se detallan los mismos:
• base_de_datos.c • base_de_datos.h • cola_char.c • cola_char.h • hardware.c • hardware.h • lectura.c • lectura.h • logs.c
47
• logs.h • main_proyecto.c • maq_estados.c • maq_estados.h • menú.c • menú.h • procesamiento.c • procesamiento.h • reloj.c • reloj.h