Архитектура организации промышленных программно-определяемых сетей для развертывания в программно-определяемой автоматизированной системе

Изобретение относится к архитектуре программно-определяемой сети (SDN) для промышленного окружения. Технический результат заключается в проектировании промышленных производственных приложений без ограничения вследствие конфигурации сети и использовании информации относительно сетевых событий для того, чтобы не только обслуживать сеть, но также и администрировать промышленные операции. Промышленная SDN-архитектура содержит плоскость инфраструктуры, плоскость управления, содержащую контроллеры, чтобы управлять и администрировать физические и виртуальные устройства, причем контроллеры включают в себя сетевой контроллер, контроллер администрирования виртуализации и контроллер кибербезопасности, плоскость приложений, содержащую одно или более конечных пользовательских промышленных приложений, и плоскость платформы, содержащую набор программных услуг и интерфейсов прикладного программирования, чтобы задавать интерфейс связи с плоскостью приложений в направлении севера и плоскостью управления в направлении юга для доступа к одному или более из множества контроллеров в плоскости управления для централизованного администрирования промышленной сети. 3 н. и 21 з.п. ф-лы, 2 табл., 40 ил.

 

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

[0001] Данная заявка притязает на приоритет и выгоду следующих предварительных заявок на патент (США): заявки (США) порядковый номер № 62/370686, озаглавленной "Deployment of Software Defined Network As Part Of Software Defined Automation", поданной 3 августа 2016 года; и заявки (США) порядковый номер № 62/376470, озаглавленной "Deployment of Software Defined Network As Part Of Software Defined Automation", поданной 18 августа 2016 года. Вышеуказанные заявки на патент явно содержатся по ссылке в данном документе.

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

[0002] Сети связи (или просто сети) обеспечивают обмен данными. Обмен данными может осуществляться между компьютерами, компьютерами и периферийными устройствами и другими устройствами. Промышленные сети отличаются от традиционных сетей связи, поскольку они обрабатывают управление и мониторинг физических процессов, которые зачастую выполняются в суровых атмосферных условиях, при ограничениях на целостность данных и в реальном времени и с ожиданием непрерывной и надежной работы для обеспечения безопасности и по другим причинам. Промышленные сети связи типично основаны на таких технологиях/протоколах связи, как: Ethernet, Modbus, ControlNet, DeviceNet и т.п.

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

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

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

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

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

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

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

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

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

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

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

[0013] Фиг. 5C является блок-схемой, иллюстрирующей проектную архитектуру промышленной SDN-системы в соответствии с некоторыми вариантами осуществления.

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

[0015] Фиг. 6B является блок-схемой, иллюстрирующей SDA-сети.

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

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

[0018] Фиг. 7A является блок-схемой, иллюстрирующей SDN-архитектуру, содержащую три плоскости.

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

[0020] Фиг. 7C является блок-схемой, иллюстрирующей архитектуру промышленных программно-определяемых сетевых приложений (ISDNA) в соответствии с некоторыми вариантами осуществления.

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

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

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

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

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

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

[0027] Фиг. 9D является блок-схемой, иллюстрирующей вид возможностей промышленных логических подключений примерного промышленного приложения по фиг. 9A.

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

[0029] Фиг. 9F является блок-схемой, иллюстрирующей общий вид возможностей подключения примерного промышленного приложения по фиг. 9A.

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

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

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

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

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

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

[0036] Фиг. 13A является блок-схемой, иллюстрирующей примерные компоненты аналитического приложения в рабочей промышленной SDN в соответствии с некоторыми вариантами осуществления.

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

[0038] Фиг. 13C является блок-схемой трендов активности на ежемесячной основе, день за днем и час за часом.

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

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

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

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

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

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

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

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

[0046] Это раскрытие сущности описывает архитектуру программно-определяемой сети (SDN) для промышленного окружения ("промышленной SDN") и развертывание промышленной SDN в программно-определяемой автоматизированной (SDA) системе.

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

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

[0049] Чтобы осознавать признаки и преимущества промышленной SDN-архитектуры и SDA-системы, развернутой с промышленной SDN, ниже предоставляется краткий обзор традиционной SDN-архитектуры и SDA-системы.

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

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

[0051] SDN-архитектура представляет собой многоуровневую архитектуру на основе трех базовых принципов:

(1) Разделение плоскостей управления и данных: Этот принцип предоставляет возможность отдельной эволюции механизма перенаправления от управления сетевыми ресурсами. Другими словами, управление сетью работает на абстрактных механизмах перенаправления, позволяющих сетевым элементам становиться товаром.

(2) Логически централизованное управление: В SDN-виде, контроллер представляет собой окрестратор сетевых элементов. Логически централизованное управление означает вид сетевой инфраструктуры в качестве целостного объекта, предоставляющий SDN-контроллеру глобальное управление всеми сетевыми ресурсами, т.е. контроллер ведет себя как централизованный административный и управляющий объект.

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

[0052] Ссылаясь на фиг. 1A, архитектура традиционной организации сетей содержит выделенные сетевые устройства 102, такие как, но не только: маршрутизаторы, коммутаторы, брандмауэры и т.п., предоставленные посредством различных производителей. Каждое сетевое устройство 102 включает в себя плоскость управления, поддерживающую различные протоколы, и плоскость 108 данных. Эта сетевая инфраструктура с оборудованием от различных производителей гарантирует, что каждое устройство 102a, 102b и 102c администрируется отдельно с использованием собственного интерфейса 104a, 104b и 104c производителя, соответственно, в силу этого приводя к тому, что подготовка, обслуживание и отмена ввода в действие являются чрезвычайно длительными и дорогостоящими. Использование специализированных аппаратных средств и иногда настраиваемых протоколов гарантирует то, что реализация и доступность сетевых функций диктуется посредством производителей. Она также соответствует бизнес-модели производителя и жизненному циклу продукта, а не потребностям при развертывании сети.

[0053] В отличие от традиционной организации сетей, SDN характеризуется посредством разъединения функций управления и перенаправления в сети. Сетевое управление или интеллект является логически централизованным в SDN-контроллере 120, что обеспечивает возможность администраторам сети динамически регулировать сетевой поток трафика, чтобы удовлетворять изменяющиеся потребности. Кроме того, даже несмотря на то, что программные SDN-контроллеры поддерживают глобальный вид сети, она выглядит для приложений, механизмов обработки политик и/или других объектов 112 как один логический объект. При реализации через открытые стандарты, SDN упрощает проектирование и работу сети, поскольку инструкции предоставляются посредством SDN-контроллеров 120 вместо нескольких конкретных для производителя устройств и протоколов. Каждое из сетевых устройств 114a и виртуализированного сетевого устройства 114b (например, OpenvSwitch) содержит плоскость данных, отвечающую за перенаправление трафика.

[0054] Ссылаясь на фиг. 1B, в типичном сетевом устройстве 102, таком как маршрутизатор или коммутатор, весь интеллект находится в самом устройстве. Устройство 102 обычно реализуется в трех плоскостях: плоскость 108a данных, плоскость 106a управления и плоскость 116a администрирования. Плоскость 108 данных представляет собой уровень, отвечающий за перемещение пакетов, и обычно реализуется в собственных аппаратных средствах поставщика с фиксированной технологией перенаправления и требует собственного приложения/конфигурации 104. Плоскость 106a управления представляет собой уровень, отвечающий за принятие решений по перенаправлению и обмен ими с другими устройствами. Она может реализовываться в аппаратных средствах и/или в микропрограммном обеспечении с конкретными для производителя протоколами и признаками. Этот тип реализации приводит к существованию сложных и выделенных сетевых устройств. Плоскость 116a администрирования представляет собой уровень, который предоставляет интерфейс администрирования и обычно реализуется в качестве программного обеспечения в форме интерфейса командной строки (CLI). CLI-реализация является конкретной (специфичной) для производителя и в силу этого затруднительной для автоматизации в окружении с оборудованием от различных производителей.

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

[0056] В реализации SDN-устройства 114 плоскость управления может реализовываться на CPU общего назначения, за счет этого снижая сложность сетевых аппаратных средств и исключая сложную реализацию протоколов в микропрограммном обеспечении. Кроме того, плоскость управления более не привязывается к конкретному сетевому устройству, в силу чего возможна консолидация плоскостей управления всех устройств. Эта консолидация представляет собой то, что известно как SDN-контроллер 155. Он представляет собой SDN-контроллер 155, который предоставляет централизованный сетевой интеллект и обеспечивает целостный вид сети. Плоскость 116b администрирования в SDN-устройстве 114 представляет собой непосредственно SDN-приложение 112. Оно представляет собой программируемую часть SDN, и оно предназначено для того, чтобы предоставлять свободу администрирования сети и проектные решения, конкретные для сетевых потребностей пользователей.

[0057] Один из наиболее распространенных протоколов, используемых посредством SDN-контроллера 155 для того, чтобы программировать базовые аппаратные средства плоскости 108b данных, представляет собой OpenFlow (OF). OpenFlow представляет собой независимый от производителей стандарт. Один аспект SDN на основе OpenFlow заключается в том, что плоскость 108b данных работает с потоками, а не со статическими таблицами поиска, такими как таблица MAC-адресов в коммутаторах или таблицы маршрутизации в маршрутизаторах. Потоки в SDN лучше всего описываются как правила сопоставления с шаблоном, используемые для коммутации пакетов. Именно принцип снижения сложности управляющих протоколов до одного протокола и обеспечения поисков на основе потоков с использованием быстродействующего запоминающего устройства, такого как троичное ассоциативное запоминающее устройство (TCAM), может приводить к упрощению инфраструктурных устройств и использованию превращенных в товар аппаратных средств в качестве сетевых устройств.

2. Программно-определяемая автоматизация (SDA)

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

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

[0059] Фиг. 2 является схемой, иллюстрирующей упрощенную архитектуру SDA-системы в соответствии с некоторыми вариантами осуществления. Архитектура иллюстрирует туманный сервер 222, связанный с системным программным обеспечением 224, и соединенные интеллектуальные устройства 228A, 228B, которые функционально соединяются с туманным сервером 222 и системным программным обеспечением 224 через магистраль 226 связи. Архитектура также иллюстрирует то, что, по меньшей мере, некоторые соединенные интеллектуальные устройства 228B и туманный сервер 222 могут функционально соединяться с облаком 218.

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

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

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

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

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

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

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

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

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

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

[0069] Примерный функциональный вид SDA-системы, проиллюстрированный на фиг. 3, включает в себя плоскость 305 приложений, плоскость 315 управления и плоскость 352 ресурсов. Плоскость 305 приложений охватывает системное программное обеспечение 334 и программные компоненты или приложения 325, которые выполняются в системе и которые используют и администрируют набор ресурсов системы. Плоскость 315 управления включает в себя набор контроллеров, включающих в себя туманный серверный контроллер 335 (или туманный контроллер, или контроллер администрирования виртуализации), сетевой контроллер 356 и контроллер 345 кибербезопасности (CS). При использовании в данном документе сетевой контроллер 356 может включать в себя SDN-контроллер, TSN-контроллер или TsSDN-контроллер, который включает временную область в SDN-контроллер. TsSDN-контроллер и его роль в предоставлении гарантированной детерминированной связи описываются в связанной PCT-заявке № PCT/EP2017/068213, поданной 19 июля 2017 года, которая полностью содержится в данном документе. Эти контроллеры предоставляют стандартизированный набор интерфейсов с приложениями в плоскости 305 приложений, чтобы осуществлять доступ и/или администрировать ресурсы в плоскости 352 ресурсов системы. В некоторых вариантах осуществления контроллеры также предоставляют диагностику, администрирование доступности и т.п. Сетевой контроллер 356 может администрировать и распределять сетевые политики 336 на системном уровне. Аналогично, CS-контроллер 345 может принудительно активировать политики 338 безопасности на системном уровне.

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

[0071] Плоскость 352 ресурсов может включать в себя сетевые ресурсы 348, вычислительные ресурсы, представленные посредством вычислительных узлов 342, ресурсы 344 хранения и ресурсы 346 безопасности. Системное программное обеспечение 334 и приложения 325 выполняются в вычислительных узлах 342, администрируемых посредством туманного контроллера 335. Вычислительные узлы 342, которые предоставляют вычислительные ресурсы в систему, могут физически распределяться и администрироваться посредством туманного контроллера 335. Например, некоторые вычислительные узлы в форме серверов расположены на туманном сервере или в закрытом облаке, тогда как другие вычислительные узлы, такие как соединенные интеллектуальные устройства, работают на краю. Сетевые ресурсы 348 могут представлять собой виртуальные сетевые ресурсы на туманном сервере, физические инфраструктурные ресурсы в коммутационном/маршрутизирующем оборудовании или инфраструктурные ресурсы, расположенные в соединенных интеллектуальных устройствах. Ресурсы 344 хранения могут представлять собой базы данных и/или другие устройства для сохранения виртуальных образов, томов, приложений, данных технологических процессов, данных состояния и т.п. Ресурсы 346 безопасности могут включать в себя компоненты системы безопасности, постоянно размещающиеся в вычислительных узлах 342, узлах 344 хранения, и/или автономные компоненты, которые предоставляют услуги обеспечения безопасности, такие как принудительная активация политик безопасности, обнаружение и защита от проникновений и т.п.

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

III. SDA-система

[0073] SDA-система содержит различные подсистемы, которые взаимодействуют, чтобы предоставлять полностью интегрированное решение для создания, администрирования и работы автоматизированных систем. Фиг. 4A является блок-схемой, иллюстрирующей подсистемы SDA-системы в соответствии с некоторыми вариантами осуществления. SDA-система 400 в некоторых вариантах осуществления включает в себя туманную серверную подсистему 454 ("туманный сервер"), имеющую туманный контроллер или резервированные туманные контроллеры 435, один или более вычислительных узлов 442 и хранилище 444. SDA-система 400 также включает в себя программные компоненты 456. В других вариантах осуществления, SDA-система 400 дополнительно может включать в себя подсистему 458 кибербезопасности (CS), имеющую контроллер безопасности или резервированные контроллеры 445 безопасности, физические и/или виртуализированные компоненты 461 системы безопасности и репозиторий 438 политик безопасности, сохраняющий CS-политики. В еще одних других вариантах осуществления, SDA-система 400 также может включать в себя сетевую подсистему 462, имеющую сетевой контроллер или резервированные сетевые контроллеры 456, физическую сеть 463, физические сетевые компоненты 465, виртуальные сети 464, виртуальные сетевые компоненты 466 и репозиторий 436 сетевых политик, сохраняющий сетевые политики.

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

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

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

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

[0078] Подсистема 456 программных компонентов может включать в себя виртуализированные компоненты 459, которые хостинг которых выполняется посредством экосистемы виртуализации туманного сервера 454. Подсистема 456 программных компонентов также может включать в себя виртуализированные экземпляры программного обеспечения 425, которые выполняются в окружении виртуализации (например, программного обеспечения для программирования, конфигурирования и/или администрирования (например, Unity, SoMachine, SCADA), которое используется для того, чтобы программировать, конфигурировать, администрировать или иным образом взаимодействовать с автоматизированными устройствами. В некоторых вариантах осуществления подсистема 456 программных компонентов также может включать в себя системное программное обеспечение 434 (также называемое "порталом автоматизации"), которое предоставляет один интерфейс для администрирования топологии, инвентаризации, конфигурирования, программирования, управления и/или диагностики автоматизированных устройств и/или автоматизированной системы в целом.

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

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

[0081] Сетевая подсистема 462 включает в себя сетевую Ethernet-инфраструктуру для всего решения на основе SDA-системы. В некоторых вариантах осуществления сетевая подсистема 462 представляет собой сетевую SDN-подсистему, имеющую SDN-контроллер или резервированные SDN-контроллеры в качестве сетевого контроллера 456. SDN-сеть предоставляет отделение управляющей логики сети от базовых сетевых аппаратных средств (например, маршрутизаторов, коммутаторов) и логическую централизацию управления сетью через SDN-контроллер. Это означает то, что SDN-контроллер может распределять сетевые политики по всей сетевой инфраструктуре (т.е. физической сети 463 и физическим сетевым компонентам 465, а также виртуальным сетям 464 и виртуальным сетевым компонентам 466), чтобы управлять возможностями подключения, полосой пропускания и временем задержки, соглашениями об уровне обслуживания (SLA) (например, в ответ на: детерминированное время ответа/время передачи), управление потоком трафика и т.д., и сетевые аппаратные средства могут реализовывать эти политики. Сетевые политики сетевой подсистемы 462 могут сохраняться в репозитории 436 сетевых политик в некоторых вариантах осуществления.

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

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

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

[0085] Область действия туманного сервера 454 представляет собой туманный контроллер 435, вычислительные узлы 442 и администрирование виртуализированных компонентов 459 в пределах туманного сервера 605. Виртуализированные компоненты 459 и программное обеспечение 425 (например, Historian, SCADA, SoMachine, Unity) находятся не в пределах объема управления туманным сервером 605, а в пределах объема управления подсистемой 456 программных компонентов. Тем не менее, программные компоненты 456, через системное программное обеспечение/портал 434 автоматизации, взаимодействуют с туманным контроллером 435 и вычислительными узлами 442, чтобы предоставлять конфигурационные и управляющие вводы на туманный сервер 454 и/или в другие подсистемы, чтобы управлять их работой.

[0086] Чтобы предоставлять решение на уровне всей системы, неразрывность управления сетью расширяется таким образом, что она включает в себя и виртуальные и физические компоненты сети. Следовательно, область действия сетевой подсистемы 462 включает в себя не только физические сетевые компоненты 465 и физическую сеть 463, но также и виртуальные сети 464 и виртуальные сетевые компоненты 466, которые создаются и существуют в пределах туманного сервера 454. Это требует полной интеграции между сетевой подсистемой 462 и туманным сервером 454, чтобы предоставлять механизмы, чтобы осуществлять это управление. Например, туманный серверный контроллер 435 может создавать виртуальные сети 464 на туманном сервере 454 и управлять возможностями подключения между виртуальными машинами/контейнерами, хостинг которых выполняется на вычислительных узлах 442, и виртуальными сетями 464, в то время как сетевой контроллер 456 может конфигурировать виртуальные сетевые компоненты 466 виртуальных сетей 464 в соответствии с одной или более сетевых политик. Эта степень интеграции требует оркестровки последовательностей создания и удаления экземпляров, поскольку, очевидно, виртуальная сеть 464 должна существовать до того, как виртуальные машины и контейнеры могут быть соединены.

[0087] CS-подсистема 458 управляет компонентами системы безопасности, такими как системы 467 обнаружения проникновений (IDS), системы 468 защиты от проникновений (IPS) (например, виртуализированные брандмауэры следующего поколения) и т.п., а также CS-контроллером 445, который распределяет политики безопасности в различные объекты. CS-подсистема 458 может интегрироваться со всеми аспектами решения на основе SDA-системы в некоторых вариантах осуществления. Например, сетевой контроллер 456 может использовать услуги обеспечения безопасности, предоставленные посредством CS-подсистемы 458, чтобы предоставлять конфигурационную информацию системы безопасности в сетевые компоненты (например, физические или виртуальные) в пределах объема. В некоторых вариантах осуществления туманный сервер 454 может использовать эту услугу для того, чтобы аутентифицировать входы в учетную запись, предоставлять политики безопасности для конфигураций хостов (виртуальных машин, контейнеров, платформ без программного обеспечения), проверять достоверность образов хостов перед созданием экземпляра и т.п.

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

3. SDN для промышленного окружения

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

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

[0091] Архитектура, системы и способы, раскрытые в данном документе (в дальнейшем "раскрытая технология"), разрешают эти и другие проблемы посредством обеспечения упрощения при администрировании сети. В некоторых аспектах, раскрытая технология упрощает создание экземпляра, развертывание, обслуживание и администрирование промышленных сетей. Более нет необходимости понимать то, как компонуется сеть, либо то, к какому порту подключать промышленное устройство. Вместо этого, устройство может подключаться где угодно в заводской сети, и раскрытая технология должна автоматически обнаруживать устройство, определять его характеристики, подготавливать сетевой тракт в соответствии с политиками безопасности, чтобы обеспечивать возможность ему обмениваться данными с другими объектами в сети, и вводить в действие устройство с тем, чтобы начинать выполнение.

[0092] Раскрытая технология делает сеть программируемой, что в свою очередь позволяет вносить область сетевого инжиниринга в область промышленных приложений и делать ее неотъемлемой частью полного проектирования промышленных приложений. Другими словами, разработчики промышленных приложений не должны быть ограничены в соответствии с проектированием сети или решениями сетевого инженера. Проектировщики промышленных приложений должны иметь прямой программируемый доступ к событиям технологического процесса, таким как: ухудшение времени отклика приложений (ART), потеря возможностей подключения, нарушение системы безопасности и многие другие. Проектировщик промышленных приложений также должен иметь способность сегментировать сеть на основе промышленных функций, а не характеристик сети или, что еще хуже, проектирования сети. Таким образом, промышленное приложение должно становиться адаптируемым к состоянию сети со "сквозной" сетевой видимостью и управлением.

[0093] Посредством оркестровки, аспекта раскрытой технологии, проектировщик промышленных приложений должен иметь способность прозрачно создавать экземпляр услуг сетевого уровня по запросу (например, через промышленное SDN-приложение) для виртуализации сетевых функций (NFV). Примеры таких услуг включают в себя, но не только: услуги обеспечения кибербезопасности, такие как: глубокий анализ пакетов (DPI) и брандмауэры, балансировщики нагрузки, анализаторы трафика, NAT, прокси-услуги, маршрутизация и т.п. Создание экземпляра сетевой функции в качестве виртуализированной услуги в корректное время и в корректном месте является ответственностью промышленного SDN-приложения (ISDNA), которое подробно описывается в отношении фиг. 7C-7E. Предоставление соответствующих возможностей подключения на основе политик между элементами, виртуальными или реальными, может достигаться с использованием сцепления функций предоставления услуг (SFC).

4. Промышленная SDN-архитектура

[0094] Промышленная SDN-архитектура 500 может быть проиллюстрирована как состоящая из нескольких различных плоскостей и уровней, как проиллюстрировано на фиг. 5A и 5B, соответственно. Ссылаясь на фиг. 5A, плоскостно-ориентированный вид промышленной SDN-архитектуры содержит четыре плоскости, каждая из которых описывается ниже.

I. Плоскость приложений

[0095] Плоскость 505 приложений в промышленной SDN-архитектуре реализует управляющие промышленные приложения 525. Управляющие промышленные приложения (или просто промышленное приложение) и управляющие SDA-приложения (или просто SDA-приложения) используются взаимозаменяемо в этом раскрытии сущности. Управляющие промышленные приложения разрабатываются с помощью программного обеспечения для разработки промышленного приложения. Один пример управляющего промышленного приложения, которое постоянно размещается в этой плоскости 505, представляет собой программу, которая достигает функции транспортерной ленты с опциями для запуска и остановки, обнаружением отказов и простым счетчиком изделий, разработанную посредством разработчика промышленных приложений. Функция транспортерной ленты может разрабатываться с использованием других управляющих приложений, таких как управляющее PLC-приложение (например, для того, чтобы управлять набором точек ввода-вывода) и приложение контроллера электромотора, которые затем могут программным образом связываться, чтобы формировать приложение для работы транспортерной ленты. Промышленные приложения 525 в этой плоскости составляют часть программного компонента 456 на фиг. 4A. Промышленные приложения 525 могут считаться источником информации и требований для промышленной SDN.

II. Плоскость платформы

[0096] Плоскость 510 платформы реализует набор программного обеспечения и интерфейсов прикладного программирования (API), которые задают интерфейс с промышленным приложением 525 в плоскости 505 приложений в направлении севера и обеспечивают доступность программируемого доступа контроллерам (550, 555, 560) в плоскости 515 управления в направлении юга. Компоненты плоскости 510 платформы включают в себя туманный окрестратор 535, промышленное SDN-приложение 540 (ISDNA) и CS-окрестратор 545. Приложение или услуга верхнего уровня, известная как SDA-окрестратор 530, скрывает большую часть сложности оркестровки и управления и обеспечивает доступность API, который разработчики промышленных приложений могут использовать для того, чтобы разрабатывать промышленные приложения 525.

III. Плоскость управления

[0097] Плоскость 515 управления реализует объекты, которые управляют устройствами в плоскости 520 инфраструктуры. Компоненты оркестровки плоскости 510 платформы оркеструют SDN и/или другие элементы управления, чтобы достигать функций промышленного приложения 525. Плоскость 515 управления содержит туманный контроллер 550, SDN-контроллер 555 и контроллер 560 кибербезопасности (CS). Следует отметить, что каждый из этих контроллеров представляет логически централизованную систему управления. Например, в примерной системе, несколько контроллерных SDN-узлов могут быть физически распределены, но вместе они представляют логически централизованный SDN-контроллер. SDN-контроллер 555, не только администрирует физические сети, но и вместе с туманным контроллером 550 также администрирует виртуальные сети. CS-контроллер 560 администрирует политики безопасности и совместно работает и с туманным контроллером 550 и с SDN-контроллером 555, чтобы принудительно активировать политики безопасности. Следует отметить, что в некоторых вариантах осуществления плоскость 515 управления может включать в себя TsSDN-контроллер либо как SDN-контроллер 555, так и TSN-контроллер. В таких вариантах осуществления, плоскость 510 платформы может содержать соответствующий компонент(ы) окрестратора. Аспекты туманного контроллера 550, SDN-контроллера 555 и CS-контроллера 560 уже описаны в отношении фиг. 4A (например, туманного контроллера 435, сетевого контроллера 456 и CS-контроллера 445).

IV. Плоскость инфраструктуры

[0098] Плоскость 520 инфраструктуры реализует связь посредством предоставления возможностей физических и виртуальных сетевых подключений. Она содержит каждое устройство в сети, которое участвует в сети в качестве отправителя, потребителя или переходного элемента информации (т.е. устройства, которое извлекает/проталкивает информацию). Эти устройства могут представлять собой промышленные устройства 575 и инфраструктурные устройства 570. Промышленные устройства 575 включают в себя те устройства, которые выполняют промышленную функцию или функцию автоматизации либо ее часть. Например, PLC, модуль ввода-вывода, электромотор, привод и т.д., которые необходимы для того, чтобы реализовывать функции автоматизации. Инфраструктурные устройства 570 включают в себя сетевое оборудование, такое как коммутаторы, маршрутизаторы, промежуточные устройства и т.п. Предусмотрено два типа инфраструктурных 570 и промышленных устройств 575 - виртуальные и реальные. Виртуальные устройства 565 (или виртуализированные элементы) выполняются на таких аппаратных средствах, как серверы, PC и т.п. PLC, который выполняется на сервере и который не имеет физической реализации, представляет собой пример виртуального промышленного устройства. Аналогично, OpenvSwitch, который представляет собой программную реализацию многоуровневого сетевого коммутатора, представляет собой пример виртуализированного элемента 565, хостинг которого выполняется на вычислительном ресурсе 580. С другой стороны, реальное устройство представляет собой аппаратное устройство. Примеры реального инфраструктурного устройства включают в себя контроллерные SDN-устройства, такие как NoviSwitch 1248 от NoviFlow и BlackDiamond X8 от Extreme Networks. Эти инфраструктурные устройства, в отличие от традиционных сетевых устройств, представляют собой простые перенаправляющие устройства без встроенного управления. Сетевой интеллект из этих устройств является логически централизованным в SDN-контроллере 555 в плоскости 515 управления. В некоторых вариантах осуществления реальные инфраструктурные устройства 570 могут включать в себя унаследованные сетевые устройства, которые могут не допускать SDN-управление.

[0099] Промышленные SDN-плоскости соединяются с двумя понятиями ответственности: оркестровка 574 и информация 573. Оркестровка включает в себя ответственность за автоматизированную компоновку, координацию и администрирование сложных сетевых элементов и протоколов. Информация включает в себя ответственность за сбор, анализ, интерпретацию, представление и организацию информации сети, что в свою очередь обеспечивает возможность промышленному приложению программным образом реагировать на характеристики сети.

[00100] Сетеориентированный вид задается посредством вида сети по модели взаимодействия открытых систем (OSI). Естественно описывать сеть по уровням и обычно с использованием подхода по принципу "снизу вверх". Например, сеть может описываться как содержащая 3 устройства и 10 коммутаторов, соединенных в ячеистую сеть, бесконтурная топология обеспечивается с использованием RSTP-протокола; и устройства обмениваются данными с использованием EIP-протокола. Промышленная SDN-архитектура, как проиллюстрировано на фиг. 5B, состоит из семи уровней, имеющих собственные конкретные функции. Эти уровни включают в себя: уровень инфраструктуры, южный интерфейс, уровень управления, северный интерфейс, уровень ISDNA-, туманной и SDN-оркестровки, уровень SDA-оркестровки и промышленное приложение. В некоторых вариантах осуществления ISDNA-, туманная, SDN- и SDA-оркестровка могут рассматриваться как часть уровня оркестровки.

[00101] Согласно сетевым индивидуальным настройкам и для простоты понимания, ниже описывается каждый из различных уровней промышленной SDN-архитектуры, охватывающей четыре плоскости, проиллюстрированные на уровне-ориентированном виде промышленной SDN-архитектуры, по принципу "снизу-вверх" от аппаратных средств к промышленному приложению.

I. Уровень 1: Уровень инфраструктуры

[00102] Промышленная SDN-инфраструктура содержит инфраструктурные устройства 570, промышленные устройства 575 и виртуализированные элементы 565. Ниже подробно описывается каждый из компонентов уровня инфраструктуры в отношении фиг. 6A-6D.

[00103] Вся область SDN-управления, как проиллюстрировано на фиг. 6A, может классифицироваться на физические и виртуальные устройства. Область SDN-управления включает в себя реальные инфраструктурные устройства 678, такие как промышленные устройства и сетевые устройства, а также виртуальные промышленные устройства и сетевые устройства в виртуальном окружении 679, которые выполняются на облачном сервере 677 (т.е. в распределенной вычислительной платформе). На основе этой классификации, даже фактическая сеть может различаться в качестве реальной сети и виртуальной сети, поскольку эти сети могут быть основаны на любых сетевых топологиях 666, таких как кольцо, ячеистая сеть, полностью соединенная, линия, дерево, звезда и т.п. Хотя с точки зрения ISDNA-технологии, различение между физическими и виртуальными устройствами не является обязательным, основная цель различения состоит в том, чтобы упрощать понимание объема и ответственности ISDNA.

[00104] SDA-сеть (т.е. сеть в SDA-системе) может разделяться на три различных физических сети, как проиллюстрировано на фиг. 6B. Туманная административная сеть выделяется администрированию туманных устройств 676 с возможностями сетевых подключений, проиллюстрированными посредством пунктирных линий. Административная SDN-сеть (сеть управления и администрирования (OAM)) выделяется администрированию SDN-устройств 614 с возможностями сетевых подключений, проиллюстрированными посредством сплошных полужирных линий. Промышленная сеть представляет собой фактическую производственную сеть сетью, которая предоставляет связь между реальными и виртуализированными промышленными устройствами 675. Возможности сетевых подключений в промышленной сети проиллюстрированы посредством неполужирных сплошных линий.

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

[00106] Хотя промышленная сеть имеет реальные физические устройства, она также имеет виртуальные устройства, которые соединяются через виртуальные сети, как проиллюстрировано на фиг. 6C. Устройства, проиллюстрированные в облаке 679 виртуального окружения, представляют собой виртуализированные экземпляры физических устройств, таких как коммутаторы, маршрутизаторы, PC, PLC, брандмауэры и т.п. Они соединяются через виртуальные линии связи. Сеть виртуальных устройств с виртуальными соединениями упоминается как виртуализированная сеть. Виртуальные устройства постоянно размещаются на физических узлах туманного сервера (т.е. вычислительных узлах), которые составляют часть реальной сети. Это означает то, что реальная сеть и виртуализированная сеть взаимно соединяются, чтобы формировать область промышленного SDN-управления, как проиллюстрировано на фиг. 6D. Как проиллюстрировано на фиг. 6D, область промышленного SDN-управления содержит физические туманные устройства 676 (например, серверы) на туманном сервере 677, SDN-устройства 614 (например, коммутаторы компании Extreme Networks), промышленные устройства 675 в промышленной инфраструктуре 678, виртуальные промышленные и инфраструктурные устройства в виртуализированном окружении 679, хостинг которого выполняется на туманном сервере 654, а также физическую сеть 663 и виртуальную сеть 664. ISDNA администрирует область промышленного SDN-управления через SDN-контроллер с вводом, предоставленным из SDA-приложения или промышленного приложения, туманного административного приложения или туманного окрестратора 535 и приложения системы кибербезопасности или CS-окрестратора 545. Также проиллюстрированы на фиг. 6D в виртуальном окружении 679 туманные устройства 679a без программного обеспечения. Устройства без программного обеспечения выполняют специализированный двоичный образ, который тесно соединяется с аппаратными средствами хоста (т.е. аппаратными средствами вычислительного узла), во многом аналогично традиционному встроенному устройству. Это двоичный образ может в полной мере пользоваться преимуществом прямого доступа к аппаратным средствам, идентично тому, как если образ установлен на заводе. В некоторых вариантах осуществления образ без программного обеспечения может представлять собой полное ядро и операционную системы (ОС), чтобы превращать узел без программного обеспечения в полный вычислительный узел с VM и/или контейнеры с собственной поддержкой для VM и/или контейнеров.

[00107] Исторически, доминирующая топология в промышленной инфраструктуре представляет собой цепь или кольцо в местах, в которых требуется резервирование. Основной движущий фактор этих топологий в отношении древовидных или ячеистых топологий состоит в уменьшении материальных затрат и затрат на установку. Теперь, когда туман представляет собой основной фактор в промышленной инфраструктуре, топологический вид сети преобразуется в смесь колец и ячеистых сетей. Поскольку ядро тумана (т.е. туманный контроллер) типично постоянно размещается физически очень близко к другим физическим частям туманного сервера, таким как вычислительные узлы, узлы хранения и т.п., которые взаимно соединяются с помощью быстрых соединений с высокой пропускной способностью, и поскольку оно представляет собой высокопроизводительное устройство, оно может иметь множество высокоскоростных сетевых интерфейсов. В связи с этим, его монтажные соединения могут полностью объединяться в ячеистую топологию 666a при относительно низких затратах. С другой стороны, промышленные устройства, в общем, развертываются на большом расстоянии друг от друга и имеют существенно худшие характеристики с меньшим числом сетевых интерфейсов с более низкой скоростью. В связи с этим, краевые устройства могут развертываться в цепях и кольцах (например, 666b). Следует отметить, что в других вариантах осуществления, могут развертываться различные другие топологии, такие как звезда, полностью соединенная, линия, дерево, шина и т.п.

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

[00109] В промышленных сетях внимание акцентируется на Ethernet. Ethernet спроектирован с возможностью работать в бесконтурных топологиях. Эта топология может достигаться посредством соединения устройств Ethernet в: шине, звезде, дереве или в комбинации вышеозначенного. Неправильная конфигурация монтажных соединений в этих топологиях приводит к созданию контуров, которые впоследствии приводят к репликации линейной скорости трафика, более известной как "широковещательные штормы". Чтобы исправлять случайные или даже намеренные контурные топологии, инфраструктурные Ethernet-устройства обычно развертывают протоколы связующего дерева, такие как STP, RSTP, MSTP, SPB и т.п. Способность этих протоколов предоставлять полностью соединенную (связующую) и бесконтурную (древовидную) топологию приводит к намеренному Ethernet-развертыванию с использованием кольцевых и ячеистых топологий. В этих топологиях, протоколы связующего дерева выступают в качестве протоколов резервирования. Промышленный Ethernet очень любит кольцевую топологию, поскольку она предоставляет одну отказоустойчивую сеть при минимальных затратах на кабельные соединения с обоснованными временами восстановления. Идентичный или аналогичный уровень функциональности может предоставляться в промышленной SDN-сети.

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

[00111] Когда административная сеть и производственная сеть сливаются, возникает проблема самоинициализации: если SDN-контроллер должен администрировать административную сеть, то административная сеть должна быть бесконтурной. Для того, чтобы быть бесконтурной, ей требуется SDN-контроллер. Именно здесь возникает дилемма причинной связи. С точки зрения SDN, SDN-контроллер имеет полное управление сетью, т.е. каждое устройство в SDN-управляемой сети имеет тракт в SDN-контроллер после подготовки.

[00112] Устройство, самоинициализируемое со всеми интерфейсами в состоянии блокировки, может использовать LLDP-протокол для того, чтобы обмениваться информацией относительно местоположения контроллера. Протокол обнаружения канального уровня (LLDP) может использоваться для обмена OpenFlow-информацией таким способом, который приводит к тракту в SDN-контроллер. После того, как устройство получает тракт в SDN-контроллер, контроллер может переконфигурировать устройство с возможностью интегрироваться в сеть. Контроллерное SDN-приложение затем может приспосабливать разделение администрирования и эксплуатации через свои конфигурационные параметры.

[00113] Некоторые инфраструктурные устройства в промышленной области интегрируют инфраструктуру и конечное устройство в одно устройство. Например, PLC, который выступает в качестве как PLC, так и коммутатора. В связи с этим, эти типы промышленных устройств являются подходящими для прямого администрирования посредством SDN-контроллера. Чтобы администрироваться посредством SDN-контроллера, устройство может реализовывать, по меньшей мере, один южный интерфейс выбранного SDN-контроллера. Одно примерное решение состоит в том, чтобы инструктировать такому устройству реализовывать OpenFlow или аналогичный протокол. Реализация OpenFlow на уровне промышленных устройств должна обеспечивать SDN-управление на уровне устройств.

II. Уровень 2. Южный интерфейс

[00114] На фиг. 5C, для того, чтобы администрироваться посредством SDN-контроллера, устройство в плоскости 520 инфраструктуры может реализовывать, по меньшей мере, один южный интерфейс 585 выбранного SDN-контроллера. Южные интерфейсы 584, которые включают в себя южные API, задают протокол связи между управляющими объектами в плоскости 515 управления и инфраструктурными устройствами в плоскости 520 инфраструктуры, чтобы обеспечивать возможность им взаимодействовать друг с другом. В связи с этим, южные интерфейсы 574 требуются для разделения между плоскостью 515 управления и плоскостью 520 инфраструктуры. OpenFlow представляет собой один из наиболее популярных открытых южных стандартов для SDN.

III. Уровень 3. Управление

[00115] Одна из выгод SDN заключается в упрощенном развертывании, администрировании и обслуживании сети посредством логически централизованного управления, предлагаемого посредством SDN-контроллера 555. Инфраструктура уровня 1 администрируется посредством объектов плоскости управления, которые включают в себя:

(1) Туманный контроллер 550: отвечающий за администрирование тумана (т.е. платформы виртуализации)

(2) SDN-контроллер 555: отвечающий за администрирование SDN-сети

(3) CS-контроллер 560: отвечающий за администрирование кибербезопасности в целом.

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

(i) SDN-архитектура

[00117] Цель SDN-контроллера заключается в том, чтобы отделять управление сетью от тракта передачи данных и предоставлять абстракцию сетевых услуг. Как иллюстрирует SDN-архитектура, проиллюстрированная на фиг. 7A, SDN-контроллер 755a представляет собой посредника между сетью или SDN-приложением 712 и базовой сетевой инфраструктурой 714 в плоскости 708b данных.

[00118] В плоскости 754 приложений SDN-контроллер реализует интерфейс плоскости контроллеров приложений (A-CPI) и обеспечивает доступность северных интерфейсов 713 (NBI) для пользователей SDN-контроллера, чтобы разрабатывать сетеориентированные приложения без учета сведений по сетевой реализации. Эта плоскость представляет собой естественное постоянное размещение ISDNA.

[00119] Плоскость 706b управления представляет собой непосредственно SDN-контроллер 755a. Эта плоскость представляет централизованный интеллект SDN-сети. Хотя SDN-контроллер 755a может быть физически распределенным, он является логически централизованным в этой плоскости. Подробная архитектура контроллера зависит от реализации, но в общем, SDN-контроллер реализует южные протоколы 717 интерфейса плоскости контроллеров данных (D-CPI), чтобы обмениваться данными с инфраструктурными ресурсами и соответствующей услугой, чтобы обеспечивать возможность программируемости через A-CPI в качестве NBI 713. В частности, набор протоколов, реализованных в качестве D-CPI-интерфейса, позволяет SDN-контроллеру 755a непосредственно управлять фактическими ресурсами сетевых устройств, постоянно размещающимися в плоскости 708b данных.

[00120] Современный ландшафт контроллеров может разделяться на контроллеры с открытым исходным кодом и собственные контроллеры. Открытый исходный код предназначен главным образом для общего многофункционального SDN-контроллера, тогда как собственные контроллеры приспособлены к конкретным приложениям. Для функциональной совместимости, для SDN-контроллера 755a предпочтительно быть независимым от производителя. Один подход к ISDNA заключается в использовании платформы с открытым исходным кодом. SDN-контроллер 755a, подходящий для ISDNA-инфраструктуры, включает в себя OpenDaylight (ODL), который предлагает множество сетевых услуг и южных протоколов. Другая подходящая опция включает в себя ONOS, при этом ее производительность представляет собой главную причину для выбора.

[00121] Одно место, в котором может осуществляться ISDNP-интеграция с SDN-контроллером, находится в NBI-интерфейсе SDN-контроллера. Тем не менее, в NBI-интерфейсах множества SDN-контроллеров отсутствует стандартизация. Тем не менее, ISDNA-архитектура оснащена таким образом, чтобы справляться с этим посредством реализации контроллерных SDN-агентов, которые описываются в отношении фиг. 7E.

(ii) Интеграция с туманным контроллером

[00122] Ссылаясь на фиг. 5B, ISDNA 540 управляет реальной, а также виртуальной промышленной сетью. В то время как реальная сеть находится под прямым управлением SDN-контроллера 555, виртуализированная сеть управляется посредством туманного контроллера 550. Чтобы обеспечивать возможность этим двум системам управления взаимодействовать друг с другом, в раскрытой промышленной SDN-архитектуре, туманный контроллер 550 и SDN-контроллер 555 функционально соединяются друг с другом, предоставляя единую сетевую привязку в ISDNA 540. Интеграция туманного контроллера 550 и SDN-контроллера 555 материализуется на плоскости 515 промышленного SDN-управления. Одна примерная реализация интеграции между туманным контроллером 550 и SDN-контроллером 55 проиллюстрирована на фиг. 7B, который описывается ниже.

[00123] Фиг. 7B иллюстрирует пример интеграции между OpenStack-реализацией туманного контроллера 750 и ODL-реализацией SDN-контроллера 755. Подключаемый ML2-модуль 750a, предоставленный посредством OpenStack, использует REST API ODL для того, чтобы осуществлять доступ к приложению 755b в SDN-контроллере 755 и выдавать команды в ODL. ODL интерпретирует команды и, в ответ, создает, конфигурирует и заполняет таблицы перенаправления коммутаторов OpenvSwitch-базы 755b данных (OVSDB) с использованием OpenFlow. В этот момент, SDN-контроллер 755 и туманный контроллер 750 полностью управляются посредством SDN-контроллера 755, что означает то, что полная сетевая топология является доступной для ISDNA через северные ODL-интерфейсы. ISDNA может в этот момент интегрироваться с SDN-контроллером 755.

(iii) Интеграция с контроллером кибербезопасности

[00124] Ссылаясь на фиг. 5B, CS-контроллер 560 представляет собой объект, отвечающий за управление политиками кибербезопасности. Эти политики вырабатываются на сетевом уровне и уровне устройств. В связи с этим, CS-контроллер 550 сопрягается с туманным контроллером 550, а также с ISDNA 540.

[00125] Цель интеграции CS-контроллера 560 с туманным контроллером 550 состоит в том, чтобы создавать и манипулировать виртуализированной сетевой инфраструктурой. Интеграция CS-контроллера 560 с ISDNA 540 основана на простом предписании инструктировать CS-контроллеру 560 управлять: возможностью доступа, использованием и контентом связи, обрабатываемой посредством ресурсов в промышленной SDN-сети. Интеграция SDN-контроллера 555 и CS-контроллера 560 основана на нескольких фундаментальных аспектах ISDNA 540, включающих в себя виртуализацию сетевых функций (NFV) и сцепление функций предоставления услуг (SFC).

[00126] Виртуализация сетевых функций (NFV) представляет собой принцип сетевой архитектуры, который использует технологии IT-виртуализации для того, чтобы виртуализировать полные классы функций сетевых узлов в компоновочные блоки, которые могут соединяться или сцепляться вместе, чтобы создавать услуги связи. С точки зрения безопасности в некоторых вариантах осуществления NFV может использоваться для того, чтобы виртуализировать связанные с кибербезопасностью функции, такие как брандмауэры, DPI и т.п., и позиционировать их в стратегически важных точках в промышленной SDN-сети. Предусмотрено два типа NFV-развертывания: централизованное и распределенное. Централизованный подход основан на развертывании виртуализированной сетевой функции и перенаправлении всего трафика в нее для обработки. Распределенный подход основан на специализированной для устройства функции кибербезопасности с конкретным набором политик. В любом случае, SDN-контроллер 555 направляет трафик к функциям на основе политик, заданных посредством CS-контроллера 560.

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

[00128] В некоторых вариантах осуществления интеграция ISDNA 540 и CS-контроллера 560 может быть основана на наборе базовых потребностей с двух точек зрения. Во-первых, CS-контроллер 560 создает функции и озадачивает ISDNA 540, чтобы соединять их. Во-вторых, CS-контроллер 560 озадачивает ISDNA 540, чтобы создавать функции и соединять их на основе набора предоставленных политик.

IV. Уровень 4. Северный интерфейс

[00129] SDN-контроллер 555 предлагает API разработчикам приложений, чтобы обеспечивать возможность разработчикам приложений программировать SDN-контроллер 555. Этот API используется посредством ISDNA 540 в плоскости 510 платформы, чтобы обмениваться данными с SDN-контроллером 555.

V. Уровень 5: ISDNA-, туманная и CS-оркестровка

[00130] Этот уровень содержит набор программного обеспечения и API, которые могут программным образом осуществлять доступ к контроллерам в плоскости 515 управления и оркестровать их, чтобы администрировать и управлять инфраструктурными устройствами. ISDNA 540, туманный окрестратор 535 и CS-окрестратор 545 этого уровня тесно соединяются с соответствующими SDN-, туманными и CS-контроллерами в плоскости 515 управления. Туманный окрестратор 535 реализует потребности в виртуализации через туманный контроллер 550, и CS-окрестратор 545 реализует политики безопасности через CS-контроллер 545. ISDNA 540 реализует сетевые функции через SDN-контроллер 555. В частности, ISDNA 540 описывает сеть через обеспечение доступности ISDNA API. Посредством обеспечения доступности ISDNP API на основе функциональных видов ISDNA 540 обеспечивает программируемость промышленных сетей. Эти объекты вместе формируют целостный вид SDA-приложения. Ниже подробно описывается архитектура ISDNA и некоторые его компоненты в отношении фиг. 7C-7E.

[00131] Фиг. 7C является блок-схемой, иллюстрирующей ISDNA-архитектуру в соответствии с некоторыми вариантами осуществления. ISDNA 740 предоставляет согласованный промышленный сетевой интерфейс через ISDNA API 740a, обращенный к разработчикам SDA-приложений на северной стороне. На южной стороне, он обращен к SDN-контроллеру в плоскости 715 управления. Как проиллюстрировано, ISDNA 740 может включать в себя несколько сетевых услуг, таких как CS-услуга 740b, услуга 740c топологий и туманная административная услуга 740d. Эти сетевые услуги отвечают за оркестровку сети и сбор статистики на основе конкретного вида услуг. Услуга 740c топологий предоставляет информацию относительно физической и логической сетевой топологии. CS-услуга 740b предоставляет интерфейс с CS-окрестратором (также называемым "CS-приложением") (например, CS-оркестровкой 545 на фиг. 5B). Туманная административная услуга 740d предоставляет интерфейс с туманным окрестратором (также называемым "туманным административным приложением") (например, туманной оркестровкой 535 на фиг. 5B).

[00132] ISDNA 740 также включает в себя несколько агентов, таких как контроллерный SDN-агент 740e, агент 740f SDN-устройства и агент 740g виртуализации. Контроллерный SDN-агент 740e реализует интерфейс, конкретный для SDN-контроллера в плоскости 715 управления. Например, если SDN-контроллер представляет собой ODL-контроллер, контроллерный SDN-агент 740e представляет собой контроллерный ODL-агент. Аналогично, если SDN-контроллер представляет собой ONOS-контроллер, контроллерный SDN-агент 740e представляет собой контроллерный ONOS-агент. Агент 740g виртуализации реализует интерфейс, конкретный для платформы виртуализации. Агент 740f SDN-устройства, с другой стороны, реализует интерфейсы с сетевыми устройствами в плоскости 720 инфраструктуры. В некоторых вариантах осуществления агент 740f SDN-устройства представляет собой необязательный интерфейс для прямой поддержки унаследованных устройств, которые не являются совместимыми с SDN-контроллером. Агент 740f SDN-устройства предоставляет южные интерфейсы, чтобы обеспечивать возможность целевым устройствам управляться и конфигурироваться. Неограничивающие примеры целевых устройств включают в себя устройства, которые могут управляться и конфигурироваться с использованием промышленных протоколов, таких как, но не только: Modbus и EtherNet/IP (EIP). В других вариантах осуществления, вместо агента 740f SDN-устройства, интеграция промышленных протоколов в качестве южного интерфейса SDN-контроллера может поддерживать унаследованные устройства.

[00133] Ссылаясь на фиг. 7D, проиллюстрирована примерная архитектура для услуги 740c топологий. Одна из основных функций услуги 740c топологий заключается в обнаружении устройств в сети. Чтобы обнаруживать и идентифицировать устройства, услуга 740c топологий взаимодействует с SDN-контроллером, туманным контроллером и CS-контроллером (например, компонентами 555, 550 и 560, соответственно, на фиг. 5B). Процесс обнаружения может включать в себя обнаружение различных аспектов, включающих в себя возможности подключения, идентификацию устройств, идентификацию сетей, идентификацию связи и т.п.

[00134] Например, услуга 740c топологий сопрягается с SDN-контроллером, чтобы определять возможности физических и логических подключений (например, через администрирование 781 физической сети и администрирование 782 логической сети, соответственно). Для идентификации устройств, услуга 740c топологий может сопрягаться с контроллерным SDN-агентом 740e, SDA-окрестратором, туманной административной услугой 740d и/или административной CS-услугой 740b. Например, из контроллерного SDN-агента 740e, услуга 740c топологий может получать характеристики сетевых устройств. Из SDA-окрестратора, туманной административной услуги 740d и административной CS-услуги 740b, услуга 740c топологий может получать информацию, идентифицирующую устройства, обнаруженные в сети.

[00135] Для идентификации сетей услуга 740c топологий может сопрягаться с контроллерным SDN-агентом 740e и SDA-окрестратором. В частности, из контроллерного SDN-агента 740e, услуга 740c топологий может идентифицировать технологии сегментации сети и сегменты существующей сети. Из SDA- или туманного окрестратора, услуга 740c топологий может идентифицировать взаимосвязь сегмента сети с SDA-группировкой промышленных функций или приложений. Например, группа промышленных функций может обмениваться данными с использованием логического или физического сегмента сети. Услуга 740c топологий может связывать сеть с SDA-группировкой. Услуга 740c топологий также может идентифицировать доступные протоколы связи (например, из аналитического приложения, описанного в отношении фиг. 11A и 13A, либо из анализа потоков связи), отдельные потоки связи или потоки (например, через диспетчер 783 связи).

[00136] Услуга 740c топологий также может включать в себя функциональный диспетчер 784, который идентифицирует функции сетевых устройств. Сетевые устройства могут разделяться или группироваться посредством функций. Например, некоторые ассоциированы с функцией управления, в то время как другие могут быть ассоциированы с производственной функцией. Рассмотрим систему смешивания цемента, которая имеет сенсорную систему, которая измеряет влагу, текучесть, частоту вращения, температуру и/или другие параметры. Если не предусмотрено функционального администрирования, система смешивания цемента может останавливаться по любой причине, к примеру, когда комплект осветительных приборов гаснет, или контроллер прекращает работу, что приводит к остановке всей сети и принудительному затвердеванию цементной смеси. Таким образом, вместо наличия прямого соединения, информация подается через обмен 786 информацией в систему 788 управления очередью событий, которая администрирует события асинхронным способом.

[00137] Хотя функциональность обнаружения топологии решает проблемы, связанные с устройствами, которые в данный момент присутствуют в сети, функциональность проектирования топологий решает проблемы, связанные с предполагаемыми и проектированными устройствами в сети. Основная цель этой функциональности состоит в том, чтобы предоставлять пользователю способность создавать сетевые топологии и модифицировать обнаруженные топологии. Создание сетевых топологий может рассматриваться с двух точек зрения: физические и логические топологии вместе с управлением политиками. Физическая топология или возможности подключения представляют собой фактическую линию связи между двумя узлами в сети. Эта возможность подключения может устанавливаться между любым типом узла, причем узел представляет собой конечный узел или инфраструктурный узел. В некоторых вариантах осуществления функциональность проектирования топологий может идентифицировать сетевые устройства, доступные для использования в промышленном приложении, предоставлять характеристики сети обнаруженных устройств в промышленное приложение, сопрягаться с туманной административной услугой 740d, чтобы подготавливать NFV, сопрягаться с SDN-контроллером, чтобы создавать сегментацию сети, обеспечивать доступность API для проектирования подложенной сети, обеспечивать доступность API для проектирования наложенной сети и т.п.

[00138] Ссылаясь на фиг. 7E, контроллерный SDN-агент 740e обеспечивает связь между ISDNA 740 и SDN-контроллером 755. Контроллерный SDN-агент 740e сопрягается с ISDNA API в направлении севера и с SDN-контроллером 755 в направлении юга. ISDNA-архитектура является агностической к SDN-контроллеру, т.е. она обеспечивает возможность использования любого SDN-контроллера через развертывание подключаемого модуля 740e контроллерного агента для этого SDN-контроллера. Например, если ODL-контроллер развертывается в сети, то контроллерный ODL-агент может развертываться в ISDNA, чтобы обеспечивать возможность ISDNA сопрягаться с ODL-контроллером. Контроллерный SDN-агент 740e может транслировать информацию из услуги 740c топологий, например, для SDN-контроллера таким образом, что SDN-контроллер может добавлять устройство, удалять устройство, заменять устройство и т.д. В некоторых вариантах осуществления контроллерный SDN-агент 740e может включать в себя управляющий агент 789, имеющий API 789a администрирования топологий, обработку 789b событий устройства и администрирование 789c сетевых политик. Администрирование 789c сетевых политик может транслировать требования кибербезопасности для SDN-контроллера 755. Один пример такой транслируемой политики представляет собой: разрешать только YouTube-доступ к любому устройству, соединенному с портом 1.

[00139] Компонент 789b обработки событий устройства может проталкивать события из SDN-контроллера 755 вверх в другие компоненты ISDNA 740e. Например, SDN-контроллер 755 может обнаруживать событие потери линии связи, и это событие может обрабатываться посредством компонента 789b обработки событий устройства. Дополнительная информация (например, относительно события) может получаться через API 789a администрирования топологий. В любом случае, событие передается в услугу 740c топологий. Услуга 740c топологий затем может определять, от физического к логическому, где физическое соединение потеряно, и формировать сообщения в различных плоскостях. Например, услуга 740c топологий может определять то, где физическое соединение потеряно, и формировать сообщение в плоскости инфраструктуры, например, через агент SDN-устройства. Аналогично, она может определять то, где логическое соединение разрывается, и формировать сообщение в плоскости управления, например, через контроллерный SDN-агент 740e. Информация, при передаче в плоскость приложений, например, может приводить к вводу в действие резервирования. Таким образом, как проиллюстрировано на фиг. 5B, информация 573 может распространяться из плоскости 520 инфраструктуры через различные уровни в плоскость 505 приложений, тогда как оркестровка 574 распространяется из плоскости приложений 525 вниз в плоскость 520 инфраструктуры.

VI. Уровень 6. SDA-оркестровка

[00140] Ссылаясь на фиг. 5B, компонент 530 SDA-оркестровки представляет собой единое программное обеспечение, которое размещается поверх ISDNA 540, туманного окрестратора 535 и CS-окрестратора 545 уровня 5 и скрывает сложность за этими компонентами посредством обеспечения доступности API в направлении севера, чтобы сопрягаться с промышленными приложениями 525.

VII. Уровень 7. Промышленное приложение

[00141] Промышленные приложения 525 размещаются поверх SDA-окрестратора 535. Пользователи работают с точки зрения приложения и, по сути, описывают систему, которую они хотят встраивать, на собственном языке приложения, а не на языке сети. Эти промышленные приложения используют API, доступный посредством SDA-окрестратора, чтобы передавать свои требования в SDA-окрестратор 530 для оркестровки элементов управления в плоскости 515 управления.

5. Проектная архитектура промышленной SDA-системы

[00142] Фиг. 5C является блок-схемой, иллюстрирующей пример проектной архитектуры промышленной SDA-системы. На схеме проектной архитектуры, пользователи используют программное обеспечение, чтобы создавать промышленные приложения 525 в плоскости 505 приложений. Такие промышленные приложения 525 могут включать в себя функцию или набор функций и создаются не на языке сети, а на языках программирования, которые являются собственными для приложений (например, на PLC-языках программирования). В качестве примера, пользователь может создавать приложение для работы транспортерной ленты с использованием одного или более приложений, задающих различные компоненты, такие как PLC, электромотор, коммутатор, датчик движения, визуальная сигнализация и т.д., которые требуются для работы транспортерной ленты.

[00143] SDA-окрестратор 530, который сопрягается с промышленным приложением 525 (например, через API), предоставляет необходимые абстракции, чтобы скрывать подробности оркестровки компонентов плоскости 510 платформы и плоскости 515 управления, чтобы упрощать разработку приложений. Другими словами, пользователь может создавать приложение для работы транспортерной ленты без знания подробности нижележащих уровней и компонентов, без необходимости отдельно осуществлять доступ и программировать каждый из контроллеров или инфраструктурных устройств, и без необходимости тщательно планировать то, где и как соединять инфраструктурные устройства с существующей сетью. SDA-окрестратор 530 вместе с ISDNA 540, туманным административным окрестратором 535 и CS-окрестратором 545 упрощает процесс создания приложений для работы транспортерной ленты посредством предложения возможностей физических и логических сетевых подключений и реализации CS-признаков и политик для того, чтобы создавать изолированные логические единицы для диагностики, управления, брандмауэра и т.д. В частности, туманный административный окрестратор 535, который соединяется с туманным контроллером 550, может оркестровать создание виртуализированных элементов в одном или более вычислительных узлов на туманном сервере. CS-окрестратор 545, который соединяется с CS-контроллером 560, может оркестровать CS-контроллер 560 с возможностью реализовывать политики кибербезопасности. Для SDN, функции и взаимосвязи между ISDNA 540, SDN-контроллером 555 и виртуализированными элементами 565, инфраструктурными устройствами 570 и промышленными устройствами 575 представляют основной интерес. ISDNA 540, которое сопрягается с SDN-контроллером 555 через северный интерфейс 584, оркеструет SDN-контроллер 555 с возможностью предлагать тракты связи, которые могут быть основаны на определяемых пользователем критериях, таких как нагрузка, характеристики базовой инфраструктуры, чувствительность ко времени и т.п. SDN-контроллер 555 взаимодействует с виртуализированными элементами 565, инфраструктурными устройствами 570 и/или промышленными устройствами 575 через южный интерфейс 585, чтобы задавать тракт(ы) связи, который может использовать каждое устройство в плоскости 520 инфраструктуры.

6. Примерный случай использования промышленной SDN-архитектуры

[00144] Промышленная SDN-архитектура, содержащая ISDNA, удовлетворяет различным потребностям в промышленном окружении и предоставляет промышленным потребителям окончательное управление и понимание сети, которое является невозможным при традиционной архитектуре или архитектуре SDN-сети. Другими словами, при ISDNA-архитектуре, сеть становится потребляемой по отношению к пользователю. Следовательно, сеть может становиться нематериальной, когда она является работающей, и прозрачной, когда она не является работающей. Один из примерных случаев использования для реализации промышленной SDN-архитектуры служит для упрощения процесса подготовки и ввода в действие с точки зрения промышленного приложения, т.е. предоставления возможности пользователю "защищенно соединять что угодно где угодно".

I. Защищенная и явная подготовка и ввод в действие

[00145] В существующем промышленном окружении подготовка и ввод в действие устройства представляет собой сложный процесс. Нельзя просто соединять устройство где угодно и ожидать то, что он будет работать надлежащим образом. Промышленная сеть имеет множество правил (топологий) подключений, системных ограничений, ограничений сетевых протоколов и т.д. Вдобавок к сложности существующей сети, виртуализация, которая представляет собой неотъемлемый аспект SDA, еще более повышает эту сложность. В силу комбинации физических и виртуальных устройств и их комплементарных реальных и виртуальных сетей формируется новый сетевой домен, который проиллюстрирован на фиг. 6D. Как проиллюстрировано, область промышленного SDN-управления охватывает туман 654, в котором выполняется хостинг виртуального окружения 679, включающего в себя виртуализированные устройства, а также инфраструктурного окружения 678, которое включает в себя промышленные устройства, вычислительные системы и т.д.

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

(i) SDA-система (например, через ISDNA) определяет то, подходит или нет физическое местоположение для соединения устройства.

(ii) SDA-система (например, через ISDNA) определяет то, разрешается или нет соединенному устройству участвовать в сети.

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

(iv) SDA-система (например, через ISDNA) подготавливает сетевой тракт во все ресурсы, требуемые посредством устройства, такие как хранение, точки ввода-вывода, другие равноправные устройства и т.п.

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

[00148] Фиг. 8 является диаграммой потоков данных, иллюстрирующей явную и защищенную подготовку устройства в промышленной SDN-сети в соответствии с некоторыми вариантами осуществления.

[00149] Когда новое промышленное устройство 875c в первый раз соединяется с промышленной SDN-сетью (например, Ethernet-сетью) настоящего раскрытия сущности, оно передает в широковещательном режиме запрос по протоколу разрешения адресов (ARP). Каждое инфраструктурное устройство (например, 814) в сети программируется посредством SDN-контроллера 855, чтобы перенаправлять ARP-пакет неизвестного источника в SDN-контроллер 855. Таким образом, ARP-пакет из промышленного устройства 875c, которое должно подготавливаться, также перенаправляется в SDN-контроллер 855. Следующий этап для SDN-контроллера 855 заключается в том, чтобы определять то, разрешается или нет промышленному устройству 875c обмениваться данными с какими-либо другими устройствами или ресурсами в сети. Чтобы выполнять это определение, SDN-контроллер 855 передает информацию относительно промышленного устройства 875c (например, его MAC-адрес, IP-адрес и/или любую другую информацию, инкапсулированную в ARP-запросе), извлеченную из ARP-запроса, в ISDNA 840 (например, через контроллерный SDN-агент 740e на фиг. 7C). ISDNA 840 в свою очередь может запрашивать SDA-окрестратор на предмет того, чтобы идентифицировать промышленное устройство и релевантные политики кибербезопасности, применимые к промышленному устройству в некоторых вариантах осуществления. В частности, SDA-окрестратор 830 может получать релевантные политики для подготовки промышленного устройства 875c из CS-окрестратора 845/CS-контроллера 860. Например, такая политика может требовать, чтобы промышленное устройство 875c было аутентифицировано посредством услуги 865a аутентификации. Услуга 865a аутентификации, которая управляется посредством CS-контроллера 860, например, может постоянно размещаться на физическом вычислительном узле туманного сервера. Услуга 865a аутентификации может реализовывать список управления доступом (ACL), который представляет собой способ для внесения в белый список устройств, разрешенных в сети, или любой другой способ аутентификации. SDN-контроллер 855, на основе информации, предоставляемой посредством SDA-окрестратора 830 (например, через ISDNA), создает сетевой тракт из промышленного устройства 875c в услугу 865a аутентификации. Таким образом, когда промышленное устройство 875c отправляет другой ARP-запрос, этот запрос проходит через предоставленный сетевой тракт в услугу 865a аутентификации. Услуга 865a аутентификации определяет то, авторизовано или нет промышленное устройство 875c на то, чтобы участвовать в сети, и то, что промышленному устройству 875c разрешается делать в сети. Если услуга 865a аутентификации определяет то, что промышленному устройству 875c разрешается участвовать в сети, она может осуществлять доступ к базе данных устройств, сконфигурированной посредством потребителя для сохранения различных типов устройств, то, как они группируются, характеристики, промышленные функции, протоколы, процедуры опроса и т.п. Информация из такой базы данных может использоваться для того, чтобы опрашивать и идентифицировать промышленное устройство 875c и/или определять ресурсы, требуемые посредством промышленного устройства 875c.

[00150] Например, услуга 865a аутентификации может определять из собранной информации (например, из базы данных устройств, информации из опроса устройств) то, что промышленное устройство 875c должно передавать во все устройства в "группе A". На примерной схеме по фиг. 8, PLC1 представляет собой устройство 875a, которое составляет часть группы A, с которой промышленное устройство 875c хочет обмениваться данными. Услуга 865a аутентификации предоставляет эту конфигурационную информацию доступа, ассоциированную с промышленным устройством 875c, в CS-контроллер 860 (например, через API). SDN-контроллер 855, на основе конфигурационной информации доступа, подготавливает тракт P1 из промышленного устройства 875c в PLC1 875a. Если разрешено посредством услуги 865a аутентификации (например, на основе CS-политики), тракт (P1') из PLC1 875a в промышленное устройство 875c также может подготавливаться посредством SDN-контроллера 855. Таким образом, промышленное устройство 875c и PLC1 875a могут обмениваться данными двунаправленно через тракты P1 и P1', подготовленные посредством SDN-контроллера 855.

[00151] Предположим, что PLC2 875b также принадлежит группе A, но находится в сегменте сети, отличном от PLC1 875a. SDN-контроллер 855 может программировать инфраструктурное устройство (устройства) 814 с возможностью подготавливать тракт P2 из промышленного устройства 875c в PLC2 875b и тракт P2' из PLC2 875b в промышленное устройство 875c. Следует отметить, что прямой и обратные тракты могут быть идентичными или отличающимися. В некоторых случаях, связь может быть однонаправленной.

[00152] В некоторых вариантах осуществления промышленному устройству 875c может требоваться внешнее хранение. Промышленное устройство 875c может запрашивать такое хранение, либо требование может указываться в политике. Запрос может обрабатываться посредством SDA-окрестратора 830 или через услугу конфигурирования устройства. В конечном счете, туманный контроллер 850 создает экземпляр узла хранения в одном или более вычислительных узлов и информирует SDN-контроллер 855 в отношении местоположения узла хранения. SDN-контроллер 855 в свою очередь предоставляет сетевой тракт из промышленного устройства 875c в узел хранения, чтобы обеспечивать возможность промышленному устройству 875c соединяться с узлом хранения, чтобы сохранять/извлекать данные (например, конфигурационную информацию, данные приложения и т.п.).

[00153] В некоторых вариантах осуществления SDN-контроллер 855 может предоставлять тракт на основе требований по QoS. Например, SDN-контроллер 855 может идентифицировать трафик из промышленного устройства 875c как "MODBUS". SDN-контроллер 855 затем может применять сетевую политику (например, сохраненную в базе данных сетевых политик) для MODBUS-трафика. На фиг. 8, предположим, что P1/P1' и P2/P2' представляют собой тракты, предоставленные посредством SDN-контроллера 855 для MODBUS-трафика. SERCOS представляет собой высокоскоростной протокол со строгими требованиями по синхронизации. Сетевая политика для SERCOS-трафика может предписывать, что SDN-контроллер 855 должен предоставляет новый тракт, на котором не разрешается другой трафик. На фиг. 8, P3/P3' могут представлять собой тракты, предоставленные посредством SDN-контроллера 855 для SERCOS-трафика.

[00154] После того, как новое промышленное устройство 875c проходит все проверки и имеет доступ ко всем ресурсам, которые ему требуются для того, чтобы быть полностью работающим (например, приложение загружается), процесс подготовки и ввода в действие считается законченным. Процесс отмены ввода в действие, в отличие от процесса подготовки и ввода в действие, заключает в себе отключение связи между двумя точками. Процесс отмены ввода в действие может инициироваться посредством пользовательской инструкции, изменения политики кибербезопасности, автоматического обнаружения отказа, возможности повторной оптимизации тракта и т.п. Например, аналитическое приложение (например, аналитическое приложение 1129 на фиг. 11A, аналитическое приложение 1320 на фиг. 13A), активно отслеживающее сеть, может определять то, что связь через тракт A не удовлетворяет требованиям по QoS (например, время задержки является слишком высоким), и в таком случае SDN-контроллер может отключать тракт A и предоставлять новый тракт B, который удовлетворяет требованиям по QoS.

7. Создание и развертывание промышленного приложения в промышленной SDN

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

[00156] Фиг. 9A является блок-схемой, иллюстрирующей создание примерного промышленного приложения в соответствии с некоторыми вариантами осуществления. Следует отметить, что примерное приложение служит только для цели иллюстрации; фактические промышленные приложения типично являются более сложными. Примерное приложение представляет собой примерное приложение для работы транспортерной ленты с опциями для остановки и запуска, обнаружением отказов и простым счетчиком изделий. В качестве первых нескольких этапов, пользователь может создавать требуемые функциональные компоненты с использованием приложения для проектирования. В некоторых вариантах осуществления несколько приложений могут использоваться для того, чтобы создавать приложение для работы транспортерной ленты (например, программное обеспечение Unity, чтобы предоставлять функциональность контроллеров при совместной работе с программным обеспечением Wonderware (SCADA-системы), чтобы визуализировать и управлять системой). Такие приложения могут быть доступными через системное программное обеспечение или портал автоматизации (например, системное программное обеспечение 434). Например, пользователь может создавать блок 902 транспортерной ленты и элемент 904 актуатора. Создание элемента актуатора или любых других элементов при функциональном проектировании может влечь за собой, например, выбор элемента актуатора из списка вариантов выбора, доступных через приложение для проектирования, и перетаскивание выбранного элемента актуатора на рабочую область приложения для проектирования. Пользователь также может задавать для элемента актуатора идентификационные данные (например, название: MAIN MOTOR, серийный номер: SCH90045) и назначать его функциональной группе (например, группа: G_CONVEYORBELT). Пользователь может создавать диагностические элементы 906A, 906B и задавать для каждого идентификационные данные (например, название: MAIN MOTOR ALARM1, серийный номер SCH70100) и назначать каждый функциональной группе (например, группа: G_CONVEYORBELT). Пользователь также может создавать элемент 908 управления и задавать для него идентификационные данные (например, название: MAIN MOTOR CONTROL SWITCH, серийный номер SCH6099) и назначать его группе (например, группа: G_CONVEYORBELT). Пользователь может соединять эти элементы между собой (например, посредством рисования линий подключения), приводя к функциональному виду 901, проиллюстрированному на фиг. 9B. В этом виде элемент 908 управления (например, коммутатор) может использоваться человеком для того, чтобы включать/отключать элемент 904 актуатора (например, электромотор), который запускает/останавливает транспортерную ленту 902. Дополнительно, диагностический элемент 906B (например, датчик) может подсчитывать число комплектов на транспортерной ленте 902. И в завершение, диагностический элемент 906A (например, диагностическая лампочка), соединенный с элементом 904 актуатора, может указывать проблему посредством переключения с зеленого на красный цвет.

[00157] С учетом вида 901 подключений на основе функций, проиллюстрированного на фиг. 9B, SDA-система может предлагать другие элементы, требуемые для того, чтобы создавать и разворачивать транспортерную ленту, как проиллюстрировано на фиг. 9A. Например, SDA-система может предлагать группу 912 пользователей (например, для управления, обслуживания и администрирования приложений) (название: CONVEYOR BELT PERSONNEL PC, группа: G_CONVEYORBELT), резервированный контроллер 914 приложений (название: CONVEYOR BELT PLC, серийный номер: SCH10001, группа: G_CONVEYORBELT), контроллер 916 актуатора (название: CONVEYOR BELT MOTOR CONTROLLER, серийный номер: SCH30077, группа: G_CONVEYORBELT) и диагностический контроллер 918 (название: MAIN ALARM CONTROLLER, серийный номер: SCH40066, группа: G_CONVEYORBELT). В некоторых вариантах осуществления SDA-система может осуществлять эти предложения на основе информации, предоставленной пользователем, и информации относительно правил и ассоциирований, пользовательских профилей, профилей устройств и т.п., сохраненной в одной или более баз данных. Например, когда пользователь выбирает электромотор, SDA-система может автоматически извлекать каталог контроллеров электромотора и предлагать контроллер электромотора, который удовлетворяет пользовательским/проектным критериям. Правила и ассоциирования в некоторых вариантах осуществления могут извлекаться или распознаваться из предыдущих проектных решений и/или указываться для каждого промышленного приложения. SDA-система также может предлагать оптимальные возможности подключения через один или более промышленных протоколов, как проиллюстрировано. Фиг. 9C иллюстрирует вид 903 возможностей подключения на основе трафика, иллюстрирующий оптимальные возможности подключения между PC 912, резервированными контроллерами 914 приложений, контроллером 916 актуатора, диагностическим контроллером 918 с использованием EIP- и MB/TCP-протоколов. В некоторых вариантах осуществления SDA-система может предлагать оптимальные возможности подключения на основе такой информации, как характеристика устройства, число/тип портов, правила и т.п.

[00158] После соединения активов и различных контроллеров SDA-система вводит сетевой аспект. Информация из вида 901 подключений на основе функций и вида 903 возможностей подключения на основе трафика может служить в качестве ввода, чтобы формировать возможности физических подключений, как проиллюстрировано на фиг. 9D. Чтобы формировать возможности физических подключений, SDA-система (например, через ISDNA) может создавать экземпляр сетевых элементов, таких как DNS-сервер 926 и маршрутизаторы 928. SDA-система (например, через ISDNA) также может предлагать сетевую топологию (например, резервированную физическую топологию). В некоторых вариантах осуществления SDA-система может предлагать возможности физических подключений и сетевую топологию на основе характеристик выбранных устройств, затрат, правил и/или других критериев. SDA-система затем может соединять сетевые элементы в топологии (например, контурной или ячеистой) в зависимости от затрат и/или других критериев. Результирующий вид 907 возможностей физических подключений иллюстрирует три маршрутизатора, соединенные в ячеистой топологии.

[00159] При подтверждении предложенных возможностей физических подключений SDA-система (например, через ISDNA) может предлагать возможности логических подключений. Возможности логических подключений могут интегрироваться с признаками кибербезопасности и политиками, такими как изоляция логических единиц (например, изоляция диагностики от управления), брандмауэры и т.д. Возможности логических подключений также могут быть основаны на пользовательском вводе. Например, пользователь через промышленное приложение может запрашивать брандмауэр, DNS, NAT и виртуальный коммутатор на предмет того, чтобы сводить две VLAN вместе. Туманный контроллер может создавать экземпляр брандмауэра на туманном сервере и информировать ISDNA в отношении того, где находится брандмауэр (например, через IP-адрес), и принудительно активировать политику кибербезопасности, которая требует прохождения всего трафика через брандмауэр. Вид 909 возможностей логических подключений, проиллюстрированный на фиг. 9E, иллюстрирует две изолированных области управления VLAN1 для управления и VLAN2 для производства. Этот вид возможностей логических подключений является более простым в понимании, чем вид возможностей физических подключений.

[00160] В этот момент SDA-система (через ISDNA) может предлагать тракты связи на основе нагрузки, характеристик базовой инфраструктуры, чувствительности ко времени и любых определяемых пользователем критериев, тогда как базовая физическая инфраструктура полностью абстрагируется. Например, в виде 903 возможностей подключения на основе трафика, проиллюстрированном на фиг. 9C, контроллер 916 актуатора может обмениваться данными с резервированными контроллерами 914 приложений по EIP-протоколу. Аналогично, резервированные контроллеры 914 приложений могут обмениваться данными с диагностическим контроллером 918 по Modbus TCP (MB/TCP). На основе этой информации из вида возможностей подключения на основе трафика SDN-контроллер может подготавливать тракт из резервированных контроллеров 914 приложений в диагностический контроллер 918, который разрешает только MB/TCP-трафик. Таким образом, SDA-система обеспечивает совместимость с протоколами.

[00161] В этот момент интегрированное SDA/SDN-проектирование промышленных функций считается законченным. Фиг. 9F показывает функциональный 901, трафика 903, логический 909 и физический 907 виды возможностей подключения, соответствующие приложению для работы транспортерной ленты.

8. Функциональный вид промышленной SDN

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

Таблица 2. Группы персонала и интересующий сетевой аспект

Персонал	Интересующий сетевой аспект
Административный персонал	бизнес-состояние
Эксплуатационный персонал	текущее рабочее состояние промышленных функций
Персонал по техническому обслуживанию	диагностика проблем, расширение сети, отмена ввода в действие
Инженерно-технический персонал	проектирование сети, текущее состояние сети, статистические сетевые данные
Персонал службы безопасности	проектирование сети, текущее состояние сети, статистические сетевые данные с точки зрения сетевой безопасности

[00163] На основе этих групп персонала ISDNA может разделяться на пять сетевых видов или плоскостей, при этом каждый вид передает уровень информации, подходящий для интересов конкретной группы, как проиллюстрировано на функциональной схеме промышленной SDN по фиг. 10. На схеме, бизнес-вид 1011 направлен на административный персонал 1014, чтобы предоставлять возможность пользователю отслеживать влияние сетевых событий на бизнес. Функциональный вид 1001 возможностей подключения предназначен для рабочего персонала 1016, чтобы предоставлять возможность пользователю администрировать промышленные функции. Вид 1003 возможностей подключения на основе трафика предназначен как для персонала 1018 службы безопасности, так и для инженерно-технического персонала 1022, чтобы обеспечивать возможность пользователям администрировать политики связи, отслеживать использование, работоспособность связи и т.п. Вид 1009 возможностей логических подключений также предназначен для персонала 1018 службы безопасности и инженерно-технического персонала 1022, например, чтобы обеспечивать возможность пользователям администрировать возможности подключения и политики логической сегментации сети. В завершение, вид 1007 возможностей физических подключений предназначен для персонала 1018 службы безопасности, инженерно-технического персонала 1022 и персонала 1024 по техническому обслуживанию, чтобы обеспечивать возможность пользователям администрировать возможности и политики физических сетевых подключений.

9. Мониторинг и обслуживание рабочей промышленной SDN

[00164] После того, как подготовка и ввод в действие выполнены, рабочая промышленная сеть может отслеживаться, и различные действия могут предприниматься в ответ на данные мониторинга. В некоторых вариантах осуществления мониторинг может выполняться распределенно посредством различных компонентов рабочей промышленной SDN. Например, ссылаясь на фиг. 11A, SDN-контроллер 1155 в плоскости 1115 управления может включать в себя модуль 1155e сбора данных в качестве приложения 1155b. Модуль 1155e сбора данных, программируемый через ISDNA 1140, может задавать тракты через сеть, чтобы прослушивать то, что перенаправляют сетевые устройства в плоскости 1120 инфраструктуры. Например, если устройства A и B обмениваются данными через сетевой тракт, который имеет 10 коммутаторов. SDN-контроллер 1155 (через модуль 1155e сбора данных) может конфигурировать эти коммутаторы (например, каждый коммутатор или коммутаторы 3 и 10) с возможностью копировать пакеты, которые они принимают, и перенаправлять в агент 1127 сбора. Агент 1127 сбора в некоторых вариантах осуществления может представлять собой логически централизованное хранилище данных (т.е. может быть физически распределенным в некоторых случаях), которое представляет собой репозиторий для данных мониторинга, собранных из устройств в плоскости 1120 инфраструктуры. В конечном счете аналитическое приложение 1129 может принимать или извлекать данные мониторинга из агента 1127 сбора, чтобы выполнять различный анализ, включающий в себя анализ, требуемый для того, чтобы формировать конкретную для сетевого уровня информацию, применимую для пользователей, работающих на каждом сетевом уровне, подробно описанном ниже. Аналитическое приложение подробно описывается в отношении фиг. 13A.

[00165] В некоторых вариантах осуществления SDN-контроллер/ISDNA может отслеживать все уровни сети, от физического уровня до функционального уровня. Тем не менее, чистый объем информации, которая формируется и должна обрабатываться посредством системы, может быть ошеломительным, что может предотвращать своевременный ответ. Например, система может не иметь возможность проводить своевременную диагностику отказа (например, что случилось, или где возник отказ), если имеется громадный объем информации, которая должна обрабатываться. Кроме того, информация из мониторинга и обработки не обязательно является полезной для всех групп персонала. Например, рассмотрим сценарий, в котором водитель ударяется о столб, через который проходит кабель, что приводит к обрезке кабеля. В резервированной системе, производство не должно прекращаться, т.е. транспортерная лента продолжает работать. Для инженера информации "потеря возможностей подключения в порту 1" может быть достаточно. Тем не менее, эта информация может не иметь смысла для рабочего персонала или административного персонала, который может не видеть видимые знаки. В некоторых вариантах осуществления ISDNA может разрешать эту проблему посредством предоставления соответствующей подробности информации, индивидуально адаптированной к целевым группам персонала.

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

[00167] ISDNA имеет центральный вид сети и привязку по сетевым событиям, возникающим в сети. Ссылаясь на фиг. 11B, 11C и 11D, это означает то, что ISDNA отслеживает физический уровень, логический уровень, уровень трафика и функциональный уровень сети и может коррелировать сетевые события, возникающие на одном уровне, с изменениями на других уровнях.

[00168] В некоторых вариантах осуществления на физическом уровне 1109 ISDNA может:

- отслеживать статистику сети, такую как эффективность использования полосы пропускания в расчете на порт, использование полосы пропускания сети, пропускная способность и т.п.,

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

- определять физическое расстояние между устройствами (например, используемое в уравнениях визуализации и оценки материалов),

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

- отслеживать возможности сетевых подключений,

- отслеживать возможности физических подключений, такие как состояния каналов портов, скорость соединения и т.п.,

- отслеживать возможности логических подключений,

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

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

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

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

- отслеживать статистику сети, такую как эффективность использования полосы пропускания, время отклика сети,

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

- отслеживать возможности сетевых логических подключений,

- создавать и отслеживать параметры соединения (например, LAG, скорость и направление соединения, резервирование)

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

- создавать и принудительно активировать логическую сегментацию сети

- создавать и принудительно активировать политики сетевого доступа

- отслеживать конфигурацию и работу сетевых технологий

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

[00171] ISDNA может коррелировать информацию, доступную на логическом уровне 1107, с информацией, распространяемой из физического уровня 1109, чтобы определять или формировать информацию 1121a вида возможностей логических подключений, релевантную для пользователей, работающих на этом уровне. Например, при условии, что сеть по фиг. 11B основана на кольцевой топологии, ISDNA может информировать инженерно-технический персонал и/или персонал службы безопасности касательно того, что системе требуется 20 мс для того, чтобы обнаруживать сетевое событие 1123a потери возможностей подключения на физическом уровне 1109, и переключаться на альтернативный тракт, который исключает затронутое сетевое устройство.

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

- отслеживать работоспособность и состояние в расчете на соединение,

- отслеживать статистику протокола, такую как PPS, время отклика сети,

- отслеживать объем и тип трафика, сформированного посредством устройств,

- обнаруживать трафик и характеристики устройств (см. приложение аналитики),

- создавать и принудительно активировать политики связи,

- распределенная передача (каждый канал связи принимает произвольный тракт через сеть),

- агрегированная передача (весь канал связи между двумя устройствами принимает конкретный тракт),

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

[00173] В примере по фиг. 11B ISDNA может предоставлять пользователям (например, инженерно-техническому персоналу и/или персоналу службы безопасности) информацию 1119a касательно того, что система работает при сниженном уровне отказоустойчивости (т.е. уровень отказоустойчивости или FTL упал с 1 из 0).

[00174] По мере того, как информация достигает функционального уровня 1101, интерпретация отказа может представлять собой простое предупреждение и состояние базовой сети. С точки зрения организации сетей для промышленной функции, ISDNA может:

- обнаруживать промышленные функции,

- администрировать промышленные функции: группировку, изоляцию, административное управление доступом к функциям,

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

- отслеживать возможности подключения,

- отслеживать работоспособность связи,

- отслеживать время отклика приложений,

- создавать и принудительно активировать политики связи,

- администрирование соединений на основе ART с использованием TSN,

- распространять сетевые события пользователям с соответствующей детальностью вида.

[00175] В примере по фиг. 11B ISDNA может предоставлять пользователям, работающим на этом уровне (например, эксплуатационному персоналу), рабочее предупреждение 1117a в отношении того, что сетевой отказ обнаружен на физическом уровне 1109, но приложение для работы транспортерной ленты по-прежнему выполняется.

[00176] В завершение, информация распространяется на бизнес-уровень 1111, который представляет объединенный вид всех базовых вопросов для того, чтобы формировать бизнес-перспективу (например, финансовые потери или выгоду), при этом бизнес-атрибуты назначаются отказу, полностью завершает вид. Другими словами, в этом высокоуровневом виде, вся доступная информация из всех четырех ISDNA-плоскостей объединяется, чтобы формировать финансовый или бизнес-образ промышленного процесса в псевдореальном времени. Неограничивающие примеры бизнес-атрибутов включают в себя: оцененное время простоя, затраты на ремонт и т.п.

[00177] С точки зрения организации сетей для бизнес-приложения ISDNA может предоставлять возможность пользователю, работающему на этом уровне:

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

- отслеживать эксплуатационные затраты и затраты на техническое обслуживание ресурсов с финансовой точки зрения,

- назначать значение затрат для сдерживающего фактора для производства.

[00178] В примере по фиг. 11B ISDNA может предоставлять пользователям, работающим на этом уровне (например, административному персоналу), затраты 1113a, ассоциированные с событием 1123a потери возможностей подключения на физическом уровне 1109. Например, в этом примере оцененные затраты на ремонт определяются как составляющие 300$ и могут быть основаны на следующем: затраты на персонал по техническому обслуживанию/час * отработанные часы (например, $100/час * 0,5 часа)+материальные затраты (например, 250$). Если, например, сетевое событие является достаточно серьезным для того, чтобы вызывать простой производства, то затраты или потери могут определяться следующим образом: число единиц, производимых в час * средняя прибыль в расчете на единицу * число часов простоя. Следует отметить, что эти вычисления затрат являются примерами. Затраты или потери, ассоциированные с сетевым событием, могут вычисляться любым числом способов на основе бизнес-атрибутов, таких как, но не только: оцененное время простоя, затраты на ремонт и т.п.

[00179] Фиг. 11C является блок-схемой, иллюстрирующей второй пример распространения сетевых отказов через различные сетевые уровни рабочей промышленной SDN, сконфигурированной в ячеистой топологии в соответствии с некоторыми вариантами осуществления. Когда кабель извлекается из устройства, сетевое событие 1123b потери возможностей подключения возникает на физическом уровне 1109. Информация относительно этого сетевого события может коррелироваться с другой информацией, доступной на этом уровне, чтобы информировать пользователя, работающего на этом уровне, в отношении того, что порт 1 простаивает вследствие события потери возможностей подключения (1123b). Информация из этого уровня может распространяться на следующий логический уровень 1107, причем информация из физического уровня 1109 может коррелироваться с информацией, доступной на этом уровне, чтобы информировать пользователя, работающего на этом уровне, в отношении того, что возникают потери на резервирование, и система может восстанавливаться в течение 20 мс (1121b). Информация, доступная на логическом уровне, затем может распространяться на уровень 1103 трафика, на котором принимаемая информация коррелируется с доступной информацией, чтобы информировать пользователя, работающего на уровне, в отношении того, что система имеет сниженный уровень отказоустойчивости с уровнем отказоустойчивости по сравнению с 10 трактами в 1 (1119b). На функциональном уровне 1101, информация, распространяемая из уровня 1103 трафика, коррелируется с доступной информацией, чтобы формировать предупреждение оператору в отношении того, что сетевой отказ с низким уровнем серьезности обнаружен на физическом уровне (1117b). На бизнес-уровне 1111, на котором информация из всех уровней объединяется, пользователю могут предоставляться финансовые затраты (1113b) сетевого отказа на физическом уровне. Например, затраты могут составлять 0$, если запланировано, что система должна работать со сниженным уровнем отказоустойчивости (например, согласно проектному решению, не предпринимать действий до тех пор, пока FTL не упадет до 5). Альтернативно, если система спроектирована специально с возможностью работать с FTL в 10 (т.е. FTL менее 10 может вызывать увеличение перегрузки, что оказывает влияние на производство), то возникают финансовые затраты, ассоциированные с сетевым событием, чтобы инструктировать персоналу техобслуживания находить поврежденное устройство и подключать кабель (например, 300$).

[00180] Фиг. 11D является блок-схемой, иллюстрирующей третий пример распространения сетевых отказов через различные сетевые уровни рабочей промышленной SDN в соответствии с некоторыми вариантами осуществления. Как и в случае фиг. 11B и 11C, сетевое событие, обнаруженное на одном уровне, распространяется через другие уровни полностью на бизнес-уровень 1117 и коррелируется с информацией, доступной на каждом уровне, чтобы формировать, на каждом уровне, конкретную для уровня информацию сетевых событий, применимую для пользователей, работающих на этом уровне. В этом примере, сетевое событие, связанное с активацией порта (1123c), может обнаруживаться на физическом уровне 1109. Альтернативно, сетевое событие, связанное с нерегулярным шаблоном (1119c) трафика из устройства, может обнаруживаться на уровне 1103 трафика. Оба сетевых события служат признаком неавторизованного проникновения или кибератаки. В некоторых вариантах осуществления SDN-контроллер может быть сконфигурирован через ISDNA, чтобы реализовывать подготовленный план обеспечения безопасности в случае неавторизованного проникновения. Такой план может влечь за собой, например, маршрутизацию трафика из подозрительного устройства в поддельную сеть (ловушку системы безопасности или приманку) и в силу этого изоляцию проникновения от фактической сети. Если план обеспечения безопасности успешно активирован, ISDNA может транслировать это сетевое событие (1119c или 1123c) в конкретную для логического уровня информацию сети, которая информирует пользователя, работающего на логическом уровне 1107, в отношении того что сетевое событие обработано путем активации плана (1121c) обеспечения безопасности. В некоторых случаях, кибератака может обрабатываться посредством деактивации порта, ассоциированного с сетевым событием, причем в этом случае конкретная для логического уровня информация сети должна сообщать пользователю в отношении означенного. Аналогично, ISDNA может транслировать идентичное сетевое событие в конкретную для функционального уровня информацию сети, чтобы информировать пользователя, работающего на функциональном уровне 1101, в отношении того, что система работает нормально, но имеется неавторизованная активность (1117c). Альтернативно, может быть возможным то, что неавторизованное проникновение вызывает некоторые временные функциональные потери до того, как исправительные меры вступают в силу. В таком случае пользователь может информироваться в отношении того, что система работает нормально после временных функциональных потерь (1117c). В завершение, на бизнес-уровне 1111 ISDNA может определять затраты (1113c) неавторизованной активности. В этом примере затраты могут составлять любую сумму от 100$ до 100000$ (т.е. от минимальных до существенных потерь). Например, если неавторизованная активность обусловлена осуществлением доступа пользователем к авторизованному веб-узлу с PC, затраты на информирование пользователя касательно политик являются минимальными. Тем не менее, если неавторизованная активность обусловлена PC, зараженным вредоносными программами, вся сеть может останавливаться либо должна переводиться в оффлайн, чтобы разрешать проблему.

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

[00182] Следует отметить, что сетевое событие может представлять собой любое событие, возникающее в сети, которое вызывается или допускает вызывание изменения в сети. Изменение может быть неблагоприятным или непреднамеренным либо положительным или предназначенным. Потеря возможностей подключения и кибератака представляют собой только примеры сетевого события. Другие события, такие как, но не только: сбой сетевого устройства, обнаружение неизвестного/ненужного трафика и т.п., также представляют собой сетевые события. Эти сетевые события могут способствовать общему ухудшению качества в системе и должны иметь ассоциированные затраты на бизнес-уровне. Непосредственно сбой сетевого устройства может быть обусловлен различными причинами. Например, один тип сбоя сетевого устройства может не проявляться в потере возможностей подключения на физическом уровне, но он сбоит на уровне перенаправления и может представлять собой реакционное событие в ответ на потерю связи на других поврежденных устройствах. Другой тип сбоя сетевого устройства может быть связан с неуправляемой повторной передачей кадров посредством сетевого устройства. Еще один другой тип сбоя сети может быть связан с обнаружением ненужного трафика в специальных областях сети (например, вследствие интерпретации отказавшей сети/SDN-политики). Сбой сетевого устройства также может быть связан с сетевым устройством, которое не может применять запрашиваемую SDN-политику, или с сетевым устройством, которое является частично рабочим и перенаправляет трафик в ранее сконфигурированной политике, но которое более не является доступным для SDN-контроллера. Пример сетевого события, которое приводит к положительному или намеченному изменению сети, представляет собой момент, когда устройство успешно авторизуется на то, чтобы участвовать в сети.

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

10. Завод в качестве услуги

[00184] Типичный процесс строительства завода представляет собой работы, которые являются не только дорогими, но также и длительными. Когда завод построен, он типично работает в течение многих лет до тех пор, пока он не сталкивается с некоторыми сложностями. Например, другая технологическая линия должна добавляться, пространство завода является слишком небольшим, завод должен перемещаться в другое место и т.д. Безотносительно причины, строительство идентичного/аналогичного завода в другом месте является непростым и обычно требует привлечения помощи извне, чтобы начинать с нуля. Кроме того, различная информация, такая как списки оборудования, технические требования, приложения, протоколы и т.д., должна собираться, чтобы помогать в работах по строительству нового завода. Промышленная SDN-архитектура, описанная в данном документе, использует завод в качестве модели предоставления услуг, чтобы обеспечивать простую операцию цепочечного копирования и вставки, что приводит к проектированию завода на основе сцепления промышленных функций. Интеллектное сцепление или комплектование может возникать на всех уровнях промышленного приложения с проектом для уменьшения OPEX и CAPEX посредством многократного использования инфраструктуры и логической изоляции связи.

[00185] Рассмотрим пример процесса создания приложений для работы транспортерной ленты, описанный в отношении фиг. 9A-9F. Этот процесс формирует SDA-функцию, которая может интеллектно сцепляться с другой, так что формируется производственную группу. Создание технологического объекта из абстрактных промышленных функций упоминается как "завод в качестве услуги". Фиг. 12 иллюстрирует SDA-завод в качестве услуги, при которой молоко перерабатывается в мороженое и упаковывается и помещается на грузовик для доставки. Предположим, что первый завод (группа 1) включает в себя упаковочную функцию 1204A (например, приложение для работы транспортерной ленты), которая сцепляется с другой, чтобы формировать производственную группу 1206A. SDA-система имеет всю информацию относительно функционального уровня, уровня трафика, логического уровня и физического уровня первого заводского приложения, сохраненную в одном или более хранилищ данных. В некоторых вариантах осуществления, например, каждая из SDA-функций может сохраняться в форме шаблона. В других вариантах осуществления весь завод, содержащий SDA-функции, сцепляемые вместе, может сохраняться в форме шаблона. Когда второй завод должен создаваться (группа 2), пользователь может просто перетаскивать значок завода или функциональные значки и сцеплять их вместе в приложении для проектирования. Если, например, доступны более новые/улучшенные контроллеры, операция замены может выполняться, чтобы обновлять или модифицировать шаблоны. SDA-система затем может автоматически формировать базовый трафик, виды возможностей физических логических подключений, подготавливать необходимые сетевые тракты, вводить в действие инфраструктурные и промышленные устройства и т.д., с тем чтобы создавать полностью работающий завод. В некоторых вариантах осуществления SDA-система может предлагать режим моделирования в дополнение к реальному режиму. В режиме моделирования, SDA-функция представляет собой виртуальную SDA-функцию (например, 1204, 1206), в которой все промышленные и сетевые устройства представляют собой виртуализированные устройства, хостящиеся на туманном сервере или в распределенном вычислительном окружении 1202. SDA-система затем может использовать виртуальные SDA-функции для того, чтобы моделировать весь промышленный процесс. Данные из моделирования затем могут использоваться для моделирования, могут использоваться для проектирования, последовательной подготовки и ввода в действие, увеличения срока службы, тестирования в период обслуживания, оптимизации технологических объектов и т.д. В некоторых вариантах осуществления данные для моделирования могут использоваться для того, чтобы оценивать CAPEX (капитальные расходы) и OPEX (эксплуатационные расходы) на SDA-развертывание.

11. Аналитическое приложение в промышленной SDN

[00186] Фиг. 13A является блок-схемой, иллюстрирующей примерные компоненты аналитического приложения 1329 в промышленной SDN. Аналитическое приложение 1329 может представлять собой виртуализированное (например, на туманном сервере или во внешнем облаке) либо может собой физическое аппаратное устройство (например, с мощными вычислительными возможностями). Аналитическое приложение 1329 может осуществлять доступ к данным мониторинга из логически централизованного агента 1327 сбора и выполнять различный анализ в реальном времени или в псевдореальном времени. Только в качестве примера, а не в качестве ограничения, аналитика может использоваться для того, чтобы:

- обнаруживать и администрировать проблемы перегрузки (целостный сетевой балансировщик в реальном времени, комбинирующий реальные и виртуальные сети),

- обнаруживать присутствие устройств (профилирование устройств на основе шаблонов связи),

- подтверждать эффективность правил и политик (обнаружение и администрирование нежелательного трафика и разрешенного трафика),

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

- отслеживать работоспособность связи (обнаружение/измерение дрожания фазы),

- предоставлять статистику по промышленным функциям и сетевое профилирование (аналитику в реальном времени в качестве ART-измерения, обнаружения времени восстановления после отказов)

I. Примерный случай: Перегрузка

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

[00188] Модуль 1304 администрирования перегрузки аналитического приложения 1329 может реализовывать примерное решение по администрированию перегрузки, которое включает в себя компоновку точной карты всех объектов (например, датчиков, машин и компьютеров) на интерактивном веб-узле, при этом линии показывают то, как каждый объект соединяется с другим. Примерная карта, проиллюстрированная на фиг. 13B, иллюстрирует представление в реальном времени того, что происходит точно в этот момент. На примерной карте, сплошные одиночные линии иллюстрируют положительную связь между объектами, сплошные сдвоенные линии иллюстрируют рабочие соединения, которые не используются в данный момент, и пунктирные линии иллюстрируют связь, которая не функционирует корректно.

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

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

II. Примерный случай: обнаружение устройств

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

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

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

III. Примерный случай использования: использование сети

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

[00195] Организации типично имеют веб-узлы, которые заблокированы вследствие контента. Тем не менее, пользователи по-прежнему могут попытаться осуществлять доступ к этим веб-узлам или другим веб-узлам, которые не помещены в список запрета. При попытке доступа к этим веб-узлам предупреждение может отправляться сетевому администратору или другому персоналу, чтобы бдительно следить за сетью. Это обеспечивает возможность организации поддерживать безопасную сеть.

[00196] В некоторых вариантах осуществления может реализовываться технология, которая обеспечивает использование цифровых отпечатков для веб-узлов. Могут быть предусмотрены различные цифровые отпечатки для веб-узлов и даже несколько цифровых отпечатков для веб-узлов внутри веб-узлов. Например, Gmail и Google Drive могут иметь различные цифровые отпечатки. Аналитика может собираться по этим цифровым отпечаткам и анализироваться, чтобы видеть то, что делают люди, и когда люди осуществляют доступ к этим веб-узлам. Например, анализ по использованию средств социального общения может использоваться для того, чтобы формировать образ, который представляет приложения, к которым осуществляется доступ в сети. Чем больше пузырьки, тем интенсивнее к ним осуществляется доступ. Это представляет собой реализацию предписывающей, прогнозирующей, диагностической и описательной аналитики, поскольку она комбинирует статистические данные с данными в реальном времени, чтобы анализировать то, что пошло не так, как надо (или так, как надо), и решать то, что делать в будущем, чтобы иметь лучший результат.

IV. Примерный случай использования: статистические данные

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

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

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

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

V. Примерный случай использования: связь

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

VI. Примерный случай использования: данные в реальном времени

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

VII. Примерный случай использования: замены

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

[00204] В некоторых вариантах осуществления модуль 1318 администрирования замен может реализовывать экспоненциально снижающуюся функцию плотности распределения вероятностей (PDF). Экспоненциальные функции могут предоставлять модели для описания случайных переменных (например, сроков службы лампочек и множества видов электронных компонентов). Экспоненциальные функции также могут использоваться для того, чтобы моделировать количество времени до тех пор, пока некоторое конкретное событие не возникнет. Большинство продуктов имеет гарантию в конкретное количество лет, например, гарантия в двадцать лет, как проиллюстрировано на фиг. 13D. Приблизительно через двадцать лет, производительность должна начинать падать, и посредством использования экспоненциальной функции плотности, организация может определять то, когда продукт с наибольшей вероятностью станет ненужным, и она может преимущественно заменять его. При использовании примера в двадцать лет предусмотрен огромный объем доступных вычислений. Таблица, проиллюстрированная на фиг. 13E, показывает некоторые вычисления. Вероятность того, что продукт перестает работать до года 20, составляет 36%, тогда как вероятность того, что он будет служить между годами 20 и 30, составляет 14% и т.д. Эти данные могут использоваться для того, чтобы оценивать выгоды и потери посредством упреждающей замены продукта в определенном году, или просто позволять продукту изнашиваться, с возможным прерыванием всего процесса и результирующим полным потерям. Посредством проверки статистических графиков временной шкалы, организации могут решать, когда наилучшее время для того, чтобы заменять продукт, чтобы нарушать весь процесс в наименьшей степени.

12. Примерные способы

[00205] Ниже описываются различные примерные способы, реализованные в промышленной SDN, имеющей архитектуру, описанную на фиг. 5A-C.

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

[00207] На этапе 1404 ISDNA может координироваться с SDN-контроллером, с которым оно сопрягается через контроллерный SDN-агент, чтобы определять тракт связи между первым и вторым промышленными устройствами. Тракт связи может определяться на основе, по меньшей мере, одного определяемого пользователем критерия связи на этапе 1404a. Например, если промышленная SDN-сеть содержит сетевые устройства A, B, C, D, E и F, тракт связи может исключать сетевое устройство C и D вследствие того, что они уже обрабатывают интенсивный трафик, и вместо этого выбирать сетевой тракт через устройства A, B, E и F.

[00208] На этапе 1406 SDN-контроллер взаимодействует с одним или более сетевых устройств, чтобы задавать тракт связи, чтобы обеспечивать связь между первым промышленным устройством и вторым промышленным устройством. Взаимодействие с сетевыми устройствами может включать в себя программирование сетевых устройств, например, с возможностью устанавливать или обновлять правила обработки пакетов (или таблицу потоков). Это обеспечивает возможность каждому сетевому устройству в тракте связи сопоставлять пакеты с правилами обработки пакетов и выполнять определенные указанные действия. В некоторых вариантах осуществления тракт связи (или сетевой тракт) может проходить через виртуализированное сетевое устройство. Таким образом, тракт связи может содержать реальные или виртуализированные сетевые устройства на этапе 1406a. Например, из сетевых устройств A, B, E и F из вышеприведенного примера, сетевое устройство B может представлять собой виртуализированное сетевое устройство.

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

[00210] В примерном способе SDN-контроллер может обнаруживать присутствие нового промышленного устройства в промышленной SDN на этапе 1502. Присутствие нового промышленного устройства в промышленной сети может обнаруживаться посредством программно-определяемого сетевого (SDN) контроллера, когда сетевое устройство в промышленной сети не имеет правил для обработки сообщения из нового промышленного устройства. В таком случае сообщение перенаправляется в SDN-контроллер. На этапе 1504 сообщение из нового промышленного устройства может маршрутизироваться в услугу аутентификации, которая может определять то, авторизовано или нет новое промышленное устройство на то, чтобы участвовать в промышленной сети. В некоторых вариантах осуществления маршрутизация сообщения в услугу аутентификации может выполняться в ответ на определение, посредством контроллера кибербезопасности, того, что, по меньшей мере, одна политика кибербезопасности является применимой к новому промышленному устройству, и такая политика кибербезопасности может требовать того, что новое промышленное устройство должно быть аутентифицировано посредством услуги аутентификации. SDN-контроллер затем может подготавливать сетевой тракт из нового промышленного устройства в услугу аутентификации, с тем чтобы обеспечивать возможность маршрутизации следующего сообщения из нового промышленного устройства в услугу аутентификации. Если новое промышленное устройство определяется как неавторизованное на то, чтобы участвовать в промышленной SDN на этапе 1506 принятия решения, процесс подготовки прекращается на этапе 1508. Новое промышленное устройство в таком случае не должно иметь возможность обмениваться данными с другими промышленными устройствами в сети. Тем не менее, если новое промышленное устройство успешно аутентифицируется, способ переходит к 1510, на котором могут определяться атрибуты нового промышленного устройства и его промышленная функция.

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

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

[00213] В некоторых вариантах осуществления событие отмены ввода в действие может обнаруживаться. Если такое событие обнаруживается на этапе 1516 принятия решения, SDN-контроллер может отменять ввод в действие сетевого тракта на этапе 1518 и затем предоставлять новый сетевой тракт из нового промышленного устройства в ресурс на этапе 1514. Неограничивающие примеры события отмены ввода в действие могут включать в себя: пользовательскую инструкцию, обновление политики кибербезопасности, автоматическое обнаружение отказа вдоль сетевого тракта, обнаружение возможности повторно оптимизировать сетевой тракт, изменение характеристик нагрузки, изменение качества обслуживания, сетевое событие и т.п. Если событие отмены ввода в действие не обнаруживается на 1516, действие может не предприниматься на этапе 1520.

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

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

[00216] В различных вариантах осуществления услуга сетевого уровня может включать в себя, но не только обеспечение возможностей подключения, по меньшей мере, между некоторыми из множества компонентов плоскости данных, услугу обеспечения кибербезопасности, балансировщик нагрузки и анализатор трафика. Может создаваться экземпляр услуги сетевого уровня по запросу с использованием виртуализации сетевых функций на этапе 1606 в некоторых вариантах осуществления. ISDNA может координироваться с SDN-контроллером и контроллером администрирования виртуализации, чтобы создавать экземпляр услуги сетевого уровня по запросу с использованием виртуализации сетевых функций. В других вариантах осуществления, может создаваться экземпляр услуги сетевого уровня по запросу с использованием сцепления функций предоставления услуг на этапе 1608, которое соединяет, по меньшей мере, две услуги сетевого уровня, чтобы реализовывать одну или более политик кибербезопасности, отрегулированных посредством контроллера кибербезопасности. ISDNA может координироваться, по меньшей мере, с SDN-контроллером и контроллером кибербезопасности, чтобы создавать экземпляр услуги сетевого уровня с использованием сцепления функций предоставления услуг. Некоторые неограничивающие примеры услуги сетевого уровня могут включать в себя виртуальный брандмауэр, глубокий анализ пакетов (DPI), балансировщики нагрузки, анализаторы трафика, NAT, прокси-услуги, маршрутизацию и т.п.

[00217] Фиг. 17 является логической блок-схемой последовательности операций, иллюстрирующей примерный способ для централизованного мониторинга и формирования сообщений рабочей промышленной сети. Рабочая промышленная сеть представляет собой SDN, развернутую в промышленной области, и содержит физический уровень, логический уровень, уровень трафика, функциональный уровень и бизнес-уровень. В некоторых вариантах осуществления ISDNA, которое имеет централизованный вид рабочей промышленной сети, может собирать и обрабатывать информацию сетевых событий на каждом уровне рабочей промышленной сети на этапе 1702. Например, ISDNA отслеживает текущее состояние рабочей промышленной сети и выполняет этапы сбора и обработки, распространения, формирования и предоставления. В некоторых вариантах осуществления информация сетевых событий ассоциирована с сетевым событием, обнаруженным на уровне посредством ISDNA. Примеры включают в себя, но не только: потерю возможностей подключения на физическом уровне рабочей промышленной сети или неавторизованный доступ к рабочей промышленной сети.

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

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

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

13. Дополнительные варианты осуществления

[00221] Ниже приводится список дополнительных вариантов осуществления на основе промышленной SDN-архитектуры и/или SDA-системы, развернутой с промышленной SDN-архитектурой в соответствии с настоящим раскрытием сущности.

Вариант 1 осуществления. Архитектура промышленной сети для централизованного и упрощенного администрирования промышленной сети, содержащая:

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

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

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

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

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

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

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

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

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

Вариант 7 осуществления. Архитектура промышленной сети по варианту 6 осуществления, в которой ISDNA включает в себя агент устройства для того, чтобы сопрягаться с унаследованными сетевыми устройствами в плоскости инфраструктуры.

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

Вариант 9 осуществления. Архитектура промышленной сети по варианту 8 осуществления, в которой защищенная и явная подготовка включает в себя:

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

- определение атрибутов устройства;

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

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

Вариант 10 осуществления. Архитектура промышленной сети по варианту 9 осуществления, в которой атрибуты устройства включают в себя тип устройства, характеристики устройств и промышленную функцию устройства.

Вариант 11 осуществления. Система для централизованного администрирования промышленной сети, содержащая:

- компонент плоскости платформы, предоставляющий интерфейс с промышленным приложением, причем компонент плоскости платформы включает в себя промышленное программно-определяемое сетевое приложение (ISDNA);

- компонент плоскости управления, соединенный с компонентом плоскости платформы через интерфейс прикладного программирования, причем компонент плоскости управления соединяется с другими компонентами плоскости управления, при этом компонент плоскости управления включает в себя программно-определяемый сетевой (SDN) контроллер, и другие компоненты плоскости управления включают в себя контроллер администрирования виртуализации и контроллер кибербезопасности; и

- при этом в ответ на ввод из промышленного приложения, ISDNA в координации, по меньшей мере, с SDN-контроллером создает экземпляр по запросу одной или более услуг сетевого уровня в промышленной сети.

Вариант 12 осуществления. Система по варианту 11 осуществления, дополнительно содержащая:

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

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

Вариант 14 осуществления. Система по варианту 12 осуществления, в которой каждый из компонентов плоскости управления представляет собой логически централизованный объект, выполняемый в распределенном вычислительном окружении.

Вариант 15 осуществления. Система по варианту 11 осуществления, в которой одна или более услуг сетевого уровня включают в себя услугу обеспечения кибербезопасности, балансировщик нагрузки или анализатор трафика.

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

Вариант 17 осуществления. Система по варианту 16 осуществления, в которой создается экземпляр одной или более услуг сетевого уровня посредством ISDNA в координации с SDN-контроллером и контроллером администрирования виртуализации.

Вариант 18 осуществления. Система по варианту 11 осуществления, в которой создается экземпляр одной или более услуг сетевого уровня посредством ISDNA в координации, по меньшей мере, с SDN-контроллером и контроллером кибербезопасности.

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

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

Вариант 21 осуществления. Система по варианту 11 осуществления, в которой создание экземпляра по запросу одной или более услуг сетевого уровня в промышленной сети включает в себя координацию между ISDNP, SDN-контроллером, контроллером администрирования виртуализации и контроллером кибербезопасности.

Вариант 22 осуществления. Способ для упрощения развертывания и обслуживания сетевой инфраструктуры в промышленной области, содержащий:

- прием, посредством промышленного программно-определяемого сетевого приложения (ISDNA), по меньшей мере, одного определяемого пользователем критерия связи для развертывания автоматизированной системы, причем определяемые пользователем критерии связи принимаются из промышленного приложения, при этом развертывание автоматизированной системы включает в себя, по меньшей мере, первое промышленное устройство и второе промышленное устройство, соединенные с промышленной программно-определяемой сетью (SDN);

- координирование с SDN-контроллером, чтобы определять тракт связи между первым промышленным устройством и вторым промышленным устройством развертывания автоматизированной системы, причем тракт связи определяется на основе, по меньшей мере, одного определяемого пользователем критерия связи; и

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

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

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

Вариант 25 осуществления. Способ по варианту 22 осуществления, в котором ISDNA сопрягается с SDN-контроллером через контроллерный SDN-агент.

Вариант 26 осуществления. Способ для упрощения администрирования промышленной сети, содержащий:

- обнаружение присутствия нового промышленного устройства в промышленной сети;

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

- определение атрибутов нового промышленного устройства и его промышленной функции;

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

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

Вариант 27 осуществления. Способ по варианту 26 осуществления, в котором присутствие нового промышленного устройства в промышленной сети обнаруживается посредством программно-определяемого сетевого (SDN) контроллера, когда сетевое устройство в промышленной сети не имеет правил для обработки сообщения из нового промышленного устройства.

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

Вариант 29 осуществления. Способ по варианту 28 осуществления, дополнительно содержащий подготовку, посредством программно-определяемого сетевого (SDN) контроллера, сетевого тракта из нового промышленного устройства в услугу аутентификации.

Вариант 30 осуществления. Способ по варианту 26 осуществления, в котором, по меньшей мере, один ресурс, требуемый посредством нового промышленного устройства, включает в себя одно или более других промышленных устройств, соединенных с промышленной сетью или внешним устройством хранения.

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

Вариант 32 осуществления. Способ по варианту 26 осуществления, в котором сетевой тракт подготавливается на основе, по меньшей мере, одного определяемого пользователем критерия.

Вариант 33 осуществления. Способ по варианту 32 осуществления, в котором определяемые пользователем критерии включают в себя требование по качеству обслуживания, нагрузку, характеристики сетевых устройств или требование по чувствительности ко времени.

Вариант 34 осуществления. Способ по варианту 26 осуществления, дополнительно содержащий, в ответ на событие отмены ввода в действие, отмену ввода в действие сетевого тракта из нового промышленного устройства, по меньшей мере, в один ресурс.

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

Вариант 36 осуществления. Способ для централизованного администрирования промышленной сети, содержащий:

- прием инструкции из промышленного приложения в плоскости приложений, причем промышленное приложение сопрягается с промышленным программно-определяемым сетевым приложением (ISDNA) в плоскости платформы через интерфейс прикладного программирования, доступный посредством ISDNA;

- в ответ на ввод из промышленного приложения, создание экземпляра по запросу одной или более услуг сетевого уровня в промышленной сети, при этом создание экземпляра выполняется посредством ISDNA в координации, по меньшей мере, с программно-определяемым сетевым (SDN) контроллером в плоскости управления, при этом плоскость платформы функционально соединена с плоскостью управления через интерфейс прикладного программирования, и при этом плоскость управления дополнительно содержит контроллер администрирования виртуализации и контроллер кибербезопасности.

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

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

Вариант 39 осуществления. Способ по варианту 36 осуществления, в котором одна или более услуг сетевого уровня включают в себя услугу обеспечения кибербезопасности, балансировщик нагрузки или анализатор трафика.

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

Вариант 41 осуществления. Способ по варианту 36 осуществления, в котором создается экземпляр одной или более услуг сетевого уровня посредством ISDNA в координации с SDN-контроллером и контроллером администрирования виртуализации.

Вариант 42 осуществления. Способ по варианту 36 осуществления, в котором создается экземпляр одной или более услуг сетевого уровня посредством ISDNA в координации, по меньшей мере, с SDN-контроллером и контроллером кибербезопасности.

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

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

Вариант 45 осуществления. Способ по варианту 36 осуществления, в котором создание экземпляра по запросу одной или более услуг сетевого уровня в промышленной сети включает в себя координацию между ISDNP, SDN-контроллером, контроллером администрирования виртуализации и контроллером кибербезопасности.

Вариант 46 осуществления. Способ по варианту 36 осуществления, в котором каждый из контроллеров в плоскости управления представляет собой логически централизованный объект, выполняемый в распределенном вычислительном окружении.

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

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

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

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

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

Вариант 48 осуществления. Способ по варианту 47 осуществления, в котором рабочая промышленная сеть содержит физический уровень, логический уровень, уровень трафика, функциональный уровень и бизнес-уровень.

Вариант 49 осуществления. Способ по варианту 48 осуществления, в котором:

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

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

- функциональный уровень ассоциирован с пользователями из группы рабочих пользователей,

- бизнес-уровень ассоциирован с пользователями из группы административных пользователей.

Вариант 50 осуществления. Способ по варианту 47 осуществления, в котором рабочая промышленная сеть представляет собой программно-определяемую промышленную сеть (SDN), развернутую в промышленной области.

Вариант 51 осуществления. Способ по варианту 50 осуществления, в котором рабочая промышленная сеть содержит промышленное программно-определяемое сетевое приложение (ISDNA), сопрягаемое с SDN-контроллером, при этом ISDNA отслеживает текущее состояние рабочей промышленной сети и выполняет этапы сбора и обработки, распространения, формирования и предоставления.

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

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

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

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

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

Вариант 57 осуществления. Способ варианту 51 осуществления, в котором информация сетевых событий ассоциирована с сетевым событием, обнаруженным на уровне посредством ISDNA.

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

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

- принимать, посредством промышленного программно-определяемого сетевого приложения (ISDNA), по меньшей мере, один определяемый пользователем критерий связи для развертывания автоматизированной системы, причем определяемые пользователем критерии связи принимаются из промышленного приложения, при этом развертывание автоматизированной системы включает в себя, по меньшей мере, первое промышленное устройство и второе промышленное устройство, соединенные с промышленной программно-определяемой сетью (SDN);

- координироваться с SDN-контроллером, чтобы определять тракт связи между первым промышленным устройством и вторым промышленным устройством развертывания автоматизированной системы, причем тракт связи определяется на основе, по меньшей мере, одного определяемого пользователем критерия связи; и

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

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

- обнаружение присутствия нового промышленного устройства в промышленной сети;

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

- определение атрибутов нового промышленного устройства и его промышленной функции;

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

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

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

- прием инструкции из промышленного приложения в плоскости приложений, причем промышленное приложение сопрягается с промышленным программно-определяемым сетевым приложением (ISDNA) в плоскости платформы через интерфейс прикладного программирования, доступный посредством ISDNA;

- в ответ на ввод из промышленного приложения, создание экземпляра по запросу одной или более услуг сетевого уровня в промышленной сети, при этом создание экземпляра выполняется посредством ISDNA в координации, по меньшей мере, с программно-определяемым сетевым (SDN) контроллером в плоскости управления, при этом плоскость платформы функционально соединена с плоскостью управления через интерфейс прикладного программирования, и при этом плоскость управления дополнительно содержит контроллер администрирования виртуализации и контроллер кибербезопасности.

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

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

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

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

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

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

[00222] Фиг. 18 является блок-схемой примерной машины/компьютера/устройства, которое может выполнять различные операции и сохранять различную информацию, сформированную и/или используемую посредством таких операций в соответствии с некоторыми вариантами осуществления. Компьютер 1800 предназначен иллюстрировать аппаратное устройство, в котором могут реализовываться любые из объектов, компонентов или услуг, проиллюстрированных в примерах фиг. 1A-13A (и любые другие компоненты, описанные в этом подробном описании), и технологий, описанных в примерах фиг. 14-17, таких как сервер, клиентские устройства, вычислительные узлы, контроллерные узлы, такие как туманный контроллер (335, 435, 550, 750, 850), сетевой контроллер (например, 456), SDN-контроллер (например, 555, 755a, 755, 855, 1155), CS-контроллер (например, 445, 560, 860), устройства/узлы хранения, базы данных, промышленные устройства (например, PLC, PAC), сетевые устройства и т.п. Компьютер 1800 включает в себя один или более процессоров 1805 и запоминающее устройство 1810, соединенные с межкомпонентным соединением. Межкомпонентное соединение может представлять любую одну или более отдельных физических шин, соединений "точка-точка" или и то, и другое, соединенных посредством соответствующих мостов, адаптеров или контроллеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Архитектура промышленной сети по п. 3, в которой ISDNA, услуга администрирования виртуализации и услуга обеспечения кибербезопасности плоскости платформы соединены с сетевым контроллером, контроллером администрирования виртуализации и контроллером кибербезопасности плоскости управления, соответственно.

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

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

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

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

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

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

- определение атрибутов устройства;

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

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

10. Архитектура промышленной сети по п. 9, в которой атрибуты устройства включают в себя тип устройства, характеристики устройств и промышленную функцию устройства.

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

- принимают, посредством промышленного программно-определяемого сетевого приложения (ISDNA), по меньшей мере, один определяемый пользователем критерий связи для развертывания автоматизированной системы, причем определяемые пользователем критерии связи принимаются из промышленного приложения, при этом развертывание автоматизированной системы включает в себя, по меньшей мере, первое промышленное устройство и второе промышленное устройство, соединенные с промышленной программно-определяемой сетью (SDN);

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

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

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

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

14. Способ по п. 11, в котором ISDNA сопрягается с SDN-контроллером через контроллерный SDN-агент.

15. Способ для упрощения администрирования промышленной сети, содержащий этапы, на которых:

- обнаруживают присутствие нового промышленного устройства в промышленной сети;

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

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

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

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

16. Способ по п. 15, в котором присутствие нового промышленного устройства в промышленной сети обнаруживают посредством программно-определяемого сетевого (SDN) контроллера, когда сетевое устройство в промышленной сети не имеет правил для обработки сообщения из нового промышленного устройства.

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

18. Способ по п. 17, дополнительно содержащий этап, на котором подготавливают, посредством программно-определяемого сетевого (SDN) контроллера, сетевой тракт из нового промышленного устройства в услугу аутентификации.

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

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

21. Способ по п. 15, в котором сетевой тракт подготавливают на основе, по меньшей мере, одного определяемого пользователем критерия.

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

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

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