Сегодня практически любая встраиваемая система, в составе которой есть вычислитель, является распределенной. Рассмотрим пример системы, в которой есть микроконтроллер, для которого мы пишем программу и другое устройство, логику работы которого мы изменить не можем. Нам необходимо взаимодействовать с этим устройством — для этого мы подключаем микроконтроллер к нему через некоторый интерфейс (напрямую или опосредовано, возможно, через набор конверторов интерфейсов). Далее нам необходимо общаться с этим устройством — для этого мы должны поддержать в нашей программе протокол общения, задаваемый устройством.
Эта задача — реализация протокола в микроконтроллере — является типовой для многих проектов. А поскольку любое устройство имеет собственный протокол общения и зачастую не имеет его реализации под ваш микроконтроллер или ваш интерфейс, то вам необходимо руками реализовывать протокол. Это трудоемкая задача. А значит есть смысл сделать инструмент, который позволит автоматизировать её решение.
Такой инструмент мы и хотим добавить в пакет MCU Blocks.
Известно, что тема взаимодействия распределенных компонент изучается со времен появления первого программируемого радиокомпонента (а возможно и до этого момента). Есть методы формальных описаний (МФО), есть стандарты ITU (в реализации SDL, MSC, ASN, …), есть модель OSI, есть много еще чего. Всего этого мы обязательно коснемся в других статьях, чтобы сравнить и понять что мы можем использовать, что не можем и где наше место под солнцем. Если вам есть что подсказать нам, прошу оставить комментарий к этой заметке.
Среди прочих работ, посвященных генерации реализаций протоколов, нам попался исследовательский проект LaBRI – University of Bordeaux под названием z2z (презентация, статья, диссертация). Задача проекта — автоматическая генерация кода, реализующего протокольный шлюз. Рассматривается область телекоммуникационных систем. Конкретно в статье рассматривается проблема необходимости реализации шлюза, объединяющего различные протоколы (SIP for telephones, RTSP for televisions, X2D for thermostats, and X10 for lamps), в системах типа Умный дом. В принципе, если мы рассматриваем ситуацию, когда нужно объединить в одну сеть устройства разных производителей и общаться с ними по одному протоколу такая проблема может иметь место. Предлагается использовать 3 разных DSL для описания «protocol behaviors, message structures, and the gateway logic» и последующая кодогенерация в Си + рантайм. Тестирование проводилось на ARM 200Mhz и решение заняло ~200Кб памяти.
Отмечается, что компилятор из DSL в Си производит проверку корректности свойств протоколов (checks essential correctness properties)
- DSL PS (Protocol spec) описывает свойства протокола (tcp\upd, unicast\multicast, sync\async), описывает маппинг хэндлеров в зависимости от значений, определенных полей входящих сообщений и описывает конструктор исходящих сообщений. Есть отдельная секция для обработки сессий (определяет как идентифицировать запросы в рамках одной сессии)
- DSL MS (Message spec) позволяет описывать шаблон для разбора приходящих сообщений и шаблон для генерации исходящих сообщений
- DSL MT (Message translation) — Си-подобный язык для оперирования с входящими и исходящими сообщениями, задания логики работы шлюза
Мы можем представить нашу задачу аналогично данной (см. схему)
Нам необходим шлюз, который с одной стороны умеет принимать сообщения от внешнего устройства по его интерфейсу и в терминах его протокола, а с другой стороны умеет отсылать эти сообщения в терминах, которые будут понятны коду, который напишет разработчик (другими словами в терминах разработчика). Этот шлюз необходимо автоматически генерировать по некоторым исходным описаниям.
К этим описаниям (исходным данных для генератора) относятся:
- Описание свойств стэка протокола устройства (аналогично DSL PS, но дополнительно еще и указание интерфейса и его свойств)
- Описание форматов сообщений, которые “приходят” от устройства (сообщения прикладного уровня стэка протоколов устройства)
- Описание API для кода программиста (описание функций и структур данных), через которое код программиста будет взаимодействовать с шлюзом
- Описание логики трансляции сообщений (аналог DSL MT).
При этом очевидным, на мой взгляд, развитием подхода является выделение в DSL MT типовых схем трансляции — например, по типам внешних устройств (работа с АЦП, работа с драйвером шагового двигателя, работа с сервером) или по типам взаимодействий (REST или RPC или….) Тем самым мы можем еще больше повысить уровень DSL и подойти вплотную к тому, что сейчас делают в области генерации реализации протоколов в области распределенных высокопроизводительных сервисов (смотри, например, проекты AERON, AJRPC, Aconite — два последних разрабатываются командой проекта Acapella).
Добавить комментарий