1.0 Introducción
El Internet Industrial de las Cosas (IIOT) consiste en dispositivos conectados en red que crean sistemas capaces de supervisar, recopilar, intercambiar y analizar datos del proceso para habilitar a las empresas industriales a tomar decisiones empresariales más inteligentes y rápidas. Las ventajas de aplicar enfoques de Internet Industrial de las Cosas (IIOT) a los problemas empresariales industriales son enormes, ya que incluso un pequeño porcentaje de mejora en la eficiencia, el tiempo, el gasto de capital y la asignación de activos se traduce en un ahorro significativo y/o un aumento de los ingresos. Las soluciones de IIOT han demostrado este tipo de mejoras porcentuales. Sin embargo, para implementar una solución de IIOT es necesario comprender su arquitectura y diseño.
El objetivo de este documento es proporcionar esa comprensión de los sistemas de supervisión del Internet Industrial de las Cosas (IIOT). Tenga en cuenta que los sistemas IIOT pueden utilizarse tanto para la supervisión como para el control. De los dos casos de uso, la supervisión suele ser más sencilla de configurar y mantener. Las ventajas inmediatas de la supervisión del IIOT incluyen: alertas remotas de condiciones, seguimiento del historial y eliminación del tiempo y el esfuerzo que supone la comprobación manual.
El resto de este documento comienza con una arquitectura conceptual para la solución de supervisión IIOT en la sección 2.0. La arquitectura conceptual proporciona un marco para describir las opciones de arquitectura de diseño que se detallan en la sección 3.0. En la sección 4.0 se ofrece una guía de selección para elegir entre las opciones. La descripción general del ecosistema y la línea de productos de Omega Link en la sección 5.0 muestra una instancia de la arquitectura de diseño. La sección 5.0 ofrece una breve introducción al tema de la computación periférica, que vuelve al uso del Internet Industrial de las Cosas (IIOT) para el control frente a la supervisión.
El tema de la seguridad del IIOT es importante. Dejamos el debate detallado para otro documento, pero ofrecemos un resumen de las directrices relacionadas con la arquitectura en el Anexo. Las arquitecturas conceptuales y de diseño presentadas (así como el ecosistema Omega Link de Omega) incorporan la seguridad como parte integral de sus estructuras.
2.0 Conceptual Architecture
2.1 Overview
La arquitectura conceptual de una solución IIOT se muestra en la figura 2.1. Un sistema es supervisado por uno o varios sensores. El sistema y los sensores se encuentran en las instalaciones. La información de esos sensores se envía a una ubicación fuera de las instalaciones, en la nube, a través del elemento de conectividad. Nos referimos a los datos que se transfieren desde el elemento de conectividad a la nube como comunicaciones «northbound» (hacia el norte) y a los que se transfieren desde el elemento de conectividad a los sensores como «southbound» (hacia el sur).
2.2 Elementos
2.2.1 Nube
La nube es la ubicación externa de almacenamiento y análisis de los datos procedentes de los sensores. También proporciona un acceso seguro a estos datos a los usuarios, normalmente a través del inicio de sesión en un navegador web. A diferencia del almacenamiento local, que suele estar limitado al acceso en esa ubicación, el almacenamiento y el análisis en la nube están disponibles a través de Internet. El acceso a Internet permite al usuario o usuarios acceder a estos datos de forma remota a través de un ordenador de sobremesa, una tableta o un teléfono móvil. También se dispone de análisis avanzados (por ejemplo, aprendizaje automático).
2.2.2 Conectividad
El elemento de conectividad se encarga de transferir la información de forma segura entre los sensores y la nube. Como se verá en la siguiente sección, este elemento es complejo, debido al número de opciones disponibles y a los subelementos que intervienen. Independientemente de la complejidad, la tarea sigue siendo la misma: la transferencia segura de datos.
2.2.3 Sensores
Los sensores son el medio para detectar el estado del sistema. El objetivo de la solución de Internet Industrial de las Cosas (IIOT) es llevar los datos más importantes recopilados por los sensores a la nube para su posterior análisis y toma de decisiones por parte de los usuarios que se encuentran alejados del propio sistema. La figura 3.1 ofrece más detalles sobre las funciones de la nube, la conectividad y los sensores. En las subsecciones siguientes se ofrece una explicación más detallada.
3.0 Design Architecture
3.1 Overview
The Design Architecture (Figure 3.1) takes the Conceptual Architecture to the next level of detail by providing design options and elements for each of the major functions (cloud, connectivity, sensors). Figure 3.1 gives more detail on the cloud, connectivity, and sensors functions. Further explanation is in the subsections below.
3.2 Sensores
3.2.1 Cableados frente a inalámbricos
Desde el punto de vista de la arquitectura de soluciones IIOT, la distinción entre sensores cableados e inalámbricos es el atributo más importante. Las salidas de los sensores cableados pueden ser analógicas o digitales. Si son analógicas, se debe disponer de medios para convertir los datos a un formato digital para su transmisión más arriba en la cadena. Si son digitales, entonces el protocolo para mover los datos debe ser conocido y compatible con la solución de conectividad (lo que llamamos la conexión «southbound»). El protocolo digital incluirá tanto los componentes físicos (cables, conectores) como el protocolo de software. Se ofrece más información en la sección sobre conectividad: protocolos. En el caso de los sensores inalámbricos, al igual que en los sensores con salida digital cableada, los datos ya se han convertido, por lo que deben establecerse protocolos para enviar y recibir la información. Además, los componentes físicos incluyen capacidad de transmisión y recepción inalámbrica.
3.2.2 Factores de forma
Los factores de forma permiten empaquetar uno o varios sensores que funcionan en diferentes entornos y regímenes normativos. Desde el punto de vista de la arquitectura del Internet Industrial de las Cosas (IIOT), es importante comprender los factores de forma que combinan sensores con transmisión inalámbrica. Estos se recogen en la figura 3.1, en los recuadros de línea punteada «unidad única». Uno muestra sensores que se han emparejado con una conectividad celular, lo que permite el acceso directo a la nube. El otro muestra una combinación de sensor/transmisor que proporciona conexión a una puerta de enlace a través de un enlace inalámbrico.
3.2.3 Tipos de detección
Los sensores detectan una variedad de fenómenos físicos, químicos, biológicos y nucleares a través de una serie de mecanismos o modalidades. Desde el punto de vista de la arquitectura, las modalidades de detección son menos importantes que la forma en que la información se transmite desde el sensor a la nube.
3.3 Nube
La nube consta de cuatro componentes principales:
a. Un concentrador, que proporciona una conexión segura al sistema local, la telemetría y la gestión de dispositivos. Un concentrador habilita la comunicación remota hacia y desde los sistemas locales, a través de múltiples sitios, si es necesario. Por lo general, gestiona todos los aspectos de la comunicación, incluida la gestión de la conexión, la ruta de comunicación segura y la autenticación y autorización de dispositivos. También aplica cuotas de conexión y rendimiento. La telemetría y otros mensajes de los dispositivos se introducen en la nube y el intercambio de mensajes es gestionado por el concentrador.
b. almacenamiento para conservar los datos
c. procesamiento para analizar los datos
d. interfaz usuario y visualización para hacer llegar los resultados del análisis al usuario final, normalmente a través de una interfaz de navegador web, pero en el caso de las alarmas, a través de correo electrónico, mensajes de texto y/o llamadas de voz.
3.4 Connectivity: Configurations
Connectivity moves data north to the cloud and commands and configuration information south. Authentication and authorization information for secure communications moves north/south as well. The structure of this communication path follows three patterns described below and shown in Figure 3.1.
1. Sensores a la nube: el factor de forma de unidad única de sensor/celular permite la conexión directa a la nube desde las instalaciones.
2. Sensores a la puerta de enlace a la nube: la configuración más habitual implicará una puerta de enlace (véase la siguiente sección) que proporciona la conexión entre los sensores y la nube. La puerta de enlace suele tener opciones de conexión por cable e inalámbrica. La opción inalámbrica suele ser un sensor/transmisor de factor de forma de unidad única, como se muestra en la figura 3.1.
3. Sensores a transmisor a receptor a pasarela a la nube: esta configuración es típica de las instalaciones heredadas en las que hay transmisores y receptores existentes y/o en las que hay un número significativo de sensores cableados que se encuentran a cierta distancia de donde estaría la pasarela.
3.5 Conectividad: pasarelas
3.5.1 Descripción general
Una pasarela actúa como facilitadora de la comunicación y, potencialmente, como centro de procesamiento de datos de dispositivos. Su función es trasladar datos e información entre los sensores y la nube. Una pasarela también puede transformar los datos como parte de la transferencia. Admite protocolos de comunicación seguros que incluyen información de autenticación y autorización. Una pasarela se diferencia de un enrutador en que desempeña un papel activo en la gestión del acceso y el flujo de información. Las pasarelas pueden instanciarse en forma de hardware o software.
3.5.2 Pasarelas de hardware
Las pasarelas de hardware son dispositivos independientes. Proporcionan una o más interfaces para la conexión de sensores hacia el sur: cableadas (analógicas y digitales) e inalámbricas. También proporcionan acceso a Internet, ya sea integrado o a través de una conexión a un router.
3.5.3 Pasarelas de software
Las pasarelas de software se instalan en ordenadores personales. El software puede ejecutarse en primer plano o en segundo plano, proporcionando los mismos enlaces de comunicación hacia el norte y hacia el sur que la pasarela de hardware, con las interfaces físicas proporcionadas por el ordenador. Las pasarelas basadas en software pueden proporcionar interfaces de usuario para acceder a la configuración visual de los sensores y a la visualización de los datos de los sensores. Dado que la pasarela de software se ejecuta en un ordenador, puede ofrecer almacenamiento y visualización de datos in situ. El acceso remoto también es posible si el departamento de tecnología de la información permite el acceso seguro desde el exterior a la red interna con el ordenador. Si es así, la pasarela de software in situ puede eliminar la necesidad de la capa de capacidad de la nube.
3.6 Conectividad: protocolos
3.6.1 Descripción general
El movimiento de datos a través de la Solución de Internet Industrial de las Cosas (IIOT) requiere el uso de protocolos. Estos protocolos deben estar bien definidos, ser seguros y, a ser posible, cumplir con los estándares del sector. Las especificaciones de los protocolos pueden incluir cualquiera o todos los siguientes elementos: características físicas de los conectores y el cableado, cómo establecer un canal de comunicación, el formato de los datos enviados a través de ese canal. El modelo OSI (figura 3.6.1 a continuación) describe el protocolo como un conjunto de capas, cada una de las cuales tiene una función específica.
3.6.2 Northbound: puerta de enlace hacia/desde la nube
Existen varios protocolos estándar disponibles para la interfaz entre la puerta de enlace y la nube. A continuación se definen algunos de los más comunes, junto con un diagrama resumen.
El Protocolo de transferencia de hipertexto (HTTPS) es el protocolo de la World Wide Web, destinado a las interacciones de solicitud/respuesta. La «S» de «HTTPS» significa «seguro». El HTTP es basado en texto y, por lo tanto, bastante prolijo, pero fácil de implementar.
El Protocolo avanzado de colas de mensajes (AMQP) es un protocolo de transferencia de mensajes multiplexado, bidireccional y orientado a la conexión, con codificación de datos compacta e inherente. A diferencia de protocolos más antiguos como el HTTP, el AMQP se diseñó para conexiones de tipo Internet Industrial de las Cosas (IIOT) a la nube.
MQ Telemetry Transport (MQTT). MQTT es un protocolo de transferencia de mensajes ligero de cliente-servidor. MQTT es útil para dispositivos de la Internet Industrial de las Cosas (IIOT) debido a su espacio de código compacto y al pequeño tamaño de los marcos de mensajes.
Protocolo de aplicación restringido (CoAP). El protocolo de aplicación restringido es un protocolo basado en datagramas que se puede implementar sobre una capa de transporte como UDP. CoAP puede considerarse una versión compacta de HTTP creada para las necesidades del Internet Industrial de las Cosas (IIOT).
3.6.3 Southbound: puerta de enlace hacia/desde sensores
Al igual que con los protocolos northbound, también hay muchas opciones para la conexión southbound entre la puerta de enlace y los sensores. Estas opciones incluyen los protocolos northbound enumerados anteriormente. Sin embargo, debido a las limitaciones de los dispositivos y a las restricciones locales, como los sistemas y redes de producción previamente implementados, tienden a ser de desarrollo propio o un estándar de facto establecido por un único proveedor para sus productos. Algunos ejemplos son: Zigbee, Bluetooth, WiFi, USB, SimpliciTI. Estos protocolos cubren diferentes áreas de la pila OSI. Por ejemplo, Zigbee especifica la capa de red y las superiores, mientras que WiFi solo especifica las capas de enlace de datos y física. Esta separación de funcionalidades permite también mezclar y combinar algunos protocolos.
4.0 Guía de selección
La guía de selección (Figura 4.1) ofrece orientación para elegir entre las distintas configuraciones de la arquitectura de diseño. Se hace hincapié en la selección entre celular, inalámbrico o cableado. La determinación de la configuración inalámbrica o entre conexiones cableadas digitales y/o analógicas depende de un análisis más detallado de la aplicación específica.
5.0 El ecosistema IIOT de Omega Link
El ecosistema IIOT de Omega Link es una instancia de la arquitectura de diseño IIOT, como se muestra a continuación. Como era de esperar, hay tres capas: nube, conectividad (a través de puertas de enlace) y sensores. Existen múltiples opciones para las puertas de enlace, tanto de hardware (de Omega y Avnet) como de software (OEG). Los sensores vienen en múltiples formatos, con conexiones tanto cableadas como inalámbricas. Se utilizan protocolos estándar seguros, que incluyen la autenticación y la autorización entre capas y dispositivos. Los protocolos aprovechan AMQP y SimpliciTI para permitir la configuración plug and play con productos compatibles con el ecosistema.
6.0 Referencias
Arquitectura de referencia de Microsoft Azure IoT, versión 2.1, 26/9/2018.
http://www.steves-internet-guide.com/internet-protocol-suite-explained/
http://www.steves-internet-guide.com/iot-messaging-protocols/
https://www.postscapes.com/internet-of-things-protocols/
Anexo A. Seguridad del IIOT
Las soluciones de IIOT deben ser fiables para proporcionar datos e información con integridad, ya que supervisan y miden sistemas y entornos críticos. Esa confianza se verifica garantizando que el sistema sea seguro frente a las amenazas. El modelado de amenazas es el mejor enfoque para diseñar la seguridad. Utilizando una configuración típica de solución de Internet Industrial de las Cosas (IIOT), podemos identificar varias zonas (Figura A.1). Los límites de estas zonas son los puntos en los que los datos y la información pasan de un elemento de la solución a otro. Las amenazas se producirán en los límites de estas zonas. Para realizar el análisis de amenazas, podemos utilizar el modelo STRIDE, que define las amenazas según las categorías que se indican en la tabla siguiente.
Una explicación detallada del uso del modelo STRIDE queda fuera del alcance de esta guía; sin embargo, la seguridad de una solución IIOT debe validarse utilizando este método o su equivalente en cada una de las zonas de la figura A.1.
¿Qué son los motores paso a paso y los controladores? – Omega Engineering Introducción a los motores paso a paso
