Таксономия для IIoT

Короли играют в шахматы на прекрасных стеклянных стульях. Кто-нибудь это помнит?

Для большинства это, вероятно, тарабарщина. Но не для меня. Эта мнемоника помогает мне вспомнить систематику жизни:Царство, Тип, Класс, Порядок, Семья, Род, Вид.

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

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

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

Также бесполезно разделять приложения по отраслям, таким как «медицина, транспорт и электроэнергетика». Хотя эти среды важны, применимые архитектуры и технологии просто не разделяются по отраслям. Здесь снова нам нужно более глубокое понимание характеристик, которые определяют основные проблемы, и эти проблемы будут определять архитектуру.

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

Итак, что мы можем использовать для разделения? Какие определяющие характеристики мы можем использовать, чтобы отделить млекопитающих от рептилий от насекомых IIoT?

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

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

Исходя из обширного опыта RTI с почти 1000 реальных приложений IIoT, я предлагаю несколько ранних разделов ниже. Чтобы быть максимально точным, я также выбрал «метрики» для каждого подразделения. Линии, конечно, не такие резкие. Но числа дают ясность, и это очень важно; без числовых мер (измеритель?), смысл слишком часто теряется.

Предложение по таксономии Интернета вещей

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

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

Мы обнаружили, что самый простой и полезный способ категоризации надежности - это спросить:«Каковы последствия неожиданного отказа в течение 5 минут в год?» (Мы выбираем здесь 5 минут в год только потому, что это золотая спецификация «5-9 секунд» для серверов корпоративного класса. Многие промышленные системы не выдерживают даже нескольких миллисекунд неожиданного простоя.)

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

В реальном времени [показатель:ответ <100 мс]

Есть тысячи способов охарактеризовать «реальное время». Все системы должны быть «быстрыми». Но чтобы быть полезными, мы должны четко понимать, какие требования к скорости определяют архитектуру.

Архитектура, которая может удовлетворить человека-пользователя, не желающего ждать веб-сайта более 8 секунд, никогда не удовлетворит промышленный контроль, который должен ответить в течение 2 мс. Мы обнаружили, что «изгиб кривой», который сильно влияет на дизайн, возникает, когда скорость отклика измеряется в несколько десятков миллисекунд (мс) или даже микросекунд (мкс). Мы выберем 100 мс просто потому, что это связано с потенциальным джиттером (максимальной задержкой), налагаемым сервером или брокером на пути данных. Системы, которые реагируют намного быстрее, чем это обычно, должны быть одноранговыми, и это оказывает огромное влияние на архитектуру.

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

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

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

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

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

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

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

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

Ориентация на распространение [показатель:разветвление> 10]

Мы определяем «разветвление» как количество получателей данных, которые должны быть проинформированы при изменении одного элемента данных. Это влияет на архитектуру, поскольку многие протоколы работают через одиночные соединения 1:1. Большая часть корпоративного мира работает таким образом, часто с TCP, протоколом сеанса 1:1. Примеры включают подключение браузера к веб-серверу, приложения для телефона к бэкэнду или банка к компании-эмитенту кредитной карты.

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

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

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

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

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

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

[1] [2] 下一页