y y sÍy6 y ¯´ S o...¯^ P;tx â Tm O s Ý ´ M F µ ¨ z Í ² w é z U b M q V Ç U w 0 ªz» á...

$: y y sÍy6 y ¯´ S o...¯^ P;tx â Tm O s Ý ´ M F µ ¨ z Í ² w é z U b M q V Ç U w 0 ªz» á 8w× =K zMxP; x z t h b 0 t r s ¹ ´ w ? =S | Ø C=x ÆD=tsloM b{fw Os ? =S |$
4193-529305　14/10/23　初校　再山　表紙 - おもて

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

Vector Journal 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

Deve

lopm

ent

Consulting

Tech

nica

l

Software

ECU

Calibration

ECU

ECUキャリブレーション

www.vector-japan.co.jp

お問い合わせ

Info

rmat

ion

製品の購入／見積りに関するお問い合わせ

東　京　TEL : 03-5769-6980

名古屋　TEL : 052-238-5020

E-mail : [email protected]

［組込ソフトウェア関連製品］TEL : 03-5769-7808E-mail : [email protected]

技術関連のお問い合わせ

［各種ソフトウェア・ハードウェア製品］■ カスタマーサポートTEL : 03-5769-6971E-mail : [email protected]

［組込ソフトウェア関連製品］■ ホットラインサポートサービス東　京　TEL : 03-5769-6972

名古屋　TEL : 052-238-5014E-mail : [email protected]

各種トレーニングに関するお問い合わせ

TEL : 03-5769-6973


本誌定期購読についての詳細は

ベクター・ジャパンの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の開発をスムーズに

4193-529305　14/10/20　初校　奥山　表紙 - うら

Vector Journal Vol.9 01

CONTENTS


〒140-0002　



2014年11月発行


02

22

06

10

14

18

26

30

54



02

06

10

14

18

22

Cover Story


Technical Article






Vector Report


Vector Academy

はじめてのCAPL

News from Vector









Testing

ECU

Diagnostics

Distr. Systems

Deve

lopm

ent

Consulting

Tech

nica

l

Software

ECU

Calibration

ECU


Cover Story


建設機械分野で世界をリードするコマツは、ECUの開発とテストにベク

ターの「CANape」を導入しました。日米欧で定められた厳しい排ガス規制

（Tier4 Interim）に対応した建機の開発に「CANape」を全面的に活用し、

計画どおりのスケジュールで製品化を実現。合わせて、品質の向上や社内テス

ト環境の統一化などを果たしています。

02 Vector Journal Vol.9


電子化と情報化で建機業界をリードするコマツ

建設機械にも電子化および情報化の波が押し寄せています。ブルドーザーや油圧ショベルに代表される建機には武骨かつ重厚なイメージが付きまといますが、燃費の向上、排ガス規制への対応、施工や運転の自動化、あるいは建機車両の遠隔監視などに対応するためにも、もはや電子化および情報化は不可欠になっています。そのような電子化および情報化で業界を

リードしているのがコマツです。農業や除雪などに使われる小型建機から、鉱山で使われるような超大型建機までを幅広くラインアップするコマツでは、世界初となるハイブリッド油圧ショベルの商用化、建機の遠隔監視サービスである「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 Tier3Tier4

interimTier4 �nal

欧州 EU

StageI StageII StageIIIA StageIIIB StageIV

図1：建機を対象にした排ガス規制



して利用しているそうです。

排ガス規制対応建機の開発を予定通り完了

石河氏は、「CANape」の導入でもたらされたもっとも大きな成果は、多数の「Tier4 Interim」対応の開発の中で、予定通りにECU開発を完了することが出きたことだと述べています。「CANapeを導入したことにより、複雑に絡み合った問題の要因を解析・特定する力が向上しました。これは開発をスケジュール通り進めていくことに大きく貢献したと思います。」（同氏）。また、ECUを通して車体全体の挙動がより詳

しく判るようになったことで、品質の向上にもつながったそうです。テスト環境やテスト方法が社内で統一されたことも導入メリットのひとつ

実車両試験では、圧力センサーや速度センサーなどの情報は既存の測定環境で取得し、ECUの挙動のみを「CANape」でモニタリングし、得られたMDF（Measurement Data 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 StoryTier4 Interimに対応したECUの開発とテストに「CANape」を活用

図4：耐久試験におけるロガーを使ったCANバスの長時間測定

T echnical Ar t ic le 1

複数の自動車メーカーが、2015年にCar2x通信の量産車への導入開始を計画しています。すでに始まっているCar2xのアプリケーション開発は、コンポーネントテストとアプリケーションテストの実施という新しい課題をもたらしています。本稿では、Car2xの「道路工事警告」アプリケーションの例を基にしたテストツールの関連要件を取り上げます。

Car2xアプリケーションのテスト～道路工事警告の警告システムのための　テストツールの要件～



Car2xアプリケーションのテスト

Technical Article 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 opera 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 Article 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 echnical Ar t ic le 2

自動車業界でAUTOSARの採用が広く定着してきた昨今、大型車両分野もAUTOSARに目を向け始めており、大型車両メーカーもAUTOSARのモジュール概念を適用して開発コストを節約したいと考えています。自動車業界で使用されている静的なネットワークとは異なり、大型車両ではJ1939規格に基づいた動的な通信が使用されています。本稿では、J1939をAUTOSARに統合する利点と制約について考察します。




大型車両とAUTOSAR

Technical Article 21 3 4 5

SAE J1939は、大型車両業界のネットワークと通信のために確立された標準規格です。J1939は、直接使用される場合と、派生標準規格の形で使用される場合とがあります。例えば、ISOBUSは農業や林業の分野で、NMEA2000®（National Marine Electronics Association）は海洋分野で使用されています。ヨーロッパやその他の特定の地域の大型トラック業界では、J1939の一部しか使用していません。一般の自動車業界と比べ、大型車両業界は生産量が少ないため、ハードウェアのコストや倉庫保管のコストよりもソフトウェア開発に掛かる費用の比率が高くなります。そのため、ソフトウェアの再利用に注力することは理にかなっています。しかし実際は、ほとんどの開発者が個々のECUに新たにコードを書いています。ハードウェアやプロトコルドライバーさえも、多くのプロジェクトで毎回開発されており、それはドライバーやアプリケーションソフトウェアのパーツを再利用するための共通の標準規格がないことに起因しています。

AUTOSARの狙い ― ソフトウェアの再利用

AUTOSAR規格の開発には、主に2つの動機があります。1つは、ハードウェアとプロトコルドライバーの標準化で、これはECUサプライヤーの変更を容易にします。もう1つは、アプリケーションソフトウェアのモジュール化で、ますます複雑化するECUの取り扱いを容易にします。プロトコルおよびハードウェアドライバーは、ベーシックソフトウェアモジュール（BSW 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 Net work Management」

　> J1939-73に準じた、診断用「J1939 Diagnostic Communication Manager」

AUTOSARバージョン4.1のJ1939 Request Managerは、要求およびアクノリッジメッセージの送受信を処理します。この目的を達成するため、J1939 Request ManagerはRTE経由で、関連するBSWモジュールまたはアプリケーションソフトウェアコンポーネントへ、インターフェイスを提供します。さらに、送信された要求のタイムアウトモニタリングも行います。




大型車両と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.jp


3T echnical Ar t ic le

車両診断は車両の各コンポーネントの不具合を迅速かつ効率的に突き止め、修正するための重要なツールです。ただし、まれなケースではあるものの、その車両のエキスパートの助けが現場で得られなければ、トラブルの原因を特定できないことがあります。しかし今、このようなエキスパートが実際に現場に出向かなくても、リモート診断機能を使って車両にダイレクトに、しかもインタラクティブにアクセスし、車両の問題の調査と原因の体系的な解明を行うことが可能となりました。




スウェーデン、零下20度、降雪あり。雪に覆われた氷の湖でテストドライバーが寒冷地テストドライブを行っています。カーブでのブレーキ操作中、ドライバーは車両の挙動に違和感を覚えました。原因はブレーキシステムにありそうです。さらにテストを重ねた結果、ベテランのテストドライバーである彼は、その現象が極めて特殊な条件下でしか発生しないことにすぐ気付きました。知り尽くした車のことではありますが、ここで

はシステム開発者による精密な分析が必要と判断しました。この挙動の原因を迅速かつ包括的に究明するのに必要な知識は、この車両のシステム開発者のみが持っています。ただし、そのようなエキスパートが現場におり、問題のカギとなる車両データを読み出したり、車両診断機能を使用してアクチュエーターを動かし、テストしたりできるケースはごくまれです。リモート診断を使用すれば、遠隔地からの車

両へのアクセスが可能になり、システム開発者がスウェーデンに急行する必要はなくなります。

ユースケース

診断エキスパートが車両やそのコンポーネントに手軽にリモートアクセスできることは、遠隔地でのテストドライブに役立つだけではありま

せん。自動車メーカーやサプライヤーにとっても、リモート診断は生産開始後のシステム診断に威力を発揮します。そして、サービス工場などの現場でも、時には

診断エキスパートのアドバイスが必要になる場合があります。予期せぬ複雑な問題が発生した場合、それを迅速かつ経済的に修復するには、リモート診断が唯一の頼みの綱になるケースもあるのです。

さまざまな視点からの診断

システム開発者や診断のエキスパートによる車両診断は、修理に要する時間、コスト、そしてその成果に関する顧客満足度を高いレベルで実現するのに重要なファクターかもしれません。これは車両にとっては、開発から生産、そして

顧客サービスに至るライフサイクル全体を通して欠くことのできない、切っても切れないツールです。ライフサイクルの各フェーズでは設定されている要求がまったく異なるため、診断機能はその点を考慮して開発しなければなりません。車両の開発中には、ECUをより詳しく調べ、より包括的に介入することが必要です。生産においては、診断機能は「合格 /不合格」のテストに使用されます。販売後の顧客サービスでは、ガイド付きのトラブルシューティングがあれば、特に

専門的な知識がなくてもエラーを特定できるでしょう。その後はそれを使用して、修理が成功したかを簡単に検証できます。要求がこのように多岐にわたるため、これら

の診断テスターはユーザーの状況により機能を制限するコンセプト、詳細度のレベル、アクセスできる機能の面においてかなり異なります。サービス工場のテスターは安全の面からECUに実装されている診断機能の一部しか使用せず、その他の部分は開発または生産の工程でしか使用されないようになっているわけです。しかし時には、現場で想定外の問題が発生

し、診断のエキスパートがまさにそれらの開発固有の情報や機能にアクセスしなければならないこともあります。

データ保護

顧客サービス用のテスターにすべての診断データを付けて一般に配布しても解決にはなりません。それを行えば、本来はごく少数のエキスパートにのみ許されるべき極めて幅広いシステム介入も可能になってしまいます。したがって、データと機能は機密として扱い、それらへのアクセスは限られたユーザーにのみ許可します。こうすることで許可のない第三者が各システムの機能の実装方法に関する情報にアクセスした


遠隔地からの診断


図1：診断テスター「Indigo」のフォールトメモリーと測定

り、それらを操作したりすることもより難しくなります。そのため、顧客サービス用のテスターには、サービス工場での診断機能のユースケースに必要な部分を正確に抽出したものを用意します。車両診断の場面においてユーザー操作をできる限り簡素化することで、意図しない操作ミスを防ぎます。

インタラクティブなリモート診断

インタラクティブなリモート診断機能を使用すれば、診断エキスパートが車両から物理的に離れていることの問題を回避できます。このエキスパートはあたかも現場にいるかのように車両にアクセスし、専門知識を発揮して作業にあたることができます。サービス工場のスタッフは、リモートで測定値を読み出したり、関係する車両コンポーネントの挙動を詳しく観察したりしている間、ブレーキペダルを操作するなどの補助的な作業を行うことができます。車両の条件が許せば、遠隔地からアクチュエーターにアクセスすることも可能です。診断エキスパートはさらに踏み込んだ操作を行って、観察された挙動を説明しうる原因のうち、最初に疑われる部分を確認したり、それらを原因から除外したりして、効果的に問題を判定できます。つまり、前述のスウェーデンのテストドライ

バーのケースであれば、この車両のエキスパートがスウェーデンに駆け付ける必要はなく、また開発診断データをテストドライバーに送付して、エキスパートの指示の下で自力で問題解決にあたってもらう必要もありません。さらに、現場で状況を直ちに検証できるのであれば、車両がスウェーデンから戻るのを待つ必要もなく問題の再現が可能です。観察された挙動に何らかの環境条件が影響を及ぼしている場合、これは特に重要です。リモート診断で第一に挙げられる利点は、診

断エキスパートが測定結果に即座に対応して、追加の測定を行い、パラメーターを修正し、アクチュエーターに対処できる点です。このインタラクティブなアクセス機能が、リモート診断と、ロガーやオンボードテスターを使用するアプローチとの決定的な違いです。

高いレベルのパフォーマンスとデータ保護を実現するリモート診断

インタラクティブなリモート診断の利点を生かせるかどうかは、診断時の照会を高速かつ低レイテンシーで処理できる能力に掛かっています。ベクターが提供する診断テスターIndigo バージョン4.0（図1）は、インタラクティブなリモート診断をサポートします。

これに対し、従来の診断テスターはネットワークインターフェイスを介して車両と直接接続されています（図2）。この場合、必要な診断データと、求められる診断およびモジュールの知識が現場にすべて揃っていなければなりません。

Indigoを使用したリモート診断では、従来の診断テスターに代わってアクセスポイントが用いられます。これがインターネット上の通信サーバーとともにルーティングハブとして機能し、車両と実際の診断テスターの間の診断リクエスト/レスポンスをルーティングします（図3）。実際の診断テスターが置かれているのは、エキスパートのいる遠隔地です。診断データやエキスパートを現場に送らなくても、車両への直接アクセスが可能なのです。リモート診断は、アクセスポイントを車両側の

測定環境にダウンロードし、診断エキスパートにIDとパスワードを渡して診断セッションに招待するだけで使用できます。車両に変更を加えなくても、このテストシステムが即座に使用可能になる点は注目に値します。実装したソリューションでは、診断データ、テ

ストシーケンス、セキュリティーのアルゴリズムは保護された環境内に留まり、制御、解釈、評価などの操作はいずれも診断エキスパートのコンピューター上で行われます。高いレベルのデータセキュリティーが、エンドツーエンドのエン




遠隔地からの診断

コーディングと併せて実現します。すべての診断機能を効率的に使用できるよ

う、高帯域幅と低レイテンシーを約束する、技術的な手段が多数実装されています。これによって、たとえ送信データが大容量であっても、世界各地の車両に極めて短い応答時間でアクセスすることが可能になります。

まとめ

システムや診断を担当するエキスパートは、インタラクティブなリモート診断を使用することで、世界中の車両に場所を問わずに接続し、居ながらにしてリアルタイムにエラーを調べることができます。このプロセスでは、診断エキスパートは現場

にある顧客サービス向けのテストシステムに頼るのではなく、専門的なツールを使用できます。そのうえ、診断に必要なデータはこのエキスパートの保護された環境に留まり、それらを配布または送信する必要もありません。ベクターが提供する診断テスター、Indigoが

持つインタラクティブなリモート診断機能は、オンボードのテストシステムが持つ静的な診断機能を凌駕するだけでなく、リモートデスクトップのアプローチとも、データの保護とパフォーマンスの点で一線を画しています。

この診断ツールにより、試運転での想定外の挙動をはるか遠方から検証することが可能になります。また、サービス工場で予期せぬ問題が発生した場合の修理時間も大幅に短縮します。特にサービス工場では、開発者レベルのサポートをリモート診断で効率的に行うことで、修理時間とコストを減らし、結果、高いレベルの顧客満足度を実現できます。

提供元見出し画像および図1～3：Vector Informatik GmbH

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

Vector Informatik GmbH（シュツットガルト）にて、診断プロダクトラインのチームマネージャーおよびプロダクトマネージャーを務め、診断テスターのIndigoとフラッシュツールのvFlashに代表される診断分野のテストシステム領域を担当。

Vector Informatik GmbH（シュツットガルト）の診断プロダクトラインディレクター。

執筆者

Rolf Weber

Christoph Rätz

図2：従来の診断テスター図3：Indigoによるインタラクティブなリモート診断のコンセプト


T echnical Ar t ic le 14T echnical Ar t ic le


（2013年11月発行、ベクター導入事例より）





電気自動車の自由を広げる急速充電器

低炭素社会の実現に向けて温室効果ガスの削減が必要とされています。走行中にCO2を排出しない電気自動車の利用は、温室効果ガス削減への有効な手段の一つとして期待が持たれています。電気自動車を利用する際に、誰しもが感じるのは「充電が切れることが心配で遠出しづらい」といった電欠に対する不安です。その不安を取り除き電気自動車を、安心して利用できるようにする役割を担うのが急速充電器です。高速道路のサービスエリアや幹線道路沿いの施設など急速充電器の設置数が増えれば増えるほど、電気自動車ユーザーの利便性は高まります。そのため、電気自動車の利用者を拡大に向けて急速充電器などのインフラ整備が望まれています。現在、急速充電方式の国際標準化が進めら

れていますが、その1つに「CHAdeMOプロトコル（以下、CHAdeMO）」があります。CHAdeMOは、CHAdeMO協議会が推奨する急速充電方式です。CHAdeMO協議会には、自動車・充電器メーカーにとどまらず、官民両方のセクターからさまざまな企業・団体が業界の枠を超えて参画しています。CHAdeMO協議会の活動は技術部会と整備部会の2つの作業部会から構成されています。技術部会では、技術仕様の制定・

維持および国際標準化の提案活動を行い、整備部会では、充電インフラの普及を推進するため、さまざまな取り組みの事例紹介や設置・運用に関する情報共有を行なっています。国際標準化の動向とCHAdeMO急速充電器の普及状況について、東京電力株式会社 CHAdeMO協議会事務局　高橋真氏は次のように語ります。「DC急速充電規格は、2010年からIEC（国際電気標準会議）で審議が行なわれてきており、CHAdeMOのほかコンボ方式（米・独案）、中国案の4つが併記される形で2013年度には国際標準として発行される見通しです。また、CHAdeMO急速充電器は2013年7月現在、世界で2,703台（日本1,716台ヨーロッパ 815台アメリカ160台その他12台）が設置されています。また、引き続き各地で導入プロジェクトが計画されており、2014年3月末までに倍増する見通しです」

CHAdeMO充電器検定器の汎用化

CHAdeMO方式に正しく対応した急速充電器を開発するためには検定試験が欠かせません。CHAdeMO協議会では、従来、独自の検定器を用いて検定試験を行っていました。従来の検定器はハードウェア、ソフトウェアとも専用に開発されたもので、検定器が車両模擬、電子負荷

制御、シーケンスチェックをすべて行います。そして、試験結果、ログデータをシリアル通信で転送し、PCで表示するという方式を取っていました。しかし、今後CHAdeMO充電器が普及する

ことを考慮するとCHAdeMO協議会自身が検定試験を行い続けるには限界があるため、2012年にver1.0の仕様改訂を行なうとともに検定規格を整備し、充電器検定を第三者機関が行なえるようにする準備を始めました。それには、検定器自体も第三者機関への開示・サポート、および仕様書に合わせて維持していくことが必要となるため、汎用性のあるプラットフォームへの置き換えを目指しました。検定器を汎用性のあるプラットフォームに置

き換えるにあたり、CHAdeMO協議会が選定したのが、ベクターのECUテストソリューションである「CANoe」と「 VTシステム」です。「CANoeとVTシステムは、CHAdeMO協議会メンバーの自動車メーカーでも標準的に使用されていること、また欧州や北米でのサポートが可能な点で導入を検討しました。最終的な導入の決め手となったのは、自動車業界における実績です。選考に当たってそれらの会員からの推薦がありました」（高橋氏）

CANoeとVTシステムは、自動車のECUテストを自動化するためのソリューションとしてすでに多くの自動車メーカーならびECUサプライ

図1：CANoeテスト機能を用いたテストの自動実行の画面図2：VTシステムの外観



ヤーに利用されています。CANoeのテスト機能を用いることで、ECUテストの実行、合否判定、レポート作成を自動で行えるようになります。これにより、テスト時間が大幅に削減されるだけでなく、テストエンジニアのスキルに依存しない高品質なテストや手動では難しいミリ秒単位のテストを実現できます。

VTシステムは、ECUテスト専用ハードウェアです。CANoeと組み合わせることで、通信テストに加えて I/Oや電源を含めたECUの統合テストを自動化できます。VTシステムには、リレースイッチ、信号処理回路、各種 I/O、コントローラーなどECUの I/Oテストに必要な各種コンポーネントが統合されています。筐体は、モジュール型の設計になっています。アナログおよびデジタルの測定と刺激、CANバスインターフェイス、さまざまな種類のフォールトインジェクションなど、多くの重要機能をカバーする幅広いモジュールが提供されているため、ユーザーは目的に合わせて柔軟にテスト環境を構築することができます。また、CANoeとの親和性にも優れ、CANoe上でテストの制御や各信号のモニターなどを行うことができます。

CANoeとVTシステムを用いた検定器

CANoeとVTシステムを用いた検定器は3つの要素で構成されています。1つ目は、充電器と接続される主回路を構成する電気自動車のリレー、電子負荷などのハードウェアです。2つ目は、充電器とのCANを含んだ通信、充電制御を行う車両エミュレータ機能と試験のパターン生成や合否判定を行う試験実行機能のソフトウェアプログラムです。3つ目は、充電器との信号のやり取りやハードウェアを制御するためのインターフェイスとしてのVTシステムです（図3、4、5）。車両エミュレータ機能と試験実行機能の2つ

はCANoe上で動作します。この2つのソフトウェアプログラムは独立しており、車両エミュレータ機能が充電器との通信をしている間、試験実行機能は各制御シーケンスおよびタイミングチェックを行います。そのため試験実行機能に試験シナリオを記述することで、ハードウェア故障が発生した場合や誤動作が行なわれた場合などのさまざまな試験をソフトウェアで実施することが可能となります。VTシステムはラック式の計測器であることから、将来のシステム拡張も容易に可能です。

試験仕様の変更に短時間で対応

CHAdeMO協議会は、CANoeとVTシステムを導入したことにより、2つのメリットを享受しました。1つ目は、検定器システムの開発期間が短縮されたことです。従来の検定器はハードウェア、ソフトウェアともに独自に開発していたため、動作確認、不具合、変更があった場合、すべてのハードウェアとソフトウェアの組み合わせ試験を行う必要があり、そこに時間が掛かっていました。自動車業界で実績のあるCANoeとVTシステムを導入したことで、これらの工数が削減され早期に検定システムを立ち上げることに成功しました。「既成製品を用いた事で個々のボード、ユニットの開発期間が不要であり、さらにデバッグ方法が確立されているため、検定器システムの開発期間が短縮されました」（高橋氏）

2つ目は、試験仕様そのものの変更があった場合、短時間で対応できるようになったことです。従来の検定器は、ハードウェアとソフトウェアが一体となっていたため、ソフトウェアプログラムを少しでも変更する場合、その都度ハードウェアから電子基板を取り外し、変更作業を行う必要がありました。CANoeであれば、PC上での作業でソフトウェアプログラムの変更が可能なため、CHAdeMO協議会は仕様変更に短時間で対応することが可能となりました。「今回の作業

図3：CANoeとVTシステムを用いた検定器のシステム図図4：CANoeとVTシステムを用いた検定器：VTシステム

CHAdeMO充電器検定器

① ハードウェア機構

動作要求

電子負荷各種リレー

充電器

（検定対象）

電源ライン

CAN

信号

VTシステム

CANoe

車両エミュレーション機能

試験実行機能

③ ②





では試験仕様そのもののデバッグをしながらソフトウェアプログラムを作成していくという状況でありましたが、試験の変更がCANoe上のソフトウェアの変更だけで済んだ事から、それらを短期間で成し遂げる事ができました」（高橋氏）

車載から車外へ広がるベクターソリューション

CHAdeMO協議会は、今後、当初の目的通りCANoeとVTシステムを用いたCHAdeMO充電器検定器を国内外の第三者認証機関で活用することを視野に入れています。そのために、市場からのフィードバックに対応した試験項目の追加・見直し、およびハードウェアの追加も含めたシステムの改良を検討しています。ベクターは、これまでCANなどの車載ネット

ワークを中心に車載電子システムの開発を支援するソリューションを提供してきました。そこで培った多くのノウハウは、車載電子システムにとどまらず、急速充電器など自動車と外界をつなぐ電子システム開発にも有効であることを、今回の導入プロジェクトは多分に示しています。「今回は検定器開発そのものをベクターに委託したのですが、ベクターはCHAdeMO協議会の正会員ということもあり、まずCHAdeMOのプロトコルについてよく理解いただいた上でシ

ステムの構築をしてもらいました。要求仕様を詰めていく際にベクターの豊富な事例が役立っていたと思います。また検定試験の仕様書から試験プログラムを作成するまでの手順等を整理したドキュメントは、今後協議会で検定器の改定・保守を行うにあたって必要となるだけでなく、CHAdeMO会員のトレーニング資料として役立つ事と思います」（高橋氏）

プロジェクトを振返って

東京電力株式会社 CHAdeMO協議会事務局高橋真氏

「実際の検定では当初作成した試験項目に加えて、電流の大きさや信号を入れるタイミングなどを微妙に変化させた試験を行うことが多々あります。CANoeとVTシステムを導入したことでこのような細かいカスタマイズに対応できる環境が整ったことは大きな成果だと感じています。また、本プロジェクトの担当者であるベクターの森さんがCHAdeMO充電器の設計概念を踏まえて、CANoeやVTシステムの使い方をアドバイスしてくれたのが非常に助かりました」

ベクター・ジャパン株式会社開発ツール部森修治

「CANoeとVTシステムを高くご評価いただき、充電器検定器へと採用頂けたことは弊社にとって大変光栄な事でした。CHAdeMO協議会を通じ、東京電力様を中心とした各車両メーカーとシステム設計を共同で実施させて頂いたが故、強電部分を含む検定器の開発が可能だったと考えています。これからも協議会メンバーの一社として、EV向け急速充電器の普及に貢献できるようより一層の技術的サポートに努めてまいります」

提供元表紙：CHAdeMO協議会図1、図2、図3、図4、図5：ベクター・ジャパン

図5：CANoeとVTシステムを用いた検定器： CANoeのインターフェイス


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


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




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

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

サービスを提供します。ユーザーはSDで提供されたメソッドをRPCを介して利用します（図3、パートA）。また、特定のイベントに対する通知を設定することも可能です（図3、パートB）。アプリケーションは読取および書込関数を使用して任意のプロセスデータにアクセスできます（図3、パートC）。SOME/IPの目的は、与えられた帯域幅を最適に利用して、極めて柔軟な通信を実現することにあります。通信とシグナルはFIBEX 4.1以降か、AUTOSARリリース4.1以降を用いて記述されています。残りのバスシミュレーションにおいては、

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

本稿では、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はネットワーク内でサービスを探索し、また自らの



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

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

のモニターポートを使用すればこの問題は解決しますが、コスト上の理由から、量産用のシステムでこの方法を採れるとは限りません [3]。スイッチはミラーリングと呼ばれる方法を使用し、受信した全パケットをモニターポートに転送します。この方法には、受信したデータパケットがタイムスタンプを持たず、共通の時間基準がないというデメリットがあります。また、多くの場合は有効なパケットのみがモニターポートに転送

されるため、エラー解析も困難です。解析中のネットワークにほとんど影響を与

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

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

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

ただし、フロー制御が必要になるため、アクティブ接続は物理層（OSI Layer 1）上では不可能です。フロー制御はLayer 2以降でなければ利用できません。しかも、フロー制御では一定した遅延時間は保証できません。どの方法を選ぶにせよ、パケットデータの正

確な解析には、物理層にできるだけ近い部分で取得した精密なタイムスタンプが必要です。多くの場合、ネットワーク解析で対象とするバスは1つのEthernetに限らず、他の車載ネットワーク

もその対象に含まれます。そのため、これらのタイムスタンプには他のインターフェイスとの同期が必要です。

開発ツールの選択

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

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

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

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

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

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

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

図3： S O M E / I Pでは、RPC、通知、読取 /書込関数などの多様なアクセスが可能




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

展望

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

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

和訳したものです。

参考文献：[1] Schnelle Wege zur Restbussimulation: Virtuelle

Netzwerke ohne Programmier-Know-how

erstellen (“Quick paths to the remaining bus

simulation: 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

リンク：ベクターの車載Ethernetソリューションwww.vector-japan.co.jp/ethernet


（*）CANoe.IPは現在、CANoe.Ethernetに名称変更されています。

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

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

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

執筆者

Hans-Werner Schaal (Dipl.-Ing.)

Matthias Schwedt(Dipl.-Ing. (FH))

Peter Fellmeth (Dipl.-Ing. (FH))


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


ベクターがEthernet対応を加速ECUの開発・テスト環境を揃える

Vector Report

ECUの開発ツールなどを手がけるベクター・ジャパンは、2014年7月9日（水）にコクヨ

ホールで開催された日経エレクトロニクスセミナー「第3回 Ethernetが変えるク

ルマの未来～鉄道、産業機器にも拡がる～」で、「車載Ethernetの測定・シミュレー

ションツールの課題」と題して講演し、車載Ethernetの開発に必要なツールの要件

および課題と、車載Ethernetに対応した同社のソリューションについて説明した。

　竹本氏はベクターの会社概要を紹介したあと、最初に、車載Ethernet機器の開発や評価に必要な開発ツールの要件と課題について説明した。　現在、ECUおよび車載ネットワークの開発およびテストでは、「レスト・バス・シミュレーション」あるいは「リメイニング・バス・シミュレーション」と呼ばれる手法が一般的に用いられている。ネットワークに接続されるすべてのECUが揃っていないときに、仮想的なECUを構築して必要なメッセージなどをネットワークに送出し、ネットワークのトラフィックを観測しつつテスト対象のECUの挙動を確認するやり方である。　従来のCANバスの場合は、ひとつのバスに複数のECUが接続されるため、CANバスをモニターするだけで各ECUの挙動を把握できるという簡便性があった。また、仮想的なECUの接続も比較的容易である。　一方のEthernetは、ドメインコントローラまたはスイッチを親とするスター型のトポロジーで構成されるため、ECU間のトラフィックをモニターするにはネットワーク・タップと呼ばれる機器を間に挟む必要がある。　こうした違いに加えて、竹本氏は、「CANとは違いEthernetでは上にさまざまなプロトコルが乗るため、開発ツール側ではそれらに対応した複数のプロトコルスタックを装備している必

ベクター・ジャパン株式会社開発ツール部

竹本順一

ベクター・リポート日経BP社発行『日経Automotive Technology 2014年 11月号』掲載記事より



Vect

or R

epor

t

要がある」と指摘した。たとえば、音声や映像データを扱うAVBや、AVBの一部であるAVTP（IEEE 1772）、サービス指向のSOME/IP、診断用のDoIP、時刻同期用の IEEE 802.1AS、および標準的なTCPやUDPなどのサポートが求められる。　このほか、車載Ethernet用の開発ツールには、評価のためにMACアドレスや IPアドレスを自由に設定できる機能や、CRCエラーなどさまざまなプロトコルエラーを疑似的に発生できる機能なども必要と述べた。

主要ソリューションがEthernetに対応

　続いて、車載Ethernetを対象にしたベクターのソリューションを説明した。　ベクターは、CAN、CAN FD、LIN、FlexRay、MOSTなど、さまざまな車載ネットワークに対応したソリューションを提供しているが、いくつかの製品はすでにEthernetにも対応済みだという（図1）。　具体的には、ECUのシミュレーションや測定を行う「CANoe」、ECUキャリブレーションツール「CANape」、ECUのリプログラミングツール「vFlash」、診断テスター「 Indigo」、BroadR-Reachにも対応したネットワークインタフェースハードウェア「VN5610」、AUTOSARに対応した組込ソフト「MICROSAR」などが主な対応

図1：車載Ethernetに対応したベクターのソリューションの一例

製品である。　このうち「 VN5610」は、標準的な100BASE-TXおよび1000BASE-Tのほか、ブロードコムが開発したBroadR-Reachをサポートする、ネットワーク・タップ型のネットワークインタフェースハードウェアである。また、CANおよびCAN FDのモニターも可能である（CAN FDは2014年末からの予定）　「 VN5610」の使い方としてカメラシステムの開発に適用した例を示した（図2）。BroadR-Reachで接続されるカメラとECU間の通信をモニターするために「 VN5610」を両者の間に挿入し、「 VN5610」で取得したバケットを「CANoe.Ethernet」で解析するという流れである。また「CANoe.Ethernet」でSOME/IPのサブスクライブを生成し、ECUからのノーティフィケーションを受け取るといった、サービス指向

測定・解析、シミュレーション、テストCANoe.Ethernet

測定キャリブレーションCANape

ベクターの車載Ethernet対応製品●ツールと組込ソフト

リプログラミングvFlash

診断テスター診断テスターIndigo

DoIPXCP on Ethernet /XCP routing

VN5610VN5610

Ethernet/BroadR-Reach

ISO15118対応組込ソフト

オンボードチャージャー/充電スポット

ECU

ネットワークインターフェース

AUTOSARベーシックソフトウェア

MICROSAR ETH

G/W



Vector Report

「MICROSAR V2G」をそれぞれ提供済みである。　これらソリューションは基本的にはAUTOSAR 4.xに対応しているが、一部機能についてはAUTOSAR 3.xでも利用できるという。　Ethernetコントローラとしては、フリースケールのMPCシリーズ、インフィニオンのTriCore、ルネサスのV850やRH850、テキサス・インスツルメンツの Jacinto、トランシーバデバイスとしては、ブロードコムのBCM89810、テキサス・インスツルメンツのDP83848などに対応済みであることを明らかにした。このほかのコントローラあるいはトランシーバについても要望があれば対応するという。

普及に向けた取り組みを強化

　車載Ethernetのソリューションの拡充を図るベクターは、車載Ethernetの関連団体に参加して普及の一助に努めているという。　竹本氏は、車載Ethernetのアプリケーション拡大を目指したOpen AllianceSIGでツール関連の技術開発を進めるTC4（TCはテクニカル・コミッティの略）に参加して、技術的課題の明確化や情報共有で貢献してきたと述べた。TC4は2013年秋で役割を終えており、現在は欧州の自動車メーカーのニーズを集めながら製品に反映する方向に活動の軸を移している。　国内では高度化・複雑化する車載電子制御システムのソフトウェアやネットワークの標準化を推し進めるJasParの次世代高速LANワーキ

制御の解析にも適用できる（図2の右下）。　同様の使い方はマルチメディア系システムにも応用が可能だ。「CANoe.Ethernet」側でAVBトーカー（たとえばテレマティクスECU）やAVBリスナー（たとえばアンプECU）を模擬しつつ、ナビゲーションECUとラジオECUとの間のパケットを「 VN5610」でモニターするような使い方である。　次に、AUTOSARに対応した組込ソフト「MICROSAR」を紹介した。講演時点で、標準的なTCPやDoIP、SOME/IPにも対応したAUTOSARベーシックソフトウェアモジュール「MICROSAR ETH」、AUTOSARをベースにEthernet AVB対応を追加・拡張したモジュール「MICROSAR AVB」、および、ISO 15118などの充電通信プロトコル用の拡張モジュール

ベクターがEthernet対応を加速ECUの開発・テスト環境を揃える

図2：「CANoe.Ethernet」と「 VN5610」で構成したEthernetカメラシステムの評価セットアップ

カメラ

CANoe.Ethernet

ベクターの車載Ethernet対応製品●カメラシステムでの使用例

SOME/IPNotificationOABR : Open Alliance BroadR-Reach®

CANVN5610

SOME/IPリクエストレスポンス

ECU

OABR

SOME/IP-SDSubscribe

SOME/IP-SDOffer Service

パケット解析

OABR

仮想ECU

ベクター・リポート


www.vector-japan.co.jpwww.vector-japan.co.jp

Vect

or R

epor

t

ンググループに参加中であり、国内自動車メーカーやサプライヤのEthernet導入を支援することを目的に、データ記述フォーマットや産業用Ethernetの情報提供、コンフォーマンスツールの調査、実証実験のサポートなどの活動を行っているという。　講演の最後にまとめとして車載Ethernetの動向を説明した。全般的な動向として、OABR（Open Alliance BroadR-Reach）ベースでの開発や検討がいくつかの自動車メーカーで始まっていることを挙げた。OABRは IEEE化が提案されており、標準規格になればより多くの開発ソリューションが市場に出回って、車載Ethernetの導入を推し進めるだろうと期待を述べた。　ツールについては、車載Ethernetを採用している自動車メーカーはまだ少数にとどまっているため、CANほどに充実した開発環境が揃うまでにはまだ時間がかかるだろうとの見通しを示した。技術的には、AUTOSAR 4.1のARXML（システムディスクリプション）をデータベースフォーマットとして使う動きが少しずつ出ているほか、サービスディスカバリや制御コマンドには自動車メーカーごとに異なるプロトコルが使われる方向だという。AVBの採用も進む見込みである。　「ベクターは車載Ethernetの分野でも、自動車メーカーやサプライヤに向けて、開発やテストを支援するソリューションやサービスを提供していく」と竹本氏は述べ、同社ソリューションでの対応を加速させながら、車載Ethernetの導入と普及に努めていく考えを改めて示した。

本稿は『日経Automotive Technology 2014年11月号（日経BP社）』に掲載された記事「第3回 Ethernetが変えるクルマの未来～鉄道、産業機器にも拡がる～ Review」より転載したものです。


V ector Academy

はじめてのCAPL

はじめに本稿は、CANoe/CANalyzerのCAPL

機能について初歩的な内容をまとめたものです。「プログラミングは初めて」、「C言語がよく分からない」という方でも本稿を読めばCAPLが使えるようになることを目指して作成いたしました。CAPLノードの作成方法から基本的なメッセージ送信方法、受信メッセージに対する反応の記述、データ値の可変など、CAPLの基礎をご紹介していきます。

ここではCAN通信を前提として説明しておりますが、オプションにより他のプロトコル（LIN・FlexRayなど）を使用の場合にも一部ご参考いただけます。

なお、CAPLのさらなる詳細につきましては、「CAPLクイックガイド」をご参照ください。「CAPLクイックガイド」（PDF資料）は、ベクター・ジャパン会員専用ページ「myVector」にてご覧いただけます。また、CAPLの実践的な知識についてお知

りになりたい方には、ベクターにてCAPL関連のトレーニングも開催しておりますので、そちらも是非ご利用ください。

3. CAPLノードの役割CAPLは、バス上に存在する1つの仮想ノー

ドとしてメッセージ送受信を行うことができます。CANoeでは、この仮想ノードを複数作成することできるので、仮想ネットワークのシミュレーションを行うことが可能です（CANalyzerは1つのみ）。また、異なるバス間のゲートウェイとして使用したり、フィルターやトリガーといった解析のための機能拡張に用いたり、さまざまな役割をすることができます。（図1）

1. CAPLとは？CAPL（キャプル）はCommunication Access

Programming Languageの略称であり、CANoe/CANalyzer専用のプログラミング言語です。

2. CAPLの特徴●C言語に似ている●「何かが起きた時に何かを行う」イベントドリ

　　ブンのプログラム実行形式で動作する

ECU

重要な注意事項】 ●本稿はCANoe full および CANalyzer pro の各機能を基準に説明しています。●CANoe run、pexおよびCANalyzer fun、exp等のグレードにより、機能制限がございます。機能制限の詳細につきましては、ベクターの別途資料「CANoe/CANalyzerの機能マトリクス」をご覧ください。

図1


はじめてのCAPL V ector Academy

4. CAPLノードの設置CAPLを配置するためのノード（ブロック）を

設置します。CAPLノードの設置位置は任意ではなく、プログラムの機能に合わせ、考えて配置されなければなりません。以下に、実バスにメッセージ送信を行うため

のノード設置を説明します。

4.1 CAPLノード挿入

4.1.1 CANoeの場合

CANoeでは、[シミュレーション設定 ]Windowに設置します。

1. CANoeメニューバーより[ビュー ]-[シミュ　　レーション設定 ]を選択します。

2.シミュレーション設定Windowの赤黒2　　重横線の上で右クリックして、コンテキスト　　メニューより［ネットワークノードを挿入］を　　選択します。（図2）

4.1.2 CANalyzerの場合

CANalyzerでは、[測定設定 ]Windowに設置します。

1. CANalyzerメニューバーより[ビュー ]-[測　　定設定 ]を選択します。

2. 測定設定WindowのSendブランチの

　　ホットスポット（）の上で右クリックして、　コンテキストメニューより［CAPLノードを

　　挿入］を選択します。3. メッセージを生成し、実バスに送信するため

　　のCAPLプログラムは、測定設定Window　の「SENDブランチ」に挿入します。　（図3）

右クリック

挿入されたノード

右クリック

評価ブランチ

SENDブランチ

図2

図3


4.2 CAPL配置に関する注意

CAPLブロックを直列に配置した場合、下流にあるCAPLノードはフィルターのような動作をします。そのため、上流のメッセージは下流のCAPLブロックに遮られ、メッセージを通過させません。

CANalyzerの場合、測定設定WindowのSENDブランチ内に（図4のように）直列配置すると、上から流れてきたメッセージはすぐ下のCAPLブロックにより遮断されます。メッセージの遮断は全てのメッセージ通過を

明示的に出力するプログラムを実装することにより、回避することができます。

メッセージを生成し実バスに送信する必要のないプログラム（データの解析にのみ使用するCAPLプログラム）は、測定設定Windowの評価ブロック前に設置することを推奨します。

図5はCANalyzerの測定設定Windowですが、各評価ブロックへの流れはCANoeも同様です。CANalyzerのSENDブランチは、CANoeでは［シミュレーション設定Window］になります。

図5

図4

on * {

output(this); }

A

B

C

A

B

C

※注意

　上記プログラムを実装しないと　Cのメッセージしか出力されません!!

CBA

C

ABC全てを出力

結果Cのみ出力

Aメッセージ通過ABメッセージ出力

ABメッセージ追加ABCメッセージ出力

Aメッセージを遮断しBメッセージのみ出力

Bメッセージを遮断しCメッセージのみ出力

【出力プログラム】　重要!!

評価ブランチ

SENDブランチ

実バスへ

評価ブロック



図6

図7

図8

4.3 ファイル管理に関する注意　　（参考）

CANoe/CANalyzerのファイル管理は、図6のような基本構成でフォルダ管理すると便利です。

[Project_1]と名前付けしたフォルダを大きなくくりとし、その中に[DB]と[Node]という2つのフォルダを予め作成します。そして、このコンフィグレーションで使用するデータベースを[DB]に予め保存します。作成したCAPLファイル（拡張子can）の保存先は、この予め作成しておいた [Project_1]-[Node]を指定し、名前を付けて保存します。こうしておくことで、使用するPCが変更になっ

た場合も、[Project_1]をコピーして一括で移管することが可能となり、一部ファイル不足やコンパイル時のエラーを回避することができます。

5. CAPLファイルの作成CAPLファイルの保存先と名前を決定します。

5.1 CANoeの場合

1. ノードを右クリックして［設定］を選択し、　　 [ノード設定]を開きます。（図7）

2. [ノード設定]の [ファイル]をクリックして　　 [ファイルを開く]画面を表示し、CAPLファ　　イルの保存先と名前を決定します。（図8）

Aメッセージ通過ABメッセージ出力

ABメッセージ追加ABCメッセージ出力

　　　　Project_1

　　　　　　　 Configuration コンフィグレーションファイル [拡張子 cfg]

　　　　　　　　　 DB → データベースファイル　 [拡張子dbc]

　　　　　　　　　 Node → CAPLファイル [拡張子 can]

　　　　　　　　　 Log → ログファイル [拡張子blf/asc等 ]


5.2 CANalyzerの場合

1. ノードを右クリックして［設定］を選択し、　　 [CAPLノードを設定]を開きます。（図9）

2. [CAPLノードを設定]の [選択 ] をクリック　　して [ファイルを開く]画面を表示し、CAPL　　ファイルの保存先と名前を決定します。　　（図10）

図9

図10



6. CAPLブラウザーの起動[編集 ]をクリックすることにより、CAPL

Browser が起動します。（図11）

CANoeの場合

【CAPLブラウザーの画面】　(基本画面はCANoe/CANalyzer共通です )

CANalyzerの場合

A B

C D

E

ナビゲーターテキストエディターCAPL関数エクスプローラー※

シンボルエクスプローラー※

出力Window

ABCDE

CAPLプログラムの構造をツリーで表示しますCAPLプログラムのソースコードを記述しますCAPLのイベントハンドラーとCAPL関数の一覧を表示しますシグナルをテキストエディターにドラッグ＆ドロップで挿入可能コンパイルの結果が表示されます

※CAPL関数エクスプローラー（C）とシンボルエクスプローラー（D）はタブ切り替えで表示

ナビゲーターテキストエディター

出力Window

図11


7. CAPLの記述

7.1 CAPLの用語

「何かが起きた時に何かを行う」イベントドリブンのプログラム実行形式で動作するCAPLには、イベントハンドラーというものがあります。またプログラミングでは、関数・変数という言葉をよく耳にしますが、CAPLにも関数・変数というものがあります。以下に、これらの用語（「イベントハンドラー」、

「関数」、「変数」）について説明していきます。

7.1.1 イベントハンドラーとは

CAPLでいう「イベント」とは、ユーザーによるキーボード操作やメッセージの受信などをいい（図12）、「イベントハンドラー」とは、発生したイベントを検知して何らかの処理を実行させる機能のことをいいます。CAPLの特徴である「何かが起きた時に何かを行う」の、『何かが起きた時』に呼ばれるのがイベントハンドラーです。CAPLは、イベントハンドラーによって発生したイベントに対応して処理を行います。

これらの「イベント」が発生したら、イベントハンドラーが呼ばれます。それぞれのイベントハンドラーは個々に独立しており、変数と関数によって連結されプログラム化されます。

7.1.2 関数とは

関数（英：function）とは、データを受け取り、決められたとおりの処理を実行するさまざまな命令です。プログラムは、関数を組み合わせて記述します。CAPLには専用の関数があります。

7.1.3 変数とは

変数（英：Variable）とは、プログラムで扱われるデータを一定期間保管して必要なときに利用できるようにするための「名前の付いた箱」のようなもので、この箱から、利用するときに値を持ってくることができるものです。CAPLではC言語等に用いられる一般的な変数と、CAPL専用の変数があります。

7.2 CAPLのイベントハンドラー

CAPLは、イベントハンドラーによって発生したイベントに対応して処理を行います。イベントハンドラーには次のようなものがあ

り、それぞれのイベントは表1のようになっています。

青字については、本稿の第7章～8章で実際の使用例を説明します。なお、表1のリストはCANoe/CANalyzerのCANに関するものだけです。プロトコルオプション（LIN/MOST/FlexRay/J1939等）により追加イベントがあります。

　　バスイベント　　　　　　キーボードイベント　　　タイマーイベント

図12

表1

※1: システム変数とは、コンフィグレーション（.cfg）に定義し使用できるCANoe/CANalyzer専用の変数です。※2: 環境変数とは、データベース（.dbc）に定義し使用できるCANoe専用の変数です。

CAN　on busOff 　on errorActive　on errorFrame　on errorPassive　on message <CAN ID>　on warningLimit　on *

System　on key <Key>　on preStart　on preStop　on start　on stopMeasurement　on timerValue Objects　on signal <signal>　on signal_update <signal>　on sysvar <sysvar>　on sysvar_update <sysvar>　on envVar <EnvVar>

CANコントローラーがバスオフへ変化CANコントローラーがエラーアクティブ状態へ変化エラーフレームの受信CANコントローラーがエラーパッシブ状態へ変化指定したCANメッセージの受信CANコントローラーがワーニングリミットへ到達メッセージ／フレームの受信（指定無し）

キーボードのキーを押す測定初期化（測定開始前）測定初期化（測定停止前）測定開始測定停止設定したタイマー時間経過

シグナルの変化シグナルの更新システム変数 (※1)の変化システム変数の更新環境変数 (※2)の変化（CANoeのみ）

イベントハンドラーイベント



図14

図13

7.3 CAPLの関数

CAPLの特徴である「何かが起きた時に何かを行う」の『何かを行う』の部分で使われるのがCAPL関数です。数多くのCAPL関数がありますが、表2によく使われる基本的なものを一部抜粋しました。これらについては、本稿で後ほど説明します。

7.3.1 関数write()を使ってみましょう　　　~演習~

CAPLは、C言語と同じように、{ } で囲まれたステートメント（命令文）と呼ばれる構成ブロック（1行以上のセミコロンが後ろに付くコード）を使用してプログラムします。

CAPLは基本的にイベントプロシージャーの命令文で構成されており、指定したイベントが発生することにより実行されます。

1. CAPLプラウザーでプログラムを記述2. コンパイルする3. 保存する4. 実行する

以上のCAPL記述の基本的な流れを体感いただければと思います。

write

setTimer

cancelTimer

output

stop

出力Windowへテキスト出力（C言語関数printf ()と同等）タイマーを設定（本稿第7.5.3章を参照）タイマーを取り消す（本稿第8章を参照）メッセージ変数を出力（本稿第7.5章で使用しています）測定を終了（本稿第8章を参照）

CAPL関数特徴（どのような時に使われるか）

CANoe/CANalyzerの測定を開始時に出力Windowで名前表示させてみましょう。

　イベントハンドラーはon start　CAPL関数はwrite を使用します

以下を参考に、CAPL記述の前にCAPLブラウザーの起動までを終了しておきます。本稿第4章（p.31）CAPLノード挿入本稿第5章（p.33~34） CAPLファイルの作成本稿第6章（p.35）　CAPLブラウザーの起動

①CAPL起動で説明したCAPLブラウザー画　面左のナビゲーター（区分A）より、[Event 　Handlers] を右クリックし [新しいイベントハ　ンドラー ] - [on start] を選択し、テキストエ　ディター（区分B）にon startを追加します。　（図13）

② [CAPL Browser]の画面中央、テキストエ　ディター（B部分）に追加されたon startの { } 　内にwrite関数を用いて図14のように記述　します。

出力Windowに表示させる文字を（）中の""内に記述します。最後に ;を付けるのを忘れずに!

on start{

　　write （"辺区田太郎"）;

}

表2


③ツールバーのアイコンまたはキーボードのF9　を押下して、コンパイルします。（図15）

図15

図16

***

コンパイルアイコン

CAPL Browser下方の出力Windowには、コンパイル結果が表示されます　　コンパイル成功「Successfully compiled ・・・」と表示　　コンパイル失敗「Error: Compiler returned: ・・・」と表示

お名前が出力Windowに表示されたらCAPLプログラム成功です。

④CANoe/CANalyzerで測定開始し、出力　Windowに表示されたことを確認しましょう。　（図16）

ドラッグ＆ドロップで入力も可能

Configuring compiler..Start compiling 'C:\Documents and Settings\vector\My Documents\Samlpe_write.can'..Successfully compiled 'C:\Documents and Settings\vector\My Documents\Samlpe_write.can' to 'C:\Documents and Settings\vector\My Doc



表4

表3

7.4 CAPLで使用される変数

CAPLで使用できる変数とよばれるものには、4つの種類があります。

1. 一般的な変数（C言語などで使用される　　もの）

2. CAPL固有の変数3. システム変数4. 環境変数

それぞれの特徴は、表3のとおりです。

CAPLブラウザーに定義する変数は、定義した場所により「グローバル変数」または「ローカル変数」として使用されます。グローバル変数とローカル変数の特徴は、表4のとおりです。

※1: システム変数は、CANalyzer fun では扱えません。※2: 環境変数は、CANoeのみで扱うことができ、CANalyzerでは扱えません。

変数の種類定義する場所特徴

変数（一般的なもの）

CAPLの変数

システム変数 (※1)

環境変数 (※2)

CAPLブラウザー

CAPLブラウザー

コンフィグレーション

データベース

「整数」「浮動小数点」「文字列」のデータ型がある「メッセージ」と「タイマー」のデータ型があるCANoe/CANalyzerの cfgファイルに保存されるdbcファイルに定義され、CANoeでのみ使える

※1: ローカル変数は、他のイベントハンドラーでは使用できません。定義されたハンドラー以外はその変数を　見つけることができませんので、使用するとコンパイルエラーとなります。※2: CAPLの変数は、初期値を指定しない限り’0’に初期化されます。そして、測定中は新しい値が設定される　まで変数は割り当てられた値を保持します。

グローバル変数

ローカル変数

Variables｛｝セクション

各イベントハンドラー内

変数の種類定義する場所使用できる場所特徴

CAPLプログラム全体

定義したイベントハンドラー内でのみ (※1)

CANoe/CANalyzerの測定が開始され、CAPLプログラムが実行された時に初期化 (※2)

定義されているイベントハンドラーのプログラムが最初に実行された時に初期化 (※2)


表5

variables

{

　message 0x100 msg={DLC=5}; /* ID 0x100 (DLC5) のCANメッセージを「msg」と定義*/

　message ABSdata MSG2; /*データベースに定義されたメッセージABSdataを「MSG2」と定義*/

　Timer TM1; // 「 TM1」という名前で秒単位のタイマーを定義

　msTimer T2; // 「 T2」という名前でミリ秒単位のタイマーを定義

}

7.4.1 CANにおける変数のデータ型

CAPLの変数はvariablesセクションに定義します。下記は定義の例です。

CAPLで使用できる一般的な変数

　整数

浮動小数点

　文字列

よく使用されるCAPL（固有）の変数メッセージ

　タイマー

-32765…+32767C/C++:short

-2147483648…+2147483647C/C++:long

-9223372036854775808～ 9223372036854775807C/C++: long long

0…255C/C++:unsigned char

0…65535C/C++:unsigned short

0…4294967295C/C++

0～18446744073709551615(0xffffffffffffffff)

C/C++: unsigned long long

IEEEによる

IEEEによる

-128…+127 C/C++:char

CANメッセージ用秒単位のタイマー用ミリ秒単位のタイマー用

16 bit

(2 byte)

32 bit

(4 byte)

64 bit

(8 byte)

8 bit

(1 byte)

16 bit

(2 byte)

32 bit

(4 byte)

64 bit

(8 byte)

64 bit

(8 byte)

64 bit

(8 byte)

8 bit

(1 byte)

Int

long

Int64

byte

word

dword

qword

float

double

char

message

Timer

msTimer

ビット (バイト)名前用途データ型補足

符号付

符号なし

CAN秒タイマーミリ秒タイマー



※ [Alt] [Esc] [Fn] [Tab] [BackSpace]キーなど、特殊用途キーは一部使用できません。

7.5 イベントハンドラー、変数、　　関数の使用例

次に、よく使用されるイベントハンドラーを使用した基本的なCAPLの記述例を紹介します。

7.5.1 イベントハンドラー　on key

on key は、パソコンのキーボード押下に対して反応します。（表6）

表6

イベントハンドラー「 on key」への定義例

on key　‘a’ // [a]キーを押した時に反応（大文字・小文字は区別されます）

on key　‘ ’ // スペースバーを押した時に反応

on key　F1 // [F1]キーを押した時に反応

on key　shiftF3 // [Shift]–[F3]キーを押した時に反応

on key　PageUp // [Page Up]キーを押した時に反応

on key　Home // [Home]キーを押した時に反応

on key　* // どれかのキーを押した時に反応

1. 何かが起きた　（イベント発生）

キーボードの aが押された

2. 何かを行う　（イベントに対する処理）

出力Windowに「‘a’ が押されました」と表示する

CANメッセージ（ID：0x100）を送信し、

出力Windowに「0x100を送信」と表示する

記述例

variables{}

on key 'a'　// aキー押下で反応{　write (“'a' が押されました”); }variables{　message 0x100 msg1={DLC=6};　　　　// 送信メッセージ0x100の　　　　　定義}

on key 'a'{　output (msg1);　// aキーを押す　　　　　ごとに0x100を1回送信　write (“0x100を送信”);}

　使用するイベントハンドラー on key


7.5.2 イベントハンドラー　　　　on message

on message は、CANメッセージの受信に対して反応します。（表7）

表7

イベントハンドラー「 on message」への定義例

on message 100 // メッセージ100（10進数）に反応、受信チャンネルは考慮されません

on message 0x100 // メッセージ100（16進数）に反応、受信チャンネルは考慮されません

on message EngineData // データベースより参照定義したメッセージEngineDataに反応

on message CAN1.0x200 // CAN1でメッセージ200（16進数）を受信したら反応

on message * // 全てのメッセージ受信時に反応

on message CAN2.* // CAN2で受信した全てのメッセージに反応

on message 100-200 // ID100から200（10進数）の間の全てのメッセージに反応

on message EngineData, ABSdata //EngineData ABSdataどちらか受信時に反応


メッセージ 0x100を受信した

2. 何かを行う（イベントに対する処理）

出力Windowに「0x100を受信」と表示する

　

0x200を送信して出力Windowに「0x200を送信」と表示する

記述例

variables{}

on message 0x100　// ID0x100のメッセージ受信で反応{　write (“0x100を受信”); }variables{　message 0x200 Sendmsg={DLC=4};　// 送信メッセージ0x200の定義}

on message 0x100{　output (Sendmsg);　// 0x100受信ごとに0x200を送信　write (“0x200を送信”);}

使用するイベントハンドラー on message



表8

7.5.3 イベントハンドラー　　　　on start / on timer

on start は、CANoe/CANalyzerの測定開始に対して反応します。

on Timer は、タイマー設定時間経過に対して反応します。（表8）

イベントハンドラー「on timer」への定義例

on timer ‘a’ // [a]キーを押した時に反応（大文字・小文字は区別されます）

on timer ‘ ’ // スペースバーを押した時に反応

on timer F1 // [F1]キーを押した時に反応

on timer shiftF3 // [Shift]–[F3]キーを押した時に反応

on timer PageUp // [Page Up]キーを押した時に反応

CAPLはTimerの概念が1つのキーとなります。表8の記述例を見ると、「on start」と「on timer」の両方にCAPL関数「setTimer」が記述されていますが、これらはどのような役割をしているのでしょうか。また、どのようにしてCAPLからメッセージの周期送信が行われるのでしょうか。これらについて、以下に解説していきます。


CANoe、 CANalyzerが測定開始された

2. 何かを行う（イベントに対する処理）

500ms後にタイマー T1を開始しCANメッセージ（ID 0x100）を50ms周期送信する

記述例

variables{　message 0x100 msg1={DLC=6};　msTimer T1;}

on start{　setTimer(T1,500); /*測定開始500ms後に　　　　　　　　　　タイマー T1を呼び出す*/

on timer T1{　setTimer(T1,50); //50ms毎 T1をセット　output(msg1); //メッセージを出力}

使用するイベントハンドラー on start / on timer


【Timerの特徴】1. タイマーはイベントが発生した後、設定時間　が経過した後に関係するon timerを呼び出す2. タイマーの開始には、setTimer()関数を用い　て時間を設定する3. タイマー経過後に関連するタイマーイベント　ハンドラーが呼ばれる4. タイマーイベントハンドラーは、タイマー経　過後にイベントを実行すると同時に初期化さ　れる5. タイマーイベントは停止条件がない限り、繰　り返し呼ばれ、処理が行われる

図17

setTimerは次の2つの役割を担います。① Variablesで定義したタイマーを（設定時間　経過後に）呼び出す② on timer内に記述したプログラムを（設定　時間経過後に）処理する

図17をご覧ください。

①で、測定開始と同時にon startが呼ばれる（ここで1つ目の setTimerスタート）

　→ ②500ミリ秒後にタイマー“T1”が呼ば　　れる（つまりon timer T1が呼ばれ、2つ　　目の setTimerがスタート）

　　→ 100ミリ秒後にCAPL関数outputに　　　よってメッセージが出力される

　このように、onTimer内の setTimerに記述した時間経過ごとにoutputが呼ばれてメッセージを送信することで、CAPLからの周期送信が行われています。

測定スタート

測定開始からの時間の流れ

タイマーイベント

0ms 600ms 700ms

50ms

メッセージ出力



50ms 50ms

800ms500ms

タイマー T1の呼び出し

②on timer T1　{　　setTimer(T1,50);　　output(msg1);　}

　①on start　　{ 　　　setTimer(T1,500);　　}



表9

8. 便利なCAPL関数の紹介

詳細は、本稿の第11章で紹介しているCAPL関数一覧（リファレンス）PDFをご参照ください。

resetCanEx

cancelTimer

getLocalTimeString

stop

指定したチャンネルを初期化、バスオフ時の復帰

CANoe/CANalyzerがバスオフに至った場合にも、自動復帰することができます。

本稿の第7.5.3で説明したTimerを停止します。これによりタイマーによるメッセージ周期送信をしている場合に送信を停止することができます。

イベント発生時の時刻を取得します。文字列のフォーマットはddd mmm dd hh:mm:ss yyyy (例: Fri Aug 21 15:22:24 2014) です。

オンラインの測定を停止します。

on busOff{ resetCanEx(1);　//カッコ内は初期化するチャンネル　　　　　　　　　　 //上の記述はCAN1を初期化}

on key 'c'{ cancelTimer(T1);　//cキーを押下でタイマー T1を停止}

variables{ char timeBuffer[64];　//時刻取得用の変数の定義}on errorFrame　//エラーフレーム受信で反応{ getLocalTimeString(timeBuffer);　//イベント発生時の時間を格納

write （"送信停止 %s",timeBuffer);　//取得時間をwrite関数にて　　　　　　　　　　　　　　　　　　　 //出力Windowに書き込む}

on key ' ' 　//スペースキー{ stop();　//CANoe/CANalyzerの測定を停止}

CAPL関数特徴／使用例記述例


9. キーワード“this”CAPLの「 this」とは、on messageなどのプ

ロシージャー内で自動生成される変数です。on messageで受信したメッセージのデータ（シグナル）アクセスには、「this」を使用します。on Keyでは、「this」を使用することにより変数として使用できます。右に例を示します。

variables{ message 0x200 Sendmsg={DLC=4};　//送信するメッセージを定義}

on message 0x100　//メッセージ0x100受信時に反応{ Sendmsg.byte(0) = this.byte(0); // 送信メッセージの0byte目に　　　　　　　　　　　　　　　　　　　 0x100の0bite目の値を代入 output(Sendmsg);　// 0x200を出力}

on message EngineTemperature //DBに定義されたメッセージ　　　　　　　　　　　　　　　　　　 ”EngineTemperature”受信時に反応{ if (this.SigTemp.phys > 100) // シグナル”SigTemp”が物理値で100を超えたら　　write ("値が上限を超えました"); // 出力Windowに"値が上限を超えました"と　　　　　　　　　　　　　　　　　　書き込む}

10. ゲートウェイCAPLを用いてCANoe/CANalyzerをゲー

トウェイ（※）ノードとして動作させることができます。右記は、2つのCANバスの間でメッセージを受け渡すための記述例です。オンラインヘルプ（CANoe/CANalyzerメニュー [ヘルプ ]-[目次 ]）にもゲートウェイに関する記述がありますので、ご参照ください。

※ゲートウェイとは、異なるネットワークと接続　するためのネットワークノードのこと。

① 2つのバス間で、メッセージをそのまま受け渡すための記述例------------------------------------------------------------------------------------------　　on message CAN1.* //CAN1でメッセージを受信

　{

　　　message CAN2.* msg; //CAN2から送信するメッセージの定義

　　　if(this.dir != rx) return; //重要!! CAN2から送信するメッセージに

　　　　　　　　　　　　　　　　反応しないようにする記述

　　　msg = this;

　　　output(msg);

　}

　　on message CAN2.* //CAN2でメッセージを受信

　{


　　　if(this.dir != rx) return; //重要!! CAN2から送信するメッセージに

　　　　　　　　　　　　　　　　反応しないようにする記述

　　　msg = this;

　　　output(msg);

}

------------------------------------------------------------------------------------------



------------------------------------------------------------------------------------------------------------------------------------------

　　variables

　{

　　　 message CAN2.0xFF GWmsg={DLC=8}; //送信するメッセージ IDおよびDLCの定義

　　　const int targetID = 0xc9; //特定 IDを定義

　}

　on message CAN1.* //CAN1でメッセージを受信　

　{


　　　if((this.id==targetID) && (this.dir==rx)) //ターゲットとなる特定 IDを受信した時に反応

　　　{

GWmsg.byte(0)=this.byte(0); //各バイトへデータ値の入れ込み

GWmsg.byte(1)=this.byte(1);　 //ここでは8バイト分を行っているが

GWmsg.byte(2)=this.byte(2);　//実データ長に合わせ削除等を行う

GWmsg.byte(3)=this.byte(3);





output(GWmsg);

}

else if(this.dir == rx) //重要!! CAN1から送信するメッセージに反応しないようにする記述

{

msg = this;

output(msg);

}

　}

------------------------------------------------------------------------------------------------------------------------------------------

② 2つのバス間で、メッセージをそのまま受け渡すが、ある特定の IDを受信した場合に IDを変更し、データバイト値にはそのまま送信されたデータを入れ込んで送信する記述例


11. CAPL関数一覧V8.2以降のCANoe/CANalyzer CAPL関

数一覧（リファレンス）は、CANoe/CANalyzerのオンラインヘルプにあります。オンラインヘルプの起動方法について、以下

（図18、19）に示します。

【オンラインヘルプ起動方法】

V8.1.までのCAPL関数の一覧（リファレンス）は、CANoe/CANalyzerのDVDメディア内に日本語版PDFが収録されています。

DVD内保存場所： ¥Documentation¥Manual¥CAPL&COM_ManualPDFファイル名： CAPLFunctions_JP.pdf

※バージョンにより保存場所やファイル名称およびイメージが異なる場合がございますが何卒ご了承ください。

図18

図19

CANoe/CANalyzer V8.2を起動し、メニューバーの [ヘルプ] より [目次]を選択

Windowsのスタートより、 [ Vector CANoe（CANalyzer） V8.2] - [User Assistance（Japanese）] - [オンラインヘルプ]を選択

オンラインヘルプの起動後、画面左側のツリーから「 CAPL関数」を選択してください。



12. 参考（文法）ご参考までに、一般的なC言語等のプログラ

ミングに充当する内容に関して紹介します。

12.1 演算子について

演算子は、C言語と同じものを使用することができます。簡単なものをいくつか紹介します。

①算術演算子加算「+」、減算「-」、乗算「*」、除算「 /」、余り

「%」を求めます。

②比較演算子等しい値「 ==」、等しくない値「 !=」、不等号

「 >」「 >=」「 <=」「 <」を調べます。（表10）

③論理演算子真と偽を論理演算で評価します。（表11）

④インクリメント /デクリメント演算子変数を1加算「++」、変数を1減算「--」します。

⑤ビット演算子各変数をビット単位で処理 (計算 )するための

演算子で、以下のようなものがあります。（表12）

⑥シフト演算子2進数の各ビットを右または左にずらす演算

子です。（表13）

==

!=

>

>=

a == b

a != b

a > b

a >= b

aとbは等しいaとbは等しくないaはbより大きいaはb以上

演算子使用例説明

&&

||

!

a && b

a || b

a ! b

AND(かつ )　戻り値 :TRUEまたはFALSE

OR(または )　戻り値 :TRUEまたはFALSE

NOT(否定 )TRUEをFALSEへ、FALSEをTRUEへ変更

演算子使用例説明

&

|

~

ビット積（AND）

ビット和（OR）

ビット否定（NOT）

a=b&c;

a=b|c;

a=b~c;

bとcの各ビットの論理積の結果をaに代入a = 1 & 7 ← 結果aは1 (0001 & 0111 ◊ 0001)

bとcの各ビットの論理和の結果をaに代入a = 1 | 7 ← 結果aは 7 (0001 | 0111 ◊ 0111)

bの各ビットを反転しその結果をaに代入a = ~1 ← 結果aは 14 (0001 ◊ 1110)

演算子意味使用例説明

>>

<<

右にシフト

左にシフト

a=b>>c;

a=b<<c;

bを右にcビットずらすbを左にcビットずらす1 << 3 ← 結果は 8 (0001 ◊ 1000)

演算子意味使用例説明

表10

表11

表12

表13


12.2 制御文

CAPLは、C言語と同じように、制御文を使用することができます。また、反復処理から脱出

するための「 break文」や、反復処理をスキップするための「 continue文」も使用できます。

以下の表14～16に、ステートメント（命令文）の説明と基本例文を記します。

IF文

IF-ELSE文

SWITCH文

if文を使用して式を評価し、評価結果が「真 (True)」の場合のみ命令が実行されます。評価結果が「偽 (False)」の場合、コードブロックは実行されません。

注記： if文はネストする (=入れ子構造にする) ことが可能です。例えばif文の中にさらに (1つ以上の) if文を記述することができます。

if-else文も式を評価できます。評価した式の結果によって、2つの命令のいずれかが実行されるという点が if文と異なります。式の結果が「真 (True)」であればif節の命令が実行され、結果が「偽 (False)」であれば、else節の命令が実行されます。

注記： if-else文も、if文同様にネストする ( = 入れ子構造にする) ことができ、たとえばif節の中にさらにif-else文を、else節の中にさらにif-else文を記述することができます。

switch文は、if-else文と同じ制御になりますが、2つ以上の選択肢を必要とする場合に使用すると、より便利です。switch文の中にcase文を複数記述することによって1つの文に2つ以上の分岐を作ることができます。switch文は、式の「値」に応じて実行内容を分岐します。「値」と「整数または文字の定数」を比較し、一致した選択肢の文を実行します。つまり、1つ以上のcase文と比較し、｛｝内で最初に一致した文の制御が実行されます。case文はいくつあってもよく、1つの｛｝の中にすべて記述できます。caseの後ろは、整数の定数、文字の定数、定数式のいずれかになり、定数式には、変数や関数を置くことはできません。

注記：どの case文にも値が一致しない場合、default文が実行されます。default文がない場合 (defaultは省略も可能 )、switch文を抜けます。

if (条件文 ){ 　..条件文の結果がTrueの場合に実行される命令文..}例：　if (Blinker_On == 1)　{　　 write (“Blinker is on.”);　}

一般的な形式：if ( 条件文 )　{ ...条件文の結果がTrueの時に実行される命令文... }else　{ ...条件文の結果がFalseの時に実行される命令文... }　例：　// 時計の「分」を進める関数　　　increment_clock_minutes()　　　{　　　　int clock_minutes;

　　　if (clock_minutes >= 60) 　　clock_minutes = 0;　　　else 　　clock_minutes++;　　　}　

例：　�oat value1, value2, result;　char operator;　...　switch (operator)　{　　　case ‘+’: result = value1 + value2; 　break;　　　case ‘-’: result = value1 - value2; 　break;　　　case ‘*’: result = value1 * value2; 　break;　　　case ‘/’: result = value1 / value2; 　break;　}

ステートメント説明一般的な形式

表14



WHILEループ

DO-WHILEループ

FORループ

while文では、その条件が成立している間 ( = 比較している式が「偽（False）」になるまで) 同じ処理が繰り返し行われます。

注記：命令文が実行される前に、必ず最初に条件式が評価されます。結果が「偽 (False)」の場合には、whileループ内の命令文は実行されません。

do-while文は、while文と同じ制御ですが、実行中に少なくとも1度はループ内の命令を実行する必要がある場合に用いると、より便利です。このループ文は、最初に命令文を実行し、次に条件式を評価します。条件式が「真 (True)」の場合、それが「偽 (False)」になるまで命令文の始めから繰り返し実行 (ループ ) されます。

for文もまた、while、do-whileと同様に繰り返し実行されるループ文の1つです。定められた回数だけ繰り返し実行する場合に用いると便利です。

注記：「初期設定式」とは、最初にfor文が処理される時に1度だけ実行される式です。「条件式」の意味はwhile文のものと同じで「真 (true)」の時にループします。「再設定式」は、“繰り返す処理”が最後まで終了した時に実行される式で、ループするたび (「繰り返す処理」が終了するたび ) に実行されます。

while (条件式 ){　..条件式の結果がTrueの場合に実行される命令文..};

例：// カウントが10になるまでループする　while (count < 10)　{ 　count ++;　}

do{ ...条件式の結果がTrueの場合に実行される命令文...}while (条件文 );

例： // カウントが10になるまでループする　do　{ count ++;　}　while (count != 10);

for (初期設定式; 条件式; 再設定式 ){　...条件式の結果がTrueの場合に実行される命令文...}

例：// 10回ループする　int i, count;　for ( i = 0; i < 10; i ++ )　{ count ++;　}

注意：条件式を省略した場合、for文は無限ループになりますのでご注意ください。またCAPLではWaitのための for文は使用できません。


表15


BREAK文

CONTINUE文

RETURN文

break文はswitch、do-while、while、forの繰り返し文の中でループから抜け出すために用います。

continue文は、switch、do-while、while、forの繰り返し文の中で、ループ中の残りの処理をスキップして、ループの先頭に戻ります。

return文はユーザー定義の関数で、イベントプロシージャーに値や式の値を返す場合に使用します。return文は、ループの中に引数がない場合、ループを抜けることもできます。

例はSWITCH文参照

例：　int x;　while ( x != 0 )　{　　doThis (x);　　if( x == 4 ) continue;　　doThat (x);　}

例：

　　long Power( int x, int y )

　{ int i; long result; result = 1; for ( i = 1; i <= y; i++ ) result *= y; return result;　}


表16



ベクター・ジャパン株式会社カスタマーサポート部

ベクターのカスタマーサポートは、ベクターのCANoe、CANalyzer、CANapeをはじめ、各種ハードウェア

製品をお使いいただく際の技術的なお問い合わせ窓口となっております。

ベクターWebサイトでは、技術サポートに関する情報やFAQなどを掲載しておりますので、是非ご覧くだ

さい。

CAPLのさらなる詳細や実践的な知識について学びたい方のために、ベクターではCAPL関連のトレーニ

ングも開催しておりますので、そちらも是非ご利用ください。

執筆者

ベクターのトレーニング

リンク：ベクター「技術サポート」ページhttps://vector.com/vj_support_jp.html

ベクター「トレーニング」ページwww.vector-japan.co.jp/training




12月に『人とくるまのテクノロジー展2014 名古屋』出展ベクターは、来たる12月11日（木）～12日（金）にポートメッセなごや（名古屋市国際展示場）にて開催される『人とくるまのテクノロジー展2014 名古屋』に出展いたします。本イベントの最新情報につきましては、下記URLをご参照ください。

『人とくるまのテクノロジー展2014 名古屋』◎会期： 2014年12月11日（木） 10：00～20：00／2014年12月12日（金） 10：00～17：00◎会場：ポートメッセなごや（名古屋市国際展示場）◎URL：「人とくるまのテクノロジー展」オフィシャルサイト　http://expo.jsae.or.jp

News from Vector

New

s from V

ector

6月に『Vector TechDay in OSAKA』を開催しましたベクターは、2014年6月に大阪にて、「Vector TechDay in OSAKA」と題してセミナー形式のイベントを開催しました。次世代車載ネットワーク、AUTOSAR、ASAMといった自動車業界で注目のトピックに関する講演を実施し、ヤマハ発動機株式会社様によるCANoe導入事例やECUテストの自動化など開発業務の効率化についての講演も行われました。ご多忙の折にもかかわらず多くのお客様にお越しいただき、盛況のうちに執り行うことができました。ご来場くださいました皆様、誠にありがとうございました。

10月に『AUTOSAR Roadshow』を開催しましたベクターは、10月14日（名古屋）、10月16日（東京）の日程にて

『AUTOSAR Roadshow 2014』を開催しました。本イベントは、AUTOSAR開発の最新情報をセミナー形式でお届けする弊社主催のイベントで、今年で3回目の開催となりました。今回は、ビー・エム・ダブリュー（BMW）株式会社様、パナソニック株式会社様による講演に加え、ISO 26262、車載Ethernet、テスト効率化などの業界注目トピックとAUTOSAR開発との関連についてベクターが講演を実施しました。今回も多くのお客様にお越しいただき、おかげさまで盛況のうちに終えることができました。ご来場いただきました皆様に心より厚く御礼申し上げます。


11月に『Vector TechDay in FUKUOKA』開催ベクターは、11月13日(木)に福岡にて「Vector TechDay in FUKUOKA」と題したセミナー形式のイベントを開催します。本イベントでは、CANoe/CANalyzerの基本操作、CAPL基礎をはじめ、ECUテストの工数低減、EthernetやCAN FDなどの次世代車載ネットワークについてのセミナーを実施します。本イベントは事前お申込み制となっており、すでに多くのお客様にお申込みいただきました。誠にありがとうございます。当日、皆様のご来場をお待ちしております。

『Vector TechDay in FUKUOKA 2014』◎会期： 2014年11月13日（木） [セミナー] 9：30～17：10 [展示会] 10：00～17：00◎会場：福岡市博多区博多駅東1-16-14　リファレンス駅東ビル5F （JR博多駅筑紫口より徒歩約4分）

「CANoe/CANalyzerバージョン8.2（日本語版）」リリースベクターの車載ネットワーク開発・テストツール「CANoe」および解析ツール

「CANalyzer」の最新バージョン「CANoe/CANalyzerバージョン8.2（日本語版）」が7月にリリースされました。　バージョン8.2の主な特長は以下のとおりです。　● SOME/IP PDUを表示　● 使いやすくなったトレースWindowおよびグラフィックWindow　● オプションSCOPEがFlexRayに対応開始最新情報や詳細については、ベクターWebサイトをご覧ください。

「CANape」バージョン13.0（日本語版）」リリース予定（2014年10月～11月頃）※

ベクターの「CANape」は、測定データの取得だけでなく、ECU開発、キャリブレーション、診断にも使用できるECUキャリブレーション用万能ツール。その最新バージョン「CANapeバージョン13.0（日本語版）」がリリースされました。　バージョン13.0の主な特長は以下のとおりです。　● 強力な印刷機能とレポート機能　● 統計解析手法を簡単にコンフィギュレーション　●リアルタイム性のあるVN8900インターフェイス上でスタンドア　ローンのバイパス実行が可能　● VN5610インターフェイスと連携してSOME/IPおよびAVBを含　　む車載Ethernet（BroadR-Reach®）に対応最新情報や詳細については、ベクターWebサイトをご覧ください。

「vTESTstudioバージョン1.1」リリースベクターのテスト設計ツール「vTESTstudio」の最新バージョン1.1がリリースされました。　バージョン1.1の主な特長は以下のとおりです。　● 試験対象システム（SUT）のスティミュレーションカーブをグラフィカルに定義する波形エディター　● さらなる再利用性および可読性の向上を実現するため、サブダイアグラムによりテストダイアグラムを構造化　● 抽象的なテストケース定義とテストベクターごとの具体的なパラメーター値に基づいたテストケースリストを定義　● IBM Rational DOORSと完全に連携可能　● テストユニットウィンドウ内でのC#やCAPLコードのデバッグ最新情報や詳細については、ベクターWebサイトをご覧ください。

YouTubeで「ベクター・ジャパンチャンネル」を公開中ベクター・ジャパンは、公式YouTubeチャンネルとして「ベクター・ジャパンチャンネル」を公開しております。CANoe/CANalyzerの機能紹介や、お客様から要望の高いECUテストソリューション、VTシステム概要などの製品・ソリューション動画を配信していますので、是非ご覧ください。

制御パネル、表示パネル、解析Window、トレースWindowを表示したCANoeユーザーインターフェイス

さまざまなWindowを備えたCANapeのユーザーインターフェイス

■ベクター・ジャパンHP 　　主要製品　　 CANoe（およびCANalyzer）　CANoeバージョン8.2 www.vector-japan.co.jp/canoe　CANalyzerバージョン8.2 www.vector-japan.co.jp/canalyzer

■ベクター・ジャパンチャンネル　　https://www.youtube.com/user/vectorchanneljapan

■ベクター・ジャパンHP 　　主要製品　　 CANape　CANape　　www.vector-japan.co.jp/canape

■ベクター・ジャパンHP 　　主要製品　　 vTESTstudio　vTESTstudio　　www.vector-japan.co.jp/vTESTstudio

※リリース日は予告なく変更になる場合もございます。


12月に『人とくるまのテクノロジー展2014 名古屋』出展ベクターは、来たる12月11日（木）～12日（金）にポートメッセなごや（名古屋市国際展示場）にて開催される『人とくるまのテクノロジー展2014 名古屋』に出展いたします。本イベントの最新情報につきましては、下記URLをご参照ください。

『人とくるまのテクノロジー展2014 名古屋』◎会期： 2014年12月11日（木） 10：00～20：00／2014年12月12日（金） 10：00～17：00◎会場：ポートメッセなごや（名古屋市国際展示場）◎URL：「人とくるまのテクノロジー展」オフィシャルサイト　http://expo.jsae.or.jp

News from VectorN

ews from

Vector

6月に『Vector TechDay in OSAKA』を開催しましたベクターは、2014年6月に大阪にて、「Vector TechDay in OSAKA」と題してセミナー形式のイベントを開催しました。次世代車載ネットワーク、AUTOSAR、ASAMといった自動車業界で注目のトピックに関する講演を実施し、ヤマハ発動機株式会社様によるCANoe導入事例やECUテストの自動化など開発業務の効率化についての講演も行われました。ご多忙の折にもかかわらず多くのお客様にお越しいただき、盛況のうちに執り行うことができました。ご来場くださいました皆様、誠にありがとうございました。

10月に『AUTOSAR Roadshow』を開催しましたベクターは、10月14日（名古屋）、10月16日（東京）の日程にて

『AUTOSAR Roadshow 2014』を開催しました。本イベントは、AUTOSAR開発の最新情報をセミナー形式でお届けする弊社主催のイベントで、今年で3回目の開催となりました。今回は、ビー・エム・ダブリュー（BMW）株式会社様、パナソニック株式会社様による講演に加え、ISO 26262、車載Ethernet、テスト効率化などの業界注目トピックとAUTOSAR開発との関連についてベクターが講演を実施しました。今回も多くのお客様にお越しいただき、おかげさまで盛況のうちに終えることができました。ご来場いただきました皆様に心より厚く御礼申し上げます。


11月に『Vector TechDay in FUKUOKA』開催ベクターは、11月13日(木)に福岡にて「Vector TechDay in FUKUOKA」と題したセミナー形式のイベントを開催します。本イベントでは、CANoe/CANalyzerの基本操作、CAPL基礎をはじめ、ECUテストの工数低減、EthernetやCAN FDなどの次世代車載ネットワークについてのセミナーを実施します。本イベントは事前お申込み制となっており、すでに多くのお客様にお申込みいただきました。誠にありがとうございます。当日、皆様のご来場をお待ちしております。

『Vector TechDay in FUKUOKA 2014』◎会期： 2014年11月13日（木） [セミナー] 9：30～17：10 [展示会] 10：00～17：00◎会場：福岡市博多区博多駅東1-16-14　リファレンス駅東ビル5F （JR博多駅筑紫口より徒歩約4分）

「CANoe/CANalyzerバージョン8.2（日本語版）」リリースベクターの車載ネットワーク開発・テストツール「CANoe」および解析ツール

「CANalyzer」の最新バージョン「CANoe/CANalyzerバージョン8.2（日本語版）」が7月にリリースされました。　バージョン8.2の主な特長は以下のとおりです。　● SOME/IP PDUを表示　● 使いやすくなったトレースWindowおよびグラフィックWindow　● オプションSCOPEがFlexRayに対応開始最新情報や詳細については、ベクターWebサイトをご覧ください。

「CANape」バージョン13.0（日本語版）」リリース予定（2014年10月～11月頃）※

ベクターの「CANape」は、測定データの取得だけでなく、ECU開発、キャリブレーション、診断にも使用できるECUキャリブレーション用万能ツール。その最新バージョン「CANapeバージョン13.0（日本語版）」がリリースされました。　バージョン13.0の主な特長は以下のとおりです。　● 強力な印刷機能とレポート機能　● 統計解析手法を簡単にコンフィギュレーション　●リアルタイム性のあるVN8900インターフェイス上でスタンドア　ローンのバイパス実行が可能　● VN5610インターフェイスと連携してSOME/IPおよびAVBを含　　む車載Ethernet（BroadR-Reach®）に対応最新情報や詳細については、ベクターWebサイトをご覧ください。

「vTESTstudioバージョン1.1」リリースベクターのテスト設計ツール「vTESTstudio」の最新バージョン1.1がリリースされました。　バージョン1.1の主な特長は以下のとおりです。　● 試験対象システム（SUT）のスティミュレーションカーブをグラフィカルに定義する波形エディター　● さらなる再利用性および可読性の向上を実現するため、サブダイアグラムによりテストダイアグラムを構造化　● 抽象的なテストケース定義とテストベクターごとの具体的なパラメーター値に基づいたテストケースリストを定義　● IBM Rational DOORSと完全に連携可能　● テストユニットウィンドウ内でのC#やCAPLコードのデバッグ最新情報や詳細については、ベクターWebサイトをご覧ください。

YouTubeで「ベクター・ジャパンチャンネル」を公開中ベクター・ジャパンは、公式YouTubeチャンネルとして「ベクター・ジャパンチャンネル」を公開しております。CANoe/CANalyzerの機能紹介や、お客様から要望の高いECUテストソリューション、VTシステム概要などの製品・ソリューション動画を配信していますので、是非ご覧ください。

制御パネル、表示パネル、解析Window、トレースWindowを表示したCANoeユーザーインターフェイス

さまざまなWindowを備えたCANapeのユーザーインターフェイス

■ベクター・ジャパンHP 　　主要製品　　 CANoe（およびCANalyzer）　CANoeバージョン8.2 www.vector-japan.co.jp/canoe　CANalyzerバージョン8.2 www.vector-japan.co.jp/canalyzer

■ベクター・ジャパンチャンネル　　https://www.youtube.com/user/vectorchanneljapan

■ベクター・ジャパンHP 　　主要製品　　 CANape　CANape　　www.vector-japan.co.jp/canape

■ベクター・ジャパンHP 　　主要製品　　 vTESTstudio　vTESTstudio　　www.vector-japan.co.jp/vTESTstudio

※リリース日は予告なく変更になる場合もございます。



お問い合わせ

Info

rmat

ion


東　京　TEL : 03-5769-6980

名古屋　TEL : 052-238-5020








TEL : 03-5769-6973

















CONTENTS


〒140-0002　



2014年11月発行


02

22

06

10

14

18

26

30

54



02

06

10

14

18

22

Cover Story


Technical Article






Vector Report


Vector Academy

はじめてのCAPL

News from Vector









Testing

ECU

Diagnostics

Distr. Systems

Deve

lopm

ent

Consulting

Tech

nica

l

Software

ECU

Calibration

ECU



お問い合わせ

Info

rmat

ion


東　京　TEL : 03-5769-6980

名古屋　TEL : 052-238-5020








TEL : 03-5769-6973

















4193-529305　14/10/20　初校　奥山　表紙 - うら

4193-529305　14/10/23　初校　再山　表紙 - おもて

y y sÍy6 y ¯´ S o...¯^ P;tx â Tm O s Ý ´ M F µ ¨ z Í ² w é z U b M q V Ç U w 0 ªz» á...

Documents

Transcript of y y sÍy6 y ¯´ S o...¯^ P;tx â Tm O s Ý ´ M F µ ¨ z Í ² w é z U b M q V Ç U w 0 ªz» á...