Углубленная интерпретация «универсального языка» устройства, возможности распределенной программной шины системы Hongmeng.

HarmonyOS

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

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

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

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

1. Введение

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

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

2. Характеристики распределенной мягкой шины

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

2.1 Самообнаружение и связь между устройствами

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

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

2.2 Взаимодействие нескольких устройств и сеть

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

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

2.3 Передача данных между несколькими устройствами

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

3. Протокол программной шины COAP

WEB-приложения в Интернете распространены повсеместно, и многие из них основаны на архитектуре протокола REST. Для поддержки REST в основном на узлах с ограничениями (таких как 8-битные микроконтроллеры с ограниченным объемом ОЗУ и ПЗУ) и сетях с ограничениями (таких как 6LoWPAN) инженеры решили обратиться к «ограниченным средам отдыха» или CoRE. Ограниченная сеть, такая как 6LoWPAN, поддерживает разделение данных IPv6 на небольшие пакеты, но значительно снижает эффективность передачи.

Одной из основных целей CoAP (протокол ограниченных приложений) является разработка общего веб-протокола, который поддерживает очень низкие накладные расходы для удовлетворения особых требований ограниченных сред, таких как энергетика, автоматизация зданий или другие приложения M2M. Реализует общее HTTP-подмножество REST, упрощенное для приложений M2M, вместо слепого сжатия HTTP. Протокол COAP можно легко преобразовать в HTTP, что удобно для преобразования с помощью существующей WEB-системы, а также может удовлетворить такие требования, как встроенное обнаружение, поддержка многоадресной рассылки и асинхронная передача сообщений.

3.1 Особенности протокола COAP

Это протокол прикладного уровня, который работает поверх протокола UDP, а не поверх TCP, как HTTP.

  1. Сетевой транспортный уровень протокола COAP изменен с TCP на UDP;

  1. На основе REST адрес ресурса сервера также аналогичен формату URL, а у клиента также есть методы POST, GET, PUT, DELETE для доступа к серверу, что упрощает HTTP;

  2. COAP — это двоичный формат, HTTP — это текстовый формат, а COAP более компактен, чем HTTP;

  3. Небольшой и легкий, минимальная длина составляет всего 4 байта, а заголовок HTTP требует десятков байтов;

  4. Поддержка надежной передачи, повторной передачи данных, блочной передачи;

  5. Поддержка многоадресной рассылки IP, возможность отправки запросов на несколько устройств одновременно, для этой функции используется функция обнаружения устройства Hongmeng;

  6. Коммуникация с недолгим соединением, подходящая для сценариев IoT с низким энергопотреблением;

  7. Поддержка режима наблюдения;

3.2 Тип и структура протокола

Протокол COAP имеет 4 типа сообщений.

  • CON: требуется подтверждение.Если запрос CON отправлен, другая сторона должна ответить, чтобы подтвердить получение сообщения для надежной передачи сообщения;
  • NON: Запрос, который не нужно подтверждать.Если отправлен NON-запрос, другая сторона не обязана отвечать. Он подходит для часто повторяющейся отправки сообщений, а потеря пакетов не влияет на нормальную работу. Как и UDP, он используется для ненадежной передачи сообщений;
  • ACK: сообщение подтверждения, соответствующее ответу на сообщение CON;
  • RST: сброс сообщения, когда полученное сообщение неизвестно или неверно во время надежной передачи, необходимо вернуть сообщение RST;

Определение структуры протокола

Структура протокола COAP определена в исходном коде discovery/coap/include/coap_def.h.

3.3 Передача пакетов COAP

Режим передачи — клиентский и серверный, а серверная сторона запускает службу мониторинга пакетов COAP.

Исходный код discovery/coap/include/coap_socket.h обеспечивает определение функций отправки и получения пакетов COAP.

3.4 Обнаружение устройства COAP

Обнаружение исходного кода/coap/source/coap_discover.c реализует функцию обнаружения устройств на основе COAP.

3.5 Безопасность COAP

TLS нельзя использовать для защиты данных, передаваемых по UDP, поэтому Datagram TLS пытается расширить существующую архитектуру TLS для поддержки UDP.

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

4. Структура исходного кода и анализ

Исходный код распределенного софтбуса находится в каталоге Communication_Services_softbus_lite, структура следующая:

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

4.1 Инициализация программной шины

Функция StartListener() имеет адаптации, соответствующие разным версиям платформы, отражающие идею модульного дизайна о разделении каждой части и объединении различных аппаратных устройств в ОС, наиболее подходящую для данного устройства. Например, при создании потока используется унифицированная статическая функция void WaitProcess(void), а внутри инкапсулируется код адаптации различных базовых API.

4.2 Уровень адаптации операционной системы

Базовой операционной системой HarmonyOS может быть: микроядро HarmonyOS, ядро ​​Linux иLite OSОн станет полной архитектурой микроядра Hongmeng.

Функции, используемые в каждом модуле системы Hongmeng, должны поддерживать адаптацию к различным версиям платформы, отражая идею модульного дизайна о разделении каждой части и объединении различных аппаратных устройств в ОС, наиболее подходящую для устройства. Например, при создании потока используется унифицированная статическая функция void WaitProcess(void), а внутри инкапсулируются коды адаптации различных базовых API. SemCreate использует LOS_SemCreate для создания семафоров в LiteOS и стандартный интерфейс sem_init() Posix в Linux.

Код в каталоге исходного кода os_adapter реализует адаптацию распределенной программной шины к операционной системе.

LiteOS

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

Проект с открытым исходным кодом LiteOS поддерживает ARM Cortex-M0, Cortex-M3, Cortex-M4, Cortex-M7 и другие архитектуры чипов.

4.3 Обнаружение устройства и подключение

Каждое устройство передается и выпускается в виде службы. После выпуска окружающие устройства могут обнаружить его, подключиться и взаимодействовать с ним. Исходный код находится в каталоге discovery\discovery_service\source.

В качестве обнаруженного устройства упрощенное устройство вызывает PublishService для публикации службы. Скриншот кода входа:

Ниже приведены скриншоты разбора кода в последовательности операций для справки.

1) проверка разрешений

os_adapter адаптирован к системе ОС, а инкапсулированные функции имеют разные реализации в разных операционных системах. Например, SemCreate использует LOS_SemCreate для создания семафоров в LiteOS, а стандартный интерфейс Posix sem_init() используется в Linux.

2) проверка параметров

3) Создать семафор

4) Инициализировать службу

A) CoapInit

Инициализация COAP, обработка регистрации стека протоколов TCP/IP и обработка регистрации базового сокета сеанса.

B) CoapWriteMsgQueue()

Напишите сообщение, триггер, чтобы получить IP-адрес Wi-Fi, и запустите шину.

5) Информация Присоединяйтесь к ****модулю

6) регистрCOAPСлужить

Описание: Присвойте g_localDeviceInfo.serverData значение «port:auth_port», auth_port — это номер порта, привязанный к сокету службы аутентификации на основе TCP (назначается в функции StartBus).

7) Обратный вызов отправлен успешно

Вызовите PublishCallback(), чтобы выполнить функцию обратного вызова успешной публикации в cb.

4.4 Управление аутентификацией устройства

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

Модуль authmanager — это модуль, который Hongmeng предоставляет механизм аутентификации для устройств. Основной процесс обработки в модуле включает этапы приема, расшифровки, реинкапсуляции, шифрования и отправки пакетов. Например, при обнаружении запроса вызывается функция ProcessDataEvent(wifi_auth_manager) для получения пакета, проверки заголовка пакета и определения различных методов обработки в зависимости от типа пакета данных. Существует три основных типа пакетов данных:

  • Тип зашифрованных данных MODULE_AUTH_SDK
  • MODULE_TRUST_ENGINE Доверенный тип, прямая передача данных
  • MODULE_CONNECTION для аутентификации IP и устройства

1) Связь внутренней структуры модуля

2) Зашифрованные шаги и алгоритмы отправки

Алгоритм шифрования AES-GCM: AES — это алгоритм симметричного шифрования, и GCM использует режим счетчика для симметричного шифрования с кодом аутентификации сообщения GMAC. Алгоритм AES-GCM — это алгоритм с аутентификацией и шифрованием, который может генерировать зашифрованные данные и код аутентификации для заданного исходного текста.

3) Безопасность подключения устройств Hongmeng

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

Реализовать безопасный поток пользовательских данных между устройствами в сценарии взаимосвязи устройств и реализовать безопасную передачу пользовательских данных.

процесс связывания

  • Устройства генерируют пары ключей Ed25519 соответственно;
  • Используйте PIN-код и PAKE (обмен ключами с проверкой подлинности паролем) для согласования ключей для создания сеансового ключа;
  • Шифровать открытые ключи друг друга с помощью сеансового ключа (шифровать не нужно, просто посчитайте MAC, если вы можете убедиться, что открытый ключ действительно исходит от другой стороны)
  • Открытый ключ идентификации здесь относится к двум кортежам, которые должны быть (идентификация устройства, открытый ключ)

поток общения

  • Сеансовый ключ согласовывается с помощью открытого ключа, как следует использовать сеансовый ключ?Вообще говоря, первоначально согласованный ключ будет распределен и разделен на ключ шифрования, MAC-ключ и т. д.;
  • Шифруйте данные связи с помощью сеансового ключа.

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

4.5 Аутентификация и передача сеанса

Модуль trans_service опирается на службу сетевых сокетов, предоставляемую системной ОС, обеспечивает управление каналом аутентификации и передачу и прием данных аутентификации в модуль аутентификации; обеспечивает управление сеансом и функции передачи и приема данных на основе сеанса для бизнес-модуля, а также обеспечивает передачу и прием сообщений через функцию шифрования модуля GCM, защита от шифрования и дешифрования.

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

Исходный код части передачи данных находится в каталоге trans_service/source/libdistbus.

Основные этапы обработки следующие:

**CreateSessionServer[**Session] → SelectSessionLoop[данные] → OnBytesReceived[обратный вызов]

1) CreateSessionServer****Создать сеанс

2) SelectSessionLoop

После запуска шины создается служба управления сеансом на основе TCP.Поток задач службы — SelectSessionLoop, который обрабатывает прием всех данных сеанса.

3) OnBytesReceived

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

Наконец

Распределенная программная шина является базовым модулем операционной системы HarmonyOS, а также краеугольным камнем распределенного управления данными и распределенного планирования задач.Полное понимание распределенной программной шины является основой для глубокого понимания всего HarmonyOS. .

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

Для конкретных разработок, пожалуйста, обратитесь к соответствующим документам на официальном сайте Hongmeng:developer.harmonyos.com/

Нажмите «Подписаться», чтобы впервые узнать о новых технологиях HUAWEI CLOUD~

Категории