自 動 車

車載用通信プロトコル（スケーラブル C A N ）開発
倉地手嶋山本亮・西＊村政信・高＊田広章

茂晴・宮下之宏・堀端啓史秀樹・夏目晃

宏Development of Scalable CAN Protocol ─ by Ryo Kurachi, Masanobu Nishimura, Hiroaki Takada, Shigeharu
Teshima, Yukihiro Miyashita, Satoshi Horihata, Hideki Yamamoto and Akihiro Natsume ─ In today’s automotive
industry, FlexRay and other next generation protocols for automotive network communications are gaining attention.
However, these protocols are unlikely to replace existing applications in the immediate future due to the cost andreliability problems caused by the replacement.
In this paper we propose Scalable CAN, a new automotive network protocol based on the existing CAN (controllerarea network). Having a new ACK (acknowledgement) information field, instead of an ACK slot, the Scalable CANfeatures 10 Mbps of transmission speed and a new collision resolution algorithm which guarantees delivery of amessage within a given time period. Our analysis using a simulator indicates that the Scalable CAN protocol issuperior to the conventional CAN in throughput performance such as maximum data transmission speed, scalability,and priority inversion.
This paper also includes considerations given for the implementation of the Scalable CAN.
Keywords: Scalable CAN, protocol, controller, delay

1.

緒言

近年、自動車装備の電子化に伴い、車両一台あたりに搭

そこで本稿では、将来の高速化にも対応可能で、従来載される ECU（Electronic Control Unit）は数十個にもCAN 向けに開発されたソフトウェア資産との互換性を保ち及ぶ。各 ECU は、車載ネットワークを介して、多くの情つつ、より高速で低遅延な通信を可能とする新たなプロト報を共有し、様々な機能や制御を実現している。車載ネッコル（スケーラブル CAN）について紹介する。また提案すトワークとして、低速では LIN （Local Interconnect

るプロトコルは、低速から高速まで、車載ネットワークと（Controller Area Network）
Network）、中高速では CAN（2）して様々な用途にスケーラブルに適用可能とすることを目が用いられることが一般的である。しかしながら、これら指して開発した。

（ 1）のネットワークには、既に多くの ECU が接続されており、今後の拡張性は、GW（gateway）を介したネットワークの追加や、ECU 統合による接続数の低減などに頼らざるを得ない。

2.

CAN の課題
CAN は、衝突メッセージを非破壊で調停可能とする特徴

一方で、高速・高信頼性を確保するネットワークとして的なメカニズムを有するため、伝送路上の遅延など様々なFlexRay（ 3 ）があり、既に欧州の高級車メーカなどから、制約を持つ。これらのメカニズムや制約は、伝送速度の高ネットワークの一部に FlexRay を搭載した自動車が発売さ速化の妨げとなっており、仕様としては 1Mbps まで規定れている。しかしながら、CAN から FlexRay への移行は、されているものの、車載環境下で使用されるのは 500kbps

既存の CAN 向けソフトウェア資産（ミドルウェアやアプまでに留まっているのが現状である。また、500kbps 以下リケーション）を流用できず、ネットワークに接続可能なの CAN であっても、特定の条件下では、アプリケーショノード数が CAN に比べて制限されるなど、高速化以外のン要求を満足できないなどの課題がある。

課題が残る。
自動車の分野では、新たなプロトコルへの移行に伴い、システムや部品を一新することは、コストや品質確保の観点からも非常に難しい。そのため、既存プロトコルを使い続けるための技術開発も重要になる。

−（ 30 ）− 車載用通信プロトコル（スケーラブル CAN）開発

以下にて、CAN 高速化へ向けて、本稿が解決しようとする課題の詳細を示す。
2−1

伝送路上の遅延CAN の高速化を妨げる要因として、以下の 2 つの特徴的な機能がある。
① ‘bitwise’ （non-destructive）arbitration

② ACK（Acknowledgement）field
CAN は、CSMA によるコンテンション・ベースの調停メカニズムを持つが、SOF ビットで開始されるフレームは、3−1

CAN に対し、下記の変更を加える。

複数ノードからの送信によって衝突し得る。しかしながら、① ACK メカニズムの変更（ACK/NAK 情報のメッ衝突した場合であっても、同期メカニズムによって同期さセージ化）れた 1bit 毎にビット比較が行われ、優位ビット（ドミナント）を送信しているフレームは、劣位ビット（レセッシブ）

既存 CAN に対する伝送遅アプローチの概要

延要求を緩和し、最悪遅延の予測を可能にするため、従来② 調停手法の変更（スロットによる送信権限の管理）（1）遅延要求の緩和を送信しているフレームによって破壊されることなく、調①②の変更により、従来、厳しい伝播遅延要求を伴い、停フィールド以内に送信権限を獲得し、その後の送信を維

1bit 時間内で実施されていたバス調停および ACK メカニ持できる。

ズムが廃止され、既存の各種シリアル通信プロトコルと同CAN の ACK メカニズムは、ビット同期メカニズムに様に、ノード間の伝播遅延に対する制約は大きく緩和できよって同期された複数のノードが、受信したフレームに対る。さらに、受信したフレームに対する ACK/NAK 情報は、する ACK/NAK 判定結果を、同時に同じビット位置（ACKフレーム中の新たな情報ビットとして送信することで、従スロット）へ送信し合うことで、CAN バス上の全てのノー来機能を代替する。

ドによる判定を実現している。

（2）最悪遅延の保障

これらのメカニズムは、CAN を特徴付ける上で重要な仕②の変更により、バスに対する送信権限を時間間隔（ス様であるが、CAN バス上の各ノード間での伝送遅延に対しロット）毎に管理し、各スロット毎に、1 つの送信ノードて厳しい制約を生む要因でもある。

を割付ることで、送信時の衝突を回避し、従来 CAN におCAN をより高速で使用可能とするためには、上記 2 つのいて「バス調停で負け続ける可能性」によって予測困難と特徴的な機能を置換し、伝送遅延に対する制約を排除できされていたアプリケーション間の最悪遅延時間を、一定時る工夫が必要となる。

間内に収めることが可能となる。

その他にも、配線長の増加に伴う信号の減衰や、CANバスの分岐点の数、支線長の影響など、物理的な信号特性の以降にて、これら提案手法を実現する手段について、その詳細を示す。

劣化要因も高速化を妨げるが、これらの要因は、後述する提案手法を採用することで、バス・リピータの導入など一般的な手法での改善が期待されるため、ここでは議論しない。

3−2

提案手法におけるフフレームフォーマット

レームフォーマットと従来 CAN との比較を図 1 に示し、その変更点について以下に示す。

車載システムでは、「ACK 情報フィールド（図中、AckInfo）」は、自身のしばしば一定時間内に ECU から別の ECU へメッセージを送信以前に受信した他者の送信に対する ACK 情報を格納受け渡すことが求められる。CAN バスに対するメッセージする。従来 CAN において ACK スロットで提示されていたの送信は、送信ノードの内部イベントに応じて開始される。

情報をメッセージとして通知するためのものである。

CAN バスに対し、複数のノードから同時にフレームが送信「CRC（cyclic redundancy check）フィールド」は、される場合、そのフレームは、各送信ノードによって同期17 ビットに変更され、CRC（15bit）と CRC デリミタ（2bit）され、調停フィールド内で最終的な送信権限が決定されるで構成される。ACK ビットの廃止に伴い、CRC デリミタ

ため、低い優先度の ID を持つフレームは、調停負けする。

を 2 ビットとし、1 ビットのレセッシブと 1 ビットのドミ

この調停負けは、再送信の場合であっても同様に複数回連ナントで構成する仕様とした。ACK ビットの廃止に伴い、2−2

メッセージの遅延保障続して起こり得る。このことは、イベント発生に伴い送信開始されたメッセージが、他のノードに受信されるまでの最悪時間を保障できないことを意味する。
一般的に、連続して調停負けすることへの対策としては、
OS のタスクスケジューリング等と同様の考えにより、高優先度のフレーム送信を連続して行わないなど、運用上の工夫によって一定の改善が期待できるが、このような対策は、問題を根本的に解決するものではない。

CRC
(15)

CAN
R
DSOF
(1)

ID field

Control

Data field(0〜8Byte)

提案手法（スケーラブルCAN）

3.

CAN 高速化への提案手法
本稿では、伝送路遅延の影響を最小にし、メッセージ遅RDSOF(1)

ID field

AckInfo Control

CRC ACK ACK
DL (1) DL

CRC field ACK
(16)
(2)

CRC
(15)
Data field(0〜64Byte)

EOF
(7)

CRC CRCDL DL
CRC field(17)

IFS（3bit times）
SOF(1)

ID field

IFS（3bit times）
EOF
(7)

SOF
(1)

ID field（SOF : start of frame EOF : end of frame IFS : interframe space）

延の最悪値を保障可能とするために、プロトコル上の工夫によって実現する手法を提案する。

図1

フレームフォーマット

2 0 1 0 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 7 号 −（ 31 ）−フレーム終端を示す EOF（end of frame、レセッシブ 7bit）保障を可能にしている。

以前にビット再同期処理が行われる立ち下がりエッジは、（2）送信待ち時間15 ビットの CRC 中にて発生するドミナントビットとなる。

前述（1）にて示すとおり、フレームを送信する順番に従来 CAN の仕様であれば、EOF 以前の立ち下がりエッジあるノードが、自身のフレームを送信するまでの送信待ちは、CRC デリミタに続く ACK ビットであり、その後に時間は、自身の送信前に受信したフレームの CRC デリミタ

ビット再同期されないレセッシブ・ビットの連続で累積し（2bit）を検出後から、tbackoff 時間経過後とする。

うるノード間の同期ズレ量は、このエッジを基点に推定可能であった。今回、ACK ビットの廃止に伴い、従来 ACKビットが担っていた同期メカニズム上の意味合いは、新しい CRC デリミタ（2bit）のビットパターンによって代替すtbackoff = (tEOF + tIFS)（3）期待応答受信時間
前述（1）の通信シーケンスに示すとおり、一旦、送受ることとした。
通信シーケンスについて、信が開始された後は、現在の送信者と次の送信者との間で、簡略化のため、図 2 に示すように、GW と ECU が 1 対 1 でフレームの衝突が回避できることを担保する必要がある。

3−3

通信シーケンス接続された場合を例にして説明する。

このために必要な、時間条件に対する考え方を以下に示す。
図 3 は、GW がフレームを送信後、ECU からのフレーム受信を待つ時の、期待時間を示すものである。メッセージの送信中、CRC デリミタの送信が完了した時点を t ＝ 0 と
GW

GW

ECU

ECU

図2

Tx

Msg.G1

し、応答メッセージの SOF を検出するためにビットサンプ

Mse.G2

Rxt

リングを開始する。SOF を検出した時の時刻を t とする。

Rx
Tx

Msg.E1t接続構成と通信シーケンス0（EOF期間開始）

衝突検出期間EOF (7 bit times)（1）基本シーケンス
図 2 に示すように、GW が先に送信を開始し、送信されGW

GW は、一定時間バス上にフレームが送信されていないこECUたフレームが衝突しない場合を例に通信シーケンスを示す。

Tx

SOF検出
正常受信期間IFS＋2τ (bit times)
IFS (3)tt̲RTT (<2τ)

Msg.G1Rx
RxTxとを確認した後、自身のフレーム（Msg.G1）を送信する。

α：ビット同期誤差
伝播遅延時間t̲gw/ecu (<τ)

バス上にフレームが送信されたことを検出した ECU は、そのフレーム（Msg.G1）を受信する。

図3

フレーム（Msg.G1）を送信完了した GW は、ECU から応答までのバックオフ期間
EOF＋IFS (＝7＋3 bit times)

Msg.E1
伝播遅延時間t̲ecu/gw (<τ)

通信タイミングの詳細の応答を期待し、受信待ち状態となる。GW からのフレーム（Msg.G1）を受信した ECU は、受信したフレームの異常の有無に応じて、ACK 情報フィールドに ACK またはGW がフレーム（Msg.G1）を送信後、ECU の応答送信

NAK を格納したフレーム（Msg.E1）を送信する。このとフレーム（Msg.E1）を受信するまでの時間は、理想的にき ECU は、GW から受信したメッセージに対する応答や、は、t response 時間である。ビット同期誤差αは、正負の値を自身が送信したいイベントデータなどがあれば、データフィールドに格納してフレームを送信する。
ECU からの応答フレームを待っていた GW は、フレーム（Msg.E1）を受信し、このフレームに含まれる ACK 情報を取りうる。

tresponse = (tEOF + tIFS + tgw/ecu ± |α | + tecu/gw)

参照することによって、先の送信の成否を判定する。同様

ここで、GW と ECU 間の往復に要する伝播遅延時間に、GW は、受信したフレーム（Msg.E1）に対する ACK ま（tgw/ecu ＋ tecu/gw）を tRTT（Round Trip Time）と表わすと、たは NAK を格納した次のフレーム（Msg.G2）を送信する。
このように、GW と ECU が順に ACK 情報を含むフレー

GW が ECU からの応答を期待できる待ち時間は、（EOF ＋IFS ＋ tRTT ± |α|）時間となり、（tRTT ＞α）の関係が成立しムを送信し合うことで、衝突を回避し、各ノードが、一定ない限り、GW が認識する IFS（3bit times）中に、ECU時間内に、送信権限を獲得することで、調停に負け続けるの送信したフレームの先頭ビット（SOF）が検出される可可能性を排除し、アプリケーション間における最悪遅延の能性が生じる。

−（ 32 ）− 車載用通信プロトコル（スケーラブル CAN）開発

tRTT は、1 ビットの時間よりも十分短い場合もあり得る

ECU-A

だけでなく、αは、ボーレートが低い場合や、ビットに対ECU-B
衝突するサンプリング周期が長い程、tRTT に対し相対的に大きくなる（tRTT ＜α）。

本稿で提案する方式では、下式が成立する範囲内の伝送遅延と同期誤差を許容することとした。

(tIFS+ tRTT − α ) > 0

応答待ち
タイムアウト

応答待ち
タイムアウト

再送開始待ちt1

再送開始待ちt2（4）許容伝播遅延時間

再送開始待ちキャンセル

前述（3）では、図 3 で例示した GW と ECU 間の伝播遅延時間にて期待応答時間を示した。実際の車両では、この伝播遅延時間は、ECU の配置やハーネスの形態などによっ交互送信て、様々な値を取り得る。また、複数ノードが接続されたバスに対し、本方式を用いる場合には、任意の 2 ノード間の伝播遅延の内、最悪の値（tRTTmax）が考慮されるべきである。

図4

ここでτを、システム内の全てのノードで同じ値をもち、非対称な再送待ち時間

伝送路遅延の許容値に基づいて設定される値として定義する。当然のことながら、τは設計上、伝送路遅延の許容値提案する手法では、ノード毎に異なる再送信待ち時間よりも大きな値で設定される。

（図 4 中、t1, t2）を設定し、2 度目の衝突を起こすことな

 tRTT + |α | 
τ >  max2

く、再送信が開始されるようにする。

最小の再送待ち時間の設定は、ノード毎にユニークな IDなど、車載 ECU が静的に持つ情報に基き算出する手法とした。但し、再送待ち時間の最小単位は、応答待ち時間と同様（5）衝突判定アルゴリズム
前述（3）（4）より、応答待ち状態において SOF 検出した時間 t に対する判定ルールを表 1 の通り定義する。

表1No.に、ノード間で生じ得る同期誤差を考慮して決定されるべきであり、同一バス上の各ノードで、統一する必要がある。

4.

衝突判定条件

提案手法の評価
本稿で提案する手法に対しては、その仕様の妥当性・十条件式

判定結果①t ＜ 7［bit times］衝突あり②7［bit times］≦ t ＜ rtout

正常受信③rtout ≦ t

応答受信なしを行った。

※ rtout ＝ EOF ＋ IFS ＋ 2τ

4−1

分性を検証するために、①モデル検査、②シミュレーション、③ FPGA による試作、の 3 つのアプローチによる評価
モデル検査

本提案方式の振る舞いは、鵜飼ら（4）（6）
により、モデル検査（5）、の手法を用いて網羅的に解析する試みがなされた。仕様の振る舞いは、伝送路におけるビッ（6）再送信待ち時間
表 1 の条件式に基づいて、フレームの衝突が検出された

トエラーの発生も考慮したモデルが SMV 言語で記述され、モデル検査ツール NuSMV（7）を用いて検査が行われた。

場合、GW からフレーム（Msg.G1）の再送信を行う必要

ここから得られた反例を解析することで、仕様の不具合・がある。この時、次の送信は衝突することなく、必ず送信不足などの有益な情報を得ることができ、開発プロセスの早を終了できることを保障するために、ノード毎に異なる再期段階において、仕様の完成度を高めることができた。

送信待ち時間を設定する。

4−2

シミュレーションによる評価

本提案方式の衝突回避の手法として、衝突発生後、ランダムな待ち時倉地ら による最悪遅延に関するシミュレーションの一例（8）間を設けて再送信を試みる手法が一般的に用いられる。しとして、GW を介して 20 ノードが接続された状態におけかしながら、この手法では、2 度目も衝突してしまう可能るシミュレーション結果を紹介し、提案手法を用いること性が残るため、最悪遅延時間の保障が求められる車載用プで、ノード間の送信遅延が、一定レベル以内に収まることロトコルとしては適さない。

を示す。

2 0 1 0 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 7 号 −（ 33 ）−

率の最悪値は、ボーレート 10Mbps において 1.75 ％と、良好な効果が確認された。更にメッセージ量を 10 倍に増やしたシミュレーションにおいても、16.76 ％と十分な遅Simulation parameters of 10Mbps CAN.
Parameters
StatusNumber of ECUs
201
Number of gateways
Size of message queue 200 messages
Data rate
10 Mbps
Simulation time
10 seconds

図5

延率に抑えられることが確認できた。
4−3

FPGA による試作（1）試作の概要

本提案方式は、倉地ら（8）によって FPGA 上への実装が行われ、10Mbps 設定での評価が行われた。FPGA 上への実装仕様を図 6 に、提案手法を実装したコントローラのリソース消費の概要を表 3 に、評価の様子を図 7 に示す。

提案手法のシミュレータ構成

このデザインの主要なコンポーネントである NiosII プロ（1）シミュレーション環境
提案手法のシミュレーションは、OPNET Modeler（9）を表3用いて、図 5 に示す構成で実施された。

このシミュレーションでは、提案手法を既存の CAN バスに順次導入・展開する場合を想定し、GW を介して提案手法のバスを拡張する構成を想定している。シミュレー
ション時に送信するフレームは、実際の車両で使われるテストボードにおける合成結果

ECU

GW

Total logic elements

4,251

5,200

Total pins

8185

48,384

48,512

Total memory bits

（内、Scalable CAN Controller は 949［LE］）

メッセージセット（ID、データ長、送信周期）を使い評価を実施した。また、シミュレーションモデルは、1 ビット毎の振る舞いを表現できるようモデル化されており、ほぼ実際のネットワークで起こり得る現象を再現可能な環境となっている。
（2）シミュレーション・シナリオ
最悪遅延時間を評価するために、シミュレーション開始と同時に、各ノードから GW に対する送信が開始され、ある ECU に対する出力が最も遅滞するシナリオとしている。
シミュレーションからは、GW に蓄積されたフレームが、どれだけ効率よくポートから出力可能であるかという点が評価できる。

FPGA
NiosII プロセッサ（アプリケーション）

GW

タイマ

Scalable CAN Bus
ECUScalable CAN Controller
ホストIFOnChipRAM

mailbox
ACK管理
コントローラCore

DDR-SDRAM
Controller

評価環境
NiosII Development Kit, Cyclone II Edition（3）評価指標
シミュレーション結果の評価は、遅延率を用いて行った。
遅延率は、各送信メッセージに設定された送信周期に対すコンポーネント
NiosII プロセッサ，タイマ，オンチップRAM，
DDR-SDRAMコントローラ，Scalable CANコントローラ

る遅延時間で表わされる。

図6

FPGA による試作環境

 メッセージの遅延時間 100％
 メッセージの送信周期 遅延率＝ （4）評価結果

FPGA

評価結果を表 2 に示す。

FPGA

Bus Driver I/F

Bus Driver I/F

シミュレーションの結果、最も中継が混雑するノード宛の GW 出力ポートにおいて、最大 181 メッセージがキューイングされた。シナリオ内での結果に限定されるが、遅延GWノード

表2ECUノード

遅延率評価結果（最悪値）

No.

方式

ボーレート トラフィック量

遅延率1

スケーラブル CAN

10Mbps×1

1.75 ％2スケーラブル CAN

10Mbps× 1016.76 ％−（ 34 ）− 車載用通信プロトコル（スケーラブル CAN）開発

図7

評価の様子

セッサとスケーラブル CAN コントローラはそれぞれ、ス

今後は、より車載環境に近い条件において、仕様の検証、ケーラブル CAN コントローラのホストプロセッサ、提案シミュレーションと、試作による動作検証を行うとともに、手法を実現するネットワークコントローラとして実装され車両走行環境下における信号特性の評価を進めていく。ている。スケーラブル CAN コントローラの機能は主にフレームのデコードやエンコード、ビットスタッフなどを行うことであり、このコンポーネントは図 6 に示すような内部モジュールで構成される。また、コントローラ実装における従来 CAN との違いは少なく、新しい ACK シーケンスや提案する衝突解決アルゴリズムを、プロトコルのステートマシーンとして実装している点などである。
（2）試作結果

なお、本研究の成果は、名古屋大学と株式会社オートネットワーク技術研究所との共同研究で得られたものである。
・FlexRay は、ドイツ Daimler AG のドイツ及びその他の国における商標、または登録商標です。
・OPNET、OPNET Modeler は、米国 OPNET Technologies, Inc. の米国及びその他の国における商標、または商標登録です。
・Nios は、米国 Altera Corporation の米国及びその他の国における商標、または商標登録です。

本実装に対して、①従来 CAN コントローラとの互換性と、②コントローラの処理能力を評価した。
一つ目の評価項目である従来 CAN との互換性は、その参考

文

献制御レジスタ構成を比較することで実施された。その結果、（1）LIN Consortium, http://www.lin-subbus.de/

送信待ちのためのバックオフ時間の優先度設定ビットを追（2）International Organization for Standardization, Road vehicles .
Controller area network (CAN). Part1: Data link layer and physicalsignaling, ISO IS11898-1（2003）

加している以外は従来 CAN コントローラと同等であり、従来 CAN とはコントローラの初期化処理のみの変更で互換性を確保できていることを確認した。
二つ目の評価項目である処理能力は、実際のコントロー
ラ動作を確認するために、AUTOSAR（10）COM スタック及びその上で動作するデモアプリを作成し、その処理能力を確認した。ここで作成された AUTOSAR COM スタックはCAN の仕様で定義される CAN Driver、CAN Interface、COM、PDU Router、および、デモアプリで構成され、PDU Router はゼロコストオペレーションで実装された。
その結果、10Mbps 設定において、約 7Mbps の伝送が可能であることを確認した。

5.

（3）FlexRay Consortium, http://www.flexray.com/（4）鵜飼謙児、坂部俊樹、高田広章、倉地亮、酒井正彦、草刈圭一朗、西田直樹、「電子情報通信学会技術研究報告. SS」、ソフトウェアサイエ
ンス 108（242）、61-66、20081009（5）Huth,M. and Ryan,M : Logic in Computer Science : Modelling andReasoning about Systems, Cambridge University Press, 2nd ed.,
2004, Chapter 3, pp.172-255.
（6）Clarke,E.M., Grumberg,O and Peled,D : Model Checking, MIT Press,（2000）（7）NuSMV home page, http://nusmv.irst.itc.it/（8）倉地亮、高田広章、手嶋茂晴、宮下之宏、「10MbpsCAN プロトコルの設計と評価」、情報処理学会論文誌、Vol.50 No.11、pp. 2643-2653（2009 年 11 月）（9）OPNET Modeler, http://www.opnet.com/（10）AUTOSAR. http://www.autosar.org/

提案手法の課題
提案手法を、実際の車両環境に適用可能とするまでには、複数ノードがバス型に接続された形態を実現可能とするこ執筆

倉地とが必要であり、①フレームフォーマットの見直し、②送信順序管理手法の規定、③複数ノード間での ACK/NAK 情報を管理する方式、などに対する検討・開発が必要である。

6.

結者 ---------------------------------------------------------------------------------------------------------------亮＊：名古屋大学 大学院情報科学研究科
附属組込みシステム研究センター
研究員
車載ネットワークシステムに関する研究に従事

西村

政 信＊：㈱オートネットワーク技術研究所
ネットワーク研究部
車載ネットワークシステムの開発に従事

高田広 章 ：名古屋大学 大学院情報科学研究科
附属組込みシステム研究センター センター長 博士（理学）手嶋茂 晴 ：名古屋大学 大学院情報科学研究科
附属組込みシステム研究センター 特任教授 博士（工学）宮下之 宏 ：㈱オートネットワーク技術研究所 ネットワーク研究部

堀端

啓 史 ：㈱オートネットワーク技術研究所 ネットワーク研究部
主任研究員

山本

秀 樹 ：㈱オートネットワーク技術研究所 ネットワーク研究部 室長

夏目晃 宏 ：㈱オートネットワーク技術研究所 ネットワーク研究部 部長

言

本稿では、従来 CAN における様々な制約を緩和し、高速化を可能とするためのプロトコル的な対策を提案した。
その上で、これら提案手法が、アプリケーション間の最悪遅延を一定のレベル以内に抑えることが可能であることを確認し、FPGA による試作によって、ボーレート 10Mbpsにおいて、約 7Mbps の伝送能力を発揮できることを確認した。また、開発過程においては、仕様策定フェーズにおいて、モデル検査とネットワークシミュレータによる検証を行い、開発前工程における品質確保手法として、その有効性を確認できた。

------------------------------------------------------------------------------------------------------------------------------------＊主執筆者

2 0 1 0 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 7 号 −（ 35 ）−