ES2908461T3 - Arquitectura de red industrial definida por software para despliegue en un sistema de automatización definido por software - Google Patents

Arquitectura de red industrial definida por software para despliegue en un sistema de automatización definido por software Download PDF

Info

Publication number
ES2908461T3
ES2908461T3 ES17748474T ES17748474T ES2908461T3 ES 2908461 T3 ES2908461 T3 ES 2908461T3 ES 17748474 T ES17748474 T ES 17748474T ES 17748474 T ES17748474 T ES 17748474T ES 2908461 T3 ES2908461 T3 ES 2908461T3
Authority
ES
Spain
Prior art keywords
network
industrial
controller
software
sdn
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17748474T
Other languages
English (en)
Inventor
Alen Mehmedagic
Vijay Vallala
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Schneider Electric Industries SAS
Original Assignee
Schneider Electric Industries SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Schneider Electric Industries SAS filed Critical Schneider Electric Industries SAS
Application granted granted Critical
Publication of ES2908461T3 publication Critical patent/ES2908461T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H04L63/0218—Distributed architectures, e.g. distributed firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/149—Network analysis or design for prediction of maintenance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)

Abstract

Una red industrial definida por software que tiene una arquitectura para la gestión centralizada de la red industrial definida por software, comprendiendo la red industrial definida por software: un plano de infraestructura (520) que incluye dispositivos físicos y virtuales conectados a la red industrial definida por software; un plano de control (515) que comprende una pluralidad de controladores para controlar y gestionar los dispositivos físicos y virtuales en el plano de infraestructura hacia el sur, incluyendo la pluralidad de controladores un controlador de red definido por software (555), SDN, un controlador de gestión de la virtualización y un controlador de ciberseguridad (560), en la que el controlador de gestión de la virtualización está adaptado para utilizar una Interfaz de Programación de Aplicaciones, API, del controlador SDN para emitir comandos al controlador SDN para crear, configurar y rellenar tablas de reenvío de conmutadores de una base de datos de conmutadores virtuales de múltiples capas; un plano de aplicación (505) que comprende una o más aplicaciones industriales; y un plano de plataforma (510) que comprende un conjunto de servicios de software e interfaces de programación de aplicaciones, API, en la que el conjunto de servicios de software incluye una aplicación de red industrial definida por software, ISDNA (540), que proporciona interfaces de comunicación al plano de aplicación al norte y al plano de control al sur, las interfaces de comunicación adaptadas para proporcionar, a una aplicación industrial en el plano de aplicación, acceso programático a uno o más de la pluralidad de los controladores en el plano de control para la gestión centralizada de la red industrial definida por software.

Description

DESCRIPCIÓN
Arquitectura de red industrial definida por software para despliegue en un sistema de automatización definido por software
ANTECEDENTES
Las redes de comunicación (o simplemente redes) permiten la comunicación de datos. La comunicación de datos puede darse entre ordenadores, ordenadores y periféricos y otros dispositivos. Las redes industriales se diferencian de las redes de comunicación tradicionales porque se encargan del control y la supervisión de procedimientos físicos que a menudo se desarrollan en entornos difíciles, con limitaciones de tiempo real e integridad de los datos, y con la expectativa de una operación continua y fiable por razones de seguridad y otras. Las redes de comunicación industrial típicamente están basadas en tecnologías/protocolos de comunicación tal como: Ethernet, Modbus, ControlNet, DeviceNet, y similares. Tales sistemas pueden ser conocidos, por ejemplo, por "Security implications of Software Defined Networking in Industrial Control Systems", de G. Kalman en Proceedings of the tenth international multiconference on computing in the global information technology (iccgi 2015) of October 11,2015; o de "Applicability of Software Defined Networking in Industrial Ethernet", 201422nd Telecommunications forum Telfor, pages 340-343, of November 1st, 2014.
Aunque las redes industriales han permitido conectar casi todos los elementos en la planta de una fábrica y han mejorado enormemente la integridad de los datos y la precisión de las señales, siguen siendo relativamente estáticas. Por ejemplo, cualquier modificación, aunque sea menor, requiere la atención de un ingeniero de redes. Además, es el ingeniero de redes quien diseña, despliega y define las limitaciones de la red. Por ello, un desarrollador de aplicaciones industriales tiene que convivir con las decisiones de diseño y las consiguientes características de la red. Esta dependencia de la red hace que los desarrolladores de aplicaciones industriales se vean a menudo limitados por la red cuando desarrollan aplicaciones industriales.
Los procedimientos de automatización industrial son cada vez más grandes y sofisticados, con más requisitos de datos. Por ello, no es de extrañar que las redes industriales que soportan estos procedimientos también sean cada vez más difíciles y complejas. Esto plantea retos en cuanto a la gestión de esas redes industriales. Estos retos se ven agravados por la falta de centralización de los elementos de control de la red, lo que hace que la gestión de la red industrial sea muy compleja. En un entorno de este tipo, tareas como la configuración de la red de acuerdo con las políticas y la reconfiguración de la red en respuesta a cambios, fallos u otros parámetros de operación se vuelven muy difíciles, requieren mucho tiempo y tienen un coste prohibitivo. Para empeorar las cosas, el tiempo de inactividad de la fábrica se hace inevitable al realizar estas tareas, lo que conlleva pérdidas financieras.
SUMARIO DE LA INVENCIÓN
Un objeto de la invención es aliviar los problemas mencionados anteriormente. En un aspecto, la invención se refiere a una red industrial definida por software de acuerdo con la reivindicación 1. En otro aspecto, la invención se refiere a un procedimiento para la gestión centralizada de una red industrial definida por software ISDN, de acuerdo con la reivindicación 9. Otras realizaciones se definen en las reivindicaciones dependientes.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La FIG. 1A es un diagrama de bloques que ilustra redes tradicionales en comparación con redes definidas por software ("SDN").
La FIG. 1B es un diagrama de bloques que ilustra la implementación de un dispositivo de red tradicional en comparación con la implementación de un dispositivo s Dn .
La FIG. 2 es un diagrama de bloques que ilustra una arquitectura simplificada de un sistema de automatización definido por software ("SDA").
La FIG. 3 es un diagrama de bloques que ilustra la arquitectura funcional de un sistema SDA.
La FIG. 4A es un diagrama de bloques que ilustra los subsistemas de un sistema SDA.
La FIG. 4B es un diagrama de bloques que ilustra el ámbito de control de cada subsistema SDA de la FIG.
4A.
La FIG. 5A es un diagrama de bloques que ilustra la arquitectura SDN industrial en planos de acuerdo con algunas realizaciones.
La FIG. 5B es un diagrama de bloques que ilustra la SDN industrial en capas de acuerdo con algunas realizaciones.
La FIG. 5C es un diagrama de bloques que ilustra la arquitectura de diseño del sistema SDN industrial de acuerdo con algunas realizaciones.
La FIG. 6A es un diagrama de bloques que ilustra el dominio de control de la SDN.
La FIG. 6B es un diagrama de bloques que ilustra las redes SDA.
La FIG. 6C es un diagrama de bloques que ilustra una red virtualizada.
La FIG. 6D es un diagrama de bloques que ilustra el dominio de control de la SDN industrial. La FIG. 7A es un diagrama de bloques que ilustra la arquitectura SDN que comprende tres planos. La FIG. 7B es un diagrama de bloques que ilustra un ejemplo de integración entre un controlador en la Niebla y un controlador SDN de acuerdo con algunas realizaciones.
La FIG. 7C es un diagrama de bloques que ilustra una arquitectura de aplicación de red industrial definida por software ("ISDNA") de acuerdo con algunas realizaciones.
La FIG. 7D es un diagrama de bloques que ilustra una arquitectura de servicio de topología de acuerdo con algunas realizaciones.
La FIG.7E es un diagrama de bloques que ilustra componentes de ejemplo de un agente controlador de SDN de acuerdo con algunas realizaciones.
La FIG.8 es un diagrama de bloques que ilustra la provisión y la puesta en marcha de un dispositivo industrial en una red SDN industrial de acuerdo con algunas realizaciones.
La FIG. 9A es un diagrama de bloques que ilustra la creación de una aplicación industrial de ejemplo de acuerdo con algunas realizaciones.
La FIG. 9B es un diagrama de bloques que ilustra una vista de conectividad de funciones industriales de la aplicación industrial de ejemplo de la FIG. 9A.
La FIG. 9C es un diagrama de bloques que ilustra una vista de conectividad de tráfico industrial de la aplicación industrial de ejemplo de la FIG. 9A.
La FIG. 9D es un diagrama de bloques que ilustra una vista de conectividad física industrial de la aplicación industrial de ejemplo de la FIG. 9A.
La FIG. 9E es un diagrama de bloques que ilustra una vista de conectividad lógica industrial de la aplicación industrial de ejemplo de la FIG. 9A.
La FIG. 9F es un diagrama de bloques que ilustra toda la vista de conectividad de la aplicación industrial de ejemplo de la FIG. 9A.
La FIG. 10 es un diagrama de bloques que ilustra las vistas de red de ISDNA en el cual cada vista proporciona un nivel de información adecuado a los intereses de un grupo de usuarios específico.
La FIG. 11A es un diagrama de bloques que ilustra los componentes de supervisión y análisis en una SDN industrial operativa de acuerdo con algunas realizaciones.
La FIG. 11B es un diagrama de bloques que ilustra un primer ejemplo de propagación de un fallo de red a través de los distintos niveles de red de una SDN industrial operativa de acuerdo con algunas realizaciones. La FIG. 11C es un diagrama de bloques que ilustra un segundo ejemplo de propagación de un fallo de red a través de los distintos niveles de red de una SDN industrial operativa de acuerdo con algunas realizaciones. La FIG. 11D es un diagrama de bloques que ilustra un tercer ejemplo de propagación de un fallo de red a través de los distintos niveles de red de una SDN industrial operativa de acuerdo con algunas realizaciones. La FIG. 12 es un diagrama de bloques que ilustra un ejemplo de implementación de una fábrica como servicio de acuerdo con algunas realizaciones.
La FIG. 13A es un diagrama de bloques que ilustra componentes de ejemplo de una aplicación de análisis en una SDN industrial de acuerdo con algunas realizaciones.
La FIG. 13B es un diagrama de bloques que ilustra un mapa de objetos que representa en tiempo real la conectividad entre los objetos, para supervisar y analizar los problemas de congestión en la SDN industrial de acuerdo con algunas realizaciones.
La FIG. 13C es un diagrama de bloques de las tendencias de la actividad mes a mes, día a día y hora a hora.
La FIG. 13D es un diagrama que ilustra la disminución de la productividad de un producto en función del tiempo utilizando una función de densidad exponencial.
La FIG. 13E es una tabla que muestra la probabilidad de que un producto falle en función de los años.
La FIG. 14 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para simplificar el despliegue y el mantenimiento de la infraestructura de red en un dominio industrial de acuerdo con algunas realizaciones.
La FIG. 15 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para simplificar la gestión de una red industrial de acuerdo con algunas realizaciones.
La FIG. 16 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la gestión centralizada de una red industrial de acuerdo con algunas realizaciones.
La FIG. 17 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la supervisión centralizada y la elaboración de informes de una red industrial operativa.
La FIG. 18 muestra una representación diagramática de una máquina en la forma de ejemplo de un sistema informático dentro del cual puede ejecutarse un conjunto de instrucciones, para hacer que la máquina realice una o más de las metodologías discutidas en la presente memoria .
DESCRIPCIÓN DETALLADA
Esta divulgación describe una arquitectura de una Red Definida por Software (SDN) para un entorno industrial ("SDN industrial") y el despliegue de la SDN industrial en un sistema de Automatización Definido por Software ("SDA").
La arquitectura SDN industrial desvelada en la presente memoria es una mejora de la arquitectura SDN tradicional. Si bien la arquitectura SDN industrial ofrece muchas de las ventajas de la arquitectura SDN tradicional, también proporciona beneficios adicionales, tal como brindar a los desarrolladores de aplicaciones industriales acceso directo a la red, lo que les permite (1) diseñar aplicaciones de control industrial sin estar limitados por el diseño de la red, y (2) programar y supervisar la red y utilizar la información sobre los eventos de la red no sólo para mantener la red, sino también para gestionar las operaciones industriales.
La SDN industrial desplegada en un sistema SDA mejora aún más el sistema SDA a través de una aplicación de SDN industrial que permite al sistema automatizar tareas que normalmente requieren una gran cantidad de experiencia en redes, planificación y tiempo. Por ejemplo, proporcionar y poner en marcha dispositivos en una red industrial es una tarea que suele requerir la intervención de un ingeniero de redes. El sistema SDA desplegado con la SDN industrial desvelado en la presente memoria ("sistema SDA") puede proporcionar y poner en marcha de forma segura los dispositivos de acuerdo con las políticas de red y de seguridad cuando los dispositivos se conectan por primera vez a la red, sin necesidad de un ingeniero de red o de cualquier usuario.
Con el fin de apreciar plenamente las características y beneficios de la arquitectura SDN industrial, y el sistema SDA desplegado con la s Dn industrial, se proporciona a continuación una breve descripción de la arquitectura SDN tradicional y del sistema SDA.
1. Visión general de la SDN
La SDN es una arquitectura de red en la que el sistema que toma las decisiones sobre hacia qué lugar se envía el tráfico (es decir, el plano de control) está desacoplado de los sistemas subyacentes que reenvían el tráfico al destino seleccionado (es decir, el plano de datos). En términos sencillos, la SDN hace que la red sea programable. Con la SDN, los administradores de red pueden gestionar los servicios de red mediante la abstracción de la funcionalidad de nivel superior.
La arquitectura SDN es una arquitectura en capas basada en tres principios básicos:
(1) Desacoplamiento de los planos de control y de datos: Este principio permite separar la evolución del mecanismo de reenvío del control de los recursos de la red. En otras palabras, el control de la red opera sobre mecanismos de reenvío abstraídos que permiten que los elementos de la red se conviertan en una mercancía.
(2) Control lógicamente centralizado: Desde el punto de vista de la SDN, un controlador es un orquestador de elementos de red. El control lógicamente centralizado se refiere a una visión de la infraestructura de red como una entidad holística, dando al controlador SDN un control global sobre todos los recursos de la red, es decir, el controlador se comporta como una entidad central de gestión y control.
(3) Exposición de los recursos y el estado de la red abstracta a las aplicaciones externas: La red como función virtual es el principal motor de este principio. La separación de los planos de control y de datos permite al controlador SDN proporcionar una abstracción de la red a otros controladores o aplicaciones, lo que supone una abstracción recursiva de las redes y sus elementos.
Por referencia a la FIG. 1A, la arquitectura de red tradicional comprende dispositivos de red dedicados 102 como, pero no limitados a: enrutadores, conmutadores, cortafuegos, y similares, proporcionados por varios vendedores. Cada dispositivo de red 102 incluye un plano de control que soporta varios protocolos y un plano de datos 108. Esta infraestructura de red de múltiples proveedores garantiza que cada dispositivo 102a, 102b y 102c se gestione individualmente mediante la interfaz propietaria del proveedor 104a, 104b y 104c respectivamente, lo que hace que la provisión, el mantenimiento y la retirada del servicio sean extremadamente lentos y costosos. El uso de hardware especializado y, en ocasiones, de protocolos personalizados, garantiza que la implementación y la disponibilidad de las funciones de red sean dictadas por los proveedores. También sigue el modelo de empresa y el ciclo de vida de los productos del proveedor, más que las necesidades de despliegue de la red.
A diferencia de las redes tradicionales, la SDN se caracteriza por desacoplar las funciones de control y reenvío de la red. El control o la inteligencia de la red se centraliza lógicamente en un controlador SDN 120, que permite a los administradores de la red ajustar dinámicamente el flujo de tráfico de toda la red para satisfacer las necesidades cambiantes. Además, aunque los controladores de SDN basados en software mantienen una visión global de la red, ésta aparece ante las aplicaciones, los motores de políticas y/u otras entidades 112 como una entidad única y lógica. Cuando se implementa a través de estándares abiertos, la SDN simplifica el diseño y la operación de la red porque las instrucciones son proporcionadas por los controladores 120 de la SDN en lugar de por múltiples dispositivos y protocolos específicos de cada proveedor. Cada uno de los dispositivos de red 114a y el dispositivo de red virtualizado (por ejemplo, Open vSwitch) 114b comprenden el plano de datos responsable de reenviar el tráfico.
Por referencia a la FIG. 1B, en un dispositivo de red típico 102, como un enrutador o un conmutador, toda la inteligencia está en el propio dispositivo. El dispositivo 102 suele estar implementado en tres planos: plano de datos 108a, plano de control 106a y plano de gestión 116a. El plano de datos 108 es la capa responsable de mover los paquetes, y normalmente se implementa en hardware propietario del proveedor con metodología de reenvío fija y requiere una aplicación/configuración propietaria 104. El plano de control 106a es la capa responsable de la toma de decisiones de reenvío y de los intercambios de éstas con otros dispositivos. Puede implementarse en hardware y/o firmware (microprograma) con protocolos y características específicas del proveedor. Este tipo de implementación conlleva la existencia de dispositivos de red complejos y dedicados. El plano de gestión 116a es la capa que proporciona una interfaz de gestión, y suele implementarse como software en forma de interfaz de línea de comandos (CLI). La implementación de la CLI es específica del proveedor y, por lo tanto, es difícil de automatizar en un entorno de múltiples proveedores.
A diferencia de las redes tradicionales, el enfoque principal de la SDN es la separación del plano de control y del plano de datos y su conexión, normalmente, con un protocolo abierto. Este enfoque permite que los protocolos y requisitos del plano de control se desplieguen por separado del plano de datos, creando así una apertura para la generalización.
En una implementación del dispositivo 114 de SDN, el plano de control puede ser implementado en una CPU de propósito general, reduciendo así la complejidad del hardware de red y eliminando la compleja implementación de protocolos en el firmware. Además, el plano de control ya no está vinculado a un dispositivo de red específico, por lo que es posible consolidar los planos de control de todos los dispositivos. Esta consolidación es lo que se conoce como el controlador SDN 155. Es el controlador SDN 155 que proporciona inteligencia de red centralizada y permite una visión holística de la red. El plano de gestión 116b en un dispositivo SDN 114 es la propia aplicación SDN 112. Esta es la parte programable de la SDN y su objetivo es proporcionar libertad de gestión de la red y diseños específicos para las necesidades de la red de los usuarios.
Uno de los protocolos más comunes utilizados por un controlador SDN 155 para programar el hardware del plano de datos subyacente 108b es OpenFlow (OF). OpenFlow es un estándar neutral en cuanto a proveedores. Un aspecto de la SDN basada en OpenFlow es que el plano de datos 108b opera sobre flujos en lugar de tablas de búsqueda estáticas como la tabla MAC en los conmutadores o las tablas de enrutamiento en los enrutadores. Los flujos en SDN se describen mejor como reglas de coincidencia de patrones utilizadas para la conmutación de paquetes. El principio de reducir la complejidad de los protocolos de control a un solo protocolo y permitir las búsquedas basadas en el flujo utilizando una memoria de alta velocidad como la memoria ternaria direccionable por contenido (TCAM) es lo que puede conducir a la simplificación de los dispositivos de infraestructura y al uso de hardware mercantilizado como dispositivos de red.
2. Automatización Definida por Software (SDA)
SDA proporciona una arquitectura de referencia para diseñar, gestionar y mantener un sistema de automatización altamente disponible, escalable y flexible. En algunas realizaciones, la tecnología SDA permite que el sistema o sistemas de control y el software asociado se ejecuten dentro de una plataforma de niebla o una nube privada. Se pueden encontrar sistemas de control de diversos grados de complejidad en instalaciones de fabricación tradicionales, refinerías, submarinos, vehículos, túneles, sistemas de manipulación de equipajes, sistemas de gestión de la energía, sistemas de gestión de edificios, sistemas de control de aguas de inundación, sistemas de control de la red eléctrica y similares. Al trasladar todo el sistema o sistemas de control, o al menos una parte de ellos, a una plataforma de niebla o a una nube privada, y proporcionar una interfaz de software a los elementos del sistema de control, la tecnología SDA permite realizar las tareas de ingeniería de todo el ciclo de vida de la ingeniería de automatización, como el diseño, la programación, la configuración, la instalación, el operación, el mantenimiento, la evolución y el apagado, de una forma más sencilla, eficiente y rentable.
I. Arquitectura Simplificada
La FIG. 2 es un diagrama que ilustra una arquitectura simplificada de un sistema SDA de acuerdo con algunas realizaciones. La arquitectura representa un servidor de niebla 222 vinculado a un software de sistema 224, y dispositivos inteligentes conectados 228A, 228B que están acoplados de manera comunicativa al servidor de niebla 222 y al software de sistema 224 a través de una red troncal de comunicaciones 226. La arquitectura también representa que al menos algunos dispositivos inteligentes conectados 228B y el servidor de niebla 222 pueden estar acoplados de manera comunicativa a una nube 218.
El servidor de niebla 222 está compuesto por una colección de recursos de control y recursos informáticos que están interconectados para crear un sistema lógicamente centralizado pero potencialmente distribuido físicamente para alojar los sistemas de automatización de una empresa. El "servidor de niebla" o la "plataforma de niebla", tal y como se utiliza en la presente memoria, es un sistema de gestión de la nube (o subsistema localizado o sistema localizado o plataforma de gestión de la virtualización) que se ha localizado en uno o más nodos informáticos y/o control. En otras palabras, el servidor de niebla 222 es una tecnología en la nube que se ha bajado al terreno o instalación local (de ahí el término "niebla") en forma de uno o más nodos informáticos y/o control para gestionar todo el sistema de automatización o una parte del mismo. El servidor de niebla 222 permite la virtualización al proporcionar una infraestructura de virtualización en la que se puede ejecutar y/o gestionar el sistema o sistemas de automatización. La infraestructura de virtualización incluye nodos informáticos que ejecutan huéspedes tal como máquinas virtuales, recipientes y/o metales desnudos (o imágenes de metal desnudo). Los huéspedes, a su vez, pueden ejecutar invitados que incluyen aplicaciones y/o implementaciones de software de componentes físicos o unidades funcionales y un portal de automatización o software del sistema 224. Tal y como se utiliza en la presente memoria, la virtualización es la creación de una versión virtual de algo. Por ejemplo, un componente virtual o un componente virtualizado (por ejemplo, un PLC virtual, un conmutador virtual, virtualización de funciones de red (NFV)) representa una función que se ejecuta en un huésped que se ejecuta en un nodo informático. No tiene una existencia física por sí misma. El servidor de niebla 222 no tiene por qué estar localizado en una sala de control centralizada; los controladores, dispositivos y/o servidores 232 cercanos a los sensores y accionadores (por ejemplo, dispositivo IO, dispositivo integrado) también pueden considerarse bajo la gestión del servidor de niebla 222. En algunas realizaciones, el servidor de niebla 222 también puede agregar, almacenar y/o analizar datos, y/o informar de los datos o análisis a la nube 218. La nube 218 puede ser una nube empresarial (es decir, una nube privada), una nube pública o una nube híbrida. El software del sistema 224 proporciona un único punto de entrada para que un usuario final defina (por ejemplo, diseñar, proveer, configurar, y similares) el sistema de automatización. Una forma de definir el sistema de automatización es gestionando la distribución de las aplicaciones/funciones de la aplicación donde los usuarios quieren que se ejecuten.
Los dispositivos conectados inteligentes 228A, 228B (también productos conectados inteligentes) supervisan y/o controlan dispositivos, sensores y/o accionadores cercanos a los equipos/materias primas/entorno mediante la ejecución de aplicaciones/funciones de aplicación. En varias realizaciones, un dispositivo inteligente conectado tiene las siguientes características: (1) los componentes físicos y eléctricos, (2) el firmware o una parte "inteligente" incorporada, y (3) la conectividad y la interoperabilidad. En algunas realizaciones, un dispositivo inteligente conectado puede tener también un componente de ciberseguridad que puede funcionar de forma remota o a bordo.
Algunos dispositivos inteligentes conectados 228A pueden ejecutar aplicaciones o funciones de aplicación ("aplicaciones") localmente (por ejemplo, el bucle de regulación de velocidad/par de un variador de velocidad) porque tienen la capacidad de procesamiento para hacerlo. Esto significa que no es necesario ejecutar esas aplicaciones en otro lugar (por ejemplo, en un PC conectado, en un servidor o en otros dispositivos informáticos) para obtener datos que permitan realizar sus funciones. Esto tiene la ventaja de un tiempo de respuesta más rápido (es decir, menos latencia) y un ahorro en el ancho de banda de la red. Otra ventaja de la ejecución local o a bordo de las aplicaciones es que mejora la consistencia de los datos y la robustez de la arquitectura, ya que el dispositivo puede seguir produciendo información (por ejemplo, alarmas) o registrando datos aunque la red esté caída.
En algunas realizaciones, los dispositivos inteligentes conectados 228B pueden ser ejecutados total o parcialmente en uno o más servidores (por ejemplo, el servidor 232, el servidor de niebla 222). Por ejemplo, un dispositivo inteligente conectado 228B puede responder a señales remotas (por ejemplo, llamadas a procedimientos remotos, interfaz de programación de aplicaciones o llamadas API) como si una aplicación se ejecutara localmente, cuando en realidad la aplicación se ejecuta remotamente, por ejemplo en el servidor de niebla 222. En algunas realizaciones, los dispositivos inteligentes conectados pueden capturar datos en tiempo real sobre su propio estado y el estado de su entorno (por ejemplo, los dispositivos siendo supervisados) y enviar dichos datos al servidor de niebla 222 y/o a una nube remota 218. En algunas realizaciones, los dispositivos inteligentes conectados 228A, 228B pueden transformar los datos capturados en tiempo real en información (por ejemplo, alarmas), almacenarlos y realizar análisis operativos sobre ellos. Los dispositivos inteligentes conectados 228A, 228B pueden entonces combinar las funciones de supervisión y control descritas anteriormente para optimizar su propio comportamiento y estado.
La red troncal de comunicaciones 226 facilita la interacción entre el servidor de niebla 222, el software del sistema 224 y los dispositivos inteligentes conectados 228A, 228B. La red troncal de comunicaciones (o la red troncal del Internet de las Cosas (IoT)/Internet Industrial de las Cosas (IIoT)) abarca un conjunto de arquitecturas de red y ladrillos de red que permiten las conexiones físicas y lógicas de los dispositivos inteligentes conectados 228A, 228B, el servidor de niebla 222 y cualquier otro componente que forme parte de la arquitectura SDA. Por ejemplo, los distintos equipos de una planta pueden conectarse entre sí y con el sistema de la empresa (por ejemplo, MES o ERP) utilizando tecnologías basadas en diversos estándares tal como: Ethernet, TCP/IP, web y/o tecnologías de software. La red troncal de comunicaciones 226 en forma de red troncal global unificada de Ethernet Industrial puede proporcionar: un fácil acceso a los datos, desde la planta (OT) hasta las aplicaciones empresariales (IT), una forma flexible de definir diferentes tipos de arquitecturas de red (por ejemplo, estrellas, cadena tipo margarita, anillo) que se ajusten a las necesidades del cliente, una arquitectura robusta que pueda cumplir requisitos como la disponibilidad, la seguridad y el soporte de entornos difíciles y la información correcta a las personas adecuadas en el momento adecuado en un solo cable.
La red troncal de comunicaciones 226 incluye una infraestructura completa de Ethernet industrial que ofrece conmutadores, enrutadores y/o un sistema de cables para abordar las necesidades de todas las topologías. La red troncal de comunicación 226 también admite un conjunto de protocolos de conectividad basados en normas (por ejemplo, Modbus/TCP-IP, Ethernet IP, OPC UA, DHCP, FTP, SOAP, REST, etc.). La red troncal de comunicaciones 226 también puede soportar un conjunto de funciones web que ofrecen funciones como el diagnóstico, la supervisión y la configuración utilizando páginas web estándar y la arquitectura de referencia de integración de dispositivos que define los patrones, el ladrillo para integrar el grupo de dispositivos a los controladores a nivel de aplicación y a nivel de red para la configuración, el ajuste y el diagnóstico. En algunas realizaciones, los elementos de ciberseguridad pueden incorporarse a la arquitectura. La red troncal de comunicaciones 226 también se adhiere a un conjunto de reglas de arquitectura que estructuran la arquitectura a nivel de prestaciones (Calidad de Servicio o QoS), robustez (RSTP y PRP HSR para la redundancia) y seguridad (IEC61508). En algunas realizaciones, la red troncal de comunicaciones 226 también admite la integración de un conjunto de pasarelas para conectar a la red de equipos heredados (es decir, no Ethernet).
La red troncal de comunicaciones 226 puede utilizar múltiples protocolos para proporcionar múltiples servicios para satisfacer múltiples necesidades. En la tabla 1 se enumeran algunos ejemplos de necesidades de comunicación y protocolos adecuados.
Tabla 1 Servicios y Protocolos
Figure imgf000007_0001
Las redes de los sistemas existentes están muy segmentadas para permitir una comunicación garantizada o fiable. La red troncal de comunicaciones 226 en la arquitectura SDA puede superar los problemas de los sistemas existentes a través de las tecnologías de redes definidas por software (SDN) y/o redes sensibles al tiempo (TSN). Como se ha descrito anteriormente, la tecnología SDN permite separar la lógica de control de una red del hardware o dispositivo de red subyacente (por ejemplo, conmutadores, enrutadores) y la centralización lógica del control de la red. La tecnología SDN puede aportar simplicidad y flexibilidad a estas redes, permitiendo la comunicación en y a través de diferentes capas dirigidas por políticas de red. La tecnología TSN añade un conjunto de capacidades a la Ethernet estándar para proporcionar capacidad en tiempo real e intercambios con garantía de tiempo en zonas o en toda la arquitectura. Además, la solución de ciberseguridad también puede integrarse y adaptarse a la arquitectura SDA.
II. Arquitectura Funcional
En algunas realizaciones, la arquitectura SDA permite la gestión de un sistema de automatización a través de un conjunto de controladores que proporcionan la gestión de los recursos en todo el sistema. Estos controladores constituyen los recursos de control del servidor de niebla y proporcionan un procedimiento homogéneo para gestionar todo el sistema. Un administrador del sistema puede establecer una interfaz con estos nodos controladores para la configuración inicial, la ampliación del sistema, el diagnóstico, el mantenimiento, etc. De manera similar, las aplicaciones que se ejecutan en el sistema o fuera de él pueden establecer una interfaz con estos nodos controladores para gestionar facetas o funciones específicas del sistema (por ejemplo, la herramienta ICS, la herramienta de red, la herramienta del sistema eléctrico), gestionar los recursos informáticos (por ejemplo, la supervisión, la gestión de otras aplicaciones y/o recursos), y similares. Esta vista funcional de la arquitectura s Da se representa en la FIG. 3.
La vista funcional de ejemplo de un sistema SDA representado en la FIG. 3 incluye un plano de aplicación 305, un plano de control 315 y un plano de recursos 352. El plano de aplicación 305 abarca el software del sistema 334 y los componentes de software o aplicaciones 325 que se ejecutan en el sistema y que utilizan y gestionan un conjunto de recursos del sistema. El plano de control 315 incluye un conjunto de controladores que incluyen un controlador de servidor de niebla (o controlador de niebla o controlador de gestión de virtualización) 335, un controlador de red 356 y un controlador de ciberseguridad (CS) 345. Tal y como se utiliza en la presente memoria, el controlador de red 356 puede incluir un controlador SDN, un controlador TSN o un controlador TsSDN, que incorpora el dominio del tiempo en el controlador SDN. El controlador TsSDN y su función de proporcionar una comunicación determinista garantizada se describe en una Solicitud PCT relacionada Núm. PCT/EP2017/068213 presentada el 19 de julio de 2017 que se incorpora a la presente memoria en su totalidad. Estos controladores proporcionan un conjunto estandarizado de interfaces a las aplicaciones en el plano de aplicación 305 para acceder y/o gestionar los recursos en el plano de recursos 352 del sistema. En algunas realizaciones, los controladores también proporcionan diagnósticos, gestión de la disponibilidad, y similares. El controlador de red 356 puede gestionar y distribuir las políticas de red 336 a nivel de sistema. De manera similar, el controlador CS 345 puede aplicar las políticas de seguridad 338 a nivel del sistema.
En algunas realizaciones, estos controladores pueden tener una relación jerárquica entre sí. Por ejemplo, un sistema SDA puede incluir un controlador de nivel superior (no mostrado) y un conjunto de controladores centralizados (por ejemplo, el controlador de niebla 335, el controlador de red 356 y el controlador CS 555), cada uno de los cuales controla un edificio o un sitio. El controlador de nivel superior puede, por ejemplo, distribuir políticas a los controladores centralizados para que estos controlen su propio edificio o sitio. El entorno de virtualización admite la distribución jerárquica de los controladores.
El plano de recursos 352 puede incluir recursos de red 348, recursos informáticos representados por nodos informáticos 342, recursos de almacenamiento 344 y recursos de seguridad 346. El software del sistema 3.34 y las aplicaciones 325 se ejecutan en los nodos informáticos 342 gestionados por el controlador de niebla 335. Los nodos informáticos 342 que proporcionan los recursos informáticos al sistema pueden estar físicamente distribuidos y gestionados por el controlador de niebla 335. Por ejemplo, algunos nodos informáticos en forma de servidores se encuentran en el servidor de niebla o en la nube privada, mientras que otros nodos informáticos, como los dispositivos inteligentes conectados, operan en el borde. Los recursos de red 348 pueden ser recursos de red virtuales en el servidor de niebla, recursos de infraestructura física en el hardware de conmutación/enrutamiento o recursos de infraestructura ubicados en dispositivos inteligentes conectados. Los recursos de almacenamiento 344 pueden ser bases de datos y/u otros dispositivos para almacenar imágenes virtuales, volúmenes, aplicaciones, datos de procedimiento, datos de estado y similares. Los recursos de seguridad 346 pueden incluir componentes de seguridad que residen en los nodos informáticos 342, nodos de almacenamiento 344, y/o componentes independientes que proporcionan servicios de seguridad tales como la aplicación de políticas de seguridad, detección y protección de intrusos, y similares.
Los controladores orquestan y supervisan algunos o todos los recursos del sistema. Las aplicaciones que gestionan el sistema (por ejemplo, el software del sistema 540 o el portal de automatización, la herramienta de administración de la red, etc.) envían solicitudes al sistema para aplicar estrategias específicas. Por ejemplo, el software del sistema 334 puede utilizarse para desplegar un nuevo PLC conectado a un conjunto de dispositivos con requisitos específicos de red en tiempo real, requisitos de seguridad y requisitos de disponibilidad/resiliencia. En algunas realizaciones, las aplicaciones corresponden a implementaciones de software/firmware de los componentes. Estas aplicaciones pueden desplegarse en recursos informáticos y pueden utilizar recursos de almacenamiento y de red para comunicarse.
III. Sistema SDA
Un sistema SDA comprende varios subsistemas que trabajan en conjunto para proporcionar una solución totalmente integrada para crear, gestionar y operar sistemas de automatización. La FIG.4A es un diagrama de bloques que ilustra los subsistemas de un sistema SDA de acuerdo con algunas realizaciones. Un sistema SDA 400 en algunas realizaciones incluye un subsistema de servidor de niebla 454 ("servidor de niebla") que tiene un controlador de niebla o controladores de niebla redundantes 435, uno o más nodos informáticos 442 y almacenamiento 444. El sistema SDA 400 también incluye componentes de software 456. En otras realizaciones, el sistema SDA 400 puede incluir además un subsistema de ciberseguridad ("CS") 458 que tiene un controlador de seguridad o controladores de seguridad redundantes 445, componentes de seguridad físicos y/o virtualizados 461 y un repositorio de políticas de seguridad que almacena políticas de CS 438. En otras realizaciones, un sistema SDA 400 también puede incluir un subsistema de red 462 que tiene un controlador de red o controladores de red redundantes 456, una red física 463, componentes de red física 465, redes virtuales 464, componentes de red virtual 466 y un repositorio de políticas de red que almacena políticas de red 436.
El servidor de niebla 454 proporciona un entorno de virtualización en el que se puede ejecutar y/o gestionar el sistema o sistemas de automatización. El servidor de niebla 454 comprende nodos informáticos 442 que proporcionan capacidades de procesamiento lógico y pueden alojar aplicaciones, bases de datos y similares con un alto nivel de elasticidad. Los ejemplos no limitantes de nodos informáticos incluyen: servidores, ordenadores personales, dispositivos de automatización incluyendo dispositivos inteligentes conectados y similares.
El controlador del servidor de niebla 435 utiliza un software de gestión del servidor de niebla para realizar sus funciones. El software de gestión del servidor de niebla puede basarse en un software de gestión de la nube como OpenStack. El software de gestión de la nube, como OpenStack, en su forma estándar/listo para la venta, suele utilizarse en el mundo de las tecnologías de la información (TI) para la gestión de los centros de datos. Sin embargo, la gestión de los sistemas de automatización implica una serie de retos diferentes. Por ejemplo, algunos sistemas de automatización pueden ejecutar aplicaciones críticas para el tiempo y/o la seguridad que necesitan garantías deterministas con respecto al retraso, la fiabilidad y/u otros factores. La consideración de un sistema automatizado de corte de queso en el que un movimiento sincronizado de alta velocidad entre una hoja de cuchillo que corta un bloque de queso y el movimiento del bloque de queso es fundamental para producir rebanadas de queso de espesor uniforme. Si hay algún retraso en el procesamiento o en la red, puede dar lugar a que las rebanadas de queso tengan un espesor diferente, lo que supone un desperdicio y una pérdida de productividad.
El controlador del servidor de niebla 435 gestiona todos los aspectos del entorno de virtualización y el ciclo de vida completo de los nodos informáticos 442. Por ejemplo, el servidor de niebla 454 puede levantar y retirar huéspedes como máquinas virtuales, recipientes o metales desnudos en nodos informáticos, y crear y destruir componentes virtualizados 459 y redes virtuales 464. Un componente/elemento/instancia virtualizado 459, tal y como se utiliza en la presente memoria, es un equivalente lógico de un dispositivo físico o una parte del dispositivo físico que representa, implementado como una entidad de software para ejecutarse dentro del servidor de niebla 454. Los componentes virtualizados 459 también pueden incluir componentes de software como aplicaciones y/o funciones de aplicación que se ejecutan en un huésped (por ejemplo, una máquina virtual configurada con una aplicación es un componente/elemento/instancia virtualizado).
El controlador del servidor de niebla 435 puede proporcionar alta disponibilidad (HA) a través de la redundancia del controlador y la gestión de los fallos de los nodos informáticos. El controlador también puede gestionar la puesta en marcha, el apagado y la aplicación de parches de los distintos nodos informáticos. En algunas realizaciones, la plataforma de servidor de niebla puede proporcionar soporte para la alta disponibilidad de los componentes virtualizados. En algunas realizaciones, el servidor de niebla 454 puede incluir un nodo de almacenamiento o almacén de datos 444. El almacenamiento 444 puede almacenar imágenes virtuales, volúmenes (es decir, el disco duro de una imagen instada), aplicaciones y procedimientos de datos, y similares.
El subsistema de componentes de software 456 puede incluir componentes virtualizados 459 que se alojan en el ecosistema de virtualización del servidor de niebla 454. El subsistema de componentes de software 456 también puede incluir instancias virtualizadas de software 425 que se ejecutan dentro del entorno de virtualización (por ejemplo, software de programación, configuración y/o gestión (por ejemplo, Unity, SoMachine, SCADA) que se utilizan para programar, configurar, gestionar o establecer una interfaz de otro modo con los dispositivos de automatización. En algunas realizaciones, el subsistema de componentes de software 456 también puede incluir un software de sistema 434 (también llamado portal de automatización) que proporciona una interfaz única para gestionar la topología, el inventario, la configuración, la programación, el control y/o el diagnóstico de los dispositivos de automatización y/o del sistema de automatización en su conjunto.
A través del software del sistema 434 los usuarios pueden acceder a varias aplicaciones para la definición y gestión del sistema en todas las fases del ciclo de vida. Por ejemplo, el software del sistema 434 puede ser utilizado para configurar y establecer parámetros en el equipo durante la fase de ingeniería y afinar, programar y/o diagnosticar el equipo durante la fase de mantenimiento. Algunas de las ventajas del software del sistema 434 incluyen la simplicidad y facilidad para los usuarios finales y la reducción de costes, dado que todos los aspectos de cualquier equipo de un sistema de automatización pueden gestionarse desde un único portal. Además de proporcionar un único punto de entrada a todo el sistema, el software del sistema 434 también presenta una interfaz de usuario consistente y una experiencia de usuario, que ayudan a reducir la inconsistencia y aumentar la eficiencia y la productividad.
El subsistema CS 458 incluye un controlador CS asociado o controladores CS redundantes 445 y componentes de seguridad virtualizados y/o físicos 461. El subsistema de seguridad 458 proporciona una solución holística de ciberseguridad a través de políticas de seguridad y componentes de seguridad tal como sistemas de detección/protección de intrusos, cortafuegos virtualizados de nueva generación, sistemas de identificación y autoridad de certificados, y similares. El controlador CS 445 difunde las políticas de seguridad a los componentes virtualizados y/o físicos 461 para garantizar que se establezcan las protecciones de seguridad necesarias. En algunas realizaciones, el subsistema CS 458 también puede proporcionar servicios de política de seguridad y autenticación a otros componentes y subsistemas. Las políticas de seguridad del sistema CS 458 pueden almacenarse en un repositorio de políticas de seguridad 438 en algunas realizaciones.
El subsistema de red 462 incluye la infraestructura de red Ethernet para toda la solución del sistema SDA. En algunas realizaciones, el subsistema de red 462 es un subsistema de red SDN que tiene un controlador SDN o controladores SDN redundantes como el controlador de red 456. La red SDN proporciona la separación de la lógica de control de la red del hardware de red subyacente (por ejemplo, enrutadores, conmutadores) y la centralización lógica del control de la red a través del controlador SDN. Esto significa que el controlador SDN puede difundir políticas de red a través de la infraestructura de red (es decir, la red física 463 y los componentes de red física 465, así como las redes virtuales 464 y los componentes de red virtual 466) para controlar la conectividad, el ancho de banda y la latencia, los Acuerdos de Nivel de Servicio (SLA) (por ejemplo, con respecto a: tiempo de respuesta determinista/tiempo de transferencia), el control del flujo de tráfico, etc., y el hardware de red puede implementar esas políticas. Las políticas de red del subsistema de red 462 pueden almacenarse en un repositorio de políticas de red 436 en algunas realizaciones.
En algunas realizaciones, el subsistema de red 462 puede comprender una red de radio de malla. En una red de radio en malla, cada nodo puede conectarse con al menos otros dos nodos y los datos pasan de un nodo a otro en un procedimiento denominado "salto". Dado que los propios nodos hacen de enrutadores, las redes de malla de radio no suelen necesitar enrutadores designados. Sin embargo, algunas redes de radio de malla incluyen uno o más enrutadores de malla junto con los nodos de malla para retransmitir el tráfico en nombre de otros enrutadores de malla y/o nodos de malla. En algunas realizaciones, el subsistema de red 462 puede comprender circuitos virtuales en una red híbrida o de malla de radiofrecuencia (RF) de alta velocidad con comunicación facilitada únicamente por los transceptores de radio de los nodos, sin ningún dispositivo externo. Así, en algunas realizaciones, la configuración de los elementos de red del subsistema de red o de la infraestructura de red puede incluir la configuración de los nodos de malla y/o de los enrutadores de malla (por ejemplo, los enrutadores de malla habilitados para OpenFlow) en la red de radio de malla.
En algunas realizaciones, el subsistema de red 462 puede ser un subsistema de Red Sensible al Tiempo (TSN) que tiene un controlador TsSDN o ambos controladores SDN y TSN como el controlador de red 456 y una infraestructura de red que incluye dispositivos de red capaces de TSN. El subsistema de red TSN garantiza que los datos de misión crítica y sensibles al tiempo se transfieran/compartan de acuerdo con el tiempo máximo de transferencia determinista predefinido y con alta fiabilidad. En varias realizaciones, el controlador de red 456 puede ser un controlador de red virtual de servidor de niebla nativo, un controlador de sistema de gestión de red tradicional, un controlador SDN, un controlador TSN, un controlador TsSDN y/o cualquier combinación de los mismos.
Las funciones de los subsistemas de la solución SDA se complementan entre sí para proporcionar una solución totalmente integrada. Específicamente, el servidor de niebla 454 puede establecer una interfaz con cada uno de estos subsistemas a través del alojamiento de elementos virtualizados del subsistema y/o a través de las funciones de control del subsistema. Aunque el servidor de niebla 454 tiene relaciones integrales con cada uno de los subsistemas SDA, los subsistemas SDA no se consideran dentro del ámbito del servidor de niebla 454. La FIG. 4B es un diagrama que ilustra el alcance del control de cada uno de los subsistemas SDA de acuerdo con algunas realizaciones.
El ámbito del servidor de niebla 454 es el controlador de niebla 435, los nodos informáticos 442 y la gestión de los componentes virtualizados 459 dentro del servidor de niebla 605. Los componentes virtualizados 459 y el software 425 (por ejemplo, historiador, SCADA, SoMachine, Unity) no están dentro del ámbito de control del servidor de niebla 605, sino bajo el ámbito de control del subsistema de componentes de software 456. Sin embargo, los componentes de software 456, a través del portal de software/automatización del sistema 434, establece una interfaz con el controlador de niebla 435 y los nodos informáticos 442 para proporcionar entradas de configuración y control al servidor de niebla 454 y/o a otros subsistemas para impulsar su operación.
Para proporcionar una solución en todo el sistema, la continuidad del control de la red se extiende para incluir tanto los componentes virtuales como los físicos de la red. Por lo tanto, el ámbito del subsistema de red 462 incluye no sólo los componentes de red física 465 y la red física 463, sino también las redes virtuales 464 y los componentes de red virtual 466 que se crean y existen dentro del servidor de niebla 454. Esto requiere una integración total entre el subsistema de red 462 y el servidor de niebla 454 para proporcionar los mecanismos para ejercer este control. Por ejemplo, el controlador del servidor de niebla 435 puede crear las redes virtuales 464 en el servidor de niebla 454 y controlar la conectividad entre las máquinas virtuales/recipientes alojados en los nodos informáticos 442 y las redes virtuales 464, mientras que el controlador de red 456 puede configurar los componentes de red virtual 466 de las redes virtuales 464 de acuerdo con una o más políticas de red. Este nivel de integración requiere la orquestación de secuencias de etapa de instar y eliminación, ya que, evidentemente, la red virtual 464 debe existir antes de que las máquinas virtuales y los recipientes puedan conectarse.
El subsistema CS 458 tiene control sobre los componentes de seguridad, tales como los sistemas de detección de intrusos (IDS) 467, los sistemas de protección contra intrusos (IPS) 468 (por ejemplo, cortafuegos virtualizados de próxima generación) y similares, así como el controlador CS 445 que difunde las políticas de seguridad a diferentes entidades. El subsistema CS 458 puede integrarse con todos los aspectos de la solución del sistema SDA en algunas realizaciones. Por ejemplo, el controlador de red 456 puede utilizar los servicios de seguridad proporcionados por el subsistema CS 458 para proporcionar información de configuración de seguridad a los componentes de red (por ejemplo, físicos o virtuales) dentro de su ámbito. En algunas realizaciones, el servidor de niebla 454 puede utilizar este servicio para autenticar los inicios de sesión, proporcionar políticas de seguridad para las configuraciones del huésped (máquina virtual, recipiente, metal desnudo), validar las imágenes del huésped antes de la etapa de instar, y similares.
En algunas realizaciones, ciertos subsistemas pueden ser considerados como externos a la solución del sistema SDA. Estos subsistemas externos incluyen la red OT no SDN y los dispositivos de borde no SDN 472 (por ejemplo, los dispositivos heredados) y la red IT y los equipos administrativos 471. En algunas realizaciones, el Internet Industrial de las Cosas (IIoT) 469 u otro servicio basado en la nube puede considerarse externo o parte de la solución del sistema SDA.
3. SDN para entorno industrial
La creación de redes en entornos industriales es muy compleja y costosa de desplegar, gestionar y actualizar, y requiere la intervención de ingenieros de red cualificados. Por ejemplo, considérese la tarea de añadir un nuevo dispositivo industrial a una planta y su conexión a la red. Esta tarea generalmente requiere una cuidadosa selección de un puerto en el que se conecta el dispositivo, seguido del envío de pings (por ejemplo, pings SNMP) para interrogar al dispositivo y asegurarse de que está correctamente conectado a la red y responde. Un ingeniero de redes que realice esta tarea no sólo debe conocer los protocolos de red y demás, sino que también debe estar familiarizado con la disposición de la red de la planta (por ejemplo, para determinar en qué lugar conectar el dispositivo). Incluso después de que el dispositivo esté conectado a la red, el ingeniero de red puede necesitar realizar más configuraciones para garantizar que el dispositivo pueda hablar sólo con los dispositivos que necesita (por ejemplo, mediante la configuración de la lista de control de acceso (ACL), MACSecurity). Por lo tanto, todo el procedimiento de añadir un nuevo dispositivo a una red de planta existente es una tarea que no es sencilla ni instantánea. Para una tarea más compleja, como el despliegue de un nuevo sistema de automatización, no es difícil suponer que pueden ser necesarias muchas horas o días de cuidadosa planificación antes de poder crear una red para el sistema. Por ejemplo, cuántos enrutadores y cortafuegos desplegar, qué tipo de topología de red seleccionar, cómo lograr el aislamiento de las unidades o dispositivos lógicos, etc.
A modo de otro ejemplo, considérese una situación en la que surge un problema de red en una planta que tiene una red totalmente redundante. Un director de planta, por ejemplo, no sabría cómo diagnosticar y resolver el problema de la red. El director de planta tampoco sabría evaluar la gravedad del problema de la red. Por ejemplo, ¿el problema de la red está relacionado con la pérdida de redundancia, por lo que una inacción podría provocar la paralización de la producción si la segunda red también se cae, o el problema de la red es simplemente un problema que no afectará a la producción? El desconocimiento en cuanto a qué se traduce un problema de red en un lenguaje que entiendan los responsables de la toma de decisiones puede suponer que los responsables de la planta sean incapaces de controlar el nivel de producción. Por ejemplo, en el escenario anterior, un director de planta puede optar por ignorar el problema de la red relacionado con la pérdida de redundancia. Sin embargo, cuando la segunda red se cae, la producción se detiene durante unas horas hasta que se soluciona el problema de la red y se reinicia la planta, todo lo cual puede costar miles de dólares. Si el director de planta pudiera entender lo que significa la pérdida de redundancia en términos de coste, o de tiempo, podría haber tomado la decisión de llamar inmediatamente a un ingeniero de redes para arreglar el problema, en lugar de retrasarlo. De manera similar, si el problema de la red es un mero problema que no afectará a la producción, el director de planta podría retrasar la reparación hasta el siguiente mantenimiento programado.
La arquitectura, los sistemas y los procedimientos desvelados en el presente memoria (en adelante "tecnología desvelada") resuelven estos y otros problemas aportando una simplificación a la gestión de la red. En algunos aspectos, la tecnología desvelada facilita la instauración, el despliegue, el mantenimiento y la gestión de las redes industriales. Ya no es necesario entender cómo está dispuesta la red, o en qué puerto conectar un dispositivo industrial. En su lugar, un dispositivo podría conectarse en cualquier lugar de la red de la planta, y la tecnología desvelada detectaría automáticamente el dispositivo, determinaría sus capacidades, proporcionaría una trayectoria de red de acuerdo con las políticas de seguridad para permitirle comunicarse con otras entidades en la red, y pondría en marcha el dispositivo para comenzar la ejecución.
La tecnología desvelada hace que la red sea programable, lo que a su vez permite llevar el dominio de la ingeniería de redes a un dominio de aplicación industrial y hacerla parte integral del diseño general de la aplicación industrial. En otras palabras, los desarrolladores de aplicaciones industriales no tendrían que verse limitados por el diseño de la red o las decisiones del ingeniero de redes. Los diseñadores de aplicaciones industriales tendrían acceso directo programable a los eventos del procedimiento como: degradación del tiempo de respuesta de la aplicación (ART), pérdida de conectividad, violación de la seguridad y muchos otros. El diseñador de aplicaciones industriales también tendría la capacidad de segmentar la red en función de las funciones industriales y no de la capacidad de la red, o peor aún, del diseño de la misma. De este modo, la aplicación industrial se adaptaría a un estado de la red con visibilidad y control de la red "de extremo a extremo".
A través de la orquestación, un aspecto de la tecnología desvelada, un diseñador de aplicaciones industriales tendría la capacidad de instar de forma transparente servicios a nivel de red bajo demanda (por ejemplo, a través de la aplicación industrial SDN) para la virtualización de funciones de red (NFV). Los ejemplos de estos servicios incluyen, pero sin limitación: servicios de ciberseguridad como: inspección profunda de paquetes (DPI) y cortafuegos, equilibradores de carga, analizadores de tráfico, NAT, servicios de proxy, enrutamiento y similares. La etapa de instar de la función de red como servicio virtualizado en el momento y lugar correctos es responsabilidad de la aplicación SDN industrial (ISDNA) que se describe en detalle en referencia a las FIGS. 7C-7E. Proporcionar una conectividad adecuada basada en políticas entre elementos, virtuales o reales, puede lograrse utilizando el encadenamiento de funciones de servicio (SFC).
4. Arquitectura SDN industrial
Una arquitectura SDN industrial 500 puede representarse como compuesta por varios planos y capas diferentes, como se ilustra en las FIGS. 5A y 5B respectivamente. Por referencia a la FIG. 5A, la vista orientada al plano de la arquitectura SDN industrial comprende cuatro planos, cada uno de los cuales se describe a continuación.
I. Plano de aplicación
El plano de aplicación 505 en la arquitectura SDN industrial implementa aplicaciones de control industrial 525. Las aplicaciones de control industrial (o simplemente aplicación industrial) y las aplicaciones de control SDA (o simplemente aplicaciones SDA) se utilizan indistintamente en esta divulgación. Las aplicaciones de control industrial se desarrollan con software para el desarrollo de aplicaciones industriales. Un ejemplo de aplicación de control industrial que reside en este plano 505 es un programa que logra la función de cinta transportadora con opciones de arranque y parada, detección de fallos y contador de elementos simple desarrollado por un desarrollador de aplicaciones industriales. La función de la cinta transportadora puede desarrollarse utilizando otras aplicaciones de control, como una aplicación de control de PLC (por ejemplo, para controlar un conjunto de puntos de E/S) y una aplicación de controlador de motor, que luego pueden unirse mediante programación para formar la aplicación de la cinta transportadora. Las aplicaciones industriales 525 de este plano forman parte del componente de software 456 de la FIG. 4A. Las aplicaciones industriales 525 pueden considerarse la fuente de información y los requisitos para la SDN industrial.
II. Plano de plataforma
El plano de plataforma 510 implementa un conjunto de software e interfaces de programación de aplicaciones (API) que definen una interfaz para una aplicación industrial 525 en el plano de aplicación 505 al norte y exponen el acceso programático a los controladores (550, 555, 560) en el plano de control 515 al sur. Los componentes del plano de plataforma 510 incluyen un orquestador de niebla 535, una aplicación SDN industrial (ISDNA) 540 y un orquestador CS 545. Una aplicación o servicio de alto nivel conocido como orquestador SDA 530 oculta gran parte de la complejidad de la orquestación y el control, y expone una API que los desarrolladores de aplicaciones industriales pueden aprovechar para desarrollar aplicaciones industriales 525.
III. Plano de control
El plano de control 515 implementa entidades que controlan los dispositivos en el plano de infraestructura 520. Los componentes de orquestación del plano de plataforma 510 orquestan la SDN y/o otros elementos de control para lograr las funciones de una aplicación industrial 525. El plano de control 515 comprende un controlador de niebla 550, un controlador SDN 555 y un controlador de ciberseguridad (CS) 560. Cabe señalar que cada uno de estos controladores representa un sistema de control lógicamente centralizado. Por ejemplo, en un sistema de ejemplo, múltiples nodos controladores SDN pueden estar físicamente distribuidos, pero en conjunto representan un controlador SDN lógicamente centralizado. El controlador SDN 555, no sólo gestiona las redes físicas, sino que en conjunto con el controlador de niebla 550 gestiona también las redes virtuales. El controlador CS 560 gestiona las políticas de seguridad y colabora con el controlador de niebla 550 y el controlador SDN 555 para aplicar las políticas de seguridad. Cabe señalar que en algunas realizaciones, el plano de control 515 puede incluir un controlador TsSDN, o tanto un controlador SDN 555 como un controlador TSN. En tales realizaciones, el plano de plataforma 510 puede comprender componentes orquestadores correspondientes. Ciertos aspectos del controlador de niebla 550, del controlador SDN 555 y del controlador CS 560 ya han sido descritos con referencia a la FIG. 4A (por ejemplo, el controlador de niebla 435, el controlador de red 456 y el controlador CS 445).
IV. Plano de infraestructura
El plano de infraestructura 520 realiza la comunicación proporcionando conectividad de red física y virtual. Comprende todos los dispositivos de una red que participan en ella como emisores, consumidores o transeúntes de información (es decir, dispositivos que tiran/empujan información). Estos dispositivos pueden ser dispositivos industriales 575 y dispositivos de infraestructura 570. Los dispositivos industriales 575 incluyen aquellos dispositivos que realizan una función industrial o de automatización o una parte de ella. Por ejemplo, un PLC, un módulo de E/S, un motor, un accionamiento, etc., que son necesarios para implementar las funciones de automatización. Los dispositivos de infraestructura 570 incluyen equipos de red como conmutadores, enrutadores, aparatos de caja intermedia y similares. Existen dos tipos de infraestructuras 570 y dispositivos industriales 575: virtuales y reales. Los dispositivos virtuales (o elementos virtualizados) 565 se ejecutan en hardware como servidores, PC y similares. Un PLC que se ejecuta en un servidor y que no tiene ninguna manifestación física es un ejemplo de dispositivo industrial virtual. De manera similar, Open vSwitch, que es una implementación de software de un conmutador de red de múltiples capas, es un ejemplo de elemento virtualizado 565 alojado en un recurso informático 580. En cambio, un dispositivo real es un dispositivo de hardware. Entre los ejemplos de un dispositivo de infraestructura real se encuentran los dispositivos controladores de SDN, como el NoviSwitch 1248 de NoviFlow y el BlackDiamond X8 de Extreme Networks. Estos dispositivos de infraestructura, a diferencia de los dispositivos de red tradicionales, son simples dispositivos de reenvío sin control integrado. La inteligencia de red de estos dispositivos está lógicamente centralizada en el controlador SDN 555 en el plano de control 515. En algunas realizaciones, los dispositivos de infraestructura real 570 pueden incluir dispositivos de red heredados que pueden no ser capaces de controlar la SDN.
Los planos SDN industriales están conectados con dos nociones de responsabilidad: orquestación 574 e información 573. La orquestación incluye la responsabilidad de la disposición, coordinación y gestión automatizada de elementos y protocolos de red complejos. La información incluye la responsabilidad de la recopilación, el análisis, la interpretación, la presentación y la organización de la información de la red que, a su vez, permite que una aplicación industrial reaccione de forma programada a las condiciones de la red.
La vista centrada en la red está definida por la vista de red de la Interconexión de Sistemas Abiertos (OSI). Es natural describir una red en capas y, por lo general, utilizando un enfoque ascendente. Por ejemplo, una red puede describirse como compuesta por 3 dispositivos y 10 conmutadores conectados en malla, la topología sin bucles se garantiza mediante el protocolo RSTP; y los dispositivos se comunican mediante el protocolo EIP. La arquitectura SDN industrial representada en la FIG. 5B está compuesta por siete capas, cada una de las cuales tiene sus propias funciones específicas. Estas capas son: capa de infraestructura, interfaz sur, capa de control, interfaz norte, ISDNA, capa de orquestación de niebla y SDN, capa de orquestación SDA y aplicación industrial. En algunas realizaciones, la orquestación de ISDNA, niebla, SDN y SDA puede considerarse parte de la capa de orquestación.
De acuerdo con las costumbres de la red, y para facilitar la comprensión, cada una de las diferentes capas de la arquitectura SDN industrial repartidas en los cuatro planos representados en la vista orientada a capas de la arquitectura SDN industrial se describirá ahora de abajo a arriba, desde el hardware hasta la aplicación industrial.
I. Capa 1: Capa de infraestructura
La infraestructura SDN industrial comprende dispositivos de infraestructura 570, dispositivos industriales 575 y elementos virtualizados 565. Cada uno de los componentes de la capa de infraestructura se describirá ahora en detalle en referencia a las FIGS. 6A-6D.
Todo el dominio de control de la SDN, como se ilustra en la FIG. 6A puede clasificarse en dispositivos reales y virtuales. El dominio de control SDN incluye dispositivos de infraestructura reales 678 como dispositivos industriales y dispositivos de red, así como dispositivos industriales virtuales y dispositivos de red en un entorno virtual 679 que se ejecutan en un servidor en la nube (es decir, una plataforma informática distribuida) 677. Sobre la base de esta clasificación, incluso la red real puede distinguirse como una red real y una red virtual, ya que estas redes pueden basarse en cualquier topología de red 666 tal como anillo, malla, de tipo totalmente conectada, línea, árbol, estrella y similares. Aunque desde el punto de vista de la tecnología ISDNA, la distinción entre dispositivos reales y virtuales no es necesaria, el objetivo principal de la distinción es facilitar la comprensión del alcance y la responsabilidad de ISDNA.
La red SDA (es decir, la red en un sistema SDA) puede dividirse en tres redes físicas distintas como se representa en la FIG. 6B. La red de gestión de la niebla está dedicada a la gestión de los dispositivos de niebla 676 con la conectividad de la red representada por las líneas de puntos. La red de gestión s Dn (red de operación y gestión (OAM)) está dedicada a la gestión de los dispositivos SDN 614 con la conectividad de la red representada por líneas sólidas en negrita. La red industrial es la red de producción real que proporciona la comunicación entre los dispositivos industriales reales y virtualizados 675. La conectividad de la red industrial se representa con líneas sólidas sin negrita.
En algunas realizaciones, cada una de estas redes puede ser gestionada utilizando SDN. Para facilitar la explicación, se tratará en detalle la gestión de la red industrial y la comunicación que fluye a través de esa red. La conectividad física y las normas que rigen la conectividad se denominan red subyacente.
Mientras que la red industrial tiene dispositivos físicos reales, también tiene dispositivos virtuales que están conectados a través de redes virtuales como se representa en la FIG. 6C. Los dispositivos representados en la nube del entorno virtual 679 son instancias virtualizadas de dispositivos físicos como conmutadores, enrutadores, PC, PLC, cortafuegos y similares. Están conectados a través de enlaces virtuales. La red de dispositivos virtuales con conexiones virtuales se denomina red virtualizada. Los dispositivos virtuales residen en los nodos físicos del servidor de niebla (es decir, los nodos de cálculo) que forman parte de la red real. Esto significa que la red real y la red virtualizada están interconectadas para formar el dominio de control de la SDN industrial, como se muestra en la FIG.6D. Además, como se ilustra en las FIGS. 6D, el dominio de control SDN industrial comprende dispositivos de niebla físicos 676 (por ejemplo, servidores) en el servidor de niebla 677, dispositivos SDN 614 (por ejemplo, conmutadores de Red Extrema), dispositivos industriales 675 en la infraestructura industrial 678, dispositivos industriales y de infraestructura virtuales en el entorno virtualizado 679 alojados en el servidor de niebla 654, así como la red física 663 y la red virtual 664. La ISDNA gestiona el dominio de control de la SDN industrial a través de un controlador de SDN con la entrada proporcionada por una SDA o aplicación industrial, una aplicación de gestión de niebla u orquestador de niebla 535 y una aplicación de ciberseguridad u orquestador de CS 545. También se muestra en la FIG. 6D en el entorno virtual 679 son dispositivos de niebla de metal desnudo 679a. Los dispositivos de metal desnudo ejecutan una imagen binaria construida a propósito que está estrechamente acoplada al hardware del huésped (es decir, el hardware del nodo informático), de forma muy parecida a un dispositivo integrado tradicional. Esta imagen binaria puede aprovechar al máximo el acceso directo al hardware como si la imagen se instalara en la fábrica. En algunas realizaciones, la imagen de metal desnudo puede ser un núcleo completo y un sistema operativo (OS) para convertir el nodo de metal desnudo en un nodo informático completo con VM y/o recipientes con su propio soporte para VM y/o recipientes.
Históricamente, la topología dominante en la infraestructura industrial es la de cadena o anillo en lugares en los que se requiere redundancia. El principal motivo de estas topologías frente a las de árbol o malla es la reducción de los costes de material e instalación. Ahora que la niebla es el principal contribuyente a la infraestructura industrial, la visión topológica de la red se transforma en una mezcla de anillos y mallas. Dado que el núcleo de la niebla (es decir, el controlador de niebla) suele estar muy cerca de otras partes físicas del servidor de niebla, como los nodos de cálculo, los nodos de almacenamiento y otros similares, que están interconectados con conexiones rápidas de alto rendimiento, y dado que se trata de un dispositivo de gama alta, puede tener una plétora de interfaces de red de alta velocidad. Como tal, puede ser totalmente cableado en una topología de malla 666a a un costo relativamente bajo. Por otro lado, los dispositivos industriales suelen estar desplegados a gran distancia y tienen capacidades significativamente menores, con menos interfaces de red y a menor velocidad. Como tal, los dispositivos de borde pueden ser desplegados en cadenas y anillos (por ejemplo, 666b). Cabe señalar que, en otras realizaciones, pueden desplegarse otras topologías, como la de estrella, la de conexión completa, la de línea, la de árbol, la de bus o similares.
Generalmente, un controlador SDN gestiona la red utilizando una red de gestión separada y físicamente aislada. Las redes industriales prefieren una forma de red simplificada en todos los aspectos, incluyendo un cableado mínimo y una gestión sencilla. En otras palabras, una vista de red unificada para toda la aplicación industrial. A la luz de estas expectativas de la red, es deseable la consolidación de la red de gestión y operaciones. Esta consolidación abre preocupaciones adicionales como el diseño (topologías), el arranque y la gestión de dicha red.
En las redes industriales, la atención se centra en Ethernet. Ethernet está diseñada para funcionar en topologías sin bucles. Esta topología se puede conseguir conectando los dispositivos Ethernet en: Bus, Estrella, Árbol o una de sus combinaciones. Una mala configuración del cableado en estas topologías lleva a la creación de bucles que, en consecuencia, conducen a la replicación del tráfico a velocidad de línea, más conocida como tormentas de difusión. Para remediar las topologías de bucle accidentales o incluso intencionadas, los dispositivos de infraestructura Ethernet suelen desplegar Protocolos de Árbol de Expansión tal como STP, RSTP, MSTP, SPB y similares. La capacidad de estos protocolos para proporcionar una topología totalmente conectada (expandida) y sin bucles (árbol) ha llevado al despliegue intencionado de Ethernet mediante topologías de anillo y malla. En estas topologías, los protocolos de árbol de expansión actúan como protocolos de redundancia. A la Ethernet industrial le agrada mucho la topología en anillo, ya que proporciona una red única tolerante a los fallos con un coste de cableado mínimo y tiempos de recuperación razonables. Una red SDN industrial puede ofrecer el mismo o similar nivel de funcionalidad.
La creación de topologías en bucle o en malla en SDN se simplifica por su dependencia de una red de gestión separada (OUT-BAND) que se considera estable. En esa red reside un controlador SDN y todos los dispositivos se aprovisionan para acceder a ella. Dado que el controlador SDN tiene el control total de cada dispositivo, puede dar instrucciones a cada uno de ellos sobre cómo reenviar el tráfico para no crear bucles. En otras palabras, la red sin bucles es una aplicación de red más en la red SDN industrial.
Cuando la red de gestión y la red de producción se fusionan, se encuentra un problema de arranque: si un controlador SDN debe gestionar la red de gestión, entonces la red de gestión debe estar libre de bucles. Para que esté libre de bucles se requiere el controlador SDN. En la presente memoria es el sitio en que se encuentra un dilema de causalidad. Desde la perspectiva de la SDN, el controlador de la SDN tiene el control total de la red, es decir, cada dispositivo de una red controlada por la SDN tiene una trayectoria hacia el controlador de la SDN después de la provisión.
Un dispositivo arrancado con todas las interfaces en estado de bloqueo puede utilizar el protocolo LLDP para intercambiar información sobre la ubicación del controlador. El Protocolo de Descubrimiento de la Capa de Enlace (LLDP) puede ser utilizado para el intercambio de información OpenFlow de tal manera que resulte en una trayectoria hacia el controlador SDN. Una vez que el dispositivo ha obtenido la trayectoria hacia el controlador SDN, el controlador puede reconfigurar el dispositivo para integrarlo en la red. La aplicación del controlador SDN puede entonces acomodar la gestión y la separación de la operación a través de sus opciones de configuración.
Algunos dispositivos de infraestructura en el ámbito industrial integran la infraestructura y el dispositivo final en un solo dispositivo. Por ejemplo, un PLC que actúe como autómata y como conmutador. Por ello, este tipo de dispositivos industriales son aptos para ser gestionados directamente por el controlador SDN. Para ser gestionado por el controlador SDN, el dispositivo puede implementar al menos una interfaz vinculada al sur de un controlador SDN seleccionado. Un ejemplo de solución es que dicho dispositivo implemente el protocolo OpenFlow o similar. La implementación de OpenFlow a nivel de dispositivo industrial llevaría el control de la SDN al nivel del dispositivo.
II. Capa 2: Interfaz orientada hacia el sur
En la FIG. 5C, con el fin de ser gestionado por el controlador SDN, un dispositivo en el plano de infraestructura 520 puede implementar al menos una interfaz vinculada al sur 585 de un controlador SDN seleccionado. Las interfaces orientadas hacia el sur 584, que incluyen API orientadas hacia el sur, definen el protocolo de comunicación entre las entidades de control en el plano de control 515 y los dispositivos de infraestructura en el plano de infraestructura 520 para permitirles establecer una interfaz entre sí. Como tal, las interfaces orientadas hacia el sur 574 son necesarias para la separación entre el plano de control 515 y el plano de infraestructura 520. OpenFlow es uno de los estándares abiertos más populares para SDN.
MI. Capas: Control
Uno de los beneficios de la SDN es la simplificación del despliegue, la gestión y el mantenimiento de la red mediante un control lógicamente centralizado ofrecido por el controlador SDN 555. La infraestructura de la capa 1 es gestionada por entidades del plano de control, que incluyen:
(1) Controlador de niebla 550: responsable de la gestión de la niebla (es decir, la plataforma de virtualización)
(2) Controlador SDN 555: responsable de la gestión de la red SDN
(3) Controlador CS 560: responsable de la gestión de la ciberseguridad en su conjunto.
El plano de control 515 está formado por la interconexión de los tres controladores para formar una vista unificada de la red a través de la exposición de las API de la capa de control. Desde la perspectiva de la SDN, el controlador de SDN 555 es una pieza central de este esfuerzo de integración y es una parte fundamental de la SDN. Es importante comprender los principios básicos de la implementación y uso del controlador SDN antes de poder examinar en detalle el papel del controlador SDN 555 y su integración en el plano de control industrial 515.
(i) Arquitectura SDN
El propósito del controlador SDN es separar el control de la red de la trayectoria de datos y proporcionar una abstracción de los servicios de red. Como la arquitectura SDN ilustrada en la FIG. 7A, el controlador s Dn 755a es un mediador entre la red o aplicación SDN 712 y la infraestructura de red subyacente 714 en el plano de datos 708b.
En el plano de aplicación 754, el controlador SDN implementa la interfaz del plano de aplicación (A-CPI) y expone las interfaces orientadas hacia el norte (NBI) 713 a los usuarios del controlador SDN para desarrollar aplicaciones centradas en la red sin preocuparse por los detalles de implementación de la red. Este plano es una residencia natural de la ISDNA.
El plano de control 706b es el propio controlador SDN 755a. Este plano representa la inteligencia central de la red SDN. Aunque el controlador s Dn 755a puede estar físicamente distribuido, está lógicamente centralizado en este plano. La arquitectura detallada del controlador es específica de la implementación, pero en general, el controlador SDN implementa protocolos 717 del plano de control de datos (D-CPI) hacia el sur para comunicarse con los recursos de la infraestructura y el servicio correspondiente para permitir la programabilidad a través de A-CPI como NBI 713. Específicamente, el conjunto de protocolos implementados tal como interfaz D-CPI permite al controlador SDN 755a controlar directamente los recursos de los dispositivos de red reales que residen en el plano de datos 708b.
El panorama actual de los controladores puede dividirse en controladores de código abierto y controladores propietarios. El código abierto está orientado principalmente a los controladores SDN de características generales, mientras que los controladores propietarios están orientados a aplicaciones específicas. Para la interoperabilidad, es preferible que el controlador SDN 755a sea independiente del proveedor. Un enfoque de ISDNA es el uso de la plataforma de código abierto. Un controlador SDN 755a adecuado para la infraestructura ISDNA incluye OpenDaylight (ODL), que ofrece muchos servicios de red y protocolos vinculados al sur. Otra opción adecuada es ONOS, cuyo rendimiento es la principal razón para su selección.
Un lugar en el que la integración de ISDNP con el controlador SDN puede tener lugar es en la interfaz NBI del controlador SDN. Sin embargo, las interfaces NBI de muchos controladores SDN carecen de estandarización. Sin embargo, la arquitectura ISDNA está equipada para manejar esto mediante la implementación de agentes controladores SDN que se describen en referencia a la FIG. 7E.
(ii) Integración con el Controlador de Niebla
Por referencia a la FIG. 5B, ISDNA 540 controla tanto la red industrial real como la virtual. Si bien la red real está bajo el control directo del controlador SDN 555, la red virtualizada está bajo el control del controlador de niebla 550. Para permitir que estos dos sistemas de gestión interactúen entre sí, en la arquitectura SDN industrial desvelada, el controlador de niebla 550 y el controlador SDN 555 están acoplados de manera comunicativa entre sí proporcionando una conciencia de red unificada a la ISDNA 540. La integración del controlador de niebla 550 y el controlador SDN 555 se materializa en el plano de control SDN industrial 515. Un ejemplo de implementación de la integración entre el controlador de niebla 550 y el controlador SDN 55 se representa en la FIG. 7B, que se describe a continuación.
La FIG. 7B ilustra un ejemplo de integración entre la implementación OpenStack de un controlador de niebla 750 y la implementación ODL de un controlador SDN 755. El complemento ML2750a proporcionado por OpenStack utiliza una API REST de ODL para acceder a una aplicación 755b en el controlador SDN 755, y emitir comandos a ODL. El ODL interpreta los comandos y, en respuesta, crea, configura y rellena las tablas de reenvío de los conmutadores Open vSwitch Database (OVs Db ) 755b utilizando OpenFlow. En este punto, el controlador SDN 755 y el controlador de niebla 750 están totalmente controlados por el controlador SDN 755, lo que significa que toda la topología de la red está disponible para la ISDNA a través de las interfaces de ODL orientadas al norte. En este punto, ISDNA puede integrarse con el controlador SDN 755.
(iii) Integración con el Controlador de Ciberseguridad
Por referencia a la FIG. 5B, el controlador CS 560 es la entidad responsable de la gobernanza de las políticas de ciberseguridad. Estas políticas se tejen a nivel de red y de dispositivo. Como tal, el controlador CS 550 establece una interfaz con el controlador de niebla 550 así como con la ISDNa 540.
El propósito de la integración del controlador CS 560 con el controlador de niebla 550 es crear y manipular la infraestructura de red virtualizada. La integración del controlador CS 560 con ISDNA 540 se basa en un simple mandato para que el controlador CS 560 controle: la accesibilidad, el uso y el contenido de la comunicación manipulada por los recursos dentro de la red SDN industrial. La integración del controlador SDN 555 y el controlador CS 560 se basa en algunos aspectos fundamentales de la ISDNA 540, como la virtualización de funciones de red (NFV) y el encadenamiento de funciones de servicio (SFC).
La virtualización de funciones de red (NFV) es un concepto de arquitectura de red que utiliza las tecnologías de virtualización de TI para virtualizar clases enteras de funciones de nodos de red en bloques de construcción que pueden conectarse, o encadenarse, para crear servicios de comunicación. Desde el punto de vista de la seguridad, en algunas realizaciones, la NFV puede utilizarse para virtualizar las funciones relativas a la ciberseguridad, como cortafuegos, DPI y similares, y situarlas en lugares estratégicos de la red SDN industrial. Hay dos tipos de despliegue de NFV: centralizado y distribuido. El enfoque centralizado se basa en el despliegue de una función de red virtualizada y la redirección de todo el tráfico hacia ella para su procesamiento. El enfoque distribuido se basa en la función de ciberseguridad dedicada al dispositivo con un conjunto específico de políticas. En cualquier caso, el controlador SDN 555 dirige el tráfico hacia funciones basadas en políticas definidas por el controlador CS 560.
El Encadenamiento de Funciones de Servicio (SFC) proporciona la capacidad de definir una lista ordenada de servicios de red (por ejemplo, cortafuegos, equilibradores de carga) que luego se cosen en conjunto en la red para crear una cadena de servicios. El SFC a la luz de la ciberseguridad puede verse como un conjunto de funciones de red relacionadas con la ciberseguridad que se orquestan para hacer cumplir las políticas globales de ciberseguridad del SDA. Estas funciones pueden ser virtuales, funciones virtuales de red (NVF), o dispositivos reales. La responsabilidad del controlador SDN 555 en SFC es permitir o facilitar el flujo lógico de paquetes de una función a otra para aplicar las políticas de ciberseguridad de SDA.
En algunas realizaciones, la integración de ISDNA 540 y el controlador CS 560 puede basarse en un conjunto de necesidades básicas desde dos perspectivas. En primer lugar, el controlador CS 560 crea funciones y tareas ISDNA 540 para conectarlas. En segundo lugar, el controlador CS 560 encarga a ISDNA 540 que cree funciones y las conecte en base a un conjunto de políticas proporcionadas.
IV. Capa 4: Interfaz orientada al norte
El controlador SDN 555 ofrece una API a los desarrolladores de aplicaciones para permitirles programar el controlador SDN 555. Esta API es utilizada por la ISDNA 540 en el plano de plataforma 510 para comunicarse con el controlador SDN 555.
V. Capa 5: Orquestación de ISDNA, Niebla y CS
Esta capa comprende un conjunto de software y API que pueden acceder programáticamente a los controladores del plano de control 515 y orquestarlos para gestionar y controlar los dispositivos de infraestructura. La ISDNA 540, el orquestador de niebla 535 y el orquestador CS 545 de esta capa están estrechamente acoplados a los correspondientes controladores SDN, Niebla y CS en el plano de control 515. El orquestador de niebla 535 implementa las necesidades de virtualización a través del controlador de niebla 550 y el orquestador CS 545 implementa las políticas de seguridad a través del controlador CS 545. ISDNA 540 implementa funciones de red a través del controlador SDN 555. Específicamente, ISDNA 540 describe la red mediante la exposición de la API ISDNA. Al exponer las API de ISDNP, basadas en vistas funcionales, ISDNA 540 permite la programabilidad de la red industrial. Estas entidades forman en conjunto una visión holística de la aplicación SDA. La arquitectura de ISDNA y algunos de sus componentes se describirán ahora en detalle con referencia a las FIGS. 7C-7E.
La FIG. 7C es un diagrama de bloques que ilustra la arquitectura ISDNA de acuerdo con algunas realizaciones. ISDNA 740 proporciona una interfaz de red industrial consistente a través de ISDNA API 740a de cara a los desarrolladores de aplicaciones SDA en su lado norte. En su lado sur, se enfrenta al controlador SDN en el plano de control 715. Como se ha representado, la ISDNA 740 puede incluir varios servicios de red, como un servicio CS 740b, un servicio de topología 740c y un servicio de gestión de niebla 740d. Estos servicios de red son responsables de la orquestación de la red y de la recopilación de estadísticas basadas en una vista de servicio particular. El servicio de topología 740c proporciona información sobre la topología física y lógica de la red. El servicio CS 740b proporciona una interfaz al orquestador CS (también denominado aplicación CS) (por ejemplo, la orquestación CS 545 en la FIG. 5B). El servicio de gestión de la niebla 740d proporciona una interfaz al orquestador de la niebla (también denominado aplicación de gestión de la niebla) (por ejemplo, la orquestación de la niebla 535 en la FIG. 5B).
ISDNA 740 también incluye varios agentes tal como un agente controlador de SDN 740e, un agente de dispositivo de SDN 740f y un agente de virtualización 740g. Un agente controlador SDN 740e implementa una interfaz específica para un controlador SDN en el plano de control 715. Por ejemplo, si el controlador SDN es un controlador ODL, el agente controlador SDN 740e es un agente controlador ODL. De manera similar, si el controlador SDN es un controlador ONOS, el agente controlador SDN 740e es un agente controlador ONOS. Un agente de virtualización 740g implementa una interfaz específica para la plataforma de virtualización. Un agente de dispositivo SDN 740f, por otro lado, implementa interfaces para dispositivos de red en el plano de infraestructura 720. En algunas realizaciones, un agente de dispositivo SDN 740f es una interfaz opcional para el soporte directo de dispositivos heredados, que no son compatibles con el controlador SDN. El agente de dispositivos SDN 740f proporciona interfaces orientadas al sur para permitir el control y la configuración de los dispositivos objetivo. Los ejemplos no limitantes de los dispositivos de destino incluyen dispositivos que pueden ser controlados y configurados usando protocolos industriales tales como, pero no limitados a: Modbus y EtherNet/IP (EIP). En otras realizaciones, en lugar del agente de dispositivo SDN 740f, la integración de protocolos industriales como interfaz de dirección sur del controlador SDN puede dar soporte a dispositivos heredados.
Por referencia a la FIG. 7D, se representa un ejemplo de arquitectura para el servicio de topología 740c. Una de las principales funciones del servicio de topología 740c es el descubrimiento de dispositivos en la red. Para descubrir e identificar dispositivos, el servicio de topología 740c establece una interfaz con el controlador SDN, el controlador de niebla y el controlador CS (por ejemplo, los componentes 555, 550 y 560 respectivamente en la FIG. 5B). El procedimiento de descubrimiento puede incluir el descubrimiento de varios aspectos, incluyendo la conectividad, la identificación del dispositivo, la identificación de la red, la identificación de la comunicación, y similares.
Por ejemplo, el servicio de topología 740c establece una interfaz con el controlador SDN para determinar la conectividad física y lógica (por ejemplo, a través de la gestión de la red física 781 y la gestión de la red lógica 782 respectivamente). Para la identificación de dispositivos, el servicio de topología 740c puede establecer una interfaz con el agente controlador SDN 740e, el orquestador SDA, el servicio de gestión de niebla 740d y/o el servicio de gestión CS 740b. Por ejemplo, desde el agente controlador SDN 740e, el servicio de topología 740c puede adquirir las capacidades del dispositivo de red. Desde el orquestador SDA, el servicio de gestión de niebla 740d y el servicio de gestión CS 740b, el servicio de topología 740c puede adquirir información que identifique los dispositivos descubiertos en la red.
Para la identificación de la red, el servicio de topología 740c puede establecer una interfaz con el agente controlador SDN 740e y el orquestador SDA. Específicamente, desde el agente controlador SDN 740e, el servicio de topología 740c puede identificar las tecnologías de segmentación de red y los segmentos de red existentes. Desde el SDA o el orquestador de niebla, el servicio de topología 740c puede identificar la relación de los segmentos de red con la agrupación de funciones o aplicaciones industriales del SDA. Por ejemplo, un grupo de funciones industriales puede comunicarse utilizando un segmento lógico o físico de la red. El servicio de topología 740c puede relacionar la red con la agrupación SDA. El servicio de topología 740c también puede identificar los protocolos de comunicación disponibles (por ejemplo, desde la aplicación de análisis descrita en referencia a las FIGS. 11A y 13A o de examinar los flujos de comunicación), flujos individuales de comunicaciones o flujos (por ejemplo, a través del gestor de comunicación 783).
El servicio de topología 740c también puede incluir un gestor de funciones 784 que identifica las funciones de los dispositivos de red. Los dispositivos de red pueden separarse o agruparse por funciones. Por ejemplo, algunos se asocian a la función de control mientras que otros pueden asociarse a la función de producción. Considérese un sistema de mezcla de cemento que tiene un sistema sensorial que mide la humedad, la fluidez, la velocidad de rotación, la temperatura y/u otros parámetros. Si no hay una gestión funcional, el sistema de mezcla de cemento puede detenerse por cualquier motivo, como cuando se apaga una pila de luces o el controlador deja de funcionar, lo que hace que toda la red se caiga y que la mezcla de cemento se solidifique. Así, en lugar de tener una conexión directa, la información se alimenta a través del intercambio de información 786 a un sistema de cola de eventos 788 que gestiona los eventos de forma asíncrona.
Mientras que la funcionalidad de descubrimiento de topología se ocupa de los dispositivos que están actualmente presentes en la red, la funcionalidad de diseño de topología se ocupa de los dispositivos previstos y diseñados en la red. El objetivo principal de esta funcionalidad es proporcionar al usuario la capacidad de crear topologías de red y modificar las topologías descubiertas. La creación de topologías de red puede observarse desde dos perspectivas: topologías físicas y lógicas junto con el control de políticas. La topología física o conectividad es el enlace real entre dos nodos de la red. Esta conectividad puede establecerse entre cualquier tipo de nodo, ya sea un nodo final o un nodo de infraestructura. En algunas realizaciones, la funcionalidad de diseño de topología puede identificar los dispositivos de red disponibles para su uso en una aplicación industrial, proporcionar las capacidades de red de los dispositivos descubiertos a la aplicación industrial, establecer una interfaz con el servicio de gestión de niebla 740d para proporcionar NFV, establecer una interfaz con el controlador SDN para crear la segmentación de la red, exponer la API para el diseño de la red Inferior, exponer la API para el diseño de la red Superior, y similares.
Por referencia a la FIG. 7E, el agente controlador SDN 740e permite la comunicación entre la ISDNA 740 y el controlador SDN 755. El agente controlador de SDN 740e establece una interfaz con la API ISDNA al norte, y con el controlador de SDN 755 al sur. La arquitectura ISDNA es agnóstica respecto al controlador SDN, es decir, permite el uso de cualquier controlador SDN mediante el despliegue de un plug-in de agente controlador 740e para ese controlador SDN. Por ejemplo, si se despliega un controlador ODL en la red, entonces se puede desplegar un agente del controlador ODL en la ISDNA para permitir que la ISDNA interactúe con el controlador ODL. El agente controlador de SDN 740e puede traducir la información del servicio de topología 740c, por ejemplo, para el controlador de SDN, de modo que el controlador de SDN pueda añadir un dispositivo, eliminar un dispositivo, sustituir un dispositivo, etc. En algunas realizaciones, el agente controlador SDN 740e puede incluir un agente de control 789 que tiene una API de gestión de topología 789a, un procesamiento de eventos de dispositivo 789b y una gestión de políticas de red 789c. La gestión de políticas de red 789c puede traducir los requisitos de ciberseguridad para el controlador SDN 755. Un ejemplo de esta política traducida es: permitir sólo el acceso a YouTube a cualquier dispositivo conectado al puerto 1.
El componente de procesamiento de eventos del dispositivo 789b puede empujar los eventos del controlador SDN 755 hacia otros componentes de la ISDNA 740e. Por ejemplo, el controlador SDN 755 puede detectar un evento de pérdida de enlace y ese evento puede ser procesado por el componente de procesamiento de eventos del dispositivo 789b. Se puede obtener más información (por ejemplo, sobre el evento) a través de la API de gestión de la topología 789a. En cualquier caso, el evento se transmite al servicio de topología 740c. El servicio de topología 740c puede entonces determinar de lo físico a lo lógico el lugar en que se pierde la conexión física y generar mensajes en varios planos. Por ejemplo, el servicio de topología 740c puede determinar dónde se pierde la conexión física y generar un mensaje en el plano de infraestructura, por ejemplo, a través del agente de dispositivo SDN. De manera similar, puede determinar el lugar en que se rompe la conexión lógica y generar un mensaje en el plano de control, por ejemplo, a través del agente controlador SDN 740e. La información cuando se pasa al plano de aplicación puede, por ejemplo, dar lugar a la redundancia. Así, como se representa en la FIG. 5B, la información 573 puede propagarse desde el plano de infraestructura 520 a través de las distintas capas hasta el plano de aplicación 505, mientras que la orquestación 574 se propaga desde el plano de aplicación 525 hasta el plano de infraestructura 520.
VI. Capa 6: Orquestación SDA
Por referencia a la FIG. 5B, el componente de orquestación SDA 530 es un software unificado que se asienta sobre la ISDNA 540, el orquestador de niebla 535 y el orquestador CS 545 de la capa 5 y oculta la complejidad detrás de estos componentes exponiendo una API al norte para establecer una interfaz con las aplicaciones industriales 525.
VII. Capa 7: Aplicación industrial
Las aplicaciones industriales 525 se asientan sobre el orquestador SDA 535. Los usuarios trabajan desde la perspectiva de la aplicación, y como tal describen el sistema que quieren construir en el lenguaje nativo de la aplicación, no en el lenguaje de la red. Estas aplicaciones industriales utilizan la API expuesta por el orquestador SDA para comunicar sus requisitos al orquestador SDA 530 para orquestar los elementos de control en el plano de control 515.
5. Arquitectura de diseño de sistema SDA industrial
La FIG. 5C es un diagrama de bloques que ilustra un ejemplo de la arquitectura de diseño del sistema SDA industrial. En el diagrama de arquitectura de diseño, los usuarios utilizan el software para crear aplicaciones industriales 525 en el plano de aplicación 505. Estas aplicaciones industriales 525 pueden incluir una función, o un conjunto de funciones, y se crean no en el lenguaje de la red, sino en lenguajes de programación nativos de las aplicaciones informáticas (por ejemplo, lenguajes de programación de PLC). A modo de ejemplo, un usuario puede crear una aplicación de cinta transportadora utilizando una o más aplicaciones de software, definiendo varios componentes como un PLC, un motor, un interruptor, un sensor de movimiento, una señalización visual, etc., que son necesarios para que una cinta transportadora sea operativa.
El orquestador SDA 530 que establece una interfaz con la aplicación industrial 525 (por ejemplo, a través de API) proporciona las abstracciones necesarias para ocultar los detalles de la orquestación de los componentes del plano de plataforma 510 y del plano de control 515 para simplificar el desarrollo de la aplicación. En otras palabras, el usuario puede crear la aplicación de la cinta transportadora sin conocer los detalles de las capas y componentes subyacentes, sin tener que acceder y programar individualmente cada uno de los controladores o dispositivos de infraestructura, y sin tener que planificar cuidadosamente el lugar y la forma en que conectar los dispositivos de infraestructura a una red existente. El orquestador SDA 530, junto con la ISDNA 540, el orquestador de gestión de niebla 535 y el orquestador CS 545, simplifica el procedimiento de creación de aplicaciones de la cinta transportadora proponiendo la conectividad física y lógica de la red e implementando las características y políticas CS para crear unidades lógicas aisladas para el diagnóstico, el control, el cortafuegos, etc. Específicamente, el orquestador de gestión de niebla 535 que está acoplado al controlador de niebla 550 puede orquestar la creación de elementos virtualizados en uno o más nodos informáticos en el servidor de niebla. El orquestador CS 545 que está acoplado al controlador CS 560 puede orquestar el controlador CS 560 para implementar políticas de ciberseguridad. En el caso de la SDN, las funciones y las relaciones entre la ISDNA 540, el controlador SDN 555 y los elementos virtualizados 565, los dispositivos de infraestructura 570 y los dispositivos industriales 575 son las principales preocupaciones. La ISDNA 540 que estable interfaz con el controlador SDN 555 a través de la interfaz orientada al norte 584 orquesta el controlador SDN 555 para proponer trayectorias de comunicación que pueden basarse en criterios definidos por el usuario, como la carga, las capacidades de la infraestructura subyacente, la sensibilidad al tiempo, y similares. El controlador SDN 555 establece una interfaz con los elementos virtualizados 565, los dispositivos de infraestructura 570 y/o los dispositivos industriales 575 a través de la interfaz sur 585 para definir las trayectorias de comunicación que puede tomar cada dispositivo en el plano de infraestructura 520.
6. Ejemplo de uso de la arquitectura SDN industrial
La arquitectura SDN industrial que comprende ISDNA satisface varias necesidades en el entorno industrial y proporciona a los usuarios industriales un control y una comprensión finales de la red que no son posibles con la arquitectura de red tradicional o SDN. En otras palabras, con la arquitectura basada en ISDNA, la red se convierte en consumible para un usuario. En consecuencia, la red puede llegar a ser inmaterial cuando está operativa, y transparente cuando no lo está. Uno de los ejemplos de casos de uso para la implementación de la arquitectura SDN industrial es simplificar el procedimiento de provisión y puesta en marcha desde la perspectiva de las aplicaciones industriales, es decir, permitir a un usuario "conectar de forma segura cualquier cosa en cualquier lugar"
I. Provisión y puesta en marcha seguras y rápidas
En un entorno industrial existente, la provisión y la puesta en marcha de un dispositivo es un procedimiento complejo. No se puede simplemente conectar el dispositivo en cualquier lugar y esperar que funcione correctamente. La red industrial tiene una plétora de reglas de conectividad (topologías), restricciones del sistema, restricciones de los protocolos de red, etc. Además de la complejidad de la red existente, la virtualización, que es un aspecto integral de la SDA, aumenta esa complejidad. Con la combinación de dispositivos reales y virtuales y sus redes reales y virtuales complementarias, se forma un nuevo dominio de red que se representa en la FIG. 6D. Como se ilustra, el dominio de control SDN industrial abarca la niebla 654 en la que se aloja el entorno virtual 679 que incluye dispositivos virtualizados, así como el entorno de infraestructura 678 que incluye dispositivos industriales, sistemas informáticos, etc.
Considérese un escenario en el que un usuario tiene un dispositivo industrial que requiere ser desplegado en una planta para realizar una función industrial particular. Este dispositivo específico puede desplegarse cerca del procedimiento o a distancia, dependiendo de la disposición de la planta. Para conectarlo a la red basada en la arquitectura SDN industrial, no es requerido que el usuario conozca la topología exacta ni la configuración de la red. El usuario puede simplemente tomar un cable Ethernet y conectar el dispositivo al primer puerto de conmutación disponible en la ubicación física deseada. Como resultado de la realización de esta sencilla acción, se pueden poner en marcha una o varias de las siguientes operaciones en la red industrial SDN.
(i) El sistema SDA (por ejemplo, a través de ISDNA) determina si la ubicación física es adecuada para la conexión del dispositivo.
(ii) El sistema SDA (por ejemplo, a través de ISDNA) determina si el dispositivo conectado puede participar en la red.
(iii) El sistema SDA (por ejemplo, a través de ISDNA) determina el tipo de dispositivo, sus capacidades y su función industrial particular.
(iv) El sistema SDA (por ejemplo, a través de ISDNA) proporciona una trayectoria de red a todos los recursos requeridos por el dispositivo, como el almacenamiento, los puntos IO, otros dispositivos pares, y similares.
Una vez completadas las etapas anteriores, el dispositivo puede considerarse totalmente aprovisionado y listo para la fase de puesta en marcha. Cabe destacar que existe una distinción sustancial entre los estados de provisión y de puesta en marcha de un dispositivo. En el sentido más simple, un dispositivo aprovisionado está listo para ejecutar una aplicación, mientras que un dispositivo comisionado está autorizado para comenzar la ejecución. Cuando el dispositivo inicia la ejecución de la aplicación, se considera que el dispositivo está operativo.
La FIG. 8 es un diagrama de flujo de datos que ilustra la provisión expresa y segura de un dispositivo en una red SDN industrial de acuerdo con algunas realizaciones.
Cuando un nuevo dispositivo industrial 875c se conecta por primera vez a una red SDN industrial (por ejemplo, una red Ethernet) de la presente divulgación, emite una solicitud de protocolo de resolución de direcciones (ARP). Cada dispositivo de infraestructura (por ejemplo, 814) en la red es programado por el controlador SDN 855 para redirigir el paquete ARP de origen desconocido al controlador SDN 855. Por lo tanto, el paquete ARP del dispositivo industrial 875c que se va a proporcionar también se redirige al controlador SDN 855. La siguiente etapa del controlador SDN 855 es determinar si el dispositivo industrial 875c puede comunicarse con otros dispositivos o recursos de la red. Para hacer esa determinación, el controlador SDN 855 pasa información sobre el dispositivo industrial 875c (por ejemplo, su dirección MAC, dirección IP, y/o cualquier otra información encapsulada en la solicitud ARP) extraída de la solicitud ARP al ISDNA 840 (por ejemplo, a través del agente controlador SDN 740e en la FIG. 7C). 840 a su vez puede solicitar al orquestador SDA identificar el dispositivo industrial y las políticas de ciberseguridad relevantes aplicables al dispositivo industrial en algunas realizaciones. Específicamente, el orquestador SDA 830 puede obtener las políticas relevantes para la provisión del dispositivo industrial 875c desde el orquestador CS 845/Controlador CS 860. Por ejemplo, dicha política puede requerir que el dispositivo industrial 875c sea autenticado por un servicio de autenticación 865a. El servicio de autenticación 865a, controlado por el controlador CS 860, puede residir en un nodo informático físico del servidor de niebla, por ejemplo. El servicio de autenticación 865a puede implementar una lista de control de acceso (ACL) que es un procedimiento para hacer una lista blanca de dispositivos permitidos en la red o cualquier otro procedimiento de autenticación. El controlador SDN 855 basado en la información proporcionada por el orquestador SDA 830 (por ejemplo, a través de ISDNA) crea una trayectoria de red desde el dispositivo industrial 875c al servicio de autenticación 865a. Por lo tanto, cuando el dispositivo industrial 875c envía otra petición ARP, esa petición atraviesa la trayectoria de red proporcionada hasta el servicio de autenticación 865a. El servicio de autenticación 865a determina si el dispositivo industrial 875c está autorizado a participar en la red y lo que el dispositivo industrial 875c puede hacer en la red. Si el servicio de autenticación 865a determina que el dispositivo industrial 875c está autorizado a participar en la red, puede acceder a una base de datos de dispositivos configurada por un cliente para almacenar varios tipos de dispositivos, cómo están agrupados, capacidades, funciones industriales, protocolos, procedimientos de interrogación y similares. La información de dicha base de datos puede ser utilizada para interrogar e identificar el dispositivo industrial 875c y/o determinar los recursos requeridos por el dispositivo industrial 875c.
Por ejemplo, el servicio de autenticación 865a puede determinar a partir de la información recolección (por ejemplo, de la base de datos de dispositivos, información de la interrogación de dispositivos) que el dispositivo industrial 875c necesita comunicarse con todos los dispositivos del "grupo A". En el diagrama de ejemplo de la FIG. 8, PLCi es un dispositivo 875a que forma parte del grupo A con el que el dispositivo industrial 875c quiere comunicarse. El servicio de autenticación 865a proporciona esta información de configuración de acceso asociada al dispositivo industrial 875c al controlador CS 860 (por ejemplo, a través de una API). El controlador SDN 855, en base a la información de configuración de acceso, aprovisiona una trayectoria "Pi" desde el dispositivo industrial 875c hasta el PLCi 875a. Si el servicio de autenticación 865a lo permite (por ejemplo, en base a una política CS), el controlador SDN 855 también puede proporcionar una trayectoria (Pi') desde el PLCi 875a hasta el dispositivo industrial 875c. Por lo tanto, el dispositivo industrial 875c y el PLCi 875a pueden comunicarse bidireccionalmente a través de las trayectorias Pi y Pi' proporcionadas por el controlador SDN 855.
Supóngase que el PLC2875b también pertenece al grupo Ab pero se encuentra en un segmento de red diferente del PLCi 875a. El controlador SDN 855 puede programar los dispositivos de infraestructura 814 para proporcionar una trayectoria P2 desde el dispositivo industrial 875c al PLC2875b y una trayectoria P2' desde el p LC2875b al dispositivo industrial 875c. Cabe destacar que las trayectorias de ida y vuelta pueden ser iguales o diferentes. En algunos casos, la comunicación puede ser unidireccional.
En algunas realizaciones, el dispositivo industrial 875c puede requerir un almacenamiento externo. El dispositivo industrial 875c puede solicitar dicho almacenamiento, o el requisito puede estar especificado en una política. La solicitud puede ser manipulada por el orquestador SDA 830, o a través de un servicio de configuración de dispositivos. Finalmente, el controlador de niebla 850 instala un nodo de almacenamiento en uno o más nodos informáticos, e informa al controlador SDN 855 la ubicación del nodo de almacenamiento. El controlador SDN 855, a su vez, proporciona una trayectoria de red desde el dispositivo industrial 875c al nodo de almacenamiento para permitir que el dispositivo industrial 875c se conecte al nodo de almacenamiento para almacenar/recuperar datos (por ejemplo, información de configuración, datos de aplicación y similares).
En algunas realizaciones, el controlador SDN 855 puede proporcionar una trayectoria basada en los requisitos de QoS. Por ejemplo, el controlador SDN 855 puede identificar el tráfico del dispositivo industrial 875c como "MODBUS". El controlador SDN 855 puede entonces aplicar una política de red (por ejemplo, almacenada en una base de datos de políticas de red) para el tráfico MODBUS. En la FIG. 8, supóngase que P1/P1' y P2/P2' son trayectorias proporcionadas por el controlador SDN 855 para el tráfico MODBUS. SERCOS es un protocolo de alta velocidad con estrictos requisitos de sincronización. La política de red para el tráfico SERCOS puede dictar que el controlador SDN 855 proporcione una nueva trayectoria en la que no se permita ningún otro tráfico. La FIG. 8 , P3/P3' pueden ser las trayectorias proporcionadas por el controlador SDN 855 para el tráfico SERCOS.
Una vez que el nuevo dispositivo industrial 875c ha pasado por todas las verificaciones y tiene acceso a todos los recursos que necesita para ser plenamente operativo (por ejemplo, la aplicación está cargada), el procedimiento de provisión y puesta en marcha se considera completo. El procedimiento de desmantelamiento, a diferencia del procedimiento de provisión y puesta en marcha, implica la desactivación de la comunicación entre dos puntos. El procedimiento de desmantelamiento puede iniciarse por instrucción del usuario, cambio de política de ciberseguridad, autodetección de un fallo, oportunidad de reoptimización de una trayectoria, y similares. Por ejemplo, una aplicación de análisis (por ejemplo, la aplicación de análisis 1129 en la FIG. 11A, la aplicación de análisis 1320 de la FIG. 13A) que supervisa activamente la red puede determinar que la comunicación a través de la trayectoria A no cumple con los requisitos de QoS (por ejemplo, la latencia es demasiado alta), entonces el controlador SDN puede desactivar la trayectoria A y proporcionar una nueva trayectoria B que cumpla con los requisitos de QoS.
7. Creación y despliegue de una aplicación industrial en una SDN industrial
Una de las ventajas de la arquitectura SDN industrial, incluyendo la ISDNA y otros orquestadores, es la simplificación del procedimiento de creación de una aplicación industrial (o aplicación SDA) sin tener que cargar con las restricciones de diseño de la red. En este procedimiento de creación de aplicaciones, un diseñador de aplicaciones no tiene que preocuparse por los detalles de la red ni por sus implicaciones. La ISDNA y otros orquestadores pueden crear la aplicación industrial y prepararla para el despliegue en base únicamente a las funciones requeridas o en el diseño funcional en algunas realizaciones. En otras realizaciones, la entrada del usuario, por ejemplo, en relación con los requisitos o características de la red, también puede ser utilizada en la creación de la aplicación industrial.
La FIG.9A es un diagrama de bloques que ilustra la creación de una aplicación industrial de ejemplo de acuerdo con algunas realizaciones. Cabe destacar que el ejemplo de aplicación es meramente ilustrativo; las aplicaciones industriales reales suelen ser más complejas. El ejemplo de aplicación es el de una cinta transportadora con opciones de parada y arranque, detección de fallos y un simple contador de elementos. En las primeras etapas, el usuario puede crear los componentes funcionales necesarios mediante una aplicación de diseño. En algunas realizaciones, se pueden utilizar múltiples aplicaciones para crear la aplicación de la cinta transportadora (por ejemplo, el software Unity para proporcionar la funcionalidad de los controladores en colaboración con el software Wonderware (sistema SCADA) para visualizar y controlar el sistema). Dichas aplicaciones pueden ser accesibles a través del software del sistema o del portal de automatización (por ejemplo, el software del sistema 434) Por ejemplo, el usuario puede crear una unidad de cinta transportadora 902 y un elemento accionador 904. La creación de un elemento accionador o de cualquier otro elemento en el diseño funcional puede implicar, por ejemplo, la selección de un elemento accionador de una lista de opciones disponibles a través de la aplicación de diseño y arrastrar y soltar el elemento accionador seleccionado en un área de trabajo de la aplicación de diseño. El usuario también puede dar al elemento accionador una identidad (por ejemplo, Nombre: MOTOR PRINCIPAL número de serie: SCH90045) y asignarlo a un grupo funcional (por ejemplo, Grupo: G_CINTA TRANSPORTADORA). El usuario puede crear elementos de diagnóstico 906A, 906B, y dar a cada uno una identidad (por ejemplo, Nombre: ALARMA DEL MOTOR PRINCIPAL1, número de serie SCH70100) y asignar cada una a un grupo funcional (por ejemplo, Grupo: G_CINTA TRANSPORTADORA). El usuario también puede crear un elemento de control 908, y darle una identidad (por ejemplo, Nombre: INTERRUPTOR DE CONTROL DEL MOTOR PRINCIPAL, número de serie SCH6099) y asignarlo a un grupo (por ejemplo, Grupo: G_CINTA TRANSPORTADORA). El usuario puede conectar estos elementos entre sí (por ejemplo, dibujando líneas de conectividad), dando como resultado la vista de la función 901 representada en la FIG. 9B. En esta vista, el elemento de control 908 (por ejemplo, un interruptor) puede ser utilizado por un humano para encender/apagar el elemento de accionamiento 904 (por ejemplo, un motor) que pone en marcha/para la cinta transportadora 902. Además, el elemento de diagnóstico 906B (por ejemplo, un sensor) puede contar el número de paquetes en la cinta transportadora 902. Y finalmente, el elemento de diagnóstico 906A (por ejemplo, las luces de diagnóstico) conectado al elemento accionador 904 puede indicar un problema pasando de verde a rojo.
Dada la vista de conectividad basada en la función 901 representada en la FIG. 9B, el sistema SDA puede sugerir otros elementos necesarios para crear y desplegar la cinta transportadora como se representa en la FIG. 9A. Por ejemplo, el sistema SDA puede proponer un grupo de usuarios 912 (por ejemplo, para el control, mantenimiento y gestión de la aplicación) (Nombre: PC PERSONAL DE CINTA TRANSPORTADORA , Grupo: G_CINTA TRANSPORTADORA), controlador de aplicación redundante 914 (Nombre: CINTA TRANSPORTADORA PLC, número de serie: SCH10001, Grupo: G_CINTA TRANSPORTADORA), un controlador de accionadores 916 (Nombre: CONTROLADOR DE MOTOR DE CINTA TRANSPORTADORA, número de serie: SCH30077, Grupo: G_CINTA TRANSPORTADORA) y un controlador de diagnóstico 918 (Nombre: CONTROLADOR DE ALARMA PRINCIPAL, número de serie: SCH40066, Grupo: G_CINTA TRANSPORTADORA). En algunas realizaciones, el sistema SDA puede hacer estas sugerencias en base a la información proporcionada por el usuario y en la información sobre reglas y asociaciones, perfiles de usuario, perfiles de dispositivos y similares almacenados en una o más bases de datos. Por ejemplo, cuando un usuario selecciona un motor, el sistema SDA puede recuperar automáticamente un catálogo de controladores de motor y sugerir uno que cumpla con los criterios del usuario/diseño. Las reglas y asociaciones, en algunas realizaciones, pueden derivarse o aprenderse de diseños anteriores y/o especificarse para cada aplicación industrial. El sistema SDA también puede proponer una conectividad óptima a través de uno o varios protocolos industriales, tal y como se representa. La FIG. 9c representa una vista de conectividad basada en el tráfico 903 que ilustra la conectividad óptima entre el PC 912, los controladores de aplicaciones redundantes 914, el controlador de accionadores 916 y el controlador de diagnóstico 918 utilizando los protocolos EIP y MB/TCP. En algunas realizaciones, el sistema SDA puede proponer la conectividad óptima en base a información como la capacidad del dispositivo, el número/tipo de puertos, reglas y similares.
Una vez conectados los activos y los distintos controladores, el sistema SDA introduce el aspecto de la red. La información de la vista de conectividad basada en la función 901 y la vista de conectividad basada en el tráfico 903 puede servir como entrada para generar la conectividad física como se representa en la FIG. 9D. Para generar la conectividad física, el sistema SDA (por ejemplo, a través de ISDNA) puede instar elementos de red como un servidor DNS 926 y enrutadores 928. El sistema SDA (por ejemplo, a través de ISDNA) también puede proponer una topología de red (por ejemplo, topología física redundante). En algunas realizaciones, el sistema SDA puede proponer la conectividad física y la topología de la red en base a la capacidad de los dispositivos seleccionados, el coste, las reglas y/u otros criterios. A continuación, el sistema SDA puede conectar los elementos de la red en una topología (por ejemplo, en bucle o en malla) en función del coste y/o de otros criterios. La vista de conectividad física resultante 907 muestra los tres enrutadores conectados en una topología de malla.
Al aceptar la conectividad física propuesta, el sistema SDA (por ejemplo, a través de ISDNA) puede proponer la conectividad lógica. La conectividad lógica puede integrarse con funciones y políticas de ciberseguridad como el aislamiento de unidades lógicas (por ejemplo, aislar los diagnósticos del control), cortafuegos, etc. La conectividad lógica también puede basarse en la entrada del usuario. Por ejemplo, el usuario a través de la aplicación industrial puede solicitar un cortafuegos, un DNS, un NAT y un conmutador virtual para unir dos VLAN. El controlador de la niebla puede instar el cortafuegos en el servidor de la niebla, e informar a la ISDNA el lugar en que se encuentra el cortafuegos (por ejemplo, a través de la dirección IP) y aplicar una política de ciberseguridad que exija que todo el tráfico pase por el cortafuegos. La vista de conectividad lógica 909 representada en la FIG. 9E ilustra dos dominios de control aislados VLANi para control y VLAN2 para producción. Esta vista de conectividad lógica es más sencilla y fácil de entender que la vista de conectividad física.
En este punto, el sistema SDA (a través de ISDNA) puede proponer trayectorias de comunicación basadas en la carga, las capacidades de la infraestructura subyacente, la sensibilidad temporal y cualquier criterio definido por el usuario, mientras que la infraestructura física subyacente está siendo completamente abstraída. Por ejemplo, en la vista de conectividad basada en el tráfico 903 representada en la FIG. 9C, el controlador del accionador 916 puede comunicarse con los controladores de aplicación redundantes 914 a través del protocolo EIP. De manera similar, los controladores de aplicación redundantes 914 pueden comunicarse con el controlador de diagnóstico 918 a través de Modbus TCP (MB/TCP). en base a esta información de la vista de conectividad basada en el tráfico, el controlador SDN puede proporcionar una trayectoria desde los controladores de aplicaciones redundantes 914 hasta el controlador de diagnóstico 918 que sólo permite el tráfico MB/TCP. De este modo, el sistema SDA garantiza la compatibilidad con los protocolos.
En este punto, el diseño de la función industrial integrada SDA/SDN se considera completo. La FIG. 9F muestra las vistas de función 901, tráfico 903, conectividad lógica 909 y física 907 correspondientes a la aplicación de la cinta transportadora.
8. Vista funcional de SDN industrial
La red industrial tiene muchos usuarios diferentes. Cada usuario de la red tiene una función diferente dentro de una organización y con cada función viene una percepción diferente de la red, así como la necesidad de diferentes niveles o tipos de información. Sobre la base de la estructura típica de la organización industrial, la tabla 2 a continuación enumera los grupos de personal de acuerdo con sus funciones y sus intereses plausibles en relación con la red.
Tabla 2 Grupos de personal y aspecto de la red de interés
Figure imgf000022_0001
Sobre la base de estos grupos de personal, ISDNA puede dividirse en cinco vistas o planos de red, y cada vista transmite un nivel de información adecuado a los intereses de un grupo en particular, como se representa en el diagrama funcional de SDN industrial de la FIG. 10. En el diagrama, la vista de empresa 1011 está dirigida al personal de gestión 1014 para permitir al usuario supervisar el impacto de los eventos de la red en la empresa. La vista de conectividad funcional 1001 está dirigida al personal operativo 1016 para que el usuario pueda gestionar las funciones industriales. La vista de conectividad basada en tráfico 1003 está dirigida tanto al personal de seguridad 1018 como al personal de ingeniería 1022 para permitir a los usuarios gestionar las políticas de comunicación, supervisar el uso, la salud de la comunicación y similares. La vista de conectividad lógica 1009 también está dirigida al personal de seguridad 1018 y al personal de ingeniería 1022 para permitir a los usuarios gestionar la conectividad y las políticas de segmentación lógica de la red, por ejemplo. Por último, la vista de conectividad física 1007 está dirigida al personal de seguridad 1018, al personal de ingeniería 1022 y al personal de mantenimiento 1024 para que los usuarios puedan gestionar la conectividad y las políticas de la red física.
9. Supervisión y mantenimiento de una SDN industrial operativa
Una vez que se ha realizado la provisión y la puesta en marcha, la red industrial operativa puede ser supervisada, y se pueden tomar varias acciones en respuesta a los datos de supervisión. En algunas realizaciones, la supervisión puede realizarse de forma distribuida por varios componentes de la SDN industrial operativa. Por ejemplo, por referencia brevemente a la FIG. 11A, un controlador s Dn 1155 en el plano de control 1115 puede incluir un módulo de recolección de datos 1155e como una aplicación 1155b. El módulo de recolección de datos 1155e, programado a través de la ISDNA 1140, puede establecer trayectorias a través de la red para escuchar lo que los dispositivos de red en el plano de infraestructura 1120 están reenviando. Por ejemplo, si los dispositivos A y B se comunican a través de una trayectoria de red que tiene 10 conmutadores. El controlador SDN 1155 (a través del módulo de recolección de datos 1155e) puede configurar esos conmutadores (por ejemplo, cada conmutador o los conmutadores 3 y 10) para que copien los paquetes que reciben y los reenvíen a un agente de recolección 1127. El agente de recolección 1127, en algunas realizaciones, puede ser un almacén de datos lógicamente centralizado (es decir, puede estar físicamente distribuido en algunos casos) que es un repositorio de datos de supervisión recogidos de los dispositivos en el plano de infraestructura 1120. Finalmente, una aplicación de análisis 1129 puede recibir o recuperar los datos de supervisión del agente de recolección 1127 para realizar varios análisis, incluyendo los necesarios para generar información específica a nivel de red pertinente a los usuarios que operan en cada nivel de red descrito en detalle a continuación. La aplicación de análisis se describe en detalle en referencia a la FIG. 13A.
En algunas realizaciones, el controlador SDN/ISDNA puede supervisar todos los niveles de la red, desde el nivel físico hasta el nivel funcional. Sin embargo, la gran cantidad de información que se genera, y que debe ser procesada por el sistema, puede ser abrumadora, lo que puede impedir una respuesta oportuna. Por ejemplo, el sistema puede no ser capaz de producir un diagnóstico oportuno de un fallo (por ejemplo, qué ha pasado o dónde se ha producido el fallo) si hay un volumen masivo de información que procesar. Además, la información procedente de la supervisión y el tratamiento no es necesariamente útil para todos los grupos de personal. Por ejemplo, considérese un escenario en el que un conductor golpea un poste por el que pasaba un cable, lo que hace que éste se corte. En un sistema redundante, la producción no se detiene, es decir, la cinta transportadora sigue funcionando. Para un ingeniero, la información "pérdida de conectividad en el puerto 1" puede ser suficiente. Sin embargo, esta misma información puede no tener ningún significado para un personal operativo o un personal de gestión que puede no percibir ningún signo visible. En algunas realizaciones, la ISDNA puede resolver este problema proporcionando un detalle adecuado de información adaptada a los grupos de personal objetivo.
En algunas realizaciones, los desarrolladores de aplicaciones industriales pueden tener un acceso directo programable a varios eventos de la red, como la degradación de ART, la pérdida de conectividad, la violación de la seguridad, etc., detectados a partir de la supervisión de todos los niveles de la red. Por ejemplo, considérese el ejemplo de la supervisión de ART, que incluye el tiempo de procesamiento de la aplicación (APT) y el tiempo de transición de la red (NTT). Cuando la red está congestionada, el controlador SDN puede detectar la degradación del rendimiento del tráfico, lo que se traduce en la degradación de la ART. La ISDNA puede supervisar el ART y detectar su degradación. El desarrollador de la aplicación industrial puede programar el controlador SDN a través de la ISDNA para que responda a la degradación del ART redirigiendo el tráfico a través de trayectorias menos cargadas, ayudando así a recuperar el ART degradado. A modo de otro ejemplo, considérese una intrusión en una red en la que un puerto se desconecta repentinamente y otro dispositivo aparece en éste y comienza a comunicarse utilizando protocolos desconocidos. La ISDNA, que supervisa todos los niveles de la red, puede detectar la desconexión del puerto y los mensajes de protocolos desconocidos. Un desarrollador de aplicaciones industriales puede programar el controlador SDN a través de la ISDNA para implementar un plan de seguridad preparado. Este plan puede implicar, por ejemplo, el enrutamiento del tráfico del dispositivo sospechoso a una red falsa (una trampa de seguridad o honey pot) y así aislar la intrusión de la red real.
La ISDNA tiene una visión central de la red y es consciente de los eventos de red que ocurren en la red. Por referencia a las FIGS. 11B, 11Cy11D, esto significa que la ISDNA está supervisando los niveles físicos, lógicos, de tráfico y de función de la red y puede correlacionar los eventos de red que ocurren en un nivel con los cambios en otros niveles.
En algunas realizaciones, en el nivel físico 1109, la ISDNA puede:
• supervisar las estadísticas de la red, tal como la utilización del ancho de banda por puerto, la utilización del ancho de banda de la red, el rendimiento y similares,
• adquirir información específica del dispositivo, como la ubicación física, el uso de la energía, etc.,
• determinar la distancia física entre los dispositivos (por ejemplo, utilizada en las ecuaciones de visualización y estimación de materiales),
• descubrir la conectividad de la red y las capacidades de los dispositivos,
• supervisar la conectividad de la red,
• supervisar la conectividad física, tal como los estados de los enlaces de los puertos, la velocidad de la conexión, etc.,
• supervisar la conectividad lógica,
• crear y aplicar políticas de conectividad,
• correlacionar y propagar los eventos de la red a los usuarios con el detalle adecuado.
Por ejemplo, cuando un solo enlace físico falla resultando en una pérdida de conectividad en el puerto 1 como se representa en la FIG. 11B, la ISDNA puede correlacionar el evento de red de pérdida de conectividad 1123 con otra información de nivel de red disponible (por ejemplo, del listado anterior) para determinar la información de vista de conectividad física como el tipo de evento de red, el equipo afectado y la ubicación del equipo afectado que son relevantes para los usuarios que operan a este nivel (por ejemplo, el personal de ingeniería, mantenimiento y/o seguridad). Utilizando la información de la vista de conectividad física asociada con el evento de red, un personal de mantenimiento, por ejemplo, puede tomar una acción correctiva (por ejemplo, enchufar el cable en el puerto 1) para mitigar o resolver el problema.
A medida que la información de este nivel se propaga al nivel lógico 1107 superior, el detalle de la información del protocolo de red está disponible. En algunas realizaciones, en el nivel lógico 1107, la ISDNA puede:
• supervisar las estadísticas de la red, tal como la utilización del ancho de banda y el tiempo de respuesta de la red, • descubrir la conectividad lógica de la red y las capacidades de los dispositivos,
• supervisar la conectividad lógica de la red,
crear y supervisar los parámetros de conexión (por ejemplo, LAG, velocidad y dirección de conexión, redundancia) crear y describir el comportamiento de la red, como el control del nivel de acceso a la red del nivel de calidad del servicio
crear y aplicar la segmentación lógica de la red
crear y aplicar políticas de acceso a la red
supervisar la configuración y el operación de las tecnologías de red
correlacionar y propagar los eventos de la red a los usuarios con el detalle adecuado.
La ISDNA puede correlacionar la información disponible en el nivel lógico 1107 con la información propagada desde el nivel físico 1109 para determinar o generar información de vista de conectividad lógica 1121a relevante para los usuarios que operan en este nivel. Por ejemplo, suponiendo que la red de la FIG. 11B se basa en una topología de anillo, la ISDNA puede informar al personal de ingeniería y/o seguridad que el sistema tardó 20ms en detectar el evento de pérdida de conectividad de red 1123a en el nivel físico 1109 y cambiar a una trayectoria alternativa que evite el dispositivo de red impactado.
A medida que la información alcanza el nivel de tráfico 1103, comienza a tomar una forma más general al transmitir el significado de la falla en lugar de los detalles del protocolo. La ISDNA en este nivel puede:
supervisar la salud y el estado de la conexión
supervisar las estadísticas del protocolo, tal como PPS, el tiempo de respuesta de la red.
controlar la cantidad y el tipo de tráfico generado por los dispositivos.
descubrir el tráfico y las capacidades de los dispositivos (ver aplicación de la analítica)
crear y aplicar políticas de comunicación.
transmisión distribuida (cada canal de comunicación toma un trayectoria arbitrario a través de la red) transmisión agregada (todo el canal de comunicación entre dos dispositivos toma una trayectoria específica) correlacionar y propagar los eventos de la red a los usuarios con el detalle adecuado.
En el ejemplo de la FIG. 11B, la ISDNA puede proporcionar a los usuarios (por ejemplo, al personal de ingeniería y/o seguridad) información 1119a de que el sistema está funcionando con un nivel reducido de tolerancia a fallos (es decir, el nivel de tolerancia a fallos o FTL ha bajado de 1 de o).
Cuando la información llega al nivel de función 1101, la interpretación del fallo puede ser una simple advertencia y estado de la red subyacente. Desde una perspectiva de red de la función industrial, la ISDNA puede:
• descubrir funciones industriales
• gestionar funciones industriales: agrupación, aislamiento, gestión del control de acceso a funciones
• perfilar, crear, eliminar y modificar, funciones industriales. (La modificación de la creación y supresión no está pensada como interfaz de programación principal, sino que se trata de una integración con la aplicación global SDA)
• supervisar la conectividad
• controlar la salud de la comunicación
• controlar el tiempo de respuesta de las aplicaciones
• crear y aplicar políticas de comunicación
• gestionar la conexión en base a ART mediante TSN
• propagar los eventos de la red a los usuarios en el detalle apropiado de la vista.
En el ejemplo de la FIG. 11B, la ISDNA puede proporcionar a los usuarios que operan en este nivel (por ejemplo, el personal de operaciones) una advertencia operativa 1117a de que el fallo de la red fue detectado en la capa física 1109, pero la aplicación de la cinta transportadora sigue funcionando.
Finalmente, la información se propaga al nivel de empresa 1111 que presenta una vista coalescente de todos los problemas subyacentes para formar una perspectiva de empresa (por ejemplo, pérdida o ganancia financiera) en la que los atributos de empresa se asignan a la falla completa la vista completa. En otras palabras, en esta vista de nivel superior, toda la información disponible de los cuatro planos ISDNA se fusiona para formar una imagen financiera o empresarial de un procedimiento industrial en pseudo tiempo real. Los ejemplos no limitativos de atributos comerciales incluyen: el tiempo de inactividad estimado, el coste de la reparación y similares.
Desde una perspectiva de red de aplicación empresarial, la ISDNA puede permitir a un usuario que opera a este nivel:
• asignar un perfil financiero a las funciones, el tráfico o la conectividad
• supervisar los costes de explotación y mantenimiento de los recursos desde el punto de vista financiero
• asignar un valor de coste al impedimento de producción
En el ejemplo de la FIG. 11B, la ISDNA puede proporcionar a los usuarios que operan en este nivel (por ejemplo, el personal de gestión) el coste 1113a asociado al evento de pérdida de conectividad 1123a en el nivel físico 1109. Por ejemplo, en este ejemplo, se determina que el coste estimado de la reparación es de 300 dólares y puede basarse en: coste del personal de mantenimiento/hora * horas trabajadas (por ejemplo, 100 dólares/hora *0,5 horas)+ coste del material (por ejemplo, 250 dólares). Si, por ejemplo, el evento de la red fuera lo suficientemente grave como para causar un tiempo de inactividad en la producción, entonces el coste o la pérdida puede determinarse de la siguiente manera: número de unidades producidas por hora*beneficio promedio por unidad*número de horas de inactividad. Cabe destacar que estos cálculos de costes son ejemplos. El coste o la pérdida asociada a un evento de la red puede calcularse de cualquier manera, en base a atributos de la empresa como, por ejemplo, el tiempo de inactividad estimado, el coste de la reparación, etc.
La FIG. 11C es un diagrama de bloques que ilustra un segundo ejemplo de propagación de fallos de red a través de los distintos niveles de red de una SDN industrial operativa configurada en una topología de malla de acuerdo con algunas realizaciones. Cuando se extrae un cable de un dispositivo, se produce un evento de red de pérdida de conectividad 1123b en el nivel físico 1109. La información sobre este evento de red puede correlacionarse con otra información disponible en este nivel para informar a un usuario que opera en este nivel que el puerto 1 está caído debido a un evento de pérdida de conectividad (1123b). La información de este nivel puede propagarse al siguiente nivel lógico 1107, en el que la información del nivel físico 1109 puede correlacionarse con la información disponible en este nivel para informar a un usuario que opera en este nivel que se produjo una pérdida de redundancia y que el sistema pudo recuperarse en 20 ms (1121b). La información disponible en el nivel lógico puede entonces propagarse al nivel de tráfico 1103 en el que la información recibida se correlaciona con la información disponible para informar a un usuario que opera en el nivel que el sistema tiene un nivel reducido de tolerancia a fallos con el nivel de tolerancia a fallos bajado de 10 trayectorias a 1 (1119b). En el nivel de función 1101, la información propagada desde el nivel de tráfico 1103 se correlaciona con la información disponible para generar un aviso al operador de que se ha detectado un fallo de red de baja gravedad en el nivel físico (1117b). En el nivel de empresa 1111, en el que se cohesiona la información de todos los niveles, se puede proporcionar al usuario un coste financiero (1113b) del fallo de la red a nivel físico. Por ejemplo, el coste puede ser de 0 dólares si el sistema se planificó de modo de operar con el nivel reducido de tolerancia a los fallos (por ejemplo, diseñado para no tomar ninguna medida hasta que el FTL baje a 5). Alternativamente, si el sistema fue diseñado específicamente para operar con un FTL de 10 (es decir, un FTL inferior a 10 puede hacer que la congestión aumente y afecte a la producción), entonces hay un coste financiero asociado al evento de red para que una persona de mantenimiento localice el dispositivo impactado y enchufe el cable (por ejemplo, 300 dólares).
La FIG. 11D es un diagrama de bloques que ilustra un tercer ejemplo de propagación de un fallo de red a través de los distintos niveles de red de una SDN industrial operativa de acuerdo con algunas realizaciones. Como en el caso de las FIGS. 11B y 11C, un evento de red detectado en un nivel se propaga a través de los otros niveles hasta llegar al nivel de empresa 1117, y se correlaciona con la información disponible en cada nivel para generar en cada nivel, información de eventos de red específica para los usuarios que operan en ese nivel. En este ejemplo, un evento de red relacionado con la activación de un puerto (1123c) puede ser detectado en el nivel físico 1109. Alternativamente, un evento de red relacionado con un patrón de tráfico irregular (1119c) de un dispositivo puede ser detectado en el nivel de tráfico 1103. Ambos eventos de red son indicativos de una intrusión no autorizada o un ciberataque. En algunas realizaciones, el controlador SDN puede estar configurado a través de la ISDNA para implementar un plan de seguridad preparado en caso de una intrusión no autorizada. Este plan puede implicar, por ejemplo, el enrutamiento del tráfico del dispositivo sospechoso a una red falsa (una trampa de seguridad o honey pot) y así aislar la intrusión de la red real. Si el plan de seguridad se activó con éxito, la ISDNa puede traducir este evento de red (1119c o 1123c) en información de red específica del nivel lógico que informa a un usuario que opera en el nivel lógico 1107 que el evento de red se manejó activando el plan de seguridad (1121c). En algunos casos, el ciberataque puede ser manejado mediante la desactivación del puerto asociado al evento de red, en cuyo caso la información de red específica de nivel lógico informaría al usuario del mismo. De manera similar, la ISDNa puede traducir el mismo evento de red en información de red específica del nivel de función para informar a un usuario que opera en el nivel de función 1101 que el sistema está operando normalmente pero que hubo una actividad no autorizada (1117c). Otra posibilidad es que la intrusión no autorizada haya causado alguna pérdida temporal de funciones antes de que las medidas correctoras surtieran efecto. En tal caso, el usuario puede ser informado de que el sistema está operando normalmente después de una pérdida temporal de función (1117c). Por último, en el nivel de empresa1111, la ISDNA puede determinar el coste (1113c) de la actividad no autorizada. En este ejemplo, el coste puede oscilar entre 100 y 100.000 dólares (es decir, una pérdida mínima o significativa). Por ejemplo, si la actividad no autorizada se debió a que un usuario accedió a un sitio autorizado desde un PC, el coste de informar al usuario sobre las políticas será mínimo. Sin embargo, si la actividad no autorizada se debe a un PC infectado con malware, es posible que toda la red se haga o deba desconectarse para solucionar el problema.
De esta manera, la ISDNA puede propagar un evento de red a través de los niveles de la red, correlacionando en cada nivel la información de ese nivel con la del nivel precedente para generar y/o seleccionar información relevante para los usuarios que operan en ese nivel. Por lo tanto, cada nivel proporciona un nivel de información distinto basado en el conjunto de habilidades de los usuarios que operan en ese nivel. Un nivel adecuado de flujo de información y su difusión en la perspectiva apropiada, significa que los usuarios pueden obtener información relevante para sus funciones, lo que puede ayudar a una rápida toma de decisiones, y potencialmente prevenir problemas mayores o pérdidas financieras. Además, la combinación de todas las vistas de la red y sus niveles de funcionalidad proporciona a los usuarios una sensación completa de control y seguridad de la red.
Cabe destacar que un evento de red puede ser cualquier evento que ocurra en una red y que cause o sea capaz de causar un cambio en la red. El cambio puede ser adverso o involuntario, o positivo o intencionado. La pérdida de conectividad y el ciberataque son sólo ejemplos de un evento de red. Otros eventos tales como, pero sin limitación: el fallo de un dispositivo de red, la detección de tráfico desconocido o innecesario, etc., también son eventos de red. Estos eventos de red pueden contribuir a la degradación genérica del sistema, y tendrán un coste asociado a nivel empresarial. El fallo del dispositivo de red puede deberse a varias razones. Por ejemplo, un tipo de fallo de dispositivo de red puede no manifestarse en una pérdida de conectividad a nivel físico, pero falla a nivel de reenvío y puede ser un evento de reacción en respuesta a la pérdida de comunicación en otros dispositivos afectados. Otro tipo de fallo del dispositivo de red puede estar relacionado con la retransmisión incontrolada de tramas por parte de un dispositivo de red. Otro tipo de fallo de la red puede estar relacionado con la detección de tráfico innecesario en áreas específicas de una red (por ejemplo, debido a una interpretación defectuosa de la política de la red/SDN). Un fallo del dispositivo de red también puede estar relacionado con un dispositivo de red que no aplique una política SDN solicitada, o con un dispositivo de red que esté parcialmente operativo y reenvíe el tráfico de acuerdo con la política previamente configurada, pero que ya no sea accesible para el controlador SDN. Un ejemplo de evento de red que provoca un cambio positivo o previsto en la red es cuando un dispositivo es autorizado con éxito a participar en la red.
Cabe destacar que el término vista no se limita a la representación visual de la información. Puede incluir información en un formato fácilmente consumible por una aplicación de software o interfaces (por ejemplo, interfaces visuales o de programación, API, etc.). En algunas realizaciones, las vistas correspondientes a estos planos ISDNA pueden integrarse en formato de realidad aumentada o mediada. De acuerdo con el usuario de la vista y el nivel de interés, la información recolección en una aplicación SDA centralizada puede entrelazarse con la vista real de la fábrica, lo que puede mejorar la resolución de problemas, proporcionar información instantánea sobre la producción, etc.
10. Fábrica como un servicio
Un procedimiento típico de construcción de una fábrica es un esfuerzo que no sólo es costoso sino que también consume tiempo. Cuando se construye una fábrica, suele funcionar durante muchos años hasta que tiene algunos problemas. Por ejemplo, hay que añadir otra línea de producción, el espacio de la fábrica es demasiado pequeño, hay que trasladar la fábrica a otro lugar, etc. Sea cual sea el motivo, construir una fábrica igual o similar en otro sitio no es fácil y suele requerir la contratación de ayuda externa para empezar desde cero. Además, hay que recopilar diversa información, tal como listas de equipos, especificaciones, aplicaciones, protocolos, etc., para ayudar a la construcción de la nueva fábrica. La arquitectura SDN industrial descrita en la presente memoria utiliza el modelo de fábrica como servicio para permitir una simple operación en cadena de copia-pega que da lugar a un diseño de planta en base al encadenamiento de funciones industriales. El encadenamiento o apilamiento inteligente puede producirse en todas las capas de la aplicación industrial con la propuesta de reducción de OPEX y CAPEX mediante la reutilización de la infraestructura y el aislamiento lógico de la comunicación.
Considérese un ejemplo del procedimiento de creación de la aplicación de la cinta transportadora descrito en referencia a las FIGS. 9A-9F. Este procedimiento produce una función SDA que puede encadenarse inteligentemente a otra para formar un grupo de producción. La creación de una instalación de producción a partir de funciones industriales abstraídas se denomina "Fábrica como un Servicio". La FIG. 12 describe una fábrica SDA como un servicio en el que la leche se transforma en helado y se empaca y sube a un camión para su entrega. Supóngase que la primera fábrica (grupo 1) incluye una función de empaque 1204A (por ejemplo, aplicación de cinta transportadora) que está encadenada a otra para formar un grupo de producción 1206A. El sistema SDA tiene toda la información sobre la función, el tráfico, las capas lógicas y físicas de la primera aplicación de fábrica almacenada en uno o más almacenes de datos. En algunas realizaciones, por ejemplo, cada una de las funciones SDA puede almacenarse en forma de plantilla. En otras realizaciones, toda la fábrica que comprende las funciones SDA encadenadas puede ser almacenada en forma de plantilla. Cuando se va a crear una segunda fábrica (grupo 2), el usuario puede simplemente arrastrar y soltar un icono de fábrica o iconos de función y encadenarlos en la aplicación de diseño. Si, por ejemplo, se dispone de controladores más nuevos o mejorados, se puede realizar una operación de sustitución para actualizar o modificar las plantillas. A continuación, el sistema SDA puede generar automáticamente el tráfico subyacente, las vistas de conectividad física y lógica, el suministro de las trayectorias de red necesarias, la puesta en marcha de la infraestructura y los dispositivos industriales, etc., para crear una fábrica totalmente operativa. En algunas realizaciones, el sistema SDA puede ofrecer un modo de simulación además del modo real. En el modo de simulación, la función SDA es una función SDA virtual (por ejemplo, 1204, 1206) en la que todos los dispositivos industriales y de red son dispositivos virtualizados alojados en el servidor de niebla o en un entorno informático distribuido 1202. El sistema SDA puede entonces utilizar las funciones SDA virtuales para simular todo el procedimiento industrial. Los datos de la simulación pueden utilizarse para el diseño, la provisión secuencial y la puesta en marcha, la expansión en vivo, las pruebas de mantenimiento, la optimización de las instalaciones de producción, etc. En algunas realizaciones, los datos de la simulación pueden utilizarse para estimar los CAPEX (gastos de capital) y los OPEX (gastos de explotación) del despliegue de la SDA.
11. Aplicación analítica en una SDN industrial
La FIG. 13A es un diagrama de bloques que ilustra componentes de ejemplo de una aplicación analítica 1329 en una SDN industrial. La aplicación de análisis 1329 puede estar virtualizada (por ejemplo, en el servidor de niebla o en una nube externa), o puede ser un dispositivo de hardware físico (por ejemplo, con potentes capacidades de procesamiento). La aplicación de análisis 1329 puede acceder a los datos de supervisión desde un agente de recopilación 1327 lógicamente centralizado y realizar diversos análisis en tiempo real o pseudo real. A modo de ejemplo, y no de forma limitativa, la analítica puede utilizarse para:
• detectar y gestionar los problemas de congestión (equilibrador de red holístico en tiempo real que combina redes reales y virtuales)
• detectar la presencia de dispositivos (elaboración de perfiles de dispositivos basados en patrones de comunicación)
• confirmar la eficacia de las normas y políticas (detección y gestión del tráfico no deseado y permitido)
• datos históricos para predecir patrones de comunicación potencialmente problemáticos (reaccionar a los armónicos de red creados por la aplicación, presencia de paquetes de gestión elevados, falta de comunicación prevista como detección de fallos)
• supervisar la salud de las comunicaciones (detección/medición de fluctuación)
• proporcionar estadísticas de funciones industriales y perfiles de red (análisis en tiempo real tal como medición de ART, detección de tiempo de recuperación de fallos)
I. Ejemplo de caso: Congestión
Los usuarios pueden detectar y gestionar los problemas de congestión. La detección de la congestión puede lograr un equilibrio holístico de la red en tiempo real combinando redes reales y virtuales.
Un módulo de gestión de la congestión 1304 de la aplicación analítica 1329 puede implementar un ejemplo de solución de gestión de la congestión que incluye la construcción de un mapa exacto de todos los objetos (por ejemplo, sensores, máquinas y ordenadores) en un sitio interactivo, con líneas que muestran la forma en que cada objeto se conecta con otro. Por ejemplo, como se ilustra en las FIGS. 13B muestra una representación en tiempo real de lo que está ocurriendo exactamente en ese momento. En el mapa de ejemplo, las líneas sólidas simples representan la comunicación positiva entre los objetos, las líneas sólidas dobles representan las conexiones en operación que no se están utilizando en este momento y las líneas de puntos representan las comunicaciones que no funcionan correctamente.
Si, por alguna razón, la fabricación se ha detenido, la dirección del edificio puede examinar este mapa y señalar exactamente la pieza de equipo defectuosa, en lugar de jugar a las adivinanzas. De este modo, los problemas pueden resolverse con mayor eficacia y rapidez. Además, la eficiencia de cada objeto (por ejemplo, producto o dispositivo) no se aplica a todos los demás objetos, sino sólo a algunos otros objetos en algunas realizaciones. Por lo tanto, cuando un objeto no funciona correctamente, el objeto puede alertar sólo a los que necesitan ser informados. Algunos ejemplos de notificaciones pueden ser: el encendido y apagado de una luz, un teléfono automático o el envío de un correo electrónico automático. Esta es la forma más eficaz de supervisar una red industrial.
Al implementar el mapa de usuarios, las organizaciones pueden supervisar las redes y analizar los problemas de congestión. Los problemas de congestión pueden resolverse por sí solos porque una vez que el sistema se da cuenta de que hay un problema, puede elegir la mejor opción y cortarla de la red o redirigir la actividad para aliviar la aglomeración. Un módulo de visualización 1302 puede representar el mapa del usuario y/u otros gráficos.
II. Ejemplo de caso: Detección de dispositivos
En algunas realizaciones, se puede utilizar una técnica de perfilado de dispositivos basada en patrones de comunicación para detectar la presencia de dispositivos a través de un módulo de detección de dispositivos 1306.
Un mapa de usuarios como el descrito anteriormente puede ser implementado para permitir a las organizaciones analizar exactamente lo que está sucediendo en cualquier momento. El mapa puede mostrar diferentes representaciones de lo que es cada dispositivo. Por ejemplo, un ordenador puede tener un aspecto diferente al de un teléfono móvil. En función del perfil del dispositivo (es decir, un ordenador, un teléfono móvil, un dispositivo HMI), el protocolo puede reconfigurar automáticamente la red si es necesario, manteniendo la productividad. Por ejemplo, es mejor desconectar el dispositivo de un huésped, como su teléfono móvil, que interrumpir un procedimiento industrial y perder productos o beneficios.
En otra implementación, el tráfico del teléfono móvil puede ser redirigido para aliviar el tráfico cerca del procedimiento industrial. Se trata de una aplicación de análisis descriptivo porque muestra datos en tiempo real.
III. Ejemplo de uso: Uso de red
En algunas realizaciones, se pueden utilizar datos y análisis en tiempo real para analizar el uso de la red, detectar y gestionar el tráfico no deseado y permitido y supervisar las normas y políticas de la organización, entre otros, a través de un módulo de gestión del uso de la red 1308.
Las organizaciones suelen tener sitios bloqueados por su contenido. Sin embargo, los usuarios pueden seguir intentando acceder a estos sitios o a otros que no hayan sido incluidos en la lista restringida. Cuando se intenta acceder a estos sitios, se puede enviar una alerta a un administrador de la red o a otro personal para que vigile la red. Esto permite a una organización mantener una red segura.
En algunas realizaciones, se puede implementar una tecnología que permita el uso de huellas dactilares para los sitios. Puede haber diferentes huellas dactilares para los sitios e incluso múltiples huellas dactilares para los sitios dentro de los sitios. Por ejemplo, Gmail y Google Drive pueden tener huellas dactilares diferentes. Se pueden recopilar datos analíticos sobre estas huellas dactilares y analizarlos para ver qué hace la gente y cuándo accede a estos sitios. Por ejemplo, un análisis sobre el uso de las redes sociales puede utilizarse para generar una imagen que represente las aplicaciones a las que se accede en la red. Cuanto más grandes son las burbujas, más se accede a ellas. Se trata de una aplicación de la analítica prescriptiva, predictiva, de diagnóstico y descriptiva, ya que combina datos históricos con datos en tiempo real para analizar lo que ha ido mal (o bien) y decidir qué hacer en el futuro para obtener un mejor resultado.
IV. Ejemplo de uso: Datos históricos
En algunas realizaciones, los datos históricos pueden ser analizados a través de un módulo de análisis de datos históricos 1312 para predecir patrones de comunicación potencialmente problemáticos. El análisis puede basarse en la reacción a los armónicos de red creados por la aplicación, la presencia de paquetes de gestión elevados, la falta de comunicación prevista como detección de fallos, y similares.
Por ejemplo, un sitio puede generar tendencias y predicciones de datos, y se pueden producir gráficos que muestren la actividad en un nivel muy alto. Algunos ejemplos de gráficos pueden ser: mes a mes, día a día, hora a hora como se muestra en la FIG. 13C. Estos gráficos pueden mostrar qué máquinas se comunican en determinados días, y detectar si algo parece ir mal durante un ciclo. Estos gráficos pueden ser útiles no sólo para entender el procedimiento, sino también para decidir cuándo programar sustituciones u otras reparaciones sensibles al tiempo que podrían interrumpir el procedimiento. Se trata de una aplicación de análisis predictivo, ya que utiliza datos históricos para predecir mejor el futuro.
Existen muchas aplicaciones de los gráficos interactivos en tiempo real como los descritos anteriormente. Además de gestionar la comunicación entre las máquinas, los gráficos pueden utilizarse para predecir las sustituciones y las tendencias de la plantilla. Los clientes pueden examinar los gráficos y observar cuándo hay una pausa en la comunicación, o ciertos días del mes que son extremadamente ocupados. Con esta información, los usuarios saben que deben contratar menos o más empleados en función de la cantidad de tráfico prevista para ese día específico.
Si se hace evidente que un determinado sensor o máquina parece morir durante la misma parte en el ciclo, las industrias pueden comenzar a cambiar preventivamente el sensor o máquina con uno durante un tiempo tranquilo en el ciclo antes de que perezca. Esto será más eficiente porque no es necesario interrumpir o detener el proceso debido a un equipo defectuoso.
V. Ejemplo de uso: Comunicaciones
En algunas realizaciones, la salud de las comunicaciones puede ser supervisada. Por ejemplo, la fluctuación puede ser detectada y medida para evaluar la salud de las comunicaciones a través de un módulo de salud de las comunicaciones 1314. Se trata de una aplicación de la analítica prescriptiva, predictiva, de diagnóstico y descriptiva, ya que combina datos históricos con datos en tiempo real para analizar lo que ha ido mal y decidir qué hacer en el futuro para obtener un mejor resultado
VI. Ejemplo de uso: Datos en tiempo real
En algunas realizaciones, un módulo de análisis en tiempo real 1316 puede poner a disposición de los usuarios estadísticas de funciones industriales e información de perfiles de red para su revisión. Los análisis en tiempo real pueden incluir, por ejemplo: medición de ART, detección del tiempo de recuperación de fallos, y similares. Se trata de una aplicación de análisis descriptivo porque se basa en datos en tiempo real.
VII. Ejemplo de uso: Sustituciones
En algunas realizaciones, un módulo de gestión de reemplazos 1318 puede utilizar análisis para determinar qué productos/dispositivos pueden ser reemplazados preventivamente para evitar la interrupción de los procedimientos.
En algunas realizaciones, el módulo de gestión de reemplazos 1318 puede implementar una función de densidad de probabilidad (PDF) exponencialmente decreciente. Las funciones exponenciales pueden proporcionar modelos para describir variables aleatorias (por ejemplo, la vida útil de las bombillas y muchos tipos de componentes electrónicos). Las funciones exponenciales también se pueden utilizar para modelar la cantidad de tiempo hasta que ocurra algún evento específico. La mayoría de los productos tienen una garantía de una cantidad específica de años, por ejemplo, una garantía de veinte años como se muestra en la FIG. 13D. Alrededor de los veinte años, la productividad empezará a declinar, y utilizando la función de densidad exponencial, una organización puede determinar cuándo es más probable que el producto vaya a fallar, y pueden sustituirlo preventivamente. Utilizando el ejemplo de los veinte años, hay una gran cantidad de cálculos disponibles. La tabla representada en la FIG. 13E muestra algunos de los cálculos. La probabilidad de que el producto perezca antes del año 20 es del 36%, mientras que la probabilidad de que funcione entre los años 20 y 30 es del 14%, y así sucesivamente. Estos datos pueden utilizarse para evaluar las ganancias y pérdidas al sustituir preventivamente el producto a un año determinado, o simplemente dejar que el producto siga su curso, lo que posiblemente interrumpa todo el procedimiento y resulte en una pérdida global. Observando los gráficos de la línea de tiempo histórica, las organizaciones pueden decidir cuál es el mejor momento para sustituir el producto que menos perturbe todo el procedimiento.
12. Ejemplos de procedimientos
Varios procedimientos de ejemplo implementados en una SDN industrial que tiene la arquitectura descrita en las FIGS. a continuación, se describirán en la sección 5A-C.
La FIG. 14 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para simplificar el despliegue y el mantenimiento de la infraestructura de red en un dominio industrial de acuerdo con algunas realizaciones. En este procedimiento de ejemplo, ISDNA puede recibir al menos un criterio de comunicación definido por el usuario para un despliegue del sistema de automatización en el bloque 1402. El despliegue del sistema de automatización puede incluir al menos un primer dispositivo industrial y un segundo dispositivo industrial conectados a una SDN industrial. En algunas realizaciones, el despliegue del sistema de automatización puede definir servicios a nivel de red (por ejemplo, cortafuegos) que necesitan ser instados en la red SDN industrial. En algunas realizaciones, los criterios de comunicación definidos por el usuario pueden recibirse desde una aplicación industrial (por ejemplo, ejecutándose en un plano de aplicación de la arquitectura SDN industrial). Los ejemplos no limitantes de los criterios de comunicación definidos por el usuario incluyen la carga, la calidad del servicio, las capacidades del dispositivo de red, la sensibilidad al tiempo, y/o similares.
En el bloque 1404, la ISDNA puede coordinarse con un controlador SDN con el que establece una interfaz a través de un agente controlador SDN para determinar una trayectoria de comunicación entre los primeros y segundos dispositivos industriales. La trayectoria de comunicación puede determinarse en base al al menos un criterio de comunicación definido por el usuario en el bloque 1404a. Por ejemplo, si la red industrial SDN está compuesta por los dispositivos de red A, B, C, D, E y F, la trayectoria de comunicación puede evitar los dispositivos de red C y D porque ya están manejando un tráfico pesado y en su lugar elegir una trayectoria de red a través de los dispositivos A, B, E y F.
En el bloque 1406, el controlador SDN establece una interfaz con uno o más dispositivos de red para definir la trayectoria de comunicación para permitir la comunicación entre el primer dispositivo industrial y el segundo dispositivo industrial. La interacción con los dispositivos de red puede incluir la programación de los dispositivos de red, por ejemplo, para instalar o actualizar las reglas de manejo de paquetes (o tabla de flujo). Esto permite que cada dispositivo de red en la trayectoria de comunicación haga coincidir los paquetes con las reglas de manejo de paquetes y realice ciertas acciones especificadas. En algunas realizaciones, la trayectoria de comunicación (o trayectoria de red) puede pasar por un dispositivo de red virtualizado. Por lo tanto, la trayectoria de comunicación puede comprender dispositivos de red reales o virtualizados en el bloque 1406a. Por ejemplo, de los dispositivos de red A, B, E y F del ejemplo anterior, el dispositivo de red B puede ser un dispositivo de red virtualizado.
La FIG. 15 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para simplificar la gestión de una red industrial de acuerdo con algunas realizaciones.
En el procedimiento de ejemplo, un controlador SDN puede detectar la presencia de un nuevo dispositivo industrial en una SDN industrial en el bloque 1502. La presencia del nuevo dispositivo industrial en la red industrial puede ser detectada por un controlador de red definido por software (SDN) cuando un dispositivo de red en la red industrial no tiene reglas para manejar un mensaje del nuevo dispositivo industrial. En este caso, el mensaje se reenvía al controlador SDN. En el bloque 1504, un mensaje del nuevo dispositivo industrial puede ser dirigido a un servicio de autenticación que puede determinar si el nuevo dispositivo industrial está autorizado a participar en la red industrial. En algunas realizaciones, el enrutamiento del mensaje al servicio de autenticación puede ser en respuesta a un controlador de ciberseguridad que determina que al menos una política de ciberseguridad es aplicable al nuevo dispositivo industrial, y dicha política de ciberseguridad puede requerir que el nuevo dispositivo industrial sea autenticado por el servicio de autenticación. A continuación, el controlador SDN puede proporcionar una trayectoria de red desde el nuevo dispositivo industrial hasta el servicio de autenticación, para permitir que el siguiente mensaje del nuevo dispositivo industrial se dirija al servicio de autenticación. Si se determina que el nuevo dispositivo industrial no está autorizado a participar en la SDN industrial en el bloque de decisión 1506, el procedimiento de provisión se detiene en el bloque 1508. El nuevo dispositivo industrial no podrá comunicarse con otros dispositivos industriales de la red. Sin embargo, si el nuevo dispositivo industrial se autentifica con éxito, el procedimiento procede a ambos 1510 donde se pueden determinar los atributos del nuevo dispositivo industrial y su función industrial.
En el bloque 1512, el controlador SDN puede identificar, en base a los atributos del nuevo dispositivo industrial, al menos un recurso requerido por el nuevo dispositivo industrial para realizar su función industrial. En el bloque 1514, el controlador SDN puede proporcionar una trayectoria de red hacia el al menos un recurso para permitir que el nuevo dispositivo industrial realice su función industrial en la red industrial. En algunas realizaciones, el recurso requerido por el nuevo dispositivo industrial puede incluir uno o más de otros dispositivos industriales conectados a la red industrial, o un almacenamiento externo. Si, por ejemplo, el recurso es un almacenamiento externo, una ISDNA puede coordinarse con un controlador de gestión de la virtualización para instar un nodo de almacenamiento en una plataforma de gestión de la virtualización y proporcionar al controlador de la SDN la ubicación del nodo de almacenamiento para permitir que el controlador de la SDN aprovisione la nueva trayectoria desde el nuevo dispositivo industrial hasta el nodo de almacenamiento que proporciona el almacenamiento externo.
En algunas realizaciones, la trayectoria de red puede ser proporcionada en base a al menos un criterio definido por el usuario. Los criterios definidos por el usuario pueden incluir, pero sin limitación: un requisito de calidad de servicio, carga, capacidades del dispositivo de red y requisito de sensibilidad al tiempo.
En algunas realizaciones, se puede detectar un evento de desmantelamiento. Si se detecta un evento de este tipo en el bloque de decisión 1516, el controlador de la SDN puede desmantelar la trayectoria de red en el bloque 1518 y luego proporcionar una nueva trayectoria de red desde el nuevo dispositivo industrial hasta el recurso en el bloque 1514. Los ejemplos no limitantes del evento de desmantelamiento pueden incluir: una instrucción del usuario, una actualización de la política de ciberseguridad, una autodetección de un fallo a lo largo de la trayectoria de la red, una detección de una oportunidad para reoptimizar la trayectoria de la red, un cambio en las condiciones de carga, un cambio en la calidad del servicio, un evento de la red, y similares. Si no se detecta ningún evento de desmantelamiento en 1516, no se puede realizar ninguna acción en el bloque 1520.
La FIG. 16 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la gestión centralizada de una red industrial de acuerdo con algunas realizaciones.
En el bloque 1602, una instrucción de una aplicación industrial en un plano de aplicación es recibida por una ISDNA en el plano de plataforma. La aplicación industrial establece una interfaz con la ISDNA a través de una interfaz de programación de aplicaciones expuesta por la ISDNA. En respuesta a la instrucción de la aplicación industrial, la ISDNA coordina con múltiples entidades en el plano de plataforma y en el plano de control para instar bajo demanda un servicio a nivel de red en la red industrial en el bloque 1604. En algunas realizaciones, la etapa de instar puede ser realizada por la ISDNA en coordinación con al menos un controlador de red definido por software (SDN) en el plano de control. El plano de la plataforma está acoplado de manera comunicativa al plano de control a través de una interfaz de programación de aplicaciones.
En varias realizaciones, un servicio a nivel de red puede incluir, pero sin limitación, proporcionar conectividad entre al menos algunos de los componentes del plano de datos, un servicio de ciberseguridad, un equilibrador de carga y un analizador de tráfico. El servicio de nivel de red puede ser instado bajo demanda utilizando la virtualización de la función de red en el bloque 1606 en algunas realizaciones. La ISDNA puede coordinarse con el controlador SDN y el controlador de gestión de la virtualización para instar el servicio a nivel de red bajo demanda utilizando la virtualización de funciones de red. En otras realizaciones, el servicio de nivel de red puede ser instado bajo demanda utilizando el encadenamiento de funciones de servicio en el bloque 1608 que conecta al menos dos servicios de nivel de red para implementar una o más políticas de ciberseguridad gobernadas por el controlador de ciberseguridad. La ISDNA puede coordinarse con al menos el controlador SDN y el controlador de ciberseguridad para instar el servicio a nivel de red utilizando el encadenamiento de funciones de servicio. Algunos ejemplos no limitativos del servicio a nivel de red pueden incluir un cortafuegos virtual, inspección profunda de paquetes (DPI), equilibradores de carga, analizadores de tráfico, NAT, servicios de proxy, enrutamiento y similares.
La FIG. 17 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la supervisión centralizada y la elaboración de informes de una red industrial operativa. La red industrial de operación es una SDN desplegada en un dominio industrial y comprende un nivel físico, un nivel lógico, un nivel de tráfico, un nivel de función y un nivel de empresa. En algunas realizaciones, la ISDNA que tiene una vista centralizada de la red industrial operativa puede reunir y procesar información de eventos de red en cada nivel de la red industrial operativa en el bloque 1702. Por ejemplo, la ISDNA supervisa el estado actual de la red industrial operativa y realiza las etapas de recopilación y procesamiento, propagación, generación y suministro. En algunas realizaciones, la información de eventos de red está asociada a un evento de red detectado en un nivel por la ISDNA. Los ejemplos incluyen, pero sin limitación: una pérdida de conectividad a nivel físico de la red industrial operativa o un acceso no autorizado a la red industrial operativa.
En el bloque 1704, la ISDNA puede propagar al menos parte de la información de eventos de red de cada nivel a un nivel posterior, de forma que cada nivel posterior tenga información de eventos de red cohesionada de todos los niveles anteriores. En el bloque 1706, la ISDNA puede generar en cada nivel, a partir de la información de eventos de red coalescente disponible en ese nivel, información de eventos de red específica de nivel que es pertinente para los usuarios de uno o más grupos de usuarios que operan en ese nivel.
Por ejemplo, la información de eventos de red a nivel físico incluye o se deriva de al menos una de las siguientes: estadísticas de red, información específica del dispositivo, información de ubicación, conectividad de red, conectividad física o políticas de conectividad. La información de eventos de red a nivel lógico incluye o se deriva de al menos una de las siguientes: estadísticas de red, información específica del dispositivo, conectividad lógica, parámetros de conexión, comportamiento de la red, segmentos lógicos de la red, políticas de acceso a la red o configuración. De manera similar, la información de eventos de red a nivel de tráfico incluye o se deriva de al menos uno de los siguientes: salud de la conexión, estado de la conexión, estadísticas de protocolo, cantidad y tipo de tráfico generado por los dispositivos, capacidades de tráfico y de dispositivos, políticas de comunicación o tipo de transmisión. La información de eventos de red a nivel de función incluye o se deriva de al menos una de las siguientes: función industrial, conectividad, salud de la comunicación, tiempo de respuesta de la aplicación (ART) o políticas de comunicación. Por último, la información sobre eventos de red a nivel empresarial incluye o se deriva de al menos uno de los siguientes: coste de explotación, coste de mantenimiento, coste asociado a un impedimento de producción o coste asociado a un evento de red.
En el bloque 1708, la ISDNA puede proporcionar a un usuario información de eventos de red específicos del nivel correspondiente a un nivel en el que el usuario está operando en la red industrial operativa. En algunas realizaciones, el nivel físico está asociado a los usuarios de los grupos de usuarios de ingeniería, mantenimiento y seguridad, el nivel lógico y el nivel de tráfico están asociados a los usuarios de los grupos de usuarios de ingeniería y seguridad, el nivel de función está asociado a los usuarios de un grupo de usuarios operativos, y el nivel de empresa está asociado a los usuarios de un grupo de usuarios de gestión.
13. Sistematización informática
La FIG. 18 es un diagrama de bloques de una máquina/ordenador/aparato ejemplar que puede realizar varias operaciones, y almacenar varias informaciones generadas y/o utilizadas por tales operaciones de acuerdo con algunas realizaciones. El ordenador 1800 pretende ilustrar un dispositivo de hardware en el que cualquiera de las entidades, componentes o servicios representados en los ejemplos de las FIGS. 1A-13A, (y cualquier otro componente descrito en esta especificación) y las metodologías descritas en los ejemplos de las FIGS. 14-17 pueden implementarse, como un servidor, dispositivos de cliente, nodos informáticos, nodos controladores como el controlador de niebla (335, 435, 550, 750, 850), controlador de red (por ejemplo, 456), controlador SDN (por ejemplo, 555, 755a, 755, 855, 1155), controlador CS (por ejemplo, 445, 560, 860), dispositivos/nodos de almacenamiento, bases de datos, dispositivos industriales (por ejemplo, PLC, PAC), dispositivos de red, y similares. El ordenador 1800 incluye uno o más procesadores 1805 y memoria 1810 acoplados a una interconexión. La interconexión puede representar uno o más buses físicos separados, conexiones punto a punto, o ambos conectados por puentes, adaptadores o controladores apropiados.
Los procesadores 1805 son las unidades centrales de procesamiento (CPU) del ordenador y, por lo tanto, controlan la operación general del ordenador. En ciertas realizaciones, el procesador o procesadores logran esto mediante la ejecución de software o firmware almacenado en la memoria. El procesador o procesadores pueden ser, o pueden incluir, uno o más microprocesadores programables de propósito general o especial, procesadores de señales digitales (DSP), controladores programables, circuitos integrados de aplicación específica (ASIC), dispositivos lógicos programables (PLD), módulos de plataforma de confianza (TPM), o similares, o una combinación de dichos dispositivos.
La memoria 1810 es o incluye la memoria principal del ordenador. La memoria representa cualquier forma de memoria de acceso aleatorio (RAM), memoria de sólo lectura (ROM), memoria direccionable de contenido ternario (TCAM), memoria flash, o similares, o una combinación de tales dispositivos. En uso, la memoria puede contener un código. En una realización, el código incluye un módulo de programación general configurado para reconocer el programa de propósito general recibido a través de la interfaz de bus del ordenador, y preparar el programa de propósito general para su ejecución en el procesador. En otra realización, el módulo de programación general puede ser implementado utilizando circuitos de hardware tal como ASIC, PLD, o matrices de puertas programables en campo (FPGA).
También se conectan a los procesadores a través de la interconexión un adaptador de red 1825, un dispositivo(s) de almacenamiento 1815 y dispositivos de E/S 1820. El adaptador de red proporciona al ordenador la capacidad de comunicarse con dispositivos remotos, a través de una red y puede ser, por ejemplo, un adaptador Ethernet o un adaptador de canal de fibra o radio inalámbrica. El adaptador de red también puede proporcionar al ordenador la capacidad de comunicarse con otros ordenadores dentro del grupo. En algunas realizaciones, el ordenador puede utilizar más de un adaptador de red para tratar las comunicaciones dentro y fuera del grupo por separado.
Los dispositivos de E/S pueden incluir, por ejemplo, un teclado, un ratón u otro dispositivo señalador, unidades de disco, impresoras, un escáner y otros dispositivos de entrada y/o salida, incluyendo un dispositivo de visualización. El dispositivo de visualización puede incluir, por ejemplo, un tubo de rayos catódicos (CRT), una pantalla de cristal líquido (LCD), o algún otro dispositivo de visualización aplicable conocido o conveniente.
El código almacenado en la memoria puede ser implementado como software y/o firmware para programar los procesadores para llevar a cabo las acciones descritas anteriormente. En ciertas realizaciones, dicho software o firmware puede proporcionarse inicialmente al ordenador descargándolo desde un sistema remoto a través del ordenador (por ejemplo, mediante un adaptador de red). En algunas realizaciones, la memoria 1810 y los dispositivos de almacenamiento 1815 pueden ser una sola entidad.
Los componentes introducidos en la presente memoria pueden ser implementados, por ejemplo, por circuitos programables (por ejemplo, uno o más microprocesadores) programados con software y/o firmware, o enteramente en circuitos cableados de propósito especial (no programables), o en una combinación de tales formas. Los circuitos de propósito especial puede estar en forma de, por ejemplo, uno o más ASIC, PLD, FPGA, etc.
El software o firmware para su uso en el sistema SDN/TsDN introducido en la presente memoria puede ser almacenado en un medio de almacenamiento legible por máquina y puede ser ejecutado por uno o más microprocesadores programables de propósito general o especial. Un "medio de almacenamiento legible por máquina", tal y como se utiliza el término en el presente memoria, incluye cualquier mecanismo que pueda almacenar información en una forma accesible por una máquina.
Un ordenador también puede ser un ordenador servidor, un ordenador de cliente, un ordenador personal (PC), un PC tipo tableta , un ordenador portátil, un decodificador (STB), un asistente personal digital (PDA), un teléfono móvil, un teléfono inteligente, una tableta, un phablet, un procesador, un teléfono, un dispositivo web, un enrutador de red, un conmutador o un puente, un controlador (por ej., PLC, PAC), o cualquier máquina capaz de ejecutar un conjunto de instrucciones (secuenciales o de otro tipo) que especifiquen las acciones que debe realizar dicha máquina.
Un medio de almacenamiento accesible por la máquina o un dispositivo de almacenamiento incluye, por ejemplo, medios registrables/no registrables (por ejemplo, ROM; RAM; medios de almacenamiento en disco magnético; medios de almacenamiento óptico; dispositivos de memoria flash; etc.), etc., o cualquiera de sus combinaciones. El medio de almacenamiento puede ser típicamente no transitorio o incluir un dispositivo no transitorio. En este contexto, un medio de almacenamiento no transitorio puede incluir un dispositivo que es tangible, lo que significa que el dispositivo tiene una forma física concreta, aunque el dispositivo puede cambiar su estado físico. Por lo tanto, por ejemplo, no transitorio se refiere a un dispositivo que sigue siendo tangible a pesar de este cambio de estado.
El término "lógica", tal y como se utiliza en la presente memoria, puede incluir, por ejemplo, circuitos programables programados con software y/o firmware específico, circuitos cableados de propósito especial, o una combinación de los mismos.
14. Conclusión
A menos que el contexto requiera claramente lo contrario, a lo largo de la descripción y de las reivindicaciones, las palabras "comprende", "que comprende" y similares deben interpretarse en un sentido inclusivo, en contraposición a un sentido exclusivo o exhaustivo; es decir, en el sentido de "que incluye, pero no se limita a" Tal y como se utilizan en la presente memoria, los términos "conectado", "acoplado" o cualquiera de sus variantes, significan cualquier conexión o acoplamiento, directo o indirecto, entre dos o más elementos; el acoplamiento de la conexión entre los elementos puede ser físico, lógico o una de sus combinaciones. Además, los términos "en la presente memoria", "arriba", "abajo" y términos de significado similar, cuando se utilizan en esta solicitud, se refieren a esta solicitud en su conjunto y no a ninguna parte particular de esta solicitud. Cuando el contexto lo permita, los términos de la anterior Descripción Detallada que utilicen el número singular o plural pueden incluir también el número plural o singular, respectivamente. La palabra "o", en referencia a una lista de dos o más elementos, abarca todas las siguientes interpretaciones: cualquiera de los elementos de la lista, todos los elementos de la lista y cualquier combinación de los elementos de la lista.

Claims (15)

REIVINDICACIONES
1. Una red industrial definida por software que tiene una arquitectura para la gestión centralizada de la red industrial definida por software, comprendiendo la red industrial definida por software:
un plano de infraestructura (520) que incluye dispositivos físicos y virtuales conectados a la red industrial definida por software;
un plano de control (515) que comprende una pluralidad de controladores para controlar y gestionar los dispositivos físicos y virtuales en el plano de infraestructura hacia el sur, incluyendo la pluralidad de controladores un controlador de red definido por software (555), SDN, un controlador de gestión de la virtualización y un controlador de ciberseguridad (560), en la que el controlador de gestión de la virtualización está adaptado para utilizar una Interfaz de Programación de Aplicaciones, API, del controlador SDN para emitir comandos al controlador SDN para crear, configurar y rellenar tablas de reenvío de conmutadores de una base de datos de conmutadores virtuales de múltiples capas;
un plano de aplicación (505) que comprende una o más aplicaciones industriales; y
un plano de plataforma (510) que comprende un conjunto de servicios de software e interfaces de programación de aplicaciones, API, en la que el conjunto de servicios de software incluye una aplicación de red industrial definida por software, ISDNA (540), que proporciona interfaces de comunicación al plano de aplicación al norte y al plano de control al sur, las interfaces de comunicación adaptadas para proporcionar, a una aplicación industrial en el plano de aplicación, acceso programático a uno o más de la pluralidad de los controladores en el plano de control para la gestión centralizada de la red industrial definida por software.
2. La red industrial definida por software de la reivindicación 1, en la que el controlador de ciberseguridad (560) está acoplado de manera comunicativa al controlador de red y al controlador de gestión de la virtualización, y en la que el controlador de ciberseguridad está adaptado para controlar a través del controlador de red la accesibilidad, el uso y el contenido de la comunicación manipulada por los dispositivos físicos y virtuales en el plano de infraestructura.
3. La red industrial definida por software de la reivindicación 1, en la que el conjunto de servicios en el plano de plataforma (510) comprende además un servicio de gestión de la virtualización y un servicio de ciberseguridad, en la que la ISDNA (540) está acoplada de manera comunicativa tanto al servicio de gestión de la virtualización como al servicio de ciberseguridad.
4. La arquitectura de red industrial definida por software de la reivindicación 3, en la que la ISDNA (540), el servicio de gestión de la virtualización y el servicio de ciberseguridad del plano de plataforma están acoplados al controlador de red, al controlador de gestión de la virtualización y al controlador de ciberseguridad del plano de control, respectivamente.
5. La red industrial definida por software de la reivindicación 1, en la que la red industrial definida por software comprende redes reales y virtuales, y en la que la red real está adaptada para ser controlada por el controlador de red mientras que la red virtual está adaptada para ser controlada por el controlador de gestión de la virtualización, estando el controlador de red acoplado de manera comunicativa al controlador de gestión de la virtualización.
6. La red industrial definida por software de la reivindicación 3, en la que la ISDNA (540) está adaptada para establecer una interfaz con un controlador de red a través de un agente controlador de red para el controlador de red.
7. La red industrial definida por software de la reivindicación 6, en la que la ISDNA (540) incluye un agente de dispositivo que está adaptado para establecer una interfaz con dispositivos de red heredados en el plano de infraestructura.
8. La ISDN de la reivindicación 1, en la que uno o más servicios de nivel de red incluyen un cortafuegos virtual desplegado en la red industrial definida por software, y en la que el controlador de SDN (555) dirige, en base a una o más políticas de ciberseguridad definidas por el controlador de ciberseguridad, el tráfico que coincida con uno o más criterios a través del cortafuegos virtual para su procesamiento.
9. Un procedimiento para la gestión centralizada de una red industrial definida por software ISDN de acuerdo con la reivindicación 1, comprendiendo el procedimiento:
recibir (1602), por la aplicación de red industrial definida por software, ISDNA, de la red industrial definida por software, ISDN, una instrucción de una aplicación industrial en un plano de aplicación de la ISDN, estableciendo la aplicación industrial una interfaz con la ISDNA a través de una interfaz de programación de aplicaciones expuesta por la ISDNA;
en respuesta (1604) a la instrucción de la aplicación industrial, instar, por parte de la ISDNA, bajo demanda uno o más servicios de nivel de red en la ISDN, en el que la etapa de instar es realizada por la ISDNA en coordinación con al menos un controlador de red definido por software, SDN, de la ISDN.
10. El procedimiento de la reivindicación 9, en el que uno o más servicios de nivel de red incluyen proporcionar conectividad entre al menos algunos de los componentes del plano de datos.
11. El procedimiento de la reivindicación 9 o 10, en el que uno o más servicios a nivel de red incluyen un servicio de ciberseguridad, un equilibrador de carga o un analizador de tráfico.
12. El procedimiento de cualquiera de las reivindicaciones 9 - 11, en el que uno o más servicios de nivel de red son instados bajo demanda utilizando la virtualización de funciones de red.
13. El procedimiento de cualquiera de las reivindicaciones 9-12, en el que el uno o más servicios de nivel de red es instado por la ISDNA en coordinación con el controlador de SDN y el controlador de gestión de virtualización de la ISDN y el controlador de ciberseguridad de la ISDN.
14. El procedimiento de cualquiera de las reivindicaciones 9-13, en el que la etapa de instar bajo demanda de uno o más servicios de nivel de red incluye el uso de encadenamiento de funciones de servicio (1608) para conectar al menos dos servicios de nivel de red para implementar una o más políticas de ciberseguridad gobernadas por el controlador de ciberseguridad.
15. El procedimiento de cualquiera de las reivindicaciones 9-14, en el que cada uno de la pluralidad de controladores en el plano de control es una entidad lógicamente centralizada que se ejecuta en un entorno informático distribuido.
ES17748474T 2016-08-03 2017-08-03 Arquitectura de red industrial definida por software para despliegue en un sistema de automatización definido por software Active ES2908461T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662370686P 2016-08-03 2016-08-03
US201662376470P 2016-08-18 2016-08-18
PCT/EP2017/069606 WO2018024809A1 (en) 2016-08-03 2017-08-03 Industrial software defined networking architecture for deployment in a software defined automation system

Publications (1)

Publication Number Publication Date
ES2908461T3 true ES2908461T3 (es) 2022-04-29

Family

ID=59520907

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17748474T Active ES2908461T3 (es) 2016-08-03 2017-08-03 Arquitectura de red industrial definida por software para despliegue en un sistema de automatización definido por software

Country Status (7)

Country Link
US (2) US11134010B2 (es)
EP (2) EP3494687B1 (es)
CN (1) CN109716732B (es)
AU (2) AU2017307345B2 (es)
ES (1) ES2908461T3 (es)
RU (1) RU2737480C2 (es)
WO (1) WO2018024809A1 (es)

Families Citing this family (108)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12276420B2 (en) 2016-02-03 2025-04-15 Strong Force Iot Portfolio 2016, Llc Industrial internet of things smart heating systems and methods that produce and use hydrogen fuel
US11605037B2 (en) * 2016-07-20 2023-03-14 Fisher-Rosemount Systems, Inc. Fleet management system for portable maintenance tools
US11924322B2 (en) * 2017-05-16 2024-03-05 Arm Ltd. Blockchain for securing and/or managing IoT network-type infrastructure
US11681568B1 (en) 2017-08-02 2023-06-20 Styra, Inc. Method and apparatus to reduce the window for policy violations with minimal consistency assumptions
US11496517B1 (en) 2017-08-02 2022-11-08 Styra, Inc. Local API authorization method and apparatus
EP4060481A1 (en) * 2017-09-19 2022-09-21 Huawei Technologies Co., Ltd. Application deployment method, apparatus, and system
US11488692B2 (en) * 2018-03-30 2022-11-01 CurieHealth, Inc. Emergency department communication system
US11394653B2 (en) 2018-04-04 2022-07-19 Siemens Aktiengesellschaft Data transmission in time-sensitive data networks
US20200133254A1 (en) 2018-05-07 2020-04-30 Strong Force Iot Portfolio 2016, Llc Methods and systems for data collection, learning, and streaming of machine signals for part identification and operating characteristics determination using the industrial internet of things
US11140019B2 (en) * 2018-06-01 2021-10-05 David M. Sherr Software-defined network resource provisioning architecture
JP6973299B2 (ja) * 2018-06-04 2021-11-24 日本電信電話株式会社 管理装置、および、管理方法
WO2019245824A1 (en) 2018-06-18 2019-12-26 Battelle Energy Alliance, Llc Smart network switching systems and related methods
US10298329B1 (en) 2018-06-28 2019-05-21 At&T Intellectual Property I, L.P. Multi-layer system self-optimization
US10719373B1 (en) 2018-08-23 2020-07-21 Styra, Inc. Validating policies and data in API authorization system
US11853463B1 (en) 2018-08-23 2023-12-26 Styra, Inc. Leveraging standard protocols to interface unmodified applications and services
US11080410B1 (en) 2018-08-24 2021-08-03 Styra, Inc. Partial policy evaluation
CN108989134B (zh) * 2018-09-04 2021-09-07 浪潮云信息技术股份公司 基于sdn的虚拟化网络数据平面配置恢复系统及方法
EP3629108B1 (de) * 2018-09-28 2022-08-24 Siemens Aktiengesellschaft Projektierung eines automatisierungssystems
US11245728B1 (en) * 2018-10-16 2022-02-08 Styra, Inc. Filtering policies for authorizing an API
US10841509B2 (en) 2018-10-22 2020-11-17 At&T Intellectual Property I, L.P. Camera array orchestration
US10785115B2 (en) * 2018-10-26 2020-09-22 Illumio, Inc. Allocating enforcement of a segmentation policy between host and network devices
CN113016162A (zh) * 2018-11-20 2021-06-22 Abb瑞士股份有限公司 联网设备的配置
TWI699136B (zh) * 2018-12-12 2020-07-11 中華電信股份有限公司 用於軟體定義網路的動態串接系統及其方法
US20220060966A1 (en) * 2018-12-18 2022-02-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and Controller for Managing a Microwave Network
EP3909223B1 (en) * 2019-01-13 2024-08-21 Strong Force Iot Portfolio 2016, LLC Monitoring and managing industrial settings
TWI713384B (zh) * 2019-02-12 2020-12-11 中華電信股份有限公司 虛擬公眾ＷｉＦｉ電路指配系統
EP3703340A1 (de) * 2019-02-26 2020-09-02 Siemens Aktiengesellschaft Verfahren zum betreiben von netzwerkgeräten in einem netzwerk, recheneinrichtung sowie netzwerk
DE102019106543A1 (de) * 2019-03-14 2020-09-17 Anapur Ag Verfahren und Kommunikationssteuersystem zur Steuerung von Kommunikation in einem Kommunikationsnetzwerk
US11418399B2 (en) * 2019-04-30 2022-08-16 Cisco Technology, Inc. Multi-fabric deployment and management platform
CN111917689B (zh) * 2019-05-08 2023-02-03 创升益世(东莞)智能自控有限公司 一种应用于工业互联网的虚拟主机系统
US11593525B1 (en) 2019-05-10 2023-02-28 Styra, Inc. Portable policy execution using embedded machines
US11231701B2 (en) 2019-06-10 2022-01-25 Fisher-Rosemount Systems, Inc. Publish/subscribe protocol for real-time process control
GB2621485B (en) 2019-06-10 2024-08-28 Fisher Rosemount Systems Inc Ease of node switchovers in process control systems
GB2623651B (en) 2019-06-10 2024-11-20 Fisher Rosemount Systems Inc Automatic load balancing and performance leveling of virtual nodes running real-time control in process control systems
GB2589661B (en) 2019-06-10 2024-06-05 Fisher Rosemount Systems Inc Virtualized real-time I/O in process control systems
US11550311B2 (en) 2019-06-10 2023-01-10 Fisher-Rosemount Systems, Inc. Centralized virtualization management node in process control systems
US11249464B2 (en) 2019-06-10 2022-02-15 Fisher-Rosemount Systems, Inc. Industrial control system architecture for real-time simulation and process control
US11681278B2 (en) * 2019-06-19 2023-06-20 Honeywell International Inc. High availability for container based control execution
DE102019120103A1 (de) * 2019-07-25 2021-01-28 Beckhoff Automation Gmbh Verfahren zur Datenkommunikation zwischen Feldbusgeräten und einem Leitstand eines Automatisierungssystems und Automatisierungssystem
US10979309B2 (en) * 2019-08-07 2021-04-13 Schweitzer Engineering Laboratories, Inc. Automated convergence of physical design and configuration of software defined network
US11411843B2 (en) * 2019-08-14 2022-08-09 Verizon Patent And Licensing Inc. Method and system for packet inspection in virtual network service chains
US11057348B2 (en) 2019-08-22 2021-07-06 Saudi Arabian Oil Company Method for data center network segmentation
WO2021040674A1 (en) * 2019-08-23 2021-03-04 Siemens Aktiengesellschaft Aspect-oriented programming based programmable logic controller (plc) simulation
US11516086B1 (en) * 2019-09-04 2022-11-29 Cisco Technology, Inc. Method and apparatus for automated spanning-tree loop detection in networks
EP3800864B1 (de) * 2019-10-01 2022-11-23 Siemens Aktiengesellschaft Verfahren zum konfigurieren eines opc ua pubsub teilnehmers, automatisierungssystem, computerprogramm und computerlesbares medium
US11349663B2 (en) * 2019-10-30 2022-05-31 International Business Machines Corporation Secure workload configuration
CN112994994B (zh) * 2019-12-16 2022-09-06 中国科学院沈阳自动化研究所 基于工业以太网协议在工业sdn中的接入方法
EP3845984B1 (en) * 2019-12-31 2025-09-10 Schneider Electric Systems USA, Inc. Secure network of safety plcs for industrial plants
US20210218772A1 (en) * 2020-01-14 2021-07-15 Saudi Arabian Oil Company Security configuration assessment of newly commissioned network hardware devices
US11502992B1 (en) 2020-01-27 2022-11-15 Styra, Inc. Local controller and local agent for local API authorization
US12498998B1 (en) 2020-03-02 2025-12-16 Apple Inc. Method and apparatus for enforcing policies for authorizing APIs
US11907742B2 (en) * 2020-04-02 2024-02-20 Vmware, Inc. Software-defined network orchestration in a virtualized computer system
US11316736B2 (en) * 2020-05-04 2022-04-26 Cisco Technology, Inc. Intent-based networking using device administrative shell
CN111600754B (zh) * 2020-05-11 2022-02-25 重庆邮电大学 一种面向tsn和非tsn互联的工业异构网络调度方法
EP3929679A1 (en) * 2020-06-23 2021-12-29 ABB Schweiz AG Engineering system for orchestration of an industrial plant
US12003543B1 (en) 2020-07-24 2024-06-04 Styra, Inc. Method and system for modifying and validating API requests
US11513778B1 (en) 2020-08-14 2022-11-29 Styra, Inc. Graphical user interface and system for defining and maintaining code-based policies
US12066804B2 (en) 2020-09-22 2024-08-20 Rockwell Automation Technologies, Inc. Integrating container orchestration systems with operational technology devices
US11474873B2 (en) * 2020-09-22 2022-10-18 Rockwell Automation Technologies, Inc. Implementing serverless functions using container orchestration systems and operational technology devices
US11593363B1 (en) 2020-09-23 2023-02-28 Styra, Inc. Comprehension indexing feature
US11520579B1 (en) 2020-11-30 2022-12-06 Styra, Inc. Automated asymptotic analysis
CN112511462B (zh) * 2020-12-17 2022-07-26 上海交通大学 一种软件定义工业异构时间敏感网络系统及资源调度方法
CN112578755B (zh) * 2020-12-17 2025-09-23 上海通群科技有限公司 可编程智能控制器及基于可编程智能控制器的应用系统
US11463326B2 (en) 2021-02-24 2022-10-04 Cisco Technology, Inc. Lightweight ring manager with distributed policies
CN113037731B (zh) * 2021-02-27 2023-06-16 中国人民解放军战略支援部队信息工程大学 基于sdn架构和蜜网的网络流量控制方法及系统
US11310146B1 (en) 2021-03-27 2022-04-19 Netflow, UAB System and method for optimal multiserver VPN routing
US12417120B2 (en) * 2021-06-16 2025-09-16 Fisher-Rosemount Systems, Inc. Systems and methods for dynamically maintained redundancy and load balancing in software defined control systems for industrial process plants
US11716305B2 (en) 2021-06-29 2023-08-01 Cisco Technology, Inc. Control embedded data packet for efficient ARP query in SDA environment
NL2028737B1 (en) * 2021-07-15 2023-01-20 Axite Intelligence Services B V A method, a monitoring system and a computer program product for monitoring a network connected controller
CN114363187B (zh) * 2021-07-16 2023-10-13 网络通信与安全紫金山实验室 一种虚拟工业设备节点的部署方法及系统
US11522755B1 (en) 2021-07-19 2022-12-06 Cisco Technology, Inc. Automated provisioning of endpoint devices with management connectivity
WO2023003812A1 (en) * 2021-07-19 2023-01-26 Cisco Technology, Inc. Automated provisioning of endpoint devices with management connectivity
US12135974B1 (en) 2021-09-29 2024-11-05 Styra, Inc. Using custom templates to define new system types for instantiation
US12133095B2 (en) * 2021-10-15 2024-10-29 Hewlett Packard Enterprise Development Lp Machine learning-based approaches for service function chain selection
CN114124650A (zh) * 2021-12-08 2022-03-01 中国电子科技集团公司第三十四研究所 一种sptn网络控制器主从部署方法
US12061461B2 (en) 2022-01-13 2024-08-13 Saudi Arabian Oil Company System and method for the automatic switching of multiple vendor controllers with an interfaced input/output device
TWI820717B (zh) * 2022-05-20 2023-11-01 智連工控股份有限公司 去中心化之製造場域智慧型輔助系統及其橋接介面裝置
CN115037762B (zh) * 2022-05-26 2023-04-07 清华大学 一种基于控制和传输融合交换机的工业网络系统
JP2023180512A (ja) * 2022-06-09 2023-12-21 株式会社日立製作所 認証認可システム、認証認可手段決定方法および認証認可手段決定プログラム
CN115102777A (zh) * 2022-07-11 2022-09-23 上海磐御网络科技有限公司 一种网络流量的隔离引导方法及系统
CN115102862B (zh) * 2022-07-22 2024-03-12 烽火通信科技股份有限公司 一种用于sdn设备的自动同步方法及装置
US20240039813A1 (en) * 2022-07-27 2024-02-01 Vmware, Inc. Health analytics for easier health monitoring of a network
US12520193B2 (en) * 2022-08-15 2026-01-06 At&T Intellectual Property I, L.P. Extended, open network architectures supporting delivery of network-accessible services
CN115396495B (zh) * 2022-08-22 2023-12-12 上海交通大学 一种sdn-fog环境下工厂微服务体系的故障应对方法
US20240118669A1 (en) * 2022-10-10 2024-04-11 Schneider Electric USA, Inc. Management system for infrastructure of an industrial system
CN116112304A (zh) * 2022-10-25 2023-05-12 广州西麦科技股份有限公司 一种内生安全可编程网络系统
US12040955B2 (en) 2022-11-08 2024-07-16 Be Broadband Technologies (Bbt.Live) Ltd. System and method for the management and optimization of software defined networks
IL298056B2 (en) * 2022-11-08 2024-04-01 Be Broadband Tech Bbt Live Ltd A system and method for managing and optimizing software defined networks
US12081565B2 (en) * 2022-11-14 2024-09-03 Rockwell Automation Technologies, Inc. Facilitating direct device-to-cloud communications within a secure deployment management system
CN116232743A (zh) * 2023-03-15 2023-06-06 国网智能电网研究院有限公司 基于软件定义的多组件协同防护方法及装置
US12452260B2 (en) * 2023-03-21 2025-10-21 Honeywell International Inc. Apparatuses, computer-implemented methods, and computer program products for improved remote access cybersecurity based on quarantining remote action data and generating malicious determination data
US12218822B2 (en) 2023-03-28 2025-02-04 Netflow, UAB Hierarchical-context area network as a virtual private network infrastructure system
US12341696B2 (en) 2023-03-28 2025-06-24 Netflow, UAB Hierarchical-context area network as a virtual private network infrastructure system
US20250036496A1 (en) * 2023-07-25 2025-01-30 Siemens Aktiengesellschaft Method and device for automatically generating a rest api specification based on a plain-text user story
US20250039220A1 (en) * 2023-07-28 2025-01-30 Cisco Technology, Inc. Dynamic placement of compensating controls on dpu and ebpf based on workload, trust, and threat scoring
US12495051B2 (en) * 2023-09-29 2025-12-09 Dell Products L.P. Service level verification in distributed system
US12549440B2 (en) 2023-09-29 2026-02-10 Dell Products L.P. Management of network services through pre-population of management plane from system level view
US12609874B2 (en) 2023-09-29 2026-04-21 Dell Products L.P. Dynamic subscription based management of networks for computing systems
US12355770B2 (en) * 2023-10-03 2025-07-08 strongDM, Inc. Identity and activity based network security policies
US12223062B1 (en) 2024-03-27 2025-02-11 Zafran Security LTD Techniques for identifying gaps in security controls
US12184687B1 (en) * 2024-03-27 2024-12-31 Zafran Security LTD Techniques for mapping security controls to cyber threats
US20250330469A1 (en) * 2024-04-17 2025-10-23 Red Hat, Inc. Remote login resource access control using a container
US12542786B2 (en) 2024-04-29 2026-02-03 Dell Products L.P. Systems and methods for managing operations of data processing systems based on geolocation tracking
US12494979B2 (en) * 2024-04-29 2025-12-09 Dell Products L.P. Authentication systems and methods using an existence confirmation result
US12242599B1 (en) 2024-09-27 2025-03-04 strongDM, Inc. Fine-grained security policy enforcement for applications
US12348519B1 (en) 2025-02-07 2025-07-01 strongDM, Inc. Evaluating security policies in aggregate
US12432242B1 (en) 2025-03-28 2025-09-30 strongDM, Inc. Anomaly detection in managed networks
US12603921B1 (en) 2025-11-19 2026-04-14 strongDM, Inc. Indexing entities and attributes for policy enforcement

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114474A1 (en) * 2003-11-20 2005-05-26 International Business Machines Corporation Automatic configuration of the network devices via connection to specific switch ports
US8942219B2 (en) * 2007-04-13 2015-01-27 Hart Communication Foundation Support for network management and device communications in a wireless network
US8918835B2 (en) * 2010-12-16 2014-12-23 Futurewei Technologies, Inc. Method and apparatus to create and manage virtual private groups in a content oriented network
US8693374B1 (en) * 2012-12-18 2014-04-08 Juniper Networks, Inc. Centralized control of an aggregation network with a reduced control plane
CN105340241A (zh) * 2013-11-27 2016-02-17 华为技术有限公司 用于均衡在sdn网络中的负载的方法和系统
US9953171B2 (en) * 2014-09-22 2018-04-24 Infosys Limited System and method for tokenization of data for privacy
US10644950B2 (en) * 2014-09-25 2020-05-05 At&T Intellectual Property I, L.P. Dynamic policy based software defined network mechanism
CN104582004B (zh) * 2015-01-13 2018-04-06 成都西加云杉科技有限公司 基于sdn的wlan分层组网系统及方法
CN106411820B (zh) * 2015-07-29 2019-05-21 中国科学院沈阳自动化研究所 一种基于sdn架构的工业通信流传输安全控制方法
CN105406992B (zh) * 2015-10-28 2018-11-09 浙江工商大学 一种面向sdn的业务需求转化和部署方法
CN105430688B (zh) * 2015-11-13 2019-03-08 重庆邮电大学 一种基于软件定义网络的wlan系统
US10355969B2 (en) * 2015-12-25 2019-07-16 KN Install Solutions (N.IRE) Limited Data driven orchestrated network using a light weight distributed sdn controller
US10257100B2 (en) * 2016-05-04 2019-04-09 University of Conneticut Enabling resilient microgrid through ultra-fast programmable network

Also Published As

Publication number Publication date
RU2019105709A (ru) 2020-09-04
US20210029029A1 (en) 2021-01-28
RU2737480C2 (ru) 2020-12-01
AU2022203513A1 (en) 2022-06-09
CN109716732A (zh) 2019-05-03
EP3494687B1 (en) 2021-12-15
AU2017307345B2 (en) 2022-02-24
EP3985938A2 (en) 2022-04-20
CA3032323A1 (en) 2018-02-08
AU2022203513B2 (en) 2025-04-24
AU2017307345A1 (en) 2019-01-31
US11134010B2 (en) 2021-09-28
US20210385159A1 (en) 2021-12-09
EP3985938A3 (en) 2022-07-06
RU2019105709A3 (es) 2020-09-28
WO2018024809A1 (en) 2018-02-08
EP3494687A1 (en) 2019-06-12
US11888739B2 (en) 2024-01-30
CN109716732B (zh) 2021-07-27

Similar Documents

Publication Publication Date Title
ES2908461T3 (es) Arquitectura de red industrial definida por software para despliegue en un sistema de automatización definido por software
US12585256B2 (en) Software defined automation system and architecture
CA3032323C (en) Industrial software defined networking architecture for deployment in a software defined automation system