Diseño de un sistema de control para ascensores con ...
71
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA Diseño de un sistema de control para ascensores con análisis de sus variables energéticas en la nube utilizando Machine Learning. TESIS DE GRADO EN INGENIERÍA EN CONTROL Presentado por: Andrés Camilo Torrez Martínez Jonathan Fernando Amaya Benavides
Transcript of Diseño de un sistema de control para ascensores con ...
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA
Diseño de un sistema de control para ascensores con análisis de sus variables energéticas en la nube utilizando Machine Learning. TESIS DE GRADO EN INGENIERÍA EN CONTROL
Presentado por: Andrés Camilo Torrez Martínez Jonathan Fernando Amaya Benavides
1
1. Contenido
HOJA DE ACEPTACIÓN .................................................................................................................. 2
AGRADECIMIENTOS ...................................................................................................................... 3
RESUMEN ...................................................................................................................................... 4
OBJETIVOS..................................................................................................................................... 5
Generales .................................................................................................................................. 5
Específicos ................................................................................................................................. 5
MARCO TEÓRICO .......................................................................................................................... 6
Variador de frecuencia .............................................................................................................. 6
Sistema de ascensores .............................................................................................................. 9
Codesys .................................................................................................................................... 11
Lenguajes de programación .................................................................................................... 12
Protocolo de comunicación Modbus ...................................................................................... 15
Protocolo i2c ........................................................................................................................... 16
Protocolo MQTT ...................................................................................................................... 17
Raspberry Pi............................................................................................................................. 19
PSoC (Programmable System on Chip).................................................................................... 21
Machine Learning (Aprendizaje de máquina) ......................................................................... 21
DESARROLLO ............................................................................................................................... 23
Comunicación Control - Variador ............................................................................................ 23
Lógica de Control ..................................................................................................................... 28
Llamadas de Carro ............................................................................................................... 29
Llamadas de Piso ................................................................................................................. 34
Sistema de sensores para pisos .......................................................................................... 38
Lógica del ascensor ............................................................................................................. 39
Toma de datos ......................................................................................................................... 46
Comunicación MQTT ........................................................................................................... 48
Node-red y base de datos Cloudant de IBM ....................................................................... 50
Azure y Machine Learning ................................................................................................... 54
CONCLUSIONES ........................................................................................................................... 58
REFERENCIAS .............................................................................................................................. 60
Anexos……………………………………………………………………………………………………………………………….62
2
Hoja De Aceptación
Observaciones
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
____________________________
Ing. Eduardo Alberto Delgadillo
____________________________
Firma Jurado 1
____________________________
Firma Jurado 2
Bogota D.C.
3
Agradecimientos
Los autores expresan sus agradecimientos a todos nuestros familiares y amigos que
sirvieron como apoyo durante nuestro desarrollo profesional hasta este punto.
Al profesor Eduardo Alberto Delgadillo por sus conocimientos durante el desarrollo de
la carrera y del proyecto en cuestión.
A Variadores S.A. por permitirnos usar los recursos con los que se realizaron pruebas de
laboratorio.
A todos los docentes que a lo largo de la carrera brindaron su conocimiento y apoyo con
los que se logró dar desarrollo a este proyecto, y con los que se creció cada día de
manera profesional y personal.
A los compañeros y amigos que estuvieron durante estos años brindando su compañía
y su apoyo en cada una de las etapas que se llevaron a cabo en la Universidad.
4
2. Resumen
El presente documento pretende explicar el procedimiento realizado para llevar al cabo
el proyecto denominado “Diseño de un sistema de control para ascensores con análisis
de sus variables energéticas en la nube utilizando Machine Learning”, para esto se
cuenta con un marco teórico que pretende explicar brevemente el funcionamiento de
los elementos utilizados y una etapa de desarrollo en donde se explica cuál fue el
procedimiento realizado y como se construyó cada una de las etapas.
El prototipo resultante del proyecto permite llevar a cabo un control en un ascensor
haciendo uso de una Raspberry como plataforma para alojar la lógica y un variador
marca Yaskawa para manejar el motor que genera el movimiento en el sistema, para la
comunicación entre estos dos se usó el protocolo de comunicación Modbus RTU. Se
diseñó una pantalla que permite simular los llamados y salidas correspondientes a cada
etapa, los llamados reales se realizan con un microcontrolador PSoc el cual recibe las
señales como entradas digitales y las comunica a la Raspberry por medio del protocolo
I2C.
También se lleva registro en una base de datos en la nube la cual almacena los valores
de funcionamiento del variador para posteriormente poder realizar un análisis con esos
datos y determinar si se presenta algún problema de funcionamiento o en la Red en la
que se encuentra el equipo.
5
3. Objetivos
3.1 Generales.
Desarrollar un sistema lógico de control para ascensores, el cual almacene y permita un
monitoreo de variables del consumo energético principalmente voltaje y corriente en la
nube y haciendo uso de Machine Learning analizar el comportamiento de las mismas.
3.2 Específicos.
Elaborar la lógica en un sistema de control para ascensores donde se cuente con
los parámetros básicos de control de movimiento, una puerta, iluminación,
además de las alarmas y seguridades necesarias para su correcto funcionamiento
para un ascensor de 5 pisos.
Construir las tarjetas de control para los pisos y la cabina, las cuales se
comunicarán con la tarjeta principal por medio de algún protocolo de
comunicación.
Generar una adquisición de datos entre el control y un variador para poder
manipular y monitorear el sistema del ascensor.
Establecer una comunicación con el control a una nube de código abierto y de
allí mismo se pueda observar el comportamiento del sistema obteniendo datos
de consumo, alarmas y tiempos de trabajo.
Utilizar algún método Machine Learning para el análisis de los datos obtenidos
en el cual se observe el comportamiento energético del sistema.
6
4. Marcó Teórico
4.1. Variador de frecuencia
El variador de velocidad es un dispositivo de conversión de energía eléctrica a mecánica
el cual envía una señal en frecuencia al motor la cual varía dependiendo de las
necesidades de la aplicación. En la industria la instalación de este tipo de equipos
permite tener un mayor control sobre el trabajo del motor y así mismo una mayor
seguridad en su funcionamiento.
Para este caso específico se trabaja con un variador de frecuencia, el cual está
compuesto por 3 etapas principales las cuales se describen a continuación:
- Rectificación: La primera etapa con la que cuenta el variador es la rectificación
de la señal AC de alimentación, esta consta de un puente rectificador trifásico de
onda completa el cual transforma la energía alterna en directa para las siguientes
etapas. Como se puede observar en la imagen la señal obtenida no se ha
suavizado, lo que ocurre en la siguiente etapa.
Fig. 1 Etapa de rectificación del variador [1]
- Bus DC: Consta de un conjunto de condensadores los cuales cumplen con dos
funciones dentro del variador, por un lado, suaviza el voltaje resultante de la
etapa de rectificación eliminando el rizado restante y por otro se encarga de dar
la energía necesaria para la salida del equipo. Con la implementación de esta
etapa se obtiene una señal DC más limpia que mejora el trabajo del variador en
sí.
7
Fig. 2 Etapa de bus DC en el variador de frecuencia [1]
- Etapa Inversora: Esta etapa está compuesta por una serie de módulos IGBT los
cuales toman el voltaje DC almacenado en los condensadores y aplicando una
modulación PWM construyen una señal que se asemeja a una AC en sus valores
de voltaje en el tiempo. La principal ventaja de manejar el voltaje en el motor
por este medio es la posibilidad de tener un mejor control sobre el torque y el
comportamiento del voltaje en los diferentes valores de frecuencia.
En la imagen siguiente se puede observar como es la salida real del variador teniendo
en cuenta que es una serie de pulsos de voltajes DC que en promedio forman una señal
con similitud a una AC.
Fig. 3 Ejemplo de señal de salida en variador de frecuencia. [2]
Los variadores con el tiempo han ganado confiabilidad gracias a los beneficios que
tienen frente a otros tipos de arranque como el directo, o los arrancadores suaves.
Principalmente al momento de romper inercia en donde las corrientes pueden elevarse
a valores mucho más altos de los nominales de trabajo, es donde se ven los beneficios
de sistemas de arranques con variador ya que permiten tener un control sobre el
funcionamiento que suaviza el trabajo. Las protecciones con las que cuenta cada equipo
8
permiten que la vida útil tanto del mismo como del motor sean mayores en comparación
con un funcionamiento no controlado.
Para este proyecto en específico se implementó un Variador marca Yaskawa, esta es una
compañía que se ha enfocado en la comercialización de equipos para el control de
movimiento desde el año 1915, tiene presencia alrededor de todo el mundo.
En el rango de productos con los que cuenta la empresa se encuentran variadores
especializados en ciertas aplicaciones comunes como lo son el modelo A1000 para uso
general, IQPump 1000 para sistemas de bombeo, Z1000 para sistemas de aire y el usado
en este proyecto L1000E para el control de máquinas en ascensores. También existe el
modelo L1000A el cual tiene varias similitudes con el mencionado anteriormente, pero
este se usa en la región de Norte América.
Fig. 4 Variador Yaskawa Modelo L1000E. [3]
El modelo L1000E presenta ciertas configuraciones que para el caso específico de los
ascensores se hacen necesarias y facilitan su implementación, como lo son el manejo
del freno, parámetros de nivelación y confort que permiten configurar el sistema para
que trabaje dentro de los mejores estándares.
El variador L1000E cuenta con las siguientes características que permiten un control y
monitoreo sobre el mismo implementando varios protocolos de comunicación, o
contactos secos de marcha y parada:
- 8 entradas digitales multi-función - 2 entradas análogas multi-función - 3 salidas digitales relevadas multi función - 2 salidas digitales optoacopladas multi función
9
- 1 rele de fallas - 2 entradas de seguridad - Comunicación integrada Modbus RTU RS-422, RS-485
En el caso específico de este proyecto la principal característica usada es la
comunicación Modbus RTU ya que con esta se monitorea y controla el variador de
acuerdo a las órdenes que el control le envía, el cual en este caso es la Raspberry Pi
usada como PLC. [3]
4.2. Sistema de ascensores
Un sistema de ascensor está compuesto por una serie de componentes tanto mecánicos
como eléctricos, la parte mecánica la cual consta principalmente de una polea acoplada
al eje del motor, la cabina y el contrapeso como se observa en la siguiente imagen.
Fig. 5 Esquema básico de un ascensor. [4]
La cabina es en la cual se transporta la carga a manejar usualmente siendo personas,
dentro de la cabina se encuentra la botonera que permite realizar los llamados a piso
que se necesiten, tienen un sistema de iluminación y sensores de seguridad que serán
tratados más adelante. El contrapeso es una parte importante del sistema ya que este
10
es el que facilita el trabajo del motor cuando debe levantar la carga del ascensor, este
debe ser calculado de acuerdo a la carga máxima que soporta el sistema para que el
motor trabaje con los mismos valores tanto en subida como en bajada.
Otro componente importante que cuenta tanto en la parte mecánica como eléctrica es
el motor, este es el que específicamente se encarga de convertir la energía eléctrica en
mecánica para generar el movimiento del ascensor. Para el manejo de ascensores
actualmente se suelen utilizar dos tipos de motores los cuales serán explicados
brevemente:
- Motor De Inducción
EL motor de inducción es uno de los más usados actualmente en diferentes aplicaciones,
este se encuentra compuesto por 3 partes principales que son el rotor, el estator y la
carcasa. Tanto el rotor como el estator están conectados a unos bobinados que son los
encargados de transformar la energía eléctrica en mecánica. Cuando se aplica una
corriente sobre el bobinado del estator se genera un campo electromagnético que
induce una corriente sobre el bobinado del rotor, de esta manera es que estos campos
son los que llevan al motor a que tenga un movimiento.
Fig. 6 Componentes Básicos de un Motor De Inducción. [5]
- Maquina Gearless
Estas máquinas son motores que cuentan con unos imanes coloques en posiciones
predefinidas para su funcionamiento, las ventajas que presenta principalmente son que
la relación entre el consumo de corriente y la potencia generada es mejor que en un
motor de inducción por lo que el tamaño de los mismos también se ve disminuido al
hablar de potencias de valores similares.
11
Fig. 7 Maquina Gearless. [6]
El principal componente electrónico con el que cuenta el sistema es el sistema de control
el cual se encarga de manejar la lógica para el movimiento del ascensor, el variador que
controla el motor de acuerdo a las ordenes enviadas por parte del control principal, los
sensores de piso que usualmente son imanes que envían las señales al control para que
este sepa en qué posición se encuentra, actuadores para iluminación, puertas, y otros
sensores que permiten tener cierto control sobre seguridades.
Debido a que la carga que mueve un sistema de ascensores es tan crítica como lo es la
vida de las personas, es necesario contar con una serie de seguridades que eviten se
llegue a presentar algún accidente. Por ejemplo, casos de incendio, terremoto, excesos
de velocidad y otros que llevan al ascensor a presentar algún inconveniente en su
funcionamiento.
También se suele hacer uso de algún equipo de frenado junto con el variador, esto
debido a que se presenta el fenómeno de regeneración constantemente en los sistemas.
La regeneración consiste en el momento en que el motor debe cambiar de estado en
tiempos muy cortos por lo que su construcción lo lleva a trabajar como un generador y
entregar energía al variador, usualmente se instala una resistencia de frenado la cual se
encarga de disipar esta energía sobrante en forma de calor.
4.3. Codesys
El término Codesys es un acrónimo que tiene como significado “Sistema de desarrollo
de controladores”. [10] Este software es un programa que permite crear programas de
control de las estaciones didácticas de la plataforma, además de comunicarse con el
autómata, vía ethernet, y transferirle la información. [11]
Codesys es uno de los sistemas de programación del estándar IEC 61131-3 más comunes
para PLCs y reguladores industriales. Permite programar autómatas de diferentes
fabricantes, así como generar código para algunos microprocesadores y DSPs. [11]
12
Soporta los cinco lenguajes de programación del estándar los cuales son; lenguaje en
escalera (Ladder Diagram LD), Diagrama de bloques funcionales (Function Block Diagram
FBD), Texto estructurado (Structured Text ST), Bloque de función secuenciales
(Sequential Function Chart SFC) y Bloque de funciones continuas (Continuous function
Chart CFC), además dispone de visualización integrada, como también de un simulador
online. [11]
4.3.1. Lenguajes de programación.
A continuación, explicaremos con brevedad la definición y/o el uso de cada lenguaje de
programación que puede usar el software Codesys:
Ladder Diagram: diagrama de contactos, diagrama en escalera, o lógica de contactos, es
un lenguaje gráfico que tiene muchas similitudes al principio utilizado por los técnicos
en la elaboración de cuadros eléctricos y de automatismo. [12]
Un programa escrito en Ladder está compuesto de una serie de circuitos que son
ejecutados secuencialmente por un autómata. La representación gráfica se asemeja a la
de un esquema eléctrico de control clásico, ya que se emplean símbolos similares a los
utilizados en estos esquemas, siendo mucho más intuitivos para los profesionales
familiarizados con este tipo de instalaciones que el uso de lenguajes de formato texto.
[12]
Dada su sencillez, es el lenguaje más utilizado en los relés programables y autómatas.
Entre los símbolos básicos podemos hacer mención de los mostrados en la siguiente
tabla 1.
Tabla 1. Algunos símbolos básicos del lenguaje Ladder. [12]
Function Block Diagram: en el lenguaje FBD se programa la aplicación gráficamente
conectando en cascada bloques lógicos; del mismo modo que se hace en los esquemas
de electrónica digital. En relación con las entradas y salidas, estas se representan por
variables asignadas a cada bloque. Además, el lenguaje FBD permite al programador
diseñar sus propios bloques. [12]
13
En la siguiente figura 7, podremos observar la manera de programación del lenguaje
FBD.
Fig. 8 Ejemplo básico del lenguaje FBD.
Structured Text: Texto estructurado es únicamente empleado en autómatas de alta
gama y ciertos entornos industriales. Se trata de un lenguaje de programación de alto
nivel que permite programación estructurada, es decir, es posible dividir varias tareas
complejas en tareas más sencillas para resolver un problema de automatización, usando
lo que se conoce como subrutinas. Al ser un lenguaje de alto nivel tiene muchas
similitudes con otros lenguajes similares utilizados en la industria informática, Basic,
Pascal, o C++. [12]
Este lenguaje emplea la definición de variables para identificar variables internas,
entradas y salidas, y dispone de estructuras de control que permite repetir procesos y
tomar decisiones de cómo actuar en función de unas condiciones complejas. En la figura
8, podemos observar la forma de programación del lenguaje ST.
Fig. 9 Ejemplo básico del lenguaje ST.
14
Sequential Function Chart: Podríamos considerarlo un lenguaje orientado a gráficos que
nos permiten representar el desarrollo en el tiempo de las distintas acciones de un
programa. El SFC es similar a un diagrama de flujo, en el que podemos organizar
subprogramas o subrutinas programadas en ST, LD, FBD, IL y que forman parte del
programa de control. El lenguaje SFC se emplea frecuentemente en el diseño de
soluciones asociadas a sistemas secuenciales donde el programa se ejecuta paso a paso
conforme se cumplen determinadas condiciones. [12]
La programación SFC dispone de tres elementos principales encargados de organizar el
programa de control: pasos o etapas, transiciones o condiciones y acciones. Nuestro
programa se irá ejecutando de una etapa a otra conforme se vayan cumpliendo las
condiciones y en cada etapa se ejecutará las acciones que se hayan definido. [12]
En la figura 9 observaremos un ejemplo básico de la programación del lenguaje SFC.
Fig. 10 Ejemplo básico del lenguaje SFC.
Continuous function Chart: en el lenguaje de programación CFC se pueden realizar
programas a partir de bloques prefabricados. Al utilizar este lenguaje se usan bloques
que realizan una función y se les asigna unos parámetros, y además se pueden
interconectar. La interconexión significa, por ejemplo, que los valores se transfieren de
una salida a una o más entradas durante la comunicación entre bloques. [13]
Los gráficos de funciones continuas se utilizan básicamente para controlar procesos
continuos, donde se ejecuta toda lógica y se calculan las salidas. El lenguaje CFC se usar
mayormente en procesos Bach continuos. A continuación, en la figura 10 observaremos
la forma de programación del lenguaje CFC. [13]
15
Fig. 11 Ejemplo básico del lenguaje CFC.
4.4. Protocolo de comunicación Modbus
Modbus es un protocolo de comunicaciones, basado en la arquitectura maestro/esclavo
o cliente/servidor, diseñado en 1979 por Modicon para su gama de controladores
lógicos programables (PLCs). Debido a que este protocolo fue público, de fácil uso y que
requiere poco desarrollo (maneja bloques de datos sin suponer restricciones) se
convirtió en un protocolo de comunicaciones estándar en la industria. Es el protocolo
de mayor disponibilidad para la conexión de dispositivos electrónicos industriales. El
protocolo Modbus permite el control de una red de dispositivos, por ejemplo, un equipo
de medición temperatura y humedad puede comunicar los resultados a una PC. Modbus
también se usa para la conexión de un PC de supervisión con una unidad remota (RTU)
en sistemas de supervisión de adquisición de datos (SCADA). Existen versiones del
protocolo Modbus para puerto serial y Ethernet (Modbus/TCP).
Para hacer uso del protocolo Modbus es necesario tener claro que el mismo trabaja a
partir de funciones que son las que definen cual será la acción a llevar a cabo durante la
transmisión, como se observa en la siguiente tabla, existen una variedad de funciones
que permiten la lectura y escritura tanto de variables digitales como análogas, esto
teniendo solo una dirección como referencia o varias de estas en una sola función.
Fig. 12 Funciones en la comunicación del protocolo Modbus [7]
16
Para poder direccionar correctamente el dato que se quiere transmitir, a cada valor se
le asigna una dirección, de acuerdo a lo establecido por el protocolo dependiendo de si
es una entrada, una salida y si es un valor digital o análogo se le asigna una dirección
dentro de un rango. En la siguiente tabla se observa la asignación de las direcciones de
acuerdo al tipo de dato que se desea trabajar.
Fig. 13 Direcciones establecidas para cada tipo de dato en el protocolo Modbus [7]
4.5. Protocolo i2c
El protocolo I2C es muy sencillo desde el punto de vista de hardware (Figura 13) ya que
se compone únicamente de dos líneas de colector abierto (Open collector) o drenaje
abierto (Open drain), una para la comunicación SDA y otra para actuar como reloj de
sincronismo SCL. [14]
Figura 14. Esquemático de la comunicación I2C Maestro-esclavos.
Cuando el bus no está siendo usado las dos líneas están a nivel alto y cualquier maestro
puede acceder al bus poniendo a nivel bajo la línea SDA, luego podrá la dirección del
receptor y, finalmente, se establecerá un dialogo que terminará con la vuelta de la línea
17
SDA a nivel alto. [14] En términos generales, una transacción obedecerá a alguna de las
siguientes estructuras de la figura 14: [15]
Fig. 15 Formatos de una transacción: a) sin cambio de sentido, b) con re-direccionamiento y posible
cambio de sentido. [15]
El protocolo I2C es muy flexible, pero presenta limitaciones en cuanto a su velocidad de
transmisión de datos, que es reducida (en mejor de los casos 3 a 4 Mbit/s aunque el
valor estándar es de 100kbit/s), lo que no es un problema para la mayoría de los sistemas
de instrumentación pero sí para otras aplicaciones dentro del mundo de la informática.
[14]
4.6. PROTOCOLO MQTT
Para dispositivos de Internet de las cosas (IoT) es necesaria la conexión a internet. La
conexión a internet permite que los dispositivos trabajen entre ellos y con servicios
backend. El protocolo de red subyacente de internet es TCP/IP. MQTT (Message Queue
Telemetry Transport), que está construido sobre la pila de TCP/IP, y se ha convertido en
el estándar para las comunicaciones de IoT. [16]
MQTT es un protocolo de red liviano y flexible que logra el equilibrio adecuado para los
desarrolladores de IoT: [16]
El protocolo liviano le permite implementarse en hardware de dispositivos altamente
limitados y en redes con ancho de banda de alta latencia/limitado.
Su flexibilidad hace que pueda soportar varios escenarios de aplicaciones para
dispositivos y servicios IoT.
El protocolo MQTT define los tipos de entidades en la red: un intermediario de mensajes
y un número de clientes. El intermediario es un servidor que recibe todos los mensajes
de los clientes y luego los redirige a clientes de destinos relevantes. Un cliente es
cualquier cosa que pueda interactuar con el intermediario para enviar y recibir
mensajes. Un cliente puede ser un sensor de IoT en el campo o una aplicación del centro
de datos que procesa datos IoT. [16]
18
El cliente se conecta con el intermediario. Se puede suscribir a cualquier “tema” de
mensajes de intermediario. Esta conexión puede ser una conexión TCP/IP simple o una
conexión TLS cifrada para mensajes confidenciales.
El cliente publica el mensaje, sobre un tema, enviando el mensaje y el tema al
intermediario.
Después, el intermediario redirige el mensaje a todos los clientes que están suscritos a
ese tema.
Ya que los mensajes MQTT están organizados por temas, el desarrollador de
aplicaciones tiene la flexibilidad de especificar que ciertos clientes sólo puedan
interactuar con determinados mensajes. Por ejemplo, los sensores publicarán sus
lecturas sobre el tema “sensor_data” y se suscribirán al tema “config_change”. Las
aplicaciones de procesamiento de datos que guardan los datos del sensor en una base
de datos backend se suscribirán al tema “sensor_data”. Una aplicación de consola de
administración puede recibir los comandos del administrador del sistema para ajustar
las configuraciones de los sensores, como la sensibilidad y la frecuencia de la muestra, y
publicar esos cambios en el tema “config_change”, siendo un modelo de este protocolo
mostrado en la figura 15. [16]
Figura 16. Ejemplo de un Modelo del protocolo MQTT. [16]
4.7. RASPBERRY PI.
La Raspberry Pi es un pequeño ordenador del tamaño de una tarjeta de crédito de muy
bajo costo, menos de 35 euros y fue desarrollado en el Reino Unido por la Fundación
Raspberry Pi, el cual se puede usar prácticamente como un verdadero PC y además
puede estimular el aprendizaje en las ciencias informáticas. [17]
El software que es usado en esta tarjeta es Open Source, el cual su sistema operativo es
adaptado de Debian, denominada Raspbian, aunque también la placa puede trabajar
bajo otros sistemas operativos, incluyendo la versión 10 de Windows. A continuación,
en la figura 16, observaremos las partes que componen la mayoría de las versiones de
Raspberry.
19
Fig. 17. Placa Raspberry Pi Modelo 3. [17]
A) Procesador.
Es el corazón de la Raspberry Pi, es del tipo de procesadores que encuentras en tu
teléfono celular. Si usas una Raspberry Pi 3, este procesador es de 64 bit, un sistema 4
núcleos (quad core) de 1.2 GHz, el cual está construido en arquitectura ARM. Los chips
ARM vienen en una variedad de arquitecturas con diferentes núcleos configurados que
brindad otras capacidades a diferentes precios. La Raspberry Pi 1 tiene 512 megabytes
de RAM y la Raspberry 2 y 3 tienen 1Gb de RAM. [17]
B) Jack de video y audio.
Una salida de video y audio está disponible en un estándar 3.5mm el conector plug. Un
lado de la conexión es un mini Jack, el otro lado es de tres conectores RCA para audio
estéreo y video compuesto por NTSC o PAL. [17]
C) Leds de estado.
Dos leds indicadores en la tarjeta demuestran el estado de la tarjeta. Además, también
hay unos Leds indicando la actividad del puerto Ethernet por sí mismo. [17]
D) Puertos USB externos.
En las versiones principales de Raspberry Pi, encontramos 4 puertos USB 2.0 para
conectar periféricos tales como el teclado, el ratón, controladores e impresoras.
Mientras más dispositivos se alimenten de los puertos, es recomendable considerar el
uso de una fuente externa alimentando a los dispositivos que necesiten más energía,
como un disco duro. [17]
E) Puerto Ethernet.
El puerto Ethernet es de un estándar RJ45 de una capacidad de velocidad de 10 a 100
megabits por segundo. Conectándolo a un router dispondrá de internet, o por otro lado
puede usar WiFi en la versión 3 de Raspberry Pi. [17]
20
F) Conector HDMI.
El puerto HDMI brinda salida de audio y video digital. Soporta 14 diferentes resoluciones
de video, y la señal HDMI puede ser convertida a DVI (usado por muchos monitores),
compuesta (Señal análoga de video con un conector RCA amarillo), o SCART (un
equipamiento de estándar europeo para conexión audiovisual) con adaptadores
externos. [17]
G) Alimentación de entrada.
Este conector MicroUSB es usado para alimentar la tarjeta (este no es un puerto
adicional USB, solo se usa para alimentar). El conector MicroUSB fue seleccionado
debido a que este conector es barato y además las fuentes de alimentación son fáciles
de encontrar. [17]
H) Slot de la memoria MicroSD.
Notaras que la Raspberry Pi no tiene disco duro, todo es almacenado en una memoria
MicroSD. En los modelos recientes, deberás insertar la memoria oprimiéndola en el Slot,
y de la misma manera la podrás remover. En esta memoria deberás ingresar primero el
sistema operativo para luego hacer uso de la Raspberry Pi. [17]
I) Conector para la interfaz del display serial DSI
El conector acepta 15 pines, cable de cinta plana puede ser usado para la comunicación
con un Display Touch oficial de la Raspberry Pi. [17]
J) Entradas y salidas GPIO y otros pines.
Actualmente la Raspberry Pi tiene un conector que tiene 2x20 pines GPIO. Estos pines
pueden leer interruptores y botones, como también controlar actuadores, Leds, relés y
motores. [17]
K) Conector para la interfaz de la cámara serial CSI
Este puerto permite un módulo cámara que se conectará directamente con la tarjeta
por medio del cable cinta. [17]
4.8. PSoC (Programmable System On Chip)
Es la denominación que tienen los microcontroladores programables desarrollados por
Cypress Semiconductor. Esta tecnología constituye un arreglo configurable de señal
mezclada (Parte análoga y digital) con controlador para una tarjeta. Estos dispositivos
conjugan las ventajas de los SoC, con la flexibilidad de los sistemas programables. [18]
La unión de circuitos análogos y digitales programables son la base de la plataforma
PSoC. Se puede configurar sus bloques usando las librerías pre-construidas o crear tus
propias librerías. Al combinar varios bloques digitales, se pueden crear recursos lógicos
de 16, 24 hasta 32 bits. [18]
21
Los bloques análogos están compuestos de capacitadores conmutados, Op-amp,
comparadores, ADC, DAC, y bloque de filtros digitales, permitiendo flujos complejos de
señales análogas. [18]
PSoC además ofrece un subsistema CPU sostificado con SRAM, EEPROM, una memoria
flash, varios núcleos y una variedad de sistemas incluyendo: [18]
- Un oscilador interno principal de baja velocidad. - Conectividad con un oscilador cristal externo para precisión. - Interrupciones internas y Watchdog. - Múltiples relojes que incluyen un PLL.
Los dispositivos PSoC también están dedicados a comunicaciones tales como I2C, USB
2.0, CAN 2.0 y capacidades de depuración en el Chip usando JTAG y Serial Wire Debug.
Los nuevos PSoC estas construidos bajo un estándar de procesadores como los 8051,
ISSP y ARM Cortex M3. [18]
4.9. Machine Learning (Aprendizaje de máquina)
El aprendizaje de máquina es un área que estudia cómo construir programas de
computadoras que mejoren su desempeño en alguna tarea gracias a la experiencia. Ésta
se basa en las ideas de diversas disciplinas, como inteligencia artificial, estadística y
probabilidad, teoría de la información, psicología y neurobiología, teoría de control y
complejidad computacional. El mismo autor afirma que, para utilizar el abordaje de
aprendizaje, se deben considerar una serie de decisiones que incluyen la selección del
tipo de entrenamiento, la función objetiva a ser aprendida, su representación y el
algoritmo para aprender esa función a partir de ejemplos de entrenamiento. [19]
Las técnicas de aprendizaje se clasifican en supervisadas, no supervisadas y semi-
supervisadas. En las supervisadas, la meta es aprender el mapeo de las respuestas
correctas para los datos de entrada que le son proporcionados; para esto, se utiliza un
conjunto de datos de entrenamiento constituidos por pares que consisten en patrones
de entrada y salida correcta. De esta forma, el sistema aprende el mapeo de la salida
correcta para cada patrón de entrada que se le presenta. [19]
Yu Wanjun y Song Xiaoguang afirman que las etapas del aprendizaje supervisado
aplicadas en la categorización de texto son inicialmente un conjunto de ejemplos ya
clasificados que son presentados al algoritmo con lo que se construye un clasificador.
Posteriormente, se presentan ejemplos no clasificados al clasificador para que los
ordene. Finalmente, se debe tomar medidas para evaluar el desempeño del clasificador.
Algunos ejemplos de técnicas de aprendizaje de máquina supervisado son árboles de
decisión, máxima entropía, naive bayes, support vector machines, etcétera. [19]
En las técnicas de aprendizaje no supervisado, no se requiere la intervención de
humanos para elaborar un conjunto de datos previamente categorizados para ser
presentado al algoritmo de aprendizaje. La meta del aprendizaje no supervisado es
encontrar patrones interesantes considerando la distribución y composición de los
22
datos que le son presentados. Ejemplos de las técnicas de aprendizaje no supervisado
son las técnicas de clustering. [19]
Las técnicas de aprendizaje semi-supervisado son un término medio entre el aprendizaje
supervisado y el no supervisado. En este tipo de aprendizaje, los datos se dividen en dos
partes: un grupo de datos clasificados y otro de no clasificados. A esto se denomina
aprendizaje semi-supervisado estándar. [19]
Ejemplos de técnicas de aprendizaje semi-supervisado son las técnicas de transductive
support vector machines, expectation maximization (EM), etc. Algunas aplicaciones del
aprendizaje semi-supervisado, mencionadas por los autores son el reconocimiento del
habla, clasificación de páginas web y en la secuencia de proteínas. [19]
23
5. Desarrollo
El desarrollo llevado a cabo se puede dividir en una serie de etapas la cual en donde
cada una se compone de sus propios elementos tanto de Hardware como de Software.
Para explicar el procedimiento realizado se explicará la composición de cada uno de los
bloques y así mismo como fue el proceso de construcción.
Fig. 18 Diagrama de bloques del proyecto Fuente autor
Antes de iniciar con la explicación de cada uno de los bloques, se hace necesario aclarar
algunos conceptos:
- Llamadas de carro: Las llamadas de carro son aquellas que se realizan desde el
interior de la cabina del ascensor, estas le indican al sistema cual es el destino
del pasajero para que se decida cuál es la mejor ruta a seguir.
- Llamadas de piso: Estas llamadas son las que se realizan desde el panel presente
en cada uno de los pisos donde trabaje el ascensor, en el caso de este sistema se
cuenta con la posibilidad de solicitar el equipo para bajada y subida de manera
separada.
5.1. Comunicación Control – Variador
Ya que es necesario que el control de ascensor (Raspberry) y el control del motor
(Variador) se comuniquen para de esta manera enviar órdenes y recibir datos de
monitoreo se implementó el protocolo de comunicación MODBUS RTU, esto se decidió
debido a la facilidad con la que cuenta el variador modelo L1000 de tener los puertos
para este protocolo instalados de fábrica.
Para poder llevar a cabo esta comunicación se hace necesario realizar ciertas
configuraciones tanto en la raspberry como en el variador. Primero el variador cuenta
con una serie de parámetros que permiten configurar los valores de trabajo, el motor
que usara, las comunicaciones entre otras.
24
Fig. 19 Diagrama de conexiones comunicación Modbus, Variador Yaskawa. [8]
La conexión observada en la imagen anterior proviene directamente del manual del
variador, los bloques denominados Drive son cada uno de los posibles variadores a
conectar. Como se observa para realizar la conexión se hace uso de las borneras
denominadas S-, S+, R-, R+ estas se conectan en este caso al conversor USB-485 usado
en la raspberry, con lo anterior ya están listas todas las conexiones necesarias entre
Raspberry y Variador para trabajar.
Fig. 20 Módulo de conversión USB-485. [9]
25
La configuración del variador se realiza por medio del operador digital del mismo el cual
es la interfaz que permite interactuar con los parámetros de configuración del mismo.
En el caso del variador Yaskawa los parámetros de configuración se encuentran
agrupados como lo muestra la siguiente tabla, en esta se puede ver que los parámetros
se encuentran agrupados de acuerdo a la función que cumplen, lo que permite que sea
más sencillo realizar su configuración. Se pueden encontrar parámetros para el control
de velocidad de aceleración y desaceleración, valores del motor, protecciones entre
otros. Los que en este caso se necesitan principalmente son los relacionados con el
grupo H5, los cuales son los encargados de configurar la comunicación por medio del
protocolo MODBUS.
Fig.
20
Tabla de grupos de parametros variador yaskawa. [8]
De los parametros H5 es necesario rectificar como minimo los siguientes:
H5-01: Establece la dirección de esclavo que va a tener cada uno de los variadores, en
este caso debe coincidir con la que es buscada por parte del control o Raspberry.
H5-02: Aquí se modifica la velocidad de comunicación, el valor predeterminado
corresponde a 9600 Bps, este puede ser modificado en el caso de que se necesite
trabajar con una velocidad mayor.
H5-03: Este parametro permite seleccionar el tipo de paridad con el que va a trabajar el
sistema por predeterminado viene sin paridad.
Los valores de bits de datos y de parada vienen configurados en 8 y 1 respectivamente,
estos no es posible modificarlos. Los demas parametros del grupo H5 permiten
seleccionar como responde el variador en caso de perdida de comunicación entre otros.
Vale la pena aclarar que algunos de los parametros necesitan que el variador sea
reiniciado para que se vea el cambio reflejado.
26
Por el lado de codesys y la raspberry se añade un dispositivo de tipo Modbus como se
observa en la imagen, las configuraciones del mismo deben corresponder a las
realizadas en el variador, en codesys es posible determinar si la comunicación se esta
realizando de manera correcta si al momento de iniciar el programa se observa un icono
de color verde al lado de los dispositivos añadidos.
Fig. 21 Configuracion Modbus en Codesys. Fuente Autor
La manera en la que se envian los comandos de funcionamiento al variador es usando
la funcion con codigo 6, la que permite escribir un solo registro, de acuerdo al manual
es posible obtener las direcciones correspondientes a los diferentes comandos de
funcionamiento. Es de aclarar que a todos los parametros que tiene el variador se le
asigna una direccion Modbus por parte del fabricante, por lo que es posible realizar la
modificacion de cada uno de estos si llega a ser necesario.
Fig. 22 Parametros de configuracion función de lectura de registro Modbus. Fuente Autor
27
Los que nos interesan principalmente son los correspondientes a la referencia de
velocidad y a los comandos de marcha, como se observa en lo descrito por el manual en
la dirección 1 se escribe el valor que permite dar marcha al equipo tanto en el sentido
superior como en el inferior, y en la dirección 2 se puede ingresar la referencia de
velocidad con la cual trabajara el equipo, la modificación de este parámetro es la que
permite realizar el cambio a velocidad intermedia antes de parar en el piso
correspondiente.
Fig. 23 Direcciones y comandos usados en la comunicación. [8]
Para realizar la lectura de los monitores del equipo se utiliza la función con código 3 que
permite realizar la lectura de un registro del mapa Modbus, como en la escritura de
parámetros, en el manual se encuentran todas las direcciones correspondientes a los
valores de lectura.
Fig. 24 Configuración función de lectura de registros. Fuente Autor
En la tabla que se ve a continuación se observan los principales monitores a leer, en la
primera columna bajo el nombre se encuentra la dirección Modbus correspondiente,
28
con esto es posible llamar cualquiera de los datos que mide el variador, tanto de
corriente como potencia, etc.
En el caso de este proyecto se está consultando constantemente los valores de corriente
de consumo, voltaje de bus DC, referencia de velocidad, salida de velocidad y potencia
de salida.
Fig. 25 Ejemplo de monitores para lectura. [8]
5.2. Lógica De Control
Como se mencionó en el marco teórico la lógica de control es el cerebro del
funcionamiento del sistema, este se encarga de recibir las señales de los sensores y
enviar a los actuadores las activaciones de acuerdo a lo que se necesite. Para realizar la
implementación de esta se utilizó una Raspberry pi como componente de Hardware y
Codesys como componente de software.
El control implementado permite trabajar con un total de 5 pisos, esto indica que cuenta
con las señales de entrada tanto para los llamados de carro como los de piso
correspondientes a cada uno.
29
Fig. 26 Entorno de desarrollo Codesys. Fuente Autor
Codesys permite implementar una interfaz visual tipo HDMI que permite controlar el
sistema, para poder llevar a cabo pruebas y como un sistema de manejo opcional se
realiza el desarrollo de una pantalla que permita realizar las solicitudes de llamados y
observar el estado del funcionamiento la cual se puede observar en la siguiente imagen,
con esta se puede simular todo un ciclo de trabajo con lo que es posible rectificar fallos
en la lógica o así mismo realizar un proceso de rescate o similar.
Fig. 27 Interfaz de pruebas para la lógica de control. Fuente Autor
5.2.1. Llamadas de carro
El primer punto a analizar es el panel de llamadas de carro, cuenta con un botón para
cada uno de los pisos enumerado correspondientemente y uno para activar la apertura
de las puertas en caso de ser necesario. Se ha de tener en cuenta que en caso de activar
la llamada al piso actualmente en uso se ejecutara la apertura de las puertas.
30
Fig. 28 Panel para llamadas de carro. Fuente Autor
Como se observa a continuación cada una de las variables asignadas a los botones se
encargan de cambiar a verdadero la posición de un vector que almacena los
correspondientes llamados a piso, de esta manera a pesar de ser una señal no enclavada
permite que se maneje el llamado como un espacio de memoria que será consultado al
momento de realizar los viajes. Esta lógica se encuentra escrita en lenguaje Ladder
dentro del software Codesys.
Fig. 29 Código en ladder para detectar los llamados de carro. Fuente Autor
A continuación, se explicará en detalle el programa realizado para indicar el destino del
ascensor desde la cabina. Para ello dividimos el programa en las funciones que cumplen.
En la figura 6 podemos observar el bloque de comunicación implementado en un PSoC
4 con el fin de comunicarse con la Raspberry Pi quien es la encargada de la lógica del
sistema de control del ascensor.
31
Fig. 30. Bloque de comunicación I2C
El bloque de comunicación I2C observado en la figura anterior se implementó para la
transmisión y recepción de datos con la Raspberry Pi. Este bloque es configurado en
modo esclavo con la dirección 0x09 = 0001001, el cual siempre está a la espera de la
solicitud recibida por el dispositivo Maestro siendo para el proyecto una Raspberry Pi 3.
Luego se utiliza un bloque para hacer uso de un display 7 segmentos y el cuál podemos
observar en la figura 31.
Fig. 31. Bloque para manejo de Display 7 segmentos.
La configuración implementada para el bloque Segment LCD fue asignar como 1 el
número de líneas comunes y 7 como el número de segmentos, por lo cual cabe indicar
que se hace uso de un display 7 segmentos con un digito. Además, se debe agregar un
reloj para que realice la visualización del display de forma correcta.
Por otro lado, se crean pines de entrada para conectar a estos los botones encargados
de indicar el piso de destino, cerrar y abrir la puerta, un botón de emergencia, y un LED
para observar si hay comunicación entre el PSoC esclavo y la Raspberry Maestro.
Podemos observar esto en la figura 32.
32
Fig. 32 Pines de entrada.
Luego de terminar la programación gráfica procedemos a realizar la lógica de
programación en lenguaje C la cual mostraremos a continuación, y de la misma manera
analizaremos por partes, comenzado por la figura 33.
Fig. 33 Primera visualización del código de la cabina.
Del código que podemos ver en la figura 33 observamos unas variables creadas para la
comunicación I2C, estas variables se encargan de guardar la información que será
envidad o recibida por el protocolo I2C, además también encontramos una variable
‘status’ la cual indica la solicitud que es recibida por el dispositivo Maestro. También en
el inicio del código se tiene una variable llamada ‘piso’, la cual guardara el piso en el que
se encuentra el ascensor. Posteriormente encontramos unas instrucciones para
inicializar los bloques implementados anteriormente y además unos parámetros
iniciales necesarios para el protocolo I2C. En la figura 34 encontraremos la continuación
del código.
33
Fig. 34 Segunda visualización del código de la cabina.
La figura 34 nos muestra el comienzo del bucle infinito del código donde se ejecutará la
parte principal del programa. Para realizar el envío de datos por I2C se crea un
condicional que es usado para preguntar por una solicitud de lectura enviado por el
dispositivo maestro, al cumplir dicha condición se procede a limpiar el buffer de lectura
y posteriormente asignar a las variables que serán enviadas el estado de los pines de
entradas creados con el fin de indicar el piso de destino del ascensor, como también
algunos botones necesarios dentro de la cabina. Por último, en la figura 35 podemos ver
la parte final del código implementado.
Fig. 35 Tercera visualización del código de la cabina.
De la misma manera que se envían los datos por I2C, para recibir los datos enviados por
el dispositivo maestro se crea un condicional que pregunta por la solicitud escritura o
como se puede apreciar es una rutina para recibir datos. Como se realizó anteriormente,
se limpia el buffer de escritura y luego se procede a recorrer el vector donde queda
guardado los datos recibidos, y así poder asignar a la variable ‘piso’ la posición del piso
34
donde se encuentra el ascensor, con el fin de usar esta información y con la última
instrucción poder visualizarlo con el Display 7 segmentos. En el anexo podremos
apreciar el código completo el cual se ejecutará en la PSoC encargada de las llamadas
desde la cabina o carro, como también el plano del circuito PCB desarrollado. A
continuación, en la figura 36 se puede observar el circuito PCB ya con los componentes
montados.
Fig. 36 Circuito PCB con sus componentes encargado de llamadas desde la cabina.
5.2.2. Llamadas De piso
Desde la interfaz, las llamadas de piso pueden ser simuladas por medio de los paneles
que se observan en la siguiente imagen, cada uno de estos consta de un botón
correspondiente al llamado de subida y de baja dependiendo del piso, además de un
panel indicando cual es el piso actual en el que se encuentra el ascensor.
Fig. 37 Panel para realizar las llamadas de piso. Fuente Autor
De igual manera que con los llamados de carro, cada uno de los botones cambia a
verdadero el valor de una variable booleana que se encuentra en un vector, debido a
que el sistema diferencia los llamados de subida y de bajada, cada uno de estos cuenta
con un vector diferente para almacenar sus respectivos llamados.
35
Fig. 38 Programa en ladder para detectar las llamadas de piso. Fuente Autor
Cabe mencionar que el código de programación para hacer el llamado del ascensor e
indicar hacia donde se dirige, es muy similar al código anteriormente visto, así que se
mostrará los pocos cambios realizados. A continuación, podemos observar en la figura
38 algunos cambios en asignación y nombre de los pines de entradas.
Fig. 39 Esquema de la programación para el llamado del ascensor desde los pisos.
Para comenzar el PSoC 4 esclavo se configura con la dirección 0x08 = 0001000. Luego
podemos observar que los pines de entrada están asignados de tal manera que indican
la acción que debe realizar ascensor para dirigirse al piso de destino. Y encontramos
además un led que funciona igual que el programa anterior, solo se usa con el fin de
observar si la comunicación está funcionando.
Al terminar el esquema de la programación, procedemos a realizar la lógica de
programación en C de este programa, el cuál no varía mucho. Por lo tanto,
observaremos el cambio realizado para el llamado del ascensor en la figura 39.
36
Fig. 40 Rutina para envío de datos por I2C.
Como ya habíamos analizado anteriormente, el envío de datos por I2C se realiza usando
un condicional, pero el cambio realizado se encuentra en que las variables asignadas
indican en esta ocasión la acción y el destino que debe realizar el ascensor. En el anexo
podremos observar el código completo para el PSoC encargado del llamado del ascensor
desde cada piso, como su esquema y a su vez el circuito PCB desarrollado. A
continuación, podemos apreciar en la figura 40 (a) el circuito con sus componentes
donde se encuentra el PSoC y en la figura 40 (b) el circuito PCB el cual irá en cada uno
de los 5 pisos para el llamado del ascensor.
Fig. 41 (a) (arriba) Circuito PCB donde se el PSoC, (b) (abajo) Circuito PCB el cual se reparte en cada uno
de los 5 pisos.
37
- Programación de la comunicación I2C para la Raspberry Pi en Codesys.
Posteriormente de haber realizado los programas de las tarjetas que hacen los llamados
del ascensor e indican el destino del piso que se desea, se procede a mostrar el
desarrollo hecho por la Raspberry Pi (Maestro) para la comunicación I2C usando el
entorno del software CODESYS. Para comenzar, se agrega un dispositivo maestro I2C al
proyecto, cabe resaltar que para que realmente funcione la comunicación I2C se debe
habilitar esta opción por el terminal de Raspbian o por el escritorio. A continuación,
podemos observar en la figura 40 las variables creadas para enviar o recibir la
información de los PSoC esclavos.
Fig. 42 Asignación de variables para el protocolo I2C.
Luego de crear las variables para la comunicación I2C procedemos a realizar la lógica
para recibir los datos envidas por los esclavos y asignarlos a variables que usaremos para
el sistema de control del ascensor. La lógica de programación de este proceso se realiza
en el lenguaje de texto estructurado, como podemos ver en la figura 41.
Fig. 43 Lectura y asignación de datos recibidos por el buffer.
38
5.2.3. Sistema de sensores para pisos
Para poder detectar la llegada a cada uno de los pisos se utilizan las señales de unos
sensores que se encuentran en uno de los costados de la cabina, a continuación, se
procederá a explicar el funcionamiento de la detección de los pisos. Como se puede
observar la cabina cuenta con dos sensores, que en la mayoría de los casos son activados
por medio de imanes, uno ubicado encima del otro que están conectados directamente
como señal a la tarjeta de control, en la imagen se puede observar la ubicación
aproximada de los mismos, lo importante en este caso es que se encuentren a distancias
iguales de cada uno de los extremos para que la ubicación de parada no varíe entre
subida y bajada.
Fig. 44 Posición de los sensores en cabina. Fuente Autor
Cada uno de estos sensores detectara una señal correspondiente a los activadores del
piso, en el caso de ser imanes estos se encontrarán ubicados dentro del trayecto del
ascensor en una de las paredes de manera que cuando la cabina pase por su ubicación
estos sean detectados. De la misma manera que es importante la ubicación de los
sensores de cabina, los que se encuentran en las paredes del trayecto también deben
ser colocados de manera correcta para que el sistema no presente problemas de
nivelación.
Fig. 45 Posición Sensores de cabina y pared. Fuente Autor
Cabina
Sensor Superior
Sensor Inferior
Cabina
Sensores de piso
39
Si el ascensor va de bajada está a la espera de que el sensor inferior de la cabina detecte
un imán, esto le indica que se acerca al piso siguiente y en caso de ser necesario parar,
hace el cambio a una velocidad intermedia para que la parada no sea tan brusca, al
momento de detectar el imán superior una señal le indica que esta en el punto de
nivelación por lo que envía la señal de parada y espera a una próxima indicación. En caso
de que se encuentre el ascensor en subida el funcionamiento es el mismo pero el orden
de detección de los sensores se invierte.
En la interfaz de prueba los sensores superior e inferior son los que se observan en la
siguiente imagen, donde cada botón simula los sensores superior e inferior
respectivamente. Con esto es posible enviar ordenes de parada y de nivelación al
variador.
Fig. 46 Panel para simular la detección de los imanes. Fuente Autor
Los sensores también son configurados como entradas externas al control que permiten
que sean conectados cualquier tipo de sensor que se quiera utilizar.
5.2.4. Lógica del ascensor
El código principal del programa está escrito en Ladder como se observa en la figura, se
encarga de realizar la activación y desactivación de acciones que se encuentran como
subprogramas, donde cada una de estas se encarga de los posibles estados del ascensor,
siendo estos subida, bajada y quieto. Además de activar el estado de emergencia en
caso de que alguna de las seguridades sea activada o se evidencie algún problema de
funcionamiento.
40
Fig. 47 Programa de control principal. Fuente Autor
- Principal
El código que se encuentra en el programa principal se encarga de establecer cuál es la
siguiente acción a realizar por el ascensor, el mismo se activa cada vez que se cierra la
puerta después de un llamado y no tenía ninguna llamada previa en el mismo sentido
en el que se estaba realizando el viaje anterior. Este código se ejecuta constantemente
mientras no se tenga ningún llamado para que en el caso de presentarse alguno se
reaccione inmediatamente.
La línea 1 se encarga de colocar la referencia de velocidad nominal con la que debe
trabajar el variador al momento de iniciar algún viaje, después de esto el programa
ejecuta un ciclo alrededor de los posibles llamados que tenga el sistema en alguno de
los pisos con los que cuenta lo que se observa en la línea 2, en caso de encontrar un
llamado analiza cual es el sentido del viaje desde la línea 6 para que entre a trabajar otro
de los programas encargados de las funciones de subida o bajada.
1. G.Referencia_W := 6000; 2. FOR G.counter:=1 TO 5 BY 1 DO 3. //Si el llamado esta hecho 4. IF G.SP[G.Counter] OR G.LPD[G.Counter] OR
G.lpU[G.Counter] THEN
5. //Pregunta para subir o bajar 6. IF G.Piso < G.Counter THEN 7. G.LSubida := TRUE; 8. G.LPrin := FALSE; 9. ELSIF G.Piso > G.Counter THEN 10. G.LBajada :=TRUE;
11. G.LPrin := FALSE;
12. ELSE
13. G.Lpuertas := TRUE;
14. G.LPrin := FALSE;
15. G.SP[G.Piso] := FALSE;
16. G.LPU[G.Piso] := FALSE;
17. G.LPD[G.Piso] := FALSE;
18. END_IF
19. END_IF
20. END_FOR
41
El código encargado de la subida y de la bajada trabajan de manera similar, la línea 1
activa un booleano que sirve para la lógica interna del sistema, en la línea 2 se cambia
la variable de comandos del variador, la cual al tomar el valor de 2 para activar el bit 1
de la trama Modbus y así el Variador ande en uno de los sentidos de marcha. La línea 3
también funciona como una lógica interna para que el sistema sepa cuál es el último
estado de movimiento del ascensor.
1. G.On2 := TRUE; 2. G.Comandos := 2; 3. G.Subiendo := TRUE;
En el caso de que el ascensor se encuentre en subida lo primero que espera es la
detección del sensor inferior que se encuentra en la pared, al momento de encontrarlo
aumenta el contador de piso y en la línea 6 se pregunta si existe algún llamado que
atender en el mismo, de ser asi la variable denominada Bandera que permite cambiar el
estado de la lógica toma el valor de 2 y la referencia de velocidad es disminuida a la
intermedia o de nivelación, si no existen llamados en el piso la Bandera toma el valor de
1.
1. //Esta esperando Inferior 2. IF G.IInferior AND Bandera = 0 THEN 3. //Numero menos de piso y si esta solicitado parar 4. G.Piso := G.Piso + 1; 5. //Si esta solicitado bajar a media y esperar segundo iman 6. IF G.SP[G.Piso] OR G.LPU[G.Piso] or G.LPD[G.Piso] THEN 7. Bandera := 2; 8. G.Referencia_W := 3000; 9. ELSE 10. Bandera := 1;
11. END_IF
12. END_IF
En caso de que no hubiera llamado de piso se espera a que se detecte el sensor superior
con lo que se dará por dicho que este piso ya fue pasado y la bandera volver a tomar el
valor de 0.
1. IF Bandera = 1 THEN 2. IF G.ISuperior THEN 3. Bandera := 0; 4. END_IF 5. END_IF
Si se detectó un llamado en el piso al cual se llegó se espera a la detección del siguiente
sensor con lo que se envía la orden de parada al variador en la línea 5 y se activa el
programa que se encarga de la apertura de la puerta, antes de que se pase a la activación
de las puertas se consulta si existe algún llamado más arriba del piso actual para que al
cerrarse las puertas se continúe el viaje en el mismo sentido. De no existir más el
programa principal se encargara de rectificar la existencia de llamadas en bajada o de
esperar una nueva de ser necesario.
42
1. IF Bandera = 2 THEN 2. IF G.ISuperior THEN 3. //Mantiene media hasta que llegue el inferior 4. G.On2 := FALSE; 5. G.Comandos := 0; 6. G.Lpuertas := TRUE; 7. ////Si no hay mas llamados de subida de ahi para arriba
apagar subida
8. IF G.Piso = 5 THEN 9. G.Subiendo := FALSE; 10. ELSE
11. FOR G.counter_b:= G.Piso + 1 TO 5 BY 1 DO
12. IF G.SP[G.Counter_b] OR G.LPU[G.Counter_b] THEN
13. G.Subiendo := TRUE;
14. Bandera := 0;
15.
16. G.SP[G.Piso] := FALSE;
17. G.LPU[G.Piso] := FALSE;
18.
19. G.LSubida := FALSE;
20.
21. RETURN;
22. ELSE
23. G.Subiendo := FALSE;
24. END_IF
25. END_FOR
26. END_IF
27.
28. //Resetear Piso Al LLegar
29. G.SP[G.Piso] := FALSE;
30. G.LPU[G.Piso] := FALSE;
31.
32. G.LSubida := FALSE;
33.
34. Bandera := 0;
35. END_IF
36. END_IF
37.
El código de bajada cumple con el mismo funcionamiento que subida solo teniendo en
cuenta los llamados en otro sentido y el orden de los imanes en sentido inverso.
1. //Detecto superior si hay llamado 2. IF Bandera = 2 THEN 3. IF G.IInferior THEN 4. //Mantiene media hasta que llegue el inferior 5. G.On1 := FALSE; 6. G.Comandos := 0; 7. G.Lpuertas := TRUE; 8. ////Si no hay mas llamados de bajada de ahi para abajo
apagar bajada
9. IF G.Piso = 1 THEN 10. G.Bajando := FALSE;
11. ELSE
12. FOR G.counter_b:=1 TO G.Piso - 1 BY 1 DO
13. IF G.SP[G.Counter_b] OR G.LPD[G.Counter_b] THEN
14. G.Bajando := TRUE;
15. Bandera := 0;
16.
17. G.SP[G.Piso] := FALSE;
43
18. G.LPD[G.Piso] := FALSE;
19.
20. G.LBajada := FALSE;
21.
22. RETURN;
23. ELSE
24. G.Bajando := FALSE;
25. END_IF
26. END_FOR
27. END_IF
28.
29. //Resetear Piso Al LLegar
30. G.SP[G.Piso] := FALSE;
31. G.LPD[G.Piso] := FALSE;
32.
33. G.LBajada := FALSE;
34.
35. Bandera := 0;
36. END_IF
37. END_IF
38.
39. //Esta esperando Superior
40. IF G.ISuperior AND Bandera = 0 THEN
41. //Numero menos de piso y si esta solicitado parar
42. G.Piso := G.Piso - 1;
43. //Si esta solicitado bajar a media y esperar segundo iman
44. IF G.SP[G.Piso] OR G.LPD[G.Piso] OR G.LPU[G.Piso] THEN
45. Bandera := 2;
46. G.Referencia_W := 3000;
47. ELSE
48. Bandera := 1;
49. END_IF
50. END_IF
El programa que se encarga de la apertura de las puertas se observa a continuación, lo
primero es enviar la orden de apertura de puertas para lo cual se activa la variable
Apuertas, posterior a esto se tiene un retraso que permite que las personas entren o
salgan para luego enviar la orden de cierre de las puertas. Este procedimiento cuenta
con dos sensores que le permiten al sistema saber si la puerta se encuentra
efectivamente cerrada, o hay alguna obstrucción que impida su cierre, cuyo caso se
mantendrá la señal de apertura hasta que sea posible cerrar la puerta sin correr ningún
riesgo.
1. IF bandera_p THEN 2. G.Apuertas := TRUE; 3. 4. G.Delay(IN:=TRUE, PT:=T#3S); 5. IF NOT(G.Delay.Q) THEN 6. RETURN; 7. END_IF 8. 9. G.Delay(IN:=FALSE); 10. END_IF
11.
12. //Escribir Logica De puertas
13. //Esperar tiempo y no cerrar si esta activo sensor
14. //Cuando puertas termina activa principal
15.
44
16. bandera_p := FALSE;
17. IF G.puerta_obs THEN
18. G.Apuertas := TRUE;
19. ELSE
20. G.Apuertas := FALSE;
21. IF G.Puerta_Cerrada THEN
22. G.Lpuertas := FALSE;
23. Bandera_p := True;
24. IF G.Bajando THEN
25. G.LBajada := TRUE;
26. ELSIF G.Subiendo THEN
27. G.LSubida := TRUE;
28. ELSE
29. G.LPrin := TRUE;
30. END_IF
31. END_IF
32. END_IF
El código correspondiente al módulo de inspección se encarga de enviar órdenes
directas al variador a una velocidad especifica tanto en sentido como superior e inferior
por motivos de mantenimiento o solución de problemas, este código solo se encarga de
enviar las ordenes, lo importante es que en este modo todos los llamados son
almacenados mas no atendidos, de manera que es posible realizar cualquier trabajo sin
problema.
1. //Habilitar movimiento por inspeccion 2. G.Referencia_W := 3000; 3. IF G.UInsp THEN 4. G.Comandos := 2; 5. RETURN; 6. ELSIF G.DInsp THEN 7. G.Comandos := 1; 8. RETURN; 9. END_IF 10. G.Comandos := 0;
En el caso de activarse una emergencia se enviará una orden de bloqueo al variador, con
esta el mismo no recibe comandos de marcha de ningún tipo hasta que la señal sea
levantada por lo que se mantendrá en el punto en el que se presentó el inconveniente.
Luego de detectarse la alarma iniciará un conteo por un tiempo determinado después
del cual se dará inicio a un viaje el cual llevará la cabina al primer piso para en este abrir
las puertas y evitar cualquier problema de seguridad.
1. //Apagar todo 2. G.On1 := FALSE; 3. G.On2 := FALSE; 4. G.Comandos := 64; 5. 6. G.Delay(IN:=TRUE, PT:=T#20S); 7. IF NOT(G.Delay.Q) THEN 8. RETURN; 9. END_IF 10.
11. G.Delay(IN:=FALSE);
12.
13. IF NOT g.IEInferior THEN
45
14. G.On1 := TRUE;
15. ELSE
16. G.On1 := FALSE;
17. END_IF
18.
Fig. 48 Diagrama de flujo alarma
Aparte de las funciones y de los programas mencionados anteriormente, el sistema
cuenta con las siguientes funciones que complementan el funcionamiento:
- Control de iluminación: se designó una salida para la energización del sistema de
iluminación interno de la cabina, este funciona de manera que después de cierto
tiempo sin recibir un comando de marcha la iluminación se apague para así evitar
un consumo de energía excesivo.
- Detección de tiempo de viaje: También el sistema se alarma en caso de que algún
viaje realizado dure más de un tiempo establecido, esto depende del piso en el
que se encuentra y del destino del viaje. Esto se hace para evitar que se presente
46
algún tipo de inconveniente con que no se detectaron bien los sensores de los
pisos.
- Piso inicial: en el caso de que el sistema sea encendido por primera vez se utilizan
dos sensores extremos para enviar el ascensor a un punto conocido y posterior
a eso iniciar su funcionamiento normal.
- Sensores De Extremos de trayecto: son un par de sensores que se encuentran en
los puntos más extremos del trayecto, su función es impedir que el ascensor por
razones de mal funcionamiento suba demasiado o baje demasiado, esto lo
consigue activando el estado de emergencia del equipo.
5.3. Toma de Datos
Los datos tomados para analizar son la corriente, la velocidad tanto de referencia como
de salida, el voltaje del bus DC y el torque de salida, estos datos fueron seleccionados
para poder comprobar diversos problemas que pueda llegar a presenta el variador
durante su funcionamiento y tener un registro del consumo que presenta este, estos
datos pueden ser consultados desde la misma interfaz la cual permite visualizarlos por
medio de graficas mientras son enviados a la base de datos.
En el caso de la corriente, podemos monitorear cual es el consumo del motor en el
sistema, las horas de uso y el promedio durante el día, en estos sistemas la posibilidad
de tener acceso a esta información permite saber que tan bien dimensionado e instalado
está el sistema. Se puede observar el pico de corriente que presenta en el arranque, la
gráfica presente en la figura presenta la corriente multiplicada por 10.
Fig. 49 Datos de corriente tomados en la raspberry
La velocidad tanto de referencia como de salida permiten saber si el sistema está
haciendo un buen seguimiento y por lo tanto si está trabajando en las velocidades
47
correctas, un desfase en estas ocasiona problemas de nivelación, parada y puede llegar
a disparar el variador por desviaciones de velocidad.
Fig. 50 Arriba grafica de referencias de frecuencia al momento del arranque, abajo grafica de
referencias de frecuencia al momento de nivelar.
En las gráficas se puede observar tanto el momento de arranque cuando el variador
recibe la referencia de frecuencia y esta es posteriormente enviada como frecuencia de
salida y también el cambio de velocidad nominal a intermedia al momento de llegar a
piso y realizar la nivelación.
El voltaje del bus DC permite saber dos cosas, por un lado, si este tiene un valor muy
bajo quiere decir que la alimentación de este no se encuentra en los valores en los que
debería estar lo que fuerza al variador para que entregue la corriente de salida
solicitada. Además, en el caso de que este voltaje suba en algún punto, se puede deber
48
a la regeneración del sistema lo que indica una carga demasiado grande para el variador
o un equipo de frenado mal dimensionado.
Fig. 51 Graficas de Voltaje en el bus DC y corriente en el equipo al momento del arranque.
A continuación, podemos observar en la figura 52 de forma general el proceso que se
realizará para subir los datos obtenidos por el variador hasta la nube.
Fig. 52 Proceso para subir y almacenar a una base de datos IBM.
5.3.1. Comunicación Mqtt con CloudMqtt
Como parte de los objetivos del proyecto a realizar está establecer una comunicación
con la nube de código abierto. Por consiguiente, la manera que se utilizó para subir datos
al internet fue usar el protocolo de comunicación MQTT en Codesys e implementarlo a
la Raspberry Pi.
Como primer paso para realizar este proceso es necesario que la Raspberry Pi posea
conexión con internet, la cual puede recibir tanto por conexión Ethernet o usando una
conexión Wifi.
El segundo paso por realizar es usar la página https://www.cloudmqtt.com/ con la cual
se puede crear una instancia con un plan gratuito, y al cual subiremos la información
49
que deseamos con la Raspberry Pi. Al crear la instancia esta nos brinda los parámetros
tales como el servidor, un usuario, una contraseña, un puerto, etc. Necesarios para
poder establecer la comunicación con esta instancia, como podemos observar a
continuación en la figura 46.
Fig. 53 Información para establecer comunicación con el servidor creado.
Como tercer paso implementaremos la comunicación Mqtt con el servidor creado
usando Codesys, al cuál es necesario instalarle la librería ‘Janz Tec MQTT library’ para
poder desarrollar la comunicación. En la figura 47 podemos observar las variables
creadas y a su vez asignadas a los parámetros que obtuvimos del servidor creado.
Fig. 54 Variables creadas y asignadas según los parámetros del servidor.
El lenguaje que se utilizó para realizar la comunicación Mqtt fue CFC, el cual podemos
observar en la figura 48, allí encontraremos el bloque que exige todas las variables
anteriormente creadas con el fin de poder conectarse al servidor de CloudMqtt, y el cuál
sabremos si hubo conexión al ver el estado de la variable ‘conectado’.
50
Fig. 55 Esquema para establecer comunicación por protocolo Mqtt.
Al realizar estos pasos se obtuvo una conexión correcta con la nube siempre y cuando la
Raspberry Pi tenga internet. A continuación, se desarrolla la lógica para poder publicar
la información al servidor, para ello la figura 49 se muestra la lógica de programación
para subir información, que para este proyecto los son datos de la corriente del motor
que mueve el ascensor y el voltaje DC de entrada.
Fig. 56 Bloques para publicar al servidor Mqtt.
Como podemos observar en la figura 49 se toman las variables ‘Corriente’ y
‘Voltaje_BUS_DC’ y se realiza una conversión a tipo String, ya que este es el único
formato que recibe el servidor Mqtt. Para poder hacer la publicación de la variable que
deseamos, se usa la variable Booleana ‘ciclotrigger’ con el fin que al tener el estado
‘TRUE’ publique la información en ese instante, por lo tanto, el fin de esta variable es su
cambio de estado para poder publicar información constantemente.
5.3.2. Node-red y Base de datos Cloudant de IBM.
El desarrollo hecho hasta el momento permite publicar a un servidor en la nube los datos
que se obtienen del variador que controla el motor del ascensor. Ahora el método
implementado para guardar esa información fue usar Node-red como intermediario
entre el servidor CloudMqtt y un servicio de plan gratuito de IBM llamado Cloudant el
cual funciona como una base de datos. Para lograr esto se llevó a cabo los siguientes
pasos.
51
Primero se registró una cuenta a IBM Cloud obteniendo el plan Lite, este plan permite
usar algunos servicios que distribuye IBM de forma gratuita, aunque posee algunas
limitaciones. Allí al tener la cuenta ya creada procedemos a agregar el recurso de una
base de datos llamada Cloudant, el cual podemos observar en la figura 50.
Fig. 57 Recurso Cloudant lite.
Al tener el servicio agregado en nuestra cuenta, ingresamos a este recurso para obtener
las credenciales, ya que estas son necesarias para realizar una conexión a esta base de
datos desde node-red. Al estar dentro el entorno de Cloudant procedemos a crear una
base de datos en la cual se almacenará los datos que publicamos con la Raspberry Pi,
por lo tanto, la figura 51 muestra la base de datos creada con el nombre ‘database1’.
Fig. 58 Base de datos en Cloudant.
Al tener nuestra base de datos ya creada procedemos a usar node-red para realizar la
conexión entre Cloudmqtt y la base de datos Cloudant. Para ello primero se instaló los
flujos necesarios para node-red. A continuación, la figura 52 muestra los flujos usados
para este proyecto y el esquema de las variables que serán almacenadas en la base de
datos.
52
Fig. 59 Flujos para envío datos de Mqtt a la base de datos.
Para que los flujos funcionen correctamente se ingresan unos parámetros necesarios
que permitirán conectar primero el Servidor CloudMqtt al flujo Mqtt de node-red y
luego del flujo Cloudant a la base de datos de Cloudant. Por consiguiente, primero los
datos que exige el flujo mqtt son los mostrados en la figura 53.
Fig. 60 Parámetros para configurar el Flujo Mqtt de salida.
Al configurar el flujo Mqtt como fue mostrado en la figura anterior, permitirá una
conexión con el servidor de CloudMqtt anteriormente creado. El siguiente paso que se
realizo fue configurar el flujo de Cloudant de node-red para realizar la conexión con el
recurso de IBM que creamos anteriormente llamado Cloudant, como podemos observar
en la figura 54.
Fig. 61 Parámetros para configurar el flujo de Cloudant de entrada.
53
Los parámetros ingresados en el flujo de node-red son las credenciales que fueron
brindados al crear el recurso de IBM Cloudant. Lo único faltante para poder almacenar
la información es indicar la base de datos que fue creada en el recurso de IBM, de tal
manera que la figura 55 muestra la configuración faltante.
Figura 62. Configuración para almacenar información a la base de datos creada.
También podemos observar en node red otros flujos tales como “Split” encargado de
dividir los datos obtenidos del flujo Mqtt usando un carácter divisor, “Fecha_hora”
encargada de agregar al flujo de datos la fecha y hora en que fue publicado el mensaje
proveniente del servidor cloudmqtt, además de clasificar las variables publicadas
asignándoles un número del 1 a 5 respectivamente con “Corriente”, “Voltaje_BUS”,
“Referencia_R”, “Frecuencia_Salida” y “Alarmas”, en la figura 56 podremos observar el
código que realiza esa función, y por último el flujo “delete” encargado de borrar
información no tan relevante.
Fig. 63 Función “Fecha_hora” y el código incluido.
Al ejecutar en conjunto toda la programación que se ha realizado hasta este punto, se
pudo observar como la información iba siendo almacenada en la base de datos
‘database1’ obteniendo como resultado la figura 56.
54
Fig. 64 Base de datos ‘database1’ con datos almacenados.
5.3.3. Azure Studio y Machine Learning.
Para llevar a cabo la etapa de manejo de los datos con Machine Learning se hace uso de
la plataforma de Microsoft Azure con la cual es posible realizar proyectos de machine
learning en primera instacia lo que se necesita es llevar la base de datos obtenida desde
la raspberry a la plataforma de Microsoft, esto se puede realizar importándola
directamente como el archivo csv generado, ya que la plataforma de Microsoft es
totalmente en línea estos datos quedan almacenados en la nube para que sea posible
acceder a los mismos desde cualquier parte.
Fig. 65 Pantalla de la interfaz de azure para subir un nuevo dataset.
55
Fig. 66 Datasets subidos a la plataforma de azure
Ya teniendo los datos cargados en el sistema se crea un experimento el cual permite
hacer uso de bloques de funciones que permiten hacer el manejo de los datos y crear
los modelos y experimentos para entrenar y evaluar los diseños.
Para el caso de este proyecto se decidio hacer uso de las maqunas de soporte vectorial
o SVM, esta es entrenada con una serie de datos como se observa en la siguiente figura.
Fig. 67 Flujo de funciones para el entrenamiento y la evaluación
56
Lo primero que se realiza con el conjunto de datos obtenido es seleccionar las columnas
que serán necesarias para realizar el proceso, posterior a esto se realiza la normalización
de los datos y la división de los mismos, con una de las partes se entrena el modelo de
soporte vectorial y con la otra se realiza una evaluación de los datos buscando que el
porcentaje de exactitud sea lo suficientemente alto.
Luego de realizar este análisis es posible determinar la probabilidad con la que aparecerá
cada uno de los valores en el tiempo como se observa en la siguiente imagen, el dato
payload es el valor que es enviado en este caso de potencia en el sistema. Observando
que a pesar de que la mayor presencia esta en los valores positivos, aunque es posible
encontrar varios valores negativos los cuales están presentes en la regeneración del
sistema.
Fig. 68 Probabilidad obtenida de cada uno de los datos normalizados
A continuación, se presenta una gráfica con los resultados en precisión del
entrenamiento del modelo, la idea es que el modelo tampoco tenga un valor demasiado
alto ya que esto llevaría a un exceso de computo a la hora de evaluar realmente los
datos.
Fig. 69 Precisión obtenida durante las pruebas.
57
Con la evaluación de datos se obtiene unos valores estadísticos que permiten determinar qué
tan preciso es todo el proceso realizado.
Fig. 70 Datos estadísticos obtenidos luego de realizar la evaluación
A continuación, se puede observar los valores asignados a una base de datos de entrada
preestablecida en la cual se ingresan una serie de valores de tiempo con los que el
modelo entrenado devuelve los posibles valores de corriente. Para esta prueba se
tomaron lapsos de tiempo cortos debido a las limitaciones en la raspberry y en las
pruebas, se observa que 3 valores son los que principalmente se encontraran durante la
ejecución según la predicción realizada los cuales son 14.4 que equivale a 1.4 amperios
que es el consumo en la velocidad nominal del sistema 0.9 amperios para la velocidad
de nivelación y 0 durante los lapsos en los cuales el ascensor no se encuentra realizando
ningún viaje.
Fig. 71 Evaluación de una base de datos de en lapsos de minutos.
58
6. Conclusiones
El variador de velocidad es un dispositivo que permite manejar los motores de manera
eficiente y permitiendo tener un control sobre el voltaje, la corriente y el torque de
salida. Además de esto cuenta con las suficientes posibilidades de configuración para
que se pueda manipular la carga de manera óptima de acuerdo a la aplicación específica.
Una de las ventajas de la implementación del modelo de variador usado en este
proyecto es la sencilla implementación de comunicación Modbus con la que cuenta, ya
que el venir previamente integrada no es necesario instalar ningún tipo de tarjeta de
comunicación o similar.
Los sensores de detección de piso cuentan con un papel muy importante en el
funcionamiento de un ascensor, una ubicación errónea de los mismo lleva a que el
sistema pierda el punto de referencia lo que puede llegar a ocasionar que funcione fuera
de los valores normales de trabajo.
La importancia que cobra tener ciertos parámetros de seguridad en el sistema se debe
a la carga manejada, por esto es necesario que se tenga en cuenta ciertas seguridad
como tiempos de viaje, apertura de puertas y excesos de velocidad.
La lógica manejada por el control como tal tiene que tener en cuenta cual es el viaje con
mayor sentido a realizar y así mismo atender cada llamada en el mejor momento, esto
se evidencia al momento de realizar pruebas de subida y de bajada en donde el ascensor
puede tener pérdidas de algunas de estas o dirigirse en un sentido que alargue alguno
de los viajes.
Al realizar las pruebas de comunicación I2C entre la Raspberry Pi Maestro y los PSoCs
esclavos, uno de los errores comunes por la que puede fallar esta comunicación es
porque se agregan dentro la rutina de lectura o escritura, retrasos (Delays) que hacen
desincronizar la comunicación causando fallas en la trasmisión de datos. Otra de las
fallas o más que todo deficiencias de este tipo de comunicación es que la distancia
permitida para lograr una comunicación aceptable es de 50m, si contamos que tenemos
un edificio de 5 pisos podríamos estar alcanzando esta brecha, por lo cual no sería muy
viable esta comunicación para un edificio que supere esta altura, además de que la
comunicación puede fallar un poco más si se encuentra en un entorno industrial.
En las primeras pruebas realizadas para subir los datos que nos brindaba el variador de
velocidad, encontramos que la velocidad con la que publica la comunicación MQTT los
datos influye en una falla del programa y al mismo tiempo bloquea la Raspberry Pi. Por
lo tanto, haciendo pruebas de ensayo y error se encontró qué para que no ocurriera esta
falla la velocidad con la que se publican los datos es de cada 200 mseg
aproximadamente.
Al querer usar un servidor de código abierto o de forma gratuita encontramos que el
servidor de CloudMqtt nos sería útil para subir la información. El inconveniente que
surge es que el plan gratuito que brinda CloudMqtt permite solo suscribir 5 Tópicos no
más, ya que para adquirir más tópicos se debe cambiar a un plan pago. Sin embargo, las
variables que publicamos son tan solo 5 estando en la brecha del límite del plan.
De la misma manera que usamos la versión gratuita en CloudMqtt, así mismo utilizamos
los servicios lite gratuitos que dispone IBM Cloud, pero por obvias razones nos
enfrentamos a limitantes como recursos que no podemos usar, limitaciones en cantidad
de conexiones, algunas opciones propias de los recursos no se pueden usar, o alguna
59
limitante en cantidad de datos que se manejan. Por lo tanto, al realizar las pruebas en
ciertos casos nos veíamos cohibidos para probar otras opciones que pudiesen haber sido
más útiles pero que a su vez no son gratuitos.
60
7. Referencias
[1] ABB, «New ABB,» 2018. [En línea]. Available: https://new.abb.com/drives/es/que-es-un-
variador.
[2] ATO, «AC DRIVE,» 2018. [En línea]. Available: http://www.acdrive.org/ac-drive-working-
principle.html. [Último acceso: 07 2018].
[3] Yaskawa, «Yaskawa Corporation,» 2018. [En línea]. Available:
https://www.yaskawa.com/products/drives/elevator-drives/commercial-
solutions/l1000e-drive. [Último acceso: 07 2018].
[4] L. LOPEZ, «eoi,» 19 10 2016. [En línea]. Available:
http://www.eoi.es/blogs/redinnovacionEOI/2016/10/13/el-ahorro-energetico-en-
ascensores/. [Último acceso: 07 2018].
[5] Enggcyclopedia, «Enggcyclopedia,» 2018. [En línea]. Available:
http://www.enggcyclopedia.com/2012/09/squirrel-cage-induction-motors/. [Último
acceso: 07 2018].
[6] «Emfmotor,» 2018. [En línea]. Available: https://www.emfmotor.com/sqml-gearless-lift-
motor.html. [Último acceso: 07 2018].
[7] Schneider, «Schneider Electric,» 2018. [En línea]. Available: https://www.schneider-
electric.com/en/faqs/FA168406/. [Último acceso: 07 2018].
[8] Yaskawa, Variador De CA Yaskawa L1000E, 2016.
[9] Electronilab, «Electronilab,» 2018. [En línea]. Available:
https://electronilab.co/tienda/convertidor-usb-rs485/. [Último acceso: 07 2018].
[10] Anton Girod Fortuño, “Programación de PLC con CODESYS - Automatización
Industrial,” 2018. [Online]. Available: https://cursoplcs.com/. [Accessed: 25-Jul-2018].
[11] “Índice a . El Software De Programación Codesys ___ 3,” pp. 1–37
[12] S. Gallardo Vázquez, Tecnicas y procesos en instalaciones domoticas y automaticas :
Electricidad-electronica : [Sistemas electrotecnicos y automatizados]. Paraninfo, 2013.
[13] SIEMENS, “SIMATIC CFC - Software for SIMATIC Controllers - Siemens.
[14] M. A. (ingeniero industrial) Pérez García, Instrumentacion electronica. Paraninfo, 2014.
[15] _ © Antonio and M. Fernández, “Tema 5: El bus I2C TEMA 5 EL BUS I2C,” 2004.
[16] D. Oasis, “¿ Por qué MQTT es uno de los mejores protocolos de red para,” pp. 1–9, 2017.
[17] F. Mocq, Raspberry Pi 2 : utilice todo el potencial de su nano-ordenador. Ediciones ENI,
2016.
[18] CYPRESS, “Programmable System - on - Chip - Cypress,” Estados Unidos ( California), p. 1, 2014.
61
[19] A. F. G. Viera, «Técnicas de aprendizaje de máquina utilizadas para la minería de texto,» SciELO Analytics, 2017.
62
8. ANEXOS
Anexo 1.
Código completo desarrollado para las llamadas desde el carro y esquema, además del
circuito PCB desarrollado.
#include <project.h>
#include <stdio.h>
#include <stdlib.h>
int piso = 0;
int main(void)
{
int i=0, LED;
////VARIABLES I2C
uint8 wrBuf[8];
uint8 rdBuf[8];
uint8 userArray[8];
uint8 byteCnt;
uint8 indexCntr;
uint32 status;
CyGlobalIntEnable; /* Enable global interrupts. */
LCD_Seg_Start(); //Inicializamos el bloque LCD_SEG
Clock_Start(); //Inicializamos el Reloj
I2C_Start(); //Inicializamos el bloque de comunicación I2C
I2C_I2CSlaveInitWriteBuf((uint8 *) wrBuf, 8);
I2C_I2CSlaveInitReadBuf((uint8 *) rdBuf, 8);
//Comienzo bucle infito ----------------------------------------
for(;;)
{
/* Place your application code here. */
// Rutina para enviar datos por I2C ------------------------
if(0u != (I2C_I2CSlaveStatus() & I2C_I2C_SSTAT_RD_CMPLT))
{
byteCnt = I2C_I2CSlaveGetReadBufSize();
I2C_I2CSlaveClearReadStatus();
I2C_I2CSlaveClearReadBuf();
rdBuf[0]=Piso1_Read();
rdBuf[1]=Piso2_Read();
rdBuf[2]=Piso3_Read();
rdBuf[3]=Piso4_Read();
rdBuf[4]=Piso5_Read();
rdBuf[5]=Abrir_Read();
rdBuf[6]=Cerrar_Read();
rdBuf[7]=Emergencia_Read();
}
// Fin de la rutina para enviar datos ------------------------
// Rutina para recibir datos por I2C ------------------------
if(0u != (I2C_I2CSlaveStatus() & I2C_I2C_SSTAT_WR_CMPLT))
{
byteCnt = I2C_I2CSlaveGetWriteBufSize();
63
I2C_I2CSlaveClearWriteStatus();
for(i=0; i < byteCnt; i++)
{
userArray[i] = wrBuf[i]; /* Transfer data */
LED = userArray[1];
piso = userArray[2]; //En esta posición del arreglo
guardamos el piso del ascensor
}
I2C_I2CSlaveClearWriteBuf();
}
// Fin de la rutina para enviar datos ------------------------
if(LED == 1){led_Write(1);}
if(LED == 0){led_Write(0);}
LCD_Seg_Write7SegDigit_0(piso,0); //Instrucción para
escribir un número en el Display 7 seg
//el cual indicará el piso
donde esta el ascensor
}
//Fin del bucle infito ----------------------------------------
}
/* [] END OF FILE */
Código llamadas de cabina.
Esquema del código llamadas de cabina.
64
Circuito PCB desarrollado para llamadas de la cabina.
Anexo 2.
Código completo desarrollado para las llamadas desde los pisos y esquema, además de
los dos circuitos PCB desarrollados.
#include <project.h>
#include <stdio.h>
#include <stdlib.h>
int piso = 0;
int main(void)
{
int i=0, LED;
////VARIABLES I2C
uint8 wrBuf[8];
uint8 rdBuf[8];
uint8 userArray[8];
uint8 byteCnt;
uint8 indexCntr;
uint32 status;
//SPIS_Start();
CyGlobalIntEnable; /* Enable global interrupts. */
LCD_Seg_Start();
Clock_Start();
65
I2C_Start();
I2C_I2CSlaveInitWriteBuf((uint8 *) wrBuf, 8);
I2C_I2CSlaveInitReadBuf((uint8 *) rdBuf, 8);
for(;;)
{
/* Place your application code here. */
// Rutina para enviar datos por I2C ------------------------
if(0u != (I2C_I2CSlaveStatus() & I2C_I2C_SSTAT_RD_CMPLT))
{
byteCnt = I2C_I2CSlaveGetReadBufSize();
I2C_I2CSlaveClearReadStatus();
I2C_I2CSlaveClearReadBuf();
rdBuf[0]=UpP1_Read();
rdBuf[1]=DownP2_Read();
rdBuf[2]=UpP2_Read();
rdBuf[3]=DownP3_Read();
rdBuf[4]=UpP3_Read();
rdBuf[5]=DownP4_Read();
rdBuf[6]=UpP4_Read();
rdBuf[7]=DownP5_Read();
}
// Fin de la rutina para enviar datos ------------------------
// Rutina para recibir datos por I2C ------------------------
if(0u != (I2C_I2CSlaveStatus() & I2C_I2C_SSTAT_WR_CMPLT))
{
byteCnt = I2C_I2CSlaveGetWriteBufSize();
I2C_I2CSlaveClearWriteStatus();
for(i=0; i < byteCnt; i++)
{
userArray[i] = wrBuf[i]; /* Transfer data */
LED = userArray[1];
piso = userArray[2];
}
I2C_I2CSlaveClearWriteBuf();
}
// Fin de la rutina para enviar datos ------------------------
if(LED == 1){led_Write(1);}
if(LED == 0){led_Write(0);}
LCD_Seg_Write7SegDigit_0(piso,0); //Instrucción para
escribir un número en el Display 7 seg
//el cual indicará el piso
donde esta el ascensor
}
}
/* [] END OF FILE */
Código llamado desde los pisos.
66
Esquema del código llamadas desde los pisos.
Circuito PCB donde se encuentra el PSoC
Circuito PCB ubicada en cada piso.
67
Anexo 2
Equipos Para pruebas
Durante el desarrollo del proyecto las principales pruebas fueron realizada utilizando un
demo de variador A1000, ya que en sus parámetros principales y funcionamiento no
difiere del modelo L1000. El demo consiste en un variador modelo A1000 el cual tiene
acoplada en su alimentación un arreglo de condensadores que permiten alimentarlo de
una línea de 120.
Variador instalado en el Demo. Fuente Autor
Junto con el demo usado se utilizó un motor trifásico para comprobar que todos los
comandos funcionaran de manera correcta.
68
Motor usado junto con el Demo Fuente Autor
Los datos de prueba enviados a la base en la nube son tomados de estas pruebas de
funcionamiento. Debido a la facilidad de manipulación de este demo es posible realizar
pruebas sin necesidad de la instalación de
También fue posible utilizar un modelo L1000 en la realización de pruebas usando un
tablero de pruebas el cual consta del variador y sus conexiones tanto de potencia como
de control, en este caso se utilizó una maquina gearless para realizar las pruebas.
Maquina Gearless Usada para pruebas. Fuente Autor
Las simulaciones realizadas con este tablero permiten una más alta fiabilidad debido a
que en este caso se utiliza una alimentación de 220 V y un motor de más capacidad.
Además, una de las salidas del tablero es utilizada para alimentar el electrofreno de la
misma máquina que por seguridad si no es activado impide el movimiento del motor.
también en este caso es posible trabajar un control de velocidad en lazo cerrado, esto
gracias a que la maquina cuenta con un encoder instalado que permite la realimentación
al variador de la velocidad de salida.
69
Planos del tablero de pruebas con variador L1000A
70
