AUTOSAR Classic LIN

The LIN Communication module cluster realizes the standardized connection of LIN sub-bus systems via the modules LinSM, LinIf, LinTrcv, and Lin (SWS COMManager p. 19). It controls the schedule-based transmission of frames on masters as well as reactive header evaluation and data transmission on slaves ([SWS_LinIf_91004], [SWS_Lin_00168]). At the same time, the cluster coordinates the orderly transition between full communication and sleep mode as well as autonomous error handling via the response_error signal ([SWS_LinIf_00763]).

more ›

The LIN Communication module cluster provides the complete AUTOSAR implementation of the LIN protocol and comprises the state manager LinSM, the interface LinIf (including the transport protocol LinTp), the transceiver driver LinTrcv, and the MCAL driver Lin (SWS COMManager p. 19). It connects subnetworks, sensors, and actuators to the AUTOSAR communication matrix and strictly distinguishes between master nodes with autonomous schedule processing and purely reactively responding slave nodes ([SWS_LinIf_00197], [SWS_Lin_00272]).

Architecture diagram: Layered architecture and interface relationships of the LIN cluster between communication services, abstraction layer, and MCAL. Sources: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

Data transmission on master ECUs is performed by periodically triggering the driver via Lin_SendFrame and subsequent status polling via Lin_GetStatus ([SWS_Lin_00168]). On the slave, in contrast, the detection of a header in the driver triggers the synchronous callback LinIf_HeaderIndication ([SWS_LinIf_91004]). The interface decides on reception, response, or ignoring based on the PID and acknowledges completion via LinIf_RxIndication or LinIf_TxConfirmation ([SWS_LinIf_91005], [SWS_LinIf_91006]). Diagnostic messages are handled by the integrated LinTp via automated schedule table switching ([SWS_LinIf_00641]).

During the operating cycle, LinSM coordinates the state transitions between LINSM_NO_COM and LINSM_FULL_COM ([SWS_LinSM_00026], [SWS_LinSM_00032]). Wake-up is performed via a bus pulse via Lin_Wakeup ([SWS_Lin_00169]). The transition to sleep mode is initiated on the master by actively transmitting a sleep frame, on the slave upon reception of the sleep command or upon bus idle via LinIf_GotoSleep, Lin_GoToSleepInternal, and transceiver sleep control ([SWS_LinSM_00231], [SWS_LinIf_00757]).

Sequence diagram: Interaction of BSW modules when a LIN slave enters sleep state following a bus sleep signal. Sources: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Communication errors are detected on slaves via LinIf_LinErrorIndication and reported autonomously to the master in the response_error signal ([SWS_LinIf_91007], [SWS_LinIf_00763]). Cross-channel synchronization areas and strict separation between cyclic tasks (LinIf_MainFunction) and driver ISRs ensure system stability ([SWS_LinIf_00384]).

more ›

System Architecture & Role of the Module Cluster

In the AUTOSAR Classic basic software stack, the LIN Communication module cluster provides standardized communication via the Local Interconnect Network (LIN) according to ISO 17987. It primarily acts as a cost-efficient sub-bus system for connecting sensors and actuators in the vehicle network (AUTOSAR FO Features p. 58). The cluster spans multiple layers of the AUTOSAR architecture: The LIN State Manager (LinSM) operates at the Communication Services layer, the LIN Interface (LinIf) including the integrated transport protocol (LinTp) constitutes the Communication Abstraction, the LIN Transceiver Driver (LinTrcv) is part of the ECU Abstraction, and the LIN Driver (Lin) resides as a hardware-oriented module in the Microcontroller Abstraction Layer (MCAL) (SWS COMManager p. 19).

Architecturally, the cluster strictly differentiates between master and slave nodes. A LIN master autonomously controls the bus traffic via schedule tables and generates all headers, whereas LIN slaves respond purely reactively to received headers or evaluate signals ([SWS_LinIf_00197], [SWS_Lin_00272]). For diagnostic and transport tasks according to ISO 14229, the LIN Interface encapsulates the TP functionality, which handles segmented diagnostic messages (Master Request Frame MRF and Slave Response Frame SRF) via PduR and DCM ([SWS_LinIf_00351], [SWS_LinIf_00629]). Externally, the cluster interacts intensively with the Communication Manager (ComM), the Basic Software Mode Manager (BswM), the PDU Router (PduR), and the ECU State Manager (EcuM) (SWS COMManager p. 19).

Architecture diagram: Layered architecture and interface relationships of the LIN cluster between communication services, abstraction layer, and MCAL. Sources: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

Interplay & Interaction Paths Between the Modules

The interaction paths in the cluster differ fundamentally depending on the node role. In the LIN master, the LIN Interface initiates the processing of the active schedule table via its periodic task. For transmit frames that are due, LinIf fetches the payload via upper-layer trigger-transmit mechanisms and passes the Lin_PduType structure to the LIN driver via Lin_SendFrame ([SWS_Lin_00232], SWS LINInterface p. 37). The driver transmits the header and data in a non-blocking manner ([SWS_Lin_00027]). After the maximum frame transmission time has elapsed, LinIf determines the transmission result via Lin_GetStatus ([SWS_Lin_00168], SWS LINInterface p. 35). For receive slots, LinIf retrieves the data stored in the buffer by the driver and forwards it to the upper layers ([SWS_Lin_00233]).

On a LIN slave, the data path operates event-driven: If the MCAL driver Lin detects a valid break, synch, and PID header on the hardware, it synchronously calls the callback LinIf_HeaderIndication ([SWS_Lin_00280], [SWS_LinIf_91004]). The interface validates the protected identifier (PID) using the internal PID table ([SWS_LinIf_00816], [SWS_LinIf_00823]). If it is a transmit frame, LinIf retrieves the payload, configures the response type to LIN_FRAMERESPONSE_TX, and provides the data to the driver in the buffer ([SWS_Lin_00230]). If the frame is configured as receive, the driver reports success via LinIf_RxIndication ([SWS_LinIf_91005]) after complete byte reception, whereupon LinIf passes the data on to the PDU Router. Confirmations of transmitted slave responses occur via LinIf_TxConfirmation ([SWS_LinIf_91006]).

In addition, transceiver control is transparently encapsulated via the LIN Interface: The interface synchronously forwards mode requests such as LinIf_SetTrcvMode to LinTrcv_SetOpMode ([SWS_LinIf_00544], [SWS_LinTrcv_00002]). During transport protocol transactions, LinTp controls the targeted switching of the master's schedule table between application mode (LINTP_APPLICATIVE_SCHEDULE), diagnostic request (LINTP_DIAG_REQUEST), and diagnostic response (LINTP_DIAG_RESPONSE) via BswM_LinTp_RequestMode ([SWS_LinIf_00641], [SWS_LinIf_00642], [SWS_LinIf_00643]).

Sequence diagram: Dynamic control and data flow during header indication, transmit triggering, and reception confirmation on a LIN slave. Sources: [SWS_Lin_00280], [SWS_LinIf_91004], [SWS_LinIf_91005], AUTOSAR SWS LINInterface p. 133.

Synchronization, reentrancy and task contexts

Execution within the module cluster is split across cyclic task contexts and hardware-oriented interrupt levels. The core of the cyclic schedule control in the LIN Interface is the scheduled function LinIf_MainFunction_<LinIfChannel.ShortName>, which must be instantiated separately for each configured LIN channel ([SWS_LinIf_00384], [SWS_LinIf_00725]). It handles the advancement of schedule slots, status polling from the driver, and timeout handling of the transport protocol ([SWS_LinIf_00800], SWS LINInterface p. 119). In parallel, LinSM_MainFunction manages the countdown and confirmation timers for asynchronous channel and wakeup requests ([SWS_LinSM_00162], [SWS_LinSM_00159]).

In contrast to the task level, the driver routines of the MCAL module Lin run in the interrupt context (ISR) when an interrupt-driven controller or a UART interface is present (AUTOSAR CP SWS LINDriver p. 53). The callbacks LinIf_HeaderIndication, LinIf_RxIndication, and LinIf_TxConfirmation are triggered synchronously directly from this ISR context ([SWS_Lin_00280], [SWS_LinIf_91005], [SWS_LinIf_91006]). This requires strict protection of critical sections (Exclusive Areas) in the LIN Interface: Control calls such as LinIf_Transmit, LinIf_GotoSleep, LinIf_ScheduleRequest, or LinIf_Wakeup may only modify internal channel structures while protected against concurrent access from LinIf_MainFunction or ISR callbacks (SWS LINInterface p. 119).

Regarding reentrancy, the API functions of modules LinIf and LinSM are predominantly designed to be reentrant for different channels or networks, but non-reentrant for the same channel ([SWS_LinSM_00126], [SWS_LinIf_00201], [SWS_LinIf_00204]). The driver services in Lin (e.g. Lin_Wakeup, Lin_GoToSleepInternal) behave similarly and must be strictly synchronized per physical channel ([SWS_Lin_00167], [SWS_Lin_00169]). With simple UART hardware lacking a multi-byte FIFO, the LIN driver buffers bytes temporarily in software ([SWS_Lin_00026]), which, Interpretation: is likely to lead to increased CPU interrupt load on slave nodes under high bus load. Question Q-0d07d89d1ade6a01 (open)

Typical lifecycles and operating modes

During system startup, BswM initializes the BSW modules in a defined chain: First, the basic drivers Lin_Init and LinTrcv_Init are initialized, followed by LinIf_Init, LinTp_Init, and finally LinSM_Init (ModemanagementGuide p. 54). LinIf_Init defaults the schedule of all master channels to NULL_SCHEDULE ([SWS_LinIf_00233]) and, on slaves, loads the preconfigured NAD and PID tables ([SWS_LinIf_00767], [SWS_LinIf_00768]). LinSM starts in state LINSM_NO_COM without issuing callbacks to ComM or BswM during initialization ([SWS_LinSM_00026], [SWS_LinSM_00166]).

If ComM requests communication release via LinSM_RequestComMode(COMM_FULL_COMMUNICATION), LinSM directly triggers LinIf_Wakeup and starts a monitoring timer ([SWS_LinSM_00047], [SWS_LinSM_00100]). LinIf transmits the physical wakeup pulse onto the bus via Lin_Wakeup ([SWS_LinIf_00205], [SWS_Lin_00043]). If LinIf reports successful wakeup via LinSM_WakeupConfirmation(success=TRUE), the state transitions to LINSM_FULL_COM ([SWS_LinSM_00049], [SWS_LinSM_00132]). This is signaled to ComM via ComM_BusSM_ModeIndication and to BswM via BswM_LinSM_CurrentState ([SWS_LinSM_00033], [SWS_LinSM_00192]). On slaves, the bus is only considered successfully woken up once the master sends the first LIN header and it is received ([SWS_LinIf_00761], SWS LINStateManager p. 28).

Shutting down into sleep mode (Go-to-Sleep) differs substantially: On a master, request COMM_NO_COMMUNICATION leads to a call to LinIf_GotoSleep ([SWS_LinSM_00036], [SWS_LinSM_10208]). LinIf instructs the driver via Lin_GoToSleep to transmit a standardized Go-to-Sleep frame on the bus ([SWS_Lin_00166], [SWS_Lin_00089]). On a slave, by contrast, the interface receives the Go-to-Sleep command or detects a bus-idle timeout and informs LinSM via LinSM_GotoSleepIndication ([SWS_LinSM_91000]). LinSM then synchronously calls LinIf_GotoSleep ([SWS_LinSM_00231]). The interface switches the driver locally to state LIN_CH_SLEEP via Lin_GoToSleepInternal ([SWS_LinIf_00757], [SWS_Lin_00095]) and puts the transceiver into sleep mode via LinIf_SetTrcvMode(LINTRCV_TRCV_MODE_SLEEP) ([SWS_LinIf_00544], AUTOSAR CP SWS LINInterface p. 137). After the confirmation LinSM_GotoSleepConfirmation, LinSM finally transitions to LINSM_NO_COM ([SWS_LinSM_00046], [SWS_LinSM_00233]).

Sequence diagram: Interaction of BSW modules when a LIN slave enters sleep state following a bus sleep signal. Sources: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Error Handling, DET Tracing, and Degradation

The cluster features a multi-level error detection and diagnostic concept. Development errors are recorded via the Default Error Tracer (Det): Invalid channel or network parameters are reported by LIN_E_INVALID_CHANNEL ([SWS_Lin_00259]), LINIF_E_NONEXISTENT_CHANNEL ([SWS_LinIf_00539]), and LINSM_E_NONEXISTENT_NETWORK ([SWS_LinSM_00127]), respectively. Calls to uninitialized modules result in LIN_E_UNINIT, LINIF_E_UNINIT, or LINSM_E_UNINIT ([SWS_Lin_00258], [SWS_LinSM_00128]). Transceiver errors such as invalid network numbers are reported to DET by LINTRCV_E_INVALID_LIN_NETWORK ([SWS_LinTrcv_00145]).

Communication faults occurring during runtime are classified as runtime errors: The interface defines LINIF_E_RESPONSE for erroneous frames and LINIF_E_NC_NO_RESPONSE for missing responses to node configuration requests ([SWS_LinIf_00729]). Physical bus and protocol errors (framing errors, checksum errors, bit monitoring errors) are reported by the MCAL driver on the slave via LinIf_LinErrorIndication with status Lin_SlaveErrorType ([SWS_LinIf_91007], [SWS_Lin_91140]). On master nodes, Lin_GetStatus provides detailed error codes such as LIN_TX_HEADER_ERROR, LIN_TX_ERROR, or LIN_RX_ERROR to the interface ([SWS_Lin_00168], [SWS_Lin_00233]).

A central error mechanism for LIN slaves is the standardized response_error signal. The LIN Interface manages this 1-bit signal autonomously: If a transmission error occurs, LinIf sets the bit, which is transmitted to the master in the next unconditional transmit frame ([SWS_LinIf_00763], SWS LINInterface p. 58). After successful frame transmission, LinIf clears the flag automatically ([SWS_LinIf_00747]). On the diagnostic channel, LinTp monitors strict protocol time windows: If N-PDUs fail to arrive, the timers $N_{As}$ and $N_{Cr}$ abort the transaction in a defined manner and report E_NOT_OK to the PDU Router ([SWS_LinIf_00799], [SWS_LinIf_00804], [SWS_LinIf_00806]). If buffer capacity is lacking at the PDU Router, the interface aborts acceptance and switches the master's schedule table back to application operation ([SWS_LinIf_00676], [SWS_LinIf_00792]).