LIN Architecture & Master/Slave Concept - Vehicle Networks

LIN Physical Layer

LIN Single-Wire Bus Topology

  LIN Master (e.g., BCM)
  ┌────────────────────────────────────────┐
  │  MCU UART TX ──► Lin Transceiver       │
  │                  (NXP MC33662)         │
  │  1 kΩ pull-up to Vbat ──────────────── ┼──► LIN bus (single wire)
  └────────────────────────────────────────┘         │
                                                      │
  LIN Slave 1 (Window Motor)            LIN Slave 2 (Mirror)
  ┌─────────────────────────┐           ┌──────────────────────┐
  │ ~30 kΩ internal pull-up │           │ ~30 kΩ internal      │
  │ Lin Transceiver ────────┼───────────┼──────────────────────┤
  └─────────────────────────┘           └──────────────────────┘

  Dominant = 0 V (grounded by transmitter)
  Recessive = Vbat (12 V) via pull-up
  Max 16 nodes, 40 m, 1.2–19.2 kbps

Parameter	Value	Note
Supply voltage	12 V (Vbat)	LIN defined for 12 V automotive supply
Dominant level	0 V	Transmitter grounds the bus
Recessive level	Vbat (~12 V)	Pull-up resistor charges bus
Master pull-up	1 kΩ	Determines recessive recovery time
Slave pull-up	~30 kΩ (internal)	Weaker than master — master always wins
Max speed	19.2 kbps	Standard; 20 kbps in LIN 2.2
Max nodes	16 slaves + 1 master	Capacitance limit

Master/Slave Roles

The LIN master owns the bus entirely — it generates the Break field and Sync byte that start every frame, then the Protected Identifier byte that designates which node responds. Slaves can only transmit their response after receiving and validating their own PID. Collisions are impossible: exactly one node (the designated publisher) responds to each PID.

Role	Transmits	Receives	Collision Possible?
Master	Break + Sync + PID for every slot	Slave responses in subscriber frames	No
Publisher Slave	Response (data + checksum) after its PID	All headers	No — only one publisher per PID
Subscriber Slave	Nothing (listens only)	All frames matching its subscriber IDs	No

Schedule Table: Fixed Polling Cycle

LDFbody_schedule.ldf

/* LIN schedule table — master sends these PIDs in order */
Schedule_tables {
  Normal_Schedule {
    /* Slot 0: read window motor position every 10 ms */
    Window_Motor_Frame    delay 10 ms;
    /* Slot 1: read mirror position every 10 ms */
    Mirror_Frame          delay 10 ms;
    /* Slot 2: write seat heater command every 20 ms (master transmits) */
    Seat_Heater_Cmd       delay 20 ms;
    /* Slot 3: read door status every 50 ms */
    Door_Status_Frame     delay 50 ms;
  }
  Diagnostic_Schedule {
    /* Switch to this schedule during UDS session */
    MasterReq             delay 10 ms;   /* PID 0x3C: master sends UDS request */
    SlaveResp             delay 10 ms;   /* PID 0x3D: slave sends UDS response */
  }
}

AUTOSAR LIN Driver Stack

AUTOSAR Layer	Module	Responsibility
MCAL	LIN Driver (Lin.h)	Hardware UART with Break generation; Lin_SendFrame(), Lin_GetStatus()
HAL	LIN Interface (LinIf)	Executes schedule table; calls Lin driver per slot; handles response timeout
HAL	LIN Transport Protocol (LinTp)	Segments multi-byte UDS messages across diagnostic slots (PID 0x3C/0x3D)
Services	DCM	Routes UDS services to LinTp for diagnostic sessions
Services	NvM/DEM	Stores LIN diagnostic data; generates DEM events for LIN errors

Summary

LIN's master/slave architecture with a fixed schedule table eliminates all collision and arbitration complexity at the cost of flexibility. The master controls 100% of bus timing — no slave can transmit without first receiving its PID in a master header. This determinism makes LIN ideal for body actuators (window motors, mirrors, seat heaters) where low cost and simplicity matter more than bandwidth or latency.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.