{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.tr.local-interconnect-network","code":"thing-q1867168","url":"https://ver.cy/models/thing/q1867168/","name":"Local Interconnect Network","alternateNames":[],"kind":"thing","status":"published","version":"0.1.0-research.1","language":"en","classifiers":{"family":"Thing Registry","category":"Information and virtual systems","entryKind":"thing","plane":"INF","domain":["INF.KNW"],"industry":[],"navPath":"","tags":[],"facets":{}},"whatItIs":"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.","purpose":"Enable an agent to recognise Local Interconnect Network (LIN), assess a declared implementation, and determine which configuration, diagnostic and communication actions its evidence supports.","scope":{"in":["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":["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"],"boundaries":[]},"distinguishingFeatures":["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/)"],"structure":{"bundles":[{"id":"protocol-identity-and-baseline","name":"Protocol identity and baseline","description":"Establish what LIN means for this entry and which requirements govern an implementation.","layers":[{"id":"technology-boundary","name":"Technology boundary","description":"Separate the protocol family from a particular bus, device or field of study.","findings":[{"id":"lin-identity-evidence","name":"LIN identity evidence","description":"Record the evidence needed to classify the subject as LIN and distinguish protocol identity from implementation identity.","questions":[{"text":"Does the record describe the LIN protocol family, a deployed LIN cluster or a component implementing LIN?","id":"lin-identity-evidence-q01","kind":"definition"},{"text":"Which documented framing and coordination behaviour distinguishes this interface from an ordinary serial link or another single-wire protocol?","id":"lin-identity-evidence-q02","kind":"boundary"}]}]},{"id":"revision-and-profile","name":"Revision and profile","description":"Bind assessments to explicit specification and implementation evidence.","findings":[{"id":"applicable-requirements","name":"Applicable requirements","description":"Capture the baseline and any declared extensions, omissions or mixed-revision constraints.","questions":[{"text":"Which specification revision, applicable parts and supplier profile are claimed, and where is that claim documented?","id":"applicable-requirements-q01","kind":"provenance"},{"text":"Which compatibility rules must be checked before combining the cluster's node revisions?","id":"applicable-requirements-q02","kind":"boundary"}]}]}]},{"id":"cluster-and-electrical-interface","name":"Cluster and electrical interface","description":"Relate participating node roles to the bus conditions under which communication is expected.","layers":[{"id":"node-role-ownership","name":"Node role ownership","description":"Identify cluster membership and separate header initiation from response publication.","findings":[{"id":"cluster-role-map","name":"Cluster role map","description":"Record expected and observed participants, including the initiating node's own response responsibilities.","questions":[{"text":"Which node initiates headers, and which nodes publish or subscribe to each configured frame?","id":"cluster-role-map-q01","kind":"definition"},{"text":"What evidence distinguishes an absent node from one that is present but not scheduled to respond?","id":"cluster-role-map-q02","kind":"measurement"}]}]},{"id":"electrical-and-rate-envelope","name":"Electrical and rate envelope","description":"Identify the electrical and timing conditions required by the selected implementation.","findings":[{"id":"bus-operating-conditions","name":"Bus operating conditions","description":"Record bitrate, reference conditions, termination and loading evidence without assuming one universal installation limit.","questions":[{"text":"What bitrate, supply range, reference-ground conditions and bus loading are specified for this cluster?","id":"bus-operating-conditions-q01","kind":"measurement"},{"text":"Which transceiver documentation and measurements establish acceptable termination and signal levels?","id":"bus-operating-conditions-q02","kind":"provenance"}]}]}]},{"id":"frames-signals-and-schedules","name":"Frames, signals and schedules","description":"Connect wire-level exchanges to signal meaning and planned communication timing.","layers":[{"id":"frame-and-signal-contract","name":"Frame and signal contract","description":"Establish how identifiers, responses and signal definitions combine into interpretable information.","findings":[{"id":"frame-interpretation-rules","name":"Frame interpretation rules","description":"Capture each frame's publisher, payload interpretation and applicable integrity checks.","questions":[{"text":"For each frame identifier, what payload length, publisher, checksum mode and signal layout apply?","id":"frame-interpretation-rules-q01","kind":"definition"},{"text":"Which evidence establishes signal byte order, scaling, units and invalid or unavailable encodings?","id":"frame-interpretation-rules-q02","kind":"provenance"},{"text":"How are frame identifiers kept distinct from diagnostic node addresses in interpretation?","id":"frame-interpretation-rules-q03","kind":"boundary"}]}]},{"id":"schedule-and-freshness","name":"Schedule and freshness","description":"Assess frame opportunities, schedule transitions and resulting signal age.","findings":[{"id":"scheduled-delivery-contract","name":"Scheduled delivery contract","description":"Record active schedule behaviour and the conditions under which timing requirements are met.","questions":[{"text":"What slot durations, repetition periods and schedule-switching rules govern each operating mode?","id":"scheduled-delivery-contract-q01","kind":"measurement"},{"text":"Where optional frame types or diagnostic exchanges are used, how do they affect delivery delays and collision handling?","id":"scheduled-delivery-contract-q02","kind":"boundary"},{"text":"Which schedule changes preserve the required maximum age of every affected signal?","id":"scheduled-delivery-contract-q03","kind":"action"}]}]}]},{"id":"configuration-and-diagnostics","name":"Configuration and diagnostics","description":"Connect machine-readable cluster descriptions to installed nodes and supported diagnostic operations.","layers":[{"id":"description-and-installation-alignment","name":"Description and installation alignment","description":"Establish which configuration artefacts accurately describe the deployed cluster.","findings":[{"id":"configuration-authority","name":"Configuration authority","description":"Identify authoritative LIN Description File and node capability information where available.","questions":[{"text":"Which LIN Description File or equivalent configuration defines the cluster, and how is its version tied to installed software?","id":"configuration-authority-q01","kind":"provenance"},{"text":"What comparison would reveal disagreements between declared frame mappings and observed node behaviour?","id":"configuration-authority-q02","kind":"measurement"}]}]},{"id":"addressing-and-service-support","name":"Addressing and service support","description":"Determine how diagnostic targets are identified and which services they implement.","findings":[{"id":"diagnostic-operation-contract","name":"Diagnostic operation contract","description":"Record supported addressing, transport behaviour and diagnostic services before selecting an operation.","questions":[{"text":"How are diagnostic node addresses assigned and associated with supplier or product identification?","id":"diagnostic-operation-contract-q01","kind":"definition"},{"text":"Which diagnostic services, response timing and transport constraints are documented for each node?","id":"diagnostic-operation-contract-q02","kind":"provenance"},{"text":"What target verification and operating-state prerequisites apply before a diagnostic or configuration-changing request?","id":"diagnostic-operation-contract-q03","kind":"action"}]}]}]},{"id":"operating-state-and-recovery","name":"Operating state and recovery","description":"Interpret communication health in the context of power state and choose evidence-supported recovery actions.","layers":[{"id":"sleep-and-wake-transitions","name":"Sleep and wake transitions","description":"Track intended low-power behaviour and restoration of scheduled communication.","findings":[{"id":"power-state-evidence","name":"Power-state evidence","description":"Record the observations needed to distinguish normal sleep, wake activity and communication failure.","questions":[{"text":"Which commands, inactivity conditions and observations establish entry into sleep for this implementation?","id":"power-state-evidence-q01","kind":"definition"},{"text":"Which nodes may initiate wake-up, and what timing evidence confirms return to scheduled communication?","id":"power-state-evidence-q02","kind":"measurement"},{"text":"Under what application conditions may an agent request sleep or initiate wake-up?","id":"power-state-evidence-q03","kind":"action"}]}]},{"id":"fault-evidence-and-intervention","name":"Fault evidence and intervention","description":"Connect observed communication errors to bounded hypotheses and corrective actions.","findings":[{"id":"communication-health-assessment","name":"Communication health assessment","description":"Assess faults using schedule context, electrical evidence and node reports while recording unresolved causes.","questions":[{"text":"Over what observation interval were missing responses, parity errors, checksum errors and timing violations measured?","id":"communication-health-assessment-q01","kind":"measurement"},{"text":"What evidence separates an electrical fault, schedule mismatch, sleeping node and incorrect frame interpretation?","id":"communication-health-assessment-q02","kind":"boundary"},{"text":"Which recovery action is supported, and what post-action observation would demonstrate restored communication?","id":"communication-health-assessment-q03","kind":"action"}]}]}]},{"id":"evidence-and-external-alignment","name":"Evidence and external alignment","description":"What the world already says about this thing, gathered so the model can be checked against it.","layers":[{"id":"reported-evidence","name":"Reported evidence","description":"Findings from the breadth pass, kept separate from the structural claims.","findings":[{"id":"evidence-confidence-notes","name":"Check these first","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these check these first hold for the sense of Local Interconnect Network this model covers, and on what evidence?","id":"evidence-confidence-notes-q01","kind":"provenance"}]},{"id":"evidence-kinds","name":"Kinds and varieties","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these kinds and varieties hold for the sense of Local Interconnect Network this model covers, and on what evidence?","id":"evidence-kinds-q01","kind":"provenance"}]},{"id":"evidence-identifiers","name":"Identifiers and schemes","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these identifiers and schemes hold for the sense of Local Interconnect Network this model covers, and on what evidence?","id":"evidence-identifiers-q01","kind":"provenance"}]},{"id":"evidence-standards-and-regulation","name":"Standards and regulation","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these standards and regulation hold for the sense of Local Interconnect Network this model covers, and on what evidence?","id":"evidence-standards-and-regulation-q01","kind":"provenance"}]},{"id":"evidence-real-world-use","name":"Real-world use","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these real-world use hold for the sense of Local Interconnect Network this model covers, and on what evidence?","id":"evidence-real-world-use-q01","kind":"provenance"}]},{"id":"evidence-measurements","name":"Typical measurements","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these typical measurements hold for the sense of Local Interconnect Network this model covers, and on what evidence?","id":"evidence-measurements-q01","kind":"provenance"}]},{"id":"evidence-failure-modes-and-hazards","name":"Failure modes and hazards","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these failure modes and hazards hold for the sense of Local Interconnect Network this model covers, and on what evidence?","id":"evidence-failure-modes-and-hazards-q01","kind":"provenance"}]},{"id":"evidence-neighbours","name":"Neighbouring kinds and how to tell them apart","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"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?","id":"evidence-neighbours-q01","kind":"provenance"}]}]}]}]},"agentConduct":{"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."],"mustNot":["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."],"requiresHuman":["Reprogramming nodes on a vehicle in use on public roads."]},"ethics":{"considerations":["Vehicle networks control features occupants rely on, so tampering can endanger people.","Diagnostic access can be misused for theft."],"affectedParties":["Vehicle occupants","Vehicle keepers","Technicians"]},"owners":{"steward":"The vehicle keeper; the manufacturer answers for the network design.","roles":[],"masterSystems":[]},"relations":[{"target":"Q21078287","type":"parent","note":"registry parent class"}],"interaction":{"identity":{"applicability":"required","items":["Vercy registry: vr.tr.local-interconnect-network","Wikidata: Q1867168 (https://www.wikidata.org/wiki/Q1867168)"]},"properties":{"applicability":"not-applicable","items":["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"]},"recognition":{"applicability":"optional","items":["A single signal wire bundled with power and ground to small modules such as switches and motors."]},"capabilities":{"applicability":"required","items":["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":{"applicability":"required","items":["A failed commander node can stop all connected functions.","Wiring faults cause intermittent loss of features like wipers or windows."]},"interfaces":{"applicability":"required","items":["ISO 17987, Road vehicles, Local Interconnect Network (LIN), International Organization for Standardization."]},"context":{"applicability":"required","items":["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":[{"title":"Wikidata item Q1867168: Local Interconnect Network","url":"https://www.wikidata.org/wiki/Q1867168","note":"identity and sense of the item"},{"title":"Wikipedia: Local Interconnect Network","url":"https://en.wikipedia.org/wiki/Local_Interconnect_Network","note":"general description of the item"}],"openQuestions":["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?"],"resources":{"spec":"/models/things/publications/thing-q1867168/spec.json"},"provenance":{"origin":"thing registry research (pass 2)","builtFrom":["models/things/publications/thing-q1867168/spec.json"],"providers":["Codex"],"researchStatus":"unreviewed","generatedAt":"2026-09-12T11:00:35Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"filled","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"_gate":"Published through the thing publication gate 1.0 on 2026-10-07T10:10:27+00:00: completeness 1.00; sense: Wikidata description; 2 live sources; review by codex: pass","interaction.properties":"Plane INF: no invented physical properties."},"score":1.0}}