fmi-standard
fmi-standard copied to clipboard
modelica
Layered standard for automotive CAN
(I think this was discussed at several design meetings but I found no other ticket for it).
Before the release of FMI 3.0 we shall make sure that future layered standard can build on the terminals an features to define layered standards e.g. for
- standardization of terminals of certain domains
- bus simulation for automotive buses, virtual ECUs
- ...
@pmai : could you please comment on this as you have ideas regarding layered standards
A mental exercise is certainly not going to give us the certainty we would like to have. A better proposal appeared during the ProSTEP discussions w.r.t. vECUs with FMI 3.0: If we can show in a layered standard how to describe a CAN bus interface for a vECU, such a certainty would largely be attained.
(Andreas J, Christian B)
Let's create a first a layered standard for automotive CAN. @andreas-junghanns : I will create a draft and review with @pmai
Here is an initial sketch of what we need to define to get the ball rolling...
Assumptions:
- we define standard/classic CAN (read: not CAN-FD)
- description format is either DBC or ARXML
- timing information comes from the definition files and we do not provide overwrite capabilities
- message structure and scaling the same way
- no definition file composition defined/allowed
Definition sketch:
- in /extra/org.modelica.fmi.can_bus/ all CAN bus description files are placed, the root name of the file is the name of the bus: BusName
- CAN signals in the IO are physical values scaled according to DBC/ARXML definition
- we will define a Terminal type CAN_Message BusName::MessageName that groups signals and matches by variable name [ - variable names are composed as BusName::MessageName::SignalName (signal names are not unique within a bus definition and message names are not unique across buses) to make them unique as required by FMI]
- each CAN_Message has its own dedicated clock, the name is BusName::MessageName:::Clock
- all variables belonging to a CAN_Message are clocked variables (the output/input clock is active when a message is sent/received)
- signal variables are generally of type fmiFloat64, except if conversion to physical requires other data types, e.g. fmi3Int64
Open: ? mapping of CAN message to clock: 1. do not link CAN_Messages to the variable clocks explicitly, but implicitly via the clock of the variables? 2. link CAN_Messages to clock via name convention? 3. link CAN_Messages to clock via annotation? 4. add clock to terminal definition (maybe even empty to avoid conflicts) ? above is a signal-view CAN; alternatively, we could send a binary type with the payload of the message (I like the first better and I would not yet define the second option): variableKind should reflect current phyical signal view, later extensions to raw signal and message load are trivial ? how do we specify which node(s) to emulate inside the FMU? ? Naming convention for signals: maybe use '.' as separator: not so important anymore because of in-terminal mapping (terminal name should use ::) ? Naming convention for clock: alternatives; maybe we add clock to terminal and use an empty variable name...
Note:
- we keep it simple by using only one encoding of messages: physical signals (to simplify coupling with plant models)
- future versions of this layered standard might add raw signals or raw (binary) messages
Some further thoughts based on our discussions:
-
There is no problem with the underspecification of the physical data type in e.g. DBC files: The FMU itself provides that mapping, through the specification of the fmi variable type. For generators that do not allow the user to specify this, they would follow whatever conventions they require (e.g. something matching CAN interface code generators when wrapping ECU code).
-
Hence the combination of FMU variable types and DBC entries provides enough information on what to map, e.g. whether to map a single bit to boolean or integer, a non-fractional number to integer or floating-point, etc.
-
All signals in a CAN_Message terminal must be either inputs or outputs, thereby making the terminal in-coming or out-going.
-
If we use CAN_Message for the terminal type of messages, we can wrap those terminals in a terminal with type CAN_Bus, which then allows easy plugging of busses.
-
Node selection could be specified as additional annotation of terminal (thus allowing multiple CAN nodes to be wrapped in a single FMU).
* There is no problem with the underspecification of the physical data type in e.g. DBC files: The FMU itself provides that mapping, through the specification of the fmi variable type. For generators that do not allow the user to specify this, they would follow whatever conventions they require (e.g. something matching CAN interface code generators when wrapping ECU code). * Hence the combination of FMU variable types and DBC entries provides enough information on what to map, e.g. whether to map a single bit to boolean or integer, a non-fractional number to integer or floating-point, etc.
This is correct and simplifies the FMU generation code, if we leave the type mapping open. But it make connecting FMUs harder because it forces mapping of different types in the importer.
If we can find a unique way to prescribe what type to pick for what DBC type description, importers could simply connect inputs to outputs without additional work. I think for most cases, defining this mapping is trivial. The few remaining cases (float types with strange factor/offset/min/max combinations) might destroy my dream. I will give this some thought...
Ticket-viewing-meeting
Andreas: I created a PR; some more people have to look into this. TorstenB: Can we accept this and create new PRs to improve this? Andreas: I will ask TorstenS or try to add it to the CircleCI YAML file. Then I will merge this. Christian: We perhaps have to clarify that layered standards of the FMI Project are covered by the CLA/CCLA Christian: A different approach would be to use binary instead of using lots of physical signals Pierre/AndreasJ: one still can do this with this approach. Andreas: we have lots of experience with this (w/o the clocks) Pierre: the only reason why one would use the binary stuff would be to test the low-level encoding ...
Feedback from an internal discussion with @tg9541 and @fajansen:
- there should be a clear separation of the approaches “High Cut” or “Signal Layer Approach” (maybe “K-Matrix view” or “Functional Integration View”) or vs. “Low Cut” or “Network Layer Approach” (maybe “Packet View”, “Communication-Stack-under-Test View”) as there is value in both, and both have their use-cases. The current PR #1091 is a "High Cut" proposal and this should be reflected in the name of the layered standard.
- “High Cut” represents the function integrator’s level – technical properties like signal rates are defined by contracts, not by the implementation
- “Low Cut” represents the technical integrators level – technical properties like latency of the communication stack or network packets can be fully represented by models or by the implementation
- Rendering “AUTOSAR Signals” as FMI Physical signals is fine iff we’re dealing with physical signals. The ISO23150 (ADAS sensor Object Level information) is a good reason to look beyond that, e.g. in the direction of MIME type specified byte streams
We like to propose the following points:
- “Message” as hierarchical clocked variable is an interesting concept in the “High Cut” case. It was, however, associated with the technical specification (DB, ARXML) and the “Message” has been equated with the packet level (e.g. LPDU) and this will lead to modelling problems in the case of “multi-packet messages” (many messages for one signal) or “multiplexed messages” (a single message with sender defined rates for indexed individual signals)
- Network definitions (DBC, ARXML, Fibex etc) are semantic information. As the source of this information is the integrating system it’s questionable if this type of semantic information should be included in the FMU artifact (rationale: these artifact often contain information that describe the integrating environment, and the information may be subject to 3rd part copyright)
- “High Cut” or “Signal Level might benefit from a standardized AUTOSAR compatible network definition. Due to many dialects and description formats, and the risk of leaking protected information in the case we include the original specification files, a neutral, and sufficiently general description file may be needed
- A neutral IDL definition might well be a way forward (we proposed using the Flatbuffers IDL)
- Time information should be included as semantic information for both “High Cut” (Signal Layer) and “Low Cut” (Packet Layer or Network Layer). The problem is highly related to the problem of modeling distributed functional blocks with message signaling events (see our 2018 FMI3 “Virtual ECU” use case): receiving a network packet often is the signaling event!
The "high cut" and "low cut" are equivalent, iff one has the proper description formats to translate between them. This is the point of this proposal: We use the physical layer (high cut) because this is closest to the current FMI/Modelica world and likely maps better into existing simulations. If you need a "low cut", you can create the messages (or PDUs or frames) out of the physical signals when you receive the messages using the description formats. But the point is well taken: I will add a clarification.
Physical signals: Indeed, this is an interesting point that needs clarification: some signals have no physical or numeric interpretation. But FMI 3.0 will have new types to allow for transport of those binary objects. We will need to clarify that this is of course possible to use (even if for CAN, this will remain special cases, like UDS packages).
Semantic information hiding/IP protection: This is an interesting topic and belongs to the AUTOSAR consortium to solve there as it requires holistic treatment from extraction tooling to process descriptions in work share settings. And even today, as example, ECU extracts are available that allow reduction of what is exposed to partners. We cannot solve such topics with a standard for a simulation artifact container.
IDL: What is suggested here is an alternative format for ARXML (or DBC, or even Fibex if we would go beyond CAN). Developing such an alternative format would force us to continuously adapt to new features of ARXML to keep it functionally equivalent. But would it solve the IP protection issue (or copyright issues)? It might do better than current approaches because it could more specifically reduce what is present in the ARXML. But why not simply define a subset of ARXML tags? Tooling for ARXMLs is now widely available and must be maintained at the speed of AUTOSAR releases anyway. Again, such a reduction belongs to the standardization body it originates from (of course we could cooperate in such a definition).
Timing: Timing is defined in the ARXMLs (or DBCs). Why should we redefine it? The idea of this proposal is precisely to reuse what is already available, validated, comes with tooling support and does not require extra standardization work because it refers to an existing, evolving standard and delegates the handling to tools that are capable of interpreting it. The FMU importer does not need to know about the special interpretation of the CAN signals for signal forwarding, unless, of course, it is specifically enabled to do so (e.g. a CAN fuzzing tool or CAN tracing tool). In a sense, we are using FMI as an OSI Transport Layer (looking at it from far enough) and it is a luxury to not have to deal with the levels above or below, unless you chose to.
To summarize my thoughts on the ways to map increasingly deeper levels of the interface to the bus, based on the current proposal:
Level 1
The current proposed signal-based level, where mapping to CAN bus, framing,etc. is all handled through mapping information outside of the FMU.
Level 2
The next slightly deeper level (which is actually already kind of implied in the spec) would be to have just one binary variable in the message terminal, that includes the whole data part of the message (the 0-8 bytes of data for CAN). This allows avoiding any signal mapping/type conversions at the FMI interface level, leaving that to the FMU-internal code. I think the current PR should just be clarified to allow this directly.
Level 3
The next level down from this would just have two binary variables (one input, one output) for the whole bus terminal (i.e. no message terminals), which represents the whole CAN frame (everything from SOF until and including EOF, without interframe space and without bit-stuffing) being sent/received.
This allows arbitrary frames to be transceived, including e.g. remote frames, etc.
It would still be based on two clocks (input and output aperiodic clocks) to signal time of start of transmission/time of reception.
To be discussed: Whether to include already at this level additional clocks and variables to allow signalling of Invalid Message Received Error/Bit Stuffing Error/Wake up and Acknowledge/Form/Bit Error. This could also be considered an even lower level.
Level 4 (or 5)
This level would require actual bit-clock transmission, to simulate e.g. arbitration errors inside messages (i.e. multiple senders with same ID), etc. I would not cover this here in too much detail for now.
Interoperability
Level 1 and 2 can be trivially bridged by an importer (as long as DBC/ARXML description is available). Level 3 could also be bridged to Level 1/2 with reduced functionality. The same, but much reduced for Level 4/5.
Summary
Does the above description of levels make sense? Are we missing something obvious?
It seems to me that Level 1&2 should be covered by the current CAN signals PR, Level 3 might be added or might be a separate layered standard depending on the details, level 4/5 or below seem to me to make more sense as something separate.
I added PR #1177 that clarifies how to transport CAN message data - that is what @pmai calls Level 2. How to include Level 3 would need a discussion to clarify a few details.
@pmai from my understanding I'd like to describe your levels like this:
Level1
Signal specs as defined by a bus node in a K-matrix (communication model). The origin of received signals is modeled outside of the ECU. The update rate of signals sent is an intrinsic property of the model (associated to events or to clock domains). The receiver can model reception (or non-reception).
This level is independent of the underlying bus type.
Level2
As a COM stack is part of the implementation, bus events can be modeled as binary variables ("LPDU"). The K-matrix is used to model origin and destination of binary variables outside of the FMU.
I agree that a model of the interpretation of a buffer can be delivered, together with the FMU, and implementations of "hybrid FMUs" that allow satisfying hybrid Level1/Level2 use cases may be possible.
I differ on the point that such an implementation is trivial ( even though the case of a DBC may make it appear as if that's what it is). ARXML descriptions can be very complex and the correct interpretation of such a specification is precisely what raises the need for buffer level simulations for the purpose of acceptance- and integration testing.
Level3
In my opinion this is the general case for buffer level testing (of implementations).
Modeling CAN buses on the behavioral level is rather simple if a basic behavioral model of a CAN bus interface controller (say 82C200) is assumed. All properties that the can bus depends on (e.g. the effects of arbitration or error frames on time) are already present. Modeling FIFOs or message buffers is then a mere implementation detail.
Modeling other bus systems (e.g. FlexRay) or more complex communication systems (e.g. Ethernet with QoS and GoS) can be dealt with in a similar way. A "bus model", in the simulation environment and thus outside of the FMU, models the behavior of message flow between ECUs. Such a bus model can be implemented by an FMU.
Level 4/5
This is simular to Level3 except that we're entering the domain of HDLs.
This should be feasible, too, but it's actually in the domain of V&V of hardware, not a CPS behavioral level. In the case of a "bus model" a HDL description (transaction level modeling) might be an appropriate solution. Please note that such a model, in most automotive use cases would be agnostic of any interpretation of a buffer contents that would be the payload of such a transaction.
Edit: clarifications added
