→ Источник
В июле 2016 на сайте National Institute of Standards and Technology (NIST), как обычно, в свободном доступе, появилась новая публикация NIST Special Publication 800-183, Networks of ‘Things’. Данный документ был выпущен в серии SP 800, Computer Security, что подразумевает его непосредственное отношение к информационной безопасности. Тем не менее, NIST SP 800-183 посвящен, в первую очередь, нотации проектирования и описания архитектуры IoT.
Я решил разобраться с содержанием этого документа, поскольку NIST выпускает более чем солидные руководства, среди которых, например, всемирно известный NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations или NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security и многое другое.
Тем более, что автором NIST SP 800-183 является Jeffrey Voas, известный еще с начала 1990-х гг. публикациями по теории оценивания и тестирования ПО.
Согласно референсной архитектуре интернета вещей (IoT-RA), уровень IoT Device Layer реализует функции мониторинга и управления процессами и объектами реального мира, включая получение данных от датчиков (sensing), обработку информации (computing), передачу информации (communication) и выдачу команд на исполнительные устройства (actuation). В NIST SP 800-183 применяется термин «Network of Things (NoT)», поскольку «вещи» могут быть объединены в сеть, но при этом не подключены к Internet.
NIST SP 800-183 говорит о том, что предлагается уникальный подход в описании IoT. Для этого используется пять типов примитивов: 1) Sensor, 2) Aggregator, 3) Communication Channel, 4) External Utility (eUtility), 5) Decision Trigger.
Все они представлены на заглавной картинке, которая является иллюстрацией к NIST SP 800-183.
Primitive #1: Sensor
Sensor – это датчик, предназначенный для измерения физических параметров (температура, влажность, давление, ускорение и т.д.).
Primitive #2: Aggregator
Sensor передает информацию в Aggregator, который представляет собой программную реализацию функций (возможно, с использованием искусственного интеллекта), превращающих исходные (raw) данные в промежуточные агрегированные данные. Для Aggregator введены еще и понятия акторов (Actor) обработки данных двух типов: Cluster & Weight. Под Cluster подразумевается виртуальный динамический Cluster of Sensors, который организуется и изменяется в зависимости от подхода к агрегированию данных. Под Weight подразумевается весовой коэффициент (также, возможно, динамический), который применяется для обработки данных при помощи Aggregator.
Primitive #3: Communication Channel
Communication Channel представляет собой виртуальную или физическую среду передачи данных, объединяющую все остальные примитивы.
Primitive #4: eUtility (External Utility)
Под eUtility подразумевается любое аппаратное устройство, программа или сервис, являющееся платформой для исполнения Aggregator. В будущем предполагается конкретизировать данный примитив, выделив несколько категорий.
Primitive #5: Decision Trigger
Decision Trigger формирует конечный результат, необходимый для выполнения целевой функции конкретной системы на базе IoT (NoT).
Далее NIST SP 800-183 подробно излагает свойства примитивов, которые, для краткости, можно опустить.
Для дополнения модели IoT (NoT) вводятся шесть свойств (в публикации применяется термин elements): Environment, Cost, Geographic Location, Owner, Device_ID, Snapshot. Подразумевается, что эти свойства влияют на обеспечение достоверности (trustworthiness) работы системы.
1. Environment – физическая среда работы устройств IoT (NoT).
2. Cost – стоимость, она и есть стоимость.
3. Geographic Location – географическое местоположение физического устройства.
4. Owner – физический или юридический владелец примитива; это свойство включает также и роль оператора.
5. Device_ID – уникальный идентификатор примитива.
6. Snapshot – временной срез работы системы, определяющий, в том числе, подход к синхронизации.
В публикации также приводятся примеры, относящиеся к обеспечению и нарушению свойств надежности (reliability) и информационной безопасности (security) для примитивов. На мой взгляд, примеры эти не слишком репрезентативны.
Выводы: что это дает?
В NIST SP 800-183 мне понравился универсальный подход к описанию дизайна IoT в виде полуформальной нотации. По сути, это шаг к стандартизации референсной архитектуры (IoT-RA) на уровне Device Layer. Такое описание может быть входом для разработки соответствующего CAD-инструмента. Возможно, такое ПО уже разрабатывается, а пока, для формирования спецификации IoT можно использовать существующие редакторы (например, MS Visio).
Настораживает, конечно, отсутствие более сложных примеров и информации о применении для реальных проектов. Очевидно, такая информация может появиться в дальнейшем.
Кроме того, если еще немного копнуть, то может получиться хороший аппарат для анализа сценариев использования систем на базе IoT (use case scenarios) и, соответственно, для анализа рисков, связанных с обеспечением таких свойств, как достоверность (trustworthiness), информационная безопасность (security) и надежность (dependability). В отношении последнего свойства, на мой взгляд, автор «не докрутил», поскольку в NIST SP 800-183 применяется термин «reliability», который, хотя и трактуется порой, как «надежность», тем не менее, обозначает «безотказность», т.е. способность непрерывно сохранять работоспособное состояние в течение некоторого времени (наработки). Для IoT, как и для других сложных систем, более уместным является обеспечения свойства «dependability», т.е. надежности в широком смысле, которая описывается, как правило, набором свойств RAMS (reliability – безотказность, availability – готовность, maintainability – ремонтопригодность, safety – безопасность).
Еще я нигде в публикации не нашел явного описания такой критической для IoT характеристики, как электропитание. Возможно, автор подразумевал, что электропитание попадает в категорию Environment, но лучше бы об этом сказать в явно виде.
Несмотря на простоту, нотация выглядит достаточно продуманной. По крайней мере, для описания небольших систем она точно подойдет. Для большой размерности можно применить иерархической представление (система, состоящая из подсистем, или «system of systems»).
Будем попробовать применить такой подход в практике дизайна IoT.
Автор: Vladimir_Sklyar
