Практическая таксономия для систем Industrial Internet of Things (IIoT)

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

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

Системы Industrial Internet of Things (IIoT) так же разнообразны. Без сопоставимой таксономии архитекторы борются с выбором подходящих архитектур, протоколов и технологий.

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

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

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

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

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

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

Предложение таксономии IIoT

Надежность [Метрика: Непрерывная доступность должна быть лучше «99.999%»]

«Высоконадежное» — размытое обещание. Чтобы перевести надежность в архитектуру, спрашиваем: каковы последствия 5-минутного простоя в год? Промышленные системы часто не терпят даже миллисекунд простоя.

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

Реальное время [Метрика: Ответ < 100 мс]

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

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

Масштаб набора данных [Метрика: Размер набора данных > 10 000 элементов]

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

Масштаб команды или приложения [Метрика: Количество команд или взаимодействующих приложений > 10]

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

Вызов обнаружения данных устройств [Метрика: > 20 типов устройств с мультивариантными наборами данных]

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

Фокус распределения [Метрика: Fan-out > 10]

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

Фокус сбора [Метрика: Односторонний поток данных с fan-in > 100]

Системы, которые в основном собирают данные для хранения или анализа — часто отправляя информацию в облачный бэкенд — могут использовать hub-and-spoke или облако-центричные дизайны, упрощая архитектуру.

Преимущества таксономии

Хорошо определенная IIoT-таксономия — не роскошь, а предпосылка для информированного дизайна. Проясняя ключевые вызовы, архитекторы могут выбирать правильные протоколы, сетевые топологии и вычислительные ресурсы, избегая дорогостоящих ошибок вроде неправильного размещения серверов или несоответствующих real-time претензий.

Industrial Internet Consortium готов взять на себя эту задачу. Его новая Рабочая группа нацелена на дистилляцию этих фундаментальных бизнес- и технических императивов. Я взволнован ко-лидерствовать группу на следующем заседании участников IIC в Барселоне. Если вы заинтересованы, свяжитесь со мной по stan@rti.com, Dirk Slama (Dirk.Slama@bosch-si.com) или Jacques Durand (JDurand@us.fujitsu.com). Вместе мы можем применить наш коллективный опыт к формированию будущего IIoT.