Local Interconnect Network
Enable an agent to recognise Local Interconnect Network (LIN), assess a declared implementation, and determine which configuration, diagnostic and communication actions its evidence supports.
Bundle → Layer → Finding → Questions Filled
6 bundles · 11 layers · 18 findings · 33 questions
Protocol identity and baseline Establish what LIN means for this entry and which requirements govern an implementation.
Technology boundary
Separate the protocol family from a particular bus, device or field of study.
LIN identity evidence
Record the evidence needed to classify the subject as LIN and distinguish protocol identity from implementation identity.
- Does the record describe the LIN protocol family, a deployed LIN cluster or a component implementing LIN? definition
- Which documented framing and coordination behaviour distinguishes this interface from an ordinary serial link or another single-wire protocol? boundary
Revision and profile
Bind assessments to explicit specification and implementation evidence.
Applicable requirements
Capture the baseline and any declared extensions, omissions or mixed-revision constraints.
- Which specification revision, applicable parts and supplier profile are claimed, and where is that claim documented? provenance
- Which compatibility rules must be checked before combining the cluster's node revisions? boundary
Cluster and electrical interface Relate participating node roles to the bus conditions under which communication is expected.
Node role ownership
Identify cluster membership and separate header initiation from response publication.
Cluster role map
Record expected and observed participants, including the initiating node's own response responsibilities.
- Which node initiates headers, and which nodes publish or subscribe to each configured frame? definition
- What evidence distinguishes an absent node from one that is present but not scheduled to respond? measurement
Electrical and rate envelope
Identify the electrical and timing conditions required by the selected implementation.
Bus operating conditions
Record bitrate, reference conditions, termination and loading evidence without assuming one universal installation limit.
- What bitrate, supply range, reference-ground conditions and bus loading are specified for this cluster? measurement
- Which transceiver documentation and measurements establish acceptable termination and signal levels? provenance
Frames, signals and schedules Connect wire-level exchanges to signal meaning and planned communication timing.
Frame and signal contract
Establish how identifiers, responses and signal definitions combine into interpretable information.
Frame interpretation rules
Capture each frame's publisher, payload interpretation and applicable integrity checks.
- For each frame identifier, what payload length, publisher, checksum mode and signal layout apply? definition
- Which evidence establishes signal byte order, scaling, units and invalid or unavailable encodings? provenance
- How are frame identifiers kept distinct from diagnostic node addresses in interpretation? boundary
Schedule and freshness
Assess frame opportunities, schedule transitions and resulting signal age.
Scheduled delivery contract
Record active schedule behaviour and the conditions under which timing requirements are met.
- What slot durations, repetition periods and schedule-switching rules govern each operating mode? measurement
- Where optional frame types or diagnostic exchanges are used, how do they affect delivery delays and collision handling? boundary
- Which schedule changes preserve the required maximum age of every affected signal? action
Configuration and diagnostics Connect machine-readable cluster descriptions to installed nodes and supported diagnostic operations.
Description and installation alignment
Establish which configuration artefacts accurately describe the deployed cluster.
Configuration authority
Identify authoritative LIN Description File and node capability information where available.
- Which LIN Description File or equivalent configuration defines the cluster, and how is its version tied to installed software? provenance
- What comparison would reveal disagreements between declared frame mappings and observed node behaviour? measurement
Addressing and service support
Determine how diagnostic targets are identified and which services they implement.
Diagnostic operation contract
Record supported addressing, transport behaviour and diagnostic services before selecting an operation.
- How are diagnostic node addresses assigned and associated with supplier or product identification? definition
- Which diagnostic services, response timing and transport constraints are documented for each node? provenance
- What target verification and operating-state prerequisites apply before a diagnostic or configuration-changing request? action
Operating state and recovery Interpret communication health in the context of power state and choose evidence-supported recovery actions.
Sleep and wake transitions
Track intended low-power behaviour and restoration of scheduled communication.
Power-state evidence
Record the observations needed to distinguish normal sleep, wake activity and communication failure.
- Which commands, inactivity conditions and observations establish entry into sleep for this implementation? definition
- Which nodes may initiate wake-up, and what timing evidence confirms return to scheduled communication? measurement
- Under what application conditions may an agent request sleep or initiate wake-up? action
Fault evidence and intervention
Connect observed communication errors to bounded hypotheses and corrective actions.
Communication health assessment
Assess faults using schedule context, electrical evidence and node reports while recording unresolved causes.
- Over what observation interval were missing responses, parity errors, checksum errors and timing violations measured? measurement
- What evidence separates an electrical fault, schedule mismatch, sleeping node and incorrect frame interpretation? boundary
- Which recovery action is supported, and what post-action observation would demonstrate restored communication? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Check these first
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these check these first hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Kinds and varieties
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these kinds and varieties hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Identifiers and schemes
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these identifiers and schemes hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Standards and regulation
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these standards and regulation hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Real-world use
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these real-world use hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Typical measurements
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these typical measurements hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Failure modes and hazards
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these failure modes and hazards hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of Local Interconnect Network this model covers, and on what evidence? provenance
Classifiers Filled
- Family
- Thing Registry
- Category
- Information and virtual systems
- Entry kind
- thing
- Plane
- INF
- Domain
- INF.KNW
What it is Filled
Local Interconnect Network (LIN) is a low-cost, single-wire serial communication network and protocol that uses one scheduling commander and multiple responders to connect sensors and actuators, principally within automotive subsystems.
In scope
- LIN specification identity, revision and implementation profile
- Cluster organisation, node roles and physical communication constraints
- Frame interpretation, signal ownership and schedule behaviour
- Configuration descriptions, diagnostics and node identification
- Communication health, sleep and wake behaviour, and permitted interventions
Out of scope
- CAN, Ethernet and other neighbouring communication protocols
- Complete vehicle electrical architecture and gateway application logic
- Internal design and manufacturing of individual LIN transceivers or microcontrollers
- Mechanical behaviour of actuators and physical sensing principles
- Organisation of automotive engineering as a discipline
- Vehicle-level safety certification and cybersecurity assurance
Why it exists Filled
Enable an agent to recognise Local Interconnect Network (LIN), assess a declared implementation, and determine which configuration, diagnostic and communication actions its evidence supports.
Distinguishing features Filled
- LIN is a low-cost serial communication protocol used mainly in automotive networks, with a single signal wire and communication speeds up to 20 kbit/s; the wire count does not eliminate power and reference-ground requirements. [Microchip LIN overview](https://developerhelp.microchip.com/xwiki/bin/view/applications/lin/overview/)
- A LIN cluster has one node responsible for initiating communication, distinguishing its organisation from a network of competing bus initiators. [Microchip LIN physical layer](https://developerhelp.microchip.com/xwiki/bin/view/applications/lin/lin-physical-layer/)
- A LIN frame separates a commander-generated header from a response carrying one to eight data bytes and a checksum, so a generic UART connection alone does not establish LIN identity. [Microchip LIN commander documentation](https://onlinedocs.microchip.com/oxy/GUID-BF0CC5BA-1C78-4CCE-9C55-E847CB1F91C0-en-US-5/GUID-5A0B2CC1-CBE3-4A83-9491-DDA98FCD5776.html)
- Schedule tables organise frame opportunities; assessment must identify the active schedule as well as decode individual messages. [Microchip LIN data link layer](https://developerhelp.microchip.com/xwiki/bin/view/applications/lin/data-link-layer/)
What robots and AI may and may not do Filled
Must not
- Inject or alter LIN messages on a vehicle it does not own or is not authorized to work on.
- Disable or spoof sensors and actuators, such as window, seat or mirror controls, in a way that endangers occupants.
- Use network access to unlock or start a vehicle without authorization.
Only with a human decision
- Reprogramming nodes on a vehicle in use on public roads.
May
- Read and log LIN traffic on vehicles or test rigs it is authorized to diagnose.
- Report faulty nodes or schedule errors to the vehicle's keeper or technician.
Moral aspects Filled
- Vehicle networks control features occupants rely on, so tampering can endanger people.
- Diagnostic access can be misused for theft.
Who is affected
- Vehicle occupants
- Vehicle keepers
- Technicians
Owners Filled
Steward
The vehicle keeper; the manufacturer answers for the network design.
Links to other meta-models Filled
parent
- Q21078287 - registry parent class
What else AI and robots need to interact with it Filled
Identity and identifiers required Filled
- Vercy registry: vr.tr.local-interconnect-network
- Wikidata: Q1867168 (https://www.wikidata.org/wiki/Q1867168)
Direct properties not applicable Not applicable
- Specification baseline: Named specification, revision, applicable parts and implementation profile
- Configured communication rate: bit/s, recording configured and observed values separately
- Node communication role: Header initiator; response publisher; response subscriber, with roles recorded per node and frame
- Cluster membership: Cluster to expected nodes, observed nodes and node-description evidence
- Frame publication map: Frame identifier to frame type, publisher, subscribers, payload length and signals
- Active schedule: Identified schedule and slot position; transitioning; unknown
- Signal update interval: ms, with required maximum and observed distribution
- Frame checksum mode: Classic; enhanced; unresolved, assessed per frame against the baseline
- Communication power state: Awake; sleep requested; asleep; waking; unknown
- Communication fault observations: Counts and rates of missing responses, parity errors, checksum errors and timing violations over a stated interval
Plane INF: no invented physical properties.
Recognition optional Filled
- A single signal wire bundled with power and ground to small modules such as switches and motors.
Capabilities and actions required Filled
- Classify a claimed interface as LIN using specification, configuration and trace evidence.
- Interpret a capture using its frame publication map, signal definitions and active schedule.
- Check whether proposed nodes and configurations are compatible with the declared cluster baseline.
- Assess whether schedule timing can satisfy stated signal freshness requirements.
- Identify plausible causes of missing or invalid responses and select targeted verification steps.
- Determine prerequisites for changing schedules, invoking supported diagnostics or initiating sleep and wake operations.
Hazards and failure modes required Filled
- A failed commander node can stop all connected functions.
- Wiring faults cause intermittent loss of features like wipers or windows.
Standards and interfaces required Filled
- ISO 17987, Road vehicles, Local Interconnect Network (LIN), International Organization for Standardization.
Context of use required Filled
- Local Interconnect Network is used within vehicles to connect relatively simple sensors and actuators in subsystems such as doors, seats and climate controls.
- It supports scheduled communication where low wiring cost and modest data rates suit the application.
- Engineers and diagnostic agents encounter it when checking subsystem configuration, message schedules and communication faults.
Sources Filled
- Wikidata item Q1867168: Local Interconnect Network - identity and sense of the item
- Wikipedia: Local Interconnect Network - general description of the item
Open questions
- Does an existing Vercy world model already cover LIN, requiring this registry entry to link to that publication?
- Should this entry encompass all LIN revisions and ISO standardised variants, or use a particular baseline with explicit extensions?
- Which authoritative documents establish revision-specific electrical limits, timing tolerances and compatibility requirements?
- Which optional frame types, configuration mechanisms and diagnostic capabilities warrant dedicated treatment rather than implementation-specific questions?
- Should deployed LIN clusters have a separate instance model linked to this protocol model, and which observations belong exclusively there?
Machine files
Provenance
thing registry research (pass 2) · unreviewed
Built from: models/things/publications/thing-q1867168/spec.json