Artigo orixinal
Control de acceso e sistema de bloqueo para o centro de inmunoloxía molecular
Control de acceso e entrelazado Sistema para o centro de inmunoloxía molecular
ing. Marcel Pedreira Marcel1, Dr Valery Moreno Vega2
1. Centro de inmunoloxía molecular, a Habana, Cuba, correo electrónico: [email protected].
2. Departamento automático, Facultade de Enxeñaría Eléctrica, Instituto Superior Politécnico José Antonio Echeverría, A Habana, Cuba. Correo electrónico: [email protected].
Resumo
No presente traballo o deseño e desenvolvemento dun sistema de control de acceso e entrelazado no centro de inmunoloxía molecular porque Os sistemas comerciais deste tipo instalados nese centro non cumpren todas as necesidades. O sistema proposto consta de dúas tarxetas electrónicas: o controlador de portas eo controlador de interlock, ambos foron desenvolvidos en función do microcontrolador Microchip programado usando o compilador CCS PCW. Estas tarxetas son capaces de comunicarse con dispositivos de lectura de código de barras, proximidade, biométrica ou calquera outra que transmite o protocolo de WIEGAND. Tamén deben ser configurados para operar de forma desexada, para iso, unha aplicación de software de parametría desenvolveuse usando Qt como marco e implementación de prácticas de enxeñaría de software eficiente. Esta aplicación comunícase cos controladores a través de RS232 con Modbus Protocol.
Palabras clave: Control de acceso, interlock, microcontrolador, MODBUS, WIEGAND, enxeñaría de software.
Resumo
Este artigo mostra o deseño e desenvolvemento dun control de acceso e sistema de interlockación para o centro de inmunoloxía molecular porque os sistemas comerciais instalados neste centro non cumpren todas as necesidades .. O sistema proposto consta de dúas placas electrónicas: o controlador de portas eo controlador de interlock, ambos foron desenvolvidos en función do microcontrolador PIC de Microchip programado usando o compilador CCS PCW. Estas tarxetas son capaces de comunicarse con dispositivos como a lectura de código de barras, a proximidade, a biométrica ou calquera outra que transmita polo Protocolo de Wiegand. Tamén deben ser configurados para operar de forma desexada e, polo tanto, a aplicación de software desenvolveuse usando Qt como marco e implementando prácticas eficaces de enxeñaría de software. Esta aplicación comunícase cos controladores a través de RS232 usando o protocolo Modbus.
Palabras clave: control de acceso, interlocro, microcontrolador, modbus, WIEGAND, enxeñaría de software.
Introdución
O concepto de control de acceso foi usado en varios contextos, está asociado con conceptos de seguridade informática e redes de computadores. Non obstante, neste traballo o sistema é referido ao vinculado ás portas dunha edificación. Baixo estes principios, un sistema de control de acceso administra a entrada a áreas restrinxidas e impide que as persoas non autorizadas ou indesexables teñan a liberdade de acceder a certas instalacións. Do mesmo xeito, pode ter coñecemento da asistencia persoal, horarios de ingresos e graduación e tamén poder ter un control histórico das entradas de persoas a todas as áreas.
Os sistemas de control de acceso están formados por varios dispositivos ou compoñentes. Os controladores de portas constitúen o elemento fundamental ou de intelixencia nun sistema de control de acceso. Doutra banda, os dispositivos de lectura utilízanse para a identificación do usuario a través dunha tecnoloxía, como o código de barras, a radiofrecuencia ou o código de biometría. Os elementos de acción final son responsables do bloqueo físico das portas, poden ser parafusos ou bloqueos electrónicos, electromagnets, etc. Ademais, estes sistemas normalmente presentan un software de supervisión que opera en todos os controladores dispostos na rede e, polo tanto, realizan seguimento e control. Tamén é posible integrar circuítos de televisión pechados, sistemas de loita contra os incendios contra os intrusos e os mecanismos de interlocación Usando este último, o acceso a unha área común entre dúas portas pode ser bloqueada cando un deles foi aberto.
O Centro de Inmunoloxía Molecular (CIM), pertencente ao Polo Científico no oeste da capital cubana, é unha institución especializada na investigación, desenvolvemento e fabricación de produtos biofarmacéuticos para a loita contra o cancro a partir do Cultura das células de mamíferos de acordo coa normativa de boas prácticas de produción (GMP). Este centro, así como outro polo dedicado á biotecnoloxía, ten áreas de produción chamadas salas limpas especialmente deseñadas para obter baixos niveis de contaminación.Estas salas teñen os seus parámetros ambientais estrictamente controlados: partículas no aire, a temperatura, a humidade, o fluxo de aire, a presión interior, a iluminación etc.1
O sistema de control de acceso ten un papel importante na obtención deste obxectivo. Actualmente, dous control de acceso e sistemas de interlocación de diferentes fabricantes están en funcionamento en funcionamento: Kantech e Siemens. Estes sistemas teñen as seguintes desvantaxes na súa aplicación:
· Arquitectura pechada. Hai incompatibilidade en termos de protocolos de comunicación, bases de datos, etc. Por este motivo, a información está fragmentada ou divida, o que fai que unha xestión sexa difícil de nivel central.
· Soporte técnico. Presentáronse dificultades coa obtención de tarxetas de proximidade e actualmente están esgotadas os traballadores existentes que necesitan entrar nunha determinada área que non teña os medios para facelo.
· A pesar de ser sistemas ben eficientes e robustos, concedéronse circunstancias particulares nas que non son efectivas ou non poden resolver o problema usando o sistema só coas opcións que trae por definición.
Por este motivo, creouse a necesidade de implementar un novo control de acceso e sistema de control de interlock, que está totalmente desenvolvido no CIM.ÉTE permitirá a xestión central da información e un maior nivel de configuración, personalización e expansión, permitindo proporcionar as necesidades non resoltas polos sistemas de pagamento instalados na actualidade.
Neste traballo, descríbese o proceso de desenvolvemento do sistema proposto para resolver o problema anterior. Na sección 2, é dada unha descrición, aproximadamente, do devandito sistema, destacando os elementos que o compoñen, así como os protocolos utilizados. Na sección 3, o deseño dos controladores é detallado, contar hardware e firmware, necesarios para a operación. A sección 4 aborda todo o proceso de desenvolvemento da aplicación de software de parametrización de cada un dos controladores. Finalmente, a sección 5 describe os resultados obtidos na implementación do sistema a unha escala piloto.
Descrición xeral do sistema proposto
A solución presentada consiste nun sistema composto por dous elementos fundamentais: o controlador de portas eo controlador de interlock. Ambas son tarxetas electrónicas con diferentes fins dentro do sistema.
A función do controlador da porta é, como o seu nome indica, o control das portas. Un controlador deste tipo pode controlar un máximo de dúas portas. Deste xeito, é responsable de recibir a solicitude de acceso que provén do elemento de identificación, determine se o código de chegada ten acceso pola porta especificada de acordo coa configuración previa e, se é positivo ou válido, desbloquear a porta en cuestión. A Figura 1 mostra a conexión deste controlador. Cómpre salientar que isto é capaz de recibir a codificación enviada desde calquera lector que implementa o formato de protocolo de WIEGAND 26. Este protocolo está aberto e considérase un estándar dentro dos sistemas de control de acceso. Deste xeito, a comunicación cunha ampla gama de dispositivos de lectura que se producen actualmente está garantida.
Outro elemento asociado ao sistema é un dispositivo para detectar o caso de que un usuario quere saír dunha local a través de algúns Porta controlada, é dicir, pola parte contraria onde se atopa o lector. Estes casos son chamados REX (solicitude de saída) na maioría dos sistemas de control de acceso e un elemento está incluído no hardware do sistema que notifica a través dun sinal, esta acción ao controlador. Este elemento pode ser un sensor de presenza ou un botón simple.2
O controlador de interlock é responsable de engadir a capacidade de entrelazado ao sistema. Este mecanismo consiste en bloquear unha ou máis portas despois de detectar a apertura dunha porta dada. Isto faise, por suposto, cunha configuración previa do controlador, onde se establece esta relación ou interacción entre as portas. Este sistema pode ter moitos usos ou aplicacións e, no caso de CIM, úsase para reducir os riscos de contaminación cruzada, un concepto asociado ao GMP no que unha persoa que sae da área limpa pode inducir a contaminación ao que está a entrar. A Figura 2 mostra a conexión deste dispositivo.
Estes dispositivos deben estar configurados ou parametrizados, de xeito que realicen a función desexada. Para iso, desenvolveuse unha ferramenta de software que se comunica con estes a través dun porto RS-232 usando unha PC. O protocolo de comunicación entre a aplicación e os dispositivos é Modbus.Este protocolo aberto foi implementado para que os controladores sexan capaces de comunicarse co maior número de software posible, facilitando así a posibilidade de supervisión central a través dun SCADA, por citar un exemplo.
As dúas cartas están baseadas en microcontroladores de microchip pic, debido á gran difusión que existe destes dispositivos e para a dispoñibilidade destes coas súas ferramentas asociadas para implementar e verificar aplicacións deste tipo no CIM. A programación dos microcontroladores foi feita usando o compilador CCS PCW, para os motivos de coñecemento do autor e tamén para a dispoñibilidade legal do devandito software no centro. As probas de configuración de hardware dos dispositivos realizáronse utilizando o Picschool, unha ferramenta que consta dun modelo ou protoboard para a sintonía das aplicacións que utilizan microcontroladores PIC. A aplicación de parameterización desenvolveuse usando o cadro Qt, por ser unha plataforma de código aberto poderosa moi emitida neste momento.
Protocolo de Wiegand
Este protocolo é unidireccional e permite a transferencia de datos dun lector ao controlador. Aínda que foi concibido para os lectores de Wiegand Effect, dada a súa eficiencia nesta área, tamén foi implementado en lectores con outra tecnoloxía, como as de proximidade ou radiofrecuencia e mesmo en teclados numéricos. O protocolo establece liñas de datos, poder e sinalización. As liñas de sinalización son aquelas usadas para o manexo e LEDs de Horn, que normalmente posúen estes lectores, mentres que a transmisión de datos realízase a través de tres fíos:
· data1: liña para enviar lóxicas.
· Data0: liña para enviar ceros lóxicos.
· GND: fixo de referencia de ambos.
A figura 3 representa gráficamente este sistema de transmisión. No estado de descanso, as liñas de Data1 e Data0 están a un alto nivel. Para transmitir un pouco en `1’se enviar un pulso de baixo nivel de 50 anos de duración pola liña de datos1, mentres que DATAR0 segue sendo alto. Pola contra, transmitir un pouco a`0 ‘o que se fai é enviar un pulso baixo, da mesma duración, pero pola liña de datos, mentres que a liña de datos permanece alta. A separación entre cada pulso e a próxima é de aproximadamente 2 ms.
Usar este sistema pode transmitirse calquera número de bits. Non obstante, hai un consenso internacional para usar un certo número de bits e a interpretación deles. O formato máis utilizado e, polo tanto, o empregado neste proxecto é o Wiegand26, que especifica que o primeiro bit (B0) é a paridade dos primeiros 12 bits transmitidos (B1: 12), os próximos oito (B1: B8) constitúen Un número enteiro de 8 bits chamado FacturityCode, os seguintes 16 bits (B9: B24) representan un número enteiro de 16 bits chamado UserCode eo último bit (B25) é a estraña paridade dos últimos 12 bits transmitidos (B13: B24). 2
Protocolo Modbus
O protocolo de Modbus está baseado na arquitectura Master / Slave. Deseñado en 1979 pola empresa Modicon para o seu rango PLC, converteuse nun protocolo de comunicacións factuales estándar na industria e é que goza de maior dispoñibilidade para a conexión de dispositivos intelixentes. É principalmente debido ás seguintes razóns:
· É público.
· A súa implementación é fácil e require pouco desenvolvemento.
· Manexar bloques de datos sen ter restricións.
Ás veces, na literatura refírese a Modbus como unha estrutura de mensaxes, xa que non especifica unha capa física, o loque pode ser implementado usando diferentes estándares, como RS232, RS422, RS485 E, mesmo, mesmo, Sobre Ethernet. Existen dúas variantes con diferentes representacións numéricas dos datos e detalles do protocolo lixeiramente desigual: Modbus RTU e MODBUS ASCII.There tamén é unha versión de Modbus TCP, senón que é o formato RTU establecendo a transmisión a través de paquetes TCP / IP. A variante utilizada neste proxecto é a RTU.
Nunha rede de Modbus cada dispositivo ten un adicto. Calquera dispositivo pode enviar ordes, aínda que o habitual é permitir que só o profesor e os escravos estean limitados a responder ás solicitudes. A Modbus mensaxe enviada do mestre a un escravo contén o enderezo do escravo, a orde ou a fin de ser feita, os datos asociados co mando, e unha información redundante ou Suma de verificación para garantir a integridade da recepción.O protocolo establece unha gran variedade de comandos ou funcións, e neste proxecto só se utilizan os relacionados co valor do valor de varios dos rexistros de escravos (writemultiplisters) ea solicitude do contido destes rexistros (ReadholderGregisters). Cómpre salientar que o estándar oficial establece rexistros de 16 bits entre outras especificacións.3
Entón, como xa remitido anteriormente, neste proxecto Modbus RTU Protocol en RS232, onde a PC é o dispositivo Master e o Os controladores son escravos, aínda que se conecta unha á vez. Por este motivo, non hai necesidade de especificar indicacións para cada un dos escravos, xa que todas as mensaxes enviadas polo profesor son transmitidas ou transmitidas (enderezo 0) e só serán recibidas polo único escravo conectado a el. Non obstante, a implementación deste protocolo proporciona a posibilidade de expandir o sistema resultante de forma sinxela, sen moitos cambios significativos, introducindo un sistema de supervisión ou SCADA e conectando os controladores formando unha rede de Modbus.
Desenvolvemento dos controladores
Como se menciona anteriormente, as tarxetas que representan os controladores que compoñen o sistema proposto están baseados en microcontroladores PIC. Neste caso, un 16F877 foi usado para cada tarxeta. Estees un microcontrolador de 8 bits, pertencente ao medio alcance desta familia e que satisfaga perfectamente os requisitos das dúas aplicacións, cóntame a memoria, o número de entradas e saídas entre outros aspectos. Abaixo está a configuración do circuíto das tarxetas mencionadas, así como o firmware programado nos microcontroladores para o seu correcto funcionamento.
Hardware do controlador de portas
Na Figura 4 móstrase un esquema da configuración do hardware da tarxeta que representa o controlador de portas.
As liñas do alto Nabible do porto B foron utilizadas para recibir os datos enviados a partir dos dous lectores que se poden conectar Para un controlador, como se describe anteriormente no Protocolo de Wiegand, cada lector usa dúas liñas para a transmisión de datos: datos0 e datos1. Estaba conectado deste xeito a usar a interrupción do cambio de estado nas catro entradas máis significativas do porto B. Deste xeito, calquera variación en calquera destes pines interrompe o funcionamento do microcontrolador coincidindo coa chegada dun pouco pertencente ao pulso Tren correspondente a un código enviado por un lector. Outras seis liñas de entrada / saída do microcontrolador, esta vez configuradas como saídas, foron utilizadas para o manexo de lectores. Neste caso, foron reservados para a conexión de tres fíos de sinalización que proporcionan a maioría dos lectores que implementan o protocolo mencionado anteriormente para a activación dos LEDs Vermellos e Verdes, así como o corno.
A memoria externa estaba conectada usando a interface I2C e que a cargo de almacenar os códigos dos usuarios autorizados para acceder a calquera das portas pertencentes ao controlador en cuestión. Decidiu que a memoria era externa por dúas razóns fundamentais:
1. A memoria interna de EEPROM do microcontrolador non cumpre as necesidades do espazo.
2. Facilita o mantemento e reconfiguración do sistema como a exportación / importación dos datos é posible.
A estrutura desta memoria móstrase na Figura 5. Como se pode ver, utilízanse catro ubicacións para un código de usuario. O primeiro é gardado polo código de instalación, que como se indica anteriormente é un 8 número de bits. O código de usuario é entón almacenado, que ten 16 bits, polo tanto, úsanse dúas ubicacións para iso, no primeiro destes a parte superior e na segunda parte inferior deste número. Finalmente, a cuarta localización do código está ocupada pola política de acceso, que non é máis que un número que identifica o tipo de acceso que ten o propietario do usuario do código en cuestión. A táboa 1 relaciona os tipos de acceso eo seu número de política de acceso correspondente.
O número máximo de usuarios Para un controlador, foi ambientado a 256, a cantidade que satisfaga perfectamente as necesidades da aplicación. Entón, coa estrutura antes exposta, é necesaria unha memoria EEPROM I2C de 1 kX8. Para este propósito, utilizouse o circuíto integrado ST24W08MR que constitúe unha memoria coas características necesarias.
A canle asíncrona do porto serie ou o uso do microcontrolador foi reservado para a conexión da tarxeta a unha PC e realizará a configuración ou parametrización do controlador por esta ruta.É, polo tanto, que as liñas portuarias en serie foron acopladas a un MAX232, un circuíto integrado que adapta os niveis de tensión que manexa o microcontrolador á norma RS-232. Deste xeito, a PC está comunicada co microcontrolador usando o Protocolo Modbus.
Utilizáronse dúas liñas de entrada / saída do microcontrolador (configuradas como saídas) para a unidade das portas. Isto pódese basear en varios tipos de peche electrónico: socket, electromagnet, etc. e, en calquera caso, hai que ter en conta que estes elementos son alimentados por 24VDC ou 12VDC. A continuación, o circuíto necesario para a unidade baseada en relé estaba acoplado a estas dúas saídas de microcontrolador.
Tres outras liñas de entrada / saída do microcontrolador (esta vez configuradas como entradas) utilizáronse para detectar os sinais REX que, como se indica anteriormente, poden proceder desde un botón ou un sensor de presenza. En calquera caso, o dispositivo do sensor debe estar conectado a unha das entradas destinadas a isto, dependendo da porta tratada. A configuración de hardware do controlador de portas inclúe un circuíto de condicionamento destes sinais dixitais ás entradas de microcontrolador, así como unha lóxica para que unha activación de calquera destes signos interrompela pola liña correspondente á interrupción externa.4- 5
firmware do controlador de portas
O papel do controlador da porta é a recepción do código enviado desde calquera dos dous lectores a través do Protocolo de Wiegand e comparalo cos almacenados na memoria externa Para que, se hai unha coincidencia e aplícase a política de acceso, o acceso é dado á porta en cuestión. O firmware do microcontrolador obtido mediante o compilador CSS PCW, como se refire anteriormente, usando a linguaxe C para a programación. Este compilador ten varias instalacións para o programador, neste traballo os condutores proporcionados por esta ferramenta para o manexo de dispositivos I2C e para a implementación dun dispositivo de modbus escravo respectivamente. A continuación, o programa é Sectado fundamentalmente en tres funcións:
1. A función principal: principal.
2. A característica de coidados de interrupción debido ao cambio de estado en calquera dos catro pinos máis significativos en Port B.
3. A función de coidados de interrupción externa.
Na Figura 6, móstrase o diagrama de fluxo da función principal. Nesta función, o que se fai está constantemente levando a chegada dunha mensaxe de Modbus. Se é así, identifícase cal é o comando enviado desde o profesor a través da mensaxe en cuestión e faise a acción correspondente, que non é máis que a lectura ou a escritura dos rexistros e envíase unha resposta ao profesor. Os comandos que se utilizan nesta aplicación están lidos con Registro, para ler o Master of the Records que almacenen os códigos de usuario do controlador conectado e Writemultiplisterios no caso de que desexe modificar o contido destes rexistros.3
A Figura 7 ofrece un diagrama de fluxo da característica de atención á interrupción por cambio estatal nos catro bits máis importantes do porto B. O obxectivo fundamental desta función é a actualización do buffer de código WIEGAND, xa que se executará coa chegada dun pouco Correspondente a devandito código. Esta interrupción pode ser presentada tanto por un flanco de outono como un de ascenso en calquera dos pasadores máis significativos do porto B. Entón, analizando o funcionamento do Protocolo de Wiegand, previamente exposto, pódese inferir que a chegada dun pouco para algúns Das liñas de datos, representadas por un pulso de baixo nivel, causou dúas interrupcións por cambio de estado no PIN conectado a esa liña. Por este motivo, decidiuse a actualizar o buffer de código WIEGAND só coa detección do flanco de pulso desde o pulso correspondente á chegada dun pouco, polo que é necesario primeiro ler o porto e descartar os posibles casos nos que A interrupción foi motivada por un flanco de subida. Se é así, é dicir que a interrupción foi motivada por unha desvantaxe, o PIN está identificado polo que se produce o pulso para actualizar o buffer de código con ‘1’ ou ‘0’ segundo corresponda (datos0 ou datos1) e Deixar a porta desde onde provén o código. Finalmente, está marcado se se alcanzou o final do código, caso en que se debe determinar se o código de chegada está autorizado, é dicir, se está almacenado na memoria do código de usuario. Caso afirmativo, o acceso é concedido se aplica o Política de acceso.
A función de atención á interrupción externa O único que fai é determinar polo cal as dúas portas ocorreron o Rex e logo permitir o acceso. Enténdese por conceder acceso por unha porta, a acción de desbloqueo do controlador por un período de tempo de cinco segundos.
Hardware do controlador de interlock
Na figura 8 móstrase un esquema da configuración de hardware da tarxeta que representa o controlador de entrelazado.
Como podes ver, o hardware do controlador de interlock é moito máis sinxelo en comparación co controlador de portas. Está formado, na súa estrutura básica, por oito entradas dixitais cos circuítos de condición correspondentes ás entradas de microcontrolador e oito saídas ao relé. Do mesmo xeito que o controlador de portas, a canle de Usart do microcontrolador úsase para a comunicación coa PC a través do Protocolo Modbus, polo tanto, o uso do circuíto integrado MAX232 tamén é necesario por riba do controlador de interlocro.
A función básica do controlador de entrelazada non é máis que examinar as entradas e, dependendo do que se lea e a configuración anterior, active as saídas correspondentes. A configuración realízase a través dunha aplicación de parametrización que se executa nunha PC e que está conectada á tarxeta a través de RS-232, que se gardou na memoria interna de EEPROM do microcontrolador. A estrutura desta memoria móstrase na Figura 9. Como se pode ver, nas localizacións deles un número que codifica as saídas que deben activar cando se active calquera entrada. Este formulario, nos dous primeiros lugares. Atopar a codificación do Saídas para a entrada 0, a continuación, a entrada 1 e así por diante. Utilizáronse dúas ubicacións para cada entrada porque o protocolo de Modbus usa rexistros de 16 bits.
O algoritmo da función principal do programa (principal) móstrase na Figura 10. baséase fundamentalmente no Lectura constante do porto que constitúe as entradas do controlador e despois mapeo con a configuración almacenada na memoria e, deste xeito, formará o resultado que é eliminado polo porto de saída. A continuación móstrase a chegada dunha mensaxe de protocolo de Modbus e, se é así, é a forma de mimación que no programa do controlador de portas. É dicir, o comando enviado do profesor identifícase a través da mensaxe recibida, realízase a acción correspondente e envíase unha resposta ao mestre.
Desenvolvemento da aplicación de parametrización
Para a configuración dos controladores era necesario desenvolver unha aplicación de software para que, facilmente, amigable e intuitiva, o operador realizará a devandita parametrización Esta aplicación debe poñerse en contacto co porto serie RS-232 da PC con controladores para, deste xeito, escribir e ler a configuración implementando o Protocolo Modbus. O desenvolvemento realizouse mediante o marco Qt, por razóns previamente expresadas, con C ++ como linguaxe de programación.
Decidiuse implementar unha aplicación de parameterización diferente para cada controlador de confort e razóns de claridade. Non obstante, os dous son moi similares e difieren en pequenos aspectos sobre como manexar os datos e representar a información. Isto será mellor enfermo a medida que se dirixe o proceso de desenvolvemento das aplicacións, que se describe a continuación.
Aplicación de parameterización do controlador de portas
Para o caso do controlador de portas, procederase un levantamento dos requisitos do usuario, ao comezo, para facer unha enquisa.
Requisitos funcionais:
1. A solicitude debe estar conectada ao controlador, ler a configuración existente e representar a información.
2. O usuario debe ter a posibilidade de engadir e modificar os códigos, así como a política de acceso.
3. A aplicación debe actualizar o controlador cando se solicite, a fin de descargar todos os cambios posibles na configuración do usuario.
Requisitos non funcionales:
1. Uso da lingua española ao longo do proxecto.
2. Use un formato e un estilo uniforme en todas as fiestras da aplicación.
A partir do levantamento dos requisitos do usuario, entón, os casos de uso están definidos, cuxo diagrama móstrase na Figura 11. O actor do sistema é o administrador, que é o único operador do sistema capaz de modificar e controlar a Configuración dos controladores.
A partir dos casos de uso, entón a fase de análise está definida que formará parte da arquitectura como tal software e relacións con cada un outro. Para o deseño da solicitude, utilizouse unha estrutura de dúas capas, composta pola capa de presentación, que representa a interface co usuario e a capa de negocio onde se realiza a lóxica da aplicación, así como o acceso de datos.
A figura 12 mostra un diagrama de clases da aplicación. A capa de negocio está formada por unha única clase: Tcontroller, que encapsula todas as operacións que se realizarán cos controladores. O acceso de datos realízase usando a Biblioteca de FieldTalk Open Source, que permite a xestión sinxela do Protocolo de Modbus sen ter que dominar moitos detalles. A capa de vista ou a presentación está intimamente relacionada co cadro Qt, que proporciona as clases necesarias para o desenvolvemento da interface de usuario ou a GUI da aplicación de software. A interface está composta por unha xanela principal, que herda da clase QMainwindow da propia biblioteca QT, dúas fiestras créanse dinámicamente do tipo QDialog, para casos en que o operador desexa editar os códigos ou establecer os parámetros da conexión co controlador respectivamente.6-7
Debe notarse que a clase Tcontroller, que é desde onde o acceso a datos a través do Fieldalk Library, ten un membro que constitúe o modelo de datos, contar códigos e a política de acceso, que se amosan na vista. Aquí utilizouse un patrón de deseño moi difundido no desenvolvemento do software chamado Model Vista Controller (M-V-C), onde o procesamento dos datos da súa presentación está separado facilitando a reutilización e mantemento. O framework Qt proporciona unha implementación máis sinxela deste patrón, polo que se crea un modelo dos datos creando un obxecto de tipo qstandarditemmodel e está asociado a un obxecto visual de tipo Qtableview a través do cal se presenta e modifique a información do modelo. Deste xeito, o procesamento de datos e a capa de presentación realízase na capa de empresa como interface co usuario.7-8
Unha vez que teña o deseño das clases, faise unha análise máis profunda do uso casos, pero desde unha perspectiva diferente, desde a secuencia de interaccións cronolóxicas entre obxectos individuais do sistema para que cada caso de uso poida ser totalmente executado.9
A figura 13 mostra a secuencia de eventos para o caso de uso Connect Controller. Neste caso, na xanela principal da aplicación, o obxecto Mainwindow da clase Tmainwindow, a posibilidade proporciónase a través dun botón que o usuario solicita a conexión co controlador. Entreatamente se dá unha xanela de diálogo onde a posibilidade de especificar os parámetros de a conexión, contar o porto de PC, a velocidade, etc. Este último é creado creando un obxecto de conexión herdadaDialog de QDialog que presenta os campos asociados cos parámetros mencionados e devolve os seus valores unha vez que o usuario acepta a xanela de diálogo.
Unha vez que o obxecto MainWindow recibe información, entón creouse un obxecto da clase Tcontroller e executa o método OpenprotoCol do devandito obxecto para abrir a conexión cos parámetros especificados. A continuación, o obxecto do controler executa o comando Readholderingregister pertencente ao Protocolo de Modbus, a través do cal se le a configuración actual do controlador conectado. Con esta información, entón, o modelo de datos actualízase, co que se envía un sinal ou mensaxe para a actualización automática da vista do mecanismo QT para o patrón MVC mencionado anteriormente.10
O caso de usar Engadir código, cuxa secuencia está ilustrada na Figura 14, comeza unha vez que o usuario presione o botón correspondente na xanela principal. Cando o obxecto Mainwindow recibe o sinal deste evento, crea un obxecto da clase EditDialog herdado de QDialog onde se proporcionan os campos necesarios para a edición do novo código que se engadirá. Unha vez que o usuario remata a edición, entón o modelo dos datos pertencentes ao obxecto do controlador é actualizado e automaticamente, lanza un sinal para a actualización deles na vista.7
a secuencia do caso O código de edición de uso é similar ao de engadir código, a diferenza reside nun pequeno cambio no modo de actualización dos datos do modelo, xa que aquí non se engade un novo rexistro, pero determínase cal é o rexistro que quere cambiar e proceder á súa modificación.
Finalmente, a Figura 15 mostra a secuencia de eventos para o uso do controlador de actualización.Cando o usuario o especifica por botón por parte da xanela principal, o obxecto MainWindow instancia a función de obxecto do controlador de actualización. Esta función executa o comando WritemultIlleregisters correspondente ao Protocolo de Modbus, que escribe a configuración dos datos presentes no modelo da configuración de memoria de o controlador conectado.
Aplicación de parametrización do controlador de interlock
Neste caso o produto final é similar ao do controlador de portas e a diferenza reside na presentación da información. Say, o As fiestras son as mesmas, agás que os elementos que os fan cambialos. Deste xeito, a xanela principal, en lugar de presentar unha táboa para representar os códigos do controlador de porta, neste caso o que está dispoñible é unha árbore, onde as saídas que dependen que se amosan en cada entrada. Do mesmo xeito, esta información está baseada nun modelo que forma parte dunha clase Tcontroller pertencente á capa de negocio. Do mesmo xeito, a xanela de diálogo para editar a configuración cambia a súa composición.
Os requisitos do usuario son similares, agás o requisito funcional do controlador de portas, porque no caso do controlador de entrelazada non se engaden códigos, simplemente son saídas relacionadas coas entradas. Polo tanto, o diagrama de uso de uso ten un lixeiro cambio eliminando os casos de uso de uso e edición do código e incorporar un novo caso de uso chamado Configuración de edición, que está ilustrado na Figura 16. A secuencia de eventos para este caso de uso é similar Ao de engadir e editar código no controlador de portas, só a fiestra de configuración diferente.
Resultados
Despois da simulación correspondente dos controladores que utilizan o software Proteus, era posible Asemblea do hardware deles en Picschool, que tal e como se indicou anteriormente, consiste nunha especie de protabio onde se poden probar os prototipos de aplicacións baseados en microcontroladores PIC. O resultado esperado para o controlador da porta foi que recibiu correctamente o código WIEGAND enviado desde un lector de proximidade pertencente ao sistema Kantech. Tamén debe comunicarse correctamente coa aplicación da parametrización mediante o Protocolo Modbus e, segundo a configuración establecida a través desta aplicación, proporcionando acceso aos códigos programados. Do mesmo xeito, no caso do Controlador de Interlock, que foi perseguido, era que responde correctamente na interacción entre as entradas e as saídas, segundo a configuración previa realizada a través da aplicación de configuración.
As probas fixéronse gradualmente ou por pasos. No caso do controlador de portas, a comunicación de Modbus comproba por primeira vez a través dunha aplicación de terceiros, que se comporta como mestre, executándose no PC conectado ao kit a través do porto serie RS232. Con este software era posible verificar que as respostas do controlador aos comandos que foron enviados foron correctos. A continuación, utilizouse para usar a aplicación de parametrización desenvolvida e un lector de proximidade do sistema Kantech, que se transmite usando o protocolo de Wiegand que estaba conectado. Pódese verificar que os códigos configurados e programados no controlador a través da solicitude de parametría foron aceptados polo controlador como correcto inmediatamente despois de ser ingresado a través do lector, comportándose así correctamente no seu papel como controlador de portas.
Do mesmo xeito, o software de terceiros foi usado para o controlador de interlock para comprobar a comunicación de Modbus. As entradas foron acopladas aos interruptores presentes nos picschool e as saídas aos LED. Deste xeito, as saídas poderían verificarse, activadas coa activación das entradas respectando a configuración programada a través do software que funcionaba como Master Modbus. Entón, continuando coas probas, o software de terceiro foi substituído pola aplicación de parametrización desenvolvida e tamén se comportou. Polo tanto, pódese concluír que o desenvolvemento de controladores de escala piloto realizouse de forma satisfactoria e fóra do seu traballo correctamente, como se esperaba.
Respecto ao uso de microcontroladores, 19 liñas de entrada / saída dos 32 dispoñibles no PIC16F877 foron utilizados no controlador de portas, pero o resto pode usarse en expansións ou adaptacións futuras se desexa conectar os controladores de rede , por exemplo. Usouse a canle I2C, así como o uso e tres fontes de interrupción. O firmware ocupou o 57% da memoria ROM ou do programa e usa o 65% de memoria RAM ou a memoria de datos.No caso do Controlador de Interlock, que ten un microcontrolador similar, tamén se utilizou unha parte da entrada / saída total dispoñible, neste caso 18. Do mesmo xeito as restantes liñas poden ser necesarias para unha expansión por necesidade de enquisa a Maior número de entradas ou operar maior cantidade de saídas, citando dous exemplos. O uso da canle e só se empregou unha fonte de interrupción. O firmware ocupou o 20% da ROM e usa o 39% das conclusións de RAM.4
Expuxo a concepción e desenvolvemento dun sistema de control de acceso e entrelazado, que Incluíu a configuración, os dous controladores e a aplicación de parametrización. Estes elementos foron probados lanzando resultados satisfactorios. O sistema traerá varias vantaxes e beneficios na súa implementación no CIM, como un maior apoio técnico e personalización de Undayor. O desenvolvemento da solicitude de parametrización realizouse tendo en conta unha estrutura por capas, así como o uso do patrón de deseño M-V-C, garantindo un maior mantemento e reutilización do código, elementos clave en boa enxeñería de software. No desenvolvemento dos controladores, por igual, tiveron en conta varios factores de maior rendemento e compatibilidade do sistema, como:
· O protocolo de WIEGAND Use en comunicación cos lectores.
· Modbus Protocol Use en comunicación coa aplicación de parametría que se executa no PC.
· Uso de memoria externa para almacenar a configuración no caso do controlador de portas, o que facilita o mantemento ou a substitución deles habilitando a importación / exportación dos datos.
O sistema obtido funciona de forma autónoma. Non obstante, a forma en que foi deseñada proporciona posibilidades de expansión sen moita complicación, integralo nun sistema de supervisión ou escada coa implementación dunha rede de Modbus.
Referencias
1. PEDREIRA, M. “Supervisión de acceso a instalacións do centro de inmunoloxía molecular”. Tese de diploma. Cujae, 2008.
2. Cosentino, L. “Control de acceso, elementos de identificación”. Rnds. 2008, 168 p.
3. PEFHANY, S. MODBUS Protocol. 2000.
4. Microchip Technology Inc. PIC16F87XA Ficha de datos. 1998.
5. Breijo, por exemplo CCS Compilador e proteus simulador para microcontroladores PIC. México: Marcombo, 2008. 276 p. ISBN: 978-970-15-1397-2.
6. Eels, estratexias de capas de P.. Cupertino: software racional, 2002. 13 p.
7. Thelin, J. Fundacións do desenvolvemento QT. Nova York: APRESS, 2007. 528 p. ISBN: 978-1-59059-831-3
8. Gamma, E., Helm, R., Johnson, R., Vlissides, J. Patróns de deseño: Elementos de software de orientación de obxectos reutilizables. 1997. 431 p.
9. Schmuller, J. Learning UML 24 horas. 2004. 398 p.
10. Fieldk Inc FieldTalk Modbus Master C ++ Biblioteca Biblioteca Software Manual. 2009.