Firewalls en Capa 2 en entornos OT

En muchas ocasiones se habla que la primera medida técnica a implementar en lo que a seguridad en entornos industriales se refiere es definir los perímetros entre los entornos IT y OT. Para ello empleamos NGFW capaces no sólo de filtrar tanto por IPs y servicios sino realizar DPI (Deep Packet Inspection) a nivel de capa 7 además de otras funcionalidades como Antivirus, IDS/IPS, Anti DoS. Ya dentro del entorno OT, la recomendación es definir áreas, o zonas, más pequeñas y filtrar el tráfico entre ellas por medio de un segundo Firewall. El de “Segmentación”.

Físico o virtual, en el supuesto de que un error humano o acción malintencionada se produjese en alguna de ellas, evitaríamos la propagación al resto provocando un daño mayor. Además, si el daño es menor, el tiempo que necesitaremos para recuperar el conjunto de equipos afectado será menor, como menor será su número.

En la siguiente imagen podemos ver una configuración en la dicha separación la hacemos por medio de la definición de Firewalls Lógicos dentro de uno físico del fabricante Fortinet.

Esquema de uyso de Firewall Virtuales

El tamaño de estas áreas, zonas o celdas según sea la literatura de referencia, podrá albergar un número mayor o menor de equipos. Una de las opciones es definir una VLAN para cada una de ellas con un único dominio de broadcast y direccionamiento. Esto cubriría aspectos como protocolos industriales que operen en Capa 2 o tráfico multicast como LLDP. De esta manera podremos filtrar cualquier comunicación entre subredes, otras áreas, servidores en IDMZ (Industrial DMZ), estaciones de ingeniería, etc. Todo este tráfico pasaría por el Firewall de “Segmentación”.

Esto supone asumir que una acción malintencionada en la misma subred podría tener éxito ya que el control se efectúa cuando llega, al menos, en Capa 3. No en Capa 2. Pero, ¿qué ocurre si por alguna razón tenemos que llevar a cabo un filtrado a nivel de Capa 2 a un nivel más bajo y un número de equipos más reducido? Quizás una de las respuestas sea el cambio, o rediseño, del plan de direccionamiento de la/las área/s OT en cuestión y así escalar hasta el siguiente nivel. Sin embargo, esto no puede ser viable.

Mejor pongamos un ejemplo gráfico:

Arquitectura

Como podemos observar en esta celda disponemos de un convertidor de fibra a cobre hacia un switch (Switch 1) donde se localizan un HMI y del que cuelga otro (Switch 2) al que se encuentran conectados otros controladores, componentes “Safety”, control de movimiento, etc. Si por alguna razón dicho HMI sufriera alguna infección o se quisiera llevar acabo alguna acción malintencionada, podría alcanzar el resto de equipamiento conectado. Vemos que todo se ubica en un mismo dominio de broadcast y con direccionamiento bajo 192.168.0.0/24.

El problema que se plantea es que el HMI sea un equipo con un sistema operativo sin actualizaciones o fuera de soporte. Bien porque la actualización de éstos pueda ser difícil, aunque no imposible, y por otro lado dado, el ciclo de vida elevado, genera más probabilidad de falta de actualizaciones, nuevos desarrollos, pero siguiendo 100% funcionales. Esto puede suponer un riesgo importante a los equipos ubicados en el otro switch de donde cuelgan autómatas, controladores y otros sistemas.

Sin embargo, no podemos olvidar que las intervenciones en entornos OT no sólo deben ser lo menos intrusivas posible sino, que no alteren la operación normal de las instalaciones. El despliegue de soluciones debe ser transparente y con un nivel de riesgo lo más cercano a cero. Como ya sabemos el riesgo igual a cero, no existe.

Cada cambio introduce un riesgo. Por mucho que lo preparemos, planifiquemos, involucremos a todas las personas que puedan responder ante alguna acción no prevista, siempre puede suceder algo que no esté contemplado. La falta de respuesta en tiempo y forma puede desembocar en la pérdida de disponibilidad. Por ello, cuanto menor sea la cantidad de acciones a realizar mejor. Hemos de guardar un equilibrio entre simplicidad y eficiencia.

Es por todo lo anterior que hemos de considerar el uso y funcionalidades a nivel de capa 2 que ofrecen los cortafuegos. Esto es, filtrar el tráfico entre dispositivos que se encuentren en la misma red y tratar de proteger de forma individualizada todos los elementos desplegados en ella sin requerir cambios adicionales. Esto nos permitirá mantener el direccionamiento intacto siendo la única pérdida de servicio, a priori, los segundos que empleemos en conectar el equipo en nuestra red. Obviamente esto introducirá un punto más de fallo, algo que deberemos asumir si lo que queremos es que otro elemento nos proporcione la seguridad que pretendemos.

Por tanto, cuanto más reduzcamos el riesgo sin intervenir en los equipos finales, indudablemente mejor. Claro está esto también dependerá de la criticidad del equipo, su funcionalidad, ciclo de vida, soporte, entre otros factores. Sin embargo, esto no debe ser algo que deba ser así siempre. Para alcanzar unos niveles lo más completos e integrales posibles hemos de aplicar aquellas que estén disponibles en PLCs, switches industriales, entre otros. Aquí os dejo aquellas que podremos encontrar en autómatas modelo S7-1200 del fabricante Siemens.

En el día de hoy he querido destacar la necesidad de uso de modos y funcionalidades a nivel de capa 2 para proteger los entornos industriales, evitando así cambios o interfiriendo en la operativa aunque esto sea tan sencillo como cambiar una dirección IP.

En sucesivas entradas abordaremos este tema y la manera de cubrir estas necesidades. Esto es uso de firewalls a nivel de capa 2, en lugar de 3, como es a lo que estamos más acostumbrados.

¡Nos vemos en la siguiente!

“DoS Policy” más allá del filtrado tradicional

Como hemos comentado en otras ocasiones la separación y segmentación de los entornos IT y OT es la primera medida técnica que debemos tomar. Es necesario definir los perímetros y qué comunicaciones deben permitirse entre uno y otro lado. Para conseguirlo, empleamos Cortafuegos aunque con características adicionales que han dado lugar a los conocidos NGFW. Sin embargo, también podemos contar con otras adicionales, en este caso, para evitar denegaciones de servicio, DoS.

La primera acción que debemos hacer es identificar el tráfico. Definir qué comunicaciones existen en nuestro entorno de control y automatización. Luego, permitirlas en función del criterio que más se ajuste ya sea por IPs, interfaces, servicios, subredes, aplicaciones, protocolos o cualquier otro. Sin embargo, una vez hecho esto y teniendo que claro “qué si y qué no”, también es importante identificar posibles anomalías dentro del mismo pudiendo afectar al funcionamiento del, o los equipos, destino.

Una de las acciones con las que podríamos afectar a las comunicaciones de este ámbito es introduciendo tráfico adicional. Sea este Broadcast, Multicast o Unicast los efectos podrán ser unos u otros ya que dependerá si la electrónica de red lo replica por todos los puertos o sólo por aquél que está dirigido al destinatario.

Si nos referimos a los equipos de control, sabemos que éstos tienen un ciclo de vida mayor con lo que es muy común encontrarnos con equipos antiguos con una capacidad para gestionar comunicaciones mucho más limitada que los equipos actuales. Ante un exceso de tráfico, aunque esté dirigido a un puerto de destino permitido, éstos podrían dejar de responder perdiendo así visibilidad y control.

Hay que tener presente que una denegación de servicio puede no venir exclusivamente de medidas claramente intencionadas. También puede hacerse por un error o mala parametrización de sistemas. Un caso lo podríamos encontrar en los escáneres de vulnerabilidades. Si no los configuramos correctamente y no los ejecutamos acorde a los equipos finales podríamos llegar a comprobar vulnerabilidades de sistemas operativos Windows, Linux, etc. sobre autómatas o controladores que, lógicamente, no los empleen o podrían no hacerlo. Aparte de que los resultados no tendrían sentido, podría desembocar en posibles bloqueos en módulos de comunicaciones, tiempos de respuesta tardíos, entre otros.

Para emular una situación de esta índole he elaborado una Prueba de Concepto empleando el simulador Snap7 y equipos virtuales. No obstante, la prueba fue realizada sobre dos autómatas Siemens S7-400 y S7-300 y los resultados fueron la pérdida de visibilidad desde el servidor que los gestionaba. Los equipos no eran capaces de manipular tanto tráfico. Por supuesto, en un entorno de laboratorio.

La misma sigue el siguiente esquema:

Desde un equipo con una distribución Kali Linux realizamos una inundación de tráfico por medio de la herramienta hping3, efectuando peticiones TCP SYN contra el puerto TCP 102, que es el empleado por el fabricante Siemens. Dicho equipo tendrá una IP 192.168.100.20, mientras que el PLC virtualizado 192.168.20.10.

root@kali:~# hping3 –flood -p 102 -S 192.168.20.10

Antes de realizar dicha operación podremos comprobar que el consumo de CPU como de memoria es bajo dada la ausencia de sesiones.

Sin embargo, una vez comenzado el envío de paquetes el consumo de recursos va en aumento:

Si en ese momento decidiésemos conectarnos a dicho PLC simulando un servidor, HMI, etc. veríamos que no sería posible y cómo la propia herramienta muestra un mensaje en la parte inferior de la captura “ISO: An error occurred during…”

En este sentido fabricantes como Fortinet introducen una funcionalidad denominada “IPv4 DoS Policy” que nos va a permitir atajar que, algo o alguien, de una manera intencionada, o no, pueda generar un exceso de tráfico que desemboque en una pérdida de visibilidad o control sobre equipos finales.

En la imagen siguiente podemos ver los distintos parámetros que podemos definir y parametrizar según sea nuestra necesidad.

 

Deberemos indicar la interfaz de entrada por dónde esperaremos el tráfico en cuestión, ya sea física o lógica; direcciones IP de origen y destino y servicios. A continuación, hemos de identificar las características a nivel de capa 3 y/o 4 que queremos habilitar y los respectivos umbrales de cada uno de ellos. Este es un trabajo que hemos realizar con cautela ya que nos obliga a tener una estimación acerca de los valores tolerables y qué se escapa de un normal comportamiento. No tenemos porqué habilitar todas las opciones, sino aquellas que consideremos que nos pueden ser de utilidad o tengan sentido dependiendo de la ubicación y exposición del cortafuegos. Finalmente, una de las opciones que sí resulta conveniente habilitar es la opción de registro ya que nos va a permitir disponer de información al respecto, como se puede ver en la imagen siguiente.

Cuando hablamos de cortafuegos, generalmente nos viene a la mente la opción de permitir o denegar tráfico y sobre él aplicarle controles adicionales como Antivirus, IDS/IPS, entre otros. Es cierto, ese su principal cometido. Sin embargo, podemos encontrar funcionalidades que, sin penalizar el rendimiento, pueda ayudar a identificar anomalías de aquél que estamos dejando pasar.

La primera tarea es decidir qué debemos autorizar y qué no. Esto nos va obligar a conocer qué comunicaciones establecen nuestros equipos de control y sistemas asociados. A menudo partiremos de un desconocimiento total ya que nos enfrentaremos a entornos conmutados o enrutados donde no se ha documentado dicha información y obviamente no existen elementos de seguridad perimetral. Si queremos filtrarlas deberemos identificarlas, y entender el por qué deben producirse, o no. No todo lo que veamos debe ser permitido. Probablemente ni tan siquiera los propios usuarios de las instalaciones lo sepan. Es una labor que puede complicarse según sean los escenarios, pero que en cualquier caso, ha de realizarse.

Un buen recurso pueden ser los “Puerto Espejo” o dispositivos como el Siemens TAP  104, que nos ayudarán a replicar tráfico de red y que pueda ser colectado y analizado a posteriori.

Hasta aquí la entrada de hoy.

¡Un saludo nos vemos en la próxima!

Presentación Check Point 1200R Rugged Appliance

Una de las características que presentan los entornos industriales, o aquellos donde estén presentes los sistemas de control y automatización, es lo hostil que puede ser el medio en cuanto polvo, humedad, temperatura, se refiere. Con la necesidad de tomar medidas en materia de ciberseguridad, los equipos deben de poseen una serie de características, aparte de las funcionales, que cumplan con estos requisitos de robustez, tolerancia a fallos, entre otras. Conscientes de esta situación, los fabricantes de soluciones de seguridad perimetral y redes han sacado al mercado productos para cubrir esta necesidad con más o menos gama dependiendo del fabricante. Hoy hablaremos del equipo 1200R del fabricante CheckPoint.

Como podemos comprobar posee un diseño rugerizado soportando un rango de temperatura entre -40 y 75 ºC con un índice de humedad sin condensación entre 20 y 90%. Al igual que otros, no posee un ventilador para su refrigeración, importante para aquellos espacios con gran cantidad de polvo en el ambiente. Pose un total de 6 puertos para comunicar equipos; 4 LAN, 1 WAN y 1 DMZ, pudiendo los dos últimos ser utilizados a través de módulos SFP como fibra óptica. También un puerto serie para comunicación por consola.

Tendremos la opción de alimentarlo bien por un bornero en la parte frontal o con una fuente tradicional a un enchufe a 220V por la zona posterior. Importante tener en cuenta que la que se suministra opera entre 0-40ºC lo cual supone una diferencia notable con respecto al del propio equipo.

En la zona posterior nos encontraremos con un slot para introducir una tarjeta SD-HC y ser utilizada como almacén de logs. El fabricante ofrece una de 32GB de capacidad con lo que, al menos, hasta esta cantidad estaremos cubiertos.

Cara a la instalación, tendremos la opción de colocar un soporte para carril DIN y montarlo en aquellos espacios que así lo requieran.

Sin embargo, conviene prestar atención si nuestra opción sea la de alimentarlo con la fuente de alimentación a 220 V ya que el espacio entre equipo y armario puede no ser el suficiente para el que ocupa el conector.

El equipo trae consigo la posibilidad de ser administrado tanto de forma centralizada a través de una consola de administración, o local vía web. En mi caso he elegido esta opción, para su puesta en marcha inicial. Para ello habrá que conectarse a l puerto LAN 1 e introducir la IP que viene por defecto, 192.168.1.1. Luego seguiremos el asistente para su configuración inicial.

 

 

Luego deberemos de llevar a cabo la actualización sistema y los servicios que trae consigo el propio equipo. Aquí al hacerlo a la versión de Firmware R77.20.75 como podemos apreciar la apariencia cambia.

Hasta aquí la presentación de este equipo que al igual que otros puede ser empleado para técnicas de Virtual Patching, protección de conjunto de equipos, o acceso remoto seguro. En futuras entradas veremos más del funcionamiento y cómo podremos proteger tanto nuestro entornos industriales como nuestras infraestructuras críticas.

Un abrazo!

Edorta

TAP Devices, Siemens TAP 104

Few months ago, I wrote about how port mirroring is an allied to capture and analyze network traffic. You can access to the article clicking here. There are a lot of reasons to use it, such as identify communications, troubleshooting tasks, use of IDS/IPS systems, and so on. But port mirroring is not the only one, we can use TAP devices. However, as I said several times, we must use specialized equipment for these environments, in particular industrial ones. Today I will talk about Siemens TAP 104.

Siemens TAP 104 is a hardware device that can be installed between two devices to gather a copy of data traffic on Ethernet based networks. Once the collected frames are stored, we can visualize them with a network analyzer tool to identify the information that we are looking for. The TAP device does not affect to the communication that pass through it.

Siemens TAP 104

It has four RJ-45 ports. Two to connect the segments that we want to monitor and two more to connect the systems to collect the frames. It operates in a fault-free mode even when the power is off.

One use case can be as the picture below shows. For example, we can be interested to identify issues between the HMI and the S7-1500 PLC. The traffic will be gathered by Grassmarlin tool that can be downloaded from here. I wrote about it more than a year and half. You can find the article clicking here.

Siemens TAP 104

Following the concept of the previous picture, this time, I have replicated this scenario in small testbed. In the picture below you can identify different devices, such as Fortinet Fortigate Rugged 90D, Fortinet Fortiswitch 112D-PoE, Siemens PLC S7-1200, Siemens HMI, Siemens TAP 104 and a laptop. As you can see, the TAP is just in the middle of the Fortigate switch and the PLC. Each communication from and to them, is replicated to the first RJ-45 port, where the laptop is connected and running Wireshark packet analyzer.

Testbed Lab

Testbed Lab

Once the traffic is gathered, we can open it with an analyzrer. Below we can see the information available from LLDP protocol as system description, IP management address, and so on.

LLDP Wireshark

But if we are looking for information, we can see the values of sending and receiving from and to the devices.  In the picture below you can see the field “Function: GetMultiVariables”

S7 Communication Wireshark

And then displaying the field “Response Set-ValueList”  we can see the values 84 and 16, the same that appears in the HMI.

S7 Communication Wireshark

Today, with Siemens TAP 104, we see other way to gather network traffic to identify possible issues in our industrial communications where it is mandatory not to introduce additional latencies that may affect them. In general, it is very common to do it using Port Mirroring configurations, but as we have seen, there are others. Either Port Mirroring or TAP devices, we can find them a helpful resource for different use cases such as troubleshooting, anomalies, security problems and much more. Always with specialized equipment.

That is all for now, see you next time!

Edorta

Specialised products, FortiSwitch Rugged 112-D PoE

As I said several times, the industrial communications trend to Ethernet Technology for the advantages that it provides. However, this is not similar to affirm that everything will can communicate by frames or packets. There are many scenarios where serial protocols are being used because is not possible to update to Ethernet. For example, migrate to it requires to change cabling, reconfigure devices, deploy new networking equipment, programming changes, and many other measures. But if we can, we must deploy networking devices according to these harsh environments. Today, I will show one that can be used for its capabilities, Fortinet FortiSwitch Ruuged 112D-PoE.

It has 8 GE RJ-45 ports and 4 more GE SFP slots. It can be necessary for those situations when you need to connect devices by optical fiber. It is widespread used because permits more than 100 meters, or less, and does not affect electromagnetic interferences in comparison with unshielded twisted pair Ethernet cabling. It supports fiber single mode, multimode and long haul single mode with LC connector

FortiSwitch Rugged 112D-PoE

This switch can be used to connect PLCs, HMIs, or other device that communicates by industrial based Ethernet Protocols such as PROFINET, Ethernet/IP, Modbus/TCP, and so on. It has redundant power input terminals in the range from 44 to 57V DC to give service for PoE ports if needed.

FortiSwitch Rugged 112D-PoE

There are not any fans to cool itself to prevent damages. It is so important for those dusty places where can affect the operation stopping them if it is excessive. The switch can work in a temperature range from -40 to 75º C (-40 – 167º F) and can be mounted in DIN rail or wall depending your rack or facility. Related to the atmosphere, it tolerates up to 5-95% of non-condensing humidity.

FortiSwitch Rugged 112D-PoE

As you know, the lifecycle of industrial components and systems are higher in comparison with IT world. In this way, Fortinet affirm this switch has a mean time between failures (MTBF) more than 25 years. For this, it is capable to work in OT scenarios.

When you connect to its web interface you can see the dashboard where you can identify different information.

FortiSwitch Rugged 112D-PoE Menu

As you can see on the left, you will find a menu from where you can configure different features. For example, authenticate user to a LDAP server, port mirror ports, syslog server, and so on.

FortiSwitch Rugged 112D-PoE Authenticatio

FortiSwitch Rugged 112D-PoE Port Mirror

FortiSwitch Rugged 112D-PoE Logs

It operates at Layer 2 but you can get more Layer 3 capabilities if you connect it to a Fortinet Fortigate unit. Furthermore, you can manage your Fortiswitch from Fortigate console by FortiLink protocol. You will not find all the features, but you can configure VLAN interfaces, switch on and switch off ports, enable or disable PoE, and others.

FortiSwitch Rugged 112D-PoE and Fortigate Rugged 90D

Even though Ethernet technology give us a lot of improvements not always we will be able to implement them in own facilities in particular when they are working for 24 hours a day, 7 days a week, 365 days a year. It requires a very big effort in time, knowledge and obviously, budget .

Depending the activity, availability, probably, we will only get time on Christmas, Easter Week or summer Holidays, to do everything we need. In addition to that, be sure that you meet with others employees such as maintenance technicians that they have to do tasks relative to keep on good state of operation of our infrastructures. And as you know, they have more priority.

In spite of this, either it is possible to update or deploy a new facility we need to know which are the devices available that meet the requirements that we need. In the same way, industrial and automation control system vendors have been working to deploy new products for Cybersecurity purposes; the Cybersecurity product manufactures have developed industrial networking equipment. One of them, is Fortinet FortiSwitch Rugged 112D-PoE that I have shown. All features can be found by clicking here.

Other choice to find the best solution for our needs.

See you next time!

Regards

Edorta

BACnet, fundamentos de un protocolo para la gestión de edificios

A menudo nos centramos en materia de Ciberseguridad haciendo referencia a aquellos equipos y sistemas que intervienen en los procesos productivos o entornos de control y automatización. Sin embargo, las fábricas no sólo son PLCs, HMIs, Workstations, sensores u actuadores. Dependiendo de la actividad y el tamaño, cuentan con otros elementos que también contribuyen a que se garantice la disponibilidad de la que tanto hemos hablado. Me refiero a sistemas de refrigeración, extinción de fuegos, climatización, montacargas, etc. los cuales pueden ser gestionados por medio del protocolo BACnet.

Habitualmente los vemos referenciados en los denominados “Edificios Inteligentes”, sin embargo, su uso ni es exclusivo de ellos ni es algo relativamente nuevo. La gestión de edificios viene dada por las siglas BMS, Building Management System debiéndose distinguir, entre edificios de viviendas o edificios industriales. En general, los sistemas BMS integran un conjunto de subsistemas encargados de los sistemas de control de iluminación, antincendios, alarmas, elevadores, ventilación, temperatura, etc. Si bien muchos de ellos son comunes a ambos entornos no podemos decir que son similares ya que las aplicaciones y alcance son distintos.

Ahora bien, al igual que PLCs, HMIs, y demás dispositivos, estos sistemas han de comunicarse entre sí para su propio funcionamiento y gestión. En este sentido, uno de los protocolos empleados es BACnet, Buiding Automation Control Network. Desarrollado en 1987, ha sido un ANSI e ISO estándar desde 1995 y 2003, respectivamente. Aunque su mantenimiento es continuo, el propósito de BACnet es proporcionar interoperabilidad entre sistemas y dispositivos en aplicaciones de control y automatización de edificios, mediante un protocolo de comunicaciones estándar.

Al igual que muchos otros, cada dispositivo BACNet es una combinación de hardware y software, encontrándolo como norma general en forma de controlador, pasarela o interfaz de usuario. Cada uno de ellos dispone de un identificador o número de instancia único que lo identifica y diferencia de los existentes en la red aparte de otros con información relativa a las entradas y salidas que  monitoriza y controla.

Dentro de BACnet podemos encontrar 3 conceptos claramente diferenciados, Objetos, Propiedades y Servicios.

Toda la información contenida dentro de un dispositivo BACnet es ordenada como objetos, el cual le convierte en un protocolo orientado justamente a esto mismo, a objetos. Cada Objeto” representa un componente del propio dispositivo o un conjunto de información que puede ser solicitada por otro a través de medios como Ethernet, IP, RS-485, etc.

El protocolo define un total de 54 tipos de objetos para los usos más comunes cubriendo así la mayoría de las necesidades. Sin embargo, da la posibilidad de crear otros nuevos para no interferir sobre aquellos usos más concretos o aplicaciones propietarias.

La imagen muestra la arquitectura e interoperabilidad entre los distintos elementos que definen el funcionamiento del protocolo para la gestión y automatización de edificios BACnet.

Arquitectura e inteoperabilidad en BACnet

 

Cada objeto tiene un identificador de 32 bits el cual contiene un código para el tipo de objeto y el número de instancia de dicho objeto.

Con independencia del propósito o función, cada “Objeto” posee un conjunto de “Propiedades”. Cada una de ellas contendrá dos partes, un identificador y un valor. El identificador son números que la definen de forma única en el ámbito del tipo de objeto; y el valor, la magnitud del mismo. Luego, dicha información podrá ser tanto de lectura como de y escritura.

Si unificamos ambos conceptos, podemos decir que cada “Objeto” incluyen “Propiedades” que determinan sus capacidades, operación e información asociada.

Como hemos dicho anteriormente los dispositivos interactúan entre sí para su operación. Cuando un equipo se comunica con otro para llevar a cabo una determinada acción, lo hace a través de los denominados “Servicios”. Los servicios son agrupados en 5 categorías según su funcionalidad:

  1. Object access (lectura, escritura, creación, borrado)
  2. Device management (descubrimiento, sincronización horaria, inicialización, copia de respaldo y restauración)
  3. Alarm and event (alarmas y cambios de estado)
  4. File transfer (Tendencia de datos y cambio de programa)
  5. Virtual terminal (interfaz hombre-máquina por medio de menús o similar)

Cada dispositivo envía las peticiones empleando mensajes convenientemente estructurados tanto en la pregunta como en la respuesta. Los mensajes son codificados en un stream numérico definiendo las funciones que deben llevarse a cabo.

Para que dichos mensajes puedan enviarse y recibirse, se establecen varios medios de transporte, los cuales se citan a continuación:

  1. BACnet/IP
  2. BACnet ISO 802-3 (Ethernet)
  3. BACnet MS/TP (Master-Slave/Token Passing)
  4. BACnet over ARCNET
  5. BACnet Point-to-Point (EIA-232 and Telephone)
  6. BACnet over LonTalk Foreign Frames
  7. BACnet over ZigBee

Cada uno de ellos son una combinación de capas Físicas y Enlace de Datos. Sin embargo, el mensaje BACnet es independiente del medio empleado pudiendo existir a su vez pasarelas referenciadas como “Routers” que puedan combinar cada uno de los medios. No obstante, serán los dos primeros los que reclaman más nuestra atención ya que proporcionan integración con redes tradicionales.

BACnet/IP proporciona conectividad a nivel de capa 3 pudiendo ser los equipos accesibles desde distintas redes IP. Cuando este medio es empleado con múltiples subredes, es necesario el uso de una funcionalidad especial denominada BBMD, Broadcast (Management Devices), equipo empleado para administrar los mensajes broadcast entre subredes. Éste recoge dichos mensajes y los redistribuye a otro BBMD ubicado en otra red mediante mensajes unicast.

Mientras que, BACnet ISO 802.3, similar al anterior, pero limitando las comunicaciones a nivel de capa 2.

Ahora bien, teniendo en cuenta los conceptos acerca de dispositivos, objetos propiedades, servicios y la forma en la que transmitir los mensajes, BACnet proporciona capacidades funcionales las cuales son denominadas como “Interoperability Areas”.  Existen un total de 5:

  1. Data Sharing, intercambio de información entre dispositivos. Lo mensajes pueden ser priorizados en función de su propiedad, además de ser de lectura o lectura/escritura.
  2. Trending, visualización de los valores recogidos y graficados para determinar tendencias.
  3. Scheduling, programación de tareas a ejecutar en momentos o intervalos concretos.
  4. Alarm & Event Management, intercambio de información relativo a alarmas o eventos.
  5. Device & Network Management, permite el descubrimiento de dispositivos, objetos dentro de ellos, establecimiento y reconexión en caso de caída de comunicación, sincronización horaria y reinicio.

Estas áreas están definidas dentro de BACnet como BIBB, “BACnet Interoperability Blocks”.

Puesto que BACnet es un estándar, los distintos fabricantes de equipos deben garantizar que sus productos soportan ciertos requisitos para poder operar unos con otros. Para ello, deben cumplir con lo definido en lo que se denomina “Protocol and Implementation and Conformance Statement”, PICS; una ficha técnica con distinta información y entre ella, los distintos BIBB soportados para que puedan ser comparados y garantizar su funcionamiento.

Es importarte resaltar que los mensajes pueden ser dotados de una “Prioridad” dependiendo el tipo de mensaje y la información que transporta. Se definen un total de 16, siendo las dos primeras relativas a cuestiones de “Safety”, “Manual Life-Safety” y “Automatic Life-Safety”.

Hasta aquí la presentación de los conceptos básicos de BACnet. Un protocolo con unas características específicas para entornos concretos. Como decía, es importante remarcar que su uso puede no estar necesariamente asociado a edificios de viviendas sino también a entornos industriales. Éstos también disponen de sistemas de refrigeración, sensores de humos, montacargas, etc. dependiendo, claro está, del tamaño y la actividad. Podrán almacenar productos químicos que deban ser almacenados bajo unas condiciones de temperatura determinada; entornos donde la calidad del aire deba ser única debiendo accionarse los sistemas de ventilación bajo unas circunstancias concretas; controlar la iluminación de un pabellón en distintas franjas horarias, entre otras muchas. ¿Alguien se imagina los efectos que pudiera tener si algo o alguien, pudiese alterar a las dos de la madrugada la iluminación de parte o toda una nave de producción y los operarios no pudiesen trabajar? Y peor aún, cómo o porqué se genera esa situación si no se puede acotar la causa que lo origina. No estamos hablando de un hecho con unas consecuencias graves, pero sí con impacto sobre la actividad de la propia empresa.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .