ECUs

The last object in the network simulation to consider is the ECU. ECUs have Controllers just like Sources, and connect to the Channels in the same way through Connectors. Rather than the Controllers being backed by Drivers as they are in Sources, they are backed by an ECU simulation environment.

ECUs may be created by importing database files into the application. They can also be created by the user from within a Python script.

The concept of the ECU is designed to mirror a real-life microcontroller box you might find in a vehicle. In the same way that a physical ECU which connects to three CAN channels will necessarily have three CAN controllers, an ECU within the simulation with support for three CAN channels will have three vspyx.Communication.CANController s, and this is the only way it affects other parts of the network simulation. On one side of the controller, we have the network simulation. On the other, we have the ECU simulation.

The ECU simulation is comprised of the Stack, which decodes traffic for the ECU to feed the Environment, and the Environment, which manages the ECU’s viewpoint of the Traceables.

Observer

One particularly notable ECU is the vspyx.VehicleSpy.Observer. It is an ECU we create within the simulation when the simulation starts. It’s purpose is to provide the decoding necessary for our network analysis use case. If you connect to every bus on a vehicle, you want the Monitor to show you the decodings for every PDU, every Signal, etc. In a complex network archicture, it is unlikely that any existing ECU’s viewpoint would provide such a complete picture of all of the traffic occuring in the vehicle. So, we connect the Observer to every Channel in the topology, and configure it to be a passive receiver of all signals, PDUs, etc in the topology.