From 66e79ed5ba3503624d5163cbbab8b7b0b1b664ff Mon Sep 17 00:00:00 2001 From: Konrad Breitsprecher Date: Thu, 25 Jun 2026 14:03:53 +0200 Subject: [PATCH 1/4] Delinieation fast / accurate simulation Signed-off-by: Konrad Breitsprecher --- docs/api/netsim.rst | 2 + docs/api/services/lin.rst | 8 ++++ docs/overview/overview.rst | 76 +++++++++++++++++++++++++++++++------- 3 files changed, 73 insertions(+), 13 deletions(-) diff --git a/docs/api/netsim.rst b/docs/api/netsim.rst index c4c0b6545..988a84c97 100644 --- a/docs/api/netsim.rst +++ b/docs/api/netsim.rst @@ -1,5 +1,7 @@ .. include:: /substitutions.rst +.. _chap:custom-netsim: + ======================================== Custom Network Simulator ======================================== diff --git a/docs/api/services/lin.rst b/docs/api/services/lin.rst index 9349151d6..ffe842160 100644 --- a/docs/api/services/lin.rst +++ b/docs/api/services/lin.rst @@ -15,6 +15,7 @@ LIN Service API .. |InitDynamic| replace:: :cpp:func:`InitDynamic()` .. |SendFrame| replace:: :cpp:func:`SendFrame()` .. |SendFrameHeader| replace:: :cpp:func:`SendFrameHeader()` +.. |SendDynamicResponse| replace:: :cpp:func:`SendDynamicResponse()` .. |UpdateTxBuffer| replace:: :cpp:func:`UpdateTxBuffer()` .. |SetFrameResponse| replace:: :cpp:func:`SetFrameResponse()` @@ -433,3 +434,10 @@ The experimental API is defined as follows: .. doxygenfunction:: SilKit::Experimental::Services::Lin::AddFrameHeaderHandler(SilKit::Services::Lin::ILinController* linController, SilKit::Experimental::Services::Lin::LinFrameHeaderHandler handler) .. doxygenfunction:: SilKit::Experimental::Services::Lin::RemoveFrameHeaderHandler .. doxygenfunction:: SilKit::Experimental::Services::Lin::SendDynamicResponse + +.. note:: + An dynamic response to a LIN header can only be delivered with certain timing restrictions: + When a LIN master initiates a frame transmission with |SendFrameHeader| at time T. + The LIN Slave that wants to send the response receives the LIN Header at T+dt and calls |SendDynamicResponse|. + The LIN Master will receive the response at T+2dt, which may be out of the timing window for the LIN frame. + \ No newline at end of file diff --git a/docs/overview/overview.rst b/docs/overview/overview.rst index 8cb056c11..186e82753 100644 --- a/docs/overview/overview.rst +++ b/docs/overview/overview.rst @@ -15,6 +15,13 @@ SIL Kit Overview .. |Timesync-API| replace:: :ref:`time synchronization` .. |Logging-API| replace:: :ref:`logging` +.. |fastBus| replace:: fast bus +.. |FastBus| replace:: Fast bus +.. |BoldFastBus| replace:: **Fast bus** +.. |accurateBus| replace:: accurate bus +.. |AccurateBus| replace:: Accurate bus +.. |BoldAccurateBus| replace:: **Accurate bus** + The |ProductName| is an open source library for connecting Software-in-the-Loop Environments. It provides: @@ -48,22 +55,65 @@ Vehicle Networks ---------------- The |ProductName| provides means to simulate |CANBuses|, 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 |ProductName| |NetSim|, which considers these aspects as well. -The |NetSim| is not part of |ProductName| 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 |NetSim|. - -In general, |ProductName| deliberately avoids imposing restrictions on bus protocols. +Vehicle networks are accessed through their corresponding services (for example, a CAN controller). + +Fast vs. Accurate Bus Simulation +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For all supported bus systems, |ProductName| distinguishes between two simulation styles: + +* |BoldFastBus| - Lightweight communication with idealized behavior. + Communication is functional and timing effects are simplified (e.g., no modeled delay or bandwidth limits). + This is the default simulation style. +* |BoldAccurateBus| - A more detailed bus behavior is modeled by integrating a Network Simulator. + A Network Simulator can apply realistic timing and protocol effects, e.g. sending delays, bandwidth limits and frame validation. + The |NetSim| is not part of |ProductName| itself. + The chapter :ref:`chap:custom-netsim` describes how to implement a custom Network Simulator and integrate it with |ProductName|. + +.. important:: + Because of its sensitivity regarding time, **FlexRay** is only available with the |BoldAccurateBus| and thus requires a Network Simulator. + +The service interfaces are the same for |fastBus| and |accurateBus| simulation. +As a result, an application that works in the |fastBus| use case also works when switching to |accurateBus| simulation. +The section :ref:`sec:api-services` describes how to configure and use the vehicle network services (valid for both modes). + +Choosing the Right Mode +~~~~~~~~~~~~~~~~~~~~~~~ + +As a practical default, start with |fastBus| unless the need for detailed network simulation is clear. +Switch to |accurateBus| when timing fidelity or protocol-level effects are required. + +.. + vECU level guidance (rule of thumb): + + * **vECU levels 1-2:** prefer |fastBus| for early functional development and rapid iteration. + * **vECU level 3:** start with |fastBus|; use |AccurateBus| selectively for timing-critical paths. + * **vECU levels 4-5:** prefer |accurateBus| when network timing, delays, bandwidth, timestamps, or payload validation influence behavior. + +.. list-table:: Vehicle network overview + :header-rows: 1 + :widths: 20 40 40 + + * - Bus system + - |FastBus| + - |AccurateBus| + * - CAN + - High execution speed and functional tests. + - Required for arbitration effects, delay behavior and payload validation. + * - Ethernet + - Service-oriented and high-throughput functional traffic patterns. + - Required for switching behavior, buffering effects, and bandwidth contention. + * - FlexRay + - Not available. FlexRay requires |accurateBus| simulation. + - Strict requirement. + * - LIN + - Simple and fast functional integration for body/control style scenarios. + - Better for schedule timing, bus delay modeling, and payload constraints. + +In general, |ProductName| deliberately avoids imposing restrictions on bus protocols with the |fastBus|. This enables user applications to freely determine the desired level of detail for vehicle network simulations. For example, a test participant can inject faulty frames without being blocked by |ProductName|. -The section :ref:`sec:api-services` describes how to configure and use the vehicle network services in detail. Simulation Basics ----------------- From a6708687543df10557a96bf7c40d471192405f5d Mon Sep 17 00:00:00 2001 From: KonradBreitsprecherBkd <117755498+KonradBreitsprecherBkd@users.noreply.github.com> Date: Tue, 18 Aug 2026 09:18:23 +0200 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Alex Signed-off-by: KonradBreitsprecherBkd <117755498+KonradBreitsprecherBkd@users.noreply.github.com> --- docs/api/services/lin.rst | 9 +++++---- docs/overview/overview.rst | 18 +++++++++--------- 2 files changed, 14 insertions(+), 13 deletions(-) diff --git a/docs/api/services/lin.rst b/docs/api/services/lin.rst index ffe842160..f79c98133 100644 --- a/docs/api/services/lin.rst +++ b/docs/api/services/lin.rst @@ -436,8 +436,9 @@ The experimental API is defined as follows: .. doxygenfunction:: SilKit::Experimental::Services::Lin::SendDynamicResponse .. note:: - An dynamic response to a LIN header can only be delivered with certain timing restrictions: - When a LIN master initiates a frame transmission with |SendFrameHeader| at time T. - The LIN Slave that wants to send the response receives the LIN Header at T+dt and calls |SendDynamicResponse|. - The LIN Master will receive the response at T+2dt, which may be out of the timing window for the LIN frame. + A dynamic response to a LIN header can only be delivered with certain timing restrictions: + + - At time **T**, the LIN coordinator initiates a frame transmission by calling |SendFrameHeader|. + - At time **T + dt**, the LIN responder receives the LIN Header and calls |SendDynamicResponse|. + - The LIN coordinator will receive the response at **T + 2dt**, which may exceed the allowed timing window for the LIN frame. \ No newline at end of file diff --git a/docs/overview/overview.rst b/docs/overview/overview.rst index 186e82753..da0f6c8ad 100644 --- a/docs/overview/overview.rst +++ b/docs/overview/overview.rst @@ -60,24 +60,24 @@ Vehicle networks are accessed through their corresponding services (for example, Fast vs. Accurate Bus Simulation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For all supported bus systems, |ProductName| distinguishes between two simulation styles: +For all supported bus systems, |ProductName| distinguishes between two simulation modes: * |BoldFastBus| - Lightweight communication with idealized behavior. Communication is functional and timing effects are simplified (e.g., no modeled delay or bandwidth limits). - This is the default simulation style. -* |BoldAccurateBus| - A more detailed bus behavior is modeled by integrating a Network Simulator. - A Network Simulator can apply realistic timing and protocol effects, e.g. sending delays, bandwidth limits and frame validation. + This is the default simulation mode. +* |BoldAccurateBus| - a more detailed bus behavior. It is modeled by integrating a Network Simulator, which + can apply realistic timing and protocol effects, e.g., sending delays, bandwidth limits, and frame validation. The |NetSim| is not part of |ProductName| itself. - The chapter :ref:`chap:custom-netsim` describes how to implement a custom Network Simulator and integrate it with |ProductName|. + The :ref:`chap:custom-netsim` chapter describes how to implement a custom Network Simulator and integrate it with |ProductName|. .. important:: Because of its sensitivity regarding time, **FlexRay** is only available with the |BoldAccurateBus| and thus requires a Network Simulator. The service interfaces are the same for |fastBus| and |accurateBus| simulation. As a result, an application that works in the |fastBus| use case also works when switching to |accurateBus| simulation. -The section :ref:`sec:api-services` describes how to configure and use the vehicle network services (valid for both modes). +The :ref:`sec:api-services` section describes how to configure and use the vehicle network services (valid for both modes). -Choosing the Right Mode +Choosing the Right Simulation Mode ~~~~~~~~~~~~~~~~~~~~~~~ As a practical default, start with |fastBus| unless the need for detailed network simulation is clear. @@ -99,7 +99,7 @@ Switch to |accurateBus| when timing fidelity or protocol-level effects are requi - |AccurateBus| * - CAN - High execution speed and functional tests. - - Required for arbitration effects, delay behavior and payload validation. + - Required for arbitration effects, delay behavior, and payload validation. * - Ethernet - Service-oriented and high-throughput functional traffic patterns. - Required for switching behavior, buffering effects, and bandwidth contention. @@ -108,7 +108,7 @@ Switch to |accurateBus| when timing fidelity or protocol-level effects are requi - Strict requirement. * - LIN - Simple and fast functional integration for body/control style scenarios. - - Better for schedule timing, bus delay modeling, and payload constraints. + - Required for schedule timing, bus delay modeling, and payload constraints. In general, |ProductName| deliberately avoids imposing restrictions on bus protocols with the |fastBus|. This enables user applications to freely determine the desired level of detail for vehicle network simulations. From c250498b3494e4977f6683c675bdfe29ea3f78e7 Mon Sep 17 00:00:00 2001 From: KonradBreitsprecherBkd <117755498+KonradBreitsprecherBkd@users.noreply.github.com> Date: Tue, 18 Aug 2026 09:20:30 +0200 Subject: [PATCH 3/4] Remove commented ecu level list in overview.rst Signed-off-by: KonradBreitsprecherBkd <117755498+KonradBreitsprecherBkd@users.noreply.github.com> --- docs/overview/overview.rst | 7 ------- 1 file changed, 7 deletions(-) diff --git a/docs/overview/overview.rst b/docs/overview/overview.rst index da0f6c8ad..9a8a9b141 100644 --- a/docs/overview/overview.rst +++ b/docs/overview/overview.rst @@ -83,13 +83,6 @@ Choosing the Right Simulation Mode As a practical default, start with |fastBus| unless the need for detailed network simulation is clear. Switch to |accurateBus| when timing fidelity or protocol-level effects are required. -.. - vECU level guidance (rule of thumb): - - * **vECU levels 1-2:** prefer |fastBus| for early functional development and rapid iteration. - * **vECU level 3:** start with |fastBus|; use |AccurateBus| selectively for timing-critical paths. - * **vECU levels 4-5:** prefer |accurateBus| when network timing, delays, bandwidth, timestamps, or payload validation influence behavior. - .. list-table:: Vehicle network overview :header-rows: 1 :widths: 20 40 40 From 48c121cd34f1866b75cbb07fb7f995dd3650b7bb Mon Sep 17 00:00:00 2001 From: KonradBreitsprecherBkd <117755498+KonradBreitsprecherBkd@users.noreply.github.com> Date: Thu, 20 Aug 2026 12:10:16 +0200 Subject: [PATCH 4/4] Update overview.rst Signed-off-by: KonradBreitsprecherBkd <117755498+KonradBreitsprecherBkd@users.noreply.github.com> --- docs/overview/overview.rst | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/docs/overview/overview.rst b/docs/overview/overview.rst index 9a8a9b141..8e9f5183f 100644 --- a/docs/overview/overview.rst +++ b/docs/overview/overview.rst @@ -64,7 +64,10 @@ For all supported bus systems, |ProductName| distinguishes between two simulatio * |BoldFastBus| - Lightweight communication with idealized behavior. Communication is functional and timing effects are simplified (e.g., no modeled delay or bandwidth limits). - This is the default simulation mode. + This is the default simulation mode. + Here, |ProductName| deliberately avoids imposing restrictions on bus protocols. + This enables user applications to freely determine the desired level of detail for vehicle network simulations. + For example, |ProductName| will not prevent the injection of faulty frames. * |BoldAccurateBus| - a more detailed bus behavior. It is modeled by integrating a Network Simulator, which can apply realistic timing and protocol effects, e.g., sending delays, bandwidth limits, and frame validation. The |NetSim| is not part of |ProductName| itself. @@ -103,11 +106,6 @@ Switch to |accurateBus| when timing fidelity or protocol-level effects are requi - Simple and fast functional integration for body/control style scenarios. - Required for schedule timing, bus delay modeling, and payload constraints. -In general, |ProductName| deliberately avoids imposing restrictions on bus protocols with the |fastBus|. -This enables user applications to freely determine the desired level of detail for vehicle network simulations. -For example, a test participant can inject faulty frames without being blocked by |ProductName|. - - Simulation Basics -----------------