オープンソース FlexRay 通信：TimeTriggered OS と FlexRay 通信ミドルウェア( 第 8 回 IP アワード応募書類 特徴の説明書 )服部博行† 大西秀一† 森川聡久† 片岡歩 中村和彦‡ 中村俊夫‡ 高田広章◆
†株式会社ヴィッツ ‡株式会社サニー技研 ◆名古屋大学情報科学研究科
E-mail: †{hat,ohnishi,morikawa,kata}@witz-inc.co.jp, ‡{nakamura.kazuhiko,nakamura.toshio}@sunnygiken.co.jp ◆hiro@ertl.jp

1. FlexRay 通信とシステム LSI
FlexRay通信はFlexRayコンソーシアム1により仕様策定された，

FlexRay 通信対応の目的は，次世代車両通信として利用が見込
める通信であるにも関わらず，その詳細仕様などの決定が遅く，ど先進自動車アプリケーション向けの通信規格である．
欧州の自動車のような想定で利用するべきか不明な点が多いため，現在までに決メーカや自動車部品メーカを中心に自動車の電子アーキテクチャ

定している仕様を元に，車両への適応検証などの研究用途として評のオープンな標準を作成するために設立された AUTOSAR2にお価することである．ただし，単なる研究用途だけでなく，現世代通いても，FlexRay 通信を用いた標準化が検討されており，次世代

信の置き換えとしての利用を模索するために，
現状の自動車メーカの自動車通信分野において欧州ではデファクトスタンダードになが利用している通信システムへの要求/機能を調査し，さらに，自りつつある．さらに日本国内においても，日本の自動車メーカが中動車メーカが FlexRay 通信に期待する要求事項などを盛り込み，心となり，自動車制御システム向けのネットワーク技術，ミドルウ

製品適応に対応できる機能，性能，品質を実現している．また，ェア，ソフトウェア基盤等を協調して開発するために設立された

FlexRay コンソーシアムに参加している半導体メーカから

JasPar3で製品への適応方法等について検討を開始し始めている．

FlexRay 通信の特徴や FlexRay デバイス情報の提供を受け，現在

このように，FlexRay 通信は，次世代の自動車制御装置においてのデバイス機能を“素直”に利用して実現している．これは，今後必要不可欠な通信であり，その通信ミドルウェアは自動車開発に不FlexRay コンソーシアムで仕様検討が進み，仕様変更が行われた

可欠な IP ( ソフトウェア設計資産 ) の一つであるといえる．

場合でも柔軟に対応できるように留意したためである．

FlexRay 通信を効率よく利用するためには，従来の制御で広くこれらのソフトウェア部品は，TOPPERS プロジェクト6から利用されていたイベント駆動型からタイムトリガ型の制御に変更

2006年1月中旬よりTOPPERSプロジェクト会員向けに早期リリする必要がある．そのため，利用するオペレーティングシステムはースし，最終的にオープンソースソフトウェアとして公開する予定

タイムトリガ制御に対応する必要がある．

である．研究用途や組込み利用を想定して，これらのソフトウェア

欧州の自動車メーカが中心となり自動車制御用基盤ソフトウェ

部品は，フリーソフトウェアとしても特に柔軟な TOPPERS ライ

アの標準仕様を策定する OSEK/VDX4では，タイムトリガに対応

センス7による配布とし，製品への利用，販売等に制限を与えない．

したオペレーティングシステム仕様[1]を策定し，欧州を中心とし

3. FlexRay 通信対応の機能および特徴た多くのオペレーティングシステムベンダがこの仕様に準拠した

本 FlexRay 通信対応ソフトウェアは大きく 3 種類に大別するこ

オペレーティングシステムを開発しているものの，
自動車制御装置とが出来る．一つは TOPPERS/OSEK カーネルに TTM と呼ぶタへの適応には問題点も含まれている．

イムトリガ処理を実現するミドルウェアを組み合わせた TT-OS

2. FlexRay 通信対応の概要( Time Triggered Operating System ) ，二つ目は FlexRay デバイ

FlexRay 通信への対応には，
OSEK/VDX OS 仕様[2]に準拠したスドライバ，FlexRay-NM，TT-COM から構成される FlexRay 通

TOPPERS/OSEK カーネル5上で稼動する TTM (Time Triggered

信ミドルウェア，三つ目は，これらのミドルウェアおよびアプリケ

Module ) ，FlexRay デバイスを制御する FlexRay デバイスドラーションをオペレーティングシステムと接続するコンフィグレー

イ バ ， FlexRay 通 信 管 理 を 行 う FlexRay-NM(Network

ションツールである SG (System Generator ) である．このうち，Management)およびタイムトリガ処理に対応しアプリケーション

三つ目の SG は静的なコンフィグレーションを行うものであり，タと の イ ン タ ー フ ェ ー ス を 担 う TT-COM ( Time Triggered

ーゲット上では稼動しない開発ツールに分類されるため，
本説明かCommunication ) などのソフトウェア部品を利用し実現する．

ら除外する．

ターゲット環境として，現時点では，ルネサステクノロジ社のM32C プロセッサおよび同社製の FlexRay デバイスをサポートしているが，他に NEC 製，フリースケール製などの各種プロセッサへのポーティングが進行中である．

3.1 TT-OS の機能および特徴
FlexRay 通信を実現する上で重要となるタイムトリガ処理は，
OSEK 仕様 OS にタイムトリガモジュールを追加して実現し，本構成では TT-OS と称する．すなわち，TT-OS = OSEK OS + TTMとあらわすことができる．

1

欧州の自動車メーカ，電装部品メーカが中心となり次世代車両通信仕様を策定する団体 http://www.flexray.com
2 Automotive Open System Architecture http://www.autosar.org/
3 Japan Automotive Software Platform Architecture

TT-OS は，OSEK/VDX が，タイムトリガ通信を実現するために仕様策定した OSEK/VDX Time-Triggered Operating System( 以下 OSEKtime )[1] を参考にしているが，最終的な仕様は大き

http://www.jaspar.jp

く異なっている．すなわち，OSEKtime はタイムトリガ処理を実

4 Open System and the corresponding interfaces for automotive

現することを目的とし，
非タイムトリガ処理はタイムトリガ処理を

electronics / Vehicle Distributed executive
http://www.osek-vdx.org/
5 応募代表者らが 2004 年に開発した OSEK OS 仕様に準拠したリアルタ

イムカーネル．現在オープンソースソフトウェアとして一般公開中

6 http://www.toppers.jp/
7 http://www.toppers.jp/license.html

実行していない空き時間を利用してサービスを提供する．一方，

OS の割込みレベルで実現している．この割込みレベルで実行する

TT-OS の仕様は，タイムトリガ機能を利用した，FlexRay 通信機

TTM スケジューラは，イベントドリブン処理に影響を極力与えな能を実現することを目的としているものの，FlexRay 通信と非タいよう割込みレベルも任意設定とし，TTM スケジューラ内ではタイムトリガで実行するべき制御処理を両立することに注力していイムトリガ処理本体を実行しない ( OSEKtime は割込み処理内

る．この仕様の違いは，自動車メーカが FlexRay 通信の利用を想でタイムトリガ処理本体を実行する ) ．すなわち，TTM スケジュ

定している製品を複数選定し，製品適応時に必要となる機能およびーラはOSEK/VDX OSにタイムトリガ処理に必要な処理要求を発性能を明確にした結果である．そのため，TT-OS の機能および特行するのみである．これにより，アプリケーション設計者は，タイ

徴は，OSEKtime との比較を行うことにより明確となる．

ムトリガタスクおよび非タイムトリガタスクの動作順序が優先度

TT-OS のタイムトリガ機能は，TTM を OSEK/VDX OS 上で稼

ベースとなり，
重要な処理は優先度を高くすることによりシステム

動させることにより実現している．一方 OSEK/VDX が提唱するとして動作を保障することができる．また，優先順位を設計者自身

方法は，タイムトリガ処理はタイムトリガ機能を提供するが決定できるため，低優先度タスクの遅延時間予測も容易になる．

OSEKtime で実現し，非タイムトリガ処理は，OSEKtime のア
イドル処理時にサービスを提供する ( 通常，アイドル処理に
OSEK/VDX OS を利用する )．

TT-OS
TT-OS
OSEK/VDX OS Ver2.2.1

ISR Category
Category 1
Conform
Conform to
to ISR1
ISR1 ofof OSEKOSEK OS
OS

Interrupt level
CONFORM
CONFORM TO:
TO:
Interrupt
Interrupt level
level ofof OSEKOSEK OSOS

TTM
TTM
Scheduler
Scheduler

ISR
ISR Category 2
Conform
Conform to
to ISR2
ISR2 ofof OSEKOSEK OSOS

Applications②

Time
TriggerModulehigh① OSEK OS-API② OSEKtime -API

Applications①

Priority①

OSEK OS Scheduler

OSEK/VDX OS
Version2.2.1

Conform
Conform to
to Scheduler
Scheduler ofof OSEKOSEK OSOS

OSEK/VDX Time-Triggered OS(OSEKtime)

Task Level

OSEK Task
OSEK Task
TT Task

Conform
Conform to
to Task
Task level
level ofof OSEKOSEK OSOS

CPU

TT-OS構成図CPU

参考：OSEKtime構成図

TT-OS を利用した場合のソフトウェア構成では，OS はLow

TT-OSプロセッシングレベル図

また，TT-OS は，OSEKtime では対応が難しいとされるタイム

OSEK/VDX OS のみで実現できるため，以下の優位点がある

トリガ処理と非タイムトリガ処理の両立が可能である．すなわち，・ 小メモリリソース

OSEKtime 環境下では，OSEK/VDX OS の非タイムトリガ処理

TT-OS はOSEK/VDX OS に TTM を組み合わせて実現するたはタイムトリガ処理の要求がないアイドル時間でのみサービスがめ，タイムトリガ機能を実現するにあたり，TTM モジュール提供される．そのため，これら非タイムトリガ処理は，たとえ割りの追加のみで可能となる．

込み処理要求であったとしても，タイムトリガで実現される[単位:Byte
ROM
RAM
CODE
DATA
DATA
5,851
64
103
TOPPERS/OSEKカーネル
TTM
1,804
790
13
※TT-OSはTOPPERS/OSEK + TTM で算出可能※計測はルネサス製コンパイラを利用し，対象CPUはM32C

・ 既存アプリケーションの移植性
FlexRay 通信を利用する場合，今まではタイムトリガを提供するのは OSEKtime のみであり，これらの通信を利用する場合
は，例え OSEK/VDX OS 上で稼動しているアプリケーション
であっても OSEKtime への移植，もしくは，OSEKtime のアイドル時間に動作する制限のある環境に適応させる必要があった．本 TT-OS はイベントドリブン処理とタイムトリガ処理が共に OSEK/VDX OS に準拠した OS 上で稼動するため，
サービスルーチンの変更や時間的制約を受けることが無く，従来同様の優先度ベースによるタスク設計をすることが可能となるため，新たに移植もしくは適応作業を必要としない．
すなわち，OS が 1 種類のみの実装で実現しているため，アプ
リケーション設計者は OS を使い分ける必要がなく，従来同様の設計ポリシーが継承でき，新たにOS を習得する必要がない．
これらの優位点に加え，OS 構成上の特徴としてプロセッシング
レベルが他のタイムトリガを提供する OS と比べて特徴がある．すなわち，TT-OS のプロセッシングレベルは，イベントドリブン OSである OSEK/VDX OS のプロセッシングレベルを踏襲し，タイムトリガ処理要求部 ( 以下，TTM スケジューラ ) を OSEK/VDX

FlexRay 通信により阻害されることとなる．この問題点を，エンジン制御を例にして説明する．
通常エンジン制御はクランク軸の回転に同期して処理を実行する必要があり，タイミングを逃すと失火や排気部位での燃焼などとなり，安全性や環境上問題となる．通常
これらのイベント処理は OSEK/VDX OS で実現する．このエンジン制御で用いる情報交換にOSEKtime環境でのFlexRay通信を利用した場合，FlexRay 通信は OSEKtime でサービスされる．すな
わち，OSEK OS 上で稼動するエンジン制御は，OSEKtime 上で稼動する通信制御のアイドル時間に実行されることとなり，
正しくエンジンを制御することは難しい．一方，TT-OS はシステム全体で処理の優先順位を設計者が指定することが可能となり，必要な処
理はタイムトリガ処理より優先的に実行することができ，システム全体で安全に制御することができる．この特徴が TT-OS の最大の特徴であるといえる．
TT-OS を構成する TTM 機能は，OSEKtime 仕様およびOSEK/VDX OS 仕様を参考にし，タスク起動要求の他に，コールバック関数機能，デッドラインモニタリング機能を実現した．
コールバック関数機能は，TTM スケジューラ内からコールバッ
ク関数の呼び出しを実行することができる．この機能はOSEKtime には見られないが，OSEK/VDX OS のサービスルー
チン内からコールバック関数を呼び出す機能があるため，TTM の機能に加えた．
これはタイムトリガタスクが起動要求されて起動されるまでの遅延が許容されない場合などに有効であるが，TTM ス
ケジューラは割込み処理であるため，割込み処理内からのアプリケーション関数を呼び出こととなり，短い処理に限定して利用しなければならない．

タイムトリガ機能の特徴として，ある種のサービスを外部時間にたとおり，所望とするタイミングを外部時間タイマから取得す

同期して実行する必要があり，
タイムトリガ処理部のタスク起動処るため，正確な時間を取得できる．しかし，何らかの問題 ( ス

理により，所望とするタスクを起動することができることは前述でタートアップ時や障害等 ) が発生すると，通信エラー状態と説明した．しかし，所望とするタイミングでのタスク起動が実現でなり，外部時間が得られなくなる．この様な場合，例え通信がきたとしても，
何らかの影響により指定時間までに処理が完了してできなくても，プロセッサ内部で処理をする必要がないとは判いない，もしくは情報が作成されていない場合にシステムとして致断できない．この様な場合を想定し，TTM 内部に内部時間作

命的な問題が発生しないよう，
デッドラインモニタリング機能を実成用のタイマを常に稼動させておき，障害時の対応を行う．具

現した．TTM スケジューラで静的に決められた情報により指定タ

体的には，プロセッサ内部のインテリジェントタイマ ( タイ

スクが完了しているかをモニタし，未完了の場合は，設計者が意図

マ値 0 からカウントアップし，指定タイマ値になると，タイ

したミス処理を実行する．

マ満了割込みを発生し，タイマ値を初期化して，再スタートとタイムトリガ機能は，外部時間に同期して処理をする事であり，なるタイマ ) を用いて，内部カウンタを動作させる．この時，

本 TTM では，処理するべき時刻を外部機器から提供される時刻をタイマ満了値を外部時間周期より長く設定 ( デフォルトではそのまま利用した．その結果，TTM 内部で時刻補正処理を省くこ

外部周期の 110% ) し，正常時は FlexRay デバイスからのサイとを可能し，同時に，通信同期がずれた場合の同期方法も，補正計

クル開始割込みにより，タイマ値を初期化する．この初期化が算をすることなく同期させる手法も考案した．

内部時間の補正となり，サイクル毎の複雑な演算を必要として・ トリガ時刻取得

いない．また，仮に同期ずれなどの通信障害が発生した場合は，TTM が利用する基本となる時間は，外部からの割込みにより

FlexRay デバイスから通知されるエラー割込みを捕らえる，も取得する．本 TT-OS は，FlexRay 通信機能を実現するためにしくは FexRay デバイスから発行されるはずのサイクル開始

開発したため，基本時間を得る割込みは FlexRay 通信用デバ

割込みが通達される前（もしくは通達なし ） にインテリジェ

イスのタイマを利用する．多くのタイムトリガ機能を提供する

ントタイマの満了割込みを確認した場合は，即座に利用するタ

OS は，外部時間（ FlexRay の場合は，外部ネットワーク時間

イマをプロセッサ内部タイマに切り替える．このように通信エをさし，グローバル時間を呼ぶ場合が多い ）と内部時間 ( プラー状態であっても，同期通信時ほど正確なタイミングでは無ロセッサ内部の時間をさし，ローカル時間と呼ぶ場合が多い )いが，処理の継続を可能とする ( 通信が行われないため，正を別々に管理し，外部時間と内部時間の差を周期的に計算して，確なタイミングは不要である )．

周期開始時のオフセット処理やクロックの伸張などで外部時

時間同期は，FlexRay デバイスが他のノードと同期が完了する

間と内部時間の補正を行う．このような場合，周期的に処理負と，正常時同様にサイクルの開始割込みが発生する．この割込荷の多いオフセット計算や比例計算をしなくてはならない．そみと内部時間を比較し，補正不要と判断した時点で内部タイマのため，周期タイミングでの処理負荷や周期内での起動誤差を初期化して時間の同期が完了する．ここで重要となる点は，（周期のはじめと終わりなど）が大きくなる傾向が考えられる．

外部時間周期と内部時間周期が同じである場合，両者の周期開

これらの問題点を解決するために，本 TTM では，FlexRay デ

始タイミングは縮まらない．この解決方法として，前述した内

バイスに指定サイクルの指定時間に割込みを発生させる方式

部周期時間を外部周期より長めに設定し，補正不要領域に入らにした．この方式を利用することにより，タイムトリガタスクない部位での外部周期開始は無処理とし，外部周期と内部周期の起動トリガとなる割込みは正確にプロセッサに伝達され，かの時間差を利用して，外部時間と内部時間を同期させる．

つ，周期毎の補正処理が不要となる．反面，FlexRay デバイス

TTモジュール Timerの切り替え制御の機能を利用することにより，FlexRay デバイス仕様と密接に（前提：同期時と非同期時でTT-モジュールの１サイクル周期が異なる）■FlexRay timer(T0)（ネットワーク時間）

1ｻｲｸﾙ周期5ms

c

サイクルスタート割込みにてTT-タイマのカウンタ値をRead
c
c

c

c

なる問題が発生する．この問題点への対応として，国内半導体メーカの FlexRay デバイスを調査した結果，すべての半導体メーカが同一サプライヤからデバイスの供給を受けており，国■TT-タイマ1．補正不要判断：c min以上

バイスドライバで対応することにより，TTM への影響を最小

補正不要
領域
m
c

m・・補正時の最大通信サイクル時間（c基準10％)B
c max・・FlexRayの最大通信サイクル時間（c+30us）

max

c・・FlexRayの理想通信サイクル時間
c min ・・FlexRayの最小通信サイクル時間（c-30us）c min c

内での利用は問題にならないことと，仮に海外半導体への対応でデバイス機能の利用ができない場合であっても，FlexRay デ

補正領域

m

FlexRayタイマへ切り替え
2．位相補正必要
判断：c min未満

c max
c min cmc max
c min cm

c min以上になるまで補正

c max
c min cmm

FlexRayタイマへ切り替え

限に抑えている．
さらに，FlexRay の特徴として，64 周期で 1 つのラウンドとカウンタ値して扱うため，周期の開始が内部と外部で一致したとしても実TT-OS内のタイムトリガ処理実行モ
ジュール（割込みで実行）が起動され、TT-Taskの起動を要求する

行しているサイクルが一致していないと問題がある．このサイ
外部ネットワークタイマ等

クルの同期も前述した周期時間差を利用し，徐々に時間およびサイクルを合わせる．この方式を提供することにより，サイク
ル抜けやタイムトリガ処理の抜けを防止することができる．
このような特徴を持ちタイムトリガ処理を提供する TTM は新指定起動時間・ 時間およびサイクルの同期方法
FlexRay 通信が正常に通信を行っている場合は，前述で説明し規に追加したサービスルーチンは驚くほど少ない( OS としてのサービスは OSEK/VDX OS の API で提供 ) ．以下に TT-OS( TTM ) にて新たに提供したサービスルーチンを列記する．

機能

API名称

TTMの動作開始指令

ttmInitTTM

エラーフックttmErrorHook

スタートアップフック

ttmStartupHook

ネットワーク同期ずれフック

ttmNetworkNoSyncHook

ネットワーク同期フック
サイクルスタート通知

ttmNetworkSyncHook
ttmIntNetworkCycleStart

ネットワーク割込み通知

ttmIntNetworkTimeｒ

ネットワーク同期ずれ通知
ネットワーク状態取得
サイクルカウント、クロック取得
TTM実行中サイクルカウント取得
利用中のタイマ情報取得

ttmIntNetworkCCF
ttmGetSyncStatus
ttmGetNetworkTime
ttmGetActionCycleCount
ttmGetTime

備考
エラー発生時に呼び出される
フックルーチン
TTM動作開始時に呼び出されるフックルーチン
ネットワーク同期から外れた場
合に呼び出されるフックルーチ
ネットワーク同期時に呼び出されるフックルーチン
指定サイクル、指定クロック時に呼び出される
ネットワーク同期ずれ検出時に呼び出される

TT-COM は ， 3.1 章 で 説 明 し た TT-OS に 対 応 し たCommunication ミドルウェアであり，OSEK/VDX が規定した OSEK/VDX Communication Version 3.0.3 [3] ( OSEKCOM ) ， OSEK/VDX Fault-Tolerant Communication
Version 1.0 [4] (OSEK FT-COM ) を参考に TT-OS 仕様を考
慮して仕様策定した通信用データ処理ミドルウェアである．主な機能とし，フィルタ制御，Que 制御，メッセージのPack/UnPack 制御，エンディアン変換，通信途絶チェックなどを持ち，アプリケーションから直接指令を受け，また通信状
態を返却する I/F 部を受け持つ部位である．

以上の説明から明確なように，TT-OS は軽量コンパクトにタイ

この I/F 部には複数のサービス関数を用意しており，アプリケ

ムトリガを実現し，従来の OSEK/VDX OS を最大限利用したリアーションからは以下の関数で送信・受信制御を行うことができ

ルタイム OS であると言える．また，タイムトリガ処理とイベン

る．

ト処理のどちらも対応できるため，OSEKtime と比較して応用範

機能

API名称

囲が広く，利用しやすく，移植性が高い特徴があり，ソフトウェア

メッセージ送信
メッセージ受信ttSendMessage
ttReceiveMessageの部品化を支援する基盤ソフトウェア部品である．

フレーム送信実行処理

ttSendFrame

3.2 FlexRay 通信ミドルウェアの機能および特徴
FlexRay 通信を実現するためには，物理的なデバイス提供が必要であるばかりではなく，そのデバイスをソフトウェアで制御する
デバイスドライバが必要となる．また，アプリケーションの負荷を軽減するために，FlexRay 通信を利用するアプリケーションが共通に必要となるデータ処理部位をミドルウェア機能に用意するべきである．さらに，FlexRay 通信は LIN 通信等と異なり，各ノー
ドが FlexRay バスに接続されているノードを意識する必要があり，
バス上ノードの接続状況や Wake Up/Sleep を管理する機能もミ
ドルウェアに用意するべきである．FlexRay 通信ミドルウェアは
これらの機能をすべて満たした FlexRay 通信専用のミドルウェア
であり，各機能を順に，FlexRay デバイスドライバ，TT-COM，FlexRay-NM として開発した．
・ FlexRay デバイスドライバ

備考
MessageSend処理（送信コピー処理）
MessageReceive処理（受信コピー処理）

フレーム受信実行処理
ttReceiveFrame
TT-COMイニシャル関数
ttInitCOM
TT-COMバッファ初期化関数 ttInitBufferCOM
TT-COMステータス情報
ttReadFlag
フラグの読み出し
途絶判定処理送信キューに溜まったアプリ
TT-COM周期処理関数
ttTickCOM
ケーションデータの送信処理
FIFO受信フレーム取得
ttReadFifo

フィルタ制御は，アプリケーションエンジニアが規定できる要
素を残しながら，一般的な処理をあらかじめミドルウェアに含めている機能であり，データがアクティブ ( 非ゼロ ) やデー
タの変化が発生した場合 ( 前回データと今回データが変化した場合 ) にデータを送信するなどの条件を指定できる．
どちらの場合も，アプリケーションのデータ作成のタイミングで送信
データを TT-COM に通達するのみで，指定されたフィルタ条
件に一致した場合に送信したり，受信したりすることができる機能を提供する制御である．Que 制御は，短期間に発生する状
態変化をすべて送信および受信するために，状態変化時にデー

FlexRay デバイスドライバは FlexRay デバイスを制御するた

タをバッファリングし，送受信する制御である．バッファ構成

めに用意されたサービスルーチン群であり，デバイスに依存すが Que 構造であるため，Que 制御と呼ぶ．

る部位である． ( 現在はルネサス製 FlexRay8デバイスを対象

FlexRay 通信の通信単位は，スロットと呼ばれる単位で通信をとし，他のデバイスに対応するためには，このデバイスドライ

行い，そのスロットには複数の情報を保持することができる．

バ部位を移植することとなる．) 通常のデバイスドライバの場

多くのスロットは，複数のアプリケーション部位からデータが合，アプリケーションからはデバイスの利用開始時に公開され作られ，それがひとつのスロットにまとめられてデータ送受信ている初期化ルーチンをコールするのみであり，FlexRay 通信が行われる．OS などを用いて，それぞれの部位が非同期で動ミドルウェアのデバイスドライバも同様の思想となる．しかし，作している場合，スロット内のまとめられる各データがどのタ

FlexRay 通信はネットワーク時間に同期して処理を行う必要

イミングで集まるか定まらない場合が多く，また，それらのデがあるため，他のデバイスドライバと異なり，ネットワーク時

ータをまとめる処理をアプリケーションの処理にするのは移間との同期に必要な時間通知機能，サイクル開始割込み，同期植上問題がある．そのため，これらのメッセージデータをまとずれ通知割込みなどを外部公開し，同期処理を可能とするサーめる機能をメッセージ Pack 制御，受信データからメッセージ

ビスを提供している．3.1 章で説明した TT-OS は，このデバイ

データを分離する処理をメッセージ UnPack 制御と呼び，

スドライバ提供機能を利用して同期処理を実現しているため，

FlexRay 通信ミドルウェアに含めている．また，FlexRay 通信

TT-OS には必須となるサービスであり，TT-OS と密接に結合

バスに接続されている各ノードのエンディアンは統一されてしている部位である．そのため，他のデバイスに移植する場合いるわけではなく，各ノードはデータ送信時に FlexRay 通信

は，これらのサービスを TT-OS に提供する必要がある．

で用いるエンディアンに変換し，受信時にはプロセッサエンデ

・ TT-COM

ィアンに変換する必要がある．これらの処理も通信ミドルウェ
アに含めている．通信途絶制御は，ネットワーク管理

8 ルネサスは，欧州の BOSCH からライセンスを供与されて FlexRay デバ

イスを作成しているため，正式には BOSCH 仕様のデバイスと言える．尚，
日本の半導体メーカの多くは BOSCH 仕様を利用している．

( FlexRay-NM ) と協調し，接続ノードもしくは自ノードが通信途絶状況に陥っているかどうかを判断し，アプリケーションに通知する機能を提供している．

上記の機能セットは，OSEK COM 仕様[3]においても同等の1 ) ，同社製簡易エミュレータ ( M3A-0655 FoUSB ) を用いてデ機能セットを規定しているが，本 TT-COM は，TT-OS より提バッグを実施した．

供されるタイムトリガ機能に同期して送受信が実行できるよ5. 開発成果について

うな機構およびタイミング通知機構を兼ね備えており，

応募代表者は，TT-OS および FlexRay 通信ミドルウェアを搭載

FlexRay 通信などの外部ネットワーク時間に同期して処理をした「FlexRay Steering by Wire」( 以下デモ装置 )9を実現し，必要とする通信システムに利用できるミドルウェアである．

FlexRay 通信技術の検証実験を行い，FlexRay 通信の耐障害性お一方，OSEK/VDX は，タイムトリガ通信用の通信ミドルウェ

よびイベント処理とタイムトリガ処理の両立が実現できているこ

アとして，OSEK FT-COM 仕様[4]を規定し，障害対策を考慮とを確認した． また，ESEC200510および FlexRay Product Days

した通信ミドルウェアを規定している．本 TT-COM はこの

200511 にデモ装置を出展して本ミドルウェアの有用性を広くアピ

OSEK FT-COM 仕様は参考にしているものの，FT-COM のールし，国内外から問い合わせおよび評価をいただいている．

最大の特徴である Fault Tolerant 部位を取り除いている．
FlexRay 通信の場合，FlexRay デバイスで Fault Tolerant を考慮しており，二重化などに対応している．そのため，FlexRay
通信用のソフトウェアミドルウェアに必要な障害対策が何であるべきかが正しく分析できていないため，現 TT-COM はソ
フトウェアで障害対策をするのではなく，FlexRay デバイスをそのまま利用し，このミドルウェアを利用し，FlexRay 通信を実現した後に，障害対策の必要性などを検討する．
・ FlexRay-NM (Network Management )6. 今後の計画
本TT-OS およびFlexRay 通信ミドルウェアと応募代表者らが中心となり研究開発中の保護機能および現世代通信ミドルウェア( 経済産業省の平成 17 年度地域新生コンソーシアム研究開発事業( 中部地区 ) ：「自動車統合制御用組込み OS の開発」) を結合し次世代の標準的な自動車制御用プラットフォームの叩き台として完成させ，名古屋大学高田･冨山研究室より JasPar に提案する計画である．また，AUTOSAR のメンバ社を通じて AUTOSAR でも検討していただけるように提案したいと考えている．

FlexRay 通信には FlexRay バスに最低 3 ノード (FlexRay コ
自動車制御プラットフォーム
自動車制御プラットフォーム

ンソーシアムでは最低 4 ノードを推奨 )がネットワーク時間を作成するために必要であり，通常，FlexRay バスには複数のノコンポーネントコンポーネントードが接続されている．これらのバスに接続されているノード
が，何らかの障害状況に陥った場合や省電力対応などの理由でマルチプロセッサ
マルチプロセッサ

必要がある．これらの管理機能は，各ノードに管理機構が必要となるものの，処理内容は共通で良いため，ソフトウェアによるミドルウェアで提供すればよい．本 FlexRay 通信ミドルウ

TOPPERS/OSEKTOPPERS/OSEK
Ver1.0Ver1.0FlexRay
FlexRay
発
開発
信開
通信
代通
世代
次
次世

メモリ保護
メモリ保護

高
高
信
信
頼
頼
性
性
OOS
S

部品
部
品化
化／
／機
機能
能分
分散
散技
技術
術

ノードが休止できる場合などのネットワーク状況を管理する

時間保護
時間保護

FlexRay対応
対応OS
OS拡張
拡張
FlexRay
FlexRay対応OS拡張

大限活用し，FlexRay デバイスが提供するネットワーク管理処

CAN/LIN
CAN/LIN
ミドルウェアミドルウェアCOM
COM
CCC0,CCC1
CCC0,CCC1COM
COM
CCCA,CCCB
CCCA,CCCB

発
開発
系開
信系
通
通信

CAN/LIN
CAN/LIN
ドライバ
ドライバ

標準
標準
ＮＭ
ＮＭ

赤斜線：2005/10現在 開発完了部品

ェアにおいては，FlexRay-NM として提供している．
FlexRay-NM も TT-COM 同様に，FlexRay デバイス機能を最FlexRay対応
対応COM
COM拡張
拡張
FlexRay
FlexRay対応COM拡張(( FT-COM 類似))
FT類似
FT-COM類似)

7. 謝辞
本TT-OS およびFlexRay 通信ミドルウェアを開発するにあたり，理を有効に利用している．具体的には，FlexRay 通信メッセー

トヨタ自動車統合システム開発部の細谷様をはじめ，自動車メーカジフレーム内にネットワーク管理用ビットを規定することがの立場からご意見をいただきまいた．
ここに記して謝意を表します．

でき，その管理ビットに各ノードのアライブ状況 ( 正常起動状況 ) とスリープ許可状況 ( 休止可能状況 ) を割り当てて，ノード管理を行っている．これらの管理ビット操作は，FlexRay
デバイスが自動的に処理を行い，ソフトウェアで処理をする必要はない．そのため，FlexRay-NM は，管理ビットを参照し，適切な情報をアプリケーションに通達する機能を提供しているに留めている．
この方針は，FlexRay 通信のネットワーク管理機能に必要な要求事項が明確でないことと，現在 FlexRay デバイスから提供されるネットワーク管理が改良の余地があると判断している
ため，最低限の機能のみ提供することである．

4. 動作環境と開発環境

文

献[1] OSEK/VDX ， OSEK/VDX Time-Triggered Operating System
Version 1.0 ，OSEK VDX，July 24th 2001[2] OSEK/VDX，OSEK/VDX Operating System Version 2.2.1 ，
OSEK VDX，January 16th 2003
[3] OSEK/VDX ， OSEK/VDX Communication Version 3.0.3 ，OSEK/VDX，July 20th 2004[4] OSEK/VDX，OSEK/VDX Fault –Tolerant Communication Version
1.0 ，OSEK/VDX，July 24th 2001
[5] TOPPERS プロジェクトホームページ，http://www.toppers.jp/[6] 株式会社ヴィッツ，TT-OS Stage-1 外部仕様書 Version 1.0，
2005 年 11 月
[7] 株式会社サニー技研，FlexRay 通信ソフト TT-COM モジュール仕様書 Rev 1.01 ，2005 年 10 月

1章で述べた通り，
TT-OSおよびFlexRay通信ミドルウェアは，
ターゲットプロセッサとして，現時点では，ルネサステクノロジ製
M32C をサポートしている．開発時に用いたターゲットボードは，
ルネサステクノロジ製 FlexRay 評価ボード ( M3A-0847G21 ) であり，このボードを用いて動作を確認した．開発環境は，ルネサス
テクノロジ製コンパイラ ( NC308 Version 5.20 Release 02 ) を

9 紹介デモビデオ http://www.witz-inc.co.jp/pi/img/frsbwd.wvx

用いて開発し，同社製デバッガ( KD3083 Version 3.30 Release

10 組込みシステム開発技術展 http://www.reedexpo.co.jp/ESEC/
11 http://www.hanser.de/seminare/index.asp?fz_id=2521814468-81&task=010