Informe técnico: Implementación e integración BACnet en BMS

Resumen ejecutivo del Estandar BACNet

BACnet es un estándar global de comunicaciones para automatización y control de edificios (BAS/BMS), mantenido por el comité SSPC 135 de ASHRAE y adoptado internacionalmente como ISO 16484-5, con el objetivo de habilitar interoperabilidad multi‑fabricante para una amplia gama de aplicaciones (HVAC, iluminación, seguridad, etc.). La implementación “que funciona en laboratorio” y la implementación “que funciona en obra” difieren principalmente por decisiones de ingeniería de red, direccionamiento, control de broadcasts y ciberseguridad.

En proyectos reales, el enfoque más robusto suele ser una arquitectura híbrida: BACnet/IP como backbone (alto ancho de banda e integración con IT) y BACnet MS/TP como bus de campo para dispositivos económicos y abundantes (VAV, controladores de zona, medidores, etc.). La decisión clave de diseño es cómo “contener” y “transportar” correctamente los mecanismos de descubrimiento y broadcast (Who‑Is/I‑Am) cuando el sistema crece más allá de una subred IP o se segmenta en VLANs. En BACnet/IP tradicional esto se resuelve con BBMD/Foreign Device Registration; en arquitecturas modernas, BACnet/SC (sobre TLS/WebSockets) permite eliminar la dependencia de broadcast y añade autenticación y cifrado a nivel de enlace.

Para integrar dispositivos de forma práctica, se recomienda un flujo repetible: (1) planificar direccionamiento y numeración (Device Instance, Network Numbers, MAC MS/TP); (2) validar físicamente MS/TP (topología lineal, terminaciones, bias) y lógicamente BACnet/IP (puertos UDP, subred, broadcast domain); (3) ejecutar descubrimiento Who‑Is/I‑Am, leer el Device Object y su Object_List, y luego mapear objetos/propiedades relevantes mediante ReadProperty/ReadPropertyMultiple; (4) validar comandos (WriteProperty) considerando “command prioritization” mediante Priority_Array/Relinquish_Default; (5) optimizar adquisición mediante COV y validar Alarm/Event (intrínseco o algorítmico).

En seguridad, el mínimo profesional es segmentación por zonas (VLANs/DMZ), control estricto de flujos por firewall y acceso remoto mediante VPN (evitar exponer BACnet/UDP en Internet). Para entornos que requieren cifrado/autenticación end‑to‑end, BACnet/SC introduce TLS 1.3 y un modelo hub‑and‑spoke con certificados, pero exige una disciplina operativa de gestión de certificados (vigencia, renovación, respuesta ante compromiso) y una arquitectura que evite puntos únicos de falla (hub primario + failover).

Fundamentos de BACnet y arquitectura del protocolo

Estandarización e interoperabilidad

BACnet es un estándar de comunicaciones orientado a automatización de edificios, mantenido por ASHRAE (Standard 135) y adoptado como ISO 16484-5; su estándar “companion” de ensayos de conformidad es ASHRAE 135.1 (adoptado también como ISO 16484-6). El foco del estándar es definir un lenguaje y servicios comunes (modelo de datos + servicios), de manera que dispositivos de distintos fabricantes puedan interoperar dentro de un mismo “internetwork” BACnet.

En proyectos de integración, la interoperabilidad práctica se apoya en tres artefactos:

• PICS (Protocol Implementation Conformance Statement): documento del fabricante que declara servicios, objetos, propiedades, opciones de enlace, etc. (qué “habla” el dispositivo).
• BIBBs (BACnet Interoperability Building Blocks): “bloques” funcionales normalizados (p.ej., DS‑RP‑B para ReadProperty ejecutado) que ayudan a comparar capacidades y diseñar compatibilidad.
• BTL Mark y BTL Listing: certificación y base de productos ensayados que brindan evidencia independiente de conformidad con el conjunto de pruebas.

Modelo BACnet: dispositivos, objetos, propiedades y servicios

BACnet representa toda la información como objetos con propiedades accesibles por servicios. Un punto crucial para integración es que todo dispositivo BACnet debe exponer un Device Object, cuyas propiedades describen capacidades (servicios soportados, tipos de objetos soportados, tamaño máximo de APDU, etc.) y contienen el Object_List, que enumera los objetos presentes en el dispositivo.

Para ingeniería e integración, tres ideas del modelo son especialmente operativas:

• Identidad del dispositivo: el Instance del Device Object debe ser único en todo el internetwork BACnet, porque se usa como identificador global del dispositivo.
• Descubrimiento por broadcast controlado: Who‑Is/I‑Am y Who‑Has/I‑Have permiten “encontrar” dispositivos y objetos sin pre‑cargar tablas de direcciones, reduciendo configuración manual cuando la red está bien diseñada (o incrementándola si broadcasts no se enrutan).
• Servicios mínimos vs. servicios “de proyecto”: ReadProperty es el único servicio que (en introducciones clásicas del estándar) se considera imprescindible en todo dispositivo; el resto depende del perfil/conformance y del caso de uso (alarmas, tendencias, scheduling, etc.).

Arquitectura por capas y encapsulación (visión de integrador)

A nivel práctico, conviene pensar BACnet como:

• Capa de aplicación: servicios (Who‑Is, ReadProperty, SubscribeCOV, EventNotification, etc.).
• Capa de red: ruteo BACnet entre “redes” identificadas por Network Number (MS/TP, IP, Ethernet, etc.).
• Capa de enlace (data link): define cómo se transportan NPDUs sobre un medio concreto. Para BACnet/IP existe una “capa virtual” BVLL (BACnet Virtual Link Layer) introducida en Annex J, y para BACnet/SC existe un enlace seguro basado en WebSockets sobre TLS.

Esta separación es vital para depuración: muchos problemas que se perciben como “BACnet no descubre” en realidad son problemas de capa de enlace (broadcast domain/BVLL/BBMD) o capa física (RS‑485).

Diseño de red: BACnet MS/TP y BACnet/IP

Comparativa técnica MS/TP vs BACnet/IP

La topología en bus MS/TP y su restricción a cableado lineal están enfatizadas en guías de instalación y operación (lineal/daisy‑chain como “única topología permitida” en implementaciones típicas). Para BACnet/IP, el estándar define el uso de BVLL y especifica que los broadcasts IP locales no son reenviados por routers IP convencionales; en redes con dos o más subredes IP se requiere BBMD.

Diseño de BACnet MS/TP en campo

Reglas de cableado (lo que más “rompe” proyectos)

En MS/TP, la ingeniería física determina la estabilidad:

• Topología: especificar e instalar un bus lineal que pase por cada nodo sin derivaciones; las configuraciones en estrella o anillos generan reflexiones y fallas intermitentes.
• Terminaciones y bias (fail‑safe): en los extremos del bus se emplean terminaciones (típicamente 120 Ω) y es necesario biasing del bus; muchas guías operativas señalan que el bias puede depender de terminaciones integradas en controladores, y que la ausencia de bias/terminación adecuada produce comportamientos erráticos.
• Polarisación A/B: distintos fabricantes rotulan de forma diferente (A/B, +/‑, RxD+/RxD‑, etc.); documentar y validar polaridad evita “redes vivas pero mudas”.

Capacidad, baud rate y latencia de token‑passing

Aunque el espacio de direcciones permite hasta 255 MACs, en la práctica la capacidad se restringe por carga eléctrica y tiempo de token‑passing. Una guía de ingeniería de entity"company","Distech Controls","building controls vendor", por ejemplo, explicita que a 9600 baud el máximo práctico puede reducirse fuertemente por congestión de token‑passing y recomienda 38 400 baud; también propone límites prácticos (p.ej., “~50 dispositivos” bajo ciertas condiciones de carga) y detalla cómo el “device loading” (1/8‑load, 1/2‑load, full‑load) fija el límite real.

En cuanto a parámetros MS/TP:

• Max Master: define el MAC máximo considerado en el ciclo de búsqueda de masters; configurarlo muy alto provoca pérdida de tiempo “preguntando” por MACs inexistentes.
• Max Info Frames: limita cuántos frames puede enviar un master por token; valores excesivos pueden monopolizar el bus, y valores muy bajos pueden penalizar throughput desde routers.

Recomendación de diseño MS/TP (práctica)

1. Defina “troncales” MS/TP por piso/ala/área y evite mezclar demasiados equipos críticos y no‑críticos en un mismo bus (para aislar fallas y simplificar puesta en marcha). Este principio está alineado con prácticas de particionamiento por disponibilidad/performance que se aplican también en redes OT/ICS.
2. Use 38 400 baud como punto de partida salvo que un dispositivo obligue a bajar; documente qué equipos “imponen” baud rate.
3. Asigne MACs secuenciales, minimice huecos y ajuste Max Master al último master real (cuando el ecosistema de equipos lo permita).
4. Planifique repetidores solo si hay razones claras (distancia/segmentación); varias guías advierten límites de repetidores y restricciones asociadas a bias/terminación.

Diseño de BACnet/IP en backbone

Transporte y puertos

BACnet/IP encapsula NPDUs en BVLL y los transporta típicamente sobre UDP. El puerto por defecto ampliamente interoperable es 47808 (0xBAC0), y muchas implementaciones recomiendan no cambiarlo salvo necesidad específica (p.ej., coexistencia de dominios, políticas IT o escenarios multi‑red).

Broadcast y el punto de quiebre “1 subred vs muchas”

El estándar define que en una sola subred IP, un broadcast BACnet/IP puede enviarse como Original‑Broadcast‑NPDU usando la dirección de broadcast de la subred. Sin embargo, los routers IP estándar no reenvían este tipo de broadcast; si la red BACnet/IP abarca dos o más subredes IP, se requiere un dispositivo auxiliar: el BACnet/IP Broadcast Management Device (BBMD).

El mismo estándar describe dos enfoques de distribución de broadcast (p.ej., utilizando “directed broadcasts” cuando la infraestructura lo soporta o métodos alternativos cuando no). En la práctica, esto se traduce en: “si hay routing IP entre subredes, el descubrimiento BACnet/IP no funcionará sin BBMD (o sin BACnet/SC)”.

Routers BACnet e internetwork

Para conectar MS/TP con IP se usan routers BACnet (operan a nivel de red BACnet). Esto introduce el concepto operativo de Network Numbers: cada “red BACnet” (MS/TP, BACnet/IP, BACnet/Ethernet) debe tener un número único (típicamente 1–65534; 0 y 65535 reservados en documentación de routers).

Planificación de direccionamiento y numeración (Device Instance, Network Numbers, MAC)

Un plan riguroso de direcciones evita fallas difíciles de diagnosticar (colisiones, rutas inestables, descubrimientos parciales). Reglas base respaldadas por documentación de implementación:

• Network Number (NN): en entornos con routers, asignar un NN único por cada red BACnet; varios manuales de routers y drivers remarcan el rango 1–65534 y reservados 0/65535.
• Device Instance (Device Object Instance): debe ser único en todo el internetwork; su rango operativo citado en documentación de drivers suele ser 0–4 194 303 (22 bits de instancia).
• MAC MS/TP: prácticas comunes asignan MACs bajos y consecutivos; algunos manuales recomiendan explícitamente evitar huecos y ubicar el router en MAC bajo.
• IP + UDP port: mantener 47808/0xBAC0 como base mejora interoperabilidad; si se cambia, debe documentarse en todo el ecosistema (BMS, routers, BBMDs, herramientas).

Una práctica útil para proyectos medianos/grandes es definir “bloques” por edificio/piso/sistema (p.ej., NN por segmento físico; Device Instance por edificio‑disciplina‑equipo), con un registro maestro (planilla) que se convierte en artefacto contractual y de puesta en marcha.

Descubrimiento de dispositivos y procedimientos de ingeniería

Servicios de descubrimiento: Who‑Is/I‑Am y Who‑Has/I‑Have

En BACnet, el descubrimiento típico se basa en dos pares de servicios:

• Who‑Is / I‑Am: permiten obtener direcciones de dispositivos (y su Device Instance). En descripciones clásicas, Who‑Is se emite como broadcast especificando un Device Instance o un rango; los dispositivos que coinciden difunden I‑Am incluyendo su información de direccionamiento.
• Who‑Has / I‑Have: apuntan a descubrir dispositivos que contengan un objeto específico, ya sea por Object Identifier o por Object_Name (útil cuando el BMS integra por nombres normalizados).

En BACnet/IP, la eficacia del Who‑Is depende del dominio de broadcast de la subred; si existen múltiples subredes IP, Who‑Is no “viaja” por routing estándar y se requiere BBMD/FD o BACnet/SC.

Procedimiento recomendado de descubrimiento e inventario (paso a paso)

Un procedimiento robusto, repetible y auditable para obra:

1. Confirmar el dominio de broadcast y el camino L2/L3
   • En IP: verificar subred, máscara, puerto UDP, y si hay routing entre VLANs.
   • En multi‑subred: confirmar si se usará BBMD/FD o BACnet/SC.
2. Descubrimiento de dispositivos (Who‑Is / I‑Am)
   • Ejecutar Who‑Is por rangos acotados (si hay plan de Device Instances) para reducir tormentas de broadcast. La literatura del propio modelo BACnet enfatiza el uso de rangos.
3. Asegurar unicidad de Device Instance
   • Colisiones de Device Instance generan síntomas “fantasma” (duplicados que aparecen/desaparecen). La documentación del modelo BACnet subraya que el Instance del Device Object debe ser único en el internetwork.
4. Leer el Device Object del dispositivo descubierto
   Como mínimo: Object_Name, Vendor_Identifier, Protocol_Services_Supported, Protocol_Object_Types_Supported, Object_List, Max_APDU_Length_Supported y Segmentation_Supported.
5. Inventario de objetos (“point list real”)
   • Usar Object_List para enumerar objetos y luego leer propiedades relevantes para cada tipo (Present_Value, Units, Status_Flags, Reliability, Out_Of_Service, etc.).
6. Prueba rápida de lectura y escritura (si aplica)
   • Lectura: ReadProperty/ReadPropertyMultiple.
   • Escritura: WriteProperty a setpoints o salidas, controlando prioridad y “relinquish”.

Herramientas y prácticas de campo

• Exploradores BACnet / drivers con discovery automático: muchos drivers industriales implementan discovery explícitamente con Who‑Is/I‑Am y ofrecen modos “manual” cuando broadcasts son indeseables o no funcionan.
• Analizadores de tráfico: Wireshark decodifica BACnet/IP y documenta el puerto UDP por defecto, facilitando diagnóstico de “¿hay tráfico?” vs “¿hay respuesta?”.
• Registro de evidencias: capturas de tráfico (pcap), export de listas (CSV), y snapshots de configuración (routers/BBMD) se convierten en entregables de commissioning.

Ejemplos de “frames” y servicios (orientativos)

Los siguientes ejemplos son ilustrativos para entender encapsulación y campos clave; no pretenden ser un volcado binario completo.

Who‑Is en BACnet/IP (broadcast local)

UDP dst port: 47808 (0xBAC0)

BVLL:
  BVLC Type     = 0x81
  BVLC Function = 0x0B  (Original-Broadcast-NPDU)
  BVLC Length   = ...

NPDU:
  Version = 0x01
  Control = ... (con/sin info de ruteo según el caso)

APDU (Unconfirmed Request):
  Service Choice = Who-Is
  Device Instance Range (opcional): low_limit .. high_limit

El uso de Original‑Broadcast‑NPDU y la definición de sus campos (BVLC Type/Function/Length + NPDU) están especificados en Annex J.

I‑Am (respuesta típica a Who‑Is)

APDU (Unconfirmed Request):
  Service Choice = I-Am
  Device Instance = <Device Object Instance>
  Max APDU Length Accepted = <n>
  Segmentation Supported = <none / transmit / receive / both>
  Vendor ID = <vendor_identifier>

El comportamiento “Who‑Is broadcast → I‑Am broadcast” y su finalidad de auto‑configuración de direcciones se describe en documentación de arquitectura BACnet.

Nota específica MS/TP: “slaves” y proxy

Un aspecto poco recordado: un nodo MS/TP “slave” no participa en token‑passing y puede no responder por sí mismo a Who‑Is; existe el concepto de “slave proxy” para responder I‑Am en nombre de slaves. Esto afecta proyectos donde se mezclan masters/slaves o gateways antiguos.

Integración práctica en BMS: objetos, propiedades y servicios clave

Enfoque de integración: del inventario al “punto operable”

Una integración BACnet útil para operación no es solo “ver valores”, sino:

1. Identificar y normalizar nombres (Object_Name / Device Object Name) evitando duplicados que confundan al operador. Muchos documentos PICS y guías remarcan la necesidad de unicidad de nombres en el contexto del sistema.
2. Mapear el “punto” a un objeto/propiedad (p.ej., Analog Input 3 / Present_Value).
3. Definir el método de adquisición: polling (ReadProperty) vs evento (COV) según criticidad, ancho de banda y latencia requerida.
4. Definir control y arbitraje de comandos usando prioridades BACnet, no “a ojo”.
5. Gestionar alarmas/eventos (intrínsecos o por Event Enrollment) con confirmación/ack según riesgo operacional.

Tabla de servicios comunes y uso típico en BMS

La clasificación de servicios (confirmed vs unconfirmed), la lista de servicios de acceso a objetos (Read/Write Property, múltiples, etc.) y la descripción operativa de Who‑Is/I‑Am y Who‑Has/I‑Have están descritas en guías de arquitectura BACnet. La motivación de ReadPropertyMultiple/WritePropertyMultiple como reducción de overhead también se explicita en esas fuentes.

Escritura robusta: command prioritization (Priority_Array / Relinquish_Default)

Un problema clásico en puesta en marcha: “escribo Present_Value pero el equipo no cambia” o “cambia y vuelve”. BACnet resuelve arbitraje de comandos con un mecanismo de prioridades en objetos “commandable”:

• Un objeto commandable mantiene un Priority_Array (16 slots).
• El valor efectivo toma la prioridad más alta no‑NULL; si todo es NULL aplica Relinquish_Default.
• Interpretaciones del estándar describen que, cuando Priority_Array/Relinquish_Default están presentes, escribir Present_Value queda gobernado por el mecanismo de priorización.

Ejemplo orientativo de WriteProperty con prioridad:

WriteProperty (Confirmed Request)
  Object Identifier: analog-output, 5
  Property Identifier: present-value
  Value: 22.0
  Priority: 8

Recomendación práctica: definir en el proyecto una política de prioridades (por ejemplo: seguridad/vida, operación automática, operador, BMS, commissioning) y exigir que integraciones externas usen niveles acordados; además, documentar el procedimiento de “relinquish” (escribir NULL en la misma prioridad) para devolver control a la lógica local.

COV: reducir polling sin perder confiabilidad operativa

COV convierte al servidor en “activo”: el cliente se suscribe mediante SubscribeCOV y recibe notificaciones de cambios por COVNotification, confirmadas o no confirmadas. Esto reduce tráfico y carga, pero introduce consideraciones de operación:

• Confirmed COV requiere ACK (más robusto, más overhead); Unconfirmed COV no requiere confirmación.
• Algunos entornos usan COV de forma selectiva (solo puntos de alto valor: alarmas, estados, setpoints) y polling para el resto, buscando equilibrio entre latencia y simplicidad.

Alarmas y eventos: intrínseco vs algorítmico (Event Enrollment)

BACnet soporta alarmas/eventos mediante dos estilos:

• Intrínseco: el propio objeto (p.ej., Analog Input) detecta condiciones (límites, estados) y genera notificaciones.
• Algorítmico (Event Enrollment): un objeto Event Enrollment monitorea una propiedad (local o incluso remota) y genera eventos según condiciones definidas; literatura de BACnet describe la evolución y equivalencia de algoritmos entre intrínseco y algorítmico.

En el diseño de integración, es fundamental validar:

• Notification Class / recipient list / prioridades / Ack_Required (qué transiciones requieren reconocimiento).
• Si el BMS usará ConfirmedEventNotification o UnconfirmedEventNotification según criticidad y confiabilidad requerida.

BBMD, Foreign Devices y BACnet/SC: alcance, configuración y límites

BBMD en BACnet/IP: cuándo se necesita

Cuando BACnet/IP abarca más de una subred IP, los broadcasts necesarios para descubrimiento y ciertos servicios no cruzan routers IP. Annex J define la necesidad de un dispositivo auxiliar (BBMD) y describe su concepto: interceptar broadcasts y reenviarlos como mensajes dirigidos hacia BBMDs “pares”.

En términos operativos:

• Un solo IP subnet: normalmente no se requiere BBMD.
• Múltiples subnets/VLANs con routing: se requiere BBMD o una alternativa (BACnet/SC).

Conceptos de configuración: BDT, FDT y NAT

BDT (Broadcast Distribution Table)

El estándar define que cada BBMD mantiene una BDT con sus peers BBMD. En implementaciones, además, se advierte sobre loops de reenvío si múltiples BBMDs en una misma subred comparten entradas en BDT.

FDT (Foreign Device Table) y FDR (Foreign Device Registration)

Algunas arquitecturas (p.ej., aplicaciones remotas, herramientas de commissioning o subredes donde no se desea un BBMD local) usan Foreign Device Registration: el dispositivo “foreign” se registra en un BBMD que mantiene una FDT con entradas temporales.

El estándar (y addenda) especifican el manejo de Time‑to‑Live y el comportamiento de timer: el BBMD inicia un temporizador TTL + un “grace period” (p.ej., 30 s) y borra la entrada si no hay re‑registro; el foreign device debe re‑registrarse antes de expirar su TTL.

NAT y puertos

En entornos con NAT, documentación de BBMDs y addenda destacan que ciertas tramas (Forwarded‑NPDU) deben contener la dirección accesible (externa) cuando NAT está en juego. En la práctica, esto implica:

• Definir correctamente “public IP”/“global IP” usado en la BDT.
• Cuidar el puerto UDP; 47808/0xBAC0 es el default interoperable.

Tabla de configuración BBMD/Foreign Device (plantilla de ingeniería)

Los conceptos de BBMD/BDT/FDT y el hecho de que los routers IP no reenvían broadcast están definidos en Annex J y documentos explicativos del comité. Los detalles de TTL y timers de FDT están definidos en addenda del estándar.

Snippets orientativos de configuración (no específicos de un fabricante)

BDT (ejemplo conceptual)

BBMD Enable: true
BACnet UDP Port: 47808

BDT entries:
  - local_bbmd:   10.10.10.10:47808  mask 255.255.255.255
  - bbmd_site_b:  10.20.10.10:47808  mask 255.255.255.255
  - bbmd_site_c:  10.30.10.10:47808  mask 255.255.255.255

Foreign Device Registration (concepto)

Register-Foreign-Device to BBMD 10.10.10.10:47808
  Time-To-Live: 600 s
(re-register before TTL expires)

Seguridad y operación de BBMD/FDR

Un punto recurrente: “hacer que funcione” con port forwarding y reglas laxas es técnicamente posible, pero introduce riesgos significativos. Documentos de mejores prácticas para acceso remoto a sistemas BACnet resaltan el uso de firewalls y VPNs como mecanismos más seguros y advierten sobre diferencias de seguridad y facilidad entre enfoques.

BACnet/SC: cuándo preferirlo y qué cambia

BACnet/SC es una opción moderna de enlace que usa WebSockets sobre TLS para autenticación entre pares, cifrado de mensajes y comunicación orientada a conexión; puede operar sobre IPv4 o IPv6. Su topología lógica típica es hub‑and‑spoke, con soporte de failover hub para resiliencia.

Ventajas prácticas frente a BACnet/IP + BBMD:

• Reduce/elimina dependencia de broadcast para descubrimiento (y por ende simplifica operación en redes segmentadas).
• Introduce autenticación y cifrado (TLS); guías de BACnet/SC especifican requisitos mínimos como TLS 1.3.
• Integra mejor con NAT/DHCP/DNS en comparación con mecanismos clásicos de broadcast.

Tradeoffs y exigencias:

• Requiere gestión de certificados (emisión, distribución, renovación). Guías de implementación señalan además que BACnet/SC no define un mecanismo interoperable de revocación, quedando como “local matter”, lo que impacta la respuesta ante compromiso.
• Introduce un componente crítico (hub), por lo que se recomienda failover para evitar punto único de falla.

Seguridad, pruebas y puesta en marcha

Seguridad: de “red aislada” a “OT gestionada”

En edificios modernos, “seguridad por aislamiento físico” ya no es suficiente; la práctica recomendada en OT/ICS es segmentar en dominios/zones, controlar flujos en los límites y aplicar defensa en profundidad.

Un marco técnico aplicable a BAS/BMS:

• Segmentación por zonas (VLANs / enclaves): reduce superficie de ataque y también evita interferencia de tráfico IT sobre BAS (performance).
• Firewalls y DMZ: NIST describe patrones donde los componentes “compartidos” (historians, acceso remoto, soporte tercero) se colocan en DMZ para evitar caminos directos entre red corporativa y red de control.
• Acceso remoto: usar VPNs y controles de acceso; evitar port forwarding directo a BACnet/UDP.

Cuando BACnet/SC está disponible, aporta una capa adicional (cifrado/autenticación) pero no reemplaza segmentación y control de flujos: se recomienda como parte de un enfoque defense‑in‑depth.

Pruebas de conformidad e interoperabilidad (qué pedir y cómo validar)

• Revisar PICS/BIBBs antes de integrar: confirma servicios críticos (ReadPropertyMultiple, COV, alarmas, trending) y evita suposiciones.
• Preferir dispositivos con evidencia BTL: el BTL Mark indica pruebas de conformidad por una organización reconocida y la BTL Listing permite acceder a detalles (incluyendo PICS).
• Usar ASHRAE 135.1 como referencia de pruebas: 135.1 define métodos para verificar que una implementación soporta lo que declara en su PICS.

Puesta en marcha: estrategia de validación (de red a funcional)

Una secuencia de puesta en marcha técnicamente sólida:

1. Validación física MS/TP
   • Topología lineal, terminaciones, bias, polaridad, y verificación de carga/baud rate.
2. Validación de ruteo y numeración
   • Network Numbers únicos por segmento; verificación de routers y ausencia de loops.
3. Validación de broadcast/discovery
   • En subred única: Who‑Is debe ver respuestas I‑Am.
   • En multi‑subred IP: validar BBMD/BDT/FDT o BACnet/SC.
4. Validación de integración de puntos
   • Lecturas confiables (ReadPropertyMultiple si aplica), unidades/estados, estabilidad de valores.
5. Validación de control
   • WriteProperty con prioridades predefinidas; prueba de relinquish; confirmar que la lógica local y BMS arbitran como se diseñó.
6. Validación de COV y alarmas/eventos
   • Confirmed vs unconfirmed según criticidad; validar notificaciones y acknowledgements.
7. Pruebas de resiliencia y operación
   • Reinicios controlados (routers/controladores), expiración de FDT en foreign devices, failover hub en BACnet/SC, y monitoreo de certificados (vigencia).

Arquitecturas de proyecto, checklist por fases y problemas comunes

Arquitecturas de referencia (diagramas mermaid)

Arquitectura típica “edificio pequeño”: IP backbone + MS/TP campo (1 subred IP)

Esta arquitectura se alinea con el uso común de MS/TP como bus de campo para “pequeños dispositivos abundantes” y BACnet/IP para backbone.

Arquitectura “campus / multi‑edificio” con segmentación y DMZ (BACnet/IP + BBMD o SC)

El patrón “corporativo ↔ DMZ ↔ control network” y el rol de firewalls/DMZ en ICS están descritos como mejora significativa frente a redes planas, permitiendo reglas más seguras y evitando caminos directos corporativo→control. La necesidad de BBMD cuando hay múltiples subredes IP para transportar broadcasts BACnet/IP está definida en Annex J.

Arquitectura moderna con BACnet/SC (seguridad y eliminación de broadcast)

BACnet/SC define un enlace basado en WebSockets TLS y una topología lógica hub‑and‑spoke con concepto de failover hub para disponibilidad. Guías de implementación resaltan además la necesidad de segmentación y políticas en puntos de conexión entre segmentos, aun con BACnet/SC.

Checklist por fases (diseño → implementación → pruebas → operación)

Fase de diseño

• Definir qué quedará en BACnet/IP, qué quedará en MS/TP y dónde se ubicarán routers (puntos de segmentación).
• Diseñar MS/TP como bus lineal (sin estrella) e incluir en planos: extremos del bus, estrategia de terminación/bias, y criterios de carga y número de dispositivos por segmento.
• Definir un plan maestro de numeración: Network Numbers, Device Instances, MAC MS/TP, puertos UDP (si no estándar).
• Definir arquitectura de broadcast/discovery:
  • 1 subred IP: sin BBMD (normalmente).
  • múltiples VLANs/subredes: BBMD/FD o BACnet/SC.
• Seguridad: definir zonas, DMZ, reglas de firewall, y acceso remoto por VPN (no por port forwarding a BACnet/UDP).
• Especificación de interoperabilidad: requerir PICS/BIBBs y, de ser posible, evidencia BTL para equipos críticos.

Fase de implementación

• Cableado y verificación MS/TP: continuidad, polaridad, tierra de shield, terminaciones, bias.
• Configurar routers: Network Numbers correctos, MAC del router, Max Master/Max Info Frames coherentes.
• Configurar BACnet/IP: IP/máscara/gateway, puerto UDP, y (si aplica) BBMD/BDT/FDT.
• Registrar inventario real: Device Instance, nombre, ubicación, firmware (si está disponible), y PICS.
• Definir política de prioridades para comandos (Priority_Array) y documentar procedimientos de relinquish.

Fase de pruebas y validación

• Discovery controlado: Who‑Is por rangos y verificación de respuestas I‑Am en cada segmento.
• Validar lectura de Device Object y Object_List.
• Validar punto a punto: lectura estable, unidades/estados correctos, calidad de datos (Reliability/Status_Flags).
• Validar escritura: prioridad correcta, comportamiento esperado, retorno a control local (relinquish).
• Validar COV: suscripciones, confirmaciones (si se usan), comportamiento ante reinicios.
• Validar alarmas/eventos: notificación, recipientes, ack, severidades/prioridades.
• Validar seguridad: reglas de firewall, separación corporativo/control, acceso remoto por VPN y monitoreo.
• Si hay BACnet/SC: validar cadenas de certificados, vigencias, failover hub y requisitos TLS.

Fase de operación

• Monitorear tráfico y límites operativos (latencia MS/TP, saturación, tormentas de broadcast).
• Gestión de cambios: altas/bajas de dispositivos, actualización de tablas BBMD/BDT o nodos SC, control de versiones de firmware.
• Seguridad continua: revisión de reglas, credenciales, segmentación; en BACnet/SC, monitoreo de expiración y cambios inesperados en certificados.
• Mantener actualizado el “as‑built” de direccionamiento (NN, Device Instance, IP, MAC).

Problemas comunes y soluciones (diagnóstico rápido)

Referencias y fuentes

1. ASHRAE — “ASHRAE Standard 135 Resource Files / About the BACnet Standard” (página informativa del estándar y su mantenimiento).
2. BACnet.org — “About the BACnet Standard” (historia, estatus ISO, estándar companion 135.1).
3. BACnet.org — “The Language of BACnet: Objects, Properties and Services” (modelo de objetos/propiedades/servicios, Device Object, Who‑Is/I‑Am, etc.).
4. ASHRAE— Addendum a to ANSI/ASHRAE 135‑1995 (Annex J: BACnet/IP, BVLL, BBMD, Original‑Broadcast‑NPDU, etc.).
5. ASHRAE — Addendum m to ANSI/ASHRAE 135‑2004 (FDT TTL, timers, re‑registro de Foreign Devices).
6. ASHRAE — Addendum bj to ANSI/ASHRAE 135‑2016 (BACnet/SC: WebSockets TLS, hub‑and‑spoke, failover).
7. BACnet International — Página técnica BACnet/SC (definición, WebSockets + TLS).
8. BACnet Testing Laboratories — BTL Mark y BTL Listing (certificación, base de productos ensayados).
9. Distech Controls — “Network Guide” (MS/TP: límites prácticos, device loading, baud rate recomendado, terminaciones/bias, topología).
10. Schneider Electric — Manual de router multi‑red (Network Numbers, MS/TP MAC/MaxMaster, BBMD enable, puerto BACnet/IP).
11. Contemporary Controls — “What is BBMD and Why Should I Care?” (explicación BBMD/FDR y consideraciones de firewall).
12. Contemporary Controls — Whitepaper “Deploying and Maintaining BACnet Systems in Today’s Networks” (tradeoffs MS/TP vs Ethernet/IP y mejores prácticas).
13. Contemporary Controls — “BACnet Introduction” (prioridades, Priority_Array, Relinquish_Default, conceptos básicos).
14. National Institute of Standards and Technology — NIST SP 800‑82 Rev. 2 (seguridad ICS: segmentación, firewalls, DMZ, acceso remoto).
15. ASHRAE — “Managed BACnet Guidance” (segmentación en VLAN, firewall guidelines, BACnet/SC, TLS 1.3, gestión de certificados y limitaciones de revocación).
16. Siemens — “Building automation system security with BACnet/SC” (hub/failover, ruteo entre enlaces, motivación de seguridad).