Novedades 20151223

publicado en: BACnet, KNX, LonWorks, PID, Schneider, Seguridad | 0

Poco a poco se va difuminando la frontera entre autómatas y controladores domóticos. Esta primavera Schneider presentaba los Modicon M171/172, capaces de hablar BACnet y LonWorks. Hace unos días Siemens presentó el módulo CMK2000, permite a los Logo! 8 comunicarse en KNX (las versiones anteriores usan el CM EIB/KNX).
En 2009 se definió el estándar ANSI/ISA-18.2 para la gestión de alarmas en los sistemas de control. Con miras en la seguridad, que depende de una respuesta urgente ante situaciones de riesgo, y por tanto de la eficacia del sistema de alarmas, se define un ciclo de vida para éste. Comprende su optimización (filosofía o definición del proceso, identificación de alarmas, racionalización o clasificación, diseño en detalle e implementación), soporte (operación y mantenimiento), evaluación y mejora continua (gestión de cambios y auditoría).
He sabido por el blog de Martín Castillo de la aplicación LDmicro, que permite programar PIC en ladder. No he tenido ocasión de probarla, pero parece sencilla, viene acompañada de simulador y, aunque el conjunto de operaciones es bastante limitado, permite algunas funciones de cierto nivel, como manejo de tablas o comunicación vía puerto serie.
Schneider ha publicado guía sobre los protocolos abiertos más usados en inmótica, que incluye tanto exclusivos de este campo (Bacnet, LonWorks, KNX, Dali…) como más generales (Modbus, OPC, Web Services…). Están clasificados en alámbricos e inalámbricos, y aunque su descripción es muy breve, da algunas pistas sobre su idoneidad en función de la aplicación.
Hace una década me cansé de copiar y pegar código, y desarrollé una aplicación que genera el programa (la parte sistemática) a partir de un listado de equipos. Muchos fabricantes han seguido ese camino, por desgracia creando herramientas cerradas a sus productos. Nos lo cuenta Daniel B. Cardinal, que además describe las metodologías de diseño más comunes para el diseño automático de código. De ahí pasa a describir estrategias para aplicar a toda la pirámide de control, a la que idealmente se debería extender esta forma de desarrollo.
Como Vance VanDoren comenta, los lazos PID no son una solución universal y perfecta. Hace poco ha publicado la tercera parte de un artículo que comenzó a escribir ¡en 2012! acerca de sus problemas, y cómo soslayarlos (1, 2 y 3). Acumulación de la acción integral en caso de saturación o no actuación, respuesta abrupta en el arranque, regulación “del ruido”, sobreactuación cuando el proceso conlleva retraso… Yo añadiría que el ajuste se realiza para unas determinadas condiciones de proceso, que con frecuencia no se mantienen invariables; en este caso, una solución es establecer tramos con diferente parametrización.
En las últimas semanas se han publicado varias vulnerabilidades que afectan a equipos extendidos en el ámbito de la automatización. Comento las más importantes:
– Desbordamiento de buffer en productos M340 de Schneider que permite ejecutar código arbitrario o detener el PLC.
– Inyección de código con elevación de privilegios en SCADA PowerStudio (Circutor).
– Múltiples vulnerabilidades en routers eWON (inyección de código que permitiría actualiar firmware, cambiar de configuración, envío de contraseñas inseguro, etc.)
– Evasión de autenticación en dispositivos Siemens (CP343-1, CP443-1…)
– Varias vulnerabilidades en MicroLogix (Allen-Bradley): desbordamiento de buffer que permite ejecución de código, subida de archivos, inyección SQL…
Por último, una postal y una canción para felicitaros las fiestas.

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)

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