пространство имён <RoutineInterface-Namespace>

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

больше ›

Контекст

Пространство имён namespace <RoutineInterface-Namespace> является частью функционального кластера diag (Diagnostic Management) стандарта AUTOSAR Adaptive Platform в релизе R25-11. Внутри этого пространства имён класс интерфейса <RoutineInterface> определён как DiagnosticRoutineInterface. Основная роль этого пространства имён заключается в предоставлении стандартизированной основы для инкапсуляции диагностических рутин, выполняемых компонентами прикладного программного обеспечения в транспортном средстве.

Класс <RoutineInterface>, вероятно, служит слоем абстракции между системой управления диагностикой платформы и специфичными для транспортного средства процессами рутин. Вопрос Q-03b9b94f9c2849b0 (открытый) Вышестоящее управление диагностикой обрабатывает внешние диагностические запросы (такие как UDS RoutineControl согласно ISO 14229-1) и перенаправляет их зарегистрированной прикладной рутине. Приложение через реализацию интерфейса предоставляет фактическую логику управления, тестирования и проверки, не имея прямых зависимостей от уровня транспортного протокола или топологий сети.

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

Жизненный цикл экземпляров класса интерфейса <RoutineInterface>, вероятно, тесно связан с состоянием готовности соответствующих диагностических сервисов. Вопрос Q-32a86efa16843445 (открытый) Инстанцирование обычно происходит в ходе фазы инициализации адаптивного приложения, до того как интерфейс будет зарегистрирован в менеджере диагностики и активирован для внешних запросов. При этом приложение берёт на себя ответственность за создание объектов и предоставление необходимых контекстов выполнения.

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

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

Типичный сценарий использования диагностической рутины делится на структурированную последовательность шагов взаимодействия между системой управления диагностикой и прикладной логикой. Процесс, предположительно, включает следующие фазы: Вопрос Q-da2cd4e1ceb5b3b8 (открытый)

1. Инициализация и регистрация: приложение инстанцирует класс <RoutineInterface> и регистрирует объект интерфейса в службе управления диагностикой модуля diag.
2. Запуск рутины: при получении соответствующего диагностического запроса система вызывает метод запуска интерфейса. В результате запускается специфичная для приложения логика, например проверка исполнительного механизма, прогон калибровки или цикл вычислений.
3. Опрос статуса и результата: во время выполнения или после завершения операции промежуточные состояния или окончательный результат могут быть запрошены через соответствующие вызовы интерфейса и переданы системе управления.
4. Завершение или досрочное прерывание: рутина завершается либо штатно после успешной отработки, либо при необходимости контролируемо прерывается по явному запросу остановки от диагностической инфраструктуры.

Сценарии ошибок

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