Skip to content

Commit 3a676c1

Browse files
bmenne-dspaceBenedikt Menne
bmenne-dspace
and
Benedikt Menne
authored
Created initial content for fmi-ls-bus guide (#80)
* Created initial content for fmi-ls-bus guide * Removed index.html * Update and add new content * Remove index.html --------- Co-authored-by: Benedikt Menne <[email protected]>
1 parent 7699f42 commit 3a676c1

21 files changed

+1173
-1
lines changed

‎ls-bus-guide/1___introduction.adoc

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,9 @@
11
== Introduction
2+
This document provides best practice recommendations to implementers of https://modelica.github.io/fmi-ls-bus/main/[FMI Layered Standard for Network Communication].
3+
The overarching goal of the recommendations is to aid interoperability of implementations and ensure good ease-of-use for the user in employing FMI.
24

3-
TODO
5+
This document is intended for simulation tool vendors planning to support FMI Layered Standard for Network Communication in their products, either for creating or simulating such FMUs, or both.
6+
It assumes a technical audience familiar with the specification documents and tries to give further information and hints in areas where either the relevant specification documents have been found sometimes to be less clear than expected or where user expectations are relevant to implementation choices.
7+
It also considers errors and bugs encountered in the practical use of existing FMI implementations and guides to avoid common pitfalls.
8+
9+
This document will be maintained and expanded over time as new issues or needs for clarification appear.

‎ls-bus-guide/2___common.adoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
== Common
2+
#TODO#

‎ls-bus-guide/3____physical_signal_abstraction.adoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
== Physical Signal Abstraction ("high cut")
2+
This chapter contains details on common topics of the physical signal abstraction layer.

‎ls-bus-guide/4____network_abstraction.adoc

Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
== Network Abstraction ("low cut")
2+
This chapter contains details on common topics of the network abstraction layer.
3+
4+
=== Differences between System Compositions
5+
The principles of communication is closely linked with the introduced System Compositions.
6+
Within the `Direct Communication` use case in combination with network abstraction, exactly two FMUs communicate with each other.
7+
No Bus Simulation is required.
8+
<<#figure-example-network-simulation-direct>> illustrates this communication, whereby FMU 1 transmits network data to FMU 2.After that, the transmission is directly confirmed by FMU 1 itself, whereby FMU 1 handles that self confirmation internally.
9+
10+
.Direct communication between two FMUs.
11+
[#figure-example-network-simulation-direct]
12+
image::principles_of_communication_direct.svg[width=40%, align="center"]
13+
14+
Within `Composition with dedicated Bus Simulation FMU` and `Importer with Integrated Bus Simulation` communication case there exists always a Bus Simulation and two or more FMUs can be connected for communication.
15+
Bus connections between FMUs are then redirected via the Bus Simulation (FMU).
16+
This means that the bus simulation model sets the level of accuracy and feature support for the respective bus type.
17+
18+
<<#figure-example-network-simulation-complex>> shows the communication of two FMUs which are connected via a Bus Simulation.
19+
All in all FMU 1 transmits network data to FMU 2.
20+
First FMU 1 commits the baud rate to the Bus Simulation.
21+
This information can be used for timing calculations during the transmission of a message.
22+
In a second operation FMU 1 transmits network data to the Bus Simulation.
23+
Inside the Bus Simulation a calculation of the transmission time for the specified network data is done.
24+
After this the Bus Simulation transmits the network data to FMU 2 and confirms the successful transmission to FMU 1.
25+
26+
.Communication between two FMUs by using a Bus Simulation FMU.
27+
[#figure-example-network-simulation-complex]
28+
image::principles_of_communication_complex.svg[width=70%, align="center"]
29+
30+
=== Creating Bus Operations ahead of the next Simulation Step
31+
#TODO dSPACE#
32+
33+
=== Data and Time Synchronization
34+
#TODO dSPACE#
35+
36+
=== Decoupling of Fixed and Variable Step Size FMUs [[low-cut-decoupling-of-fixed-and-variable-step-size-fmus]]
37+
#TODO dSPACE#
38+
39+
=== CAN, CAN FD, CAN XL
40+
This chapter contains details on CAN, CAN FD, CAN XL specific topics.
41+
42+
==== Sequence Diagrams [[low-cut-can-sequence-diagrams]]
43+
This section contains sample sequences to clarify the facts in the CAN, CAN FD, CAN XL part.
44+
45+
===== Transmission [[low-cut-can-example-transmission]]
46+
<<#figure-can-transmission-acknowledge>> illustrates the two possible results of a `Transmit` operation, whereby the transition from FMU 1 -> FMU 2 represents the successful case and FMU 2 -> FMU 1 represents the unsuccessful case.
47+
For the second transmission, the Bus Simulation injects a failure of transmission.
48+
In step (1), a `Transmit` operation will be delivered to the Bus Simulation.
49+
Within step (2), the `Transmit` operation will transferred to FMU 2, so the transmission was successful.
50+
Also in step (2), FMU 1 receives a `Confirm` operation, which means the transmission was successful.
51+
In step (3), FMU 2 wants to transmit network data to FMU 1:
52+
A `Transmit` operation will be delivered from FMU 2 to the Bus Simulation.
53+
In step (4), we see that the transmission results in an `Bus Error` operation, because the Bus Simulation injects a failure of transmission.
54+
Based on the `Bus Error` operation FMU 2 knows that the transmission was not successful.
55+
Within this `Bus Error` operation, the `Is Sender` argument is set to `TRUE` for FMU 2, because it provides the failing `Transmit` operation.
56+
Another `Bus Error` operation instance is provided by the Bus Simulation to FMU 1.
57+
For FMU 1, the `Error Flag` argument is set to `PRIMARY_ERROR_FLAG`, which means that FMU detects the specified transmission error.
58+
59+
.Successful and unsuccessful cases of a CAN transmission.
60+
[#figure-can-transmission-acknowledge]
61+
image::can_transmission_acknowledge.svg[width=60%, align="center"]
62+
63+
Normally, transmission failure cannot occur during a simulated bus transmission.
64+
Most common kinds of errors are used to inject transmission errors, for example using the Bus Simulation FMU, for advanced test scenarios.
65+
66+
===== CAN Arbitration without Buffering [[low-cut-can-example-can-arbitration-without-buffering]]
67+
<<#figure-can-arbitration-overview>> shows the realization of a CAN arbitration by using the `Arbitration Lost Behavior` option `DISCARD_AND_NOTIFY` within the `Configuration` operation.
68+
At the beginning, FMU 1 and FMU 2 each send network data at the same time.
69+
In this situation, an arbitration is necessary to decide which frame should be sent in this case.
70+
Both frames are transferred to the Bus Simulation.
71+
Arbitration takes place within the Bus Simulation.
72+
In the example given, the two frames with CAN ID = 15 and CAN ID = 16 are analyzed and it is decided that CAN ID = 15 wins the arbitration.
73+
The Bus Simulation then calculates the transmission time for the CAN frame with CAN ID = 15.
74+
The next time the FMI `Event Mode` is called up for the Bus Simulation, the corresponding CAN frame is transmitted to FMU 2 and FMU 3.
75+
For CAN ID 16, FMU 2 is informed via an `Arbitration Lost` operation that this frame cannot be sent.
76+
FMU 1 gets a `Confirm` operation, because the specified frame with CAN ID 15 was successfully transmitted.
77+
78+
.Arbitration of CAN frames within Bus Simulation.
79+
[#figure-can-arbitration-overview]
80+
image::can_arbitration_overview.svg[width=80%, align="center"]
81+
82+
===== CAN Arbitration with Buffering [[low-cut-can-example-can-arbitration-with-buffering]]
83+
<<#figure-can-arbitration-overview-with-buffer>> shows the realization of a CAN arbitration by using the `Arbitration Lost Behavior` option `BUFFER_AND_RETRANSMIT` within the `Configuration` operation.
84+
At the beginning, FMU 1 and FMU 2 each send network data at the same time.
85+
In this situation, an arbitration is necessary to decide which frame should be sent in this case.
86+
Both frames are transferred to the Bus Simulation.
87+
Arbitration takes place within the Bus Simulation.
88+
In the example given, the two frames with CAN ID = 15 and CAN ID = 16 are analyzed and it is decided that CAN ID = 15 wins the arbitration.
89+
The Bus Simulation then calculates the transmission time for the CAN frame with CAN ID = 15.
90+
The next time the FMI `Event Mode` is called up for the Bus Simulation, the corresponding CAN frame is transmitted to FMU 2 and FMU 3.
91+
The `Transmit` operation of CAN ID 16 is buffered by the Bus Simulation and will be sent within the next time slot.
92+
The Bus Simulation does not return an `Arbitration Lost` operation to FMU 2.
93+
FMU 1 gets a `Confirm` operation, because the specified frame with CAN ID 15 was successfully transmitted.
94+
95+
.Arbitration of CAN frames with buffering within Bus Simulation.
96+
[#figure-can-arbitration-overview-with-buffer]
97+
image::can_arbitration_overview_with_buffer.svg[width=80%, align="center"]
98+
99+
==== Realization of CAN Error Handling
100+
This chapter describes a possible implementation of the CAN error handling within Network FMUs using a rule set based on `Bus Error` operations.
101+
Each Network FMU will provide its own Transmit Error Counter (TEC), Receive Error Counter (REC) and current CAN node state.
102+
The values for TEC and REC will be increased and decreased with respect to the `Error Code`, `Is Sender` and `Error Flag` arguments of a `Bus Error` operation and are inherited from the original CAN error confinement rules.
103+
Based on the values of TEC and REC, the CAN controller moves in the following state machine:
104+
105+
.CAN node state machine.
106+
[#figure-can-error-state-machine]
107+
image::can_error_state_machine.svg[width=60%, align="center"]
108+
109+
This CAN node state machine and the related TEC and REC values have to be included within the Network FMUs.
110+
`Bus Error` operations shall be directly used to maintain the TEC and REC values.
111+
The Network FMU shall react on the `Bus Error` operations that the Bus Simulation provides, based on the following rule set:
112+
113+
* When an FMU gets a `Bus Error` operation where the arguments `Is Sender = FALSE` and `Error Flag = SECONDARY_ERROR_FLAG` and also `Error Code != BROKEN_ERROR_FRAME`, the REC shall be increased by 1.
114+
* When an FMU gets a `Bus Error` operation where the arguments (`Is Sender = FALSE` and `Error Flag = PRIMARY_ERROR_FLAG`) or `Error Code = BROKEN_ERROR_FRAME`, the REC shall be increased by 8.
115+
* When an FMU gets a `Bus Error` operation where the arguments `Is Sender = TRUE` or `Error Code = BROKEN_ERROR_FRAME`, the TEC shall be increased by 8.
116+
Exception: `Status = ERROR_PASSIVE` and `Error Code = ACK_ERROR`.
117+
* When an FMU provides a `Transmit` operation and receives a `Confirm` operation for it, the TEC shall be decreased by 1 unless it was already 0.
118+
* When an FMU gets a `Transmit` operation, the REC shall be decreased by 1, if it was between 1 and 127.
119+
If the REC was 0, it stays 0, and if it was greater than 127, then it will be set to the value between 119 and 127.
120+
121+
A Network FMU communicates its current CAN node state via the `Status` operation by using the following rule set:
122+
123+
* After the initialization of a Network FMU, the current CAN node state shall be set to `ERROR_ACTIVE` and communicate via `Status` operation to the Bus Simulation.
124+
* The current CAN node state of a Network FMU shall be set to `ERROR_PASSIVE` if the value of REC > 127 or TEC > 127 and communicate via `Status` operation to the Bus Simulation.
125+
* The current CAN node state of a Network FMU shall be set to `ERROR_ACTIVE` if the value of REC < 128 and TEC < 128 and communicate via `Status` operation to the Bus Simulation.
126+
* The current CAN node state of a Network FMU shall be set to `BUS_OFF` if the value of TEC > 255 and communicate via `Status` operation to the Bus Simulation.
127+
* The `BUS_OFF` status shall be set to `ERROR_ACTIVE` again when the Network FMU simulates a controller reset (optional) and has received in total 128 `Transmit` operations or `Bus Error` operations from the network.
128+
129+
If `org.fmi_standard.fmi_ls_bus.WaitForBusNotification` is set to `false`, the `Confirm` operation cannot be directly used as indicator to set the TEC value and will be incorrect under the rules outlined above.
130+
Also `Bus Error` operations are not available in this scenario, so that the values for TEC and REC automatically remain zero in this case.
131+
It is recommended to solve the error handling differently in this case or to disabling it completely within the specified Network FMU.

0 commit comments

Comments
 (0)