Паттерны IoT

Internet of Things Patterns, Lukas Reinfurt, Uwe Breitenbücher, Michael Falkenthal, Frank Leymann, and Andreas Riegg. 2016. Internet of Things Patterns. EuroPLoP’16, , Article (), 21 pages. DOI: 10.1145/3011784.3011789 https://doi.org/10.1145/3011784.3011789

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

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

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

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

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

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

Решение: Подключить устройства к посреднику - Device Gateway, который осуществляет конвертация различных типов протоколов.

Результат: Device Gateway обычно представляет собой специализированное аппаратное устройство, которое может соединять одновременно несколько коммуникационных технологий. На интерфейсе к серверу он обычно поддерживает IP-связь через Ethernet, Wi-Fi или мобильных сетей. На интерфейсах к устройствам в сою очередь он поддерживает низкоэнергетические коммуникационные технологии. Предполагается, что все отправляемые сообщения между устройствами должны содержать определенный идентификатор.

Контекст: Устройства, работающие в обычном, Low-Power, или Always-On режимах. Эти устройства могут отключаться в разное время.

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

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

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

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

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

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

Результат: Rules Engine содержит набор правил и действия, которые должны быть выполнены, если конкретное правило выполняется. Как правило, эти правила и связанные с ними действия определяются пользователем с помощью графического интерфейса на внутреннем сервере. Во время операции каждое входящее сообщение сравнивается с этими правилами. Если правило совпадает, связанное действие срабатывает. Rules Engine часто расположен на центральном бэкенд-сервере, но также может быть расположено на Device Gateway. Действия могут отличаться по сложности выполнения. Простые действия могут вызвать некоторые операции, встроенная в платформу, например, отправку уведомления пользователю. Они могут также выступать в качестве маршрутизатора передавая данные на внутренний или внешний серверы для дальнейшей обработки. Одно сообщение может вызвать только одно действие, но присутствует возможность связать несколько действий в одно правило, которое затем может быть выполнено.

Контекст: Есть бэкенд-сервер, где регистрируется устройство. Время от времени возникает ситуация, когда немедленно необходимо связаться со спящим устройством.

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

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

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

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

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

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