ПНСТ 420-2020. Предварительный национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей промышленный. Типовая архитектура

(утв. и введен в действие Приказом Росстандарта от 23.07.2020 № 29-пнст)

до 1 января 2024 года

Предисловие

1 РАЗРАБОТАН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Акционерным обществом «Российская венчурная компания» (АО «РВК»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 «Кибер-физические системы»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 23 июля 2020 г. № 29-пнст

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 121205 Москва, Инновационный центр Сколково, улица Нобеля, д. 1, e-mail: info@tc194.ru и/или в Федеральное агентство по техническому регулированию и метрологии: 109074, Москва, Китайгородский проезд, д. 7, стр. 1.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

Настоящий стандарт не ограничивается существующими технологиями и учитывает технологии на стадии испытаний.

1 Область применения

Настоящий стандарт определяет:

• типовую архитектуру для систем промышленного ИВ;
• структуру архитектуры промышленного ИВ, содержащую точки зрения на архитектуру и интересы системы для разработки, документирования и взаимодействия;
• точки зрения на бизнес, использование, функциональность и реализацию с учетом концепций по ГОСТ Р 57100.

2 Нормативные ссылки

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

ГОСТ Р 57100/ISO/IEC/IEEE 42010:2011 Системная и программная инженерия. Описание архитектуры

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ Р 57100, а также следующие термины с соответствующими определениями:

3.1 каркас архитектуры (architecture frame): Совокупность концепций и соглашений по задачам, заинтересованным сторонам, точкам зрения и типам модели.

3.2 архитектурное отображение (architecture presentation): Набор результатов применения каркаса архитектуры к конкретной или абстрактной системе в виде архитектурного представления и моделей.

3.3 типовая архитектура (reference architecture): Результат применения структуры архитектуры к классу систем для предоставления рекомендации и определения, анализа и решения общих важных архитектурных задач.

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

4 Сокращения

В настоящем стандарте применены следующие сокращения:

ICS — промышленная система управления (Industrial Control Systems);

RFID — радиочастотная идентификация (Radio Frequency Identification);

SDN — программно-определяемая сеть (Software Defined Network);

SLA — соглашение об уровне обслуживания (Service Level Agreement);

ИВ — интернет вещей (Internet of Things);

ИТ — информационные технологии (Information Technologies, IT);

ОТ — операционные технологии (Operation Technologies, OT);

ПИД — пропорционально-интегрально-дифференцирующие (proportional-integrative-derivative, PID).

5 Концепция типовой архитектуры промышленного Интернета вещей

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

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

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

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

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

6 Структура архитектуры промышленного Интернета вещей

6.1 Структура архитектуры

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

В структуре архитектуры промышленного ИВ использованы концепции ГОСТ Р 57100. Структура архитектуры определяет соглашения, принципы и практики для согласованного описания архитектуры. Стандартная структура архитектуры облегчает оценку, а также системное и эффективное решение задач заинтересованных сторон.

На рисунке 1 приведена концептуальная модель описания архитектуры по ГОСТ Р 57100. Цветные прямоугольники со сплошной заливкой добавлены к исходному рисунку, приведенному в ГОСТ Р 57100, для обозначения архитектурных конструкторов типовой архитектуры.

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

В основе описания архитектуры по ГОСТ Р 57100 лежат определенные точки зрения. Точка зрения включает в себя условности конструкции и анализ интересов системы и структурирует один интерес или более. Для каждой точки зрения определен один вид модели или более. Конструкции точек зрения и соответствующие заинтересованные стороны, интересы и виды моделей составляют каркас архитектуры.

Архитектурное представление выражает архитектуру рассматриваемой системы в соответствии с точкой зрения. Применение видов моделей для каждой точки зрения приводит к созданию архитектурных моделей. Совместно архитектурные представления и архитектурные модели составляют архитектурное отображение.

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

Каркас архитектуры и архитектурное отображение представлены на рисунке 2.

6.2 Структура архитектуры промышленного Интернета вещей

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

6.3 Типовая архитектура промышленного Интернета вещей

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

На рисунке 3 представлены конструкция и применение типовой архитектуры промышленного ИВ.

Типовая архитектура представляет собой уровень абстракции, который исключает архитектурные элементы, для оценивания которых требуются характеристики конкретной системы. Типовая архитектура адаптирует концепцию архитектуры по ГОСТ Р 57100 с двумя отличиями:

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

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

6.4 Точки зрения типовой архитектуры промышленного Интернета вещей

6.4.1 Общие положения

Точки зрения типовой архитектуры включают [2]:

• точку зрения на бизнес;
• точку зрения на использование;
• функциональную точку зрения;
• точку зрения на реализацию.

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

6.4.2 Точка зрения на бизнес

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

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

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

6.4.3 Точка зрения на использование

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

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

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

6.4.4 Функциональная точка зрения

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

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

Функциональная точка зрения подробно определена в разделе 9.

6.4.5 Точка зрения на реализацию

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

Точка зрения на реализацию представляет интерес для системных архитекторов, разработчиков, интеграторов и операторов системы.

Точка зрения на реализацию подробно определена в разделе 10.

6.5 Сквозные интересы и системные характеристики

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

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

Кроме того, существуют группы интересов системы, например связанные с безопасностью и защитой, которые требуют последовательного рассмотрения со всех точек зрения. Такие интересы именуют сквозными. Сквозные интересы часто связаны с производными свойствами системы, определяющимися не только компонентами системы, но и взаимодействием между ними. В контексте типовой архитектуры производные общесистемные свойства называются системными характеристиками. Системные характеристики — это свойства и поведение системы промышленного ИВ, обусловленные характеристиками подсистем и их взаимодействием друг с другом, контекстом и рабочей средой. Системные характеристики, как правило, имеют договорную стоимость для заинтересованных сторон системы, например наличие соглашения об уровне обслуживания (SLA).

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

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

Более подробные обсуждения сквозных интересов и системных характеристик, таких как безопасность и защита, а также понятие доверенности для решения вопросов безопасности, защищенности, надежности, способности к восстановлению и приватности приведены в [1], [3].

6.6 Учет жизненного цикла системы

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

7 Точка зрения на бизнес

Точка зрения на бизнес — это точка зрения на архитектуру, которая определяет видение, ценности и цели заинтересованных сторон в создании системы промышленного ИВ в ее деловом и нормативном контексте.

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

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

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

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

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

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

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

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

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

8 Точка зрения на использование

Точка зрения на использование — это точка зрения на ту архитектуру, которая отражает интересы системы, связанные с реализацией возможностей и структуры системы промышленного ИВ.

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

На рисунке 7 показаны основные понятия точки зрения на использование и их взаимосвязь.

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

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

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

Задача имеет роль, функциональную карту и карту реализации.

Под ролью понимается, если применимо, роль или роли, ответственная(ые) за выполнение задачи.

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

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

Примеры задач и ролей включают:

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

Действия — это конкретная координация задач для четко определенного использования или процесса системы промышленного ИВ. Действия могут быть выполнены в режиме повторения. Действия включают следующие элементы:

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

Примером действия является подключение устройства. Триггером является утверждение добавления в систему (роль — администратор). Производственный поток включает следующие последовательные задачи:

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

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

После проведения указанных действий в проекте системы промышленного ИВ имеется конкретное представление о действиях путем сопоставления задач с функциональными компонентами и компонентами реализации. Сопоставления позволяют проводить верификацию архитектуры и реализации.

9 Функциональная точка зрения

9.1 Базовая проблематика

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

Промышленный ИВ представляет собой соединение двух традиционно разных областей с разными целями, стандартами и дополнительными дисциплинами: информационные технологии (ИТ) и операционные технологии (ОТ).

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

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

Появление ИТ в мире ОТ связано с необходимостью объединения больших систем в сети, установления контроля над иерархиями машин и внедрения идей ИТ в ОТ (таких как планирование и оптимизация потребления ресурсов). Также произошел переход к элементам управления, которые моделируют физический мир в цифровой форме и основывают свои решения по управлению на имитационной модели, а не с использованием уравнения обратной связи, определяемого инженером по системам автоматизации. Это позволяет применять к ОТ такие технологии ИТ, как машинное обучение. Конвергенция ИТ и ОТ привела к тому, что системы ОТ стали восприимчивыми к проблемам ИТ, таким как атака и отказ в обслуживании в сети, а также вышеупомянутая проблема «заземления» символов.

Конвергенция ИТ и ОТ представляет собой познание, воплощенное в индустриальную систему. Возможно, это позволит уйти от проблемы «заземления» символов, так как индустриальная система будет базироваться на своем представлении о мире (а не на моделях, предоставляемых программистами) и на собственном опыте (не ограничиваясь человеческими представлениями). Ближайшие научно-технические достижения, которые поддерживают расширенную аналитику реальных данных, а не инженерные модели, могут привести к существенным улучшениям.

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

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

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

9.2 Функциональная точка зрения и функциональные домены

Функциональная точка зрения — это точка зрения на ту архитектуру, которая отражает интересы, связанные с функциональными возможностями и структурой системы промышленного ИВ и ее компонентов [2].

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

Настоящий стандарт устанавливает пять функциональных доменов типовой архитектуры:

• домен контроля;
• домен эксплуатации;
• информационный домен;
• домен приложения;
• бизнес-домен.

Потоки данных и потоки управляющих команд происходят внутри и между функциональными доменами. Рисунок 8 иллюстрирует движение потоков данных и потоков управляющих команд между функциональными доменами. Зеленые стрелки показывают движение потоков данных, красные — потоков управляющих команд. Другие стрелки обозначают входные потоки и генерирование новых форм потоков данных или потоков управляющих команд.

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

9.3 Домен контроля

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

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

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

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

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

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

Связь — это функция соединения датчиков, исполнительных устройств, контроллеров, шлюзов и других граничных систем. Механизмы связи имеют разные формы, такие как шина (локальная для базовой системной платформы или удаленная) или сетевая архитектура (иерархическая, звездообразная, ячеистая, двухточечная). Связь может быть настроена статически или динамически. Должны быть учтены такие характеристики качества обслуживания (QoS), как задержка, пропускная способность, джиттер, надежность и способность к восстановлению.

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

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

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

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

Управление активами обеспечивает управление эксплуатацией системы контроля, включая настройку системы, конфигурирование, политику, обновление системы, обновление ПО/встроенного ПО и другие операции управления жизненным циклом.

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

Исполнитель несет ответственность за применение политики сферы управления. Перемещение данных из сферы управления, использование исполнительных устройств и т.д. должны находиться в рамках политики сферы управления.

9.4 Домен эксплуатации

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

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

На рисунке 10 показана поддержка работы системы промышленного ИВ с помощью набора функций поддержки взаимозависимых операций.

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

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

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

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

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

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

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

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

9.5 Информационный домен

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

Примеры работы информационного домена:

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

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

Данные включают функции:

• для приема сенсорных данных и данных о рабочем состоянии из всех доменов;
• обработки качества данных (очистка данных, фильтрация, дедупликация и т.д.);
• синтаксического преобразования (например, нормализации формата и значений);
• семантического преобразования [семантическое назначение, внедрение контекста и другая обработка дополнения данных на основе метаданных (при предоставлении данных из домена эксплуатации) и другого набора данных для совместной работы];
• хранения данных (например, для пакетного анализа);
• распределения данных (например, для потоковой аналитической обработки).

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

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

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

Объем данных на системном уровне в большинстве систем промышленного ИВ в конечном итоге превысит объем данных в традиционных аналитических наборах инструментов и подходах. Могут быть использованы платформы хранения и анализа больших данных.

9.6 Домен приложений

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

Декомпозиция домена приложений показана на рисунке 11.

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

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

9.7 Бизнес-домен

Бизнес-домен — это функциональный домен для реализации бизнес-логики [2]. Бизнес-домен представляет собой бизнес-функции, поддерживающие бизнес-процессы и деятельности, которые должна интегрировать система промышленного ИВ для комплексной работы. Примеры бизнес-функций включают планирование ресурсов предприятия (ERP), управление взаимоотношениями с клиентами (CRM), управление жизненным циклом продукта (PLM), систему управления производством (MES), управление человеческими ресурсами (HRM), управление активами, управление жизненным циклом служб, счета и платежи, планирование работ и расписание.

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

9.8 Сквозные функции и системные характеристики

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

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

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

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

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

Взаимосвязь между функциональными доменами, сквозными функциями и основными системными характеристиками показана на рисунке 12.

и системные характеристики

9.9 Функциональные домены и вычислительные модели развертывания

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

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

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

С одной стороны, стали доступны возможности крупномасштабных вычислений с беспрецедентной масштабируемостью, удобством обслуживания, доступностью и эластичностью при низких затратах благодаря экономии масштаба в крупных центрах обработки данных, что привело к появлению облачных вычислений. Это стало возможным благодаря достижениям в технологиях виртуализации, в том числе в технологиях контейнеризации, инфраструктуры как служб (IaaS), платформы как службы (PaaS), ПО как службы (SaaS).

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

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

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

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

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

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

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

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

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

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

9.10 Роли человека при создании и эксплуатации системы промышленного Интернета вещей

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

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

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

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

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

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

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

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

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

10 Точка зрения на реализацию

10.1 Общие положения

Точка зрения на реализацию — это точка зрения на архитектуру, которая отражает интересы, связанные с реализацией возможностей и структуры системы промышленного ИВ.

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

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

Точка зрения на реализацию определяет:

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

- карту реализации основных системных характеристик.

10.2 Примеры архитектурных паттернов

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

В реализациях системы промышленного ИВ используют следующие архитектурные паттерны:

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

Архитектурный паттерн — это упрощенный и абстрактный вид реализации системы, повторяющийся во многих системах промышленного ИВ, но допускающий вариации. Например, реализация трехуровневого шаблона в системе не исключает нескольких реализаций каждого уровня, а также связи «многие ко многим» между экземплярами уровня и экземплярами следующего уровня. Каждый уровень и его соединения представляются в определении паттерна только один раз.

10.2.1 Трехуровневый паттерн архитектуры

Трехуровневый паттерн архитектуры включает в себя граничный уровень, уровень платформы и уровень предприятия. Уровни играют определенную роль в обработке потоков данных и потоков контроля, связанных с действиями по использованию. Они связаны тремя сетями, как показано на рисунке 13.

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

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

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

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

Уровни соединяются с помощью следующих сетей:

• сети ближнего действия, которые соединяют датчики, исполнительные устройства, устройства, системы контроля и активы, совместно именуемые граничными узлами. Сеть соединяет граничные узлы как один или несколько кластеров, связанных со шлюзом, который соединяется с другими сетями;
• сети доступа, которые обеспечивает подключаемость для потоков данных и управляющих команд между граничным уровнем и уровнем платформы. Сетью доступа может быть корпоративная сеть, оверлейная частная сеть через общедоступный Интернет или сеть 4G/5G;
• сети служб, которые обеспечивает подключаемость между службами уровня платформы и уровня предприятия, а также между службами внутри каждого уровня. Сетью служб может быть Интернет или оверлейная частная сеть через общедоступный Интернет, что обеспечивает корпоративный уровень безопасности между конечными пользователями и различными службами.

Паттерн трехуровневой архитектуры объединяет основные компоненты (например, платформы, службы управления, приложения), которые, как правило, отображаются в функциональные домены, как показано на рисунке 14 [4].

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

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

Потоки управления активами отправляются от компонента домена эксплуатации уровня платформы для управления активами на граничном уровне.

Компонент домена эксплуатации уровня платформы предоставляет службы (потоки служб управления активами) другим компонентам либо на том же уровне, либо на другом.

Компонент служб данных (информационный домен) уровня платформы может:

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

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

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

10.2.2 Паттерн архитектуры взаимодействия и управления посредством шлюза

Паттерн архитектуры взаимодействия и управления посредством шлюза содержит решение для локального подключения на границе системы промышленного ИВ с тем шлюзом, который соединяется с глобальной сетью, как показано на рисунке 15. Шлюз действует как оконечная точка для глобальной сети, изолируя локальную сеть от граничных узлов. Данный паттерн архитектуры позволяет локализовать операции и контроль (граничные аналитика и вычисления). Главное преимущество паттерна состоит в том, что можно снизить сложность систем промышленного ИВ для масштабирования по количеству управляемых активов и по сетям. Однако паттерн не подходит для систем с мобильными активами ввиду невозможности создавать стабильные кластеры в пределах локальной сети.

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

Локальная сеть может использовать различные топологии, как то:

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

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

Граничный шлюз поддерживает следующие возможности:

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

10.2.3 Паттерн многоуровневой шины данных

Многоуровневая шина данных обеспечивает безопасную одноранговую передачу данных с низкой задержкой по логическим уровням системы (см. рисунок 16). Многоуровневая шина данных эффективна для систем с прямым взаимодействием между приложениями.

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

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

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

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

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

Многоуровневая шина данных является применимой для домена эксплуатации для мониторинга, предоставления и управления устройствами, приложениями и подсистемами в системе.

Центральное место в шине данных занимает коммуникационная модель публикации-подписки, ориентированная на данные. Приложения «подписываются» на нужные им данные и «публикуют» производимую ими информацию. Логически сообщения передаются непосредственно между узлами связи. Модель связи подразумевает обнаружение — какие данные должны быть отправлены, и доставку — когда и куда их отправлять. Данная схема используется в срочных системах доставки информации в повседневной жизни, включая телевидение, радио, журналы и газеты. Системы публикации-подписки эффективны для быстрого распространения большого количества срочной информации, особенно при наличии ненадежных механизмов доставки.

Многоуровневая шина данных имеет следующие преимущества:

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

10.2.4 Паттерн системы систем

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

БИБЛИОГРАФИЯ

[1]	ISO/IEC DTR 30166 Internet of things (IoT) — Industrial IoT (Интернет вещей. Промышленный интернет вещей)
[2]	Гойхман В. Индустриальный Интернет вещей (понятия, архитектура, функциональные объекты). [Электронный ресурс] Режим доступа: https://www.tssonline.ru/articles/industrialnyj-internet-veshchej-ponyatiya-arhitektura-funkcionalnye-obekty
[3]	Industrial Internet Consortium: «Industrial Internet Security Framework Technical Document, version 1.0», 2016
[4]	Влацкая И.В., Пономарева Н.Н. Коммуникационный интерфейс для промышленного Интернета вещей. — Университетский комплекс как региональный центр образования, науки и культуры: материалы Всероссийской научно-методической конференции — Министерство образования и науки РФ, ФГБОУ ВО «Оренбургский государственный университет», 2018. — с. 1785 — 1788

УДК 004.738:006.354	ОКС 35.110, 35.020
Ключевые слова: информационные технологии, промышленный Интернет вещей, типовая архитектура

---