Use Cases for Lifecycle and Virtual Time Synchronization Services

[VladislavNeufeld]

Hello,

I'm not sure for what use cases I can use the lifecycle and virtual time synchronization service and would be happy if you could tell me some use cases where it makes sense to use it.

We are planning to use the Silkit as a virtual bus for co-simulation of virtual ECU type 3 networks. The virtual ECUs are integrated as FMUs with Silkit DLLs into the simulator (Silver, VEOS, Matlab/Simulink) and are using silkit services to exchange messages via automotive protocols.

I am wondering whether I can use the Virtual Time Synchronization service in the described use case in order to achieve determinism in my simulation? In our current solution the sender does not now whether the receiver received his message before the next simulation step starts. It might happen that frame event callbacks are processed downstream. This makes it sometimes tough to reproduce error cases.

I'm currently having difficulty imagining how I could integrate the time synchronization service into our current setup. Do I need a SiL tool/simulator which already supports Silkit in order to benefit from time synchronization service? Or could I incorporate another component into my SiL simulation setup which initializes the lifecycle service?

It would be nice if you could provide one real world example of a SiL simulation setup (tools, components) where this service is used and what is the benefit of using it (why not simple communication without lifecycle service). So that I have a better understanding of the capabilities of the Silkit.

Best regards

Vladislav

[JoakimRobakowski]

@VladislavNeufeld Given that you will be working with virtual ECU 'type 3' (which I assume refers to 'level 3'), it opens up a few specific use cases worth mentioning:

• Bus Communication (e.g., CAN): In protocols like CAN, many messages are transmitted with a known cycle time. This predictable timing can be crucial in the communication between distributed systems.

• Higher-Level Communication (e.g., Diagnostics): In diagnostic communication, certain parameters dictate how long a diagnostic client, such as a Diagnostic Tester, should wait for incoming responses from the ECU. Timing is critical here to avoid misinterpretation of response delays.

• ECU Response Timing (Set-Wait-Check Tests): There are scenarios where the ECU must respond to stimuli within a certain timeframe. This is commonly tested using a "Set-Wait-Check" approach, where the "Wait" step involves considering the longest allowed reaction time.

Virtual Time Synchronization Consideration: When using SIL Kit to connect different simulation environments, each with varying complexity, the simulation speed can differ significantly. For instance, a complex virtual ECU might run much slower than a restbus simulation in CANoe.

• If the test execution engine within CANoe is used to run tests against the virtual ECU, these timing discrepancies could lead to issues. Without proper time synchronization, you might encounter false-positive test results, where the tests incorrectly flag failures due to these virtual time deviations.

[VladislavNeufeld]

Hello @JoakimRobakowski, thank you for clarification.

And what do I need to do in order to synchronize a complex virtual ECU with the restbus simulation in CANoe using the Silkit? Do I need to implement one additional Silkit component (participant) which has the synchronization code and add it into the simulation in CANoe? So that this component can synchronize the virtual ECU component and the restbus simulation component/test execution engine?

[JoakimRobakowski]

@VladislavNeufeld You are correct; there must be a participant that controls the simulation progress. You can use the sil-kit-system-controller, a utility that is also included in this repository.

There are a couple of SIL Kit Demos that you could use to try out running with and without time synchronization (e.g., CAN Demo), and have a look at the source code of the demo applications how SIL Kit Virtual Time Synchronization can be implemented on the participant side.

If you are using simulation tools where SIL Kit is integrated, like Vector CANoe and Synopsys Silver, the configuration of the SIL Kit participants can often be done directly in the tools, or by a configuration file.

Going back to the CAN Demo: if you would like to set up a CANoe configuration to exchange data with the CAN Demo participants with time synchronization, you could prepare the following things in your CANoe configuration:

• Enable SIL Kit (CANoe Options | Extensions | SIL Kit)
  • You also need to specify the: a. URI to the SIL Kit Registry b. The participant name that you want your CANoe simulation instance to have
• Map simulated networks to SIL Kit (Hardware | Channel Mapping)
  • Instead of mapping a network to a channel of a real interface (e.g., VN5620), you can make the mapping to SIL Kit.
  • Important: The name of the CAN network in CANoe must match with the name of the virtual CAN network that the other SIL Kit participants want to communicate over.
• Enable virtual time synchronization (CANoe Options | Measurement | General)
  • Change "Simulation | Working mode" to "Simulated bus (slave mode)"

[PRAVEENFrmBOSCH]

Hello @JoakimRobakowski, Please share how to achieve below use case, MyConfig :

• 1 FMU connected to silKit

• Canoe as a retBus configued with silKit (slave), configured generator for frames periodically.

• As mentioned above i have configured Canoe in slave mode and acting as a restBus, and controlling the simulation time from FMU using virtual time synchronization service.

• Tx flow is as expected, SendFrames is called under SetSimulationStepHandler()

• Rx flow is not as expected since AddFrameHandler is receiving the frames in async mode, where determinism is missing, also how long i need to wait for the reception for a particular step, whether all frames has been received from restBus. canController->AddFrameHandler( [](Can::ICanController* /*ctrl*/, const Can::CanFrameEvent& frameEvent) { // **Asynchroneously handle message reception** });

I am expecting determinism in my simulation as like below in each doStep,

1. Tick (DoStep)
2. sendFrames (send frames to Canoe)
3. Receive Frames (all the periodic frames sent by Canoe should be received) for the same i need help.

[JoakimRobakowski]

Hello @PRAVEENFrmBOSCH, I am not sure what is not working for you, especially when you say that you are receiving the frames in async mode or that determinism is missing. Could you please elaborate more?

[JoakimRobakowski]

Hello @PRAVEENFrmBOSCH, You can also reach me at joakim.robakowski@vector.com :slightly_smiling_face: