Способ для размещения рабочих нагрузок в программно-определяемой автоматизированной системе

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

 

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

[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] Фиг. 17A является блок-схемой, иллюстрирующей пример автоматизированной системы, в которой функция автоматизации может быть сконфигурирована в соответствии с первым вариантом осуществления.

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

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

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

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

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

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

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

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

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

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

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

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

[0042] Это раскрытие также описывает способы для размещения рабочих нагрузок в SDA-системе.

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

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

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

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

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

[0048] Фиг. 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)).

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

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

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

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

[0053] Хотя традиционная архитектура автоматизации, проиллюстрированная на фиг. 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-технология может упрощать развертывание и конфигурирование функций и/или приложений автоматизации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0071] Магистраль 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

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

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

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

[0074] Примерный функциональный вид 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 безопасности на системном уровне.

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

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

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

3. SDA-система

[0078] 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 сетевых политик.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00107] Фиг. 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-сетью.

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

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

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

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

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

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

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

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

[00115] Фиг. 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, что добавляет дополнительный слой и ассоциированное время задержки. Некоторые конкретные для производителя ускорения могут использоваться для того, чтобы смягчать это последствие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00127] Системный 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 и имеет полный вид автоматизированной системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Компоновки рабочих нагрузок в SDA-системе

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

[00159] В некоторых вариантах осуществления, SDA-система может реализовывать один или более способов для размещения рабочих нагрузок, чтобы оптимизировать производительность систем управления (например, систем управления производственным процессом).

[00160] В качестве примера автоматизированной системы, в которой сконфигурирована функция автоматизации, фиг. 17A показывает инженерную станцию 1701 для конфигурирования рабочих станций, т.е. транспортной станции, управляемой через PLC 1702, сборочной станции, управляемой через PLC 1703, и упаковочной станции, управляемой через PLC 1704. Рядом со станциями предусмотрены локальные экраны для операторов соответствующих человеко-машинных интерфейсов 1705-1707 (HMI), которые соединены через Ethernet-шину 1708 с HMI 1709 верхнего уровня. Инженерная система 1701 обеспечивает возможность проектировать функцию автоматизации в качестве распределенного и управляемого событиями приложения, которое развертывается в SCADA и системе 1710 оперативного управления производством. Локальная инженерная станция 1711 обеспечивает возможность распределения сеансов для PLC рабочих станций. При адаптации IEC 61499, стандарта для размещения связи между функциональными объектами, можно воспользоваться преимуществом этого стандарта для разбиения функции автоматизации на функциональные блоки и увязывать и распределять их по PLC рабочих станций 1702-1704. Как видно из элементов T1-3, A1-5 и P1-4, которые загружаются из инженерной станции 1701 на соответствующие рабочие станции1702-1704.

[00161] Другой пример автоматизированной системы, в которой сконфигурирована функция автоматизации, показан на фиг. 17B. Он снова показывает инженерную станцию 1701 для конфигурирования рабочих станций. Автоматизированная система имеет транспортную станцию, управляемую через PLC 1702, сборочную станцию, управляемую через PLC 1703, и виртуальный элемент 1712. Виртуальный элемент 1712 может реализовываться как вычислительный узел, интеллектуальное устройство, сервер или другой модуль обработки. В этом примере, инженерная станция 1701 распределяет несколько экземпляров элемента T1, элементов A1-5 и элементов P1-4 способом, отличающимся от способа на фиг. 17A. Виртуальный элемент 1712 может представлять собой автономное устройство, предоставляющее опорные функции для рабочих станций, управляемых посредством PLC 1702 и 1703. Альтернативно, виртуальный элемент 1712 может управлять рабочей станцией непосредственно.

[00162] Фиг. 17C показывает еще один другой пример автоматизированной системы, в которой все PLC-устройства по фиг. 17A заменены посредством виртуальных элементов 1712, 1713 и 1714, аналогично виртуальному элементу 1712 по фиг. 17B. Виртуальные элементы 1712, 1713, 1714 могут реализовываться как вычислительный узел, интеллектуальное устройство, сервер или другой модуль обработки.

[00163] Чтобы обеспечивать возможность различного распределения этих элементов или функциональных задач обработки, их требования к аппаратным средствам должны согласовываться с характеристиками доступных аппаратных средств. Функциональные (например, P1) характеристики приложений, такие как программное окружение ОС, зависимость от времени, полоса пропускания сети, определяют требования для оптимальных параметров гостя, например, в качестве местоположения. Параметр типа хоста, например, виртуальная машина, контейнер или платформа без программного обеспечения, определяет то, какой тип ограничений накладывается на гостя, хостинг которого может выполняться. В свою очередь, параметр вычислительного узла характеризуется посредством типа аппаратной платформы узла и определяет то, какие ограничения накладываются на хост. Тип аппаратной платформы определяется, например, посредством типа процессора, к примеру, ARM или X86; емкости запоминающего устройства, емкости хранения или близости.

9. Примерные технологии для размещения рабочих нагрузок

[00164] Ссылаясь на фиг. 18, проиллюстрирован способ для размещения рабочей нагрузки в SDA-системе (например, в SDA-системе 600 на фиг. 6A). SDA-система, которая предоставляется 1801, сконфигурирована через портал автоматизации или системное программное обеспечение (например, системное программное обеспечение 640 на фиг. 6A, системное программное обеспечение 740 на фиг. 7B) для выполнения намеченной функции автоматизации, которая включает в себя предварительно определенные функции устройств, назначаемые различным автоматизированным устройствам.

[00165] Как пояснено выше, функция автоматизации включает в себя различные функции устройств для различных полевых устройств. Эти функции устройств включают в себя различные задачи, которые могут разбиваться согласно программированным программным объектам. Соответственно, способ требует определения 1802 задач предварительно определенных функций устройств. Когда задачи определены или идентифицированы, промышленные рабочие параметры оцениваются 1803 на предмет каждой задачи функций устройств. Кроме того, после оценки, задачи функций устройств могут ранжироваться 1804 посредством рабочих параметров автоматизированной системы. Когда промышленные рабочие параметры оценены и ранжированы, задачи могут выбираться для распределения по автоматизированным устройствам на основе промышленных рабочих параметров. Распределение задач по автоматизированным устройствам может включать в себя повторное развертывание задач 1805, по меньшей мере, в одном автоматизированном устройстве и разгрузку задач 1806 в один из вычислительных узлов на основе промышленных рабочих параметров. Помимо этого, автоматизированное устройство может представлять собой соединенное интеллектуальное устройство, допускающее хостинг самого вычислительного узла, за счет этого обеспечивая разгрузку задач в вычислительный узел, хостинг которого выполняется посредством автоматизированного устройства.

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

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

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

[00169] Кроме того, чувствительный ко времени уровень в качестве промышленных рабочих параметров также может быть компилирован в качестве набора параметров, причем набор параметров в таком случае включает в себя точность времени выполнения и количественную длительность.

[00170] Дополнительный промышленный рабочий параметр представляет собой затраты на исполнение. Этот промышленный рабочий параметр может выражать, например, ограничения по времени обработки, такие как количество времени обработки, он может выражать уровень потребления ресурсов и/или требование с точки зрения производительности обработки, необходимой для выполнения конкретной задачи на конкретном автоматизированном устройстве. Он может выражаться в объеме запоминающего устройства, требуемом для того, чтобы сохранять информацию. Он также может выражаться как характеристики с точки зрения объема обработки, например, в миллионах инструкций в секунду (MIPS) или в операциях с плавающей запятой в секунду (FLOPS).

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

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

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

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

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

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

[00177] Обращаясь к фиг. 19, проиллюстрирован другой пример способа для размещения рабочей нагрузки в SDA-системе (например, SDA-системе по фиг. 4). Аналогично, в способе, описанном относительно фиг. 19, SDA-система, которая предоставляется 1901, может быть сконфигурирована через системное программное обеспечение (например, системное программное обеспечение 640 на фиг. 6A) для выполнения функции автоматизации. Аналогично, способ этого примера включает в себя определение 1902 задач предварительно определенных функций устройств, оценку 1903 промышленных рабочих параметров для каждой задачи функций устройств и ранжирование 1904 задач функций устройств посредством промышленных рабочих параметров. SDA-система затем может быть сконфигурирована 1905 согласно упорядоченным промышленным рабочим параметрам, которые могут включать в себя повторное развертывание задач на автоматизированных устройствах и разгрузку задач в вычислительные узлы.

[00178] Способ затем продолжается посредством переоценки промышленных рабочих параметров 1906 для каждой задачи и еще одного ранжирования 1 907 этих параметров. Когда промышленные рабочие параметры переоценены и ранжированы, задачи могут быть повторно развернуты 1908 в автоматизированных устройствах, и задачи могут разгружать в вычислительные узлы автоматизированной системы.

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

[00180] В способе, ссылаясь на фиг. 20, оценка промышленных рабочих параметров для каждой задачи 2001 включает в себя определение нескольких или всех параметров для каждой задачи. Таким образом, способ включает в себя определение, по меньшей мере, одного из критического с точки зрения технологического процесса уровня 2002, чувствительного ко времени уровня 2003, затрат 2004 на исполнение, критического с точки зрения близости уровня 2005; и эффективности 2006 затрат. Не все параметры, возможно, должны определяться. Но предпочтительно, для каждой задачи определяются идентичные параметры, чтобы обеспечивать возможность сравнения и ранжирования. Определение параметров может выполняться одновременно или последовательно. Некоторые параметры могут задаваться оператором системы управления производственным процессом, тогда как другие могут извлекаться из способа, которым задачи предварительно определенных функций устройств организуются или программируются. Кроме того, оценка параметров может включать в себя весовые коэффициенты, чтобы обеспечивать определенную степень гибкости в оценке параметров.

[00181] Аналогичные соображения применимы для этапа ранжирования задач посредством промышленных рабочих параметров 2101. Соответственно, в соответствии со ссылкой на фиг. 21, ранжирование задач включает в себя ранжирование посредством критического с точки зрения технологического процесса уровня 2102, посредством чувствительного ко времени уровня 2103, посредством затрат 2104 на исполнение, посредством критического с точки зрения близости уровня 2105 и/или ранжирование посредством эффективности 2106 затрат.

[00182] Обращаясь к фиг. 22, ранжирование задач посредством промышленных рабочих параметров 2201 также может включать в себя отмену выбора задач в качестве индикатора того, что они не подходят для перераспределения. Это означает того, что эти задачи не оцениваются и не рассматриваются для перераспределения. Соответственно, ранжирование задач посредством параметров 2201 может включать в себя отмену выбора критических с точки зрения технологического процесса задач 2202, отмену выбора чувствительных ко времени задач 2203, ранжирование посредством затрат на исполнение 2204, отмену выбора критических с точки зрения близости задач 2205 и/или ранжирование посредством эффективности 2206 затрат. Это, в частности, может применяться, к примеру, описанному относительно фиг. 19.

[00183] Способ, которым определяется количественно уровень каждого промышленного рабочего параметра, может отличаться согласно параметру. Один может находиться масштабе в пределах от 1 до 100, от 0 до 10 или от 0 до 1 и включать в себя десятичные дроби. Для другого, он может представлять собой просто "да/нет" для повторного развертывания, либо он может включать в себя спектр цветов. Для еще одного другого, он может представлять собой заданные строки {"низкий", "промежуточный", "высокий"}. В одном примере, параметры могут задаваться оператором. В другом примере, они могут задаваться поставщиком системы. В еще одном другом примере, они могут вычисляться на основе вычислительной мощности, временных ограничений физических соединений или других физических свойств, которые могут определяться на месте, даже в то время когда система работает.

[00184] Когда применимые параметры оцениваются, и задачи ранжируются согласно этим параметрам, повторное развертывание и разгрузка задач могут выполняться на основе промышленных рабочих параметров. Это обеспечивает прямое согласование требований задачи и ограничений с аппаратными характеристиками устройств и вычислительных узлов. Например, характеристики по безопасности устройства должны быть выше требования по безопасности, так что, например, подтверждается "SIL3, когда SIL2". Альтернативно, характеристики по доступности одного вычислительного ресурса могут составлять шесть девяток, что подтверждается, когда требование указывает пять девяток. При сопоставлении задач и аппаратных средств, весовой коэффициент может применяться для различных параметров. Например, точность синхронизации, указываемая в качестве 20 мс, может включать в себя процент от разрешенного отклонения.

[00185] Ссылаясь на фиг. 23, развертывание задач в полевых устройств и разгрузка задач в вычислительные узлы может включать в себя выбор задач 2301 для распределения на основе ранга и указание выбранных задач 2302 для туманного серверного контроллерного узла (например, туманного серверного контроллера 610 на фиг. 6A). Туманный серверный контроллерный узел затем должен распределять выбранные задачи 2303 в автоматизированные устройства, такие как PLC, PAC, устройства ввода-вывода или другие полевые устройства, на основе оцениваемых промышленных рабочих параметров. В свою очередь, сетевой контроллерный узел (например, сетевой контроллер 690 на фиг. 6A) должен устанавливать сетевую связь 2305 между вычислительными узлами, чтобы упрощать выполнение распределенных задач. Например, посредством конфигурирования виртуальной сети или управления сетевыми элементами физической сети.

[00186] В дополнение к вышеуказанному, способ дополнительно может включать в себя выбор задач 2301 для разгрузки в вычислительные узлы на основе промышленных рабочих параметров. В этом случае, эти задачи, выбранные для разгрузки, также должны указываться 2302 для туманного серверного контроллерного узла. Туманный серверный контроллерный узел затем распределяет задачи, выбранные для разгрузки 2304, в вычислительные узлы на основе оцениваемых промышленных рабочих параметров. Кроме того, сетевой контроллер устанавливает сетевую связь 2305 между вычислительными узлами, чтобы упрощать выполнение распределенных задач.

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

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

[00188] Фиг. 24 является блок-схемой примерной машины/компьютера/устройства, которое может выполнять различные операции и сохранять различную информацию, сформированную и/или используемую посредством таких операций в соответствии с некоторыми вариантами осуществления. Компьютер 2400 предназначен для того, чтобы иллюстрировать аппаратное устройство, на котором могут реализовываться любые из объекты, компоненты или услуги, проиллюстрированные в примерах фиг. 1-7B, 8A-11, 13B и 17A-C (и любые другие компоненты, описанные в этом подробном описании), и технологии, описанные в примерах фиг. 12-13A, 14-16B и 18-23, к примеру, сервер, клиентские устройства, вычислительные узлы, контроллерные узлы (например, туманный серверный контроллер (компоненты 610, 810-x, 910, 1010, 1110), контроллер кибербезопасности (например, компоненты 655, 1155), сетевой контроллер (например, компоненты 690, 590A, 590B, 1190)), устройства/узлы хранения, базы данных, PLC, PAC и т.п. Компьютер 2400 включает в себя один или более процессоров 2405 и запоминающее устройство 2410, соединенные с межкомпонентным соединением. Межкомпонентное соединение может представлять любую одну или более отдельных физических шин, соединений "точка-точка" или и то, и другое, соединенных посредством соответствующих мостов, адаптеров или контроллеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Способ размещения рабочей нагрузки в программно-определяемой автоматизированной (SDA) системе, содержащий этапы, на которых:

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

причем данное множество вычислительных узлов коммуникационно соединены с системным контроллерным узлом через первую сеть связи;

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

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

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

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

оценивают промышленные рабочие параметры для каждой задачи функций устройств;

ранжируют задачи по промышленным рабочим параметрам;

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

2. Способ по п. 1, в котором SDA-система дополнительно содержит вычислительные узлы; при этом распределение задач по, по меньшей мере, двум автоматизированным устройствам содержит этапы, на которых:

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

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

3. Способ по п. 1 или 2, в котором промышленные рабочие параметры содержат:

критический с точки зрения технологического процесса уровень; и/или

чувствительный ко времени уровень; и/или

затраты на исполнение; и/или

критический с точки зрения близости уровень; и/или

эффективность затрат.

4. Способ по п. 3, в котором оценка промышленных рабочих параметров содержит, для каждой задачи, этапы, на которых:

определяют критический с точки зрения технологического процесса уровень; и/или

определяют чувствительный ко времени уровень; и/или

определяют затраты на исполнение; и/или

определяют критический с точки зрения близости уровень; и/или

определяют эффективность затрат.

5. Способ по п. 4, в котором ранжирование задач по промышленным рабочим параметрам содержит этапы, на которых:

ранжируют по критическому с точки зрения технологического процесса уровню; и/или

ранжируют по чувствительному ко времени уровню; и/или

ранжируют по затратам на исполнение; и/или

ранжируют по критическому с точки зрения близости уровню; и/или

ранжируют по эффективности затрат.

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

потребность в доступности функции; и/или

требование по безопасности.

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

точность времени выполнения, и

количественную длительность.

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

ограничения по времени обработки;

потребление ресурсов; и/или

требование с точки зрения производительности обработки.

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

близость к первичному актуатору; и/или

взаимозависимость близости первичной задачи относительно вторичных задач.

10. Способ по любому из пп. 3-9, в котором эффективность затрат в качестве промышленных рабочих параметров содержит набор параметров, содержащих:

капитальные расходы; и

эксплуатационные расходы.

11. Способ по любому из предшествующих пунктов, в котором повторное развертывание задач и разгрузка задач содержит этапы, на которых:

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

указывают выбранные задачи для разгрузки в контроллерный SDA-узел;

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

устанавливают сетевую связь между вычислительными узлами для обеспечения выполнения распределенных задач.

12. Способ по п. 11, в котором повторное развертывание задач и разгрузка задач дополнительно содержит этапы, на которых:

выбирают задачи для повторного развертывания на основе промышленных рабочих параметров;

указывают выбранные задачи для повторного развертывания в контроллерный SDA-узел;

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

устанавливают сетевую связь между вычислительными узлами для обеспечения выполнения распределенных задач.