1August 2013

Technical Article

SOME/IPネットワークの残りのバスシミュレーションに対する新たな視点

本稿では、SOME/IP (Scalable Service-Oriented Middleware on Ethernet/IP) を例に取り上げ、動的なサービス指向のIPネットワークで残りのバスシミュレーション [1] がどのように実施されるのかを説明します (図1)。その後、メディアアクセス、同期、管理下におけるスティミュレーション [2] をそれぞれの面から論じ、そこから導かれる開発システムのための推奨事項を説明します。

SOME/IPの例を基にしたサービスプロトコルの使用

EthernetおよびIP分野のプロトコルには膨大な数の選択肢があり、想定される用途のいずれにも、すでに直接利用できるプロトコルが存在するように思われます。しかし、車載ネットワークは白紙の状態から作り始めるわけではなく、初めからある特定の要件が求められます。たとえば、使用するプロトコルは既存のシステムに組み込まねばなりません。これは特に、AUTOSARと円滑に統合できるか、そしてエラー発生時の反応時間を速め、遅延を短

縮できるかに関わってきます。BMW AGは車両での要件を満たすオープンプロトコル、SOME/IPを開発し、その仕様を策定しました。SOME/IPをECUで使用するためのTCP/IPスタック、Service Discovery、BroadR-Reach Ethernetドライバーといった実装は、ベクターから提供されています。

SOME/IPはサービス指向通信用のインターフェイスを提供しますが (図2)、この点がCANなどで通常用いられる純粋なシグナルベースの通信と大きく異なります。SOME/IPはService Discovery (SD)、Remote Procedure Call (RPC)、プロセスデータへのアクセスの3つの領域に大別できます。SDの領域では、ECUはネットワーク内でサービスを探索し、また自らのサービスを提供します。ユーザーはSDで提供されたメソッドをRPCを介して利用します (図3、パートA)。また、特定のイベントに対する通知を設定することも可能です (図3、パートB)。アプリケーションは読取および書込関数を使用して任意のプロセスデータにアクセスできます (図3、パートC)。SOME/IPの目的は、与えられた帯域幅

～車載IPネットワークの要素を検証～

BroadR-ReachベースのEthernetはすでに車載カメラで実用化されており、今後、他の分野への応用拡大も見込まれています。専用の開発ツールで、異種混合ネットワークの通信を時間同期して表示することも可能です。車載IPネットワークは静的なCAN通信とは対照的に、帯域幅を効率的に利用できるよう、動的かつサービス指向の構成となっています。そのため、開発ツールにもSOME/IPなどのサービス指向プロトコルへの対応が求められます。

2August 2013

Technical Article

を最適に利用して、極めて柔軟な通信を実現することにあります。通信とシグナルはFIBEX 4.1以降か、AUTOSARリリース4.1以降を用いて記述されています。残りのバスシミュレーションにおいては、SOME/IPはプロトコル

とミドルウェアの複合体として、その自由度を如何なく発揮します。ユーザー側の手間を最小限に抑えるため、残りのバスシミュレーションの多くの部分は自律的に構成されますが、これに必要になるのがFIBEX 4.1やAUTOSARといった標準化された記述フォーマットの使用です。これによってユーザーは、シグナルに直接アクセスできるようになります。ただし、テストを実行する際、たとえばエラーケースの呼び出しを行う場合などでは、構成を手動で上書きした方がよいでしょう。

テストツールのための柔軟なネットワークアクセス

残りのバスシミュレーションをはじめとする複雑なタスクを、テストツールが可能な限り最適に実施するには、そのアプリケーションが物理メディアに柔軟に、かつ高いパフォーマンスでアクセス可能であることが求められます (図4、残りのバスシミュレーション)。開発者は、このアクセスを使用して、ネットワーク上でエラーケース (CRCエラーなど) を生成できなければなりません。2ノード間の接続解析に主眼を置くのであれば、透過的で干渉のないアクセスを実現するための特別な手段が必要となります。なぜなら、Open Alliance BroadR-Reach (OABR) は理論上はバスシステムであるものの、電気的にはP2P接続であるためです。もちろん、システムで用いるスイッチ上の追加のモニターポート

を使用すればこの問題は解決しますが、コスト上の理由から、量産用のシステムでこの方法を採れるとは限りません [3]。スイッチはミラーリングと呼ばれる方法を使用し、受信した全パケットをモニターポートに転送します。この方法には、受信したデータパケット

がタイムスタンプを持たず、共通の時間基準がないというデメリットがあります。また、多くの場合は有効なパケットのみがモニターポートに転送されるため、エラー解析も困難です。解析中のネットワークにほとんど影響を与えないメディアアクセ

スは、いわゆるTAP (Test Access Point) で実現されます [2]。このTAPは標準のスイッチとは異なり、2ノード間の通信に影響を及ぼすことなく、Ethernetネットワークの透過的な解析を可能にします (図4、フレキシブルTAP)。TAPは以下の要件に応じて、2種類のモードで運用されます。

> 純粋にパッシブな動作モード。このモードでは遅延時間を短く一定に維持できますが、メディア上に流れるデータの監視しかできません

> アクティブなモード。追加データを既存の接続に注入できます

図2： SOME/IPはキャリブレーション用のインターフェイスを提供

図1： Ethernetネットワークが含まれた異種混合ネットワークアーキテクチャーの抜粋

3August 2013

Technical Article

ただし、フロー制御が必要になるため、アクティブ接続は物理層 (OSI Layer 1) 上では不可能です。フロー制御はLayer 2以降でなければ利用できません。しかも、フロー制御では一定した遅延時間は保証できません。どの方法を選ぶにせよ、パケットデータの正確な解析には、物理層にできるだけ近い部分で取得した精密なタイムスタンプが必要です。多くの場合、ネットワーク解析で対象とするバスは1つのEthernetに限らず、他の車載ネットワークもその対象に含まれます。そのため、これらのタイムスタンプには他のインターフェイスとの同期が必要です。

開発ツールの選択

開発者は上記の考慮事項に基づき、次の5点を確認したうえで開発ツールを選択する必要があります。

> その開発システムはSOME/IPなどのサービス指向通信に対応しているか

> その開発システムでは、ログ記録機能を提供し、プロトコル違反あり/なしの両環境で、管理下でのスティミュレーションを行えるか

> その開発システムでは、OABR、CAN、FlexRay、MOSTなどの一般的な車載ネットワークへのアクセスが可能か

> インターフェイスはミラーリング用のTAPとして、またコンバーター/スイッチとして、柔軟に使用できるか [2]

> インターフェイスで異種混合ネットワークをサポートする場合、一般的に使用されるバスシステムやIPネットワークとの同期は可能か

開発ツールのCANoe.IPは、ベクターのVN5610 Ethernet/CANインターフェイスの使用により、これらの機能のすべてに対応します。そのため、これはすでに一部の自動車メーカーやサプライヤーで使用されています。

展望

IPベースのサービス指向通信は大きな発展を遂げています。カメラのアプリケーションに使用された後、Ethernetはインフォテインメント分野に使われ、次はバックボーンなどの他のシステム分野にも使われていくことが見込まれます。車載ネットワークの開発者にとって、マルチバス機能、残りのバスシミュレーション、全データパケットに対する低レベルのタイムスタンプといった機能の重要性は、今後も高まっていくことでしょう。

本稿は2013年4月にドイツで発行されたAutomobil Elektronikに掲載されたベクター執筆による記事を和訳したものです。

図4： 多様なアプリケーションで使用されているベクターのVN5610インターフェイス

図3： SOME/IPでは、RPC、通知、読取/書込関数などの多様なアクセスが可能

4August 2013

Technical Article

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部 （東京） TEL：03-5769-6980 FAX：03-5769-6975 （名古屋） TEL：052-238-5020 FAX：052-238-5077

E-Mail：sales@jp.vector.com

Hans-Werner Schaal (Dipl.-Ing.)Vector Informatik GmbHのビジネスディベロップメントマネージャーとして、Ethernet、Car2x、オープンCANプロトコル (J1939、ISOBUSなど) の分野を担当。

Matthias Schwedt (Dipl.-Ing. (FH))Vector Informatik GmbHでEthernet、FlexRay、MOST150のネットワークインターフェイス用FPGAの開発に携わる一方、VN56xxのEthernetネットワークインターフェイスファミリー全体のプロジェクトリーダーも担当。

Peter Fellmeth (Dipl.-Ing. (FH))Vector Informatik GmbHのグループリーダーおよびプロダクトマネージャーとして、Ethernet、J1939、ISOBUS分野での製品開発と顧客固有のプロジェクトを担当。

執筆者：参考文献：

[1] Schnelle Wege zur Restbussimulation: Virtuelle Netzwerke ohne Pro grammier-Know-how erstellen (“Quick paths to the remaining bus sim ulation: Creating virtual networks without programming know-how”), Stefan Albrecht and Peter Decker, Automobil Elektronik 03/2012[2] Neue Werkzeuge für Automotive Ethernet (“New tools for automotive Ethernet”), Hans-Werner Schaal, Matthias Schwedt, Hanser automotive 3-4/2013[3] Herausforderungen von Ethernet-Debugging (“Challenges of Ethernet debugging”), Helge Zinner, www.elektroniknet.de, October 2012

提供元：見出し画像/図1～ 4：Vector Informatik GmbH

リンク：ベクターのIP/Ethernetソリューションhttp://vector.com/vj_ip_ethernet_solutions_jp.html

ベクター･ジャパンhttp://www.vector-japan.co.jp