структура ara::diag::CommunicationControl::ComCtrlRequestParamsType

Структура данных объединяет все входные параметры сервисного запроса UDS 0x28 для адаптивного управления коммуникацией согласно [SWS_DM_00805]. При поступлении такого диагностического сообщения платформа десериализует типы управления и коммуникации, а также идентификатор узла и передает заполненную структуру соответствующему обработчику сервиса. Прикладное программное обеспечение анализирует содержащиеся значения для целенаправленного воздействия на поведение передачи и приема определенных сетевых сегментов (AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»). Будучи контейнером данных без сохранения состояния, структура не имеет собственной синхронизации параллелизма, в связи с чем обращения должны оставаться в контексте выполнения обработчика.

больше ›

Контекст

Структура ara::diag::CommunicationControl::ComCtrlRequestParamsType представляет собой центральный тип передачи данных в функциональном диагностическом интерфейсе AUTOSAR Adaptive [SWS_DM_00805]. Она объявлена в заголовочном файле ara/diag/communication_control.h и служит стандартизированным контейнером параметров, который инкапсулирует все входные параметры диагностического запроса службы UDS 0x28 (CommunicationControl) (AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»).

В общей системе структура выступает в роли посредника между управлением диагностикой AUTOSAR (Diagnostic Management) и адаптивным прикладным программным обеспечением, отвечающим за управление коммуникацией конкретного транспортного средства. Входящие диагностические команды от внешних тестеров десериализуются на уровне платформы и передаются приложению через эту структуру. Структура включает три открытые переменные-члена (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 «Public Member Variables»):

• controlType ([SWS_DM_01562], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.2 «controlType»): определенное как std::uint8_t, это поле передает субфункцию, извлеченную из запроса UDS, для спецификации выполняемой операции управления.
• communicationType ([SWS_DM_01563], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.1 «communicationType»): также имеющее тип std::uint8_t, это поле представляет тип коммуникации, указанный в запросе UDS (например, обычная коммуникация или коммуникация по управлению сетью).
• nodeIdentificationNumber ([SWS_DM_01564], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.3 «nodeIdentificationNumber»): определенная как std::uint16_t, эта переменная идентифицирует конкретный целевой узел или подсеть, на которые направлена инструкция управления.

Жизненный цикл

Будучи элементарной структурой C++ (struct) [SWS_DM_00805], ComCtrlRequestParamsType обладает характеристиками простого типа значений (Plain Old Data / POD). Она не имеет внутреннего конечного автомата, указателей на виртуальные функции и динамически выделяемых областей памяти (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 «Public Member Variables»).

Создание экземпляра обычно происходит кратковременно посредством фреймворка Diagnostic Management: как только сообщение UDS 0x28 принято и формально проверено, стек инстанцирует структуру и инициализирует переменные-члены декодированными полезными данными (интерпретация: создание объекта полностью возложено на промежуточное ПО в рамках приема запроса). Вопрос Q-1abe8049ce5759f2 (открытый) Отношения владения строго ограничены контекстом вызова метода. Платформа обычно передает экземпляр по значению или константной ссылке обработчику сервиса приложения; принимающее приложение не берет на себя постоянное владение экземпляром.

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

Путь использования

Типичный сценарий использования в рамках диагностической обработки осуществляется в виде фиксированной последовательности шагов от сетевого сообщения до реакции приложения (AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»):

1. Прием диагностического сообщения: внешний диагностический тестер отправляет запрос UDS 0x28 на блок управления. Adaptive Diagnostic Management принимает пакет данных на транспортном уровне.
2. Десериализация и инстанцирование: диагностический стек разбирает полезную нагрузку, создает экземпляр ComCtrlRequestParamsType [SWS_DM_00805] и присваивает переданные значения полям controlType [SWS_DM_01562], communicationType [SWS_DM_01563], а также nodeIdentificationNumber [SWS_DM_01564].
3. Передача обработчику сервиса: промежуточное ПО перенаправляет экземпляр реализованному методу обратного вызова интерфейса CommunicationControl в адаптивном приложении.
4. Оценка параметров и выполнение: адаптивное приложение считывает структуру. На основе nodeIdentificationNumber [SWS_DM_01564] определяется, адресован ли собственный узел или подсеть. Затем через controlType [SWS_DM_01562] и communicationType [SWS_DM_01563] активируются или деактивируются соответствующие режимы передачи и приема.
5. Обратная связь: после успешного выполнения приложение подтверждает операцию компоненту Diagnostic Management, который передает соответствующий стандарту положительный ответ UDS диагностическому тестеру.

Диаграмма последовательности: типичный процесс обработки запроса от сообщения UDS 0x28 до анализа параметров в приложении. Источники: [SWS_DM_00805], AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»