Программно-определяемая автоматизированная система и архитектура

Группа изобретений относится к средствам автоматизации. Технический результат - создание средств, которые предоставляют опорную архитектуру для проектирования, управления и обслуживания высокодоступной, масштабируемой и гибкой автоматизированной системы. Для этого предложена программно-определяемая автоматизированная система. В некоторых вариантах осуществления SDA-система может включать в себя локализованную подсистему, включающую в себя системный контроллерный узел и несколько вычислительных узлов. Несколько вычислительных узлов могут функционально соединяться с системным контроллерным узлом через первую сеть связи. Системный контроллерный узел может управлять несколькими вычислительными узлами и виртуализацией системы управления на вычислительном узле через первую сеть связи. Виртуализированная система управления включает в себя виртуализированные управляющие системные элементы, соединенные с виртуальной сетью, которая соединена со второй сетью связи, чтобы обеспечивать возможность управлять физическим управляющим системным элементом через вторую сеть связи, соединенную с виртуальной сетью. 4 н. и 19 з.п. ф-лы, 25 ил., 1 табл.

 

Перекрестная ссылка на родственную заявку

[0001] Данная заявка притязает на приоритет и выгоду следующих предварительных заявок на патент: (1) предварительной заявки на патент (США) порядковый номер 62/241028, озаглавленной "Software-Defined Automation", поданной 13 октября 2015 года, (2) предварительной заявки на патент (США) порядковый номер 62/240742, озаглавленной "Architecture for Connecting Objects in the Industrial Internet of Things", поданной 13 октября 2015 года, (3) предварительной заявки на патент (США) порядковый номер 62/348770, озаглавленной "Software-Defined Automation", поданной 10 июня 2016 года, (4) предварительной заявки на патент (США) порядковый номер 62/354683, озаглавленной "Software-Defined Automation Architecture", поданной 24 июня 2016 года, (5) предварительной заявки на патент (США) порядковый номер 62/354799, озаглавленной "Software-Defined Automation Architecture", поданной 26 июня 2016 года, и (6) предварительной заявки на патент (США) порядковый номер 62/406932, озаглавленной "Software Defined Automation System and Architecture", поданной 11 октября 2016 года. Все содержимое вышеуказанных заявок на патент явно содержится по ссылке в данном документе.

Уровень техники

[0002] Автоматизация представляет собой использование устройств автоматического управления и различных технологий, чтобы автоматизировать отслеживание, работу и управление процессами и установками без значительного вмешательства оператора, чтобы достигать производительности, которая превосходит управление вручную. Известные автоматизированные системы для отслеживания и управления процессами и установками (например, на заводах, в зданиях и т.д.) типично содержат различные автоматизированные устройства, такие как контроллеры (например, программируемые логические контроллеры (PLC), программируемые автоматизированные контроллеры (PAC)), устройства ввода-вывода (устройства ввода-вывода), полевые устройства (например, датчики и актуаторы), персональные компьютеры (PC), человеко-машинные интерфейсы (HMI) и т.п.Контроллеры выполняют определяемые пользователем программы, чтобы управлять автоматизированными процессами. Типично, в системе управления, контроллеры считывают входные данные из полевых устройств, таких как датчики и измерительные устройства, и используют входные данные для того, чтобы формировать управляющие выводы на основе определяемых пользователем программ.

Краткое описание чертежей

[0003] Фиг.1 является блок-схемой, иллюстрирующей аспекты технологии программно-определяемой автоматизации (SDA) в соответствии с некоторыми вариантами осуществления.

[0004] Фиг.2A является блок-схемой, иллюстрирующей пример традиционной архитектуры автоматизированных систем, реализованной в некоторых отраслях промышленности.

[0005] Фиг.2B является блок-схемой, иллюстрирующей пример упрощенной и гибкой архитектуры автоматизированных систем в соответствии с некоторыми вариантами осуществления.

[0006] Фиг.3 является блок-схемой, иллюстрирующей пример более плоской и гибкой архитектуры операционных технологий для организации в соответствии с некоторыми вариантами осуществления.

[0007] Фиг.4 является схемой, иллюстрирующей упрощенную архитектуру SDA-системы в соответствии с некоторыми вариантами осуществления.

[0008] Фиг.5 является блок-схемой, иллюстрирующей функциональную архитектуру SDA в соответствии с некоторыми вариантами осуществления.

[0009] Фиг.6A является блок-схемой, иллюстрирующей подсистемы SDA-системы в соответствии с некоторыми вариантами осуществления.

[0010] Фиг.6B является схемой, иллюстрирующей объем управления каждой из SDA-подсистем в соответствии с некоторыми вариантами осуществления.

[0011] Фиг.7A является блок-схемой, иллюстрирующей взаимодействие между программным обеспечением для принятия решений и автоматизированным оборудованием в традиционных автоматизированных системах и между системным программным обеспечением и автоматизированным оборудованием в SDA-окружении в соответствии с некоторыми вариантами осуществления.

[0012] Фиг.7B является блок-схемой, иллюстрирующей примерные компоненты системного программного обеспечения SDA-системы в соответствии с некоторыми вариантами осуществления.

[0013] Фиг.7C-7F являются схемами со снимками экрана, иллюстрирующими примерные пользовательские интерфейсы системного программного обеспечения в соответствии с некоторыми вариантами осуществления.

[0014] Фиг.8A является блок-схемой, иллюстрирующей примерные туманные серверные компоненты в соответствии с первым вариантом осуществления.

[0015] Фиг.8B является блок-схемой, иллюстрирующей примерные туманные серверные компоненты в соответствии со вторым вариантом осуществления.

[0016] Фиг.9A является блок-схемой, иллюстрирующей примерные компоненты туманного серверного контроллера в соответствии с некоторыми вариантами осуществления.

[0017] Фиг.9B является блок-схемой, иллюстрирующей примерные компоненты вычислительного узла, выполняющего хостинг виртуальных машин в соответствии с некоторыми вариантами осуществления.

[0018] Фиг.9C является блок-схемой, иллюстрирующей примерные компоненты вычислительного узла, выполняющего хостинг контейнеров в соответствии с первым вариантом осуществления.

[0019] Фиг.9D является блок-схемой, иллюстрирующей примерные компоненты вычислительного узла, выполняющего хостинг контейнеров в соответствии со вторым вариантом осуществления.

[0020] Фиг.9E является блок-схемой, иллюстрирующей примерные компоненты вычислительного узла, выполняющего хостинг образа для платформы без программного обеспечения.

[0021] Фиг.10A является блок-схемой, иллюстрирующей пример компонентного вида SDA-системы в соответствии с некоторыми вариантами осуществления.

[0022] Фиг.10B является блок-схемой, иллюстрирующей примеры управляющего вида и системного вида SDA-системы в соответствии с некоторыми вариантами осуществления.

[0023] Фиг.11 является блок-схемой, иллюстрирующей пример оркестровки SDA-подсистем, чтобы инициализировать функциональный модуль на вычислительном узле в соответствии с некоторыми вариантами осуществления.

[0024] Фиг.12 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ создания автоматизированной системы в соответствии с некоторыми вариантами осуществления.

[0025] Фиг.13A является логической блок-схемой последовательности операций, иллюстрирующей примерный способ добавления функционального модуля в автоматизированную систему через системное программное обеспечение в соответствии с некоторыми вариантами осуществления.

[0026] Фиг.13B иллюстрирует пример топологического вида транспортирующей системы в соответствии с некоторыми вариантами осуществления.

[0027] Фиг.14 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ инициализации функционального модуля в SDA-системе в соответствии с некоторыми вариантами осуществления.

[0028] Фиг.15 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ конфигурирования функционального модуля в SDA-системе в соответствии с некоторыми вариантами осуществления.

[0029] Фиг.16A является логической блок-схемой последовательности операций, иллюстрирующей примерный способ задания автоматизированной системы через программное обеспечение в соответствии с некоторыми вариантами осуществления.

[0030] Фиг.16B является логической блок-схемой последовательности операций, иллюстрирующей примерный способ ввода в действие или инициализации функционального модуля в SDA-системе в соответствии с некоторыми вариантами осуществления.

[0031] Фиг.17 является блок-схемой, иллюстрирующей примерные компоненты компонента управления хостами туманного серверного контроллера SDA-системы в соответствии с некоторыми вариантами осуществления.

[0032] Фиг.18A является блок-схемой, иллюстрирующей некоторые примерные классы событий в виртуальном и/или физическом окружении SDA-системы, которые могут обнаруживаться в соответствии с некоторыми вариантами осуществления.

[0033] Фиг.18B является блок-схемой, иллюстрирующей некоторые примерные обработчики событий в SDA-системе в соответствии с некоторыми вариантами осуществления.

[0034] Фиг.19 является блок-схемой, иллюстрирующей пример координированного ответа на событие кибербезопасности из SDA-системы в соответствии с некоторыми вариантами осуществления.

[0035] Фиг.20 является блок-схемой, иллюстрирующей пример координированного ответа на событие отказа вычислительного узла из SDA-системы в соответствии с некоторыми вариантами осуществления.

[0036] Фиг.21A является логической блок-схемой последовательности операций, иллюстрирующей примерный способ выбора вычислительного ресурса для развертывания виртуализированного экземпляра/компонента в соответствии с некоторыми вариантами осуществления.

[0037] Фиг.21B является логической блок-схемой последовательности операций, иллюстрирующей примерный способ выбора вычислительного ресурса для развертывания гостя в соответствии с некоторыми вариантами осуществления.

[0038] Фиг.22 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ управления SDA-системой в соответствии с первым вариантом осуществления.

[0039] Фиг.23 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ обнаружения и обработки события отказа в соответствии с некоторыми вариантами осуществления.

[0040] Фиг.24 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ управления автоматизированной системой в соответствии со вторым вариантом осуществления.

[0041] Фиг.25 показывает схематическое представление машины в примерной форме компьютерной системы, в которой может выполняться набор инструкций, для инструктирования машине выполнять любые одну или более технологий, поясненных в данном документе.

Подробное описание изобретения

1. Общее представление

[0042] Это раскрытие описывает технологию и систему программно-определяемой автоматизации (в дальнейшем "SDA") (в дальнейшем "SDA-систему"), которая предоставляет опорную архитектуру для проектирования, управления и обслуживания высокодоступной, масштабируемой и гибкой автоматизированной системы.

[0043] Это раскрытие также описывает системы и способы для предоставления централизованного управления SDA-системой, в том числе ее вычислительными ресурсам, сетевыми ресурсами и ресурсами безопасности.

[0044] В некоторых вариантах осуществления, SDA-технология обеспечивает возможность выполнения систем управления и ассоциированного программного обеспечения в туманной платформе или закрытом облаке. Система(ы) управления различных степеней сложности могут содержаться в традиционных производственных помещениях, рафинировочных заводах, подводных лодках, транспортных средствах, туннелях, системах обработки багажа, системах управления энергопотреблением, системах управления зданиями, системах управления паводковой водой, системах управления электросетью и т.п.Посредством перемещения всей системы управления или, по меньшей мере, ее части в туманную платформу или закрытое облако и предоставления программного интерфейса в управляющие системные элементы, SDA-технология обеспечивает возможность выполнения инженерных задач по всему жизненному циклу автоматизированного инжиниринга, такому как проектирование, программирование, конфигурирование, установка, работа, техобслуживание, развитие и завершение работы, более простым, более рациональным и экономически эффективным способом.

[0045] Как проиллюстрировано на фиг.1, архитектура SDA-системы 100 содержит три аспекта: (1) интеллектуальную распределенную систему 105, (2) магистраль 110 связи и (3) соединенные интеллектуальные устройства 115. Интеллектуальная распределенная система 105 применяет программный подход для того, чтобы управлять различными аспектами автоматизированной системы организации, по всему жизненному циклу. Этот программный подход означает, что SDA-систему легко устанавливать, настраивать и адаптировать в отношении любых совершенствуемых требований для того, чтобы соответствовать изменяющемуся бизнес-окружению. В интеллектуальной распределенной системе, серверы автоматизации могут выполнять хостинг приложения, базы данных и т.п.и обеспечивают высокий уровень эластичности. В некоторых вариантах осуществления, система демонстрирует распределенный интеллект посредством обеспечения возможности гостю (например, приложению управления/автоматизации) логически задаваться и распределяться и перераспределяться, чтобы выполняться на одном или более хостов (например, виртуальных машин, контейнеров, платформ без программного обеспечения) на сервере, в физическом автоматизированном контроллере, встроенной системе и т.п.Распределение может инициироваться по различным причинам, например, чтобы оптимизировать производительность, модернизировать аппаратные средства и т.д. Например, приложение со строгими требованиями по объему вычислений может развертываться для выполнения на вычислительном ресурсе, который имеет возможность предоставлять необходимые вычислительные ресурсы. Аналогично, приложение с критическими временными ограничениями может развертываться на вычислительном ресурсе, который находится в непосредственной близости к полевому устройству, которым он управляет, чтобы уменьшать влияние времени задержки через сеть и/или других задержек и повышать производительность системы.

[0046] Магистраль 110 связи предоставляет возможности подключения по всей архитектуре автоматизации от уровня управления до полевой шины, в монтажной плате контроллера, для соединенных интеллектуальных устройств 115 и т.д. Эта возможность подключения, предоставляемая посредством Ethernet, значительно повышает достижимость автоматизированного оборудования и данных и помогает доставлять правильную информацию в правильный объект в правильное время. В некоторых вариантах осуществления, магистраль 110 связи SDA-системы может использовать одну или более сетевых технологий, таких как программно-определяемые сети (SDN), чувствительные ко времени сети (TSN) и/или т.п.в некоторых вариантах осуществления. SDN обеспечивает возможность более простого конфигурирования и переконфигурирования сетевых элементов, которые включают в себя коммутаторы и маршрутизаторы, а также все узлы, берущие на себя аналогичную роль, без необходимости осуществлять доступ к каждому физическому устройству. Например, к каждому сетевому устройству может осуществляться доступ посредством логически централизованного SDN-контроллера с использованием набора протоколов. TSN предоставляет Ethernet-сети в реальном времени, которые обеспечивают управление в реальном времени по всей сети.

[0047] Соединенные интеллектуальные устройства 115 (или соединенные интеллектуальные продукты) представляют собой комплексные системы, которые могут соединяться с сетью, формировать данные и выполнять функцию. Соединенные интеллектуальные устройства имеют сведения по своему рабочему контексту и, по сути, могут принимать интеллектуальные решения и адаптировать свое поведение соответствующим образом. Например, рассмотрим датчик, такой как измеритель мощности, который имеет базовую функцию опознавания электрических сетей. Одна или более функций, помимо базовой функции, могут развертываться в измерителе мощности, чтобы преобразовывать измеритель мощности в соединенное интеллектуальное устройство. Такой соединенный интеллектуальный измеритель мощности может использовать преимущество своего рабочего контекста, например, для того, чтобы проверять конкретные состояния, формировать и отправлять аварийные сигналы и т.п.Соединенные интеллектуальные устройства 115 могут содержать аппаратные средства, программное обеспечение, датчики, хранилище, микропроцессор(ы), возможности подключения и т.п.Некоторые неограничивающие примеры соединенных интеллектуальных устройств включают в себя: контроллеры (например, программируемые логические контроллеры или PLC, программируемые автоматизированные контроллеры или PAC), приводы, концентраторы ввода-вывода, датчики, актуаторы и т.п.

[0048] SDA-система, в некоторых вариантах осуществления, может описываться как совокупность услуг.В некоторых вариантах осуществления, она может представлять собой инфраструктуру как услуга (IaaS), предоставляющую виртуальную инфраструктуру, в которой потребители могут выполнять хостинг собственных приложений. Она также может представлять собой сеть как услуга (NaaS), поскольку она обеспечивает возможность простого конфигурирования и переконфигурирования или модификации сети на основе потребностей потребителя. SDA-система также может представлять собой программное обеспечение как услуга (SaaS), поскольку она может выполнять хостинг программного обеспечения (например, SoMachine, Unity) на одном или более серверов и предоставлять возможность пользователю осуществлять доступ к программному обеспечению клиент-серверным способом с использованием смартфона, переносного компьютера, персонального компьютера, планшетного компьютера и/или другого клиентского устройства. Она также может представлять собой данные/информацию как услуга, которая задает управление данными на уровне решения/системы, чтобы не допускать двойного определения и несоответствия и разрешать большие данные и аналитику. Она может представлять собой платформу как услуга (PaaS), предоставляющую платформу, содержащую набор серверов, предлагающих хостам выполнять приложения по запросу, встраиваемые или нет.

[0049] Фиг.2A иллюстрирует традиционную архитектуру автоматизированных систем, которая широко реализуется во многих отраслях промышленности. В традиционной архитектуре автоматизированных систем, автоматизированные устройства на уровне 2 (например, PLC 230A-C) соединены через сети 235A-C между устройствами, чтобы обеспечивать возможность управления автоматизированных устройств (например, полевых устройств 225A-C) на уровне 1 посредством PLC 230A-C, соответственно. Аналогично, PLC 230A-C на уровне 2 и инженерные станции 240 и серверы 245 процессов и архивных данных на уровне 3 в аппаратной соединены с идентичной управляющей сетью 250. Это обеспечивает возможность инженерам осуществлять доступ и/или программировать PLC 230A-C и осуществлять доступ к данным технологических процессов, сохраненным на серверах 245 архивных данных, непосредственно из инженерных станций 240. На уровне 4, сверху архитектуры автоматизированных систем, общекорпоративная серверная может включать в себя системные/корпоративные серверы 260, которые соединены с инженерными станциями 240 и серверами 245 процессов и архивных данных на уровне 210 диспетчерской через корпоративную сеть 255. В завершение, на самом верхнем уровне 5, мир промышленного оборудования, машин, контроллеров, датчиков и актуаторов (операционные технологии, или OT 265), охватывающий все четыре уровня, интегрируется с офисными сетями (т.е. информационные технологии 270 (IT)).

[0050] Традиционная архитектура автоматизированных систем (например, традиционная OT-архитектура 265, проиллюстрированная на фиг.2A) имеет несколько недостатков. Один такой недостаток заключается в устоявшейся архитектуре. Другими словами, в традиционной архитектуре автоматизированных систем отсутствует гибкость касательно того, чтобы вносить динамические изменения в конфигурацию на стороне приложения, устройства или сети. Кроме того, традиционная архитектура автоматизированных систем характеризуется посредством функциональных хранилищ, которые создают сложность и делают системы управления негибкими. Сложность и отсутствие гибкости ограничивают эффективность эксплуатации архитектуры, представляют собой источник неудовлетворенности для потребителей и требуют дорогостоящей и негибкой конфигурации. Например, на фиг.2A, каждый из функциональных модулей 275A-C проиллюстрирован как имеющий собственную сеть 235A-C между устройствами, соответственно, что предотвращает взаимодействие различных PLC в различных функциональных модулях между собой. Если имеется потребность переключать приложение, выполняющееся в PLC 230A в функциональном модуле 275A, в PLC 230B в функциональном модуле 275B (например, поскольку PLC 230A сбоит) и инструктировать этому приложению управлять устройством ввода-вывода в функциональном модуле 275A, такое изменение требует значительного реинжиниринга и прерывания промышленной эксплуатации, что может быть дорогостоящим.

[0051] Другая проблема традиционной архитектуры автоматизированных систем заключается в сложности с точки зрения управления различными приложениями и устройствами, а также сетевой инфраструктурой. Типичная автоматизированная система может содержать сотни автоматизированных устройств (или автоматизированного оборудования) и процессов, управляемых посредством множества приложений. Например, PLC программируются с использованием программного обеспечения для программирования (например, программного обеспечения Unity Schneider Electric для PLC, изготовленного компанией Schneider Electric), и PLC-конфигурации сохраняются в программных PLC-проектах (например, в проекте Unity). Аналогично, конфигурации по протоколу диспетчерского управления и сбора данных (SCADA) сохраняются в SCADA-проектах. Конфигурации устройств (например, IP-адресация, конфигурация ввода-вывода, списки управления доступом, локальные субкомпоненты и вспомогательные библиотеки, инициирование по событиям, пароли и т.п.) также, в общем, управляются через различные приложения. Аналогично, конфигурации автоматизированных устройств на основе Интернет-протокола (IP) управляются не из одной точки, а вместо этого в каждой точке. Управление этими приложениями и устройствами отдельно для совместимости, управления версиями, техобслуживания, возможности подключения по IP и т.д. является очень сложным и требует значительных экспертных знаний и усилий. Кроме того, поскольку эти приложения и устройства не управляются централизованно, отсутствует способ для того, чтобы восстанавливать всю систему в случае бедствия. В связи с этим, традиционные архитектуры автоматизированных систем являются уязвимыми для рисков нарушения безопасности (например, неавторизованных изменений конфигурации устройств) и бедствий (например, пожара, наводнения).

[0052] Еще одной слабостью при отсутствии централизованного управления приложений и устройств является трудность в осуществлении доступа к данным, сформированным посредством различных частей системы. Агрегирование больших количеств различных типов и наборов данных, сформированных посредством различных приложений и устройств, в одном месте становится задачей, которая является слишком сложной и длительной. Без доступа к релевантным данным становится затруднительным получать целостный вид системы для того, чтобы проводить оптимизации производительности. Например, рассмотрим сценарий, в котором несколько устройств в заводском цехе могут иметь ресурсы, доступные для того, чтобы выполнять приложения. Если инженер-технолог конкретно не осуществляет доступ к каждому из этих устройств и не выполняет определение в отношении того, какие ресурсы доступны, информация относительно доступности ресурсов из этих устройств неизвестна и в силу этого не рассматривается при определении того, где развертывать приложение, либо того, следует или нет добавлять новое автоматизированное устройство. Как результат, могут приниматься неэффективные и субоптимальные решения. В качестве другого примера, рассмотрим ситуацию, когда вирус заражает промышленный контроллер. В традиционных автоматизированных системах, обнаружение такого события может сбить работу большей части завода, если не всего завод, поскольку инженер, возможно, должен физически заменять контроллер на новый и конфигурировать и программировать его снова.

[0053] SDA-технология, описанная в данном документе, преодолевает эти и другие недостатки традиционной архитектуры автоматизированных систем посредством преобразования жесткой устоявшейся традиционной архитектуры в гибкую, "более плоскую", программно-определяемую архитектуру. Преобразованная OT-архитектура обеспечивает конфигурирование сети и развертывание функций/приложений автоматизации на лету на системном уровне с помощью технологий виртуализации (например, услуг, приложений), конфигурируемых устройств и/или сетевых технологий.

[0054] Хотя традиционная архитектура автоматизации, проиллюстрированная на фиг.2A, является жесткой и иерархической, по меньшей мере, с четырьмя уровнями управления, примерная OT-архитектура, заданная посредством SDA-технологии, проиллюстрированной на фиг.2B, является значительно более простой, с тремя уровнями управления (отсюда описание "более плоская"). Эти три уровня управления включают в себя уровень 205 общекорпоративной серверной комнаты (уровень 4), уровень 280 функциональных модулей, PLC, полевых технологических устройств (уровень 1) и консолидированный уровень 212 (уровень 3/4). Преобразованная OT-архитектура также содержит корпоративную сеть 255 и одну сеть 235 между устройствами, которая заменяет фрагментированные сети между устройствами традиционной OT-архитектуры. Например, как проиллюстрировано на фиг.2B, все автоматизированные устройства, такие как PLC, 285, I/Os, HMI 290A, 290B и инженерные станции 240, соединены с одной сетью 235 между устройствами. В этой архитектуре, приложение, выполняющееся в PLC в функциональном модуле 275B, может перемещаться на сервер(ы) 285 (например, посредством создания виртуального PLC, который представляет собой программную реализацию PLC на хосте, к примеру, виртуальную машину или контейнер), и сеть может быть автоматически сконфигурирована с возможностью обеспечивать то, что трафик из виртуального PLC (vPLC) на сервере(ах) 285 протекает в устройства ввода-вывода в функциональном модуле 275B своевременно, чтобы отслеживать и/или управлять устройствами ввода-вывода или полевыми устройствами. Некоторые неограничивающие примеры устройств ввода включают в себя: датчики, измерительные устройства, переключатель давления, переключатель уровня и т.п.Аналогично, некоторые неограничивающие примеры устройств вывода включают в себя: актуаторы, электромоторы, реле или соленоиды, аналоговые устройства и т.п.Таким образом, SDA-технология может упрощать развертывание и конфигурирование функций и/или приложений автоматизации.

[0055] Одно из преимуществ раскрытой SDA-архитектуры заключается в интеллектуальном корпоративном управлении. Интеллектуальное корпоративное управление включает в себя соединение существующих автоматизированных систем с другими системами (например, корпоративными системами, системами жизненного цикла и системами стоимостной цепочки), чтобы оптимизировать все промышленное предприятие в целом и лучше обеспечивать материальные выгоды от более глобального бизнес-управления. Интеллектуальное корпоративное управление упрощает разбиение хранилищ организации и обеспечивает возможность более тесной интеграции систем производства с системами планирования ресурсов предприятия (ERP), системами управления жизненным циклом продукта (PLM), системами управления цепочками поставок (SCM) и управления взаимоотношениями с клиентами (CRM). Эти различные корпоративные системы исторически управляются в определенной степени независимо друг от друга, что предотвращает целостный вид организации. Целостный подход раскрытой SDA-архитектуры может способствовать огромному приросту эффективности для организаций.

[0056] Например, соединенные интеллектуальные устройства могут тесно интегрироваться с более крупной организацией, чтобы способствовать более гибкому и эффективному производству. Интеллектуальное корпоративное управление является достаточно сложным в реализации, и SDA-архитектура и стандарты обеспечивают сходимость систем информационных технологий (IT) и операционного преобразования (OT). Более тесная интеграция обеспечивает возможность организациям не только быть более эффективными, но также и иметь большую гибкость и чувствительность к волатильному состоянию рынка. Понятие управления может расширяться от управления в реальном времени физическим параметром на управление в правильное время всей организацией, в том числе физическими и нефизическими параметрами. Примерные выгоды для организаций включают в себя способность повышать защиту от киберугроз, быть более инновационными и иметь возможность лучше управлять безопасностью, производительностью и воздействием на окружающую среду.

[0057] Некоторые примерные варианты применения интеллектуального корпоративного управления включают в себя индивидуализацию и размеры партий в единицу, уменьшение числа отзывов продуктов, обнаружение дефектных продуктов более заблаговременно в процессе производства и модификацию проектирования продуктов, чтобы исключать первопричины, модификацию производственного планирования на основе прогнозов погоды, модификацию производственного плана/инструкций на основе спот-цены сырья и т.д.

[0058] Фиг.3 является блок-схемой, иллюстрирующей пример более плоской и гибкой архитектуры операционных технологий (OT) для организации в соответствии с некоторыми вариантами осуществления. Как проиллюстрировано, более плоская OT-архитектура в соответствии с SDA-технологией имеет два слоя: "чувствительный ко времени" облачный слой 330 на основе IP для детерминированного управления в реальном времени и корпоративный облачный слой 325. Чувствительный ко времени слой 330 охватывает уровень 320 датчиков и актуаторов (L1) и уровень 315 дискретного, гибридного или непрерывного управления (L2) и обеспечивается посредством технологий облачных вычислений, оптимизированных для детерминированной связи в реальном времени. Другими словами, чувствительный ко времени слой 330 обеспечивает то, что чувствительный ко времени трафик управления/данных из L1- и L2-слоев управляется с возможностью удовлетворять требованиям по времени задержки и/или надежности. При использовании в данном документе, "облако" означает используемые технологии, а не физическое местоположение инфраструктуры. Например, в отрасли промышленности автоматизации, могут использоваться архитектуры с одним или более "оконечных абонентских" облаков.

[0059] В некоторых вариантах осуществления, OT-устройства, которые содержат чувствительный ко времени слой (например, датчики, актуаторы и контроллеры в L1 и L2), поддерживают облачные технологии и допускают прозрачную связь с помощью интерфейса с IT-системами корпоративного облачного слоя. Эти устройства также могут иметь высокую степень интеллектуальности или логики в некоторых вариантах осуществления. Например, в регулирующие клапаны могут встраиваться датчики температуры, датчики давления и/или акустические датчики, которые допускают автономную работу с использованием заданных точек, принимаемых из корпоративного облачного слоя, например, чтобы определять собственные потребности для профилактического техобслуживания и/или своевременно информировать отдел технического обслуживания.

[0060] Корпоративный облачный слой 335 охватывает уровень 310 управления производственными операциями (MOM) (L3) и уровень 305 планирования ресурсов предприятия (ERP) (L4) иерархии. ERP 335A, MOM 335B, управление 335C жизненным циклом продукта (PLM) и другие функции, такие как управление 335D активами, управление 335E энергопотреблением и т.д. в корпоративном облачном слое 325 взаимодействуют между собой и с чувствительными ко времени системами промышленной автоматизации и управления, чтобы предоставлять координированный целостный вид и управление корпоративной системой. В некоторых вариантах осуществления, информационный поток через оба слоя является абсолютно прозрачным с использованием механизмов семантики и обнаружения (например, на основе отраслевых стандартов).

[0061] Более плоская архитектура может предоставлять множество выгод для конечных пользователей. Например, более плоская архитектура ассоциирована с низкими затратами на реализацию и повышенной гибкостью. Она также позволяет поддерживать возможности 340 подключения к любой конечной точке, обеспечиваемые посредством стандартизированной семантической информационной модели. Семантическая информационная модель и ассоциированные услуги упрощают оптимизированное проталкивание полевых данных в облако и адаптацию поведения полевых устройств на основе аналитики, выполняемой в облаке.

[0062] Другие выгоды включают в себя реализацию дополнительных инкрементных функций, размера партии в 1, прозрачного и экономически эффективного соединения с корпоративными системами, обеспечивающими управляемое информацией производство.

[0063] Другая выгода OT-архитектуры в соответствии с SDA-технологией заключается в ее применении к крупномасштабным управляющим сетевым архитектурам. Крупномасштабная управляющая сетевая архитектура является сложной инженерной задачей для всего жизненного цикла, поскольку она, в общем, включает в себя большое число устройств, соединенных по сети (например, Ethernet/TCP-IP). Высокое число соединенных устройств означает беспрецедентный уровень сложности. Например, такая архитектура может включать в себя не менее 2800 PLC, и 5400 приводов могут соединяться в 30 сетевых контурах. OT-архитектура в соответствии с SDA-технологией может упрощать проектирование, управление и обслуживание такой крупномасштабной архитектуры. Например, в OT-архитектуре, раскрытой в данном документе, обработка данных может достигаться организованным и эффективным способом, что, в свою очередь, оптимизирует рабочие характеристики. Время ответа, например, относительно хранения и извлечения данных может отслеживаться посредством SDA-системы, и могут проводиться регулирования, чтобы оптимизировать рабочие характеристики. Аналогично, работоспособность компонентов может отслеживаться на непрерывной основе посредством компонента централизованного управления, и все события, которые могут потенциально оказывать влияние на производительность системы, могут обнаруживаться своевременно и исправляться через координированный ответ на нескольких фронтах, включающих в себя виртуализацию, кибербезопасность и сеть. Аналогично, OT-архитектура может предоставлять повышенную производительность управления посредством распределения сетей обработки и проектирования, соответственно, с учетом различных протоколов для осуществления доступа к информации устройств и приложений. Кроме того, готовность и устойчивость системы может повышаться посредством обеспечения возможности диагностики отказов и резервирования.

[0064] Далее подробно поясняются эти и различные другие аспекты SDA-системы, включающие в себя различные компоненты, признаки, преимущества и варианты применения.

2. SDA-архитектуры

A. Упрощенная архитектура

[0065] Фиг.4 является схемой, иллюстрирующей упрощенную архитектуру SDA-системы в соответствии с некоторыми вариантами осуществления. Архитектура иллюстрирует туманный сервер 405, связанный с системным программным обеспечением 440, и соединенные интеллектуальные устройства 415A, 415B, которые функционально соединяются с туманным сервером 405 и системным программным обеспечением через магистраль 410 связи. Архитектура также иллюстрирует то, что, по меньшей мере, некоторые соединенные интеллектуальные устройства 415B и туманный сервер 405 могут функционально соединяться с облаком 450.

[0066] Туманный сервер 405 состоит из совокупности ресурсов управления и вычислительных ресурсов, которые соединяются, чтобы создавать логически централизованную и при этом потенциально физически распределенную систему для хостинга автоматизированных систем организации. "Туманный сервер" или "туманная платформа" при использовании в данном документе представляет собой систему управления облаком (или локализованную подсистему, или локализованную систему), которая локализована в одном или более вычислительных и/или управляющих узлов. Другими словами, туманный сервер 405 представляет собой облачную технологию, которая сведена к локальному участку или установке (отсюда термин "туман") в форме одного или более вычислительных и/или управляющих узлов, чтобы управлять всей автоматизированной системой или ее частью. Туманный сервер 405 обеспечивает виртуализацию посредством предоставления инфраструктуры виртуализации, в которой может работать и/или управляться автоматизированная система(ы). Инфраструктура виртуализации включает в себя вычислительные узлы, которые выполняют хосты, такие как виртуальные машины, контейнеры и платформы без программного обеспечения (или образы для платформы без программного обеспечения). Хосты непосредственно могут выполнять гостей, которые включают в себя приложения и/или программные реализации физических компонентов или функциональных модулей и портал автоматизации или системное программное обеспечение 440. При использовании в данном документе, виртуализация представляет собой создание виртуальной версии чего-либо. Например, виртуальный компонент или виртуализированный компонент (например, виртуальный PLC, виртуальный коммутатор, виртуализация сетевых функций (NFV)) представляет функцию, которая выполняется на хосте, работающем на вычислительном узле. Он не должен иметь физического наличия как такового. Туманный сервер 405 не должен быть локализован в централизованной аппаратной; контроллеры, устройства и/или серверы 435 рядом с датчиками и актуаторами (например, устройством ввода-вывода, встроенным устройством) также могут считаться находящимися под управлением туманного сервера 405. В некоторых вариантах осуществления, туманный сервер 405 также может агрегировать, сохранять и/или анализировать данные и/или сообщать данные или аналитику в облако 450. Облако 450 может представлять собой корпоративное облако (т.е. закрытое облако), открытое или гибридное облако. Системное программное обеспечение 440 предоставляет одну точку входа для конечного пользователя, чтобы задавать (например, проектировать, инициализировать, конфигурировать и т.п.) автоматизированную систему. Один способ задания автоматизированной системы заключается в управлении распределением приложений/прикладных функций туда, где пользователям требуется их выполнение.

[0067] Соединенные интеллектуальные устройства 415A, 415B (также соединенные интеллектуальные продукты) отслеживают устройства и/или управляют устройствами, датчиками и/или актуаторами рядом с оборудованием/сырьем/окружением посредством выполнения приложений/прикладных функций. В различных вариантах осуществления, соединенное интеллектуальное устройство имеет следующие признаки: (1) физические и электрические компоненты, (2) микропрограммное обеспечение или "интеллектуальная" встроенная часть и (3) возможности подключения и функциональная совместимость. В некоторых вариантах осуществления, соединенное интеллектуальное устройство также может иметь компонент кибербезопасности, который может работать удаленно или на плате.

[0068] Некоторые соединенные интеллектуальные устройства 415A могут выполнять приложения или прикладные функции ("приложения") локально (например, контур регулирования скорости/крутящего момента привода скорости), поскольку они имеют возможности обработки для этого. Это означает то, что нет необходимости выполнять эти приложения в другом месте (например, на соединенном PC, сервере или свои вычислительных устройствах), чтобы получать данные, чтобы выполнять свои функции. Это имеет преимущество меньшего времени ответа (т.е. меньшего времени задержки) и экономии полосы пропускания сети. Другое преимущество встроенного или локального выполнения приложений состоит в том, что оно повышает согласованность данных и устойчивость архитектуры, поскольку устройство может продолжать формировать информацию (например, аварийный сигнал) или регистрировать данные, даже если сеть простаивает.

[0069] В некоторых вариантах осуществления, соединенные интеллектуальные устройства 415B могут полностью или частично выполняться на одном или более серверов (например, на сервере 435, туманном сервере 405). Например, соединенное интеллектуальное устройство 415B может реагировать на удаленные сигналы (например, удаленные вызовы методов, вызовы через интерфейс прикладного программирования, или API-вызовы), как если приложение выполняется локально, когда фактически приложение выполняется удаленно, например, на туманном сервере 405. В некоторых вариантах осуществления, соединенные интеллектуальные устройства могут захватывать данные в реальном времени относительно собственного состояния и состояния своего окружения (например, устройств, которые они отслеживают) и отправлять такие данные на туманный сервер 405 и/или удаленное облако 450. В некоторых вариантах осуществления, соединенные интеллектуальные устройства 415A, 415B могут преобразовать захваченные данные в реальном времени в информацию (например, аварийные сигналы), сохранять их и выполнять оперативную аналитику для них. Соединенные интеллектуальные устройства 415A, 415B затем могут комбинировать функции отслеживания и управления, описанные выше, чтобы оптимизировать собственное поведение и состояние.

[0070] Магистраль 410 связи упрощает взаимодействие между туманным сервером 405, системным программным обеспечением 440 и соединенными интеллектуальными устройствами 415A, 415B. Магистраль связи (или магистраль Интернета вещей (IoT)/промышленного Интернета вещей (IIoT)) охватывает набор сетевых архитектур и сетевых кирпичей, которые обеспечивают физические и логические соединения соединенных интеллектуальных устройств 415A, 415B, туманного сервера 405 и любых других компонентов, которые являются частью SDA-архитектуры. Например, различное оборудование на заводе может соединяться между собой и с корпоративной системой (например, MES или ERP) с использованием технологий на основе различных стандартов, таких как: Ethernet, TCP/IP, веб-технологии и/или программные технологии. Магистраль связи в форме унифицированной глобальной промышленной Ethernet-магистрали может предоставлять: легкий доступ к данным, из заводского цеха (OT) в корпоративные приложения (IT), гибкий способ задавать различные типы сетевых архитектур (например, звезды, гирляндная цепь, кольцо), соответствующих потребностям потребителя, надежную архитектуру, которая может удовлетворять таким требованиям, как доступность, безопасность и поддержка работы в неблагоприятных окружениях, а также правильная информация для правильных людей в правильное время в одном кабеле.

[0071] Магистраль 410 связи включает в себя полную промышленную Ethernet-инфраструктуру, предлагающую коммутаторы, маршрутизаторы и/или кабельную систему, чтобы разрешать потребности всех топологий. Магистраль 410 связи также поддерживает набор протоколов подключения на основе стандартов по различным стандартам (например, Modbus/TCP-IP, IP Ethernet, UA OPC, DHCP, FTP, SOAP, REST и т.д.). Магистраль 410 связи также может поддерживать набор веб-функций, предлагающих такие функции, как диагностика, отслеживание и конфигурирование, с использованием стандартной опорной архитектуры для интеграции веб-страниц и устройств, которая задает шаблоны, кирпич, чтобы интегрировать группу устройств в контроллеры на прикладном уровне и сетевом уровне для конфигурирования, настройки и диагностики. В некоторых вариантах осуществления, элементы кибербезопасности могут встраиваться в архитектуру. Магистраль 410 связи также соблюдает набор правил архитектуры, структурирующих архитектуру согласно производительностям (качество обслуживания или QoS), устойчивость (RSTP и PRP HSR для резервирования) и уровню безопасности (IEC61508). В некоторых вариантах осуществления, магистраль 410 связи также поддерживает интеграцию набора шлюзов, с тем чтобы соединять унаследованное (т.е. не-Ethernet) оборудование с сетью.

[0072] Магистраль 410 связи может использовать несколько протоколов для того, чтобы предоставлять несколько услуг, чтобы удовлетворять несколько потребностей. Некоторые примеры потребностей связи и подходящих протоколов перечислены в таблице 1.

Таблица 1. Услуги и протоколы

Услуга	Протокол
Между устройствами	Modbus/EtherNet/IP, DDS, UA OPC, pub/sub
Устройство для управления	Modbus/Eip, NTP, DHCP, FTP
Устройство для управления для жесткого реального времени	SercosIII, Profinet IRT, EtherCat
Управление между равноправными узлами	DDS, UA OPC, pub/sub
Управление в аппаратной комнате	OPC, Modbus, TCP
В архитектуре	Modbus/Eip, SNMP, SMTP, NTP, HTTP, FTP

[0073] Сети в существующих системах очень сегментированы, чтобы обеспечивать возможность гарантированную или надежную связь. Магистраль 410 связи в SDA-архитектуре может преодолевать проблемы существующих систем через технологии чувствительных ко времени сетей (TSN) и программно-определяемых сетей (SDN). SDN-технология обеспечивает отделение управляющей логики сети от базовых сетевых аппаратных средств или устройств (например, коммутаторов, маршрутизаторов) и логическую централизацию управления сетью. SDN-технология позволяет вносить простоту и гибкость в эти сети, обеспечивая связь в/через различные слои в соответствии с сетевыми политиками. TSN-технология добавляет набор характеристик в стандартный Ethernet, чтобы предоставлять характеристики в реальном времени и гарантированные по времени обмены данными в областях или по всей архитектуре. Кроме того, решение по кибербезопасности также может интегрироваться и адаптироваться к SDA-архитектуре.

B. Функциональная архитектура

[0074] В некоторых вариантах осуществления, SDA-архитектура обеспечивает управление автоматизированной системой через набор контроллеров, которые предоставляют управление ресурсами на уровне всей системы. Эти контроллеры составляют ресурсы управления туманного сервера и предоставляют гомогенный способ для того, чтобы управлять всей системой. Администратор системы может взаимодействовать с этими контроллерными узлами для начального установления, расширения системы, диагностики, техобслуживания и т.п.Аналогично, выполнение приложений в или за пределами системы позволяет взаимодействовать с этими контроллерными узлами, чтобы управлять конкретными гранями или функциями в системе (например, инструментальным ICS-средством, сетевым инструментальным средством, электрическим системным инструментальным средством), управлять вычислительными ресурсами (например, отслеживание, управление другими приложениями и/или ресурсами) и т.п.Этот функциональный вид SDA-архитектуры проиллюстрирован на фиг.5.

[0075] Примерный функциональный вид SDA-системы, проиллюстрированный на фиг.5, включает в себя плоскость 575 приложений, плоскость 580 управления и плоскость 582 ресурсов. Плоскость 575 приложений охватывает системное программное обеспечение 540 и программные компоненты или приложения 535, которые выполняются в системе и которые используют и управляют набором ресурсов системы. Плоскость 580 управления включает в себя набор контроллеров, включающих в себя туманный серверный контроллер 510, SDN-контроллер 590A/TSN-контроллер 590B (или сетевой контроллер) и CS-контроллер 555. Эти контроллеры предоставляют стандартизированный набор интерфейсов с приложениями в плоскости 575 приложений, чтобы осуществлять доступ и/или управлять ресурсами в плоскости 582 ресурсов системы. В некоторых вариантах осуществления, контроллеры также предоставляют диагностику, управление доступностью и т.п.SDN-контроллер 590A/TSN-контроллер 590B управляет и распределяет сетевые политики на системном уровне. Аналогично, CS-контроллер 555 принудительно активирует политики 565 безопасности на системном уровне.

[0076] В некоторых вариантах осуществления, эти контроллеры могут иметь иерархическую взаимосвязь между собой. Например, SDA-система может включать в себя контроллер верхнего уровня (не показан) и набор централизованных контроллеров (например, туманный серверный контроллер 510, сетевые контроллеры 590A, 590B и CS-контроллер 555), каждый из которых управляет зданием или производственным объектом. Контроллер верхнего уровня может, например, распределять политики в централизованные контроллеры, чтобы обеспечивать возможность этим контроллерам управлять своим собственным зданием или производственным объектом. Окружение виртуализации поддерживает иерархическое распределение контроллеров.

[0077] Плоскость 582 ресурсов может включать в себя сетевые ресурсы 560, вычислительные ресурсы, представленные посредством вычислительных узлов 515, ресурсы 525 хранения и ресурсы 595 безопасности. Системное программное обеспечение 540 и приложения 535 выполняются в вычислительных узлах 515, управляемых посредством туманного серверного контроллера 510. Вычислительные узлы 515, которые предоставляют вычислительные ресурсы в систему, могут физически распределяться и управляться посредством туманного серверного контроллера 510. Например, некоторые вычислительные узлы в форме серверов расположены на туманном сервере или закрытом облаке, тогда как другие вычислительные узлы, такие как соединенные интеллектуальные устройства, работают на краю. Сетевые ресурсы 560 могут представлять собой виртуальные сетевые ресурсы на туманном сервере, физические инфраструктурные ресурсы в коммутационном/маршрутизирующем оборудовании или инфраструктурные ресурсы, расположенные в соединенных интеллектуальных устройствах. Ресурсы 525 хранения могут представлять собой базы данных и/или другие устройства для сохранения виртуальных образов, томов, приложений, данных технологических процессов, данных состояния и т.п.Ресурсы 595 безопасности могут включать в себя компоненты системы безопасности, постоянно размещающиеся в вычислительных узлах 515, узлах 525 хранения, и/или автономные компоненты, которые предоставляют услуги обеспечения безопасности, такие как принудительная активация политик безопасности, обнаружение и защита от проникновений и т.п.

[0078] Контроллеры оркеструют и отслеживают некоторые или все ресурсы системы. Приложения, управляющие системой (например, системное программное обеспечение 540 или портал автоматизации, инструментальное средство администрирования сети и т.д.) отправляют запросы в систему, чтобы применять конкретные стратегии. Например, системное программное обеспечение может использоваться для того, чтобы развертывать новый PLC, соединенный с набором устройств с конкретными сетевыми требованиями в реальном времени, требованиями по обеспечению безопасности и требованиями по доступности/устойчивости. В некоторых вариантах осуществления, приложения соответствуют программным/микропрограммным реализациям компонентов. Эти приложения могут развертываться на вычислительных ресурсах и могут использовать ресурсы хранения и сетевые ресурсы, чтобы обмениваться данными.

3. SDA-система

[0079] SDA-система содержит различные подсистемы, которые взаимодействуют, чтобы предоставлять полностью интегрированное решение для создания, управления и работы с автоматизированными системами. Фиг.6A является блок-схемой, иллюстрирующей подсистемы SDA-системы в соответствии с некоторыми вариантами осуществления. SDA-система 600 в некоторых вариантах осуществления включает в себя туманную серверную подсистему 605 ("туманный сервер"), имеющую туманный контроллер или резервированные туманные контроллеры 610, один или более вычислительных узлов 615 и хранилище 625. SDA-система 600 также включает в себя подсистему 630 программных компонентов. В других вариантах осуществления, SDA-система дополнительно может включать в себя подсистему 650 кибербезопасности (CS), имеющую контроллер безопасности или резервированные контроллеры 655 безопасности, и репозиторий 665 политик безопасности. В еще одних других вариантах осуществления, SDA-система также может включать в себя сетевую подсистему 670, имеющую сетевой контроллер или резервированные сетевые контроллеры 690, физическую сеть 680, физические сетевые компоненты 682, виртуальные сети 620, виртуальные сетевые компоненты 622 и репозиторий 685 сетевых политик.

[0080] Туманный сервер 605 предоставляет окружение виртуализации, в котором может работать и/или управляться автоматизированная система(ы). Туманный сервер 605 содержит вычислительные узлы 615, которые предоставляют логические характеристики обработки и могут выполнять хостинг приложений, базы данных и т.п.с высоким уровнем эластичности. Неограничивающие примеры вычислительных узлов включают в себя: серверы, персональные компьютеры, автоматизированные устройства, включающие в себя соединенные интеллектуальные устройства, и т.п.

[0081] Туманный серверный контроллер 610 использует программное обеспечение управления туманным сервером для того, чтобы выполнять свои функции. Программное обеспечение управления туманным сервером может быть основано на программном обеспечении управления облаком, таком как OpenStack. Программное обеспечение управления облаком, такое как OpenStack, в стандартной/типовой форме типично используется в мире информационных технологий (IT) для управления центром обработки и хранения данных. Тем не менее, управление автоматизированными системами заключает в себе другой набор сложных задач. Например, некоторые автоматизированные системы могут выполнять критичные по времени и/или критичные с точки зрения безопасности приложения, которым требуются детерминированные гарантии относительно задержки, надежности и/или других факторов. Рассмотрим автоматизированную систему для резки сыра, в которой высокоскоростное синхронизированное движение между лезвием ножа, режущим брикет сыра, и перемещением брикета сыра является критичным для того, чтобы формировать куски сыра одинаковой толщины. Если возникает задержка при обработке или сетевая задержка, она может приводить к кускам сыра различной толщины, приводя к отходам и потере производительности.

[0082] Туманный серверный контроллер 610 управляет всеми аспектами окружения виртуализации и полным жизненным циклом вычислительных узлов 615. Например, туманный сервер 605 может занимать и освобождать хосты, такие как виртуальные машины, контейнеры или платформы без программного обеспечения на вычислительных узлах, и создавать и уничтожать виртуализированные компоненты 645 и виртуальные сети 620. Виртуализированный компонент/элемент/экземпляр 645, при использовании в данном документе, представляет собой логический эквивалент физического устройства или части физического устройства, которое он представляет, реализованный в качестве программного объекта, который должен выполняться внутри туманного сервера 605. Виртуализированные компоненты 645 также могут включать в себя программные компоненты, такие как приложения и/или прикладные функции на хосте (например, виртуальная машина, сконфигурированная с приложением, представляет собой виртуализированный компонент/элемент/экземпляр).

[0083] Туманный серверный контроллер 610 может предоставлять высокую готовность (HA) через резервирование контроллера и управление сбоями вычислительных узлов. Контроллер также может управлять запуском, завершением работы и исправлением отдельных вычислительных узлов. В некоторых вариантах осуществления, туманная серверная платформа может предоставлять поддержку для высокой готовности виртуализированных компонентов. В некоторых вариантах осуществления, туманный сервер 605 может включать в себя узел хранения или хранилище 625 данных. Хранилище 625 может сохранять виртуальные образы, тома (т.е. жесткий диск образа, экземпляр которого создан), данные приложений и процессов и т.п.

[0084] Подсистема 630 программных компонентов может включать в себя виртуализированные компоненты 645, хостинг которых выполняется посредством экосистемы виртуализации туманного сервера 605. Подсистема 630 программных компонентов также может включать в себя виртуализированные экземпляры программного обеспечения 635, которые выполняются в окружении виртуализации (например, программного обеспечения для программирования, конфигурирования и/или управления (например, Unity, SoMachine, SCADA), которое используется для того, чтобы программировать, конфигурировать, управлять или иным образом взаимодействовать с автоматизированными устройствами. В некоторых вариантах осуществления, подсистема 630 программных компонентов также может включать в себя системное программное обеспечение 640 (также называемое порталом автоматизации), которое предоставляет один интерфейс для управления топологией, инвентаризацией, конфигурированием, программированием, контролем и/или диагностикой автоматизированных устройств и/или автоматизированной системы в целом.

[0085] Через системное программное обеспечение 640, пользователи могут осуществлять доступ к различным приложениям для определения системы и управления системой по всем фазам жизненного цикла. Например, системное программное обеспечение 640 может использоваться для того, чтобы конфигурировать и параметризовать оборудование в течение фазы инжиниринга и настраивать, программировать и/или диагностировать оборудование в течение фазы обслуживания. Некоторые выгоды системного программного обеспечения 640 включают в себя простоту и удобство для конечных пользователей, а также снижение затрат, поскольку все аспекты любого оборудования в автоматизированной системе могут управляться из одного портала. В дополнение к предоставлению одной точки входа для всей системы, системное программное обеспечение 640 также представляет согласованный пользовательский интерфейс и возможности работы пользователей, что помогает уменьшать несоответствие и повышать эффективность и производительность. Системное программное обеспечение 640 и его компоненты подробно описываются в отношении системного программного обеспечения 740 по фиг.7B.

[0086] CS-подсистема 650 включает в себя ассоциированный CS-контроллер или резервированные CS-контроллеры 655 и виртуализированные и/или физические компоненты 660 системы безопасности. Подсистема 650 безопасности предоставляет целостное решение по кибербезопасности через политики безопасности и компоненты системы безопасности, такие как системы обнаружения/защиты от проникновений, виртуализированные брандмауэры следующего поколения, центр сертификации и системы идентификации и т.п.CS-контроллер 655 распределяет политики безопасности в виртуализированные и/или физические компоненты для того, чтобы обеспечивать то, что необходимая защита для обеспечения безопасности вводится в действие. В некоторых вариантах осуществления, CS-подсистема также может предоставлять политику безопасности и услуги аутентификации в другие компоненты и подсистемы. Политики безопасности CS-системы 650 могут сохраняться в репозитории 665 политик безопасности в некоторых вариантах осуществления.

[0087] Сетевая подсистема 670 включает в себя сетевую Ethernet-инфраструктуру для всего решения на основе SDA-системы. В некоторых вариантах осуществления, сетевая подсистема 670 представляет собой сетевую SDN-подсистему, имеющую SDN-контроллер или резервированные SDN-контроллеры в качестве сетевого контроллера 690. SDN-сеть предоставляет отделение управляющей логики сети от базовых сетевых аппаратных средств (например, маршрутизаторов, коммутаторов) и логическую централизацию управления сетью через SDN-контроллер. Это означает то, что SDN-контроллер может распределять сетевые политики по всей сетевой инфраструктуре (т.е. физической сети 680 и физическим сетевым компонентам 682, а также виртуальным сетям 620 и виртуальным сетевым компонентам 622), чтобы управлять возможностями подключения, полосой пропускания и временем задержки, соглашениями об уровне обслуживания (SLA) (например, в ответ на: детерминированное время ответа/время передачи), управление потоком трафика и т.д., и сетевые аппаратные средства могут реализовывать эти политики. Сетевые политики сетевой подсистемы 670 могут сохраняться в репозитории 685 сетевых политик в некоторых вариантах осуществления.

[0088] В некоторых вариантах осуществления, сетевая подсистема 670 может содержать ячеистую радиосеть. В ячеистой радиосети, каждый узел может соединяться, по меньшей мере, с двумя другими узлами при этом, что данные передаются между узлами в процессе, называемом "перескоком". Поскольку непосредственно узлы служат в качестве маршрутизаторов, ячеистые радиосети типично не требуют выделенных маршрутизаторов. Тем не менее, некоторые ячеистые радиосети включают в себя один или более ячеистых маршрутизаторов наряду с ячеистыми узлами, чтобы ретранслировать трафик от имени других ячеистых маршрутизаторов и/или ячеистых узлов. В некоторых вариантах осуществления, сетевая подсистема 670 может содержать виртуальные схемы в высокоскоростной радиочастотной (RF) ячеистой или гибридной сети со связью, упрощенной посредством только приемо-передающих радиоустройств узлов без внешних устройств. Таким образом, в некоторых вариантах осуществления, конфигурирование сетевых элементов сетевой подсистемы или сетевой инфраструктуры может включать в себя конфигурирование ячеистых узлов и/или ячеистых маршрутизаторов (например, ячеистых маршрутизаторов с поддержкой OpenFlow) в ячеистой радиосети.

[0089] В некоторых вариантах осуществления, сетевая подсистема 670 может представлять собой чувствительную ко времени сетевую (TSN) подсистему, имеющую TSN-контроллер в качестве сетевого контроллера 690 и TSN-инфраструктуру. Сетевая TSN-подсистема обеспечивает то, что данные для решения критически важных задач и чувствительные ко времени данные передаются/совместно используются согласно предварительно заданному максимальному детерминированному времени передачи и с высокой надежностью. Типично, TSN-инфраструктура включает в себя сетевые компоненты с поддержкой TSN. Следует отметить, что в некоторых вариантах осуществления, сетевая подсистема 670 может содержать SDN- и TSN-сети (и в силу этого SDN- и TSN-контроллеры и SDN- и TSN-компоненты). В различных вариантах осуществления, сетевой контроллер 690 может представлять собой собственный туманный серверный виртуальный сетевой контроллер, традиционный контроллер системы управления сетью, SDN-контроллер, TSN-контроллер и/или любую комбинацию вышеозначенного.

[0090] Роли подсистем в SDA-решении дополняют друг друга, чтобы предоставлять полностью интегрированное решение. В частности, туманный сервер 605 может взаимодействовать с каждой из этих подсистем посредством хостинга виртуализированных элементов подсистемы и/или посредством функций управления подсистемой. Хотя туманный сервер 605 имеет интегральные взаимосвязи с каждой из SDA-подсистем, они не считаются находящимися в пределах объема туманного сервера 605. Фиг.6B является схемой, иллюстрирующей объем управления каждой из SDA-подсистем в соответствии с некоторыми вариантами осуществления.

[0091] Область действия туманного сервера 605 представляет собой туманный серверный контроллер 610, вычислительные узлы 615 и управление виртуализированными компонентами 645 в пределах туманного сервера 605. Виртуализированные компоненты 645 и программное обеспечение 635 (например, сервер архивных данных, SCADA, SoMachine, Unity) не находятся в пределах объема управления туманным сервером 605, а в объеме управления подсистемой 630 программных компонентов. Тем не менее, программные компоненты 630, через системное программное обеспечение 640, взаимодействуют с туманным серверным контроллером 610 и вычислительными узлами 615, чтобы предоставлять конфигурационные и управляющие вводы на туманный сервер 605 и/или в другие подсистемы, чтобы управлять их работой.

[0092] Чтобы предоставлять решение на уровне всей системы, неразрывность управления сетью расширяется таким образом, что она включает в себя и виртуальные и физические компоненты сети. Следовательно, область действия сетевой подсистемы 670 включает в себя не только физические сетевые компоненты 682 и физическую сеть 680, но также и виртуальные сети 620 и виртуальные сетевые компоненты 622, которые создаются и существуют в пределах туманного сервера 605. Это требует полной интеграции между сетевой подсистемой 670 и туманным сервером 605, чтобы предоставлять механизмы, чтобы осуществлять это управление. Например, туманный серверный контроллер 610 может создавать виртуальные сети 620 на туманном сервере 605 и управлять возможностями подключения между виртуальными машинами/контейнерами, хостинг которых выполняется на вычислительных узлах 615 и виртуальных сетях 620, в то время как сетевой контроллер 690 может конфигурировать виртуальные сетевые компоненты 622 виртуальных сетей 620 в соответствии с одной или более сетевых политик. Эта степень интеграции требует оркестровки последовательностей создания и удаления экземпляров, поскольку, очевидно, виртуальная сеть 620 должна существовать до того, как виртуальные машины и контейнеры могут быть соединены.

[0093] CS-подсистема 650 управляет компонентами системы безопасности, такими как системы 696A обнаружения проникновений (IDS), системы 696B защиты от проникновений (IPS) (например, виртуализированные брандмауэры следующего поколения) и т.п., а также CS-контроллером 655, который распределяет политики безопасности в различные объекты. CS-подсистема 650 может интегрироваться со всеми аспектами решения на основе SDA-системы в некоторых вариантах осуществления. Например, сетевой контроллер 690 может использовать услуги обеспечения безопасности, предоставленные посредством CS-подсистемы 650, чтобы предоставлять конфигурационную информацию системы безопасности в сетевые компоненты (например, физические или виртуальные) в пределах объема. В некоторых вариантах осуществления, туманный сервер 605 может использовать эту услугу для того, чтобы аутентифицировать входы в учетную запись, предоставлять политики безопасности для конфигураций хостов (виртуальных машин, контейнеров, платформ без программного обеспечения), проверять достоверность образов хостов перед созданием экземпляра, и т.п.

[0094] В некоторых вариантах осуществления, определенные подсистемы могут рассматриваться как внешние для решения на основе SDA-системы. Эти внешние подсистемы включают в себя не-SDN OT-сетевые и не-SDA краевые устройства 699 (например, унаследованные устройства) и оборудование 698 IT-сети и бэк-офиса. В некоторых вариантах осуществления, промышленный Интернет 697 вещей (IIoT) или другая облачная услуга могут считаться внешней или частью решения на основе SDA-системы.

4. Системное программное обеспечение или портал автоматизации

[0095] Фиг.7A является блок-схемой, иллюстрирующей взаимодействие между программным обеспечением для принятия решений и автоматизированным оборудованием в традиционных автоматизированных системах и в SDA-окружении в соответствии с некоторыми вариантами осуществления.

[0096] Типично, каждый тип оборудования имеет собственное конкретное программное обеспечение (также называемое инструментальным средством или программным инструментальным средством), с использованием которого оборудование может конфигурироваться, параметризоваться и/или программироваться. Например, в машинных/производственных автоматизированных системах 706, программное обеспечение 735A для принятия решений, к примеру, SoMachine используется для того, чтобы конфигурировать, параметризовать и/или программировать машинное оборудование 701. Аналогично, в технологических автоматизированных системах 708, другое программное обеспечение 735B для принятия решений, к примеру, PlantStruxure PES (Process Expert System) используется для того, чтобы конфигурировать, параметризовать и/или программировать процесс.На системном уровне, на котором автоматизированное оборудование является в большей степени соединенным и более тесно интегрированным, для пользователя очень неэффективно управлять этими программными решениями отдельно. В дополнение к проблемам управления, таким как отслеживание версий программного решения, модернизация и т.д., отдельное программное решение также означает то, что для пользователя невозможно иметь системный вид всего оборудования, т.е. машинного оборудования и технологического оборудования.

[0097] В SDA-системе, системное программное обеспечение 740, через общую инфраструктуру 742 и другие компоненты, согласовывает отдельные виды в системном виде. Другими словами, системное программное обеспечение 740 предоставляет вид системного уровня всех автоматизированных устройств/оборудования с учетом полного объема автоматизации. В вышеприведенном примере промышленной автоматизированной системы, это означает то, что через системное программное обеспечение 740, пользователь видит все машинное 701 и технологическое оборудование 702 и может конфигурировать, параметризовать и/или программировать это машинное и технологическое оборудование 701, 702 без необходимости отдельно запускать или активировать конкретное для типа оборудования программное обеспечение. Общая инфраструктура 742, в частности, предлагает согласованные пользовательские интерфейсы, правила программирования и инфраструктуру, чтобы упрощать связь с контроллерами (например, машинными контроллерами 712, заводскими контроллерами 714), HMI 790, оборудованием 701, 702 и т.п.независимо от того, являются они или нет связанными на уровне машины или процесса. Таким образом, системное программное обеспечение 740 упрощает проектирование, разработку и управление автоматизированной системы в целом.

[0098] Фиг.7B является блок-схемой, иллюстрирующей примерные компоненты системного программного обеспечения SDA-системы в соответствии с некоторыми вариантами осуществления.

[0099] Системное программное обеспечение 740 может представлять собой портал на основе веб-технологий или приложение, доступное из клиентских устройств. При использовании в данном документе, клиентские устройства могут включать в себя, но не только: инженерные станции, планшетные компьютеры 740A, мобильные устройства 740B, переносные компьютеры 740C, настольные компьютеры 740D, человеко-машинные интерфейсы (HMI)/мобильные HMI 790 и т.п.Как описано выше, системное программное обеспечение предоставляет одну точку входа, через которую множество автоматизированных устройств под управлением SDA-системы или оборудования, независимо от того, находятся они на туманном сервере или в заводском цехе, могут конфигурироваться, параметризоваться и программироваться. В зависимости от вариантов осуществления, системное программное обеспечение 740 может включать в себя большее или меньше число компонентов. Следует отметить, что только избранные компоненты системного программного обеспечения 740 проиллюстрированы для краткости.

[00100] Системное программное обеспечение 740, в некоторых вариантах осуществления, включает в себя общую инфраструктуру 742, как описано выше. Общая инфраструктура 742 может предоставлять прикладной интерфейс(ы) 752, интерфейс(ы) 754 контроллеров/устройств и пользовательский интерфейс(ы) 756, осуществляющие такие задачи, как программирование, конфигурирование, настройка, диагностика и т.д., достижимые из системного программного пользовательского интерфейса и более эффективные.

[00101] В некоторых вариантах осуществления, системное программное обеспечение 740 включает в себя компонент 726 формирования топологических видов, который может собирать информацию топологии из различных частей автоматизированной системы и подготавливать посредством рендеринга визуализацию системного уровня всего автоматизированного оборудования, будь то физическое или виртуализированное, и линии связи между ними. В некоторых вариантах осуществления, может формироваться топологический вид части автоматизированной системы. Топологический вид может представлять собой табличный вид (например, показанный на навигационной панели системного программного обеспечения 740), или диаграммный вид (например, показанный на панели проектирования системного программного обеспечения 740). Информация топологии может собираться посредством выполнения запроса относительно компонентов системного программного обеспечения 740, туманного контроллера (например, туманного серверного контроллера 410 на фиг.4A-4B, туманного серверного контроллера 610 на фиг.6A), сетевого контроллера (например, сетевого контроллера 690 на фиг.6A, соединений и наличия потоков между компонентами) и/или других подсистем SDA-системы в некоторых вариантах осуществления.

[00102] Системное программное обеспечение 740 также может включать в себя библиотеку 724 шаблонов функциональных модулей в некоторых вариантах осуществления. Шаблоны функциональных модулей представляют собой модели программного обеспечения функциональных модулей, которые могут параметризоваться и подвергаться созданию экземпляра на туманном сервере. Функциональный модуль, при использовании в данном документе, представляет собой аппаратный объект, программный объект или гибридный объект с аппаратными и программными частями, допускающими выполнение указанной цели или функции. Следует отметить, что функциональный модуль может состоять из других функциональных модулей. Например, PLC, привод, электромотор и модуль ввода-вывода могут считаться функциональным модулем, как и система транспортерной ленты, состоящая из трех PLC, двух модулей ввода-вывода, привода и электромотора.

[00103] В некоторых вариантах осуществления, системное программное обеспечение 740 может включать в себя набор компонентов, реализующих конкретную для предметной области логику или приложения. Например, компонент 728 параметризации может выполнять параметризацию оборудования и шаблонов функциональных модулей, описанных выше (например, HMI-параметризацию). При использовании в данном документе, параметризация включает в себя установку или задание свойств. Например, пользователь может выбирать оборудование из топологического вида, которое следует параметризовать. Компонент 728 параметризации может автоматически запускать интерфейс параметризации (например, меню) программного обеспечения параметризации, ассоциированного с оборудованием. Аналогично, конфигурационный компонент 732 может выполнять конфигурирование оборудования (например, конфигурирование привода для обеспечения движения). Как и в случае параметризации, пользователь может выбирать оборудование из топологического вида, которое следует конфигурировать. В ответ, конфигурационный компонент 732 может отображать интерфейс конфигурирования конфигурационного программного обеспечения, ассоциированного с выбранным оборудованием. Аналогично, компонент 734 программирования может запускать интерфейс программирования программного обеспечения для программирования, ассоциированного с выбранным оборудованием. Пользователь может писать или редактировать программный код непосредственно из интерфейса программирования, отображаемого в системном программном обеспечении, без необходимости запускать программное обеспечение для программирования. Если пользователь хочет изменять программный код другого оборудования (например, оборудования идентичного типа, но другого производителя, или совершенно другого типа оборудования (например, привода вместо PLC)), которое использует различное программное обеспечение для программирования, компонент 734 программирования автоматически идентифицирует оборудование и запускает интерфейс программирования, подходящий для того оборудования наряду с любым программным кодом, ассоциированным или в данный момент развернутым на оборудовании. В некоторых вариантах осуществления, ассоциирования между оборудованием/типом оборудования и приложениями могут быть определяемыми пользователем и могут сохраняться в узле хранения.

[00104] В некоторых вариантах осуществления, системное программное обеспечение 740 также может включать в себя набор компонентов, которые поддерживают управление кибербезопасностью, управление сетью, управление данными и/или другие аспекты автоматизированной системы. Например, компонент 716 управления сетью может отслеживать автоматизированное оборудование, соединенное с сетями между устройствами и/или сетями управления (например, чтобы обнаруживать новые устройства, когда они соединяются с сетью, чтобы обнаруживать устройство, которое переходит в оффлайновый режим). В некоторых вариантах осуществления, компонент 716 управления сетью также может отслеживать сетевые компоненты, такие как коммутационное и маршрутизирующее оборудование, которые являются частью физической сети.

[00105] Компонент 718 управления кибербезопасностью, в некоторых вариантах осуществления, может управлять аспектами кибербезопасности автоматизированной системы. Например, компонент 718 CS-управления может создавать и поддерживать профили безопасности, которые могут быть ассоциированы с любым новым функциональным модулем или автоматизированным оборудованием в автоматизированной системе. Компонент 722 управления данными в некоторых вариантах осуществления может управлять тем, как данные совместно используются различными компонентами и оборудованием в автоматизированной системе. Типично, большие объемы различных данных формируются посредством различных частей системы. Извлечение больших объемов данных в одно место и управление, организация и отображение таких данных становятся сложной и грандиозной задачей. Системное программное обеспечение 740, через компонент 722 управления данными, разрешает эту проблему посредством агрегирования данных из различных частей системы в одном месте, задания организации и анализа данных намного более эффективными. В некоторых вариантах осуществления, компонент 722 управления данными может предоставлять различные фильтры, которые могут применяться, чтобы просматривать избранные данные, ассоциированные с конкретным оборудованием или поднабором оборудования, без необходимости осуществлять доступ к различному программному обеспечению, ассоциированному с различным оборудованием. В некоторых вариантах осуществления, компонент 722 управления данными также может управлять и отображать, в окружении системного программного обеспечения, системные переменные, которые включают в себя данные, совместно используемые различными устройствами в системе и серверами публикации данных.

[00106] Фиг.7C-7F являются схемами со снимками экрана, иллюстрирующими примерные пользовательские интерфейсы системного программного обеспечения в соответствии с некоторыми вариантами осуществления. Фиг.7C иллюстрирует примерный снимок экрана пользовательского интерфейса 750 системного программного обеспечения 740, предоставляющего графический вид устройств в примерной автоматизированной системе. Через системное программное обеспечение, пользователь может управлять всем жизненным циклом системы, начиная с проектирования 752, конфигурирования 754 и программирования 756. Как проиллюстрировано, примерная автоматизированная система включает в себя PLC 758, PLC 760 и привод 240, в числе других.

[00107] В некоторых вариантах осуществления, системное программное обеспечение обеспечивает возможность непосредственного доступа к различным приложениям, ассоциированным с устройствами, показанными в графическом виде, из интерфейса системного программного обеспечения (или вида с точки зрения проектирования). Например, как проиллюстрировано на снимке 751 экрана по фиг.7D, пользователь может выбирать PLC 760 и щелкать "Конфигурировать" из меню 764. Снимок 753 экрана по фиг.7E иллюстрирует интерфейс 768 PLC-конфигурирования приложения 766 для PLC-конфигурирования, которое запускается в ответ на запрос на конфигурирование. Аналогично, примерный конфигурационный экран 770, ассоциированный с приводом 762, проиллюстрированным на фиг.7C, может быть доступным непосредственно из системного программного обеспечения, как проиллюстрировано на снимке экрана 755 на фиг.7F. В некоторых вариантах осуществления, код, запрограммированный в устройстве, также может быть доступным, может редактироваться и повторно развертываться на устройстве непосредственно из системного программного обеспечения.

5. Туманный сервер

[00108] Фиг.8A является блок-схемой, иллюстрирующей туманные серверные компоненты в соответствии с первым вариантом осуществления. Туманный сервер состоит из инфраструктуры контроля и управления, называемой контроллерными узлами 810-1, 810-2, наряду с ассоциированными вычислительными узлами 820-1, 820-2, 820-3,..., 820-N. Каждый из вычислительных узлов 820-1, 820-2, 820-3,..., 820-N может выполнять определенное число хостов 802-1,..., 820-N и ассоциированных виртуальных сетей 820. Эти хосты могут представлять собой виртуальные машины, контейнеры или платформы без программного обеспечения. Каждый хост в свою очередь может выполнять гостя 804. Гость 804 может включать в себя приложение, прикладную функцию (т.е. фрагмент или часть приложения, соответствующую или выполняющую функцию) либо любую программную реализацию физического устройства, компонентного или функционального модуля. В некоторых вариантах осуществления, хост 802-1 может выполнять другой хост 802-A, который в свою очередь может выполнять гостя. Например, хост 802-1 вычислительного узла 820-3 может представлять собой виртуальную машину, на которой создается экземпляр контейнера 802-A, чтобы выполнять гостя 804. Виртуальные сети 820 соединяются из вычислительных узлов (например, 820-1, 820-2...) через внешние интерфейсы (например, Ethernet-порты) с внешними физическими сетями (например, сетью 865 передачи данных/OT-сетью). Виртуальные сети 820 постоянно размещаются в вычислительных узлах (например, 820-1, 820-2...) и предоставляют возможности подключения между виртуализированными объектами и материальным миром. В некоторых вариантах осуществления, вычислительный узел может представлять собой соединенное интеллектуальное устройство, которое может иметь физическую часть и виртуальную часть. Например, вычислительный узел 820-N может представлять собой соединенное интеллектуальное устройство 815, которое может выполнять хост 802-B, выполняющий гостя 804. Идентичное соединенное интеллектуальное устройство 815 также может иметь физический датчик/актуатор 814. Вычислительный узел 820-N в качестве других вычислительных узлов может соединяться с сетью 865 передачи данных/OT-сетью.

[00109] Гости 804 не считаются частью туманного сервера; тем не менее, управление этими объектами находится в пределах области действия туманного сервера. Некоторые действия по управлению включают в себя распределение и перераспределение хостов, создание экземпляра хостов, планирование и управление ресурсами (например, выделение RAM, сетевых интерфейсов и других ресурсов), выделение ресурсов хранения, разрушение и т.п.

[00110] Хотя виртуальные сети 820 сконфигурированы через услуги, предоставленные посредством туманного сервера, ответственность за оркестровку этих сетей принадлежит сетевой подсистеме. Это предоставляет возможность связанного управления сетью между физическими и виртуальными сетями.

[00111] Туманные серверные контроллерные узлы 810-1, 810-2 взаимно соединяются с вычислительными узлами 820-1, 820-2..., 820-N через линии 812 связи сети управления. Эти линии связи могут быть физическими с выделенными кабельными соединениями либо могут представлять собой логические линии связи в базовой физической сети. Например, линия 812 связи может находиться в физических сетях 806 или 865. В качестве другого примера, линии 806, 812 и 865 связи могут совместно использовать идентичную физическую сеть, но различные логические сети. Использование таких технологий, как VLAN, VxLAN, VTN и т.п., для того чтобы предоставлять логическое разделение физической сети, обеспечивает возможность параллельного использования единой сети для нескольких целей. В некоторых вариантах осуществления, туманный серверный контроллер 810-2 может представлять собой резервированный контроллер, которые предоставляют характеристики высокой готовности (HA).

[00112] Узел(ы) 825-1 хранения/резервированный узел 825-2 хранения может предоставлять решение по хранению больших объемов данных, которое оптимизировано для типа доступа и требованиям к данным и по времени задержки, необходимым для того, чтобы выполнять автоматизированную систему. Этот узел может быть необязательным в некоторых вариантах осуществления. Узел(ы) хранения может быть включен в систему в качестве узла(ов) хранения, непосредственно соединенного с сетью(ями) 812 управления и/или OAM-сетью(ями) 806. Если узел хранения не предоставляется, эта роль может предполагаться посредством контроллерных узлов 810-1, 810-2 и/или вычислительных узлов 820-1,..., 820-N. Узлы хранения могут использовать резервирование, чтобы предоставлять HA в некоторых вариантах осуществления. Следует отметить, что в некоторых вариантах осуществления, узел 825-1, 825-2 хранения может представлять собой логически централизованный узел, содержащий другие узлы хранения, которые могут быть потенциально распределены.

[00113] Фиг.8B является блок-схемой, иллюстрирующей туманные серверные компоненты в соответствии со вторым вариантом осуществления. Этот альтернативный сценарий развертывания оптимизирует аппаратные средства, используемые для того, чтобы реализовывать туманный сервер. Этот сценарий развертывания, известный как модель на основе оконечного абонентского оборудования (CPE), сворачивает функции контроллера, хранения и вычисления в одно серверное устройство, т.е. CPE-узел 822-1. Серверный CPE-узел также может быть дублирован (т.е. CPE-узел 822-2), чтобы предоставлять HA-развертывания в некоторых вариантах осуществления. В этом варианте осуществления, серверные CPE-узлы могут обмениваться данными через сеть 812 управления. Узел(ы) 825 хранения может быть включен в систему в качестве узлов(ы) хранения, непосредственно соединенных с сетью(ями) 812 управления и/или OAM-сетью(ями) 806, и/или сетью(ями) 855передачи данных. Если узел хранения не предоставляется, эта роль может предполагаться посредством CPE-узлов 822-1 и 822-2. Этот сценарий предоставляет недорогое решение, которое может использоваться для целей меньшего развертывания, которые принимают ограничение в виде отсутствия распределенных вычислительных узлов.

[00114] Фиг.9A является блок-схемой, иллюстрирующей примерные компоненты туманного серверного контроллера в некоторых вариантах осуществления. Как проиллюстрировано, туманный серверный контроллер 910 может включать в себя компонент 902 туманной оркестровки и компонент 916 управления хостами, в числе других. Компонент 902 туманной оркестровки взаимодействует с компонентами оркестровки других подсистем SDA-системы для инициализации, конфигурирования, управления и т.п.Роль компонента 902 туманной оркестровки поясняется подробно на фиг.10B и 11.

[00115] В некоторых вариантах осуществления, компонент 916 управления хостами может использовать одну или более технологий виртуализации хостов, чтобы предоставлять инфраструктуру виртуализации, в которой может работать и/или управляться автоматизированная система. Например, компонент 916 управления хостами может использовать технологии виртуализации хостов, чтобы создавать виртуализированные экземпляры устройства (например, программную реализацию устройства на виртуальной машине), приложения или функция в автоматизированной системе. Виртуализированное устройство выполняется в качестве чисто программного экземпляра в окружении, которое представляет для виртуального устройства абстракцию физических аппаратных средств, изолированных от хост-системы. В дополнение к устройствам, различные другие аспекты автоматизированной системы, такие как сети и элементы системы безопасности, также могут быть виртуализированы в некоторых вариантах осуществления. Ниже подробно описываются некоторые технологии виртуализации хостов, которые могут использоваться посредством компонента 916 управления хостами.

A. Классическая VM

[00116] Фиг.9B иллюстрирует примерные компоненты вычислительного узла, выполняющего хостинг виртуальных машин. В некоторых вариантах осуществления, вычислительные узлы 915 с поддержкой виртуализации могут использовать виртуальные машины (VM) 902-1,..., 902-N (хост) для того, чтобы предоставлять очень гибкие приложения 912 по принципу "песочницы" (гость). Вычислительный узел 915 выполняет хостинг одной или более виртуальных машин 902-1,..., 902-N, включающих в себя бизнес-логику приложения 912 и собственную ОС/библиотеки 926. Этот механизм предоставляет гибкое применение, поскольку гостевая VM может быть основана на любой операционной системе 916 и даже может использовать эмуляцию, чтобы сбрасывать ограничения на аппаратную архитектуру. По сути, виртуальная машина может иметь собственные виртуальные аппаратные средства. Фактически, поскольку VM содержат прямой доступ к CPU через гипервизор, и каждая классическая VM имеет собственное виртуальные аппаратные средства 924, ядро 922, инициализирующую систему 918 и ОС 916, можно запускать совершенно различные ОС (например, Windows, Linux) на идентичном вычислительном узле параллельно, независимо от собственной ОС вычислительного узла. Штраф по сравнению с другими решениями (описаны ниже) может заключаться в производительности и детерминизме. Еще одной слабостью может быть размер приложения, который может быть существенно больше, поскольку оно должно включать в себя полное ядро 922, инициализирующую систему 918, операционную систему 916 и ассоциированные библиотеки 914. Типично доступ к физическим аппаратным средствам 932 предоставляется через гипервизор 928, что добавляет дополнительный слой и ассоциированное время задержки. Некоторые конкретные для производителя ускорения могут использоваться для того, чтобы смягчать это последствие.

[00117] Виртуальные машины 902-1,..., 902-N могут мигрировать вживую, т.е. рабочие VM могут мигрировать между вычислительными узлами с очень минимальным влиянием на рабочие VM и ассоциированные прикладные процессы. Это обеспечивает возможность компоненту 916 управления хостами и/или компоненту 902 туманной оркестровки предоставлять степень балансировки нагрузки, высокой готовности и управления энергопотреблением посредством оптимизации распределения VM между несколькими вычислительными узлами 915 и завершать работу ненужных вычислительных узлов.

B. Контейнеры

[00118] Фиг.9C и 9D иллюстрируют примерные компоненты вычислительных узлов, выполняющих хостинг контейнеров. Контейнеры обеспечивают улучшения с точки зрения производительности, гибкости и размера для приложений, но предоставляются с собственным набором ограничений. Контейнеры используют "песочницу" запоминающего устройства, которая поддерживается посредством аппаратных средств хост-машины, чтобы предоставлять защищенное и изолированное окружение для того, чтобы выполнять приложение. Использование контейнера предоставляет некоторые улучшения с точки зрения производительности и размера по сравнению с VM, поскольку он непосредственно использует драйверы хоста без слоя гипервизора. Тем не менее, при использовании контейнеров, приложение неразрывно связывается с аппаратной архитектурой и ядром хоста. Одно примерное приложение контейнеров представляет собой сценарий "запрос/реакция".

[00119] Ссылаясь на фиг.9C, чтобы достигать лучшей производительности, некоторые контейнеры 904-1,..., 904-N могут включать в себя только приложение 912, при базировании на ядре 934, инициализирующей системе 918, операционной системе 916 и библиотеках 914, собственных для вычислительного узла. Эти контейнеры имеют больше ограничений с точки зрения разработки библиотек/приложений, но являются более легкими, компактными, быстрыми в развертывании и допускают лучшую производительность.

[00120] Ссылаясь на фиг.9D, некоторые контейнеры 907-1,..., 907-N могут включать в себя полную операционную систему 916 (минус ядро) для гостевого приложения 912, инициализирующей системы 918 и библиотек 914, но работать в пределах конейнерного пространства по принципу "песочницы" хоста. Поскольку контейнеры основываются на ядре 934 хоста и его ассоциированных физических аппаратных средствах 932, они должны также совпадать с происхождением аппаратной архитектуры и ядра хоста 915.

[00121] Аналогично VM, контейнеры также могут мигрировать вживую между вычислительными узлами.

C. Платформа без программного обеспечения

[00122] Фиг.9D иллюстрирует примерные компоненты вычислительного узла без программного обеспечения. В некоторых вариантах осуществления, вычислительные узлы 915 могут служить в качестве хостов платформы без программного обеспечения, чтобы обеспечивать возможность встроенным системам управляться посредством компонента 916 управления хостами туманного сервера. Хосты платформы без программного обеспечения запускают специализированный двоичный образ, который тесно соединяется с аппаратными средствами 932 хоста; во многом аналогично традиционному встроенному устройству. Это двоичный образ может в полной мере пользоваться преимуществом прямого доступа к аппаратным средствам 932, идентично тому, как если образ установлен на заводе. В некоторых вариантах осуществления, аналогично тому, как VM управляются в пределах туманного сервера, вычислительные узлы без программного обеспечения могут инициализироваться и конфигурироваться через компонент 906 инициализации и компонент 908 конфигурирования системы 916 управления хостами на фиг.9A.

[00123] В некоторых вариантах осуществления, образ для платформы без программного обеспечения может представлять собой полное ядро 934 и ОС 916, чтобы превращать узел без программного обеспечения в полный вычислительный узел с VM и/или контейнеры с собственной поддержкой для VM и/или контейнеров.

[00124] Ссылаясь на фиг.9A, компонент 906 инициализации может создавать виртуальные сети поставщиков и/или участников арендуемой среды и виртуализированные экземпляры и соединять их между собой. Компонент 908 конфигурирования может упрощать конфигурирование виртуализированных экземпляров и/или физических устройств под управлением туманного сервера. Данные, которые используются для конфигурирования, могут приниматься из системного программного обеспечения в некоторых вариантах осуществления.

6. Оркестровки в SDA-системе

[00125] Фиг.10A является блок-схемой, иллюстрирующей пример компонентного вида SDA-системы в соответствии с некоторыми вариантами осуществления. На туманном сервере 1005 (или туманной платформе), одно или более виртуальных устройств 1036 и экземпляров приложений 1-N могут выполняться на одном или более вычислительных узлов (не показаны) и/или краевых устройств, проиллюстрированных в качестве соединенного интеллектуального устройства 1015. В некоторых вариантах осуществления, аналитическое приложение(я) или механизмы 1006 могут выполняться в удаленном облаке 1050 (например, в облаке 450 на фиг.4), как проиллюстрировано, на туманном сервере 1005 или в том, и на другом. В промышленной автоматизированной системе, приложения, связанные с корпоративными системами 1035 (например, системой планирования ресурсов предприятия (ERP), системой управления производством (MES)) и управлением 1014 активами, могут выполняться на уровне общекорпоративной серверной (например, на уровне 4, уровне 205 общекорпоративной серверной комнаты на фиг.2B) или на туманном сервере 1005, в то время как некоторое оконечное абонентское программное обеспечение 1008 (например, SCADA) может выполняться на туманном сервере 1005. В системе автоматизации зданий, приложения, выполняющиеся на корпоративном уровне и на уровне туманного сервера 1005, могут иметь системы управления зданиями (не показаны).

[00126] В некоторых вариантах осуществления, физическое устройство 1034 может не иметь возможность соединяться с сетью, чтобы становиться туманным серверным управляемым устройством. Такое устройство по-прежнему может управляться и контролироваться через киберустройство 1032, которое управляется посредством туманного сервера 1005. Это киберустройство 1032 может быть виртуальным представлением одного или более физических устройств. Киберустройство 1032 может публиковать/подписываться на данные реального времени на туманном сервере 1005 или альтернативно может использовать связь "точка-точка" для того, чтобы получать доступ к данным из приложений/устройств, управляемых посредством туманного сервера 1005. Киберустройство 1032 может обмениваться данными с физическим устройством 1034 по OT-протоколу. Туманное управляемое киберустройство 1032 в силу этого может функционально соединяться с физическим устройством 1034 через OT-протокол, чтобы формировать программно-определяемую машину 1046.

[00127] Фиг.10B является блок-схемой, иллюстрирующей примеры управляющего вида и системного вида SDA-системы в соответствии с некоторыми вариантами осуществления. Управляющий SDA-вид 1002 включает в себя системное программное обеспечение 1040 и определенное число компонентов оркестровки, которые обеспечивают то, что каждая из SDA-подсистем работают координированно, чтобы задавать или вводить в действие и управлять автоматизированной системой. Компоненты оркестровки включают в себя компонент 1024 оркестровки туманного сервера, компонент 1022 оркестровки сети, компонент 1018 оркестровки кибербезопасности и компонент 1016 оркестровки хранения.

[00128] Системный SDA-вид 1012, в некоторых вариантах осуществления, включает в себя туманный сервер 1005, имеющий туманный серверный контроллер 1010, один или более вычислительных узлов 1015 и хранилище 1025. В некоторых вариантах осуществления, хранение может находиться за пределами туманного сервера 1005, как проиллюстрировано посредством хранилища 1026. Вычислительные узлы 1015 и хранилище 1025 на туманном сервере 1005 могут оркестроваться между собой посредством компонента 1024 оркестровки туманного сервера в некоторых вариантах осуществления (т.е. оркестровки 1024 туманного сервера и оркестровки 1026 хранения могут комбинироваться). Хотя каждый из компонентов оркестровки отдельно оркеструется, компонент оркестровки верхнего уровня (компонент 1016 оркестровки системы) оркеструет их между собой, чтобы виртуализировать устройства и приложения на вычислительных узлах 1015 на туманном сервере 1005 (через оркестровку 1024 туманного сервера), управлять данными, ассоциированными с этими виртуализированными устройствами и приложениями в хранилище 1025/1026 (через оркестровку 1026 хранения), задавать и распределять политики кибербезопасности во все компоненты SDA-системы (через оркестровку 1018 кибербезопасности) и сетевые потоки и связь (через оркестровку 1022 сети). Системное программное обеспечение 1040 взаимодействует с компонентом 1016 оркестровки системы, чтобы преобразовывать команды/инструкции/сигналы (например, от пользователя или другой системы) через оркестровку 1024 туманного сервера, оркестровку 1022 сети, оркестровку 1018 кибербезопасности и/или оркестровку 1026 хранения в изменения автоматизированной системы. Кроме того, системное программное обеспечение 1040 может выполняться на туманном сервере 1005 и имеет полный вид автоматизированной системы.

[00129] В некоторых вариантах осуществления, оркестровка сети включает в себя SDN-оркестровку (например, через SDN-контроллер), TSN-оркестровку (например, через TSN-контроллер) или SDN-TSN-оркестровку, которая представляет собой комбинацию SDN- и TSN-оркестровок (через SDN- и TSN-контроллеры).

[00130] В некоторых вариантах осуществления, экземпляры приложения, выполняющиеся на туманном сервере 1005 или на краевом устройстве 1004, могут совместно использовать данные с использованием протокола связи, такого как услуга распределения данных (DDS) или унифицированная архитектура связи на открытой платформе (OPC-UA). DDS обеспечивает возможность любому оборудованию, соединенному с сетью 1042, подписываться на любые данные, сформированные посредством туманных серверных управляемых устройств (например, устройства 1004, виртуальных устройств/компонентов в вычислительных узлах 1015). Устройства могут обновлять абонентов в реальном времени посредством публикации значения данных, когда эти значения изменяются в некоторых вариантах осуществления.

[00131] В других вариантах осуществления, данные могут совместно использоваться через связь "точка-точка". Независимо от применяемых протоколов совместно используемой связи или связи "точка-точка", трафик данных в/из экземпляров приложения, выполняемых на виртуальных устройствах/компонентах в вычислительных узлах 1015, переносится по виртуальным сетям 1020, которые соотнесены с физической сетью 1042. Аналогично, трафик данных в/из приложений, выполняемых на физических устройствах, переносится посредством физической сети 1042.

[00132] Фиг.11 является блок-схемой, иллюстрирующей пример оркестровки SDA-подсистем, чтобы инициализировать функциональный модуль на вычислительном узле в соответствии с некоторыми вариантами осуществления.

[00133] В некоторых вариантах осуществления, системное программное обеспечение 1140, выполняющее экземпляр набора инженерных инструментальных средств, предоставляет возможность пользователю создавать экземпляр и управлять SDA-системой. Набор инженерных инструментальных средств может быть конкретным для целевой автоматизированной системы. Например, набор инструментальных средств, предназначенный для промышленной автоматизированной системы, отличается от набора инструментальных средств, предназначенного для системы автоматизации зданий, поскольку эти автоматизированные системы могут иметь различные типы автоматизированных устройств (и в силу этого различные шаблоны устройств/функциональных модулей), а также одно или более приложений для параметризации, конфигурирования, программирования и т.п.Набор инженерных инструментальных средств интегрируется с компонентом 1116 оркестровки системы (SDA) через интерфейс прикладного программирования (API). Таким образом, когда пользователь набора инструментальных средств выдает команду, набор инструментальных средств управляет компонентом 1116 оркестровки системы таким способом, который инструктирует SDA-системе в целом работать координированно, чтобы выполнять команду.

[00134] Рассмотрим сценарий, в котором пропускная способность оформления и обработки багажа в аэропорту должна увеличиваться посредством добавления новой транспортерной ленты. Пользователь может осуществлять доступ к системному программному обеспечению 1140 (загружаемому с помощью подходящего набора инструментальных средств) и выбирать шаблон функциональных модулей, например, шаблон для системы транспортерной ленты, из списка выбора и добавлять его в панель проектирования системы управления. Пользователь может параметризовать шаблон, чтобы предоставлять информацию экземпляров для нового функционального модуля. Например, шаблон транспортерной ленты может содержать три виртуальных PAC, определенное число вводов-выводов, определенное число физических и виртуальных коммутаторов. Пользователь может предоставлять информацию экземпляров, к примеру, но не только: идентификационные данные экземпляра (например, названия компонентов/устройств, IP-адреса и т.д.), возможности подключения для ввода-вывода (например, то, как соединены элементы функционального модуля, то, в какие/из каких устройств ввода-вывода функциональный модуль может считывать/записывать), временные ограничения (например, максимальное детерминированное время ответа или время передачи между функциональным модулем и другим объектом, например, оборудованием, которым он управляет), профили безопасности (например, способность считывать/записывать доступ к данным, способность программировать функциональный модуль) и т.п.Описание 1142 функциональных модулей, т.е. информация, описывающая шаблон функциональных модулей, который должен подвергаться созданию экземпляра, передается посредством системного программного обеспечения 1140 в компонент 1116 SDA-оркестровки. В некоторых вариантах осуществления, описание 1142 функциональных модулей может включать в себя информацию, связанную с описанием виртуализации функциональных модулей, потоками связи, сетевыми потоками, профилями безопасности и т.п.В качестве примера, описание виртуализации функциональных модулей может включать в себя информацию экземпляров, включающую в себя тип и количество компонентов, которые должны подвергаться созданию экземпляра или инициализироваться (например, 3 PLC, 2 распределенных модуля ввода-вывода, 1 виртуальный коммутатор в примере транспортерной ленты), требования по резервированию и т.п.Описание виртуализации функциональных модулей также может включать в себя, для каждого компонента, ассоциированные приложения и версию приложений, ассоциированный пакет программирования (например, Unity для PLC) и т.п., чтобы упрощать конфигурирование и программирование функционального модуля или его компонентов.

[00135] Описание потока связи может включать в себя информацию, связанную с возможностями подключения для ввода-вывода или линиями связи, типом приоритета ввода-вывода (например, высокий приоритет, низкий приоритет), временными ограничениями, списком ввода-вывода с информацией соединения (например, данными, скоростью), обменом данными между равноправными узлами, SCADA-обменом данными, другими объявлениями потоков (SNMP, сеть, электронная почта и т.д.) и т.п.Профили безопасности могут включать в себя списки управления доступом (ACL), списки портов и протоколов, ограничения по авторизованной полосе пропускания, включенные в черный/белый список веб-узлы/адреса и/или т.п.В некоторых вариантах осуществления, описание 1142 функциональных модулей также может включать в себя конфигурации гостей (например, виртуальных машин), таких как, но не только: типы процессора, запоминающее устройство, подобие, проверка достоверности образов виртуальных машин и т.п.Описание сетевых потоков может включать в себя такую информацию, как полоса пропускания и списки портов, ограничения по трактам потоков (например, без видеоданных или высокоскоростных данных по линиям связи для ввода-вывода с высоким приоритетом), возможности подключения портов, скорость работы интерфейса и т.п.

[00136] Компонент 1116 SDA-оркестровки синтаксически анализирует описание функциональных модулей на вспомогательные описания и начинает управление окрестраторами различных подсистем, соответственно. Например, компонент 1116 SDA-оркестровки передает описание запрашиваемых потоков 1144 связи, извлеченных из описания 1142 функциональных модулей, в компонент 1118 оркестровки кибербезопасности CS-контроллера 1155. Компонент 1118 CS-оркестровки, на основе запрашиваемых потоков 1144 связи, извлекает политики безопасности для доступа к хосту/гостевого доступа, сегментацию сетевого трафика, конфигурации брандмауэра, ACL-конфигурации (например, IP-адрес/имя объекта соединения и природу намеченного соединения, к примеру, TCP/UDP-порт, разрешенные типы доступа, блокировку неавторизованных протоколов и портов и т.п.), авторизованные входы в учетную запись для отслеживания, конфигурирования и т.п.Управление типами трафика, разрешенными для конечных точек, конфигурирование защищенных каналов, управление длиной пакетных данных и адресацию и т.п.В некоторых вариантах осуществления, различные политики безопасности могут управляться посредством диспетчера 1126 политик безопасности. Услуга 1128 аутентификации в некоторых вариантах осуществления может предоставлять услуги аутентификации другим подсистемам. Например, она может аутентифицировать запросы, чтобы виртуализировать функциональный модуль.

[00137] Компонент 1118 оркестровки кибербезопасности, в некоторых вариантах осуществления, предоставляет необходимые политики безопасности для туманного серверного контроллера 1110 и сетевого контроллера 1190 (например, SDN-, TSN- и/или другого сетевого контроллера(ов)) в компонент 1115 SDA-оркестровки. В других вариантах осуществления, компонент 1118 CS-оркестровки может инструктировать распределение политик безопасности непосредственно в релевантные контроллеры. Например, политики безопасности, связанные с функциями виртуализации, -в туманный контроллер 1110, и политики безопасности, связанные с сетевыми функциями, -в сетевой контроллер 1190. В некоторых вариантах осуществления, CS-контроллер 1155 может распределять правила политик устройств и коммутаторов в систему защиты для обеспечения безопасности, которая затем может управлять развертыванием и принудительной активацией этих политик на уровне устройств.

[00138] Компонент 1116 SDA-оркестровки, после приема политик 1148 безопасности из CS-контроллера 1155, передает описание виртуализированных элементов функционального модуля, извлеченное из описания 1142 функциональных модулей, и релевантные политики 1152 безопасности в компонент 1124 туманной оркестровки. В некоторых вариантах осуществления, компонент 1124 туманной оркестровки может запрашивать CS-контроллер 1155 на предмет релевантных политик безопасности. Компонент 1124 туманной оркестровки управляет туманным серверным контроллером 1110 (например, компонентом 916 управления хостами на фиг.9A) с возможностью создавать, по мере необходимости, виртуальные сети 1120 поставщиков и/или участников арендуемой среды в одном или более вычислительных узлов. Это может включать в себя создание экземпляра виртуальных коммутаторов или виртуальных маршрутизаторов. Компонент 1124 туманной оркестровки создает виртуализированный экземпляр функционального модуля 1134, что включает в себя создание виртуализированного экземпляра каждого компонента в функциональном модуле (т.е. 3 vPAC и 1 виртуального коммутатора в этом примере) и соединение виртуализированных экземпляров с ассоциированными виртуальными сетями 1120. В некоторых вариантах осуществления, на основе требований по резервированию (например, предварительно заданных или указываемых с помощью запроса), может инициализироваться более одного экземпляра функционального модуля 1134.

[00139] Компонент 1116 SDA-оркестровки передает описание сетевых потоков 1154, ассоциированных с функциональным модулем, и все требуемые политики 1154 безопасности в компонент 1122 оркестровки сети. Из этого описания, компонент 1122 оркестровки сети может различать требуемые сетевые тракты, сегментацию и т.п.и управлять сетевым контроллером 1190 с возможностью конфигурировать сетевые элементы 1136 в физической сети, а также сетевые элементы в виртуальных сетях 1120, соответственно. В некоторых вариантах осуществления, все устройства (например, физические и виртуальные инфраструктурные и конечные устройства) могут запрашивать свои ассоциированные политики безопасности из сервера 1138 политик. Таким образом, SDA-система может не только инициализировать функциональный модуль на вычислительном узле, но также может инициализировать сетевые ресурсы, которые требуются функциональному модулю для работы.

[00140] После того, как функциональный модуль создан или инициализирован, и сетевая инфраструктура сконфигурирована соответствующим образом, системное программное обеспечение затем может использоваться для того, чтобы конфигурировать и программировать компоненты функционального модуля. Например, vPAC функционального модуля могут конфигурироваться и программироваться с использованием ассоциированного программного обеспечения через портал системного программного обеспечения, чтобы управлять работой системы транспортерной ленты. В некоторых вариантах осуществления, конфигурирование функционального модуля также может включать в себя конфигурирование ассоциированных физических компонентов функционального модуля. Например, туманный серверный контроллер 1110 может переконфигурировать модуль ввода-вывода посредством обновления своего ACL, чтобы обеспечивать возможность vPAC соединяться. В некоторых вариантах осуществления, модуль ввода-вывода может представлять собой соединенное интеллектуальное устройство, в котором туманный серверный контроллер 1110 может программировать ассоциированную логику (например, логику для обработки функциональности на основе безопасности).

7. Примерные технологии, реализованные в SDA-системе

[00141] Фиг.12 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ создания автоматизированной системы в соответствии с некоторыми вариантами осуществления.

[00142] На этапе 1202, туманная серверная подсистема, которая включает в себя туманный серверный контроллер и несколько вычислительных узлов, создает или создает экземпляр виртуальных компонентов автоматизированной системы на одном или более вычислительных узлов (например, через компонент 906 инициализации на фиг.9A). Элементы автоматизированной системы могут быть виртуализированы с использованием технологий виртуализации, таких как виртуальные машины, контейнеры и платформы без программного обеспечения. Кроме того, вычислительные узлы, на которых выполняются виртуальные компоненты, могут быть физически распределены в некоторых вариантах осуществления. Например, один вычислительный узел может находиться в заводском цехе, в то время как другой вычислительный узел может находиться в аппаратной. Независимо от того, где расположены вычислительные узлы, связь между туманным серверным контроллером и вычислительными узлами осуществляется по выделенной сети управления, отдельной от физической сети, или по идентичной физической сети.

[00143] На этапе 1204, туманная серверная подсистема (например, через компонент 906 инициализации на фиг.9A) создает ассоциированные виртуальные сети в вычислительных узлах. На этапе 1206, туманная серверная подсистема (например, через компонент 906 инициализации на фиг.9A) соединяет виртуальные компоненты с виртуальными сетями. Виртуальные сети затем соединяются с физической сетью. На этапе 1208, сетевая подсистема, включающая в себя сетевой контроллер, конфигурирует физические сетевые компоненты физической сети и/или виртуальные сетевые компоненты виртуальных сетей. В некоторых вариантах осуществления, сетевая подсистема конфигурирует физические и/или виртуальные сетевые компоненты посредством развертывания сетевых политик. Сетевые политики могут включать в себя политики для управления возможностями подключения, полосой пропускания, временем задержки и/или потоком трафика. Сетевой контроллер может представлять собой SDN-контроллер, TSN-контроллер или комбинацию вышеозначенного.

[00144] На этапе 1210, CS-подсистема, которая включает в себя контроллер безопасности, распределяет политики безопасности в туманную серверную подсистему и сетевую подсистему для развертывания в виртуальных компонентах, выполняющихся на вычислительных узлах, и в физических и/или виртуальных сетевых компонентах. На этапе 1212, туманная серверная подсистема использует физические и/или виртуальные сетевые компоненты для того, чтобы обмениваться данными с физическими компонентами (например, полевыми устройствами) автоматизированной системы, чтобы контролировать работу и управление автоматизированной системой.

[00145] Фиг.13A является логической блок-схемой последовательности операций, иллюстрирующей примерный способ добавления функционального модуля в автоматизированную систему через системное программное обеспечение в соответствии с некоторыми вариантами осуществления.

[00146] Начинаясь на этапе 1302, пользователь может запускать системное программное обеспечение. На этапе 1304, системное программное обеспечение может представлять топологический вид всех устройств, физических и виртуальных, которые управляются посредством автоматизированной системы. Фиг.13B иллюстрирует пример топологического вида транспортирующей системы, которая включает в себя PAC 1330 наверху иерархии, виртуальный PLC 1332 и ассоциированный модуль 1334 ввода-вывода, привод 1336, электромотор 1338 и транспортер 1340 (т.е. актуатор). На этапе 1306, системное программное обеспечение может принимать выбор шаблона функциональных модулей (например, шаблона транспортирующей системы), чтобы добавлять в автоматизированную систему. Шаблон функциональных модулей может выбираться из библиотеки шаблонов в некоторых вариантах осуществления. Системное программное обеспечение может обновлять топологический вид таким образом, что он включает в себя новый функциональный модуль, на этапе 1308. На этапе 1310, системное программное обеспечение может запускать первое приложение для конфигурирования функционального модуля. В некоторых вариантах осуществления, конфигурирование функционального модуля может включать в себя информацию, такую как, но не только: IP-адресация, конфигурация ввода-вывода, списки управления доступом, локальные субкомпоненты и вспомогательные библиотеки, инициирование по событиям, пароли и т.п.На этапе 1312, системное программное обеспечение может принимать конфигурационные данные для функционального модуля. На этапе 1314, системное программное обеспечение может запускать второе приложение для управления системными данными. На этапе 1316, системное программное обеспечение может конфигурировать новый функциональный модуль с возможностью принимать/отправлять данные (например, через связь "точка-точка" или через совместно используемую шину данных реального времени). В некоторых вариантах осуществления, конфигурирование и управление данными может выполняться через идентичное приложение. В такой ситуации, системное программное обеспечение может запускать приложение для конфигурирования и управления данными функционального модуля на этапе 1318. Системное программное обеспечение может принимать конфигурационные данные и/или инструкции для управления данными на этапе 1320. Системное программное обеспечение затем может конфигурировать функциональный модуль с возможностью принимать и/или отправлять данные на этапе 1322.

[00147] Фиг.14 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ инициализации функционального модуля в SDA-системе в соответствии с некоторыми вариантами осуществления. На этапе 1402, SDA-система может принимать запрос, чтобы создавать или добавлять новый функциональный модуль в автоматизированную систему. В некоторых вариантах осуществления, прием запроса может включать в себя прием выбора шаблона функциональных модулей из библиотеки шаблонов функциональных модулей на этапе 1404. Выбор может осуществляться пользователем через системный программный пользовательский интерфейс в некоторых вариантах осуществления. В других вариантах осуществления, определение нового функционального модуля, который должен добавляться в автоматизированную систему, может приниматься из объекта, который функционально соединяется с системным программным обеспечением (например, через API). Прием запроса также может включать в себя прием информации, чтобы параметризовать шаблон функциональных модулей, на этапе 1406. На этапе 1410, SDA-система может аутентифицировать запрос на основе, по меньшей мере, одной политики безопасности. В некоторых вариантах осуществления, аутентификация может выполняться посредством туманной серверной подсистемы с использованием, по меньшей мере, одной политики безопасности из подсистемы кибербезопасности. На этапе 1412 принятия решения, если аутентификация не является успешной, запрос может быть отклонен посредством SDA-системы на этапе 1416. Этап аутентификации обеспечивает то, что неавторизованные изменения автоматизированной системы не выполняются посредством SDA-системы.

[00148] Если запрос успешно аутентифицирован, SDA-система может создавать, по меньшей мере, одну виртуальную сеть в одном или более вычислительных узлов на этапе 1418, если целевая виртуальная сеть не существует.SDA-система также может создавать виртуальный экземпляр функционального модуля на этапе 1420. Создание виртуального экземпляра функционального модуля включает в себя создание виртуального экземпляра каждого элемента функционального модуля. Например, если функциональный модуль содержит три PAC, виртуализация функционального модуля означает создание трех виртуальных PAC (vPAC). На этапе 1422, SDA-система может развертывать виртуальный экземпляр функционального модуля на вычислительном узле. На этапе 1424, SDA-система может соединять виртуальный экземпляр функционального модуля на вычислительном узле с виртуальными сетями, чтобы инициализировать или вводить в действие функциональный модуль на вычислительном узле.

[00149] Фиг.15 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ конфигурирования функционального модуля в SDA-системе в соответствии с некоторыми вариантами осуществления.

[00150] После того, как функциональный модуль создан или инициализирован (например, через компонент 906 инициализации на фиг.9A), функциональный модуль может быть сконфигурирован с использованием системного программного обеспечения. На этапе 1502, SDA-система (например, SDA-система 600 на фиг.6A) может принимать конфигурационную информацию для нового функционального модуля из системного программного обеспечения. На этапе 1504, SDA-система (через сетевой контроллер, например, сетевой контроллер 690 на фиг.6A) может определять, по меньшей мере, один сетевой тракт, проходящий через виртуальные и физические сети. SDA-система может конфигурировать один или более сетевых компонентов, по меньшей мере, в одном сетевом тракте на этапе 1506. Конфигурирование сетевых компонентов может включать в себя предоставление и/или принудительную активацию одной или более сетевых политик, которые указывают то, как сетевые компоненты должны направлять различные типы потоков трафика. Например, виртуальный/физический коммутатор может быть ассоциирован с сетевой политикой, которая указывает разрешение только HTTP-трафика. Таким образом, коммутатор при работе должен разрешать протекание HTTP-трафика, но другой трафик, к примеру, MODBUS-трафик, должен блокироваться. На этапе 1508, SDA-система может конфигурировать виртуальный экземпляр функционального модуля с использованием конфигурационных данных (например, через конфигурационный компонент 908 на фиг.9A). На этапе 1510, SDA-система затем может разрешать трафику данных вытекать из функционального модуля в устройство (например, полевое устройство), по меньшей мере, через один сетевой тракт, чтобы управлять автоматизированным процессом.

[00151] Фиг.16A является логической блок-схемой последовательности операций, иллюстрирующей примерный способ ввода в действие или инициализации функционального модуля в SDA-системе в соответствии с некоторыми вариантами осуществления.

[00152] Примерный способ включает в себя создание, посредством системного контроллера (например, туманного серверного контроллера 910 на фиг.9A) локализованной подсистемы (например, туманной серверной подсистемы), виртуализированного экземпляра функционального модуля автоматизированной системы в одном или более вычислительных узлов, управляемых посредством системного контроллера на этапе 1602. Эти вычислительные узлы могут включать в себя контроллер автоматизированной системы, сервер, персональный компьютер и/или соединенное интеллектуальное устройство. В некоторых вариантах осуществления, создание виртуализированного экземпляра функционального модуля может включать в себя создание полностью виртуализированного экземпляра функционального модуля или частично виртуализированного экземпляра функционального модуля. Например, если функциональный модуль включает в себя два компонента (например, PLC 1 и PLC 2), то полностью виртуализированный экземпляр этого функционального модуля должен включать в себя виртуализацию обоих компонентов (т.е. двух виртуальных компонентов, например, для vPLC 1 и vPLC 2). Аналогично, частично виртуализированный экземпляр функционального модуля может включать в себя виртуализацию одного компонента (т.е. одного виртуального компонента, например, vPLC 1), при этом другой компонент представляет собой физический компонент (например, PLC 2). В некоторых вариантах осуществления, физический компонент также может вводиться в действие в SDA-системе (т.е. переводиться под управление туманного сервера). Способ ввода в действие функционального модуля, имеющего физический компонент, описывается в отношении фиг.16B.

[00153] Виртуализированный экземпляр функционального модуля может создаваться из шаблона функциональных модулей, выбранного из библиотеки шаблонов функциональных модулей. Системное программное обеспечение предоставляет интерфейс для пользователя, чтобы осуществлять доступ к библиотеке шаблонов функциональных модулей, чтобы выбирать шаблон функциональных модулей и параметризовать шаблон функциональных модулей. Параметризация шаблона функциональных модулей включает в себя задание идентификационных данных экземпляра, возможностей подключения для ввода-вывода и профиля безопасности для функционального модуля в некоторых вариантах осуществления.

[00154] Системный контроллер может создавать виртуальную сеть в одном или более вычислительных узлов на этапе 1604 и затем соединять виртуализированный экземпляр функционального модуля с виртуальной сетью на этапе 1606. Виртуальная сеть соотносится с физической сетью, чтобы обеспечивать возможность виртуализированному экземпляру функционального модуля взаимодействовать с полевым устройством автоматизированной системы, чтобы управлять автоматизированным процессом.

[00155] На этапе 1608, системный контроллер может конфигурировать безопасность виртуализированного экземпляра функционального модуля посредством применения одной или более политик безопасности из подсистемы кибербезопасности. В некоторых вариантах осуществления, это может включать в себя создание виртуализированного экземпляра системы защиты для обеспечения безопасности (например, виртуального брандмауэра следующего поколения) на одном или более вычислительных узлов на основе политики безопасности. В некоторых вариантах осуществления, виртуализированный экземпляр функционального модуля включает в себя один или более хостов, в которых выполняется программная реализация функционального модуля. В связи с этим, конфигурирование безопасности виртуализированного экземпляра функционального модуля может включать в себя конфигурирование безопасности: программной реализации функционального модуля, одного или более хостов и/или одного или более вычислительных узлов, в которых выполняются один или более хостов. В некоторых вариантах осуществления, хост из одного или более хостов включает в себя виртуальную машину, контейнер или платформу без программного обеспечения. В некоторых вариантах осуществления, в ответ на запрос на то, чтобы создавать виртуализированный экземпляр функционального модуля автоматизированной системы, системный контроллер может применять, по меньшей мере, одну политику безопасности, чтобы аутентифицировать запрос до создания виртуализированного экземпляра функционального модуля. Контроллер безопасности также может применять, по меньшей мере, одну политику безопасности, чтобы проверять достоверность образа каждого хоста, ассоциированного с виртуализированным экземпляром функционального модуля.

[00156] На этапе 1610, сетевой контроллер сетевой подсистемы может определять, по меньшей мере, один сетевой тракт из виртуализированного экземпляра функционального модуля в полевое устройство через виртуальные и физические сети. Затем на этапе 1612, сетевой контроллер может конфигурировать один или более сетевых элементов, по меньшей мере, в одном сетевом тракте, чтобы обеспечивать поток трафика данных между виртуализированным экземпляром функционального модуля и полевым устройством. На этапе 1614, сетевой контроллер может конфигурировать безопасность одного или более сетевых элементов, по меньшей мере, в одном сетевом тракте посредством применения одной или более политик безопасности, предоставленных посредством подсистемы кибербезопасности.

[00157] Фиг.16B является логической блок-схемой последовательности операций, иллюстрирующей примерный способ ввода в действие или инициализации функционального модуля в SDA-системе в соответствии с некоторыми вариантами осуществления.

[00158] Примерный способ включает в себя прием, посредством системного контроллера (например, туманного серверного контроллера 910 на фиг.9A, туманного серверного контроллера 610 на фиг.6A), запроса на ввод в действие, чтобы вводить в действие функциональный модуль, на этапе 1616. В ответ на запрос на ввод в действие, сетевой контроллер (например, сетевой контроллер 690 на фиг.6A) в ответ на прием запроса на ввод в действие посредством системного контроллера, по меньшей мере, одного сетевого тракта для функционального модуля, который соединен с физической сетью, на этапе 1618. На этапе 1620, сетевой контроллер конфигурирует один или более сетевых элементов, по меньшей мере, в одном сетевом тракте, чтобы вводить в действие функциональный модуль в автоматизированной системе, которая обеспечивает поток трафика данных между функциональным модулем и полевым устройством в автоматизированной системе.

8. Управление SDA-системой

[00159] Фиг.17 является блок-схемой, иллюстрирующей примерные компоненты компонента 1716 управления хостами в соответствии с некоторыми вариантами осуществления. В некоторых вариантах осуществления, управление хостами и гостями централизованно координируется через этот компонент.Компонент 1716 управления хостами может включать в себя такие компоненты, как компонент 1706 инициализации, конфигурационный компонент 1708, компонент 1712 мониторинга и компонент 1714 выбора вычислительных узлов в некоторых вариантах осуществления. В дополнительных вариантах осуществления, компонент 1716 управления хостами может включать в себя компонент 1726 обнаружения событий и компонент 1720 обработчика событий. В еще одних других вариантах осуществления, компонент 1716 управления хостами может включать в себя компонент 1722 формирования сообщений по использованию и/или компонент 1724 управления рабочими режимами. Следует отметить, что один или более этих компонентов могут разделяться на субкомпоненты и/или консолидироваться в один или более компонентов. Подробности, связанные с функционированием компонентов инициализации и конфигурирования, уже описаны в отношении фиг.9A.

[00160] Компонент 1712 мониторинга может отслеживать работоспособность и производительность вычислительных узлов и/или хостов (например, контейнеров, виртуальных машин, платформ без программного обеспечения), выполняющихся на вычислительных узлах. В некоторых вариантах осуществления, компонент 1712 мониторинга также может отслеживать гостей (например, приложения, выполняющиеся на хостах), физические и виртуальные сетевые элементы (например, маршрутизаторы, коммутаторы), данные журналов регистрации, данные событий из журналов регистрации и локальные события (например, прерывания по простому протоколу управления сетью, или SNMP, OpenFlow-события), ответы по исключениям для таких протоколов, как Ethernet IP и Modbus, состояние механизмов обработки (например, застрявшее состояние в конечном автомате), эффективность использования полосы пропускания (слишком высокая может указывать неконтролируемое устройство), хостинг которых выполняется на вычислительных узлах. Например, компонент 1712 мониторинга может периодически принимать подтверждения работоспособности из агентов мониторинга (не показаны) в вычислительных узлах и/или других инфраструктурных компонентах. В некоторых случаях, компонент 1712 мониторинга также может принимать статистику использования ресурсов, такую как информация использования CPU и запоминающего устройства в реальном времени в расчете на вычислительный узел и/или в расчете на VM, контейнер или узел без программного обеспечения. В некоторых вариантах осуществления, компонент мониторинга может получать данные, связанные с рабочими состояниями хостов и/или гостей, наряду со статистикой использования. Например, для виртуального PLC, может получаться статистика использования, ассоциированная с рабочими состояниями, такими как решающая логика, прекращение (т.е. отсутствие решения), останов (ошибка) и несконфигурированное.

[00161] В некоторых вариантах осуществления, компонент 1722 формирования сообщений по использованию может использовать информацию мониторинга из компонента 1712 мониторинга, чтобы регистрировать использование услуги и ресурсов виртуализации. Например, компонент 1712 мониторинга может обнаруживать, когда виртуальная машина, развернутая на вычислительном узле, начинает и прекращает выполнение приложения, а также статистику использования ресурсов для этой виртуальной машины, и может предоставлять штампы времени начала/прекращения и связанную статистику использования ресурсов в компонент 1722 формирования сообщений по использованию. Компонент 1722 формирования сообщений по использованию может агрегировать данные по использованию на основе одного или более критериев (например, посредством приложения, посредством потребителя) и/или посредством периода формирования сообщений. В некоторых вариантах осуществления, компонент 1722 может применять одно или более бизнес-правил для того, чтобы определять затраты на использование системных SDA-ресурсов. В некоторых вариантах осуществления, данные мониторинга и/или агрегированные данные по использованию могут периодически выгружаться в удаленное облако (например, облако 450 на фиг.4) для дополнительного анализа, определения затрат для использования системных SDA-ресурсов, выделения затрат для различных типов системных SDA-ресурсов и т.п.

[00162] В некоторых вариантах осуществления, компонент 1724 управления рабочими режимами может управлять рабочими состояниями вычислительных узлов, хостов (например, виртуальных машин, контейнеров и платформ без программного обеспечения) и/или гостей, которые выполняются на хостах. Например, если рассматривать виртуальный PLC, работающий на вычислительном узле, компонент 1724 управления рабочими режимами может запрашивать виртуальный PLC запускать, прекращать, останавливать, инициализировать, выключать, сбрасывать, получать и задавать состояние и т.п.

[00163] Компонент 1714 выбора вычислительных узлов может выбирать вычислительный узел для развертывания гостя. Развертывание гостя на вычислительном узле включает в себя развертывание хоста в форме виртуальной машины, контейнера или платформы без программного обеспечения на вычислительном узле и развертывание гостя на хосте. В некоторых вариантах осуществления, развертывание гостя может включать в себя развертывание первого хоста, развертывание второго хоста на первом хосте и развертывание гостя на втором хосте. Этот тип развертывания может выбираться в случаях, когда требования по гостям не могут удовлетворяться посредством аппаратных средств вычислительного узла в собственной форме. Например, приложение, которое выполняется в окружении Windows, не может развертываться в контейнере на вычислительном Linux-узле, поскольку контейнер основывается на ядре вычислительного узла. В этом случае, сначала должна развертываться виртуальная машина, затем контейнер поверх виртуальной машины, а после этого приложение на контейнере.

[00164] Компонент 1714 выбора вычислительных узлов может быть инициирован посредством компонента 1708 конфигурирования в некоторых вариантах осуществления. Туманный сервер включает в себя один или более вычислительных узлов, которые могут быть физически распределены и могут колебаться по характеристикам. Например, некоторые вычислительные узлы могут быть расположены в аппаратной комнате при промышленной эксплуатации и могут включать в себя многопроцессор Xeon и т.п.с несколькими ядрами, чтобы предоставлять высокую вычислительную мощность. Аналогично, некоторые другие вычислительные узлы могут включать в себя младший одно- или многоядерный Atom-процессор и т.п., а еще одним другие, например, могут представлять собой машины на основе высокопроизводительного ARM-процессора и т.п., расположенные в заводском цехе или около окружения, которым они управляют.Следует отметить, что аппаратные средства вычислительных узлов могут быть реализованы в форме PC, промышленного PC, HMI-модуля, серверов, специализированных контроллеров (например, промышленных контроллеров, таких как M580 PLC, изготовленные посредством Schneider Electric), соединенных интеллектуальных устройств и/или т.п.в различных вариантах осуществления. Некоторые вычислительные узлы также могут иметь возможности организации сетей, такие как высокопроизводительное межсетевое соединение (например, Ethernet-коммутатор на 10 Гбайт или на 1 ГБ) между модулями в системном блоке и распределение мощности. С учетом этих варьирований характеристик и того, как вычислительные узлы могут быть физически распределены, существующие подходы для выбора вычислительного узла для развертывания виртуальной машины, такие как случайный выбор, круговая система и простой жадный алгоритм, являются очень недейственными и неэффективными. Кроме того, в окружении автоматизации, приложения могут иметь чувствительные ко времени и критичные с точки зрения безопасности требования. Эти ограничения приложений или гостей делают процесс выбора вычислительного узла для виртуализации приложения или машины более сложным.

[00165] Компонент 1714 выбора вычислительных узлов, в некоторых вариантах осуществления, может использовать одно или более правил, регулирующих требования к ресурсам данного гостя и/или хоста, ассоциированного с гостем, чтобы выбирать вычислительный узел для развертывания. Примеры правил, которые может применять компонент 1714 выбора вычислительных узлов, включают в себя, но не только:

[00166] Если технология виртуализации хостов представляет собой виртуальную машину, то выбор вычислительного узла с высокопроизводительным процессором (например, многоядерным Xeon-процессором).

[00167] Если технология виртуализации хостов представляет собой контейнер, то выбор вычислительного узла со среднепроизводительным процессором (например, многоядерным Atom-процессором).

[00168] Если гость имеет небольшой размер (например, менее 32 MB, между 16 MB и 64 MB), то выбор вычислительного узла без программного обеспечения.

[00169] Если гость имеет строгое с точки зрения объема вычислений требование по обработке, то выбор вычислительного узла с высокопроизводительным процессором (например, многоядерным Xeon-процессором).

[00170] Если гость имеет чувствительное ко времени требование по обработке и связи, то выбор вычислительного узла, который находится около машины/процесса, которым управляет гость.

[00171] Если гость имеет чувствительное ко времени требование по обработке и связи, то выбор вычислительного узла с характеристиками чувствительных ко времени сетей.

[00172] Если гость имеет чувствительное ко времени требование по обработке и связи, то выбор вычислительного узла без соседнего узла с NUMA (неоднородным доступом к памяти).

[00173] Если гость записывается для конкретного типа технологии изготовления кристаллов (например, ARM, X86), операционной системы (ОС) (например, Linux, Windows, VxWorks), версии ОС и т.п., то выбор вычислительного узла, имеющего совместимую технологию изготовления кристаллов, ОС и версию ОС.

[00174] При использовании в данном документе, определение близости может быть основано на одном или более соображений. Например, близость может измеряться с точки зрения пропускной способности и время задержки, когда это касается производительности сети. Близость также может измеряться в физическом расстоянии, когда проблемы включают в себя безопасность и техобслуживание (например, отсутствие реально длинных кабелей), общие источники питания, окружающую среду (например, среду, в которой он работает), кибербезопасность, физическую безопасность, затраты, монтаж (кожухи) и т.п.Близость также может задаваться посредством зон безопасности в некоторых случаях.

[00175] В некоторых вариантах осуществления, правила могут включать в себя правила подобия и/или антиподобия. Одно примерное правило подобия может указывать то, чтобы хост, выполняющий гостя, работал вместе или сосуществовал с другим хостом, выполняющим гостя на идентичном вычислительном узле. Это может предоставлять возможность очень быстрых передач данных между хостами/гостями, например, через внутренний виртуальный коммутатор на 10 ГБ в вычислительном узле. Другое примерное правило подобия может указывать то, что гость всегда работает на конкретном вычислительном узле. Еще одно другое примерное правило подобия указывает то, что гость не работает на вычислительном узле, идентичном вычислительному узлу другого гостя. Это правило может быть применимым, например, в случаях, если один гость представляет собой резерв для другого.

[00176] В некоторых вариантах осуществления, правила могут формироваться на основе эвристики и/или статистических данных. Кроме того, эти правила могут обновляться и/или проходить проверку достоверности с использованием шаблонов статистических данных. Следует отметить, что одно или более этих правил могут комбинироваться (например, с использованием такой логики, как AND, OR и т.п.), использоваться изолированно или использоваться каскадным способом при осуществлении выбора вычислительного узла. Посредством использования этих правил, компонент 1714 выбора вычислительных узлов обеспечивает то, что вычислительный узел, который выбирается, удовлетворяет не только требованиям к ресурсам времени выполнения (например, обработка и связь, хранение, запоминающее устройство и т.п.) гостя и хоста и, но также и достигает оптимизаций производительности (например, уменьшенной сетевой задержки, более быстрого доступа к запоминающему устройству).

[00177] В некоторых вариантах осуществления, выбор вычислительного узла, чтобы развертывать гостя, может быть основан на упорядоченном наборе рабочих параметров. В качестве примера, рабочие параметры могут включать в себя критический с точки зрения технологического процесса уровень, чувствительный ко времени уровень, затраты на исполнение, критический с точки зрения близости уровень, эффективность затрат и т.п.

[00178] В некоторых вариантах осуществления, критический с точки зрения технологического процесса уровень может зависеть от уровня резервирования, потребности в доступности приложения, требования по безопасности, вариантов перехода на аварийный режим и т.п.Например, если промышленное предприятие по переработке стали с работающей с печью в сталепрокатном стане не может охлаждаться ни при каких обстоятельствах, то приложение(я), связанное с поддержанием работы печи, может считаться критическим с точки зрения технологического процесса. В некоторых вариантах осуществления, рабочий параметр чувствительного ко времени уровня может зависеть от точности времени выполнения, определяемой количественно длительности и т.п.Примеры чувствительных ко времени вариантов применения включают в себя варианты применения для управления высокоскоростным движением (например, машину для поточной резки сыра). В некоторых вариантах осуществления, рабочий параметр затрат на исполнение может зависеть от количества времени обработки, потребления ресурсов, требования с точки зрения производительности обработки и т.п.В некоторых вариантах осуществления, рабочий параметр критического с точки зрения близости уровня может быть связан с взаимозависимостью между или для двух или более гостей либо с близостью между гостем и датчиком/актуатором, которым он управляет.В некоторых вариантах осуществления, рабочий параметр эффективности затрат может быть основан на капитальных расходах, таких как затраты ресурсов, и эксплуатационных расходах, таких как надежность всего процесса.

[00179] В некоторых вариантах осуществления, компонент 1714 выбора вычислительных узлов может оценивать релевантность, по меньшей мере, некоторых рабочих параметров для гостя, чтобы формировать упорядоченный или ранжированный список рабочих параметров. На основе упорядоченного списка рабочих параметров, компонент 1714 выбора вычислительных узлов может выбирать вычислительный узел для развертывания гостя.

[00180] Компонент 1726 обнаружения событий, в некоторых вариантах осуществления, может обнаруживать события 1718, которые могут возникать в виртуальном и/или физическом окружении SDA-системы. Фиг.18A иллюстрирует некоторые примерные классы событий 1818 в виртуальном и/или физическом окружении, которые могут обнаруживаться посредством компонента 1726 обнаружения событий. Ссылаясь на фиг.18A, некоторые примеры классов событий 1818 включают в себя, но не только: события 1818A кибербезопасности, события 1818B отказа вычислительных узлов, диагностические события 1818C, события 1818D техобслуживания, событие 1818E модернизации, события 1818F по расширению возможностей завода, события 1818G сбоя питания, события 1818H формирования сообщений, события 1818I технологического процесса, сетевые события 1818J и т.п.Каждое из этих событий может обнаруживаться посредством компонента 1726 обнаружения событий на основе информации мониторинга из компонента 1712 мониторинга в некоторых вариантах осуществления. Следует отметить, что компонент 1726 обнаружения событий, в некоторых вариантах осуществления, может содержать один или более субкомпонентов обнаружения событий, чтобы обнаруживать различные классы событий. В некоторых вариантах осуществления, каждое из этих событий может обрабатываться или управляться посредством обработчика 1720 событий. Следует отметить, что один или более обработчиков 1720 событий могут существовать с возможностью обрабатывать различные классы событий. Также следует отметить, что в некоторых вариантах осуществления, компонент(ы) обнаружения событий и обработчик(и) событий могут быть распределены между туманным серверным контроллером, сетевым контроллером и контроллером кибербезопасности, в зависимости от чего контроллер управляет ответом по обработке событий. Ссылаясь на фиг.18B, некоторые примерные обработчики 1820 событий включают в себя, но не только: обработчик 1820A событий кибербезопасности, обработчик 1820B событий отказа вычислительных узлов, обработчик 182°C диагностических событий, обработчик 1820D событий техобслуживания, обработчик 1820E событий модернизации, обработчик 1820F событий по расширению возможностей завода, обработчик 1820G событий сбоя питания, обработчик 1820H событий формирования сообщений, обработчик 1820I событий технологического процесса, обработчик 1820J сетевых событий и т.п.

[00181] Например, события 1818A кибербезопасности могут возникать, когда существует попытка получать неавторизованный доступ к автоматизированной системе (например, к вычислительным узлам), нарушать процессы, отключать безопасные системы мониторинга и, в общем, наносить вред. Атаки системы кибербезопасности могут иметь несколько точек входа, в том числе через сетевые элементы, такие как маршрутизаторы и брандмауэры. Некоторые примеры этих событий кибербезопасности, чаще преднамеренных, чем случайных, включают в себя внешние взломы, вирус/программы-червей/вредоносное программное обеспечение и атаки по принципу отказа в обслуживании (DoS), помимо прочего. В некоторых вариантах осуществления, компоненты, которые затрагиваются посредством событий кибербезопасности, могут формировать запись в журнале, документирующую такие действия. В некоторых вариантах осуществления, системы защиты для обеспечения безопасности могут отслеживать сетевой трафик в базе данных известных уязвимостей, чтобы обнаруживать подозрительный трафик и формировать аварийный сигнал. Компонент обнаружения события кибербезопасности CS-контроллера (например, CS-контроллер 655 на фиг.6B) может анализировать эти действия совместно, чтобы обнаруживать событие 1818A кибербезопасности.

[00182] В ответ на обнаружение события 1818A кибербезопасности, обработчик 1820A событий кибербезопасности CS-контроллера может инициировать или предоставлять ответ.Ответ может варьироваться в зависимости от различных аспектов события 1818A кибербезопасности, включающих в себя, например, тип и серьезность события кибербезопасности и затрагиваемые компоненты или системы управления. Для сетевых событий кибербезопасности, ответ может включать в себя сегментацию сети, чтобы изолировать затрагиваемую часть сети, чтобы уменьшать влияние события. Для атак на основе устройств, ответ может включать в себя завершение работы портов и линий связи и даже перевод затрагиваемого устройства оффлайн. Аналогично, ответ на неавторизованную попытку изменять управляющую программу на устройстве может включать в себя помещение в черный список пользователя, чтобы не допускать доступ пользователем к любым другим устройствам, блокирование трафика в/из потенциально скомпрометированного устройства, а также коммутацию на виртуальный резерв (т.е. резервное устройство в виртуальном окружении), так что процессы могут работать без прерывания.

[00183] Эти ответы типично координируются между компонентами оркестровки, как проиллюстрировано на фиг.19. Ссылаясь на фиг.19, в некоторых вариантах осуществления, компонент 1942 обнаружения CS-событий CS-контроллера 1955 может формировать аварийный сигнал, ассоциированный с событием кибербезопасности, и предоставлять описание 1928A событий кибербезопасности, включающее в себя подробную информацию события, в компонент 1916 SDA-оркестровки. Описание 1928A событий кибербезопасности может включать в себя такие подробности, как, но не только: тип происшествия или атаки (например, вирусная атака), точка входа (например, маршрутизатор, брандмауэр), затрагиваемые компоненты (например, вычислительный узел с IP-адресом/MAC-адресом) и т.п.В некоторых вариантах осуществления, компонент 1155 CS-оркестровки может определять ответные меры (или ответ 1928B на события кибербезопасности), требуемые для того, чтобы ослаблять событие кибербезопасности и предоставлять релевантные ответные меры 1930 сети (например, связанные с сетевыми элементами) в компонент 1922 оркестровки сети, и ответные меры 1932B релевантного устройства (например, физического или виртуального) в компонент 1910 оркестровки туманного сервера, чтобы реализовывать в их соответствующих областях управления (т.е. в вычислительных узлах и виртуализированных экземплярах 1904 для туманного контроллера 1910 и в виртуальных сетях 1920 и сетевых элементах 1906 для сетевого контроллера 1990). Например, компонент оркестровки туманного сервера, в качестве ответа по кибербезопасности, может инструктировать туманному серверному контроллеру переводить затрагиваемое устройство оффлайн и перезапускать приложение, выполняющееся на устройстве, на другом вычислительном узле. Аналогично, компонент оркестровки сети может инструктировать сетевому контроллеру отключать затрагиваемые порты маршрутизатора и/или коммутатора, так что трафик может обходить затрагиваемые порты маршрутизатора и/или коммутатора при протекании через сеть. В альтернативных вариантах осуществления, ответ 1928B на события кибербезопасности, включающий в себя ответ устройства и/или сети, может предоставляться в компонент 1916 SDA-оркестровки. Компонент 1916 SDA-оркестровки затем может синтаксически анализировать ответ 1928B по кибербезопасности и предоставлять ответ 1932B устройства по кибербезопасности в компонент 1924 туманной оркестровки и/или ответ 1930 сети по кибербезопасности в компонент 1922 оркестровки сети. В некоторых вариантах осуществления, компонент 1916 SDA-оркестровки также может предоставлять описание 1932A событий кибербезопасности в компонент 1924 туманной оркестровки, который в свою очередь может инструктировать туманному серверному контроллеру (например, через компонент 1726 обнаружения событий или другой модуль аварийной сигнализации) отправлять аварийный сигнал 1916 по событию кибербезопасности в клиентское устройство 1940, чтобы уведомлять пользователя относительно события кибербезопасности и ответа.

[00184] Другой класс событий представляет собой событие отказа вычислительного узла (например, событие 1818B отказа вычислительного узла, проиллюстрированное на фиг.18A). Этот тип события может быть инициирован, когда вычислительный узел сбоит вследствие ряда причин, таких как сбой питания, катастрофический отказ ОС хоста, повреждение содержимого запоминающего устройства, сбой диска, сбой сети управления/передачи данных и т.п.Компонент 1726 обнаружения событий может обнаруживать событие отказа вычислительного узла, например, на основе предупреждения из компонента 1712 мониторинга. Компонент мониторинга может формировать предупреждение, когда он сбоит при приеме подтверждений работоспособности с ожидаемыми интервалами из вычислительного узла. Подтверждения работоспособности не могут указывать потерю связи вследствие сбоя сети или сбоя самого вычислительного узла. В некоторых вариантах осуществления, дополнительная информация, такая как состояние ошибки из сообщения журнала регистрации или сообщения об ошибке, может использоваться для того, чтобы обнаруживать событие отказа вычислительного узла.

[00185] Обработчик событий отказа вычислительных узлов (например, компонент 1820B на фиг.18B) может предоставлять ответ на событие 1818B отказа вычислительного узла, чтобы уменьшать влияние сбойного вычислительного узла на SDA-систему. Ответ может представлять собой координированный ответ, по меньшей мере, для двух из SDA-подсистем. Один пример координированного ответа из SDA-системы на событие отказа вычислительного узла проиллюстрирован на фиг.20. Ссылаясь на фиг.20, проиллюстрирован вычислительный узел (например, выполняющий PLC-приложение), который представляет собой один из нескольких вычислительных узлов, отслеживаемых посредством туманного серверного контроллера 2010 (например, через компонент 1712 мониторинга на фиг.17). Туманный серверный контроллер 2010 принимает данные 2014 мониторинга. Как описано выше, данные 2014 мониторинга могут включать в себя сообщения подтверждения работоспособности, статистику использования ресурсов, к примеру, использование CPU и запоминающего устройства в реальном времени в расчете на вычислительный узел и/или в расчете на VM или контейнер, который может предоставлять информацию относительно работоспособности вычислительного узла. Туманный серверный контроллер 2010 (например, через компонент мониторинга) может анализировать данные 2014 мониторинга и формировать аварийный сигнал, когда он определяет то, что вычислительный узел или хост на вычислительном узле сбоит.Компонент обнаружения событий туманного серверного контроллера 2010 (например, компонент 1726 обнаружения событий на фиг.17) может обнаруживать аварийный сигнал, указывающий отказ вычислительного узла. В некоторых вариантах осуществления, аварийный сигнал 2016 может передаваться в клиентское устройство 2040, чтобы уведомлять пользователя (например, заводского оператора). Пользователь затем может инструктировать SDA-системе, непосредственно из клиентского устройства 2040 или другого интерфейса (например, системного программного обеспечения), обрабатывать событие. Туманный серверный контроллер (например, через обработчик 1720 событий на фиг.17) может принимать инструкции 2018, чтобы обрабатывать событие и, в ответ, извлекать информацию 2022 относительно приложения (т.е. гостя), которое работает на хосте на вычислительном узле, который сбоит, из узла 2025 хранения. Примеры информации, извлеченной из узла хранения, могут включать в себя, но не только: данные логики и состояния приложения. Такие данные могут обеспечивать возможность приложению запускаться из последнего синхронизированного состояния, вместо полного перезапуска. В некоторых вариантах осуществления, туманный серверный контроллер 2010 может создавать хост 2004, чтобы выполнять гостя 2005, который работает на сбойном вычислительном узле 2002A. Туманный серверный контроллер 2010 также может создавать необходимую виртуальную сеть(и) 2020 и соединять хост 2004, сконфигурированный с гостем 2005, с виртуальной сетью(ями) 2020. Туманный серверный контроллер 2010 затем может выбирать вычислительный узел 2002B (например, через компонент 1714 выбора вычислительных узлов), на котором развертывается хост 2004.

[00186] После того, как гость 2004 развертывается на вычислительном узле, который удовлетворяет требованиям по оптимизации ресурсов и/или производительности гостя 2005, выполняющегося на хосте 2004, туманный серверный контроллер 2010 может предоставлять описание 2024 виртуализации, включающее в себя информацию относительно хоста 2004 и ассоциированных виртуальных сетей, в компонент 2016 SDA-оркестровки в некоторых вариантах осуществления. Описание 2024 виртуализации может включать в себя информацию, такую как, но не только: потоки связи и сетевые потоки, ассоциированные с хостом 2004 и ассоциированными сетями. Компонент 2016 SDA-оркестровки может синтаксически анализировать описание виртуализации, чтобы извлекать потоки 2026 связи и сетевые потоки 2030A и перенаправлять их в компонент 2018 CS-оркестровки и компонент 2022 оркестровки сети, соответственно. Компонент 2018 CS-оркестровки затем может инструктировать CS-контроллеру 2055 извлекать политики 2028 безопасности для запрашиваемого потока 2026 связи и перенаправлять эти политики безопасности в компонент 2016 оркестровки системы. Аналогично, компонент 2022 оркестровки сети может инструктировать сетевому контроллеру 2090 использовать описание 2030A сетевых потоков и политики 2030B безопасности, чтобы конфигурировать физические и/или виртуальные сетевые элементы 2006. Кроме того, политики 2032 безопасности также могут перенаправляться на туманный серверный контроллер 2010 для распределения в хост 2004.

[00187] Одно из преимуществ наличия CS-подсистемы, включающей в себя CS-контроллер, заключается в том, что ассоциирования между устройством и его кибербезопасностью поддерживаются до тех пор, пока эти ассоциирования не будут разорваны преднамеренно. Другими словами, кибербезопасность сопровождает устройство в любом месте, в котором оно развертывается. Идентично тому, как сеть переконфигурируется в качестве части ответа на событие, переконфигурируется и кибербезопасность. В примере по фиг.20, вычислительный узел 2002A может представлять собой PLC, выполняющий PLC-приложение, и политика безопасности, ассоциированная с PLC, требует брандмауэра перед ним. Когда PLC-приложение развертывается на хосте 2004 на вычислительном узле 2002B, туманный серверный контроллер автоматически создает виртуальный брандмауэр перед хостом 2004, выполняющим PLC-приложение, поскольку политика безопасности, ассоциированная с логической функцией (т.е. PLC-приложением), сохраняется, даже когда логическая функция перемещается между хостами или между вычислительными узлами.

[00188] После того, как гость и хост развертываются на новом вычислительном узле 2002B, устанавливается с приложением, и конфигурирование сети и системы безопасности проведено, исходящий трафик приложений из хоста 2004 может протекать через виртуальные сети 2020, через виртуальные и/или физические сетевые элементы 2006, в распределенный ввод-вывод 2008 и затем в оборудование 2012 (например, актуатор) в этом примере. Аналогично, входящий трафик из оборудования 2012, которым управляет хост 2004, разрешается через сетевые элементы 2006 в хост 2004.

[00189] В то время, когда хост 2004 на вычислительном узле 2002B работает, вычислительный узел 2002A, который сбоит, может восстанавливаться или заменяться. Например, если вычислительный узел 2002A представляет собой физическое PLC-устройство, то в то время, когда его приложение и процессы выполняются на хосте 2004 на вычислительном узле 2002B, PLC-устройство может восстанавливаться или заменяться. В некоторых вариантах осуществления, PLC-устройство 2002A должно включаться только для того, чтобы переключать свое приложение и процессы из вычислительного узла 2002B обратно в PLC-устройство 2002A. Другими словами, PLC-устройство 2002A должно снова отвечать за управление оборудованием 2012. Чтобы завершать передачу управления, SDA-подсистемы координируются между собой, чтобы переконфигурировать или исправлять сеть (например, через сетевой контроллер 2090) и/или окружения системы безопасности (например, через CS-контроллер 2055), чтобы перенаправлять потоки обратно в вычислительный узел 2002A. Это переключение управления означает то, что хост 2004 может завершать работу посредством туманного контроллера 2010, за счет этого освобождая ресурсы.

[00190] В некоторых вариантах осуществления, хост может представлять собой резерв для активного устройства, т.е. в соотношении 1 к 1 или для нескольких устройств, в соотношении N к 1 в системе с теплым/горячим резервом. Когда устройство сбоит, группа технического обслуживания должна диагностировать, идентифицировать и перезапускать устройство максимально быстро. На традиционном заводе, диагностические и ремонтные работы могут быть затруднительными и длительными и могут вызывать простой. При использовании виртуального резерва, виртуальные ресурсы доступны немедленно для того, чтобы принимать под свое управление все прикладные процессы, уменьшая или исключая время простоя и обеспечивая возможность системе работать с минимальными проблемами или задержкой. В примере по фиг.20, хост 2004 на вычислительном узле 2002B может представлять собой виртуальный резерв для сбойного вычислительного узла 2002A (например, PLC-устройства).

[00191] В некоторых вариантах осуществления, чтобы уменьшать затраты на аппаратные средства и на электроэнергию в силу наличия резервных систем в соотношении N к 1, эластичная инфраструктура виртуализированных резервных систем может быть сконфигурирована. Если устройство сбоит или переходит в состояние ошибки, хост из пула может принимать под свое управление процессы неисправного устройства, принимая на себя все задачи и функции. В некоторых вариантах осуществления, резерв для одного или более устройств может выбираться из активного пула хостов различных типов (виртуальных машин, контейнеров и платформ без программного обеспечения) и особенностей (например, характеристик, ОС, версий ОС, емкости запоминающего устройства и т.д.) на основе одного или более критериев. Пул хостов может представлять собой общие несконфигурированные хосты в некоторых вариантах осуществления, так что только данные логики и состояния приложения должны передаваться во время активации резерва.

[00192] В некоторых вариантах осуществления, данные состояния в реальном времени приложения или процесса могут поддерживаться в узле 2025 хранения. При занятии виртуального резерва, данные состояния для прикладного процесса, который ранее выполнен на устройстве, могут извлекаться из этого узла хранения и передаваться в виртуальный резерв, так что состояние виртуального резерва соответствует состоянию устройства, которое он временно заменяет, обеспечивая возможность вторичному или резервному устройству быстро принимать на себя роль первичного или неисправного устройства.

[00193] Следует отметить, что передача управления между вычислительными узлами или из физического устройства хосту, как описано выше, возникает прозрачным способом. Рассмотрим пример технологической линии для резки сыра для изготовления кусков швейцарского сыра, имеющих указанный вес.В такой системе, поворотное лезвие, перемещающееся на высокой скорости, разрезает брикет швейцарского сыра по мере того, как он подталкивается к лезвию на скорости, которая регулируется на основе дыр в сыре. Координирование быстрого перемещения лезвия с перемещением брикета сыра является чувствительным ко времени. Таким образом, любая задержка в передаче управления процессом резки сыра между вычислительными узлами может оказывать отрицательное влияние на процесс (например, изготавливать куски сыра с неравномерными весами). С учетом этих проблем, в соответствии с некоторыми вариантами осуществления, передача управления между вычислительными узлами может возникать через мягкий переход, который учитывает зависимость от времени прикладных процессов. Например, мягкий переход для системы управления высокоскоростным движением, к примеру, системы для резки сыра, может возникать не более чем за 1 мс, что может приводить к прозрачному переходу от физического к виртуальному устройству.

[00194] В некоторых вариантах осуществления, мягкий переход активируется посредством клонирования хоста. SDA-система может обеспечивать возможность двух или более точных копий хоста на сети. Эти копии или клоны могут иметь идентичный IP-адрес, MAC-адрес, порядковый номер, конфигурацию и т.п., выполняя идентичные приложения. В некоторых вариантах осуществления, клоны также могут синхронизировать состояния между собой, чтобы обеспечивать то, что они являются точно подобными во всех отношениях в любой момент времени. В некоторых вариантах осуществления, SDN-контроллер может направлять/блокировать потоки на основе любого числа критериев. Такие критерии основаны на производителе трафика данных. Например, сетевой контроллер (например, SDN/, TSN/) разрешает всем клонам принимать вводы из сети, но разрешает вывод только из одного выбранного клона для распространения через сеть. В некоторых вариантах осуществления, вывод всех клонов может быть дублирован в узел(ы) проверки достоверности для сравнения и проверки достоверности. Точный клон компонента, виртуальный или физический, существующий на идентичной сети, предоставляет резервирование, при этом сетевой контроллер (например, SDN-контроллер и/или TSN-контроллер) направляет входящий трафик во все клоны, но разрешает исходящий трафик только из одного. Передача управления в таком случае представляет собой проблему переключения того, какому компоненту разрешать распространять вывод, чтобы упрощать мгновенное переключение из одного узла на другой (резервный) узел.

[00195] В некоторых вариантах осуществления, технология клонирования может расширяться на несколько клонов со схемой голосования, реализованной посредством компонента (например, в туманном контроллере 910 на фиг.9A). Компонент может сравнивать несколько выводов и принимать значение, полученное через консенсус.Технология клонирования также обеспечивает прошедшую проверку достоверности модернизацию устройства, при которой вывод модернизированного устройства проходит проверку достоверности в течение испытательного периода до того, как разрешается участвовать в автоматизированной системе. Технология клонирования также предоставляет возможность усреднения нескольких вычислительных процессов, чтобы учитывать стохастическую ошибку в вычислении. В некоторых вариантах осуществления, клоны также могут устанавливаться в качестве безопасности по принципу "приманка", когда незащищенные устройства приносятся в жертву кибервзломщикам.

[00196] Ссылаясь на фиг.17 и 18, диагностическое событие 1818C, в некоторых вариантах осуществления, может быть ассоциировано с любыми компонентами SDA-системы, включающими в себя, например, вычислительные узлы, сетевые компоненты (например, коммутаторы) и т.п.Диагностическое событие типично инициировано, когда удовлетворяется предварительно заданное условие. Например, когда оборудование достигает своего временного предела для непрерывной работы, когда оборудование не достигает определенной позиции вовремя, или когда сетевая задержка превышает определенное время. В некоторых вариантах осуществления, диагностическое событие может быть инициировано посредством внешнего сигнала. Например, аналитический механизм, работающий в облаке (например, в облаке 450 на фиг.4), который может собирать данные, включающие в себя данные мониторинга, из места эксплуатации и преобразовывать в практическую информацию, такую как диагностическая информация в реальном времени. Такой механизм может формировать сигнал, когда диагностические данные указывают потенциальную проблему. Компонент обнаружения диагностических событий (например, компонент 1726 обнаружения событий на фиг.17) может обнаруживать диагностическое событие, и в ответ, обработчик диагностических событий (например, компонент 182°C на фиг.18B) может или диспетчеризовать или выполнять диагностическую проверку компонента, который инициирует диагностическое событие. В некоторых вариантах осуществления, обработчик диагностических событий может координироваться с компонентами оркестровки, чтобы упрощать диагностическую проверку компонента. Например, если сетевой коммутатор имеет диагностическое событие, то обработчик диагностических событий может запрашивать сетевой контроллер (например, через компонент 1922 оркестровки сети на фиг.19 и/или компонент оркестровки системы 1916 на фиг.19), чтобы перенаправлять сетевые потоки в направлении от этого сетевого коммутатора в то время, когда диагностические проверки выполняются на нем. В некоторых вариантах осуществления, диагностическое событие может инициировать другое событие, к примеру, событие техобслуживания или событие модернизации.

[00197] Другой тип события, которое может обнаруживать компонент 1726 обнаружения событий, представляет собой событие 1818D техобслуживания. Событие техобслуживания может диспетчеризоваться заранее, инициироваться по запросу пользователем, чтобы проверять и/или восстанавливать один или более вычислительных узлов, или в ответ на другие события, к примеру, диагностические события. В диспетчеризованное время или в ответ на пользовательский запрос, событие техобслуживания может быть инициировано и обнаружено посредством компонента обнаружения событий. В ответ на событие, может активироваться обработчик 1820 событий техобслуживания. Обработчик событий техобслуживания может использовать компонент оркестровки туманного сервера для того, чтобы переключать прикладные процессы из вычислительного узла, диспетчеризованного на то, чтобы подвергаться техобслуживанию, на другой вычислительный узел (например, виртуальные машины, контейнеры или платформы без программного обеспечения). Обработчик событий техобслуживания также может, через компонент оркестровки сети и компонент CS-оркестровки, исправлять или переконфигурировать сеть и окружения системы безопасности, чтобы обеспечивать возможность виртуализированным прикладным функциям управлять машиной или процессом. В некоторых вариантах осуществления, один примерный ответ на событие техобслуживания может быть аналогичным ответу на событие отказа вычислительного узла, описанное в отношении фиг.20.

[00198] Другой тип события в физическом и/или виртуальном окружении представляет собой событие модернизации. Аналогично событиям техобслуживания, события модернизации также могут диспетчеризоваться заранее или инициироваться по запросу пользователем, чтобы модернизировать аппаратные средства, микропрограммное обеспечение и/или программное обеспечение. Для событий модернизации аппаратные средства, микропрограммное обеспечение и/или программное обеспечение может быть полностью рабочим, но модернизация может требоваться в ответ на киберугрозы, обнаружение потенциальных дефектов, доступность новых признаков и т.п.

[00199] Событие 1818F по расширению возможностей завода может быть инициировано, когда возможности части завода должны расширяться. Это событие может диспетчеризоваться заранее или в некоторых случаях инициироваться по запросу. В ответ на обнаружение этого события через компонент 1716 детектора событий, обработчик 1820F событий по расширению возможностей завода может инструктировать части завода, возможности которой должны быть расширены, перемещаться в окружение виртуализации туманного сервера, в котором ассоциированные системы управления могут выполняться на виртуальных машинах и/или контейнерах. Обработчик 1820F событий по расширению возможностей завода также может передавать в служебных сигналах компонентам оркестровки необходимость взаимодействовать, чтобы переконфигурировать или исправлять сетевое окружение и окружение системы безопасности и переводить часть завода оффлайн.

[00200] Событие 1818G сбоя питания может быть инициировано, когда прекращается подача мощности в автоматизированную систему. В ответ на такое событие, резервная система питания, к примеру, источник бесперебойного питания (UPS) типично используется для того, чтобы предоставлять чистую и непрерываемую подачу мощности, чтобы поддерживать систему полностью рабочей в течение некоторого времени. Продолжительность, в течение которой система может поддерживаться работающей, должна зависеть от размера аккумулятора в UPS. В некоторых вариантах осуществления, компонент 1712 мониторинга может отслеживать систему и обнаруживать событие сбоя питания. В некоторых вариантах осуществления, обработчик 1820F событий сбоя питания может определять или вычислять продолжительность, в течение который система может оставаться рабочей на основе требований по мощности системы и характеристик UPS-системы. Обработчик 1820F событий сбоя питания затем может, на основе оставшегося времени работы, инициировать завершение работы процессов и вычислительных узлов, начиная с некритических, так что критические могут работать дольше и могут продолжать работать до тех пор, пока питание не будет восстановлено.

[00201] Событие 1818H формирования сообщений может быть инициировано пользователем или автоматически на основе предварительно заданных условий, к примеру, каждый раз, когда возникает событие безопасности, или каждый раз, когда обрабатывается событие безопасности. Обработчик 1820H событий формирования сообщений может обрабатывать событие формирования сообщений посредством сбора релевантных данных и формирования сообщения на основе данных. Такой отчет может включать в себя такую информацию, как идентификатор события, тип события, компонент(ы), который инициирует событие, действие, предпринимаемое для того, чтобы добиться события, и т.п.Другой пример сообщения, которое может формироваться в ответ на событие формирования сообщений, может представлять собой сообщение, которое включает в себя список событий определенного типа. Например, сообщение, которое перечисляет все события кибербезопасности, которые возникают за месяц в системе.

[00202] Событие 1818I технологического процесса представляет собой тип с инициированием по событиям посредством процессов, выполняющихся на вычислительных узлах. Событие технологического процесса может формироваться, когда переменная технологического процесса или измерение работает вне пределов, либо когда срабатывает аварийный сигнал, указывающий то, что процесс является анормальным. В некоторых вариантах осуществления, обработчик 1820H событий технологического процесса может обрабатывать событие технологического процесса, например, посредством перемещения компонента гостя между вычислительными узлами или между хостами в идентичном вычислительном узле или в другом, изменения типа процесса (например, с обработки в реальном времени на пакетную обработку), выполнения управления энергопотреблением (например, посредством консолидации обработки в несколько вычислительных узлов, чтобы экономить энергию) и т.п.Ответ из обработчика 1820I технологического процесса в силу этого может включать в себя переконфигурирование хостов и/или гостей, которые могут инициировать переконфигурирование окружения кибербезопасности и сетевого окружения.

[00203] Другой класс событий, которые возникают в виртуальном и/или физическом окружении, представляет собой сетевое событие 1818J. Примеры сетевых событий могут включать в себя, но не только: потери возможностей подключения (например, сбой точки соединения, сбой инфраструктурного оборудования) в виртуальном и физическом окружении, обнаружение перегрузки, переконфигурирование трактов и т.п.Эти типы сетевых событий могут обнаруживаться посредством компонента обнаружения событий (например, компонента 1726 по фиг.17) и обрабатываться посредством обработчика сетевых событий (например, обработчика 1820J сетевых событий). Обработчик сетевых событий, после обнаружения сетевого события, указывающего сбой сети любого типа, может немедленно повторно маршрутизировать трафик через другой сетевой тракт в качестве ответа на событие.

9. Примерные технологии для управления SDA-системой

[00204] Фиг.21A является логической блок-схемой последовательности операций, иллюстрирующей примерный способ выбора вычислительного ресурса для развертывания виртуализированного экземпляра/компонента в соответствии с некоторыми вариантами осуществления. На этапе 2102, компонент выбора вычислительных узлов (например, компонент 1714 выбора вычислительных узлов системы 1716 управления хостами на фиг.17) может идентифицировать вычислительные ресурсы, которые доступны для того, чтобы потенциально принимать развертывание виртуализированного компонента. В некоторых вариантах осуществления, вычислительный ресурс может представлять собой серверную машину, персональный компьютер, встроенные аппаратные средства, модуль человеко-машинного интерфейса (HMI) или промышленный контроллер. В некоторых реализациях, вычислительные ресурсы, которые доступны, могут включать в себя, по меньшей мере, одну машину в аппаратной комнате и, по меньшей мере, одну машину в цехе завода. Вычислительные ресурсы, которые доступны, не должны быть физически централизованными, а могут физически распределяться, но отслеживаться посредством туманного серверного контроллера.

[00205] На этапе 2104, компонент выбора вычислительных узлов может выбирать, по меньшей мере, частично на основе любых чувствительных ко времени требований по обработке и связи виртуализированного компонента во время выполнения, возможные варианты вычислительных ресурсов из доступных вычислительных ресурсов. В некоторых вариантах осуществления, возможные варианты вычислительных ресурсов, которые выбираются на основе чувствительных ко времени требований по обработке и связи виртуализированного компонента, могут находиться в физической близости к процессу или машине (например, в цехе завода), которым управляет виртуализированный компонент.

[00206] На этапе 2106, компонент выбора вычислительных узлов может выбирать вычислительный ресурс из возможных вариантов вычислительных ресурсов на основе набора правил, который регулирует требования к ресурсам виртуализированного компонента. В некоторых вариантах осуществления, выбор может рассматривать компонент (т.е. логический компонент или образ компонента) и технологию виртуализации, ассоциированную с компонентом. В некоторых вариантах осуществления, набор правил, который задает требования к ресурсам виртуализированного компонента, включает в себя, по меньшей мере, одно правило подобия, которое регулирует совместное использование двух или более виртуализированных устройств или приложений на идентичном вычислительном ресурсе. Другие примеры правил могут включать в себя правило, которое регулирует тип вычислительных ресурсов, подходящих для технологии виртуализации, ассоциированной с компонентом, и правило, которое регулирует возможность организации сетей, требуемую для устройств или приложений с чувствительными ко времени потребностями по обработки и связи.

[00207] На этапе 2108, туманный серверный контроллер может развертывать виртуализированный компонент на выбранном вычислительном ресурсе. В некоторых вариантах осуществления, развертывание виртуализированного компонента на выбранном вычислительном ресурсе может выполняться в ответ на событие, к примеру, событие отказа или событие техобслуживания, или запрос, чтобы инициализировать виртуализированный компонент на вычислительном ресурсе. Событие отказа может быть инициировано посредством сбоя вычислительного ресурса, на котором развернут виртуализированный компонент.

[00208] Фиг.21B является логической блок-схемой последовательности операций, иллюстрирующей примерный способ выбора вычислительного ресурса для развертывания гостя (например, приложения, образа) в соответствии с некоторыми вариантами осуществления. Примерный способ может осуществляться посредством компонента выбора вычислительных узлов (например, компонента 1714 выбора вычислительных узлов системы 1716 управления хостами на фиг.17). Способ включает в себя идентификацию, посредством компонента выбора вычислительных узлов, вычислительных ресурсов в автоматизированной системе, которые доступны для того, чтобы потенциально принимать развертывание гостя, на этапе 2110. В некоторых вариантах осуществления, вычислительные ресурсы, которые доступны, могут физически распределяться, но отслеживаться посредством системного контроллера автоматизированной системы. Неограничивающие примеры вычислительных ресурсов включают в себя серверную машину, персональный компьютер, соединенное интеллектуальное устройство, модуль человеко-машинного интерфейса (HMI), промышленный контроллер и т.п.

[00209] На этапе 2112, компонент выбора вычислительных узлов может оценивать ограничения гостя на предмет набора рабочих параметров, чтобы выбирать тип хоста для гостя. В некоторых вариантах осуществления, рабочие параметры могут включать в себя одно или более из следующего: критический с точки зрения технологического процесса уровень, чувствительный ко времени уровень, затраты на исполнение, критический с точки зрения близости уровень, эффективность затрат и т.п.На основе оценки, компонент выбора вычислительных узлов может выбирать тип хоста для гостя на этапе 2114. В некоторых вариантах осуществления, тип затрат может представлять собой виртуальную машину, контейнер или платформу без программного обеспечения. На этапе 2116, компонент выбора вычислительных узлов может выбирать, на основе типа выбранного хоста, оценки и атрибутов вычислительных ресурсов, которые доступны, вычислительный ресурс для гостя. Некоторые неограничивающие примеры атрибутов вычислительных ресурсов включают в себя вычислительную мощность, емкость запоминающего устройства, технологию изготовления кристаллов процессора, операционную систему, уровень использования CPU, число соседних NUMA-узлов и т.п.

[00210] На этапе 2118, компонент выбора вычислительных узлов может развертывать хост выбранного типа, который сконфигурирован с гостем, на выбранном вычислительном ресурсе. В некоторых вариантах осуществления, развертывание хоста, сконфигурированного с гостем, на выбранном вычислительном ресурсе может выполняться в ответ на событие отказа, событие техобслуживания, событие технологического процесса или запрос, чтобы инициализировать гостя на вычислительном ресурсе. Событие отказа может быть инициировано, например, посредством сбоя вычислительного ресурса, на котором ранее развернут гость. Событие технологического процесса может быть инициировано, например, посредством переменной технологического процесса, работающей вне пределов.

[00211] Фиг.22 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ управления SDA-системой в соответствии с первым вариантом осуществления. Примерный способ включает в себя отслеживание посредством компонента мониторинга (например, компонента 1712 мониторинга на фиг.17) нескольких вычислительных узлов автоматизированной системы на этапе 2202. В некоторых вариантах осуществления, по меньшей мере, некоторые из нескольких вычислительных узлов выполняют хостинг компонентов виртуализации (например, виртуальные машины, контейнеры, платформы без программного обеспечения), на которых выполняются прикладные функции.

[00212] На этапе 2204, компонент обнаружения событий (например, даже компонент обнаружения на фиг 17) событие, ассоциированное с первым вычислительным узлом из нескольких отслеживаемых вычислительных узлов, может обнаруживаться (например, через компонент 1726 обнаружения событий на фиг.17). В некоторых вариантах осуществления, первый вычислительный узел может представлять собой промышленное автоматизированное устройство, выполняющее одну или более прикладных функций, и второй вычислительный узел может представлять собой машину, выполняющую хостинг, по меньшей мере, одного компонента виртуализации, в котором выполняются одна или более прикладных функций. В различных вариантах осуществления, событие, ассоциированное с первым отслеживаемым вычислительным узлом, может включать в себя событие отказа вычислительного узла, событие техобслуживания или событие модернизации.

[00213] На этапе 2206, компонент обработки событий (например, компонент обработки событий 1720 на фиг.17) может отвечать на событие. Ответ на событие может выполняться в ответ на подтверждение пользователя или автоматически, без вмешательства пользователя. Например, компонент обработки событий может выбирать второй вычислительный узел из нескольких вычислительных узлов, чтобы принимать под свое управление выполнение одной или более прикладных функций из первого вычислительного узла. В некоторых вариантах осуществления, прием под свое управление выполнения одной или более прикладных функций осуществляется через мягкий переход. Мягкий переход может упрощаться посредством второго вычислительного узла, который представляет собой клон первого вычислительного узла.

[00214] Компонент обработки событий может конфигурировать второй вычислительный узел с возможностью выполнять одну или более прикладных функций на этапе 2208 и конфигурировать сетевое окружение автоматизированной системы с возможностью завершать передачу управления из первого вычислительного узла второму вычислительному узлу на этапе 2210. В некоторых вариантах осуществления, конфигурирование второго вычислительного узла с возможностью выполнять одну или более прикладных функций включает в себя извлечение данных логики и состояния, связанных с одной или более прикладных функций, из узла хранения и использование данных логики и состояния, чтобы конфигурировать второй вычислительный узел с возможностью выполнять одну или более прикладных функций.

[00215] В некоторых вариантах осуществления, конфигурирование сетевого окружения автоматизированной системы с возможностью завершать передачу управления из первого вычислительного узла второму вычислительному узлу включает в себя конфигурирование, по меньшей мере, одного физического или виртуального сетевого коммутатора с возможностью разрешать входящий и исходящий трафик, ассоциированный с управлением процессом или машиной, из второго вычислительного узла. В некоторых других вариантах осуществления, конфигурирование сетевого окружения автоматизированной системы с возможностью завершать передачу управления из первого вычислительного узла второму вычислительному узлу дополнительно включает в себя конфигурирование, по меньшей мере, одного физического или виртуального сетевого коммутатора с возможностью блокировать исходящий трафик, ассоциированный с управлением процессом или машиной, из первого вычислительного узла. До обнаружения события, ассоциированного со вторым вычислительным узлом, сетевое окружение может быть выполнено с возможностью распространять вводы из первого и второго вычислительных узлов и вывод только из первого вычислительного узла.

[00216] Фиг.23 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ обнаружения и обработки события отказа в соответствии с некоторыми вариантами осуществления.

[00217] Примерный способ включает в себя обнаружение, посредством компонента детектора события (например, компонента 1718 обнаружения событий на фиг.17), аварийного сигнала, ассоциированного с событием отказа, на этапе 2302. Событие отказа может быть инициировано посредством сбоя вычислительного узла, вызываемого посредством сбоя питания, катастрофического отказа ОС хоста, повреждения содержимого запоминающего устройства, сбоя диска, сбоя сети управления/передачи данных и т.п.На этапе 2304, компонент детектора события может идентифицировать вычислительный узел, который представляет собой источник аварийного сигнала, в качестве сбойного узла.

На этапе 2306, компонент детектора события может отправлять уведомление относительно аварийного сигнала, идентифицирующего сбойный узел, и/или другую информацию, связанную с событием и/или сбойным узлом (например, ассоциированные прикладные функции, выполняющиеся на сбойном узле), в клиентское устройство, такое как планшетный компьютер или HMI-модуль. Пользователь, к примеру, заводской оператор может просматривать уведомление и санкционировать обработку события посредством автоматизированной системы. На этапе 2308, обработчик событий (например, обработчик 1720 событий на фиг.17, обработчик 1820B событий отказа вычислительных узлов на фиг.18B) может принимать индикатор из клиентского устройства, чтобы обрабатывать событие отказа. В альтернативных вариантах осуществления, событие отказа может обрабатываться автоматически без подтверждения или вмешательства пользователя.

[00218] В некоторых вариантах осуществления, в ответ на прием индикатора, чтобы обрабатывать событие отказа (или при обнаружении события, если подтверждение пользователя не требуется), компонент инициализации (например, компонент 1706 инициализации на фиг.17) может создавать виртуализированный экземпляр, чтобы выполнять прикладные функции сбойного узла и ассоциированных виртуальных сетей в вычислительном узле, на этапе 2310. На этапе 2312, компонент инициализации может соединять виртуализированный экземпляр с виртуальными сетями. Кроме того, на этапе 2314, сетевой контроллер может конфигурировать сетевую инфраструктуру с возможностью направлять потоки трафика в виртуализированный экземпляр в вычислительном узле вместо сбойного узла. На этапе 2316, компонент программирования может загружать процессы сбойного узла на виртуализированном экземпляре.

[00219] В некоторых вариантах осуществления, эластичная инфраструктура виртуализированных резервных систем может быть доступной. Таким образом, когда событие отказа должно обрабатываться, туманный серверный контроллер может выбирать виртуальную машину из пула виртуальных машин на этапе 2318, которая может принимать под свое управление процессы сбойного узла, принимая на себя все задачи и функции. В некоторых вариантах осуществления, пул виртуальных машин может иметь виртуальные машины с различными особенностями (например, характеристиками, версиями ОС, емкостью запоминающего устройства и т.д.) на основе одного или более критериев. Кроме того, пул VM может представлять собой общие несконфигурированные VM в некоторых вариантах осуществления. На этапе 2320, туманный серверный контроллер может извлекать данные логики и состояния приложения для процессов сбойного узла из базы данных состояний в реальном времени и загружать данные логики и состояния приложения на выбранной виртуальной машине, так что виртуальная машина может принимать под свое управление процессы сбойного узла, на этапе 2322.

[00220] Фиг.24 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ управления автоматизированной системой в соответствии со вторым вариантом осуществления. Примерный способ включает в себя отслеживание окружений выполнения, сетевых окружений и окружений системы безопасности автоматизированной системы (например, SDA-системы) на этапе 2402, обнаружение события в первом окружении из числа окружений выполнения, сетевых окружений и окружений системы безопасности на этапе 2404, и в ответ на обнаруженное событие, исправление, по меньшей мере, одного компонента в первом окружении, причем исправление первого окружения создает триггер для того, чтобы вызывать исправление, по меньшей мере, одного компонента в каждом из второго и третьего окружений из числа окружений выполнения, сетевых окружений и окружений системы безопасности, на этапе 2406. Например, когда первое окружение представляет собой окружение системы безопасности, то событие, обнаруженное в окружении системы безопасности, представляет собой событие безопасности. Переконфигурирование, по меньшей мере, одного компонента в окружении системы безопасности может включать в себя сегментирование сети, чтобы изолировать компонент, ассоциированный с событием безопасности, от остальной части компонентов автоматизированной системы. В некоторых вариантах осуществления, исправление окружения системы безопасности может представлять собой ответ, который не требует вмешательства пользователя, поскольку события безопасности, в общем, представляют собой критические события, которые требуют немедленного действия, чтобы сдерживать негативные воздействия, такие как несанкционированное изменение или потерю данных либо потерю управления частями завода.

10. Систематизация компьютера

[00221] Фиг.25 является блок-схемой примерной машины/компьютера/устройства, которое может выполнять различные операции и сохранять различную информацию, сформированную и/или используемую посредством таких операций в соответствии с некоторыми вариантами осуществления. Компьютер 2500 предназначен для того, чтобы иллюстрировать аппаратное устройство, на котором могут реализовываться любые из объекты, компоненты или услуги, проиллюстрированные в примерах фиг.1-7B, 8A-11, 13B, 17-20 (и любые другие компоненты, описанные в этом подробном описании), и технологии, описанные в примерах фиг.12-13A, 14-16B и 21A-24, к примеру, сервер, клиентские устройства, вычислительные узлы, контроллерные узлы (например, туманный серверный контроллер (компоненты 610, 810-x, 910, 1010, 1110, 1910, 2010), контроллер кибербезопасности (например, компоненты 655, 1155, 1955, 2055), сетевой контроллер (например, компоненты 690, 590A, 590B, 1190, 1990, 2090)), устройства/узлы хранения, базы данных, PLC, PAC и т.п.Компьютер 2500 включает в себя один или более процессоров 2505 и запоминающее устройство 2510, соединенные с межкомпонентным соединением. Межкомпонентное соединение может представлять любую одну или более отдельных физических шин, соединений "точка-точка" или и то, и другое, соединенных посредством соответствующих мостов, адаптеров или контроллеров.

[00222] Процессор(ы) 2505 представляет собой центральный процессор(ы) (CPU) компьютера и за счет этого управляет всей работой компьютера. В конкретных вариантах осуществления, процессор(ы) осуществляет это посредством выполнения программного обеспечения или микропрограммного обеспечения, сохраненного в запоминающем устройстве. Процессор(ы) может представлять собой или может включать в себя один или более программируемых микропроцессоров общего назначения или специального назначения, процессоров цифровых сигналов (DSP), программируемых контроллеров, специализированных интегральных схем (ASIC), программируемых логических устройств (PLD), доверенных платформенных модулей (TPM) и т.п.либо комбинацию таких устройств.

[00223] Запоминающее устройство 2510 представляет собой или включает в себя основное запоминающее устройство компьютера. Запоминающее устройство представляет любую форму оперативного запоминающего устройства (RAM), постоянного запоминающего устройства (ROM), троичного ассоциативного запоминающего устройства (TCAM), флэш-памяти и т.п.либо комбинации таких устройств. При использовании, запоминающее устройство может содержать код. В одном варианте осуществления, код включает в себя общий программный модуль, выполненный с возможностью распознавать программу общего назначения, принимаемую через компьютерный шинный интерфейс, и подготавливать программу общего назначения для выполнения в процессоре. В другом варианте осуществления, общий программный модуль может реализовываться с использованием аппаратных схем, таких как ASIC, PLD или программируемые пользователем вентильные матрицы (FPGA).

[00224] Также с процессором(ами) через межкомпонентное соединение соединяются сетевой адаптер 2525, устройство(а) 2515 хранения данных и устройство(а) 2520 ввода-вывода. Сетевой адаптер предоставляет компьютеру способность обмениваться данными с удаленными устройствами, по сети и, например, может представлять собой Ethernet-адаптер или Fibre Channel-адаптер, или беспроводной радиомодуль. Сетевой адаптер также может предоставлять компьютеру способность обмениваться данными с другими компьютерами в кластере. В некоторых вариантах осуществления, компьютер может использовать более одного сетевого адаптера для того, чтобы справляться со связью в пределах и за пределами кластера отдельно.

[00225] Устройство(а) ввода-вывода может включать в себя, например, клавиатуру, мышь или другое указательное устройство, накопители на дисках, принтеры, сканер и другие устройства ввода и/или вывода, включающие в себя устройство отображения. Устройство отображения может включать в себя, например, электронно-лучевую трубку (CRT), жидкокристаллический дисплей (ЖК-дисплей) или некоторое другое применимое известное или удобное устройство отображения.

[00226] Код, сохраненный в запоминающем устройстве, может реализовываться как программное обеспечение и/или микропрограммное обеспечение, чтобы программировать процессор(ы), чтобы выполнять действия, описанные выше. В конкретных вариантах осуществления, такое программное обеспечение или микропрограммное обеспечение может первоначально предоставляться в компьютер посредством его загрузки из удаленной системы на компьютер (например, через сетевой адаптер). В некоторых вариантах осуществления, запоминающее устройство 2510 и устройство(а) 2515 хранения данных могут представлять собой один объект.

[00227] Компоненты, представленные в данном документе, могут реализовываться, например, посредством программируемой схемы (например, одного или более микропроцессоров), программируемой с помощью программного обеспечения и/или микропрограммного обеспечения, либо полностью в аппаратной (непрограммируемой) схеме специального назначения, либо в комбинации таких форм. Аппаратная схема специального назначения может иметь форму, например, одной или более ASIC, PLD, FPGA и т.д.

[00228] Программное обеспечение или микропрограммное обеспечение для использования в SDA-системе, представленной здесь, может сохраняться на машиночитаемом носителе хранения данных и может выполняться посредством одного или более программируемых микропроцессоров общего назначения или специального назначения. "Машиночитаемый носитель хранения данных", при использовании этого термина используется в данном документе, включает в себя любой механизм, который может сохранять информацию в форме, доступной посредством машины.

[00229] Компьютер также может представлять собой серверный компьютер, клиентский компьютер, персональный компьютер (PC), планшетный PC, переносной компьютер, абонентскую приставку (STB), персональное цифровое устройство (PDA), сотовый телефон, смартфон, планшетный компьютер, фаблет, процессор, телефон, устройство для доступа на основе веб-технологий, сетевой маршрутизатор, коммутатор или мост, контроллер (например, PLC, PAC) или любую машину, допускающую выполнение набора инструкций (последовательных или иных), которые указывают действия, которые должны предприниматься посредством этой машины.

[00230] Машиночитаемый носитель хранения данных или устройство(а) хранения данных включают в себя, например, записываемые/незаписываемые носители (например, ROM; RAM; носители хранения данных на магнитных дисках; оптические носители хранения данных; устройства флэш-памяти; и т.д.) и т.д. либо любую комбинацию вышеозначенного. Носитель хранения данных типично может быть энергонезависимым или включать в себя энергонезависимое устройство. В этом контексте, энергонезависимый носитель хранения данных может включать в себя устройство, которое является материальным, что означает то, что устройство имеет конкретную физическую форму, хотя устройство может изменять свое физическое состояние. Таким образом, например, энергонезависимый означает устройство, остающееся материальным, несмотря на это изменение состояния.

[00231] Термин "логика", при использовании в данном документе, может включать в себя, например, программируемую схему, программируемую с конкретным программным обеспечением и/или микропрограммным обеспечением, аппаратную схему специального назначения или комбинацию вышеозначенного.

11. Заключение

[00232] Если контекст в явной форме не требует иного, во всем описании и в формуле изобретения слова "содержит", "содержащий" и т.п.должны быть истолкованы во включающем, в отличие от исключающего или исчерпывающего смысла; т.е. в смысле "включает в себя, но не только". При использовании в данном документе, термины "соединенный", "связанный" или всех их разновидности, означают любое соединение или связывание, прямое либо косвенное, между двумя или более элементов; связывание соединения между элементами может быть физическим, логическим либо комбинацией вышеозначенного. Дополнительно, слова "в данном документе", "выше", "ниже" и слова аналогичного смысла, при использовании в этой заявке, должны относиться к этой заявке в целом, а не к каким-либо конкретным частям этой заявки. Если позволяет контекст, слова в вышеприведенном "Подробном описании" с использованием единственного или множественного числа также могут включать в себя множественное или единственное число, соответственно. Слово "или" в отношении списка из двух или более элементов охватывает все из следующих интерпретаций слова: любой из элементов в списке, все элементы в списке и любая комбинация элементов в списке.

[00233] Вышеприведенное подробное описание вариантов осуществления раскрытия не имеет намерение быть полным или ограничивать идеи точной формой, раскрытой выше. Хотя конкретные варианты осуществления и примеры для раскрытия описываются выше в качестве иллюстрации, различные эквивалентные модификации являются возможными в пределах объема раскрытия, как должны признавать специалисты в данной области техники. Например, хотя процессы или блоки представляются в данном порядке, альтернативные варианты осуществления могут выполнять процедуры, имеющие этапы, или использовать системы, имеющие блоки в другом порядке, и некоторые процессы или блоки могут удаляться, перемещаться, добавляться, подразделяться, комбинироваться и/или модифицироваться, чтобы предоставлять альтернативу или субкомбинации. Каждый из этих процессов или блоков может реализовываться множеством различных способов. Кроме того, хотя процессы или блоки время от времени показываются как выполняемые последовательно, эти процессы или блоки вместо этого могут выполняться параллельно либо могут выполняться в различные моменты времени. Дополнительно, любые конкретные числа, указанные в данном документе, являются только примерами: альтернативные реализации могут использовать отличающиеся значения или диапазоны.

[00234] Идеи раскрытия, предоставленные в данном документе, могут применяться к другим системам, не обязательно к системе, описанной выше. Элементы и этапы различных вариантов осуществления, описанных выше, могут комбинироваться с тем, чтобы предоставлять дополнительные варианты осуществления.

[00235] Все патенты и заявки и другие ссылочные документы, указанные выше, в том числе любые из них, которые могут быть перечислены в прилагаемых подаваемых документах, содержатся в данном документе по ссылке. Аспекты раскрытия могут модифицироваться, при необходимости, чтобы использовать системы, функции и принципы различных ссылочных документов, описанных выше, с тем чтобы предоставлять еще одни дополнительные варианты осуществления раскрытия.

[00236] Эти и другие изменения могут быть внесены в раскрытие в свете вышеуказанного "Подробного описания". Хотя вышеприведенное описание описывает конкретные варианты осуществления раскрытия и описывает предполагаемый наилучший режим, неважно, насколько подробно они излагаются в тексте, идеи могут осуществляться на практике множеством способов. Подробности системы могут значительно варьироваться по подробностям реализации при одновременном охватывании посредством предмета изобретения, раскрытого в данном документе. Как отмечено выше, конкретная терминология, используемая при описании определенных признаков или аспектов раскрытия, не должна рассматриваться как подразумевающая то, что терминология переопределяется в данном документе таким образом, что она ограничивается какими-либо конкретными характеристиками, признаками или аспектами раскрытия, с которыми ассоциирована эта терминология. В общем, термины, используемые в нижеприведенной формуле изобретения, не должны истолковываться как ограничивающие раскрытие конкретными вариантами осуществления, раскрытыми в подробном описании, если только вышеприведенный раздел "Подробное описание" не задает в явном виде такие термины. Соответственно, фактический объем раскрытия охватывает не только раскрытые варианты осуществления, но также и все эквивалентные способы осуществления на практике или реализации раскрытия согласно формуле изобретения.

[00237] Из вышеизложенного, следует принимать во внимание, что конкретные варианты осуществления раскрытой системы/технологии описаны в данном документе в целях иллюстрации, но могут вноситься различные модификации без отступления от сущности и объема вариантов осуществления. Следовательно, варианты осуществления не ограничены ничем, кроме как прилагаемой формулой изобретения.

1. Программно-определяемая автоматизированная (SDA) система, реализующая виртуализированную автоматизированную систему управления на по меньшей мере одном хосте, функционирующем на по меньшей мере одном вычислительном узле, содержащая:

системный контроллер, выполняющийся на хосте, функционирующем на вычислительном узле, при этом системный контроллер управляет одним или более вычислительными узлами через первую сеть связи;

при этом системный контроллер, в качестве реакции на прием описания виртуализации, задающего, по меньшей мере, тип и количество автоматизированных устройств, которые составляют автоматизированную систему управления или ее часть, и связанное с ними требование по резервированию, создает виртуализированную автоматизированную систему управления, соответствующую принятому описанию виртуализации, наряду с соответствующей виртуальной сетью на по меньшей мере одном вычислительном узле из упомянутых одного или более вычислительных узлов;

при этом виртуализированная автоматизированная система управления включает в себя по меньшей мере один виртуальный автоматизированный контроллер, выполняющий функцию автоматизированной системы управления, причем виртуализированная автоматизированная система управления выполняется на по меньшей мере одном хосте, функционирующем на упомянутом по меньшей мере одном вычислительном узле, при этом данный по меньшей мере один виртуальный автоматизированный контроллер виртуализированной автоматизированной системы управления удаленно управляет работой по меньшей мере одного физического компонента автоматизированной системы управления в реальном времени через вторую сеть связи вместо физической автоматизированной системы управления или ее части, управляющей работой этого по меньшей мере одного физического компонента автоматизированной системы управления в реальном времени.

2. SDA-система по п. 1, в которой упомянутые один или более вычислительных узлов включают в себя краевое устройство, которое выбирается отчасти на основе его близости к упомянутому по меньшей мере одному физическому компоненту автоматизированной системы управления и серверной машине.

3. SDA-система по п. 1, в которой упомянутый по меньшей мере один хост включает в себя виртуальную машину, контейнер или платформу без программного обеспечения.

4. SDA-система по п. 1, дополнительно содержащая контроллер кибербезопасности, при этом контроллер кибербезопасности, в качестве реакции на создание виртуализированной автоматизированной системы управления, предоставляет по меньшей мере одну политику безопасности в системный контроллер для конфигурирования безопасности виртуализированной автоматизированной системы управления и по меньшей мере одного хоста, выполняющего виртуализированную автоматизированную систему управления на упомянутом по меньшей мере одном вычислительном узле.

5. SDA-система по п. 4, в которой упомянутая по меньшей мере одна политика безопасности требует брандмауэра для виртуализированной автоматизированной системы управления, при этом системный контроллер создает, в соответствии с данной по меньшей мере одной политикой безопасности, экземпляр виртуального брандмауэра для виртуализированной автоматизированной системы управления на упомянутом по меньшей мере одном вычислительном узле.

6. SDA-система по п. 4, дополнительно содержащая сетевой контроллер, при этом сетевой контроллер, в качестве реакции на создание виртуализированной автоматизированной системы управления сетевым контроллером, конфигурирует по меньшей мере один физический или виртуальный сетевой компонент управлять потоком сетевого трафика, ассоциированным с управлением упомянутым по меньшей мере одним физическим компонентом автоматизированной системы управления.

7. SDA-система по п. 6, в которой сетевой контроллер управляет упомянутым по меньшей мере одним физическим или виртуальным сетевым компонентом посредством развертывания одной или более сетевых политик.

8. Система по п. 7, в которой упомянутые одна или более сетевых политик включают в себя политики для управления по меньшей мере одним из следующего: возможности подключения, полоса пропускания, время задержки и поток трафика.

9. SDA-система по п. 6, в которой контроллер кибербезопасности предоставляет по меньшей мере одну политику безопасности в сетевой контроллер, чтобы конфигурировать безопасность упомянутого по меньшей мере одного физического или виртуального сетевого компонента.

10. SDA-система по п. 9, в которой упомянутая по меньшей мере одна политика безопасности задает типы команд, которым разрешено распространяться через вторую сеть связи в упомянутый по меньшей мере один физический компонент автоматизированной системы управления через упомянутый по меньшей мере один физический или виртуальный сетевой элемент.

11. SDA-система по п. 1, дополнительно содержащая сетевой контроллер, при этом сетевой контроллерный узел, в качестве реакции на изменение в автоматизированной системе управления, конфигурирует по меньшей мере один физический или виртуальный сетевой компонент управлять потоком сетевого трафика, ассоциированным с управлением упомянутым по меньшей мере одним физическим компонентом автоматизированной системы управления.

12. SDA-система по п. 11, в которой сетевой контроллер включает в себя компонент чувствительной ко времени сети для обработки чувствительного ко времени детерминированного сетевого трафика.

13. SDA-система по п. 1, в которой виртуализированная автоматизированная система управления включает в себя компонент программной реализации встроенной системы или компонент во встроенной системе.

14. SDA-система по п. 1, в которой управление одним или более вычислительными узлами включает в себя создание экземпляра, конфигурирование, запуск, остановку и уничтожение хостов на одном или более вычислительных узлов.

15. SDA-система по п. 1, дополнительно содержащая системное программное обеспечение, исполняющееся на хосте в вычислительном узле из упомянутых одного или более вычислительных узлов, причем системное программное обеспечение передает, через интерфейс прикладного программирования, упомянутое описание виртуализации.

16. SDA-система по п. 1, дополнительно содержащая системное программное обеспечение, через которое по меньшей мере два из информации топологии, инвентаризации, конфигурирования или диагностики, соответствующей автоматизированной системе управления, являются доступными для объекта, причем системное программное обеспечение исполняется на хосте в вычислительном узле из упомянутых одного или более вычислительных узлов.

17. SDA-система по п. 1, в которой системный контроллер и упомянутые один или более вычислительных узлов локализованы в одном высокодоступном сервере.

18. SDA-система по п. 1, в которой автоматизированная система управления является системой управления, относящейся к системе автоматизации зданий.

19. SDA-система по п. 1, в которой автоматизированная система управления является системой управления, относящейся к промышленной автоматизированной системе.

20. Способ задания автоматизированной системы через программное обеспечение, содержащий этапы, на которых:

в качестве реакции на прием описания виртуализации, задающего, по меньшей мере, тип и количество автоматизированных устройств, которые составляют автоматизированную систему управления или ее часть, и связанное с ними требование по резервированию, создают посредством системного контроллера виртуализированную автоматизированную систему управления, соответствующую принятому описанию виртуализации, наряду с соответствующей виртуальной сетью на по меньшей мере одном вычислительном узле из одного или более вычислительных узлов, при этом системный контроллер коммуникационно подключен к этим одному или более вычислительным узлам через первую сеть связи, причем виртуализированная автоматизированная система управления включает в себя по меньшей мере один виртуальный автоматизированный контроллер, выполняющий функцию автоматизированной системы управления, причем виртуализированная автоматизированная система управления выполняется на по меньшей мере одном хосте, функционирующем на упомянутом по меньшей мере одном вычислительном узле; и

удаленно управляют, посредством упомянутого по меньшей мере одного виртуального автоматизированного контроллера виртуализированной автоматизированной системы управления в реальном времени, работой по меньшей мере одного физического компонента автоматизированной системы управления через вторую сеть связи вместо физической автоматизированной системы управления или ее части, управляющей работой этого по меньшей мере одного физического компонента автоматизированной системы управления в реальном времени.

21. Программно-определяемая автоматизированная (SDA) система, содержащая множество контроллеров, работающих в координации друг с другом, причем данное множество контроллеров содержит:

системный контроллер, коммуникационно подключенный к одному или более вычислительным узлам через первую сеть связи, при этом системный контроллер, в качестве реакции на прием описания виртуализации, задающего, по меньшей мере, тип и количество автоматизированных устройств, которые составляют автоматизированную систему управления или ее часть, и связанное с ними требование по резервированию, создает виртуализированную автоматизированную систему управления, соответствующую принятому описанию виртуализации, наряду с соответствующей виртуальной сетью на одном или более хостах, функционирующих на по меньшей мере одном вычислительном узле из упомянутых одного или более вычислительных узлов, при этом виртуализированная автоматизированная система управления включает в себя по меньшей мере один виртуальный автоматизированный контроллер, выполняющий функцию автоматизированной системы управления, причем виртуализированная система управления выполняется на одном или более хостах, функционирующих на упомянутом по меньшей мере одном вычислительном узле, при этом данный по меньшей мере один виртуальный автоматизированный контроллер виртуализированной автоматизированной системы управления удаленно управляет работой по меньшей мере одного физического компонента автоматизированной системы управления в реальном времени через вторую сеть связи вместо физической автоматизированной системы управления или ее части, управляющей работой этого по меньшей мере одного физического компонента автоматизированной системы управления в реальном времени;

контроллер кибербезопасности, коммуникационно подключенный к системному контроллеру, при этом контроллер кибербезопасности, в качестве реакции на создание виртуализированной автоматизированной системы управления, предоставляет по меньшей мере одну политику безопасности в системный контроллер для конфигурирования безопасности виртуализированной автоматизированной системы управления и одного или более хостов, выполняющих виртуализированную автоматизированную систему управления на упомянутом по меньшей мере одном вычислительном узле; и

сетевой контроллер, при этом сетевой контроллер, в качестве реакции на создание виртуализированной автоматизированной системы управления, конфигурирует по меньшей мере один физический или виртуальный сетевой компонент управлять потоком сетевого трафика, ассоциированным с управлением упомянутым по меньшей мере одним физическим компонентом автоматизированной системы управления.

22. SDA-система по п. 21, при этом автоматизированная система управления является системой управления, относящейся к системе автоматизации зданий.

23. Способ задания автоматизированной системы через программное обеспечение, содержащий этапы, на которых:

в качестве реакции на прием описания виртуализации, задающего, по меньшей мере, тип и количество автоматизированных устройств, которые составляют автоматизированную систему управления или ее часть, и связанное с ними требование по резервированию, создают виртуализированную автоматизированную систему управления, соответствующую принятому описанию виртуализации, наряду с соответствующей виртуальной сетью на по меньшей мере одном вычислительном узле из одного или более вычислительных узлов, при этом виртуализированная автоматизированная система управления включает в себя по меньшей мере один виртуальный автоматизированный контроллер, выполняющий функцию автоматизированной системы управления, причем виртуализированная система управления выполняется на по меньшей мере одном хосте, функционирующем на упомянутом по меньшей мере одном вычислительном узле;

управляют, посредством упомянутого по меньшей мере одного виртуального автоматизированного контроллера виртуализированной автоматизированной системы управления, работой по меньшей мере одного физического компонента автоматизированной системы управления в реальном времени через сеть связи вместо физической автоматизированной системы управления или ее части, управляющей работой этого по меньшей мере одного физического компонента автоматизированной системы управления в реальном времени;

конфигурируют безопасность виртуализированной автоматизированной системы управления и по меньшей мере одного хоста, выполняющего виртуализированную автоматизированную систему управления на упомянутом по меньшей мере одном вычислительном узле, посредством применения по меньшей мере одной политики безопасности; и

в качестве реакции на создание виртуализированной автоматизированной системы управления, конфигурируют по меньшей мере один физический или виртуальный сетевой компонент управлять потоком сетевого трафика, ассоциированным с управлением упомянутым по меньшей мере одним физическим компонентом автоматизированной системы управления, посредством развертывания одной или более сетевых политик, связанных с управлением по меньшей мере одним из следующего: возможности подключения, полоса пропускания, время задержки и поток трафика.