Novedades 20151113

publicado en: HMI, Industria 4.0, Motores, SCADA, Seguridad | 0

L. Studwell y D. Dibbern analizan el futuro de la automatización (y especialmente la robótica) en la industria alimentaria. Como otros sectores, se puede beneficiar de la creciente flexibilidad en las nuevas implantaciones, o el just-in-time con la posibilidad de personalizar el producto adquirido vía comercio electrónico. Por último, mencionan el reto de reubicar la mano de obra.
El siguiente análisis desgrana los pros y contras de los distintos métodos de arranque de motores eléctricos: los clásicos estrella-triángulo y autotransformador, los variadores y los arrancadores suaves. Además de describir sus características, A. Fornwald proporciona las claves para decantarse por uno u otro sistema.
El INCIBE ha publicado una entrada dedicada a la seguridad en la industria 4.0. Aunque los nuevos retos vienen acompañados de amenazas nuevas, las medidas a tomar son en parte actualización de las que debieran existir previamente: fortificación mediante criptografía, control de acceso, detección, etc. Concluye con referencias a grupos de trabajo de interés.
Las tablet en industria no son nuevas, pero se concebían dentro de sistemas de control obstinadamente aislados, y la conexión inalámbrica se aceptaba de mala gana sólo cuando el operador debía desplazarse. Hoy tiene poco sentido. Una tablet o un smartphone, además de servir como interfaces de precio reducido, son herramientas valiosas en una integración con el resto de sistemas que puede beneficiarse (¿por qué no?) de la nube.
Lindsey Clark resume unas buenas prácticas en el desarrollo de gráficos para HMI. Todos entendemos la necesidad de corrección o de “lógica visual”. El resto de recomendaciones no son tan generalmente compartidas: abundan los SCADA con representación abigarrada o animaciones que distraen. ¿Por qué se muestra a veces un motor parado en color rojo (¡no es una alarma!)? ¿Por qué hay animarlo cuando arranca? Prometo una reflexión más extensa.

KNX (3)

publicado en: KNX | 0

En la entrada KNX (2) comencé a explicar el protocolo KNX a partir de una trama de ejemplo, describiendo el significado de los seis primeros bytes. Quedó pendiente el resto, que contiene la información relativa a la capa de transporte (T_PDU). Ésta se subdivide a su vez en dos partes: los seis primeros bits y el resto, que encapsula el contenido de aplicación (A_PDU).

Telegrama KNX
Telegrama KNX

El primer bit del T_PDU nos indica si el paquete es de datos (0) o de control (1). En el primer caso, el telegrama transmite una petición relacionada directamente con el funcionamiento de los dispositivos (escritura de datos, lectura, respuesta, reinicio de dispositivo, etc.). Los mensajes de control, en cambio, regulan el transporte en las conexiones punto a punto. Profundizaré en estos dos tipos de tramas más adelante.
El segundo bit especifica si el paquete está numerado (1) o no (0). KNX permite fraccionar los mensajes muy largos hasta en 16 fragmentos. El orden de la secuencia se indica mediante los cuatro bits siguientes. En el caso de los paquetes no numerados, estos bits no cumplen función y quedan a cero. Examinando los dos primeros bits del T_PDU, podemos decir que existen por tanto cuatro tipos de paquetes:

  • Paquetes de datos no numerados (UDP, Unnumbered Data Packet): 00
  • Paquetes de datos numerados (NDP, Numbered Data Packet): 01
  • Paquetes de control no numerados (UCD, Unnumbered Control Data): 10
  • Paquetes de control numerados (NCD, Unnumbered Control Data): 11

El resto del T_PDU está formado por la información de aplicación. En el caso de los paquetes de control, su función viene indicada por los dos primeros bits del A_PDU, de la siguiente forma:

  • Si el paquete no está numerado (esto es, es un UCD), indican el inicio (00) o fin (01) de una conexión punto a punto.
  • Si el paquete está numerado (NCD), se usan para confirmar positivamente (10) o negativamente (11) la recepción del último telegrama.

Este tipo de mensajes se usan para controlar una conexión orientada a conexión, punto a punto, y se emplean esencialmente para la comunicación entre el software de programación (ETS) y los dispositivos, con objeto de descargar parámetros, programa, direcciones, etc. Este enlace, aunque tiene gran consumo de ancho de banda, garantiza la transmisión íntegra de la información. El servidor es el que inicia la conexión. Por cada paquete enviado se debe recibir una confirmación positiva, y en todo momento cualquiera de los dos intervinientes puede cerrar la conexión.
Cuando el paquete enviado es de datos, son los cuatro primeros bits del A_PDU los que indican su función. Se denominan APCI (Application -Layer- Protocol Control Information). Las más usadas son las siguientes:

  • 0000 – Lectura de un objetos de un grupo (GroupValueRead). Se piden los datos a los dispositivos definidos por la dirección de grupo. Los seis bits restantes del A_PDU no cumplen función alguna.
  • 0001 – Respuesta al mensaje previo (GroupValueResponse). Si los datos no caben en los seis bits restantes del A_PDU, se amplía éste con tantos bytes como sea necesario.
  • 0010 – Escritura de los objetos de un grupo (GroupValueWrite). Los valores siguientes se escriben a todos los dispositivos de dicho grupo. Como en el caso previo, si los datos superan los seis bits, se amplía el A_PDU con los bytes necesarios.
  • 0011 – Escritura de una dirección individual (IndividualAddressWrite). Similar al anterior, pero se envían los datos a un dispositivo identificado por una dirección individual, en vez de de grupo.
  • 0100 – Lectura de una dirección individual (IndividualAddressRead).
  • 0101 – Respuesta a una lectura de una dirección individual (IndividualAddressResponse).

Los siguientes APCI, en orden, son:

  • AdcRead, AdcResponse (lectura de analógicas con filtrado)
  • MemoryRead, MemoryResponse, MemoryWrite (manejo de memoria)
  • UserMessage (intercambio de datos)
  • MaskVersionRead, MaskVersionResponse (lectura de perfil del dispositivo)
  • Restart (reinicio)
  • Escape (funciones ACPI extendidas, gracias a los seis bits restantes)

Novedades 20151102

La noche del 24 al 25 de octubre, en la mayoría de los países europeos, entre ellos España, tuvo fin el horario de verano. Aproveché para avisar de que, en todas aquellas instalaciones que tienen programaciones horarias y no se haya contemplado dicho cambio, es necesario actualizar la hora de los controladores. Lo ideal es habilitar donde se pueda el servicio de horario con esta característica y mantenerlo actualizado por NTP.
El estándar IEEE 802.3at-2009 describe la alimentación eléctrica a través de la red Ethernet (PoE). Los fabricantes no siempre se acogen a esta norma, por cierto. Anja Adling, de Siemens, comenta las cuatro clasificaciones de dispositivos en el nivel físico según sus requerimientos, y la clasificación a nivel de enlace. También el mecanismo de apagado por prioridad, y el ahorro que se puede conseguir con la gestión PoE.
En un par de ocasiones me han planteado monitorizar instalaciones desde el aire, por medio de drones. La tarea es mucho más compleja de lo que puede parecer, y requiere fuertemente de la inteligencia artificial para asistir el vuelo autónomo, el reconocimiento visual, detección de patrones y la evaluación. Siemens está ensayando un nuevo enfoque, monitorizando las respuestas cerebrales de especialistas, de modo que el sistema aprende del comportamiento humano.
De este artículo de Suzanne Gill me gustaría rescatar una idea: la importancia, conforme se avance hacia la Industria 4.0 y el IIoT, de trasladar y aumentar las ventajas de tecnologías como HART o Fieldbus (sencillez de integración, “autoconfiguración”, llevar el diagnóstico hasta el MES, e incluso ERP…). Por lo demás, el texto es confuso. Identifica HART con un bus de campo, cuando ni siquiera es un bus (aparte las referencias a Fieldbus); da pie a relacionar el IoT con HART (sin pasar por HART-IP); las menciones a CAM, CIM, NAMUR NE107 o FDI no vienen al caso…
Shady Yehia tiene publicado en su blog un artículo dividido en cuatro entradas muy instructivo acerca de los sistemas de control. Lo recomiendo para quien se quiera aproximar a la materia; en particular los primeros párrafos, donde da una visión general de flujo de información desde el proceso al sistema SCADA y de nuevo de vuelta, pasando por sensores/actuadores, PLC, y servidor OPC.
Journey to the Center of the Plant, from Field to SCADA and Back – 1
Journey to the Center of the Plant, from Field to SCADA and Back – 2
Journey to the Center of the Plant, from Field to SCADA and Back – 3
Journey to the Center of the Plant, from Field to SCADA and Back – 4

KNX (2)

publicado en: KNX | 0

En la pasada entrada sobre KNX hice un esbozo sobre la arquitectura de estos sistemas domóticos. Comenté que el direccionamiento de cada equipo se hace mediante dos bytes, que recogían el área en que se encuentra (bus principal), el bus secundario y finalmente su dirección dentro de éste. Hoy voy a profundizar en la comunicación; me vais a permitir hacerlo de forma sintética, bottom up. Así, un telegrama serie típico podría ser el siguiente, que da orden de activar un elemento (una bombilla, por ejemplo):
10111100 00000000 00000001 00000000 00000010 00010001 000000 0010000001 00111111
Vamos a analizar su significado:

  • Primer byte (10111100), de control. Formado por los siguientes bits:
    • 10 – Obligatorios, salvo para ciertos telegramas breves de reconocimiento que en su momento comentaremos.
    • 1 – Indica que no es un telegrama repetido; esto es, es la primera vez que se envía.
    • 1 – También obligatorio.
    • 11 – El mensaje es de tipo normal (no se trata de una alarma ni un mensaje de sistema) y tiene prioridad baja.
    • 00 – Bits obligatorios.
  • Bytes dos y tres (00000000 00000001), dirección del remitente, de acuerdo a lo que se comentó en la entrada previa, en la que hablamos de la arquitectura de KNX.
  • Bytes cuatro y cinco (00000000 00000010), dirección del destinatario, de acuerdo al mismo critero.
  • Sexto byte (00010001), aquí comienza la información de la capa de transporte, que alcanza hasta el checksum. A esta parte se denomina N_PDU (de Protocol Data Unit; la N se refiere a Network).
    • 0 – El receptor es individual, en oposición a los mensajes de grupo.
    • 000 – Contador de enrutamiento. Puesto que vale cero, este mensaje no será enrutado por ningún acoplador de línea, así que no pasará a otro bus.
    • 0001 – Este telegrama va a contener un dato; concretamente, será el estado del actuador. Se hace notar que se cuentan datos, y no bits o bytes, a diferencia de otros protocolos.
  • Siguiente palabra (000000 0010000001): resto del N_PDU, denominado T_PDU, porque contiene información para la capa de transporte:
    • 0 – Se trata de un paquete de datos; la alternativa sería un paquete de control.
    • 0 – Dicho paquete no está numerado; es decir, contiene toda la información que se quiere transmitir. A los paquetes de datos no numerados se los llama UDP (Unnumbered Data Package).
    • 0000 – Número de secuencia. Puesto que el paquete no es numerado, este valor no tiene significado, y queda a cero.
    • El resto de la palabra (0010000001), denominado A_PDU, incluye la información para la capa de aplicación:
      • 0010 – Comando, en este caso escritura de un grupo de objetos.
      • 000001 – Valores que se escriben. Puesto que se ha indicado que sólo enviamos un dato, el único que tiene sentido es el último bit, y los ceros son de relleno. El uno indica que estamos activando el actuador.
  • El último byte es el dígito de control o checksum. En KNX se obtiene haciendo un OR de todos los bytes previos.

La siguiente figura muestra los elementos que hemos comentado.

Telegrama KNX
Telegrama KNX

Hasta aquí el ejemplo. Partiendo del mismo vamos a profundizar en la comunicación.
He dicho que éste era un telegrama típico, y que el primer byte tenía algunos bits fijos. En realidad KNX también contempla mensajes de un solo byte como respuesta. Concretamente son 0xCC (reconomiento positivo), 0x0C (reconocimiento negativo) y 0xC0 (destinatario ocupado). En los dos últimos casos, o si no se ha recibido respuesta, la transmisión debe repetirse (hasta tres veces). Se marca entonces el sexto bit de la trama, que indica dicha repetición. Cuando se ha enviado un mensaje de grupo, todos los destinatarios deben responder simultáneamente. Aquí se hace notar un detalle: el cero se transmite en KNX sobre TP1 energizando la línea (una oscilación de ±5V). Así, si varios equipos responden a un mensaje de grupo, un reconocimiento no positivo sobreescribe los positivos, lo que obliga a la retransmisión. También hay que anotar que tanto la transmisión de mensajes como de respuestas comienza siempre por los bits 00, los menos significativos, un preámbulo difícil de confundir con parásitos.
Volviendo al mensaje tipo, comenté que el tercer y cuarto bit indican la prioridad de éste. Las cuatro posibilidades son las siguientes, de mayor a menor prioridad: funciones de sistema (0x00), alarmas (0x10), normales con prioridad alta (0x01) y baja (0x11). Nuevamente, en caso de colisión prevalece el de mayor prioridad.
El sexto byte es el que inicia el N_DPU. Su bit más significativo nos indica si un mensaje es individual o de grupo. En este segundo caso, el mensaje no apunta a una dirección física, sino a una dirección de grupo, que permite una vía alternativa de relacionar los dispositivos. Cada elemento puede tener una o varias direcciones de este tipo, que además puede ser compartida. Aunque formalmente una dirección de grupo apenas se diferencia de una individual, aporta mayor versatilidad a las comunicaciones. Por ejemplo, permite que un varios interruptores gobiernen varias luminarias con una única instrucción de conmutación. Una dirección de grupo está compuesta por 15 bits (no incluye el más significativo), y se puede subdividir en grupo principal y subgrupo, o bien en principal, medio y subgrupo:
Dirección de grupo
El uso de direcciones de grupo afecta entre otras cosas a los enrutadores o acopladores de línea, que deben de mantener una tabla de filtrado para determinar qué telegramas deben retransmitir. El funcionamiento de estos dispositivos es diferente en cambio cuando trabajan con direcciones individuales. En dicho caso, la gestión es muy sencilla (máxime teniendo en cuenta que KNX no permite lazos en su instalación física), y tan sólo tienen que tener en cuenta el contador de enrutamiento incluido en el telegrama. El funcionamiento de este número es como sigue: a cada dispositivo se le asocia un valor que va a dar cuenta del alcance de sus mensajes. Cuando vale 0, sus telegramas no van a ser retransmitidos por ningún acoplador, y se quedarán en su propio bus. Si vale 7, serán siempre retransmitidos; esta posibilidad se restringe al software de programación (ETS, Engineering Tool Software). Los valores intermedios dan cuenta del número de enrutadores que los mensajes pueden saltar. Esto es así, porque cuando un acoplador lo retransmite, reduce su valor en una unidad.
Esta entrada continúa en KNX (3).

Novedades 20151021

publicado en: Energía, PLC, SCADA | 0

Schneider Electric agrupó parte de la formación gratuita que ofrece bajo un centro online que ha dado en llamar la Energy University. Es posible acreditarse de dos de ellos (esto ya no es gratuito): el de Data Center Associate y el de Professional Energy Manager. He estado echándole un vistazo al segundo. Lo componen cerca de un centenar de unidades, que tardan en completarse aproximadamente una hora cada una. Se extiende en domótica, sistemas de aire comprimido, HVAC, ilumación, motores, vapor, etc. Y por supuesto, en medidas de energía y eficiencia.
He tenido que migrar varias veces HMI, por diversas razones (obsolescencia, integración, rediseño, ampliación de funcionalidad, e incluso estética). En general son procesos sencillos, pero costosos. ¡A veces más que el desarrollo original, por carecer de documentación! Por esta razón, a los siguientes consejos de Fabio Terezinho, añadiría otro: aportar valor a la nueva aplicación que justifique estos costes aparentemente elevados.
Matthew Wells hacía recientemente una serie de reflexiones sobre la modernización de los SCADA, o HMI en general. El artículo habla de cómo afrontar la obsolescencia, de las nuevas tecnologías, la conveniencia de adoptar estándares, Industrial Ethernet, o los beneficios de afrontar el cambio. En último término, ofrece unos consejos a la hora de elegir un nuevo sistema.
Control Design está publicando fragmentos de una entrevista a Dick Morley, el que es considerado por muchos el inventor del PLC. Os invito a ver tres de ellos, en los que relata el nacimiento de los controladores industriales y las diferencias entre éstos y los PC o las PAC.
http://www.controldesign.com/articles/2015/the-father-of-the-plc-explains-its-birth/
http://www.controlglobal.com/industrynews/2015/plc-creator-explains-the-difference-between-pc-based-control-and-plcs/?utm_content=21432800
http://www.controlglobal.com/industrynews/2015/plc-creator-explains-the-difference-between-plcs-and-pacs/?utm_content=21432825

1 3 4 5 6 7 8 9 12