KNX (3) | José Casares

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

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