4_4_3_flexray.adoc

FlexRay

This chapter describes the Layered Standard Bus Protocol for FlexRay.

Overview

This specification refers primary to the data link layer specification of FlexRay communications systems defined by ISO 17458-2:2013(en). Furthermore, essential elements from previous FlexRay specifications are covered so that they can also be realized using this layered standard.

To simulate FlexRay communication between Networked FMUs, FlexRay-specific operations are specified based on the Layered Standard Bus Protocol. Overall, the following operations and groups of operations exists:

• Transmit, Cancel and Confirm: These operations are used to simulate a FlexRay frame transmission.

• Bus- and Format Error: This group of operations is used for protocol format errors and to simulate bus failures.

• Configuration: This operation enables the controller to publish bus-specific parameters and options that are required to simulate the bus behavior properly. For example, it allows the specification of a macrotick duration or the length of static/dynamic slots.

• Start Communication: This operation is used by Networked FMUs or Bus Simulations to start the FlexRay communication.

• Symbol: Represents a set of operations that are used for transmission of FlexRay-specific symbols, like for wake-up, startup or media testing.

The following table gives a detailed overview of the available operations. It shows all operations and the arguments they contain.

Table 1. Overview of the available operations for FlexRay.

Operation Name	Operation Content
	OP Code	Length	Specific Content
Format Error	0x01	:= 10 + n (4 bytes)	DL (2 bytes)	Data (n bytes)
Transmit	0x10	:= 17 + DL (4 bytes)	Cycle ID (1 byte)	Slot ID (2 bytes)	Channel (1 byte)	…​	DL (1 bytes)	Data (n bytes)
Cancel	0x11	:= 12 (4 bytes)	Cycle ID (1 byte)	Slot ID (2 bytes)	Channel (1 byte)
Confirm	0x12	:= 12 (4 bytes)	Cycle ID (1 byte)	Slot ID (2 bytes)	Channel (1 byte)
Bus Error	0x20	:= 13 (4 bytes)	Error Flags (1 byte)	Cycle ID (1 byte)	Segment Indicator (2 bytes)			Channel (1 byte)
Configuration	0x30	<Length> (4 bytes)	Kind (1 byte)	Dynamic Part
Start Communication	0x40	:= 16 (4 bytes)	Start Time (8 bytes)
Symbol	0x50	:= 11 (4 bytes)	Cycle ID (1 byte)	Channel (1 byte)	Type (1 byte)

Basic Type Definitions

The following basic types are defined for the FlexRay section and are used within the operation definitions as operation arguments.

Channel Type

The following values for the channel type are defined:

Table 2. Overview of the available channel type values.

[Flag] Channel	Value	Description
CHANNEL_A	0x01	Describes the FlexRay Channel A.
CHANNEL_B	0x02	Describes the FlexRay Channel B.

Operations

This section defines the specified operations for FlexRay. The following tables provide an overview of all operations and specify the position and length of the corresponding arguments. Also a detailed description of the operations is provided.

Transmit

The Transmit operation is used to simulate the transmission of FlexRay frames.

Table 3. Detailed description of the Transmit operation.

Name	Transmit
Description	Initiates the transmission of FlexRay frames.
OP Code [hex]	0x10
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x10) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 17 + Data Length.
	Cycle ID	1 byte	The specified Cycle ID of the FlexRay message.
	Slot ID	2 bytes	Specifies the FlexRay Slot ID of the given frame.
	Channel	1 byte	The specified channel type value, based on Overview of the available channel type values., whereby the combination of more than one channel is allowed.
	Startup Frame Indicator	1 byte	Specifies whether the given frame represents a startup frame. The boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Sync Frame Indicator	1 byte	Specifies whether the given frame represents a sync frame. The boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Null Frame Indicator	1 byte	Specifies whether the payload contains valid data (= FALSE) or is composed of zero values only (= TRUE). The boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Payload Preamble Indicator	1 byte	Indicates whether the payload contains a network management vector (= TRUE) or a message identifier (= FALSE). The boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Data Length	1 byte	Specifies the length of the Data argument in bytes.
	Data	n bytes	Stores the given frame data to transfer, whereby the valid length of the data depends on the FlexRay Format.
Behavior	The Transmit operation shall be provided by Network FMUs to indicate the transmission of a FlexRay frame. In the case of directly connected Network FMUs (see [common-concepts-direct-communication]), the FMU importer forwards the operation directly to the receiving Network FMUs. If a Bus Simulation is involved (see [common-concepts-composition-with-dedicated-bus-simulation-fmu] and [common-concepts-importer-with-integrated-bus-simulation]), the FMU importer forwards the operation initially to the Bus Simulation, where the operation is distributed with respect to the simulated bus behavior. Depending on the simulation details, the Bus Simulation might respond with a Confirmation, Bus Error or Format Error operation. If the specific Transmit operation is to be set across multiple channels, the channel argument can combine both channels. The point in time at which a Network FMU provides a Transmit operation must be within a valid provision time window. For the static segment, this circumstance is dealt within Static Segment, for the dynamic segment in Dynamic Segment. The point in time at which a Bus Simulation shall provide Transmit operations depends on the DeliveryOnBoundary configuration parameter.

Cancel

The Cancel operation is used for cancellation of a FlexRay frame transmission.

Table 4. Detailed description of the Cancel operation.

Name	Cancel
Description	Initiates the cancellation transmission of FlexRay frames within a Bus Simulation.
OP Code [hex]	0x11
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x11) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 12.
	Cycle ID	1 byte	The specified Cycle ID of the Transmit operation to cancel.
	Slot ID	2 bytes	Specifies the FlexRay Slot ID of the Transmit operation to cancel.
	Channel	1 byte	The specified channel type value, based on Overview of the available channel type values. of the Transmit operation to cancel, whereby the combination of more than one channel is allowed.
Behavior	The Cancel operation shall be provided by Network FMUs to indicate a cancellation of a specified Transmit operation that is buffered by a Bus Simulation. A Network FMU shall ignore this operation on the consumer side. A Cancel operation is possible as long as the Bus Simulation has not yet started to simulate the transmission of the specified Transmit operation. A Cancel operation must be related to a complete Transmit operation and not just to a part of it.

Confirm

The Confirm operation is used to signal a transmitted FlexRay frame (see Transmit operation).

Table 5. Detailed description of the Confirm operation.

Name	Confirm
Description	Signals a successful transmitted FlexRay frame.
OP Code [hex]	0x12
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x12) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 12.
	Cycle ID	1 byte	The specified Cycle ID of the Transmit operation to confirm.
	Slot ID	2 bytes	Specifies the FlexRay Slot ID of the Transmit operation to confirm.
	Channel	1 byte	The specified channel type value, based on Overview of the available channel type values., whereby the combination of more than one channel is allowed.
Behavior	The specified operation shall be produced by the Bus Simulation and consumed by Network FMUs. The Bus Simulation provides the Confirm operation for the Network FMU, which has previously provided the Transmit operation to be confirmed. Only Network FMUs with the corresponding optionally exposed BusNotifications parameter set to fmi3True might wait for this operation.

Format Error

A format error indicates a syntax or content error in response to a received operation. See Format Error for definition.

Bus Error

The Bus Error operation represents feedback of a Bus Simulation for a specified Transmit operation in case of an unsuccessful transmission. The following information is included within this operation:

Table 6. Detailed description of the Bus Error operation.

Name	Bus Error
Description	Represents an operation for simulated bus errors.
OP Code [hex]	0x20
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x20) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 13.
	Error Flags	1 byte	The specified error flag(s), based on the table below. The allowed combinations are defined by the FlexRay specification itself.
	Cycle ID	1 byte	The specified FlexRay Cycle ID.
	Segment Indicator	2 bytes	Identifies the specified FlexRay segment, where the Bus Error occurs. Within the static or dynamic segment, the value of Segment Indicator shall be the Slot ID of the Transmit operation to react. Within a Symbol Window or Network Idle Time segment the values of Overview of the available segment type values. shall be used instead of the specified Slot ID.
	Channel	1 byte	The specified channel type value, based on Overview of the available channel type values..
Behavior	The specified operation shall be produced by the Bus Simulation and consumed by Network FMUs. It represents a direct feedback corresponding to a specified Transmit operation. Depending on the type of Bus Error, either only the Transmit producing or all Network FMUs must be notified via Bus Error operation (see description column of Overview of the available error flag values.). Only Network FMUs with the corresponding optionally exposed BusNotifications parameter set to fmi3True might wait for this operation.

The following Error Flags can be used:

Table 7. Overview of the available error flag values.

[Flag] Kind	Value	Description
VALID_FRAME	0x01	Indicates a valid Transmit operation and can be used to point out a valid FlexRay transmission in combination with another error, for example within the FlexRay Symbol Window. This type of Bus Error is possible for both Transmit producing and Transmit consuming Network FMUs.
SYNTAX_ERROR	0x02	Indicates a syntactic error in a time slot of a Transmit operation. This type of Bus Error is possible for both Transmit producing and Transmit consuming Network FMUs.
CONTENT_ERROR	0x04	Indicates a content error of a receiving Transmit operation on the receiver side. This type of Bus Error is possible for both Transmit producing and Transmit consuming Network FMUs.
BOUNDARY_VIOLATION	0x08	Indicates that a boundary violation occurred at a boundary of the corresponding slot. This type of Bus Error is possible for both Transmit producing and Transmit consuming Network FMUs.
TX_CONFLICT	0x16	Indicates that a reception from another Network FMU is already ongoing while the specified Network FMU starts a transmission via a Transmit operation. This type of Bus Error is possible for Transmit producing Network FMUs only.

The following segment types can be used:

Table 8. Overview of the available segment type values.

Kind	Value	Description
SYMBOL_WINDOW	0xFFFE	Indicates the FlexRay Symbol Window segment.
NIT	0xFFFF	Indicates the FlexRay Network Idle Time (NIT) segment.

Configuration

The Configuration operation allows Network FMUs the configuration of the Bus Simulation with parameters like the length of a slot or the duration of a macrotick and further options. The following information are included within this operation:

Table 9. Detailed description of the Configuration operation.

Name	Configuration
Description	Represents an operation for the configuration of a Bus Simulation. It contains necessary parameters for timing calculations of transmissions and for node compatibility checks across the whole FlexRay network. Also the configuration of further options is supported by this operation.
OP Code [hex]	0x30
Content	Argument			Length	Description
	OP Code			4 bytes	Contains the OP Code (0x30) of the operation.
	Length			4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 9 + Length of parameter arguments in bytes.
	Parameter Type			1 byte	Defines the current configuration parameter. Note that only one parameter can be set per Configuration operation.
		Parameters
		FLEXRAY_CONFIG	Macrotick Duration	4 bytes	Specifies the duration of one macrotick in nanoseconds. See gdMacrotick parameter within FlexRay specification for further information.
			Macroticks per Cycle	2 bytes	Defines the length of a cycle in macroticks. See gMacroPerCycle parameter within FlexRay specification for further information.
			Cycle Count Max	1 byte	Defines the maximum cycle counter value in a given FlexRay cluster. See gCycleCountMax parameter within FlexRay specification for further information.
			ActionPoint Offset	1 byte	Defines the action point offset of a static slot in macroticks. See gdActionPointOffset parameter within FlexRay specification for further information.
			Static Slot Length	2 bytes	Defines the length of a static slot within the static segment in macroticks. See gdStaticSlot parameter within FlexRay specification for further information.
			Number of Static Slots	2 bytes	Specifies the number of static slots within one FlexRay cycle. See gNumberOfStaticSlots parameter within FlexRay specification for further information.
			Static Payload Length	1 byte	Specifies the length of static slot payload in bytes. See gPayloadLengthStatic parameter within FlexRay specification for further information.
			Minislot ActionPoint Offset	1 byte	Defines the action point offset of a minislot in macroticks. See gdMinislotActionPointOffset parameter within FlexRay specification for further information.
			Number of Minislots	2 bytes	Specifies the number of minislots within one FlexRay cycle. See gNumberOfMinislots parameter within FlexRay specification for further information.
			Minislot Length	1 byte	Defines the length of a minislot within a dynamic segment in macroticks. See gdMinislot parameter within FlexRay specification for further information.
			Maximum Dynamic Payload Length	1 byte	Specifies the maximum length of a dynamic slot payload in bytes. See pPayloadLengthDynMax parameter within FlexRay specification for further information.
			Symbol ActionPoint Offset	1 byte	Defines the action point offset within the symbol window in macroticks. See gdSymbolWindowActionPointOffset parameter within FlexRay specification for further information.
			Symbol Window Length	1 byte	Specifies the length of symbol window in macroticks, whereby a zero value is allowed. See gdSymbolWindow parameter within FlexRay specification for further information.
			NIT Length	2 bytes	Specifies the length of the Network Idle Time in macroticks. See gdNIT parameter within FlexRay specification for further information.
			NM Vector Length	1 byte	Specifies the length of the Network Management Vector. See gNetworkManagementVectorLength parameter within FlexRay specification for further information.
			Dynamic Slot Idle Time	4 bytes	Defines the length of dynamic slot idle time within a dynamic segment in macroticks, whereby zero defines that is not used.
			Coldstart Node	1 byte	Specifies if the given FlexRay node represents a coldstart node or not, by using Overview of the available coldstart node types.. If a specified node has coldstart capabilities, additionally the type of coldstart shall be defined.
Behavior	The specified operation shall be produced by a Network FMU. In case of directly connected Network FMUs (see [common-concepts-direct-communication]), Network FMUs also receive Configuration operations from other nodes. Therefore, Network FMUs shall check receiving Configuration operation of type FLEXRAY_CONFIG for compatibility. If a Bus Simulation is involved (see [common-concepts-composition-with-dedicated-bus-simulation-fmu] and [common-concepts-importer-with-integrated-bus-simulation]), the compatibility check should be done by the Bus Simulation. In this case, the Bus Simulation must not forward the Configuration to Network FMUs. The configuration of the FLEXRAY_CONFIG parameters must be completed by all Network FMUs before any Transmit operation is produced. The reconfiguration of FLEXRAY_CONFIG parameters during the runtime of a Network FMU is not allowed.

The following configuration parameters are defined:

Table 10. Overview of the available configuration parameters.

Parameter	Value	Description
FLEXRAY_CONFIG	0x01	Indicates global FlexRay parameters used by the Network FMU.

The following coldstart node types are defined:

Table 11. Overview of the available coldstart node types.

Coldstart Node Type	Value	Description
None	0x01	Describes that the current node has no coldstart capabilities.
TT-D coldstart node	0x02	Indicates a TT-D coldstart node.
TT-E coldstart node	0x03	Indicates a TT-E coldstart node.
TT-L coldstart node	0x04	Indicates a TT-L coldstart node.

Start Communication

By using the Start Communication operation, a Network FMU or Bus Simulation communicates the start of the first communication cycle. The following information is included within this operation:

Table 12. Detailed description of the Start Communication operation.

Name	Start Communication
Description	Starts the FlexRay communication.
OP Code [hex]	0x40
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x40) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 16.
	Start Time	8 bytes	Defines the absolute simulation time in nanoseconds when the first FlexRay cycle has started.
Behavior	The specified operation shall be produced by a Network FMU and distributed to all participants, except the Start Communication operation initiator, by using the Bus Simulation to distribute the start time of the first communication cycle. Network FMUs must synchronize their internal FlexRay clock when receiving a Start Communication operation.

Symbol

The Symbol operation is used for transmission of FlexRay-specific symbols, e.g. for wake-up, startup or media testing in the symbol window.

Table 13. Detailed description of the Symbol operation.

Name	Symbol
Description	Operation representing a symbol transmitted in the FlexRay symbol window.
OP Code [hex]	0x50
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x50) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 11.
	Cycle ID	1 byte	The specified FlexRay Cycle ID. If a FlexRay cycle is not yet running (for example when initiating a startup through a collision avoidance symbol), the value 0 should be used.
	Channel	1 byte	The specified channel type value, based on Overview of the available channel type values..
	Type	1 byte	The specified symbol type, based on the table below.
Behavior	The specified operation shall be produced by a Network FMU and distributed to all participants, except the Symbol operation initiator, of the bus using the Bus Simulation. Depending on the simulation details, the Bus Simulation might respond with a Bus Error operation. If a Network FMU does not support a specified Type of a Symbol operation, this operation can be ignored on the consumer side.

The following symbol type values can be used:

Table 14. Overview of the available symbol type values.

Kind	Value	Description
COLLISION_AVOIDANCE_SYMBOL	0x01	The collision avoidance symbol is used to indicate the start of the first communication cycle.
MEDIA_TEST_SYMBOL	0x02	The media test symbol is used for testing of a bus guardian.
WAKEUP_SYMBOL	0x03	The wake-up symbol is used for waking up other FlexRay nodes of the specified network.

Network Parameters

This chapter defines parameters that Network FMU might provide to configure FlexRay-specific behavior.

Bus Notification Parameter

For a detailed simulation, a Network FMU needs information about whether the message sent has arrived or whether a bus error has occurred. A Bus Simulation can simulate these effects by sending bus notifications in terms of Confirm- and Bus Error operations to the Network FMUs.

However, in scenarios where Network FMUs are connected directly to each other, or where the Bus Simulation does not simulate such effects, it must be possible to configure the Network FMU such that it does not wait for any response after a Transmit operation. Therefore, a parameter with memberName = "BusNotifications" can be added within the FlexRay-specific Configuration Terminal.
If a Network FMU supports bus notifications, the BusNotifications parameter shall be exposed. The default value of this parameter shall be false.
[The default value false allows a simple integration of Network FMUs to simulation scenarios where Confirm- or Bus Error operations are not used.]

Only Network FMUs with the corresponding optionally exposed BusNotifications parameter set to fmi3True might wait for Confirm- and Bus Error operations and respond accordingly; otherwise Network FMUs must not wait ("fire-and-forget"). Even if the Network FMU does not expect bus notifications, i.e. BusNotifications variable was not set to fmi3True, but receives them, it shall ignore them, i.e. it shall not report warnings or errors.

[Note that the bus notification parameter just informs the Network FMU if it can expect to receive notification operations or not. The parameter doesn’t define in any way on how to react upon receiving notification operations.]

Parameter to configure bus notifications within a FlexRay Bus Terminal of Network FMUs.

 memberName:    BusNotifications
 type:          Boolean
 causality:     parameter
 variability:   fixed
 start:         false

A Bus Simulation FMU shall indicate via a variable with memberName = "BusNotifications" within the FlexRay-specific Configuration Terminal whether it provides bus notifications or not. If the provision of bus notifications can be configured (e.g., via a structural parameter), the attributes of the BusNotifications variable shall contain causality = "calculatedParameter" and variability = "fixed"; or causality = "output" and variability = "constant" otherwise.

Parameter to configure bus notifications within a FlexRay Bus Terminal of the Bus Simulation.

 memberName:    BusNotifications
 type:          Boolean
 causality:     calculatedParameter/output
 variability:   fixed/constant

Delivery on Boundary Parameter

In order to minimize the number of Bus Communication Points of an entire simulation system, it can make sense that the Bus Simulation always delivers Transmit operations on a concrete slot boundary. Under the condition that participating Network FMUs also provide their Transmit operations on a slot boundary, the behavior means that the Transmit operation to be received, the next Transmit operation to be sent and a Confirm or Bus Error operation are provided and exchanged at exactly one Bus Communication Point.

Therefore, a parameter with memberName = "DeliveryOnBoundary" can be added within the FlexRay-specific Configuration Terminal to switch the behavior in the Bus Simulation. If the value of the parameter is set to fmi3True, the Bus Simulation provides Transmit operations and also resulting Confirm- and Bus Error operations at a concrete slot boundary. If the value of the parameter is set to fmi3False, the Bus Simulation provides the respective operations after the calculated transfer time. See Static Segment and Dynamic Segment for details. The default value shall be true. If a Network FMU is supporting the delivery on slot boundaries only, the parameter shall be omitted.

Parameter to configure the delivery point of reception within a FlexRay slot for Network FMUs.

 memberName:    DeliveryOnBoundary
 type:          Boolean
 causality:     parameter
 variability:   fixed
 start:         true

A Bus Simulation FMU shall indicate via a variable with memberName = "DeliveryOnBoundary" within the FlexRay-specific Configuration Terminal whether it provides operations on a concrete slot boundary or not. If the delivery on slot boundaries can be configured (e.g., via a structural parameter), the attributes of the DeliveryOnBoundary variable shall contain causality = "calculatedParameter" and variability = "fixed"; or causality = "output" and variability = "constant" otherwise.

Parameter to configure the delivery point of reception within a FlexRay slot by the Bus Simulation.

 memberName:    DeliveryOnBoundary
 type:          Boolean
 causality:     calculatedParameter/output
 variability:   fixed/constant

Configuration of Bus Simulation

The timing behavior of FlexRay communication is typically defined globally in a design phase of the FlexRay network. At runtime, the globally defined communication parameters must be used by all network nodes to communicate successfully. To ensure that all Network FMUs use compatible parameters and to tell Bus Simulations how to simulate the FlexRay communication, Network FMUs shall send the Configuration operation. Configuration parameters which are mandatory to provide when first entering the Event Mode immediately after leaving the Initialization Mode are of type FLEXRAY_CONFIG. Network FMUs receiving Configuration operations of type FLEXRAY_CONFIG shall check its compatibility. Bus Simulations are also allowed to perform compatibility checks of FLEXRAY_CONFIG parameters. In this case, a Bus Simulations must not forward Configuration operations to Network FMUs. In cases of detected incompatibilities, the simulation shall be refused accordingly.

Wake Up/Sleep

This standard supports wake up and sleep functionality for the FlexRay bus. However, the realization of local virtual ECU wake-up and sleeping processes, i.e., the transition to the sleep state as well as the virtual ECU local wake-up process, is considered internal to the FMU implementation. Therefore, only the bus-related aspects are defined in this document.

The FlexRay-specific wake-up pulse can be simulated by using the Symbol operation, initiated by one Network FMU, whereby Type is set to WAKEUP_SYMBOL. The Bus Simulation shall distribute this operation to all participants on the bus, excluding the Symbol operation initiator.

Figure 1. Wake up initiated by FMU 1 wakes up FMU 2 via bus.

Startup

Before frames can be transferred, the communication must be started. The startup process follows a defined sequence in which FlexRay nodes synchronizes step by step (for a detailed description refer to [ISO-17458-2]). FlexRay nodes, that are allowed to start the FlexRay communication, are referred to as coldstart nodes. The coldstart ability of a Network FMU must be communicated by the Coldstart Node parameter of the Configuration operation. For starting the FlexRay communication, a coldstart Network FMU shall send a Symbol operation whereby the Type argument is set to COLLISION_AVOIDANCE_SYMBOL to announce the start of the first FlexRay communication cycle. A Bus Simulation must forward the Symbol operation immediately to the other Network FMUs. Network FMUs receiving a COLLISION_AVOIDANCE_SYMBOL are not allowed to send the Symbol operation likewise from this point onwards. The first communication cycle is then started by sending the Start Communication operation. Network FMUs must synchronize their internal FlexRay clock based on the received Start Time.

Figure 2. Startup initiated by a coldstart Network FMU.

The start time of the first communication cycle is defined as \$T_{Start}\$ in this specification.

After the Start Communication operation has been sent, the Network FMU starts sending Transmit operations, whereby the Startup Frame Indicator argument is set to TRUE.

Emulating Coldstart Nodes

Normally, the startup process requires at least two coldstart nodes. For simulation systems coldstart Network FMUs are missing (because only a subset of nodes is to be simulated), a Bus Simulation is allowed to start the FlexRay communication by emulating the behavior of missing coldstart nodes. For this purpose, structural parameters e.g. for defining the startup time (\$T_{Start}\$) or the Slot ID for startup frames can be provided by the Bus Simulation. Because those parameters are Bus Simulation specific, they are not further defined in the specification.

Figure 3. Startup initiated by the Bus Simulation

Transmission and Reception

The exact time or permitted range for sending a message is essential for FlexRay, as this is a scheduled bus protocol. Within this section the data flow is first described in more detail. After this temporal aspects for data transmission are explained.

Similar to the other buses, the Transmit operation represents the core of a bus transmission. It contains all relevant frame data and is provided by a Network FMU in the role of a sender, potentially via a Bus Simulation, to one or more Network FMUs in the role of a receiver.

A Confirmation- and Bus Error operation represents feedback from a Bus Simulation for a previously carried out Transmit operation. Depending on the BusNotifications parameter, a successful transmission of a Transmit operation results for a Network FMU in a Confirmation operation, an unsuccessful Transmit operation in a Bus Error operation. If BusNotifications is false (default), then Network FMUs must not rely on receiving Confirm operations. If a specified Network FMU is depending on Confirm operations and BusNotifications is false, the self confirmation shall be realized internally within the respective Network FMU.

If a Bus Simulation is involved, the following applies: A Network FMU can update a Transmit operation in a Bus Simulation as long as the same value is used for the Slot ID argument. The last Transmit operation is always valid (last-is-best semantics). A Transmit operation can be updated as long as the Bus Simulation has not yet started to simulate the transmission of the representing FlexRay frame. The Cancel operation allows the cancellation of such buffered Transmit operations within a Bus Simulation.

General transmission mechanism for FlexRay. illustrates the sequence of the operations mentioned. First, FMU 1 provides a Transmit operation for the Bus Simulation. Within the next two steps, FMU 1 updates the specified Transmit again. In the next step, the last Transmit operation, provided by FMU 1, is transferred to FMU 2 by the Bus Simulation. Also the Bus Simulation provides a Confirm operation for FMU 1.

Figure 4. General transmission mechanism for FlexRay.

Cancellation of a transmission for FlexRay via Cancel operation. illustrates a sequence with focus to the Cancel operation. First, FMU 1 provides a Transmit operation for the Bus Simulation. Within the next step, FMU 1 updates the specified Transmit again. In the next step, the transmission ist canceled via Cancel operation. By using the Cancel operation, the Transmit operation will not be forwarded to other Network FMUs by the Bus Simulation. No transmission takes place within the simulation system.

Figure 5. Cancellation of a transmission for FlexRay via Cancel operation.

At bus level, the macrotick represents the smallest time unit on a FlexRay bus. A total of four protocol parts are logically mapped onto this: The static and the dynamic segment, the so-called symbol window and the Network Idle Time (NIT). The static and dynamic segment is in turn divided into different sections, so-called FlexRay slots. These segments repeat themselves in certain FlexRay cycles. Segmentation of a FlexRay cycle. visualizes the segmentation of a cycle.

Figure 6. Segmentation of a FlexRay cycle.

Within a real FlexRay bus, every macrotick represents a potential temporal synchronization point for the respective segments and frames to be transmitted. During a simulation, however, this type of synchronization would be unnecessarily inefficient. For simulation scenarios it is highly recommended that Transmit operations always be provided at the beginning of a slot. This minimizes the Bus Communication Points of the overall simulation system and usually increases the performance of the whole simulation. This behavior is defined more specifically and slightly differently depending on whether it is a static or dynamic segment.

What both segments have in common is that the Network FMU itself must know the appropriate time of a Transmit operation basing on the FlexRay cycle and slot principle. In concrete terms, this means that a Network FMU itself must provide the expected Transmit operation at the appropriate time via Tx Clock Variables. The start time of the first FlexRay cycle is defined by the Start Time argument value of the Start Communication operation.

That concrete means that the point in time for the start of FlexRay cycle in nanoseconds can be computed within a Network FMU as

\$ T_{\mathrm{CycleStart}}(i_{\mathrm{Iteration}}, i_{\mathrm{Cycle}}) = T_{\mathrm{Start}} + L_{\mathrm{Cycle}} \cdot (N_{\mathrm{Cycle}} \cdot i_{\mathrm{Iteration}} + i_{\mathrm{Cycle}})\$

, where:

• \$T_{\mathrm{Start}}\$ represents the start time of the first FlexRay cycle (see Start Time argument within the Start Communication operation) in nanoseconds.

• \$L_{\mathrm{Cycle}}\$ defines length of FlexRay cycle in nanoseconds (see Macrotick Duration and Macroticks per Cycle arguments within the Configuration operation).

• \$N_{\mathrm{Cycle}}\$ specifies the number of cycles per iteration (see Cycle Count Max argument within the Configuration operation, whereas \$N_{\mathrm{Cycle}} = \mathrm{gCycleCountMax} + 1\$).

• \$i_{\mathrm{Iteration}}\$ represents the desired iteration of complete FlexRay cycles.

• \$i_{\mathrm{Cycle}}\$ represents the cycle within the given iteration with \$i_{Cycle} \lt N_{Cycle}\$.

The point in time for the start of FlexRay cycle of the current iteration with focus to the simulation time can be computed within a Network FMU as

\$ T_{\mathrm{CycleStart}}(t, i_{\mathrm{Cycle}}) = T_{\mathrm{Start}} + L_{\mathrm{Cycle}} \cdot \left( \left\lceil \frac{t - T_{\mathrm{Start}}}{N_{\mathrm{Cycle}}} \right\rceil + i_{\mathrm{Cycle}} \right)\$

, where:

• \$t\$ represents the current simulation time in nanoseconds with \$t \geq T_{\mathrm{Start}}.\$

Static Segment

For a static segment, a Network FMU shall provide the respective Transmit operation in an interval starting at the beginning of a slot and ending at the action point (see ActionPoint Offset argument within the Configuration operation) of a slot. Within this time window, the Network FMU must provide the respective Transmit operation for a specific slot. The point in time at which a Bus Simulation shall provide Transmit operations and also resulting Confirm- or Bus Error operations depends on the DeliveryOnBoundary configuration parameter. If the parameter is set to fmi3False, the Bus Simulation provides the respective operations directly after the calculated transmission time (see orange arrow in Bus Communication Points within static segment.). If the parameter is true (default), the corresponding operations are only provided at the slot boundary (green arrow in Bus Communication Points within static segment.).

Figure 7. Bus Communication Points within static segment.

The starting point of the slot can be calculated at runtime based on the FLEXRAY_CONFIG configuration parameters as

\$ T_{\mathrm{Tx}_{\mathrm{Static}}}(t, i_{\mathrm{Cycle}}, i_{\mathrm{Slot}}) = T_{\mathrm{CycleStart}}(t, i_{\mathrm{Cycle}}) + (i_{\mathrm{Slot}} - 1) \cdot L_{\mathrm{StaticSlot}}\$

, where:

• \$i_{\mathrm{Slot}}\$ represents the index of the static slot for transmission (see Slot ID argument of the Transmit operation).

• \$L_{\mathrm{StaticSlot}}\$ defines the length of a static slot within the static segment in nanoseconds (see Macrotick Duration and Static Slot Length argument within the Configuration operation).

This results in an interval in which a Network FMU shall provide a specified Transmit of

\$ T_{\mathrm{Valid}} = \left[ T_{\mathrm{Tx}_{\mathrm{Static}}}(t, i_{\mathrm{Cycle}}, i_{\mathrm{Slot}}), \; T_{\mathrm{Tx}_{\mathrm{Static}}}(t, i_{\mathrm{Cycle}}, i_{\mathrm{Slot}}) + T_{\mathrm{ActionPoint}_{\mathrm{Static}}} \right]\$

, where:

• \$T_{\mathrm{ActionPoint}_{\mathrm{Static}}}\$ represents the action point offset of a static and symbol slot in nanoseconds (see Macrotick Duration and ActionPoint Offset argument within the Configuration operation).

In a sequence of operations to the respective actors and focus to the FlexRay slot counter, communication is presented as shown in Transmission sequence within a static FlexRay segment with an involved Bus Simulation.. At the beginning of slot 6, FMU 1 provides a frame to be sent in the form of a Transmit operation for the Bus Simulation. After simulation of the specified transmission time, the Bus Simulation provisions the Transmit operation to FMU 2 and a Confirm operation to FMU 1.

Figure 8. Transmission sequence within a static FlexRay segment with an involved Bus Simulation.

Dynamic Segment

When using the dynamic segment, the use is analogous to the use of Transmit operations in the static segment. Network FMUs need to provide a Transmit operation within a well-defined time window and with respect to the designated minislot. Since the dynamic FlexRay segment works more event-based, it can happen that a transmission is already ongoing at the current time. For this reason, the slot counter within Network FMUs are important, especially in the dynamic segment.

Within the dynamic segment, Slot ID = n + m represents the first valid point in time when a Network FMU is allowed to provide the respective Transmit operation, whereby n indicates the number of Transmit operations provided within the ahead static segment and m the number of past minislots within the current dynamic segment. As in the static segment, a permitted interval is defined between the concrete start of the minislot and the Minislot ActionPoint Offset (see Configuration operation). The point in time at which a Bus Simulation shall provide operations, analogous to the static segment, depends on the DeliveryOnBoundary configuration parameter. If the configuration parameter is set to fmi3False, the Bus Simulation provides the respective operation directly after the calculated transmission time (see orange arrow in Bus Communication Points within dynamic segment.). If the parameter is set to fmi3True, the corresponding operations are only provided at the slot boundary (green arrow in Bus Communication Points within dynamic segment.).

Figure 9. Bus Communication Points within dynamic segment.

In sequence Provision and delivery of Transmit operations with an involved Bus Simulation. multiple transmissions of FlexRay frames within the dynamic segment are shown. At the beginning the internal slot counters of FMU 1 and FMU 2 are equal to 8. Within the first and the second minislot, neither FMU 1 nor FMU 2 wants to transmit a frame. After the second elapsed minislot the internal slot counter values of FMU 1 and FMU 2 are equal to 10. Subsequently this FMU 1 provides a Transmit operation to the Bus Simulation for a transmission that uses the dynamic segment and Slot ID = 10. After this the Bus Simulation provides the Transmit operation to FMU 2 and in the same step a Confirm operation for FMU 1. All in all the transmission will take two minislots. Minislot 5 expires without a Network FMU wanting to make a transmission again and the internal slot counters are set to 11. In minislot 6 FMU 2 initiates a transmission via Transmit operation for Slot ID = 12. Afterward, the Bus Simulation provides the Transmit operation to FMU 1 and in the same step a Confirm operation for FMU 2. This transmission will take three minislots.

Figure 10. Provision and delivery of Transmit operations with an involved Bus Simulation.

If no Bus Simulation is involved, the transmission always applies: The length of a dynamic slot is exactly one minislot, since the transmission duration is not taken into account.

Within a Network FMU the first valid point in time when a specified Transmit operation, with respect to the specified Slot ID shall be provided can be computed as

\$ T_{\mathrm{Tx}_{\mathrm{DynamicFirst}}}(t, i_{\mathrm{Cycle}}, i_{\mathrm{Slot}}) = T_{\mathrm{Tx}_{\mathrm{Static}}}(t, i_{\mathrm{Cycle}}, N_{\mathrm{StaticSlot}} + 1) + (i_{\mathrm{Slot}} - N_{\mathrm{StaticSlot}} - 1) \cdot L_{\mathrm{Minislot}}\$

, where:

• \$N_{\mathrm{StaticSlot}}\$ represents the number of static slots within one FlexRay cycle (see Number of Static Slots argument within the Configuration operation).

• \$i_{\mathrm{Slot}}\$ represents the specified Slot ID for transmission within the dynamic segment (see Slot ID argument of the Transmit operation).

• \$L_{\mathrm{Minislot}}\$ represents the length of a minislot within a dynamic segment in macrotick (see Minislot Length argument within the Configuration operation).

Within a Network FMU the latest valid point in time when a specified Transmit operation, with respect to the specified Slot ID shall be provided can be computed as

\$ T_{\mathrm{Tx}_{\mathrm{DynamicLast}}}(t, i_{\mathrm{Cycle}}, i_{\mathrm{Slot}}) = T_{\mathrm{Tx}_{\mathrm{Static}}}(t, i_{\mathrm{Cycle}}, N_{\mathrm{StaticSlot}} + 1) + \sum_{j=N_{\mathrm{StaticSlot}} + 1}^{i_{\mathrm{Slot}} - 1} L_{\mathrm{DynamicSlot}_j} \cdot L_{\mathrm{Minislot}}\$

, where:

• \$N_{\mathrm{StaticSlot}}\$ represents the number of static slots within one FlexRay cycle (see Number of Static Slots argument within the Configuration operation).

• \$i_{\mathrm{Slot}}\$ represents the specified Slot ID for transmission within the dynamic segment (see Slot ID argument of the Transmit operation).

• \$L_{\mathrm{DynamicSlot}_j}\$ represents the number of used minislots for transmission of dynamic slot j, where also idled minislots are considered.

• \$L_{\mathrm{Minislot}}\$ represents the length of a minislot within a dynamic segment in macrotick (see Minislot Length argument within the Configuration operation).

[It should be noted that \$T_{\mathrm{Start}}\$ is already taken into account in \$T_{\mathrm{Tx}_{\mathrm{Static}}}(...)\$ and doesn’t need to be considered a second time.]

This results in an interval in which a Network FMU shall provide a specified Transmit operation of

\$ T_{\mathrm{Valid}} = \left[ T_{\mathrm{Tx}_{\mathrm{DynamicFirst}}}(t, i_{\mathrm{Cycle}}, i_{\mathrm{Slot}}), \; T_{\mathrm{Tx}_{\mathrm{DynamicLast}}}(t, i_{\mathrm{Cycle}}, i_{\mathrm{Slot}}) + T_{\mathrm{ActionPoint}_{\mathrm{Dynamic}}} \right]\$

, where:

• \$T_{\mathrm{ActionPoint}_{\mathrm{Dynamic}}}\$ represents the minislot action point offset of a dynamic slot in macroticks (see Minislot ActionPoint Offset argument within the Configuration operation).

Error Handling

FlexRay provides extensive options for detecting bus errors. Overall, the respective bus errors affect the internal controller status within the Network FMUs. To maintain the internal controller status, Bus Error operations shall be provided to all relevant Network FMUs by the Bus Simulation. Depending on the type of Bus Error, either only the Transmit producing or all Network FMUs must be notified via Bus Error operation (see Overview of the available error flag values. for details).

Figure 11. Architectural error handling overview.