ES2941337T3 - Sistema y arquitectura de automatización definidos por software - Google Patents

Sistema y arquitectura de automatización definidos por software Download PDF

Info

Publication number
ES2941337T3
ES2941337T3 ES16798807T ES16798807T ES2941337T3 ES 2941337 T3 ES2941337 T3 ES 2941337T3 ES 16798807 T ES16798807 T ES 16798807T ES 16798807 T ES16798807 T ES 16798807T ES 2941337 T3 ES2941337 T3 ES 2941337T3
Authority
ES
Spain
Prior art keywords
network
functional unit
automation
physical
subsystem
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
ES16798807T
Other languages
English (en)
Inventor
Antonio Chauvet
Philippe Wilhelm
harriman Merrill
Eric Alfano
Alen Mehmedagic
Andrew Lee Kling
David Doggett
Vijay Vallala
Philippe Nappey
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 ES2941337T3 publication Critical patent/ES2941337T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4185—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B15/00—Systems controlled by a computer
    • G05B15/02—Systems controlled by a computer electric
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41865—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by job scheduling, process planning, material flow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45541—Bare-metal, i.e. hypervisor runs directly on hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/351—Switches specially adapted for specific applications for local area network [LAN], e.g. Ethernet switches
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • 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/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/16—Plc to applications
    • G05B2219/163—Domotique, domestic, home control, automation, smart, intelligent house
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/25—Pc structure of the system
    • G05B2219/25011—Domotique, I-O bus, home automation, building automation
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2642—Domotique, domestic, home control, automation, smart house
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/31—From computer integrated manufacturing till monitoring
    • G05B2219/31229—Supervisor, master, workstation controller, automation, machine control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/80—Management or planning

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Automation & Control Theory (AREA)
  • Quality & Reliability (AREA)
  • Manufacturing & Machinery (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Programmable Controllers (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Multi Processors (AREA)

Abstract

Realizaciones de un sistema de automatización definido por software que proporciona una arquitectura de referencia para diseñar, administrar y mantener un sistema de automatización altamente disponible, escalable y flexible. En algunas realizaciones, un sistema SDA puede incluir un subsistema localizado que incluye un nodo controlador del sistema y múltiples nodos de cálculo. Los múltiples nodos de computación pueden acoplarse comunicativamente al nodo controlador del sistema a través de una primera red de comunicación. El nodo controlador del sistema puede gestionar los múltiples nodos informáticos y la virtualización de un sistema de control en un nodo informático a través de la primera red de comunicación. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Sistema y arquitectura de automatización definidos por software
Referencia cruzada a solicitud(es) relacionada(s)
Esta solicitud reivindica prioridad y se beneficia de las siguientes solicitudes provisionales de patente: (1) Solicitud Provisional de los Estados Unidos Ser. Núm. 62/241.028 titulado “Software-Defined Automation”, presentado el 13 de octubre de 2015, (2) Solicitud Provisional de los Estados Unidos Ser. Núm. 62/240.742 titulado “Architecture for Connecting Objects in the Industrial Internet of Things”, presentado el 13 de octubre de 2015, (3) Solicitud Provisional de los Estados Unidos Ser. Núm. 62/348.770 titulado “Software-Defined Automation” y presentado el 10 de junio de 2016, (4) Solicitud Provisional de los Estados Unidos Ser. Núm. 62/354.683 titulado “Software-Defined Automation Architecture”, presentado el 24 de junio de 2016, (5) Solicitud Provisional de los Estados Unidos Ser. Núm. 62/354.799 titulado “Software-Defined Automation Architecture”, presentado el 26 de junio de 2016, y (6) Solicitud provisional de los Estados Unidos Ser. Núm. 62/406.932 titulado “Software Defined Automation System and Architecture” presentado el 11 de octubre de 2016.
Antecedentes
La automatización es el uso de dispositivos de control automático y diversas tecnologías para automatizar la monitorización, el funcionamiento y el control de procesos e instalaciones sin una intervención humana significativa para lograr un rendimiento superior al del control manual. Los sistemas de automatización conocidos para monitorizar y controlar procesos e instalaciones (por ejemplo, en plantas, edificios, etc.) suelen incluir varios dispositivos de automatización, tales como controladores (por ejemplo, controladores lógicos programables (PLC), controladores de automatización programables (PAC)), dispositivos de entrada/salida (dispositivos de E/S), dispositivos de campo (por ejemplo, sensores y actuadores), ordenadores personales (PC), interfaces hombremáquina (HMI) y similares. Los controladores ejecutan programas definidos por el usuario para controlar procesos automatizados. Normalmente, en un sistema de control, los controladores leen los datos de entrada de los dispositivos de campo, tales como sensores y dispositivos de medición, y usan los datos de entrada para generar salidas de control basadas en los programas definidos por el usuario
Los documentos GB 2521 376 A, EP 2293164 A1, EP 2801942 A1, EP 2801941 A1, US 2014/228978 A1 y EP 2 899604 A1 representan el estado de la técnica pertinente.
Breve descripción de los dibujos
La FIG. 1 es un diagrama de bloques que ilustra los aspectos de una tecnología de automatización definida por software (“SDA”) de acuerdo con algunas realizaciones.
La FIG. 2A es un diagrama de bloques que ilustra un ejemplo de arquitectura de un sistema de automatización tradicional implantado en algunas industrias.
La FIG. 2B es un diagrama de bloques que ilustra un ejemplo de una arquitectura de sistema de automatización simplificada y flexible de acuerdo con algunas realizaciones.
La FIG. 3 es un diagrama de bloques que ilustra un ejemplo de una arquitectura de tecnología operativa más plana y flexible para una empresa de acuerdo con algunas realizaciones.
La FIG. 4 es un diagrama que ilustra una arquitectura simplificada de un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 5 es un diagrama de bloques que ilustra una arquitectura funcional de un SDA de acuerdo con algunas realizaciones.
La FIG. 6A es un diagrama de bloques que ilustra subsistemas de un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 6B es un diagrama que ilustra el alcance del control de cada uno de los subsistemas SDA de acuerdo con algunas realizaciones.
La FIG. 7A es un diagrama de bloques que ilustra la interacción entre el software de la solución y el equipo de automatización en sistemas de automatización tradicionales y entre el software de un sistema y el equipo de automatización en un entorno SDA de acuerdo con algunas realizaciones.
La FIG. 7B es un diagrama de bloques que ilustra los componentes de ejemplo de un software de sistema de un sistema SDA de acuerdo con algunas realizaciones.
Las FIGS. 7C a 7F son diagramas de capturas de pantalla que ilustran ejemplos de interfaces de usuario de un software de sistema de acuerdo con algunas realizaciones.
La FIG. 8A es un diagrama de bloques que ilustra componentes del servidor de niebla de ejemplo de acuerdo con una primera realización.
La FIG. 8B es un diagrama de bloques que ilustra componentes del servidor de niebla de ejemplo de acuerdo con una segunda realización.
La FIG. 9A es un diagrama de bloques que ilustra componentes de un controlador del servidor de niebla de acuerdo con algunas realizaciones.
La FIG. 9B es un diagrama de bloques que ilustra componentes de ejemplo de un nodo de cómputo que aloja máquinas virtuales de acuerdo con algunas realizaciones.
La FIG. 9C es un diagrama de bloques que ilustra componentes de ejemplo de un nodo de cómputo que aloja contenedores de acuerdo con una primera realización.
La FIG. 9D es un diagrama de bloques que ilustra componentes de ejemplo de un nodo de cómputo que aloja contenedores de acuerdo con una segunda realización.
La FIG. 9E es un diagrama de bloques que ilustra componentes de ejemplo de un nodo de cómputo que aloja una imagen de bare metal.
La FIG. 10A es un diagrama de bloques que ilustra un ejemplo de una vista de componente de un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 10B es un diagrama de bloques que ilustra ejemplos de una vista de control y una vista de sistema de un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 11 es un diagrama de bloques que ilustra un ejemplo de orquestación de subsistemas SDA para aprovisionar una unidad funcional en un nodo de cómputo de acuerdo con algunas realizaciones.
La FIG. 12 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la creación de un sistema de automatización de acuerdo con algunas realizaciones.
La FIG. 13A es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la adición de una unidad funcional a un sistema de automatización a través de un software de sistema de acuerdo con algunas realizaciones.
La FIG. 13B representa un ejemplo de una vista topológica de un sistema transportador de acuerdo con algunas realizaciones.
La FIG. 14 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para el aprovisionamiento de una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 15 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la configuración de una unidad funcional en un sistema s Da de acuerdo con algunas realizaciones.
La FIG. 16A es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la definición de un sistema de automatización vía software de acuerdo con algunas realizaciones.
La FIG. 16B es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la puesta en servicio o aprovisionamiento de una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 17 es un diagrama de bloques que ilustra componentes de ejemplo de un componente de gestión de host de un controlador del servidor de niebla de un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 18A es un diagrama de bloques que ilustra algunos ejemplos de clases de eventos en el entorno virtual y/o físico de un sistema SDA que pueden ser detectados de acuerdo con algunas realizaciones.
La FIG. 18B es un diagrama de bloques que ilustra algunos controladores de eventos de ejemplo en un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 19 es un diagrama de bloques que ilustra un ejemplo de una respuesta coordinada a un evento de ciberseguridad desde un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 20 es un diagrama de bloques que ilustra un ejemplo de una respuesta coordinada a un evento de fallo del nodo de cómputo de un sistema SDA de acuerdo con algunas realizaciones.
La FIG. 21A es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo de selección de un recurso de cómputo para desplegar una instancia/componente virtualizado de acuerdo con algunas realizaciones.
La FIG. 21B es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la selección de un recurso de cómputo para la implementación de un huésped de acuerdo con algunas realizaciones.
La FIG. 22 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la gestión de un sistema SDA de acuerdo con una primera realización.
La FIG. 23 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la detección y manejo de un evento de fallo de acuerdo con algunas realizaciones.
La FIG. 24 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la gestión de un sistema de automatización de acuerdo con una segunda realización.
La FIG. 25 muestra una representación diagramática de una máquina en la forma de ejemplo de un sistema informático dentro del cual se puede ejecutar un conjunto de instrucciones, para hacer que la máquina lleve a cabo una o más de las metodologías discutidas en la presente memoria.
DESCRIPCIÓN DETALLADA
1. Visión general
La invención se define por el sistema y el procedimiento definidos en las reivindicaciones independientes 1 y 9 adjuntas.
Esta divulgación describe la tecnología y el sistema de Automatización Definida por Software (en adelante “SDA”) (en adelante “sistema SDA”) que proporciona una arquitectura de referencia para diseñar, gestionar y mantener un sistema de automatización altamente disponible, escalable y flexible.
Esta divulgación también describe sistemas y procedimientos para proporcionar una gestión centralizada del sistema SDA que incluyen sus recursos de computación, recursos de red y recursos de seguridad.
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 porción 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 llevar a cabo las tareas de ingeniería de todo el ciclo de vida de la ingeniería de automatización, tal como el diseño, la programación, la configuración, la instalación, la operación, el mantenimiento, la evolución y el apagado, de una forma más sencilla, eficiente y rentable.
Como se ilustra en la FIG. 1, la arquitectura de un sistema SDA 100 comprende tres aspectos: (1) un sistema distribuido inteligente 105, (2) una red troncal de comunicaciones 110, y (3) dispositivos inteligentes conectados 115. El sistema distribuido inteligente 105 adopta un enfoque basado en software para gestionar diversos aspectos del sistema o sistemas de automatización de una empresa, a lo largo de todo su ciclo de vida. Este enfoque basado en software significa que el sistema SDA es fácil de configurar, ajustar y adaptar en función de cualquier requisito cambiante para cumplir con los cambios del entorno empresarial. En un sistema distribuido inteligente, los servidores de automatización pueden alojar aplicaciones, bases de datos y similares y permitir un alto nivel de elasticidad. En algunas realizaciones, el sistema exhibe inteligencia distribuida al permitir que un huésped (por ejemplo, una aplicación de control/automatización) se defina lógicamente y se distribuya y redistribuya para ejecutarse en uno o más hosts (por ejemplo, máquinas virtuales, contenedores, bare metals) en un servidor, en un controlador de automatización físico, un sistema embebido y similares. La distribución se puede iniciar por varias razones, por ejemplo, para optimizar el rendimiento, para actualizar el hardware, etc. Por ejemplo, una aplicación con grandes requisitos computacionales se puede desplegar para su ejecución en un recurso de cómputo capaz de proporcionar los recursos computacionales necesarios. Del mismo modo, una aplicación con restricciones de tiempo críticas se puede desplegar en un recurso de cómputo que esté cerca del dispositivo de campo que controla para reducir el impacto de la latencia a través de la red y/u otros retrasos y mejorar el rendimiento del sistema.
La red troncal de comunicaciones 110 proporciona conectividad en toda la arquitectura de automatización, desde el nivel de control hasta el bus de campo, en el plano troncal del controlador, hasta los dispositivos inteligentes conectados 115, etc. Esta conectividad, habilitada por Ethernet, mejora enormemente la accesibilidad de los equipos y datos de automatización y ayuda a entregar la información correcta a la entidad adecuada en el momento oportuno. En algunas realizaciones, la red troncal de comunicaciones 110 de un sistema SDA puede usar una o más tecnologías de red, tales como redes definidas por software (SDN), redes sensibles al tiempo (TSN) y/o similares en algunas realizaciones. SDN permite configurar y reconfigurar los elementos de red, entre los que se incluyen conmutadores y enrutadores, así como cualquier otro nodo que desempeñe una función similar, de una forma más sencilla y sin tener que acceder a cada dispositivo físico. Por ejemplo, el controlador SDN lógicamente centralizado puede acceder a cada dispositivo de red por medio de un conjunto de protocolos. TSN permite crear redes Ethernet en tiempo real que posibilitan el control en tiempo real en toda la red.
Los dispositivos inteligentes conectados (o productos inteligentes conectados) 115 son sistemas complejos que se pueden conectar a la red, generar datos y ejecutar una función. Los dispositivos inteligentes conectados son conscientes de su contexto operativo y, como tales, pueden tomar decisiones inteligentes y adaptar su comportamiento en consecuencia. Por ejemplo, consideremos un sensor tal como un medidor de potencia que tiene una función básica de detección de redes eléctricas. Se pueden implementar una o más funciones además de la función básica en el contador de energía para transformar el contador de energía en un dispositivo inteligente conectado. Un contador inteligente conectado de este tipo puede aprovechar su contexto operativo para, por ejemplo, comprobar condiciones específicas, generar y enviar alarmas, etc. Los dispositivos inteligentes conectados 115 pueden comprender hardware, software, sensores, almacenamiento, microprocesador(es), conectividad y similares. Algunos ejemplos no limitativos de dispositivos inteligentes conectados incluyen: controladores (por ejemplo, controladores lógicos programables o PLC, controladores de automatización programables o PAC), accionamientos, concentradores de E/S, sensores, actuadores y similares.
Un sistema SDA, en algunas realizaciones, se puede describir como una colección de servicios. En algunas realizaciones, puede ser una infraestructura como servicio (IaaS) que proporciona infraestructura virtual en la que los clientes pueden alojar sus propias aplicaciones. También puede ser una red como servicio (NaaS), dado que permite configurar y reconfigurar o modificar la red de forma sencilla en función de las necesidades del cliente. El sistema SDA también puede ser un software como servicio (SaaS), dado que puede alojar software (por ejemplo, SoMachine, Unity) en uno o más servidores y permitir a un usuario acceder al software de forma cliente/servidor mediante el uso de un smartphone, portátil, ordenador personal, tableta y/u otro dispositivo de cliente. También se puede tratar de datos/información como un servicio que define la gestión de datos a nivel de solución/sistema para evitar la doble definición y la incoherencia y permitir el big data y la analítica. Puede ser una plataforma como servicio (PaaS) que proporciona una plataforma compuesta por un conjunto de servidores que ofrecen hosts para ejecutar aplicaciones bajo demanda, integradas o no.
La FIG. 2A representa una arquitectura de sistema de automatización tradicional ampliamente implantada en numerosas industrias. En la arquitectura tradicional del sistema de automatización, los dispositivos de automatización en el nivel 2 (por ejemplo, PLC 230A a C) están conectados a través de redes de dispositivos 235A a C para permitir que los dispositivos de automatización (por ejemplo, dispositivos de campo 225A a C) en el nivel 1 sean controlados por los PLC 230A a C respectivamente. Del mismo modo, los PLC 230A a C en el nivel 2 y las estaciones de ingeniería 240 y los servidores de procesos e históricos 245 en el nivel 3 de la sala de control están conectados a la misma red de control 250. Esto permite a los ingenieros acceder y/o programar los PLC 230A a C y acceder a los datos de proceso almacenados en los servidores históricos 245 directamente desde las estaciones de ingeniería 240. En el nivel 4, en la parte superior de la arquitectura del sistema de automatización, la sala de la empresa puede incluir servidores de sistema/empresa 260 que están conectados a las estaciones de ingeniería 240 y a los servidores de procesos e historiadores 245 en el nivel de la sala de control 210 a través de la red de la empresa 255. Por último, en el nivel superior 5, el mundo de los equipos industriales, máquinas, controladores, sensores y actuadores (“Tecnología Operativa” u OT 265) que abarca los cuatro niveles se integra con las redes de oficina (es decir, Tecnología de la Información (TI) 270).
La arquitectura tradicional del sistema de automatización (por ejemplo, la arquitectura tradicional OT 265 representada en la FIG. 2A) presenta diversos inconvenientes. Uno de esos inconvenientes es la arquitectura bloqueada. En otras palabras, la arquitectura tradicional de los sistemas de automatización carece de flexibilidad para introducir cambios dinámicos en la configuración de la aplicación, el dispositivo o la red. Además, la arquitectura tradicional de los sistemas de automatización se caracteriza por silos funcionales que crean complejidad y hacen inflexibles los sistemas de control. La complejidad y la falta de flexibilidad limitan la eficacia operativa de la arquitectura, son fuente de frustración para los clientes y requieren una configuración costosa e inflexible. Por ejemplo, en la FIG. 2A, cada una de las unidades funcionales 275A a C se representa como teniendo su propia red de dispositivos 235A a C respectivamente, lo que impide que diferentes PLC en diferentes unidades funcionales interactúen entre sí. Si es necesario cambiar una aplicación que se ejecuta en un PLC 230A en la unidad funcional 275A a un PLC 230B en la unidad funcional 275b (por ejemplo, porque el PLC 230A falló) y hacer que esa aplicación controle el dispositivo de E/S en la unidad funcional 275A, tal cambio requeriría una reingeniería significativa y la interrupción de la operación industrial, lo que puede ser costoso.
Otro problema de la arquitectura tradicional de los sistemas de automatización es la complejidad en términos de gestión de las diferentes aplicaciones y dispositivos, así como de la infraestructura de red. Un sistema de automatización típico puede comprender cientos de dispositivos de automatización (o equipos de automatización) y procesos gestionados por otras tantas aplicaciones. Por ejemplo, los PLC se programan mediante el uso de un software de programación (por ejemplo, el software Unity de Schneider Electric para los PLC fabricados por Schneider Electric) y las configuraciones de los PLC se almacenan en proyectos de software de PLC (por ejemplo, el proyecto Unity). Del mismo modo, las configuraciones de control y adquisición de datos (SCADA) se almacenan en proyectos SCADA. Las configuraciones de los dispositivos (por ejemplo, direccionamiento IP, configuración de E/S, listas de control de acceso, subcomponentes locales y bibliotecas de apoyo, activación de eventos, contraseñas y similares) también se gestionan generalmente a través de diferentes aplicaciones de software. Del mismo modo, las configuraciones del Protocolo de Internet (IP) de los dispositivos de automatización no se gestionan desde un único punto, sino en cada punto. La gestión individual de estas aplicaciones y dispositivos en cuanto a compatibilidad, versiones, mantenimiento, conectividad IP, etc., es muy compleja y requiere una experiencia y un esfuerzo considerables. Además, como estas aplicaciones y dispositivos no se gestionan de forma centralizada, no hay forma de recuperar todo el sistema en caso de desastre. Como tales, las arquitecturas tradicionales de los sistemas de automatización son vulnerables a los riesgos de seguridad (por ejemplo, cambios no autorizados en la configuración de los dispositivos) y a las catástrofes (por ejemplo, incendios o inundaciones).
Otro inconveniente de la falta de gestión centralizada de aplicaciones y dispositivos es la dificultad de acceso a los datos generados por las diferentes partes del sistema. Reunir en un solo lugar grandes cantidades de diferentes tipos y conjuntos de datos generados por diferentes aplicaciones y dispositivos se convierte en una tarea demasiado compleja y lenta. Sin acceso a los datos pertinentes, resulta difícil obtener una visión holística del sistema para optimizar el rendimiento. Por ejemplo, considere un escenario en el que unos pocos dispositivos en una planta pueden tener recursos disponibles para ejecutar aplicaciones. A menos que un ingeniero de planta acceda específicamente a cada uno de esos dispositivos y determine qué recursos están disponibles, la información sobre la disponibilidad de recursos de esos dispositivos no se conocerá y, por lo tanto, no se tendrá en cuenta a la hora de decidir dónde desplegar una aplicación o si añadir un nuevo dispositivo de automatización. Como resultado, se pueden tomar decisiones ineficaces y subóptimas. Otro ejemplo: un virus infecta un controlador industrial. En los sistemas de automatización tradicionales, la detección de un evento de este tipo puede provocar la parada de la mayor parte de la planta, si no de toda, porque un ingeniero puede tener que cambiar físicamente el controlador por uno nuevo y configurarlo y programarlo de nuevo.
La tecnología SDA en la presente memoria descrita supera estos y otros inconvenientes de la arquitectura del sistema de automatización tradicional por medio de la transformación de la arquitectura tradicional rígida y bloqueada en una arquitectura flexible, “más plana” y definida por software. La arquitectura OT transformada permite la configuración de red y la automatización de despliegues de funciones/aplicaciones sobre la marcha a nivel de sistema mediante el uso de tecnologías de virtualización (por ejemplo, de servicios, aplicaciones), dispositivos configurables y/o tecnologías de red.
Mientras que la arquitectura de automatización tradicional representada en la FIG. 2A es rígida y jerárquica con al menos cuatro niveles de control, el ejemplo de arquitectura OT definido por la tecnología SDA representado en la FIG. 2B es bastante más sencillo, con tres niveles de control (de ahí la descripción “más plana”). Estos tres niveles de control incluyen una sala de empresa de nivel 205 (nivel 4), unidades funcionales, PLC, dispositivos de proceso de campo de nivel 280 (nivel 1) y un nivel consolidado 212 (nivel 3/4). La arquitectura OT transformada también comprende una red empresarial 255 y una red de dispositivo único 235 que sustituye a las redes de dispositivos fragmentadas de la arquitectura OT tradicional. Por ejemplo, como se ilustra en la FIG. 2B, todos los dispositivos de automatización tales como los PLC, 285, E/S, HMI 290A, 290B y estaciones de ingeniería 240 están conectados a una única red de dispositivos 235. En esta arquitectura, una aplicación que se ejecuta en un PLC en la unidad funcional 275B se puede mover al servidor(es) 285 (por ejemplo, por medio de la creación de un PLC virtual que es una implementación de software de un PLC en un host tal como una máquina virtual o un contenedor) y la red se puede configurar automáticamente para asegurar que el tráfico desde el PLC virtual (“vPLC”) en el/los servidor(es) 285 fluye a los dispositivos de E/S en la unidad funcional 275B de manera oportuna para monitorizar y/o controlar los dispositivos de entrada/salida o los dispositivos de campo. Algunos ejemplos no limitativos de dispositivos de entrada incluyen: sensores, dispositivos de medición, conmutador de presión, conmutador de nivel, y similares. Del mismo modo, algunos ejemplos no limitativos de dispositivos de salida incluyen: actuadores, motores, relés o solenoides, dispositivos analógicos, y similares. De este modo, la tecnología SDA puede simplificar el despliegue y la configuración de funciones y/o aplicaciones de automatización.
Una de las ventajas de la arquitectura SDA desvelada es el control inteligente de la empresa. El control inteligente de la empresa incluye la conexión de los sistemas de automatización existentes con otros sistemas (por ejemplo, los sistemas de la empresa, del ciclo de vida y de la cadena de valor) para optimizar toda la empresa de fabricación en su conjunto, y posibilitar mejor los beneficios tangibles de un mayor control empresarial. El control empresarial inteligente facilita la ruptura de los silos de la empresa y permite una integración más estrecha de los sistemas de producción con los sistemas de planificación de recursos empresariales (ERP), los sistemas de gestión del ciclo de vida de los productos (PLM), los sistemas de gestión de la cadena de suministro (SCM) y los sistemas de gestión de las relaciones con los clientes (CRM). Estos diferentes sistemas empresariales se han gestionado históricamente de forma algo independiente unos de otros, lo que impide una visión holística de la empresa. El enfoque holístico de la arquitectura SDA desvelada puede facilitar un enorme aumento de la eficiencia para las empresas.
Por ejemplo, los dispositivos inteligentes conectados se pueden integrar estrechamente con la empresa en general para facilitar una fabricación más flexible y eficiente. El control inteligente de las empresas es bastante complejo de implantar, y la arquitectura y las normas SDA permiten la convergencia de los sistemas de tecnologías de la información (TI) y de transformación operativa (OT). Una mayor integración permite a las empresas no sólo ser más eficientes, sino también tener mayor flexibilidad y capacidad de respuesta ante las volátiles condiciones del mercado. La noción de control se puede ampliar desde el control en tiempo real de un parámetro físico hasta el control en tiempo real de toda la empresa, incluidos los parámetros físicos y no físicos. Entre los ejemplos de beneficios para las empresas figuran la capacidad de aumentar la protección contra las ciberamenazas, ser más innovadoras y poder gestionar mejor la seguridad, el rendimiento y el impacto medioambiental.
Algunos ejemplos de aplicaciones del control empresarial inteligente incluyen la personalización y el tamaño de los lotes de un producto, la reducción del tamaño de las retiradas de productos, la detección de productos defectuosos en una fase más temprana del proceso de fabricación y la modificación del diseño del producto para eliminar las causas raíz, la modificación de la planificación de la producción en función de las previsiones meteorológicas, la modificación del plan de producción/recetas en función del precio al contado de las materias primas, etc.
La FIG. 3 es un diagrama de bloques que ilustra un ejemplo de una arquitectura de tecnología operativa (“OT”) más plana y flexible para una empresa de acuerdo con algunas realizaciones. Como se representa, la arquitectura OT más plana de acuerdo con la tecnología SDA tiene dos capas: una capa de nube basada en IP “sensible al tiempo” 330 para el control determinista en tiempo real y una capa de nube empresarial 325. La capa temporal 330 engloba el nivel 320 (L1) de sensores y actuadores y el nivel 315 (L2) de control discreto, híbrido o continuo, y está habilitada por tecnologías de computación en nube optimizadas para comunicaciones deterministas en tiempo real. En otras palabras, la capa sensible al tiempo 330 garantiza que el tráfico de control/datos sensible al tiempo de las capas L1 y L2 se gestione para cumplir los requisitos de latencia y/o fiabilidad. Como se usa en la presente memoria, “nube” se refiere a las tecnologías usadas, más que a la ubicación física de la infraestructura. Por ejemplo, en la industria de la automatización, se pueden usar arquitecturas con una o más nubes “en las instalaciones”.
En algunas realizaciones, los dispositivos OT que comprenden la capa sensible al tiempo (por ejemplo, sensores, actuadores y controladores en L1 y L2) están preparados para la nube y son capaces de interactuar de forma transparente con los sistemas de TI de la capa de nube empresarial. Estos dispositivos también pueden tener un alto grado de inteligencia o lógica en algunas realizaciones. Por ejemplo, las válvulas de control pueden incorporar sensores de temperatura, presión y/o acústicos capaces de funcionar de forma autónoma mediante el uso de los valores de consigna recibidos de la capa de nube de la empresa, por ejemplo, para determinar sus propias necesidades de mantenimiento preventivo, y/o informar oportunamente al departamento de mantenimiento.
La capa de empresa en nube 335 abarca el nivel de gestión de fabricación y operaciones (MOM) 310 (L3) y el nivel de planificación de recursos empresariales (ERP) 305 (L4) de la jerarquía. ERP 335A, MOM 335B, gestión del ciclo de vida del producto (PLM) 335c y otras funciones tales como la gestión de activos 335D, gestión de la energía 335E, etc.) en la capa de nube empresarial 325 interoperan entre sí y con los sistemas de automatización y control industrial sensibles al tiempo para proporcionar una visión holística coordinada y la gestión del sistema empresarial. En algunas realizaciones, el flujo de información a través de ambas capas es completamente transparente mediante el uso de mecanismos semánticos y de descubrimiento (por ejemplo, basados en estándares de la Industria).
La arquitectura más plana puede proporcionar numerosas ventajas a los usuarios finales. Por ejemplo, la arquitectura más plana se asocia con un bajo coste de implementación y una mayor flexibilidad. También puede soportar la conectividad 340 a cualquier punto final, habilitada por un modelo de información semántica normalizado. El modelo de información semántica y los servicios asociados facilitan la transmisión optimizada de datos de campo a la nube y la adaptación del comportamiento de los dispositivos de campo en función de los análisis realizados en la nube.
Otros beneficios incluyen la implementación de funciones incrementales adicionales, tamaño de lote 1, conexión transparente y rentable a sistemas empresariales que permitan la fabricación dirigida por la información.
Otra ventaja de la arquitectura OT de acuerdo con la tecnología SDA es su aplicación a arquitecturas de redes de control a gran escala. Una arquitectura de red de control a gran escala es un reto de ingeniería para todo el ciclo de vida, dado que generalmente incluye un gran número de dispositivos conectados a través de una red (por ejemplo, Ethernet/TCP-IP). El elevado número de dispositivos conectados implica un nivel de complejidad sin precedentes. Por ejemplo, una arquitectura de este tipo puede incluir hasta 2800 PLC y 5400 accionamientos conectados en 30 bucles de red. La arquitectura OT conforme a la tecnología SDA puede simplificar el diseño, la gestión y el mantenimiento de una arquitectura a tan gran escala. Por ejemplo, en la arquitectura OT desvelada en la presente memoria, el procesamiento de datos se puede lograr de una manera organizada y eficiente, que a su vez optimiza el rendimiento operativo. El tiempo de respuesta, por ejemplo, con respecto al almacenamiento y recuperación de datos, se puede controlar por medio de un sistema SDA y se pueden llevar a cabo ajustes para optimizar el rendimiento operativo. Del mismo modo, la salud de los componentes puede ser monitorizada de forma continua por un componente de gestión centralizado y cualquier evento que pudiera afectar potencialmente al rendimiento del sistema puede ser detectado a tiempo y remediado por medio de una respuesta coordinada en diversos frentes, que incluyen la virtualización, la ciberseguridad y la red. Del mismo modo, la arquitectura OT puede proporcionar un rendimiento de control mejorado distribuyendo el procesamiento y diseñando redes en consecuencia teniendo en cuenta varios protocolos para acceder a la información de dispositivos y aplicaciones. Además, la disponibilidad y sostenibilidad del sistema se pueden mejorar al permitir el diagnóstico de fallos y la redundancia.
Estos y varios otros aspectos del sistema SDA que incluyen varios componentes, características, ventajas y aplicaciones serán ahora discutidos en detalle.
.
I. Arquitectura Simplificada
La FIG. 4 es un diagrama que ilustra una arquitectura simplificada de un sistema SDA de acuerdo con algunas realizaciones. La arquitectura representa un servidor de niebla 405 vinculado a un software de sistema 440, y dispositivos inteligentes conectados 415A, 415B que están acoplados de manera comunicativa al servidor de niebla 405 y al software de sistema 224 a través de una red troncal de comunicaciones 410. La arquitectura también representa que al menos algunos dispositivos inteligentes conectados 415B y el servidor de niebla 405 pueden estar acoplados de manera comunicativa a una nube 450.
El servidor de niebla 405 está compuesto por una colección de recursos de control y recursos de cómputo 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”, como se usa 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 de cómputo y/o control. En otras palabras, el servidor de niebla 405 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 de cómputo y/o control para gestionar todo el sistema de automatización o una porción del mismo. El servidor de niebla 405 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 de cómputo que ejecutan hosts tales como máquinas virtuales, contenedores y/o bare metals (o imágenes de bare metal). Los hosts, a su vez, pueden ejecutar huéspedes 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 440. Como se usa 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 host que se ejecuta en un nodo de cómputo. No tiene una existencia física por sí misma. El servidor de niebla 405 no tiene por qué estar localizado en una sala de control centralizada; los controladores, dispositivos y/o servidores 435 cercanos a los sensores y accionadores (por ejemplo, dispositivo IO, dispositivo integrado) también se pueden considerar bajo la gestión del servidor de niebla 405. En algunas realizaciones, el servidor de niebla 405 también puede agregar, almacenar y/o analizar datos, y/o informar de los datos o análisis a la nube 450. La nube 450 puede ser una nube empresarial (es decir, una nube privada), una nube pública o una nube híbrida. El software del sistema 440 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 por medio de la gestión de la distribución de las aplicaciones/funciones de la aplicación donde los usuarios quieren que se ejecuten.
Los dispositivos inteligentes conectados 415A, 415B (también productos conectados inteligentes) monitorizan y/o controlan dispositivos, sensores y/o accionadores cercanos a los equipos/materias primas/entorno por medio de 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 415A 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 llevar a cabo 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, dado 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 415B pueden ser ejecutados total o parcialmente en uno o más servidores (por ejemplo, el servidor 435, el servidor de niebla 405). Por ejemplo, un dispositivo inteligente conectado 415B puede responder a señales remotas (por ejemplo, denominadas a procedimientos remotos, interfaz de programación de aplicaciones o denominadas 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 405. 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 monitorizados) y enviar dichos datos al servidor de niebla 405 y/o a una nube remota 450. En algunas realizaciones, los dispositivos inteligentes conectados 415A, 415B pueden transformar los datos capturados en tiempo real en información (por ejemplo, alarmas), almacenarlos y llevar a cabo análisis operativos sobre ellos. Los dispositivos inteligentes conectados 415A, 415B pueden entonces combinar las funciones de monitorización y control descritas anteriormente para optimizar su propio comportamiento y estado.
La red troncal de comunicaciones 410 facilita la interacción entre el servidor de niebla 405, el software del sistema 440 y los dispositivos inteligentes conectados 415A, 415B. 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 415A, 415B, el servidor de niebla 405 y cualquier otro componente que forme parte de la arquitectura SDA. Por ejemplo, los diferentes equipos de una planta se pueden conectar entre sí y con el sistema de la empresa (por ejemplo, MES o ERP) mediante el uso de tecnologías basadas en diversos estándares tales como: Ethernet, t Cp/ 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 tales 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 410 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 410 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 410 también puede soportar un conjunto de funciones web que ofrecen funciones como el diagnóstico, la monitorización y la configuración mediante el uso de 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 se pueden incorporar a la arquitectura. La red troncal de comunicaciones 410 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 410 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 410 puede usar 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 imgf000009_0001
Las redes de los sistemas existentes están muy segmentadas para permitir una comunicación garantizada o fiable. La red troncal de comunicaciones 410 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, al permitir 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 áreas o en toda la arquitectura. Además, la solución de ciberseguridad también se puede integrar y adaptar a la arquitectura SDA.
B. 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 de cómputo (por ejemplo, la monitorización, la gestión de otras aplicaciones y/o recursos), y similares. Esta vista funcional de la arquitectura SDA se representa en la FIG. 5.
La vista funcional de ejemplo de un sistema SDA representado en la FIG. 5 incluye un plano de aplicación 575, un plano de control 580 y un plano de recursos 582. El plano de aplicación 575 abarca el software del sistema 540 y los componentes de software o aplicaciones 535 que se ejecutan en el sistema y que usan y gestionan un conjunto de recursos del sistema. El plano de control 580 incluye un conjunto de controladores que incluye un controlador del servidor de niebla 510, un controlador SDN 590A/controlador TSN 590B (o un controlador de red) y un controlador CS 555. Estos controladores proporcionan un conjunto estandarizado de interfaces a las aplicaciones en el plano de aplicación 575 para acceder y/o gestionar los recursos en el plano de recursos 582 del sistema. En algunas realizaciones, los controladores también proporcionan diagnósticos, gestión de la disponibilidad, y similares. El controlador SDN 590A/controlador TSN 590B gestiona y distribuye las políticas de red a nivel de sistema. De manera similar, el controlador CS 555 aplica las políticas de seguridad 565 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 del servidor de niebla 510, los controlador de red 590A, 590B 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 582 puede incluir recursos de red 560, recursos de cómputo representados por nodos de cómputo 515, recursos de almacenamiento 525 y recursos de seguridad 595. El software del sistema 540 y las aplicaciones 535 se ejecutan en los nodos de cómputo 515 gestionados por el controlador del servidor de niebla 510. Los nodos de cómputo 515 que proporcionan los recursos de cómputo al sistema pueden estar físicamente distribuidos y gestionados por el controlador del servidor de niebla 510. Por ejemplo, algunos nodos de cómputo en forma de servidores se encuentran en el servidor de niebla o en la nube privada, mientras que otros nodos de cómputo, tales como los dispositivos inteligentes conectados, operan en el borde. Los recursos de red 560 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 525 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 595 pueden incluir componentes de seguridad que residen en los nodos de cómputo 515, nodos de almacenamiento 525, 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 monitorizan 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 se puede usar 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 se pueden desplegar en recursos de cómputo y pueden usar recursos de almacenamiento y de red para comunicarse.
3. 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. 6A es un diagrama de bloques que ilustra los subsistemas de un sistema SDA de acuerdo con algunas realizaciones. Un sistema SDA 600 en algunas realizaciones incluye un subsistema del servidor de niebla 605 (“servidor de niebla”) que tiene un controlador del servidor de niebla o controladores de niebla redundantes 610, uno o más nodos de cómputo 615 y almacenamiento 625. El sistema SDA 600 también incluye un subsistema de componentes de software 630. En otras realizaciones, el sistema SDA 400 puede incluir además un subsistema de ciberseguridad (“CS”) 650 que tiene un controlador de seguridad o controladores de seguridad redundantes 655, componentes de seguridad físicos y/o virtualizados 660 y un repositorio de políticas de seguridad que almacena políticas de CS 665. En otras realizaciones, un sistema SDA 400 también puede incluir un subsistema de red 670 que tiene un controlador de red o controladores de red redundantes 690, una red física 680, componentes de red física 682, redes virtuales 620, componentes de red virtual 622 y un repositorio de políticas de red que almacena políticas de red 685.
El servidor de niebla 605 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 605 comprende nodos de cómputo 615 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 limitativos de nodos de cómputo incluyen: servidores, ordenadores personales, dispositivos de automatización que incluyen dispositivos inteligentes conectados y similares.
El controlador del servidor de niebla 610 usa un software de gestión del servidor de niebla para llevar a cabo sus funciones. El software de gestión del servidor de niebla se puede basar en un software de gestión de la nube tal como OpenStack. El software de gestión de la nube, tal como OpenStack, en su forma estándar/listo para la venta, se suele usar 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 610 gestiona todos los aspectos del entorno de virtualización y el ciclo de vida completo de los nodos de cómputo 615. Por ejemplo, el servidor de niebla 605 puede levantar y retirar hosts tales como máquinas virtuales, contenedores o bare metals en nodos de cómputo, y crear y destruir componentes virtualizados 645 y redes virtuales 620. Un componente/elemento/instancia virtualizado 645, como se usa en la presente memoria, es un equivalente lógico de un dispositivo físico o una porción del dispositivo físico que representa, implementado como una entidad de software para ejecutarse dentro del servidor de niebla 605. Los componentes virtualizados 645 también pueden incluir componentes de software tales como aplicaciones y/o funciones de aplicación que se ejecutan en un host (por ejemplo, una máquina virtual configurada con una aplicación es un componente/elemento/instancia virtualizado).
El controlador del servidor de niebla 610 puede proporcionar alta disponibilidad (HA) a través de la redundancia del controlador y la gestión de los fallos de los nodos de cómputo. El controlador también puede gestionar la puesta en marcha, el apagado y la aplicación de parches de los diferentes nodos de cómputo. 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 605 puede incluir un nodo de almacenamiento o almacén de datos 625. El almacenamiento 625 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 630 puede incluir componentes virtualizados 645 que se alojan en el ecosistema de virtualización del servidor de niebla 605. El subsistema de componentes de software 630 también puede incluir instancias virtualizadas de software 635 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 usan 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 630 también puede incluir un software de sistema 640 (también denominado 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 640 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 640 se puede usar 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 640 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 se pueden gestionar desde un único portal. Además de proporcionar un único punto de entrada a todo el sistema, el software del sistema 640 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 software del sistema 640 y sus componentes se describen en detalle en referencia al software del sistema 740 FIG. 7B.
El subsistema CS 650 incluye un controlador CS asociado o controladores CS redundantes 655 y componentes de seguridad virtualizados y/o físicos 660. El subsistema de seguridad 650 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 655 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 650 se pueden almacenar en un repositorio de políticas de seguridad 665 en algunas realizaciones.
El subsistema de red 670 incluye la infraestructura de red Ethernet para toda la solución del sistema SDA. En algunas realizaciones, el subsistema de red 670 es un subsistema de red SDN que tiene un controlador SDN o controladores SDN redundantes como el controlador de red 690. 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 s Dn puede difundir políticas de red a través de la infraestructura de red (es decir, la red física 680 y los componentes de red física 682, así como las redes virtuales 620 y los componentes de red virtual 622) 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 670 se pueden almacenar en un repositorio de políticas de red 685 en algunas realizaciones.
En algunas realizaciones, el subsistema de red 670 puede comprender una red de radio de malla. En una red de radio en malla, cada nodo se puede conectar 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 670 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. De este modo, 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 670 puede ser un subsistema de Red Sensible al Tiempo (TSN) que tiene un controlador TSN como el controlador de red 690 y una infraestructura 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. Normalmente, la infraestructura TSN incluye componentes de red aptos para TSN. Se debe tener en cuenta que en algunas realizaciones, el subsistema de red 670 puede comprender redes SDN y TSN (y por lo tanto controladores SDN y TSN y componentes SDN y TSN). En varias realizaciones, el controlador de red 690 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 TSN 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 605 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 605 tiene relaciones integrales con cada uno de los subsistemas SDA, los subsistemas SDA no se consideran dentro del ámbito del servidor de niebla 605. La FIG.
6B 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 605 es el controlador del servidor de niebla 610, los nodos de cómputo 615 y la gestión de los componentes virtualizados 645 dentro del servidor de niebla 605. Los componentes virtualizados 645 y el software 635 (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 630. Sin embargo, los componentes de software 630, a través del portal de software/automatización del sistema 640, establece una interfaz con el controlador del servidor de niebla 610 y los nodos de cómputo 615 para proporcionar entradas de configuración y control al servidor de niebla 605 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 670 incluye no sólo los componentes de red física 682 y la red física 680, sino también las redes virtuales 464 y los componentes de red virtual 622 que se crean y existen dentro del servidor de niebla 605. Esto requiere una integración total entre el subsistema de red 670 y el servidor de niebla 605 para proporcionar los mecanismos para ejercer este control. Por ejemplo, el controlador del servidor de niebla 610 puede crear las redes virtuales 620 en el servidor de niebla 605 y controlar la conectividad entre las máquinas virtuales/contenedores alojados en los nodos de cómputo 615 y las redes virtuales 620, mientras que el controlador de red 690 puede configurar los componentes de red virtual 622 de las redes virtuales 620 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, dado que, evidentemente, la red virtual 620 debe existir antes de que las máquinas virtuales y los contenedores se puedan conectar.
El subsistema CS 650 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 655 que difunde las políticas de seguridad a diferentes entidades. El subsistema CS 650 se puede integrar con todos los aspectos de la solución del sistema SDA en algunas realizaciones. Por ejemplo, el controlador de red 690 puede usar los servicios de seguridad proporcionados por el subsistema CS 650 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 605 puede usar este servicio para autenticar los inicios de sesión, proporcionar políticas de seguridad para las configuraciones del host (máquina virtual, contenedor, bare metal), validar las imágenes del host 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 699 (por ejemplo, los dispositivos heredados) y la red IT y los equipos administrativos 698. En algunas realizaciones, el Internet Industrial de las Cosas (IIoT) 469 u otro servicio basado en la nube se puede considerar externo o parte de la solución del sistema SDA.
4. Software del sistema o portal de automatización
La FIG. 7A es un diagrama de bloques que ilustra la interacción entre el software de la solución y el equipo de automatización en sistemas de automatización tradicionales y en el entorno SDA de acuerdo con algunas realizaciones.
Normalmente, cada tipo de equipo tiene su propio software específico (también denominado herramienta o herramienta de software) por medio del cual se puede configurar, parametrizar y/o programar el equipo. Por ejemplo, en los sistemas de automatización de máquinas/fabricación 706, el software de solución 735A, tal como SoMachine, se usa para configurar, parametrizar y/o programar el equipo de la máquina 701. Del mismo modo, en los sistemas de automatización de procesos 708, se usa otro software de solución 735B tal como PlantStruxure PES (Process Expert System) para configurar, parametrizar y/o programar el proceso. A nivel de sistema, donde los equipos de automatización están más conectados y más estrechamente integrados, resulta muy ineficaz para un usuario gestionar estas soluciones de software por separado. Además de los problemas de gestión, tal como el seguimiento de las versiones de la solución de software, las actualizaciones, etc., la solución de software independiente también significa que un usuario no puede tener una vista del sistema de todos los equipos, es decir, los equipos de máquinas y los equipos de proceso.
En un sistema SDA, un software de sistema 740, a través de un marco común 742 y otros componentes, reconcilia vistas individuales en una vista de sistema. En otras palabras, el software del sistema 740 proporciona una vista a nivel de sistema de todos los dispositivos/equipos de automatización, teniendo en cuenta todo el ámbito de automatización. En el ejemplo anterior de un sistema de automatización industrial, esto significa que a través del software del sistema 740, un usuario puede ver toda la máquina 701 y el equipo de proceso 702, y puede configurar, parametrizar y/o programar dicha máquina y equipo de proceso 701, 702 sin tener que lanzar o invocar por separado software específico del tipo de equipo. El marco común 742, en particular, ofrece interfaces de usuario, reglas de programación e infraestructura consistentes para simplificar la comunicación con los controladores (por ejemplo, controladores de máquina 712, controladores de planta 714), HMI 790, equipos 701, 702, y similares, independientemente de si están relacionados con la máquina o con el proceso. De este modo, el software del sistema 740 facilita el diseño, el desarrollo y la gestión de un sistema de automatización en su conjunto.
La FIG. 7B es un diagrama de bloques que ilustra los componentes de ejemplo de un software de sistema de un sistema SDA de acuerdo con algunas realizaciones.
El software del sistema 740 puede ser un portal basado en web o una aplicación de software accesible desde dispositivos de cliente. Como se usan en la presente memoria, los dispositivos de cliente pueden incluir, entre otros: estaciones de ingeniería, tabletas 740A, dispositivos móviles 740B, ordenadores portátiles 740C, ordenadores de sobremesa 740D, interfaces hombre-máquina (HMI)/HMI móviles 790, y similares. Como se ha descrito anteriormente, el software del sistema proporciona un único punto de entrada a través del cual se pueden configurar, parametrizar y programar diversos dispositivos o equipos de automatización gestionados por el sistema SDA, ya se encuentren en el servidor de niebla o en la planta. Dependiendo de las realizaciones, el software del sistema 740 puede incluir más o menos componentes. Cabe señalar que, en aras de la brevedad, sólo se han representado determinados componentes del software del sistema 740.
El software del sistema 740, en algunas realizaciones, incluye un marco común 742 como se ha descrito anteriormente. El marco común 742 puede proporcionar interfaz(es) de aplicación 752, interfaz(es) de controlador/dispositivo 754 e interfaz(es) de usuario 756 haciendo que tareas tales como programación, configuración, ajuste, diagnóstico, etc., sean realizables desde la interfaz de usuario del software del sistema, y más eficientes.
En algunas realizaciones, el software de sistema 740 incluye un componente de generación de vista de topología 726 que puede recolectar información de topología de varias partes de un sistema de automatización y renderizar una visualización a nivel de sistema de todos los equipos de automatización, ya sean físicos o virtualizados, y los enlaces entre ellos. En algunas realizaciones, se puede generar una vista topológica de una porción del sistema de automatización. La vista de topología puede ser una vista de tabla (por ejemplo, mostrada en un panel de navegación del software del sistema 740) o una vista de gráfico (por ejemplo, mostrada en un panel de diseño del software del sistema 740). La información de topología se puede recopilar por medio de la consulta de componentes del software del sistema 740, el controlador del servidor de niebla (por ejemplo, el controlador del servidor de niebla 410 en las FIGs. 4A y 4B, el controlador del servidor de niebla 610 de la FIG. 6A), el controlador de red (por ejemplo, el controlador de red 690 de la FIG. 6A, conexiones y existencia de flujos entre componentes), y/u otros subsistemas del sistema SDA en algunas realizaciones.
El software de sistema 740 también puede incluir una biblioteca de plantillas de unidades funcionales 724 en algunas realizaciones. Las plantillas de unidades funcionales son modelos de software de unidades funcionales que se pueden parametrizar e instanciar en el servidor de niebla. Una unidad funcional, como se usa en la presente memoria, es una entidad de hardware, una entidad de software o una entidad híbrida con porciones de hardware y software capaz de llevar a cabo un propósito o función específicos. Cabe señalar que una unidad funcional puede estar compuesta por otras unidades funcionales. Por ejemplo, un PLC, un accionamiento, un motor y un módulo de E/S se pueden considerar cada uno una unidad funcional, al igual que un sistema de cinta transportadora compuesto por tres PLC, dos módulos de E/S, un accionamiento y un motor.
En algunas realizaciones, el software del sistema 740 puede incluir un conjunto de componentes que implementan lógica o aplicaciones específicas del dominio. Por ejemplo, un componente de parametrización 728 puede llevar a cabo la parametrización de plantillas de equipos y unidades funcionales descritas anteriormente (por ejemplo, parametrización de HMI). Como se usa en la presente memoria, la parametrización incluye el establecimiento o la definición de propiedades. Por ejemplo, un usuario puede seleccionar un equipo de una vista de topología para parametrizarlo. El componente de parametrización 728 puede lanzar automáticamente una interfaz de parametrización (por ejemplo, un menú) de un software de parametrización asociado al equipo. Asimismo, un componente de configuración 732 puede llevar a cabo la configuración del equipo (por ejemplo, la configuración del accionamiento de movimiento). Como en el caso de la parametrización, el usuario puede seleccionar un equipo de la vista de topología para configurarlo. En respuesta, el componente de configuración 732 puede mostrar una interfaz de configuración de un software de configuración asociado con el equipo seleccionado. Del mismo modo, un componente de programación 734 puede lanzar la interfaz de programación de un software de programación asociado a un equipo seleccionado. Un usuario puede escribir o editar el código del programa directamente desde la interfaz de programación que aparece en el software del sistema sin tener que iniciar el software de programación. Si el usuario desea cambiar el código de programa de otro equipo (por ejemplo, un equipo del mismo tipo pero de diferente proveedor, o un tipo de equipo completamente diferente (por ejemplo, un accionamiento en lugar de un PLC)) que usa un software de programación diferente, el componente de programación 734 identifica automáticamente el equipo y lanza la interfaz de programación adecuada para ese equipo junto con cualquier código de programa asociado o desplegado actualmente en el equipo. En algunas realizaciones, las asociaciones entre equipo/tipo de equipo y aplicaciones pueden ser definidas por el usuario y almacenadas en un nodo de almacenamiento.
En algunas realizaciones, el software de sistema 740 también puede incluir un conjunto de componentes que soportan la gestión de ciberseguridad, gestión de red, gestión de datos y/u otros aspectos de un sistema de automatización. Por ejemplo, el componente de gestión de red 716 puede monitorizar los equipos de automatización conectados al dispositivo y/o a las redes de gestión (por ejemplo, para descubrir nuevos dispositivos a medida que se conectan a una red, para descubrir un dispositivo que se desconecta). En algunas realizaciones, el componente de gestión de red 716 también puede monitorizar componentes de red como hardware de conmutación y enrutamiento que forman parte de la red física.
El componente de gestión de ciberseguridad 718, en algunas realizaciones, puede gestionar aspectos de ciberseguridad del sistema de automatización. Por ejemplo, el componente de gestión CS 718 puede crear y mantener perfiles de seguridad que pueden ser asociados con cualquier nueva unidad funcional o equipo de automatización en el sistema de automatización. En algunas realizaciones, el componente de gestión de datos 722 puede gestionar cómo se comparten los datos entre los diferentes componentes y equipos del sistema de automatización. Normalmente, las diferentes partes del sistema generan grandes cantidades de datos diferentes. Reunir grandes cantidades de datos en un solo lugar y gestionarlos, organizarlos y mostrarlos se convierte en una tarea compleja y desalentadora. El software del sistema 740, a través del componente de gestión de datos 722, resuelve este problema por medio de la agregación de datos de las diferentes partes del sistema en un solo lugar, lo cual hace que la organización y el análisis de los datos sean mucho más eficientes. En algunas realizaciones, el componente de gestión de datos 722 puede proporcionar varios filtros que se pueden aplicar para ver datos seleccionados asociados con un equipo específico o un subconjunto de equipos, sin tener que acceder a diferentes software asociados con diferentes equipos. En algunas realizaciones, el componente de gestión de datos 722 también puede gestionar y mostrar en el entorno de software del sistema, variables del sistema que incluyen datos compartidos entre diferentes dispositivos del sistema y editores de los datos.
Las FIGs. 7C a 7F son diagramas de capturas de pantalla que ilustran ejemplos de interfaces de usuario del software del sistema de acuerdo con algunas realizaciones. La FIG. 7C representa una captura de pantalla de ejemplo de una interfaz de usuario 750 del software del sistema 740 que proporciona una vista gráfica de los dispositivos en un sistema de automatización de ejemplo. A través del software del sistema, un usuario puede gestionar todo el ciclo de vida del sistema, empezando por el diseño 752, la configuración 754 y la programación 756. Como se representa, el sistema de automatización de ejemplo incluye un PLC 758, un p Lc 760 y un accionamiento 240, entre otros.
En algunas realizaciones, el software del sistema permite acceder directamente desde la interfaz de software del sistema (o vista de diseño) a diferentes aplicaciones de software asociadas con los dispositivos mostrados en la vista gráfica. Por ejemplo, como se muestra en la captura de pantalla 751 de la FIG. 7D, un usuario puede seleccionar el PLC 760 y hacer clic en “configurar” en el menú 764. La captura de pantalla 753 de la FIG. 7E representa una interfaz de configuración de PLC 768 de la aplicación de configuración de PLC 766 que se lanza en respuesta a la solicitud de configuración. Del mismo modo, una pantalla de configuración de ejemplo 770 asociada con la unidad 762 representada en la FIG. 7C se puede acceder directamente desde el software del sistema, como se muestra en la captura de pantalla 755 de la FIG. 7F. En algunas realizaciones, también se puede acceder al código programado en un dispositivo, editarlo y volver a desplegarlo en el dispositivo directamente desde el software del sistema.
5. Servidor de Niebla
La FIG. 8A es un diagrama de bloques que ilustra componentes del servidor de niebla de acuerdo con una primera realización. El servidor de niebla se compone de una infraestructura de control y gestión denominada nodos controladores 810-1, 810-2 junto con los nodos de cómputo asociados 820-1, 820-2, 820-3, ..., 820-N. Cada uno de los nodos de cómputo 820-1, 820-2, 820-3, ..., 820-N puede ejecutar un número de hosts 802-1, ..., 802-N y redes virtuales asociadas 820. Estos hosts pueden ser máquinas virtuales, contenedores o bare metals. Cada host a su vez puede ejecutar un huésped 804. Un huésped 804 puede incluir una aplicación, una función de aplicación (es decir, una pieza o porción de una aplicación que corresponde o lleva a cabo una función), o cualquier implementación de software de un dispositivo físico, componente o unidad funcional. En algunas realizaciones, un host 802-1 puede ejecutar otro host 802-A que a su vez puede ejecutar un huésped. Por ejemplo, el host 802-1 del nodo de cómputo 820-3 puede ser una máquina virtual en la que se instancie un contenedor 802-A para ejecutar el huésped 804. Las redes virtuales 820 se conectan desde dentro de los nodos de cómputo (por ejemplo, 820-1, 820­ 2, ...) a través de interfaces externas (por ejemplo, puertos Ethernet) a las redes físicas externas (por ejemplo, la red de datos/OT 865). Las redes virtuales 820 residen dentro de los nodos de cómputo (por ejemplo, 820-1, 820-2, ...) y proporcionan conectividad entre las entidades virtualizadas y el mundo físico. En algunas realizaciones, un nodo de cómputo puede ser un dispositivo inteligente conectado, que puede tener una parte física y una parte virtual. Por ejemplo, el nodo de cómputo 820-N puede ser un dispositivo inteligente conectado 815 que puede ejecutar un host 802-B que ejecute un huésped 804. El mismo dispositivo inteligente conectado 815 también puede tener un sensor/actuador físico 814. El nodo de cómputo 820-N como otros nodos de cómputo se pueden conectar a la red de datos/OT 865.
Los huéspedes 804 no se consideran parte del servidor de niebla; sin embargo, la gestión de estas entidades está dentro del ámbito del servidor de niebla. Algunas de las acciones de gestión incluyen la distribución y redistribución de los hosts, instanciación de hosts, planificación y gestión de recursos (por ejemplo, asignación de RAM, interfaces de red y otros recursos), asignación de almacenamiento, destrucción y similares.
Mientras que las redes virtuales 820 se configuran a través de servicios proporcionados por el servidor de niebla, la responsabilidad de la orquestación de estas redes pertenece al subsistema de red. Esto permite una gestión de red cohesiva entre las redes físicas y virtuales.
Los nodos controladores del servidor de niebla 810-1, 810-2 están interconectados a los nodos de cómputo 820-1, 820-2, ..., 820N a través de enlaces de red de gestión 812. Estos enlaces pueden ser físicos con cableado dedicado o pueden ser enlaces lógicos en una red física subyacente. Por ejemplo, el enlace 812 puede estar en las redes físicas 806 u 865. A modo de otro ejemplo, los enlaces 806, 812 y 865 pueden compartir la misma red física, pero diferentes redes lógicas. El uso de tecnologías tales como VLAN, VxLANs , VTN y similares para proporcionar una separación lógica de la red física permite usar una única red para múltiples fines simultáneamente. En algunas realizaciones, el controlador del servidor de niebla 810-2 puede ser un controlador redundante que proporciona capacidad de alta disponibilidad (HA).
El nodo(s) de almacenamiento 825-1/nodo de almacenamiento redundante 825-2 puede proporcionar una solución de almacenamiento de alto volumen que está optimizada para el tipo de acceso y los requisitos de datos y latencia necesarios para ejecutar un sistema de automatización. Este nodo puede ser opcional en algunas realizaciones. El nodo o nodos de almacenamiento se pueden incorporar al sistema como nodos de almacenamiento conectados directamente a la red o redes de gestión 812 y/o a la red o redes de OAM 806. Si no se proporciona el nodo de almacenamiento, este papel puede ser asumido por los nodos controladores 810-1, 810-2 y/o los nodos de cómputo 820-1, ..., 820-N. Los nodos de almacenamiento pueden usar redundancia para proporcionar HA en algunas realizaciones. Cabe señalar que en algunas realizaciones, el nodo de almacenamiento 825-1, 825-2 puede ser un nodo lógicamente centralizado que comprende otros nodos de almacenamiento que pueden estar potencialmente distribuidos.
La FIG. 8B es un diagrama de bloques que ilustra componentes del servidor de niebla de acuerdo con una segunda realización. Este escenario de despliegue alternativo optimiza el hardware usado para implementar el servidor de niebla. Este escenario de despliegue, conocido como modelo CPE (Equipo en las Instalaciones del Cliente), agrupa las funciones de controlador, almacenamiento y computación en un único dispositivo servidor, es decir, el nodo c Pe 822-1. El nodo servidor CPE también se puede duplicar (es decir, el nodo CPE 822-2) para proporcionar despliegues HA en algunas realizaciones. En esta realización, los nodos del servidor CPE se pueden comunicar a través de una red de gestión 812. El(los) nodo(s) de almacenamiento 825 se puede(n) incorporar al sistema como nodos de almacenamiento conectados directamente a la(s) red(es) de gestión 812 y/o red(es) OAM 806 y/o red(es) de datos 855. Si no se proporciona el nodo de almacenamiento, este papel puede ser asumido por los nodos CPE 822-1 y 822-2. Este escenario proporciona una solución de bajo coste que se podría usar en objetivos de implantación más pequeños que acepten la restricción de no disponer de nodos de cómputo distribuidos.
La FIG. 9A es un diagrama de bloques que ilustra componentes de un controlador del servidor de niebla en algunas realizaciones. Como se representa, un controlador del servidor de niebla 910 puede incluir un componente de orquestación de niebla 902 y un componente de gestión de host 916, entre otros. El componente de orquestación de niebla 902 interactúa con los componentes de orquestación de otros subsistemas de un sistema SDA para el aprovisionamiento, la configuración, la gestión y similares. El papel del componente de orquestación de niebla 902 se discute en detalle en las FIGs. 10B y 11.
En algunas realizaciones, el componente de gestión de host 916 puede usar una o más tecnologías de virtualización de host para proporcionar una infraestructura de virtualización sobre la que se puede ejecutar y/o gestionar un sistema de automatización. Por ejemplo, el componente de gestión de host 916 puede usar tecnologías de virtualización de host para crear instancias virtualizadas de un dispositivo (por ejemplo, implementación de software del dispositivo en una máquina virtual), aplicación o función en el sistema de automatización. El dispositivo virtualizado se ejecuta como una instancia sólo de software en un entorno que presenta al dispositivo virtual una abstracción del hardware físico aislado del sistema del host. Además de los dispositivos, otros aspectos del sistema de automatización, tal como las redes y los elementos de seguridad, también se pueden virtualizar en algunas realizaciones. Algunas de las tecnologías de virtualización de host que pueden ser usadas por el componente de gestión de host 916 se describen en detalle a continuación.
A. VM clásica
La FIG. 9B ilustra componentes de ejemplo de un nodo de cómputo que aloja máquinas virtuales. En algunas realizaciones, los nodos de cómputo 915 con soporte de virtualización pueden usar máquinas virtuales (VM) (host) 902-1, ..., 902-N para proporcionar aplicaciones 912 (huésped) altamente flexibles y aisladas. Un nodo de cómputo 915 aloja una o más máquinas virtuales 902-1, ..., 902-N que incluyen la lógica de negocio de la aplicación 912 y sus propios SO/bibliotecas 926. Este mecanismo proporciona una aplicación flexible, dado que la VM invitada se puede basar en cualquier sistema operativo 916 e incluso puede usar la emulación para liberarse de las restricciones de la arquitectura de hardware. Como tal, la máquina virtual puede tener su propio hardware virtual. De hecho, debido a que las VM tienen acceso directo a la CPU a través del hipervisor y cada VM clásica tiene su propio hardware virtual 924, núcleo 922, sistema de inicio 918 y OS 916, es posible ejecutar OS completamente diferentes (por ejemplo, Windows, Linux) en el mismo nodo de cómputo de forma simultánea, independientemente del OS nativo del nodo de cómputo. La penalización con respecto a las otras soluciones (descritas a continuación) puede ser en rendimiento y determinismo. Otro inconveniente puede ser el tamaño de la aplicación, que podría ser sustancialmente mayor, dado que debe incluir un núcleo 922 completo, un sistema de inicio 918, un sistema operativo 916 y bibliotecas asociadas 914. Típicamente, el acceso al hardware físico 932 se proporciona a través de un hipervisor 928 que añade una capa adicional y latencia asociada. Se pueden usar algunas aceleraciones específicas del proveedor para mitigar este efecto.
Las máquinas virtuales 902-1, ..., 902-N se pueden migrar en vivo, es decir, las VM en ejecución se pueden migrar de un nodo de cómputo a otro con un impacto mínimo en las VM en ejecución y en los procesos de aplicación asociados. Esto permite al componente de gestión de host 916 y/o al componente de orquestación de niebla 902 proporcionar un grado de equilibrio de carga, alta disponibilidad y gestión de energía por medio de la optimización de la distribución de VM entre múltiples nodos de cómputo 915 y apagar los nodos de cómputo innecesarios.
B. Contenedores
Las FIGs. 9C y 9D ilustran ejemplos de componentes de nodos de cómputo que alojan contenedores. Los contenedores proporcionan mejoras de rendimiento, flexibilidad y tamaño para las aplicaciones, pero vienen con su propio conjunto de limitaciones. Los contenedores usan una sandbox de memoria que se apoya en el hardware de la máquina del host para proporcionar un entorno seguro y aislado para ejecutar la aplicación. El uso de un contenedor proporciona algunas mejoras de rendimiento y tamaño con respecto a una VM, dado que usa directamente los controladores del host sin la capa del hipervisor. Sin embargo, con los contenedores, una aplicación está inextricablemente vinculada a la arquitectura de hardware y al núcleo del host. Un ejemplo de aplicación de los contenedores es la respuesta a la demanda.
Con referencia a la FIG. 9C, para conseguir un mejor rendimiento, algunos contenedores 904-1, ..., 904-N pueden incluir sólo la aplicación 912, mientras que se basan en el núcleo 934, el sistema de inicio 918, el sistema operativo 916 y las bibliotecas 914 nativas del nodo de cómputo. Estos contenedores tienen más limitaciones desde el punto de vista del desarrollo de bibliotecas/aplicaciones, pero son más ligeros, más pequeños, más rápidos de desovar y son capaces de ofrecer el mejor rendimiento.
Con referencia a la FIG. 9D, algunos contenedores 907-1, ..., 907-N pueden incluir el sistema operativo completo 916 (menos el núcleo) para la aplicación huésped 912, el sistema de inicio 918, y las bibliotecas 914 pero ejecutándose dentro del espacio contenedor en sandbox del host. Dado que los contenedores dependen del núcleo 934 del host y de su hardware físico asociado 932, también deben coincidir con la arquitectura de hardware y el linaje del núcleo del host 915.
Al igual que las VM, los contenedores también pueden ser migrados en vivo de un nodo de cómputo a otro.
C. Bare Metal
La FIG. 9D ilustra ejemplos de componentes de un nodo de cómputo bare metal. En algunas realizaciones, los nodos de cómputo 915 pueden servir como hosts de bare metal para permitir que los sistemas integrados sean administrados por el componente de administración de host de servidor de niebla 916. Los hosts de bare metal ejecutan una imagen binaria construida a propósito que está estrechamente acoplada al hardware del host 932, de forma muy parecida a un dispositivo integrado tradicional. Esta imagen binaria puede aprovechar al máximo el acceso directo al hardware 932 como si la imagen se instalara en la fábrica. En algunas realizaciones, de forma similar a cómo se gestionan las VM dentro del servidor de niebla, los nodos de cómputo de bare metal se pueden aprovisionar y configurar a través del componente de aprovisionamiento 906 y el componente de configuración 908 del sistema de gestión de host 916 de la FIG. 9A.
En algunas realizaciones, la imagen de bare metal puede ser un núcleo completo 934 y un OS 916 para convertir el nodo de bare metal en un nodo de cómputo completo con VM y/o contenedores con su propio soporte para VM y/o contenedores.
Con referencia a la FIG. 9A, el componente de aprovisionamiento 906 puede crear redes virtuales de proveedor y/o arrendatario e instancias virtualizadas y conectarlas entre sí. El componente de configuración 908 puede facilitar la configuración de las instancias virtualizadas y/o dispositivos físicos bajo la gestión del servidor de niebla. Los datos que se usan para la configuración se pueden recibir del software del sistema en algunas realizaciones.
6. Orquestaciones en un sistema SDA
La FIG. 10a es un diagrama de bloques que ilustra un ejemplo de una vista de componente de un sistema SDA de acuerdo con algunas realizaciones. En el servidor de niebla (o la plataforma de niebla) 1005, uno o más dispositivos virtuales 1036 e instancias de aplicaciones 1-N se pueden ejecutar en uno o más nodos de cómputo (no mostrados) y/o dispositivos de borde representados como un dispositivo inteligente conectado 1015. En algunas realizaciones, la(s) aplicación(es) analítica(s) o los motores 1006 se pueden ejecutar en una nube remota 1050 (por ejemplo, la nube 450 de la FIG. 4) como se muestra, en el servidor de niebla 1005 o en ambos. En un sistema de automatización industrial, las aplicaciones relacionadas con los sistemas empresariales 1035 (por ejemplo, Planificación de Recursos Empresariales (ERP), Sistema de Ejecución de Manufactura (MES)) y la gestión de activos 1014 se pueden ejecutar en el nivel de sala empresarial (por ejemplo, nivel 4, nivel de sala empresarial 205 en la FIG. 2B) o en el servidor de niebla 1005, mientras que algún software local 1008 (por ejemplo, SCADA) se puede ejecutar en el servidor de niebla 1005. En un sistema de automatización de edificios, las aplicaciones que se ejecutan a nivel de empresa y a nivel del servidor de niebla 1005 pueden ser de sistemas de gestión de edificios (no mostrados).
En algunas realizaciones, un dispositivo físico 1034 puede no tener la capacidad de conectarse a la red para convertirse en un dispositivo gestionado por el servidor de niebla. Dicho dispositivo puede seguir siendo gestionado y controlado a través de un dispositivo cibernético 1032 gestionado por el servidor de niebla 1005. Este dispositivo cibernético 1032 puede ser una representación virtual de uno o más dispositivos físicos. El dispositivo cibernético 1032 se puede publicar/suscribir a datos en tiempo real en el servidor de niebla 1005 o, alternativamente, puede usar la comunicación punto a punto para obtener acceso a datos de aplicaciones/dispositivos gestionados por el servidor de niebla 1005. El dispositivo cibernético 1032 se puede comunicar con el dispositivo físico 1034 a través de un protocolo OT. El dispositivo cibernético gestionado por niebla 1032 de este modo se puede acoplar comunicativamente a un dispositivo físico 1034 a través de un protocolo OT para formar una máquina definida por software 1046.
La FIG. 10B es un diagrama de bloques que ilustra ejemplos de una vista de control y una vista de sistema de un sistema SDA de acuerdo con algunas realizaciones. La vista de control del SDA 1002 incluye un software de sistema 1040 y un número de componentes de orquestación que garantizan que cada uno de los subsistemas del SDA trabaje de forma coordinada entre sí para definir o poner en marcha y gestionar el sistema de automatización. Los componentes de orquestación incluyen un componente de orquestación de servidor de niebla 1024, un componente de orquestación de red 1022, un componente de orquestación de ciberseguridad 1018 y un componente de orquestación de almacenamiento 1016.
La vista del sistema SDA 1012, en algunas realizaciones, incluye un servidor de niebla 1005 que tiene un controlador del servidor de niebla 1010, uno o más nodos de cómputo 1015 y un almacenamiento 1025. En algunas realizaciones, el almacenamiento puede estar fuera del servidor de niebla 1005, como se representa por el almacenamiento 1026. Los nodos de cómputo 1015 y el almacenamiento 1025 en el servidor de niebla 1005 pueden ser orquestados juntos por el componente de orquestación del servidor de niebla 1024 en algunas realizaciones (es decir, la orquestación del servidor de niebla 1024 y la orquestación del almacenamiento 1026 se pueden combinar). Mientras que cada uno de los componentes de orquestación son orquestados individualmente, un componente de orquestación de nivel superior - el componente de orquestación del sistema 1016 - los orquesta conjuntamente para virtualizar dispositivos y aplicaciones en nodos de cómputo 1015 en el servidor de niebla 1005 (vía orquestación del servidor de niebla 1024), gestionar los datos asociados a esos dispositivos y aplicaciones virtualizados en el almacenamiento 1025/1026 (por medio de la orquestación del almacenamiento 1026), definir y difundir las políticas de ciberseguridad a todos los componentes del sistema SDA (por medio de la orquestación de la ciberseguridad 1018), y los flujos y comunicaciones de red (por medio de la orquestación de la red 1022). Un software del sistema 1040 interactúa con el componente de orquestación del sistema 1016 para transformar comandos/instrucciones/señales (por ejemplo, del usuario u otro sistema) a través de la orquestación del servidor de niebla 1024, la orquestación de red 1022, la orquestación de ciberseguridad 1018 y/o la orquestación de almacenamiento 1026 en cambios del sistema de automatización. Además, el software del sistema 1040 se puede ejecutar en el servidor de niebla 1005 y tiene una visión completa del sistema de automatización.
En algunas realizaciones, la orquestación de red incluye orquestación SDN (por ejemplo, por medio de controlador SDN), orquestación TSN (por ejemplo, por medio de controlador TSN) u orquestación SDN-TSN, que es una combinación de orquestaciones SDN y TSN (por medio de controladores SDN y TSN).
En algunas realizaciones, las instancias de aplicación que se ejecutan en el servidor de niebla 1005 o en un dispositivo de borde 1004 pueden compartir datos mediante el uso de un protocolo de comunicación tal como el Servicio de Distribución de Datos (DDS) o la Arquitectura Unificada de Comunicaciones de Plataforma Abierta (OPC-UA). El DDS permite a cualquier equipo conectado a la red 1042 suscribirse a cualquier dato producido por los dispositivos gestionados por el servidor de niebla (por ejemplo, el dispositivo 1004, los dispositivos/componentes virtuales en los nodos de cómputo 1015). Los dispositivos pueden actualizar los suscriptores en tiempo real por medio de la publicación del valor de los datos cuando esos valores cambian en algunas realizaciones.
En otras realizaciones, los datos pueden ser compartidos a través de una comunicación punto a punto. Independientemente de los protocolos de comunicación compartidos o punto a punto usados, el tráfico de datos hacia/desde las instancias de aplicación que se ejecutan en dispositivos/componentes virtuales en los nodos de cómputo 1015 se transporta en redes virtuales 1020 que se mapean a la red física 1042. Del mismo modo, el tráfico de datos hacia/desde las aplicaciones que se ejecutan en los dispositivos físicos es transportado por la red física 1042.
La FIG. 11 es un diagrama de bloques que ilustra un ejemplo de orquestación de subsistemas SDA para aprovisionar una unidad funcional en un nodo de cómputo de acuerdo con algunas realizaciones.
En algunas realizaciones, un software de sistema 1140 que ejecuta una instancia de una cadena de herramientas de ingeniería permite a un usuario instanciar y gestionar un sistema SDA. Una cadena de herramientas de ingeniería puede ser específica de un sistema de automatización concreto. Por ejemplo, una cadena de herramientas destinada a un sistema de automatización industrial sería diferente de una destinada a un sistema de automatización de edificios, dado que estos sistemas de automatización pueden tener diferentes tipos de dispositivos de automatización (y, por lo tanto, diferentes plantillas de dispositivos/unidades funcionales), así como una o más aplicaciones de software para la parametrización, configuración, programación y similares. La cadena de herramientas de ingeniería se integra con un componente de orquestación del sistema (SDA) 1116 a través de una interfaz de programación de aplicaciones (API). De este modo, cuando el usuario de la cadena de herramientas emite un comando, la cadena de herramientas dirige el componente de orquestación del sistema 1116 de forma que hace que el sistema SDA en su conjunto trabaje coordinadamente para ejecutar el comando.
Consideremos un escenario en el que es necesario aumentar la capacidad de tratamiento de equipajes en un aeropuerto por medio de la adición de una nueva cinta transportadora. Un usuario puede acceder al software del sistema 1140 (cargado con una cadena de herramientas adecuada) y seleccionar una plantilla de unidad funcional, por ejemplo, una plantilla para un sistema de cinta transportadora, de una lista de selección y añadirla al panel de diseño del sistema de control. El usuario puede parametrizar la plantilla para proporcionar información de instancia para la nueva unidad funcional. Por ejemplo, la plantilla de cinta transportadora puede consistir en tres PAC virtuales, un número de IO, un número de conmutadores físicos y virtuales. El usuario puede proporcionar información sobre la instancia, tal como por ejemplo: identidad de la instancia (por ejemplo, nombres de componentes/dispositivos, direcciones IP, etc.), conectividad de E/S (por ejemplo, cómo están conectados los elementos de la unidad funcional, de qué dispositivos de E/S puede leer/escribir la unidad funcional), restricciones de tiempo (por ejemplo, tiempo de respuesta determinista máximo o tiempo de transferencia entre la unidad funcional y otra entidad, por ejemplo, el equipo que controla), perfiles de seguridad (por ejemplo, capacidad de acceso de lectura/escritura a los datos, capacidad de programación de la unidad funcional), y similares. La descripción de la unidad funcional 1142, es decir, la información que describe la plantilla de unidad funcional a instanciar es comunicada por el software del sistema 1140 al componente de orquestación SDA 1116. En algunas realizaciones, la descripción de la unidad funcional 1142 puede incluir información relacionada con la descripción de virtualización de la unidad funcional, flujos de comunicación, flujos de red, perfiles de seguridad, y/o similares. A modo de ejemplo, la descripción de virtualización de la unidad funcional puede incluir la información de instancia, que incluyen el tipo y la cantidad de componentes a instanciar o aprovisionar (por ejemplo, 3 PLCs, 2 módulos de E/S distribuidos, 1 conmutador virtual en el ejemplo de la cinta transportadora), los requisitos de redundancia, y similares. La descripción de virtualización de la unidad funcional también puede incluir, para cada componente, las aplicaciones asociadas y la versión de las aplicaciones, el paquete de programación asociado (por ejemplo, Unity para el PLC) y similares para facilitar la configuración y programación de la unidad funcional o de los componentes de la misma.
La descripción del flujo de comunicación puede incluir información relativa a la conectividad o enlaces de E/S, tipo de prioridad de E/S (por ejemplo, alta prioridad, baja prioridad), restricciones de tiempo, lista de E/S con información de conexión (por ejemplo, datos, tasa), intercambio de datos peer-to-peer, intercambio de datos SCADA, declaraciones de otros flujos (SNMP, Web, correo electrónico, etc.,), y similares. Los perfiles de seguridad pueden incluir listas de control de acceso (ACL), listas de puertos y protocolos, restricciones de ancho de banda autorizado, sitios/direcciones en lista negra/blanca y/o similares. En algunas realizaciones, la descripción de la unidad funcional 1142 también puede incluir configuraciones de huésped (por ejemplo, VM), tales como pero no limitadas a: tipos de procesador, memoria, afinidad, validación de imagen de máquina virtual y similares. La descripción del flujo de red puede incluir información tal como listas de ancho de banda y puertos, restricciones de ruta de flujo (por ejemplo, no vídeo o datos de alto ancho de banda en enlaces de E/S de alta prioridad), conectividad de puertos, velocidad de interfaz, y similares.
El componente de Orquestación SDA 1116 analiza la descripción de la unidad funcional en subdescripciones y comienza a manejar los orquestadores de los diferentes subsistemas en consecuencia. Por ejemplo, el componente de orquestación SDA 1116 pasa una descripción de los flujos de comunicación solicitados 1144 extraída de la descripción de la unidad de función 1142 al componente de orquestación de ciberseguridad 1118 del controlador CS 1155. El componente de orquestación CS 1118, en base a los flujos de comunicación solicitados 1144, deriva políticas de seguridad para el acceso de anfitriones/huéspedes, segmentación del tráfico de red, configuraciones de cortafuegos, configuraciones ACL (por ejemplo, dirección IP/nombre de la entidad de conexión y naturaleza de la conexión prevista tal como puerto TCP/UDP, tipos de acceso permitidos, bloqueo de protocolos y puertos no autorizados, y similares), inicios de sesión autorizados para monitorización, configuración, y similares. Control de los tipos de tráfico permitidos a un punto final, configuración de canales seguros, control de la longitud y el direccionamiento de los paquetes de datos, etc. En algunas realizaciones, las diversas políticas de seguridad pueden ser gestionadas por un gestor de políticas de seguridad 1126. El servicio de autenticación 1128 en algunas realizaciones puede proporcionar servicio de autenticación a los otros subsistemas. Por ejemplo, puede autenticar las solicitudes de virtualización de una unidad funcional.
El componente de orquestación de ciberseguridad 1118, en algunas realizaciones, proporciona las políticas de seguridad necesarias para el controlador del servidor de niebla 1110 y el controlador de red 1190 (por ejemplo, SDN, TSN y/u otro(s) controlador(es) de red) al componente de orquestación SDA 1115. En otras realizaciones, el componente de orquestación CS 1118 puede hacer que las políticas de valores se distribuyan directamente a los controladores pertinentes. Por ejemplo, las políticas de seguridad relativas a las funciones de virtualización al controlador del servidor de niebla 1110, y las políticas de seguridad relativas a las funciones de red al controlador de red 1190. En algunas realizaciones, el controlador CS 1155 puede diseminar reglas de políticas de dispositivos y conmutadores al sistema de protección de seguridad que puede entonces gestionar el despliegue y la aplicación de esas políticas a nivel de dispositivo.
El componente de orquestación SDA 1116 al recibir las políticas de seguridad 1148 del controlador CS 1155, pasa una descripción de los elementos virtualizados de la unidad funcional extraída de la descripción de la unidad funcional 1142 y las políticas de seguridad relevantes 1152 al componente de orquestación de niebla 1124. En algunas realizaciones, el componente de orquestación de niebla 1124 puede solicitar al controlador CS 1155 las políticas de seguridad pertinentes. El componente de orquestación de niebla 1124 acciona el controlador del servidor de niebla 1110 (por ejemplo, el componente de gestión del host 916 en la FIG. 9A) para crear, de acuerdo con lo necesario, las redes virtuales de proveedor y/o arrendatario 1120 en uno o más nodos de cómputo. Esto puede incluir la instanciación de conmutadores virtuales o enrutadores virtuales. El componente de orquestación de niebla 1124 crea una instancia virtualizada de la unidad funcional 1134 que incluye la creación de una instancia virtualizada de cada componente de la unidad funcional (es decir, 3 vPAC y 1 conmutador virtual en este ejemplo) y la conexión de las instancias virtualizadas a las redes virtuales asociadas 1120. En algunas realizaciones, en base a los requisitos de redundancia (por ejemplo, predefinidos o especificados con la solicitud), se puede proporcionar más de una instancia de la unidad funcional 1134.
El componente de orquestación SDA 1116 pasa una descripción de los flujos de red 1154 asociados con la unidad funcional y cualquier política de seguridad requerida 1154 al componente de orquestación de red 1122. A partir de esta descripción, el componente de orquestación de red 1122 puede discernir las rutas de red requeridas, la segmentación, y similares, y dirigir el controlador de red 1190 para configurar los elementos de red 1136 en la red física, así como los elementos de red en las redes virtuales 1120 en consecuencia. En algunas realizaciones, todos los dispositivos (por ejemplo, infraestructura física y virtual y dispositivos finales) pueden solicitar sus políticas de seguridad asociadas a un servidor de políticas 1138. De este modo, el sistema SDA no sólo puede aprovisionar una unidad funcional en un nodo de cómputo, sino que también puede aprovisionar los recursos de red que la unidad funcional necesita para estar en funcionamiento.
Una vez creada o aprovisionada la unidad funcional y configurada en consecuencia la infraestructura de red, se puede usar el software del sistema para configurar y programar los componentes de la unidad funcional. Por ejemplo, los vPAC de la unidad funcional se pueden configurar y programar mediante el uso del software asociado a través del portal de software del sistema para controlar el funcionamiento del sistema de cintas transportadoras. En algunas realizaciones, la configuración de la unidad funcional también puede incluir la configuración de los componentes físicos asociados de la unidad funcional. Por ejemplo, el controlador del servidor de niebla 1110 puede reconfigurar un módulo de E/S por medio de la actualización de sus ACL para permitir la conexión de los vPAC. En algunas realizaciones, el módulo de E/S puede ser un dispositivo inteligente conectado en el que el controlador del servidor de niebla 1110 puede programar la lógica asociada (por ejemplo, la lógica para procesar la funcionalidad basada en la seguridad).
7. Ejemplos de metodologías aplicadas en el sistema SDA
La FIG. 12 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la creación de un sistema de automatización de acuerdo con algunas realizaciones.
En el bloque 1202, un subsistema del servidor de niebla que incluye un controlador del servidor de niebla y múltiples nodos de cómputo crea o instancia componentes virtuales del sistema de automatización en uno o más nodos de cómputo (por ejemplo, a través del componente de aprovisionamiento 906 de la FIG. 9A). Los elementos del sistema de automatización se pueden virtualizar mediante el uso de tecnologías de virtualización tales como máquinas virtuales, contenedores y bare metals. Además, los nodos de cómputo en los que se ejecutan los componentes virtuales pueden estar físicamente distribuidos en algunas realizaciones. Por ejemplo, un nodo de cómputo puede estar en la planta, mientras que otro puede estar en una sala de control. Independientemente de la ubicación de los nodos de cómputo, la comunicación entre el controlador del servidor de niebla y los nodos de cómputo se lleva a cabo a través de una red de gestión dedicada separada de la red física, o a través de la misma red física.
En el bloque 1204, el subsistema del servidor de niebla (por ejemplo, a través del componente de aprovisionamiento 906 de la FIG. 9A) crea redes virtuales asociadas dentro de los nodos de cómputo. En el bloque 1206, el subsistema del servidor de niebla (por ejemplo, a través del componente de aprovisionamiento 906 de la FIG. 9A) conecta los componentes virtuales a las redes virtuales. A continuación, las redes virtuales se conectan a una red física. En el bloque 1208, un subsistema de red que incluye un controlador de red configura componentes de red físicos de la red física y/o componentes de red virtuales de las redes virtuales. En algunas realizaciones, el subsistema de red configura los componentes de red físicos y/o virtuales por medio del despliegue de políticas de red. Las políticas de red pueden incluir políticas para controlar la conectividad, el ancho de banda, la latencia y/o el flujo de tráfico. El controlador de red puede ser un controlador SDN, un controlador TSN o una combinación de ambos.
En el bloque 1210, un subsistema CS que incluye un controlador de seguridad distribuye políticas de seguridad al subsistema del servidor de niebla y al subsistema de red para su despliegue a los componentes virtuales que se ejecutan en los nodos de cómputo y a los componentes de red físicos y/o virtuales. En el bloque 1212, el subsistema del servidor de niebla usa los componentes de red físicos y/o virtuales para comunicarse con los componentes físicos (por ejemplo, dispositivos de campo) del sistema de automatización para controlar el funcionamiento y la gestión del sistema de automatización.
La FIG. 13A es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la adición de una unidad funcional a un sistema de automatización a través de un software de sistema de acuerdo con algunas realizaciones.
Comenzando en el bloque 1302, un usuario puede lanzar el software del sistema. En el bloque 1304, el software del sistema puede presentar una vista topológica de todos los dispositivos, físicos y virtuales, gestionados por el sistema de automatización. La FIG. 13B representa un ejemplo de vista topológica de un sistema transportador que incluye un PAC 1330 en la parte superior de la jerarquía, un PLC virtual 1332 y un módulo de E/S asociado 1334, un accionamiento 1336, un motor 1338 y un transportador (es decir, actuador) 1340. En el bloque 1306, el software del sistema puede recibir una selección de una plantilla de unidad funcional (por ejemplo, plantilla de sistema transportador) para añadir al sistema de automatización. En algunas realizaciones, la plantilla de la unidad funcional se puede seleccionar de una biblioteca de plantillas. El software del sistema puede actualizar la vista topológica para incluir la nueva unidad funcional en el bloque 1308. En el bloque 1310, el software del sistema puede lanzar una primera aplicación para configurar la unidad funcional. En algunas realizaciones, la configuración de la unidad funcional puede incluir información tal como, pero no limitada a: Direccionamiento IP, configuración de E/S, listas de control de acceso, subcomponentes locales y bibliotecas de apoyo, activación de eventos, contraseñas y similares. En el bloque 1312, el software del sistema puede recibir datos de configuración para la unidad funcional. En el bloque 1314, el software del sistema puede lanzar una segunda aplicación para la gestión de datos del sistema. En el bloque 1316, el software del sistema puede configurar la nueva unidad funcional para recibir/enviar datos (por ejemplo, a través de una comunicación punto a punto o a través de un bus de datos en tiempo real compartido). En algunas realizaciones, la configuración y la gestión de datos se pueden llevar a cabo a través de la misma aplicación. En tal situación, el software del sistema puede lanzar una aplicación de configuración y gestión de datos de la unidad funcional en el bloque 1318. El software del sistema puede recibir los datos de configuración y/o instrucciones para la gestión de datos en el bloque 1320. A continuación, el software del sistema puede configurar la unidad funcional para recibir y/o enviar datos en el bloque 1322.
La FIG. 14 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para el aprovisionamiento de una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones. En el bloque 1402, el sistema SDA puede recibir una solicitud para crear o añadir una nueva unidad funcional a un sistema de automatización. En algunas realizaciones, la recepción de la solicitud puede incluir la recepción de una selección de una plantilla de unidad funcional de una biblioteca de plantillas de unidad funcional en el bloque 1404. En algunas realizaciones, un usuario puede llevar a cabo la selección a través de la interfaz de usuario del software del sistema. En otras realizaciones, la definición de la nueva unidad funcional que se va a añadir al sistema de automatización se puede recibir de una entidad que está acoplada comunicativamente al software del sistema (por ejemplo, a través de una API). La recepción de la solicitud también puede incluir la recepción de información para parametrizar la plantilla de unidad funcional en el bloque 1406. En el bloque 1410, el sistema SDA puede autenticar la solicitud en base a al menos una política de seguridad. En algunas realizaciones, el subsistema del servidor de niebla puede llevar a cabo la autenticación mediante el uso de al menos una política de seguridad del subsistema de ciberseguridad. En el bloque de decisión 1412, si la autenticación no es exitosa, la solicitud puede ser denegada por el sistema SDA en el bloque 1416. La etapa de autenticación garantiza que el sistema SDA no lleve a cabo cambios no autorizados en el sistema de automatización.
Si la solicitud es autenticada exitosamente, el sistema SDA puede crear al menos una red virtual en uno o más nodos de cómputo en el bloque 1418, si una red virtual objetivo no existe. El sistema SDA también puede crear una instancia virtual de la unidad funcional en el bloque 1420. La creación de una instancia virtual de la unidad funcional incluye la creación de una instancia virtual de cada elemento de la unidad funcional. Por ejemplo, si una unidad funcional consta de tres PAC, la virtualización de la unidad funcional implicaría la creación de tres PAC virtuales (vPAC). En el bloque 1422, el sistema SDA puede desplegar la instancia virtual de la unidad funcional en un nodo de cómputo. En el bloque 1424, el sistema SDA puede conectar la instancia virtual de la unidad funcional en el nodo de cómputo a las redes virtuales para aprovisionar o comisionar la unidad funcional en el nodo de cómputo.
La FIG. 15 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la configuración de una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
Una vez creada o aprovisionada una unidad funcional (por ejemplo, a través del componente de aprovisionamiento 906 de la FIG. 9A), la unidad funcional se puede configurar por medio del software del sistema. En el bloque 1502, el sistema SDA (por ejemplo, sistema SDA 600 en la FIG. 6A) puede recibir información de configuración para la nueva unidad funcional desde el software del sistema. En el bloque 1504, el sistema SDA (vía un controlador de red, por ejemplo, el controlador de red 690 en la FIG. 6A) puede determinar al menos una ruta de red que atraviese redes virtuales y físicas. El sistema SDA puede configurar uno o más componentes de red en la al menos una ruta de red en el bloque 1506. La configuración de los componentes de red puede incluir la provisión y/o aplicación de una o más políticas de red que especifiquen cómo los componentes de red deben dirigir los diferentes tipos de flujos de tráfico. Por ejemplo, un conmutador virtual/físico se puede asociar a una política de red que especifique que sólo se permite el tráfico HTTP. De este modo, el conmutador en funcionamiento permitiría el paso del tráfico HTTP, pero bloquearía otro tipo de tráfico tal como el MODBUS. En el bloque 1508, el sistema SDA puede configurar la instancia virtual de la unidad funcional mediante el uso de los datos de configuración (por ejemplo, a través del componente de configuración 908 de la FIG. 9A). En el bloque 1510, el sistema SDA puede entonces permitir que el tráfico de datos fluya desde la unidad funcional a un dispositivo (por ejemplo, dispositivo de campo) a través de la al menos una ruta de red para controlar un proceso automatizado.
La FIG. 16A es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la puesta en servicio o aprovisionamiento de una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
El procedimiento de ejemplo incluye la creación, por parte de un controlador del sistema (por ejemplo, el controlador del servidor de niebla 910 de la FIG. 9A) de un subsistema localizado (por ejemplo, subsistema del servidor de niebla), una instancia virtualizada de una unidad funcional de un sistema de automatización en uno o más nodos de cómputo gestionados por el controlador del sistema en el bloque 1602. Estos nodos de cómputo pueden incluir un controlador del sistema de automatización, un servidor, un ordenador personal y/o un dispositivo inteligente conectado. En algunas realizaciones, la creación de una instancia virtualizada de una unidad funcional puede incluir la creación de una instancia totalmente virtualizada de la unidad funcional o de una instancia parcialmente virtualizada de la unidad funcional. Por ejemplo, si una unidad funcional incluye dos componentes (por ejemplo, PLC 1 y PLC 2), entonces una instancia totalmente virtualizada de esta unidad funcional incluiría la virtualización de ambos componentes (es decir, dos componentes virtuales, por ejemplo, vPLC 1 y vPLC 2). Del mismo modo, una instancia parcialmente virtualizada de la unidad funcional podría incluir la virtualización de un componente (es decir, un componente virtual, por ejemplo, vPLC 1), siendo el otro componente un componente físico (por ejemplo, PLC 2). En algunas realizaciones, el componente físico también se puede poner en servicio en el sistema SDA (es decir, ponerse bajo la gestión del servidor de niebla). El procedimiento de puesta en servicio de una unidad funcional que tiene un componente físico se describe en referencia a la FIG. 16B.
La instancia virtualizada de la unidad funcional se puede crear a partir de una plantilla de unidad funcional seleccionada de una biblioteca de plantillas de unidad funcional. Un software de sistema proporciona una interfaz para que un usuario acceda a la biblioteca de plantillas de unidades funcionales para seleccionar la plantilla de unidad funcional y parametrizar la plantilla de unidad funcional. Parametrizar la plantilla de la unidad funcional incluye definir la identidad de la instancia, la conectividad de entrada/salida y el perfil de seguridad para la unidad funcional en algunas realizaciones.
El controlador del sistema puede crear una red virtual en los uno o más nodos de cómputo en el bloque 1604, y luego conectar la instancia virtualizada de la unidad funcional a la red virtual en el bloque 1606. La red virtual se asigna a una red física para permitir que la instancia virtualizada de la unidad funcional interactúe con un dispositivo de campo del sistema de automatización para controlar un proceso automatizado.
En el bloque 1608, el controlador del sistema puede configurar la seguridad de la instancia virtualizada de la unidad funcional por medio de la aplicación de una o más políticas de seguridad desde un subsistema de ciberseguridad. En algunas realizaciones, esto puede incluir la creación de una instancia virtualizada de un sistema de protección de seguridad (por ejemplo, un cortafuegos virtual de próxima generación) en uno o más nodos de cómputo basado en una política de seguridad. En algunas realizaciones, la instancia virtualizada de la unidad funcional incluye uno o más hosts en los que se ejecuta la implementación de software de la unidad funcional. Como tal, la configuración de la seguridad de la instancia virtualizada de la unidad funcional puede incluir la configuración de la seguridad de la implementación de software de la unidad funcional, los uno o más hosts, y/o los uno o más nodos de cómputo en los que se ejecutan los uno o más hosts. En algunas realizaciones, un host de los uno o más hosts incluye una máquina virtual, un contenedor o un bare metal. En algunas realizaciones, en respuesta a una solicitud para crear la instancia virtualizada de la unidad funcional del sistema de automatización, el controlador del sistema puede aplicar al menos una política de seguridad para autenticar la solicitud antes de crear la instancia virtualizada de la unidad funcional. El controlador de seguridad también puede aplicar al menos una política de seguridad para validar una imagen de cada host asociado con la instancia virtualizada de la unidad funcional.
En el bloque 1610, el controlador de red del subsistema de red puede determinar al menos una ruta de red desde la instancia virtualizada de la unidad funcional a un dispositivo de campo a través de las redes virtual y física. A continuación, en el bloque 1612, el controlador de red puede configurar uno o más elementos de red en la al menos una ruta de red para permitir el flujo de tráfico de datos entre la instancia virtualizada de la unidad funcional y el dispositivo de campo. En el bloque 1614, el controlador de red puede configurar la seguridad de uno o más elementos de red en la al menos una ruta de red por medio de la aplicación de una o más políticas de seguridad proporcionadas por el subsistema de ciberseguridad.
La FIG. 16B es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la puesta en servicio o aprovisionamiento de una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
El procedimiento de ejemplo incluye la recepción, por parte de un controlador del sistema (por ejemplo, el controlador del servidor de niebla 910 de la FIG. 9A, el controlador del servidor de niebla 610 de la FIG. 6A), una solicitud de puesta en servicio de una unidad funcional en el bloque 1616. En respuesta a la solicitud de puesta en servicio, un controlador de red (por ejemplo, el controlador de red 690 de la FIG. 6A) en respuesta a la recepción de la solicitud de puesta en servicio por el controlador del sistema, al menos una ruta de red para la unidad funcional que está conectada a una red física en el bloque 1618. En el bloque 1620, el controlador de red configura uno o más elementos de red en la al menos una ruta de red para poner en servicio la unidad funcional en el sistema de automatización que permite el flujo de tráfico de datos entre la unidad funcional y un dispositivo de campo en el sistema de automatización.
8. Gestión del sistema SDA
La FIG. 17 es un diagrama de bloques que ilustra componentes de ejemplo de un componente de gestión de host 1716 de acuerdo con algunas realizaciones. En algunas realizaciones, la gestión de hosts y huéspedes se coordina de forma centralizada a través de este componente. El componente de gestión de host 1716 puede incluir componentes tales como un componente de aprovisionamiento 1706, un componente de configuración 1708, un componente de monitorización 1712, y un componente de selección de nodo de cómputo 1714 en algunas realizaciones. En otras realizaciones, el componente de gestión de host 1716 puede incluir un componente de detección de eventos 1726 y un componente de gestión de eventos 1720. En otras realizaciones, el componente de gestión de host 1716 puede incluir un componente de informe de uso 1722 y/o un componente de gestión de modo operativo 1724. Cabe señalar que uno o más de estos componentes se pueden dividir en subcomponentes y/o consolidar en uno o más componentes. Los detalles relativos al funcionamiento de los componentes de aprovisionamiento y configuración ya se han descrito en referencia a la FIG. 9A.
El componente de monitoreo 1712 puede monitorizar la salud y el desempeño de los nodos de cómputo y/o hosts (por ejemplo, contenedores, máquinas virtuales, bare metals) corriendo en los nodos de cómputo. En algunas realizaciones, el componente de monitorización 1712 también puede monitorizar huéspedes (por ejemplo, aplicaciones ejecutándose en hosts), elementos de red físicos y virtuales (por ejemplo, routers, conmutadores), datos de logs, datos de eventos de logs y eventos locales (por ejemplo, protocolo simple de gestión de red o trampas SNMP, eventos OpenFlow), respuestas de excepción a protocolos tales como Ethernet IP y Modbus, estado de los motores de procesamiento (por ejemplo, atascado en un estado en una máquina de estado), uso del ancho de banda (demasiado alto puede indicar un dispositivo deshonesto) alojado en los nodos de cómputo. Por ejemplo, el componente de monitoreo 1712 puede recibir periódicamente latidos de agentes de monitoreo (no mostrados) en los nodos de cómputo y/u otros componentes de infraestructura. En algunos casos, el componente de monitoreo 1712 también puede recibir estadísticas de uso de recursos tales como información de uso de CPU y memoria en tiempo real por nodo de cómputo y/o por VM, contenedor o nodo bare metal. En algunas realizaciones, el componente de monitorización puede obtener datos relativos a los estados operativos de los anfitriones y/o huéspedes junto con las estadísticas de uso. Por ejemplo, para un PLC virtual, se pueden obtener estadísticas de uso asociadas a estados operativos tal como lógica de resolución, detención (es decir, no resolución), parada (error) y no configurado.
En algunas realizaciones, el componente de reporte de uso 1722 puede usar la información de monitoreo del componente de monitoreo 1712 para registrar el uso del servicio de virtualización y recursos. Por ejemplo, el componente de monitoreo 1712 puede detectar cuando una máquina virtual desplegada en un nodo de cómputo inicia y detiene la ejecución de una aplicación así como las estadísticas de uso de recursos para esa máquina virtual, y puede proporcionar las marcas de tiempo de inicio/parada y las estadísticas de uso de recursos relacionadas al componente de reporte de uso 1722. El componente de informe de uso 1722 puede agregar los datos de uso en base a uno o más criterios (por ejemplo, por aplicación, por cliente) y/o por período de informe. En algunas realizaciones, el componente 1722 puede aplicar una o más reglas de negocio para determinar el coste de uso de los recursos del sistema SDA. En algunas realizaciones, los datos de monitorización y/o los datos de uso agregados se pueden cargar periódicamente en una nube remota (por ejemplo, la nube 450 de la FIG. 4) para su posterior análisis, determinación de costes por el uso de los recursos del sistema SDA, asignación de costes a diferentes tipos de recursos del sistema SDA, y similares.
En algunas realizaciones, el componente de gestión del modo operativo 1724 puede gestionar los estados operativos de los nodos de cómputo, hosts (por ejemplo, máquinas virtuales, contenedores y bare metals) y/o huéspedes que se ejecutan en los hosts. Por ejemplo, considere un PLC virtual ejecutándose en un nodo de cómputo, el componente de administración de modo operativo 1724 puede solicitar al PLC virtual que inicie, detenga, pare, inicie, apague, reinicie, obtenga y establezca estado, y similares.
El componente de selección de nodo de cómputo 1714 puede seleccionar un nodo de cómputo para desplegar un huésped. El despliegue de un huésped en un nodo de cómputo incluye el despliegue de un host en forma de máquina virtual, contenedor o bare metal en el nodo de cómputo y el despliegue del huésped en el host. En algunas realizaciones, el despliegue de un huésped puede incluir el despliegue de un primer del host, el despliegue de un segundo del host en el primer del host y el despliegue del huésped en el segundo del host. Este tipo de despliegue se puede seleccionar en casos en los que el hardware del nodo de cómputo en su forma nativa no pueda satisfacer los requisitos del huésped. Por ejemplo, una aplicación que se ejecuta en el entorno Windows no se puede desplegar en un contenedor en un nodo de cómputo basado en Linux porque el contenedor depende del núcleo del nodo de cómputo. En este caso, primero habría que desplegar una máquina virtual, luego un contenedor sobre la máquina virtual y después la aplicación en el contenedor.
El componente de selección de nodo de cómputo 1714 puede ser activado por el componente de configuración 1708 en algunas realizaciones. El servidor de niebla incluye uno o más nodos de cómputo que pueden estar distribuidos físicamente y variar en capacidades. Por ejemplo, algunos nodos de cómputo pueden estar situados en una sala de control de una operación industrial y pueden incluir un multiprocesador Xeon o similar, con múltiples núcleos para proporcionar potencia de computación de gama alta. Del mismo modo, algunos otros nodos de cómputo pueden incluir un procesador Atom más pequeño de uno o múltiples núcleos o similar y otros pueden ser máquinas de gama alta basadas en procesadores ARM o similares ubicadas en una planta o cerca del entorno que controlan, por ejemplo. Se debe tener en cuenta que el hardware de los nodos de cómputo se puede llevar a cabo en forma de Pc , PC industrial, un módulo HMI, servidores, controladores especializados (por ejemplo, controladores industriales tales como el PLC M580 fabricado por Schneider Electric), dispositivos inteligentes conectados, y/o similares en diversas realizaciones. Algunos de los nodos de cómputo también pueden disponer de capacidades de red, tales como interconexión de redes de gama alta (por ejemplo, conmutador Ethernet de 1 GB o 10 GB) entre módulos del chasis y distribución de energía. Dadas estas variaciones en las capacidades y en cómo se pueden distribuir físicamente los nodos de cómputo, los enfoques existentes para seleccionar un nodo de cómputo para desplegar una máquina virtual, tal como la selección aleatoria, el round robín y el greedy simple, son muy ineficientes e ineficaces. Además, en el entorno de la automatización, las aplicaciones pueden tener requisitos sensibles al tiempo y críticos para la seguridad. Estas restricciones de la aplicación o del huésped hacen que el proceso de selección de un nodo de cómputo para la virtualización de una aplicación o máquina sea más complejo.
El componente de selección de nodo de cómputo 1714, en algunas realizaciones, puede usar una o más reglas que gobiernan los requerimientos de recursos de un huésped dado y/o host asociado con el huésped para seleccionar un nodo de cómputo para despliegue. Los ejemplos de las reglas que el componente de selección de nodo de cómputo 1714 puede aplicar incluyen, pero no se limitan a:
Si la tecnología de virtualización del host es una máquina virtual, entonces seleccione un nodo de cómputo con un procesador de gama alta (por ejemplo, procesador Xeon de múltiples núcleos).
Si la tecnología de virtualización del host es un contenedor, entonces seleccione un nodo de cómputo con un procesador de gama media (por ejemplo, procesador Atom de múltiples núcleos).
Si el huésped tiene un tamaño pequeño (por ejemplo, menos de 32 MB, entre 16 MB y 64 MB), entonces seleccione un nodo de cómputo bare metal.
Si el huésped tiene un requerimiento de procesamiento intensivo de computación, entonces seleccione un nodo de cómputo con un procesador de alta gama (por ejemplo, procesador Xeon de múltiples núcleos).
Si el huésped tiene un requerimiento de procesamiento y comunicación sensible al tiempo, entonces selecciona un nodo de cómputo que esté en proximidad a una máquina/proceso que el huésped controle.
Si el huésped tiene un requerimiento de procesamiento y comunicación sensible al tiempo, entonces selecciona un nodo de cómputo con capacidad de red sensible al tiempo.
Si el huésped tiene un requerimiento de procesamiento y comunicación sensible al tiempo, entonces selecciona un nodo de cómputo sin un vecino NUMA (acceso no uniforme a memoria).
Si el huésped está escrito para un tipo específico de tecnología de chip (por ejemplo, ARM, X86), sistema operativo (OS) (por ejemplo, Linux, Windows, VxWorks), versión de OS, y similares, entonces selecciona un nodo de cómputo que tenga tecnología de chip, OS y versión de OS compatibles.
Como se usa en la presente memoria, la determinación de proximidad se puede basar en una o más consideraciones. Por ejemplo, la proximidad se puede medir en términos de rendimiento y latencia cuando se trata del rendimiento de la red. La proximidad también se puede medir en distancia física cuando las preocupaciones incluyen la seguridad y el mantenimiento (por ejemplo, que no haya cables muy largos), las fuentes de alimentación comunes, el medio ambiente (por ejemplo, el entorno en el que funciona), la ciberseguridad, la seguridad física, el coste, el montaje (armarios) y similares. En algunos casos, la proximidad también se puede definir por zonas de seguridad.
En algunas realizaciones, las reglas pueden incluir reglas de afinidad y/o antiafinidad. Un ejemplo de regla de afinidad puede especificar que un host que ejecuta un huésped corra junto o coexista con otro host que ejecuta un huésped en el mismo nodo de cómputo. Esto puede permitir transferencias de datos muy rápidas entre los hosts/huéspedes, por ejemplo, a través del conmutador virtual interno de 10 GB del nodo de cómputo. Otro ejemplo de regla de afinidad puede especificar que un huésped siempre se ejecute en un nodo de cómputo específico. Otro ejemplo de regla de afinidad especifica que un huésped no se ejecute en el mismo nodo de cómputo que otro huésped. Esta regla se puede aplicar, por ejemplo, en los casos en que un huésped sea suplente del otro.
En algunas realizaciones, las reglas se pueden generar en base a heurística y/o datos históricos. Además, estas reglas se pueden actualizar y/o validar mediante el uso de patrones de datos históricos. Se debe tener en cuenta que una o más de estas reglas se pueden combinar (por ejemplo, mediante el uso de lógica tales como Y, O, y similares), usarse de forma aislada o usarse en cascada cuando se hace una selección de un nodo de cómputo. Mediante el uso de estas reglas, el componente de selección de nodo de cómputo 1714 asegura que un nodo de cómputo que es seleccionado satisface no sólo los requerimientos de recursos de tiempo de ejecución (por ejemplo, procesamiento y comunicación, almacenamiento, memoria, y similares) del huésped y el del host y también logra optimizaciones de desempeño (por ejemplo, retardo de red reducido, acceso de memoria más rápido).
En algunas realizaciones, la selección de un nodo de cómputo para desplegar un huésped se puede basar en un conjunto ordenado de parámetros operacionales. A modo de ejemplo, los parámetros operativos pueden incluir un nivel crítico de proceso, un nivel sensible al tiempo, un coste de ejecución, un nivel crítico de proximidad, rendimiento de costes y similares.
En algunas realizaciones, el nivel de criticidad del proceso puede depender del nivel de redundancia, de la necesidad de disponibilidad de la aplicación, de los requisitos de seguridad, de las opciones de fall back, y similares. Por ejemplo, si una planta industrial de procesamiento de acero que opera un horno en una acería no puede bajo ninguna circunstancia enfriarse, entonces la(s) aplicación(es) relacionada(s) con el mantenimiento del funcionamiento del horno se puede(n) considerar críticas para el proceso. En algunas realizaciones, el parámetro operativo de nivel sensible al tiempo puede depender de la precisión del tiempo de ejecución, la duración cuantificada del tiempo y similares. Entre los ejemplos de aplicaciones sensibles al tiempo se incluyen las aplicaciones de control de movimiento de alta velocidad (por ejemplo, cortadora de queso en línea de producción). En algunas realizaciones, el parámetro operativo de coste de ejecución puede depender de la cantidad de tiempo de procesamiento, consumo de recursos, demanda de capacidad de procesamiento y similares. En algunas realizaciones, el parámetro operativo de nivel crítico de proximidad se puede referir a la interdependencia entre dos o más huéspedes, o a la proximidad entre un huésped y un sensor/actuador que controla. En algunas realizaciones, el parámetro operativo de rendimiento de costes se puede basar en los gastos de capital, tales como el coste de los recursos, y en los gastos operativos, tales como la fiabilidad general del proceso.
En algunas realizaciones, el componente de selección de nodo de cómputo 1714 puede evaluar la relevancia de al menos algunos de los parámetros operacionales para el huésped para generar una lista ordenada o clasificada de parámetros operacionales. Basado en la lista ordenada de parámetros operacionales, el componente de selección de nodo de cómputo 1714 puede seleccionar un nodo de cómputo para desplegar el huésped.
El componente de detección de eventos 1726, en algunas realizaciones, puede detectar eventos 1718 que pueden ocurrir en el entorno virtual y/o físico del sistema SDA. La FIG. 18A representa algunos ejemplos de clases de eventos 1818 en el entorno virtual y/o físico que pueden ser detectados por el componente de detección de eventos 1726. Con referencia a la FIG. 18A, algunos ejemplos de clases de eventos 1818 incluyen, pero no se limitan a: eventos de seguridad cibernética 1818A, eventos de fallo de nodo de cómputo 1818B, eventos de diagnóstico 1818C, eventos de mantenimiento 1818D, evento de actualización 1818E, eventos de mejora de planta 1818F, eventos de fallo de energía 1818G, eventos de reporte 1818H, eventos de proceso 1818I, eventos de red 1818J, y similares. Cada uno de estos eventos puede ser detectado por el componente de detección de eventos 1726 basado en la información de monitoreo del componente de monitoreo 1712 en algunas realizaciones. Cabe señalar que el componente de detección de eventos 1726, en algunas realizaciones, puede comprender uno o más subcomponentes de detección de eventos para detectar diferentes clases de eventos. En algunas realizaciones, cada uno de estos eventos puede ser manejado o gestionado por un manejador de eventos 1720. Cabe señalar que uno o más manejadores de eventos 1720 pueden existir para manejar diversas clases de eventos. También se debe tener en cuenta que, en algunas realizaciones, el componente o componentes de detección de eventos y el controlador o controladores de eventos se pueden distribuir entre el controlador del servidor de niebla, el controlador de red y el controlador de ciberseguridad, dependiendo de qué controlador dirija la respuesta de gestión de eventos. Con referencia a la FIG. 18B, algunos ejemplos de manejadores de eventos 1820 incluyen pero no se limitan a: un manejador de eventos de ciberseguridad 1820A, un manejador de eventos de fallo de nodo de cómputo 1820B, un manejador de eventos de diagnóstico 1820C, un manejador de eventos de mantenimiento 1820D, un manejador de eventos de actualización 1820E, un manejador de eventos de mejora de planta 1820F, un manejador de eventos de fallo de energía 1820G, un manejador de eventos de reporte 1820H, un manejador de eventos de proceso 1820I, un manejador de eventos de red 1820J, y similares.
Por ejemplo, eventos de seguridad cibernética 1818A pueden ocurrir cuando hay un intento de obtener acceso no autorizado a un sistema de automatización (por ejemplo, nodos de cómputo), interrumpir procesos, deshabilitar sistemas de monitoreo de seguridad y en general causar daño. Los ataques de ciberseguridad pueden tener múltiples puntos de entrada, incluso a través de elementos de red tales como routers y cortafuegos. Algunos ejemplos de estos eventos de ciberseguridad, más a menudo deliberados que accidentales, incluyen hackeos externos, virus/gusanos/malware y ataques de denegación de servicio (DoS), por nombrar algunos. En algunas realizaciones, los componentes que se han visto afectados por eventos de ciberseguridad pueden generar una entrada de registro que documente dichas actividades. En algunas realizaciones, los sistemas de protección de seguridad pueden monitorizar el tráfico de red en comparación con una base de datos de vulnerabilidades conocidas para detectar tráfico sospechoso y generar una alarma. Un componente de detección de eventos de ciberseguridad del controlador CS (por ejemplo, el controlador CS 655 en la FIG 6B) puede analizar estas actividades colectivamente para detectar un evento de ciberseguridad 1818A.
En respuesta a la detección de un evento de ciberseguridad 1818A, un manejador de eventos de ciberseguridad 1820A del controlador CS puede iniciar o proveer una respuesta. La respuesta puede variar dependiendo de varios aspectos del evento de ciberseguridad 1818A que incluyen el tipo y severidad del evento de ciberseguridad y los componentes o sistemas de control impactados por ejemplo. Para los eventos de ciberseguridad basados en la red, la respuesta puede incluir la partición de la red para aislar la porción afectada de la red para mitigar el impacto del evento. En el caso de ataques basados en dispositivos, la respuesta puede incluir el cierre de puertos y enlaces de comunicación e incluso la desconexión del dispositivo afectado. Del mismo modo, una respuesta a un intento no autorizado de cambiar un programa de control en un dispositivo puede incluir poner al usuario en una lista negra para evitar que acceda a otros dispositivos, bloquear el tráfico hacia/desde el dispositivo potencialmente comprometido, así como cambiar a un dispositivo de espera virtual (es decir, un dispositivo de espera en el entorno virtual) de forma que los procesos puedan funcionar sin interrupción.
Estas respuestas son típicamente coordinadas entre los componentes de orquestación como se muestra en la FIG.
19. Con referencia a la FIG. 19, en algunas realizaciones, un componente de detección de eventos CS 1942 del controlador CS 1955 puede generar una alarma asociada con un evento de ciberseguridad y proporcionar una descripción de evento de ciberseguridad 1928A que incluyen detalles del evento al componente de orquestación SDA 1916. La descripción del evento de ciberseguridad 1928A puede incluir detalles tales como, pero no limitados a: tipo de incidente o ataque (por ejemplo, ataque de virus), punto de entrada (por ejemplo, router, firewall), componentes impactados (por ejemplo, nodo de cómputo con dirección IP/MAC), y similares. En algunas realizaciones, el componente de orquestación CS 1155 puede determinar las medidas de respuesta (o respuesta a eventos de ciberseguridad 1928B) necesarias para mitigar el evento de ciberseguridad y proporcionar medidas de respuesta de red relevantes 1930 (por ejemplo, relacionadas con elementos de red) al componente de orquestación de red 1922 y medidas de respuesta de dispositivo relevantes (por ejemplo, físicas o virtuales) al componente de orquestación del servidor de niebla 1910 para implementarlas en sus respectivos dominios de control (es decir, nodos de cómputo e instancias virtualizadas 1904 para el controlador del servidor de niebla 1910, y redes virtuales 1920 y elementos de red 1906 para el controlador de red 1990). Por ejemplo, el componente de orquestación del servidor de niebla puede, como respuesta de ciberseguridad, hacer que el controlador del servidor de niebla desconecte un dispositivo afectado y reinicie la aplicación que se ejecuta en el dispositivo en otro nodo de cómputo. Del mismo modo, el componente de orquestación de red puede hacer que el controlador de red apague el enrutador afectado y/o los puertos de conmutación de forma que el tráfico pueda evitar el enrutador afectado y/o los puertos de conmutación cuando fluya a través de la red. En realizaciones alternativas, una respuesta de evento de ciberseguridad 1928B que incluyen la respuesta de dispositivo y/o red puede ser proporcionada al componente de orquestación SDA 1916. El componente de orquestación SDA 1916 puede entonces analizar la respuesta de ciberseguridad 1928B y proporcionar la respuesta de dispositivo de ciberseguridad 1932B al componente de orquestación de niebla 1924 y/o la respuesta de red de ciberseguridad 1930 al componente de orquestación de red 1922. En algunas realizaciones, el componente de orquestación SDA 1916 también puede proporcionar la descripción del evento de ciberseguridad 1932A al componente de orquestación de niebla 1924, que a su vez puede hacer que el controlador del servidor de niebla (por ejemplo, a través del componente de detección de eventos 1726 u otro módulo de alarma) envíe una alarma de evento de ciberseguridad 1916 a un dispositivo de cliente 1940 para notificar a un usuario el evento de ciberseguridad y la respuesta.
Otra clase de eventos es el evento de fallo de nodo de cómputo (por ejemplo, el evento de fallo de nodo de cómputo 1818B representado en la FIG. 18A). Este tipo de evento se puede desencadenar cuando un nodo de cómputo fallo debido a una variedad de razones, tales como fallo de alimentación, fallo del OS del host, corrupción de memoria, fallo de disco, fallo de la red de gestión/datos, y similares. Un componente de detección de eventos 1726 puede detectar un evento de fallo de nodo de cómputo basado en una alerta del componente de monitoreo 1712, por ejemplo. El componente de monitorización puede generar una alerta cuando no recibe latidos a los intervalos esperados desde el nodo de cómputo. La ausencia de latidos puede indicar una pérdida de comunicación debida a un fallo de la red o del propio nodo de cómputo. En algunas realizaciones, la información suplementaria, tal como el estado de error de un mensaje de registro o mensaje de error, se puede usar para detectar el evento de fallo del nodo de cómputo.
Un manejador de eventos de fallo de nodo de cómputo (por ejemplo, el componente 1820B en la FIG. 18B) puede proporcionar una respuesta a un evento de fallo de nodo de cómputo 1818B para mitigar el impacto del nodo de cómputo fallado en el sistema SDA. La respuesta puede ser una respuesta coordinada entre al menos dos de los subsistemas SDA. Un ejemplo de una respuesta coordinada del sistema SDA a un evento de fallo de nodo de cómputo es representado en la FIG. 20. Con referencia a la FIG. 20, un nodo de cómputo (por ejemplo, que ejecuta una aplicación PLC) que es uno de los múltiples nodos de cómputo monitorizados por el controlador del servidor de niebla 2010 (por ejemplo, a través del componente de monitorización 1712 de la FIG. 17). El controlador del servidor de niebla 2010 recibe los datos de monitorización 2014. Como se ha descrito anteriormente, los datos de monitorización 2014 pueden incluir mensajes heartbeat, estadísticas de uso de recursos tales como uso de CPU y memoria en tiempo real por nodo de cómputo y/o por VM o contenedor que pueden proporcionar información sobre la salud del nodo de cómputo. El controlador del servidor de niebla 2010 (por ejemplo, a través del componente de monitorización) puede analizar los datos de monitorización 2014 y generar una alarma cuando determine que el nodo de cómputo o el host en el nodo de cómputo ha fallado. Un componente de detección de eventos del controlador del servidor de niebla 2010 (por ejemplo, el componente de detección de eventos 1726 en la FIG. 17) puede detectar la alarma que indica un fallo del nodo de cómputo. En algunas realizaciones, la alarma 2016 se puede transmitir a un dispositivo de cliente 2040 para notificar a un usuario (por ejemplo, el operador de la planta). El usuario puede entonces instruir al sistema SDA, directamente desde el dispositivo de cliente 2040 u otra interfaz (por ejemplo, software del sistema), para manejar el evento. El controlador del servidor de niebla (por ejemplo, a través del controlador de eventos 1720 de la FIG. 17) puede recibir las instrucciones 2018 para manejar el evento y, en respuesta, recuperar información 2022 sobre una aplicación (es decir, huésped) que se estaba ejecutando en un host en el nodo de cómputo que falló desde un nodo de almacenamiento 2025. Los ejemplos de información recuperada del nodo de almacenamiento pueden incluir, pero no se limitan a: lógica de aplicación y datos de estado. Estos datos pueden permitir que la aplicación se inicie desde el último estado sincronizado, en lugar de reiniciarse por completo. En algunas realizaciones, el controlador del servidor de niebla 2010 puede crear un host 2004 para ejecutar el huésped 2005 que se estaba ejecutando en el nodo de cómputo 2002A que ha fallado. El controlador del servidor de niebla 2010 también puede crear la(s) red(es) virtual(es) 2020 necesaria(s) y conectar el host 2004 configurado con el huésped 2005 a la(s) red(es) virtual(es) 2020. El controlador del servidor de niebla 2010 puede entonces seleccionar un nodo de cómputo 2002B (por ejemplo, a través del componente de selección de nodo de cómputo 1714) en el que se despliega el host 2004.
Una vez que el huésped 2004 es desplegado en el nodo de cómputo que cumple con los requerimientos de optimización de recursos y/o rendimiento del huésped 2005 corriendo en el host 2004, el controlador del servidor de niebla 2010 puede proveer descripción de virtualización 2024 que incluyen información acerca del host 2004 y redes virtuales asociadas al componente de orquestación SDA 2016 en algunas realizaciones. La descripción de virtualización 2024 puede incluir información tal como, pero no limitada a: flujos de comunicación y flujos de red asociados con el host 2004 y las redes asociadas. El componente de orquestación SDA 2016 puede analizar la descripción de virtualización para extraer los flujos de comunicación 2026 y los flujos de red 2030A y reenviarlos al componente de orquestación CS 2018 y al componente de orquestación de red 2022 respectivamente. El componente de orquestación CS 2018 puede entonces hacer que el controlador CS 2055 recupere las políticas de seguridad 2028 para el flujo de comunicación solicitado 2026 y reenvíe esas políticas de seguridad al componente de orquestación del sistema 2016. De forma similar, el componente de orquestación de red 2022 puede hacer que el controlador de red 2090 use la descripción de flujo de red 2030A y las políticas de seguridad 2030B para configurar los elementos de red físicos y/o virtuales 2006. Además, las políticas de seguridad 2032 también se pueden reenviar al controlador del servidor de niebla 2010 para distribuirlas al host 2004.
Una de las ventajas de tener un subsistema CS que incluya un controlador CS es que las asociaciones entre un dispositivo y su ciberseguridad se mantienen hasta que dichas asociaciones se rompen deliberadamente. En otras palabras, la ciberseguridad sigue al dispositivo allá donde se despliegue. Al igual que la red se reconfigura como parte de la respuesta a un evento, lo mismo ocurre con la ciberseguridad. En el ejemplo de la FIG. 20, el nodo de cómputo 2002A puede ser un PLC que ejecuta una aplicación PLC y una política de seguridad asociada con el PLC requiere un cortafuegos delante de él. Cuando la aplicación PLC se despliega en un host 2004 en un nodo de cómputo 2002B, el controlador del servidor de niebla crea automáticamente un cortafuegos virtual frente al host 2004 que ejecuta la aplicación PLC, dado que la política de seguridad asociada a la función lógica (es decir, la aplicación PLC) persiste incluso cuando la función lógica se desplaza de un host a otro o de un nodo de cómputo a otro.
Una vez que el huésped y el host son desplegados en el nuevo nodo de cómputo 2002B es configurado con la aplicación, y las configuraciones de red y seguridad son realizadas, el tráfico de salida de la aplicación desde el host 2004 puede fluir a través de las redes virtuales 2020, a través de los elementos de red virtuales y/o físicos 2006, hacia una E/S distribuida 2008 y luego hacia un equipo 2012 (por ejemplo, un actuador) en este ejemplo. Del mismo modo, se permite el tráfico entrante desde el equipo 2012 que controla el host 2004 a través de los elementos de red 2006 hasta el host 2004.
Mientras el host 2004 en el nodo de cómputo 2002B está en operación, el nodo de cómputo 2002A que falló se puede reparar o reemplazar. Por ejemplo, si el nodo de cómputo 2002A es un dispositivo PLC físico, entonces mientras su aplicación y procesos están corriendo en el host 2004 en el nodo de cómputo 2002B, el dispositivo PLC puede ser reparado o reemplazado. En algunas realizaciones, el dispositivo PLC 2002A sólo necesita encenderse para que su aplicación y procesos se desplacen desde el nodo de cómputo 2002B de vuelta al dispositivo PLC 2002A. En otras palabras, el dispositivo PLC 2002A volvería a ser el encargado de controlar el equipo 2012. Para completar la transferencia de control, los subsistemas SDA se coordinan entre ellos para reconfigurar o remediar la red (por ejemplo, a través del controlador de red 2090) y/o los entornos de seguridad (por ejemplo, a través del controlador c S 2055) para redirigir los flujos de vuelta al nodo de cómputo 2002A. Este cambio de control significa que el host 2004 puede ser apagado por el controlador del servidor de niebla 2010, para de ese modo liberar los recursos.
En algunas realizaciones, un host puede ser un dispositivo de reserva para un dispositivo activo, es decir, en una proporción de 1 a 1 o para múltiples dispositivos, en una proporción de N a 1 en un sistema de reserva caliente/caliente. Cuando un dispositivo falla, un equipo de mantenimiento tiene que diagnosticarlo, identificarlo y reiniciarlo lo antes posible. En una planta convencional, las tareas de diagnóstico y reparación pueden resultar difíciles y llevar mucho tiempo, además de provocar tiempos de inactividad. Con una reserva virtual, los recursos virtuales están disponibles de inmediato para hacerse cargo de cualquier proceso de aplicación, al reducir o eliminar el tiempo de inactividad y permitir que el sistema funcione sin apenas problemas ni retrasos. En el ejemplo de la FIG.
20, el host 2004 en el nodo de cómputo 2002B puede ser un standby virtual para el nodo de cómputo 2002A fallido (por ejemplo, un dispositivo PLC).
En algunas realizaciones, para reducir los costes de hardware y energía de tener sistemas de reserva en una proporción de N a 1, se puede configurar una infraestructura elástica de sistemas de reserva virtualizados. Si un dispositivo falla o se produce un error, un host de un conjunto se puede hacer cargo de los procesos del dispositivo que ha fallado, asumiendo todas las responsabilidades y funciones. En algunas realizaciones, un dispositivo de reserva para uno o más dispositivos se puede seleccionar de un grupo activo de hosts de diferentes tipos (máquinas virtuales, contenedores y bare metals) y sabores (por ejemplo, capacidades, SO, versiones de SO, tamaño de memoria, etc.) en base a uno o más criterios. El conjunto de hosts puede ser genérico, hosts no configurados en algunas realizaciones de forma que sólo la lógica de la aplicación y los datos de estado deben ser transferidos en el momento de la activación de espera.
En algunas realizaciones, los datos de estado en tiempo real de una aplicación o proceso pueden ser mantenidos en el nodo de almacenamiento 2025. Cuando se pone en marcha un dispositivo virtual en espera, los datos de estado de un proceso de aplicación que se estaba ejecutando previamente en un dispositivo se pueden recuperar de este nodo de almacenamiento y transferir al dispositivo virtual en espera de forma que el estado del dispositivo virtual en espera se corresponda con el estado del dispositivo al que está sustituyendo temporalmente, lo que permite al dispositivo secundario o en espera asumir rápidamente el papel del dispositivo primario o averiado.
Cabe señalar que la transferencia de control de un nodo de cómputo a otro o de un dispositivo físico a un host como se describe anteriormente se produce de una manera fluida. Consideremos el ejemplo de una línea de producción de lonchas de queso para producir lonchas de queso suizo con un peso determinado. En un sistema de este tipo, una cuchilla giratoria que se mueve a gran velocidad corta un bloque de queso suizo al empujarlo hacia la cuchilla a una velocidad que se ajusta en función de los orificios del queso. Coordinar el movimiento rápido de la cuchilla con el movimiento del bloque de queso es una cuestión de tiempo. De este modo, cualquier retraso en la transferencia del control del proceso de loncheado de queso de un nodo de cómputo a otro puede afectar negativamente al proceso (por ejemplo, producir lonchas de queso de pesos no uniformes). En vista de estos problemas, de acuerdo con algunas realizaciones, la transferencia de control de un nodo de cómputo a otro puede ocurrir a través de una transferencia sin baches que respete la sensibilidad temporal de los procesos de aplicación. Por ejemplo, una transferencia sin baches para un sistema de control de movimiento de alta velocidad, tal como el sistema de corte de queso, se puede producir en menos de 1 ms, lo que puede dar lugar a una transición sin fisuras de un dispositivo físico a uno virtual.
En algunas realizaciones, una transferencia sin baches se habilita por medio de la clonación de un host. Un sistema SDA puede permitir dos o más copias exactas de un host en una red. Estas copias o clones pueden tener la misma dirección IP, dirección MAC, número de serie, configuración y similares, y ejecutar las mismas aplicaciones. En algunas realizaciones, los clones también pueden sincronizar estados entre sí para garantizar que son exactamente iguales en todos los aspectos en cualquier momento. En algunas realizaciones, el controlador SDN puede dirigir/bloquear flujos en base a cualquier número de criterios. Uno de estos criterios se basa en el productor de tráfico de datos. Por ejemplo, el controlador de red (por ejemplo, SDN, TSN) permite que todos los clones reciban entradas de la red, pero sólo permite que la salida de un clon seleccionado se propague a través de la red. En algunas realizaciones, la salida de todos los clones se puede duplicar a un nodo o nodos de validación para su comparación y validación. El clon exacto de un componente, ya sea virtual o físico, existente en la misma red proporciona redundancia, con el controlador de red (por ejemplo, controlador SDN y/o controlador TSN) dirigiendo el tráfico entrante a todos los clones pero permitiendo sólo el tráfico saliente de uno. La transferencia de control es entonces una cuestión de cambiar qué componente permitir propagar la salida para facilitar el cambio instantáneo de un nodo a otro (en espera).
En algunas realizaciones, la técnica de clonación se puede extender a múltiples clones con un esquema de votación implementado por un componente (por ejemplo, en el controlador del servidor de niebla 910 de la FIG. 9A). El componente puede comparar las múltiples salidas y aceptar el valor obtenido por medio de consenso. La técnica de clonación también permite la actualización validada de un dispositivo en el que la salida del dispositivo actualizado se valida durante un período de prueba antes de que se le permita participar en el sistema de automatización. La técnica de clonación también permite promediar múltiples procesos de cálculo para tener en cuenta el error estocástico en el cálculo. En algunas formas de realización, los clones también se pueden configurar como “tarro de miel” de seguridad donde los dispositivos expuestos se sacrifican a los ciberatacantes.
Con referencia a las FIGs. 17 y 18, un evento de diagnóstico 1818C, en algunas realizaciones, puede ser asociado con cualquier componente del sistema SDA que incluyen, por ejemplo, nodos de cómputo, componentes de red (por ejemplo, conmutadores), y similares. Un evento de diagnóstico se suele activar cuando se cumple una condición predefinida. Por ejemplo, cuando un equipo ha alcanzado su tiempo límite de funcionamiento continuo, cuando un equipo no alcanza una posición determinada a tiempo o cuando el retardo de la red supera un tiempo determinado. En algunas realizaciones, un evento de diagnóstico puede ser activado por una señal externa. Por ejemplo, un motor de análisis que se ejecuta en una nube (por ejemplo, la nube 450 en la FIG. 4) que puedan recopilar datos, incluidos datos de seguimiento sobre el terreno, y convertirlos en información procesable, tal como información de diagnóstico en tiempo real. Un motor de este tipo puede generar una señal cuando los datos de diagnóstico indican un posible problema. Un componente de detección de eventos de diagnóstico (por ejemplo, el componente de detección de eventos 1726 en la FIG. 17) puede detectar el evento de diagnóstico y, en respuesta, un controlador de eventos de diagnóstico (por ejemplo, el componente 1820C de la FIG. 18B) puede programar o llevar a cabo una comprobación de diagnóstico del componente que activó el evento de diagnóstico. En algunas realizaciones, el gestor de eventos de diagnóstico se puede coordinar con los componentes de orquestación para facilitar la comprobación de diagnóstico del componente. Por ejemplo, si un conmutador de red tiene un evento de diagnóstico, el controlador de eventos de diagnóstico puede solicitar al controlador de red (por ejemplo, a través del componente de orquestación de red 1922 de la FIG. 19 y/o el componente de orquestación del sistema 1916 de la FIG. 19) para redirigir los flujos de red fuera de ese conmutador de red mientras se llevan a cabo comprobaciones de diagnóstico en él. En algunas realizaciones, un evento de diagnóstico puede desencadenar otro evento, tal como un evento de mantenimiento o un evento de actualización.
Otro tipo de evento que el componente de detección de eventos 1726 puede detectar es un evento de mantenimiento 1818D. Un evento de mantenimiento puede ser programado con antelación, iniciado bajo demanda por un usuario para inspeccionar y/o reparar uno o más nodos de cómputo o en respuesta a otros eventos tales como eventos de diagnóstico. A la hora programada o en respuesta a una petición del usuario, se puede activar un evento de mantenimiento y ser detectado por el componente de detección de eventos. En respuesta al evento, un manejador de eventos de mantenimiento 1820 puede ser invocado. El controlador de eventos de mantenimiento puede usar el componente de orquestación del servidor de niebla para cambiar los procesos de aplicación de un nodo de cómputo programado para someterse a mantenimiento a otro nodo de cómputo (por ejemplo, máquinas virtuales, contenedores o bare metals). El gestor de eventos de mantenimiento también puede, a través del componente de orquestación de red y el componente de orquestación CS, remediar o reconfigurar la red y los entornos de seguridad para permitir que las funciones de aplicación virtualizadas controlen una máquina o proceso. En algunas realizaciones, un ejemplo de respuesta a un evento de mantenimiento puede ser similar a una respuesta a un evento de fallo de nodo de cómputo descrito en referencia a la FIG. 20.
Otro tipo de evento en el entorno físico y/o virtual es un evento de actualización. Al igual que los eventos de mantenimiento, los eventos de actualización también se pueden programar con antelación o iniciarse a petición de un usuario para actualizar el hardware, el firmware y/o el software. En el caso de las actualizaciones, el hardware, el firmware y/o el software pueden estar plenamente operativos, pero puede ser necesario actualizarlos en respuesta a ciberamenazas, al descubrimiento de posibles defectos, a la disponibilidad de nuevas funciones, etc.
El evento de mejora de planta 1818F puede ser disparado cuando una parte de una planta va a ser mejorada. Este evento se puede programar con antelación o, en algunos casos, activarse a petición. En respuesta a la detección de este evento a través del componente detector de eventos 1716, un manejador de eventos de mejora de la planta 1820F puede hacer que la parte de la planta que se va a mejorar se traslade al entorno de virtualización del servidor de niebla, donde los sistemas de control asociados se pueden ejecutar en máquinas virtuales y/o contenedores. El gestor de mejora de la planta 1820F también puede indicar a los componentes de orquestación que trabajen juntos para reconfigurar o remediar el entorno de red y el entorno de seguridad, y poner la parte de la planta fuera de línea. Un evento de fallo de alimentación 1818G se puede activar cuando se corta el suministro eléctrico a un sistema de automatización. En respuesta a un evento de este tipo, se suele usar un sistema de alimentación de reserva, tal como un sistema de alimentación ininterrumpida (SAI), para proporcionar un suministro de energía limpio e ininterrumpido que mantenga el sistema plenamente operativo durante algún tiempo. El tiempo que el sistema se puede mantener operativo dependerá del tamaño de la batería del SAI. En algunas realizaciones, el componente de monitorización 1712 puede monitorizar el sistema y detectar el evento de fallo de alimentación. En algunas realizaciones, el gestor de eventos de fallo de alimentación 1820F puede determinar o calcular el tiempo que el sistema puede permanecer operativo en base a los requisitos de alimentación del sistema y en la capacidad del sistema SAI. El manejador de eventos de fallo de energía 1820F puede entonces, basado en el tiempo operacional restante, iniciar el cierre de procesos y nodos de cómputo comenzando con los no críticos de forma que los críticos puedan correr por más tiempo y puedan continuar corriendo hasta que la energía sea restaurada.
Un evento de reporte 1818H puede ser disparado por un usuario, o automáticamente basado en condiciones predefinidas tales como cuando un evento de seguridad ocurre o cuando un evento de seguridad es manejado. Un gestor de eventos de informe 1820H puede gestionar un evento de informe por medio de la recopilación de datos relevantes y la generación de un informe basado en los datos. Dicho informe podría incluir información tal como el ID del evento, el tipo de evento, el componente o componentes que desencadenaron el evento, la acción o acciones tomadas para mediar en el evento, etc. Otro ejemplo de informe que se puede generar en respuesta a un evento de notificación puede ser un informe que incluya una lista de eventos de un determinado tipo. Por ejemplo, un informe que enumere todos los incidentes de ciberseguridad ocurridos en un mes en el sistema.
Un evento de proceso 1818I es un tipo de evento desencadenado por los procesos que se ejecutan en los nodos de cómputo. Un evento de proceso se puede generar cuando una variable o medida del proceso se sale de los límites o cuando salta una alarma que indica que el proceso es anormal. En algunas realizaciones, un manejador de eventos de proceso 1820H puede manejar un evento de proceso, por ejemplo, por medio del desplazamiento del componente huésped de un nodo de cómputo a otro, o de un host a otro en el mismo nodo de cómputo u otro, por medio del cambio del tipo de proceso (por ejemplo, de procesamiento en tiempo real a procesamiento por lotes), por medio de la realización de una gestión de energía (por ejemplo, por medio de la consolidación del procesamiento en unos pocos nodos de cómputo para ahorrar energía), y similares. La respuesta del gestor de procesos 1820I puede de ese modo incluir la reconfiguración de los anfitriones y/o huéspedes, lo que puede desencadenar la reconfiguración del entorno de ciberseguridad y del entorno de red.
Otra clase de eventos que ocurren en el entorno virtual y/o físico es un evento de red 1818J. Los ejemplos de eventos de red pueden incluir, pero no se limitan a: pérdida de conectividad (por ejemplo, fallo del punto de conexión, fallo del equipo de infraestructura) en el entorno virtual y físico, detección de congestión, reconfiguración de ruta, y similares. Estos tipos de eventos de red pueden ser detectados por un componente de detección de eventos (por ejemplo, el componente 1726 de la FIG. 17) y manejado por un manejador de eventos de red (por ejemplo, manejador de eventos de red 1820J). El gestor de eventos de red, al detectar un evento de red que indica un fallo de red de cualquier tipo, puede redirigir instantáneamente el tráfico a través de otra ruta de red como respuesta al evento.
9. Ejemplos de metodologías para gestionar un sistema SDA
La FIG. 21A es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo de selección de un recurso de cómputo para desplegar una instancia/componente virtualizado de acuerdo con algunas realizaciones. En el bloque 2102, un componente de selección de nodo de cómputo (por ejemplo, el componente de selección de nodo de cómputo 1714 del sistema de gestión de host 1716 de la FIG. 17) puede identificar los recursos de cómputo que están disponibles para recibir potencialmente el despliegue de un componente virtualizado. En algunas realizaciones, un recurso de cómputo puede ser una máquina servidor, un ordenador personal, un hardware integrado, un módulo de interfaz hombre-máquina (HMI) o un controlador industrial. En algunas implementaciones, los recursos de cómputo disponibles pueden incluir al menos una máquina en una sala de control y al menos una máquina en una planta. Los recursos de cómputo disponibles no tienen por qué estar físicamente centralizados, sino que pueden estar físicamente distribuidos pero monitorizados por el controlador del servidor de niebla.
En el bloque 2104, el componente de selección de nodo de cómputo puede seleccionar, basado al menos en parte en cualquier requerimiento de comunicación y procesamiento sensible al tiempo del componente virtualizado en tiempo de ejecución, recursos de cómputo candidatos de los recursos de cómputo disponibles. En algunas realizaciones, los recursos de computación candidatos que se seleccionan en base a los requisitos de procesamiento y comunicación sensibles al tiempo del componente virtualizado pueden estar en proximidad física a un proceso o máquina (por ejemplo, en la planta de la planta) que el componente virtualizado controla.
En el bloque 2106, el componente de selección de nodo de cómputo puede seleccionar un recurso de cómputo de los recursos de cómputo candidatos basado en un conjunto de reglas que gobiernan los requerimientos de recursos del componente virtualizado. En algunas realizaciones, la selección puede tener en cuenta tanto el componente (es decir, el componente lógico o la imagen del componente) como la tecnología de virtualización asociada al componente. En algunas realizaciones, el conjunto de reglas que define los requisitos de recursos del componente virtualizado incluye al menos una regla de afinidad que rige la coexistencia de dos o más dispositivos virtualizados o aplicaciones en el mismo recurso de cómputo. Otros ejemplos de reglas pueden incluir una regla que gobierne el tipo de recursos computacionales adecuados para una tecnología de virtualización asociada con un componente y una regla que gobierne la capacidad de red requerida para dispositivos o aplicaciones con necesidades de procesamiento y comunicación sensibles al tiempo.
En el bloque 2108, el controlador del servidor de niebla puede desplegar el componente virtualizado en el recurso de cómputo seleccionado. En algunas realizaciones, el despliegue del componente virtualizado en el recurso de cómputo seleccionado puede ser en respuesta a un evento tal como un evento de fallo o un evento de mantenimiento o una solicitud para aprovisionar el componente virtualizado en un recurso de cómputo. El evento de fallo se puede desencadenar por el fallo de un recurso de cómputo en el que se haya desplegado el componente virtualizado.
La FIG. 21B es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo de selección de un recurso de cómputo para el despliegue de un huésped (por ejemplo, aplicación, imagen) de acuerdo con algunas realizaciones. El procedimiento de ejemplo puede ser realizado por un componente de selección de nodo de cómputo (por ejemplo, el componente de selección de nodo de cómputo 1714 del sistema de gestión de host 1716 de la FIG. 17). El procedimiento incluye la identificación, por el componente de selección de nodo de cómputo, de recursos de cómputo en un sistema de automatización que están disponibles para recibir potencialmente el despliegue de un huésped en el bloque 2110. En algunas realizaciones, los recursos de cómputo disponibles pueden estar físicamente distribuidos pero monitorizados por un controlador del sistema de automatización. Los ejemplos no limitativos de recursos de cómputo incluyen una máquina servidor, un ordenador personal, un dispositivo inteligente conectado, un módulo de interfaz hombre-máquina (HMI), un controlador industrial, y similares.
En el bloque 2112, el componente de selección de nodo de cómputo puede evaluar las restricciones del huésped contra un conjunto de parámetros operacionales para seleccionar un tipo de host para el huésped. En algunas realizaciones, los parámetros operativos pueden incluir uno o más de un nivel crítico de proceso, un nivel sensible al tiempo, un coste de ejecución, un nivel crítico de proximidad, rendimiento de costes y similares. En base a la evaluación, el componente de selección de nodo de cómputo puede seleccionar un tipo de host para el huésped en el bloque 2114. En algunas realizaciones, el tipo de coste puede ser una máquina virtual, un contenedor o un bare metal. En el bloque 2116, el componente de selección de nodo de cómputo puede seleccionar, en base al tipo de host seleccionado, la evaluación y los atributos de los recursos de cómputo disponibles, un recurso de cómputo para el huésped. Algunos ejemplos no limitativos de atributos de los recursos de cómputo incluyen la potencia de procesamiento, el tamaño de la memoria, la tecnología del chip del procesador, el sistema operativo, el nivel de uso de la CPU, el número de vecinos NUMA y similares.
En el bloque 2118, el componente de selección de nodo de cómputo puede desplegar un host del tipo seleccionado que está configurado con el huésped en el recurso de cómputo seleccionado. En algunas realizaciones, el despliegue del host configurado con el huésped en el recurso de cómputo seleccionado puede ser en respuesta a un evento de fallo, un evento de mantenimiento, un evento de proceso o una solicitud para aprovisionar al huésped en un recurso de cómputo. El evento de fallo se puede desencadenar, por ejemplo, por el fallo de un recurso de cómputo en el que se haya desplegado previamente el huésped. El evento de proceso puede ser desencadenado por una variable de proceso que se ejecuta fuera de los límites, por ejemplo.
La FIG. 22 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la gestión de un sistema SDA de acuerdo con una primera realización. El procedimiento de ejemplo incluye la monitorización por parte de un componente de monitorización (por ejemplo, el componente de monitorización 1712 de la FIG. 17) múltiples nodos de cómputo del sistema de automatización en el bloque 2202. En algunas realizaciones, al menos algunos de los múltiples nodos de cómputo alojan componentes de virtualización (por ejemplo, máquinas virtuales, contenedores, bare metals) en los que se ejecutan funciones de aplicación.
En el bloque 2204, un componente de detección de eventos (por ejemplo, el componente de detección par en FIG 17) un evento asociado con un primer nodo de cómputo de los múltiples nodos de cómputo que están siendo monitorizados puede ser detectado (por ejemplo, a través del componente de detección de eventos 1726 en la FIG.
17). En algunas realizaciones, el primer nodo de cómputo puede ser un dispositivo de automatización industrial que ejecuta una o más funciones de aplicación y el segundo nodo de cómputo puede ser una máquina que aloja al menos un componente de virtualización en el que son ejecutables una o más funciones de aplicación. En varias realizaciones, el evento asociado con el primer nodo de cómputo que está siendo monitorizado puede incluir un evento de fallo de nodo de cómputo, un evento de mantenimiento o un evento de actualización.
En el bloque 2206, un componente de gestión de eventos (por ejemplo, el componente de gestión de eventos 1720 de la FIG. 17) pueden responder al evento. La respuesta al evento puede ser en respuesta a la aprobación del usuario o automática, sin intervención del usuario. Por ejemplo, el componente de gestión de eventos puede seleccionar un segundo nodo de cómputo de los múltiples nodos de cómputo para asumir la ejecución de una o más funciones de aplicación del primer nodo de cómputo. En algunas realizaciones, la toma de control de la ejecución de una o más funciones de la aplicación se lleva a cabo a través de una transferencia sin baches. La transferencia sin baches puede ser facilitada por el segundo nodo de cómputo que es un clon del primer nodo de cómputo.
El componente de manejo de eventos puede configurar el segundo nodo de cómputo para ejecutar una o más funciones de aplicación en el bloque 2208 y configurar el entorno de red del sistema de automatización para completar la transferencia de control desde el primer nodo de cómputo al segundo nodo de cómputo en el bloque 2210. En algunas realizaciones, configurar el segundo nodo de cómputo para ejecutar una o más funciones de aplicación incluye recuperar datos lógicos y de estado relacionados con una o más funciones de aplicación desde un nodo de almacenamiento y usar los datos lógicos y de estado para configurar el segundo nodo de cómputo para ejecutar una o más funciones de aplicación.
En algunas realizaciones, configurar el entorno de red del sistema de automatización para completar la transferencia de control desde el primer nodo de cómputo al segundo nodo de cómputo incluye configurar al menos un conmutador de red físico o virtual para permitir el tráfico entrante y saliente asociado con un control de un proceso o máquina desde el segundo nodo de cómputo. En algunas otras realizaciones, la configuración del entorno de red del sistema de automatización para completar la transferencia de control desde el primer nodo de cómputo al segundo nodo de cómputo incluye además la configuración de al menos un conmutador de red físico o virtual para bloquear el tráfico saliente asociado con el control del proceso o máquina desde el primer nodo de cómputo. Antes de detectar el evento asociado con el segundo nodo de cómputo, el entorno de red se puede configurar para propagar entradas desde el primer y segundo nodos de cómputo y salidas desde sólo el primer nodo de cómputo.
La FIG. 23 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la detección y manejo de un evento de fallo de acuerdo con algunas realizaciones.
El procedimiento de ejemplo incluye la detección, por un componente detector de eventos (por ejemplo, el componente de detección de eventos 1718 de la FIG. 17), una alarma asociada a un evento de fallo en el bloque 2302. El evento de fallo puede ser desencadenado por el fallo de un nodo de cómputo causado por un fallo de alimentación, fallo del OS host, corrupción de memoria, fallo de disco, fallo de la red de gestión/datos, y similares. En el bloque 2304, el componente detector de eventos puede identificar un nodo de cómputo que es la fuente de la alarma como un nodo fallido. En el bloque 2306, el componente detector de eventos puede enviar una notificación de la alarma identificando el nodo fallido y/u otra información relacionada con el evento y/o el nodo fallido (por ejemplo, las funciones de aplicación asociadas que se ejecutan en el nodo fallido a un dispositivo de cliente tal como una tableta o un módulo HMI. Un usuario, tal como un operario de planta, puede ver la notificación y aprobar la gestión del evento por parte del sistema de automatización. En el bloque 2308, un manejador de eventos (por ejemplo, el manejador de eventos 1720 en la FIG. 17, el controlador de eventos de fallo del nodo de cálculo 1820B in FIG. 18B) puede recibir la indicación del dispositivo de cliente para gestionar el evento de fallo. En realizaciones alternativas, el evento de fallo se puede gestionar automáticamente, sin la aprobación o intervención del usuario. En algunas realizaciones, en respuesta a la recepción de la indicación de gestionar el evento de fallo (o tras la detección del evento si no se requiere la aprobación del usuario), un componente de aprovisionamiento (por ejemplo, el componente de aprovisionamiento 1706 en la FIG. 17) puede crear una instancia virtualizada para ejecutar las funciones de aplicación del nodo fallido y las redes virtuales asociadas en un nodo de cómputo en el bloque 2310. En el bloque 2312, el componente de aprovisionamiento puede. Además, en el bloque 2314 el controlador de red puede configurar la infraestructura de red para dirigir los flujos de tráfico a la instancia virtualizada en el nodo de cómputo en lugar del nodo fallido. En el bloque 2316, el componente de programación puede cargar los procesos del nodo fallido en la instancia virtualizada.
En algunas realizaciones, puede estar disponible una infraestructura elástica de sistemas de reserva virtualizados. De este modo, cuando el evento de fallo necesita ser manejado, el controlador del servidor de niebla puede seleccionar una máquina virtual de un grupo de máquinas virtuales en el bloque 2318 que se puede hacer cargo de los procesos del nodo fallido, asumiendo todas las responsabilidades y funciones. En algunas realizaciones, el conjunto de máquinas virtuales puede tener máquinas virtuales de diferentes sabores (por ejemplo, capacidades, versiones de SO, tamaño de memoria, etc.) basadas en uno o más criterios. Además, en algunas realizaciones, el conjunto de VM puede ser genérico y no configurado. En el bloque 2320, el controlador del servidor de niebla puede recuperar la lógica de la aplicación y los datos de estado para los procesos del nodo fallido desde una base de datos de estado en tiempo real y cargar la lógica de la aplicación y los datos de estado en la máquina virtual seleccionada de forma que la máquina virtual pueda sobre los procesos del nodo fallido en el bloque 2322.
La FIG. 24 es un diagrama de flujo lógico que ilustra un procedimiento de ejemplo para la gestión de un sistema de automatización de acuerdo con una segunda realización. El procedimiento de ejemplo incluye monitorizar entornos de ejecución, red y seguridad de un sistema de automatización (por ejemplo, el sistema SDA) en el bloque 2402, detectar un evento en un primer entorno entre los entornos de ejecución, red y seguridad en el bloque 2404 y en respuesta al evento detectado, remediar al menos un componente en el primer entorno, la remediación del primer entorno creando un disparador para causar la remediación de al menos un componente en cada uno de un segundo y tercer entorno entre los entornos de ejecución, red y seguridad en el bloque 2406. Por ejemplo, cuando el primer entorno es un entorno de seguridad, entonces el evento detectado en el entorno de seguridad es un evento de seguridad. La reconfiguración del al menos un componente en el entorno de seguridad puede incluir la partición de la red para aislar el componente asociado con el evento de seguridad del resto de los componentes del sistema de automatización. En algunas realizaciones, la remediación del entorno de seguridad puede ser una respuesta que no requiera la intervención del usuario porque los eventos de seguridad son generalmente eventos críticos que requieren una acción inmediata para contener los impactos negativos tales como la manipulación de datos o la pérdida o pérdida de control de partes de una planta.
10. Sistematización informática
La FIG. 25 es un diagrama de bloques de una máquina/ordenador/aparato ejemplar que puede llevar a cabo varias operaciones, y almacenar varias informaciones generadas y/o usadas por tales operaciones de acuerdo con algunas realizaciones. El ordenador 2500 pretende ilustrar un dispositivo de hardware en el que cualquiera de las entidades, componentes o servicios representados en los ejemplos de las FIGS. 1 a 7B, 8A a 11, 13B, 17 a 20 (y cualquier otro componente descrito en esta memoria descriptiva) y se pueden implementar las metodologías descritas en los ejemplos de las FIGS. 12 a 13A, 14 a 16B y 21A a 24, tales como un servidor, dispositivos de cliente, nodos de cómputo, nodos controladores (por ejemplo, controlador del servidor de niebla (componentes 610, 810-x, 910, 1010, 1110, 1910, 2010), controlador de ciberseguridad (por ejemplo, componentes 655, 1155, 1955, 2055), controlador de red (por ejemplo, componentes 690, 590A, 590B, 1190, 1990, 2090)), dispositivos/nodos de almacenamiento, bases de datos, PLC, PAC y similares. El ordenador 2500 incluye uno o más procesadores 2505 y memoria 2510 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 2505 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 por medio de 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 2510 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 mediante el uso de circuitos de hardware tales 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 2525, un dispositivo(s) de almacenamiento 2515 y dispositivos de E/S 2520. 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 usar 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, que incluyen 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 se puede proporcionar inicialmente al ordenador descargándolo desde un sistema remoto a través del ordenador (por ejemplo, por medio de un adaptador de red). En algunas realizaciones, la memoria 2510 y los dispositivos de almacenamiento 2515 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 pueden estar en forma de, por ejemplo, uno o más ASIC, PLD, FPGA, etc.
El software o firmware para su uso en el sistema SDA/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”, como se usa 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 ejemplo, PLC, PAC), o cualquier máquina capaz de ejecutar un conjunto de instrucciones (secuenciales o de otro tipo) que especifiquen las acciones que debe llevar a cabo 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”, como se usa 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.
11. 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 se deben interpretar 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”. Como se usan 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 usan en esta solicitud, se refieren a esta solicitud en su conjunto y no a ninguna porción particular de esta solicitud. Cuando el contexto lo permita, los términos de la anterior Descripción Detallada que usen 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.
La descripción detallada anterior de las realizaciones de la divulgación no pretende ser exhaustiva ni limitar las enseñanzas a la forma precisa desvelada anteriormente. Si bien las realizaciones específicas y los ejemplos de la divulgación se han descrito anteriormente con fines ilustrativos, son posibles diversas modificaciones equivalentes dentro del ámbito de la divulgación, como reconocerán los expertos en la materia. Por ejemplo, mientras que los procesos o bloques se presentan en un orden determinado, las realizaciones alternativas pueden llevar a cabo rutinas que tengan etapas, o emplear sistemas que tengan bloques en un orden diferente, y algunos procesos o bloques se pueden eliminar, mover, añadir, subdividir, combinar y/o modificar para proporcionar combinaciones alternativas o subcombinaciones. Cada uno de estos procesos o bloques se puede aplicar de diferentes maneras. Además, aunque a veces se muestra que los procesos o bloques se llevan a cabo en serie, estos procesos o bloques se pueden llevar a cabo en paralelo o en momentos diferentes. Además, los números específicos que se indican en la presente memoria son sólo ejemplos: las implementaciones alternativas pueden emplear valores o intervalos diferentes.
Las enseñanzas de la divulgación en la presente memoria proporcionadas se pueden aplicar a otros sistemas, no necesariamente al sistema descrito anteriormente. Los elementos y actos de las diversas realizaciones descritas anteriormente se pueden combinar para proporcionar otras realizaciones.
Todas las patentes, solicitudes y otras referencias mencionadas anteriormente, incluidas las que puedan figurar en los documentos de presentación adjuntos, se incorporan a la presente memoria por referencia. Los aspectos de la divulgación pueden ser modificados, si es necesario, para emplear los sistemas, funciones y conceptos de las diversas referencias descritas anteriormente para proporcionar aún más realizaciones de la divulgación.
Estos y otros cambios se pueden hacer a la divulgación a la luz de la Descripción Detallada anterior. Aunque la descripción anterior describe ciertas realizaciones de la divulgación, y describe la mejor modalidad contemplada, por muy detallado que aparezca lo anterior en el texto, las enseñanzas se pueden practicar de numerosas maneras. Los detalles del sistema pueden variar considerablemente en cuanto a su implementación, sin dejar por ello de estar incluidos en el objeto de la presente memoria. Como se ha indicado anteriormente, la terminología particular usada al describir ciertas características o aspectos de la divulgación no se debe interpretar en el sentido de que la terminología se redefine en la presente memoria para restringirse a características, rasgos o aspectos específicos de la divulgación con los que se asocia dicha terminología. En general, los términos usados en las reivindicaciones siguientes no se deben interpretar como una limitación de la divulgación a las realizaciones específicas descritas en la memoria descriptiva, a menos que en la sección Descripción detallada anterior se definan explícitamente dichos términos. En consecuencia, el alcance real de la divulgación abarca no sólo las realizaciones desveladas, sino también todas las formas equivalentes de practicar o implementar la divulgación de acuerdo con las reivindicaciones. A partir de lo anterior, se apreciará que las realizaciones específicas del sistema/tecnología desvelado se han descrito en la presente memoria con fines ilustrativos, pero que se pueden hacer varias modificaciones sin desviarse del alcance de las reivindicaciones anexas. En consecuencia, las realizaciones no están limitadas excepto por las reivindicaciones adjuntas.

Claims (15)

REIVINDICACIONES
1. Un sistema de automatización definido por software, SDA, (100) que comprende:
un primer subsistema que incluye un nodo controlador del sistema (510) y uno o más nodos de cómputo (515) gestionados por el nodo controlador del sistema (510),
en el que uno o más nodos de cómputo (515) están configurados para acoplarse comunicativamente al nodo controlador del sistema (510) a través de una primera red de comunicación;
en el que el nodo controlador del sistema (510) está configurado para:
gestionar la virtualización de un sistema de control de automatización o una porción del mismo en al menos un nodo de cómputo desde los uno o más nodos de cómputo a través de la primera red de comunicación,
crear al menos una instancia parcial o totalmente virtualizada (645) de una unidad funcional del sistema de control de automatización que represente un elemento virtualizado del sistema de control de automatización en uno o más nodos de cómputo gestionados por el controlador del sistema;
crear una red virtual (620) en los uno o más nodos de cómputo;
conectar la al menos una instancia parcial o totalmente virtualizada de la unidad funcional a la red virtual; conectar la red virtual a una segunda red de comunicación física (680) para permitir que la al menos una instancia virtualizada (645) de la unidad funcional interactúe con al menos un elemento físico del sistema de control del sistema de automatización;
en el que uno o más nodos de cómputo están configurados además para:
ejecutar una función del sistema de control de automatización del al menos un elemento virtualizado del sistema de control de automatización en al menos un host que se ejecuta en los uno o más nodos de cómputo, para controlar el al menos un elemento físico del sistema de control a través de la segunda red de comunicación física conectada a la red virtual.
2. El sistema de acuerdo con la reivindicación 1, en el que los uno o más nodos de cómputo incluyen un dispositivo de borde que se encuentra en las proximidades del al menos un elemento físico del sistema de control y una máquina de servidor; y/o
en el que el al menos un elemento virtualizado del sistema de control de automatización se ejecuta en al menos un host en el al menos un nodo de cómputo, y en el que el al menos un host incluye una máquina virtual, un contenedor o un bare metal; y/ o
en el que un nodo controlador de red controla al menos un elemento de red físico o virtual por medio del despliegue de una o más políticas de red; y/o
en el que el sistema de control de automatización virtualizado incluye una implementación de software de un sistema integrado o un componente del sistema integrado; y/o
en el que la gestión de uno o más nodos de cómputo incluye la creación de instancias, la configuración, el inicio, la detención y la destrucción de hosts en los uno o más nodos de cómputo; y/o
en el que el primer subsistema, que incluye el nodo controlador del sistema y uno o más nodos de cómputo, está localizado en un único servidor de alta disponibilidad.
3. El sistema de acuerdo con cualquiera de las reivindicaciones 1 o 2, que además comprende: un segundo subsistema que incluye un nodo controlador de ciberseguridad, en el que el nodo controlador de ciberseguridad proporciona al menos una política de seguridad al primer subsistema para configurar la seguridad del sistema de control de automatización virtualizado, y al menos un host que ejecuta el sistema de control de automatización virtualizado en el al menos un nodo de cómputo.
4. El sistema de acuerdo con cualquiera de las reivindicaciones 1 a 3, que además comprende: un tercer subsistema que incluye un nodo controlador de red, en el que:
el nodo controlador de red, en respuesta a la virtualización del sistema de control de automatización o la porción del mismo en el primer subsistema, configura al menos un elemento de red físico o virtual para gestionar el flujo de tráfico de red asociado con el control del al menos un elemento de sistema de control físico; y/o
el nodo controlador de red, en respuesta a un cambio en el primer subsistema, configura al menos un elemento de red físico o virtual para gestionar el flujo de tráfico de red asociado con el control del al menos un elemento de sistema de control físico.
5. El sistema de acuerdo con la reivindicación 4, en el que el segundo subsistema proporciona al menos una política de seguridad al tercer subsistema para configurar la seguridad de al menos un elemento de red físico o virtual.
6. El sistema de acuerdo con la reivindicación 5, en el que la al menos una política de seguridad especifica los tipos de comandos que se permite propagar a través de la segunda red de comunicación al al menos un elemento de sistema de control físico a través del al menos un elemento de red físico o virtual.
7. El sistema de acuerdo con la reivindicación 4, en el que el tercer subsistema incluye un componente de red sensible al tiempo para gestionar el tráfico de red determinista sensible al tiempo.
8. El sistema de acuerdo con cualquiera de las reivindicaciones anteriores, que además comprende:
un software de sistema que se ejecuta en un host en un nodo de cómputo de los uno o más nodos de cómputo, el software de sistema que comunica, a través de una interfaz de programación de aplicaciones, la descripción de virtualización del sistema de control para la virtualización del sistema de control de automatización o la porción del mismo en el primer subsistema; y/o
que comprende un software de sistema a través del cual son accesibles a una entidad al menos dos de las informaciones siguientes: topología, inventario, configuración o diagnóstico correspondientes a componentes del primer subsistema; el software de sistema se ejecuta en un host en un nodo de cómputo de los uno o más nodos de cómputo y se comunica con el primer subsistema a través de una interfaz de programación de aplicaciones.
9. Un procedimiento para definir un sistema de automatización por medio de software, el sistema comprende un primer subsistema que incluye un nodo controlador del sistema (510) y uno o más nodos de cómputo (515) gestionados por el nodo controlador del sistema (510), los uno o más nodos de cómputo (515) están configurados para estar acoplados comunicativamente al nodo controlador del sistema (510) a través de una primera red de comunicación, y el nodo controlador del sistema está configurado para gestionar la virtualización de un sistema de control de automatización o una porción del mismo en al menos un nodo de cómputo desde los uno o más nodos de cómputo a través de la primera red de comunicación, el procedimiento comprende: crear, por medio de un controlador de sistema del primer subsistema, una instancia parcial o totalmente virtualizada (645) de una unidad funcional de un sistema de control de automatización que represente un elemento virtualizado del sistema de control de automatización en uno o más nodos de cómputo gestionados por el controlador de sistema;
crear, por el controlador del sistema, una red virtual (620) en los uno o más nodos de cómputo; conectar, por medio del controlador del sistema, la red virtual a una segunda red de comunicación física para permitir que la al menos una instancia virtualizada de la unidad funcional interactúe con el al menos un elemento de control físico del sistema de automatización; y
ejecutar, por medio de los uno o más nodos de cómputo, una función del sistema de control de automatización del al menos un elemento virtualizado del sistema de control de automatización en al menos un host que se ejecuta en los uno o más nodos de cómputo, para controlar el al menos un elemento físico del sistema de control a través de la segunda red de comunicación física conectada a la red virtual.
10. El procedimiento de acuerdo con la reivindicación 9, que además comprende: configurar la seguridad de la instancia parcial o totalmente virtualizada de la unidad funcional por medio de la aplicación de una o más políticas de seguridad de un segundo subsistema.
11. El procedimiento de acuerdo con la reivindicación 10, en el que de acuerdo con una política de seguridad, configurar la seguridad de la instancia parcial o totalmente virtualizada de la unidad funcional incluye crear una instancia virtualizada de un sistema de protección de seguridad en los uno o más nodos de cómputo; y/o en el que la instancia parcial o totalmente virtualizada de la unidad funcional incluye uno o más hosts en los que se ejecuta la implementación de software de la unidad funcional, y en el que configurar la seguridad de la instancia parcial o totalmente virtualizada de la unidad funcional incluye configurar la seguridad de: la implementación de software de la unidad funcional, los uno o más hosts, y los uno o más nodos de cómputo en los que se ejecutan los uno o más hosts.
12. El procedimiento de acuerdo con cualquiera de las reivindicaciones 9 a 11, que además comprende, en respuesta a una solicitud para crear la instancia virtualizada de la unidad funcional del sistema de automatización, aplicar por el controlador del sistema al menos una política de seguridad para autenticar la solicitud antes de crear la instancia parcial o totalmente virtualizada de la unidad funcional.
13. El procedimiento de acuerdo con cualquiera de las reivindicaciones 9 a 12, que además comprende:
determinar, por medio de un controlador de red de un tercer subsistema acoplado comunicativamente al primer subsistema, al menos una ruta de red; y
configurar, por el controlador de red de uno o más elementos de red en la al menos una ruta de red para permitir el flujo de tráfico de datos entre la instancia parcial o totalmente virtualizada de la unidad funcional y el dispositivo de campo.
14. El procedimiento de acuerdo con la reivindicación 13, que además comprende:
configurar la seguridad de uno o más elementos de red en la al menos una ruta de red por medio de la aplicación de una o más políticas de seguridad proporcionadas por un segundo subsistema; y/o
en la que al menos una ruta de red atraviesa la red virtual y una red física.
15. El procedimiento de acuerdo con cualquiera de las reivindicaciones 9 a 14, en el que la instancia parcial o totalmente virtualizada de la unidad funcional se crea a partir de una plantilla de unidad funcional seleccionada de una biblioteca de plantillas de unidades funcionales; y/o
en el que los nodos de cómputo gestionados por el controlador del sistema incluyen al menos uno de los siguientes: un controlador del sistema de automatización y un dispositivo inteligente conectado; y/o en el que la instancia parcialmente virtualizada de la unidad funcional corresponde a una instancia virtualizada de un primer componente de la unidad funcional que tiene al menos dos componentes; y/o en el que la instancia totalmente virtualizada de la unidad funcional corresponde a una instancia virtualizada de cada componente de la unidad funcional.
ES16798807T 2015-10-13 2016-10-12 Sistema y arquitectura de automatización definidos por software Active ES2941337T3 (es)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201562241028P 2015-10-13 2015-10-13
US201562240742P 2015-10-13 2015-10-13
US201662348770P 2016-06-10 2016-06-10
US201662354683P 2016-06-24 2016-06-24
US201662354799P 2016-06-26 2016-06-26
US201662406932P 2016-10-11 2016-10-11
PCT/IB2016/001609 WO2017064565A1 (en) 2015-10-13 2016-10-12 Software defined automation system and architecture

Publications (1)

Publication Number Publication Date
ES2941337T3 true ES2941337T3 (es) 2023-05-22

Family

ID=57288472

Family Applications (2)

Application Number Title Priority Date Filing Date
ES16798807T Active ES2941337T3 (es) 2015-10-13 2016-10-12 Sistema y arquitectura de automatización definidos por software
ES16795135T Active ES2972422T3 (es) 2015-10-13 2016-10-12 Procedimiento para organizar las cargas de trabajo en un sistema de automatización definido por software

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES16795135T Active ES2972422T3 (es) 2015-10-13 2016-10-12 Procedimiento para organizar las cargas de trabajo en un sistema de automatización definido por software

Country Status (8)

Country Link
US (5) US10845786B2 (es)
EP (5) EP4202681A1 (es)
CN (3) CN108885560B (es)
AU (7) AU2016337406A1 (es)
CA (3) CA3001790A1 (es)
ES (2) ES2941337T3 (es)
RU (3) RU2747966C2 (es)
WO (3) WO2017064565A1 (es)

Families Citing this family (187)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10616052B2 (en) * 2016-02-23 2020-04-07 Cisco Technology, Inc. Collaborative hardware platform management
US11316935B2 (en) 2016-02-26 2022-04-26 Cable Television Laboratories, Inc. Systems and method for micro network segmentation
US11277746B2 (en) 2016-02-26 2022-03-15 Cable Television Laboratories, Inc. Systems and method for micro network segmentation
US10440043B2 (en) 2016-02-26 2019-10-08 Cable Television Laboratories, Inc. System and method for dynamic security protections of network connected devices
US10609016B2 (en) * 2016-02-26 2020-03-31 Cable Television Laboratories, Inc Systems and method for micro network segmentation
US11072356B2 (en) 2016-06-30 2021-07-27 Transportation Ip Holdings, Llc Vehicle control system
US10298503B2 (en) * 2016-06-30 2019-05-21 General Electric Company Communication system and method for integrating a data distribution service into a time sensitive network
US10814893B2 (en) 2016-03-21 2020-10-27 Ge Global Sourcing Llc Vehicle control system
US10205784B2 (en) * 2016-03-21 2019-02-12 General Electric Company Communication system and method for controlling data distribution quality of service in time sensitive networks
WO2017165701A1 (en) 2016-03-25 2017-09-28 Nebbiolo Technologies, Inc. Fog Computing Facilitated Flexible Factory
EP4235428A3 (en) * 2016-06-24 2023-10-11 Schneider Electric Systems USA, Inc. Methods, systems and apparatus to dynamically facilitate boundaryless, high availability m..n working configuration management with supplemental resource
US10277528B2 (en) * 2016-08-11 2019-04-30 Fujitsu Limited Resource management for distributed software defined network controller
WO2018044737A1 (en) * 2016-08-31 2018-03-08 Nebbiolo Technologies, Inc. Centrally managed time sensitive fog networks
US10097472B2 (en) * 2016-09-14 2018-10-09 At&T Intellectual Property I, L.P. Method and system for dynamically distributing and controlling a virtual gateway
US10798063B2 (en) 2016-10-21 2020-10-06 Nebbiolo Technologies, Inc. Enterprise grade security for integrating multiple domains with a public cloud
US10298605B2 (en) * 2016-11-16 2019-05-21 Red Hat, Inc. Multi-tenant cloud security threat detection
US10708389B2 (en) * 2016-12-06 2020-07-07 Intelligrated Headquarters, Llc Phased deployment of scalable real time web applications for material handling system
US11629518B2 (en) 2017-02-28 2023-04-18 Hummingbird Kinetics LLC Tuned liquid damper with a membrane liquid-gas interface
US11323519B2 (en) * 2017-04-19 2022-05-03 Microsoft Technology Licensing, Llc Internet of things pub-sub data publisher
GB2575758B (en) * 2017-05-01 2023-04-12 Fisher Rosemount Systems Inc Open architecture industrial control system
US11475124B2 (en) * 2017-05-15 2022-10-18 General Electric Company Anomaly forecasting and early warning generation
DE102017209493A1 (de) * 2017-06-06 2018-12-06 Siemens Aktiengesellschaft Verfahren und System zur Durchführung eines Setups bei einem industriellen Netzwerk
SE542688C2 (en) * 2017-07-17 2020-06-23 Beijer Electronics Ab Configuring an industrial automation system for internet-of-things accessibility
US10491719B2 (en) * 2017-07-24 2019-11-26 Cisco Technology, Inc. Insertion of management packet into a wired deterministic path
EP3435180A1 (de) * 2017-07-28 2019-01-30 Siemens Aktiengesellschaft Verfahren zum betrieb eines mehrere kommunikationsgeräte umfassenden kommunikationsnetzes eines industriellen automatisierungssystems und steuerungseinheit
US10911405B1 (en) * 2017-07-31 2021-02-02 Amazon Technologies, Inc. Secure environment on a server
EP3444682A1 (de) * 2017-08-16 2019-02-20 Siemens Aktiengesellschaft Verfahren zum rechnergestützten koppeln eines verarbeitungsmoduls in ein modulares technisches system und modulares technisches system
US11489787B2 (en) * 2017-08-25 2022-11-01 Tttech Industrial Automation Ag Centrally managed time-sensitive fog networks
SE1751114A1 (en) * 2017-09-13 2019-03-14 Beijer Electronics Ab A method of configuring an automation system
US10911308B2 (en) * 2017-09-18 2021-02-02 Rapyuta Robotics Co., Ltd. Auto-determining and installing missing components to a to-be-managed device by a single execution of unique device setup command
CN111108452A (zh) * 2017-09-28 2020-05-05 西门子股份公司 用于为可编程逻辑控制器提供服务的方法和装置
US10972579B2 (en) * 2017-10-13 2021-04-06 Nebbiolo Technologies, Inc. Adaptive scheduling for edge devices and networks
IL255242A0 (en) 2017-10-24 2017-12-31 Ecoplant Tech Innovation Ltd A system and method for managing the optimal utilization of energy
US10833923B2 (en) 2017-10-26 2020-11-10 Skylo Technologies Inc. Dynamic multiple access for distributed device communication networks with scheduled and unscheduled transmissions
US11165602B2 (en) * 2017-10-31 2021-11-02 Murata Machinery, Ltd. Communication system, controlled device, and control method for communication system
DE102018100879A1 (de) * 2017-11-07 2019-05-09 Fujitsu Technology Solutions Intellectual Property Gmbh IoT-Computersystem sowie Anordnung mit einem solchen IoT-Computersystem und einem externen System
US10728288B2 (en) 2017-11-21 2020-07-28 Juniper Networks, Inc. Policy-driven workload launching based on software defined networking encryption policies
US10742690B2 (en) 2017-11-21 2020-08-11 Juniper Networks, Inc. Scalable policy management for virtual networks
US10608893B2 (en) * 2017-12-06 2020-03-31 Nokia Technologies Oy SDN control plane performance testing
US10417035B2 (en) * 2017-12-20 2019-09-17 At&T Intellectual Property I, L.P. Virtual redundancy for active-standby cloud applications
CN108196501A (zh) * 2017-12-22 2018-06-22 北京东土科技股份有限公司 一种基于plc的分布式控制系统的容灾方法、装置和系统
US20190199595A1 (en) * 2017-12-22 2019-06-27 Avaya Inc. Attribute and property overrides for remote network topology changes
CN109104454A (zh) * 2017-12-25 2018-12-28 北极星云空间技术股份有限公司 采用设备虚拟化技术构造的软件定义物联网的服务架构
US20190199626A1 (en) * 2017-12-26 2019-06-27 Cisco Technology, Inc. Routing traffic across isolation networks
US11681597B2 (en) 2017-12-29 2023-06-20 Siemens Aktiengesellschaft Anomaly detection method and system for process instrument, and storage medium
CN109995675B (zh) * 2017-12-29 2021-07-13 中国科学院沈阳自动化研究所 一种基于软件定义的自适应工业以太网网关系统与方法
US10306442B1 (en) 2018-01-16 2019-05-28 Skylo Technologies Inc. Devices and methods for specialized machine-to-machine communication transmission network modes via edge node capabilities
EP4221125A1 (en) * 2018-01-30 2023-08-02 Deutsche Telekom AG Customer premise equipment and a method and system for virtualized deployment thereof
EP3522013B1 (en) 2018-02-01 2020-04-01 Siemens Aktiengesellschaft Method and system for migration of containers in a container orchestration platform between compute nodes
EP3521948A1 (en) * 2018-02-06 2019-08-07 Tata Consultancy Services Limited Systems and methods for auto-generating a control and monitoring solution for smart and robotics environments
DE102018202398A1 (de) * 2018-02-16 2019-08-22 Siemens Aktiengesellschaft Vereinfachte Programmerstellung für Komponenten von Automatisierungssystemen
US10382284B1 (en) * 2018-03-02 2019-08-13 SILVAIR Sp. z o.o. System and method for commissioning mesh network-capable devices within a building automation and control system
RU2679739C1 (ru) * 2018-03-07 2019-02-12 Закрытое акционерное общество Инженерно-технический центр "Континуум" Система автоматизации с динамической функциональной архитектурой
US11057769B2 (en) 2018-03-12 2021-07-06 At&T Digital Life, Inc. Detecting unauthorized access to a wireless network
EP3753205B1 (de) * 2018-04-04 2024-01-24 Siemens Aktiengesellschaft Datenübertragung in zeitsensitiven datennetzen
EP3776098B1 (de) 2018-04-13 2023-03-08 SEW-Eurodrive GmbH & Co System und verfahren zum betreiben eines systems
US10348481B1 (en) 2018-04-30 2019-07-09 Cisco Technology, Inc. Clock harmonization in deterministic networks
US10739754B2 (en) * 2018-05-11 2020-08-11 Ford Motor Company Method and system for monitoring machine health to improve machine cycle time impact
EP3570160A1 (en) * 2018-05-18 2019-11-20 Siemens Aktiengesellschaft Method and platform for deployment of an industrial application on an edge computing device of a machine tool
US10742557B1 (en) 2018-06-29 2020-08-11 Juniper Networks, Inc. Extending scalable policy management to supporting network devices
US10778724B1 (en) 2018-06-29 2020-09-15 Juniper Networks, Inc. Scalable port range management for security policies
US11263098B2 (en) * 2018-07-02 2022-03-01 Pivotal Software, Inc. Database segment load balancer
WO2020006612A1 (pt) * 2018-07-05 2020-01-09 Nouvenn Corporation Sistema de rede segura em malha para compartilhamento de dados e respectivos dispositivos de acoplamento e interface
US11403000B1 (en) 2018-07-20 2022-08-02 Pure Storage, Inc. Resiliency in a cloud-based storage system
US11416298B1 (en) * 2018-07-20 2022-08-16 Pure Storage, Inc. Providing application-specific storage by a storage system
JP7052620B2 (ja) * 2018-07-30 2022-04-12 オムロン株式会社 サポート装置およびサポートプログラム
US11049055B2 (en) * 2018-09-13 2021-06-29 Blentech Corporation Digital historian and dashboard for commercial cookers
US11144039B2 (en) 2018-09-20 2021-10-12 Rockwell Automation Technologies, Inc. Systems and methods for controlling devices based on mapping between operation technology data and information technology data
DE102018216111A1 (de) * 2018-09-21 2020-03-26 Robert Bosch Gmbh Übertragungsverfahren
US10326732B1 (en) * 2018-10-08 2019-06-18 Quest Automated Services, LLC Automation system with address generation
EP3637684A1 (de) * 2018-10-12 2020-04-15 Siemens Aktiengesellschaft Verfahren zum automatischen konfigurieren eines systems, system, computerprogramm und computerlesbares medium
CN109495564A (zh) * 2018-11-13 2019-03-19 广东水利电力职业技术学院（广东省水利电力技工学校） 一种基于CoDeSys的OPC UA TSN核心实现方法及系统
US10725466B2 (en) 2018-11-15 2020-07-28 Oden Technologies Ltd. Cloud and edge manufacturing data processing system
KR20200058157A (ko) * 2018-11-19 2020-05-27 삼성전자주식회사 Ivi 서비스를 제공하기 위한 전자 장치 및 방법
US20220006694A1 (en) * 2018-11-20 2022-01-06 Abb Schweiz Ag Configuration Of Networked Devices
CN111338927B (zh) * 2018-12-19 2023-12-12 国家电投集团科学技术研究院有限公司 核电软件高效耦合分析系统
US10917308B2 (en) 2018-12-20 2021-02-09 Verizon Patent And Licensing Inc. Virtualized network service management and diagnostics
US10917339B2 (en) * 2018-12-21 2021-02-09 Juniper Networks, Inc. System and method for user customization and automation of operations on a software-defined network
US10951496B2 (en) 2018-12-24 2021-03-16 Threat Stack, Inc. System and method for cloud-based control-plane event monitor
CN109918181B (zh) * 2019-01-12 2023-04-14 西北工业大学 基于最差响应时间的混合关键系统任务可调度性分析方法
US11563768B2 (en) * 2019-01-31 2023-01-24 Keysight Technologies, Inc. Methods, systems, and computer readable media for detecting and mitigating effects of timing attacks in time sensitive networks
CN109901830B (zh) * 2019-02-21 2022-04-08 苏州宏软信息技术有限公司 一种用于scada系统开发的信号配置方法与系统
EP3702916A1 (en) * 2019-03-01 2020-09-02 ABB Schweiz AG Online reconfiguration of a node in a process control system
US10956526B2 (en) * 2019-03-04 2021-03-23 International Business Machines Corporation Implementing a policy-driven resource deployment mechanism in a cloud environment
US20200293654A1 (en) * 2019-03-12 2020-09-17 Universal City Studios Llc Security appliance extension
US10924338B2 (en) * 2019-03-29 2021-02-16 Honeywell International Inc. Controller application module orchestrator
CN110110367B (zh) * 2019-04-02 2023-08-22 南京四象新能源科技有限公司 一种电化学储能机柜热仿真方法及系统
US11036656B2 (en) * 2019-04-07 2021-06-15 Honeywell International Inc. I/O mesh architecture for an industrial automation system
EP3723346A1 (en) * 2019-04-10 2020-10-14 ABB Schweiz AG Selective address space aggregation
US11201921B2 (en) 2019-05-13 2021-12-14 Cisco Technology, Inc. Virtual devices in internet of things (IoT) nodes
DE102019207790A1 (de) * 2019-05-28 2020-12-03 Siemens Mobility GmbH Anlagenkomponente, sicherheitsrelevante Anlage und Betriebsverfahren
JP2020194354A (ja) * 2019-05-28 2020-12-03 オムロン株式会社 サポート装置および設定プログラム
DE102019114303B3 (de) * 2019-05-28 2020-09-17 Beckhoff Automation Gmbh Verfahren zum Erfassen von Netzwerkteilnehmer in einem Automatisierungsnetzwerk und Automatisierungsnetzwerk
US11537112B2 (en) * 2019-06-10 2022-12-27 Fisher-Rosemount Systems, Inc. Automatic load balancing and performance leveling of virtual nodes running real-time control in process control systems
GB2623651A (en) 2019-06-10 2024-04-24 Fisher Rosemount Systems Inc Automatic load balancing and performance leveling of virtual nodes running real-time control in process control systems
US20200403935A1 (en) * 2019-06-18 2020-12-24 Tmrw Foundation Ip & Holding S. À R.L. Software engine virtualization and dynamic resource and task distribution across edge and cloud
US20200401436A1 (en) * 2019-06-18 2020-12-24 Tmrw Foundation Ip & Holding S. À R.L. System and method to operate 3d applications through positional virtualization technology
US11216309B2 (en) 2019-06-18 2022-01-04 Juniper Networks, Inc. Using multidimensional metadata tag sets to determine resource allocation in a distributed computing environment
US11009840B2 (en) * 2019-06-19 2021-05-18 Honeywell International, Inc. Control execution environment and container based architecture
CN110390273A (zh) * 2019-07-02 2019-10-29 重庆邮电大学 一种基于多核迁移学习的室内人员入侵检测方法
RU2735348C1 (ru) * 2019-07-18 2020-10-30 Федеральное государственное бюджетное образовательное учреждение высшего образования "Самарский государственный университет путей сообщения" (СамГУПС) Устройство автоматизированного управления процессом проектирования структуры системы управления техническими средствами
DE102019120103A1 (de) * 2019-07-25 2021-01-28 Beckhoff Automation Gmbh Verfahren zur Datenkommunikation zwischen Feldbusgeräten und einem Leitstand eines Automatisierungssystems und Automatisierungssystem
CN110502467B (zh) * 2019-07-25 2020-11-10 江苏诺蓝翌新能源科技有限公司 一种基于串口modbus通信协议的通用采集接口软件系统
EP4008097A1 (en) * 2019-08-02 2022-06-08 Telefonaktiebolaget LM Ericsson (publ) Software defined manufacturing in a cellular network
CN110519776B (zh) * 2019-08-07 2021-09-17 东南大学 一种雾计算系统中的均衡聚类和联合资源分配方法
CN110677282B (zh) * 2019-09-23 2022-05-17 天津津航计算技术研究所 一种分布式系统的热备份方法及分布式系统
US11949549B2 (en) 2019-09-24 2024-04-02 Intradiem, Inc. Agent instance live-monitoring by a management network for burnout and attrition prediction and response
US11665044B2 (en) 2019-09-24 2023-05-30 Intradiem, Inc. Adaptive rule trigger thresholds for managing contact center interaction time
US11329861B2 (en) 2019-09-24 2022-05-10 Intradiem, Inc. Optimized automation triggering in live-monitoring of agent instances
US11356316B2 (en) 2019-09-24 2022-06-07 Intradiem, Inc. Live-monitoring of agent instances to trigger automation
US10623233B1 (en) * 2019-09-24 2020-04-14 Intradiem Inc. Live monitoring to trigger automation
EP3800864B1 (de) * 2019-10-01 2022-11-23 Siemens Aktiengesellschaft Verfahren zum konfigurieren eines opc ua pubsub teilnehmers, automatisierungssystem, computerprogramm und computerlesbares medium
US11099855B2 (en) * 2019-10-23 2021-08-24 American Megatrends International, Llc System and method for updating files through a peer-to-peer network
US20210135942A1 (en) * 2019-11-05 2021-05-06 Schneider Electric USA, Inc. Automatic device naming for fast device replacement
DE102019129969A1 (de) * 2019-11-06 2021-05-06 Endress+Hauser SE+Co. KG System zur Ressourcenverwaltung in einer Anlage der Automatisierungstechnik
CN113055203B (zh) * 2019-12-26 2023-04-18 中国移动通信集团重庆有限公司 Sdn控制平面的异常恢复方法及装置
CN111224970A (zh) * 2019-12-31 2020-06-02 中移（杭州）信息技术有限公司 Sdn网络系统、网络攻击防御方法、设备及存储介质
CN111245651B (zh) * 2020-01-08 2022-03-29 上海交通大学 一种基于功率控制和资源分配的任务卸载方法
US11558255B2 (en) * 2020-01-15 2023-01-17 Vmware, Inc. Logical network health check in software-defined networking (SDN) environments
US11909653B2 (en) 2020-01-15 2024-02-20 Vmware, Inc. Self-learning packet flow monitoring in software-defined networking environments
US11374819B2 (en) * 2020-01-31 2022-06-28 Wyze Labs, Inc. Systems and methods for creating virtual devices
WO2021168727A1 (en) 2020-02-27 2021-09-02 Juniper Networks, Inc. Packet steering to a host-based firewall in virtualized environments
US11595393B2 (en) * 2020-03-31 2023-02-28 Juniper Networks, Inc. Role-based access control policy auto generation
US11762742B2 (en) 2020-03-31 2023-09-19 Honeywell International Inc. Process control system with different hardware architecture controller backup
CN111459116B (zh) * 2020-04-23 2024-05-17 招商局重工（江苏）有限公司 一种高效的管子智能生产线数字化管理系统
CN111563018B (zh) * 2020-04-28 2021-11-12 北京航空航天大学 一种人机物融合云计算平台的资源管理和监控方法
US11588856B2 (en) * 2020-05-08 2023-02-21 Rockwell Automation Technologies, Inc. Automatic endpoint security policy assignment by zero-touch enrollment
US10838836B1 (en) * 2020-05-21 2020-11-17 AlteroSmart Solutions LTD Data acquisition and processing platform for internet of things analysis and control
CA3180341A1 (en) * 2020-05-28 2021-12-02 Brian P. Murphy Threat mitigation system and method
CN111651253B (zh) * 2020-05-28 2023-03-14 中国联合网络通信集团有限公司 算力资源的调度方法及装置
US11625018B2 (en) 2020-06-06 2023-04-11 Honeywell International Inc. Method and system for configuring virtual controllers in a building management system
US11782410B2 (en) 2020-06-06 2023-10-10 Honeywell International Inc. Building management system with control logic distributed between a virtual controller and a smart edge controller
US11940786B2 (en) * 2020-06-06 2024-03-26 Honeywell International Inc. Building management system and method with virtual controller and failsafe mode
CN111722590A (zh) * 2020-06-30 2020-09-29 深圳钰翔技术有限公司 一种钣金或五金冲压用送料机的简易编程方法
WO2022006760A1 (en) * 2020-07-08 2022-01-13 Huawei Technologies Co., Ltd. Supporting means of time-sensitive network (tsn) operations using tsn configuration verification
CN111857685A (zh) * 2020-07-16 2020-10-30 武汉秒开网络科技有限公司 一种自助软件定制及远程自动化测试的方法及系统
CN114002992A (zh) * 2020-07-28 2022-02-01 华晨宝马汽车有限公司 配置plc和mes之间的连接的方法和设备
US11474873B2 (en) 2020-09-22 2022-10-18 Rockwell Automation Technologies, Inc. Implementing serverless functions using container orchestration systems and operational technology devices
US11513877B2 (en) * 2020-09-22 2022-11-29 Rockwell Automation Technologies, Inc. Updating operational technology devices using container orchestration systems
US11989084B2 (en) 2020-09-23 2024-05-21 Honeywell International Inc. Self-healing process control system
US11163551B1 (en) 2020-10-13 2021-11-02 Argo AI, LLC Systems and methods for improved smart infrastructure data transfer
US11537383B2 (en) 2020-10-13 2022-12-27 Argo AI, LLC Systems and methods for improved smart infrastructure data transfer
CN112260893B (zh) * 2020-10-14 2022-04-19 天津津航计算技术研究所 一种基于网络心跳的VxWorks操作系统的以太网冗余装置
US11874938B2 (en) 2020-11-03 2024-01-16 Honeywell International Inc. Admittance mechanism
CN112394714B (zh) * 2020-12-09 2022-04-22 中国船舶工业系统工程研究院 一种基于设备虚拟化的无人艇软件系统
CN112764944A (zh) * 2020-12-31 2021-05-07 哈尔滨宇龙自动化有限公司 一种基于opc ua协议的mom系统自动化设备数据交互集成平台及方法
US11322976B1 (en) * 2021-02-17 2022-05-03 Sas Institute Inc. Diagnostic techniques for monitoring physical devices and resolving operational events
CN113037731B (zh) * 2021-02-27 2023-06-16 中国人民解放军战略支援部队信息工程大学 基于sdn架构和蜜网的网络流量控制方法及系统
CN113162991B (zh) * 2021-04-01 2022-07-12 飞昂创新科技南通有限公司 一种应用于物联网中的扩展冯诺依曼结构的多层网络结构
CN113268884B (zh) * 2021-06-08 2022-05-27 上海交通大学 一种基于资产管理壳的分布式控制系统管控方法
US20220404813A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc. Software defined control system including i/o server services that communicate with containerized services
US20220404799A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc. Software defined process control system and methods for industrial process plants
US20220404808A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc Systems and methods for associating modules in a software defined control system for industrial process plants
EP4327540A1 (de) * 2021-06-16 2024-02-28 Siemens Aktiengesellschaft Verfahren, vorrichtungen, computerprogramm und computerlesbares medium zur verwendung konfigurierbarer logiken für einen modularen aufbau einer technischen anlage
US11960588B2 (en) 2021-06-16 2024-04-16 Fisher-Rosemount Systems, Inc Security services in a software defined control system
US12007747B2 (en) * 2021-06-16 2024-06-11 Fisher-Rosemount Systems, Inc. Software defined process control system and methods for industrial process plants
US20220404807A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc. Systems and Methods for Associating Modules in a Software Defined Control System for Industrial Process Plants
US20220404790A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc. Visualization of a software defined process control system for industrial process plants
US11789428B2 (en) * 2021-06-16 2023-10-17 Fisher-Rosemount Systems, Inc. I/O server services for selecting and utilizing active controller outputs from containerized controller services in a process control environment
US11726933B2 (en) 2021-06-16 2023-08-15 Fisher-Rosemount Systems, Inc. I/O server services configured to facilitate control in a process control environment by containerized controller services
US12001874B2 (en) * 2021-07-13 2024-06-04 Rockwell Automation Technologies Digital engineering secure remote access
US11863560B2 (en) 2021-07-15 2024-01-02 Rockwell Automation Technologies, Inc. Industrial automation secure remote access
US20230053594A1 (en) * 2021-08-20 2023-02-23 Yokogawa Electric Corporation Distributive deployment of process automation software applications
EP4142212A1 (de) * 2021-08-24 2023-03-01 Siemens Aktiengesellschaft Automatisierungssystem mit mindestens einer komponente mit mindestens einer app und fertigungsanlage
CN113917897B (zh) * 2021-09-26 2024-04-02 西门子能源自动化(南京)有限公司 用于对电厂进行操作和监视的装置及其实施方法
EP4174651A1 (en) * 2021-10-26 2023-05-03 Abb Schweiz Ag Orchestrating deterministic workload execution
US20230142107A1 (en) * 2021-11-05 2023-05-11 Dragos, Inc. Data pipeline management in operational technology hardware and networks
US11646935B1 (en) * 2021-12-02 2023-05-09 Charter Communications Operating, Llc Automated provisioning and configuration for dynamically loaded NFV- and SDN-based networks
EP4198663A1 (de) * 2021-12-16 2023-06-21 Schneider Electric Industries SAS Verfahren zum verteilten berechnen von berechnungsaufgaben
CN114460892B (zh) * 2021-12-20 2022-11-01 北京科技大学 一种基于云化可编程逻辑控制器的任务控制方法
EP4206831A1 (de) 2021-12-29 2023-07-05 Siemens Aktiengesellschaft Verfahren und system zur bereitstellung von zeitkritischen steuerungsanwendungen
CN114513404B (zh) * 2021-12-30 2023-11-03 网络通信与安全紫金山实验室 时间敏感网络的配置方法、装置及计算机可读存储介质
IT202200000803A1 (it) * 2022-01-19 2023-07-19 Filippetti S P A Sistema di controllo di una stanza.
CN114115753B (zh) * 2022-01-28 2022-04-26 苏州浪潮智能科技有限公司 一种存储设备、基于存储设备的请求处理方法及装置
CN115037631B (zh) * 2022-05-13 2023-08-22 北京中科晶上科技股份有限公司 基于集群的网络仿真方法、装置和网络仿真系统
US11886325B2 (en) * 2022-06-30 2024-01-30 Browserstack Limited Network status simulation for remote device infrastructure
CN115190186A (zh) * 2022-07-07 2022-10-14 宁波三星医疗电气股份有限公司 电能表信息上报方法、电能表和存储介质
US12003594B2 (en) * 2022-07-19 2024-06-04 Rockwell Automation Technologies, Inc. Systems and methods for network discovery in a multi-layer operational technology network
US20240053741A1 (en) * 2022-08-11 2024-02-15 Fisher-Rosemount Systems, Inc. Methods and apparatus to perform process analyses in a distributed control system
CN115378822B (zh) * 2022-08-19 2023-06-06 武汉烽火技术服务有限公司 一种dds分布式应用仿真的方法和系统
US11947342B1 (en) 2022-09-19 2024-04-02 Rockwell Automation Technologies, Inc. Container registry and subscription service for industrial systems
US11846918B1 (en) 2022-09-22 2023-12-19 Rockwell Automation Technologies, Inc. Data driven digital twins for industrial automation device operation enhancement
US11860771B1 (en) 2022-09-26 2024-01-02 Browserstack Limited Multisession mode in remote device infrastructure
CN115576904B (zh) * 2022-10-09 2023-08-11 北京凯锐远景科技有限公司 一种ids三维模型解析方法
WO2024081670A1 (en) * 2022-10-10 2024-04-18 Schneider Electric USA, Inc. Management system for infrastructure of an industrial system
WO2024091217A1 (en) * 2022-10-24 2024-05-02 Rakuten Mobile, Inc. System, method, and computer program for managing deployment of network element
CN116974654B (zh) * 2023-09-21 2023-12-19 浙江大华技术股份有限公司 一种图像数据的处理方法、装置、电子设备及存储介质

Family Cites Families (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5694546A (en) * 1994-05-31 1997-12-02 Reisman; Richard R. System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list
DK1264221T3 (da) * 2000-03-10 2005-10-03 Smiths Detection Inc Styring af en industriel proces ved brug af en eller flere flerdimensionale variabler
WO2003096669A2 (en) * 2002-05-10 2003-11-20 Reisman Richard R Method and apparatus for browsing using multiple coordinated device
US7058712B1 (en) 2002-06-04 2006-06-06 Rockwell Automation Technologies, Inc. System and methodology providing flexible and distributed processing in an industrial controller environment
US7151966B1 (en) 2002-06-04 2006-12-19 Rockwell Automation Technologies, Inc. System and methodology providing open interface and distributed processing in an industrial controller environment
US8776050B2 (en) * 2003-08-20 2014-07-08 Oracle International Corporation Distributed virtual machine monitor for managing multiple virtual resources across multiple physical nodes
CA2601384A1 (en) * 2005-03-16 2006-10-26 Cluster Resources, Inc. Automatic workload transfer to an on-demand center
US7840683B2 (en) * 2006-08-31 2010-11-23 Sap Ag Systems and methods of migrating sessions between computer systems
US20100049336A1 (en) * 2007-01-25 2010-02-25 Schneider Electric Automation Gmbh Automation system comprising an implemented engineering-environment
CN100524125C (zh) * 2007-08-02 2009-08-05 上海可鲁系统软件有限公司 一种用于自动化系统远程监控与维护的解决方法
EP2359203B1 (en) 2008-11-24 2015-10-28 ABB Research Ltd. A method for providing control and automation services
US8532116B2 (en) * 2009-07-21 2013-09-10 Cisco Technology, Inc. Extended subnets
US8234377B2 (en) * 2009-07-22 2012-07-31 Amazon Technologies, Inc. Dynamically migrating computer networks
EP2293164A1 (en) * 2009-08-31 2011-03-09 ABB Research Ltd. Cloud computing for a process control and monitoring system
GB2474545B (en) 2009-09-24 2015-06-24 Fisher Rosemount Systems Inc Integrated unified threat management for a process control system
EP2325748A1 (en) 2009-10-23 2011-05-25 ABB Research Ltd. Industrial automation system architecture
US8645977B2 (en) * 2010-02-04 2014-02-04 Microsoft Corporation Extensible application virtualization subsystems
CN101794226B (zh) * 2010-03-08 2012-11-07 山东大学 一种适应多业务抽象层次的服务化软件构造方法和系统
CN101887381A (zh) * 2010-06-22 2010-11-17 北京伟库电子商务科技有限公司 基于Quartz框架的配置定时任务的方法和装置
ES2567726T3 (es) 2011-08-01 2016-04-26 Huawei Technologies Co., Ltd. Método de configuración de política de red, dispositivo de gestión y dispositivo de centro de gestión de red
US9106511B1 (en) * 2011-08-22 2015-08-11 Star2Star Communications, LLC Systems and methods for optimizing application data delivery over third party networks
DE102011053757A1 (de) * 2011-09-19 2013-03-21 Schneider Electric Automation Gmbh Verfahren zur Generierung und Handhabung von Applikationen für Komponenten eines Steuerungssytems
US8762992B2 (en) 2011-12-22 2014-06-24 Symantec Corporation Systems and methods for protecting virtual machines during physical-to-virtual conversions
US8730980B2 (en) * 2011-12-27 2014-05-20 Cisco Technology, Inc. Architecture for scalable virtual network services
US9292312B2 (en) 2012-03-22 2016-03-22 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Simulated network boot environment for bootstrap redirection
CN102857363B (zh) * 2012-05-04 2016-04-20 运软网络科技(上海)有限公司 一种虚拟网络的自主管理系统和方法
US8984134B2 (en) * 2012-05-07 2015-03-17 International Business Machines Corporation Unified cloud computing infrastructure to manage and deploy physical and virtual environments
US9396008B2 (en) * 2012-07-13 2016-07-19 Ca, Inc. System and method for continuous optimization of computing systems with automated assignment of virtual machines and physical machines to hosts
CN102749885B (zh) * 2012-07-18 2014-08-06 石毅 云数控系统
KR20140032262A (ko) * 2012-09-06 2014-03-14 엘지전자 주식회사 가전제품 및 이를 포함하여 이루어지는 온라인 시스템
US20150236901A1 (en) 2012-10-04 2015-08-20 Mitsubishi Electric Corporation Control system management apparatus
US8954780B1 (en) 2012-10-11 2015-02-10 Symantec Corporation Systems and methods for transferring input/output operations within computer clusters
US10404562B2 (en) * 2012-10-22 2019-09-03 Texas State University Optimization of retransmission timeout boundary
CN103064702A (zh) * 2012-12-13 2013-04-24 中国电信股份有限公司云计算分公司 应用程序提供方法及管理节点设备
CN103067388A (zh) * 2012-12-28 2013-04-24 丁卓 云计算基础架构资源自动化方法及系统
EP2778816B1 (en) 2013-03-12 2015-10-07 ABB Technology AG System and method for testing a distributed control system of an industrial plant
EP2790101B1 (en) 2013-04-10 2016-01-20 ABB Technology AG System and method for automated virtual commissioning of an industrial automation system
RU2543962C2 (ru) * 2013-04-23 2015-03-10 Федеральное Государственное Автономное Образовательное Учреждение Высшего Профессионального Образования "Московский Физико-Технический Институт (Государственный Университет)" Аппаратно-вычилистельный комплекс виртуализации и управления ресурсами в среде облачных вычислений
US9709978B2 (en) * 2013-05-09 2017-07-18 Rockwell Automation Technologies, Inc. Using cloud-based data for virtualization of an industrial automation environment with information overlays
US10026049B2 (en) * 2013-05-09 2018-07-17 Rockwell Automation Technologies, Inc. Risk assessment for industrial systems using big data
ES2764212T3 (es) 2013-06-19 2020-06-02 Schneider Electric Ind Sas Solución Ethernet universal
US9450823B2 (en) * 2013-08-09 2016-09-20 Nec Corporation Hybrid network management
US9430256B2 (en) * 2013-08-13 2016-08-30 Vmware, Inc. Method and apparatus for migrating virtual machines between cloud computing facilities using multiple extended local virtual networks and static network addresses
EP3042254B1 (en) 2013-09-03 2018-05-30 Siemens Aktiengesellschaft Systems and methods for virtualizing a programmable logic controller
FR3010540B1 (fr) 2013-09-10 2015-08-14 Schneider Electric Ind Sas Systeme d'automatisme comprenant plusieurs controleurs logiques programmables connectes sur un reseau de communication
US9628384B2 (en) 2013-09-19 2017-04-18 Avago Technologies General Ip (Singapore) Pte. Ltd. Adaptive industrial network
IN2013CH05013A (es) 2013-11-07 2015-05-08 Schneider Electric It Corp
US9461923B2 (en) * 2013-12-06 2016-10-04 Algoblu Holdings Limited Performance-based routing in software-defined network (SDN)
US9197569B2 (en) 2013-12-06 2015-11-24 Algoblu Holdings Limited Hierarchical control in software-defined network (SDN)
GB2521376A (en) * 2013-12-17 2015-06-24 Intellisense Io Ltd System and method for securely managing data of industrial control systems
US9866501B2 (en) 2013-12-31 2018-01-09 Schneider Electric Systems Usa, Inc. Virtual switch enabling communication between external objects and simulation objects
US9632835B2 (en) * 2014-03-17 2017-04-25 Ca, Inc. Deployment of virtual machines to physical host machines based on infrastructure utilization decisions
US9614963B2 (en) 2014-03-26 2017-04-04 Rockwell Automation Technologies, Inc. Cloud-based global alarm annunciation system for industrial systems
US9733975B2 (en) * 2014-04-03 2017-08-15 Centurylink Intellectual Property Llc System and method for implementing network experience shifting
BR112016023577B1 (pt) * 2014-04-14 2023-05-09 Huawei Technologies Co., Ltd Aparelho e método para configurar solução de redundância em arquitetura de computação em nuvem
US9912737B2 (en) 2014-08-27 2018-03-06 Exxonmobil Research And Engineering Company Method and system for modular interoperable distributed control
US10374887B2 (en) 2014-08-27 2019-08-06 Assia Spe, Llc Systems, methods, and apparatuses for implementing the virtualization of access node functions
US9882797B2 (en) * 2014-10-30 2018-01-30 International Business Machines Corporation Enabling software-defined control in passive optical networks
CN104636204B (zh) * 2014-12-04 2018-06-01 中国联合网络通信集团有限公司 一种任务调度方法与装置
CN104850450B (zh) * 2015-05-14 2017-11-28 华中科技大学 一种面向混合云应用的负载均衡方法及系统
US10511485B2 (en) * 2015-08-11 2019-12-17 At&T Intellectual Property I, L.P. Dynamic virtual network topology discovery engine

Also Published As

Publication number Publication date
US20180316729A1 (en) 2018-11-01
ES2972422T3 (es) 2024-06-12
EP3362895A1 (en) 2018-08-22
CA3001782A1 (en) 2017-04-20
EP3926475A1 (en) 2021-12-22
AU2024202727A1 (en) 2024-05-16
US20210356944A1 (en) 2021-11-18
CN108369533A (zh) 2018-08-03
EP4202681A1 (en) 2023-06-28
CN108885560A (zh) 2018-11-23
AU2016339061B2 (en) 2022-01-27
AU2016337406A1 (en) 2018-05-17
EP3362896A1 (en) 2018-08-22
EP3362896B1 (en) 2023-02-22
AU2022201372A1 (en) 2022-03-24
AU2016339067A1 (en) 2018-05-17
US11079744B2 (en) 2021-08-03
WO2017064560A8 (en) 2018-07-12
US20180024537A1 (en) 2018-01-25
WO2017064554A8 (en) 2018-09-27
RU2747966C2 (ru) 2021-05-18
RU2729885C2 (ru) 2020-08-13
CN108513655B (zh) 2022-06-03
US11579595B2 (en) 2023-02-14
CN108513655A (zh) 2018-09-07
WO2017064560A1 (en) 2017-04-20
CA3001801A1 (en) 2017-04-20
AU2016339061A1 (en) 2018-05-17
RU2018117282A (ru) 2019-11-14
AU2022201372B2 (en) 2023-05-11
EP3362895B1 (en) 2024-01-10
AU2022203956A1 (en) 2022-06-23
RU2018117284A3 (es) 2020-05-22
CN108885560B (zh) 2022-07-08
EP3362897A1 (en) 2018-08-22
RU2018117280A3 (es) 2020-03-12
US11953890B2 (en) 2024-04-09
WO2017064565A1 (en) 2017-04-20
AU2016339067B2 (en) 2022-03-10
RU2018117282A3 (es) 2020-04-16
US10845786B2 (en) 2020-11-24
CA3001790A1 (en) 2017-04-20
AU2023214270A1 (en) 2023-08-31
WO2017064554A1 (en) 2017-04-20
US20230161332A1 (en) 2023-05-25
RU2018117284A (ru) 2019-11-14
US20180299873A1 (en) 2018-10-18
RU2018117280A (ru) 2019-11-14
RU2730534C2 (ru) 2020-08-24

Similar Documents

Publication Publication Date Title
ES2941337T3 (es) Sistema y arquitectura de automatización definidos por software
ES2908461T3 (es) Arquitectura de red industrial definida por software para despliegue en un sistema de automatización definido por software
EP3469482B1 (en) Method and system for providing proxy service in an industrial system