Промышленное производство
Промышленный Интернет вещей | Промышленные материалы | Техническое обслуживание и ремонт оборудования | Промышленное программирование |
home  MfgRobots >> Промышленное производство >  >> Industrial Internet of Things >> Интернет вещей

Связь с данными в эталонной архитектуре промышленного Интернета

Сегодня Консорциум промышленного Интернета (IIC) выпустил эталонную архитектуру промышленного Интернета (IIRA). IIC - крупнейший консорциум Интернета вещей (IoT), в который входит более 170 участников (iiconsortium.org). Что еще более важно, это единственный центр, ориентированный на промышленные системы. Первый публичный выпуск IIRA представляет собой формальный обзор архитектуры системы с точки зрения высокого уровня. Он охватывает все, от бизнес-целей до взаимодействия систем. Архитектура устанавливает множество ключевых технических рекомендаций. Крайне важно, что это также исключает многие подходы; архитектура - это то, чего вы не можете сделать, как и то, что можете.

Мы в Real-Time Innovations (RTI) больше всего восхищаемся одним ключевым аспектом:архитектурой связи IIRA. «Связь», или то, как вещи общаются, является одной из самых больших проблем для развивающегося промышленного Интернета вещей (IIoT). IIRA использует инновационный подход распределенной «базы данных», который упрощает взаимодействие, обеспечивая при этом максимальную производительность, надежность и безопасность.

Сила общей архитектуры

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

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

Это проблема «интероперабельности», и это действительно специализация RTI. RTI участвует в работе 15 различных стандартов и консорциумов. Они охватывают многие отрасли:военно-морские системы, авионику, энергетику, медицинские устройства, беспилотные автомобили, бытовую электронику, промышленное управление и широковещательное телевидение, и это лишь некоторые из них. Все сосредоточены на том, как заставить системы работать вместе. IIC опирается на опыт этих и других отраслей.

Проблема интеграции

Когда вы соединяете много разных систем, фундаментальной проблемой является проблема межсоединений «N в квадрате». Соединение двух систем требует согласования многих аспектов, включая протокол, модель данных, схему связи и параметры качества обслуживания (QoS), такие как надежность, скорость передачи данных или сроки. Хотя соединение двух систем является сложной задачей, ее можно решить с помощью специального «моста». Но не масштабируется; подключение N вместе требуется N -квадратные мосты. Как N становится большим, это становится непросто.

Один из способов решить эту проблему - оставить N маленьким. Вы можете сделать это, установив все стандарты и технологии для всех взаимодействующих систем. Многие отраслевые органы по стандартизации успешно идут по этому пути. Например, Европейская универсальная архитектура транспортных средств (GVA) определяет все аспекты создания военных наземных транспортных средств, от коннекторов низкого уровня до моделей данных верхнего уровня. Усилия German Industrie 4.0 предпринимаются аналогичным образом в обрабатывающей промышленности, делая выбор в отношении заказа и доставки, проектирования завода, технологий и планирования продукции. Допускается только один стандарт на задачу.

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

На другом конце спектра вы можете построить очень общую точку моста. Корпоративные веб-службы работают таким образом, используя «служебную шину предприятия» (ESB), такую ​​как Apache Camel. Однако, несмотря на «шину» в названии, ESB не является распределенной концепцией. Все системы должны подключаться к единой точке, где каждый входящий стандарт отображается в общий формат объекта. Поскольку все отображается в одном формате, ESB требует только «одностороннего» перевода, избегая N -квадратная задача. Например, Camel поддерживает сотни адаптеров, каждый из которых преобразует один протокол или источник данных.

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

Основной стандарт связи IIRA

IIRA использует промежуточный подход. В дизайне представлена ​​концепция «Базового стандарта подключения». В отличие от ESB, базовый стандарт представляет собой распределенную концепцию. Некоторые конечные точки могут напрямую подключаться к основному стандарту. Другие конечные точки и подсистемы подключаются через «шлюзы». Затем основной стандарт связывает их все вместе. Это позволяет использовать несколько протоколов без необходимости устанавливать мост между всеми возможными парами. Каждому нужен только один мост к ядру.

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

<рисунок>
Архитектура связи IIRA определяет безопасный «базовый стандарт связи» с контролируемым качеством обслуживания. Все остальные стандарты связи должны соответствовать только одному основному стандарту.

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

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

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

Безопасность также имеет решающее значение. Чтобы безопасность работала правильно, она должна быть тесно связана с архитектурой. Например, «базовый» стандарт может поддерживать различные шаблоны и возможности доставки. Дизайн защиты должен точно соответствовать им. Например, если подключение поддерживает публикацию / подписку, безопасность также должна быть. Если ядро ​​поддерживает многоадресную рассылку, то должна быть и безопасность. Если ядро ​​поддерживает динамическое обнаружение plug-n-play, то и безопасность должна быть. Безопасность, тесно связанная с архитектурой, может быть установлена ​​в любое время без изменения кода. Безопасность становится просто еще одним контролируемым качеством обслуживания, хотя и более сложным. Это очень мощная концепция.

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

DDS как основной стандарт

IIRA не определяет стандарты; IIC сделает этот шаг в следующем выпуске. Однако очевидно, что стандарт DDS (Data Distribution Service) отлично подходит для IIRA. DDS обеспечивает автоматическое обнаружение, каждый из шаблонов, указанных в IIRA, все настройки QoS и тщательно интегрированную безопасность.

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

[1] [2] 下一页

Интернет вещей

  1. Настоящая возможность - это промышленная возможность
  2. Четвертая промышленная революция
  3. Как промышленный Интернет меняет управление активами
  4. Четыре большие проблемы для промышленного Интернета вещей
  5. Интернет вещей:управление потоком данных
  6. Несбыточная мечта умной фабрики
  7. Защита промышленного Интернета вещей
  8. Раскрытие возможностей промышленного Интернета вещей
  9. Как промышленный Интернет вещей улучшает системы сжатого воздуха
  10. Технический документ:Smart Factory Connectivity for Industrial IoT