CONTENTS
発行元： ベクター・ジャパン 株式会社 〒140-0002 東京都品川区東品川2-2-20 天王洲郵船ビル16F 2014年11月発行©2014 Vector Japan Co., Ltd. 不許複製
02
22
06
10
14
18
26
30
54
Magazine For Vector’s Technology
V
ector
J
ournal
Vol.
9
02
06
10
14
18
22
Cover Story
Tier4 Interim
に対応した
ECU
の開発とテストに「
CANape
」を活用
Technical Article
Car2x
アプリケーションのテスト
～道路工事警告の警告システムのためのテストツールの要件～大型車両と
AUTOSAR
～J1939
のAUTOSAR
への統合～遠隔地からの診断
～世界中の車両をインタラクティブに診断～CANoe
と
VT
システムを用いた
CHAdeMO
充電器検定器の開発
SOME/IP
ネットワークの
残りのバスシミュレーションに対する新たな視点
～車載IP
ネットワークの要素を検証～Vector Report
ベクター・リポート： 「ベクターが
Ethernet
対応を加速」
Vector Academy
はじめての
CAPL
News from Vector
測定、キャリブレーションから診断まで
幅広いタスクを効率化するベクターソリューション
包括的なツールサポートでECUキャリブレーションを簡単に。 ECUキャリブレーション用の万能ツール「CANape」なら、あらゆるタスク に対応できます。>
CCP、XCP-on-CAN、FlexRay、Ethernet経由あるいは外部テスト機器 からの測定データを、素早く確実に、時間同期でリアルタイムに取得可能>
ECUアルゴリズムのパラメーターを、オンラインもしくはHEXファイル のオフラインキャリブレーションで最適に調整>
トレーサビリティーを確保しながら大量のキャリブレーションデータを 簡単に管理でき、大規模なプロジェクトチームをも強力にサポート>
シームレスに統合された診断サービスとフラッシュソリューションで、お客様 のツール環境をシンプル化>
ラピッドプロトタイピングソリューションやMATLAB/Simulinkとの統合 を実現するベクターのツールチェーン ベクターは、機能開発から量産ECUまで、開発現場やテストベンチ、 実車試験などあらゆるシーンでお客様をサポートします。ECUキャリブレーションに関する情報：
www.vector-japan.co.jp/ecu-calibration
Testing ECU Diagnostics Distr. Systems Development Consulting Te chnical Software ECU Calibration ECUECU
キャリブレーション
www.vector-japan.co.jpIn
fo
rm
at
io
n
製品の購入／見積りに関するお問い合わせ 東 京 TEL : 03-5769-6980 名古屋 TEL : 052-238-5020 E-mail : sales@jp.vector.com ［組込ソフトウェア関連製品］ TEL : 03-5769-7808 E-mail : EmbeddedSales@jp.vector.com 技術関連のお問い合わせ ［各種ソフトウェア・ハードウェア製品］ ■ カスタマーサポート TEL : 03-5769-6971 E-mail : Support@jp.vector.com ［組込ソフトウェア関連製品］ ■ ホットラインサポートサービス 東 京 TEL : 03-5769-6972 名古屋 TEL : 052-238-5014 E-mail : EmbeddedSupport@jp.vector.com 各種トレーニングに関するお問い合わせ TEL : 03-5769-6973 E-mail : Training@jp.vector.com 本誌定期購読についての詳細は ベクター・ジャパンのWeb
サイト（下記URL
）までwww.vector-japan.co.jp/vj_vector_journal_jp.html
Vector Journalについて 「Vector Journal」は、ベクター･ジャパンが発行する広報誌です。原則として5月 および11月頃の年2回定期的に発行しています。お客様の事例を中心に、新しい 技術動向やベクターの新製品などに関する情報をご紹介しており、無料で ご購読いただけます。AUTOSAR
り>
DaVinci
りRuntime Environment (RTE)
>
MICROSAR
AUTOSAR 4.x
3.2
>
AUTOSAR
ECU
豊かな経験と実績に根差した製品をお届けするベクターが量産AUTOSAR
ECU
開発時のスマートなソリューションをご提供します。AUTOSAR
ソリューションに関する情報：www.vector-japan.co.jp/autosar-solutions
AUTOSAR
ソリューション
AUTOSAR 4.x
対応
ECU
の
開発をスムーズに
CONTENTS
発行元： ベクター・ジャパン 株式会社 〒140-0002 東京都品川区東品川2-2-20 天王洲郵船ビル16F 2014年11月発行©2014 Vector Japan Co., Ltd. 不許複製
02
22
06
10
14
18
26
30
54
Magazine For Vector’s Technology
V
ector
J
ournal
Vol.
9
02
06
10
14
18
22
Cover Story
Tier4 Interim
に対応した
ECU
の開発とテストに「
CANape
」を活用
Technical Article
Car2x
アプリケーションのテスト
～道路工事警告の警告システムのためのテストツールの要件～大型車両と
AUTOSAR
～J1939
のAUTOSAR
への統合～遠隔地からの診断
～世界中の車両をインタラクティブに診断～CANoe
と
VT
システムを用いた
CHAdeMO
充電器検定器の開発
SOME/IP
ネットワークの
残りのバスシミュレーションに対する新たな視点
～車載IP
ネットワークの要素を検証～Vector Report
ベクター・リポート： 「ベクターが
Ethernet
対応を加速」
Vector Academy
はじめての
CAPL
News from Vector
測定、キャリブレーションから診断まで
幅広いタスクを効率化するベクターソリューション
包括的なツールサポートでECUキャリブレーションを簡単に。 ECUキャリブレーション用の万能ツール「CANape」なら、あらゆるタスク に対応できます。>
CCP、XCP-on-CAN、FlexRay、Ethernet経由あるいは外部テスト機器 からの測定データを、素早く確実に、時間同期でリアルタイムに取得可能>
ECUアルゴリズムのパラメーターを、オンラインもしくはHEXファイル のオフラインキャリブレーションで最適に調整>
トレーサビリティーを確保しながら大量のキャリブレーションデータを 簡単に管理でき、大規模なプロジェクトチームをも強力にサポート>
シームレスに統合された診断サービスとフラッシュソリューションで、お客様 のツール環境をシンプル化>
ラピッドプロトタイピングソリューションやMATLAB/Simulinkとの統合 を実現するベクターのツールチェーン ベクターは、機能開発から量産ECUまで、開発現場やテストベンチ、 実車試験などあらゆるシーンでお客様をサポートします。ECUキャリブレーションに関する情報：
www.vector-japan.co.jp/ecu-calibration
Testing ECU Diagnostics Distr. Systems Development Consulting Te chnical Software ECU Calibration ECUECU
キャリブレーション
Cover Story
Tier4 Interimに対応した
ECUの開発とテストに「CANape」を活用
建設機械分野で世界をリードするコマツは、ECU の開発とテストにベク
ターの「CANape」を導入しました。日米欧で定められた厳しい排ガス規制
（Tier4 Interim）に対応した建機の開発に「CANape」を全面的に活用し、
計画どおりのスケジュールで製品化を実現。合わせて、品質の向上や社内テス
ト環境の統一化などを果たしています。
電子化と情報化で
建機業界をリードするコマツ
建設機械にも電子化および情報化の波が押 し寄せています。ブルドーザーや油圧ショベル に代表される建機には武骨かつ重厚なイメージ が付きまといますが、燃費の向上、排ガス規制 への対応、施工や運転の自動化、あるいは建機 車両の遠隔監視などに対応するためにも、もは や電子化および情報化は不可欠になっています。 そのような電子 化および情 報 化で業 界を リードしているのがコマツです。農業や除雪な どに使われる小型建機から、鉱山で使われるよ うな超大型建機までを幅広くラインアップする コマツでは、世界初となるハイブリッド油圧ショ ベルの商用化、建機の遠隔監視サービスである 「KOMTRAX
」の提供、鉱山向け超大型無人ダ ンプトラックや無人運転管制サービスの提供、 掘削と整地を自動的に行う「情報化建機」の実 用化など、先進的な取り組みを進めてきました。 ただし、こうした電子化や情報化は建機や関 連サービスの付加価値向上につながる一方で、 ソフトウェアの開発負担が増してきたと、同社 開発本部システム開発センタのメカトロ制御第 一グループで主任技師を務める石河浩一氏は 指摘します。とくに課題になっていたのがECU
のテストでした。石河氏は、「ツールを自作して いるなど測定方法が機種や工程ごとに異なって いる状況の中、テスト項目は加速度的に増大し ていくことが予想された」とかつての状況を振 り返ります。 同社でECU
のテスト環境を見直すべきとの 機運が高まっていましたが、大きなきっかけと なったのが排ガス規制への対応でした。2011
年施行の排ガス規制への
対応を進める
建機（オフロード特殊自動車）においても一般 の乗用車と同じように排ガス規制が定められて います。なかでもコマツで課題となったのが、2011
年施行の「Tier4 Interim
（米国）と呼ばれ」 る規制への対応でした。「Tier3
」と呼ばれてい たそれまでの規制に比べて、粒子状物質（PM
） を1/10
近くに削減する必要があるなど、「Tier4
Interim
」ではとても厳しい規制値が定められて いたからです。 「Tier4 Interim
の規制は非常に厳しく、また 燃費低減など様々な課題を解決するため、エン ジンだけでなく車体全体の最適制御を行う新 しい電子システムの開発やテストはこれまでに なく複雑化することが予想でき、効率的なツー ルの導入がどうしても必要でした」（石河氏）。 なお「Tier4 Interim
」に相当する規制は、EU
においては「Stage III B
」、日本においては「改正 オフロード法」（「 特定特殊自動車排出ガスの規 制等に関する法律」）としてそれぞれ定められて いて、規制適用日以降の新型車はこれらをクリ アしていないと販売することができません（図1
）。ECU
のテスト環境として
ベクターの
CANape
を選定
コマツはECU
の開発およびテストの効率化 を図るべく、2006
年初頭からテストツール（MC
ツール＝Measurement
およびCalibration
） の選定を開始しました。これまで工程ごとにば らばらだったテスト方法の反省を踏まえて、十分 な機能が統合され、かつ、最新テクノロジーへ のアップデートや技術サポートが期待できる市 販ツールを導入する方 針を掲げ、複 数のMC
ツールを評価・検討した結果、最終的に選定さ れたのがECU
の測定／キャリブレーション／診 断 ツ ー ル で あ る ベ ク タ ー・ジ ャ パ ン の 「CANape
」でした。 選定の最大のポイントは、ECU
マイコンに対 応したXCP
（キャリブレーション・プロトコル）の 無償のドライバーとサンプルが揃っていたこと だったと石河氏は述べています。「ベクター以外 のソリューションも 検 証を 試 みましたが 、す ぐに動き出したのがCANape
でした。Tier4
Interim
に対応した建機をスケジュールどおり 製品化するにはECU
をできるだけ早期に完成 させておく必要があり、テスト環境の構築に時 間を掛けられないという制約があったなかで、 その点を高く評価しました」（同氏）。 また、リンカーマップファイルを直接扱える 「ASAP2 Editor
」が標準で搭載されているこ と、CAN
バスのデータロガーなどのオプション が充実していること、ツールが日本語化されて いて社内ユーザーにとって使いやすいと判断さ れたことなども選定理由になったそうです。 「CANape
」は2007
年中頃に正式導入され たのち、社内ユーザー向けのマニュアルの整備、 技術情報共有を目的とした社内掲示板の開設、 ソフトウェア開発者へのトレーニングとテストエ ンジニアへの普及などを経て、本格的な利用が スタートしました。単体テストから耐久テストまで
CANape
を幅広く活用
コマツにおける「CANape
」の活用方法をい くつか紹介しましょう。もっとも基本的な使い 方がECU
ソフトウェアの品質確認です（図2
）。 単体または複数のECU
をCAN
バスに接続し て お き、ECU
入 力 の 変 化 に 応 じ た 挙 動 を 「CANape
」でモニタリングして、動作が正常か どうかを確認します。1996
年 開始規制2001
年 開始規制2006
年 開始規制2011
年 開始規制2014
年 開始規制 日本JAPAN
平成8
年 規制 平成13
年 規制 平成18
年 規制 平成23
年 規制 平成26
年 規制 米国US
Tier1
Tier2
Tier3
Tier4
interim
Tier4
final
欧州
EU
StageI
StageII
StageIIIA
StageIIIB
StageIV
図1：建機を対象にした排ガス規制して利用しているそうです。
排ガス規制対応建機の開発を
予定通り完了
石河氏は、「CANape
」の導入でもたらされた もっとも大きな成果は、多数の「Tier4 Interim
」 対応の開発の中で、予定通りにECU
開発を完 了することが出きたことだと述べています。 「CANape
を導入したことにより、複雑に絡み 合った問題の要因を解析・特定する力が向上し ました。これは開発をスケジュール通り進めて いくことに大きく貢献したと思います。」（同氏）。 また、ECU
を通して車体全体の挙動がより詳 しく判るようになったことで、品質の向上にもつ ながったそうです。テスト環境やテスト方法が 社内で統一されたことも導入メリットのひとつ 実車両試験では、圧力センサーや速度セン サーなどの情報は既存の測定環境で取得し、ECU
の挙動のみを「CANape
」でモニタリング し、得られたMDF
（Measur ement Dat a
Format
）ファイルをデータ解析ソフトに与えて、 センサーの状態とECU
の挙動とを同期させな がら解析を行いました（図3
）。 試作車両の耐久性を確認する長時間試験で は、CAN
デ ー タロガ ーで あ る「CANcaseXL
log
」を被試験車両に搭載してCAN
バスの状態 をロギングし、試験終了後に「CANape
」にデー タを移してオフラインにて測定データの解析を 行っています（図4
）。 モデルベース開発にも「CANape
」を応用し ています。「CANape
」で実測した実車両データ を車体モデルとの比較に使用や、同じく実車両 データをシミュレーション環境の入力データと に挙げられます。なお、ベクター・ジャパンの技 術サポートはとても満足のゆくものだったと、石 河氏は対応を評価しています。 今後は、テストの高度化をさらに進めて製品 のさらなる品質向上に反映していくとともに、HILS
やSILS
との連携も検討していく考えです。 電子化および情報化を推し進めるコマツ社 内では、「Tier4 Interim
」よりもさらに厳しい 「Tier4 Final
」規制に向けた開発がすでにスター トしています。ECU
の開発とテストの現場でこ れからも「CANape
」が活躍してくれるに違いあ りません。 図2： コントローラソフトウェアの品質確認の構成 図3： 既存計測設備を使ったセンサー測定と CANapeを使ったECU測定との連携本件を振り返って
コマツ 開発本部システム開発センタ メカトロ制御第一グループ 主任技師 石河浩一 氏 「CANape
の高度な機能、既存環境との連 携のしやすさ、およびベクター・ジャパンの的確 なサポートによって、導入と社内への普及を短 期間のうちに進めることができました。結果と してECU
の開発およびテストの効率化と製品 品質の向上が得られるなど、CANape
の導入 によって多くのメリットがもたらされたと考えて います。将来は、通信回線を利用した遠隔での データ収集機能や、CAN
バスと外部カメラ映 像との同時記録機能など、CANape
のさらなる 進化を期待しています」 図3： 既存計測設備を使ったセンサー測定と CANapeを使ったECU測定との連携 ベクター・ジャパン株式会社 営業部 東京営業部長 佐藤 邦彦 「CANape
をコマツ様の開発効率化に役立 てていただくことができ、大変嬉しく思っており ます。今後も先進的な自動車開発業務の効率 化に役立つツールをユーザーの皆様の声を聞 きながら提供して参りたいと思います」 画像提供元： 表紙および図1∼4：コマツCover Story
Tier4 Interimに対応したECUの開発とテストに「CANape」を活用
図4： 耐久試験における ロガーを使った CANバスの長時間測定T
e c hnic al
A r t ic le
1
複数の自動車メーカーが、
2015
年に
Car2x
通信の量産車への導入開始を計画しています。
すでに始まっている
Car2x
のアプリケーション開発は、コンポーネントテストとアプリケーショ
ンテストの実施という新しい課題をもたらしています。本稿では、
Car2x
の「道路工事警告」
アプリケーションの例を基にしたテストツールの関連要件を取り上げます。
Car2x
アプリケーションのテスト
～道路工事警告の警告システムのための
テストツールの要件～
Car2x
アプリケーションのテスト
Technical
A
rticle
1
2 3 4 5 知 的で 安 全 ― ドイツ連 邦 交 通 相は、今 年(2013
年) 6
月中 旬、将 来 の高 速 道 路につ いてこのように表 現しました。Car2x
通 信に 基づいた高 度 道 路 交 通システムとサービス （C-ITS: Cooperative Intelligent Transport
Systems
）の導入によって、これらの目標は達成 されようとしています。Car2x
とは、より安全な 道路交通と交通渋滞の早期回避を目的とした、 車両とインフラストラクチャー間の通信です。 最初のステップとして、警告用トレーラーに、車 両への道路工事情報を無線伝送するのに必要 なCar2x
技術を搭載します。 道路工事警告のシナリオは、欧州電気通信 標準化機構（ETSI
）によって定義されたCar2x
アプリケーションのひとつです[1]
。計画では、技 術的な実装は2015
年に運用が開始される予 定です。ここでは、無線LAN
標準IEEE802.11p
（ITS-G5
）にしたがって、無線LAN
の電波領域 内で、警告用トレーラーが車両にリアルタイムで 情報を送信します（図1
）。ITS-G5
用に割り当て られている、5.9GHz
の周波数帯が利用可能で す。ETSI
で規定されたGeoNetworking
プロト コル［2
］が、アドホックネットワークでのパケット ルーティングに使用され、高速道路上の工事区 域についての情報は標準化されたアプリケー ションメッセージ［3
］に含まれます。 メッセージには、「分散型環境通報メッセー ジ（DENM
）」が含まれ、これには、あるイベント （道路工事警告、渋滞警告の終了など）につい て必要な情報がすべて含まれ、関連したイベン トが起きたときのみ送信されます。イベントス テータスと場所について、さらに適用期間と適 用地域についての一般的な情報をITS
ステー ションが送信します。Car2x
の「道路工事警告」 アプリケーションでは、警告用トレーラー は速 度制限や車線閉鎖についての情報も送信しま す。さらに状況に応じて、工事区域の状態やトポ ロジーを動的に変化させます。I T S
ステ ーション で は 、「Co o p e r a t i v e
Awareness Message
（CAM
）」を使用し、 位置や走行方向、速度、加速度などのステータ ス情報を、車両のヘッドライト点灯の情報ととも に定期的に送信します。すべてのITS
ステーショ ンがこれらの情報を送信するので、警告トレー ラーは、工事区域での交通密度の計算などを 行い、工事区域での速度制限を適宜変更した り、交通渋滞情報を中央交通管制オフィスに送 信したりできます。工事区域アプリケーションで
搭載される機能
車両は工事区域の特定のDENM
を受信する と、メッセージの妥当性をチェックします。これに は、車両の位置や速度、走行方向などの情報が 必要です。将来は車両の周辺環境をより正確に 表す地図データも利用できるようになれば理想 的です。この情報は、CAN
やEthernet
などの車 載バスシステムを通じて提供されます。 妥当性のチェックでは、タイムスタンプなどの 情報によって、受信メッセージがまだ有効である かどうかを車両が判断します。工事区域と車両 の位置は、工事区域が走行ルート上にあるかど うかを判断するのに使われます。メッセージがそ の車両にとって妥当である場合は、必要なデー タが実際の工事区域アプリケーションに転送さ れます。これにより、たとえば、車両が定められた 工事区域に入ったときに、運転支援システムやHMI
など他のアプリケーションに必要なデータ を提供します。テストツールにより効率は向上するか？
車両に搭載された工事区域アプリケーション を包括的にテストするためには、すべての必要な テストシナリオにおいて、アプリケーション関連 図1：工事区域におけるシナリオでの通信の簡略図データをアプリケーションに提供しなければな りません。また、これらのシナリオは、現実の運転 状況と正確に一致している必要があります。テス トツールを使用すれば、テスト実行者は実環境 で複雑なテストを実行する必要がなくなります。 テストの初期段階では、すべてのコンポーネント が使用可能とは限らないため、実環境でのテス トを実施することは非常に困難です。 開発およびテストの段階では、テストに適切 で必要なデータをアプリケーション開発者に提 供するだけで十分です。これには、テストツール からテスト対象の
ECU
にデータを提供するため に、モデル化された環境を構築することも含ま れます。モデル化された機能とコンポーネントを 利用すれば、テスト対象のECU
をさまざまな状 態でテストできます。 つまり、工事区域の車載アプリケーションをテ ストするためには、「モデル化された道路工事警 告トレーラー」が必要になります。シナリオは個 別のテストに対して設定できます。たとえば、車 線閉鎖や速度制限に関する異なるシナリオが 想定でき、テストの土台としての役割を果たしま す。同時に、各テストケースに対し、車両の地理的 な位置や走行ベクトル、速度のデータが工事区 域アプリケーションに入力パラメータとして与え られます。テストツールはまた、車両の運転モデ ルのプロファイルをシミュレーションし、刺激入 力のためのCAN
フレームを生成します。その後、ECU
のCAN
バスインターフェイスを経由し、工事 区域アプリケーションにこのデータを提供します （図2
）。Car2x
アプリケーションの
テストツールの要件
Car2x
アプリケーションテストで効果的に使 用するために、テストツールは多くの要件を満た さなければなりません。テストツールは、アプリ ケーション用に定義された無線LAN
チャンネル を通じて、IEEE802.11p (ITS-G5)
規格に適合し た無線LAN
データパケットを送受信できる必要 があります。GeoNetworking
など、プロトコル 特有の情報を解釈するテストツールの機能も必 要です。ASN.1 (Abstract Syntax Notation.1)
で記述され、
PER
メソッド(Packed Encoding
Rules)
によってコーディングされたアプリケー ションメッセージの信号とデータフィールドにア クセスする機能も必要です。ASN.1
で定義され たアプリケーションメッセージの情報をテスト ツールが参照することにより、メッセージの変更 などに非常に柔軟に対応できます。データベー スの使用はテストツールを有効に活用するため の土台となります。データベースを使用する手法 は、CAN/LIN/FlexRay
などの車載ネットワーク ですでに確立され、解析・測定とシミュレーショ ン、テストの作成と実行に非常に有効であること が証明されています。 テスト工程でのECU
への刺激目的でシミュ レーション環境を利用するために、仮想ノード を作成できるプログラミングツールが必要で す。ツールにCar2x
特有の関数ライブラリーが 備わっていることが理想的です。アプリケーショ ンメッセージの作成と送信、シグナルとデータ フィールドの読み書き、送信前にデータをPER
コーディングの実行する機能を持つようなライ ブラリーです。Car2x
環境で必要になることの多 いUTC
タイムスタンプを生成する機能も有用で す。これによって、各テストケースに対して工事区 域特有の有効なDENM
を設定できます。 統 合されたテスト環 境では、テストの 作成 や実行などが容易です。テストは、エディターとCar2x
特有の関数ライブラリーを利用して作成 できます。また、他のテストシナリオ用に簡単に 複製や修正ができます。また、テストの実行機能 は選択されたテストを実行し、テスト結果をレ ポートとして文書化します。Car2x
環境では、多くの地理的な位置情報 が処理されるため、それらが地図上で可視化さ れることは非常に有用です。DENM
からの情報 もまた解釈され、この地図上に表示されます （図3
）。これによって、工事区域や車両がどこに 図2： Car2xテストシナリオのレイアウト図。工事区域警告アプリ ケーションは、さまざまなシナリオでの機能をテストするため にテストツールによって刺激されますCar2x
アプリケーションのテスト
Technical
A
rticle
1
2 3 4 5 あるか、関連区域やウェイポイントが正しくエン コードされているか、そして車線閉鎖に関しての メッセージでどのような情報が送信されている かを、ひと目で簡単に、正確に把握できます。 工事区域アプリケーション、つまりECU
は、CAN
やEthernet
などの車載ネットワークやITS-G5
などの外部から、必要な情報を受信しま す。したがって、テストツールは他のマルチバスの 機能とともに必要な情報の処理に対応している 必要があります。まとめ
Car2x
技術は、自動車メーカーの研究部門で 研究されているだけではありません。製品開発 部門も現在このテクノロジーによって付加価値 をつける方法や、より良いドライバーアシスタン スシステムへの応用方法があるか等を模索して います。これらの新しい機能の品質は、適切なテ ストツールによって保証される必要があります。 現在、ベクターはCANoe.Car2x
の開発とテス トツールで、Car2x
技術の量産車への導入をサ ポートしています。CAN
やFlexRay
、Ethernet
な どの車載ネットワークのテストに加え、Car2x
環 境に対応するテストも作成できます。これらの テストが、車載Car2x
技術およびCar2x
インフラ ストラクチャーを開発、統合する手助けになりま 図3： テストシナリオ全体は、CANoe.Car2xに実装でき可 視化もできます。地図Windowで、走行方向を示した ITSステーションを明解に表示 す。ベクターは、CAR 2 CAR
コミュニケーション コンソーシアム主導の覚書[4]
に署名し、将来 のテストツール要件も実装されることをお客様 に保証しています。 本稿は2013年6月にドイツで発行されたAutomobil Elektronikに掲載されたベクター執筆による記事を 和訳したものです。 参考文献： [1] ETSI TR 102 638 V1.1.1 (2009-06) [2] ETSI EN 302 636-1 V1.1.0 (2010-03) [3] ETSI TS 102 637-2 V1.2.1 (2011-03), ETSI TS 102 637-3 V1.1.1 (2010-09)[4] Memorandum of Understanding, CAR 2 CAR
Communication Consortium, Version 4.01.02
(2011-06-27) 提供元： 見出し画像および図1∼3：Vector Informatik GmbH リンク： ベクター･ジャパン www.vector-japan.co.jp Car2x - 開発パートナーとしてのベクター http://jp.vector.com/vj_car2x_solutions_jp.html .Car2x (CANoe用) - 概要 http://jp.vector.com/vj_canoe_car2x_jp.html
Vector Informatik GmbHのITS/Car2x分野 のグループリーダー兼プロダクトマネージャー。
Vector Informatik GmbHのCar2x関連テク ニカルライター。 執筆者 Cathleen Kunze (Graduate Engineer) Thomas Löffler (Graduate Engineer)
T
e c hnic al
A r t ic le
2
自動車業界で
AUTOSAR
の採用が広く定着してきた昨今、大型車両分野も
AUTOSAR
に目を向
け始めており、大型車両メーカーも
AUTOSAR
のモジュール概念を適用して開発コストを節約し
たいと考えています。自動車業界で使用されている静的なネットワークとは異なり、大型車両では
J1939
規格に基づいた動的な通信が使用されています。本稿では、
J1939
を
AUTOSAR
に統合
する利点と制約について考察します。
大型車両と
AUTOSAR
～
J1939
の
AUTOSAR
への統合～
大型車両と
AUTOSAR
Technical
A
rticle
12
3 4 5SAE J1939
は、大型車両業界のネットワー クと通信のために確立された標準規格です。J1939
は、直接使用される場合と、派生標準規 格の形で使用される場合とがあります。例えば、ISOBUS
は農業や林業の分野で、NMEA2000
® （National Marine Electronics Association
）は海洋分野で使用されています。ヨーロッパや その他の特定の地域の大型トラック業界では、
J1939
の一部しか使用していません。一般の自 動車業界と比べ、大型車両業界は生産量が少 ないため、ハードウェアのコストや倉庫保管のコ ストよりもソフトウェア開発に掛かる費用の比 率が高くなります。そのため、ソフトウェアの再 利用に注力することは理にかなっています。しか し実際は、ほとんどの開発者が個々のECU
に新 たにコードを書いています。ハードウェアやプロ トコルドライバーさえも、多くのプロジェクトで 毎回開発されており、それはドライバーやアプリ ケーションソフトウェアのパーツを再利用するた めの共通の標準規格がないことに起因してい ます。AUTOSAR
の狙い
―
ソフトウェアの再利用
AUTOSAR
規格の開発には、主に2
つの動 機があります。1
つは、ハードウェアとプロトコ ルドライバーの標準 化で、これはECU
サプラ イヤー の 変 更を容 易にします。もう1
つは、ア プリケーションソフトウェアのモジュール 化 で、ますます複雑化するECU
の取り扱いを容 易にします。プロトコルおよびハードウェアド ライバーは、ベーシックソフトウェアモジュー ル（BS W module
）の 形で 標 準 化され、ア プリケーションソフトウェアはソフトウェア コンポーネント（SWC
）の 形でモジュール 化 および抽象化されます。図1
は、J1939
アプリケー ション用ベーシックソフトウェアの一部と、ラン タイム環境（RTE
）およびアプリケーションレイ ヤーを示しています。AUTOSAR
の
ソフトウェアコンポーネントモデル
AUTOSAR
システムのアプリケーションソフ トウェアは、各エレメントが階層的に整理された コンポーネントに細かく分類されます。アプリ ケーション側から見ると、コンポーネント間の通 信がAUTOSAR
のバーチャルファンクションバ ス（VFB
）を超えて行われ、実際のECU
のトポロ ジーを隠します。コンポーネントはこれらの通信 の要求をインターフェイス（ポート）経由で定義 し、データエレメントまたはデータ操作をグルー プ化します。VFB
はこれらのポートを抽象レベル で接続します。アプリケーションソフトウェアコ ンポーネントがECU
に割り当てられた後（図2
）、RTE
は個々のECU
のためのVFB
の役割を担い ます。つまり、RTE
はアプリケーションソフトウェ アコンポーネントのすべての通信インターフェイ スを、コンポーネントとベーシックソフトウェア間 や他のECU
との間に実装します。 図1：大型車両用AUTOSARアーキテクチャーからの抜粋 図2：ライブラリーからECUへのソフトウェアコンポーネントの割り当て表1：AUTOSAR 4.1が対応するJ1939診断メッセージ
大型車両のための
AUTOSAR
―
始まり
当初、AUTOSAR
は乗用車の必要性に照準 を合わせた規格であったため、静的な通信マト リクスを使用しています。そのため、AUTOSAR
は静的なバス通信モデルを考慮して設計され ました。しかし、静的な通信モデルであったため、 初期の頃は大型車両分野ではAUTOSAR
が使 用されていませんでした。AUTOSAR
がJ1939
に初めて対応したのは、2009
年末にリリースさ れたAUTOSAR
バージョン4.0
でした。このバー ジョンにおいて、Vector Informatik GmbH (
ベ クター本社：ドイツ、シュツットガルト）は、ヨーロッ パのトラックメーカーと協力し、J1939
のトラン スポートプロトコル用AUTOSAR
ベーシックソ フトウェアモジュールを規定しました。しかし、そ の頃すでに、ほとんどのJ1939
アプリケーション にとってAUTOSAR4.0
によるJ1939
要件のサ ポートが充分ではないことは明らかでした。AUTOSAR 4.1
で拡張された
J1939
要件のサポート
AUTOSAR
バージョン4.1
は、2013
年3
月にリ リースされました。J1939
に関する最も重要な 変更は、より高いレイヤーからCAN ID
のパー ツにアクセスできるようになったことでした。こ の変更により、動的なネットワークで効率的な 通信が可能になります。メッセージを受信する と、CAN ID
のパーツがペイロードデータに付 加され、他のモジュールでも利用可能になりま す。もう一方では、メッセージの送信者がペイ ロードデータにCAN-ID
の変数パーツを付加し ます。この方法でCAN-ID
にアクセスするBSW
モジュールは、J1939
トランスポートプロトコル、UDS
トランスポートプロトコル、UDS
診断、およ びPDU
ルーターです。AUTOSAR
バージョン4.1
から、J1939
トラン スポートレイヤーは使 用するプロトコル 変 数(BAM/CMDT
）に関わらず、長いメッセージを受 信できるようになりました。メッセージを送信す るとき、J1939
トランスポートレイヤーは、直接通 信と、実際のメッセージの長さと送信先アドレス に基づいた2
つのプロトコル変数のうちの1
つを 使用する通信との間を、自動で切り替えます。ま た、動的なCAN-ID
は設定の煩わしさを大幅に 軽減します。 ベクターはトラックメーカー2
社と協力し、J1939
用BSW
モジュールを新たに3
つ規定しま した（表1
）。>
J1939-21
に準じた、要求‐応答プロトコル 用「J1939 Request Manager
」>
J1939-81
に 準じ た、簡 単 な アド レ ス 割 り 当 て 方 法 用「J1939 N e t w or k
Management
」>
J1939 -73
に 準 じ た、診 断 用「J1939
Diagnostic Communication Manager
」AUTOSAR
バージョン4.1
のJ1939 Request
Manager
は、要求およびアクノリッジメッセージ の送受信を処理します。この目的を達成するた め、J1939 Request Manager
はRTE
経由で、関 連するBSW
モジュールまたはアプリケーション ソフトウェアコンポーネントへ、インターフェイス を提供します。さらに、送信された要求のタイム アウトモニタリングも行います。Technical
A
rticle
12
3 4 5大型車両と
AUTOSAR
テュービンゲン大学でコンピューターサイエ ンスを学び、2004年からVector Informatik GmbHにてJ1939ソフトウェアを開発。J1939 のAUTOSAR統合のためのワーキンググループ にもメンバーとして参加。 執筆者 Martin Schlodder (Dipl. Inf.) 図3：ISOBUSにおける動的なアドレス割り当て： 接続したばかりのECU Cがアドレス10を占有したため、ECU Aは アドレスを変更J1939 Network Manager
により、AUTOSAR
バージョン
4.1
では、ユーザーが設定不可のECU
やソフトウェアアップデートにより設定可能と なるECU
を作成することができます。指定され たアドレスへのアドレス割り当てに失敗すると、ECU
は「CannotClaimAddress
」というメッセー ジを送信し、オフラインになります。AUTOSAR
バージョン4.1
のJ1939 Diagnostic
Communication Manager
は、すでに多くのJ1939
診断メッセージに対応しています（表1
）。 未対応なのは、OBD
メッセージと、メモリーアク セス、キャリブレーションおよびフラッシュ用の メッセージです。AUTOSAR
バージョン4.1
にお けるJ1939
診断の大きな利点は、AUTOSAR
の 「Diagnostic Event Manager
」に保存された フォールト情報へのアクセスをUDS
診断と共有 している点です。これにより、両診断プロトコル 用の診断情報を確実に統一管理することがで きます。J1939
の
AUTOSAR 4.1
への
統合におけるギャップ
AUTOSAR
はバージョン4.1
からJ1939
対応 への一歩を踏み出しましたが、農林機械におい ては特に、まだ 少 々の ギャップ が あります。AUTOSAR
で明らかに欠落しているのは、実行 時にアドレス変更を可能にする自己設定および コマンド設定可能なECU
への対応です（図3
）。 さら に 、A U T O S A R
は 、J19 3 9
ベ ース のISO 11783
（ISOBUS
）規格の下記トランスポー トプロトコルにも未対応です。>
NMEA 2000
® のFastPacket
>
ISO 11783-6
のETP
ユニバーサル端末やファームウェア管理、類 似コンポーネント用のアプリケーションプロトコ ルの実装も望まれています。 また、AUTOSAR
は、Request2
メッセージやTransfer
メッセージ、NAME
管理やその他の診 断メッセージを用いた要求‐応答の拡張プロト コルにも未対応です。そして、J1939
の標準化さ れたシグナルとメッセージへの簡単なアクセス のためのソリューションも備えていません。展望
現在、AUTOSAR
に前述のギャップを埋め るような動きはありません。しかし、特に農業や 林業を管理する業界において、より多くの商用 車自動車メーカーがAUTOSAR
に関わる動き を見せています。その結果、長期的に見れば、ISOBUS
への拡張もAUTOSAR
で標準化され ることが見込まれます。 それまでは、ツールやベーシックソフトウェ アメーカーは暫 定的なソリューションで対応 していくでしょう。例えば、Vector Informatik
GmbH
では、現在、充分に動的なアドレス割り当 てや、アプリケーションをJ1939
のメッセージや シグナルのカタログに容易にリンクさせるため のサポートを開発しています。また、ETP
およびFastPacket
トランスポートプロトコルの実装も 計画されています。 本稿は2013年11月にドイツで発行されたHanser automotiveに掲載されたベクター執筆による記事 を和訳したものです。 画像提供元： 見出し画像、図1∼3および表1：Vector Informatik GmbH リンク： ベクターのAUTOSARソリューション「MICROSAR」 www.vector-japan.co.jp/microsar ベクター ･ジャパン www.vector-japan.co.jp3
T
e c hnic al
A r t ic le
車両診断は車両の各コンポーネントの不具合を迅速かつ効率的に突き止め、修正するための重要
なツールです。ただし、
まれなケースではあるものの、
その車両のエキスパートの助けが現場で得ら
れなければ、
トラブルの原因を特定できないことがあります。しかし今、
このようなエキスパートが実
際に現場に出向かなくても、
リモート診断機能を使って車両にダイレクトに、
しかもインタラクティブ
にアクセスし、
車両の問題の調査と原因の体系的な解明を行うことが可能となりました。
遠隔地からの診断
～世界中の車両をインタラクティブに診断～
スウェーデン、零下
20
度、降雪あり。雪に覆わ れた氷の湖でテストドライバーが寒冷地テスト ドライブを行っています。カーブでのブレーキ 操作中、ドライバーは車両の挙動に違和感を覚 えました。原因はブレーキシステムにありそうで す。さらにテストを重ねた結果、ベテランのテスト ドライバーである彼は、その現象が極めて特殊 な条件下でしか発生しないことにすぐ気付きま した。 知り尽くした車のことではありますが、ここで はシステム開発者による精密な分析が必要と 判断しました。この挙動の原因を迅速かつ包括 的に究明するのに必要な知識は、この車両のシ ステム開発者のみが持っています。ただし、その ようなエキスパートが現場におり、問題のカギと なる車両データを読み出したり、車両診断機能 を使用してアクチュエーターを動かし、テストし たりできるケースはごくまれです。 リモート診断を使用すれば、遠隔地からの車 両へのアクセスが可能になり、システム開発者 がスウェーデンに急行する必要はなくなります。ユースケース
診断エキスパートが車両やそのコンポーネン トに手軽にリモートアクセスできることは、遠隔 地でのテストドライブに役立つだけではありま せん。自動車メーカーやサプライヤーにとって も、リモート診断は生産開始後のシステム診断 に威力を発揮します。 そして、サービス工場などの現場でも、時には 診断エキスパートのアドバイスが必要になる場 合があります。予期せぬ複雑な問題が発生した 場合、それを迅速かつ経済的に修復するには、リ モート診断が唯一の頼みの綱になるケースもあ るのです。さまざまな視点からの診断
システム開発者や診断のエキスパートによる 車両診断は、修理に要する時間、コスト、そしてそ の成果に関する顧客満足度を高いレベルで実 現するのに重要なファクターかもしれません。 これは車両にとっては、開発から生産、そして 顧客サービスに至るライフサイクル全体を通し て欠くことのできない、切っても切れないツール です。ライフサイクルの各フェーズでは設定され ている要求がまったく異なるため、診断機能は その点を考慮して開発しなければなりません。 車両の開発中には、ECU
をより詳しく調べ、より 包括的に介入することが必要です。生産におい ては、診断機能は「合格/
不合格」のテストに使 用されます。販売後の顧客サービスでは、ガイ ド付きのトラブルシューティングがあれば、特に 専門的な知識がなくてもエラーを特定できるで しょう。その後はそれを使用して、修理が成功し たかを簡単に検証できます。 要求がこのように多岐にわたるため、これら の診断テスターはユーザーの状況により機能 を制限するコンセプト、詳細度のレベル、アクセ スできる機能の面においてかなり異なります。 サービス工場のテスターは安全の面からECU
に実装されている診断機能の一部しか使用せ ず、その他の部分は開発または生産の工程でし か使用されないようになっているわけです。 しかし時には、現場で想定外の問題が発生 し、診断のエキスパートがまさにそれらの開発 固有の情報や機能にアクセスしなければならな いこともあります。データ保護
顧客サービス用のテスターにすべての診断 データを付けて一般に配布しても解決にはなり ません。それを行えば、本来はごく少数のエキス パートにのみ許されるべき極めて幅広いシステ ム介入も可能になってしまいます。したがって、 データと機能は機密として扱い、それらへのア クセスは限られたユーザーにのみ許可します。 こうすることで許可のない第三者が各システム の機能の実装方法に関する情報にアクセスしたTechnical
A
rticle
1 23
4 5遠隔地からの診断
図1：診断テスター「Indigo」のフォールトメモリーと測定 り、それらを操作したりすることもより難しくな ります。そのため、顧客サービス用のテスターに は、サービス工場での診断機能のユースケース に必要な部分を正確に抽出したものを用意しま す。車両診断の場面においてユーザー操作をで きる限り簡素化することで、意図しない操作ミス を防ぎます。
![図 6 図 7 図 84.3 ファイル管理に関する注意 （参考）CANoe/CANalyzerのファイル管理は、図6のような基本構成でフォルダ管理すると便利です。[Project_1]と名前付けしたフォルダを大きなくくりとし、その中に[DB]と[Node]という2つのフォルダを予め作成します。そして、このコンフィグレーションで使用するデータベースを[DB]に予め保存します。作成したCAPLファイル（拡張子can）の保存先は、この予め作成しておいた[Project_1]-[Node]を指定し、名前を付け](https://thumb-ap.123doks.com/thumbv2/123deta/6269254.617519/35.892.154.839.58.1132/フォルダフォルダなくくりコンフィグレーションデータベース.webp)
![表 8 7.5.3 イベントハンドラー on start / on timeron start は、CANoe/CANalyzer の測定開始に対して反応します。on Timer は、タイマー設定時間経過に対して反応します。（表8） イベントハンドラー 「 on timer 」 への定義例 on timer ‘ a ’ // [a] キーを押した時に反応（大文字・小文字は区別されます） on timer ‘ ’ // スペースバーを押した時に反応 on timer F](https://thumb-ap.123doks.com/thumbv2/123deta/6269254.617519/45.892.17.805.57.1096/イベントハンドラータイマーイベントハンドラースペースバー.webp)
