Способ и система для предоставления прокси-услуги в промышленной системе - RU2744562C2

Чертежи

Показать все 11 чертежа(ей)

Описание

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

Данная заявка притязает на приоритет и выгоду следующих предварительных заявок на патент: (1) предварительной заявки на патент серийный номер № 62/348770, называемой "Software-Defined Automation", поданной 10 июня 2016 года, (2) предварительной заявки на патент серийный номер № 62/354683, называемой "Software-Defined Automation Architecture", поданной 24 июня 2016 года, (3) предварительной заявки на патент серийный номер № 62/354799, называемой "Software-Defined Automation Architecture", поданной 26 июня 2016 года, и (4) предварительной заявки на патент серийный номер № 62/406932, называемой "Software Defined Automation System and Architecture", поданной 11 октября 2016 года. Все содержимое вышеуказанных заявок на патент явно содержится по ссылке в данном документе.

Область техники, к которой относится изобретение

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

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

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

Системы управления производственным процессом содержат устройства с отсутствующими или ограниченными характеристиками обработки либо с базовыми или отсутствующими услугами. Например, некоторые устройства могут поддерживать только собственные протоколы (Modbus TCP, EtherNet/IP). Другие устройства могут не допускать предоставление высокопроизводительных веб-страниц.

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

Сущность изобретения

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

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

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

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

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

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

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

Фиг. 4 является блок-схемой последовательности операций, иллюстрирующей пример способа для предоставления прокси-услуг в системе по фиг. 3.

Фиг. 5 является блок-схемой последовательности операций способа, подробнее иллюстрирующей пример по фиг. 4.

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

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

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

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

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

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

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

Имеется потребность в том, чтобы обеспечивать возможность базовым устройствам со слабыми характеристиками принимать участие в обеспечении/предоставлении высокоуровневых задач и услуг. Это может достигаться посредством введения прокси-услуг. Тем не менее, промышленное окружение представляет собой IP-центрическую систему, что означает то, что протоколы связи базируются для адресации на конкретном IP-адресе. Следовательно, нельзя основываться на прокси-решениях предшествующего уровня техники, реализующих службы разрешения имен, таких как DNS и WINS. Это обусловлено тем, что промышленные протоколы связи не обеспечивают возможность отклонения пакета или запроса услуги на адрес, отличный от адреса, явно указанного в качестве целевого адреса.

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

В различных вариантах осуществления системы поставщика прокси-услуг, сетевой контроллер может быть выполнен с возможностью перенаправлять поток связи в зависимости от критериев, отличающихся от IP-адреса, таких как тип протокола, тип запроса услуги, тип источника, подфункции протокола, тип необязательных команд, дополнительные SNMP MIB, альтернативные или дополненные веб-страницы, контент данных. Таким образом, прокси-устройство может устанавливаться/конфигурироваться с возможностью обрабатывать связь от имени целевого устройства, которое фактически адресовано. Такое прокси-устройство называется "узлом предоставления прокси-услуг". Альтернативно, если обобщить, называется "механизмом предоставления прокси-услуг", который может содержать один или более узлов предоставления прокси-услуг, которые могут распределяться по SDA-системе.

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

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

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

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

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

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

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

Фиг. 1 является схемой, иллюстрирующей упрощенную архитектуру SDA-системы в соответствии с некоторыми вариантами осуществления. Архитектура иллюстрирует туманный сервер 105, связанный с системным программным обеспечением 140, и соединенные интеллектуальные устройства 115A, 115B, которые функционально соединяются с туманным сервером 105 и системным программным обеспечением через магистраль 110 связи. Архитектура также иллюстрирует то, что, по меньшей мере, некоторые соединенные интеллектуальные устройства 115B и туманный сервер 105 могут функционально соединяться с облаком 150.

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

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

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

В некоторых вариантах осуществления, соединенные интеллектуальные устройства 115B могут полностью или частично выполняться на одном или более серверов (например, на сервере 135, туманном сервере 105). Например, соединенное интеллектуальное устройство 115B может реагировать на удаленные сигналы (например, удаленные вызовы методов, вызовы через интерфейс прикладного программирования, или API-вызовы), как если приложение выполняется локально, когда фактически приложение выполняется удаленно, например, на туманном сервере 105. В некоторых вариантах осуществления, соединенные интеллектуальные устройства могут захватывать данные в реальном времени относительно собственного состояния и состояния своего окружения (например, устройств, которые они отслеживают) и отправлять такие данные на туманный сервер 105 и/или удаленное облако 150. В некоторых вариантах осуществления, соединенные интеллектуальные устройства 115A, 115B могут преобразовывать захваченные данные в реальном времени в информацию (например, аварийные сигналы), сохранять их и выполнять оперативную аналитику для них. Соединенные интеллектуальные устройства 115A, 115B затем могут комбинировать функции отслеживания и управления, описанные выше, чтобы оптимизировать собственное поведение и состояние.

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

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

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

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

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

SDA-система содержит различные подсистемы, которые взаимодействуют, чтобы предоставлять полностью интегрированное решение для создания, управления и работы с автоматизированными системами. Фиг. 2 является блок-схемой, иллюстрирующей подсистемы SDA-системы в соответствии с некоторыми вариантами осуществления. SDA-система 100 в некоторых вариантах осуществления включает в себя туманную серверную подсистему 205 ("туманный сервер"), имеющую туманный контроллер или резервированные туманные контроллеры 210, один или более вычислительных узлов 215 и хранилище 225. SDA-система 200 также включает в себя подсистему 230 программных компонентов. В других вариантах осуществления, SDA-система дополнительно может включать в себя подсистему 250 кибербезопасности (CS), имеющую контроллер безопасности или резервированные контроллеры 255 безопасности, виртуализированные и/или физические компоненты 260 системы безопасности и репозиторий 265 политик безопасности. В еще одних других вариантах осуществления, SDA-система также может включать в себя сетевую подсистему 270, имеющую сетевой контроллер или резервированные сетевые контроллеры 290, физическую сеть 280, физические сетевые компоненты 282, виртуальные сети 220, виртуальные сетевые компоненты 222 и репозиторий 285 сетевых политик.

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

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

Туманный серверный контроллер 210 управляет всеми аспектами среды виртуализации и полным жизненным циклом вычислительных узлов 215. Например, туманный сервер 205 может занимать и освобождать хосты, такие как виртуальные машины, контейнеры или платформы без программного обеспечения на вычислительных узлах, и создавать и уничтожать виртуализированные компоненты 245 и виртуальные сети 220. Виртуализированный компонент/элемент/экземпляр 245, при использовании в данном документе, представляет собой логический эквивалент физического устройства или части физического устройства, которое он представляет, реализованный в качестве программного объекта, который должен выполняться внутри туманного сервера 205. Виртуализированные компоненты 245 также могут включать в себя программные компоненты, такие как приложения и/или прикладные функции на хосте (например, виртуальная машина, сконфигурированная с приложением, представляет собой виртуализированный компонент/элемент/экземпляр).

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

Подсистема 230 программных компонентов может включать в себя виртуализированные компоненты 245, хостинг которых выполняется посредством экосистемы виртуализации туманного сервера 205. Подсистема 230 программных компонентов также может включать в себя виртуализированные экземпляры программного обеспечения 235, которые выполняются в среде виртуализации (например, программного обеспечения для программирования, конфигурирования и/или управления (например, Unity, SoMachine, SCADA), которое используется для того, чтобы программировать, конфигурировать, управлять или иным образом взаимодействовать с автоматизированными устройствами. В некоторых вариантах осуществления, подсистема 230 программных компонентов также может включать в себя системное программное обеспечение 240 (также называемое порталом автоматизации), которое предоставляет один интерфейс для управления топологией, инвентаризацией, конфигурированием, программированием, контролем и/или диагностикой автоматизированных устройств и/или автоматизированной системы в целом.

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

Подсистема 250 кибербезопасности (CS) включает в себя ассоциированный CS-контроллер или резервированные CS-контроллеры 255 и виртуализированные и/или физические компоненты 260 системы безопасности. Подсистема 250 безопасности предоставляет целостное решение по кибербезопасности через политики безопасности и компоненты системы безопасности, такие как системы обнаружения/защиты от проникновений, виртуализированные брандмауэры следующего поколения, центр сертификации и системы идентификации и т.п. CS-контроллер 255 распределяет политики безопасности в виртуализированные и/или физические компоненты для того, чтобы обеспечивать то, что необходимая защита для обеспечения безопасности вводится в действие. В некоторых вариантах осуществления, CS-подсистема также может предоставлять политику безопасности и услуги аутентификации в другие компоненты и подсистемы. Политики безопасности CS-системы 250 могут сохраняться в репозитории 265 политик безопасности в некоторых вариантах осуществления.

Сетевая подсистема 270 включает в себя сетевую Ethernet-инфраструктуру для всего решения на основе SDA-системы. В некоторых вариантах осуществления, сетевая подсистема 270 представляет собой сетевую SDN-подсистему, имеющую SDN-контроллер или резервированные SDN-контроллеры в качестве сетевого контроллера 290. SDN-сеть предоставляет отделение управляющей логики сети от базовых сетевых аппаратных средств (например, маршрутизаторов, коммутаторов) и логическую централизацию управления сетью через SDN-контроллер. Это означает то, что SDN-контроллер может распределять сетевые политики по всей сетевой инфраструктуре (т.е. физической сети 280 и физическим сетевым компонентам 282, а также виртуальным сетям 220 и виртуальным сетевым компонентам 222), чтобы управлять возможностями подключения, полосой пропускания и временем задержки, соглашениями об уровне обслуживания (SLA) (например, в ответ на: детерминированное время ответа/время передачи), управление потоком трафика и т.д., и сетевые аппаратные средства могут реализовывать эти политики. Сетевые политики сетевой подсистемы 270 могут сохраняться в репозитории 685 сетевых политик в некоторых вариантах осуществления.

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

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

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

Ссылаясь на фиг. 3, показана примерная система согласно некоторым вариантам осуществления. Система 300 включает в себя инструментальное средство 302 приложения, программно-определяемую сеть 304 (SDN), имеющую сетевой контроллерный узел 390, механизм 306 предоставления прокси-услуг, содержащий узлы 306a-306n предоставления прокси-услуг, физические устройства 308a-308m и виртуальные устройства 312a-312p.

Инструментальное средство 302 приложения обеспечивает возможность оператору или другому пользователю взаимодействовать с системой 300 и обеспечивает управление и конфигурирование системы 300. Инструментальное средство 302 приложения может быть частью или быть доступным через портал автоматизации или системное программное обеспечение 240. Сетевой контроллерный узел 390 оркеструет, конфигурирует и предоставляет связь в системе 300 между различными устройствами и компонентами по программно-определяемой сети 304.

Различные физические устройства 308a-308m могут присутствовать в системе 300, в зависимости от типа машины или завода, который автоматизируется/управляется. Аналогично, система может использовать различные виртуальные устройства 312a-312p для того, чтобы выполнять одну или более функций автоматизации для хостов, работающих на вычислительных узлах на туманном сервере 305. Механизм 306 предоставления прокси-услуг может содержать один или более узлов 306a-306n предоставления прокси-услуг, из которых каждый может быть адресуемым посредством сетевого контроллерного узла 390. В различных вариантах осуществления, механизм 306 предоставления прокси-услуг может размещаться на туманном сервере 305. В других вариантах осуществления, он может размещаться в отдельном компьютерном ресурсе, вычислительном узле, PLC или другом устройстве управления либо в любом другом ресурсе, предоставляющем характеристики обработки. Кроме того, механизм предоставления прокси-услуг может распределяться по любому из вышеуказанных элементов.

Ссылаясь на фиг. 4, проиллюстрирован пример способа для предоставления прокси-услуги. В дальнейшем способ поясняется в отношении примера системы 300 по фиг. 3. Из инструментального средства 302 приложения, услуга запрашивается 402. Сетевой контроллерный узел 390 направляет 404 входящий запрос услуги в по меньшей мере один узел 306a-306n предоставления прокси-услуг. Это направление 404 запроса услуги основано на наборе правил. По меньшей мере, один узел 306a-306n предоставления прокси-услуг обрабатывает 406 запрос услуги и доставляет 408 запрашиваемую услугу (т.е. доставляет ответ на запрос услуги).

Правила, присутствующие в наборе правил, могут задаваться заранее посредством инструментального средства приложения и/или могут переконфигурироваться в ходе работы. Набор правил может включать в себя назначение, т.е. целевые адреса для физических автоматизированных устройств (например, физических устройств 308a-m), виртуальных автоматизированных устройств (например, виртуального устройства 312a-p) и узлов предоставления прокси-услуг (например, узлов 306a-n предоставления прокси-услуг). Набор правил дополнительно может включать в себя привязки предварительно определенных критериев и каждого целевого адреса. Таким образом, один критерий или комбинация нескольких критериев вместе могут быть привязаны к конкретному адресу назначения. Предварительно определенные критерии могут включать в себя, но не только: IP-адрес, контент пакетов, контент сообщений, тип протокола, тип запроса услуги, тип устройства, тип источника или комбинации вышеозначенного. Другие критерии могут включать в себя подфункции протокола, тип необязательных команд, дополнительные SNMP MIB, альтернативные или дополненные веб-страницы и/или контент данных. Необязательные команды должны представлять собой команды, доступные, например, в пределах протокола, но не обязательно поддерживаемые посредством унаследованного устройства.

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

Обращаясь к фиг. 5, подробнее проиллюстрирован способ по фиг. 4. В данном документе, направление 402 запроса услуги может содержать определение 504 целевого адреса в соответствии с набором правил и маршрутизацию 506 запроса услуги на определенный целевой адрес.

Способ, проиллюстрированный на фиг. 5, подробнее показывает, что обработка 404 запроса услуги может включать в себя разложение или разбор 508 запроса услуги, агрегирование 510 результатов, требуемых для того, чтобы отвечать на запрос услуги, и компилирование 512 запрашиваемого ответа по предоставлению услуг.

Как показано на фиг. 6, разложение 508 запроса услуги может включать в себя разбиение 604 запроса услуги на один или более подзапросов или задач, которые должны обрабатываться посредством узлов предоставления прокси-услуг и/или одного или более физических автоматизированных устройств, и/или одного или более виртуальных автоматизированных устройств. Запрос услуги может указывать присутствие задач, которые могут обрабатываться отдельно, например, когда они выбраны оператором через инструментальное средство приложения из списка задач, доступных из SDA-системы, чтобы предоставлять комбинированные услуги. Помимо этого, либо когда такой индикатор не присутствует, механизм предоставления прокси-услуг может быть выполнен с возможностью идентифицировать задачи, требуемые для запрашиваемой услуги. Кроме того, разложение 508 запроса услуги дополнительно может включать в себя идентификацию 602 задач, перечисленных в наборе конфигураций услуг.

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

В некоторых вариантах осуществления, набор конфигураций услуг может перечислять задачи для обработки пакетов либо, если обобщить, для обработки потока связи для агрегирования диагностических данных и/или для ответа на запрос услуги. Он дополнительно может включать в себя перенаправление IP-адресованных пакетов в целевое автоматизированное устройство, идентифицированное посредством IP-адреса, для компилирования запрашиваемого ответа по предоставлению услуг, для доставки результатов компилированной услуги и/или для отслеживания идентификационных данных или онтологии, по меньшей мере, одного автоматизированного устройства. Набор конфигураций услуг может сохраняться и поддерживаться посредством механизма 306 предоставления прокси-услуг и быть доступным через инструментальное средство 302 приложения. Альтернативно, он может сохраняться и поддерживаться в любом другом подходящем местоположении, таком как инструментальное средство 302 приложения или сетевой контроллерный узел 390.

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

Пример 1. Модернизация унаследованного устройства с устаревшей функцией

В качестве примера варианта применения раскрытого способа, унаследованное устройство, которое требует обновления микропрограммного обеспечения, например, для того, чтобы разрешать риск нарушения безопасности или любую другую функциональность, может "виртуально модернизироваться". Кроме того, ссылаясь на фиг. 7, узел 706 предоставления прокси-услуг может быть выполнен с возможностью направлять модернизацию микропрограммного обеспечения или исправление программного обеспечения в виртуальное устройство 712. Виртуальное устройство 712, которое может выполняться на отдельном вычислительном узле на туманном сервере 705 или в механизме 706 предоставления прокси-услуг, в таком случае должно, вместо унаследованного устройства 708, устанавливаться с обновлением микропрограммного обеспечения или исправлением программного обеспечения. После установки, вся связь и/или запросы услуги, предназначенные для унаследованного устройства 708, должны направляться в виртуальное устройство 712. Это должно обеспечивать возможность виртуальной модернизации унаследованных устройств 708, которые не должны иметь возможность выполнять обновленное микропрограммное обеспечение, и даже обеспечивать возможность виртуальной модернизации унаследованных устройств, которые не спроектированы с возможностью получать модернизации. Другой пример функциональной модернизации может быть расширен на веб-услуги, к примеру, использование другого логотипа компании на веб-узле, представленном посредством унаследованного устройства. Дополнительные примеры функциональной модернизации могут включать в себя улучшения оформления и функциональности услуг, предоставленных посредством унаследованного устройства, такие как, например, графический пользовательский интерфейс (GUI), брендинг или другие интерфейсные элементы, представленные оператору.

Пример 2. Улучшение базового физического или виртуального устройства

В качестве другого примера варианта применения раскрытого способа, очевидно, что высокопроизводительные веб-страницы могут предоставляться посредством самого базового физического или виртуального устройства, тогда как фактически запрос услуги перехвачен и перенаправлен посредством SDN-контроллера в виртуальную прокси-услугу. Проксированная услуга должна использовать собственные протоколы фактического целевого устройства (Modbus TCP, EtherNet/IP, BacNet и т.п.) для того, чтобы собирать данные из устройства, с тем, чтобы конструировать запрашиваемый ответ по предоставлению веб-услуг. Например, ссылаясь на фиг. 8, зарядная станция для аккумулятора, которая заряжает аккумулятор через солнечную панель, оснащенную базовым счетчиком 808 электроэнергии, таким как счетчик силы света, может доставлять только текущее значение силы света. Узел 806 предоставления прокси-услуг затем должен агрегировать данные силы света во времени, и виртуальная веб-услуга 812, соединенная с облаком 816, должна доставлять местные прогнозы погоды. Эти потоки связи затем могут комбинироваться таким образом, чтобы не просто прогнозировать то, когда аккумулятор должен быть полностью заряжен, на основе мгновенного значения силы света, но учитывать прогноз погоды, чтобы прогнозировать скорость заряда и иметь улучшенное прогнозирование того, когда аккумулятор должен быть полностью заряжен.

Таким образом, запрос услуги из удаленного клиента 814 на предмет подробного индикатора относительно полной мощности должен направляться посредством сетевого контроллерного узла 890 в узел 806 предоставления прокси-услуг. Узел 806 предоставления прокси-услуг должен разбивать запрос услуги на подзапросы или задачи для извлечения агрегированных данных из счетчика 808 силы света и для извлечения прогноза погоды из веб-услуги 812. Ответы из этих распределенных задач затем компилируются и доставляются в качестве одной услуги или ответа в запросчик предоставления услуг.

В качестве другого примера улучшения базового физического устройства, может обеспечиваться поддержка диагностических запросов. Некоторые унаследованные устройства не поддерживают полный комплект сетевой диагностической информации. Тем не менее, сетевой контроллер и/или SDN-коммутаторы в сети могут извлекать большую часть этой информации посредством наблюдения трафика в и/или из устройства. Например, поскольку сетевой контроллер должен предусматриваться в создании и удалении сетевых соединений, таких как Modbus TCP-соединение, с устройством, сетевой контроллер может отслеживать существование этих соединений от имени унаследованного устройства. Затем SNMP-прокси-услуга или другая такая диагностическая услуга, может отвечать, от имени унаследованного устройства, на запросы существующих Modbus TCP-соединений посредством сбора информации из сетевого контроллера. Хотя пользователю очевидно, что устройство поддерживает перечень текущих Modbus TCP-соединений, в реальности, физическое устройство вообще не должно быть предусмотрено в запросе. Исходный запрос из диагностического клиента направляется посредством сетевого контроллера в SNMP-прокси-услугу. SNMP-прокси-услуга опрашивает диагностические данные сетевого контроллера, чтобы получать список текущих соединений с унаследованным устройством. После этого SNMP-прокси-услуга отвечает на запрос с подробной информацией соединения. В любом случае, физическое устройство не должно предусматриваться в транзакции на основе диагностического запроса.

Пример 3. Адресация несуществующего устройства через его IP-адрес

При дополнительном расширении принципа распределенной виртуализации, целевое устройство фактически может представлять собой распределение услуг, разбросанных по нескольким виртуальным объектам; фактическое устройство не существует не в каком-либо одном месте, а в нескольких местах в системе виртуализации (т.е. на туманном сервере) и/или в облаке. На деле, то, что очевидно из внешнего вида в качестве устройства с определенным набором характеристик, фактически представляет собой загадку. Услуги "целевого устройства" представляют собой абстрактную совокупность автономных услуг, которые совместно представляют некоторое конкретное требуемое поведение. Например, SysLog-услуга, которая регистрирует события, такие как вход в учетную запись/выход из учетной записи, функциональные изменения обработки, изменения состояния, к примеру, высокая/низкая скорость, завершение работы, ошибки и т.д. Кроме того, роевые технологии могут использоваться для того, чтобы направлять поведение совокупности автономных услуг с возможностью предоставлять уникальные характеристики. Например, может предоставляться услуга управления энергопотреблением, которая обеспечивает возможность завершения работы некритических функций.

Пример 4. Улучшение унаследованного устройства с несовместимым протоколом

Ссылаясь на фиг. 9, проиллюстрирована примерная система, которая включает в себя инструментальное средство 914 приложения, сетевой контроллерный узел 990, узел 906 предоставления прокси-услуг и унаследованное промышленное устройство 912 (например, PLC). PLC-устройство 912 оснащено только стеком протоколов для ModBus и не поддерживает IP/Ethernet. Чтобы улучшать связь с PLC-устройством 912, узел 906 предоставления прокси-услуг выполнен с возможностью включать в себя ModBus-реестр. Узел 906 предоставления прокси-услуг теперь имеет возможность транслировать любой объект ModBus-устройства в IP/Ethernet-адрес, во многом аналогично обычному DNS-серверу для Ethernet/IP. Таким образом, внутренне присущая функциональность PLC-устройства 912 расширяется за рамки его базовых характеристик.

Пример 5. Наращивание/снижение оборотов электромотора

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

Ссылаясь на фиг. 10, PLC 1014 выполнен с возможностью управления унаследованным приводом 1008 от электромотора. Привод 1008 от электромотора может управляться через команды для следующих поддерживаемых функций: "запуск", "остановка" и "заданная скорость". Следовательно, PLC 1014 может запрашивать (этап 1) любую из этих базовых поддерживаемых функций из привода 1008 от электромотора. Сетевой контроллер 1090, в качестве части SDN, должен направлять запрос (этап 2) в привод 1008 от электромотора. Помимо этого, PLC может запрашивать улучшенные функции (этап 3), которые непосредственно не поддерживаются посредством привода 1008 от электромотора. Кроме того, сетевой контроллер 1090 направляет (этап 4) запрос на предоставление улучшенных услуг в механизм 1006 предоставления прокси-услуг, который выполнен с возможностью предоставлять один или более улучшенных профилей 1006c привода. Улучшенный профиль 1006c привода выполнен с возможностью поддерживать конкретный профиль привода, который компонуется посредством использования поддерживаемых услуг унаследованного привода 1008 от электромотора: "запуск"/"остановка"/"заданная скорость". Улучшенный профиль привода может представлять собой профиль привода скорости с наращиванием/снижением оборотов, такой как линейное увеличение или снижение скорости или нелинейное увеличение или снижение скорости, такое как, например, ступенчато- или кусочно-соединенная кривая, либо он может включать в себя любой другой составной профиль привода. Механизм 1006 предоставления прокси-услуг упрощает связь (этап 5) между улучшенным профилем 1006c привода и приводом 1008 от электромотора. Таким образом, запрос услуги из PLC направляется через сетевой контроллер 1090 в механизм 1006 предоставления прокси-услуг, чтобы предоставлять поддержку улучшенных услуг.

По-прежнему ссылаясь на фиг. 10, механизм 1006 предоставления прокси-услуг включает в себя, в качестве дополнительных прокси-услуг, новый веб-сервер 1006a, SysLog 1006b и узел 1006N предоставления прокси-услуг. Прокси-услуга SysLog 1006b обеспечивает возможность регистрации событий, возникающих в механизме 1006 предоставления прокси-услуг и в приводе 1008 от электромотора. Привод 1008a от электромотора включает в себя старый веб-сервер, который в этом примере просто допускает показ текущего состояния привода от электромотора: "запущен", "остановлен" или "заданная скорость". Новый веб-сервер 1006a обеспечивает возможность дополнения старого веб-сервера 1008a, например, с состоянием привода от электромотора согласно улучшенному профилю привода. В качестве примера, текущий экземпляр в профиле привода, ход выполнения профиля привода и траектория прошлой и будущей скорости привода от электромотора.

Пример 6. Конфигурирование SDN-устройств для направления запросов услуги

Ссылаясь на фиг. 11, показан пример системы, в которой может реализовываться другой пример способа для предоставления прокси-услуг. В этом примере, подробнее конкретно представлен способ, которым сетевой контроллер компонует направление запросов услуги. Система включает в себя управляющее или интерфейсное устройство 1114, к примеру, приложение, клиент или PLC, которое может быть выполнен с возможностью управления и/или взаимодействия с одним или более устройств (не показаны), аналогично примеру по фиг. 10. Система дополнительно включает в себя механизм 1106 предоставления прокси-услуг, имеющий узлы 1106a-N предоставления прокси-услуг, размещенные аналогично примеру по фиг. 10. Сетевой контроллер 1190 управляет числом SDN-устройств 1191-1195, таких как коммутаторы, маршрутизаторы, шлюзы, в программно-определяемой сети 1104.

В этой системе, запрос услуги первоначально отправляется в сетевой контроллер 1190. Сетевой контроллер направляет запрос посредством определения целевого устройства и маршрутизирует запрос в целевое устройство, например, новый веб-сервер 1106a. В силу определения целевого устройства и маршрутизации в него для конкретного запроса, сетевой контроллер может обновлять набор правил и конфигурировать и/или программировать одно или более SDN-устройств для применения этого правила. Соответственно, когда новый запрос, предназначенный для идентичного целевого устройства, отправляется, запрос не должен обязательно перенаправляться в сетевой контроллер, а может перенаправляться посредством SDN-устройств 1191-1195 в целевое устройство непосредственно. Следовательно, способ для реализации прокси-услуг может включать в себя, посредством сетевого контроллера, конфигурирование SDN-устройств для маршрутизации запросов услуги.

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

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

Реферат

Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении возможности базовым устройствам со слабыми характеристиками принимать участие в предоставлении высокоуровневых задач и услуг. Способ предоставления прокси-услуги в промышленной системе содержит этапы, на которых предоставляют в промышленной системе, содержащей программно-определяемую сеть (SDN) с сетевым контроллерным узлом, механизм предоставления прокси-услуг, содержащий по меньшей мере один узел предоставления прокси-услуг; посредством сетевого контроллерного узла направляют входящий запрос услуги в по меньшей мере один узел предоставления прокси-услуг на основе набора правил; посредством по меньшей мере одного узла предоставления прокси-услуг обрабатывают запрос услуги; и доставляют запрашиваемую услугу. 2 н. и 12 з.п. ф-лы, 1 табл., 6 пр., 11 ил.

Формула