OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`OSEKIVDX
`
`Fault-Tolerant Communication
`
`Version 1.0
`
`July 24th 2001
`
`This document is an official release. The OSEK group retains the right to make changes to this document
`without notice and does not accept any liability for errors. All rights reserved. No part of this document
`may be reproduced, in any form or by any means, without permission in writing from the OSEKNDX
`steering committee.
`
`OSEKFTCom 1.0
`PAGE 1 OF40
`
`©byOSEK
`
`Docmnent: ftcomlO.doc
`
`BMW EXHIBIT 1010
`
`

`

`OSEKNDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`Preface
`OSEKIVDX is a joint project of the automotive industly. It aims at an indusny standard for an
`open-ended architecture for disnibuted conn·ol mlits in vehicles.
`
`For detailed infmmation about OSEK project goals and partners, please refer to the "OSEK
`Binding Specification".
`
`This document describes the concept of a fault-tolerant cmmnunication layer. It is not a product
`description which relates to a specific implementation. Tills document also specifies the fault-tolerant
`cmmmmication layer - Application Program Inte1face.
`
`General conventions, explanations of te1ms and abbreviations have been compiled in the additional
`inter-project "OSEK Overall Glossruy". Regarding implementation and system generation aspects
`please refer to the "OSEK Implementation Language" (OIL) specification.
`
`2
`PAGE20F 40
`
`© byOSEK
`
`OSEKFTCom 1.0
`
`

`

`OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`Table of Contents
`
`1
`
`Introduction ........................................................................................................................... 5
`1.1 System Philosophy .......................................................................................................... 5
`1.2 Purpose of this Document ............................................................................................... 6
`1.3 Structt1re of this Docrunent .............................................................................................. 7
`
`2 Srumnruy ............................................................................................................................... 8
`2.1 Architecnu·e of a OSEKtime System ............................................................................... 8
`2.2 Constraints on the FTCom and the underlying Co1mnunication Contr'Oller.. ..................... 11
`2.3 Message Exchange Inte1face ......................................................................................... 11
`
`3 Message Handling ................................................................................................................ 12
`3.1 Messages and Message Instances ................................................................................. 13
`3. 2 Message Copy Functions .............................................................................................. 13
`3.2 .1 Receiving Messages ................................................................................................ 13
`3.2.2 Sending Messages .................................................................................................. 14
`3. 3 Message Fnune Mapping ............................................................................................. 14
`3. 4 Packing/Unpacking Messages ....................................................................................... 15
`3.5 Byte Order ................................................................................................................... 16
`3. 6 Message Send StattlS .................................................................................................... 16
`3. 7 Notification Mechanism ................................................................................................ 17
`3. 8 Replication!R.edundancy ................................................................................................ 17
`3.9 Replica Detenninate Agreement (RDA). ........................................................................ 18
`3.9.1 Message RDA StattlS .............................................................................................. 18
`3.9.2 Exrunple: RDA "average" ........................................................................................ 19
`3.9.3 Exrunple: RDA "majmityvote" ................................................................................ 19
`3.10 Message Filter .............................................................................................................. 20
`3. 10. 1 Message Filter Flmction .... ...................................................................................... 20
`3. 10.2Message Filter Statt1s .............................................................................................. 22
`3.1 1 Ove1view Message Handling API ................................................................................. 22
`
`4 Other FTCom Functions ...................................................................................................... 24
`4.1 Time and Synchronisation Setvices ................................................................................ 24
`4. 1.1 AsSUinptions ........................................................................................................... 24
`4. 1.2 Require1nents .......................................................................................................... 24
`4.2 Extemal Clock Synchronisation ..................................................................................... 25
`4.2.1 Generation ofExtemal Conection Value .... .............................................................. 25
`4.2.2 W1ite Conection Value to Communication Contr·oller .............................................. 26
`4.3 Node Membership Setvice (optional) .............. .............................................................. 26
`4.4 Lifesign Update ............................................................................................................ 26
`4.5 Strut-up ........................................................................................................................ 26
`
`5
`
`Inter-task Co1nmunication .................................................................................................... 27
`5.1 Co1nmunication between OSEK Tasks .............................. ........................ ................... 27
`5.2 Co1nmunication between OSEK and OSEKtime Tasks ...... ........................ ................... 27
`5.3 Co1nmunication between OSEKtime Tasks ........................ ........................ ................... 27
`
`6 Specification ofFTCom System Se1vices .................................. ........................ ................... 28
`
`OSEKFrCom 1.0
`PAGE 3 OF 40
`
`© byOSEK
`
`3
`
`

`

`OSEKNDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`6.1 Conunon Data Types .................................................................................................... 29
`6.2 Nanling Conventions ..................................................................................................... 29
`6.2.1 General Nanling Conventions .................................................................................. 29
`6.3 Message Handling ......................................................................................................... 30
`6.3.1 Data Types ............................................................................................................. 30
`6.3.2 Constants ................................................................................................................ 30
`6.3.3 ttSendMessage ....................................................................................................... 30
`6.3.4 ttReceiveMessage ................................................................................................... 31
`6.3. 5 ttlnvalidateMessage ................................................................................................. 3 2
`6.3.6 Differences between OSEKtime and OSEKIVDX Message Management.. .............. 32
`6.4 Me1nbership Seivice ..................................................................................................... 33
`6.4.1 Data Types ............................................................................................................. 33
`6.4.2 Constants ................................................................................................................ 33
`6.4.3 ttGetNodeMe1nbership ........................................................................................... 33
`6.5 Notification mechanism ................................................................................................. 34
`6.5.1 Data Types ............................................................................................................. 34
`6.5.2 Constants ................................................................................................................ 34
`6.5.3 ttReadFlag .............................................................................................................. 34
`6.6 Time Seivice ................................................................................................................. 35
`6.6.1 Data Types ............................................................................................................. 35
`6.6.2 Constants ................................................................................................................ 35
`6.6.3 ttGetGlobalTilne ...................................................................................................... 35
`6.6.4 ttGetComSyncStatus ............................................................................................... 36
`6.6.5 ttGetSyncTilnes ....................................................................................................... 36
`6.7 Extemal Clock Synchronisation ..................................................................................... 37
`6. 7.1 ttExtClockSync ....................................................................................................... 3 7
`6.7.2 ttSetExtSync ........................................................................................................... 37
`
`7 Hillts .................................................................................................................................... 38
`7.1 Optional Prope1ties of the FTCom and the underlying Conununication Controller ........... 3 8
`
`8
`
`Index ................................................................................................................................... 39
`8.1 List of Se1vices, Data Types and Constants ................................................................... 3 9
`8.2 List ofFigures ............................................................................................................... 39
`8.3 List of Tables ................................................................................................................ 39
`
`9 Histo1y ................................................................................................................................. 40
`
`4
`PAGE40F 40
`
`© byOSEK
`
`OSEKFTCom 1.0
`
`

`

`OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`1 Introduction
`The specification of the fault-tolerant communication layer (FTCom layer) is to represent a tmifmm
`fimctioning enviromnent which suppo1ts efficient utilisation of resources for automotive control unit
`application software.
`
`1.1 System Philosophy
`The objective of the OSEKtime working group is to specify a fault-tolerant real-time operating
`system with a fault-tolerant communication layer as a standardised nm-time enviromnent for highly
`dependable real-time software in automotive electronic control units. The OSEKtime system must
`implement the following propetties:
`
`• predictability ( dete1ministic, a plimi known behaviour even tmder defined peak load and fault
`conditions),
`
`• clear, modular concept as a basis for cettification,
`
`• dependability (reliable operation through fault detection and fault tolerance),
`
`•
`
`suppmt for modular development and integration without side-effects ( composability), and
`
`• compatibility to OSEKIVDX OS.
`The OSEKtime operating system core offers all basic setvices for real-time applications, i.e.,
`intenupt handling, dispatching, system time and clock synchronisation, local message handling, and
`en or detection mechanislllS.
`
`All se1vices of OSEKtime are hidden behind a well-defined API. The application intetfaces to the
`OS and the communication layer only via this API.
`
`For a pruticular application the OSEKtime operating system can be configured such that it only
`complises the se1vices required for this application (the OSEKtime operating system is desclibed in
`the OS specification).
`
`that suppmts real-time
`layer
`OSEKtime also comptises a fault-tolerant colillnunication
`colillnunication protocols and systelllS. The layer offers a standardised intetface to the following
`communication setvices and featt1res: a global message handling se1vice ( complising replication and
`agreement suppmt, and transpru·ent access to the communication system), strut-up and reintegration
`suppmt, and an extemal clock synchronisation setvice.
`
`OSEKFrCom 1.0
`PAGE50F40
`
`© byOSEK
`
`5
`
`

`

`OSEKNDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`1.2 Purpose of this Document
`The following desctiption is to be regarded as a genetic desctiption which is mandato1y for any
`implementation of the OSEKtime FTCom layer. This conce1ns the general descliption of strategy
`and functionality, the inte1face of the function calls, the meaning and declaration of the parameters
`and the possible enor codes.
`
`The specification leaves a ce1tain ammmt of flexibility. On the one hand, the descliption is genetic
`enough for fhture upgrades, on the other hand, there is some explicitly specified implementation(cid:173)
`specific scope in the desaiption.
`
`It is assumed that the descliption of the OSEKtime FTCom layer is to be updated in the future, and
`will be adapted to extended requirements. Therefore, each implementation must specify which
`officially autho1ised version of the OSEKtime FTCom descliption has been used as a reference
`desc1iption.
`
`Because this descliption is mandatmy, definitions have only been made where the general system
`strategy is concemed. In all other respects, it is up to the system implementation to dete1mine the
`optimal adaptation to a specific hardware type.
`
`6
`PAGE60F 40
`
`© byOSEK
`
`OSEKFfComl .O
`
`

`

`OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`1.3 Structure of this Document
`In the following text, the essential specification chapters are descdbed bdefly:
`
`Chapter 2, Summruy
`Tills chapter provides a bdef introduction to the OSEKtime FTCom layer, gives a smvey about the
`interactions between OSEKtime layers and asSUlllptions on the conummication protocol.
`
`Chapter 3, Message Handling
`
`This chapter descdbes the message handling.
`
`Chapter 4, Other FTCom Functions
`Tills chapter describes the reconunended practice for implementing time se1vices, exte1nal clock
`synchronisation, membership se1vice, lifesign update and strut-up.
`
`Chapter 5, Inter-task Communication
`
`This chapter contains a descdption of the inter-task conununication.
`
`Chapter 6, Specification of FTC om System Services
`
`Tills chapter contains a description of the FTCom layer API.
`
`Chapter 7, Hints
`
`Tills chapter descdbes recommendations which are not prut of the specification.
`
`Chapter 8, Index
`
`List of all FTCom system se1vices, figmes and tables.
`
`Chapter 9, Histo1y
`
`List of all versions.
`
`OSEKFrCom 1.0
`PAGE70F40
`
`© byOSEK
`
`7
`
`

`

`OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`2 Summary
`The fault-tolerant communication layer (FTCom layer) is responsible for the interaction between the
`communication controller hardware and the application software. It provides the necessaty services
`to suppmt fault-tolerant highly dependable real-time distributed applications (e.g. strut-up of the
`system, message handling, state message intetface).
`
`The OSEKtime FICom layer is built in accordance with the usel's configuration insti11ctions at
`system generation time.
`
`2.1 Architecture of a OSEKtime System
`In a time-triggered system the application software uses the intetface provided by the operating
`system and by the fault-tolerance layer. The operating system is responsible for the on-line
`management of the CPUs resources, management of time and task scheduling. The FICom layer is
`responsible for the collllllunication between nodes, enor detection and fault-tolerance ftmctionality
`within the domain of the collllllunication subsystem.
`
`Figure 2-1 shows the architecttire of a OSEKtime system. Application software and FTCom Layer
`are executed under contr·ol of the operating system. OSEKIVDX Network Management (NM)
`desciibes node-related (local) and network-related (global) management methods. The global NM
`component is optional and desciibed in the OSEKIVDX NM specification.
`
`q ........
`
`Application
`
`II
`
`OSEKtime FTCom Layer
`,----~---, I
`r ------------ _j.,
`
`Application Layer
`
`•
`
`I
`
`Time
`Service
`
`1 Fault-Tolerant Subsystem
`
`1
`
`.~--~=~-::~.:_:~~::~-~~~~-f~--.
`I
`II-------------- - l
`··------------ -.-~
`:
`(
`Fault Tolerant Layer
`11
`- -------------~ - ~
`Communication Subsystemt
`
`OSEKNDX
`Network
`Management
`
`•
`
`f-1
`1..
`Interaction Layer
`~==~~==~~~ ~--~~
`I
`~
`CNI Driver
`
`Bus 1/0 Driver
`
`I
`
`Bus Communication Hardware
`
`Figure 2-1: Architecture of a OSEKtime system
`
`8
`PAGE 80F 40
`
`© byOSEK
`
`OSEKFTCom 1.0
`
`

`

`OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`Services of the FTC om Layer
`The Se1vices of the FTCom layer are listed below:
`
`• Global message handling
`
`- Replication and agreement
`
`- Message filte1ing
`
`- Communication controller communication network inte1face (CNI) access via CNI driver
`(incl. connections to multiple communication media, e.g., gateways)
`
`• Strut-up
`
`• Time se1vice and optional extemal clock synchronisation
`
`Layered Model of OSEKtime FTCom Architecture
`
`The layered model of OSEKtime FTCom architecture is shown in Figure b2. The OSEKtime
`FTCom system is divided into two subsystelllS:
`
`• Firstly the Fault Tolerant Subsystem that contains fault tolerant mechanisms; and
`
`•
`
`secondly, the Co1mnunication Subsystem that is responsible for the communication between
`distributed components.
`
`FTCom is also divided into layers:
`
`• Application Layer:
`- Provides an Application Programming Inte1face (API).
`
`• Message Filte1ing Layer:
`- Provides mechanislllS for message filte1ing.
`
`• Fault Tolerant Layer:
`
`- Provides se1vices required to suppo1t the fault-tolerant ftmctionality:
`
`• Provides judgement mechanisms for message instance management.
`
`• Suppmts a message status info1mation.
`
`•
`
`Interaction Layer:
`
`- Provides se1vices for the n·ansfer of message instances via network:
`
`• Resolves issues connected with the presentation of a message instance on different hosts
`(e.g. different byte orde1ing).
`
`• Provides a message instance packing/unpacking se1vice.
`
`• Suppmts a message instance statt1s info1mation.
`
`OSEKFTCom 1.0
`PAGE9 OF40
`
`©by OSEK
`
`9
`
`

`

`OSEKNDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`The CNI Dtiver is not prut of FTCom. It provides setvices for the transfer of FTCom fi:ames via
`network:
`
`• Resolves FTCom CNI fi:ames presentation issues.
`
`• Suppmts a FTCom fi:ame status infmmation.
`
`• Deals with a specific CNI access scheme of a pruticulru· implementation of the communication
`hru·dwru·e.
`
`Communication
`API
`
`OSEKtime OS
`Application
`
`.. ...
`
`OSEKtime FTCom Layer
`
`Application Layer
`.. -------- ___ ; ______ -----·
`! Message Filtering !
`L. ------.:~~:~------_l!
`r:;:~~=;~~;:~;;~;;;s~;;;·· ----1
`: i Fault Tolerant Layer ,i
`li
`~
`: :
`:
`:
`: :_ _____ --- ---------- ---- ~
`:
`~ ------------------------- - ---·
`
`I
`
`I
`
`I
`
`I
`
`I
`
`Conformity with
`OSI/ISO layer
`model
`
`Application
`Layer
`
`Data Link Layer
`
`,-----,
`1 Physical Layer I
`l _____ j
`
`Tolerated
`Message
`
`Message
`Instance
`
`FTCom Frame
`
`CNI Frame
`
`Bus Frame
`
`--~~·••••••••••••••••••••• -
`
`I
`
`'
`
`I
`
`I
`
`I
`
`I
`
`Communication Subsystem
`
`Interaction Layer
`
`CNI Driver
`
`~
`
`CNI
`
`Communication Controller
`
`r
`
`...
`
`...
`
`Figure 2-2: Layered model ofOSEKtime FTCom ru·chitecrure
`
`10
`PAGE 10 OF40
`
`© by OSEK
`
`OSEKFTCom 1.0
`
`

`

`OSEKNDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`the FTCom
`on
`2.2 Constraints
`Communication Controller
`Constraints on the FTCom and the llllderlying cmmnunication controller are:
`
`and
`
`the
`
`underlying
`
`• The fimdamental basis for real-time and time-niggered systems is a globally synchronised
`clock with sufficient accuracy. The globally synchronised clock must be accessible and it must
`provide means to generate programmable time-intenupts.
`
`• Error detection must be suppmted in the event of data cmmption. In addition the
`cmmnunication protocol must suppmt the detection of missing, late or early messages at the
`receiver(s) and the senders.
`
`• Time-triggered, periodic frame transmission is assumed for all messages handled by the
`FTCom layer. Other types ofn·ansmission must be handled implementation specific.
`
`• Defined Worst Case Start-up Time: The communication system must have a dete1rninistic
`worst-case stalt-up time.
`
`2.3 Message Exchange Interface
`The FTCom layer is based on a state message inte1face: the send operation ove1wtites the last recent
`valid message value, while read operations get the most recent value.
`
`The API calls "ttReceiveMessage ", "ttSendMessage ", and "ttlnvalidateMessage" (definition in
`section 6.3) are mandato1y and the standard way to consistently exchange data between application
`and the FTCom layer. No other message access is allowed for the user (programmer). Eve1y call
`causes a new consistent access of the FTCom inte1face.
`
`OSEKFfComl .O
`PAGE 11 OF40
`
`©by OSEK
`
`11
`
`

`

`OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`3 Message Handling
`The cmmmmication controller transmits frames typically consisting of a strut-of-fi:ame field, a
`header, a data field, and a CRC checksrun on the commlmication media. Each frrune can hold one or
`more application level messages in its data field. On the other hand, a message can be transmitted
`redlllldantly in more than one fi:rune on the colillmmication media. It is the main task of the FICom
`layer to handle this relationship and the transpo1t of messages between the application tasks and the
`commlmication network inte1face of the commlmication controller. The layout of a fi:ame is user
`specified.
`
`It might not be possible for the application tasks to use application messages in the representation as
`they ru·e transmitted on the commlmication media and as they ru·e also stored in the CNI:
`
`• They ru·e densely packed (i.e., not byte-aligned) to save commlmication media bandwidth,
`
`•
`
`their byte order might be different fi:om that of the receiver, and
`
`• messages might be transmitted redlmdantly, so that selection of one message or voting on a set of
`messages becomes necessruy.
`
`Therefore, each message sent or received by a node is stored exactly once and in the local CPU's
`representation in a dedicated memmy ru·ea lmder control of the host CPU. This memmy ru·ea is
`called the FT -CNI. From there it can be accessed by the application tasks. Consequently, there ru·e
`two representations of messages:
`
`• Firstly, a message is represented in the FI -CNI. This representation should match the
`requirements of the host CPU and is based on the state message concept. For exrunple, on a 16
`Bit CPU it will be optimal to represent a 10 bit analogue conversion result by a 16 bit word.
`
`• Secondly, a message is represented in frrunes as handled by the colillmmication controller. This
`representation should match the prope1ties of the commlmication controller. For exrunple, to
`utilise colillmmication bandwidth it is ideal to transmit only 10 bits of infmmation for a 10 bit
`analogue conversion result.
`
`Fruthe1more the FICom layer provides a systematic approach to apply different filter algo1ithms on
`messages transfened from the CNI to the FI -CNI and vice versa.
`
`The transpo1t between the CNI and the FT -CNI is handled by message copy tasks that ru·e
`invoked after reception of a fi:ame and before sending a fi:ame, respectively. Ideally, they ru·e prut of
`the time-tliggered task schedule. From what was said above it follows that the main job of a
`message copy task is (1) to do message alignment, (2) to conve1t between commlmication media
`and local byte order (endianness), (3) to select or vote on redlllldant messages, and (4) to filter
`messages.
`
`Figure 3- 1 shows the relationship between the CNI, the message copy tasks of the FTCom layer,
`the FT -CNI, and the application tasks. The CNI holds the data fields of all frrunes as they ru·e
`tl'311Smitted on the commlmication media. The message copy tasks of the FICom layer disassemble
`the received fi:ames and assemble the fi:runes to be sent, and copy the messages to and fi:om theFT(cid:173)
`CNI, where they can be accessed by the application tasks.
`
`12
`PAGE 12 OF 40
`
`© byOSEK
`
`OSEKFTComl.O
`
`

`

`OSEKNDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`Application Tasks
`
`ttSendMessage
`ttReceiveMessage
`
`FIComLayer
`
`Figure 3-1: CNI, Message Copy Tasks, FT -CNI, and Application Tasks
`
`3.1 Messages and Message Instances
`In the description above the te1m "message" was used for all entities, whether they reside in the FT(cid:173)
`CNI, the CNI or are transmitted on the commurrication media. To be more precise in the remainder
`of this specification the following notions of a message will be distinguished:
`
`Message:
`
`A block of application data (signals) stored in the FT-CNI. Messages, having
`the same name, can be sent by different nodes.
`
`Message Instance: One copy of a message stored in the CNI (transmitted on the commurrication
`system) at the sender. At the receiver these message instances may be used to
`generate a new single message, e.g., by using predefined agreement
`algmithms (RDAs).
`
`3.2 Message Copy Functions
`There are two types of message copy fimctions: the fimctions for receiving messages are different to
`the fimctions invoked before sending a message.
`
`3.2.1 Receiving Messages
`
`The message copy ftmction for receiving messages has to pe1f01m the following actions:
`
`•
`
`It first has to read all relevant frames from the CNI and do byte order ( endianness) conversion, if
`necessary. "Relevant 1i'ames" means all fi:ames that contain an instance of any message handled
`by this message copy task.
`
`• Evaluate fi:ame status fields and discar·d all fimnes with an invalid status.
`
`• For each message, a copy must be created fi·om a valid fimne by aligning the relevant portion of
`the fi·ame data field to suitable boundaries for the used CPU, and - if necessruy - masking out all
`parts of other messages.
`
`OSEKFfComl .O
`PAGE 13 OF40
`
`©by OSEK
`
`13
`
`

`

`OSEKIVDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`• This copy must be Wiinen to the FT -CNI.
`
`3.2.2 Sending Messages
`
`The message copy fimctions for assembling messages to be sent on the communication media must
`do the following:
`
`•
`
`It must read all messages to be transmitted fi:om the FT ~CNI.
`
`• For each fi.-ame, it must then align the message instances to their position in the fi.-ame data field,
`and then assemble the fi.·ame.
`• The byte order (endianness) must be convetted to the communication media byte order, if
`necessa1y.
`
`•
`
`• The fimction must then copy the assembled fi.·ame data field to the CNI.
`ill case of an event4iven communication system, the transmission of a fi.-ame is suppressed if all
`message instances of a fi.-ame have been invalidated by the application (i.e., contain an invalid
`send staniS (see Section 3.6)).
`
`3.3 Message Frame Mapping
`The communication controller transmits fi.-ames up to a cettain length. One fi-ame may contain one or
`more message instances. In order to support fault-tolet-ance one message is carried by one or more
`fi.-ames (i.e., one instance of the message per fi.-ame).
`
`number of
`channels
`
`Node 1 -----
`
`11111 m2 m3 m4
`frame_slot1_round1_chA
`lm6
`frame_slot1_round1_chB
`
`m5 ma m4
`
`frame_slot2_round1_chA
`
`frame_ slot2 _round 1_ chB
`
`Node2
`
`Node n
`
`-~ -
`1
`
`miL
`m11
`frame_slotn_round1_chA
`lm6
`frame_slotn_round1_chB
`
`m11
`
`I m4
`
`Figure 3-2: Example fi.-ame layout for a two-channel system
`
`number of nodes
`
`Figure 3-2 shows a configtn-ation of a system with two channels (chA and chB). Each fi.-ame is
`named based on the slot and rotmd number. The example shows a message ml which is transmitted
`by two nodes in slot 1 and slot 2 on two channels. Therefore message ml is mapped to four fi.-ames
`in one round.
`
`The message fi-ame mapping is static and is defined offline. The mapping between messages and
`fi.-ames adheres to the following rules:
`
`• One message is canied by at least one fi.-ame.
`
`• One fi.-ame canies 0 ... max_fi.-ame_size1 message instances.
`
`1 In units of bits
`
`14
`PAGE 140F40
`
`© by OSEK
`
`OSEKFTCom 1.0
`
`

`

`OSEKNDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`• One message is canied at most once in a fi.·ame (i.e., one fi.-ame does not contain more than one
`instance of the same message).
`
`Remark: It is possible that a fi.-ame is completely or prutially empty and thus rese1ves space for futtlre
`usage.
`
`3.4 Packing/Unpacking Messages
`If cost constr-aints require an optimal use of communication bandwidth, it is necessruy to pack
`messages into fi.mnes with bit gmnulruities. On the other hand, if communication bandwidth is not an
`issue, application messages can be tr-ansmitted unpacked.
`
`MESSAGE REPRESENTATION
`
`m1, 12b~
`
`m2, 10~
`
`m3, 8~
`
`m4, 2M
`
`15
`
`0 115
`
`0 17
`
`0 17
`
`0
`
`Frame with 6 byte length
`
`FRAME REPRESENTATION
`
`Figure 3-3: Example of direct message to fi.mne mapping
`
`For example, a 10 bit analogue/digital conversion result or StaniS bits could be represented in a fi.-ame
`only by the necessruy number of bits or by a fiill 16 bit value. The communication layer should
`provide the unpacked messages aligned with the CPUs word length (byte, word, long word) to
`optimise access independent of the message length.
`
`At the fi.·rune level there ru·e three types of message representation suppo1ted. A direct unpacked
`representation, a standru·d packed lineru· representation and an altemate packed representation (see
`Figure 3-3, Figure 3-4 and Figure 3-5).
`
`Below, for both packed representations it is shown in which way four 16 bit word aligned messages
`ru·e packed into a fi.-ame. The way a message is packed into fi.mnes is defined at system configuration
`phase.
`
`UNPACKED MESSAGE REPRESENTATION
`
`m1, 12M
`
`m2, 10bi1
`
`m3, 8bi1
`
`m4, 2bi1
`
`15
`
`0
`
`15 6 11
`
`0
`
`7
`
`0
`
`7
`
`0
`
`0 19
`
`0 17
`
`Frame with 4 byte lenQth, instead of 6
`
`PACKED REPRESENTATION
`
`Figure 3-4: Example for standru·d message to fi.mne mapping
`
`© byOSEK
`
`15
`
`OSEKFTCom 1.0
`PAGE 15 OF40
`
`

`

`OSEK/VDX
`
`Fault-Tolerant Communication
`Specification 1.0
`
`UNPACKED MESSAGE REPRESENTATION
`
`m1, 12M
`
`m2, 10bi1
`
`m3, 8M
`
`m4, 2bi1
`
`0
`
`7
`
`0
`
`7
`
`0
`
`7
`
`\
`0 111819810
`0 17
`0 17
`Frame with 4 byte length, instead of 6
`
`PACKED REPRESENTATION
`
`Figrn·e 3-5: Example for altemate message to frame mapping
`
`The standard message to fi:ame mapping must be suppo1ted; the altemate message to fi:ame mapping
`is optional.
`
`For messages with bit granularities the mapping has the following prope1ties:
`
`• One message maps to at least one fi:ame representation
`
`• One frame representation consists of at least one bit atTay
`
`3.5 Byte Order
`In heterogeneous clusters with different CPUs and different interoperable communication controllers
`it is impmtant to consider the byte order of the CPU (e.g., big or little endian) and on the
`communication media. The FTCom layer is responsible for the byte order conversion between the
`local CPU and the communication media.
`
`3.6 Message Send Status
`The sender must have a mechanism to present the validity state of a data value (for instance a
`sampled sensor value) to all nodes in the network. This can be realised, if the sender of a message
`can mru·k this value as invalid in the FT -CNI by a send status bit. The send status bit mechanism i