Virtual LIN is a practical starting point. But at some stage, physical ECUs, sensors, or other hardware need to be introduced. The challenge is making that transition without breaking existing setups or creating separate configurations that drift apart over time.

In many toolchains, moving to hardware means rebuilding network descriptions, reassigning nodes, or implementing hardware-specific handling. This is especially true for LIN, where hardware access is not standardized but vendor-specific - requiring different APIs, drivers, and integration models.

The result? Increased complexity just as systems become harder to manage.

A single platform for virtual and physical LIN nodes

RemotiveTopology uses the same platform definition for both virtual and physical LIN nodes, while the instance (runtime definition) is used to configure which nodes are run as physical entities.

When hardware is introduced, individual nodes can be moved from a virtual execution to a physical LIN bus - while the rest of the system continues to run virtually. From the system’s point of view, all nodes still belong to the same LIN cluster, with the same roles, schedules, and signal definitions. This makes it possible to:

• Add physical ECUs step by step
• Keep the rest of the system virtual
• Preserve addressing, schedules, and overall network structure

‍

‍

A consistent LIN bus API - independent of hardware vendor

LIN hardware access brings additional challenges due to the non-standardized host APIs. RemotiveBus is the component in RemotiveTopology that makes it possible to extend virtual LIN communication into the physical domain. It is a Docker network plugin developed by RemotiveLabs that abstracts vendor APIs behind a consistent interface, supporting both virtual and physical networks within the same runtime environment. How using RemotiveTopology simplifies LIN-development and integration:

• ‍One integration model from virtual to physical Move from a fully virtual LIN setup to hybrid hardware setups without rebuilding network descriptions or changing drivers. The same runtime model applies throughout.‍
• Vendor-independent LIN API Vendor-specific drivers are handled through RemotiveBus plugins - not spread across your test framework or applications.‍
• Deterministic lifecycle management RemotiveBus manages the full lifecycle of LIN networks: starting, restarting, and stopping both virtual and physical connections in a controlled way. This gives you predictable environments for CI, local development, and hybrid testing without manual reconfiguration.
  ‍

Adding your own LIN bridge (RemotiveBus plugins)

RemotiveBus is designed to make it straightforward to add your own LIN bridge as a RemotiveBus plugin, using the programming language of your choice.

A plugin integrates with RemotiveBus through a well-defined interface and focuses only on forwarding LIN traffic to and from the hardware interface. This keeps vendor-specific logic isolated and allows the rest of the system to remain unchanged.

[nfobox]

Kvaser LIN bus example: 

To make this concrete, RemotiveLabs provides an open-source RemotiveBus plugin for the Kvaser Hybrid Pro CAN/LIN interfaces, written in Rust. This example can be used both as a reference and as a starting point for supporting other LIN tools and vendors.

Go to Kvaser LIN bus example

Kvaser Hybrid Pro CAN/LIN interfaces

[/nfobox]

‍

A controlled transition from SIL to HIL

By adding physical LIN nodes only when they are needed, teams get a controlled path from SIL to HIL:

• Early validation can run without hardware dependencies
• Physical components are introduced step by step
• Existing tests and integrations continue to work

This reduces integration risk and makes hardware validation a natural continuation of earlier development work. Learn more about a smoother SIL to HIL transition. 

With RemotiveTopology, virtual and physical LIN are not separate workflows. They are parts of the same system, evolving together as development progresses.

‍

‍