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).

KNX (1)

publicado en: Domótica, KNX | 1

Uno de los protocolos más extendidos en domótica es el KNX. Aunque como tal su estándar se publicó en 2001, hay que hacer notar que ya tenía una década de recorrido bajo el nombre de EIB (European Installation Bus) o Instabus. Su origen hay que buscarlo por tanto hace 25 años, cuando quince compañías europeas, entre ellas Siemens, acordaron unas especificaciones comunes para las instalaciones domóticas. EIB utilizó desde sus inicios un par trenzado (TP1, de Twisted Pair) como medio de transporte. La configuración de los dispositivos se hacía mediante una herramienta independiente, ETS (EIB Tool Software). Con los años se decidió la convergencia con otros dos buses empleados en domótica, a saber: EHS (European Home Systems), que aprovecha las instalaciones eléctricas preexistentes (PLC, power line communication), y BatiBUS. De dicha unificación surgió KNX, si bien el estándar se ha ido ampliando con comunicaciones inalámbricas (KNX RF) y Ethernet (KNX IP). Durante estos años también se normalizó como EN 50090 e ISO/IEC 14543. Su administración está gestionada por la Asociación KNX.

Logo KNX
Logo KNX

KNX cubre los aspectos que se pueden esperar en un sistema domótico: iluminación, HVAC, persianas, control de accesos, audio y vídeo, etc. Por ello tiene que manejar datos con muy distinto significado o función. Al mismo tiempo, se trata de un sistema no propietario, y desde el principio se quiso desligar de cualquier plataforma o arquitectura de procesador, de modo que cada fabricante lo implementa de acuerdo a criterios propios. Y ello debe hacerse de modo que los equipos de distintas marcas puedan interactuar adecuadamente, sin requerir una configuración compleja. Otra característica de KNX es su arquitectura completamente descentralizada. Cada dispositivo habla con sus compañeros, situados incluso en otra subred, sin un maestro que gestione las comunicaciones. Lo que da lugar, como iremos viendo, a colisiones que es necesario salvar. Todas estas cuestiones obligan a una cierta vigilancia de la implementación del estándar, no sólo de las comunicaciones, sino también en cuanto al uso de tipos de datos estandarizados. El etiquetado KNX supone pues una conformidad con estos requerimientos.
Vamos a comenzar describiendo el modelo de KNX en relación con las capas OSI. En la figura inferior pueden observarse las distintas implementaciones de la capa física, que puede utilizar bien un bus de par trenzado (TP1), la red de alimentación eléctrica (PL110), comunicaciones inalámbricas (RF) o una red Ethernet (IP). Independientemente del medio, el enlace se establece mediante el direccionamiento propio de KNX, basado en la topología original de bus que se describirá más adelante. En lo que toca a la capa de aplicación, hay que distinguir el funcionamiento usual, de un sistema ya implantado, de la comunicación con las herramientas de configuración. En el segundo caso, existen varias formas de parametrizar los equipos, que se pueden agrupar en modo sistema y modo fácil. También en este nivel encontraríamos equipos de integración como supervisores, pasarelas, etc.

Modelo KNX
Modelo KNX

Para desgranar los detalles del estándar, voy a centrarme de momento en las especificaciones para par trenzado y relegaremos las variantes (PL100, FR, IP). La razón principal es que de ella, como he comentado, hereda la topología lógica de KNX, y por tanto el direccionamiento de los dispositivos se concibe con esta perspectiva. Una instalación de KNX está formada en general por un bus troncal que enlaza varios buses principales, que a su vez unen mediante acopladores buses secundarios. Un bus secundario podría típicamente cubrir una planta de un edificio, mientras que el primario recorrería la vertical; el bus troncal uniría varios edificios cercanos. Pero insisto, es sólo una posibilidad, y en último término debe entenderse que ésta es la topología lógica y no tiene por qué corresponderse con la física (imaginar por ejemplo una comunicación por radiofrecuencia).
El direccionamiento de cada elemento en esta red se realiza mediante dos bytes, que hacen referencia a un bus y al dispositivo dentro de dicho bus. El primer byte se puede dividir por otra parte en dos mitades: la primera indica el área dentro del dominio (es decir, el bus principal), y la segunda, el bus secundario. Por tanto, una instalación puede tener 16 áreas, cada una de ellas con 16 buses secundarios, y dentro de cada uno de ellos 256 dispositivos, con lo que se pueden direccionar 65536 dispositivos. En realidad habría que aclarar que para el bus troncal se reserva el número 0 (y el término área no sería por tanto adecuado), y lo mismo sucede con los buses principales; es una cuestión de terminología, y no afecta a lo expuesto. Cuando se habla de KNX sobre TP1, hay que hacer notar que por cuestiones de alimentación no se admiten segmentos de bus con más de 64 elementos; el inconveniente se soslaya introduciendo fuentes adicionales.

Topología KNX
Topología KNX

Esta entrada continúa en KNX (2).

Novedades 20151003

Microsiervos publicó recientemente una entrada dedicada a el PLC industrial basado en Arduino de nombre Industruino. El equipo se suma a una interesante serie de controladores similares que engrosa día a día, como el Controllino o los autómatas de Industrial Shields.
Según un estudio de Transparency Market Research, se espera un crecimiento en el mercado de la domótica de nada menos que un 26% anual (CAGR) hasta 2020. Este fuerte avance es debido a la necesidad de eficiencia en aplicaciones de iluminación, seguridad, entretenimiento y HVAC; y aunque el liderzago va de la mano de Estados Unidos y Canadá, regiones como Europa y Asia oriental están asimismo experimentando un fuerte crecimiento.
A estas alturas no hace falta incidir en las ventajas de Ethernet (no solo Industrial Ethernet) en las aplicaciones industriales: integración, estandarización en las capas bajas, etc. Ken Kao, de Advantech, destaca los aspectos que van a verse potenciados gracias a los avances recientes, desde la convergencia con el IoT o las mejoras en fiabilidad y diagnóstico hasta la reducción de precio de los switches gestionados.
Cuando en 2011 orienté mi TFM hacia el uso del lenguaje natural en sistemas de control, tenía claro que la penetración de estas tecnologías en el ámbito industrial iba a resultar costosa, por razones de seguridad, entre otras. La domótica no tiene unas exigencias tan estrictas. El pasado viernes, ABB presentó una versión mejorada de free@home, un sistema para controlar edificios inteligentes mediante comandos de voz. Por los pocos detalles que he visto, debe de utilizar una gramática libre de contexto; en sí, no es novedoso, pero supone un paso adelante en la dirección hacia la que debe evolucionar el sector.
Estos días descubrí Shodan en el siguiente artículo del Instituto Nacional de Ciberseguridad, que habla sobre amenazas en los sistemas de control industrial. Tras describir las consecuencias de un accidente de este tipo y presentar algunos ejemplos (la fuga en Union Carbide en 1985, que propiamente fue un error de programación, los vertidos de Maroochy en el 2000, Stuxnet, Dragonfly…), recoge unas breves buenas prácticas.
El Instituto Nacional de Ciberseguridad también ha publicado una presentación sobre Diagnóstico de Ciberseguridad en Entornos Industriales. En las primeras diapositivas describe en qué consiste una auditoría a este nivel, para después analizar las arquitecturas de red en industria, la detección de amenazas y los mecanismos de seguridad.
Para terminar, un vídeo breve para aclarar la relación entre Internet of Things (IoT), Industrial Internet of Things (IIoT) y la industria 4.0.

Historia de OPC

publicado en: OPC | 0

El estándar OPC (inicialmente OLE for Proccess Control, pero renombrado Open Platform Communications) surgió a mediados de los años 90 como una tecnología para la comunicación del software SCADA y otros HMI con los dispositivos de control en el ámbito de la industria. Consiste en realidad en un conjunto de especificaciones que resuelven diferentes tareas imprescindibles en este ámbito, para lo cual hacen uso de tecnologías estándar del mercado. El principal acicate para su desarrollo fue la superación de las insuficiencias que presentaban los sistemas basados en DDE, en particular su escaso rendimiento y la incompatibilidad de las distintas extensiones que los fabricantes habían introducido para solventarlo.

Arquitectura OPC
Arquitectura OPC

OPC se basaba originalmente en la tecnología OLE/DCOM de Microsoft. Las especificaciones iniciales fueron desarrolladas por la OPC Task Force, una institución promovida por varias de las principales compañías del sector: Fisher-Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell y Siemens AG. En agosto de 1996 se liberó una primera versión de las especificaciones (OPC Specification Version 1.0), basadas en las tecnologías COM (Component Object Model), OLE (Object Linking and Embedding) y DCOM (Distributed Component Model). La primera definía un sistema de comunicación entre procesos y de creación dinámica de objetos de forma neutral; es decir, éstos podían ser utilizados posteriormente en entornos de desarrollos distintos al de creación original. La segunda, OLE, establecía mecanismos de mantenimiento y gestión de datos y archivos de forma que pudiesen tratarse por distintas aplicaciones. La última, DCOM permitía la creación de componentes distribuidos de software en diferentes sistemas intercomunicados.
Uno de sus mayores retos del estándar OPC ha sido adaptarse a un dominio en continuo cambio, para lo que se optó desde sus orígenes por una estrategia que permitiese enriquecerlo de forma constante por medio de adiciones básicas. Esto se vino llevando a cabo inicialmente mediante distintos documentos Data Access Specification, que recogían las incorporaciones a los mecanismos y funcionalidad de lectura y escritura de datos de proceso. Paralelamente, OPC se veía enriquecido por la adición de servicios de interés en el ámbito industrial. A la primera versión del protocolo, que pasó a denominarse OPC DA (Data Access) y establecía cómo debía realizarse el intercambio de datos de tiempo real entre servidores y clientes, se le incorporó en 1999 la posibilidad de gestionar el tráfico de alarmas y eventos entre servidores y clientes, OPC AE (Alarms and Events Specification), y en el año 2000 se le agregó una capacidad semejante de manejo de datos históricos, OPC HDA (Historical Data Access Specification). También en dicho año se definieron e implementaron políticas de seguridad, OPC S (Security Specification). Otras adiciones posteriores fueron las recogidas en la OPC Batch Specification, para la gestión de tareas, la OPC XML-DA Specification para servicios web a través de XML y SOAP, o la OPC DX Specification, que define la comunicación de servidor a servidor sin uso de clientes. La comunicación entre servidores, que requieren mensajes con tipos de datos más complejos, se efectúa gracias a OPC CD (Complex Data). Entre los últimos protocolos incorporados al estándar se encuentra OPC C (Commands), que dota a clientes y servidores de un conjunto de interfaces para indentificar, enviar y moonitorizar comandos de control.
Actualmente, el rápido crecimiento en el número de productos que incorporan OPC, así como sus capacidades, han hecho de éste el estándar industrial con más aceptación. La OPC Foundation es la organización encargada de crear y mantener las especificaciones de forma abierta.
Conforme DCOM fue reemplazándose por la tecnología .NET, que permitía un desarrollo ágil en redes y entornos Web, OPC debió adaptar sus interfaces a dicha plataforma. La última API liberada del OPC clásico, conocida formalmente como OPC Express Interface (Xi), se basa en el modelo .NET 4.0 WCF (Windows Communication Foundation). Provee de una envoltura a las interfaces clásicas, y permite un uso más seguro a través de redes por medio de mecanismos de autentificación, autorización y encriptación de datos. También simplifica el acceso a través de cortafuegos, al requerir sólo la apertura de dos puertos.
Desde el año 2006, la OPC Foundation, en conjunción con el MTConnect Institute, viene trabajando en una versión unificada de los estándares (OPC UA, o Unified Architecture), con miras a avanzar hacia una arquitectura orientada a servicios de tipo multiplataforma. Gracias a esto se elimina la tradicional dependencia de Microsoft Windows de los protocolos de control industrial. OPC UA se beneficia de las características que proporcionan el conjunto de estándares descrito, a las que se une la ventaja de ser portable a otros sistemas operativos. Para ello, OPC abandona definitivamente el modelo DCOM y se constituye en una arquitectura orientada a servicios (SOA, Service Oriented Architecture). Existen interfaces de programación (API) implementadas para C, C++, .NET, Java, NodeJS y Python. Otras ventajas que aporta son la seguridad revisada, el modelo de información, redundancia, buffering de datos o monitorización de los enlaces.

Arquitectura de OPC UA
Arquitectura de OPC UA
1 2 3