In short
Rest bus simulation replaces the missing ECUs of a vehicle network with a simulated model so that one real ECU sees a complete bus. On CAN that means transmitting the frames the absent nodes would have sent. On automotive Ethernet it means simulating services rather than frames: the simulator has to offer service instances over SOME/IP service discovery with valid endpoint options and TTLs, accept or refuse eventgroup subscriptions, hold connection-oriented endpoints open, join or publish the right multicast groups, and often take a defined role in the time synchronisation domain. Choose the fidelity level deliberately, because a simulator that answers correctly and instantly is a peer the vehicle does not contain.
Rest bus simulation usually arrives in an Indian engineering team as a line in a customer requirement document, using a term most available material defines for CAN and leaves there. That definition is correct and not enough, because what is being asked for on an Ethernet programme is a different object.
This article is about that difference. It assumes the physical layer, covered in our complete guide to automotive Ethernet, and SOME/IP as the application protocol, covered in our SOME/IP explainer.
What rest bus simulation means
One real ECU, every other node simulated
A rest bus simulation replaces the ECUs that are not on your bench with a model, so the one real ECU you are testing sees what it takes to be a complete network. The device under test is real hardware running real software; everything it talks to is generated. That moves integration testing to the left: you do not need eleven other ECUs, a harness or a vehicle to find out that your ECU transmits before the network is ready, or subscribes to an eventgroup nobody is offering.
The terms you will see in requirement documents
Rest bus, residual bus and remaining bus all name the same thing. The word rest is the remainder sense, from the German Restbussimulation: the rest of the bus, not a bus at rest. Requirement documents use the three interchangeably, and no technical distinction hides between them.
Where it sits relative to unit test, HIL and vehicle test
Software-only tests do not exercise the network stack, the switch port or the physical layer. Vehicle test exercises everything at once, late and with poor observability. Rest bus simulation sits between them: real hardware, real stack, real wire, controlled peers. It is distinct from hardware-in-the-loop, though the two are often bought together: a HIL adds a plant model, a rest bus adds simulated communication peers. Needing one does not imply needing the other, and our ECU testing over Ethernet article sets out where a plant model earns its place in a communication suite.
From frames to services: what changes on Ethernet
Cyclic frames versus request, response, event and field
A CAN rest bus is close to a playback problem: the matrix says which identifiers exist, at what rate, with what layout, and a simulator that transmits them with plausible content has done most of the job.
SOME/IP inverts this. A provider offers a service, a consumer looks for it, and communication starts once the two agree at runtime that the service exists at a given address, port, transport and interface version. There is no fixed frame to replay because there is no fixed frame.
You must simulate service discovery, not only the payload traffic
This is the part teams underestimate. The AUTOSAR SOME/IP-SD specification requires Offer Service entries to reference either an IPv4 or an IPv6 Endpoint Option to signal how the service is reachable, one per transport protocol the service needs. Address, port and transport are learned, not configured, and a consumer built against that model will not accept payload from an endpoint it was never told about.
Discovery also has structure a simulator has to reproduce: an Initial Wait Phase with a randomised delay, a Repetition Phase whose delay starts at REPETITIONS_BASE_DELAY and doubles after each message, with the number of repetitions bounded by REPETITIONS_MAX, and a Main Phase in which the provider waits one CYCLIC_OFFER_DELAY before its first offer, then repeats at that interval. A FindService entry received during the Initial Wait Phase for that server service instance must be ignored, so a simulator that answers a find the instant it starts is doing what the specification tells it not to.
TTL matters for the same reason. It is the lifetime of the service instance, must not be 0x000000 because that value is the Stop Offer, and where CYCLIC_OFFER_DELAY is defined it must be greater than or equal to it. Get it wrong and a healthy service flickers in and out of availability between two correct offers.
Connection-oriented endpoints: sockets, ports and who initiates
On CAN nobody initiates anything. On Ethernet, direction is a design fact the model has to get right. Where events are carried over TCP, the specification is explicit that they use the TCP connection the client opened to the server before sending the Subscribe Eventgroup entry. If your simulator plays the server it waits; if it plays the client it connects first, then subscribes. Backwards gives you a bench where nothing arrives and every message looks correct. Our service discovery debugging article works through the reliable versus unreliable mismatch in detail.
Multicast group membership and the switch configuration it assumes
Eventgroups can be delivered by multicast, and the specification puts that endpoint in the acknowledgement: a Subscribe Eventgroup Ack references up to one Multicast Option for the internet protocol in use, IPv4 or IPv6 and not both, the option is set to UDP as its transport, and the client must open the endpoint it names as fast as possible so as not to miss events. There is a refusal case worth knowing too: a server receiving a Subscribe Eventgroup without a UDP endpoint option, where the eventgroup’s multicast threshold is not configured as one, sends a Nack.
So multicast is not a property of your simulator alone: the group has to be joined on the receiving side and forwarded by the switch, and a lab switch whose snooping differs from the vehicle switch changes what the device under test receives without a line of your model changing. Our lab switch selection guide covers the criteria, and our capture point article covers why your capture may not show it.
The simulator may also need a time synchronisation role
If the deployment has a time domain, someone on the bench has to be in it. Decide explicitly whether the simulator is grandmaster, a time-aware endpoint or absent, and record it in the bench definition: where the deployment leaves the selection algorithm enabled, a simulator that is grandmaster by default removes any test of the device under test’s own role selection; where the automotive profile disables the BMCA and assigns roles statically, the test is a configuration test instead. Our time sync validation article covers stating that role as a measured property, and our gPTP troubleshooting guide covers the domain not forming.
What you need before you can build one
Interface and network descriptions
The model is generated from the deployment’s description, which on an AUTOSAR project is ARXML derived from the System Template. Check which extract you were given. The System Template distinguishes a System Description for the complete system, a System Extract that is a subsystem specific view still containing compositions, and an ECU Extract that is the ECU specific view generated for a single ECU. Hand a bench team the device under test’s own ECU Extract and they have a description of the one node they are not simulating. Ask for the system level description, and ask early.
If you also want readable payloads in your capture tool, note that the commonly used generator of Wireshark configuration reads FIBEX 4 XML, not ARXML. Our payload decode article covers that path, and our decode fix list covers nothing decoding at all.
The address, VLAN and endpoint plan
An Ethernet rest bus needs a network plan as well as a matrix: which addresses the simulated nodes hold, which VLANs carry which traffic, which ports each service instance is offered on, which multicast groups exist. If that plan does not exist as a document, your simulator configuration becomes it by accident, and the bench is the only place the deployment is written down.
Which peers are in scope, and which are deliberately absent
Not every absent ECU should be simulated. A peer the device under test never talks to is cost with no coverage, and one it talks to only during diagnostics may be better served by a real diagnostic tester, which our diagnostics over IP article covers. Write down, for each node, one of three states: simulated, real, or deliberately absent. The third is a test condition, not an omission.
Configuration under version control
The simulator configuration is test equipment and it decides pass and fail. As a hand-edited file on one bench PC, a regression in the bench is indistinguishable from a regression in the product. Keep it in the repository with the tests, tag it with the software version it ran against, and generate it from the network description where you can.
Fidelity levels, choose deliberately
A common disappointment with rest bus simulation comes from buying one level and expecting another. The levels are cumulative, and each has a real use.
| Level | What is simulated | What it catches | Effort | Typical use |
|---|---|---|---|---|
| 1. Capture replay | Recorded traffic played back on the wire | Parsing, decoding, a stack that does not come up | Low | First bring-up, capture tool validation |
| 2. Service model | Service instances offered over discovery, requests answered correctly | Discovery configuration, version and transport mismatches, return code handling | Medium | Integration bring-up, acceptance benches |
| 3. Behavioural model | State, timing, startup and shutdown participation, network management | Ordering defects, sleep behaviour, timeouts, subscription renewal | High | Lifecycle campaigns, release qualification |
| 4. Fault-capable model | Deliberate deviation on demand: delay, refuse, stop, restart | Error and timeout paths, restart detection, degraded-mode behaviour | Highest | Safety and robustness campaigns |
Level 1, replay of a recorded capture
A captured file put back on the wire. It proves a bench works and exercises a capture and decode chain. It is not a peer: it does not answer, so any test whose result depends on what the device under test sent is out of scope by construction.
Level 2, service model that answers requests correctly
The first level that is a peer. Service instances are offered through discovery with correct endpoint options and TTLs, subscriptions are acknowledged or refused, methods return correct return codes. Many acceptance benches live here, and much of the value with them. Its limit is memory: a model that answers identically regardless of what happened earlier cannot test anything sequence dependent.
Level 3, behavioural model with state, timing and lifecycle participation
The peers now have a state machine: they start at a defined moment, participate in network management, respond according to what has already happened, and stop in a defined way. This is where the lifecycle defects in our ECU testing over Ethernet article become testable, because holding a peer down or refusing to release the network are state, not payload.
Level 4, fault-capable model that can misbehave on demand
A model you can instruct to be wrong: answer late, answer with an error, stop offering without a Stop Offer so the client expires the service on TTL, refuse a subscription, restart. Each has a defined correct response in the device under test, which separates fault injection from noise. Safety programmes generally need this level, and buying it without ever scripting a fault wastes it.
Where Ethernet rest bus simulation breaks
These are the failures that produce a green bench and a red vehicle, and none is a defect in the simulator.
Discovery timing that is right on the bench and wrong in the vehicle
Discovery on a bench with two nodes is not discovery on a vehicle network with dozens. The randomised initial delay that spreads announcements across a real network has almost nothing to spread, the repetition phase completes uncontested, and offers do not compete for the switch’s multicast forwarding. A device under test that depends on a service being available within some window therefore passes comfortably at the bench and marginally in the vehicle.
Make the timing parameters explicit test variables: run the suite at the deployment’s configured values, then again with initial delays and cyclic offer delays at their worst case.
A simulator that answers too fast, hiding real timeout handling
This is the most consequential one. The SOME/IP specification states that the protocol achieves maybe reliability with the UDP binding, that the client has to wait for the response for a specified timeout, and that SOME/IP signals E_TIMEOUT to the client application if that timeout occurs. That is a state transition in your product, and a simulator that always answers within a millisecond means it is never taken.
The specification is stricter about response timing than most models are, too. Answers to entries received in multicast discovery messages must be delayed using REQUEST_RESPONSE_DELAY, specified as a minimum and a maximum with the delay chosen randomly between them; only unicast answers to unicast messages are exempt. A model that replies to a multicast find instantly, rather than applying the deployment’s configured REQUEST_RESPONSE_DELAY, is both unrealistic and outside the specification.
Port and endpoint collisions when several simulated services share one host
On a vehicle the simulated services live on separate ECUs with separate addresses. On a bench they usually share one process on one host, and the port space with it. The open source vsomeip stack documents the failure for its client port configuration: the stack takes the first free port of the configured list, the connection fails if no free port can be found, and the configured ports must not overlap with those the IP stack selects automatically. The symptom is a connection that never appears on the wire, which looks identical to a discovery problem. Assign the bench port space in the network plan, not per service as you add it.
The simulator as an unintentionally perfect peer
A real ECU is late sometimes, drops a frame sometimes, and reboots. A simulator generally does none of these, so every path in the device under test that handles them stays unexecuted.
Restart is the clearest example. The SOME/IP-SD Reboot Flag is set to one for all messages after a reboot until the Session ID wraps around and starts at one again, with that information kept separately per sender and receiver relationship. It is how a receiver detects a peer restart, and if your model never restarts, that logic has never run. The same holds for shutdown, where a Stop Offer Service entry is required when a server service instance in the Repetition or Main Phase is stopped, and the Down Phase is required when the link goes down. Write these as explicit test cases.
Host operating system effects when the simulator is a plain PC
A general purpose operating system gives no bounded time between your model deciding to send and the frame leaving the interface. For state and sequence testing that does not matter. For a pass criterion in milliseconds it does, and it varies with load, so a suite that passes on a quiet machine fails on a busy one for reasons unconnected to the product. Separate stimulus from measurement: let the PC generate, take timing from hardware timestamped capture, and keep asking which clock stamped it.
Choosing a rest bus toolchain, vendor-neutral criteria
Tool selection is where the fidelity decision usually gets made by accident. These are properties to test in an evaluation, not features to read off a datasheet.
| Criterion | Why it matters | How to test it during evaluation |
|---|---|---|
| Import path from your network description | Hand-built models drift from the deployment silently | Import your real ARXML, not the sample, and check what was dropped |
| Fidelity ceiling | A level 2 tool may not be scriptable into level 4 later | Script a peer that stops offering without a Stop Offer, during the trial |
| Scriptability and headless operation | A test that needs a person cannot run nightly | Run one test from a command line, no GUI, and read the result from a file |
| Mixed CAN and Ethernet on one timeline | Wake, release and mode decisions cross buses | Import both descriptions and correlate one event across both |
| Determinism and timestamp quality | Timing criteria are meaningless without a stated clock | Ask what stamps the timestamp, and compare against hardware timestamped capture |
The mixed-bus criterion matters more than it looks, because the interesting events are usually cross-bus, and our multi-bus correlation article covers putting them on one timeline honestly.
Rest bus simulation in the wider test chain
A rest bus is not a deliverable on its own. It is what makes other suites possible.
The lifecycle cases are the immediate consumer: startup ordering, shutdown, sleep and wake all need peers you can start, hold, delay and stop, and the physical layer half is in our TC10 sleep and wake article. For the architecture around the bench, our vehicle communication architecture article is the wider view.
Downstream, the same simulator feeds fault campaigns, which need level 4 present from the start rather than retrofitted, and automated regression, which needs configuration and tests in version control and running without a person. Both fail if the rest bus was specified at level 2.
Keep the conformance boundary clear too. A rest bus tells you how your ECU behaves against a network you built, not that the implementation conforms to a published test suite, which is a different activity with different evidence, covered in our conformance testing article.
Where GSAS fits
The expensive mistakes on rest bus simulation are usually made at the specification stage, before anything is bought. A programme that needs level 2 buys level 4 and never scripts a fault; one that needs level 4 buys level 2 and finds out during the safety campaign. The first useful conversation is not about tools: it is about which pass criteria in your test plan require a stateful peer, which require a misbehaving one, and which are satisfied by a service model that answers correctly.
The second is the bench around the simulator: where the capture is armed relative to power, which clock stamps it, whether the lab switch forwards multicast the way the vehicle switch does, whether the port space is planned or accumulated, and whether the simulator’s time domain role is stated or accidental. On conformance we are direct about the boundary. We support pre-conformance bench preparation so teams arrive at a test house with fewer surprises; certification is carried out by accredited conformance houses, not by us.
GSAS Micro Systems is an engineering partner to automotive teams in India, and our applications engineers work alongside teams in Bengaluru, Pune, Chennai and Hyderabad rather than reviewing a bench from a distance. Our automotive Ethernet capability page sets out how we work, and you can request a consultation describing your architecture, the peers you need to stand in for and the fidelity level your test plan implies.
References
- AUTOSAR R24-11 Foundation, SOME/IP Service Discovery Protocol Specification, document 802 (entry fields and TTL rules PRS_SOMEIPSD_00356, endpoint options 00357 to 00359, FindService ignored in the Initial Wait Phase 00839, REQUEST_RESPONSE_DELAY 00417 and 00419 to 00421, TCP before subscribe 00486, multicast option 00488 to 00490, nack 00810, Stop Offer 00427, Down Phase 00751, Reboot Flag): https://www.autosar.org/fileadmin/standards/R24-11/FO/AUTOSAR_FO_PRS_SOMEIPServiceDiscoveryProtocol.pdf
- AUTOSAR R24-11 Foundation, SOME/IP Protocol Specification, document 696 (maybe reliability on the UDP binding, response timeout and E_TIMEOUT): https://www.autosar.org/fileadmin/standards/R24-11/FO/AUTOSAR_FO_PRS_SOMEIPProtocol.pdf
- AUTOSAR R24-11 Classic Platform, System Template, document 63 (System Description, System Extract, ECU Extract): https://www.autosar.org/fileadmin/standards/R24-11/CP/AUTOSAR_CP_TPS_SystemTemplate.pdf
- COVESA vsomeip, open source SOME/IP implementation, Mozilla Public License 2.0: https://github.com/COVESA/vsomeip
- COVESA vsomeip configuration reference (service discovery defaults, eventgroup multicast, client port behaviour): https://github.com/COVESA/vsomeip/blob/master/documentation/vsomeipConfiguration.md
- FibexConverter, FIBEX 4 to Wireshark configuration generator, GPL-2.0: https://github.com/LarsVoelker/FibexConverter
Also appears in:
Building for Automotive & Mobility?
Talk to our application engineers for personalized tool recommendations.
