Ключевые слова: децентрализованная система, управление IoT, IOTA, блокчейн, IPFS, управление программным обеспечением.
Введение
C каждым годом количество IoT устройств растет и как следствия, нужны механизмы для управления этими устройствами. Один из таких важных механизмов — это управление программным обеспечением. Можно выделить централизованный и децентрализованный подход для решения задачи. Особый интерес представляет децентрализованных подход. Он может решить такие проблемы централизованного подхода, как:
- конфиденциальность
- безопасность
- доверие
- единая точка отказа
Для разработки системы управления программного обеспечения необходимо выбрать распределенную платформу, на которой она будет основана. Все взаимодействия между клиентами и устройствами должны происходить только через нее. Это обеспечит прозрачность всех взаимодействий, а также гарантию того, что никакие данные не могут быть подделаны. Кроме того. необходимо решить проблему распространения обновлений. Совершенно очевидно, что предавать файла внутри распределенного реестра — плохой подход, так как это может увеличить нагрузку на сеть. Поэтому в данной работе предлагается хранить обновления внутри распределенной файловой системы, а в реестр записывать лишь хэш этого файла. Таким образом становится невозможно подменить файл, так как это повлечет изменение хэша, а записи внутри распределенного реестра невозможно изменить.
Компоненты системы
В данной работе была выбрана платформа IOTA по нескольким причинам.
В отличие от блокчейна, в котором транзакции объединяются в блоки, а затем эти блоки верифицируются и добавляются в общую цепочку, в IOTA же используется ориентированный ациклический граф, называемый Tangle. Каждая транзакция должна подтвердить 2 предыдущие. Именно поэтому данная платформа обладает высоким показателям количества транзакция в секундну, так как чем больше транзакций добавляется, тем больше подтверждается. 4.6 для биткоина, 15 для ethereum, 800 IOTA.
Также важным фактором является то, что транзакции в IOTA бесплатные и как следствие не нужно платить комиссию майнерам, что актуально для сети Интернета Вещей.
Отдельно стоит сказать про важную особенность IOTA — MAM канал. Это надежный и зашифрованный протокол передачи данных, работающий поверх транзакций. MAM канал можно сравнить с каналом в СМИ. Канал может быть публичными, на которой могут подписаться все желающие и ограниченным, для доступа к которому нужен ключ
В качестве распределенной файловой системы был выбран IPFS. В данной файловой системы для каждого файла генерируется уникальный хэш. Благодаря этому возможна адресация на основе контента, а не местоположения. Иными словами, мы может быть уверенными в том, что по данному хэшу будет доступен именно запрашиваемый файл. Его подмена невозможна. Так как изменение файла повлечет изменение хэша.
Общая архитектура
Задачу управление программным обеспечением можно разбить на 2 пункта:
- Доставка обновления
- Применение обновления
Доставка обновлений включает в себя взаимодействие, например, с распределенной платформой, этот пункт отвечает за сетевую часть работы системы.
Применение же является в большей степени локальной задачей каждого устройства.
На рисунке 1 приведена общая архитектура системы управление программным обеспечением.
Рис. 1. Общая схема архитектуры
IoT devices — это устройства Интернета вещей. Каждое такое устройство представляет собой контроллер(например, таким контроллером может быть Raspberry PI) и какое-то количество датчиков. Будем говорить, что все датчики, одной и той же модели принадлежат одному классу.
Loader — это точка взаимодействия пользователя с системой. Компонент Loader написан на NodeJS и предоставляет пользователю интерфейс командной строки. Пользователь может указать 2 основных параметра — это имя класса, для которого будет послано обновление и файл самого обновления.
Как говорилось выше, в IOTA есть защитный механизм передачи зашифрованных сообщений MAM. Для каждого класса существует свой ограниченный MAM канал, пароль от которого известен устройствам, у которых есть этот класс. Также существует публичный канал, на который подписаны все устройства, в этот канал приходит уведомление о том, что есть обновление для указанного класса.
Отправка обновления
На рисунке 2 приведена схема отправки обновления. Пользователь загружает в IPFS файл обновления, стоит отметить, что загружается не сам файл, а diff — разница между старой и новой версией файла. Это сделано для того, чтобы передавать файлы меньших размеров. IPFS возвращает хэш этого файла. Далее публикуется сообщение в публичный канал о том, что есть обновления для указанного класса. Затем в ограниченный канал класса отправляется хэш файла.
Рис. 2. Схема отправки
Таким образом, мы можем быть уверены в сохранности и надежности передачи, ввиду 2 факторов:
- Любое изменение файла повлечет за собой изменение хэш значения этого файла в распределенной файловой системе IPFS.
- Сообщение в MAM канале нельзя изменить
Получение обновления
Как только устройство читает сообщения из публичного канала о том, что есть обновление для класса, который есть у этого устройства, то оно из IPFS получает этот файл. Затем останавливает процесс, который использует этот файл. Обновляет файл, считает хэш сумму получившегося файла и отправляет в Tangle информацию о статусе применения обновления и получившийся хэш. Это нужно для того, чтобы пользователь мог убедиться в корректности обновления. В конце устройство перезапускает процесс.
Стоит отметить, что так как сообщения добавляются в Tangle, то устройство может прочитать его в любой момент времени, то есть если устройство по каким-то причинам потеряло соединение с сетью, то как только соединение восстановится, устройство сможет прочитать все сообщения, которые были отправлены в момент его отсутствия в сети и тем самым не пропустит обновление, если обновление было.
Тестирование
Применения, как уже говорилось выше, в большей степени является локальной задачей каждого устройства, так как оно может зависеть от характеристик отдельного устройства. А механизм доставки является более общим, именно этот механизм обеспечивает масштабируемость системы.
Тестирование состояло в следующем: были взяты 3, 5 и 10 устройств. На устройства отправлялись обновления. Время измерялось от отправки в public канал сообщения о наличии обновления до принятия файла самым последним устройством, то есть, например, если есть 3 устройства, а какое-то из них получило файл позже всех, то конечным времен считается принятие именно этим устройством. Помимо увеличения числа устройств также увеличивался размер файла обновления
На графике результатов теста(рис. 3) видна тенденция роста времени при увеличении размера файла, что является естественным, поскольку увеличивается время на получение файла. Особое внимание стоит уделить тому, что при одинаковых размерах файла, время, потраченное на доставку обновления, не коррелирует с количеством устройств, на которые отправляется обновление. Из этого можно сделать вывод о масштабируемости системы.
Рис. 3. Результаты тестирования
Литература:
- Sabrina Sicari, Alessandra Rizzardi, Luigi Alfredo Grieco and Alberto Coen-Porisini Security privacy and trust in Internet of Things: The road ahead. Computer networks, vol. 76, pp. 146–164, 2015.
- Ala Al-Fuqaha, Mohsen Guizani, Mehdi Mohammadi, Mohammed Aledhari, Moussa Ayyash Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications.: IEEE Communications Surveys & Tutorials (Volume: 17, Issue: 4, Fourthquarter 2015)
- Lee, J. Patch Transporter: Incentivized, Decentralized Software Patch System for WSN and IoT Environments. Sensors 2018, 18, 574–608.
- Nachiket Tapas, Yechiav Yitzchak, Francesco Longo, Antonio Puliafito, Asaf Shabtai P 4 UIoT: Pay-Per-Piece Patch Update Delivery for IoT Using Gradual Release Sensors (Basel). 2020 Apr 10;20(7):2156.
