ECU State Manager (EcuM)

Синхронная и реентерабельная функция EcuM_GoDownHaltPoll предписывает модулю ECU State Manager перейти в режим Sleep, Reset или в состояние OFF в зависимости от ранее выбранной цели отключения [SWS_EcuM_91002]. Она доступна через заголовочный файл EcuM.h и имеет Service-ID 0x2c [SWS_EcuM_91002].

Параметры и право вызова

В качестве единственного входного параметра передается UserID типа EcuM_UserType. Он идентифицирует вызывающего пользователя. Вызов строго регламентирован: выполнять данную функцию разрешено исключительно предварительно сконфигурированным пользователям [SWS_EcuM_91002].

Возвращаемые значения и ход выполнения

Поведение возврата существенным образом зависит от типа установленной цели отключения [SWS_EcuM_91002]:

• E_NOT_OK: запрос не был принят [SWS_EcuM_91002].
• E_OK: если целью является SLEEP, функция успешно возвращается с этим статусом после выхода из режима сна [SWS_EcuM_91002].
• Отсутствие возврата: если в качестве цели отключения было выбрано RESET или OFF, вызов функции больше не возвращается к вызывающему объекту [SWS_EcuM_91002].

Ограничения и обработка ошибок

Хотя функция формально объявлена как реентерабельная, ее выполнение по назначению требует предварительного определения валидной цели отключения [SWS_EcuM_91002]. Специфические коды ошибок DET или DEM в спецификации интерфейса не приведены; сбой или отклонение запроса непосредственно отображаются через возвращаемое значение E_NOT_OK [SWS_EcuM_91002].

Синхронная сервисная функция EcuM_Init инициализирует ECU State Manager и запускает штатный процесс запуска блока управления ([SWS_EcuM_02811]). Она объявляется через заголовочный файл EcuM.h с Service-ID 0x01, не принимает параметров и не возвращает значения ([SWS_EcuM_02811]). Формально классифицированная как реэнтрантная, EcuM_Init после вызова никогда не возвращает управление вызывающему компоненту, поскольку передает выполнение операционной системе путем вызова StartOS ([SWS_EcuM_02811]).

В рамках своего выполнения функция отрабатывает определенную последовательность StartPreOS и ее активности в строго заданном порядке ([SWS_EcuM_02411], [SWS_EcuM_02684]). Существенной составной частью этой фазы является проверка согласованности конфигурации: модуль внутри EcuM_Init проверяет, идентично ли соответствующее поле структуры значению ECUM_CONFIGCONSISTENCY_HASH ([SWS_EcuM_02798]).

Кроме того, EcuM_Init управляет инициализацией драйверов в многоядерных системах ([SWS_EcuM_04145]). Функция вызывает коллауты EcuM_AL_DriverInitZero и EcuM_AL_DriverInitOne на каждом отдельном ядре ([SWS_EcuM_04145]). Для реализаций коллаутов действует требование гарантировать, чтобы на текущем активном ядре инициализировались исключительно те модули MCAL, которые фактически выполняются на этом ядре ([SWS_EcuM_04145]).

Синхронная и нереентерабельная функция EcuM_StartupTwo реализует состояние STARTUP II модуля ECU State Manager [SWS_EcuM_02838]. Интерфейс объявляется через заголовочный файл EcuM.h и имеет Service ID 0x1a [SWS_EcuM_02838]. В соответствии с сигнатурой функции void EcuM_StartupTwo(void) вызов не принимает ни входных, ни входных/выходных, ни выходных параметров и не возвращает значения вызывающему компоненту [SWS_EcuM_02838].

При активации модуля ECU Manager функцией EcuM_StartupTwo он выполняет действия последовательности StartPostOS [SWS_EcuM_02932].

Для интеграции существуют важные требования относительно контекста вызова и параллелизма: функция обязательно должна вызываться из задачи, запускаемой непосредственно в результате StartOS [SWS_EcuM_02806]. Это требует, чтобы вызов EcuM_StartupTwo выполнялся либо из задачи с автостартом (Autostart Task), либо из задачи, запускаемой явно [SWS_EcuM_02806]. Поскольку функция специфицирована как нереентерабельная, одновременный или многократный вызов недопустим [SWS_EcuM_02838].

Синхронная сервисная функция EcuM_Shutdown (Service ID 0x02) предоставляется через заголовочный файл EcuM.h и берет на себя управление выполнением для проведения действий фазы «GO OFF II» [SWS_EcuM_02812]. Она служит для окончательного завершения процесса отключения [SWS_EcuM_02953].

Контекст вызова и семантика

Обычно функция вызывается из Shutdown Hook [SWS_EcuM_02812]. Этот хук в соответствии с требованиями обязан явно вызывать EcuM_Shutdown для завершения процесса отключения [SWS_EcuM_02953].

• Сигнатура: void EcuM_Shutdown(void) с Service ID 0x02 [SWS_EcuM_02812].
• Параметры: отсутствуют входные, выходные или входные/выходные параметры [SWS_EcuM_02812].
• Возвращаемое значение: интерфейс не возвращает значения [SWS_EcuM_02812].
• Синхронность: вызов выполняется синхронно [SWS_EcuM_02812].

Параллелизм и поток управления

В спецификации EcuM_Shutdown объявлена как реентерабельная [SWS_EcuM_02812]. Однако для выполнения программы действует строгое требование: EcuM_Shutdown не должна возвращать управление вызывающему компоненту [SWS_EcuM_02953]. После отработки функция окончательно отключает ECU или, в качестве альтернативы, инициирует сброс [SWS_EcuM_02953].

Использование и контекст вызова

Синхронная функция EcuM_SetState служит для того, чтобы BswM мог сообщить EcuM об изменении состояния [SWS_EcuM_04122]. В качестве входного параметра передается state типа EcuM_StateType, который задает состояние, определенное BswM [SWS_EcuM_04122]. Функция не имеет возвращаемого значения [SWS_EcuM_04122].

Принцип работы и взаимодействие

При вызове функция устанавливает внутреннее состояние EcuM в значение параметра state [SWS_EcuM_04123]. Если BswM таким образом устанавливает состояние EcuM, EcuM сообщает соответствующий режим в RTE [SWS_EcuM_04116].

Обработка ошибок

Если переданное значение параметра state недействительно, EcuM_SetState не изменяет состояние EcuM [SWS_EcuM_04123]. Если активирована функция Development Error Reporting, в этом случае ошибки функция дополнительно сообщает об ошибке ECUM_E_STATE_PAR_OUT_OF_RANGE в модуль DET [SWS_EcuM_04123].

Параллелизм и интерфейс

Выполнение является синхронным и реентерабельным [SWS_EcuM_04122]. Служба объявляется через заголовочный файл EcuM.h [SWS_EcuM_04122].

Использование

Синхронная и реентерабельная функция EcuM_RequestRUN служит для запроса состояния RUN у ECU State Manager [SWS_EcuM_04124]. В качестве параметра через user типа EcuM_UserType передается идентификатор запрашивающей сущности; авторизованными являются исключительно пользователи, о которых диспетчеру состояний стало известно еще во время конфигурации [SWS_EcuM_04124]. Функция возвращает E_OK, если EcuM принял запрос, в противном случае — E_NOT_OK [SWS_EcuM_04124]. Служба объявлена через заголовочный файл EcuM.h [SWS_EcuM_04124].

Обработка ошибок и ограничения

Запросы не должны быть вложенными: отдельный пользователь в один момент времени может удерживать максимум один активный запрос RUN [SWS_EcuM_04125]. Если EcuM_RequestRUN обнаруживает повторные или двойные вызовы одним и тем же пользователем, при активированном обнаружении ошибок разработки код ошибки ECUM_E_MULTIPLE_RUN_REQUESTS сообщается в DET [SWS_EcuM_03024], [SWS_EcuM_04125].

Взаимодействие

Каждый успешно установленный с помощью EcuM_RequestRUN запрос состояния должен быть снова освобожден после завершения активности. Для этого предусмотрена комплементарная, также синхронная и реентерабельная служба EcuM_ReleaseRUN, которой передается тот же ID пользователя [SWS_EcuM_04127].

Использование

Синхронная функция EcuM_ReleaseRUN (идентификатор службы 0x04) служит для освобождения запроса состояния RUN, ранее зарегистрированного через EcuM_RequestRUN [SWS_EcuM_04127]. Интерфейс предоставляется через заголовочный файл EcuM.h и предназначен в первую очередь для реализации портов AUTOSAR [SWS_EcuM_04127]. В качестве входного параметра функция ожидает идентификатор пользователя user типа EcuM_UserType, который однозначно идентифицирует освобождающую сущность внутри модуля [SWS_EcuM_04127].

Возвращаемое значение типа Std_ReturnType сигнализирует с помощью E_OK о том, что запрос на освобождение был успешно принят модулем [SWS_EcuM_04127]. Если освобождение не удалось обработать, служба возвращает значение ошибки E_NOT_OK [SWS_EcuM_04127].

Обработка ошибок и параллелизм

Специфические коды ошибок, ошибки разработки (DET) или производственные ошибки (DEM) в спецификации не приводятся; отклонение запроса выражается исключительно возвратом E_NOT_OK [SWS_EcuM_04127]. Следует предположить (интерпретация:), что возврат E_NOT_OK, вероятно, происходит тогда, когда для указанного идентификатора пользователя нет активного запроса или было передано недопустимое значение параметра. Вопрос Q-cbe9031cffe1be81 (открытый)

Функция объявлена как реэнтрантная и, следовательно, может вызываться в параллельных контекстах выполнения [SWS_EcuM_04127]. В качестве функционального условия последовательности вызов обязательно предполагает, что соответствующий пользователь ранее запросил состояние через EcuM_RequestRUN [SWS_EcuM_04127].

Взаимодействие

Модуль EcuM предоставляет эту службу, чтобы через определённые порты завершить удержание состояния RUN [SWS_EcuM_04127]. Для конфигурации RTE и взаимодействия с локальным поведением во время выполнения RTE спецификация определяет внутреннее поведение EcuStateManager с несколькими параллельно исполняемыми Runnable Entities [SWS_EcuM_03018].

Использование

Синхронная функция EcuM_RequestPOST_RUN служит для запроса состояния POST RUN у ECU State Manager ([SWS_EcuM_04128]). Вызывающий объект идентифицирует себя через параметр user, при этом каждая запрашивающая сущность должна быть сообщена диспетчеру состояний еще во время конфигурации ([SWS_EcuM_04128]). Служба объявлена в заголовочном файле EcuM.h, предназначена для реализации портов AUTOSAR и подтверждает успешное принятие с помощью E_OK или отклонение с помощью E_NOT_OK ([SWS_EcuM_04128]).

Обработка ошибок

Если обнаружение ошибок разработки активировано, повторный вызов тем же пользователем приводит к тому, что EcuM_RequestPOST_RUN сообщает об ошибке ECUM_E_MULTIPLE_RUN_REQUESTS в DET ([SWS_EcuM_03025]). Интерпретация: в случае таких многократных запросов или при недействительных идентификаторах пользователей служба, вероятно, отвечает E_NOT_OK ([SWS_EcuM_04128]). Вопрос Q-b5bbd7d5b53e76ba (открытый)

Параллелизм и взаимодействие

Функция спроектирована как реентерабельная ([SWS_EcuM_04128]). В модуле запросы для RUN и POST RUN должны отслеживаться строго независимо друг от друга через две отдельные переменные ([SWS_EcuM_04128]). Каждый зарегистрированный через эту службу запрос удерживает состояние POST RUN активным до тех пор, пока он не будет явно отозван комплементарным вызовом EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]).

Использование и семантика

Синхронная и реэнтрантная функция EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]) служит для освобождения запроса POST-RUN, ранее установленного с помощью EcuM_RequestPOST_RUN. Через входной параметр user типа EcuM_UserType передаётся идентификатор сущности, которая снова освобождает статус POST-RUN. Интерфейс доступен через заголовочный файл EcuM.h и в первую очередь рассчитан на реализацию портов AUTOSAR ([SWS_EcuM_04129]).

Возвращаемые значения и обработка ошибок

Функция возвращает статус Std_ReturnType ([SWS_EcuM_04129]):

• E_OK: запрос на освобождение был успешно принят ECU State Manager.
• E_NOT_OK: запрос на освобождение был отклонён. Интерпретация: отклонение с E_NOT_OK, вероятно, имеет место, если для указанного пользователя не было зарегистрировано активного запроса или был передан недействительный идентификатор пользователя. Вопрос Q-67bd8594612defca (открытый)

Параллелизм и взаимодействие

Служба специфицирована как реэнтрантная ([SWS_EcuM_04129]), так что одновременные вызовы несколькими сущностями допустимы. Функция является составной частью внутреннего поведения модуля EcuM ([SWS_EcuM_03018]). Вызов логически предполагает, что сущность ранее запросила фазу POST RUN ([SWS_EcuM_04129]). Интерпретация: как правило, вызов, вероятно, осуществляется из программных компонентов через порты RTE, как только их действия по выбегу перед отключением завершены. Вопрос Q-81f71656d4debb4a (открытый)

Синхронная сервисная функция EcuM_SelectShutdownTarget служит для выбора цели завершения работы (shutdown target) для электронного блока управления и предоставляется через заголовочный файл EcuM.h, а также как часть портового интерфейса модуля ECU Manager [SWS_EcuM_02822]. Вызов устанавливает внутреннюю цель завершения работы в значение переданного параметра shutdownTarget [SWS_EcuM_00624].

Функция ожидает два входных параметра [SWS_EcuM_02822]:

• shutdownTarget: определяет выбранную цель завершения работы [SWS_EcuM_02822].
• shutdownMode: содержит идентификатор режима сна (если целью является ECUM_SHUTDOWN_TARGET_SLEEP) или механизма сброса (если целью является ECUM_SHUTDOWN_TARGET_RESET) в соответствии с конфигурацией [SWS_EcuM_02822].

Вызов не инициирует немедленных действий по настройке или выполнению (Setup), а лишь сохраняет значения для последующего использования в фазе SHUTDOWN или SLEEP [SWS_EcuM_02585].

Что касается параллелизма, функция специфицирована как реэнтрантная [SWS_EcuM_02822]. В RTE-Internal-Behavior модуля ECU State Manager соответствующая Runnable Entity SelectShutdownTarget объявлена с canbeInvokedConcurrently = TRUE [SWS_EcuM_03018], благодаря чему параллельные вызовы допустимы.

Возвращаемое значение типа Std_ReturnType сигнализирует с помощью E_OK о том, что новая цель завершения работы была успешно установлена, а с помощью E_NOT_OK — о том, что принятие завершилось неудачей [SWS_EcuM_02822]. Конкретных причин ошибок для E_NOT_OK или сообщений DET спецификация в данном месте не приводит; вероятно, к отклонению приводят недопустимые или несконфигурированные комбинации цели и режима. Вопрос Q-e916f3a6ac0bf47e (открытый)

Синхронная функция EcuM_SelectShutdownCause служит для выбора причины отключения ECU и доступна через заголовочный файл EcuM.h [SWS_EcuM_04050].

Использование и семантика:

• Параметры: входной параметр target типа EcuM_ShutdownCauseType передает выбранную причину выключения [SWS_EcuM_04050].
• Возвращаемое значение: возвращаемое значение типа Std_ReturnType сигнализирует с помощью E_OK о том, что новая причина была успешно установлена, а с помощью E_NOT_OK — о том, что установка не удалась [SWS_EcuM_04050].
• Выполнение: служба работает синхронно с Service-ID 0x1b и специфицирована как реентерабельная [SWS_EcuM_04050].

Конкурентность и взаимодействие:

Функция является частью интерфейса портов модуля ECU Manager [SWS_EcuM_04050]. Для конфигурации локальной RTE во внутреннем поведении EcuStateManager определена исполняемая сущность (Runnable Entity) SelectShutdownCause с символом EcuM_SelectShutdownCause, при этом присвоено свойство canbeInvokedConcurrently = TRUE [SWS_EcuM_03018].

Обработка ошибок:

В объеме спецификации специфические сообщения DET или DEM не указаны; состояния ошибок при установке причины отображаются исключительно через возвращаемое значение E_NOT_OK [SWS_EcuM_04050].

Синхронная сервисная функция EcuM_ClearWakeupEvent (Service-ID 0x16) служит для сброса событий пробуждения и доступна через заголовочный файл EcuM.h [SWS_EcuM_02828]. В качестве параметра она принимает битовую маску sources типа EcuM_WakeupSourceType и не имеет возвращаемого значения [SWS_EcuM_02828].

При вызове все ожидающие события, установленные в виде бита в sources, удаляются из трех внутренних переменных модуля [SWS_EcuM_02683]:

• из внутренней переменной для ожидающих событий пробуждения (pending wakeup events),
• из внутренней переменной для подтвержденных событий пробуждения (validated events), а также
• из внутренней переменной для истекших событий пробуждения (expired events) [SWS_EcuM_02683].

В отношении контекста вызова EcuM_ClearWakeupEvent может гибко вызываться из контекста прерывания, из регулярного контекста OS, а также из контекста без OS [SWS_EcuM_02807]. В то же время функция обязательно специфицирована как нереэнтрантная (Non-Reentrant) и непрерываемая (Non-Interruptible) [SWS_EcuM_02828]. Интерпретация: поскольку функция допустима в различных контекстах, но является непрерываемой, интегратор или вызывающий компонент организационно должен обеспечить отсутствие одновременных или прерывающих друг друга вызовов. Вопрос Q-71a4b1b218505a1c (открытый)

Синхронная функция EcuM_AbortWakeupAlarm служит для отмены будильника пробуждения, ранее установленного пользователем [SWS_EcuM_04061]. Интерфейс доступен через заголовочный файл EcuM.h и является составной частью портового интерфейса модуля ECU-менеджера [SWS_EcuM_04061].

Параметры и возвращаемые значения

• user (In): идентификатор пользователя типа EcuM_UserType, который хочет отменить будильник пробуждения [SWS_EcuM_04061]. Входные/выходные или чисто выходные параметры отсутствуют [SWS_EcuM_04061].
• E_OK: сервис успешно выполнен, и будильник отменён [SWS_EcuM_04061].
• ECUM_E_NOT_ACTIVE: активный будильник, принадлежащий переданному пользователю, не найден [SWS_EcuM_04061].
• E_NOT_OK: выполнение службы завершилось сбоем [SWS_EcuM_04061].

Параллелизм и взаимодействие

Функция имеет Service-ID 0x24 и специфицирована как реентерабельная [SWS_EcuM_04061]. Таким образом, вызовы для разных пользователей могут выполняться параллельно. Внутреннее поведение ECU-менеджера определяет исполняемые сущности для конфигурации локальной RTE [SWS_EcuM_03018]; как часть портового интерфейса модуля вызов обычно должен инициироваться программными компонентами через RTE. Вопрос Q-2c8f004d9f00bbd3 (открытый)

Синхронная и реентерабельная функция EcuM_SetClock служит согласно [SWS_EcuM_04064] для установки внутреннего времени ECU State Manager на заданное значение. Будучи частью интерфейса портов ECU Manager, функция может быть подключена и вызвана через заголовочный файл EcuM.h [SWS_EcuM_04064].

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

• user (тип EcuM_UserType): идентификатор вызывающей стороны или пользователя, желающего установить время.
• time (тип EcuM_TimeType): абсолютное значение времени в секундах с момента подключения аккумулятора (Battery Connect).

В качестве возвращаемого значения служба возвращает статус Std_ReturnType с E_OK при успешном выполнении или E_NOT_OK в случае ошибки [SWS_EcuM_04064]. Конкретные причины ошибок или сообщения DET на интерфейсе не специфицированы; предположительно, передача неавторизованных идентификаторов пользователей или недопустимых значений времени приводит к возврату E_NOT_OK. Вопрос Q-248768580c0309e8 (открытый)

Что касается внутреннего поведения модуля и конфигурации RTE, функция интегрируется в структуру исполняемых сущностей (Runnable Entities) EcuStateManager [SWS_EcuM_03018].

Синхронная функция EcuM_SelectBootTarget служит для выбора boot-target для блока управления, входит в состав интерфейса портов ECU Manager и доступна через заголовочный файл EcuM.h [SWS_EcuM_02835]. Требуемая цель передается через входной параметр target типа EcuM_BootTargetType [SWS_EcuM_02835].

В качестве возвращаемого значения функция E_OK сигнализирует о том, что новый boot-target принят EcuM, в противном случае — E_NOT_OK [SWS_EcuM_02835]. Реализация должна сохранять выбранную цель способом, совместимым с загрузчиком [SWS_EcuM_02247]. Текущее установленное значение можно запросить через комплементарную службу EcuM_GetBootTarget [SWS_EcuM_02836].

Функция специфицирована как реэнтрантная [SWS_EcuM_02835]; в рамках внутреннего поведения для конфигурации RTE исполняемая сущность (Runnable Entity) SelectBootTarget объявлена с canbeInvokedConcurrently = TRUE [SWS_EcuM_03018]. В качестве ограничения действует то, что данная служба предназначена исключительно для программных компонентов (SW-C), связанных с диагностикой или управлением загрузкой, и может зависеть от конкретно используемого загрузчика [SWS_EcuM_03000].

EcuM_ValidateWakeupEvent — это синхронная служба (Service-ID 0x14), которая сигнализирует модулю ECU Manager о том, что переданные в параметре sources источники пробуждения успешно валидированы ([SWS_EcuM_02829]). После пробуждения ECU State Manager ожидает этого подтверждения в последовательности валидации. При вызове функция останавливает текущий таймер таймаута валидации ([SWS_EcuM_02710]) и заносит переданные события путем побитовой операции ИЛИ маски во внутреннюю переменную для подтвержденных событий пробуждения ([SWS_EcuM_04078]).

Функция является реэнтрантной ([SWS_EcuM_02829]) и может вызываться как из контекста задачи, так и из контекста прерывания ([SWS_EcuM_02345]). Если ECU Manager находится в состоянии RUN, вызов остается бездействующим для всех источников пробуждения, если только они не являются каналами связи ([SWS_EcuM_02790]). Для источников, сопоставленных с каналом связи, служба, напротив, оказывает неограниченное действие в любой фазе ECU ([SWS_EcuM_02791]).

В общем процессе служба тесно взаимодействует с валидацией пробуждения и управлением связью:

• Проверка валидации: ECU Manager вызывает для проверки коллаут EcuM_CheckValidation; при обнаружении действительного события пробуждения обратная связь осуществляется через EcuM_ValidateWakeupEvent ([SWS_EcuM_02925]).
• Конфигурация: если для источника пробуждения протокол валидации не сконфигурирован (EcuMValidationTimeout), то уже EcuM_SetWakeupEvent подразумевает вызов EcuM_ValidateWakeupEvent ([SWS_EcuM_02566]).
• Уведомление: если для источника пробуждения сконфигурировано EcuMComMChannelRef, служба вызывает ComM_EcuM_WakeUpIndication ([SWS_EcuM_02645]). При сконфигурированном EcuMComMPNCRef дополнительно для каждого указанного PNC инициируется ComM_EcuM_PNCWakeUpIndication ([SWS_EcuM_04140]).

Синхронная и нереэнтрантная функция обратного вызова EcuM_ErrorHook (предоставляемая через EcuM_Externals.h) вызывается модулем ECU State Manager при возникновении серьезных ошибок, которые делают невозможной штатную дальнейшую обработку и требуют останова блока управления [SWS_EcuM_02904]. Через входной параметр reason передается конкретная причина ошибки [SWS_EcuM_02904].

К определенным причинам ошибок относятся ECUM_E_RAM_CHECK_FAILED и ECUM_E_CONFIGURATION_DATA_INCONSISTENT [SWS_EcuM_02904]. Если проверка RAM при пробуждении завершается сбоем, ECU Manager обязан инициировать EcuM_ErrorHook с причиной ECUM_E_RAM_CHECK_FAILED [SWS_EcuM_02987]. Кроме того, обработка ошибок через этот хук выполняется в случае, когда вызов функции операционной системы терпит сбой и никакая другая реакция на ошибку не специфицирована; в этом случае EcuM остается в прежнем состоянии [SWS_EcuM_04139].

Для системного интегратора при реализации действуют следующие рамочные условия:

• Способ останова блока управления: интегратор выбирает способ, которым останавливается ECU (например, сброс, останов, перезапуск или безопасное состояние) [SWS_EcuM_02904]. Интерпретация: при радикальных мерах, таких как сброс или останов, функция, как правило, больше не должна возвращаться к штатному управлению выполнением. Вопрос Q-59c23e3a2569f670 (открытый)
• Сообщение об ошибке в DEM: решение о передаче ошибки в DEM остается на усмотрение интегратора при условии, что гарантируется отсутствие записи модулем DEM в поврежденные блоки NVRAM [SWS_EcuM_02987].

Использование и условия вызова

Callout-функция EcuM_AL_SetProgrammableInterrupts вызывается модулем ECU State Manager для конфигурации и установки соответствующих прерываний на блоках управления ECU с программируемыми контроллерами прерываний [SWS_EcuM_04085]. Однако выполнение этого callout происходит только в том случае, если конфигурационный параметр EcuMSetProgrammableInterrupts установлен в значение true [SWS_EcuM_04085]. Если этот параметр не активирован, вызов не производится [SWS_EcuM_04085]. Для интеграторов и платформенных драйверов объявление интерфейса предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_04085].

Интерфейс имеет синтаксис void EcuM_AL_SetProgrammableInterrupts (void) и сопоставлен с Service ID 0x4A [SWS_EcuM_04085]. Вызов полностью безнараметрический: не передаются ни входные, ни входные/выходные, ни выходные параметры, и функция не возвращает значения вызывающему модулю [SWS_EcuM_04085].

Параллелизм и ограничения

Для EcuM_AL_SetProgrammableInterrupts в спецификации определено асинхронное поведение выполнения (Asynchronous) [SWS_EcuM_04085]. В отношении параллелизма функция классифицирована как нереентерабельная (Non Reentrant) [SWS_EcuM_04085]. Для интеграции это означает, что параллельные или вложенные вызовы интерфейса недопустимы, и конфигурация прерываний должна выполняться без одновременных повторных входов [SWS_EcuM_04085].

Использование

Коллаут-функция EcuM_AL_DriverInitZero (Service-ID 0x31) вызывается синхронно, не имеет ни параметров, ни возвращаемого значения и является нереэнтрантной [SWS_EcuM_02905]. Она объявлена через заголовочный файл EcuM_Externals.h [SWS_EcuM_02905]. Функция служит для обеспечения ранней инициализации драйверов, а также базовых действий по запуску аппаратного обеспечения, которые строго необходимы для последующей возможности загрузки конфигурационных данных Post-Build [SWS_EcuM_02905].

Ограничения и многоядерный режим

Для реализации и выполнения действуют специфические требования и ограничения:

• Классы конфигурации: в этот ранний момент времени разрешается использовать исключительно модули, конфигурируемые как Pre-Compile или Link-Time [SWS_EcuM_02905]. Конфигурируемые на этапе Post-Build драйверы здесь еще недоступны.
• Контекст вызова: функция вызывается посредством EcuM_Init на каждом Core системы [SWS_EcuM_04145].
• Инициализация для конкретного Core: реализация коллаута должна гарантировать, чтобы на текущем активном Core инициализировались только те модули MCAL, которые фактически выполняются на этом конкретном Core [SWS_EcuM_04145].

Возвращаемые значения, специфические коды ошибок или уведомления через DET либо DEM для данного коллаута не определены [SWS_EcuM_02905].

Функция EcuM_DeterminePbConfiguration ([SWS_EcuM_02906]) представляет собой синхронный кол-аут ECU State Manager, который предоставляется через заголовочный файл EcuM_Externals.h и имеет Service-ID 0x32. Интерфейс не имеет входных, выходных или входных/выходных параметров ([SWS_EcuM_02906]). Ее центральная цель заключается в том, чтобы во время процесса запуска на основе условий оборудования или памяти определить, какой набор данных конфигурации Post-Build должен использоваться для дальнейшего хода запуска системы ([SWS_EcuM_02906]).

Для определения конфигурации кол-аут должен оценивать внешние или резидентные критерии, такие как состояние вывода порта или значение в NVRAM ([SWS_EcuM_02906]). Затем функция должна загрузить эти данные конфигурации в сегмент памяти, к которому могут обращаться все BSW-модули ([SWS_EcuM_02906]). В качестве возвращаемого значения она возвращает указатель типа const EcuM_ConfigType* на конфигурацию Post-Build EcuM ([SWS_EcuM_02906]). Этот указатель образует общую исходную основу для всей BSW, так как структура содержит указатели на соответствующие конфигурации Post-Build всех остальных BSW-модулей ([SWS_EcuM_02906]).

Что касается поведения при вызове, функция специфицирована как синхронная и нереентерабельная (Non Reentrant) ([SWS_EcuM_02906]). Специфические коды ошибок, особые возвращаемые значения ошибок, а также интерфейсы к DET или DEM для этого кол-аута не определены ([SWS_EcuM_02906]). Поэтому в качестве интерпретации требований можно считать, что специфичная для приложения реализация кол-аута должна самостоятельно обрабатывать ошибочные состояния, поскольку отсутствие валидного указателя конфигурации, вероятно, препятствовало бы упорядоченному запуску зависимых BSW-модулей. Вопрос Q-b9487647fb39a2e2 (открытый)

Использование и семантика

Функция EcuM_AL_DriverInitOne является коллаут-функцией менеджера состояний ECU (EcuM), которая предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02907]. Ее основная задача состоит в том, чтобы в случае Power-on-Reset выполнить инициализацию драйверов, а также дальнейшие связанные с аппаратным обеспечением действия по запуску блока управления [SWS_EcuM_02907]. Поскольку речь идет о коллауте, конкретная реализация инициализации аппаратного обеспечения и драйверов, по-видимому, должна осуществляться соответствующим системным интегратором. Вопрос Q-e22baf2fa31cf075 (открытый)

Интерфейс имеет C-сигнатуру void EcuM_AL_DriverInitOne (void) и сопоставлен с Service-ID 0x33 [SWS_EcuM_02907]. Он не принимает никаких входных параметров, а также не возвращает значения вызывающему компоненту [SWS_EcuM_02907].

Параллелизм и ограничения

Для вызова и поведения во время выполнения согласно [SWS_EcuM_02907] действуют следующие граничные условия:

• Синхронность: выполнение происходит синхронно (Synchronous), так что вызывающий компонент ожидает завершения действий по запуску.
• Реэнтрантность: функция определена как нереэнтрантная (Non Reentrant); одновременный или прерывающий многократный вызов недопустим.
• Контекст вызова: активация специфицирована исключительно для фазы инициализации непосредственно после Power-on-Reset.

Обработка ошибок

Поскольку EcuM_AL_DriverInitOne имеет тип возвращаемого значения void, на уровне интерфейса не существует прямой обратной связи об успехе или ошибке инициализации [SWS_EcuM_02907]. Специфические коды ошибок, сообщения DET или DEM в приведенном объеме спецификации для данного коллаута не определены.

Функция EcuM_LoopDetection представляет собой колбэк ECU State Manager с Service ID 0x4B, предоставляемый через заголовочный файл EcuM_Externals.h [SWS_EcuM_04137].

Использование и контекст вызова

Если параметр конфигурации EcuMResetLoopDetection установлен в true, этот колбэк синхронно вызывается при каждом запуске (Startup) [SWS_EcuM_04137]. Функция не имеет ни входных, ни входных/выходных, ни выходных параметров и не возвращает значения (сигнатура: void EcuM_LoopDetection (void)) [SWS_EcuM_04137].

Параллелизм и ограничения

Выполнение EcuM_LoopDetection специфицировано как синхронное и нереентерабельное (Non Reentrant) [SWS_EcuM_04137]. Поскольку это колбэк, конкретная реализация обнаружения циклов обычно возлагается на интегратора или пользователя для фиксации повторяющихся циклов сброса при запуске системы.

Использование

Функция EcuM_OnGoOffOne служит для оповещения о достижении состояния системы GO OFF I и предоставления системному разработчику возможности предпринять соответствующие меры непосредственно перед переходом [SWS_EcuM_02916]. Функция выполняется синхронно, не ожидает передаваемых параметров (ни in, ни inout) и не возвращает значения (void) [SWS_EcuM_02916]. Поскольку интерфейс объявляется через заголовочный файл EcuM_Externals.h, логично предположить, что речь идет о зависящей от пользователя callout-функции, реализуемой в коде интеграции [SWS_EcuM_02916]. Вопрос Q-93de53c47a5a6142 (открытый)

Обработка ошибок

В спецификации для EcuM_OnGoOffOne не приведены ни ошибки разработки (DET), ни производственные ошибки (DEM), ни специфические возвращаемые значения ошибок [SWS_EcuM_02916]. Из этого можно сделать вывод, что вызывающий компонент не ожидает стандартизированного управления ошибками, и возможные исключительные ситуации должны автономно обрабатываться в рамках пользовательской реализации [SWS_EcuM_02916].

Параллелизм и ограничения

Для контекста вызова и поведения во время выполнения определены следующие свойства [SWS_EcuM_02916]:

• Реентерабельность: функция специфицирована как нереентерабельная (Non Reentrant) и ни в коем случае не должна вызываться параллельно или вложенно [SWS_EcuM_02916].
• Синхронность: семантика строго синхронная (Synchronous), поэтому вызывающий компонент ожидает полного возврата из функции [SWS_EcuM_02916].
• Service ID: служба внутренне представлена шестнадцатеричным идентификатором 0x3C [SWS_EcuM_02916].

Из-за синхронного поведения и предстоящего перехода в состояние GO OFF I следует предположить, что блокирующих операций необходимо избегать, чтобы недопустимо не задерживать процесс отключения или перехода [SWS_EcuM_02916]. Вопрос Q-93f5e23c581f0c38 (открытый)

Согласно спецификации, синхронная функция EcuM_OnGoOffTwo служит для того, чтобы дать системному разработчику возможность получить уведомление о непосредственном приближении состояния GO OFF II [SWS_EcuM_02917]. Вызов выполняется без параметров (без входных (In), входных/выходных (Inout) или выходных (Out) параметров) и не возвращает вызывающей стороне никакого значения [SWS_EcuM_02917].

С точки зрения контекста выполнения и параллелизма интерфейс снабжён Service-ID 0x3D и специфицирован как нереентерабельный (Non Reentrant) [SWS_EcuM_02917]. Он предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02917]. Интерпретация: поскольку объявление находится в EcuM_Externals.h и служит для уведомления системного разработчика, функция, вероятно, спроектирована как синхронный callout управления электронным блоком управления, вызываемый перед переходом в состояние GO OFF II. Вопрос Q-bb0ae6e4632de827 (открытый)

В силу свойства интерфейса как нереентерабельного вызов не должен повторяться параллельно или с прерыванием [SWS_EcuM_02917]. Специфические коды ошибок, обратная связь в DET или DEM, а также отдельные механизмы обработки ошибок в объёме спецификации не определены [SWS_EcuM_02917].

Использование

Callout-функция EcuM_AL_SwitchOff является частью модуля ECU State Manager (EcuM) и служит для размещения пользовательского кода отключения электропитания ECU [SWS_EcuM_02920]. Интерфейс определён как синхронный, имеет Service-ID 0x3E и предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02920].

Согласно спецификации функция не принимает ни входных, ни входных/выходных, ни выходных параметров и не имеет возвращаемого значения (void) [SWS_EcuM_02920]. Если аппаратное обеспечение ECU не может самостоятельно отключить питание, спецификация предусматривает, что адекватной реакцией вместо этого может являться инициирование сброса [SWS_EcuM_02920].

Взаимодействие и параллелизм

Вызов EcuM_AL_SwitchOff обязательно выполняется модулем ECU Manager, как только выбранной целью останова становится OFF [SWS_EcuM_04075]. В отношении поведения при параллелизме callout определён как нереентерабельный (Non Reentrant) [SWS_EcuM_02920]. Интерпретация: поскольку целью функции является полное отключение электропитания или, в качестве альтернативы, сброс, данный callout, вероятно, представляет собой завершающий шаг последовательности отключения, после которого регулярное выполнение программы больше не происходит. Вопрос Q-e8a1aaa1413bbea9 (открытый)

Обработка ошибок

Для callout в спецификации не предусмотрено ни специфических кодов ошибок, ни механизмов обработки ошибок, ни сообщений в DET или DEM [SWS_EcuM_02920].

Callout EcuM_AL_Reset служит для размещения интеграционного кода, отвечающего за сброс ECU ([SWS_EcuM_04065]). Интерфейс объявляется через заголовочный файл EcuM_Externals.h и имеет Service-ID 0x4C ([SWS_EcuM_04065]).

Вызов функции является синхронным и определен как нереентерабельный (Non Reentrant) ([SWS_EcuM_04065]). В качестве единственного входного параметра передается reset типа EcuM_ResetType, который определяет конкретный тип выполняемого сброса ([SWS_EcuM_04065]). Функция не имеет возвращаемого значения (void) и не содержит параметров для вывода или ввода/вывода ([SWS_EcuM_04065]).

В рамках взаимодействия в фазе завершения работы (Shutdown) определено, что модуль ECU Manager обязан вызвать колбэк (callout) EcuM_AL_Reset, если целевым состоянием завершения работы является RESET ([SWS_EcuM_04074]). Для этого колбэка в спецификации не предусмотрено ни кодов ошибок, ни уведомлений для DET или DEM ([SWS_EcuM_04065]). Интерпретация: по всей видимости, колбэк выполняет низкоуровневые команды управления, непосредственно вызывающие сброс MCU. Вопрос Q-1e318404843faabd (открытый)

Функция EcuM_EnableWakeupSources представляет собой синхронный callout ECU-менеджера с Service-ID 0x3F, объявляемый через заголовочный файл EcuM_Externals.h [SWS_EcuM_02918]. Она служит для информирования системного разработчика о приближении состояния SLEEP, чтобы указанные в битовом поле wakeupSource (тип EcuM_WakeupSourceType) источники пробуждения могли быть соответствующим образом подготовлены и настроены [SWS_EcuM_02918].

Использование и взаимодействие

ECU-менеджер выполняет EcuM_EnableWakeupSources для настройки источников пробуждения для следующего спящего режима; это происходит для каждого источника пробуждения, настроенного в EcuMWakeupSourceMask для намеченного спящего режима [SWS_EcuM_02389]. Функция не имеет возвращаемого значения (void) и ожидает битовое поле wakeupSource в качестве входного параметра [SWS_EcuM_02918].

Параллелизм и ограничения

• Реэнтерабельность: функция специфицирована как нереэнтерабельная (Non Reentrant) [SWS_EcuM_02918].
• Синхронность: обработка выполняется синхронно [SWS_EcuM_02918].
• Обработка ошибок: в объёме спецификации интерфейса специфические сообщения об ошибках DET или DEM не определены [SWS_EcuM_02918].

Функция EcuM_GenerateRamHash служит для генерации контрольного значения RAM в контексте ECU State Manager, при этом спецификация относительно принципа работы ссылается на EcuM_CheckRamHash [SWS_EcuM_02919]. Сгенерированное контрольное значение, предположительно, служит для последующей проверки целостности оперативной памяти в связи с состояниями сна или покоя. Вопрос Q-7f316b389e1609c0 (открытый)

Использование и интерфейс

Сервис имеет Service-ID 0x40 и сигнатуру void EcuM_GenerateRamHash(void) [SWS_EcuM_02919]. Функция не имеет ни входных, ни выходных, ни входных/выходных параметров и не возвращает значения. Выполнение происходит синхронно.

Параллелизм и ограничения

Функция специфицирована как нереентерабельная (Non Reentrant) [SWS_EcuM_02919]. Следовательно, её нельзя вызывать с прерыванием или параллельно из нескольких контекстов. Объявление предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02919]. Интерпретация: судя по определению в EcuM_Externals.h, речь, вероятно, идёт о callout-функции, реализуемой пользователем, которая вызывается модулем ECU State Manager в подходящий момент последовательности состояний. Вопрос Q-2f53f1a19cee079c (открытый)

Обработка ошибок

Для EcuM_GenerateRamHash в [SWS_EcuM_02919] не определены ни специфические коды ошибок, ни сообщения DET или DEM.

Использование и контекст вызова

Функция EcuM_SleepActivity представляет собой callout модуля ECU State Manager, предоставляемый в заголовочном файле EcuM_Externals.h с Service ID 0x41 [SWS_EcuM_02928]. Вызов выполняется периодически во всех режимах сна со сниженной тактовой частотой процессора (reduced clock sleep modes) [SWS_EcuM_02928]. Функция имеет сигнатуру void EcuM_SleepActivity(void), работает синхронно и не принимает ни входных, ни выходных, ни входных/выходных параметров [SWS_EcuM_02928].

Функциональные задачи и взаимодействие

Назначением этого callout является выполнение действий во время сна: внутри EcuM_SleepActivity явно предусмотрен и разрешен циклический опрос источников пробуждения (Polling) [SWS_EcuM_02928]. Кроме того, непосредственно из callout разрешено вызывать функции уведомления о пробуждении, чтобы сигнализировать модулю ECU State Manager о выходе из состояния сна [SWS_EcuM_02928].

Параллелизм и ограничения

Интерфейс специфицирован как нереентерабельный (Non Reentrant) [SWS_EcuM_02928]. Поскольку callout не возвращает значения и параметры ошибок не определены, прямая обработка ошибок через интерфейс функции посредством кодов ошибок или таких средств оповещения, как DET или DEM, не выполняется [SWS_EcuM_02928].

Использование и контекст вызова

Согласно [SWS_EcuM_04096], синхронный интерфейс EcuM_StartCheckWakeup вызывается прошивкой ECU для запуска таймера CheckWakeupTimer для определенного источника пробуждения. Для этого функции передается параметр WakeupSource типа EcuM_WakeupSourceType. Она не имеет возвращаемого значения (void) и предоставляется через заголовочный файл EcuM_Externals.h.

Последовательность выполнения и условия

Выполнение функции зависит от конфигурации источника пробуждения [SWS_EcuM_04096]:

• Если для соответствующего источника пробуждения сконфигурировано EcuMCheckWakeupTimeout > 0, запускается сопутствующий CheckWakeupTimer.
• Если действует EcuMCheckWakeupTimeout <= 0, вызов функции полностью игнорируется EcuM.

Параллелизм и обработка ошибок

Функция специфицирована как нереентерабельная (Non Reentrant) [SWS_EcuM_04096]. Следовательно, вызывающая сторона должна гарантировать, что вызовы для одного и того же или других источников пробуждения не выполняются параллельно. Специфические коды ошибок, а также уведомления в DET или DEM для этого вызова не специфицированы; вызов при неположительном таймауте согласно спецификации остается без последствий, что, предположительно, можно интерпретировать как толерантный перехват неактуальных проверок таймера [SWS_EcuM_04096]. Вопрос Q-19d98b03d3ee7504 (открытый)

Callout EcuM_CheckWakeup служит для проверки и опроса источников пробуждения, а также для конфигурации PLL после события пробуждения [SWS_EcuM_02929]. Функция предоставляется через заголовочный файл EcuM_Externals.h и имеет Service-ID 0x42 [SWS_EcuM_02929].

Контекст вызова и семантика

• Сигнатура и параметры: функция выполняется синхронно (Synchronous), не имеет возвращаемого значения и ожидает wakeupSource типа EcuM_WakeupSourceType в качестве входного параметра [SWS_EcuM_02929].
• Вызывающие стороны: callout вызывается модулем EcuM для циклического опроса источника пробуждения. Кроме того, он обязательно должен вызываться из процедуры обработки прерывания (ISR) источника пробуждения для настройки PLL и проверки других источников пробуждения, подключённых к тому же прерыванию [SWS_EcuM_02929].
• Цикл опроса: в последовательности опроса EcuM повторно вызывает callout-функции EcuM_SleepActivity и EcuM_CheckWakeup в блокирующем цикле до тех пор, пока о событии пробуждения не будет сообщено как об ожидающем обработки или валидированном [SWS_EcuM_03020].

Ограничения и обработка ошибок

Функция специфицирована как нереентерабельная (Non Reentrant) [SWS_EcuM_02929]. Поскольку вызовы происходят как из блокирующего хода последовательности опроса, так и из контекстов ISR, интеграция, вероятно, должна гарантировать отсутствие некоординированных параллельных вызовов. Вопрос Q-8bc8f164670a0911 (открытый) Специфические коды ошибок или уведомления об ошибках в DET или DEM для этого callout не определены.

Синхронная функция EcuM_EndCheckWakeup вызывается программными модулями, когда асинхронная проверка источника пробуждения (как, например, в случае с асинхронным драйвером трансивера CAN) дает отрицательный результат, то есть событие пробуждения от этого источника отсутствует [SWS_EcuM_02927].

Использование и параметры

Через входной параметр WakeupSource типа EcuM_WakeupSourceType передается тот источник пробуждения, для которого должен быть отменен соответствующий таймер контроля [SWS_EcuM_02927]. Функция не возвращает значения (void) и не имеет входных/выходных или выходных параметров [SWS_EcuM_02927].

Принцип работы и параллелизм

• Функция отменяет таймер CheckWakeupTimer для указанного источника пробуждения; с отменой этого таймера проверка источника пробуждения считается завершенной [SWS_EcuM_02927].
• Интерфейс определен как синхронный и нереентерабельный (Non Reentrant) [SWS_EcuM_02927].
• Объявление предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02927].

Функция EcuM_CheckRamHash представляет собой синхронный нереентерабельный callout (объявленный в EcuM_Externals.h), обеспечивающий тест целостности памяти RAM [SWS_EcuM_02921]. Функция не имеет параметров и возвращает значение статуса типа uint8: значение 0 сигнализирует о неудачном завершении теста, тогда как любое другое значение указывает на успешное прохождение [SWS_EcuM_02921].

Согласно [SWS_EcuM_02863] модуль EcuM перед остановом микроконтроллера сначала вызывает [SWS_EcuM_02919], а после возврата из состояния останова выполняет EcuM_CheckRamHash. Целью является проверка того, что содержимое RAM осталось согласованным даже после длительной фазы SLEEP [SWS_EcuM_02921].

Для реализации и последовательности действий действуют следующие граничные условия:

• Алгоритм и область проверки: функция проверки предоставляется системным разработчиком; она не обязательно должна быть исчерпывающей, однако должна выполняться быстро и с достаточной надёжностью обнаруживать ошибки [SWS_EcuM_02921]. Проверяемые области следует выбирать тщательно; содержимое стека выполняющейся задачи, как правило, проверить невозможно [SWS_EcuM_02921].
• Структура задач: передовой практикой считается выполнение генерации и проверки хэша в одной и той же непрерываемой задаче при минимальной промежуточной активности [SWS_EcuM_02921].
• Многоядерные конфигурации: при наличии нескольких процессорных ядер с сателлитными модулями EcuM callout вызывается исключительно мастер-модулем EcuM и проверяет только данные в пределах его досягаемости [SWS_EcuM_02863], [SWS_EcuM_02921].

Специфические сообщения DET или DEM для этого callout не определены; реакция на ошибку при возвращаемом значении 0, вероятно, остаётся на усмотрение вышестоящего системного дизайна [SWS_EcuM_02921]. Вопрос Q-473ef8617db29fe3 (открытый)

Синхронный интерфейс EcuM_DisableWakeupSources с Service-ID 0x44 служит для того, чтобы настроить источники пробуждения, определенные в битовом поле параметра wakeupSource типа EcuM_WakeupSourceType, таким образом, чтобы они больше не могли разбудить ECU [SWS_EcuM_02922]. Сигнатура функции имеет вид void EcuM_DisableWakeupSources (EcuM_WakeupSourceType wakeupSource) [SWS_EcuM_02922].

Для контекста вызова и интеграции в соответствии со спецификацией действуют следующие свойства:

• Вызывающий модуль и заголовочный файл: функция вызывается модулем ECU Manager и предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02922].
• Параметры и возвращаемые значения: в качестве единственного входного параметра передается битовое поле wakeupSource. Функция не имеет ни входных/выходных, ни выходных параметров и не возвращает значения (void) [SWS_EcuM_02922].
• Семантика выполнения и параллелизм: обработка выполняется синхронно. Кроме того, функция специфицирована как нереентерабельная (Non Reentrant), поэтому одновременных или вложенных вызовов необходимо избегать [SWS_EcuM_02922].

Что касается обработки ошибок, спецификация для этого вызова функции не содержит ни специфических кодов ошибок, ни уведомлений для DET или DEM [SWS_EcuM_02922].

Callout EcuM_AL_DriverRestart объявляется через заголовочный файл EcuM_Externals.h и имеет Service-ID 0x45 [SWS_EcuM_02923]. Функция имеет сигнатуру void EcuM_AL_DriverRestart (void), не требует входных параметров и не возвращает значения [SWS_EcuM_02923]. Назначение этого интерфейса заключается в том, чтобы в случае пробуждения (Wakeup Case) обеспечить инициализацию драйверов, а также другие аппаратные операции во время фазы запуска [SWS_EcuM_02923].

Для интеграции и взаимодействия с модулем EcuM действуют обязательные требования:

• Для повторной инициализации во время фазы WakeupRestart интегратор должен включить блок перезапуска в интеграционный код для EcuM_AL_DriverRestart, который использует сконфигурированный список EcuMDriverRestartList [SWS_EcuM_02947] [SWS_EcuM_02923].
• Список EcuMDriverRestartList может содержать драйверы, выступающие в качестве источников пробуждения (Wakeup Sources) [SWS_EcuM_02562]. В этом случае EcuM_AL_DriverRestart должен снова взвести (re-arm) механизм срабатывания обратного вызова для распознавания пробуждения («wakeup detected») этих драйверов [SWS_EcuM_02562].

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

Callout-функция EcuM_StartWakeupSources служит для того, чтобы запустить и ввести в работу переданный(-е) источник(-и) пробуждения таким образом, чтобы они были подготовлены к последующему проведению валидации пробуждения (Wakeup Validation) [SWS_EcuM_02924].

Использование и контекст вызова

Функция специфицирована как синхронный вызов с Service-ID 0x46, не имеет возвращаемого значения (void) и предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02924].

• Параметр wakeupSource (in): передаёт запускаемый источник пробуждения или битовую маску нескольких источников пробуждения типа EcuM_WakeupSourceType в callout-функцию [SWS_EcuM_02924]. Дополнительные входные/выходные или выходные параметры (inout/out) отсутствуют [SWS_EcuM_02924].

Параллелизм и ограничения

В отношении среды выполнения EcuM_StartWakeupSources классифицирован как нереентерабельный (Non Reentrant) [SWS_EcuM_02924]. Поэтому вызывающие стороны должны гарантировать, что функция не выполняется одновременно из прерывающих процедур обработки прерываний или параллельных задач.

Взаимодействие и обработка ошибок

Поскольку EcuM_StartWakeupSources объявлен как callout, низкоуровневая аппаратная активация соответствующих источников возлагается на пользовательскую реализацию системным интегратором [SWS_EcuM_02924]. Спецификация не предусматривает для этого интерфейса ни сообщений об ошибках в DET или DEM, ни специфических возвращаемых значений ошибок [SWS_EcuM_02924]; поэтому возможные состояния ошибок при запуске источников, вероятно, должны перехватываться с учётом особенностей интеграции внутри callout. Вопрос Q-b595e7175c34a831 (открытый)

Функция EcuM_CheckValidation служит callout-интерфейсом модуля ECU State Manager для проверки источника пробуждения [SWS_EcuM_02925]. EcuM вызывает эту функцию, чтобы определить, является ли обнаруженное событие пробуждения действительным [SWS_EcuM_02925].

Использование

Callout имеет идентификатор службы 0x47 и предоставляется через заголовочный файл EcuM_Externals.h [SWS_EcuM_02925]. В качестве передаваемого параметра служит wakeupSource типа EcuM_WakeupSourceType, посредством которого идентифицируется валидируемый источник пробуждения [SWS_EcuM_02925]. Функция не возвращает значения (void) и не имеет выходных или входных/выходных параметров [SWS_EcuM_02925]. Выполнение происходит синхронно [SWS_EcuM_02925].

Обработка ошибок

Специфические коды ошибок, возвращаемые значения в случае ошибки или сообщения в DET либо DEM для данного callout в спецификации не определены.

Параллелизм и ограничения

Что касается параллелизма, EcuM_CheckValidation определена как нереэнтрантная (Non Reentrant) [SWS_EcuM_02925]. Вызывающий контекст EcuM должен гарантировать, что параллельные или вложенные вызовы для одного и того же или различных источников пробуждения не происходят.

Взаимодействие

Если во время выполнения было распознано действительное событие пробуждения, о нём обязательно должно быть сообщено обратно в EcuM через вызов функции EcuM_ValidateWakeupEvent() [SWS_EcuM_02925]. Интерпретация: аппаратно-зависимая логика проверки оборудования, а также решение о действительности, вероятно, полностью реализуются в интеграционном коде. Вопрос Q-08061e09b474728d (открытый)

Callout-функция EcuM_StopWakeupSources модуля EcuM (Classic Platform) служит для целенаправленного останова переданного(-ых) источника(-ов) пробуждения после неуспешной валидации пробуждения [SWS_EcuM_02926]. Объявление этого синхронного интерфейса доступно через заголовочный файл EcuM_Externals.h и имеет Service-ID 0x48 [SWS_EcuM_02926].

Использование и параметры интерфейса:

• Входной параметр: в качестве единственного параметра передаётся wakeupSource типа EcuM_WakeupSourceType, определяющий останавливаемый(-ые) источник(-и) пробуждения [SWS_EcuM_02926].
• Возвращаемое значение и входы/выходы: не существует ни входных/выходных параметров (inout), ни выходных параметров (out) [SWS_EcuM_02926]. Функция не возвращает вызывающей стороне возвращаемого значения (void) [SWS_EcuM_02926].
• Поведение при выполнении: выполнение функции определено как синхронное (Synchronous) [SWS_EcuM_02926].

Параллелизм и обработка ошибок:

Интерфейс специфицирован как нереентерабельный (Non Reentrant) [SWS_EcuM_02926]. Поэтому параллельные вызовы недопустимы и должны предотвращаться вызывающей стороной. Спецификация не определяет для этого callout ни специфических кодов ошибок, ни возвращаемых значений, ни уведомлений для модуля Default Error Tracer (DET) или Diagnostic Event Manager (DEM) [SWS_EcuM_02926]. Интерпретация: поскольку функция предоставляется как внешний callout через EcuM_Externals.h, аппаратная деактивация соответствующего оборудования пробуждения, а также внутренняя обработка ошибок возлагаются на пользовательскую реализацию. Вопрос Q-b537c805bed751ab (открытый)

Использование и контекст вызова

Функция EcuM_MainFunction имеет сигнатуру void EcuM_MainFunction(void) с Service ID 0x18 и предоставляется через заголовочный файл SchM_EcuM.h [SWS_EcuM_02837]. Она не принимает параметров и не возвращает значения [SWS_EcuM_02837]. Ее задача заключается в выполнении всех действий ECU State Manager, пока операционная система работает («OS is up and running») [SWS_EcuM_02837]. При этом функция, вероятно, обычно вызывается планировщиком периодически (интерпретация: интеграция через SchM_EcuM.h). Вопрос Q-ca471f22bdb1f11d (открытый)

Взаимодействие и задачи

Во время работы EcuM_MainFunction берет на себя центральные задачи координации:

• Валидация источников пробуждения: если после завершения последовательности WakeupRestart имеется список кандидатов на источники пробуждения (Wakeup Source), модуль EcuM валидирует этих кандидатов в рамках EcuM_MainFunction [SWS_EcuM_02539].
• Истечение таймаута валидации: при истечении таймаута валидации для ожидающего события пробуждения функция устанавливает соответствующий бит во внутренней переменной для истекших событий пробуждения с помощью операции «ИЛИ» [SWS_EcuM_04081]. Кроме того, она уведомляет BSW Management через BswM_EcuM_Current_Wakeup с битовой маской EcuM_WakeupSourceType события и статусом ECUM_WKSTATUS_EXPIRED [SWS_EcuM_04082].
• Alarm Clock Service: если служба присутствует через EcuMAlarmClockPresent, то EcuM_MainFunction обновляет таймер Alarm Clock [SWS_EcuM_04002].

Ограничения и экземпляры

В качестве существенного граничного условия для многоядерных или многоэкземплярных архитектур действует требование: EcuM_MainFunction должна выполняться во всех экземплярах EcuM [SWS_EcuM_04011].

Тип данных EcuM_RunStatusType определен как uint8 и предоставляется через заголовочный файл EcuM.h ([SWS_EcuM_04120]). Он служит для формального представления текущего статуса протокола Run-Request в ECU-менеджере и передается в качестве результата в Basic Software Mode Manager (BswM) ([SWS_EcuM_04120]).

Допустимый диапазон значений включает три дискретных состояния ([SWS_EcuM_04120]):

• ECUM_RUNSTATUS_UNKNOWN (значение 0): представляет неизвестный статус и одновременно служит определенным значением инициализации (Init Value).
• ECUM_RUNSTATUS_REQUESTED (значение 1): обозначает состояние, при котором статус RUN был активно запрошен ECU-менеджером.
• ECUM_RUNSTATUS_RELEASED (значение 2): сигнализирует о том, что статус RUN был снова освобожден ECU-менеджером.

Что касается взаимодействия, требование [SWS_EcuM_04121] обязывает модуль ECU-менеджера в обязательном порядке информировать BswM о текущем состоянии протокола Run-Request на основе значений статуса, приведенных в EcuM_RunStatusType. Интерпретация: поскольку в требовании не указаны конкретная сигнатура функции или соглашение о вызовах для потока сообщений, информация о статусе, вероятно, типичным образом передается в модуль BswM через внутреннюю функцию уведомления или интерфейс обратного вызова. Вопрос Q-e136b90c2edbc29c (открытый) Специфические коды ошибок, сообщения DET или DEM, а также особые условия реверсивности (реэнтрантности) для этого элементарного типа данных в данных требованиях не предусмотрены.

Согласно [SWS_EcuM_04041] тип данных EcuM_WakeupStatusType описывает возможные состояния источника пробуждения (Wakeup Source) в ECU State Manager. Тип является производным от базового типа uint8 и предоставляется через заголовочный файл EcuM.h [SWS_EcuM_04041].

Диапазон значений отображает жизненный цикл события пробуждения через четыре состояния [SWS_EcuM_04041]:

• ECUM_WKSTATUS_NONE (значение 0): ожидающее обработки событие пробуждения не обнаружено [SWS_EcuM_04041].
• ECUM_WKSTATUS_PENDING (значение 1): событие пробуждения обнаружено, но ещё не валидировано [SWS_EcuM_04041].
• ECUM_WKSTATUS_VALIDATED (значение 2): событие пробуждения действительно и успешно подтверждено [SWS_EcuM_04041].
• ECUM_WKSTATUS_EXPIRED (значение 3): событие пробуждения не было валидировано своевременно и, следовательно, истекло [SWS_EcuM_04041].

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

Тип EcuM_StateType представляет собой тип данных, производный от uint8, который предоставляется через заголовочный файл EcuM.h и отображает рабочие состояния ECU State Manager [SWS_EcuM_91005]. Модуль EcuM обязан определить все состояния, перечисленные в EcuM_StateType [SWS_EcuM_02664]. Диапазон значений охватывает маску подсостояний ECUM_SUBSTATE_MASK (0x0f), а также главные состояния ECUM_STATE_STARTUP (0x10), ECUM_STATE_RUN (0x32), ECUM_STATE_POST_RUN (0x33), ECUM_STATE_SHUTDOWN (0x40) и ECUM_STATE_SLEEP (0x50) [SWS_EcuM_91005].

Использование и взаимодействие

Тип данных функционирует как центральный параметр для обмена состояниями между BswM и EcuM:

• Изменение состояния для EcuM: через синхронный и реентерабельный вызов функции EcuM_SetState(EcuM_StateType state) с Service-ID 0x2b модуль BswM уведомляет модуль EcuM об изменении состояния [SWS_EcuM_04122].
• Сообщение состояния модулю BswM: EcuM сообщает о текущем состоянии модулю BswM путем вызова интерфейса BswM_EcuM_CurrentState(EcuM_StateType State) [SWS_EcuM_04143].

Параллелизм, порядок следования и обработка ошибок

В отношении временного порядка следования действует требование, согласно которому новое состояние может быть установлено EcuM только тогда, когда RTE выдала свой ответ через соответствующий порт подтверждения (Acknowledgement Port) [SWS_EcuM_04143]. Специфические коды ошибок, возвращаемые значения или сообщения DET/DEM для этого типа данных в имеющихся источниках не предусмотрены.

Тип EcuM_Mode определен как ModeDeclarationGroup согласно [SWS_EcuM_04107] и представляет центральные состояния ECU State Manager. В качестве начального режима задан STARTUP. Кроме того, группа включает определенные режимы POST_RUN, RUN, SHUTDOWN, а также SLEEP [SWS_EcuM_04107].

В составе системы EcuM_Mode служит базовым типом для группы режимов currentMode внутри сервисного интерфейса EcuM_CurrentMode [SWS_EcuM_04108]. Через этот интерфейс можно запросить текущий режим ECU или передать его другим программным компонентам с помощью механизма режимов RTE.

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

Элемент currentMode определен как предоставленный порт (Provided-Port) модуля EcuM и предоставляет сервисный интерфейс EcuM_CurrentMode для программной архитектуры [SWS_EcuM_04112]. Этот сервисный интерфейс служит для считывания текущего режима ECU и инкапсулирует группу режимов currentMode на основе типа данных EcuM_Mode [SWS_EcuM_04108].

В ходе работы системы используется для сигнализации об изменениях состояния:

• Вызов и использование: как только происходит смена режима, EcuM сообщает об этом через RTE-порты режима программным компонентам (SW-C) [SWS_EcuM_04133]. В предположении спецификации относительно имени порта currentMode и при использовании прямого API RTE для этого вызывается функция Rte_Switch_currentMode_currentMode( Rte_ModeType_EcuM_Mode mode) [SWS_EcuM_04133].
• Параметры и возвращаемое значение: параметр mode передает в RTE вновь принимаемый режим [SWS_EcuM_04133]. Возвращаемое значение типа Rte_StatusType, предоставляемое API переключения, не обрабатывается, а согласно спецификации обязательно должно игнорироваться [SWS_EcuM_04133].
• Взаимодействие: программный компонент, который должен информироваться об изменениях режима, должен запрашивать интерфейс переключения режима EcuM_CurrentMode в качестве Required-порта [SWS_EcuM_04133].

Использование и диапазон значений

Тип данных EcuM_ShutdownModeType основан на uint16 и предоставляется через заголовочный файл Rte_EcuM_Type.h [SWS_EcuM_04101]. Он отображает режимы, сконфигурированные в ECU State Manager. Его диапазон значений охватывает:

• сконфигурированные режимы сна согласно EcuMSleepModeId [SWS_EcuM_04101], а также
• сконфигурированные режимы сброса, вычисляемые из смещения 256 + EcuMResetModeId [SWS_EcuM_04101].

Взаимодействие и контекст вызова

Тип используется в синхронных и реентерабельных службах ECU Manager:

• EcuM_SelectShutdownTarget принимает shutdownMode в качестве входного параметра, чтобы задать конкретный режим сна (при цели ECUM_SHUTDOWN_TARGET_SLEEP) или механизм сброса (при цели ECUM_SHUTDOWN_TARGET_RESET) [SWS_EcuM_02822].
• EcuM_GetShutdownTarget через параметр-указатель на EcuM_ShutdownModeType возвращает, какой именно сконфигурированный режим сна или сброса выбран для текущей цели отключения [SWS_EcuM_02824].
• EcuM_GetLastShutdownTarget выводит режим предыдущего процесса отключения через выходной параметр [SWS_EcuM_02825]. Через сервисный интерфейс EcuM_ShutdownTarget эта функциональность также доступна программным компонентам (SW-C) [SWS_EcuM_03011].

Обработка ошибок и граничные условия

Функции возвращают Std_ReturnType. Если, например, в EcuM_GetShutdownTarget или EcuM_GetLastShutdownTarget передается NULL-указатель, вызов завершается с ошибкой E_NOT_OK [SWS_EcuM_02824], [SWS_EcuM_02825]. При успешном выполнении службы возвращают E_OK [SWS_EcuM_02822], [SWS_EcuM_03011].