Vector SIL Kit Overview

The Vector SIL Kit is an open source library for connecting Software-in-the-Loop Environments. It provides:

Communication infrastructure for automotive and non-automotive applications
Interoperability between any SIL Kit enabled applications
Cross platform communication
Implemented in C++ w/o platform dependencies
Interoperability between Windows, Linux, and other UNIX derivates
Stable API and ABI as well as long-term network layer compatibility

Supported Services

The SIL Kit supports the following services:

Vehicle Network Controllers: CAN / CAN FD, Ethernet, FlexRay, and LIN
Data Publish/Subscribe: topic-based publish/subscribe mechanism to exchange arbitrary data
RPC Servers/Clients: for dynamic remote procedure execution
Orchestration: for lifecycle and time synchronization control
Logging: for logging messages into a file, standard output, or to other participants
Custom Network Simulator: takes control over the message flow to simulate network details

Vehicle Networks

The SIL Kit provides means to simulate CAN / CAN FD, Ethernet, FlexRay, and LIN networks. All networks except for FlexRay can be simulated with two different levels of detail: a simple, functional simulation or a detailed simulation. The simple simulation assumes no delay and unlimited bandwidth. The detailed simulation is enabled by using an additional SIL Kit Network Simulator, which considers these aspects as well. The Network Simulator is not part of SIL Kit itself. Because of its sensitivity regarding time, FlexRay is only supported in a detailed simulation.

Vehicle networks are accessed through their corresponding services (e.g., a CAN controller). The service interfaces are the same for simple and detailed simulation. As a result, an application that works in the simple use case also works when switching to a detailed simulation using the Network Simulator. The section Services describes how to configure and use vehicle network services in detail.

Simulation Basics

Every simulation setup comprises several components. The SIL Kit Registry establishes connections between participants in a simulation. The SIL Kit Registry process is required and must be started as a first step. It acts as a connection broker between the actual simulation participants.

One or more participants take care of the actual simulation logic and communicate via built-in services. SIL Kit supports common vehicle networks (CAN / CAN FD, Ethernet, FlexRay, LIN), data messages for application specific communication in a publish / subscribe pattern, and Remote Procedure Calls (RPC). The participant and its services are created by the client application using the SIL Kit API.

To manage a group of participants in a simulation, SIL Kit participants can coordinate their startup behavior. For example, participants may wait before starting until a given set of required participants have joined the simulation. Furthermore, SIL Kit participants can use a virtual simulation time that is synchronized with other participants.

While participants are first configured in the SIL Kit API by the developer, they can be reconfigured by the user by providing a YAML-based participant configuration file when starting the participant. A similar configuration file is available for the SIL Kit Registry as well.

For getting started operating/orchestrating a SIL Kit simulation, see the User Guide.
For getting started developing with the SIL Kit, see the Developer Guide.

The SIL Kit Ecosystem

Guiding Principles

SIL Kit follows a few fundamental principles:

Local view: Participants do not require knowledge about the overall system setup or other participants. Communication between participants is made possible by using a common bus network or topic name.
Distributed simulation: Communication between participants is based on a peer-to-peer connections. There is no central simulation participant that handles the distribution of messages or controls the virtual time.
Stability: SIL Kit has a stable network layer and provides API and ABI guarantees. This means that participants of different versions can partake in the same simulation. Further, the SIL Kit library can be updated to newer versions without having to adapt or recompile already existing SIL Kit applications.
Reconfigurability: Users should be able to provide a configuration file to the SIL Kit application to change the its behavior (e.g., configure logging or change the network a bus controller connects to).

Terminology

(Distributed) Simulation Setup	A simulation setup consists of interconnected participants and a SIL Kit registry instance. The participants and the registry can be distributed in a network or running on the same host.
(Simulation) Participant	A participant is a communication node in the distributed simulation that provides access to the SIL Kit services.
Services	Participants interact with each other through the means of services. These can be communication services, e.g., a CAN Controller and orchestration services, such as the the Lifecycle Service, Time Synchronization Service, and the Logging Service.
Configuration	The optional participant configuration file allows easy configuration of a participant and its interconnection within the simulation. It can be used to change a participant’s behavior without recompiling its sources.
Registry	The registry is a central process that enables participant discovery in a distributed simulation. An instance of the registry is required for coordination, either as a standalone process (see sil-kit-registry) or created programmatically.
Registry URI	The registry’s URI specifies where the registry can be reached. It defaults to `silkit://localhost:8500`, that is, the registry is reachable via TCP/IP on the ‘localhost’ on port 8500.
Middleware	The concrete distributed communication implementation. That is, the software layer implementing the distributed message passing mechanism.
Network Connection	All participants in a SIL Kit simulation communicate through peer-to-peer connections. By default, participants try to establish a connection via Unix Domain Sockets or TCP/IP. If none of these work, they try to communicate by using the SIL Kit Registry as a proxy.
(Virtual) Simulation Time	Participants can opt to use a virtual simulation time that is synchronized with other participants.
Required participant	A participant that is required for a successful simulation. All required participants impact the system state (see Lifecycle Coordination Between Participants). Required participants are defined by the System Controller Utility.
Coordinated participant	Participants can opt to synchronize their lifecycle state with other participants. Coordinated participants are subject to the state of all required participants.
Autonomous participant	Participants can opt to make their participant state known to others but to ignore the system state. Autonomous participants are not stopped by the system state and therefore must be stopped manually.