ES2972422T3 - Procedimiento para organizar las cargas de trabajo en un sistema de automatización definido por software - Google Patents

Procedimiento para organizar las cargas de trabajo en un sistema de automatización definido por software Download PDF

Info

Publication number
ES2972422T3
ES2972422T3 ES16795135T ES16795135T ES2972422T3 ES 2972422 T3 ES2972422 T3 ES 2972422T3 ES 16795135 T ES16795135 T ES 16795135T ES 16795135 T ES16795135 T ES 16795135T ES 2972422 T3 ES2972422 T3 ES 2972422T3
Authority
ES
Spain
Prior art keywords
network
automation
tasks
software
sda
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
ES16795135T
Other languages
English (en)
Inventor
Antonio Chauvet
Philippe Wilhelm
Merrill Harriman
Andrew Lee Kling
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 ES2972422T3 publication Critical patent/ES2972422T3/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 definida por software (SDA) que proporciona una arquitectura de referencia para diseñar, gestionar y mantener un sistema de automatización altamente disponible, escalable y flexible. Se divulga un método para organizar cargas de trabajo en un sistema SDA que incluye determinar tareas de funciones predeterminadas del dispositivo, evaluar parámetros operativos industriales para cada tarea de las funciones del dispositivo; y clasificar las tareas según los parámetros operativos industriales. El método continúa distribuyendo tareas entre dispositivos de automatización en función de los parámetros operativos industriales. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento para organizar las cargas de trabajo en un sistema de automatización definido por softwareANTECEDENTES
La automatización es el uso de dispositivos de control automático y diversas tecnologías para automatizar la supervisión, el funcionamiento y el control de procedimientos e instalaciones sin intervención humana significativa para lograr un rendimiento superior al control manual. Los sistemas de automatización conocidos para supervisar y controlar procedimientos e instalaciones (p. ej., en plantas, edificios, etc.) suelen incluir varios dispositivos de automatización, como controladores (p. ej., controladores lógicos programables (PLC), controladores de automatización programables (PAC)), dispositivos de entrada/salida (dispositivos de E/S), dispositivos de campo (p. ej., sensores y actuadores), ordenadores personales (PC), interfaces hombre-máquina (HMI) y similares. Los controladores ejecutan programas definidos por el usuario para controlar procedimientos automatizados. Normalmente, en un sistema de control, los controladores leen los datos de entrada de los dispositivos de campo, como sensores y dispositivos de medición, y utilizan los datos de entrada para generar salidas de control basadas en los programas definidos por el usuario. El Documento GB 2521 376 A se refiere a un sistema y un procedimiento para gestionar de forma segura los datos de los sistemas de control industrial. El Documento EP 2 293 164 A1 se refiere a la computación en nube para un sistema de control y supervisión de procedimientos. El Documento EP 2 801 942 A1 se refiere a la evaluación de riesgos para sistemas industriales utilizando big data.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Figura 1 es un diagrama de bloques que ilustra aspectos de una tecnología automática definida por software ("SDA") de acuerdo con algunas realizaciones.
La Figura 2A es un diagrama de bloques que ilustra un ejemplo de arquitectura de un sistema de automatización tradicional implantado en algunas industrias.
La Figura 2B es un diagrama de bloques que ilustra un ejemplo de arquitectura de un sistema automáticamente simplificado y flexible de acuerdo con algunas realizaciones.
La Figura 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 Figura 4 es un diagrama que ilustra una arquitectura simplificada de un sistema SDA de acuerdo con algunas realizaciones.
La Figura 5 es un diagrama de bloques que ilustra una arquitectura funcional de SDA de acuerdo con algunas realizaciones.
La Figura 6A es un diagrama de bloques que ilustra subsistemas de un sistema SDA de acuerdo con algunas realizaciones.
La Figura 6B es un diagrama que ilustra el alcance del control de cada uno de los subsistemas SDA de acuerdo con algunas realizaciones.
La Figura 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 Figura 7B es un diagrama de bloques que ilustra componentes de ejemplo ilustrativos de un software de un sistema SDA de acuerdo con algunas realizaciones.
Las Figuras 7C-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 Figura 8A es un diagrama de bloques que ilustra componentes de servidor de niebla ejemplares de acuerdo con una primera realización.
La Figura 8B es un diagrama de bloques que ilustra componentes de servidor de niebla ejemplares de acuerdo con una segunda realización.
La Figura 9A es un diagrama de bloques que ilustra componentes de un controlador de un servidor de niebla ejemplares de acuerdo con algunas realizaciones.
La Figura 9B es un diagrama de bloques que ilustra componentes ejemplares de un nodo informático que aloja máquinas virtuales de acuerdo con algunas realizaciones.
La Figura 9C es un diagrama de bloques que ilustra componentes ejemplares de un nodo informático que aloja recipientes de acuerdo con algunas realizaciones.
La Figura 9D es un diagrama de bloques que ilustra componentes ejemplares de un nodo informático que aloja recipientes de acuerdo con una segunda realización.
La Figura 9E es un diagrama de bloques que ilustra componentes ejemplares de un nodo informático que aloja una imagen metal desnudo.
La Figura 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 Figura 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 Figura 11 es un diagrama de bloques que ilustra un ejemplo de orquestación de subsistemas SDA para aprovisionar una unidad funcional en un nodo informático de acuerdo con algunas realizaciones.
La Figura 12 es un diagrama de flujo lógico que ilustra un procedimiento ejemplar para crear un sistema de automatización de acuerdo con algunas realizaciones.
La Figura 13A es un diagrama de flujo lógico que ilustra un procedimiento ejemplar para añadir una unidad funcional a un sistema de automatización a través de un software de sistema de acuerdo con algunas realizaciones.
La Figura 13B representa un ejemplo de una vista topológica de un sistema transportador de acuerdo con algunas realizaciones.
La Figura 14 es un diagrama de flujo lógico que ilustra un procedimiento ejemplar para proporcionar una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
La Figura 15 es un diagrama de flujo lógico que ilustra un procedimiento ejemplar para configurar una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
La Figura 16Aes un diagrama de flujo lógico que ilustra un procedimiento ejemplar para definir un sistema de automatización a través de un software de acuerdo con algunas realizaciones.
La Figura 16Bes un diagrama de flujo lógico que ilustra un procedimiento ejemplar para ordenar o proporcionar una unidad funcional en un sistema SDAde acuerdo con algunas realizaciones.
La Figura 17A es un diagrama de bloques que ilustra un ejemplo de un sistema de automatización en el que puede configurarse una función de automatización de acuerdo con una primera realización.
La Figura 17B es un diagrama de bloques que ilustra otro ejemplo de un sistema de automatización en el que puede configurarse una función de automatización de acuerdo con una segunda realización.
La Figura 17C es un diagrama de bloques que ilustra otro ejemplo de un sistema de automatización en el que puede configurarse una función de automatización de acuerdo con una tercera realización.
La Figura 18 es un diagrama de flujo lógico que ilustra un ejemplo de un procedimiento de acuerdo con una primera realización.
La Figura 19 es un diagrama de flujo lógico que ilustra un ejemplo de un procedimiento de acuerdo con una segunda realización.
La Figura 20 es un diagrama de flujo lógico que ilustra un ejemplo de una parte de los procedimientos de las FIGS. 18 y 19 con más detalle.
La Figura 21 es un diagrama de flujo lógico que ilustra un ejemplo de una parte de los procedimientos de las FIGS. 18 y 19 con más detalle.
La Figura 22 es un diagrama de flujo lógico que ilustra un ejemplo de una parte de los procedimientos de las FIGS. 18 y 19 con más detalle.
La Figura 23 es un diagrama de flujo lógico que ilustra un ejemplo de una parte de los procedimientos de las FIGS. 18 y 19 con más detalle.
La Figura 24 muestra una representación diagramática de una máquina en la forma ejemplar de un sistema informático dentro del cual puede ejecutarse un conjunto de instrucciones, para hacer que la máquina realice una o más de las metodologías discutidas en la presente memoria .
DESCRIPCIÓN DETALLADA
1. Descripción general
Esta divulgación describe la tecnología y el sistema de Automatización Definida por Software (en adelante en la presente memoria "SDA") (en adelante en la presente memoria "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 procedimientos para organizar cargas de trabajo en un sistema SDA.
En algunas realizaciones, la tecnología SDA permite que los sistemas de control y el software asociado se ejecuten dentro de una plataforma de niebla o una nube privada. Se pueden encontrar sistemas de control de diversos grados de complejidad en instalaciones de fabricación tradicionales, refinerías, submarinos, vehículos, túneles, sistemas de manipulación de equipajes, sistemas de gestión de la energía, sistemas de gestión de edificios, sistemas de control de aguas de inundación, sistemas de control de la red eléctrica y similares. Al trasladar todo el sistema o sistemas de control, o al menos una parte de ellos, a una plataforma de niebla o a una nube privada, y proporcionar una interfaz de software a los elementos del sistema de control, la tecnología SDA permite realizar las tareas de ingeniería de todo el ciclo de vida de la ingeniería de automatización, como el diseño, la programación, la configuración, la instalación, 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 conectados inteligentes 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 anfitrión (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 anfitriones (por ejemplo, máquinas virtuales, recipientes, metales desnudos) en un servidor, en un controlador de automatización físico, un sistema incrustado y similares. La distribución puede iniciarse por varias razones, por ejemplo, para optimizar el rendimiento, para actualizar el hardware, etc. Por ejemplo, una aplicación con grandes requisitos informáticos puede desplegarse para su ejecución en un recurso informático capaz de proporcionar los recursos informáticos necesarios. Del mismo modo, una aplicación con restricciones de tiempo críticas puede desplegarse en un recurso informático 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 backplane 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 utilizar una o más tecnologías de red, como redes definidas por software (SDN), redes sensibles al tiempo (TSN) y/o similares en algunas realizaciones. La SDN permite configurar y reconfigurar de forma más sencilla los elementos de red, entre los que se incluyen conmutadores y enrutadores, así como cualquier otro nodo que desempeñe una función similar, sin tener que acceder a cada dispositivo físico. Por ejemplo, el controlador SDN centralizado lógicamente puede acceder a cada dispositivo de red mediante 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 pueden conectarse a la red, generar datos y ejecutar una función. Los dispositivos conectados inteligentes son conscientes de su contexto operativo y, como tales, pueden tomar decisiones inteligentes y adaptar su comportamiento en consecuencia. Por ejemplo, consideremos un sensor 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 conectado inteligente. 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 conectados inteligentes 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, puede describirse 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), ya 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), ya 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 utilizando un teléfono inteligente, portátil, ordenador personal, ordenador tipo tableta y/u otro dispositivo cliente. También puede tratarse de datos/información como 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 anfitriones para ejecutar aplicaciones bajo demanda, integradas o no.
La FIG. 2A representa una arquitectura de sistema de automatización tradicional ampliamente implantada en muchas industrias. En la arquitectura tradicional del sistema de automatización, los dispositivos de automatización en el nivel 2 (por ejemplo, PLC 230A-C) están conectados a través de redes de dispositivos 235A-C para permitir que los dispositivos de automatización (por ejemplo, dispositivos de campo 225A-C) en el nivel 1 sean controlados por los PLC 230A-C respectivamente. Del mismo modo, los PLC 230A-C en el nivel 2 y las estaciones de ingeniería 240 y los servidores de procedimientos 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-C y acceder a los datos de procedimiento 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 empresa puede incluir servidores de sistema/empresa 260 que están conectados a las estaciones de ingeniería 240 y a los servidores de procedimiento e historiador 245 en el nivel de la sala de control 210 a través de la red de 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 varios 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-C se representa como teniendo su propia red de dispositivos 235A-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 constar de cientos de dispositivos de automatización (o equipos de automatización) y procedimientos gestionados por otras tantas aplicaciones. Por ejemplo, los PLC se programan utilizando 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. La agregación en un solo lugar de grandes cantidades de diferentes tipos y conjuntos de datos generados por distintas 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, pueden tomarse 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 nuevamente.
La tecnología SDA descrita en la presente memoria supera estos y otros inconvenientes de la arquitectura del sistema de automatización tradicional transformando 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 considerablemente 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,<p>L<c>, dispositivos de procedimiento 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 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 a servidores 285 (por ejemplo, mediante la creación de un PLC virtual que es una implementación de software de un PLC en un host como una máquina virtual o un recipiente) y la red se puede configurar automáticamente para asegurar que el tráfico desde el PLC virtual ("vPLC") en el servidores 285 fluye a los dispositivos de E/S en la unidad funcional 275B de manera oportuna para supervisar y/o controlar los dispositivos de entrada/salida o los dispositivos de campo. Algunos ejemplos no limitantes de dispositivos de entrada incluyen: sensores, dispositivos de medición, interruptor de presión, interruptor de nivel, y similares. Del mismo modo, algunos ejemplos no limitantes 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 pueden integrarse 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 (IT) 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 puede ampliarse 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 procedimiento 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. Tal y 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 informático 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. Tal y como se en la presente memoria, "nube" se refiere a las tecnologías utilizadas, más que a la ubicación física de la infraestructura. Por ejemplo, en la industria de la automatización, pueden utilizarse arquitecturas con una o más nubes "on premise".
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 utilizando 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 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 utilizando mecanismos semánticos y de descubrimiento (por ejemplo, basados en estándares de la Industria).
La arquitectura más plana puede proporcionar muchas 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 en 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, ya 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 anteriores. 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 gran escala de este tipo. 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 la recuperación de datos, puede controlarse mediante un sistema<s>D<a>y pueden realizarse ajustes para optimizar el rendimiento operativo. Del mismo modo, la salud de los componentes puede ser supervisada 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 mediante una respuesta coordinada en varios frentes, incluyendo 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 pueden mejorarse permitiendo el diagnóstico de fallos y la redundancia.
Estos y varios otros aspectos del sistema SDA incluyendo varios componentes, características, ventajas y aplicaciones serán ahora discutidos en detalle.
2. Arquitecturas SDA
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 informáticos que están interconectados para crear un sistema lógicamente centralizado pero potencialmente distribuido físicamente para alojar los sistemas de automatización de una empresa. El "servidor de niebla" o la "plataforma de niebla", tal y como se utiliza en la presente memoria es un sistema de gestión de la nube (o subsistema localizado o sistema localizado) que se ha localizado en uno o más nodos informáticos 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 informáticos y/o control para gestionar todo el sistema de automatización o una parte del mismo. El servidor de niebla 405 permite la virtualización al proporcionar una infraestructura de virtualización en la que se pueden ejecutar y/o gestionar los sistemas de automatización. La infraestructura de virtualización incluye nodos informáticos que ejecutan anfitriones tal como máquinas virtuales, recipientes y/o metales desnudos (o imágenes de metal desnudo).
Los anfitriones, a su vez, pueden ejecutar invitados que incluyen aplicaciones y/o implementaciones de software de componentes físicos o unidades funcionales y un portal de automatización o software del sistema 440. Tal y como se utiliza en la presente memoria, la virtualización es la creación de una versión virtual de algo. Por ejemplo, un componente virtual o un componente virtualizado (por ejemplo, un PLC virtual, un conmutador virtual, virtualización de funciones de red (NFV)) representa una función que se ejecuta en un anfitrión que se ejecuta en un nodo informático. 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 pueden considerarse 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 gestionando la distribución de las aplicaciones/funciones de la aplicación donde los usuarios quieren que se ejecuten.
Los dispositivos conectados inteligentes 415A, 415B (también productos conectados inteligentes) supervisan y/o controlan dispositivos, sensores y/o accionadores cercanos a los equipos/materias primas/entorno mediante la ejecución de aplicaciones/funciones de aplicación. En varias realizaciones, un dispositivo inteligente conectado tiene las siguientes características: (1) los componentes físicos y eléctricos, (2) el firmware o una parte "inteligente" incorporada, y (3) la conectividad y la interoperabilidad. En algunas realizaciones, un dispositivo inteligente conectado puede tener también un componente de ciberseguridad que puede operarse 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 realizar sus funciones. Esto tiene la ventaja de un tiempo de respuesta más rápido (es decir, menos latencia) y un ahorro en el ancho de banda de la red. Otra ventaja de la ejecución local o a bordo de las aplicaciones es que mejora la consistencia de los datos y la robustez de la arquitectura, ya que el dispositivo puede seguir produciendo información (por ejemplo, alarmas) o registrando datos aunque la red esté caída.
En algunas realizaciones, los dispositivos inteligentes conectados 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, llamadas a procedimientos remotos, interfaz de programación de aplicaciones o llamadas API) como si una aplicación se ejecutara localmente, cuando en realidad la aplicación se ejecuta remotamente, por ejemplo en el servidor de niebla 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 supervisados) 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 realizar análisis operativos sobre ellos. Los dispositivos inteligentes conectados 415A, 415B pueden entonces combinar las funciones de supervisió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 distintos equipos de una planta pueden conectarse entre sí y con el sistema de la empresa (por ejemplo, MES o ERP) utilizando tecnologías basadas en diversos estándares tal como: Ethernet, TCP/IP, web y/o tecnologías de software. La red troncal de comunicaciones 226 en forma de red troncal global unificada de Ethernet Industrial puede proporcionar: un fácil acceso a los datos, desde la planta (OT) hasta las aplicaciones empresariales (IT), una forma flexible de definir diferentes tipos de arquitecturas de red (por ejemplo, estrellas, cadena tipo margarita, anillo) que se ajusten a las necesidades del cliente, una arquitectura robusta que pueda cumplir requisitos como la disponibilidad, la seguridad y el soporte de entornos difíciles y la información correcta a las personas adecuadas en el momento adecuado en un solo cable.
La red troncal de comunicaciones 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 supervisión y la configuración utilizando páginas web estándar y la arquitectura de referencia de integración de dispositivos que define los patrones, el ladrillo para integrar el grupo de dispositivos a los controladores a nivel de aplicación y a nivel de red para la configuración, el ajuste y el diagnóstico. En algunas realizaciones, los elementos de ciberseguridad pueden incorporarse a la arquitectura. La red troncal de comunicaciones 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 utilizar múltiples protocolos para proporcionar múltiples servicios para satisfacer múltiples necesidades. En la tabla 1 se enumeran algunos ejemplos de necesidades de comunicación y protocolos adecuados.
Tabla 1 Servicios y Protocolos
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). La tecnología SDN permite separar la lógica de control de una red del hardware o dispositivo de red subyacente (por ejemplo, conmutadores, enrutadores) y la centralización lógica del control de la red. La tecnología SDN puede aportar simplicidad y flexibilidad a estas redes, permitiendo la comunicación en y a través de diferentes capas dirigidas por políticas de red. La tecnología TSN añade un conjunto de capacidades a la Ethernet estándar para proporcionar capacidad en tiempo real e intercambios con garantía de tiempo en zonas o en toda la arquitectura. Además, la solución de ciberseguridad también puede integrarse y adaptarse a la arquitectura SDA.
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 informáticos (por ejemplo, la supervisión, la gestión de otras aplicaciones y/o recursos), y similares. Esta vista funcional de la arquitectura s Da se representa en la FIG. 5.
La vista funcional ejemplar 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 utilizan y gestionan un conjunto de recursos del sistema. El plano de control 580 incluye un conjunto de controladores que incluyen un controlador de servidor de niebla 510, un controlador de SDN 590A/controlador de TSN 590B (o controlador de red) y un controlador de 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 de SDN 590A/TSN 590B gestiona y distribuye las políticas de red al nivel de sistema. De manera similar, el controlador de CS 555 refuerza las políticas de seguridad 565 al nivel del sistema.
En algunas realizaciones, estos controladores pueden tener una relación jerárquica entre sí. Por ejemplo, un sistema SDA puede incluir un controlador de nivel superior (no mostrado) y un conjunto de controladores centralizados (por ejemplo, el controlador de servidor de niebla 510, los controladores de red 590A, 590B y el controlador de 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 informáticos representados por nodos informáticos 515, recursos de almacenamiento 525 y recursos de seguridad 595. El software del sistema 540 y las aplicaciones 535 se ejecutan en los nodos informáticos 515 gestionados por el controlador de niebla 510. Los nodos informáticos 515 que proporcionan los recursos informáticos al sistema pueden estar físicamente distribuidos y gestionados por el controlador de niebla 510. Por ejemplo, algunos nodos informáticos en forma de servidores se encuentran en el servidor de niebla o en la nube privada, mientras que otros nodos informáticos, como los dispositivos inteligentes conectados, operan en el borde. Los recursos de red 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 informáticos 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 supervisan algunos o todos los recursos del sistema. Las aplicaciones que gestionan el sistema (por ejemplo, el software del sistema 540 o el portal de automatización, la herramienta de administración de la red, etc.) envían solicitudes al sistema para aplicar estrategias específicas. Por ejemplo, el software del sistema 334 puede utilizarse para desplegar un nuevo PLC conectado a un conjunto de dispositivos con requisitos específicos de red en tiempo real, requisitos de seguridad y requisitos de disponibilidad/resiliencia. En algunas realizaciones, las aplicaciones corresponden a implementaciones de software/firmware de los componentes. Estas aplicaciones pueden desplegarse en recursos informáticos y pueden utilizar recursos de almacenamiento y de red para comunicarse.
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 Figura 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 de servidor de niebla 605 ("servidor de niebla") que tiene un controlador de niebla o controladores de niebla redundantes 610, uno o más nodos informáticos 615 y almacenamiento 625. El sistema SDA 600 también incluye un subsistema de componentes de software 630. En otras realizaciones, el sistema SDA 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 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 685.
El servidor de niebla 605 proporciona un entorno de virtualización en el que se ejecutan y/o gestionan los sistemas de automatización. El servidor de niebla 605 comprende nodos informáticos 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 limitantes de nodos informáticos incluyen: servidores, ordenadores personales, dispositivos de automatización incluyendo dispositivos inteligentes conectados y similares.
El controlador del servidor de niebla 610 utiliza un software de gestión del servidor de niebla para realizar sus funciones. El software de gestión del servidor de niebla puede basarse en un software de gestión de la nube como OpenStack. El software de gestión de la nube, como OpenStack, en su forma estándar/listo para la venta, suele utilizarse en el mundo de las tecnologías de la información (TI) para la gestión de los centros de datos. Sin embargo, la gestión de los sistemas de automatización implica una serie de retos diferentes. Por ejemplo, algunos sistemas de automatización pueden ejecutar aplicaciones críticas para el tiempo y/o la seguridad que necesitan garantías deterministas con respecto al retraso, la fiabilidad y/u otros factores. La consideración de un sistema automatizado de corte de queso en el que un movimiento sincronizado de alta velocidad entre una hoja de cuchillo que corta un bloque de queso y el movimiento del bloque de queso es fundamental para producir rebanadas de queso de espesor uniforme. Si hay algún retraso en el procesamiento o en la red, puede dar lugar a que las rebanadas de queso tengan un espesor diferente, lo que supone un desperdicio y una pérdida de productividad.
El controlador del servidor de niebla 610 gestiona todos los aspectos del entorno de virtualización y el ciclo de vida completo de los nodos informáticos 615. Por ejemplo, el servidor de niebla 605 puede levantar y retirar anfitriones como máquinas virtuales, recipientes o metales desnudos en nodos informáticos, y crear y destruir componentes virtualizados 645 y redes virtuales 620. Un componente/elemento/instancia virtualizado 645, tal y como se utiliza en la presente memoria, es un equivalente lógico de un dispositivo físico o una parte del dispositivo físico que representa, implementado como una entidad de software para ejecutarse dentro del servidor de niebla 605. Los componentes virtualizados 645 también pueden incluir componentes de software como aplicaciones y/o funciones de aplicación que se ejecutan en un anfitrión (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 informáticos. El controlador también puede gestionar la puesta en marcha, el apagado y la aplicación de parches de los distintos nodos informáticos. En algunas realizaciones, la plataforma de servidor de niebla puede proporcionar soporte para la alta disponibilidad de los componentes virtualizados. En algunas realizaciones, el servidor de niebla 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 utilizan para programar, configurar, gestionar o establecer una interfaz de otro modo con los dispositivos de automatización. En algunas realizaciones, el subsistema de componentes de software 630 también puede incluir un software de sistema 640 (también llamado portal de automatización) que proporciona una interfaz única para gestionar la topología, el inventario, la configuración, la programación, el control y/o el diagnóstico de los dispositivos de automatización y/o del sistema de automatización en su conjunto.
A través del software del sistema 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 puede ser utilizado para configurar y establecer parámetros en el equipo durante la fase de ingeniería y afinar, programar y/o diagnosticar el equipo durante la fase de mantenimiento. Algunas de las ventajas del software del sistema 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 pueden gestionarse 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 para garantizar que se establezcan las protecciones de seguridad necesarias. En algunas realizaciones, el subsistema CS 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 pueden almacenarse 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 SDN 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 pueden almacenarse 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 puede conectarse con al menos otros dos nodos y los datos pasan de un nodo a otro en un procedimiento denominado "salto". Dado que los propios nodos hacen de enrutadores, las redes de malla de radio no suelen necesitar enrutadores designados. Sin embargo, algunas redes de radio de malla incluyen uno o más enrutadores de malla junto con los nodos de malla para retransmitir el tráfico en nombre de otros enrutadores de malla y/o nodos de malla. En algunas realizaciones, el subsistema de red 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. Así, en algunas realizaciones, la configuración de los elementos de red del subsistema de red o de la infraestructura de red puede incluir la configuración de los nodos de malla y/o de los enrutadores de malla (por ejemplo, los enrutadores de malla habilitados para OpenFlow) en la red de radio de malla.
En algunas realizaciones, el subsistema de red 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 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. Cabe destacar que en algunas realizaciones, el subsistema de red 670 puede comprender redes SDN y TSN (y por 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, 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 establece 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, no se consideran dentro del ámbito del servidor de niebla 605. La Figura 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 de niebla 610, los nodos informáticos 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 sistema de software 640, establecen una interfaz con el controlador de niebla 610 y los nodos informáticos 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 620 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/recipientes alojados en los nodos informáticos 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, ya que, evidentemente, la red virtual 620 debe existir antes de que las máquinas virtuales y los recipientes puedan conectarse.
El subsistema CS 650 tiene control sobre los componentes de seguridad, tales como los sistemas de detección de intrusos (IDS) 696A, los sistemas de protección contra intrusos (IPS) 696B (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 puede integrarse con todos los aspectos de la solución del sistema SDA en algunas realizaciones. Por ejemplo, el controlador de red 690 puede utilizar 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 utilizar este servicio para autenticar los inicios de sesión, proporcionar políticas de seguridad para las configuraciones del anfitrión (máquina virtual, recipiente, metal desnudo), validar las imágenes del anfitrión 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 puede considerarse 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 los 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 llamado herramienta o herramienta de software) mediante el 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, como SoMachine, se utiliza para configurar, parametrizar y/o programar el equipo de la máquina 701. Del mismo modo, en los sistemas de automatización de procedimientos 708, se utiliza otro software de solución 735B como PlantStruxure PES (Process Expert System) para configurar, parametrizar y/o programar el procedimiento. A nivel de sistema, en el que 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, 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 procedimiento.
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 procedimiento 702, y puede configurar, parametrizar y/o programar dicha máquina y equipo de procedimiento 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 procedimiento. 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 componentes ejemplar ilustrativos de un software 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 cliente. Tal como se utilizan en la presente memoria, los dispositivos cliente pueden incluir, entre otros: estaciones de ingeniería, ordenador tipo 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 interfaces de aplicación 752, interfaces de controlador/dispositivo 754 e interfaces de usuario 756 haciendo que tareas 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 recoger 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 parte 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 puede recopilarse consultando componentes del software del sistema 740, el controlador de niebla (por ejemplo, el controlador del servidor de niebla 410 de las FIGS. 4A-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 pueden parametrizarse e instanciarse en el servidor de niebla. Una unidad funcional, tal y como se utiliza en la presente memoria, es una entidad de hardware, una entidad de software o una entidad híbrida con partes de hardware y software capaz de realizar 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 pueden considerarse cada uno una unidad funcional, y lo mismo puede decirse de 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). Tal y como se 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, un 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 utiliza 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 supervisar 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 supervisar 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 distintas 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 mediante la agregación de datos de las diferentes partes del sistema en un solo lugar, haciendo 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 programas informáticos 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 Figuras 7C-7F son diagramas de capturas de pantalla que ilustran ejemplos de interfaces de usuario del software del sistema de acuerdo con algunas realizaciones. La Figura 7C representa una captura de pantalla ejemplar 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 ha representado, el<sistema de automatización ejemplar incluye un PLC 758, un PLC>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 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 ejemplar 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. 8Aes 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 informáticos asociados 820-1, 820-2, 820-3, ..., 820-N. Cada uno de los nodos informáticos 820-1, 820-2, 820-3, ..., 820-N puede ejecutar un número de anfitriones 802-1, ..., 802-N y redes virtuales asociadas 820. Estos anfitriones pueden ser máquinas virtuales, recipientes o metales desnudos. Cada anfitrión a su vez puede ejecutar un invitado 804. Un invitado 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 realiza una función), o cualquier implementación de software de un dispositivo físico, componente o unidad funcional. En algunas realizaciones, un anfitrión 802-1 puede ejecutar otro anfitrión 802-A que a su vez puede ejecutar un invitado. Por ejemplo, el anfitrión 802-1 del nodo informático 820-3 puede ser una máquina virtual en la que se instancie un recipiente 802-A para ejecutar el invitado 804. Las redes virtuales 820 se conectan desde dentro de los nodos informáticos (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 informáticos (por ejemplo, 820 1, 820-2, ...) y proporcionan conectividad entre las entidades virtualizadas y el mundo físico. En algunas realizaciones, un nodo informático puede ser un dispositivo conectado inteligente, que puede tener una parte física y una parte virtual. Por ejemplo, el nodo informático 820-N puede ser un dispositivo conectado inteligente 815 que puede ejecutar un anfitrión 802-B ejecutando un invitado 804. El mismo dispositivo conectado inteligente 815 también puede tener un sensor/actuador físico 814. El nodo de cómputo 820-N como otros nodos de cómputo pueden conectarse a la red de datos/OT 865.
Los invitados 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 anfitriones, instanciación de anfitriones, 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 informáticos 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 como VLAN, VxLANS, VTN y similares para proporcionar una separación lógica de la red física permite utilizar 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).
Los nodos de almacenamiento 825-1/nodo de almacenamiento redundante 825-2 pueden 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 pueden incorporarse al sistema como nodos de almacenamiento conectados directamente a la red o redes de gestión 812 y/o a la red o redes CAM 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 informáticos 820-1, ..., 820-N. Los nodos de almacenamiento pueden utilizar 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 de servidor de niebla de acuerdo con una segunda realización. Este escenario de despliegue alternativo optimiza el hardware utilizado para implementar el servidor de niebla. Este escenario de despliegue, conocido como modelo CPE (Equipo de Premisas de Cliente), agrupa las funciones de controlador, almacenamiento y computación en un único dispositivo servidor, es decir, el nodo CPE 822 1. El nodo servidor CPE también puede duplicarse (es decir, el nodo CPE 822-2) para proporcionar despliegues HA en algunas realizaciones. En esta realización, los nodos del servidor CPE pueden comunicarse a través de una red de gestión 812. Los nodos de almacenamiento 825 pueden incorporarse al sistema como nodos de almacenamiento conectados directamente a las redes de gestión 812 y/o a las redes CAM 806 y/o a las redes 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 podría utilizarse en objetivos de implantación más pequeños que acepten la restricción de no disponer de nodos de cálculo distribuidos.
La FIG. 9Aes un diagrama de bloques que ilustra componentes ejemplares de un controlador de servidor de niebla en algunas realizaciones. Como se representa, un controlador de servidor de niebla 910 puede incluir un componente de orquestación de niebla 902 y un componente de gestión de anfitrión 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 anfitrión 916 puede utilizar una o más tecnologías de virtualización de anfitrión 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 anfitrión 916 puede utilizar tecnologías de virtualización de anfitrión 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 anfitrión. Además de los dispositivos, otros aspectos del sistema de automatización, como las redes y los elementos de seguridad, también pueden virtualizarse en algunas realizaciones. Algunas de las tecnologías de virtualización de anfitrión que pueden ser utilizadas por el componente de gestión de anfitrión 916 se describen en detalle a continuación.
A. VM clásica
La FIG. 9B ilustra componentes ejemplares de un nodo informático que aloja máquinas virtuales. En algunas realizaciones, los nodos informáticos 915 con soporte de virtualización pueden utilizar máquinas virtuales (VM) (anfitrión) 902-1, ..., 902-N para proporcionar aplicaciones 912 (huésped) altamente flexibles y aisladas. Un nodo informático 915 aloja una o más máquinas virtuales 902-1, ..., 902-N incluyendo la lógica de negocio de la aplicación 912 y sus propios SO/bibliotecas 926. Este mecanismo proporciona una aplicación flexible, ya que la máquina virtual invitada puede basarse en cualquier sistema operativo 916 e incluso puede utilizar 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 máquinas virtuales tienen acceso directo a la CPU a través del hipervisor y cada máquina virtual clásica tiene su propio hardware virtual 924, núcleo 922, sistema de inicio 918 y sistema operativo 916, es posible ejecutar sistemas operativos completamente diferentes (por ejemplo, Windows, Linux) en el mismo nodo informático de forma simultánea, independientemente del sistema operativo nativo del nodo informático. 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, ya 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 utilizar algunas aceleraciones específicas del proveedor para mitigar este efecto.
Las máquinas virtuales 902-1, ..., 902-N pueden migrarse en vivo, es decir, las máquinas virtuales en ejecución pueden migrarse de un nodo informático a otro con un impacto mínimo en las máquinas virtuales en ejecución y en los procedimientos de aplicación asociados. Esto permite al componente de gestión de anfitrión 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 optimizando la distribución de VM entre múltiples nodos informáticos 915 y apagar los nodos informáticos innecesarios.
B. Recipientes
Las Figuras 9C y 9D ilustran ejemplos de componentes de nodos informáticos que alojan recipientes. Los recipientes proporcionan mejoras de rendimiento, flexibilidad y tamaño para las aplicaciones, pero vienen con su propio conjunto de limitaciones. Los recipientes utilizan una caja de arena de memoria que se apoya en el hardware de la máquina anfitriona para proporcionar un entorno seguro y aislado para ejecutar la aplicación. El uso de un recipiente proporciona algunas mejoras de rendimiento y tamaño con respecto a una VM, ya que utiliza directamente los controladores del anfitrión sin la capa del hipervisor. Sin embargo, con los recipientes, una aplicación está inextricablemente vinculada a la arquitectura de hardware y al núcleo del anfitrión. Un ejemplo de aplicación de los recipientes es la respuesta a la demanda.
Por referencia a la FIG. 9C, para conseguir un mejor rendimiento, algunos recipientes 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 librerías 914 nativas del nodo informático. Estos recipientes tienen más limitaciones desde el punto de vista del desarrollo de librerías/aplicaciones, pero son más ligeros, más pequeños, más rápidos de desovar y son capaces de ofrecer el mejor rendimiento.
Por referencia a la FIG. 9D, algunos recipientes 907-1, ..., 907-N pueden incluir el sistema operativo completo 916 (menos el núcleo) para la aplicación anfitrión 912, el sistema de inicio 918, y las librerías 914 pero ejecutándose dentro del espacio recipiente sandboxed del anfitrión. Dado que los recipientes se basan en el núcleo 934 del anfitrión y su hardware físico asociado 932, también deben coincidir con la arquitectura de hardware y el linaje del núcleo del anfitrión 915.
Al igual que las VM, los recipientes también pueden ser migrados en vivo de un nodo informático a otro.
C. Metal desnudo
La FIG. 9D ilustra ejemplos de componentes de un nodo informático metal desnudo. En algunas realizaciones, los nodos informáticos 915 pueden servir como anfitriones de metal desnudo para permitir que los sistemas integrados sean administrados por el componente de administración de anfitrión de servidor de niebla 916. Los anfitriones de metal desnudo ejecutan una imagen binaria construida a propósito que está estrechamente acoplada al hardware del anfitrión 932, de forma muy parecida a un dispositivo incrustado tradicional. Esta imagen binaria puede aprovechar al máximo el acceso directo al hardware como si la imagen se instalara en la fábrica. En algunas realizaciones, de forma similar a cómo se gestionan las máquinas virtuales dentro del servidor de niebla, los nodos informáticos de metal desnudo pueden ser aprovisionados y configurados a través del componente de aprovisionamiento 906 y el componente de configuración 908 del sistema de gestión de anfitrión 916 de la FIG. 9A.
En algunas realizaciones, la imagen de metal desnudo puede ser un núcleo completo 934 y un sistema operativo (OS) 916 para convertir el nodo de metal desnudo en un nodo informático completo con VM y/o recipientes con su propio soporte para VM y/o recipientes.
Por referencia a la FIG. 9A, el componente de proporción 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 utilizan 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 pueden ejecutarse en uno o más nodos informáticos (no mostrados) y/o dispositivos de borde representados como un dispositivo conectado inteligente 1015. En algunas realizaciones, las aplicaciones analíticas o los motores 1006 pueden ejecutarse 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 pueden ejecutarse 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) puede ejecutarse 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 ciberdispositivo 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 puede publicar/suscribirse a datos en tiempo real en el servidor de niebla 1005 o, alternativamente, puede utilizar la comunicación punto a punto para obtener acceso a datos de aplicaciones/dispositivos gestionados por el servidor de niebla 1005. El ciberdispositivo 1032 puede comunicarse con el dispositivo físico 1034 a través de un protocolo OT El ciberdispositivo gestionado por niebla 1032 puede así acoplarse 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 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 una serie 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.
El sistema SDA 1012, en algunas realizaciones, incluye un servidor de niebla 1005 que tiene un controlador de niebla 1010, uno o más nodos informáticos 1015 y almacenamiento 1025. En algunas realizaciones, el almacenamiento puede estar fuera del servidor de niebla 1005, como se representa por el almacenamiento 1026. Los nodos informáticos 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 pueden combinarse). 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 informáticos 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<(mediante la orquestación del almacenamiento>1026<), definir y difundir las políticas de ciberseguridad a todos los>componentes del sistema SDA (mediante la orquestación de la ciberseguridad 1018), y los flujos y comunicaciones de red (mediante 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 puede ejecutarse 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 (p. ej., mediante controlador SDN), orquestación TSN (p. ej., mediante controlador TSN) u orquestación SDN-TSN, que es una combinación de orquestaciones SDN y<t>S<n>(mediante 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 utilizando un protocolo de comunicación 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 informáticos 1015). Los dispositivos pueden actualizar los suscriptores en tiempo real mediante la publicación del valor de los datos cuando esos valores cambian en algunas realizaciones.
En otras realizaciones, los datos pueden compartirse a través de una comunicación punto a punto. Independientemente de los protocolos de comunicación compartidos o punto a punto utilizados, el tráfico de datos hacia/desde las instancias de aplicación que se ejecutan en dispositivos/componentes virtuales en los nodos informáticos 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 informático de acuerdo con algunas realizaciones.
En algunas realizaciones, un software de sistema 1140 ejecutando 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, ya que estos sistemas de automatización pueden tener diferentes tipos de dispositivos de automatización (y, por 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). Así, 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.
Considérese un escenario en el que es necesario aumentar la capacidad de tratamiento de equipajes en un aeropuerto añadiendo 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 constar de 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, 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, incluyendo el tipo y la cantidad de componentes que deben instanciarse o aprovisionarse (por ejemplo, 3 PLC, 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 anfitrión (por ejemplo, máquina virtual), 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 como listas de ancho de banda y puertos, restricciones de trayectoria 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 diversos 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, con base en los flujos de comunicación solicitados 1144, deriva políticas de seguridad para el acceso de anfitriones/invitados, 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 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 de servidor de niebla 1110 y el controlador de red 1190 (por ejemplo, SDN, TSN y/u otros controladores 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 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 anfitrión 916 en la FIG. 9A) para crear, de acuerdo con sea necesario, las redes virtuales de proveedor y/o arrendatario 1120 en uno o más nodos informático. 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 función de 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 trayectorias 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 informático, sino que también puede aprovisionar los recursos de red que la unidad funcional necesita para estar en la operación.
Una vez creada o aprovisionada la unidad funcional y configurada en consecuencia la infraestructura de red, puede utilizarse el software del sistema para configurar y programar los componentes de la unidad funcional. Por ejemplo, los vPAC de la unidad funcional pueden configurarse y programarse utilizando el software asociado a través del portal de software del sistema para controlar la operación 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 actualizando 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 ejemplar para crear un sistema de automatización de acuerdo con algunas realizaciones.
En el bloque 1202, un subsistema de servidor de niebla que incluye un controlador de servidor de niebla y múltiples nodos informáticos crea o instancia componentes virtuales del sistema de automatización en uno o más nodos informáticos (por ejemplo, a través del componente de proporción 906 de la FIG. 9A). Los elementos del sistema de automatización pueden virtualizarse utilizando tecnologías de virtualización como máquinas virtuales, recipientes y metales desnudos. Además, los nodos informáticos en los que se ejecutan los componentes virtuales pueden estar físicamente distribuidos en algunas realizaciones. Por ejemplo, un nodo informático 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álculo, la comunicación entre el controlador del servidor de niebla y los nodos de cálculo se realiza 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 de servidor de niebla (por ejemplo, a través del componente de proporción 906 de la FIG. 9A) crea redes virtuales asociadas dentro de los nodos informáticos. En el bloque 1206, el subsistema del servidor de niebla (por ejemplo, a través del componente de proporción 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 desplegando 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 de servidor de niebla y al subsistema de red para su despliegue en los componentes virtuales que se ejecutan en los nodos informáticos y en los componentes de red físicos y/o virtuales. En el bloque 1212, el subsistema de servidor de niebla utiliza los componentes de red físicos y/o virtuales para comunicarse con 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 ejemplar para añadir 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 Figura 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 puede seleccionarse 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 pueden llevarse 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 ejemplar para proporcionar 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 agregar 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 realizar 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 con base en al menos una política de seguridad. En algunas realizaciones, el subsistema del servidor de niebla puede realizar la autenticación utilizando 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 realice 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 informáticos 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 informático. En el bloque 1424, el sistema SDA puede conectar la instancia virtual de la unidad funcional en el nodo informático a las redes virtuales para aprovisionar o comisionar la unidad funcional en el nodo informático.
La FIG. 15 es un diagrama de flujo lógico que ilustra un procedimiento ejemplar para configurar 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 proporción 906 de la FIG. 9A), la unidad funcional puede configurarse mediante el software del sistema. En el bloque 1502, el sistema SDA (por ejemplo, sistema SDA 600 en 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, controlador de red 690 en FIG. 6A) puede determinar al menos una trayectoria 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 trayectoria 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 puede asociarse a una política de red que especifique que sólo se permite el tráfico HTTP. Así, el conmutador en funcionamiento permitiría la etapa del tráfico HTTP pero bloquearía otro tipo de tráfico como el MODBUS. En el bloque 1508, el sistema SDA puede configurar la instancia virtual de la unidad funcional utilizando 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 trayectoria de red para controlar un procedimiento automatizado.
La FIG. 16A es un diagrama de flujo lógico que ilustra un procedimiento ejemplar para ordenar o proveer una unidad funcional en un sistema SDA de acuerdo con algunas realizaciones.
El procedimiento ejemplar 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 de servidor de niebla), una instancia virtualizada de una unidad funcional de un sistema de automatización en uno o más nodos informáticos gestionados por el controlador del sistema en el bloque 1602. Estos nodos informáticos 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 puede ponerse en servicio en el sistema s Da (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 puede crearse 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 el uno o más nodos informáticos 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 procedimiento automatizado.
En el bloque 1608, el controlador del sistema puede configurar la seguridad de la instancia virtualizada de la unidad funcional aplicando 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 informáticos basado en una política de seguridad. En algunas realizaciones, la instancia virtualizada de la unidad funcional incluye uno o más anfitriones 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, el uno o más anfitriones, y/o el uno o más nodos informáticos en los que se ejecutan el uno o más anfitriones. En algunas realizaciones, un anfitrión del uno o más anfitriones incluye una máquina virtual, un contenedor o un metal desnudo. 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 anfitrión 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 trayectoria 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 trayectoria 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 trayectoria de red aplicando 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 ejemplar para ordenar o proporcionar una unidad funcional en un sistema SDAde acuerdo con algunas realizaciones.
El procedimiento ejemplar 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 trayectoria 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 trayectoria 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. Disposiciones sobre la carga de trabajo en el sistema SDA
Las funciones de automatización comprenden diversas funciones y tareas que deben organizarse de forma coordinada para cumplir los requisitos especificados. Las funciones de los dispositivos están predeterminadas y asignadas a dispositivos de automatización. A modo de ejemplo, un sistema para procesar cemento en polvo ejecuta la función de alto nivel "crear polvo de cemento". Esta función puede dividirse en funciones de dispositivo para una trituradora, una cinta transportadora y una envasadora. Estas funciones pueden requerir tareas de apoyo como la medición de la temperatura, la velocidad, el volumen y la composición/mezcla del producto. Estas mediciones se utilizan a su vez para controlar el rendimiento, la continuidad del procedimiento, la estabilidad del procedimiento y la calidad del producto. Algunas de estas tareas pueden ser críticas para la seguridad, otras pueden llevar mucho tiempo y otras pueden consumir muchos recursos.
Un sistema SDA implementa uno o más procedimientos para organizar cargas de trabajo para optimizar el rendimiento de sistemas de control (por ejemplo, sistemas de control industrial).
Como ejemplo de un sistema de automatización en el que se configura una función de automatización, la FIG. 17A muestra una estación de ingeniería 1701 para configurar estaciones de trabajo, a saber, una estación de transporte controlada mediante un PLC 1702, una estación de montaje controlada mediante un PLC 1703 y una estación de embalaje controlada mediante un PLC 1704. Junto a las estaciones se encuentran las pantallas de operador locales de las respectivas Interfaces Hombre-Máquina (IHM) 1705-1707 que están conectadas a través del bus Ethernet 1708 a la IHM de nivel superior 1709. El sistema de ingeniería 1701 permite diseñar la función de automatización como una aplicación distribuida y dirigida por eventos, que se despliega al SCADA y al Sistema de Ejecución de Manufactura 1710. La estación de ingeniería local 1711 permite la distribución de sesiones para los PLC de las estaciones de trabajo. Adaptando IEC 61499, un estándar para organizar la comunicación entre objetos funcionales, se puede aprovechar este estándar para dividir la función de automatización en bloques funcionales y mapearlos y distribuirlos sobre los PLC de las estaciones de trabajo 1702-1704. Como puede observarse en los elementos T1-3, A1-5 y P1-4 que se descargan desde la estación de ingeniería 1701 a las respectivas estaciones de trabajo 1702-1704.
Otro ejemplo de un sistema de automatización en el que se configura una función de automatización se muestra en la FIG. 17B. Esto muestra de nuevo la estación de ingeniería 1701 para configurar las estaciones de trabajo. El sistema de automatización tiene una estación de transporte controlada mediante un PLC 1702, una estación de montaje controlada mediante un PLC 1703 y un elemento virtual 1712. El elemento virtual 1712 puede implementarse como un nodo informático, un dispositivo inteligente, un servidor u otra unidad de procesamiento. En este ejemplo, la estación de ingeniería 1701 distribuye las múltiples instancias del elemento T1, los elementos A1-5 y los elementos P1-4 de manera diferente que en la FIG. 17A. El elemento virtual 1712 puede ser un dispositivo autónomo que proporciona funciones de apoyo a las estaciones de trabajo controladas por los PLC 1702 y 1703. O el elemento virtual 1712 puede controlar directamente un puesto de trabajo.
La FIG.17C muestra otro ejemplo de un sistema de automatización en el que todos los dispositivos PLC de la FIG.
17A han sido reemplazados por elementos virtuales 1712, 1713 y 1714 similares al elemento virtual 1712 de la FIG.17B. Los elementos virtuales 1712, 1713, 1714 pueden implementarse como un nodo informático, un dispositivo inteligente, un servidor u otra unidad de procesamiento.
Para permitir una distribución diferente de estos elementos o tareas de procesamiento funcional, los requisitos de hardware de los mismos deben ajustarse a las capacidades del hardware disponible. Las características de la función de una aplicación (por ejemplo, P1), como el entorno de software del sistema operativo, la sensibilidad temporal o el ancho de banda de la red, determinan los requisitos de los parámetros óptimos de los invitados, como, por ejemplo, la ubicación. Un parámetro de tipo de anfitrión, por ejemplo, una máquina virtual, un recipiente, o metal desnudo, determina qué tipo de restricciones se ponen en un anfitrión que puede ser alojado. A su vez, un parámetro de nodo informático se caracteriza por el tipo de plataforma de hardware del nodo y determina qué tipo de restricciones se imponen a un anfitrión. El tipo de plataforma de hardware viene determinado, por ejemplo, por el tipo de procesador, como ARM o X86; el tamaño de la memoria, la capacidad de almacenamiento o la proximidad.
9. Ejemplos de metodologías para organizar las cargas de trabajo
Por referencia a la FIG. 18, se ilustra un procedimiento para organizar la carga de trabajo en el sistema SDA (por ejemplo, el sistema SDA 600 de la FIG. 6A). El sistema SDA que se proporciona 1801 se configura a través de un portal de automatización o software del sistema (por ejemplo, el software del sistema 640 en la FIG. 6A, el sistema de software 740 en la FIG. 7B) para ejecutar la función de automatización prevista, que incluye funciones predeterminadas del dispositivo asignadas a los distintos dispositivos de automatización.
Como se ha explicado anteriormente, la función de automatización incluye diferentes funciones de dispositivo para los distintos dispositivos de campo. Estas funciones del dispositivo incluyen varias tareas que pueden dividirse de acuerdo con los objetos de software programados. En consecuencia, el procedimiento requiere determinar 1802 las tareas de las funciones predeterminadas del dispositivo. Una vez determinadas o identificadas las tareas, se evalúan los parámetros operativos industriales 1803 para cada tarea de las funciones del dispositivo. Y cuando se evalúan, las tareas de las funciones del dispositivo se clasifican 1804 por los parámetros operativos del sistema de automatización. Una vez evaluados y clasificados los parámetros de funcionamiento industrial, se seleccionan las tareas para distribuirlas entre los dispositivos de automatización en función de los parámetros de funcionamiento industrial. La distribución de tareas sobre los dispositivos de automatización incluye el redespliegue de tareas 1805 a al menos un dispositivo de automatización y la descarga de tareas 1806 a uno de los nodos informáticos con base en los parámetros operativos industriales. Además, el dispositivo de automatización puede ser un dispositivo conectado inteligente capaz de alojar un nodo informático en sí mismo, permitiendo así la descarga de tareas al nodo informático alojado en el dispositivo de automatización.
La evaluación 1803 de los parámetros operativos industriales proporciona una indicación de qué tareas son relevantes para qué función de nivel superior, como la seguridad, el consumo de energía u otro parámetro de rendimiento general del procedimiento. La clasificación 1804 de los parámetros operativos industriales permite evaluar cuáles de las tareas pueden ser reasignadas a los dispositivos de campo y cuáles pueden ser descargadas a los nodos informático, garantizando al mismo tiempo el cumplimiento de los requisitos de rendimiento del procedimiento. Los nodos informáticos pueden formar parte de un servidor de niebla.
Los parámetros operativos industriales incluyen varios parámetros que pueden estar relacionados con el rendimiento general del procedimiento. Un primer parámetro operativo industrial es un nivel crítico de procedimiento, que puede expresar el nivel de disponibilidad y/o al menos requerido, por lo que la necesidad de disponibilidad de una función expresada, por ejemplo, en tiempo de actividad o extensividad de uso. También puede expresar el nivel de redundancia requerido para una función, ya que la redundancia es una de las formas en que se puede lograr un requisito de disponibilidad. Además, puede expresar un nivel de requisitos de seguridad, un nivel de detecciones de fallos garantizadas y/u opciones de retroceso. Por ejemplo, una planta industrial de procesamiento de acero puede operar un horno en una acería que bajo ninguna circunstancia puede enfriarse. Además, el nivel crítico del procedimiento de los parámetros operativos industriales también podría compilarse como un conjunto de parámetros, incluyendo el nivel de redundancia, la necesidad de disponibilidad de la función, los requisitos de seguridad y las opciones de emergencia.
Otro parámetro operativo industrial es un nivel sensible al tiempo. Esto puede expresar el nivel de precisión requerido del tiempo de ejecución. También puede expresar una duración de tiempo cuantificada, por ejemplo, un plazo determinado durante el cual el cemento debe permanecer en una mezcladora.
Además, el nivel sensible al tiempo del parámetro operativo industrial también podría compilarse como un conjunto de parámetros, incluyendo entonces el conjunto de parámetros la precisión del tiempo de ejecución y la duración cuantificada del tiempo.
Otro parámetro operativo industrial es el coste de ejecución. Este parámetro operativo industrial puede expresar, por ejemplo, las limitaciones de tiempo de procesamiento, como la cantidad de tiempo de procesamiento, puede expresar el nivel de consumo de recursos y/o la demanda de capacidad de procesamiento necesaria para ejecutar una tarea específica en un dispositivo de automatización específico. Esto puede expresarse en la cantidad de memoria necesaria para almacenar información. También puede expresarse como cantidad de capacidad de procesamiento en, por ejemplo, millones de instrucciones por segundo (MIPS) o en operaciones de coma flotante por segundo (FLOPS).
Además, el parámetro operacional industrial coste de ejecución también podría ser compilado como un conjunto de parámetros, el conjunto de parámetros entonces incluyendo el tiempo de procesamiento, el consumo de recursos, y la demanda de capacidad de procesamiento.
Otro parámetro operativo industrial es un nivel crítico de proximidad. Este parámetro puede expresar la proximidad requerida de una tarea a un actuador primario asociado a la tarea y/o la interdependencia de proximidad de las tareas ejecutadas, como por ejemplo la interdependencia de una tarea primaria con respecto a una tarea secundaria.
Por ejemplo, dos tareas que interactúan frecuentemente, o al menos dependen la una de la otra para resultados intermedios, pueden necesitar ser computadas en dispositivos de automatización o nodos informáticos en proximidad cercana para que la función sea realizada efectivamente. La proximidad puede indicar que una persona está muy cerca de la otra en el sentido del espacio físico o del tiempo. Pero también puede indicar que una tercera tarea requiere la proximidad de dos tareas independientes, una cadena de tareas. En particular, esto puede aplicarse a la proximidad de dispositivos de campo como sensores y actuadores. Por ejemplo, para el control de la ventilación en un pozo minero, la tarea debe ejecutarse cerca del sistema de ventilación. Todo ello para evitar interferencias operativas o disfunciones en caso de problemas en la red, debido a inundaciones u otras catástrofes naturales.
Además, el nivel crítico de proximidad del parámetro operativo industrial también podría compilarse como un conjunto de parámetros, incluyendo entonces el conjunto de parámetros la interdependencia de una tarea con otras múltiples tareas. Por lo tanto, la interdependencia de la primera tarea con respecto a una segunda tarea, la interdependencia de la primera tarea con respecto a una tercera tarea, la interdependencia de la primera tarea con respecto a una cuarta tarea, etc.
Otro posible parámetro operativo industrial que puede aplicarse es el rendimiento de costes. Puede expresar los gastos de capital como, por ejemplo, el coste de los recursos. También puede expresar los gastos operativos, como la fiabilidad global del procedimiento. Por lo que respecta a los gastos operativos, un ejemplo es que el coste de reparación de una función en una zona poco accesible es más elevado que cuando está cerca, en la sala de control. En cuanto a los gastos de capital, un ejemplo es el coste de ejecutar una función en un ordenador de gama alta, que podría ser más elevado que cuando se ejecuta en una pequeña plataforma específica.
Además, el rendimiento del coste de los parámetros operativos industriales también podría compilarse como un conjunto de parámetros. El conjunto de parámetros incluye los gastos de capital y los gastos operativos.
Por referencia a la FIG. 19, otro ejemplo de un procedimiento para organizar la carga de trabajo en un sistema SDA (por ejemplo, el sistema SDA de la FIG. 4). Asimismo, al procedimiento descrito en relación con la FIG. 19, el sistema SDA que se proporciona 1901 se configura a través del software del sistema (por ejemplo, el software del sistema 640 en la FIG. 6A) para ejecutar una función de automatización. Del mismo modo, el procedimiento de este ejemplo incluye determinar 1902 las tareas de las funciones de dispositivo predeterminadas, evaluar 1903 parámetros operativos industriales para cada tarea de las funciones de dispositivo, y clasificar 1904 las tareas de las funciones de dispositivo por los parámetros operativos industriales. El sistema SDA se configura entonces 1905 de acuerdo con los parámetros operativos industriales clasificados, lo que incluye el redespliegue de tareas en dispositivos de automatización y la descarga de tareas a nodos informáticos.
El procedimiento continúa entonces reevaluando los parámetros operativos industriales 1906 para cada tarea y clasificando una vez más 1907 estos parámetros. Cuando los parámetros operativos industriales son reevaluados y clasificados, las tareas pueden ser reasignadas 1908 a los dispositivos de automatización y las tareas pueden ser descargadas a los nodos informáticos del sistema de automatización.
El segundo ejemplo descrito anteriormente muestra la ventaja adicional del procedimiento de acuerdo con la realización, ya que permite reorganizar la carga de trabajo dentro del sistema SDA incluso después de que se haya configurado para ejecutar una función de automatización específica. De este modo, cuando se redefinen las circunstancias del procedimiento o los requisitos de rendimiento del procedimiento, la carga de trabajo de la función de automatización puede disponerse en una nueva configuración para cumplir las especificaciones de requisitos modificadas. De este modo, el procedimiento permite gestionar y abordar con mayor flexibilidad los requisitos de rendimiento de un sistema de control industrial. Como ejemplo de cambio en la función de automatización, una función de control puede actualizarse con un algoritmo de análisis que requiera más rendimiento. A continuación, la función podría dividirse y algunas tareas podrían trasladarse a otro nodo informáticos o dispositivo. Otro ejemplo es la ampliación del hardware para aumentar la capacidad, cuando el sistema funcionaba, por ejemplo, al máximo o por encima de su capacidad y es necesario reequilibrar la función de automatización para evitar que queden recursos adicionales sin utilizar.
En el procedimiento, por referencia a la FIG. 20, la evaluación de los parámetros operativos industriales para cada tarea 2001 incluye la determinación de varios o de todos los parámetros para cada tarea. Por lo tanto, el procedimiento incluye determinar al menos uno de los niveles críticos de procedimiento 2002, el nivel sensible al tiempo 2003, el coste de ejecución 2004, el nivel crítico de proximidad 2005; y el rendimiento de costes 2006. Puede que no sea necesario determinar todos los parámetros. Pero es preferente que para cada tarea se determinen los mismos parámetros para permitir la comparación y la clasificación. La determinación de los parámetros puede hacerse simultánea o consecutivamente. Algunos de los parámetros pueden ser establecidos por un operador del sistema de control industrial, mientras que otros pueden derivarse de la forma en que se organizan o programan las tareas de las funciones predeterminadas del dispositivo. Además, la evaluación de los parámetros puede incluir factores ponderados, para permitir cierto grado de flexibilidad en la evaluación de los parámetros.
Consideraciones similares se aplican a la etapa de clasificación de tareas por parámetros operativos industriales 2101. En consecuencia, en referencia a la FIG. 21, la clasificación de tareas incluye la clasificación por nivel crítico de procedimiento 2102, por nivel sensible al tiempo 2103, por coste de ejecución 2104, por nivel crítico de proximidad 2105, y/o la clasificación por rendimiento de costes 2106.
Por referencia a la FIG. 22, la clasificación de las tareas por parámetros operativos industriales 2201 también puede incluir la anulación de la selección de tareas como indicación de que éstas no son adecuadas para la redistribución. Esto significa que estas tareas no se evaluarán y no se tendrán en cuenta para su redistribución. En consecuencia, la clasificación de tareas por parámetros 2201 puede incluir la deselección de tareas críticas de procedimiento 2202, la deselección de tareas sensibles al tiempo 2203, la clasificación por coste de ejecución 2204, la deselección de tareas críticas de proximidad 2205, y/o la clasificación por rendimiento de costes 2206. Esto puede aplicarse en particular al ejemplo descrito en relación con la FIG. 19.
La manera de cuantificar el nivel de cada parámetro operativo industrial puede diferir de acuerdo con el parámetro. Puede estar en una escala que vaya de 1 a 100, de 0 a 10 o de 0 a 1 e incluir fracciones decimales. Para otro puede ser simplemente "sí / no" para la redistribución o puede incluir un espectro de colores. Por otro lado, puede ser un conjunto de cadenas de { "bajo", "intermedio", "alto" }. En un ejemplo, los parámetros pueden ser establecidos por un operador. En otro ejemplo, pueden ser establecidos por un proveedor del sistema. En otro ejemplo, podrían calcularse en función de la potencia de procesamiento, las limitaciones temporales de las conexiones físicas u otras propiedades físicas que pueden determinarse in situ, incluso mientras el sistema está operativo.
Una vez evaluados los parámetros aplicables y clasificadas las tareas en función de dichos parámetros, se procede a la redistribución y descarga de tareas en función de los parámetros operativos industriales. Esto permitiría ajustar directamente los requisitos y restricciones de las tareas a las capacidades de hardware de los dispositivos y nodos informáticos. Por ejemplo, la capacidad de seguridad de un dispositivo debe ser superior al requisito de seguridad, así por ejemplo SIL3 cuando se acepta SIL2. O la capacidad de disponibilidad de un recurso informático puede ser de seis nueves, que se acepta cuando el requisito indica cinco nueves. A la hora de emparejar tareas y hardware, se puede aplicar un factor de ponderación para diferentes parámetros. Por ejemplo, una precisión de temporización especificada como 20 mseg puede incluir un porcentaje de desviación permitido.
Por referencia a la FIG. 23, el despliegue de tareas a los dispositivos de campo y la descarga de tareas a los nodos informáticos incluye la selección de tareas 2301 para su distribución en función del intervalo y la indicación de las tareas seleccionadas 2302 al nodo controlador del servidor de niebla (por ejemplo, el controlador del servidor de niebla 610 de la FIG. 6A). El nodo controlador del servidor de niebla distribuirá entonces las tareas seleccionadas 2303 a los dispositivos de automatización, como PLC, PAC, dispositivos de E/S u otros dispositivos de campo, con base en los parámetros operativos industriales evaluados. A su vez, un nodo controlador de red (por ejemplo, el controlador de red 690 en la FIG. 6A) establecerá la comunicación de red 2305 entre los nodos informáticos para facilitar la ejecución de las tareas distribuidas. Por ejemplo, configurando una red virtual o controlando elementos de red de la red física.
Además de lo anterior, el procedimiento incluye además la selección de tareas 2301 para su descarga a nodos informáticos con base en parámetros operativos industriales. En cuyo caso, estas tareas seleccionadas para su descarga también se indicarán 2302 al nodo controlador del servidor de niebla. A continuación, el nodo controlador del servidor de niebla distribuye las tareas seleccionadas para la descarga 2304 a los nodos informáticos con base en los parámetros operativos industriales evaluados. Y el controlador de red establece la comunicación de red 2305 entre los nodos informáticos para facilitar la ejecución de las tareas distribuidas.
La distribución de las tareas seleccionadas por el nodo controlador del servidor de niebla puede ventajosamente incluir también los parámetros operativos industriales evaluados. Ya que pueden expresar un conjunto de restricciones o requisitos mínimos que pueden tenerse en cuenta a la hora de ajustar las tareas seleccionadas a las capacidades de hardware disponibles. Por otra parte, además de asignar nodos informáticos para tareas distribuidas, el controlador del servidor de niebla puede proporcionar, es decir, configurar nuevos nodos informáticos.
10. Sistematización informática
La FIG. 24 es un diagrama de bloques de una máquina/ordenador/aparato ejemplar que puede realizar varias operaciones, y almacenar varias informaciones generadas y/o utilizadas por tales operaciones de acuerdo con algunas realizaciones. El ordenador 2400 pretende ilustrar un dispositivo de hardware en el que cualquiera de las entidades, componentes o servicios representados en los ejemplos de las FIGS. 1-7B, 8A-11, 13B y 17A-C (y cualquier otro componente descrito en esta especificación) y las metodologías descritas en los ejemplos de las FIGs . 12-13A, 14-16B y 18-23, como un servidor, dispositivos cliente, nodos informáticos, nodos controladores (por ejemplo, controlador de servidor de niebla (componentes 610, 810-x, 910, 1010, 1110), controlador de ciberseguridad (por ejemplo, componentes 655, 1155), controlador de red (por ejemplo, componentes 690, 590A, 590B, 1190)), dispositivos/nodos de almacenamiento, bases de datos, PLC, PAC y similares. El ordenador 2400 incluye uno o más procesadores 2405 y memoria 2410 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 2405 son las unidades centrales de procesamiento (CPU) del ordenador y, por lo tanto, controlan la operación general del ordenador. En ciertas realizaciones, el procesador o procesadores logran esto mediante la ejecución de software o firmware almacenado en la memoria. El procesador o procesadores pueden ser, o pueden incluir, uno o más microprocesadores programables de propósito general o especial, procesadores de señales digitales (DSP), controladores programables, circuitos integrados de aplicación específica (ASIC), dispositivos lógicos programables (PLD), módulos de plataforma de confianza (TPM), o similares, o una combinación de dichos dispositivos.
La memoria 2410 es o incluye la memoria principal del ordenador. La memoria representa cualquier forma de memoria de acceso aleatorio (RAM), memoria de sólo lectura (ROM), memoria direccionable de contenido ternario (TCAM), memoria flash, o similares, o una combinación de tales dispositivos. En uso, la memoria puede contener un código. En una realización, el código incluye un módulo de programación general configurado para reconocer el programa de propósito general recibido a través de la interfaz de bus del ordenador, y preparar el programa de propósito general para su ejecución en el procesador. En otra realización, el módulo de programación general puede ser implementado utilizando circuitos de hardware tal como ASIC, PLD, o matrices de puertas programares en campo (FPGA).
También se conectan a los procesadores a través de la interconexión un adaptador de red 2425, dispositivos de almacenamiento 2415 y dispositivos de E/S 2420. El adaptador de red proporciona al ordenador la capacidad de comunicarse con dispositivos remotos, a través de una red y puede ser, por ejemplo, un adaptador Ethernet o un adaptador de canal de fibra o radio inalámbrica. El adaptador de red también puede proporcionar al ordenador la capacidad de comunicarse con otros ordenadores dentro del grupo. En algunas realizaciones, el ordenador puede utilizar más de un adaptador de red para tratar las comunicaciones dentro y fuera del grupo por separado.
Los dispositivos de E/S pueden incluir, por ejemplo, un teclado, un ratón u otro dispositivo señalador, unidades de disco, impresoras, un barredor óptico y otros dispositivos de entrada y/o salida, incluyendo un dispositivo de visualización. El dispositivo de visualización puede incluir, por ejemplo, un tubo de rayos catódicos (CRT), una pantalla de cristal líquido (LCD), o algún otro dispositivo de visualización aplicable conocido o conveniente.
El código almacenado en la memoria puede ser implementado como software y/o firmware para programar los procesadores para llevar a cabo las acciones descritas anteriormente. En ciertas realizaciones, dicho software o firmware puede proporcionarse inicialmente al ordenador descargándolo desde un sistema remoto a través del ordenador (por ejemplo, mediante un adaptador de red). En algunas realizaciones, la memoria 2410 y los dispositivos de almacenamiento 2415 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 introducido en la presente memoria puede ser almacenado en un medio de almacenamiento legible por máquina y puede ser ejecutado por uno o más microprocesadores programables de propósito general o especial. Un "medio de almacenamiento legible por máquina", tal y como se utiliza el término en el presente memoria, incluye cualquier mecanismo que pueda almacenar información en una forma accesible por una máquina.
Un ordenador también puede ser un ordenador servidor, un ordenador de cliente, un ordenador personal (PC), un PC tipo ordenador tipo tableta , un ordenador portátil, un decodificador (STB), un asistente personal digital (PDA), un teléfono móvil, un teléfono inteligente, una ordenador tipo tableta, un phablet, un procesador, un teléfono, un dispositivo web, un enrutador de red, un conmutador o un puente, un controlador (por ej., PLC, PAC), o cualquier máquina capaz de ejecutar un conjunto de instrucciones (secuenciales o de otro tipo) que especifiquen las acciones que debe realizar dicha máquina.
Un medio de almacenamiento accesible por la máquina o un dispositivo de almacenamiento incluye, por ejemplo, medios registrables/no registrables (por ejemplo, ROM; RAM; medios de almacenamiento en disco magnético; medios de almacenamiento óptico; dispositivos de memoria flash; etc.), etc., o cualquiera de sus combinaciones. El medio de almacenamiento puede ser típicamente no transitorio o incluir un dispositivo no transitorio. En este contexto, un medio de almacenamiento no transitorio puede incluir un dispositivo que es tangible, lo que significa que el dispositivo tiene una forma física concreta, aunque el dispositivo puede cambiar su estado físico. Por lo tanto, por ejemplo, no transitorio se refiere a un dispositivo que sigue siendo tangible a pesar de este cambio de estado.
El término "lógica", tal y como se utiliza en la presente memoria, puede incluir, por ejemplo, circuitos programables programados con software y/o firmware específico, circuitos cableados de propósito especial, o una combinación de los mismos.
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 deben interpretarse en un sentido inclusivo, en contraposición a un sentido exclusivo o exhaustivo; es decir, en el sentido de "que incluye, pero no se limita a" Tal y como se utilizan en la presente memoria, los términos "conectado", "acoplado" o cualquiera de sus variantes, significan cualquier conexión o acoplamiento, directo o indirecto, entre dos o más elementos; el acoplamiento de la conexión entre los elementos puede ser físico, lógico o una de sus combinaciones. Además, los términos "en la presente memoria", "arriba", "abajo" y términos de significado similar, cuando se utilizan en esta solicitud, se refieren a esta solicitud en su conjunto y no a ninguna parte particular de esta solicitud. Cuando el contexto lo permita, los términos de la anterior Descripción Detallada que utilicen el número singular o plural pueden incluir también el número plural o singular, respectivamente. La palabra "o", en referencia a una lista de dos o más elementos, abarca todas las siguientes interpretaciones: cualquiera de los elementos de la lista, todos los elementos de la lista y cualquier combinación de los elementos de la lista.
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 técnica. Por ejemplo, mientras que los procedimientos 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 procedimientos o bloques pueden ser eliminados, movidos, añadidos, subdivididos, combinados y/o modificados para proporcionar combinaciones alternativas o subcombinaciones. Cada uno de estos procedimientos o bloques puede aplicarse de distintas maneras. Además, aunque a veces se muestra que los procedimientos o bloques se realizan en serie, estos procedimientos o bloques pueden realizarse 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 proporcionadas en la presente memoria pueden aplicarse a otros sistemas, no necesariamente al sistema descrito anteriormente. Los elementos y actos de las diversas realizaciones descritas anteriormente pueden combinarse para proporcionar otras realizaciones.
Estos y otros cambios pueden hacerse 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 pueden practicarse de muchas 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 utilizada al describir ciertas características o aspectos de la divulgación no debe interpretarse 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 utilizados en las reivindicaciones siguientes no deben interpretarse como una limitación de la divulgación a las realizaciones específicas descritas en la especificación, 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.
De lo antedicho, se apreciará que las realizaciones específicas del sistema/ tecnología desvelados se han descrito en la presente memoria por propósitos de ilustración, pero que pueden realizarse diversas modificaciones. Por consiguiente, las realizaciones no están limitadas excepto por las reivindicaciones adjuntas

Claims (11)

REIVINDICACIONES
1. Un procedimiento implementado por ordenador para organizar la carga de trabajo en un sistema de Automatización Definida por Software (SDA) (600), comprendiendo el procedimiento:
proporcionar (1801) un sistema SDA (600), incluyendo un nodo controlador del sistema (610/810-1) y múltiples nodos informáticos (615/820-N),
en el que los múltiples nodos informáticos (615/820-N) están acoplados comunicativamente al nodo controlador del sistema (610/810-1) a través de una primera red de comunicación (812);
en el que el nodo controlador del sistema (610/810-1) gestiona los múltiples nodos informáticos (615/820-N) y la virtualización de un sistema de control o una parte del mismo en al menos un nodo informático (820-1) desde los múltiples nodos informáticos (615/820-N) a través de la primera red de comunicación (812) para crear un sistema de control virtualizado que incluya al menos un elemento de sistema de control virtualizado (645) conectado a una red virtual (620/820) conectada a una segunda red de comunicación (865);
en el que el al menos un elemento virtualizado del sistema de control (645) controla al menos un elemento físico del sistema de control a través de la segunda red de comunicación (865) conectada a la red virtual (620/820); y
en el que el sistema SDA (600) está configurado para ejecutar una función de automatización que comprende funciones de dispositivo predeterminadas asignadas a al menos un dispositivo de automatización (1702, 1703, 1704);
determinar (1802) las tareas (T1; A1-A5; P1-P4) de las funciones predeterminadas del dispositivo; evaluar (1803) los parámetros operativos industriales para cada una de las tareas (T1; A1-A5; P1-P4) de las funciones predeterminadas del dispositivo;
clasificar (1804) las tareas (T1; A1-A5; P1-P4) de acuerdo con los parámetros operativos industriales; seleccionar (2301) tareas (T1; A1-A5; P1-P4) para su distribución en función de la clasificación; indicar (2302) las tareas seleccionadas (T1; A1-A5; P1-P4) al nodo controlador del sistema (610/810-1); y distribuir las tareas seleccionadas (T1; A1-A5; P1-P4) por el nodo controlador del sistema (610/810-1) al: desplegar (1805) al menos una tarea (T1) a al menos un dispositivo de automatización (1702) con base en los parámetros operativos industriales; y
descargar (1806) al menos una tarea (P3) a uno (1712) de los múltiples nodos informáticos con base en los parámetros operativos industriales.
2. Procedimiento de acuerdo con la reivindicación 1, en el que los parámetros operativos industriales comprenden uno, varios o todos los siguientes: un nivel crítico de procedimiento, un nivel sensible al tiempo, un coste de ejecución, un nivel crítico de proximidad, un rendimiento de costes.
3. Procedimiento de acuerdo con la reivindicación 2, en el que la evaluación (1803) de los parámetros operativos industriales comprende, para cada una de las tareas (T1; A1-A5; P1-P4) de las funciones predeterminadas del dispositivo, una, varias o todas las siguientes:
determinar (2002) el nivel crítico del procedimiento;
determinar (2003) el nivel sensible al tiempo;
determinar (2004) el coste de ejecución;
determinar (2005) el nivel crítico de proximidad;
determinar (2006) el rendimiento de los costes.
4. Procedimiento de acuerdo con la reivindicación 3, en el que la clasificación (1804) de las tareas (T1; A1-A5; P1-P4) por los parámetros operativos industriales comprende uno, varios o todos los siguientes:
clasificación (2102) por el nivel crítico del procedimiento;
clasificación (2103) por el nivel de sensibilidad temporal;
clasificación (2104) por el coste de ejecución;
clasificación (2105) por el nivel crítico de proximidad;
clasificación (2106) por el rendimiento de los costes.
5. Procedimiento de acuerdo con cualquiera de las reivindicaciones 2-4 anteriores, en el que el nivel crítico del procedimiento de parámetros operativos industriales comprende un conjunto de parámetros que comprenden la necesidad de disponibilidad de la función o el requisito de seguridad, o ambos.
6. Procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores 2-5, en el que el parámetro operativo industrial nivel sensible al tiempo comprende un conjunto de parámetros que comprenden:
precisión del tiempo de ejecución, y
duración cuantificada del tiempo.
7. Procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores 2-6, en el que el parámetro operativo industrial coste de ejecución comprende un conjunto de parámetros que comprenden uno, varios o todos los siguientes: restricciones de tiempo de procesamiento, consumo de recursos, demanda de capacidad de procesamiento.
8. Procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores 2-7, en el que el parámetro operativo industrial nivel crítico de proximidad comprende un conjunto de parámetros que comprenden la proximidad a un actuador primario o la interdependencia de proximidad de una tarea primaria con respecto a una tarea secundaria, o ambas.
9. Procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores 2-8, en el que el parámetro operacional industrial rendimiento de costes comprende un conjunto de parámetros que comprenden:
gastos de capital; y
gastos operativos.
10. Procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores, en el que desplegar (1805) la al menos una tarea (T1) y descargar (1806) la al menos una tarea (P3) comprende:
seleccionar (2301) tareas (P1-P4) para la descarga en función de parámetros operativos industriales; indicar (2302) las tareas seleccionadas (P1-P4) al nodo controlador del sistema (610);
distribuir (2304) las tareas seleccionadas (P1-P4) para su descarga a los múltiples nodos informáticos (615) con base en los parámetros operativos industriales evaluados; y
establecer (2305) la comunicación de red entre los múltiples nodos informáticos (615) para facilitar la ejecución de las tareas distribuidas.
11. Procedimiento de acuerdo con la reivindicación 10, en el que desplegar (1805) la al menos una tarea (T1) y descargar (1806) la al menos una tarea (P3) comprende además:
seleccionar (2301) tareas (T1) para su despliegue en función de parámetros operativos industriales; indicar (2302) las tareas seleccionadas (T1) para su despliegue al nodo controlador del sistema (610); distribuir (2303) las tareas seleccionadas (T1) para su despliegue en dispositivos de automatización (1702) con base en los parámetros operativos industriales evaluados; y
establecer (2305) la comunicación en red para facilitar la ejecución de las tareas distribuidas (T1).
ES16795135T 2015-10-13 2016-10-12 Procedimiento para organizar las cargas de trabajo en un sistema de automatización definido por software Active ES2972422T3 (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/001522 WO2017064554A1 (en) 2015-10-13 2016-10-12 Method for arranging workloads in a software defined automation system

Publications (1)

Publication Number Publication Date
ES2972422T3 true ES2972422T3 (es) 2024-06-12

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 Before (1)

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

Country Status (8)

Country Link
US (5) US10845786B2 (es)
EP (5) EP3362897A1 (es)
CN (3) CN108369533A (es)
AU (7) AU2016339067B2 (es)
CA (3) CA3001801A1 (es)
ES (2) ES2941337T3 (es)
RU (3) RU2730534C2 (es)
WO (3) WO2017064560A1 (es)

Families Citing this family (196)

* 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
US11277746B2 (en) 2016-02-26 2022-03-15 Cable Television Laboratories, Inc. Systems and method for micro network segmentation
US11316935B2 (en) 2016-02-26 2022-04-26 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
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
US10814893B2 (en) 2016-03-21 2020-10-27 Ge Global Sourcing Llc Vehicle control system
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
JP6982717B2 (ja) 2016-03-25 2021-12-17 ティーティーテック インダストリアル オートメーション アーゲー フォグコンピューティング促進型フレキシブル工場
CN109643090B (zh) * 2016-06-24 2022-04-26 施耐德电子***美国股份有限公司 动态地促进m:n工作配置***管理的方法、***和设备
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
GB2605871B (en) * 2017-05-01 2023-02-08 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
WO2019061154A1 (en) 2017-09-28 2019-04-04 Siemens Aktiengesellschaft METHOD AND DEVICE FOR PROVIDING SERVICE FOR AN INDUSTRIAL PROGRAMMABLE AUTOMATE
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
WO2019087849A1 (ja) * 2017-10-31 2019-05-09 村田機械株式会社 通信システム、被制御機器、及び、通信システムの制御方法
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
US20190199595A1 (en) * 2017-12-22 2019-06-27 Avaya Inc. Attribute and property overrides for remote network topology changes
CN108196501A (zh) * 2017-12-22 2018-06-22 北京东土科技股份有限公司 一种基于plc的分布式控制***的容灾方法、装置和***
CN109104454A (zh) * 2017-12-25 2018-12-28 北极星云空间技术股份有限公司 采用设备虚拟化技术构造的软件定义物联网的服务架构
US20190199626A1 (en) * 2017-12-26 2019-06-27 Cisco Technology, Inc. Routing traffic across isolation networks
CN109995675B (zh) * 2017-12-29 2021-07-13 中国科学院沈阳自动化研究所 一种基于软件定义的自适应工业以太网网关***与方法
WO2019127501A1 (zh) 2017-12-29 2019-07-04 西门子公司 过程仪表的异常检测方法、***及存储介质
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
US11394653B2 (en) 2018-04-04 2022-07-19 Siemens Aktiengesellschaft Data transmission in time-sensitive data networks
DE102019001852A1 (de) 2018-04-13 2019-10-17 Sew-Eurodrive Gmbh & Co Kg 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
US10778724B1 (en) 2018-06-29 2020-09-15 Juniper Networks, Inc. Scalable port range management for security policies
US10742557B1 (en) 2018-06-29 2020-08-11 Juniper Networks, Inc. Extending scalable policy management to supporting network devices
US11263098B2 (en) * 2018-07-02 2022-03-01 Pivotal Software, Inc. Database segment load balancer
US20210168029A1 (en) * 2018-07-05 2021-06-03 Francisco Mathieu Safe Mesh Network System for Data Sharing and its Respective Coupling and Interface Devices
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 서비스를 제공하기 위한 전자 장치 및 방법
WO2020104016A1 (en) * 2018-11-20 2020-05-28 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
DE102019114303B3 (de) * 2019-05-28 2020-09-17 Beckhoff Automation Gmbh Verfahren zum Erfassen von Netzwerkteilnehmer in einem Automatisierungsnetzwerk und Automatisierungsnetzwerk
DE102019207790A1 (de) * 2019-05-28 2020-12-03 Siemens Mobility GmbH Anlagenkomponente, sicherheitsrelevante Anlage und Betriebsverfahren
JP2020194354A (ja) * 2019-05-28 2020-12-03 オムロン株式会社 サポート装置および設定プログラム
GB2589941B (en) 2019-06-10 2024-03-27 Fisher Rosemount Systems Inc Ease of node switchovers in process control systems
US11550311B2 (en) * 2019-06-10 2023-01-10 Fisher-Rosemount Systems, Inc. Centralized virtualization management node in process control systems
GB2589663B (en) 2019-06-10 2024-04-10 Fisher Rosemount Systems Inc Automatic load balancing and performance leveling of virtual nodes running real-time control in process control systems
US12033271B2 (en) 2019-06-18 2024-07-09 The Calany Holding S. À R.L. 3D structure engine-based computation platform
CN112102463B (zh) * 2019-06-18 2024-03-29 卡兰控股有限公司 通过位置虚拟化技术操作3d应用的***和方法
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
CN112104691B (zh) * 2019-06-18 2023-10-10 卡兰控股有限公司 跨边缘和云的软件引擎虚拟化以及动态资源和任务分布
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通信协议的通用采集接口软件***
CN114144739A (zh) * 2019-08-02 2022-03-04 瑞典爱立信有限公司 蜂窝网络中的软件定义制造
CN110519776B (zh) * 2019-08-07 2021-09-17 东南大学 一种雾计算***中的均衡聚类和联合资源分配方法
CN110677282B (zh) * 2019-09-23 2022-05-17 天津津航计算技术研究所 一种分布式***的热备份方法及分布式***
US10623233B1 (en) * 2019-09-24 2020-04-14 Intradiem Inc. Live monitoring to trigger automation
US11356316B2 (en) 2019-09-24 2022-06-07 Intradiem, Inc. Live-monitoring of agent instances to trigger automation
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
US11329861B2 (en) 2019-09-24 2022-05-10 Intradiem, Inc. Optimized automation triggering in live-monitoring of agent instances
US11665044B2 (en) 2019-09-24 2023-05-30 Intradiem, Inc. Adaptive rule trigger thresholds for managing contact center interaction time
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
US11700236B2 (en) 2020-02-27 2023-07-11 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 中国联合网络通信集团有限公司 算力资源的调度方法及装置
US11940786B2 (en) * 2020-06-06 2024-03-26 Honeywell International Inc. Building management system and method with virtual controller and failsafe mode
EP3919991A3 (en) 2020-06-06 2022-02-16 Honeywell International Inc. Method and system for configuring 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
CN111722590A (zh) * 2020-06-30 2020-09-29 深圳钰翔技术有限公司 一种钣金或五金冲压用送料机的简易编程方法
CN115699696A (zh) * 2020-07-08 2023-02-03 华为技术有限公司 使用时间敏感网络(tsn)配置验证的tsn操作的支持装置
CN111857685A (zh) * 2020-07-16 2020-10-30 武汉秒开网络科技有限公司 一种自助软件定制及远程自动化测试的方法及***
CN114002992A (zh) * 2020-07-28 2022-02-01 华晨宝马汽车有限公司 配置plc和mes之间的连接的方法和设备
US12034785B2 (en) 2020-08-28 2024-07-09 Tmrw Foundation Ip S.Àr.L. System and method enabling interactions in virtual environments with virtual presence
US11513877B2 (en) * 2020-09-22 2022-11-29 Rockwell Automation Technologies, Inc. Updating operational technology devices using container orchestration systems
US11474873B2 (en) 2020-09-22 2022-10-18 Rockwell Automation Technologies, Inc. Implementing serverless functions using container orchestration systems and operational technology devices
US11989084B2 (en) 2020-09-23 2024-05-21 Honeywell International Inc. Self-healing process control system
US11537383B2 (en) 2020-10-13 2022-12-27 Argo AI, LLC Systems and methods for improved smart infrastructure data transfer
US11163551B1 (en) 2020-10-13 2021-11-02 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***自动化设备数据交互集成平台及方法
CN112948051B (zh) * 2021-02-05 2024-06-25 中国铁建重工集团股份有限公司 一种刀盘驱动数据处理方法、装置及介质
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 飞昂创新科技南通有限公司 一种应用于物联网中的扩展冯诺依曼结构的多层网络结构
US12021740B2 (en) 2021-05-28 2024-06-25 Juniper Networks, Inc. Policy enforcement for bare metal servers by top of rack switches
CN113268884B (zh) * 2021-06-08 2022-05-27 上海交通大学 一种基于资产管理壳的分布式控制***管控方法
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
US20220404799A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc. Software defined process control system and methods for industrial process plants
US20220404812A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc. Discovery Service in a Software Defined Control System
US20220404790A1 (en) * 2021-06-16 2022-12-22 Fisher-Rosemount Systems, Inc. Visualization of a software defined process control system for industrial process plants
US11960588B2 (en) 2021-06-16 2024-04-16 Fisher-Rosemount Systems, Inc Security services in a software defined control system
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
US12007747B2 (en) * 2021-06-16 2024-06-11 Fisher-Rosemount Systems, Inc. Software defined process control system and methods for industrial process plants
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
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
CN117501677A (zh) * 2021-06-16 2024-02-02 西门子股份公司 将可配置逻辑用于技术设备的模块化设置的方法、装置、计算机程序和计算机可读介质
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
US12020056B2 (en) 2021-07-13 2024-06-25 Rockwell Automation Technologies, Inc. Industrial automation control project conversion
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三维模型解析方法
US20240118669A1 (en) * 2022-10-10 2024-04-11 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
US20240160190A1 (en) * 2022-11-14 2024-05-16 Rockwell Automation Technologies, Inc. Managing firmware and software updates within a secure deployment system
EP4395234A1 (de) * 2022-12-29 2024-07-03 Siemens Aktiengesellschaft Verfahren zum betrieb eines automatisierungsgeräts, system und steuerungsprogramm
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
DE60113073T2 (de) * 2000-03-10 2006-08-31 Smiths Detection Inc., Pasadena Steuerung für einen industriellen prozes mit einer oder mehreren multidimensionalen variablen
WO2003096669A2 (en) * 2002-05-10 2003-11-20 Reisman Richard R Method and apparatus for browsing using multiple coordinated device
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
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
US8776050B2 (en) * 2003-08-20 2014-07-08 Oracle International Corporation Distributed virtual machine monitor for managing multiple virtual resources across multiple physical nodes
EP2362310B1 (en) 2005-03-16 2017-10-04 III Holdings 12, LLC 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
WO2008090216A1 (de) * 2007-01-25 2008-07-31 Schneider Electric Automation Gmbh Automatisierungssystem mit implementierter engineering-umgebung
CN100524125C (zh) * 2007-08-02 2009-08-05 上海可鲁***软件有限公司 一种用于自动化***远程监控与维护的解决方法
CN102224470B (zh) 2008-11-24 2015-11-25 Abb研究有限公司 用于提供控制和自动化服务的***和方法
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框架的配置定时任务的方法和装置
EP2725737B1 (en) * 2011-08-01 2016-01-20 Huawei Technologies Co., Ltd. Network policy configuration method, management device and network management centre device
US9699069B1 (en) * 2011-08-22 2017-07-04 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 엘지전자 주식회사 가전제품 및 이를 포함하여 이루어지는 온라인 시스템
JP5701462B2 (ja) 2012-10-04 2015-04-15 三菱電機株式会社 制御システム管理装置
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
CN105409173A (zh) 2013-06-19 2016-03-16 施耐德电器工业公司 统一以太网解决方案
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
US9954733B2 (en) 2013-09-03 2018-04-24 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
EP3116163B1 (en) * 2014-04-14 2019-06-19 Huawei Technologies Co., Ltd. Disaster recovery scheme configuration method and apparatus in cloud computing architecture
KR102366526B1 (ko) 2014-08-27 2022-02-23 아씨아 에스피이, 엘엘씨 액세스 노드의 가상화 구현을 위한 시스템, 방법 및 장치
US9912737B2 (en) 2014-08-27 2018-03-06 Exxonmobil Research And Engineering Company Method and system for modular interoperable distributed control
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
US10845786B2 (en) 2020-11-24
AU2016337406A1 (en) 2018-05-17
CA3001782A1 (en) 2017-04-20
WO2017064554A1 (en) 2017-04-20
US11953890B2 (en) 2024-04-09
ES2941337T3 (es) 2023-05-22
CA3001801A1 (en) 2017-04-20
EP4202681A1 (en) 2023-06-28
RU2018117284A (ru) 2019-11-14
RU2018117282A (ru) 2019-11-14
EP3362896A1 (en) 2018-08-22
WO2017064554A8 (en) 2018-09-27
US20230161332A1 (en) 2023-05-25
AU2016339067B2 (en) 2022-03-10
CN108885560B (zh) 2022-07-08
CN108513655A (zh) 2018-09-07
EP3362895A1 (en) 2018-08-22
RU2747966C2 (ru) 2021-05-18
RU2018117280A3 (es) 2020-03-12
US20180316729A1 (en) 2018-11-01
AU2024202727A1 (en) 2024-05-16
CN108369533A (zh) 2018-08-03
AU2016339061A1 (en) 2018-05-17
AU2022201372B2 (en) 2023-05-11
AU2022201372A1 (en) 2022-03-24
AU2023214270A1 (en) 2023-08-31
US11079744B2 (en) 2021-08-03
EP3362895B1 (en) 2024-01-10
WO2017064565A1 (en) 2017-04-20
RU2729885C2 (ru) 2020-08-13
RU2730534C2 (ru) 2020-08-24
EP3926475A1 (en) 2021-12-22
US20180299873A1 (en) 2018-10-18
RU2018117284A3 (es) 2020-05-22
EP3362896B1 (en) 2023-02-22
RU2018117280A (ru) 2019-11-14
US20210356944A1 (en) 2021-11-18
RU2018117282A3 (es) 2020-04-16
AU2016339061B2 (en) 2022-01-27
CN108513655B (zh) 2022-06-03
WO2017064560A1 (en) 2017-04-20
AU2016339067A1 (en) 2018-05-17
AU2022203956A1 (en) 2022-06-23
WO2017064560A8 (en) 2018-07-12
CN108885560A (zh) 2018-11-23
US20180024537A1 (en) 2018-01-25
CA3001790A1 (en) 2017-04-20
US11579595B2 (en) 2023-02-14
EP3362897A1 (en) 2018-08-22

Similar Documents

Publication Publication Date Title
ES2972422T3 (es) Procedimiento para organizar las cargas de trabajo en un sistema de automatización definido 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