LIN State Manager (LinSM)

LIN State Manager преобразует запросы на связь от ComM для каждой LIN-сети в вызовы LIN Interface. О полученных состояниях LINSM_FULL_COM и LINSM_NO_COM он сообщает в ComM и BswM [SWS_LinSM_00126]. Пробуждение, переход в режим сна и — только для ведущего узла (Master) — смену расписания он запускает напрямую и отслеживает подтверждения с помощью таймеров в LinSM_MainFunction. У ведомого узла (Slave) переход в режим сна определяет ведущий узел: только LinSM_GotoSleepIndication инициирует LinIf_GotoSleep [SWS_LinSM_00231]. Если переход завершается неудачей, LinSM повторно сообщает прежнее состояние для сохранения согласованности верхних уровней.

больше ›

LIN State Manager представляет собой менеджер состояния шины для LIN. Через него ComM запрашивает готовность сети к передаче данных (SWS ComM с. 19). Запросы режимов он принимает через LinSM_RequestComMode [SWS_LinSM_00126]. Он управляет LinIf и сообщает о состояниях в ComM и BswM [SWS_LinSM_00229]. Какой именно драйвер LIN обслуживает сеть, остается скрытым за LinIf (SWS LinSM с. 28).

Контекстная диаграмма: ComM и BswM управляют LinSM, LinSM управляет LinIf, а LinIf возвращает отклики через функции обратного вызова. Источники: [SWS_LinSM_00229], [SWS_LinSM_00138], SWS LinSM с. 28

Согласно LinSM_Init, каждая сеть находится в состоянии LINSM_NO_COM [SWS_LinSM_00155]. ComM и BswM при этом не уведомляются (SWS LinSM с. 23). Связь разрешена только в LINSM_FULL_COM. При входе ComM и BswM получают сообщение, и выполняется вход в подсостояние LINSM_RUN_COMMUNICATION [SWS_LinSM_00301]. Для BswM видны только LINSM_FULL_COM и LINSM_NO_COM [SWS_LinSM_00220].

Диаграмма состояний: для каждой сети LinSM переключается между LINSM_NO_COM и LINSM_FULL_COM по подтверждению пробуждения и сна. Источники: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM с. 20

Пробуждение и переход в спящий режим LinSM запускает непосредственно при вызове. Подтверждения от LinIf он отслеживает с помощью таймеров в LinSM_MainFunction [SWS_LinSM_00156] (SWS LinSM с. 28). На ведущем узле запрос на COMM_NO_COMMUNICATION немедленно приводит к LinIf_GotoSleep [SWS_LinSM_00036]. На ведомом узле он только сохраняется [SWS_LinSM_00230]; лишь LinSM_GotoSleepIndication инициирует переход в режим сна [SWS_LinSM_00231]. Таймер Silence-after-Wakeup задерживает повторные попытки пробуждения [SWS_LinSM_00237].

Смена расписания возможна только на ведущем узле [SWS_LinSM_00241]. LinSM напрямую передает LinSM_ScheduleRequest в LinIf и сообщает о результате через BswM_LinSM_CurrentSchedule (SWS LinSM с. 26). В отношении ошибок действует следующее:

• Об ошибках разработки LinSM сообщает в DET, используя коды из [SWS_LinSM_00053].
• Отсутствие вызова функции обратного вызова от LinIf считается LINSM_E_CONFIRMATION_TIMEOUT [SWS_LinSM_00224].
• После неудавшегося перехода LinSM повторно устанавливает прежнее состояние, чтобы ComM и BswM были проинформированы согласованно [SWS_LinSM_00177].

больше ›

Роль между ComM, BswM и LIN Interface

LIN State Manager (LinSM) является менеджером состояния шины для LIN. Как и в случае с другими менеджерами состояния шин, ComM запрашивает через него готовность сети к передаче данных (SWS ComM с. 19). Центральным входным интерфейсом для этого является LinSM_RequestComMode [SWS_LinSM_00126]. Текущий режим возвращает LinSM_GetCurrentComMode [SWS_LinSM_00122]. LinSM работает исключительно с сетями. То, какой именно LIN-драйвер обслуживает сеть, скрыто за LinIf. Поэтому электронные блоки управления (ECU) с несколькими различными LIN-драйверами не затрагивают LinSM (SWS LinSM с. 28).

К обязательным интерфейсам относятся LinIf_GotoSleep и LinIf_ScheduleRequest вниз по стеку, а также сообщения ComM_BusSM_ModeIndication, ComM_BusSM_BusSleepMode, BswM_LinSM_CurrentState и BswM_LinSM_CurrentSchedule вверх по стеку [SWS_LinSM_00229] (SWS LinSM с. 41). LinIf_Wakeup LinSM вызывает в процессе пробуждения (SWS LinSM с. 27). Опционально он использует Det_ReportError и LinIf_SetTrcvMode [SWS_LinSM_00138]. LinIf возвращает отклики через следующие функции обратного вызова:

• LinSM_WakeupConfirmation [SWS_LinSM_00132]
• LinSM_GotoSleepConfirmation [SWS_LinSM_00135]
• LinSM_GotoSleepIndication [SWS_LinSM_91000]
• LinSM_ScheduleRequestConfirmation [SWS_LinSM_00129]

Импортируемые типы, такие как ComM_ModeType, NetworkHandleType и LinIf_SchHandleType, определяет [SWS_LinSM_00219].

Контекстная диаграмма: LinSM является посредником между ComM и BswM сверху и LinIf снизу; драйверы LIN остаются скрытыми за LinIf. Источники: [SWS_LinSM_00126], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00156], SWS LinSM с. 28, Mode-Management-Guide с. 54

Модель состояний для отдельной LIN-сети, инициализация и циклическая часть

При запуске перед любым вызовом API активно общемодульное состояние LINSM_UNINIT (SWS LinSM с. 22). LinSM_Init является синхронной и нереентерабельной [SWS_LinSM_00155]. Функция принимает указатель на конфигурацию Post-Build зависимого от реализации типа LinSM_ConfigType [SWS_LinSM_00221]. После этого каждая сеть находится в подсостоянии LINSM_NO_COM суперсостояния LINSM_INIT. Об этом первом переходе LinSM_Init не сообщает ни в ComM, ни в BswM, так как ComM к этому моменту еще не обязательно инициализирован (SWS LinSM с. 23). В примере из руководства по управлению режимами (Mode Management Guide) правило BswM вызывает LinSM_Init(null) после Lin_Init и LinIf_Init (Mode-Management-Guide с. 54).

В LINSM_NO_COM шина остается неактивной (SWS LinSM с. 23). Связь по шине разрешена только в LINSM_FULL_COM, и каждая сеть достигает этого состояния независимо от других. При входе происходит следующее (SWS LinSM с. 23):

• ComM получает сообщение с COMM_FULL_COMMUNICATION, а BswM — сообщение с LINSM_FULL_COM.
• Если сконфигурирован LinSMTransceiverPassiveMode, LinSM переводит трансивер в активное состояние с помощью LinIf_SetTrcvMode.
• Выполняется вход в подсостояние LINSM_RUN_COMMUNICATION [SWS_LinSM_00301].

Временное подсостояние LINSM_GOTO_SLEEP перекрывает ожидание подтверждения перехода в режим сна (SWS LinSM с. 20, SWS LinSM с. 21). Для BswM видимы только два значения LinSM_ModeType: LINSM_FULL_COM (0x01) и LINSM_NO_COM (0x02) [SWS_LinSM_00220].

Контроль тайм-аутов выполняется в LinSM_MainFunction. Эта периодическая функция обслуживает таймеры тайм-аутов запросов [SWS_LinSM_00156]. В ней же отрабатывают таймеры подтверждения пробуждения с отдельным таймером для каждой сети (SWS LinSM с. 28). Напротив, фактические действия на шине LinSM запускает непосредственно при вызове, не ожидая следующего цикла основной функции (Main Function) [SWS_LinSM_00036] [SWS_LinSM_00231].

Диаграмма состояний: для каждой сети LinSM переключается между LINSM_NO_COM и LINSM_FULL_COM по подтверждению пробуждения и сна; LINSM_GOTO_SLEEP является лишь состоянием ожидания. Источники: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM с. 20, SWS LinSM с. 21, SWS LinSM с. 24

Пробуждение: от LINSM_NO_COM к LINSM_FULL_COM

LIN-сеть пробуждается, когда ComM запрашивает полную связь через LinSM_RequestComMode. Если шину пробуждает другой узел, это обрабатывает не LinSM, а EcuM; этот случай также приводит к запросу со стороны ComM (SWS LinSM с. 27). Затем LinSM напрямую вызывает LinIf_Wakeup и сбрасывает счетчик максимального количества повторов. Если LinIf уже находится в активном состоянии, он игнорирует вызов. Перед вызовом LinSM запускает для канала таймер подтверждения пробуждения со значением LinSMConfirmationTimeout. Это значение должно быть равно 0 или целому кратному периоду основной функции (SWS LinSM с. 28).

Если LinSM_WakeupConfirmation возвращает success = TRUE, сеть переходит в LINSM_FULL_COM [SWS_LinSM_00132]. Во всех остальных случаях LinSM повторно выставляет состояние, предшествовавшее запросу, чтобы ComM и BswM все равно получили индикацию режима (SWS LinSM с. 27). На ведомом узле LinIf выполняет подтверждение только тогда, когда принимает первый LIN-заголовок от ведущего узла. Если ведущий узел не начинает диспетчеризацию расписания, подтверждение отсутствует и срабатывает тайм-аут LinSM (SWS LinIf с. 52).

Диаграмма последовательности: LinSM пробуждает сеть непосредственно при вызове, однако изменение состояния происходит только после асинхронного подтверждения от LinIf. Источники: [SWS_LinSM_00126], [SWS_LinSM_00132], [SWS_LinSM_00224], SWS LinSM с. 42, SWS LinSM с. 27

Второй временной границей является таймер Silence-after-Wakeup с LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Пока он работает, LinSM откладывает новый вызов LinIf_Wakeup, даже если ComM запрашивает полную связь [SWS_LinSM_00237]. После его истечения LinSM перезапускает процесс пробуждения, если ComM по-прежнему запрашивает COMM_FULL_COMMUNICATION [SWS_LinSM_00236]. Условие, запускающее таймер, содержится в требовании, которое здесь отсутствует. Поэтому оно не описывается.

Диаграмма деятельности: запрос на полную связь завершается переходом в LINSM_FULL_COM, возвратом к прежнему состоянию или тайм-аутом подтверждения в зависимости от состояния таймеров и полученного отклика. Источники: [SWS_LinSM_00237], [SWS_LinSM_00236], [SWS_LinSM_00224], SWS LinSM с. 27, SWS LinSM с. 28

Переход в спящий режим: ведущий узел запрашивает, ведомый следует за шиной

Процесс Goto-Sleep различается для ведущего и ведомого узлов. В обоих случаях LinSM сообщает о входе в режим отсутствия связи (No-Communication) в BswM и ComM, даже если возникла проблема (SWS LinSM с. 24).

Для ведущего узла действует следующее:

• Если ComM запрашивает COMM_NO_COMMUNICATION в состоянии LINSM_FULL_COM, LinSM вызывает LinIf_GotoSleep, который отправляет команду Goto-Sleep [SWS_LinSM_10208].
• Вызов выполняется напрямую [SWS_LinSM_00036]. Во всех остальных случаях он не осуществляется [SWS_LinSM_10209].
• Вызов разрешен только в подсостоянии LINSM_RUN_COMMUNICATION (SWS LinSM с. 24).
• Если LinIf_GotoSleep возвращает E_NOT_OK, то и LinSM_RequestComMode возвращает E_NOT_OK. Прежнее состояние устанавливается повторно, чтобы ComM и BswM получили индикацию [SWS_LinSM_00177].

После этого LinIf вызывает LinSM_GotoSleepConfirmation [SWS_LinSM_00135]. Если LinSM при этом находится в LINSM_FULL_COM/LINSM_GOTO_SLEEP, он переходит в LINSM_NO_COM независимо от параметра success. В любом другом состоянии он игнорирует подтверждение (SWS LinSM с. 24). На схеме спецификации таймер запускается перед LinIf_GotoSleep и останавливается после подтверждения (SWS LinSM с. 47).

Диаграмма последовательности: на ведущем узле переход в режим сна инициируется ComM; LINSM_NO_COM достигается только с подтверждением сна, возвращение E_NOT_OK от LinIf_GotoSleep приводит к повторному сообщению о старом состоянии. Источники: [SWS_LinSM_00036], [SWS_LinSM_00177], [SWS_LinSM_00135], SWS LinSM с. 47, SWS LinSM с. 24

На ведомом узле решение о переходе в режим сна принимает ведущий узел. Если ComM запрашивает COMM_NO_COMMUNICATION в LINSM_FULL_COM, LinSM только сохраняет запрос и возвращает E_OK [SWS_LinSM_00230]. LinIf сигнализирует LinSM_GotoSleepIndication, когда получена команда Goto-Sleep или истек тайм-аут неактивности шины (Bus-Idle-Timeout) [SWS_LinSM_91000]. Только после этого LinSM напрямую вызывает LinIf_GotoSleep [SWS_LinSM_00231]. Дальнейшие действия зависят от сохраненного запроса:

• Если запрошен режим COMM_NO_COMMUNICATION и LinIf_GotoSleep возвращает E_OK, ComM узнает о событии перехода шины в режим сна через ComM_BusSM_BusSleepMode [SWS_LinSM_00233].
• Если запрошена полная связь, LinSM перезапускает процесс пробуждения после подтверждения сна [SWS_LinSM_00234].

В LinIf процесс для ведомого узла переводит контроллер и, если поддерживается, трансивер в спящий режим (SWS LinIf с. 137).

Диаграмма последовательности: на ведомом узле запрос на переход в режим сна от ComM только сохраняется, а непосредственный переход в спящий режим запускается по индикации от LinIf. Источники: [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234], SWS LinSM с. 48, SWS LinSM с. 24

Смена расписаний (только Master)

LinSM_ScheduleRequest [SWS_LinSM_00113] существует только в том случае, если хотя бы один канал сконфигурирован как ведущий (Master) [SWS_LinSM_00241]. То же самое относится к функции обратного вызова LinSM_ScheduleRequestConfirmation [SWS_LinSM_00242]. Асинхронная функция напрямую передает запрос в LinIf_ScheduleRequest в обход основной функции (Main Function). Ее возвращаемое значение она возвращает вызывающей стороне (SWS LinSM с. 26). Вызывающей стороной является BswM. Он использует LinSMScheduleIndex в качестве символьной ссылки, значение которой должно соответствовать значению в LinIf (SWS LinSM с. 52). Переключения диагностических расписаний транспортного протокола LIN также осуществляются через BswM и LinSM_ScheduleRequest (SWS LinIf с. 142).

Результат LinSM передает через BswM_LinSM_CurrentSchedule (SWS BswM с. 80). Какое именно расписание передается, зависит от хода выполнения (SWS LinSM с. 26):

• Если LinSM_ScheduleRequestConfirmation подтверждает [SWS_LinSM_00129] до истечения таймера, LinSM передает новое расписание.
• Если таймер истек, он передает неизмененное расписание.
• Если LinIf_ScheduleRequest возвращает E_NOT_OK, при следующем вызове main-функции он передает старое расписание.
• Он также сообщает о переключении без предварительного запроса, например о переключении на NULL-расписание, которое LinIf выполняет при переходе в режим сна.

Диаграмма последовательности: смена расписания передается напрямую и контролируется по времени; BswM при любом исходе получает фактически действующее расписание. Источники: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00156], SWS LinSM с. 26, SWS LinSM с. 48

Тип узла, конфигурация и отличия от более поздних релизов

Параметр LinSMNodeType определяет, действует ли для канала поведение Master или Slave. От этого зависит, доступны ли LinSM_ScheduleRequest, LinSM_ScheduleRequestConfirmation и LinSM_GotoSleepIndication [SWS_LinSM_00241] [SWS_LinSM_00242] [SWS_LinSM_00243]. Важнейшими временными параметрами являются LinSMConfirmationTimeout (SWS LinSM с. 28) и LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Контейнеры LinSMSchedule ссылаются на расписания из конфигурации LinIf (SWS LinSM с. 52). Проверки DET привязаны к LinSMDevErrorDetect [SWS_LinSM_00239].

Многие фрагменты документации взяты из более поздних релизов. Для R20-11 определяющими являются требования, и в некоторых местах они расходятся:

• Второй параметр LinSM_ScheduleRequest в R20-11 называется schedule и описывается как «Pointer to the new Schedule table», хотя его тип — LinIf_SchHandleType [SWS_LinSM_00113]. В R22-11 он был переименован (SWS LinSM с. 1, Release Overview с. 50); в R24-11 он называется ScheduleTableIdx (SWS LinSM с. 34).
• В R20-11 LinSM_GetCurrentComMode имеет Service-ID 0x11 [SWS_LinSM_00122], а LinSM_RequestComMode — Service-ID 0x12 [SWS_LinSM_00126]. В более поздних редакциях указаны 0x41 и 0x40, и ревходимость допускается только для различных сетей (SWS LinSM с. 35, SWS LinSM с. 36).
• Функции обратного вызова ComM в R20-11 называются ComM_BusSM_… [SWS_LinSM_00233], а в R25-11 — ComM_<Bus>SM_… (SWS LinSM с. 41).

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

Ошибки разработки определяет [SWS_LinSM_00053]:

• LINSM_E_UNINIT (0x00)
• LINSM_E_NONEXISTENT_NETWORK (0x20)
• LINSM_E_PARAMETER (0x30)
• LINSM_E_PARAM_POINTER (0x40)
• LINSM_E_INIT_FAILED (0x50)

При активном LinSMDevErrorDetect функции обратного вызова проверяют сеть и инициализацию, как, например, LinSM_GotoSleepIndication [SWS_LinSM_00239] [SWS_LinSM_00240]. Функции обратного вызова не имеют возвращаемого значения, поэтому обработка ограничивается сообщением DET (SWS LinSM с. 40, SWS LinSM с. 39). API с Std_ReturnType дополнительно возвращают E_NOT_OK, например при некорректной сети, режиме или расписании либо в состоянии LINSM_UNINIT (SWS LinSM с. 36, SWS LinSM с. 34). Интерпретация: эти проверки происходят из редакций начиная с R24-11 и, вероятно, по содержанию аналогично применимы к R20-11. Примечательно, что более поздняя редакция требует E_NOT_OK при передаче NULL-указателя также и для API void LinSM_GetVersionInfo [SWS_LinSM_00117] (SWS LinSM с. 34). Вопрос Q-6b2d75dd286bdcb4 (открытый)

В качестве ошибки времени выполнения предусмотрен LINSM_E_CONFIRMATION_TIMEOUT (0x00) на случай отсутствия обратных вызовов от LinIf [SWS_LinSM_00224]. Предположительно, о ней сообщается через Det_ReportRuntimeError, который в более поздних редакциях значится как обязательный интерфейс (SWS LinSM с. 41). Вопрос Q-06b13a07d0d60152 (открытый) Функционально LinSM гарантирует, что ComM и BswM всегда видят согласованное состояние:

• После неудавшегося пробуждения он повторно устанавливает и сообщает прежнее состояние (SWS LinSM с. 27).
• При возврате E_NOT_OK от LinIf_GotoSleep действует то же самое [SWS_LinSM_00177].
• Подтверждение перехода в режим сна даже при success = FALSE приводит к состоянию LINSM_NO_COM (SWS LinSM с. 24).
• При неудачной смене расписания BswM получает старое или неизмененное расписание (SWS LinSM с. 26).

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

• Запрос режима от ComM и переход в режим сна у ведущего узла (Master): [SWS_LinSM_00126], [SWS_LinSM_00036], [SWS_LinSM_10208], [SWS_LinSM_10209], [SWS_LinSM_00177].
• Переход в режим сна у ведомого узла (Slave): [SWS_LinSM_91000], [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234]; дополнительно последовательность в SWS LinSM с. 24.
• Пробуждение и контроль по времени: [SWS_LinSM_00132], [SWS_LinSM_00235], [SWS_LinSM_00236], [SWS_LinSM_00237], SWS LinSM с. 28.
• Смена расписания: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00241], [SWS_LinSM_00242].
• Инициализация, состояния и типы: [SWS_LinSM_00155], [SWS_LinSM_00156], [SWS_LinSM_00220], [SWS_LinSM_00221], [SWS_LinSM_00301]; оповещение BswM в SWS BswM с. 72.
• Коды ошибок и интерфейсы: [SWS_LinSM_00053], [SWS_LinSM_00224], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00219].
• Трассируемость к требованиям SRS и список неприменимых требований: SWS LinSM с. 18, SWS LinSM с. 55.