LIN State Manager (LinSM)

The LIN State Manager translates the communication requests of ComM per LIN network into calls to the LIN Interface. It reports the resulting states LINSM_FULL_COM and LINSM_NO_COM to ComM and BswM [SWS_LinSM_00126]. It starts wakeup, sleep, and—only on the master—the switch of the schedule table directly and monitors confirmations with timers in LinSM_MainFunction. On the slave, the master determines going to sleep: only LinSM_GotoSleepIndication triggers LinIf_GotoSleep [SWS_LinSM_00231]. If a transition fails, LinSM reports the previous state again so that the upper layers remain consistent.

more ›

The LIN State Manager is the bus state manager for LIN. Through it, ComM requests the communication capability of a network (SWS ComM p. 19). It accepts mode requests via LinSM_RequestComMode [SWS_LinSM_00126]. It controls LinIf and reports states to ComM and BswM [SWS_LinSM_00229]. Which LIN driver serves a network remains hidden behind LinIf (SWS LinSM p. 28).

Context diagram: ComM and BswM control LinSM, LinSM controls LinIf, and LinIf reports back via callbacks. Sources: [SWS_LinSM_00229], [SWS_LinSM_00138], SWS LinSM p. 28

After LinSM_Init, every network is in LINSM_NO_COM [SWS_LinSM_00155]. ComM and BswM are not notified in this process (SWS LinSM p. 23). Communication is permitted only in LINSM_FULL_COM. Upon entry, ComM and BswM receive a notification, and the substate LINSM_RUN_COMMUNICATION is entered [SWS_LinSM_00301]. Only LINSM_FULL_COM and LINSM_NO_COM are visible to BswM [SWS_LinSM_00220].

State diagram: Per network, LinSM transitions between LINSM_NO_COM and LINSM_FULL_COM via wakeup and sleep confirmation. Sources: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20

LinSM initiates wakeup and sleep directly in the call. It monitors the confirmations of LinIf with timers in LinSM_MainFunction [SWS_LinSM_00156] (SWS LinSM p. 28). On the master, a request for COMM_NO_COMMUNICATION leads immediately to LinIf_GotoSleep [SWS_LinSM_00036]. On the slave, it is only stored [SWS_LinSM_00230]; only LinSM_GotoSleepIndication triggers going to sleep [SWS_LinSM_00231]. A silence-after-wakeup timer delays repeated wakeup attempts [SWS_LinSM_00237].

Schedule switching exists only on the master [SWS_LinSM_00241]. LinSM forwards LinSM_ScheduleRequest directly to LinIf and reports the result via BswM_LinSM_CurrentSchedule (SWS LinSM p. 26). For errors, the following applies:

• LinSM reports development errors to DET, with the codes from [SWS_LinSM_00053].
• An absent callback from LinIf is considered a LINSM_E_CONFIRMATION_TIMEOUT [SWS_LinSM_00224].
• After a failed transition, LinSM sets the previous state again so that ComM and BswM remain consistently informed [SWS_LinSM_00177].

more ›

Role between ComM, BswM, and LIN Interface

The LIN State Manager (LinSM) is the bus state manager for LIN. As with the other bus state managers, ComM requests the communication capability of a network via it (SWS ComM p. 19). The central input interface for this is LinSM_RequestComMode [SWS_LinSM_00126]. The current mode is provided by LinSM_GetCurrentComMode [SWS_LinSM_00122]. LinSM operates exclusively on networks. LinIf conceals which LIN driver serves a network. Therefore, ECUs with multiple different LIN drivers do not affect LinSM (SWS LinSM p. 28).

The mandatory interfaces include LinIf_GotoSleep and LinIf_ScheduleRequest downwards as well as notifications ComM_BusSM_ModeIndication, ComM_BusSM_BusSleepMode, BswM_LinSM_CurrentState, and BswM_LinSM_CurrentSchedule upwards [SWS_LinSM_00229] (SWS LinSM p. 41). LinSM calls LinIf_Wakeup in the wake-up sequence (SWS LinSM p. 27). Optionally, it uses Det_ReportError and LinIf_SetTrcvMode [SWS_LinSM_00138]. LinIf reports back via the following callbacks:

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

The imported types such as ComM_ModeType, NetworkHandleType, and LinIf_SchHandleType are defined by [SWS_LinSM_00219].

Context diagram: LinSM mediates between ComM and BswM at the top and LinIf at the bottom; the LIN drivers remain hidden behind LinIf. Sources: [SWS_LinSM_00126], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00156], SWS LinSM p. 28, Mode-Management-Guide p. 54

State model per LIN network, initialization, and cyclic part

At startup, prior to any API call, the module-wide state LINSM_UNINIT is active (SWS LinSM p. 22). LinSM_Init is synchronous and non-reentrant [SWS_LinSM_00155]. The function receives a pointer to the post-build configuration of implementation-specific type LinSM_ConfigType [SWS_LinSM_00221]. After this, each network is in substate LINSM_NO_COM of superstate LINSM_INIT. LinSM_Init does not report this initial transition to either ComM or BswM, because ComM does not need to be initialized at this point (SWS LinSM p. 23). In the example of the Mode Management Guide, a BswM rule calls LinSM_Init(null) after Lin_Init and LinIf_Init (Mode-Management-Guide p. 54).

In LINSM_NO_COM, the bus remains silent (SWS LinSM p. 23). Bus communication is only permitted in LINSM_FULL_COM, and each network reaches this state independently of the others. Upon entry, the following occurs (SWS LinSM p. 23):

• ComM receives a notification with COMM_FULL_COMMUNICATION, BswM receives a notification with LINSM_FULL_COM.
• If LinSMTransceiverPassiveMode is configured, LinSM activates the transceiver via LinIf_SetTrcvMode.
• Substate LINSM_RUN_COMMUNICATION is entered [SWS_LinSM_00301].

The transient substate LINSM_GOTO_SLEEP bridges the wait for the sleep confirmation (SWS LinSM p. 20, SWS LinSM p. 21). For BswM, only two values of LinSM_ModeType are visible: LINSM_FULL_COM (0x01) and LINSM_NO_COM (0x02) [SWS_LinSM_00220].

Time monitoring runs in LinSM_MainFunction. This periodic function manages the timers of the request timeouts [SWS_LinSM_00156]. The wake-up confirmation timers also expire there, with a dedicated timer per network (SWS LinSM p. 28). In contrast, LinSM initiates the actual bus actions directly within the call and does not wait for the next main function cycle [SWS_LinSM_00036] [SWS_LinSM_00231].

State diagram: Per network, LinSM transitions between LINSM_NO_COM and LINSM_FULL_COM through wake-up and sleep confirmations; LINSM_GOTO_SLEEP is merely a wait state. Sources: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20, SWS LinSM p. 21, SWS LinSM p. 24

Wake-up: from LINSM_NO_COM to LINSM_FULL_COM

A LIN network is woken up when ComM requests full communication via LinSM_RequestComMode. If another node wakes the bus, this is handled not by LinSM, but by EcuM; this case also leads to a request by ComM (SWS LinSM p. 27). LinSM then calls LinIf_Wakeup directly and resets the counter for the maximum number of retries. If LinIf is already awake, it ignores the call. Prior to the call, LinSM starts the wake-up confirmation timer for the channel using LinSMConfirmationTimeout. This value must be 0 or an integer multiple of the main function period (SWS LinSM p. 28).

If LinSM_WakeupConfirmation reports success = TRUE, the network transitions to LINSM_FULL_COM [SWS_LinSM_00132]. In all other cases, LinSM re-sets the state prior to the request so that ComM and BswM still receive a mode indication (SWS LinSM p. 27). For a slave, LinIf does not confirm until it receives the master's first LIN header. If the master does not start scheduling, the confirmation is absent, and the LinSM timeout takes effect (SWS LinIf p. 52).

Sequence diagram: LinSM wakes the network immediately within the call, but the state change only follows with the asynchronous confirmation from LinIf. Sources: [SWS_LinSM_00126], [SWS_LinSM_00132], [SWS_LinSM_00224], SWS LinSM p. 42, SWS LinSM p. 27

A second time limit is the silence-after-wakeup timer with LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. As long as it is running, LinSM delays a new call to LinIf_Wakeup, even if ComM requests full communication [SWS_LinSM_00237]. After it expires, LinSM restarts the wake-up process provided that ComM continues to request COMM_FULL_COMMUNICATION [SWS_LinSM_00236]. The condition that starts the timer is specified in a requirement that is not present here. It is therefore not described.

Activity diagram: Depending on timer states and feedback, a request for full communication ends in LINSM_FULL_COM, in the previous state, or in a confirmation timeout. Sources: [SWS_LinSM_00237], [SWS_LinSM_00236], [SWS_LinSM_00224], SWS LinSM p. 27, SWS LinSM p. 28

Going to sleep: Master requests, slave follows the bus

The go-to-sleep sequence differs between master and slave. In both cases, LinSM reports the entry into no-communication mode to BswM and ComM, even if a problem occurred (SWS LinSM p. 24).

For the master, the following applies:

• If ComM requests COMM_NO_COMMUNICATION in LINSM_FULL_COM, LinSM calls LinIf_GotoSleep, which transmits the go-to-sleep command [SWS_LinSM_10208].
• The call occurs directly [SWS_LinSM_00036]. In all other cases, it is omitted [SWS_LinSM_10209].
• The call is only permitted in substate LINSM_RUN_COMMUNICATION (SWS LinSM p. 24).
• If LinIf_GotoSleep returns E_NOT_OK, LinSM_RequestComMode also returns E_NOT_OK. The previous state is set again so that ComM and BswM receive an indication [SWS_LinSM_00177].

After that, LinIf calls LinSM_GotoSleepConfirmation [SWS_LinSM_00135]. If LinSM is then in LINSM_FULL_COM/LINSM_GOTO_SLEEP, it transitions to LINSM_NO_COM, regardless of the success parameter. In any other state, it ignores the confirmation (SWS LinSM p. 24). The diagram in the specification starts a timer before LinIf_GotoSleep and stops it after the confirmation (SWS LinSM p. 47).

Sequence diagram: For the master, ComM initiates going to sleep; LINSM_NO_COM is reached only with the sleep confirmation, an E_NOT_OK from LinIf_GotoSleep leads to re-reporting the previous state. Sources: [SWS_LinSM_00036], [SWS_LinSM_00177], [SWS_LinSM_00135], SWS LinSM p. 47, SWS LinSM p. 24

For the slave, the master decides on going to sleep. If ComM requests COMM_NO_COMMUNICATION in LINSM_FULL_COM, LinSM merely stores the request and returns E_OK [SWS_LinSM_00230]. LinIf reports LinSM_GotoSleepIndication when a go-to-sleep command was received or a bus idle timeout occurred [SWS_LinSM_91000]. Only then does LinSM directly call LinIf_GotoSleep [SWS_LinSM_00231]. How the process continues depends on the stored request:

• If COMM_NO_COMMUNICATION is requested and LinIf_GotoSleep returns E_OK, ComM is notified of the bus sleep event via ComM_BusSM_BusSleepMode [SWS_LinSM_00233].
• If full communication is requested, LinSM restarts the wake-up process after the sleep confirmation [SWS_LinSM_00234].

In LinIf, the slave sequence puts the controller and, if supported, the transceiver into sleep mode (SWS LinIf p. 137).

Sequence diagram: For the slave, ComM's sleep request is merely stored; going to sleep is triggered by the indication from LinIf. Sources: [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234], SWS LinSM p. 48, SWS LinSM p. 24

Switching schedule tables (master only)

LinSM_ScheduleRequest [SWS_LinSM_00113] exists only if at least one channel is configured as master [SWS_LinSM_00241]. The same applies to the callback LinSM_ScheduleRequestConfirmation [SWS_LinSM_00242]. The asynchronous function forwards the request directly to LinIf_ScheduleRequest without routing it through the main function. It returns LinIf's return value to the caller (SWS LinSM p. 26). The caller is BswM. It uses LinSMScheduleIndex as a symbolic reference whose value must correspond to the value in LinIf (SWS LinSM p. 52). Diagnostic schedule switches of the LIN transport protocol also run via BswM and LinSM_ScheduleRequest (SWS LinIf p. 142).

LinSM reports the result via BswM_LinSM_CurrentSchedule (SWS BswM p. 80). Which schedule is reported depends on the execution course (SWS LinSM p. 26):

• If LinSM_ScheduleRequestConfirmation confirms [SWS_LinSM_00129] before the timer expires, LinSM reports the new schedule.
• If the timer has expired, it reports the unchanged schedule.
• If LinIf_ScheduleRequest returns E_NOT_OK, it reports the old schedule in the next main function call.
• It also reports a change without a prior request, such as the switch to the NULL schedule performed by LinIf when going to sleep.

Sequence diagram: The schedule switch is forwarded directly and monitored by timer; BswM is notified of the actually valid schedule in every outcome. Sources: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00156], SWS LinSM p. 26, SWS LinSM p. 48

Node type, configuration, and differences from later releases

The parameter LinSMNodeType determines whether master or slave behavior applies to a channel. This governs whether LinSM_ScheduleRequest, LinSM_ScheduleRequestConfirmation, and LinSM_GotoSleepIndication are available [SWS_LinSM_00241] [SWS_LinSM_00242] [SWS_LinSM_00243]. The most important timing parameters are LinSMConfirmationTimeout (SWS LinSM p. 28) and LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. The LinSMSchedule containers reference schedules from the LinIf configuration (SWS LinSM p. 52). The DET checks depend on LinSMDevErrorDetect [SWS_LinSM_00239].

Many document references originate from later releases. For R20-11, the requirements are authoritative, and in several places they diverge:

• The second parameter of LinSM_ScheduleRequest is named schedule in R20-11 and is described as “Pointer to the new Schedule table”, although its type is LinIf_SchHandleType [SWS_LinSM_00113]. With R22-11 it was renamed (SWS LinSM p. 1, Release Overview p. 50); in R24-11 it is called ScheduleTableIdx (SWS LinSM p. 34).
• In R20-11, LinSM_GetCurrentComMode has service ID 0x11 [SWS_LinSM_00122] and LinSM_RequestComMode has service ID 0x12 [SWS_LinSM_00126]. Later versions specify 0x41 and 0x40 and permit reentrancy only for different networks (SWS LinSM p. 35, SWS LinSM p. 36).
• The ComM callbacks are named ComM_BusSM_… [SWS_LinSM_00233] in R20-11, and ComM_<Bus>SM_… in R25-11 (SWS LinSM p. 41).

Behavior in the event of an error

The development errors are defined by [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)

When LinSMDevErrorDetect is enabled, the callbacks check the network and initialization, such as LinSM_GotoSleepIndication [SWS_LinSM_00239] [SWS_LinSM_00240]. Callbacks do not have a return value, so only the DET notification remains there (SWS LinSM p. 40, SWS LinSM p. 39). APIs with Std_ReturnType additionally return E_NOT_OK, for example in case of an invalid network, mode, or schedule, or in state LINSM_UNINIT (SWS LinSM p. 36, SWS LinSM p. 34). Interpretation: These checks originate from versions R24-11 onwards and likely apply with identical content to R20-11. Notably, the later version also requires E_NOT_OK for a NULL pointer for the void API LinSM_GetVersionInfo [SWS_LinSM_00117] (SWS LinSM p. 34). Question Q-6b2d75dd286bdcb4 (open)

As a runtime error, LINSM_E_CONFIRMATION_TIMEOUT (0x00) is designated for missing callbacks from LinIf [SWS_LinSM_00224]. Presumably, it is reported via Det_ReportRuntimeError, which later versions list as a mandatory interface (SWS LinSM p. 41). Question Q-06b13a07d0d60152 (open) Functionally, LinSM ensures that ComM and BswM always observe a consistent state:

• After a failed wake-up, it re-sets and re-reports the old state (SWS LinSM p. 27).
• In case of E_NOT_OK from LinIf_GotoSleep, the same applies [SWS_LinSM_00177].
• A sleep confirmation leads to LINSM_NO_COM even with success = FALSE (SWS LinSM p. 24).
• Upon a failed schedule switch, BswM receives the old or unchanged schedule (SWS LinSM p. 26).

Further detailed evidence

• Mode request from ComM and going to sleep for the master: [SWS_LinSM_00126], [SWS_LinSM_00036], [SWS_LinSM_10208], [SWS_LinSM_10209], [SWS_LinSM_00177].
• Going to sleep for the slave: [SWS_LinSM_91000], [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234]; plus the sequence in SWS LinSM p. 24.
• Wake-up and time monitoring: [SWS_LinSM_00132], [SWS_LinSM_00235], [SWS_LinSM_00236], [SWS_LinSM_00237], SWS LinSM p. 28.
• Schedule switch: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00241], [SWS_LinSM_00242].
• Initialization, states, and types: [SWS_LinSM_00155], [SWS_LinSM_00156], [SWS_LinSM_00220], [SWS_LinSM_00221], [SWS_LinSM_00301]; notification to BswM in SWS BswM p. 72.
• Error codes and interfaces: [SWS_LinSM_00053], [SWS_LinSM_00224], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00219].
• Traceability to SRS requirements and list of non-applicable requirements: SWS LinSM p. 18, SWS LinSM p. 55.