Una taxonomía para el IIoT

Los reyes juegan al ajedrez en taburetes de vidrio fino. ¿Alguien recuerda esto?

Para la mayoría, eso probablemente sea un galimatías. Pero no para mí. Este mnemónico me ayuda a recordar la taxonomía de la vida:reino, filo, clase, orden, familia, género, especie.

La amplitud, profundidad y variedad de la vida en la Tierra es abrumadora. Una taxonomía divide lógicamente los tipos de sistemas por sus características. La ciencia de la biología sería imposible sin una buena taxonomía. Permite a los científicos clasificar plantas y animales en tipos lógicos, identificar puntos en común y construir reglas para comprender clases enteras de sistemas vivos.

La amplitud, profundidad y variedad del Internet industrial de las cosas (IIoT) también es abrumadora. La ciencia de los sistemas IIoT necesita una taxonomía organizada de manera similar de tipos de aplicaciones. Solo entonces podremos proceder a discutir las arquitecturas y tecnologías apropiadas para implementar sistemas.

El primer problema es elegir divisiones de nivel superior. En el Reino Animal, la mayoría de los animales se pueden etiquetar como animales "terrestres, marinos o aéreos". Sin embargo, esas descripciones ambientales no ayudan mucho a comprender al animal. La "arquitectura" de una ballena no se parece mucho a un pulpo, pero se parece mucho a un oso. Para ser entendido, los animales deben dividirse por sus características y arquitectura.

Tampoco es útil dividir las aplicaciones por sus industrias como "médico, transporte y energía". Si bien estos entornos son importantes, las arquitecturas y tecnologías aplicables simplemente no se dividen a lo largo de las líneas de la industria. Aquí nuevamente, necesitamos una comprensión más profunda de las características que definen los principales desafíos, y esos desafíos determinarán la arquitectura.

Me doy cuenta de que esta es una afirmación poderosa, incluso impactante. Implica, por ejemplo, que los estándares, protocolos y arquitecturas personalizados en cada industria no son formas útiles de diseñar las futuras arquitecturas de los sistemas IIoT . No obstante, es un hecho claro de los sistemas en el campo. Al igual que en la transformación que se convirtió en la Internet empresarial, las tecnologías genéricas reemplazarán los enfoques con fines especiales. Para aumentar nuestra comprensión y hacer realidad la promesa del IIoT, debemos abandonar nuestro antiguo pensamiento específico de la industria.

Entonces, ¿qué podemos usar para las divisiones? ¿Qué características definitorias podemos usar para separar a los mamíferos de los reptiles de los insectos del IIoT?

Hay miles y miles de requisitos, tanto funcionales como no funcionales, que podrían utilizarse. Al igual que en los animales, necesitamos encontrar esos pocos requisitos que dividen el espacio en categorías importantes y útiles.

La tarea se simplifica al darse cuenta de que el objetivo es dividir el espacio para que podamos determinar la arquitectura del sistema . Por lo tanto, los buenos criterios de división son a) inequívocos yb) impactantes en la arquitectura. Puede parecer fácil, pero en realidad no es trivial. La única forma de hacerlo es a través de la experiencia. Estamos al principio de nuestra búsqueda. Sin embargo, el progreso significativo está a nuestro alcance colectivo.

De la amplia experiencia de RTI con casi 1000 aplicaciones IIoT del mundo real, sugiero algunas divisiones tempranas a continuación. Para ser lo más nítido posible, también elegí "métricas" para cada división. Las líneas, por supuesto, no son tan duras. Pero los números fuerzan la claridad, y eso es fundamental; sin varas de medir numéricas (¿métricas?), el significado se pierde con demasiada frecuencia.

Propuesta de taxonomía IIoT

Fiabilidad [Métrica:la disponibilidad continua debe ser mejor que "99,999%"]

No podemos estar satisfechos con el tópico de "altamente confiable". Casi todo "necesita" eso. Para ser significativo, debemos ser más específicos acerca de las demandas arquitectónicas para lograr esa confiabilidad. Eso requiere comprender qué tan rápido una falla causa problemas y qué tan graves son esos problemas.

Hemos descubierto que la forma más sencilla y útil de clasificar la confiabilidad es preguntar:"¿Cuáles son las consecuencias de una falla inesperada durante 5 minutos al año?" (Elegimos 5 min / año aquí solo porque esa es la especificación de oro “5-9s” para servidores de clase empresarial. Muchos sistemas industriales no pueden tolerar ni siquiera unos pocos milisegundos de tiempo de inactividad inesperado).

Esta es una característica importante porque tiene un gran impacto en la arquitectura del sistema. Un sistema que no puede fallar, incluso por poco tiempo, debe admitir computación, sensores, redes y más redundantes. Cuando la confiabilidad es verdaderamente crítica, rápidamente se convierte en un impulsor arquitectónico clave, o quizás en el factor clave.

Tiempo real [Métrica:Respuesta <100 ms]

Hay miles de formas de caracterizar el "tiempo real". Todos los sistemas deben ser "rápidos". Pero para ser útil, debemos comprender específicamente qué requisitos de velocidad impulsan la arquitectura.

Una arquitectura que pueda satisfacer a un usuario humano que no esté dispuesto a esperar más de 8 segundos para un sitio web nunca satisfará a un control industrial que debe responder en 2ms. Encontramos que el “codo en la curva” que impacta en gran medida el diseño ocurre cuando la velocidad de respuesta se mide en unas pocas decenas de milisegundos (ms) o incluso microsegundos (µs). Elegiremos 100 ms, simplemente porque se trata de la fluctuación potencial (latencia máxima) impuesta por un servidor o corredor en la ruta de datos. Los sistemas que responden mucho más rápido que esto generalmente deben ser peer-to-peer, y eso es un gran impacto arquitectónico.

Escala del conjunto de datos [Métrica:Tamaño del conjunto de datos> 10,000 elementos]

Nuevamente, hay miles de dimensiones para escalar, incluida la cantidad de "nodos", la cantidad de aplicaciones, la cantidad de elementos de datos y más. No podemos dividir el espacio por todos estos parámetros. En la práctica, están relacionados. Por ejemplo, un sistema con muchos elementos de datos probablemente tenga muchos nodos.

A pesar del amplio espacio, hemos descubierto que dos preguntas simples se correlacionan con los requisitos arquitectónicos. El primero es el "tamaño del conjunto de datos", y el codo en la curva es de aproximadamente 10k elementos. Cuando los sistemas se vuelven tan grandes, ya no es práctico enviar todas las actualizaciones de datos a todos los receptores posibles. Por lo tanto, administrar los datos en sí se convierte en una necesidad arquitectónica clave. Estos sistemas necesitan un diseño "centrado en los datos" que modele explícitamente los datos, permitiendo así el filtrado y la entrega selectivos.

Escala de aplicaciones o equipos [Métrica:número de equipos o aplicaciones que interactúan> 10]

El segundo parámetro de escala que elegimos es el número de equipos o aplicaciones desarrolladas independientemente en el "proyecto", con un punto de interrupción de alrededor de 10. Cuando muchos grupos independientes de desarrolladores crean aplicaciones que deben interactuar, el control de la interfaz de datos domina el desafío de la interoperabilidad. Nuevamente, esto a menudo indica la necesidad de un diseño centrado en datos que modele y administre explícitamente estas interfaces.

Desafío de descubrimiento de datos de dispositivos [Métrica:> 20 tipos de dispositivos con conjuntos de datos de múltiples variables]

Algunos sistemas IIoT pueden (o incluso deben) configurarse y comprenderse antes del tiempo de ejecución. Esto no significa que se conozcan todas las fuentes y sumideros de datos, sino solo que esta configuración es relativamente estática.

Sin embargo, cuando los sistemas IIoT integran racks y racks de máquinas o dispositivos, a menudo deben configurarse y comprenderse durante el funcionamiento. Por ejemplo, una HMI de controlador de planta puede necesitar descubrir las características del dispositivo de un dispositivo instalado o bastidor para que un usuario pueda elegir los datos a monitorear. La elección de "20" dispositivos diferentes es arbitraria. El punto:cuando hay muchas configuraciones diferentes para los dispositivos en un rack, esta "introspección" se convierte en una necesidad arquitectónica importante para evitar la gimnasia manual. La mayoría de los sistemas con esta característica tienen muchos más de 20 tipos de dispositivos.

Enfoque de distribución [métrica:distribución> 10]

Definimos "abanico" como el número de destinatarios de datos que deben ser informados sobre el cambio de un solo elemento de datos. Esto afecta la arquitectura porque muchos protocolos funcionan a través de conexiones individuales 1:1. La mayor parte del mundo empresarial funciona de esta manera, a menudo con TCP, un protocolo de sesión 1:1. Los ejemplos incluyen la conexión de un navegador a un servidor web, una aplicación de teléfono a un backend o un banco a una compañía de tarjetas de crédito.

Sin embargo, los sistemas IIoT a menudo necesitan distribuir información a muchos más destinos. Si un solo elemento de datos debe ir a muchos destinos, la arquitectura debe admitir múltiples actualizaciones eficientes. Cuando el abanico excede 10 aproximadamente, no es práctico hacer esta ramificación administrando un conjunto de conexiones 1:1.

Enfoque de la colección [Métrica:flujo de datos unidireccional con entrada de ventilador>

[1] [2] 下一页

Mapeo arquitectónico dentro de Internet industrial Conectividad de datos en la arquitectura de referencia de Internet industrial