модуль ara::nm — Network Management

Функциональный кластер Network Management предоставляет интерфейсы для State Management, позволяя скоординированно запрашивать логические сетевые дескрипторы, подсети и физические каналы связи, а также опрашивать их статус ([SWS_ANM_01000], EXP_SWArchitecture с. 77). С помощью класса NetworkHandle осуществляется управление целевыми и фактическими состояниями между kNoCom и kFullCom, а также регистрируются асинхронные уведомления ([SWS_ANM_01009], [SWS_ANM_01010], [SWS_ANM_01358]). Использование интерфейса предназначено исключительно для State Management, в то время как об ошибках сообщается единообразно через NmErrorDomain ([SWS_ANM_01101], [SWS_ANM_01111]).

больше ›

Функциональный кластер Network Management (NM) предоставляет AUTOSAR Adaptive Platform механизмы для запроса и мониторинга состояния сетей связи и подсетей. Программный интерфейс ориентирован исключительно на функциональный кластер State Management, который управляет сетевыми ресурсами через логические экземпляры класса NetworkHandle и изолирован от физических структур шин, таких как Ethernet или CAN ([SWS_ANM_01000], EXP_SWArchitecture с. 77, EXP_PlatformDesign с. 60).

Контекстная диаграмма: системная интеграция функционального кластера Network Management между State Management и физическим сетевым уровнем. Источники: SWS_NetworkManagement с. 13, EXP_PlatformDesign с. 60, [SWS_ANM_01000]

NetworkHandle инициализируется с помощью ara::core::InstanceSpecifier и поддерживает операции перемещения, тогда как конструктор копирования и присваивание копированием удалены ([SWS_ANM_01001], [SWS_ANM_01003], [SWS_ANM_01005]). Модуль различает установленное состояние запроса (SetNetworkRequestedState, GetNetworkRequestedState) и фактически активное состояние сети (GetNetworkState), каждое из которых представлено перечислением NetworkStateType с состояниями kNoCom и kFullCom ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01358]).

Диаграмма последовательности: поток взаимодействий при регистрации уведомителя, запросе состояния и опросе состояния. Источники: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement с. 38

Для асинхронной сигнализации об изменениях статуса можно зарегистрировать функции обратного вызова через RegisterNetworkStateChangeNotifier или RegisterNetworkRequestedStateChangeNotifier — опционально с собственным исполнителем (Executor) ([SWS_ANM_01010], [SWS_ANM_01014], [SWS_ANM_01020]). Ошибки отображаются через NmErrorDomain и NmErrc; стандартизированные коды, такие как kServiceNotAvailable и kInvalidHandler, обеспечивают детерминированную обработку сбоев и некорректных конфигураций ([SWS_ANM_01101], [SWS_ANM_01111]).

больше ›

Системная роль и функциональное разграничение архитектуры

Функциональный кластер Network Management (NM) обеспечивает в составе AUTOSAR Adaptive Platform скоординированное управление сетями связи и подсетями (Partial Networks, PN). Программный интерфейс модуля не предназначен для произвольных Adaptive Applications, а служит специально для функционального кластера State Management (SM), позволяя по мере необходимости запрашивать или освобождать коммуникационные возможности ([SWS_ANM_01000], EXP_SWArchitecture с. 77). State Management выступает в роли центрального системного оркестратора машины и управляет функциональными группами, а также состояниями платформы, тогда как Network Management инкапсулирует фактический мониторинг шины, логику подсетей и состояния поддержания активности шины (SWS_NetworkManagement с. 13, EXP_PlatformDesign с. 60).

С точки зрения архитектуры Network Management развязывает вышестоящее управление состояниями и физическую топологию сетей, таких как Ethernet или CAN, с помощью логических сетевых дескрипторов (NetworkHandle) (EXP_PlatformDesign с. 60). Сетевой запрос от State Management внутренне сопоставляется с канальными автоматами состояний и автоматами состояний частичных сетей (Partial Network State Machines, PNSM), благодаря чему связь на физических каналах синхронизируется и активируется либо отключается по мере необходимости (SWS_NetworkManagement с. 18, SWS_StateManagement с. 17).

Контекстная диаграмма: системная интеграция функционального кластера Network Management между State Management и физическим сетевым уровнем. Источники: SWS_NetworkManagement с. 13, EXP_PlatformDesign с. 60, [SWS_ANM_01000]

Инстанцирование и управление ресурсами через NetworkHandle

Функциональный доступ к конкретной подсети или физическому каналу связи осуществляется через экземпляры класса NetworkHandle ([SWS_ANM_01000]). NetworkHandle создается явным образом путем передачи ara::core::InstanceSpecifier, который однозначно ссылается на назначенный прототип порта NetworkManagementPortInterface ([SWS_ANM_01001]). Инициализация через этот конструктор специфицирована как потокобезопасная ([SWS_ANM_01001]).

Проектирование интерфейса NetworkHandle следует строгим правилам жизненного цикла и владения: конструктор копирования и оператор присваивания копированием явным образом удалены (= delete), что предотвращает нескоординированное дублирование экземпляров дескрипторов ([SWS_ANM_01005], [SWS_ANM_01006]). Напротив, конструктор перемещения и оператор присваивания перемещением предоставляются для контролируемой передачи ресурсов ([SWS_ANM_01003], [SWS_ANM_01004]). Интерпретация: поскольку копирование запрещено и разрешены только операции перемещения, архитектура, вероятно, предписывает семантику монопольного владения для каждого экземпляра дескриптора, чтобы исключить конкурирующие регистрации уведомителей на одном и том же объекте. Вопрос Q-912cb5d1ddff2896 (открытый) Деструктор и оператор присваивания перемещением явно определены как непотокобезопасные, поэтому управление жизненным циклом дескриптора в State Management должно выполняться синхронизированно ([SWS_ANM_01002], [SWS_ANM_01004]).

Управление и опрос состояний связи

Модуль строго различает запрошенное целевое состояние (Requested State) и фактически активное текущее состояние (Network State) сетевого дескриптора ([SWS_ANM_01007], [SWS_ANM_01008]). Оба состояния представлены через перечисление NetworkStateType со значениями kNoCom (значение 0) и kFullCom (значение 1) ([SWS_ANM_01358]). Общее состояние по определению является kFullCom только тогда, когда абсолютно все назначенные дескриптору частичные или полные сети находятся в состоянии связи FULL_COM; в противном случае статус равен kNoCom ([SWS_ANM_01358]).

Через метод SetNetworkRequestedState State Management запрашивает активацию (kFullCom) или деактивацию (kNoCom) соответствующей сети PNC, VLAN или физической сети ([SWS_ANM_01009], EXP_SWArchitecture с. 77). С помощью GetNetworkRequestedState можно синхронно опросить последнее установленное запрошенное значение ([SWS_ANM_01008]). Фактическое же, релевантное для шины рабочее состояние считывается с помощью GetNetworkState, при этом оба метода опроса объявлены как потокобезопасные и инкапсулируют свой результат в ara::core::Result ([SWS_ANM_01007], [SWS_ANM_01008]).

Диаграмма состояний: переходы базового сетевого статуса NetworkStateType. Источники: [SWS_ANM_01358], [SWS_ANM_01007], [SWS_ANM_01009]

Событийно-ориентированный мониторинг состояний и механизмы оповещения

Поскольку изменения состояний на сетевом уровне поступают с задержкой из-за внешних участников шины, таймаутов сообщений или асинхронного времени запуска, NetworkHandle предоставляет механизмы асинхронного оповещения через функции обратного вызова типа NetworkStateChangeNotifier (std::function<void(const NetworkStateType&)>) ([SWS_ANM_01020]). Для изменений эффективного состояния сети служит RegisterNetworkStateChangeNotifier ([SWS_ANM_01010]), тогда как изменения запрошенного состояния отслеживаются через RegisterNetworkRequestedStateChangeNotifier ([SWS_ANM_01012]).

Для каждого дескриптора и типа мониторинга может быть зарегистрирован максимум один уведомитель; каждый последующий вызов регистрации перезаписывает ранее зарегистрированный обратный вызов (EXP_SWArchitecture с. 77). С помощью UnregisterNetworkStateChangeNotifier и UnregisterNetworkRequestedStateChangeNotifier существующие регистрации могут быть явным образом отменены ([SWS_ANM_01011], [SWS_ANM_01013]). Для расширенного управления выполнением доступны шаблонные методы регистрации, принимающие пользовательский исполнитель (ExecutorT&& executor) для обработки оповещения в конкретном контексте выполнения или потоке ([SWS_ANM_01014], [SWS_ANM_01015]).

Диаграмма последовательности: поток взаимодействий при регистрации уведомителя, запросе состояния и опросе состояния. Источники: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement с. 38

Моделирование манифеста и конфигурация сопоставления

Интеграция Network Management в Adaptive Application осуществляется через стандартизированные элементы метамодели в манифесте. Интерфейс NetworkManagementPortInterface специализирует фундаментальный метакласс PortInterface и тем самым определяет формальные прототипы портов (PPortPrototype, RPortPrototype) для взаимодействия с кластером (TPS_ManifestSpecification с. 263).

В манифесте развертывания привязка между экземплярами приложений и логическим Network Management декларируется с помощью элемента сопоставления NetworkHandlePortMapping (TPS_ManifestSpecification с. 620). Он связывает прототип порта внутри процесса (Process) с логическим NmNetworkHandle (TPS_ManifestSpecification с. 620). Кроме того, через элемент метамодели NmInteractsWithSmMapping обязательно конфигурируется координационная связь между кластером State Management (через StateManagementStateRequest) и сетевым дескриптором (NmNetworkHandle) (TPS_ManifestSpecification с. 875).

Диаграмма метамодели: связи конфигурации ARXML и сопоставлений между портами, процессами, дескрипторами и State Management. Источники: TPS_ManifestSpecification с. 263, TPS_ManifestSpecification с. 620, TPS_ManifestSpecification с. 875

Поведение при ошибке

Для единообразной обработки ошибок модуль реализует собственный домен ошибок в соответствии с архитектурой обработки ошибок AUTOSAR Adaptive. Класс NmErrorDomain наследуется от ara::core::ErrorDomain и идентифицирует ошибки управления сетью с помощью статического запроса домена GetNmDomain, а также методов идентификации Name и Message ([SWS_ANM_01101], [SWS_ANM_01105], [SWS_ANM_01106], [SWS_ANM_01107], [SWS_ANM_01109]).

Специфические причины ошибок определены в перечислении NmErrc ([SWS_ANM_01111]). Код ошибки NmErrc::kServiceNotAvailable (код 1) сигнализирует о том, что базовая служба платформы или демон недоступны; он может возникать в методах GetNetworkState, GetNetworkRequestedState и SetNetworkRequestedState ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01111]). Код ошибки NmErrc::kInvalidHandler (код 2) возвращается, если в один из методов регистрации был передан недействительный обработчик-уведомитель ([SWS_ANM_01010], [SWS_ANM_01012], [SWS_ANM_01014], [SWS_ANM_01015], [SWS_ANM_01111]).

Коды ошибок преобразуются через MakeErrorCode в обычные объекты ara::core::ErrorCode ([SWS_ANM_01110]). Если в средах выполнения разрешены и настроены исключения C++, эти ошибки могут генерироваться через ThrowAsException как исключение типа NmException ([SWS_ANM_01100], [SWS_ANM_01102], [SWS_ANM_01108]). Для упрощения доступны псевдонимы типов Errc и Exception ([SWS_ANM_01103], [SWS_ANM_01104]).

Дальнейшие подробные доказательства

Основные требования модуля опираются на нормативные положения спецификации и сопутствующие архитектурные модели:

• Спецификация классов и интерфейсов: NetworkHandle как базовый класс для сетевых запросов и опросов состояния ([SWS_ANM_01000]–[SWS_ANM_01015]).
• Определение состояний: NetworkStateType с kNoCom и kFullCom для отображения сетевого статуса ([SWS_ANM_01358]).
• Домен ошибок и коды ошибок: NmErrorDomain, NmException и NmErrc ([SWS_ANM_01100]–[SWS_ANM_01111]).
• Архитектурные свидетельства и подтверждения в манифесте: определения интерфейсов и портов в EXP_SWArchitecture с. 77, SWS_NetworkManagement с. 13, EXP_PlatformDesign с. 60, а также сопоставления метамодели в TPS_ManifestSpecification с. 263, TPS_ManifestSpecification с. 620 и TPS_ManifestSpecification с. 875.