El modelo de objetos y propiedades de BACnet
Todo lo que hace BACnet descansa en una idea: un dispositivo expone sus datos como una colección de objetos, y cada objeto lleva un conjunto definido de propiedades. Si usted está integrando un controlador de edificio a un sistema supervisorio, o mapeando puntos de HVAC a un historiador, entender el modelo de objetos y propiedades es lo que le permite leer un dispositivo que nunca ha visto. Esta referencia explica qué es un objeto, qué es una propiedad, qué propiedades debe tener todo objeto y por qué esta estructura hace a BACnet autodescriptivo de una forma que un protocolo de registros pelados no es.
Modelo de objetos y propiedades BACnet en una línea: En BACnet, un dispositivo se modela como un conjunto de objetos estandarizados - como Analog Input, Binary Output o Schedule - y cada objeto es un paquete de propiedades con nombre como Present_Value, Object_Name y Status_Flags. El tipo de objeto le dice al cliente qué representan los datos, y sus propiedades guardan el valor, las unidades y el estado. Como todo objeto de un tipo dado lleva las mismas propiedades requeridas, un cliente puede leer cualquier dispositivo conforme sin un mapa de datos del fabricante.
Qué representa un objeto
Un objeto BACnet es la representación en software de una cosa que el dispositivo mide, controla o gestiona. La entrada de un sensor de temperatura se vuelve un objeto Analog Input; una compuerta controlable se vuelve un Analog Output o un Binary Output; el total acumulado de un medidor se vuelve un Accumulator. El estándar define un catálogo de tipos de objeto, y cada tipo tiene un significado acordado, así que un cliente que encuentra un objeto Analog Value en el controlador de un fabricante y en el de otro puede tratar a ambos igual. Ese es el corazón de la interoperabilidad de BACnet, y es un contraste deliberado con un protocolo como Modbus, donde un número de registro no lleva ningún significado incorporado.
Los objetos no se limitan a puntos físicos. Junto a las entradas y salidas hay objetos para las estructuras de datos que el controlador gestiona internamente: un objeto Schedule que enciende y apaga puntos por hora del día, un objeto Calendar que lista fechas especiales, un objeto Trend Log que registra la historia de un punto, un objeto Notification Class que enruta alarmas. Tratarlos como objetos, con la misma mecánica de lectura y escritura que un valor de sensor, es lo que permite a un cliente supervisorio configurar de forma remota la programación horaria o el alarmado de un controlador sin una herramienta propietaria. Cada uno de esos tipos de objeto tiene su propia referencia dedicada en este grupo de páginas.
Cada objeto de un dispositivo se direcciona por un Object_Identifier, que combina el tipo de objeto y un número de instancia - Analog Input 3, Binary Output 12. Ese identificador es cómo un cliente nombra el objeto que quiere leer o escribir. La mitad del tipo le dice al cliente cómo interpretar el objeto; la mitad de la instancia lo distingue de todos los demás objetos del mismo tipo en el mismo dispositivo. El identificador y el modelo de propiedades juntos significan que un cliente puede localizar e interpretar cualquier punto de un dispositivo recién descubierto.
Qué es una propiedad y cuáles son requeridas
Una propiedad es un atributo con nombre y tipo de un objeto. La propiedad Present_Value guarda el valor actual del objeto: la temperatura medida, la salida comandada, el estado de marcha. Object_Name guarda una etiqueta legible por humanos. Units guarda la unidad de ingeniería de un valor analógico. Status_Flags guarda los cuatro bits de falla y alarma que le dicen al cliente si el valor es confiable. Cada propiedad tiene un tipo de dato definido y un significado definido, así que un cliente que lee Units en cualquier Analog Input sabe que recibirá una unidad de ingeniería enumerada, no una cadena libre.
El estándar marca cada propiedad de cada tipo de objeto como requerida, opcional o escribible. Las propiedades requeridas deben existir en todo objeto de ese tipo, lo que garantiza que un cliente puede confiar en encontrar Present_Value, Object_Name, Object_Type y Status_Flags en cualquier objeto de entrada o de valor. Las opcionales pueden estar o no, según el dispositivo y qué tan rico lo hizo el fabricante. Las escribibles son las que un cliente puede cambiar: el Present_Value de un objeto de salida, las entradas de horario de un objeto Schedule. Leer la Property_List del dispositivo, donde se soporta, le dice al cliente exactamente qué propiedades lleva realmente un objeto dado.
Como el conjunto de propiedades requeridas está fijo por tipo de objeto, la integración se vuelve un ejercicio de explorar y mapear, no de descifrar. Un cliente recorre la lista de objetos del dispositivo, lee Object_Name y Present_Value de cada objeto, y ya tiene una lista de puntos funcional. Por eso subir puntos BACnet a una base de tags o a una estructura de tags de SCADA suele ser más directo que mapear un dispositivo basado en registros, donde el mismo trabajo requiere un mapa de registros suministrado por fuera para darles significado a los números.
Cómo el modelo da forma a la integración y el monitoreo
Cuando un sistema supervisorio o un gateway lee un controlador BACnet, en realidad está leyendo propiedades de objetos. Un sondeo por la temperatura de un cuarto es una petición de la propiedad Present_Value de un objeto Analog Input específico; un comando a una compuerta es una escritura al Present_Value de un objeto Analog Output a una prioridad elegida. Entender que toda interacción es un acceso a una propiedad de un objeto con nombre es lo que hace que el resto de BACnet - los servicios que hacen la lectura y la escritura, descritos en la referencia del servicio ReadProperty - caiga en su lugar.
La naturaleza autodescriptiva del modelo también da forma a cómo debe confiarse en un valor. Un Present_Value nunca viaja solo en una integración bien diseñada: sus propiedades Status_Flags y Reliability dicen si el valor es válido en este momento, si está en falla o en alarma. Un cliente que mapea solo Present_Value e ignora las propiedades de estado registrará feliz un número obsoleto o en falla como si fuera bueno. Leer el estado junto al valor es un poco de trabajo extra que convierte un número crudo en uno confiable, y eso importa tanto para un punto de HVAC de una instalación como para una medición de proceso.
Para el monitoreo unificado, el modelo de objetos es lo que permite que los datos de instalaciones convivan de forma natural con la telemetría de proceso. Un SCADA de nube como Merobix que explora los objetos de un dispositivo BACnet puede mapear cada Present_Value a un tag, llevar sus unidades y su estado, y graficarlo en el mismo historiador que todo lo demás. El mapeo de puntos es durable porque los identificadores de objeto son estables en el dispositivo, así que una vez mapeados los objetos la integración no depende de redescubrirlos - el mismo principio que cubre la guía de descubrimiento BACnet.
Preguntas frecuentes
¿Cuál es la diferencia entre un objeto y una propiedad en BACnet?
Un objeto representa una cosa que el dispositivo mide, controla o gestiona: una entrada, una salida, un horario, una fuente de alarmas. Una propiedad es un atributo con nombre y tipo de ese objeto, como Present_Value para su valor actual, Object_Name para su etiqueta o Status_Flags para su validez. Un dispositivo es una colección de objetos, y cada objeto es una colección de propiedades. Un cliente lee o escribe datos nombrando un objeto y una de sus propiedades.
¿Qué propiedades tiene todo objeto BACnet?
Todo objeto lleva al menos Object_Identifier, Object_Name y Object_Type como propiedades requeridas, así que un cliente siempre puede identificarlo y nombrarlo. Los objetos con valor, como entradas, salidas y objetos de valor, requieren además Present_Value y Status_Flags. Más allá de eso, el conjunto de propiedades requeridas depende del tipo de objeto, y las requeridas de cada tipo están fijadas por el estándar, que es lo que permite a un cliente interpretar un objeto que nunca ha visto.
¿Por qué se dice que el modelo de objetos BACnet es autodescriptivo?
Porque el tipo y el significado de cada valor viajan con los datos en lugar de vivir en un mapa externo. Un objeto Analog Input anuncia que es una medición analógica, lleva sus propias unidades de ingeniería y reporta su propia validez mediante Status_Flags. Un cliente puede explorar un dispositivo, leer el nombre y el valor de cada objeto y construir una lista de puntos funcional sin un mapa de registros del fabricante, que es la diferencia práctica frente a un protocolo de registros pelados.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- ASHRAE Standard 135 (BACnet) - ASHRAE
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.