Open Source FlexRay Communication: Time Triggered OS and FlexRay Communication Middleware

Hiroyuki Hattori ⁺, Shuichi Ohnisi⁺, Akihisa Morikawa⁺, Ayumu Kataoka⁺, Kazuhiko Nakamura⁺⁺, Toshio Nakamura⁺⁺, Hiroaki Takada^*
+Witz Corporation, ⁺⁺Sunny Giken Inc., ^* Nagoya University

Abstract

In recent years, many process computers, called ECU (Electronic Control Unit), are used for automotive control and more accurate control is realized by their communication with each other. But as various devices and protocols are developed for ECU communication, it becomes difficult to connect ECUs with each other and verifying the systems that contain them is costly. Moreover if we use the present communication protocol for the next generation automotive control, it will exhaust the communication bandwidth that will be necessary in a few years. To solve these problems, we developed a set of software programs for FlexRay communication, which is considered the next de facto standard for automotive communication, and we will release our programs as open source software in near future.

For the programs mentioned above, we have decided to develop specifications for a time triggered real time operating system that is suitable for FlexRay communication middleware. This operating system has a special feature which manages both time triggered control and event triggered control. We do not know of other OSs with this feature, so we believe this specification is new.

1. FlexRay Communication

We introduce three consortiums related FlexRay here.

FlexRay Consortium¹ just releases FlexRay Communications System Specifications.

AUTOSAR³ is established by automakers and electronic equipment makers in order to make open architecture specification standard for automotive electronics. . They are discussing about the standard of using FlexRay communication.

JasPar is established by Japanese automakers and Japanese electronic equipment makers in order to develop network technology, middleware and basic software for automotive. They are discussing how to use product.

FlexRay will be de-facto standard for the next generation automotive communication protocol and the middleware of FlexRay will become one of the indispensable IP.

If you want to use FlexRay more efficiently, you would have to reconstruct the application structure from an event triggered type to a time triggered one, because FlexRay communication requires time triggered control. So this requires a time triggered operating system.

OSEK/VDX⁴, the standardization group for automotive electronics in Europe, has already released a time triggered operating system (OSEKtime) [1]. And many operating system developers in Europe have already developed OSEKtime OS. But, we don¡¯t think this specification is always suitable for automotive control.

2. FlexRay communication applications

We developed a set of programs that are compatible with FlexRay communication and run on TOPPERS/OSEK kernel5 that is based on the OSEK/VDX OS specification. The programs are modules described as follows:

• TTM (Time Triggered Module) manages trigger timing
• FlexRay-DRV (FlexRay Device DRiver) controls FlexRay devices
• FlexRay-NM (FlexRay Network Management) manages FlexRay communication protocols
• TT-COM (Time Triggered COMmunication) provides an API (Application Program Interface) with time triggered functions to application programs

Now our FlexRay communication software supports only M32C processor and physical FlexRay device that are supplied by RENESAS. But we are porting to various processors. For example, V850 processors (NEC electronics) and S12X processor (Freescale ).

At first we developed the software to evaluate FlexRay communication as research. Because, FlexRay communication specification didn¡¯t fix at that time and we didn¡¯t know the detailed specification of FlexRay. We developed FlexRay communication software not only for research of itself, but we also investigated the requirements and functions for communication system that were required for the next generation one. At last we realized requirements that an automaker was expecting practical function, performance and quality.

We decided to release from TOPPERS Project. TOPPERS License⁶ has no limit to utilization the software for products and selling products. It is one of the most flexible licenses.

We have already released these programs to members of TOPPERS Project[2] since the end of March 2006, and we will release them as open source software.

3. FlexRay communication functions and characteristics

FlexRay software can be divided roughly into three parts. The first is TT-OS (Time Triggered Operating System) that consists of TOPPERS/OSEK Kernel and TTM. The second is FlexRay communication middleware that consists of FlexRay-DRV, FlexRay-NM and TT-COM. The third is SG (System Generator), a tool to configure an application with those middleware programs and TT-OS.

SG is not run on the target system. So we will not explain it in this paper.

3.1 Function and characteristic of TT-OS

Time triggered control, that is very important to FlexRay communication, is realized by placing Time-Trigger Module on OSEK specification OS. We call this pair TT-OS.

Before designing TT-OS, we considered using OSEKtime in order to get efficient time triggered communication. But TT-OS¡¯s specification is quite different from OSEKtime.

Though OSEKtime provides time triggered control, it does not provide non time triggered control (event triggered control). Non time triggered control tasks should run during OSEKtime idol time on the OSEK/VDX.

TT-OS supports both time triggered control for FlexRay communication and non time triggered control. This is a result that we have investigated related to requirements from products that will use FlexRay communication.

As for TT-OS, time triggered control is realized by a TTM module on OSEK/VDX, and non time triggered control is realized by OSEK/VDX originally. Only OSEK OS API exists. As for OSEKtime, time triggered control is realized by OSEKtime itself and non time triggered control is realized by OSEK/VDX OS that should run during the idol time of OSEKtime. This approach requires two APIs. One is OSEKtime-API for time triggered control and the other is OSEK OS API for non time triggered control.

Under the TT-OS environment, automotive control is possible with only the OSEK/VDX OS. There are some advantages with this method.

• Small memory resources

TT-OS can do time triggered control only by appending TTM to OSEK/VDX OS.

	ROM		RAM
	CODE	DATA	DATA
TOPPERS/OSEK kernel	5,851	64	103
TTM	1,804	790	13

[unit: Byte]

Where TOPPERS/OSEK is implemented based on the OSEK/VDX specification.

• Portability of existing applications

To realize FlexRay communication without TT-OS, OSEKtime is only usable OS for time triggered control. Under OSEKtime environment, the existing application that run on OSEK OS must port from OSEK OS API to OSEKtime API in order to adapt limited environment on which non time triggered control can run only during idol time of time triggered one.

Under TT-OS environment, TT-OS can control both time triggered control and non-time triggered one.

The application can be controlled under an OSEK/VDX OS. So all existing applications do not need to change the time values of service routines and other parameters (difference between time triggered control and event triggered control). The application tasks can be designed with the priority base. Then, redesign and remake using the TT-OS is not required.

Application engineers don't need to select OS API, and can design in a similar way before and don't need to learn new OS API, because TT-OS environment is constructed by only a type of OS.

TT-OS has the same processing level as OSEK/VDX, which is an event triggered OS. Time triggered operating part (TTM-scheduler) runs as an interrupt service routine of the OSEK/VDX OS, and the main component of time triggered control runs as an OSEK/VDX task. In the OSEKtime environment, time triggered control runs as an interrupt service routine.

TTM scheduler, which runs in interrupt routine, can select interrupt level. Then it can be made no influence as much as possible.

Under the TT-OS, only the TTM-scheduler will request time triggered action from the OSEK/VDX OS. Therefore, application software can be a priority based design, and run well in operating systems. The starting order of TT-OS tasks is decided by depending on their priority regardless of time triggered or non time triggered control. It makes it easier to predict the timing of low priority tasks.

Under the OSEKtime environment non time triggered function, even if it is interrupt request, was interrupted by FlexRay communication function served by time triggered control.

I explain this case with using engine control.

Usually, many engine control system must synchronize with rotation of crankshaft to control engine. If the control system lose or loose control timing, the engine control misses fire or burning at part of exhaust. It might cause some environment problems and safety problems.

This event triggered control is realized by OSEK/VDX OS in engine control unit. If an engine control unit must use FlexRay to communicate each other under the OSEKtime environment, maybe OSEKtime will service both FlexRay communication and engine control system.

In this case, the engine control system can only be serviced during idol time of FlexRay communication. So it is difficult to control an engine with safety.

On the other hand, TT-OS can design task of priority in the entire system and important tasks can execute preferentially than time triggered tasks. As the result, it can do safety control in the entire system. This feature is the most different in other time triggered control OS.

TTM function was designed with reference of OSEKtime and OSEK OS specification. TTM has start of tasks function, call-back function and dead line monitoring function.

The call-back function can call voluntary function from among TTM scheduler. This function is not provided by OSEKtime, but OSEK OS specification has same function which can use call-back function from among service routine of OSEK OS. We decided to add call-back function to TTM.

This function is effective in which the delay is not permitted between start requests of tasks and actual start of tasks. (Because TT-OS¡¯s time triggered function control not in interrupts routine, TT-OS has a bit of delay time to service time triggered functions.) If use this function under the TT-OS environments, the call-back function must be limited execution time as short as possible. Because, the call-back function control from TTM scheduler that is running from among interrupt functions.

Time triggered function must synchronize with external clock, and TT-OS can activate tasks at specified timing. But time triggered tasks might not be finished within deadline or might not be completed to make sending messages by some influences. In this case, the fatal problem will occur in the system. To deal with such problems, TT-OS provides deadline monitoring function.

TT-OS checks whether some tasks, that need check, complete or finish within deadline time. If a task does not complete within deadline time, TT-OS provide a recover service which is designed by application engineers.

Time triggered function provides service in synchronized timing with external clock because TTM works in synchronized timing. As the result, things below are achieved.

• The correction processing of time can be omitted between internal clock and external clock, during state of normal communication.

• Between internal clock and external clock can be synchronized without the correction calculation, when it recovers from communication failure.

Obtain external clock timing

TTM obtains basic timing through the interrupt from external device. As TT-OS is developed to realize FlexRay communication, it uses FlexRay communication device timer interrupt to get basic time.

Some time triggered OSs have two timers. One is for external time, and another one is for internal time. Time triggered OSs manage them separately. For TT-OS, the external time is network time in FlexRay bus system and it is called ¡°global time¡±. The internal time is only used in processor and it is called ¡°local time¡±.

Most time triggered OSs must synchronize external time and internal time by resetting cycle offset or adjusting clock width rate. On such a system, cycle offset or clock width rate must be calculated each cycle, and those calculations usually need a lot of processor load

Therefore those OSs need a lot of processor load in each cycle start (or end) and much bigger timing jitter between cycle start and cycle end.

To solve those problems, TTM uses the method that occurs interrupt at specified cycle number and relative time in cycle. In this method, interrupt to activate time triggered tasks are requested at accurate time and it is not necessary to synchronize each cycle. On the other side, TT-OS becomes weak in portability because TT-OS depends on FlexRay device function. To minimize dependence, this function is realized by FlexRay device driver software. external network timer counter valuespecified start timeTime Trigger Module in TT-OS is started by interrupt and it starts TT task

• Method of synchronizing time and cycle

Under the normal state of FlexRay communication, TT-OS can service in expected time with using external device function.

But if some problem happens, the system gets into the error state and the system can¡¯t get external time from FlexRay device. In this case, FlexRay communication can¡¯t work. But some other functions should work. TTM provide another internal timer for other time triggered functions against the error state FlexRay communication .

To be specific, the intelligent timer in processor is used as internal timer. (The intelligent timer count up form zero to expire time. When it reaches expire time, interrupt arises and reset and restart the timer.)

TT-OS uses the method that is to set the cycle time of internal timer longer than global cycle time (default is 110% longer than global cycle time) and internal timer is reset by FlexRay device at start of cycle in state of normal communication.

With this method FlexRay device synchronizes internal timer to external timer without complicated calculation. And if communication failure happens, interrupt will arise from FlexRay device or it will be recognized as communication failure by catching interrupt of timer expiration from internal timer before cycle start interrupt from FlexRay device. Because, FlexRay cycle interrupt should reach earlier than interrupt of timer expiration.

If TT-OS detects any failure of FlexRay communication, TT-OS immediately switches from global timer to local timer.

In error state of FlexRay communication, time triggered functions should be serviced even if lack of timing accuracy. (Timing accuracy is not necessary for time triggered functions other than FlexRay communication).

The interrupt of cycle start is recovered by FlexRay device automatically after the FlexRay device synchronizes other FlexRay device node.

The synchronization mechanism of TT-OS is realized by timing difference between interrupt of cycle start and interrupt of internal timer. If the interrupt of cycle start arises within correction unnecessary period, it shall reset internal timer. Then synchronization between local timer (internal timer) and global timer (network timer) completes.

In TT-OS, as cycle time of internal timer and global timer are different, eventually interrupt of cycle start arises within correction unnecessary period. If cycle time of global timer and internal timer are same, interrupt of cycle start never arises within correction unnecessary period.

In addition, the feature of FlexRay use unit of cycle, which can use maximum 64 cycle in round, if the both execution cycle (FlexRay driver execution cycle and local time execution cycle) are not corresponding at time synchronize, it has problem to finish synchronization mode.

This cycle synchronization method use different width time between internal and external time and it synchronizes gradually. To provide this method for cycle synchronization, it can prevent skip execution cycle and time triggered function during correction mode.

Very few new C language functions for TTM are required.

TT-OS provides the new functions listed below to execute time triggered control.

TT-OS API

function	function name	comment
TTM starting request	ttmInitTTM
error hook	ttmErrorHook	hook is called when error occurred
startup hook	ttmStartupHook	hook is called when TTM module starts
network sync error hook	ttmNetworkNoSyncHook	hook is called when sync error occurred
network sync hook	ttmNetworkSyncHook	hook is called when sync established
network cycle start	ttmIntNetworkCycleSta
network interrupt notification	ttmIntNetworkTime£ò	called when time or cycle count meet designated value
network sync error	ttmIntNetworkCCF	called when sync error
getting network status	ttmGetSyncStatus
Getting network time	ttmGetNetworkTime
Getting cycle count	ttmGetActionCycleCou
Getting timer information	ttmGetTime

TT-OS realizes time triggered control with small resources and compact size comparing with conventional time triggered OS that based on OSE/VDX OS specification. And TT-OS has unique feature that can control both event triggered and time triggered functions.

3.2 Functions and characteristics of FlexRay communication middleware

Not only physical devices for FlexRay but also device driver programs for FlexRay devices are necessary for good FlexRay communication.

FlexRay middleware must provide common functions that are used by FlexRay applications. In addition, the middleware have functions that manage Wake up / Sleep function and state of connection on FlexRay bus of own node, because each nodes connect FlexRay bus and node must consider each other state of other nodes.

The programs developed are as follows:

• FlexRay-DRV (FlexRay device DRiVer)

This controls FlexRay physical devices. It is composed of some service routines and depends on the makeup of the physical device.

FlexRay communication driver has general function same as general device driver. FlexRay device driver also need unique function. for example.

• Notify function to synchronize network time
• Interrupt of cycle start
• Notify interrupt of non synchronization

As described in chapter 3.1, TT-OS needs those FlexRay device driver functions to realize synchronization between FlexRay timer and internal timer. As a result, TT-OS strongly depends on this device driver.

• TT-COM (Time Triggered COMmunication)

TT-COM is communication middleware that matches TT-OS. And this middleware referred to OSEK/VDX Communication Version 3.0.3 [3] (OSEK COM) and OSEK/VDX Fault-Tolerant Communication Version 1.0 [4] (OSEK FT-COM) that are released by OSEK/VDX.

TT-COM functions are filtering control, queue control, packing and unpacking messages, changing endean, and checking communication blackouts and control parameters from applications. TT-COM is also an API for notification of communication status.

This API provides some service routines. An application using FlexRay communication can control receive and send message with those service routines.

function	function name	comments
send message	ttSendMessage
receive message	ttReceiveMessage
send message frame	ttSendFrame	copy send frame
receive message frame	ttReceiveFrame	copy receive frame
TT-COM initialize	ttInitCOM
TT-COM initialize buffer	ttInitBufferCOM
TT-COM getting status	ttReadFlag	read flags
TTCOM cyclic task	ttTickCOM	check communication condition
getting FIFO framett	ReadFifo

The filter control function sets sending/receiving condition. With this condition sending/receiving timing is controlled, when data is active or data is changed (current sending data changed from previous sending data).

As the result, using FlexRay application can send to TT-COM just making time in application (do not need actual sending time on FlexRay bus). TT-COM must decide receiving and sending time by make reference to filter condition.

The Que control function save sending/ receiving data to data storage buffer to protect losing data from overwrites during short term.

Unit of communication in FlexRay is called ¡°slot¡±. The unit can keep variable information.

Most slots data is made by various parts of application and those data are packed in slots to send. If each application has same packing function, it must merge to port other system or to integrate with each other.

This packing method is called ¡°packing function¡± and taking out data from slot is called ¡°unpacking function¡±.

And then, the endian connected FlexRay bus node is diverse one. Each node need to change endian from own node endian to FlexRay bus endian at sending or from bus endian to own node endian at receiving.

We developed TT-COM specification reference from OSEK COM specification [3] and OSEK FT-COM specification [4] released by OSEK/VDX

• FlexRay-NM (FlexRay Network Management)

4. System requirements and development environments

Currently TT-OS and FlexRay communication middleware support M32C processors that are manufactured by RENESAS. We use a compiler (NC308 version 5.20 Release 02) and a debugger (KD308 Version 3.3 Release 1) supplied by RENESAS as development environments. In addition, we use an emulator (M3A-0655 FoUSB) for debugging that is also supplied by RENESAS.

5. About products

We developed the ¡°Full X-by-wire electronic cart⁸¡± using this TT-OS and FlexRay communication middleware. And we have already done proof experiment for FlexRay technology, fault tolerance of FlexRay communication and realizing both ¡°event triggered function¡± and ¡°time triggered function¡± in same time.

We have already exhibited those software and demonstration in ESEC2006, ET20059, FlexRay Product Days10 to appeal it¡®s effectiveness.

6. Appreciation

We have received much advice from automaker specialists and their suppliers. Especially Mr. Hosotani (TOYOTA MOTOR CORPORATION) offered valuable support during our development of TT-OS and FlexRay communication middleware. We mention special thanks here.

Bibliography

[1] OSEK/VDX£¬OSEK/VDX Time-Triggered Operating System Version 1.0 £¬OSEK VDX£¬July 24th 2001

[2] TOPPERS Project¡¯s WEB site

[3] OSEK/VDX£¬OSEK/VDX Operating System Version 2.2.1 £¬OSEK VDX£¬January 16th 2003

[4] OSEK/VDX£¬OSEK/VDX Communication Version 3.0.3£¬OSEK/VDX£¬July 20th 2004

[5] OSEK/VDX£¬OSEK/VDX Fault ¨CTolerant Communication Version 1.0£¬OSEK/VDX£¬July 24th 2001

[6] WITZ inc. , TT-OS Stage-1 specification version 1.0 , November 2005

[7] Sunny Giken inc. , TT-COM module specification for FlexRay communication Rev 1.01 , October 2005

¹ Making specification for FlexRay communication

³ Automotive Open System Architecture 

⁴ Open System and the corresponding interfaces for automotive electronics / Vehicle Distributed executive

⁵ We developed this OS. This OS has already released as open source software.

⁶ http://www.toppers.jp/license.html

⁸ http://techon.nikkeibp.co.jp/article/NEWS/20060704/118830/

⁹ Embedded system expo & conference in Tokyo http://www.reedexpo.co.jp/ESEC/

¹⁰ http://www.hanser.de/seminare/index.asp?fz_id=2521814468-81&task=010