---
title: "Rest-bus simulation"
---

# Rest-bus simulation

Simulate every node of the network except the devices under test from the database's interaction-layer attributes, drive signals with generators, inject faults, send by hand with Interactive Transmit, run AUTOSAR CAN network management, and simulate CAN and SOME/IP together.

**State:** modelled, with community databases on the virtual bus and python-can; no vendor database was simulated and no real ECU received the frames. Network management is modelled against the specification's state machine and an independent implementation; CAN and Ethernet together against vsomeip.

## Start a simulation

1. Run **Start Rest-Bus Simulation** (Ctrl+Alt+H, the title bar, or the CAN Simulation panel). Only databases that hold a CAN network are offered; an AUTOSAR file with only a LIN cluster is listed under "Not offered" with the reason.
2. Choose the channel and the devices under test, which are left out of the simulation.
3. The **CAN Simulation** panel's **Simulation** view shows the simulated nodes and messages, each message's cycle time and send type, achieved cycle time and jitter, frames sent, the last payload and live values. **Show Rest-Bus Simulation** opens it; **Stop Rest-Bus Simulation** stops it. The status bar says what is running.

![The Simulation view with simulated nodes and messages, each with its cycle time, send type, achieved timing and signal generators.](https://neuralinverse.com/docs-images/modules/automotive/rest-bus-simulation.webp)

Messages follow the interaction-layer attributes:

- cyclic at `GenMsgCycleTime`, with start delays and start values (float start values included);
- OnWrite and OnChange signals triggering sends with repetitions; IfActive messages with their fast cycle and repetitions; `GenMsgFastOnStart`; `GenMsgILSupport` No (the message starts off); delay times;
- Ford's FixedPeriodic, EventPeriodic and Event send types.

What the attributes do not say is shown on the message, never guessed. From a message row you can edit the cycle time, **Set Fast Cycle Time**, **Set Inactive Value**, **Send It Although GenMsgILSupport Is No**, **Send It Every n ms (GenMsgCycleTime)** for an OEM send type the Editor does not interpret, and send it now. Change a signal by physical value or value name, or drive it with a generator: Ramp, Sine, Square, Rolling Counter, Random or Sequence. J1939 nodes claim their addresses and use the transport protocol (see [J1939 networks](https://neuralinverse.com/docs/modules/automotive/j1939/)); protected messages carry E2E and SecOC (see [E2E and SecOC](https://neuralinverse.com/docs/modules/automotive/e2e-and-secoc/)).

## Inject faults

On a message row of a running simulation, **Inject Fault into ...**, for a number of frames or until cleared:

| Fault | Needs |
|---|---|
| Drop frames, repeat each frame, delay the cycle by 1 to 60000 ms | Any message |
| Freeze the E2E counter, skip it by a number of steps, corrupt the CRC | A message with AUTOSAR E2E protection |
| Send a stale freshness value or a wrong MAC | A message with SecOC |
| An error frame in place of each frame | A channel that transmits error frames (the virtual bus, Vector classic CAN, Kvaser with the capability, python-can udp_multicast) |

The faults are applied by the bus host where it protects each frame. A fault that does not fit the message is refused with the reason. The Simulation view shows each message's active faults with the frames injected ("frames dropped: 88 of 600 frames"), and the stop button on the row (Stop Injecting Faults) ends them; stopping the simulation clears them.

Frames a fault touched are marked injected on every channel of the bus: the CAN Bus trace shows, for example, "CRC (injected)" or "Error Frame (injected)", and the Statistics view counts injected failures apart from real ones.

![The Simulation view with an E2E CRC corrupted until cleared on one message and frames dropped on another.](https://neuralinverse.com/docs-images/modules/automotive/simulation-fault-injection.webp)

![The CAN Bus trace flagging frames with an injected E2E CRC fault as injected, apart from frames that pass the check.](https://neuralinverse.com/docs-images/modules/automotive/injected-faults-trace.webp)

Faults are injected into the simulation's cyclic messages, not into Interactive Transmit or J1939 transport transfers. A frame is recognised as injected on another channel by its identifier and bytes within 2 s.

## Send by hand: Interactive Transmit

The **Interactive Transmit** view of the CAN Simulation panel keeps entries in workspace storage:

- **Add Raw Frame to Interactive Transmit** and **Add Database Message to Interactive Transmit**: sent once, cyclically (timed by the bus host) or on a key, with signals edited by physical value or value name;
- **Add Error Frame to Interactive Transmit**: 1 to 1000 error frames per send, once or on a key, never cyclically, on channels that transmit them;
- **Choose Interactive Transmit Channel** and **Stop All Cyclic Interactive Transmit**.

An entry's editor says what the chosen channel does with it, or why it cannot. Protected messages are sent with their E2E counter and CRC and SecOC freshness value and MAC; their counters continue from the simulation's. Interactive Transmit refuses J1939 groups longer than 8 bytes.

![An Interactive Transmit entry of 16 error frames sent on a virtual bus, with the note on what the channel does with them.](https://neuralinverse.com/docs-images/modules/automotive/interactive-transmit-error-frames.webp)

On any channel but the virtual bus, every injection and every interactive send, a key press included, is confirmed.

## AUTOSAR CAN network management

Every simulated node that the database makes a member of an AUTOSAR CanNm cluster runs CAN network management: Bus-Sleep, Prepare Bus-Sleep and the Network Mode with Repeat Message, Normal Operation and Ready Sleep, with the NM-Timeout, Repeat Message, Wait Bus-Sleep and remote sleep indication timers. The NM PDU carries the source node identifier and control bit vector. Cycle offsets, immediate transmissions, bus load reduction, passive nodes, communication control and partial networking are run where the database configures them. A node's other messages are sent only in the Network Mode.

The configuration comes from the database:

- **AUTOSAR system description:** the CAN-NM-CLUSTER of the CAN cluster and its CAN-NM-NODEs.
- **DBC:** the NmAsr attributes (`NmAsrCanMsgCycleTime`, `NmAsrTimeoutTime`, `NmAsrRepeatMessageTime`, `NmAsrWaitBusSleepTime`, `NmAsrCanMsgReducedTime`, `NmAsrCanMsgCycleOffset`, `NmAsrBaseAddress`, `NmAsrMessageCount`, `NmAsrNode`, `NmAsrNodeIdentifier`), with the specification's default PDU layout. Node detection, bus load reduction, remote sleep indication, immediate transmissions and partial networking are off from a DBC.
- A cluster whose timing the database does not give does not run; its NM messages stay with the interaction layer, with a note naming what is missing.

Each simulated node starts by requesting the network. On its row in the Simulation view:

- **Keep the Network Awake** and **Release the Network** request or release the network;
- with node detection, **Send a Repeat Message Request**;
- a node woken by an NM PDU starts up passively and stays in Ready Sleep while another node keeps the network awake.

The view shows each node's NM identifier and state, and on hover the cluster, the NM PDU and what the database leaves open. The CAN Bus trace and the CAN Trace editor name every NM PDU, for example `NmBFC: NM node 0x02 (BFC); CBV 0x00`, with control bits and partial networks by name. On a real bus, keeping awake and releasing are confirmed, naming the node, the channel and what it does to the cluster.

![Three simulated nodes in Normal Operation keeping the network awake, with the NM PDU's cycle measured by the bus host.](https://neuralinverse.com/docs-images/modules/automotive/network-management-awake.webp)

![The CAN Bus trace filtered to NM PDUs, each named with its source node and control bit vector.](https://neuralinverse.com/docs-images/modules/automotive/network-management-trace.webp)

**State:** modelled: the AUTOSAR 4.4.0 state machine by requirement ID, compared with an independent implementation, Vector's published DBC and system extract of one network, the virtual bus and python-can with a peer process. Not run against CANoe or a real ECU. The NM timers run in the window, so a busy window acts on a timeout late; the NM PDU cycle itself is timed by the bus host.

## CAN and Ethernet together

Start the simulation on a channel with an AUTOSAR system description that also describes SOME/IP services. The devices under test are picked from the CAN nodes and from the description's Ethernet ECUs and machines (listed as "Ethernet (SOME/IP)").

- One simulation runs the CAN nodes not under test and every SOME/IP service instance of an ECU or machine not under test, offered by the Editor's SOME/IP node (see [Automotive Ethernet](https://neuralinverse.com/docs/modules/automotive/ethernet/)). The node starts on `neuralInverse.automotive.someip.localAddress`, or asks for an address.
- Both sides start and stop together.
- Where the description maps the same data to a CAN signal and a SOME/IP event or field notifier, the two are one value: write it once from either row. The event row shows the CAN signal it is linked to, with **Show the Mapping in the AUTOSAR File**.
- An event mapped to no CAN signal says so; a link whose CAN signal a device under test sends is shown as not driven. No link is guessed from names or values. Element-level mappings, methods and Classic Platform PDUs on Ethernet are reported, not linked.

**State:** modelled on a description written from the AUTOSAR schema, with vsomeip as the gateway's SOME/IP stack; no public description holds CAN, Ethernet and a mapping between them. The two sides are timed by different processes, so a change reaches them at different times within the cycle.