модуль ara::com — Communication Management
Руководство по модулюСОЗДАНО ИИ
Предоставляет типизированные интерфейсы для сервис-ориентированного взаимодействия и абстрагирует транспортные протоколы.
Предоставляет типизированные интерфейсы для сервис-ориентированного взаимодействия и абстрагирует транспортные протоколы.
Functional Cluster Communication Management (ara::com) обеспечивает сервис-ориентированное взаимодействие между Adaptive-приложениями через стандартизированные интерфейсы прокси и скелетона (SWS_CommunicationManagement с. 55, ARAComAPI с. 1). Он управляет динамическим обнаружением сервисов с помощью OfferService() и FindService() ([SWS_CM_00101], [SWS_CM_00122]) и предоставляет синхронные, а также асинхронные методы, события и поля со встроенной защитой E2E и SecOC ([SWS_CM_00141], [SWS_CM_90420]). При временной недоступности сервиса промежуточное ПО перехватывает обрывы соединения и автоматически обновляет существующие объекты прокси после восстановления доступности (ARAComAPI с. 32).
Functional Cluster Communication Management (ara::com) образует основу сервис-ориентированной архитектуры (SOA) в AUTOSAR Adaptive Platform и изолирует прикладную логику от конкретных протоколов передачи с помощью шаблона «прокси-скелетон» (SWS_CommunicationManagement с. 55, ARAComAPI с. 1). Сгенерированные на основе формальных описаний интерфейсов прокси-классы на стороне потребителя и классы скелетона на стороне поставщика предоставляют методы, события и поля через типобезопасные C++-API ([SWS_CM_00130], [SWS_CM_00131]).
Предоставление и динамический поиск сервисов выполняются через Service Discovery (SWS_CommunicationManagement с. 67). Поставщик предлагает свой сервис через OfferService() ([SWS_CM_00101]), в то время как потребители определяют подходящие экземпляры синхронно через FindService() или асинхронно с помощью StartFindService() ([SWS_CM_00122], [SWS_CM_00123]). При этом экземпляры могут адресоваться на основе модели через ara::core::InstanceSpecifier и разрешаться во время выполнения в конкретные ara::com::InstanceIdentifier ([SWS_CM_00118], [SWS_CM_00622]).
Диаграмма последовательности: процесс предложения сервиса (Service Offering), асинхронного поиска и создания прокси. Источники: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces с. 16
Для передачи данных ara::com поддерживает методы «запрос-ответ» через ara::core::Future ([SWS_CM_00191], [SWS_CM_00196]), а также шаблон «публикация-подписка» для событий и полей (AUTOSAR_EXP_ARAComAPI с. 68). Подписчики регистрируются через Subscribe() ([SWS_CM_00141]) и считывают входящие данные через GetNewSamples() ([SWS_CM_00701]). Для повышения производительности поставщик подготавливает данные через Allocate() и передает право владения по схеме Zero-Copy через Send() ([SWS_CM_90437], [SWS_CM_90438]).
Для защиты передачи платформа интегрирует сквозную защиту (E2E), криптографическую аутентификацию (SecOC) через Freshness Value Management (FVM), а также трансляцию сигналов в сервисы (Signal-to-Service Translation) для классических сетей ([SWS_CM_90420], [SWS_CM_11288], [SWS_CM_10174], SWS_CommunicationManagement с. 222). Состояния ошибок стандартизировано сигнализируются через типобезопасные домены ошибок, такие как ComErrorDomain и ComE2EErrorDomain ([SWS_CM_10432], [SWS_CM_10474]). Если соединение с сервисом обрывается, состояние прокси меняется на kSubscriptionPending; после повторного появления сервиса промежуточное ПО прозрачно обновляет внутреннюю адресацию, благодаря чему обмен данными продолжается без повторного создания экземпляра прокси (ARAComAPI с. 32).
Роль и системная архитектура сервис-ориентированного взаимодействия
Functional Cluster Communication Management (ara::com) образует информационно-технологическую основу AUTOSAR Adaptive Platform и реализует сервис-ориентированное взаимодействие (Service-Oriented Architecture, SOA) как между изолированными процессами приложений, так и через границы блоков управления (SWS_CommunicationManagement с. 55). Ключевым принципом является строгое следование шаблону проектирования «прокси-скелетон» (ARAComAPI с. 1): на основе формальных описаний программных интерфейсов (Service Interfaces) генератор кода на базе модели создает типизированные классы прокси для потребителей сервисов и классы скелетона для поставщиков сервисов ([SWS_CM_00130], [SWS_CM_00131]). Логика приложений взаимодействует исключительно с этими абстракциями, тогда как специфичные для протоколов привязки (Bindings), такие как SOME/IP, IPC или DDS, а также их сериализация подключаются только на этапе интеграции и развертывания (AUTOSAR_AP_EXP_ARAComAPI с. 124).
Для выполнения требований платформы ara::com тесно кооперирует с другими функциональными кластерами (SWS_CommunicationManagement с. 34). Во время выполнения Execution Management контролирует жизненный цикл процессов, в то время как Identity and Access Management (IAM) с помощью проверок доступа на основе политик (Policy Decision Point) предотвращает несанкционированные взаимодействия на уровне методов, событий и полей (SWS_CommunicationManagement с. 215). Кроме того, события безопасности напрямую передаются в EventReporter менеджера системы обнаружения вторжений (IdSM) (SWS_CommunicationManagement с. 34).
Контекстная диаграмма: встраивание ara::com и развязка уровней приложений через привязки (Bindings). Источники: SWS_CommunicationManagement с. 55, ARAComAPI с. 1
Обнаружение сервисов и создание экземпляров через прокси и скелетоны
Динамическое посредничество сервисов (Service Discovery) управляет установлением локальных и распределенных связей взаимодействия (SWS_CommunicationManagement с. 67). Поставщик сервиса сигнализирует о своей доступности путем вызова OfferService() на скелетоне ([SWS_CM_00101]). Если работа сервиса прекращается или его предоставление отзывается, StopOfferService() отзывает предложение ([SWS_CM_00111]). Потребители определяют подходящие экземпляры сервиса синхронно через FindService() или асинхронно через StartFindService() ([SWS_CM_00122], [SWS_CM_00123], ARAComAPI с. 103). В последнем случае регистрируется FindServiceHandler, который уведомляется при каждом изменении состава экземпляров до тех пор, пока поиск не будет явно остановлен с помощью StopFindService() ([SWS_CM_00125], [SWS_CM_00383]).
Чтобы отвязать исходный код от фиксированных идентификаторов сети и экземпляров, интерфейс допускает адресацию через абстрактные модельные пути с помощью ara::core::InstanceSpecifier ([SWS_CM_00622], [SWS_CM_00623], AUTOSAR_AP_EXP_ARAComAPI с. 124). Промежуточное ПО разрешает эти спецификаторы через сохраненный манифест экземпляра сервиса (Service Instance Manifest) в конкретные ara::com::InstanceIdentifier ([SWS_CM_00118], [SWS_CM_11520], ARAComAPI с. 1). Найденный сервис предоставляется в виде типизированного дескриптора (HandleType) в ServiceHandleContainer ([SWS_CM_10383], AUTOSAR_EXP_SensorInterfaces с. 16). С помощью статического фабричного метода Proxy::Create() или конструктора потребитель создает связанный экземпляр прокси для дальнейшего использования функций ([SWS_CM_10438], [SWS_CM_00131]).
Диаграмма последовательности: процесс предложения сервиса (Service Offering), асинхронного поиска и создания прокси. Источники: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces с. 16
Шаблоны взаимодействия: вызовы методов и асинхронная обработка
Вызовы методов реализуют синхронную и асинхронную парадигму «запрос-ответ». Клиент инициирует методы через оператор вызова функции operator() на прокси ([SWS_CM_00196]). В качестве возвращаемого типа по умолчанию служит ara::core::Future, инкапсулирующий результат или состояние ошибки ([SWS_CM_00191], ARAComAPI с. 1). Потребитель гибко выбирает способ синхронизации: путем блокирующего опроса через get(), ожидания по тайм-ауту через wait_for() или wait_until() либо путем регистрации основанных на событиях функций обратного вызова с помощью then() (ARAComAPI с. 1). Для сугубо однонаправленных уведомлений без ответа существуют методы типа Fire-and-Forget с возвращаемым значением void ([SWS_CM_90434], [SWS_CM_90435]).
На стороне поставщика MethodCallProcessingMode определяет стратегию выполнения входящих вызовов ([SWS_CM_00301], [SWS_CM_00130]). В управляемом событиями режиме (kEvent или kEventSingleThread) вызов метода происходит немедленно в рабочем потоке, управляемом промежуточным ПО (AUTOSAR_SWS_CommunicationManagement с. 60). В режиме опроса (kPoll) приложение самостоятельно детерминированно управляет моментами обработки, регулярно вызывая ProcessNextMethodCall() ([SWS_CM_00199], EXP_SWArchitecture с. 68). Реализация метода формирует результат внутри через ara::core::Promise и возвращает связанный Future (ARAComAPI с. 1).
Диаграмма последовательности: вызов метода между прокси и скелетоном при диспетчеризации kPoll и kEvent. Источники: [SWS_CM_00196], [SWS_CM_00199], AUTOSAR_SWS_CommunicationManagement с. 60
Взаимодействие по событиям и полям в шаблоне «публикация-подписка»
Распределение непрерывных потоков данных и изменений состояний происходит через события и поля в шаблоне «публикация-подписка» (SWS_CommunicationManagement с. 67). Активный подписчик регистрирует свой интерес к приему через Subscribe() с указанием максимального числа сохраняемых сэмплов (maxSampleCount) ([SWS_CM_00141], [SWS_CM_12002]). Состояние подписки опрашивается через GetSubscriptionState() или асинхронно контролируется через функции обратного вызова посредством SetSubscriptionStateChangeHandler() ([SWS_CM_00310], [SWS_CM_00316], [SWS_CM_01110]). Завершение подписки осуществляется через Unsubscribe() ([SWS_CM_00151]).
Прием данных может осуществляться по событиям через SetReceiveHandler() или путем периодического считывания буфера приема ([SWS_CM_00181], [SWS_CM_11356]). С помощью GetNewSamples() потребитель передает функциональный объект (лямбду), который вызывается для каждого поступившего сэмпла с типизированным SamplePtr ([SWS_CM_00701], [SWS_CM_11610]). Во избежание затрат на копирование (Zero-Copy) скелетон выделяет память через Allocate() и отправляет типизированный указатель SampleAllocateePtr с полной передачей права владения через Send() на уровень передачи ([SWS_CM_90438], [SWS_CM_90437], [SWS_CM_00308], AUTOSAR_EXP_ARAComAPI с. 63, ARAComAPI с. 1).
Поле расширяет концепцию событий семантикой геттеров и сеттеров (AUTOSAR_EXP_ARAComAPI с. 68). Потребители считывают поле через Get() или записывают его через Set() ([SWS_CM_00112], [SWS_CM_00113]). На стороне сервера эти запросы обслуживаются с помощью RegisterGetHandler() и RegisterSetHandler() соответственно ([SWS_CM_00114], [SWS_CM_00116]). Если сервер обновляет состояние через Update(), поле автоматически выполняет роль нотификатора и рассылает изменение всем зарегистрированным подписчикам ([SWS_CM_00119], ARAComAPI с. 1).
Диаграмма последовательности: выделение памяти по схеме Zero-Copy, публикация событий, подписка и потребление через GetNewSamples. Источники: [SWS_CM_00141], [SWS_CM_00701], [SWS_CM_90437], AUTOSAR_EXP_ARAComAPI с. 63
Защита, трансляция сервисов и интеграция с платформой
Для критически важных для безопасности и детерминированных потоков данных ara::com интегрирует сквозную защиту (E2E) и аутентификацию в соответствии со стандартами AUTOSAR (AUTOSAR_AP_TR_SystemTests с. 132). Через GetProfileCheckStatus() и GetE2EStateMachineState() потребители могут проверять статус целостности и валидации принятых данных ([SWS_CM_90420], [SWS_CM_90421], [SWS_CM_11554]). На стороне сервера приложение регистрирует процедуры обработки ошибок через SetTransportFaultConditionHandler(), чтобы стандартизированно реагировать на дефекты E2E и транспортировки на уровне методов ([SWS_CM_00093], [SWS_CM_00094], [SWS_CM_00100], EXP_SWArchitecture с. 68).
Криптографическая целостность и аутентичность внешних сообщений обеспечиваются протоколом Secure Onboard Communication (SecOC) (SWS_CommunicationManagement с. 222). Для этого промежуточное ПО подключает заменяемую библиотеку Freshness Value Management (FVM), которая управляет значениями свежести через GetRxFreshness(), GetTxFreshness() и Initialize() ([SWS_CM_11288], [SWS_CM_11289], [SWS_CM_11290], SWS_CommunicationManagement с. 226). Диагностические функции и функции безопасности контролируют или управляют верификацией через специализированные интерфейсы, такие как SetVerificationStatus() ([SWS_CM_19999], AUTOSAR_AP_EXP_SWArchitecture с. 70).
Для функциональной совместимости с AUTOSAR Classic Platform ara::com поддерживает сигнальное взаимодействие (Signal-to-Service Translation) (SWS_CommunicationManagement с. 146, TPS_ManifestSpecification с. 476). Согласно [SWS_CM_10174] и [SWS_CM_80001], классические сигнальные IPDU и сообщения SOME/IP могут транспортироваться через один и тот же сокет. При наличии конфигурации SecOC на основе сигналов промежуточное ПО считывает параметры защиты непосредственно из PDU Triggering манифеста ([SWS_CM_11346], SWS_CommunicationManagement с. 228).
Диаграмма деятельности: конвейер защиты E2E и SecOC для входящих сообщений. Источники: [SWS_CM_90420], [SWS_CM_11288], SWS_CommunicationManagement с. 222
Поведение при ошибке
Управление ошибками в ara::com базируется на типобезопасных доменах ошибок и кодах возврата базового фреймворка AUTOSAR ([SWS_CM_11334], [SWS_CM_11335]). Ошибки общего коммуникационного уровня объединяются в ComErrorDomain и кодируются через перечислитель ComErrc ([SWS_CM_10432]). При ошибках проверки E2E домен ComE2EErrorDomain с помощью значения перечисления ComE2EErrc сигнализирует о специфических ошибках проверки, таких как расхождение контрольных сумм или недействительные счетчики ([SWS_CM_10474], [SWS_CM_12510], [SWS_CM_12511]). Для ошибок свежести SecOC аналогично существует ComSecOcFvmErrorDomain с ComSecOcFvmErrc ([SWS_CM_12521], [SWS_CM_12522]).
Если во время работы происходит обрыв соединения, статус подписки прокси меняется с kSubscribed на kSubscriptionPending ([SWS_CM_00310], [SWS_CM_00316], ARAComAPI с. 32). Вызовы методов на этом этапе завершаются с ошибкой. Если затем поставщик сервиса возвращается через Service Discovery, промежуточное ПО прозрачно обновляет внутреннюю адресацию прокси без необходимости повторной инициализации объекта прокси потребителем; после успешной повторной синхронизации статус автоматически возвращается в kSubscribed (ARAComAPI с. 32). За временные рамки и контроль дедлайнов (Deadline Monitoring) согласно системной спецификации отвечает само прикладное программное обеспечение (TPS_ManifestSpecification с. 504).
Диаграмма состояний: жизненный цикл и состояния соединения экземпляра прокси при изменениях доступности поставщика. Источники: [SWS_CM_00310], [SWS_CM_00316], ARAComAPI с. 32
Дальнейшие подробные доказательства
Основные требования и системные интерфейсы соотносятся со спецификациями AUTOSAR следующим образом:
- Жизненный цикл сервисов и обнаружение: предоставление сервисов и механизмы поиска основаны на [SWS_CM_00101], [SWS_CM_00111], [SWS_CM_00122] и [SWS_CM_00123], подробно описанных в руководстве по архитектуре программного обеспечения (ARAComAPI с. 103).
- Парадигмы взаимодействия: методы и асинхронные будущие значения стандартизированы в [SWS_CM_00191] и [SWS_CM_00196]; подписки на события и передачи сэмплов соответствуют [SWS_CM_00141], [SWS_CM_00701] и [SWS_CM_90437] (SWS_CommunicationManagement с. 67).
- Безопасность и сериализация: концепции защиты для E2E ([SWS_CM_90420]), SecOC ([SWS_CM_90108], [SWS_CM_11288]) и преобразования сигналов в сервисы (Signal-to-Service-Translation) ([SWS_CM_10174]) регулируют общесистемный обмен данными (SWS_CommunicationManagement с. 146, SWS_CommunicationManagement с. 222).
- Определения манифестов и типов: отображение структурированных типов данных, опциональных полей и спецификаторов экземпляров закреплено в спецификации манифеста (TPS_ManifestSpecification с. 161, TPS_ManifestSpecification с. 458).
Настоящее руководство составлено ИИ-ассистентом курации на основе AUTOSAR Adaptive Release R25-11.
Карта тем
ara::com
22Для этого релиза нет данных об элементах
<SI-Namespace>::proxy
Service Interface Proxy
<SI-Namespace>::proxy::fields
Service proxy Field class, one for each Field defined in the ServiceInterface in the role field.
<SI-Namespace>::proxy::methods
Service proxy fire-and-forget method class, one for each ClientServerOperation ( ClientServerOperation.fireAndForget==TRUE) defined in the S
Service proxy method class, one for each ClientServerOperation ( ClientServerOperation.fireAndForget ==FALSE) defined in the ServiceInterfac
<SI-Namespace>::proxy::triggers
Service proxy Trigger class, one for each Trigger defined in the ServiceInterface in the role trigger.
<SI-Namespace>::skeleton
Service skeleton class
<SI-Namespace>::skeleton::fields
Service skeleton Field class, one for each Field defined in the ServiceInterface in the role field.
<SI-Namespace>::skeleton::triggers
Service skeleton Trigger class, one for each Trigger defined in the ServiceInterface in the role trigger.
apext::com::secoc
Defines a class representing the SecOc Freshness Value Manager error domain
наследует от ara::core::ErrorDomain
Defines a class for exceptions to be thrown by the SecOc Freshness Value Manager
наследует от ara::core::Exception
A container to hold the length of freshness value in bits and the freshness value itself
A freshness value management interface to be implemented by the OEM/stack vendor
Returns a reference to the apext::com::secoc::ComSecOcFvmErrorDomain object
constexpr const ara::core::ErrorDomain & GetComSecOcFvmErrorDomain () noexcept;Creates an instance of ara::core::ErrorCode
constexpr ara::core::ErrorCode MakeErrorCode (apext::com::secoc::Com SecOcFvmErrc errorCode, ara::core::ErrorDomain::SupportDataType data) noexcept;Defines the error codes for the apext::com::secoc::ComSecOcFvmErrorDomain
enum class ComSecOcFvmErrc : ara::core::ErrorDomain::CodeType {...};ara::com
Defines a class representing the Communication error domain.
наследует от ara::core::ErrorDomain
Defines a class for exceptions to be thrown by the API.
наследует от ara::core::Exception
The exact definition of ara::com::FindServiceHandle is Communication Management implementation specific
Unique identifier of a specific AdaptivePlatformServiceInstance, to distinguish different instances of exactly the same service
Emulates a std::unique_ptr to an event sample. The ara::com::SamplePtr behaves as a std::unique_ptr as long as the event/ field is subscrib ≙ std::unique_ptr
Specifies a Service Identifier The exact type may be overridden by the Communication Management software provider
Specifies a Service Version
Returns a reference to the ara::com::ComErrorDomain object
constexpr const ara::core::ErrorDomain & GetComErrorDomain () noexcept;Creates an instance of ara::core::ErrorCode
constexpr ara::core::ErrorCode MakeErrorCode (ara::com::ComErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept;Defines the error codes for the ara::com::ComErrorDomain
enum class ComErrc : ara::core::ErrorDomain::CodeType {...};Processing modes for the service implementation.
enum class MethodCallProcessingMode : std::uint8_t {...};The state of the service from GetServiceState()
enum class ServiceState : std::uint8_t {...};The subscription state of an event.
enum class SubscriptionState : std::uint8_t {...};Callback function invoked if new event data arrives for an event. The event receiver must provide the function implementation which is not required to be re-entrant. Usage of std::function is recommended but not mandatory. ≙ std::function
using EventReceiveHandler = std::function<void()>;Callback function invoked if a new notification arrives for a field. The field receiver must provide the function implementation which is not required to be re-entrant. Usage of std::function is recommended but not mandatory. ≙ std::function
using FieldReceiveHandler = std::function<void()>;Callback function invoked if service availability changes. It takes as input parameter a handle container containing handles for all matching service instances and a ara::com:: FindServiceHandle which can be used to invoke StopFindService() from within the ara::com::FindServiceHandler.
using FindServiceHandler = std::function<void(ServiceHandle Container<T>, FindServiceHandle)>;Holds a list of ara::com::InstanceIdentifiers. The assigned data type is allowed to be changed by the Communication Management software provider, but must adhere to [container.requirements.general] and [sequence.reqmts] requirements as per [30] A ara::core::Vector ([SWS_CORE_01301]) for example fulfills these requirements.
using InstanceIdentifierContainer = ara::core::Vector<Instance Identifier>;Pointer to an allocated (by Communication Management) data sample. The implementation is allowed to be changed by the Communication Management software provider.
using SampleAllocateePtr = std::unique_ptr<T>;Holds a list of service handles and is used as a return value of any of the FindService() methods) • [SWS_CM_00122] • [SWS_CM_00622] . The assigned data type is allowed to be changed by the Communication Management software provider, but must adhere to [container.requirements.general] and [sequence.reqmts] requirements as per [30]. A ara::core::Vector ([SWS_CORE_ 01301]) for example fulfills these requirements.
using ServiceHandleContainer = ara::core::Vector<T>;Functor used as input arguments for any of the SetServiceStateChangeHandler() methods: • [SWS_CM_01074] • [SWS_CM_01076]
using ServiceStateHandler = std::function<void(ServiceState)>;Callback function invoked if ara::com::SubscriptionState of an event has changed.
using SubscriptionStateChangeHandler = std::function<void(Subscription State)>;A function wrapper for the handler function that gets called in case a new trigger arrives for an event. The trigger receiver must provide the function implementation which is not required to be re-entrant. Usage of std::function is recommended but not mandatory. ≙ std::function
using TriggerReceiveHandler = std::function<void()>;ara::com::e2e
Defines a class representing the E2E error domain
наследует от ara::core::ErrorDomain
Defines a class for exceptions to be thrown by the E2E APIs
наследует от ara::core::Exception
Returns a reference to the ara::com::e2e::ComE2EErrorDomain object
constexpr const ara::core::ErrorDomain & GetComE2EErrorDomain () noexcept;Creates an instance of ara::core::ErrorCode
constexpr ara::core::ErrorCode MakeErrorCode (ara::com::e2e::ComE2 EErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept;Defines the error codes for the ara::com::e2e::ComE2EErrc
enum class ComE2EErrc : ara::core::ErrorDomain::CodeType {...};The result of the check of a single ara::com::SamplePtr
enum class ProfileCheckStatus : std::uint8_t {...};The state of the E2E supervision after the most recent check of a received sample of the event. If ara::com::e2e::SMState == kValid, and the ara::com::SamplePtr:: GetProfileCheckStatus did not result in an Error then, the last checked sample can be used.
enum class SMState : std::uint8_t {...};Defines the TransportFaultCondition which represent a single transport-related fault event
enum class TransportFaultCondition : std::uint8_t {...};Handler type to be called when one or more (determined by the value of the std::size_t) fault conditions are detected ≙ std::size_t
using TransportFaultConditionHandler = std::function<void(Transport FaultCondition, std::size_t)>;ara::com::runtime
Translates an ara::core::InstanceSpecifier to a ara::com:: InstanceIdentifierContainer. The length/size of the ara::com:: InstanceIdentifierContainer is relative to the number of matches.
ara::core::Result< ara::com::InstanceIdentifierContainer > Resolve InstanceIDs (ara::core::InstanceSpecifier metaModelIdentifier) noexcept;Сервисные интерфейсы
Als ara::com-Dienst modellierte Schnittstelle; Methoden/Felder werden über generierte Proxies/Skeletons aufgerufen (Parameterrichtung IN/OUT).
Als ara::com-Dienst modellierte Schnittstelle; Methoden/Felder werden über generierte Proxies/Skeletons aufgerufen (Parameterrichtung IN/OUT).
Als ara::com-Dienst modellierte Schnittstelle; Methoden/Felder werden über generierte Proxies/Skeletons aufgerufen (Parameterrichtung IN/OUT).
Verwandte Komponenten in anderen Universen
function: 179 class: 20 type alias: 20 variable: 13 enumeration: 10 struct: 4 service method: 2 header file: 1 service event: 1
Пространства имён
- <SI-Namespace>::proxy 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::proxy::fields 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::proxy::methods 2 Klassen, 0 freie Funktionen
- <SI-Namespace>::proxy::triggers 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::skeleton 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::skeleton::fields 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::skeleton::triggers 1 Klassen, 0 freie Funktionen
- apext::com::secoc 4 Klassen, 2 freie Funktionen
- ara::com 7 Klassen, 2 freie Funktionen
- ara::com::e2e 2 Klassen, 2 freie Funktionen
- ara::com::runtime 0 Klassen, 1 freie Funktionen
Сервисные интерфейсы (моделируются через ara::com)
- VerificationStatus 1 Mitglieder
- VerificationStatusConfigurationByDataId 1 Mitglieder
- VerificationStatusConfigurationByFreshnessId 1 Mitglieder
UML-диаграмма классов модуля
Abgerundete Rahmen = Namespaces; hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); graue Boxen = modulfremde bzw. externe Basisklassen. Klicken öffnet die Klassenseite.
gemini-3.8-flash-low· 2026-10-13 · Немецкий оригинал