Automotive ethernet training_jp

株式会社
日本イントリピッド・コントロール・システムズ
車載Ethernet入門
(株) 日本イントリピッド・コントロール・システムズ
TEL:045-263-9294 / http://intrepidcs.jp
1
Ver. 20140905

目次
序章：クルマはEthernetへ
第一章：第１層～物理層～
第二章：第２層～データリンク層～
第三章：第３層～ネットワーク層～
第四章：第４層～トランスポート層～
第五章：Audio Visual Bridging概観
2

目次
1.1. 車載ネットワーク概観
1.2. 車載Ethernetとは
1.3. BroadR-Reachとは
3

その他一般のネットワークと同様、
単にデータをやりとりするコンピュータの集まり。
しかし・・・
4
Data

車載製品に求められる条件
車載機器家電
製品特性品質・信頼性が最重要。15年もし
くはそれ以上の寿命を期待
消費者にとって最新かつリッチな機
能を、最速で提供
保守購入後に壊れた場合、修理・交換
が可能であることが必須
購入数年で壊れた場合、そのまま捨
てられることも多い
開発白紙からの開発は殆どなく、実績
のある既存製品から積み上げる形
で開始
白紙状態から新製品を開始すること
もある
寿命 11.4年(乗用車の平均年齢＠米国) ～5年
5

過酷な環境下での稼働
 雪、塵、油、泥、水、、、＠ - 40～125ºC
冬＠デトロイト夏＠デトロイト

2014/08＠ICS本社周辺
7

パワーマネジメント＆スリープ機能
 電力浪費＝燃費、バッテリー上がりに直結

車載ネットワークの開発背景
9
• 電子機器を通じた機能充実要求(80’～)
• 搭載ECU数の増大
• ECU間通信の増大(当初はPoint-to-Point)
• 配線＆コネクタの複雑化・巨大化
ECU
BCM
 燃費＆加速性能＆コストに悪影響
 製造&組立＆保守に難
 車内空間圧迫
TCU
インパネ

~90’：各社固有の規格を利用
10
ゼネラル・モーターズ - Class 2
クライスラー - CCD(Chrysler Collision Detection)
フォード - SCP(Standard Corporate Protocol)
トヨタ - BEAN(Body Electronic Area Network)
90’～：Boschの開発したCANが業界標準へ
1983 Bosch内部にて開発開始
1986 公式発表＠米国SAE
1987 初のCANコントローラ出荷
1992 メルセデスベンツに採用
1993 ISO11898として国際標準化
1998 ダイムラー＆クライスラーの合併等により米国にも普及

1.1.1. CAN概観
11
ECU
BCM
TCU
インパネ
ECU
BCM
TCU
インパネ
CAN
適用
それまでの通信方式に比べて・・・
ローコスト 2線、国際標準化に伴う大量生産効果
高速最大1Mbps
高ノイズ耐性＆高信頼性エラー検出機能等
取り扱い容易ノードの追加/削除を、他のノードに影響を与える
ことなく実現

1.1.2. CAN-FD概観
CANでは不足となりつつある近年の
通信量増大に対応すべく、2012年にBoschが発表
12
CAN CAN-FD
最高通信速度 1Mbps 8Mbps
最大ペイロード 8バイト 64バイト
CAN-FDのメリット≒CANのメリット
ローコスト 2線のみ、国際標準化に伴う大量生産効果
高速最大8Mbps
高ノイズ耐性＆高信頼性エラー検出機能等
取り扱い容易ノードの追加/削除を、他のノードに影響を与える
ことなく実現
※CAN-FDはCANに対する後方互換性なし。即ち従来のCANノードはCAN-FDネットワーク上では使用不可

1.1.3. LIN概観
13
出典：CVEL
メリットデメリット
・CANより廉価：１線のみ、UART利用
・データエラー検出、ノード障害検出
・遅延保証
・低速：19.2Kbps@40m
・最大１６ノードまで

1.1.4. FlexRay概観
14
・最大10Mbpsの高速通信
・高信頼性(2つの冗長なデータチャネル確保)
・高精度のメッセージ遅延制御
・複数のトポロジ対応
(バス型/スター型/ハイブリッド型)
・ネットワーク全体をあらかじめ
設計・固定しておく必要あり
・高コスト

1.1.5. MOST概観
15
・最大150Mbpsの高速通信
・プラグ＆プレイ：デバイスの自己認識
及び自動初期化機能
・光ファイバ利用による軽量化＆被ノイ
ズ耐性＆ゼロノイズ放射
・1箇所の故障で全体がダウン
(開発・評価ツールもリングの一部な
ので、ツールの誤動作でもダウン)
・光ファイバは高価＆曲げにくい

16
車載Ethernetへの関心の高まり…

“車載Ethernet”の種類と動向
17
IEEE 802.3 100BASE-TX
Ethernet
BroadR-Reach
Ethernet
Reduced Pair Gigabit
Ethernet
～2014 2014~ 2020～
100Mbps 100Mbps 1Gbps
・診断
・ECUフラッシュ
・ドライバアシスト
・インフォテイメント
・ネットワークバックボーン
2014 BMW X5 SUV
駐車補助システムに採用
(EE Timesより)

18
利用例1：DoIP(Ethernet経由での診断)

19
利用例2：XCP on Ethernet
ETHERNET

利用例3：ドライバアシスト
(Broadcom社資料より)
TEL:045-263-9294 / http://intrepidcs.jp 20

利用例4：インフォテイメント
(1394 Trade Association発表資料より)

利用例5：車載ネットワークバックボーン
(NXP社資料より)

IEEE 802とBroadR-Reachの関係
主な802ファミリ
23
802.1 ネットワークブリッジ
802.3 Ethernet
802.11 WiFi
802.15 Bluetooth
802.3がクルマ用に
改良され、
車載Ethernet規格
BroadR-Reachへ
802.3
BroadR-Reach
(Broadcom社発表資料)

802.3と比較したBroadR-Reachの主な改善点
24
コスト＆重量・4組から1組のツイストペアへ(8線⇨2線)
・シールドなし
パワーマネジメント・低消費電力&スリープモード対応
過酷な環境下での動作・車載向け認証取得(AEC-Q100等)
EMC(電磁両立性) ・カーラジオ周波数帯におけるノイズ放射を軽減
・インジェクタ等からのノイズ耐性
FMラジオ70～100MHｚ帯
における電磁放射低減
(Broadcom社資料より)

802.3 EthernetとBroadR-Reachの層構造比較
ネットワーク層
MII MII
25
802.3 MAC
(データリンク層)
802.3
PHY
BroadR
PHY
共通
部分
固有
部分
*MII:Media Independent Interface
すなわち
物理層より上層のあらゆる既存の
Ethernet HW/SW
を再利用可能！
・あらゆるTCP/IP関連規格
・あらゆるMACコントローラ
・IP技術に携わるあらゆる人間
を車載へ！

BroadR-Reachは、CAN等の代替として
車載ネットワークの決定版になりうるか?
26

答えはNO
(Ethernet Tech Dayより)
27

BroadR-Reachの位置付け
データレート
[bps]
LIN
BroadR-Reach
CAN-FD
CAN
MOST
FlexRay
１ノードあたりの相対コスト
1 2 5 10
150M
100M
25M
10M
1M
20K

Ethernet(BroadR-Reach)とMOST比較
BroadR-Reach MOST
オープン性プロプライエタリ(Broadcom)
※上位プロトコルは一般標準
(TCP/IP, AVB, …)
プロプライエタリ
(SMSC)
速度 100Mbps/ポート
※将来的には1Gbpsも
150Mbps/ネットワーク
累積チップ出荷数 120M個(～2020年予想) 数M個
サプライヤ複数(Broadcom, NXP, Renesas…) SMSC
実装・運用コスト低：
・普遍的なプロトコル利用
・オープンソース活用
・豊富な人的資源
・複数チップサプライヤ
高：
・限られたツール
・限られた技術者

関連団体
車載Ethernet規格BroadR-Reachの策定・普及に特化した団体。
電気電子全般を扱う米国の標準化団体。ネットワーク分野では
Ethernetやブリッジ等、物理層周りの規格が有名
IEEEでは扱わない、物理層よりも上のプロトコルを策定。
例：RFC 791(IP), 768(UDP), 793(TCP)
幅広い分野を扱う国際標準化団体。品質管理・診断規格が特に有
名。自動車向けではISO13400として、Ethernet経由での診断手法
を策定(※)
ECU評価に用いるデータフォーマット等の標準化を推進。XCP on
Ethernetとして、Ethernet経由でのECU評価手法を策定(※)
ECU用ソフトウェアの標準化を推進。
車載に特化したEthernetプロトコルスタック等を策定
※標準のIEEE 802.3 Ethernet利用(BroadR-Reachではない)

目次
31

第１層～物理層～
階層主な役割例
７：アプリケーション層
６：プレゼンテーション層
５：セッション層
・ユーザインタフェース
・データエンコード/デコード
・ユーザ認証
HTTP
FTP
SMTP
４：トランスポート層・プログラム間通信
・データ転送保証
TCP
UDP
３：ネットワーク層・異なるネットワーク間通信
(ルーティング)
IPv4
IPv6
２：データリンク層・同一ネットワーク内通信
・エラー検出
Ethernet
CAN
１：物理層・隣接ノード間ビット転送
・機械的 / 電気的仕様策定
Ethernet
CAN

参考：ネットワークの”層”とは？
OSI参照モデル
ユーザデータ
アプリケーション層プレゼンテーション層セッション層
トランスポート層
ネットワーク層
データリンク層
アプリケーション間通信
・ポート番号
WAN
異なるネットワーク間ノード通信
・IPアドレス
・ルータ
同一ネットワーク内ノード通信
・MACアドレス
・スイッチ
33
ヘッダ
物理層
隣接ノード間通信
WAN

参考：ネットワークの”層”とは？
Q. OSI参照モデルの目的は？なぜ“層”に区切る？
A. 通信プロトコルの開発・改良の簡単化。本モデルに則って開発すれば、他の
層の既存のプロトコルの改変等を行う必要がない。またユーザにとっては使
用プロトコルの差替も容易
Q. OSI参照モデルの実際は？
A. モデルが複雑すぎることもあり、HTTPやTCP/IP等既存のプロトコルの多くは
、本モデルには基づかない。但し、モデルの概念自体は有用なのでよく引用され
る(例：「このプロトコルはレイヤ２相当」、「レイヤ３で障害が発生」、レイ
ヤ1/2/3デバイス(ハブ/スイッチ/ルータ)等)
Q. 各層の実体は？
A. 殆どの場合パケット中のヘッダ情報。これを駆使することで各層の機能を実現
Q. 車載ネットワークプロトコルをOSI参照モデルに当てはめると？
A. 例えばCAN/LINは、通信の機械的・電気的仕様及び同一ネットワーク内のノ
ード間通信を定め、かつ異なるネットワーク間での通信には関知しないので
、物理層かつデータリンク層に対応すると考えられる
34

Ethernet物理層概観
35
同心10BASE2 (現在ほぼ未使用)
10Mbs、1線、半二重通信
100BASE-TX Ethernet
100Mbs、ツイストペアx2組(4線)、全二重通信
ギガビットEthernet
1Gbs、ツイストペアx4組(8線)、全二重通信
BroadR-Reach
100Mbps、ツイストペアx1組(2線)、全二重通信
従来型
Ethernet
車載
Ethernet

ギガビットEthernetのバス状態
1
0.5
0
36
-0.5
-1
V
t
8ナノ秒
＝バス周波数62.5MHz
＝125Mシンボル/秒
PAM5
1シンボルで5通りの情報伝達
 4通り分:２ビットのデータ伝達
 1通り分:エラー訂正用
 (125Mシンボル/秒) ＊ (2ビット/シンボル) * 4組 = 1ギガビット/秒

BroadR-Reachのバス状態
1
37
0
-1
V
t
15ナノ秒
＝バス周波数33.3MHz
＝66.7Mシンボル/秒
PAM3
1シンボルで3通りの情報伝達
 2シンボルで9通り
 8通り分:3ビットのデータ伝達
 1通り分:データ転送終了記号
 (66.7Mシンボル/秒) ＊ (3ビット/2シンボル) * 1組 = 100Mビット/秒

Ethernetケーブル上には何が見える？
Q. CAN/LINと同じ様に、ケーブルにオシロをあてれ
ばEthernetフレームが見える？？
A. 見えることは見えるが、その理解/デコードは極
めて困難。なぜなら・・・
 BroadR-Reachは同一線上での全二重通信を実現。即ち２ノードが互い
38
に同時に送信し、信号が重なっていることがある
 各ノードのPHYのみが、両者を切り分けることが可能
(自分が何を送信したのか知っているので)
 スクランブル処理により、最終的にケーブル上に見えるシンボル(電圧)
の並びはランダムにみえる
 さらにActive Idle方式のため、フレーム皆無の状態でも常に、一見ランダム
なシンボルが流れ続けている

Power Over Ethernet機能
家電におけるPoE利用例
39
BroadR-Reach
でも利用可!
出典:Panasonic社資料
 電源用配線を簡単化
 コスト＆重量削減に貢献
 対応チップBCM59105
 4ポート、最大電力5W/ポート、最長500m

ネットワークトポロジ
スター型
40
出典:Continental社資料
 スイッチポート1個：ノード1個対応
 各ペアが、それぞれ独立して100Mbpsを実現
 CAN等とは異なり、フレーム間の衝突は発生しない

目次
41

第２層～データリンク層～
・ユーザ認証
HTTP
FTP
SMTP
TCP
UDP
IPv4
IPv6
・エラー検出
Ethernet
CAN
Ethernet
CAN

Ethernetフレーム
Ethernetネットワーク上におけるデータ輸送の基本単位
• MACアドレス：世界中の各ノードが持つ一意なアドレス(６バイト
≒280兆個)
• ブロードキャスト：送信先がFF:FF:FF:FF:FF:FFなら全ノードに同時送信
• マルチキャスト：先頭バイトのLSBが1なら特定のノードグループに同時送信
• ユニキャスト：先頭バイトのLSBが0なら特定のノード単体に送信
• EtherType：上位層プロトコルを指定(IPv4なら0x0800)
• CRC：フレーム全体に対するエラー検出。エラーならフレーム廃棄(
エラー回復はTCP等の上位プロトコルで行う)
43
送信先アドレス 06:05:04:03:02:01
送信元アドレス 01:02:03:04:05:06
Ether Type 0x0 800
データ 46-1500バイト
CR C ４バイト
ヘッダ

Ethernetフレーム(802.1Qオプション付き)
44
送信先アドレス 06:05:04:03:02:01
送信元アドレス 01:02:03:04:05:06
Ether Type 0x0 800
CR C ４バイト
802.1Q タグ 4バイト
802.1Qタグ(VLANタグ)
スイッチ内部にて利用。
単一Ethernetネットワークの仮想的な分割、
またフレーム転送の優先順位制御を行う。
AVB等のプロトコルが使用

スイッチとは
ヘッドユニット
スイッチ
45
360°カメラ
後部座席
ディスプレイ
スピーカー
LAN内ノード間の中継機器
 各ノードの直接の接続先
所属する層：レイヤ２
 Ethernetフレームヘッダのみを
モニタ、その上のIP等には関知
しない(ルーティングはレイヤ３
機器即ちルータの仕事)
スイッチ vs ハブ
 ハブは受け取ったフレームを単
純に全ポートに送信するのみだ
が、スイッチは必要なノードの
みに伝達(スイッチング)
ポート0
1 2 3

スイッチの動作
カメラ→ディスプレイへとフレーム送信する場合
MACアドレステーブルの構築方法
スイッチ
46
360°カメラ
後部座席
ディスプレイ
スピーカー
ポート0
1 2 3
１．カメラがディスプレイ宛にフレーム送信
２．スイッチはポート１にてフレーム受信
３．スイッチはフレーム内部の送信先MAC確認
４．スイッチはそのMACがポート２に対応することを、
MACアドレステーブルから確認
５．スイッチはフレームをポート２へと送信
６．ディスプレイがフレーム受信
１．任意のフレーム受信時、その送信元MAC及び受信ポ
ートを逐次記録
２．適当な時間が経てば自動的にテーブルが完成
(自分から全く送信しないノードは、通常存在しない)
※送信先MACがテーブルに未だ登録されていない場合は、
とりあえずブロードキャストしてフレーム伝達

スイッチの動作
スイッチ
47
360°カメラ
後部座席
ディスプレイ
スピーカー
ポート0
1 2 3
バッファリング
 受信したフレームを一時的に溜め
込むことで、バンド幅の異なるポ
ート間の通信実現(100M/1G/…)
 複数ポートから同時にフレーム送
受信可能
 ネットワークの事実上の帯域幅が増大
(右図では200Mbps)
VLANタグによるフレーム優先度制御
 IP電話やAVB等リアルタイム性の
高いアプリケーションで利用
エラーフレームの廃棄(CRCエラー)
100Mbps
100Mbps

スイッチの動作：デバッグツールとしての利用
２ノード間の通信をモニタしたい・・・
 スイッチの空きポートが利用できそう。しかしスイッチ
は通常、目的のノードにしかフレームを流さない
 スイッチのポートミラーリング機能を利用
 あるポート上の通信内容を、別のポート上へコピーして出力
48
しかし・・・
 もしスイッチがミラーリング未対応だったら？
 スイッチに自動的に廃棄されるエラーフレームも観たい場合は？
 そもそも空きポートが無ければ？

ソリューション：ネットワークタップ
49
タップ
モニタPC
 任意の２点間にタップを挟むことで、エラーフレームも含
めたトラフィックの解析が可能に
 ビットレベルでトラフィックをコピーするだけなので、レ
イヤ１機器といえる

当社製BroadR-Reach対応タップ：RAD-STAR
ノードA ノードB
ノードA→B
トラフィック
ノードB→A
トラフィック
RAD-STAR
BroadR-Reach
10/100 Ethernet
50
 マイクロ秒以下の遅延で、BroadR-Reach通信を標準
Ethernetへとコピー
 ２ノード間の、各方向の通信をそれぞれ分離して観測可能
 PCからの任意のフレーム送信も可能

デモ：Vehicle SpyによるEthernetフレームモニタ
51

目次
52

第３層～ネットワーク層～
・ユーザ認証
HTTP
FTP
SMTP
TCP
UDP
IPv4
IPv6
・エラー検出
Ethernet
CAN
Ethernet
CAN

Internet Protocol (1/4)
• RFC 791にて定義(IPv4)
• IPパケットフォーマット＆IPアドレス
• ゲートウェイ(ルータ)の動作
• IPアドレス：ノード識別用の一意な番号
MACアドレスとIPアドレスはどちらも一意、何が違うのか？
MACアドレス IPアドレス
利用範囲第２層、同一ネットワーク内通信第３層、異なるネットワーク間
通信
一意性世界で一意、ノードに刻印され不変世界で一意、だがノードへの
割当は動的に変更可能
割振方法ランダム
(ネットワーク機器ベンダ依存)
ノードの所在特定を容易にする
階層的割当
比喩住民票コード電話番号
（株）日本イントリピッド・コントロール・システムズ
231-0015 横浜市中区尾上町5-80 神奈川産業振興センター７階3号室
TEL:045-263-9294 FAX:045-263-9296 URL:http://intrepidcs.jp/

身近な例に基づくMACアドレスとIPアドレスの構造比較
MACアドレス
00 FC 70 01 02 03
ベンダID ランダム数値
 位置情報を一切含まないので、MACアドレスのみで
世界のどこかにあるノードを特定・通信することは極めて困難 (LAN内であればOK)
IPアドレス
202 232 86 11
アジア太平洋
(APNIC)
日本
(JPNIC)
IIJ
(ISP)
首相
官邸
住民票コード
01234567890
ランダム数値
電話番号
81 045 263 9294
日本横浜市通信事業者
番号
当社
オフィス
 世界のあらゆるネットワーク上のノードを特定する上で有用な階層構造を形成

送信先アドレス 06:05:04:03:02:01
IPパケット構造
送信元アドレス 01:02:03:04:05:06
Ether Type 0x0 800
CR C ４バイト
IPパケット
ヘッダ部
データ部

IPヘッダ構造
管理情報
(特にIP特有
ではない)
バージョン IPv4なら4で固定
ヘッダ長/全長 IPヘッダ長/IPパケット全体の長さ
プロトコル次の上位層プロトコルを指定(TCP等)
チェックサム IPヘッダの誤り検出用
拡張情報通常は未使用
ルーティング
情報(IP固有)
サービス種別パケットの転送優先順位
識別子/フラグ/断片位置パケットの分割・復元制御
生存時間パケットの生存時間(最大許容ホップ数)
送信元/宛先アドレス送信元、送信先のIPアドレス

デモ：Vehicle SpyによるIPパケットモニタ
58

議論：IPルーティング技術(ルータ)は
車両内のノード間通信で必要？
現状ではNo
しかしIPパケットは必要！
 XCP/診断/動画転送で用いるTCP/UDP等の
上位プロトコルが、IPを前提とするため
59
なぜなら車載では・・・
 ごく限られたノード数(将来的にも多くて～100)
 限られた物理的距離(LANケーブルで全て届く)
 もし特定のノード群を別ネットワークに隔離したいときは、スイッチ
付属のVLAN機能が使える
 極力余計なデバイスを増やしたくない(コスト増、伝達遅延増)

補足：IP on 非Ethernet
“層”の理解を深める上で、ある層のプロトコルを
別のプロトコルに置き換えて考えてみると有用
TCP/UDP
？
60
IP
トークンリング SONET RFC1149規格!

目次
62

第４層～トランスポート層～
・ユーザ認証
HTTP
FTP
SMTP
TCP
UDP
IPv4
IPv6
・エラー検出
Ethernet
CAN
Ethernet
CAN

UDP / TCP概観
• ポート導入によりプログラム間通信を実現
• 有名なポート：FTP = 20, HTTP = 80
• 車載では、単一ECU上で、診断用/XCP用/ECU間通信プロ
グラム用にそれぞれポートを割り振るなど
UDPとTCPの比較
UDP TCP
特徴コネクションレス型通信
・相手先応答確認なし
・データ到着確認なし
・データ到着順保証なし
コネクション型通信
・相手先応答確認
・データ到着確認
・データ到着順保証
・フロー/輻輳制御
メリット単純、高速高信頼性
デメリット低信頼性複雑、低速
例 VoIP、ビデオ会議ファイル転送、ウェブ閲覧

User Datagram Protocol
UDPヘッダ構造
IPパケットのデータ先頭部に以下を付加
送信元ポート番号
データ長
宛先ポート番号
チェックサム
送信元ポート番号宛先からの応答を受け付けるため、適当な番号を指定。
応答不要の場合はゼロ
宛先ポート番号宛先のポート番号。ウェブサーバプログラム宛なら80、
FTPサーバプログラムなら20など
データ長ヘッダ＋データの長さ
チェックサムヘッダ＋データの誤り検出

信頼性よりもリアルタイム性重視
• 車載カメラ
• 衝突回避、駐車補助、レーン逸脱回避、ドラレコ
• XCP on Ethernet
• エンジン制御など、高速で変化するデータの観測
• UDP/TCP双方サポート
66
車載におけるUDP利用例

デモ：Vehicle SpyによるUDPモニタ
67

Transmission Control Protocol
TCPヘッダ構造
送信元ポート送信先ポート
送信元/送信先ポート送信元/送信先のポート番号(UDPと同様)
シーケンス番号/確認応答番号送受信セグメントの抜け漏れ防止及び順序管理
フラグ SYN/ACK＆FIN/RST：通信確立＆終了時に利用
PSH/URG：直ちに送受信処理したいデータ用
NS/CWR/ECE：輻輳制御用
ウィンドウサイズ ACKを待たずに、連続して送信可能なデータ量
ヘッダ長/チェックサム TCPヘッダの長さ / ヘッダ＋データ誤り検出用
シーケンス番号
確認応答番号
ヘッダ
長
ウィンドウサイズ
チェックサム緊急ポインタ
オプション

Transmission Control Protocol
1. 通信確立
SYN=1
ACK=1, SYN=1
ACK=1
2. データ転送
100バイト
ACK=1
500バイト
ACK=1
300バイト
ACK=1
3. 通信終了
FIN=1
ACK=1
FIN=1
ACK=1
TCP通信フロー

リアルタイム性よりも信頼性重視
• XCP on Ethernet
• ECUフラッシュ
• DoIP
• ディーラーや工場における車両診断
• ECUフラッシュ
• UDP/TCP双方サポート
70
車載におけるTCP利用例

デモ：Vehicle SpyによるTCPモニタ
71

vs
よくあるご質問：Vehicle SpyでTCP/IPトラフィックを観ら
れるのはわかったが、Wiresharkとどう違うのか？
72
Vehicle Spy(＋当社製HW) Wireshark
Ethernetエラーフレーム
(CRCエラー)
検出及び保存可検出不可(スイッチ等
に捨てられてしまう)
車載プロトコル(CAN/LIN/…)
との同時解析・キャプチャ
可不可
データベース作成・保存機能有無
フレームのタイムスタンプ高精度(物理層からフレーム
取得直後にスタンプ)
低精度(OSを経由し
てからスタンプ)
フレーム作成・送信可不可
トラフィック表示モードスタティック/スクロールスクロールのみ

目次
 背景
 AVnuとは
 AVB規格紹介
 AVBの今後
73

背景
A/Vストリーム再生における要件
1. 複数ストリームの正確な同期・再生
 左右のスピーカから音がずれて聞こえる(音声ストリー
ムx2の同期失敗)、歌手の口と歌が合っていない(音声
ストリーム＆動画ストリームの同期失敗)などは論外
2. ストリーム転送の遅延が少なくかつ決定論的
 再生ボタンを押してからの反応が遅い、反応時間にブ
レがある、時々動画が止まる等(特に車載カメラでは問
題)
74

背景
LVDS(動画)
75
従来型A/V転送形式
１．Point-to-Point、接続機器が増えれば配線量も膨大に
２．プロプライエタリ、高価
３．家庭/プロ/車載用など分野ごとにバラバラの規格
HD-SDI(動画)
S/PDIF(音声)
Ethernetを使えば万事解決？

背景
規格追加
76
しかし標準のEthernetでは・・・
１．いつフレームが相手に届くか不明(スイッチ由来の遅延等)
２．プログラム(ストリーム)の使えるバンド幅不定、パケット損失も有
３．各ノードを時間同期する仕組みの欠如
１．タイミング保証：802.1Qav
２．ストリーム予約：802.1Qat
３．クロック同期：802.1AS
４．AVBシステム全体：802.1BA
まとめて “AV B”

AVB規格の属する層は？
IEEE 1722
IEEE 1722.1
77
Ethernet MAC(Ethernetフレーム)
Ethernet PHY
802.1AS
(gPTP)
802.1Qat
(SRP)
802.1Qav
(FQTSS)
アプリケーション
第２層
即ち・・・
 LAN内限定
 物理層は標準Ethernet
でもBroadR-Reach
でもOK
出典：Harman International(一部改変)
gPTP: generalized Precision Time Protocol, SRP: Stream Reservation Protocol
FQTSS: Forwarding and Queuing Enhancements for Time-Sensitive Streams

AVBシステム全体像
78
出典：Avnu資料改変
A/Vストリーム経路
上に１つでもAVB非
対応のノードがある
とNG

AVB利用例
出典：Avnu
79
車載カメラ
(ドラレコ/死角/駐車補助)
インフォテイメント
(動画＆音声/携帯との連携)

AVB用語集
80
Talker A/Vストリームの送信元ノード
・DVDプレーヤ、マイク
Listener A/Vストリームの送信先ノード
・スピーカ、LCDディスプレイ
Endpoint TalkerまたはListenerとなるノード
Bridge 一般的なスイッチと同義
“Either a MAC Bridge, as specified in Clause 5 of IEEE Std 802.1D-2004, or a VLAN-aware
Bridge, as specified in Clause 5 of IEEE Std 802.1Q-2005.”(802.1AS-2011より)
A/Vストリーム１つのTalkerから、１つまたは複数のListenerに対す
るA/Vデータの流れ
・車載カメラ⇨LCDディスプレイx1
・CDプレーヤ⇨スピーカx2

目次
 背景
 AVnuとは
 AVB規格紹介
 AVBの今後
81

AVnu Alliance (アヴニュー)
IEEE AVB規格と市場の橋渡し役
 AVBデバイスの試験・認証、各種技術情報提供
82

AVnu認証済み製品
83
Summit 440 / Extreme Networks
世界初のAVBブリッジ
2013/12認証
DCi 8|600ND / Harman
世界初のAVBエンドポイント
(プロ向けオーディオアンプ)
2014/06認証
車載向け製品は未だなし
(2014/09現在)

目次
 背景
 AVnuとは
 AVB規格紹介
 AVBの今後
84

802.1AS: generalized Precision Time Protocol
背景
エンドポイント
(スレーブ)
85
(グランドマスタ)
ブリッジブリッジ
(スレーブ)
(スレーブ)
ネットワーク経由での
A/V再生には各ノードの
正確な時刻同期が必須
gPTP
誤差1us以下の高精度同期実現

(スレーブ)
86
(スレーブ)
(スレーブ)
gPTP動作フロー
０．ネットワーク接続確立
１．各ノードが802.1AS対応であ
ることを確認
２．ノード間伝播遅延時間算出
３．グランドマスタ選出
４．グランドマスタが全ノードに
マスタクロック情報送信、各ス
レーブは伝達遅延を考慮して自
クロック補正

隣接ノード間伝播遅延算出の基本原理
t1
t4
t2
t3
Pdelay_Req
Pdelay_Resp
(t2,t3伝達)
１．ノードAは伝播遅延時間の算出
を要求するメッセージPdelay_Reqを
送信
２．ノードBはPdelay_Respメッセー
ジを返信(返信時刻t3及びPdelay_Req
の受信時刻t2を同梱)
３．ノードAは取得した(t1,t2,t3,t4)に
基づき片道の遅延時間Dを算出
D
D
片道遅延D = ((t4 – t1) – (t3 – t2)) / 2

より正確な”t3”取得のために・・・
t1
t4
t2
t3
Pdelay_Req
Pdelay_Resp
D
D
t3はひとまず記録しておき、 (t2伝達)
別のメッセージに載せて改めて送信
(Follow Upメッセージ)
Pdelay_Resp_Follow_Up
(t3伝達)
送信フレームの中に、そのフレーム
自身の正確な送信時間t3を入れるこ
とは困難
(フレーム送信開始と同時に定まるt3
を、どうフレーム内に入れる？？)

ノード間伝播遅延算出トラフィック例
t1
t4
t2
t3
Pdelay_Req
Pdelay_Resp
(t2伝達)
Pdelay_Resp_Follow_Up
(t3伝達)
片道遅延D =
((4.225169-4.225168) –
(13874.651720–13874.651689))/2
≒ 15us

グランドマスタによるクロック同期機構
グランドマスタの時刻を載せた
Syncメッセージを、全ノードに
周期的に送信(デフォルト125ms)。
各スレーブはマスタ時刻＆伝達遅延時間
に基づき自分の時刻を補正。
90
(スレーブ)
Sync
(スレーブ)
(スレーブ)
Sync
Sync
Sync Sync

グランドマスタのSyncメッセージトラフィック例
Sync(とFollow Up)メッセージが125msごと
にグランドマスタよりマルチキャスト
ここでも実際には、Follow Upメッセージが
Syncの正確な送信時間を伝達
91

92
パケット構造
Ethernetフレームのデータ部に格納
gPTPヘッダ
gPTPデータ
(Follow Upメッセージの場合(messageType=2))

802.1Qat: Stream Reservation Protocol
安定したA/V再生のため、各ストリームが
その経路上(Talker→Listener)において一定のバンド幅を確保
ブリッジ
93
出展：AVnu
Talker
Listener

①Talkerが、確保したいバンド幅を含むAdvertise(告知)メッセージを
Listenerに向けて送信
②経路上のブリッジは、自ポートの利用可能
バンド幅を確認。OKなら次のブリッジに
そのままメッセージを転送
(NGならTalker failedメッセージ転送)
③ListenerはAdvertise受信後、Listener
ReadyメッセージをTalkerへと送り返す
④TalkerはReadyメッセージ受信後、
ストリーム送信開始
※その後Talker/ListenerはAdvertise/Readyを
を周期的に送信し合い、通信状態を維持
94
SRPの動作フロー
② ②
①
②
②
③

95
送信先
MACアドレス
送信元 MACアドレス
Ether Type 0x22 EA
CR C ４バイト
802.1Qatパケット
ProtocolVersion Message Message ・・・・・・・・ EndMark
Attibut eType (Advertise等)
Attribute Length AttributeListLength
Attribu teList (Stream ID等)
パケット構造

802.1Qav: Forwar ding and Queuing Enhancements for Time-Sensitive Streams
SRPによってバンド幅を確保したとはいっても・・・
もし各Talkerのフレーム送信間隔に重大なムラがある場合、タイミング次
第ではブリッジにて輻輳が発生しうる (例えば複数Talkerが”10Mbps”を確保
しておいて、0.9秒間待機、次の0.1秒にて10Mビットを１つのブリッジへと
一気に放出)
 フレーム損失、不安定なフレーム遅延によるA/V品質の劣化
FQTSS
Talker及びブリッジの送信フレーム間隔を125us単位で平滑化(Class Aの場合)
 フレームがListenerに届くまで、７ホップで最悪2msの遅延を保証
 125usのうちA/Vストリームは93.75us(75%)、制御信号等の非A/Vデータ
は31.25us(25%)確保

TalkerがA/Vストリームx1を送信する場合のTalker内部動作例
このキューの
クレジット値
A/Vフレームが
キュー入り
クレジット≧0なので
A/Vフレーム送信
非A/Vフレーム送信完了
後、クレジット≧0なの
で直ちにA/Vフレーム送
信開始
※Avnu.org資料を改変
125us
非A/Vフレーム
あるA/V
ストリーム
のキュー
送信中
フレーム
時間
ルール概要
✔クレジット初期値０
✔クレジット≧0ならA/Vフレーム送信
✔ A/Vフレーム送信中はクレジット減少
、待機中は上昇
(それぞれ傾きsendSlope, idleSlope)
A/Vフレームが
キュー入り
Credit-based Faire Queuing：クレジット値に基づくキューイング

FQTSSパケット定義：なし
・なぜならFQTSSは、与えられたパケットをいかにムラなく送信
するか、というデバイス内部の動作を定めるプロトコル。送り出
すパケット内容自体の定義は行わない。
Ethernetトラフィック解析の観点からすると・・・
・各A/Vストリームのパケットが約125us周期となっていれば、
FQTSSが”みえている”といえる(Class Bなら250us)

AVBの上位プロトコル
これまでのプロトコルの組み合わせで、A/V用の安定したデータ転送が可能に
 では実際のA/Vデータをどうフレームに詰める？
 どうAVB対応デバイスを発見・制御する？
IEEE 1722.1
IEEE 1722
99
Ethernet MAC(Ethernetフレーム)
Ethernet PHY
802.1AS
(gPTP)
802.1Qat
(SRP)
802.1Qav
(FQTSS)

IEEE 1722: AVB Transport Protocol
• 各種A/V形式のEthernetフレームへのカプセル化
• MPEG2-TS(動画+音声) / AM824(音声) / MIDI等
• A/Vストリーム同期機構
100
Talker ブリッジ
1
Listener
(左スピーカ)
Listener
(右スピーカ)
プレゼンテーション時刻の利用により、
例えばパケット到達時刻の異なる
左スピーカ/右スピーカの同期再生を実現
ブリッジ
2
ブリッジ
3
ブリッジ
6
ブリッジ
5
ブリッジ
4

プレゼンテーション時刻
＝各Listenerが、Talkerから受け取ったA/Vパケットを
再生する共通時刻
＝Talkerからのパケット送信時における共通時刻＋2ms
※共通時刻＝gPTPにより確立されたグランドマスタ時刻
※SRP+FQTSSにより７ホップで最悪2msの遅延保証
Talker
(音楽プレーヤ)
ブリッジ
1
Listener
(左スピーカ)
③ぎりぎりでパケット
到着、すぐに再生！
Listener
(右スピーカ)
ブリッジ
2
ブリッジ
3
ブリッジ
6
ブリッジ
5
ブリッジ
4
①今の時刻の遅くとも2ms後にはこの
パケットが行き渡ってるだろう・・
(パケット送信)
②パケットが着いたけど、
まだプレゼン時刻までは
だいぶ間があるので待機

パケット構造
出典：Harman International
102
標準のEthernetヘッダ
AVTPパケット

パケットヘッダ及びデータ部分
103
A/Vストリーム
共通データ構造
AVTP共通ヘッダ
avtp_timestamp (プレゼンテーション時刻)

IEEE 1722.1 : Audio Video Discovery, Enumeration,
Connection management, and Control for AVTP devices
1722対応A/Vデバイスの管理用プロトコル
• Talker/Listener、両者を管理する”Controller”の３者を定義
• Controllerは物理的に別のノードでも良いし、Talkerまたは
Listenerが二役をこなしてもよい
AVDECCを構成するプロトコル
104
1. デバイス検出
AVDECC Discovery Protocol
2. デバイス接続状態管理
AVDECC Connection Management Protocol
3. デバイス機能検出＆制御
AVDECC Enumeration and Control Protocol

１．AVDECC Discovery Protocol
ネットワーク上の1722対応ノードを検出
• 各ノードは、ENTITY_AVAILABLEメッセージを
周期的(デフォルト約15秒)に送信し自身を告知
• ENTITY_DISCOVERメッセージを、ネットワーク上の
全ノードまたは特定ノードに送信することで
ENTITY_AVAILABLEメッセージを直ちに送信させる
ことも可能
105

１．AVDECC Discovery Protocol
106
IEEE 1722 AVTPパケット
のデータ部にパケット格納
ADPパケット

２．AVDECC Connection Management Protocol
Talker⇔Listener間の接続・切断を管理
• ノード間でのコマンド送信→応答による制御
• ListenerがTalkerにCONNECT_TX_CONNECT送信、
Talkerから無事RESPONSEを受け取れば接続完了
(Fast Connectモード。Controllerを介した接続方法もある)
107

ACMPコマンド一覧
108

ACMPパケット
109

３．AVDECC Enumeration and Control Protocol
1722対応ノードの各種機能やA/Vフォーマットの検出・設定
• Controllerからのコマンド送信→ノードからの応答
• 動画フォーマットの取得/設定
(アスペクト比、フレームサイズ等)
• サンプリングレートの取得/設定
• ミキサー情報の取得/設定
• ストリーミングの開始/停止
110

AECPコマンド一覧
111
AECPの主要コマンド
ファームウェア書換等に利用

AEM_COMMANDコード抜粋(計74個)
112

AECPパケット
113

まとめ
IEEE 1722.1:A/Vデバイス制御
IEEE 1722:A/Vパケット転送
802.1Qav:パケット転送間隔制御
Ethernet MAC
Ethernet PHY
IEEE 1722.1:A/Vデバイス制御
IEEE 1722:A/Vパケット転送
802.1Qav:パケット転送間隔制御
Ethernet MAC
Ethernet PHY

IEEE P1722A
IEEE 1722の機能を拡張
 車載プロトコルサポート：CAN, LIN, FlexRay
 新たなA/V形式サポート：H.264, MJPEG, …
 ネットワーク障害検出、データ暗号化、…
115
2014/09現在、
標準化進行中！

補足：AVBにおけるオーディオ
ストリームのバンド幅計算ウェブアプリ
abc.statusbar.com
116
条件を入力
して計算

目次
 背景
 AVnuとは
 AVB規格紹介
 AVBの今後
117

AVBの今後
これまで観てきたAVBは実は”初代AVB”(AVB Gen 1)
 用途はA/Vにほぼ限定
118
AVB Gen 2
自動車制御”も”実現すべく、
更なる超低遅延・高信頼性を追求
P802.1ASbt：802.1ASの強化
P802.1Qbv：802.1Qavの強化
P802.1Qbu：パケットの割込(新機能)
→100us@５ホップ等を目標(2015年仕様完成？)

AVBの今後：Ethernetの採用拡大予想
MOST置換
119
FlexRay置換
現在
中期
長期出典：Avnu

デモ：当社BroadR-Reach製品による
Ethernetネットワーク構成＆解析
120

Automotive ethernet training_jp

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (8)

Similar a Automotive ethernet training_jp

Similar a Automotive ethernet training_jp (20)

Automotive ethernet training_jp