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..f79c98133 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,11 @@ 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:: + 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 8cb056c11..8e9f5183f 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,56 @@ 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. -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. +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 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 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. + 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 :ref:`sec:api-services` section describes how to configure and use the vehicle network services (valid for both modes). + +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. + +.. 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. + - Required for schedule timing, bus delay modeling, and payload constraints. Simulation Basics -----------------