Virtual LIN in vehicle platforms
RemotiveTopology has long supported virtual CAN and Ethernet to enable software-based development and testing of vehicle platforms. With the addition of virtual LIN (Local Interconnect Network), teams can now model, test, and validate complete LIN clusters directly in software, no physical setup required.

Virtual LIN in vehicle platforms
RemotiveTopology has long supported virtual CAN and Ethernet to enable software-based development and testing of vehicle platforms. With the addition of virtual LIN (Local Interconnect Network), teams can now model, test, and validate complete LIN clusters directly in software, no physical setup required.
How virtual LIN in addition to virtual CAN is enabled in RemotiveToplogy
Unlike CAN, which is well supported in Linux through SocketCAN and can be mapped directly to network interfaces, LIN does not have a native equivalent on most computers.
To enable virtual LIN in RemotiveTopology, we therefore transport LIN traffic over existing, well-supported mechanisms - primarily CAN frames, with UDP as an alternative when appropriate.
Importantly, the LIN frame payload itself remains unchanged. This allows developers to continue using familiar tooling such as Wireshark or candump to inspect, debug, and reason about LIN communication, even in a fully virtual setup.

LIN master and slave support in every node
In RemotiveTopology, a LIN node can operate as either a master or slave (read more about LIN on Wikipedia):
- a LIN master, scheduling frames and controlling the bus
- a LIN slave, responding with data when addressed
This allows complete LIN clusters to be modeled virtually, including realistic master-slave behavior across multiple ECUs.
LIN configuration from standard automotive formats
RemotiveTopology integrates naturally into existing automotive workflows by reading much of the LIN configuration directly from established industry formats such as:
- LDF (LIN Description Files)
- ARXML (AUTOSAR XML)
This makes it possible to reuse the same network definitions and signal descriptions that are already part of an OEM or supplier toolchain, while running the communication fully virtually.
Adding LIN to your RemotiveTopology project
A LIN channel is easily added to your RemotiveTopology platform:
platform:
channels:
RearLightLIN:
type: lin
database: ./databases/rearlight.ldfTo define how the virtual LIN channel behaves at runtime, we add it to the instance configuration:
channels:
RearLightLIN:
type: lin
driver:
type: remotivebus
ecus:
RLCM:
channels:
RearLightLIN:
type: lin
schedule_autostart: true
schedule_table_name: LIN01Schedule01Here, the LIN bus is configured to use RemotiveBus to transport LIN traffic over CAN. RemotiveBus provides a consistent way to route vehicle communication between virtual ECUs, independent of the underlying transport technology. The master ECU, RLCM, is configured to automatically start controlling the bus according to the defined LIN schedule.
Moving from virtual LIN to physical LIN when you’re ready
Virtual LIN is a powerful way to accelerate development and integration testing early in the lifecycle. But as projects mature, teams often want to connect their virtual setup to real vehicle networks and hardware test benches.
When you’re ready to transition from Software-in-the-Loop (SIL) to Hardware-in-the-Loop (HIL), RemotiveTopology also supports bridging virtual LIN communication to physical LIN environments.
This allows you to start fully virtual, iterate quickly, and then scale into hardware validation without changing your overall topology or development approach.
Check out the latest from us
Join the automotive rebels that #getstuffdone with RemotiveLabs!







