V J 10 - Vector › cms › content › know-how › VJ › PDF › ...Vector Journal Vol.10 01 06 10 15 20 26 34 40 48 Technical Article 発行元：ベクター・ジャパン株式会社

06

10

15

20

26

34

40

48

Technical Article

発行元：ベクター・ジャパン株式会社

〒140-0002　

東京都品川区東品川2-2-20

天王洲郵船ビル16F

2015年5月発行

©2015 Vector Japan Co., Ltd. 不許複製

02Technical Article

■1車両およびラボ内における運転支援システムの検証（ADAS）

Vol. 10

C O N T E N T S

■2大量の測定データを合理的かつ柔軟に解析

■3測定とリプログラミングの高速化～FlexRayよりもシンプルでCANよりも帯域幅の広いCAN FDの利用～

■4診断要件から通信まで～カーエレクトロニクス開発のトレンドは標準化～

■5自動化によるテスト品質の向上～HILテストシステムの自動化が農業機械のISOBUSでの動作を保証～

■6機能定義から整備工場まで～「V字モデル」を超えた先行技術設計データの提供～

Vector Report

ベクター・リポート：「つながる」クルマのアプリ開発イベントにCANapeが貢献　　　　　　　　　　　～シリコンバレーのクリエーターに机上で最適なアプリ開発環境を提供～

インタビュー： ECUキャリブレーションプロセスを効率化する「vCDM」　　　　　　　　　～ECUキャリブレーションの品質向上と期間短縮を実現～

Vector Academy

ECUテストのプログラミングをもっと効率的に～CAPLの基礎と使用上のヒント&コツ～

News from Vector

Vector JournalMagazine For Vector’s Technology

Vector Journal Vol.10 01

06

10

15

20

26

34

40

48

Technical Article

発行元：ベクター・ジャパン株式会社

〒140-0002　

東京都品川区東品川2-2-20

天王洲郵船ビル16F

2015年5月発行

©2015 Vector Japan Co., Ltd. 不許複製

02Technical Article

■1車両およびラボ内における運転支援システムの検証（ADAS）

Vol. 10

C O N T E N T S

■2大量の測定データを合理的かつ柔軟に解析

■3測定とリプログラミングの高速化～FlexRayよりもシンプルでCANよりも帯域幅の広いCAN FDの利用～

■4診断要件から通信まで～カーエレクトロニクス開発のトレンドは標準化～

■5自動化によるテスト品質の向上～HILテストシステムの自動化が農業機械のISOBUSでの動作を保証～

■6機能定義から整備工場まで～「V字モデル」を超えた先行技術設計データの提供～

Vector Report

ベクター・リポート：「つながる」クルマのアプリ開発イベントにCANapeが貢献　　　　　　　　　　　～シリコンバレーのクリエーターに机上で最適なアプリ開発環境を提供～

インタビュー： ECUキャリブレーションプロセスを効率化する「vCDM」　　　　　　　　　～ECUキャリブレーションの品質向上と期間短縮を実現～

Vector Academy

ECUテストのプログラミングをもっと効率的に～CAPLの基礎と使用上のヒント&コツ～

News from Vector

Vector JournalMagazine For Vector’s Technology

運転支援システムは、車両周囲の状況を多彩なセンサーを介して把握します。ドライバーに対する警告から運転中の（半）自律的な介入に至るまでのすべてが、物体認識アルゴリズムの正確な結果に基づいて行われます。本稿では、物体データの検証と画像処理アルゴリズムのテストで一般的に生じる課題を取り上げます。測定とキャリブレーションに必要な高いデータスループットは、XCP標準によって実現されます。

車両およびラボ内における運転支援システムの検証

TechnicalArticle 01

02 Vector Journal Vol.10


運転中、人間は自分の感覚器官、特に目と耳を通じて周囲の情報を取得します。収集された情報は脳内の信号処理によって解釈され、判断が行われて、アクションが開始されます。こういった判断の中には、「駐車するのに十分なスペースが路肩にあるか」、「前方車両との車間距離の調整は必要か」といったものも含まれます。運転支援システム (先進運転支援システム、ADAS) は、ドライバーによるこれらの判断を支援し、それによって安全性を強化するとともに、経済性だけでなく快適性/利便性を向上させます。

センサーのデータとアルゴリズムのデータへのアクセス

運転支援システムには、いわば「注意力の高い助手」として、周囲の状況を確実に検出する能力が求められます。運転状況や車両周囲の情報をECUに提供するのに非常によく使われているのがレーダーや超音波、そしてビデオセンサーです。こうしたセンサーのデータを複雑なアルゴリズムが処理して、道路標識、駐車車両、その他の交通参加者などの物体を検出し、アクションを開始します。センサーシステムを検証するには、アルゴリズムの結果を調べ、それを実際の状況と比較すれば事足ります。たとえば、ACC (Adaptive Cruise Control) システムの距離

測定用レーダーで説明すれば、センサーは戻ってくるレーダービームの反射から物体を検出し、ECUは各物体までの距離の情報を座標として提供します。この際、センサーに届くすべてのレーダー反射

を取得する必要はありません。ただし、データを記録して後からラボ内でスティミュレーションに用いるなどの場合は、アルゴリズムが入力変数とするすべてのデータを測定しなければなりません。こうした場合、10万を超える信号が毎秒数MBのデータレートで発生することは珍しくありません。道路標識検出システムや車線維持支援機能

には、ビデオセンサーと画像処理ECUが使用されます。ビデオ画像をアルゴリズムが分析し、道路標識やレーンマークが検出されます。このようなECUのデータ処理では、一般にマイクロコントローラーの性能の高さが要求の1つとなります。一方、センサーのデータがビデオとレーダーのどちらのシステムに由来するものであっても、測定機器の要件はほとんど変わりません。肝心なのは測定データを転送するための高性能のソリューションです。測定機器を使用してアルゴリズムの評価と最適化を行う場合、それらはアルゴリズムの入出力変数とアルゴリズム内部の必要なすべての中間変数を、コントローラーに新たな負荷を与えることなく取得できなければなり

ません (図1)。これに必要なデータスループットを実現す

るには、CANやFlexRayなどのシリアルバスシステムではパフォーマンスに限界があります。そのため、この大量の測定データの転送には、Nexus、DAP、Auroraなどのコントローラー固有のインターフェイスが用いられます。個々の具体的な測定作業に合わせて個別のソリューションを開発する手間を省くには、広く定着した実績ある標準を利用するのが合理的です。こうした際に最適なのが、ベクターが提供する測定 /キャリブレーションハードウェア「VX1000」です。VX1000は、小型のアダプター(POD：プラグオンデバイス) を介してコントローラーインターフェイスからベースモジュールにデータを送ります。データはここで標準化されたXCP on Ethernetに変換され、そのデータストリームが高いスループットでPCへと送出されます[1]。

Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06

図1：入出力データ、周囲の状況に関するデータ、アルゴリズムの評価に関連するすべてのデータの取得。すべてのデータとパラメーターの連携を示す

Technical Article 01

www.vector-japan.co.jp


実データとセンサーデータの検証

ECUの物体検出結果は、実際の状況と比較して検証しなければなりません。たとえば、前方車両との路上での車間距離は本当に45.5mなのでしょうか。センサーのデータを事実と比較するには、まず、その実際のデータを入手しなければなりません。運転の状況はセンサーシステムとは別のカメラが記録しています。これにより、ECUが検出した物体をビデオ画像と比較し、物体検出アルゴリズムを迅速かつ確実に検証することが可能となります。ベクターの測定 /キャリブレーションソフトウェア「CANapeオプションドライバーアシスタンス」を使用すれば、物体データをビデオ画像にオーバーレイできます。こうすることで、開発者はそれがどこで検出されたのか、そして検出されたものが状況に合っているかを判断できます。図2で画像上に表示されている各Xマークが、センサーがデータを取得した箇所を表しています。センサーが検出した前方距離や側方への角度といった座標は、PCのビデオ画像上のピクセル座標に変換されます。

アルゴリズムの承認と最適化

検出された物体と実際の状況との間にずれがある場合、そのアルゴリズムには最適化が必要です。これはシステムのキャリブレーションパラメーターを変更して行いますが、そのためにはキャリブレーションパラメーターが実行時にRAM上に置かれ、書込アクセスで変更可能になるようコード内で定義する必要があります。これらのパラメーターのキャリブレーションには、測定 /キャリブレーションプロトコルであるXCP[2]のメカニズムが使用でき、開発者は実行時にパラメーター値を変更し、そのフィードバックをその場で得ることができます。XCPはECU以外にも利用できます。たとえば、アルゴリズムはDLLの形で、PC上の仮想ECUとして実行することもできますが、キャリブレーションと測定をXCPで行えば、PCをラピッドプロトタイピングのプラットフォームにすることが可能です。では、XCPドライバーを最も簡単にDLLに組

み込むにはどうすればよいのでしょうか。そしてそのDLLに、どのようにして入力データをリンクすればよいのでしょうか。Simulinkベースの開発であれば、MathWorksの「Simulink Coder」を使用して、1つのモデルから多様なターゲットプラットフォーム用のコードを生成できますが、ベクターの「CANape」を、このターゲットプラット

フォームに指定することが可能です。CANape用のコード生成のプロセスでは、XCPドライバーが自動的に統合され、このプロセスが終了すると、XCPドライバーを含むDLLとA2L形式のECU記述ファイルが生成されます。これら2つがCANapeに統合され、DLLの入出力ポートが実際のデータにリンクされます。測定が始まると、CANapeは測定されたセンサーデータを入力ベクトルとしてアルゴリズムに伝送し、仮想ECUが結果を計算します。キャリブレーションパラメーターは、実際のECUと同じ方法で最適化されます。CANapeに付属するC++プロジェクトは、手作業で記述したコードと同様に使用できます。

センサーデータによるスティミュレーション

センサーシステムの開発者は、次の2つの問題を抱えています。

> 多くの場合、何らかの意味を成す現実的なデータは車両内のセンサーからしか得られず、それに必要な環境がラボ内にない

> センサーデータの再現には膨大な手間が掛かる

図2：測定用レーダーシステムが検出した物体を示す周囲のビデオ画像と、物体の鳥瞰図




Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06



そのため、事前に記録したセンサーデータを用いるECUのスティミュレーションは、そのECUが実物か仮想かを問わず、開発における重要な要素となっています。データはECUのメモリーに直接書き込めるため、入力の手間が省け、VX1000システムを使用すれば必要な帯域幅を確保できます。また、センサー入力を介してECUにデータを転送することもできます (図3)。仮想ECUのスティミュレーションでは、録画し

たビデオや測定ファイル内の信号をCANapeの入力ポートにストリーミングする処理が行われますが、実際のECUの場合は、物理的なインターフェイスの検討が必要です。たとえばビデオシステムでは、ビデオセンサーの信号を、録画した交通状況を再生しているモニター上にルーティングできます。ECUは常に同じ方法で、すなわち同じビデオ、同じ信号を用いてスティミュレーションされるため、データの再現性が保証されます。アルゴリズムの動作に何らかの変化があれば、それは入力ベクタの変化によるものではなく、キャリブレーションの結果で生じたものに他なりません。仮想、実物のいずれのECUでも、スティミュレーションはデータを入力に供給するだけでなく、必要な状態や前提条件をXCP経由で設定する場合にも使用できます。

まとめ

ECUの最適なキャリブレーションには多くの手間が掛かりますが、測定 /キャリブレーションツールはECUと通信するため、コードの調整は不要です。また、A2Lの記述ファイルを生成するなどのプロセスを多数定義できますが、これらのアクティビティーはいずれも、ECUのタスクからは独立して実行されます。この際の標準のソリューションとなるのが、あらゆるタイプのECUに非常に適しているXCPです。運転支援システムには、データ量やパフォーマンスの点で特別な要求が出てくる場合があります。しかし、CANapeやVX1000製品ラインナップのデバイスを始めとする既存のXCPベースのツールを使用して、手軽にADAS ECUのためのソリューションを実現することも可能です。これらのツールは、ビデオデータへの対応から、画像処理アルゴリズム開発のためのラピッドプロトタイピングプラットフォームの利用に至る、既存ソリューションの発展的な開発の中で、既存の開発プロセスにシームレスに、無理なく統合できます。

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

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

リンク：CANapeおよびCANapeオプションドライバーアシスタンスwww.vector-japan.co.jp/canape

VX1000

www.vector-japan.co.jp/vx1000

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

Technical University of Karlsruheで電気工学を専攻し、測定および制御工学のほか、情報および生産工学を中心に研究。2003年にシュツットガルトのVector Informatik GmbHに入社し、測定およびキャリブレーションの製品ラインでカスタマーリレーションおよびサービスのチームリーダーを務めています。

執筆者

Andreas Patzer

図3：ビデオベースの仮想ECUをCANapeでスティミュレーションする際の多様な入力源。E CUはカメラや録画データ、VX1000ソリューション経由の実際のオンラインデータを入力源とする


自動車メーカーのテストベンチや耐久性試験では、車両コンポーネントの振る舞いに関わる重要な情報が現実に即した条件下で収集されます。ただし、生成されるデータ量が膨大で、データ間の相互関係も複雑であることから、多くの場合はその後の関連するデータセットの特定と解析に非常に時間が掛かります。Daimler AG (ダイムラー) は、ベクターの測定/キャリブレーションツールであるCANapeの自動データ評価機能を利用し、オートマチックトランスミッションのテストにおける測定データ解析の高速化を図っています。

TechnicalArticle 02

大量の測定データを合理的かつ柔軟に解析



Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06



ダイムラーのオートマチックトランスミッションの開発は、1960年の4速変速機からスタートしました。その技術設計は、現在の標準から見ればかなり単純なものと言えるかもしれません。その後、快適性ニーズの拡大、ギア比の増大、燃料消費量の削減、エンジンの強化、追加のギアといった多彩な新しい要求をバネに、技術開発は急速な進歩を遂げました。たとえば発進エレメントに変更を加え、遊星ギアとトルクコンバーターを追加した結果、1995年には電気油圧式のトランスミッション制御を装備した最初のモデルが登場しています。

7G-Tronic Plusはこうした開発史の頂点に位置するオートマチックトランスミッションで、設計は2010年、最大1000Nmのトルクに対応し、最も小型の4気筒、後輪駆動のCクラスから、AMGの高性能モデルに至る幅広い車両への搭載が可能となっています。Sprinterバンの一部のバリアントにもこのトランスミッションが採用されています。「燃費の最適化」、「走りの楽しさ」、「乗り心地」という一見相反する要求を見事に融合したこのトランスミッションは、2011年にダイムラー社内のEnvironmental Leadership Awardを受賞しています。

オートマチックトランスミッションに求められる数多くのパラメーター最適化

実装が多様なモデルに及び、その範囲が極めて広いため、求められる運転の振る舞いを実現するにはECUパラメーターの最適なキャリブレーションが必要です。製品の成熟度を高める過程では、無数のテストベンチ試験と耐久性走行試験が重ねられました。日常の試験で蓄積される測定データはサーバーに保存され、開発やキャリブレーションを担当する技術者はそこからデータにアクセスします。このような大量の測定データを評価・解析する際に問題になるのは、限界値の違反や過剰な熱応力といったエラーが発生したデータセットをいかに特定するかです。ギアシフト操作の不良によるエラーは、たとえば振動や振る舞いのぎごちなさの形で表面に現れることが多く、運転者や搭乗者もそれに気付きます。クラッチ操作で摩擦が許容値を超えれば過剰な熱応力が発生し、それに伴って摩耗が進みます。

実績ある解析プロセスが限界に直面

測定データには多様なフォーマットがあり、それらは測定 /キャリブレーションツールのCANapeや、その他のデータロガーから収集されます。これまで、データを評価する際は、まずそれをダイムラーの社内ツールで処理し、Excelファイルに書き出す方法が採られていました (図1)。その後、Excelのマクロでそのデータをグラフ化し、エラーが発生した「トリガーポイント」をユーザーが判別します。それらの結果を使用して、関連する測定ファイルをCANapeに読み込めば、ようやくそこに解析ポイントが表示されます。この方法は煩雑であるだけでなく、他にも不都合や制限がありました。Excelの処理が非常に遅く、大容量データではこれがさらに悪化するのです。加えて、Excelの表では行の総数に上限があり、処理できるデータには限りがあります。グラフィック表示のオプションもわずかしか提供されません。ソリューションの後続開発のための保守作業もダイムラーが行わなければなりませんでした。

図1：テストベンチや耐久性試験車両から生成された測定データはサーバー上に保存され、キャリブレーション担当の技術者はそこから評価を行います


データ解析機能でデータを自動評価

CANapeはECUのキャリブレーション、テストベンチ試験や耐久性試験時の測定データのログ記録、評価などの目的で、ダイムラーですでに広く利用されています。そのため、担当の責任者は、ベクターのこのツールをベースに実装プランを策定しました。CANapeではグラフィック表示機能が測定データの処理に合わせて最適に調整されているうえ、重要な前提条件の1つである社内/プロジェクト独自の評価アルゴリズムを定式化することも、内蔵のプログラミング言語を使用することで可能です。

キャリブレーションツールを解析とグラフィカル表示のプラットフォームに

使いやすい解析ツールを極力迅速に入手するため、ダイムラーはこのコンセプトの実現をベクターに依頼しました。ベクターの使命はダイムラーが求める評価アルゴリズムをCANapeのスクリプトで記述し、その結果をグラフィカルに表示することでした。今回、対象となる測定データの解析にはCANapeのデータ解析機能が使用されています。解析結果では、ユーザーは測定ファイルのエラーの発生個所を詳しく表示できます (図2）。CANapeは解析を実行するプラッ

トフォームとしても、またその結果を表示するプラットフォームとしても使用できます。サイズの制限は解消され、100GBの容量のデータを手間なく処理できます。設定においては、ユーザーは測定データを選

択して、用意されている評価の一覧から調べたい内容と一致するもの、たとえばアップシフトやダウンシフトなどを選び、解析プロセスを開始します（図3）。評価が完了すると統計データが生成され、解析の概要が表示されます。このデータからは、特に1-2シフトが合計で約1,200回発生したことが読み取れます (図4)。たとえば、熱データをXY図の他の物理パラメーターに重ねて表示するなども可能です。これによってデータ点の集まりが形成されますが、その点の1つ1つがシフト操作を表しています。ユーザーは限界値から外れた点を図上の位置から特定できます。点の1つを選択するとそれに関連する測定ファイルが読み込まれ、大抵はその値をグラフの時間軸に合わせて表示できます。シフト操作が行われた時間のセグメントが直接表示されます。

CANapeではWindowの内容が時間同期されるため、選択したデータ点の測定時点と正確に一致するタイミングでのトルクやエンジン回転数といった特定の内容が、他のすべてのWindowに表示されます。これらのWindowにはシグナルの応答だけ

でなく、摩擦仕事や摩擦仕事率の最大許容値を始めとする限界値のラインも表示できます。この限界値からの逸脱点は、シフト操作で発生した異常やエラーを表します。これによって、詳しい調査が必要なギアチェンジ操作の特定が容易になります。

測定データ評価の柔軟な適合

ダイムラーでテストやキャリブレーションを担当する技術者は、CANapeのデータ解析機能を使用して、基本的にすべての測定データの解析全般を行い、異常がなかったか、また望ましくない事象が発生しなかったかを調べることができます。これは開発者が既存の資料データをさらに効率的に利用するための重要なステップです。そしてこれが最終的に、ある特定のECUソフトウェアの成熟度が、要求されるレベルにまで達したかをより迅速かつ正確に判断できることにつながります。解析に対する要求は絶えず変化します。スク

リプトはエンドユーザーが修正することも、またベクターがサービスとして修正することも可能です。何らかの理由でCANapeの言語ツールが力不足だという場合は、CコードやSimulinkモデルから関数ライブラリーを別途生成し、それらをCANapeのDLLとして使用できます。こうするこ

図2：データ解析機能を使用し、不良 /良好なギアシフト操作を2軸グラフで特定します。これによって異常を迅速に検出できます



Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06




Technical University of Karlsruheで電気工学を専攻し、測定および制御工学のほか、情報および産業工学を中心に研究。2003年にドイツ・シュツットガルトのVector Informatik GmbHに入社し、測定およびキャリブレーションのプロダクトラインでカスタマーリレーションおよびサービスのチームリーダーを務めています。

執筆者

Andreas Patzer

とにより、求められるあらゆる評価の実装が可能になります。

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

図4：トラクションアップシフトの評価事前定義済みの表示Windowの情報に基づき、耐久性試験の初期アセスメントをあらかじめ実施できます

提供元：見出し画像 /図1～4：Daimler AG

リンク：CANape　www.vector-japan.co.jp/canape


図3： CANapeのデータ解析用のインターフェイスには、ダイムラーの技術者の個別の要求に応じる事が可能な機能があり、カスタマイズが行えました

Polytechnic College of Reutlingenで情報通信を専攻し、サプライヤーにプログラマーとして2年間勤務した後、European School of Businessで修士号を取得。2007年にオートマチックトランスミッションのテストエンジニアとしてDaimler AGに入社し、オートマチックトランスミッションの評価のためのテストスタンドと車両テストを担当しています。

Erhan Tepe


CAN FD (CAN with Flexible Data rate：可変データレート対応のCAN) は、CANバスにおける1つの技術革命です。その技術的な複雑さは標準のCANバスと変わらないものの、実現できる帯域幅ははるかに大きいことから、CAN FDはEthernetとともに次世代のネットワークの一つとして考えられています。ベクターのネットワーク専門家が2つの一般的なアプリケーション、すなわちXCPを経由したECU内部シグナルの測定とECUのリプログラミングを、CAN FDバスシステムを用いて検証しました。

TechnicalArticle 03

測定とリプログラミングの高速化～ FlexRayよりもシンプルでCANよりも帯域幅の広いCAN FDの利用～


XCP on CAN FDによるECU測定

ECU開発では、開ループ/閉ループの制御アルゴリズムに使われる複数のシグナルやパラメーターを測定、キャリブレーションすることが、キャリブレーションの重要なユースケースとなっています。ECU開発者によく使われるXCP (Universal Measurement and Calibration Protocol) はASAMにより標準化された測定/キャリブレーションプロトコルであり、その現行バージョンである1.2には、新しいXCPトランスポート層としてCAN FDが導入されています。XCPの使用により、ベクターのCANape（図1）をはじめとする測定 /キャリブレーションツールを利用して、操作中にリアルタイムでパラメーターを修正し、ECUの挙動の変化を測定することが可能になります。CANバスシステムの場合、監視するシグナルの数によっては伝送媒体の帯域幅がすぐ限界に達するおそれがありますが、XCP on CAN FDではその能力がペイロードで最大64バイト、データフェーズのデータレートで少なくとも5Mbit/秒にまで拡張できます。

XCP on CAN FDのデータスループット：理論と実践

CAN FD対応のCANバスにおけるXCPで利用できる最大のデータスループットを推定するために、複数のECUシグナルを測定した場合の、フレームサイズとフレームあたりの利用可能なペイロードとを比較して調べました。データスループットはバス負荷を100%と想定して算出されています。CANおよびCAN FDのフレームに含まれるフィールドの実際のサイズを図2および図3に示します。ただし、フレームのサイズはCANとCAN FDのどちらについても正確には予測できません。バス内のECU間で、シグナルのエッジを確実に同期させるため、フレームにはコンテンツに応じたスタッフビットが別途挿入されますが、このビット数を事前に把握することができないためです。このようなスタッフビットに依存するフレームサイズの増減を、最善のケースと最悪のケースのシナリオを解析してモデル化しました。データスループットの計算結果をグラフ化

すると扇形になり（図4、図5)、フレームはいずれも、実際のコンテンツに応じてこの範囲内に含まれるものと予想できます。理論上の計算値を検証するため、シミュレーション環境下で、実際のユースケースを反映した測定を行いました。

実験環境は測定 /キャリブレーションソフトウェアのCANape、適切なハードウェアインターフェイス、PCベースのECUエミュレーションから構成され、そこでCAN/CAN FDドライバーの入出力間でのパフォーマンスを双方向で測定しました。実験の測定値と数学的な予測値との一致率が高いことから（図4、図7）、利用したデータスループットのモデルの妥当性が確認されました。CANおよびCAN FDでのデータ伝送で得られた測定データを比較すると、CAN FDのスループットが、システムのコンフィギュレーションに応じ、1.3倍から最大5.4倍の範囲で高いことがわかります（図6）。

CAN FDによるパケット連結

XCP on CAN FDには、帯域幅の向上以外にも機能改善の余地があります。CANとCAN FDは物理的な通信基盤が同じであるため、既存のECUソフトウェアによるデータ送信が、CAN FDへの移行後も8バイトに制限されてしまいがちです。この場合、XCPにとってのメリットはデータ伝送レートの上昇のみに留まり、CAN FDフレームで利用可能な64バイトのペイロードをフル活用することはできません。このデータ伝送レートは、小さいXCPパケットのペイロードを連結し、一つの大きいCAN FDフレームにまとめること

図1：CANapeを使用したXCP on CAN FDによる測定

Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06



測定とリプログラミングの高速化


で最適化できます (図8)。ベクターは現在、将来のXCP仕様に向けて、XCP on CAN FD上でパケット連結を可能にする提案策定に取り組んでいます。

フラッシュプログラミング

フラッシュメモリーのプログラミング/リプログラミングは、高速ネットワークプロトコルの利用で大きな改善が期待できる、もう1つのユースケースです。従来のCANバスシステムの場合、「削除」、「ダウンロード/プログラミング」、「検証」の3つのフラッシュのフェーズのうち、鍵となるのはダウンロード時間であり、FlexRay、Ethernet、CAN FDなどの高速なバスシステムを使えばこれを短縮できます。伝送プロトコルに関わらず、データの圧縮や

プログラミングのパイプライン処理といった、ダウンロードをさらに最適化するための方策を考慮することは当然の策といえます。LZSS (Lempel-Ziv-Storer-Szymanski) アルゴリズムによる圧縮を使用すれば伝送データは小さくなりますが、その効率はデータの構造に大きく左右されるうえ、ECU内でのデータ展開で生じるCPU負荷も考慮しなければなりません。一方、プログラミングにおけるパイプライン処理は一種の並行処理で、データセグメントのECUへの

書込中に次のセグメントの伝送が開始されます。そのためこの方法では、プログラミング時間がデータ伝送時間よりも短い場合に最大のパフォーマンス向上が期待できます。

FlexRayとEthernet

FlexRayの伝送レートは10Mbit/秒ですが、そのすべてがプログラミング/リプログラミングに利用できるわけではありません。タイムトリガー型のプロトコルで用いられる周期的な通信シーケンスでは、すべてのPDU (プロトコルデータユニット) があらかじめ固定された時間枠で定義されています。ダウンロードなどの診断サービス要求用に予約されている時間枠が多ければ、それによって有効な(制御)データのための帯域幅が減ります。実際のコンフィギュレーションで対応できるのは、診断サービスサイクルあたり、42バイトから255バイトのPDUが4個から8個です。ベクターの技術者の測定では、パイプライン処理を行った場合のダウンロード速度は40KB/秒から60KB/秒でした。

ISO 13400-2に準拠したDoIP (Diagnostics over IP) をEthernetで使用するのも、ECUの高速なリプログラミングに非常に適しています。100MビットEthernetと、純粋なフラッシュ書込速度が180KB/秒の一般的なマイクロコ

ントローラーを用いたテストの結果は、ほぼTransferDataサービスのバッファーサイズに比例しています。バッファーが16KBの場合、スループットはテストに使用したフラッシュメモリーの上限に近い、約150KB/秒に到達します。

CAN FD経由のリプログラミング

CAN FDに対応するマイクロコントローラーは現時点でどの半導体メーカーからも出ていないため、ベクターのネットワークの専門家は、CAN FDコントローラーをFPGAに実装したマイクロコントローラーを使用してCAN FDを測定しました。ボード上のソフトウェアスタックはベクターの標準のUDSブートローダーからなり、ISO 15765-2のトランスポート層とCANドライバーはCAN FDに対応するよう拡張されています。ダウンロードのテスト環境をセットアップする工程を省力化するため、CAN FDへのサポートがすでに提供されている、シミュレーション/テストツールのCANoeを使用しました。このソフトウェアは、外部DLLを使用してフラッシュプログラミングのプロシージャーとトランスポート層の機能を実現します。ベクターのフラッシュツールであるvFlashは、今後CAN FDに対応する予定です。使用したトランスポート層で達成可能なCAN

図2：CANフレームの構造図3：CAN FDフレームの構造

図4：ECU測定におけるCAN FDのデータスループットの測定値および計算値



Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06

測定とリプログラミングの高速化



FD上でのフラッシングの伝送レートは、CAN FDのデータフェーズの伝送レートが4Mbit /秒の場合、理論的には270KB/秒から370KB/秒になりますが、測定値はこれをはるかに下回ります (図9)。圧縮やパイプライン処理による最適化処理は、使用したテスト環境では逆効果だったのです。この原因は、今回の実験環境で、内部フラッシュメモリーのプログラミング時間がフラッシングプロセスの制限要因となり、ダウンロードフェーズに対する最適化の効果を薄めたことにあります。しかし、データスループットと最適化の効果に関してより普遍的な結論を得るには、さらに強力なCPUを用いてテストを重ねる必要があります。この測定で得られた重要な結果としては、CAN FDはCANよりもデータのスループットが大幅に高く (図9)、移行の手間がわずかで済む点が挙げられます。

まとめと展望

CAN FD、FlexRay、Ethernetの各バスシステムの客観的な比較は、全体としてマイクロコントローラーや制約が多岐にわたるため現状では困難ですが、明言できる傾向はいくつかあります。FlexRayでは、ダウンロードのスピードとリアルタイムのデータペイロードに対するパフォーマンスは両立できません。100MビットEthernetは伝送レートは最高ですが、それには複雑なソフトウェア設定が必要であり、ハードウェアのコストはCAN FDよりも高くなります。CAN FDは、高いデータレートとほどほどのコストでさらなる改善が期待できる、おそらく最もバランスの取れたソリューションです。さらに、CANとCAN FDは非常に似ているため、この新しいCAN規格に移行するのはそれほど難しくはありません。どちらのプロトコルも基盤とする物理層は同じであり、トランシーバー、配線、バストポロジーなどを流用できます。通信の原理も変わらないため、既存のノウハウがそのまま応用できます。影響を受けるキャリブレーションとリプログラミングのソフトウェア層に対しても、加えるべき修正はわずかです。

CAN FDによって、ECUの測定とリプログラミングの両方のスループットを大幅に向上できます。これによって、プログラミング/リプログラミ

ングにおけるボトルネックはフラッシュメモリー寄りにシフトしますが、使用するMCUの開発が進んでメモリーアクセス時間が短縮すれば、一層のパフォーマンス向上が約束されます。XCP仕様を拡張して、CAN FDによるパケット連結を含めるというベクターの取り組みは、この新しいプロトコルが秘めるパフォーマンス向上のポテンシャルを引き出すものでもあるのです。

本稿は、2014年9月CiA発行の『CAN Newsletter』に掲載されたベクター執筆による記事内容を和訳したものです。

リンク：CANのためのソリューションwww.vector-japan.co.jp/can-solutions


図5：XCP on CAN FDでのデータ測定におけるスループットの計算値

図7：XCP on CAN FDでのデータ測定におけるスループットの測定値

図6：XCP on CANおよびXCP on

CAN FDでのデータ測定におけるスループットの測定値の比較

図8：複数のXCPパケットを1つのCAN FDフレームに統合することによるデータ伝送の高速化


参考文献：CAN-FD specification V1.0, Robert Bosch GmbH

Armin Happel (Dipl.-Ing.)

1997年、Vector Informatik GmbHに入社。組込ソフトウェア開発の分野で、フラッシュブートローダー製品を担当。

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

2002年、Vector Informatik GmbHに入社。CANoe/CANalyzer用マルチバス開発分野のプロダクトマネージャー。

Erik Sparrer (Dipl.-Ing.)

2013年、Vector Informatik GmbHに入社。通信用ハードウェアとCANape用のデータ取得システムの統合を主軸としたキャリブレーション/測定分野のソフトウェア開発に従事。

執筆者ベクター：ツールチェーンによりCAN FDを全面的にサポート

　CAN FD用のECUソフトウェアは、ツールチェーンの全コンポーネント

がこの改良版のCANプロトコルに対応してこそ、効率的に開発できます。ベクターは、CAN FDが将来、車載ネットワークで戦略的な役割を果たすものと確信しています。ツールメーカーとしてすでに、この新しいシステムへの製品対応を優先的に進めており、シミュレーション/解析ツールのCANoeおよびCANalyzer（バージョン8.1以降）、データベースのCANdb、測定 /キャリブレーションツールのCANape（バージョン12.0）、フラッシュツールのvFlash（バージョン2.6以降）からなるCAN FDの包括的なツールチェーンを提供しています。関連するハードウェアとしては、USB接続によるシンプルなインターフェイスから、専用のCPUを搭載した高性能のインターフェイス、そしてベクターのモジュール式テスト用ハードウェア製品であるVTシステムに至るまで、幅広い製品を揃えています。CAN FDは今後、ベクターのAUTOSARベーシックソフトウェアであるMICROSARにも含まれる予定です。ベクターは、プロセスソリューションであるPREEvisionも含め、完成度の高い製品ラインナップをご提供しています。

図9：CANおよびCAN FDでのダウンロードおよびプログラミング時間の比較



オープンアーキテクチャー、設定変更可能なコンポーネント、統一された変換形式などが存在する主な目的は、開発者に、革新的で製品を差別化できる機能の開発や再利用を促すことにあります。近年、多くの標準規格が作られ、特にODXやAUTOSARといった診断開発のプロセスやツールに影響を与えています。同時に、ECUに求められる要件の体系的な把握、管理、追跡が定着してきており、開発プロセスや方法、ツールにも多大な影響を与えています。複数の標準規格がなくても開発は可能なのでしょうか。それを可能にする万能な標準規格はあるのでしょうか。また、それぞれの標準規格と方法はお互いに効果的かつ効率的に組み合わせることができるのでしょうか。

TechnicalArticle 04

Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06

診断要件から通信まで～カーエレクトロニクス開発のトレンドは標準化～



要件工学

システム開発は、ユーザーからの視点に基づいた要件からスタートします。要件（Requirements) の把握が反復プロセス（図1）のスタートであり、そこでシステム要件がより詳しく正確に作られていきます。もし要件を満たす解（Specifications）がまだ抽象的な場合、後の工程の個々のサブシステムの仕様決定のために曖昧さを残さないように具体化します。実際、要件はその詳細さや正確性によって異

なります。テキストベースの要件は、システムプロパティーをテキスト形式で、通常は不完全で意図的に曖昧に記述したり、単なるノート形式で書かれています。一方、仕様要件は正確で、要件のみを記すだけでなくソリューションをも含んでおり、曖昧さはほとんどありません。記述には通常、形式言語が使用され、テキストベースの要件にファイルで添付されます。参照要件には「前のシステムと同様」というような仕様への参照箇所が含まれます。技術的には、これらの参照要件は多くの場合、他のデータベースの仕様やデータ管理システムを実際に参照しています。理想的なのは、要件は最初からできるだけ

正確に定義し、必要な分だけ詳しくしておく方法です。不明瞭あるいは曖昧な要件は、開発プ

ロセスに多大な労力を要します。なぜなら、明確さはその後必要とされる追加調整の程度を左右することにつながり、多くの場合は仕様変更に行きつきます。最も避けたいケースは、システム実装さえも修正しなければならなくなることです。一方で要件が必要以上に詳しいと、迅速かつ最もコスト効果の高いソリューションへの道が阻害される恐れもあります。初期の段階である要件に対する仕様を他の複数の要件にも共通にしようとすると、流用性の低い仕様になりがちで、多くの場合、再利用の機会もなくなります。特に、開発の過程で要件が変更になる場合、初期のアプローチの名残と、変更後の要件を分けることが重要です。開発過程で、すべての要件における実装の

進捗状況を知ることで、全システムまたはサブシステムにおける実装の進捗状態の概要がわかりやすくなります（成熟レベルトラッキング）。もし要件主導型のプロセスによる利点を体

系的に利用したい場合は、前述したプロセスを、実際は独立している異なる開発領域のものを含むすべてのサブシステム、そしてもちろん、診断にも適用する必要があります。今日では、要件の管理にスプレッドシート指

向のツールやデータベースが使用されており、要件はまったく形式的に記述されないか、部分

的にのみ形式的に記述されています。これらのツールは、非常に曖昧なものも含めたすべての要件を把握し、追跡できるよう充分に柔軟であることが必要です。仕様に関しては、いろいろなツールがさまざ

まな記述方法を確立しており、例えば、一般的にはある決まったフォーマットで仕様を記述するモデリング、オーサリングツール等があります。ユーザー要件と異なり、主要目的は内容の正確な定義であり、柔軟性ではありません。また、この根本的な違いから、ユーザー要件とは異なるより専門性の高いツールが必要となります。その結果、従来型の要件管理ツールは、あるレベルまでしか詳細を知ることができません。このことは、診断にも当てはまります。いくつも存在するデータを受け渡すための

標準フォーマットは、特定分野に特化して設計されています。例えばODXは、診断テスターに対するデータに特化しています。こういった変換フォーマットは、通常、細部まで考慮され一貫した仕様を補償する形式的なデータモデルを使用します。一方で、これらのフォーマットは、曖昧な要件を説明するには制限があり過ぎるわけです。従来型の要件管理ツールは、テキストベースの診断要件を説明するのによく適しています。一方で、標準化されたデータ変換フォーマットであるODXは、診断テスターのた

図1：繰り返しの多い開発プロセス


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06

診断要件から通信まで



めのものとして標準化されたものであり、これらのテキストベースの要件を記述または変換するには、形式的で正確すぎるため、適していません。

ECUソフトウェア

今日、AUTOSAR (AUTomotive Open System Architecture) は、自動車業界で使用されているECUソフトウェアのリファレンスアーキテクチャーです。AUTOSARは、個々のコンポーネントや車両機能のディスクリプション、およびシステム全体のディスクリプションを標準化します。

AUTOSARの診断ソフトウェアは、DCM、DEM、FIMという3つのベーシックソフトウェアモジュールで構成されています。

DCM（Diagnos t ic Communicat ion Manager)は、UDSおよびOBDIIに従い、診断コミュニケーションを実行します。DEM（Diagnostic Event Manager）は、フォールト発生時のフォールトメモリーを記憶し、フォールトステータスと補足情報を管理します。FIM（Function Inhibition Manager) は、アクティブフォールトのケースで、所定の機能の実行を妨げ、2次的なエラーを回避します。

DCM、DEM、FIMは、ECU Configuration

Description (ECUC) で設定されます。設定内容は、要件がどのようにソフトウェアコンポーネントの設定と関係しているかをよく示しています。曖昧さと柔軟さは、要件を把握するには有

利ですが、ECUソフトウェアの設定においては避けられるべき特性です。ソフトウェアは、起こりうるすべての条件に対し、正確に一義的に説明されなければなりません。ソフトウェア設定に関係のある重要な診断

データの内容は、リクエスト /レスポンスとそのパラメーター（サービスID、サブファンクション、データパラメーター）付きの外部診断テスターから呼び出すことのできる診断サービスを含んでいます。データの長さとデータタイプは、すべてのデータパラメーターと関連性を持っていますので、定数パラメーターもまた、一定値を要求します。UDSでは、あるデータパケットへのアクセスを所定のセッションやセキュリティレベルで制限することができます。この情報は設定データに含まれるので、ソフトウェアは決められたルールに確実に則ることができます。ソフトウェア設定データの記述フォーマッ

トで次に重要なことは、診断ソフトウェアをアプリケーションにリンクさせることです。診断サービスで受け渡されたパラメーターは、ア

プリケーションソフトウェアの変数や関数にリンク付けすることで、ソフトウェアジェネレーターは、関連のある呼び出しを行うことができます。

AUTOSARでの診断は、UDSおよびOBDIIプロトコルに限定されるため、これらのプロトコルの診断サービスのレイアウトは暗に仮定され、ECUCデータに明示的に記述されません。

AUTOSARのECUCデータは、標準化されたXMLフォーマットで保存されており、コード生成処理を可能にします。

図2：診断開発のツールチェーン



診断テスターへのデータの提供

サードパーティ製の診断テスターには、車両ごとの診断データを読み込ませる必要があります。このデータには、対象となる車両およびECUに関連する診断コミュニケーションの情報が含まれていなければなりません。前述の設定データとの大きな違いは、適用される自動車の範囲です。特にサービス領域では、単一の診断テスターで、異なるさまざまな車種、モデル、および年代による違いに対応する必要があります。データ容量は、冗長さを避け、必要なデータを小さく収納できることが求められます。設定される診断データそのものは、テスター

にどう読み込ませるかとは関係ありません。実際の場面では、診断テスターが接続されている対象車両にどんなECUがあり、どんなソフトウェアバージョンが実装されているのか不明なことが多々あります。そのため、診断データには、動作時に自動的に対象に最適なデータを選択できるよう複数のバリエーションが必要とされます。診断テスターに車両ごとの診断データを設定するための既存のデータ形式には、ベクターのcdd形式やISO規格のODX形式があります。

ツールチェーンの例

診断開発では、図2に示されるツールチェーンによって下記のタスクが実行されます。

要件の定義付け、収集、および整理

IBM DOORSは、要件の把握および管理のためのツールとして自動車メーカーの間で広く使用されています。

仕様の作成と整理

要件の把握およびインポート /エクスポートをサポートするツールCANdelaStudioは、ECU個別の診断仕様を記述するためのオーサリングツールとして、要件定義をスタートとする開発プロセスに組み込めるものとなっています。診断オブジェクト (診断サービス、データオブジェクト、DTCなど) は、図にあるように要件をインポートすることで生成できます。個々のオブジェクトは元の要件とリンクしているので、ユーザーはインポートされた要件を自動で診断仕様に取り込み、アップデートされた要件があれば同期させることができ、必要に応じて仕様変更も可能です。要件または仕様の変更が繰り返される状況では、両者の関係が明確になって

いることが重要です。その後の工程で、結果の再比較などの二度手間を防ぐことになり、プロジェクトを進めるうえでの大きなアドバンテージになります。完成した診断仕様は、一連のプロセスの後

工程へのインプットとしての役目を果たします。CANdelaStudioは、元の診断仕様をcdd形式で保存しており、ODXファイルが必要であれば簡単な操作でエクスポート可能です。

ECUソフトウェアの生成と統合

DaVinci Configurator Proは、AUTOSARのベーシックソフトウェアとECUのランタイム環境 (RTE) を設定、生成するツールです。ユーザーは診断仕様 (ODXまたはcdd) をインポートし、そこから最初のECUC設定を生成します。その後、徐々に補完しながらECUの設定をより専門的で詳細にしていきます。新しいバージョンの診断仕様がある場合、簡単に再インポートすることができ、それまでに作成していた設定と自動的に統合することができます。ECU用の診断ソフトウェアは、その統合された設定に基づいて生成されます。


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06

診断要件から通信まで



ECU診断機能のテスト

ECUに実装された診断機能そのもののテストには、サプライヤーも自動車メーカーも、CANoe.DiVaを使用しています。CANoe.DiVaは、ODXまたはcdd形式のECU仕様記述ファイルに基づいたECU専用のテストケースをカスタマイズし、テストシナリオとして生成します。生成後は、CANoeでそのシナリオが自動実行されます。テスト結果は詳細に示され、ユーザーは個々のテストケースにコメントを入れたり、さまざまな条件でグループ化、ソート、フィルタリングすることができます。

実際のECU診断

さまざまな場面に応じて、CANoeやCANape、Indigoは、診断テスターとして使用できます。CANdelaStudioの仕様をテスターのパラメーター化およびECU設定の共通要項とすることにより、テスターとECUソフトウェアをそれぞれ確実に同期させることができます。

まとめ

近年、診断分野に登場してきたAUTOSARとODX標準規格は、互いに機能を補いながら目的達成のために効果を発揮し続けています。これらは互いに関連ある内容に対応していますが、それぞれがフォーカスしている分野は異なり、オーバーラップする部分はわずかしかありません (図3)。一方が標準化した内容を、もう一方が完全にカバーすることはできていませんが、AUTOSAR方式はODXと互換性があります。実際の開発場面では、何人かの担当者がい

て、診断要件定義やそれに伴う仕様変更はたびたび起こります。こういった場面で、異なる標準規格で記述されたデータの一貫性を保つことは、課題となっています。しかし、この課題は、しっかりと定義されたプロセスや焦点の絞られたデータ変換、そして、現在市場で入手可能なツールによってサポートすることで克服することができるでしょう。


リンク：ベクターのODXのためのソリューションwww.vector-japan.co.jp/vj_odx_jp.html

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

Vector Informatik GmbH (シュツットガルト)の診断プロダクトライン開発チームマネージャー。ASAMとISOのODXワーキンググループにも参加。

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

執筆者

Dr. Klaus Beiter

Christoph Rätz

図3：ディスクリプションモデルの内容の類似点


ISOBUS通信プロトコルにより、現在では異なるメーカーの農業機械も、事実上問題なく接続され使用できるようになりました。ただしその実現には、メーカーでの膨大な開発とテスト作業が伴います。農業機器メーカーのAGCO/Fendtは、ベクターのシミュレーション/テストツールのCANoe.ISO11783を使用して、既存のHIL (Hardware-in-the-Loop) テスト環境に高性能の自動テストを統合しました。系統的なテストによって今では製品の品質が向上し、同社は「精密農業」の時代においても、車両コンポーネントのインテリジェント化というトレンドに自信を持って対応できるようになりました。

TechnicalArticle 05

自動化によるテスト品質の向上～HILテストシステムの自動化が農業機械のISOBUSでの動作を保証～


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06

J1939に基づく標準規格のISO 11783には、農業用移動機械で使用するCANベースのオープンネットワーク通信が規程されています。ISO 11783はJ1939プロトコルを拡張した、物理層にCANを使用したマルチマスターネットワークです。ISOBUSのコンセプトには、ECUやネットワークが提供すべき最低限のソフトウェア/ハードウェア機能が規程されています。ISOBUSプロトコルにより、ISOBUSに対応した任意のトラクターに、フィールドチョッパーや肥料散布機などの作業機を適宜取り付けて操作できるようになるほか、その作業機の全機能がトラクターのコンソール上でいつでも使用できるようになります。この規格の各パートでは、ネットワークマネージメント、トラクターECU、ユニバーサルターミナル (旧：バーチャルターミナル)、タスクコントローラー、診断サービス、ファイルサーバーなどの仕様が決められています。

農業技術の標準化がもたらす利点

ISOBUSがユーザーとメーカーの双方にもたらす利点は、ユニバーサルターミナル (UT) を例に挙げればわかりやすく説明できます。作業機が接続されると、UTはその作業機のコントローラーから、グラフィック制御エレメント (オブジェクトプール) のライブラリーを読み取ります。これらのオブジェクトはユーザーが使用できる各種の機能を表すもので、それらにより作業機を容易に操作できます。

ISOBUS機能の目標達成に欠かせない広範なテスト

上の例のようにすべてが円滑に機能するようになるまでには、テストや開発の担当部門による膨大な数のテストと修正の繰り返しが必要です。一方、I S O BUS標準規格には解釈の余地が残る部分があり、そういった複雑なプロジェクトでは、成熟度が必要なレベルに達するまでにプロトタイプの段階で多くの時間がかかります。そのため徹底的かつ広範な適合試験はどうしても避けられません [1]。各メーカーがいわゆる「プラグフェスト」を定期的に開催し、デバイス同士の互換性をテストする理由もここにあります。

HILシステムを用いたトラクターネットワーク全体のテスト用セットアップ

AGCO Corporationはトラクターと農業機械を製造 /販売する米国の世界的大手企業です。1997年、同社はマルクトオーバードルフ (ドイツ) を拠点としてトラクターの開発生産と販売を行っていたXaver Fendt GmbH & Co.を買収しました。Xaver Fendt社のラインナップにはトラクター以外にもフィールドチョッパー、コンバイン収穫機、ベーラーなどが含まれており、それらの製品はバイエルン州、ザクセン＝アンハル州、イタリアの各事業拠点で扱われています。増加するテスト作業に対処するべく、AGCO/

Fendtは実際のトラクターのプロトタイプで広範なテストを行っています。また、開発およびコンサルティング会社のGigatronikからも長期間にわたり協力を得ています。AGCO/FendtのECUソフトウェアはほぼすべてが内製ですが、テスト関係の作業の一部はエレクトロニクスとITの専門業者に外注されており、同社での作業の中心となるのはユニバーサルターミナルおよびトラクターコントローラーのテストと、ISOBUSとの適合性の検証です。

AGCO/Fendtが使用しているテスト構成の主なコンポーネントは、トラクターネットワーク用のブレッドボード、HIL (Hardware-in-the-



自動化によるテスト品質の向上



Loop) システム、I/Oインターフェイスを多数装備したリアルタイムサーバー (RTターゲット)、そして、ISOBUSの要求に合わせてきめ細かな調整が加えられたベクターの開発/テスト/シミュレーションツール、CANoe.ISO11783をインストールしたPCです。CANoe.ISO11783は、設計フェーズからテストフェーズ、そして保守に至る全体で開発に必要なISOBUSの機能を提供し、ISOBUSの複雑な通信の構成を、多種多様な形で解析、視覚化、調整できます。先に述べた「標準規格の解釈の余地」も、その規格の事実上の解釈を知見としてツールに実装しているため、極めてシンプルに処理できます。トラクターの試験装置には、ECU、バスシステム、配線、ランプ、スイッチ、コントロールといったトラクターのあらゆる電子/電気的コンポーネントが組み込まれます。これらは省スペース型の産業用ラックのフレームにマウントされており、実験室での使用に適しています。試験装置は製品のトラクターと完全に一致します。欠けているのは、ディーゼルエンジン、トランスミッション、ボディー、そして取り付けパーツのみです (図1)。試験装置はマルチコアケーブルを介してRT

サーバーのI /Oルーティングブロックに接続されます (図2)。このサーバーは多様なECUと、欠けているエンジンとセンサー信号の環境をMATLAB/Simulink経由でリアルタイムのシ

ミュレーションを実行し、速度、回転速度、温度といった信号を供給します。ボタンを押す、ジョイスティックを動かすといったユーザー始動のイベントは、手動での実行が必要です。このHILシステム全体の規模と複雑さはI/Oレベルを見れば一目瞭然です。それは数百に及ぶ電圧および電流のインターフェイス、無数のデジタル入出力、そして駆動リレーの出力で構成され、さらに周波数出力、あらゆるタイプのCANバス、UDPインターフェイス、そして実験用装置のECUの供給電圧と、それに対する複数の電圧出力があります。

時間を要する「窮余の策」の手動テスト

テストに使用されるもう1つのツールが、シミュレーション/テスト用ソフトウェアのCANoe.ISO11783をインストールしたPCです。このシステムは主に残りのバスシミュレーションに使われ [2]、個々のネットワークノードからサブネットワーク全体までシミュレーションできます。CANoe.ISO11783では作業機全体のシミュレーションができ、シミュレーションしたその作業機を使用して、トラクターのISOBUS機能をテストします。UTなどのサブエリアも、CANoeを使用することで、そのすべての機能をPCの画面上でシミュレーションおよび表示できます。ISOBUSアプリケーションのテストには非常に多

くの時間と手間がかかります。これはトラクターの作業機に使用されているISOBUS規格の全パートで適合性を調べる必要があるためで、それにはトラクター内部の通信も含まれます。加えて、ISOBUS規格そのものの実装レベルもさまざまです。したがって、テストでは単に現在の実装レベルのみに留まらず、作業機の過去の実装レベルに対する、複数の後方互換性も保証しなければなりません。そして最後に、おびただしい数の個別のテスト (テストケース) を、多種多様なバリアントで実行しなければなりません。

FendtとGigatronikでは、先に述べたようなHILシステムがあるにもかかわらず、やはり一部の必須のテストについては従来の手作業での実行が必要でした。テストケースにもよりますが、社員がトラクターに乗り、トラクターや作業機の特定のオペレーション機能を1回数時間、数日にわたって繰り返し実行する、ということもしばしば行われました。そういったテストの間、すべてのユーザー操作、システムの反応、バストラフィックがテストシステムに記録されます。その後、そのログ記録を使用して、メッセージ、ターミナルの反応、時間値、サイクルタイムなどの精密な解析が行われました。

図1：トラクターの試験装置には実際のトラクターのモデルのすべての電子コンポーネントが含まれています。自動テストはCANoe.ISO11783とリアルタイムターゲットにより、リアルタイムの条件で実行できます


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06




テスト自動化は最優先課題

しかしながら、このようなテスト方法は、GigatronikにもFendtにも満足できるものではありませんでした。優秀な社員が単純で時間のかかるユーザー操作に忙殺されるうえ、そのパラメーターの多さを考えれば、膨大な時間を要するにもかかわらず、テストが「原始的」であることは否めません。このようなことからマネージャーたちは、状況にそぐわない手動のインタラクションに替えて系統的かつ徹底的なテスト自動化を導入するべく、その手法を模索し始めました。機械式の制御アームで人間の動作をシミュレーションできるロボットを用いたソリューションは、導入が極めて難しいだけでなく柔軟性も高くないため、早い段階で却下されました。それよりも適切で訴求力があったのがエレク

トロニクスを用いたアプローチです。特に、ベクターのCANoeという高性能テストツールがすでに存在したことがポイントでした。このソフトウェアに組み込まれている「テスト機能セット」により、テストの要求定義からテストの実行、そして評価レポートの作成に至るすべてのフェーズを網羅する、包括的なツールチェーンが実現します。CANoeはテストマスターとして動作させることも、あるいはテスト環境に挿入することもできます。運転の制御と他ツールとの通信には

COMや.NETなどのインターフェイスが利用できます。テスト用としてテストノードと呼ばれるノードを作成できますが、それらはシミュレーション上のネットワークノード同様、実バスのネットワークに参加できます。テスト技術者はそれらの動作と機能を、Cに似たスクリプト言語のCAPLか、XML規格を使用して、テストモジュールで定義します。

リアルタイムターゲットへの橋渡しを行うCANoe

テストの自動化よりも、まず、CANoeのテストとシミュレーションをHILシステムのリアルタイムターゲットにどのようにリンクさせるかという問題を解決することが先決でした。それは、この2システム間に高速の通信チャンネルが必須になるためです。RTターゲットにはFendtが作成したデータリンクプロトコルを使用するUDPインターフェイスがあり、それでRTターゲットとの情報の送受信が行われています。そのため、Gigatronikはその相手となるCANoe側の互換インターフェイスを開発しました。これは学生の卒業論文の一環として、同社のメンバーが開発したものです。これによってテストシステムはUDP経由でRTサーバーを制御したり、以前に実際のコンポーネント (コントロール内蔵アームレスト

など) との手動操作による相互作用で生成されていたのと同じ信号ベクトルを、オプションで送信したりできるようになります (図3)。原則として、手動で操作される実際のコンポーネントはいずれもこの要領で自動化可能です。この例ではインテリジェントなアームレストでしたが、ハンドルが自動化の対象になるケースもあり得ます。これらの準備作業を経て、Gigatronikと

AGCO/FendtではISOBUSとECUのテストを包括的に自動化し、それらをスピーディーに修正することが可能となりました。特に、今ではCANoe.ISO11783の機能がテスト実行の大幅な効率化に貢献しています。たとえば、CANoeが提供するUTで、あたかもトラクターに装備された実際のUTを使用しているかのようにISOBUSの作業機を制御できるようになります。以前は社員がトラクターの実際のアームレストで数時間にわたってユーザーが操作して制御機能を実行しなければならなかったのに対し、現在では、同じ制御機能を備えたシミュレーション上のアームレストが、同じ操作を自動的に実行します (図4)。各テストケースでのシミュレーション上のコンポーネントの挙動は、CAPLテストモジュールできめ細かく定義されます。テスト用のユーザーインターフェイスにより、仮想のエンジンを始動することもできます。また、シーケンスは前方/後方互換性が維持されるようプログラ

図2：もともとのHILシステムはリアルタイムターゲット、トラクター用実験装置、残りのバスシステムとの通信に用いるUDPインターフェイスで構成されています。ユーザー制御内蔵アームレストなどが実コンポーネントとして実装されているため、それを手動で操作する必要があります



ムできます。特に重要なのが、手動の操作とは対照的に、CANoe.ISO11783ではテストの実行に完全な再現性がある点です。しかも、エラーを任意のタイミングで発生させることができます。テストの実行中、テストシステムは関連するすべてのメッセージと信号を記録し、後から自動的にテストレポートを生成します。

自動化でテスト品質が飛躍的に向上

テストの自動化により、ECUテストの品質は一変します。テストを一晩中、あるいは数日間にわたって実行するのも簡単で、社員が付き添う必要もありません。当然、これによってはるかに多くのテストケースを、はるかに詳細に、はるかに多く、系統立てて実行することが可能になります。トラクターの始動時、停止時、複数の作業機での対象物の持ち上げ時などにバス負荷を複数回繰り返してチェックするといった、テストツールなしでは不可能なテストも含まれます。開発者は他のメッセージがこれらの状況でどのように反応するか、そしてタイミング値と周期時間がどのように動作するかを解析します。数千のテストを開始し、特定のメッセージの遅延時間などのパラメーターを変更しながらログを取り、ネットワークの起動時にどのような影響が出る可能性があるかを調べると

いった、統計的な評価も実行できます。そして、EDCUテストで大きな部分を占めるのが、テスト対象のシステムにエラーを発生させることです。ここでもCANoeの指示により、RTターゲットが、考えられるすべてのエラー状況を生成します。

AGCO/Fendtの主要なテスト部門の責任者、Bernhard Stöcklは以下のように語ります。「以前はISOBUS分野ではテストを自動化していませんでした。これまでは作業のすべてを直接プロトタイプ上で実行していて、しかもそれがいつでも利用可能とは限りませんでした。我々は実際にマシンに張り付いてスイッチを操作していました。それが今、テスト自動化によって計り知れないほどの負担軽減が叶いました。実際のプロトタイプを操作する時間ははるかに少なくて済み、非常に高価なテスト車両を何台も作る必要はもうありません。同時に大幅な作業時間の短縮が実現し、開発者はいっそうの自動化に勤しんでいます」。

展望

「テスト自動化」は、テスト作業の増加に対処し、品質の向上や時間およびコストの抑制を同時に実現するためのキーワードです。AGCO/FendtとGigatronikの例は、シミュレーション/テストシステムためのツールCANoeが提供するテスト自動化機能で何が可能になるのか、そしていかにして効率的なテストの実践を迅速かつ簡単に達成できるのかを示しています。このテスト用プラットフォームが持つ柔軟性により、大規模なHILシステムを統合する過程で直面する、通信とインターフェイスに関わるさらに大きな課題も克服できます。今後も製品の品質を保証していくためには、

新しいアプローチで統合テストに取り組むしかありません。ISOBUS対応の農業機械の多様化を考えれば、これは早急に取り組むべき課題と言えます。精密農法の分野にも、新たな要求がすぐに出てくることでしょう。農業機械との動作に対応したGPSアプリケーションの実装は、トラクターと作業機の両方でますます進むと予想されます。TIM（Tractor Implement Management：トラクター作業機管理）においては、作業機がトラクターの速度や回転数を指定するなどしてトラクターを制御します。これらの拡張機能のテストを自動化することではるか

図3：既存システム全体へのCANoeインターフェイスの統合：テストモジュールが既存のテスト環境を制御します。制御機能が内蔵されたアームレストは、テストシステムに仮想コンポーネントとして実装されており、それを手動操作、またはテストプログラムで自動操作することが可能です


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06




に効率的に実現できるのです。

本稿は2013年12月にドイツで発行されたElektronik automotiveに掲載された記事を和訳したものです。

参考文献：[1] Ostermüller, A., Fellmeth, P.:Forging New

Pathways in Testing ISOBUS Task Controllers ‒ Simulations replace inflexible and time-intensive

test methods.Elektronik automotive.Issue

11.2011. pp. 32–35.

[2] Albrecht, S., Decker, P.:Quick paths to a

comprehensive remaining bus simulation ‒ Create virtual networks without programming

expertise.Automobil Elektronik.Issue 03.2012.

pp. 58–60.

提供元：見出し画像：Fendt図1～4：Gigatronik

リンク：CANoe.ISO11783 　www.vector-japan.co.jp/vj_canoe_iso11783_

jp.html

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

Bernhard Stöckl (Graduate Engineer)Technical University of Munichで機械工学を専攻し、現在は駆動技術および電気 /電子のテストを担当する事業部門責任者としてAGCO/Fendtに勤務。同社にはHIL部門のテスト技術者として入社。

Thomas Bückle (Graduate Engineer)Polytechnical College of Ulで情報工学を専攻し、GIGATRONIK Technologiesでは農業技術および建設機器のビジネスマネージャー、および組込システム部門の部門責任者。DaimlerおよびEvoBusではエレクトロニクス開発の開発技術者およびプロジェクトリーダーを経験。

Hans-Werner Schaal (Graduate Engineer)Stuttgart大学で通信工学を、また米国オレゴン州立大学で電気工学 /コンピューター工学を学び、Vector Imformatik GmbHの事業開発マネージャーとして、オープンCANプロトコル (ISO11783およびJ1939) とIPおよびCar2x分野を担当。これまで多様な業界で、複数のネットワーク技術に対応したテストツールの分野の開発エンジニア、プロジェクトリーダー、プロジェクトマネージャーを経験。

Benjamin Fernandez (M.Sc., MBA)メキシコの ITESMにて機械および電気工学の学位、Technical University of Hamburg-Harburgにてメカトロニクスの学位、NIT HamburgにてMBAをそれぞれ取得。開発技術者としてGIGATRONIK Technologiesに勤務。

執筆者

図4：ユーザー制御機能が内蔵された実際のアームレストは使用せず、そのコンポーネントから発生する信号はすべて、手動操作とテストプログラムによる制御の切り替えが可能なGUIから生成されます


高度に成熟した市場と厳格化する法規制を満たすため、自動車システムは一層複雑化しています。これらのシステムは車両の効率性と安全性の両方を高めるポテンシャルを持つものの、ひとたび障害が発生した場合、システム間の複雑な相互作用の診断は容易なことではありません。

機能定義から整備工場まで：「V字モデル」を超えた先行技術設計データの提供

TechnicalArticle 06


一般的には、こうした複雑なシステムの問題が市場において発生した場合、その解決に最も適しているのはナレッジベースを利用したシステムの整備工場への配置と活用であるとされています。ただし、情報が蓄積していない新型車両の投入直後の時期は、ナレッジベース頼みの整備工場システムが最も苦手とする期間です。しかもそれは、テストや検査をすり抜けた複雑な問題を掘り下げて特定、解決するための知識が、最も必要になると考えられる期間でもあるのです。ベクターは、先行技術データを再利用することにより、このクリティカルな期間にフィールドのサポート技術者や整備士に詳しい情報を提供するための道を開きました。

先行技術データ

新しい車両プログラムの初期段階では、それが共通のプラットフォーム内の1バリアントに使われるのか、あるいは「単独プロジェクト」に使われるのかを問わず、アーキテクチャーを定義するための大量のデータが生成されます。アーキテクチャーの設計プロセスは、そのプラットフォームが提供すべき機能やフィーチャーを列挙するところから始まります。以後これを「フィーチャーリスト」と呼びます。通常、フィーチャーリストは車両モデルやバリアント別に細分化されており、各モデルの各バリアントを市場、企業、法規制のニーズに合わせてどのような形で提供するのかを限定、洗練、詳細化するための要求のリストが付属しています。モデル／バリアントの個々のフィーチャーリストは、1つの集合と考えることができます。とすれば、システムアーキテクトの仕事は、

フィーチャーリスト同士の一貫性を保ちつつ、各モデル／バリアントの集合全体の上位集合となる、包括的なアーキテクチャーを開発することといえます。この上位集合を「150%アーキテクチャー」、個々のモデル／バリアント集合を「100%アーキテクチャー」と考えても構いません (図1を参照)。

150%アーキテクチャーを単独で見れば、通常はその具現化は不可能です。それはつまり、

「左ハンドルかつ右ハンドルで、ディーゼルとガソリンとハイブリッドで駆動する、クーペであり、コンパチブルであり、ステーションワゴンである車両」を作ることになるからです。もちろん、あるフィーチャーリストに存在する

フィーチャーのすべての組み合わせが、1つの実装に使われるわけではありません。そのためアーキテクチャー開発においては、150%アーキテクチャーに存在する個々のアイテム間相互の依存関係、排他関係を検出することが大切な手順の1つとなります。150%アーキテクチャーのモデルを作成することで、こういった依存関係、排他関係の判定がしやすくなり、「フィーチャーモデル」の作成が可能になります。

フィーチャーリストを機能アーキテクチャーとして記述する

ベクターのPREEvisionは、フィーチャーリストやそれらの相互関係および実装を、抽象化された論理的な形式と、必要なハードウェア／ソフトウェアの観点からの両方の形でモデリングできる強力な環境です。この環境はさらに、フィーチャーモデルの矛盾や依存関係を自動的に検出する「リゾルバー」機能も提供します。

PREEvisionには、フィーチャーリストの文書化を支援する階層型の表形式エディターが装備さ

図1：150%アーキテクチャーと100%アーキテクチャーの関係

150% Architecture

100% Architecture 1

Common toArchitectures 1 + 3

Common to Architectures 1 + 2

100% Architecture 2

Common toArchitectures 2 + 3

100% Architecture 3

Common to all Architectures

Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06






れています。フィーチャーリストに含まれる個々のアイテムはモデル設計要素 (または単に「設計要素」) となり、PREEvision内でさまざまな形で利用できます。まず、PREEvisionにはリッチテキストエディターが付属しますが、それを用いて個々のフィーチャーの文書による詳細記述ができます。たとえば、文章によるユースケースや図表、写真などを使用したり、図2のようにコンセプトスケッチに取り込んだりできます。次に、図3に示すように、このフィーチャーリス

ト成果物をリッチテキストエディターで作成されたテキストによる「従来型」の要求にリンクさせ、よりきめ細かいレベルに洗練したり、詳細化したりできます。そしてPREEvisionでは、情報ソース（「セン

サー」）、データの処理または意思決定（「論理機能」）、システムからの出力（「アクチュエーター」）に対する抽象的な要求の観点から、フィーチャーの実現法を表現することができます。たとえば、車のスピードを運転者に示すフィーチャーは、高い水準では図4に示すようなモデルで表すことができます。ここから、たとえば図 5に示すように

「vehicleSpeedLogic」ブロックの内容に関する、さらに詳しいモデルを作成することが可能です。車両の各種サブシステムが実現するロジックは階層的に記述でき、他のフィーチャーが

実現する機能の低水準での詳細は、抽象化した高水準のブロックを使用してダイアグラム内で省略できます。そのため、PREEvisionではダイアグラムを使用して手軽に設計を作成できますが、その設計モデル内のダイアグラムでは、全容が把握しやすいよう敢えて一部が抽象化されており、「全体像」が部分的にしか示されていない場合があるので注意が必要です。図5のブロックの「Type」のラベルが示唆する

ように、PREEvisionはユーザー定義の部品ライブラリーの使用をサポートします。モデリング効率を向上するため、プロトタイプの設計要素を作成

し、それをライブラリーに即時に追加できます。ライブラリー定義のために、たとえば独立した「ブロックエディター」などを使う必要はありません。論理設計要素は、PREEvision内で設計要素

間のマッピングを作成することで、フィーチャーリスト内の特定のフィーチャーと関連付けることができます。このようなマッピングは双方向であるため、自動クエリーを使用して設計モデルを複数の方向に全探索できます。複雑な実装に含まれる論理ブロック設計

要素の数によっては、マッピングを多数作成する必要が生じます。そのためPREEvisionには、

図3：テキストによる要求を用いたフィーチャー定義の詳細化

図2：リッチテキストでのフィーチャーの定義


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06




フィーチャーとその実現とのマッピングを省力化する「Activity Chain」という概念があります。Activity Chainでは、フィーチャーに関連する論理ブロックを別の設計要素、すなわちActivity Chainにまとめたうえ、フィーチャーとその個々のActivity Chainの間に1つのマッピングを作成することにより、関連するすべてのロジックを暗黙的に含めることができます (Activity Chainは制御シーケンスの記述に似ています)。このように、150%のフィーチャーリストに含まれる全フィーチャーの実現に必要な論理ブロック網を完全にモデル化すれば、150%の「論理アーキテクチャー」が完成します。また、Activity Chainを使用することで、

フィーチャー間に存在する共通の領域と排他的な領域の判断が可能になり、データソースとシステム出力の再利用がしやすくなります。論理アーキテクチャーは、システムの実装に使われるソフトウェア／ハードウェア設計要素のプロトタイプであると考えることができます。技術革新に

よって、個々のプロジェクトのソフトウェアやハードウェアには数々の変更が加えられていくことでしょう。しかし、よく考えられた論理アーキテクチャーはおそらく、いくつものプロジェクトにわたって、長期間安定して使用されます。

実装のモデリング

抽象的なロジックをソフトウェア設計要素として実装するのに必要なソフトウェア機能同士の関係も、論理アーキテクチャーを構築するのと同様にモデリングできます。そして、それらの論理ブロックとソフトウェアブロックの間の関係を、マッピングを作成して表現すれば、150%の「ソフトウェアアーキテクチャー」を作成できます。次に作成するのは150%の「ハードウェアトポ

ロジー」でしょう。これは、この車両で使用される可能性のあるハードウェア間の相互接続を表すもので、その接続がハードワイヤー接続によるか、あるいは通信バスによるかは問いません

(個々の配線やハーネスピンにまで細分化した、よりきめ細かいモデリングも可能ですが本稿では説明しません)。このようなハードウェアには、センサー、電子制御ユニット (「ECU」)、ヒューズ／リレーボックス、アクチュエーターなどが含まれます。ここでも、ソフトウェアブロックとハードウェアブロックの設計要素同士をマッピングできます。図6に示すようにダイアグラムでは、ソフトウェアとハードウェアへのマッピングを「ふきだし」の形で表示できます。論理アーキテクチャーとソフトウェアアーキテ

クチャーでは、ある設計要素から別の設計要素に転送される「データ要素」に適用するデータ型を、AUTOSARが規定する手法に従って定義できます。そして、アーキテクチャーのモデリング（後述する、通信構造を含むモデリング）が完了すれば、それをAUTOSARシステム記述ファイルとしてエクスポートし、下流の製品開発作業に利用できます。この時点で、設計モデルは制約を追加するの

に十分な完成度に達します。制約ではたとえば、

図4：高水準の論理モデリング

図5：車両速度計算の詳しい論理モデリング



「キセノンヘッドランプはタングステンフィラメントヘッドランプと相互排他的である」という形で、設計要素間の排他関係および包含関係を任意に指定できます。使用したい個々のバリアントモデルの内容は、フィーチャーリスト単位で指定できます。こうすることで、PREEvisionの自動リゾルバーのメカニズムがモデル内のマッピングを全探索して、希望する100%アーキテクチャーの実際の内容を調べ、フィーチャーリストに不適合がないかを判別できます。

通信構造の定義

モデルがこれまで説明してきたレベルに到達し、フィーチャーリスト内の不適合がすべて解消されれば、あとは論理アーキテクチャーとソフトウェアアーキテクチャーにハードウェアトポロジーを組み合わせたものが「機能アーキテクチャー」になります。ここで、論理アーキテクチャーやソフトウェアアーキテクチャーはデータフローを定義し、ハードウェアトポロジーはそのデータフローがどのようなルートを取りうるのかを定義します。

100%アーキテクチャーのデータフローを正しくルーティングするプロセスは、手動で行えば非常に煩雑になりかねませんが、PREEvisionには通信シグナルをルーティングするメカニズ

ムが装備されているため、定義されたデータフローをハードウェアトポロジーに照らして自動的に解析し、最適なルートを決定することができます。これには通信バス (またはサブバス) システムで、バスを相互接続するゲートウェイをどこに置くのが最適かを決定することも含まれます。ここで特筆すべきなのは、この自動ルーティングのアルゴリズムが、機能アーキテクチャー内の信号のうち、特定のハードウェア設計要素の外に渡す必要のない通信シグナルを「最適化したうえで除去」してくれる点です。たとえば、あるデータ要素の出力する機能（ソース）と、それを利用する唯一の機能（コンシューマー）が同一のECUにマッピングされているのであれば、通信シグナルの作成は不要です。通信シグナルのルーティング作業の後、アー

キテクチャー内の通信シグナル経路を視覚化できます。図7に示すように、その通信シグナルを選択するだけで、対応するデータ要素のソース (黄色) およびコンシューマー（明るい茶）のマッピングの場所と、それらを結ぶパス、そしてゲートウェイ（オレンジ）が強調表示されます。機能アーキテクチャーでデータフローのルー

ティングが確定すると、今度はPREEvisionの統合ネットワーク設計環境を使用して、アーキテクチャー内で信号が通過しなければならないバスのタイプに応じた、プロトコルデータユニッ

ト（「PDU」）への信号の割り当てと、フレームおよびフレームスケジュールへのPDUの割り当てを行い、そのアーキテクチャーの「通信構造」を実現できます。通信構造が完成したところで、AUTOSARベースのエクスポート機能のほかに、LDF、DBC、FIBEXの各ファイル形式に依存する従来の下流工程に合わせて、それらのファイルをエクスポートする機能も使用できます。

サービスに関連する情報の追加

機能アーキテクチャーと通信構造は、製品開発プロセスにおける数多くの下流工程の基礎となるものです。ここで注目したいのは、これまで述べてきたPREEvisionモデルで定義されている関係が、ある車両の開発が終了して量産に入り、最終的に整備工場に入った時に役立つという事実です。たとえば、PREEvisionに組み込まれている自動クエリーのメカニズムを使ってモデルを全探索すれば、フィーチャーリストの特定の設計要素の実現を表すActivity Chain内の論理ブロックや、それに入力を与える論理ブロックを、すべて探し出すことができます。このようにして作成されたクエリーを、ナレッジベースの存在しない、複雑な新システムの障害に対処する際にフィールドサポートの技術者がまずチェックする、「最初の問い合わせ先」のデータ

図6：ソフトウェアのマッピングを表示したハードウェアトポロジーのモデル


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06




ソースとして使用できるのです。さらに、論理アーキテクチャーやソフトウェア

アーキテクチャーに対して、それらの通常の (機能上の) 通信要求に関わる定義を追加するのと同じように、機能アーキテクチャー全体に、診断要求の定義を追加することができます。

診断アーキテクチャーへのステップ

このためにはまず、「誤動作」というタイプの設計要素を作成し、高水準の診断要求に合わせて、機能アーキテクチャーの各部分にマッピングします。これらの診断要求としては、社内の一般的

要求、または過去トラブルの何らかの詳しい解析の結果に基づいた要求が想定されています。たとえば、次に示す「一般的」誤動作タイプを、ある企業の一般的なセンサーとアクチュエーターに関する要求文書に従って作成したとし、診断もそれらに応じて行うものとします。

図7：車両速度の通信シグナルのルーティングを表すハードウェアトポロジー (凡例については本文を参照)



> センサーには次の2種類の誤動作がある　　• 電気的な誤動作（断線など）　　• 信号／パフォーマンスの誤動作（上下　限値範囲外など）

> アクチュエーターには次の1種類の誤動作がある

　　• 電気的な誤動作（断線など）

次に、図8に示すように、そのような誤動作の設計要素を機能アーキテクチャー内の設計要素とリンクし、誤動作マッピングを定義します。

機能アーキテクチャーモデルで論理アーキテクチャー、ソフトウェアアーキテクチャー、ハードウェアトポロジーの間のマッピングをたどれば、これら2種類の誤動作を検出するにはどのプロセッサーで診断ルーチンを実行すればよいかを判別できます。そしてそれに従って、対応する診断トラブルコード (「DTC」) 要求をこのアーキテクチャー内で作成できます。PREEvisionは診断に関するマスター／スレーブ関係の概念をサポートするため、1つのECUやプロセッサーに、1つ以上の他のECU、(スマート) センサー、(スマート) アクチュエーターなどの診断情報を集約させることができます。一例として、診断の内容がモデル構造の中でどのように見えるのかを図9に示します (図ではDTCに加え、診断データ識別子、

診断測定、診断制御の要件を表示しています)。このような構造を作成するところまで来れば、

ハードウェアトポロジーを介して機能アーキテクチャーと双方向にリンクされた、診断アーキテクチャーの作成に踏み出したといってよいでしょう。このモデリングの主な目的は、ハードウェアトポロジーでモデル化されているマスター／スレーブのインタラクションを考慮し、さらにはモデルで定義された要求にも従いながら、ECUレベルの診断仕様の作成を円滑化することにあります。そのためPREEvisionには、特定のECUに割り当てられた診断要求のエクスポートを可能にするインターフェイスが用意されており、ベクターのCANdelaStudioでさらに詳しい処理を行って、下流工程で利用できるようになっています。上で説明した誤動作の設計要素は、図10に

示すように、論理アーキテクチャーを診断アーキテクチャーと双方向にリンクするのにも使用できます。これに加えて、誤動作の設計要素は機能安全

コンセプトの解析と開発にも使用できます。そのような形を取ることで、機能安全コンセプト、機能アーキテクチャー、診断アーキテクチャーの設計が一緒にリンクされたと考えることもできます。

図8：誤動作を論理的センサーにマッピング

図9：診断設計要素のモデル構造


Tech

nica

l Article

01Te

chn

ical A

rticle 02

Tech

nica

l Article

03Te

chn

ical A

rticle 04

Tech

nica

l Article

05Te

chn

ical A

rticle 06




整備工場での先行技術情報の使用

診断アーキテクチャー内で作成された個々のDTC要求が、量産車用にリリースされるソフトウェア内で実現できるようであれば、今度は前に説明したように、PREEvisionの設計モデル内のリンクとマッピングを使用し、自動クエリーを実行したり、関連する設計要素を簡単な操作により手作業で追っていったりして、フィーチャーからそのActivity Chainに含まれている機能への入力を検索できます。また論理ブロックからも、そのシステムに関連付けられたDTCのうち、機能やフィーチャーの障害につながる可能性のあるものを検索できます。整備工場で作業するディーラーの整備士が、複雑で不慣れなシステムの障害を診断しようとする場合、これは必須の情報になるかもしれません。当然、車両システムと機能が極めて密接に

接続されているという性格上、車載電子システムのある1つの障害が多数のフィーチャーや機能の障害を引き起こすこともあります。ただし、PREEvision設計モデルのリンクとマッピングは双方向であるため、逆のユースケースも考えることができます。つまり、車両でDTCが見つかった場合は設計モデルに対してクエリーを実行して、そのDTCに関連する障害が発生する可能性のあるすべてのフィーチャーを検索できるのです。

これも、整備工場では非常に有益な情報です。

まとめ

非常に複雑かつ密接に相互接続されたシステムが自動車に導入されることは、厳格化が進む法規制上の安全要求に車両を対応させると同時に、顧客に「驚きと喜び」をもたらす機能とフィーチャーを提供する大きなチャンスを与えてくれます。しかし、万一障害が発生すれば、そのようなシステムとシステム間相互作用の複雑さは、サービスの現場で診断を下すことを難しくさせる可能性を示唆しています。その反面、まさにこの複雑さが、ベクターの

PREEvisionをはじめとするシステム設計ツールの開発を促してもいるのです。そして、そのようなツールで開発される設計モデルは、多忙を極める整備工場に、車両のオリジナルの設計データに基づいた強力かつ新しい情報源を提供することができるのです。

PREEvisionに診断モデリング設計要素が導入されたことで、設計モデルから取り出せる情報の潜在的な有用性が高まり、今ではフィーチャーや機能を提供するロジックへの入力を検索できるだけでなく、フィーチャーや機能に障害を及ぼすおそれのあるDTCも、単一の情報源から判別できるようになっています。

図10：誤動作を介した論理アーキテクチャーと診断アーキテクチャーの間のマッピング


リンク：PREEvision

www.vector-japan.co.jp/preevision

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

2013年よりVector GB Ltd（イギリス）に勤務。プロセスツールおよび診断分野にてビジネスディベロップメントを担当。

執筆者

Iain Cunningham(BEng(hons), MSc)


「つながる」クルマのアプリ開発イベントに CANapeが貢献

トヨタがシリコンバレーで開催した「つながる」クルマのアプリ開発イベント

　トヨタ自動車株式会社（以下、トヨタ）は、新しいクルマづくりや楽しみ方のヒントを得ることを目的に「つながる」クルマのアプリ開発イベント「Onramp Challenge」を2014年12月6日、7日の2日間、米国カリフォルニア州サンマテオにて開催しました。同イベントには、シリコンバレーの起業家、ベンチャー企業、IT企業のプログラマーで構成される20チーム以上が参加しました。参加チームは24時間の制限時間内で「安全運転」、「運転の楽しさ」、「エコ運転」というテーマのもと、サーキットでの走行データを使用してどのチームが優れたスマホアプリやウェブアプリの開発ができるかを競い合いました。

ベクター・リポート

～シリコンバレーのクリエーターに机上で最適なアプリ開発環境を提供～

サーキット上を走行する車両の各種情報を高周期かつ高精度で測定するCANape　　同イベントを開催するにあたりトヨタでは、参加者が机上でのアプリ開発に使用する様々な走行シーンの車両データ、GPSデータ、走行中の映像といった情報を測定する必要がありました。データ測定とアプリ開発イベントの告知を目的として2014年7月28日にアメリカ合衆国のカリフォルニア州モントレーにあるサーキット「ラグナ・セカ」にて小型スポーツカー「 FR-S」（日本名：86）を使用した走行会を実施しました。この走行会で、車両データ、GPSデータ、走行中の映像の測定に使用されたのが、ベクターの測定 /キャリブレーションツール「CANape」です。サーキット上を走行する車両の各種情報

を同期させて測定するには、高周期でかつ高精度に測定ができるツールが求められましたが、CANapeはその要件を十分に満たしていると評価され採用にいたりました。　CANapeは、CAN/LINなど車載ネットワーク情報や、ECU内部値、GPS、映像、音声など複数のデータを同期して測定できます。さらに、測定データはCANape上で1つの画面にグラフィカルに表示できるためユーザーは統合的に情報を把握することができます。走行会では、車速やエンジン回転数などの車両データはベクターのCANインターフェイス「 VN1610」を、GPSデータは、u-blox社製のGPSレシーバーを介してCANapeで測定しました。加えて、USBカメラの映像もCANapeで測定しました（図1）。　

Vector Report


Vect

or R

epor

t

　同イベントの本番で使用するために、走行会で測定された情報からCANapeを使用してアプリクリエーターに有用な走行シーンの情報が抽出されました。CANapeで測定された車両データ、GPSデータ、走行中の映像の時間情報（※1）は、測定データ用のバイナリーファイル形式でASAMの標準規格であるMDF（Measurement Data Format）ファイルとして保存されます。CANapeでは、MDFファイル上の必要なシグナルのみを選択したり、時間範囲を指定して新規MDFファイルとして保存することができます。トヨタは、CANapeのこれらの機能を使用して走行会で測定したデータが保存されているMDFファイルから、アプリクリエーターにとって有用な情報と時間帯を抽出して、本番で使用するアプリ開発用の車両情報を作成しました。（※1）映像情報はAVIファイルで保存されます

サーキットでの走行データにリアルタイムでアクセスできる開発環境

　同イベントで参加者が使用した開発環境は図2のようになります。CANapeから車両や

GPSのデータを日本精機社が開発したCAN-Gateway ECUに送信し、CAN-Gateway ECUからBluetoothを介して、スマートフォンに車両やGPSのデータが送信されました。そして、参加者はCAN-Gateway ECUから送信されたデータをもとにスマートフォン用のアプリ開発にチャレンジしました。これらの開発環境により、参加者はサーキットでの走行データにリアルタイムにアクセスでき、あたかも車上で測定しているかのような環境でアプリ開発を行うことができました。　24時間の制限時間後、斬新でユニークなアプリが次々と発表されました。その後、厳正なる審査の結果、カメラを備えたラジコンヘリが走行車両を自動追従・撮影し、空中から車両走行映像を楽しめるアプリを開発したチーム「Eye in the Sky」が優勝しました（図4）。今回の導入事例は、最先端の IT知能が集まるシリコンバレーでのオープンイノベーションにおいても、CANapeが十分に貢献できることを示しています。

図2：Onramp Challengeで提供された開発環境の概略図

図3：アプリを開発する参加者

図4：優勝チーム「 Eye in the Sky」

図1：走行会でのCANapeの使用イメージ

画像の提供元

表紙、図3.4 ：トヨタ自動車株式会社

図1、2 ：ベクター・ジャパン株式会社


日本精機製

CAN-gateway

Bluetooth

Smart phone

車両データ、GPSデータ出力

CANape

車両データGPSデータ

GPSデータ

車両データ

U-blox社製 GPSレシーバ

VN1610

CANapeUSBカメラ


インタビュー

現在の自動車に求められる機能の高度化や複雑化を背景に、ECUの制御パラメータを最適化するキャリブレーションプロセスも年々複雑化しています。こうした課題に対してベクターが提供するソリューションツールが「vCDM」です。「vCDM」はキャリブレーションデータ管理ツールで、ECUのパラメータデータを一元的に管理することで、データの重複更新や競合、誤設定などを防止するとともに、変更記録やバリアント（リビジョン）管理などを効率化することができます。今回、ベクター・ジャパンで「vCDM」ツールを担当している蛭子朝三にECUキャリブレーション業務を取り巻く課題やその解決手法について話を聞きました。

ベクター・ジャパン株式会社適合ツール部（PMC）

蛭子朝三（えびすともみ）

◆複雑化するECUキャリブレーション

－ECUのキャリブレーションとはどのような工程なのですか？

蛭子：エンジンやトランスミッションなどの制御を行うECUの開発において、ソフトウェアのアルゴリズムに相当する部分はECUプログラムに格納されています。しかし特性マップ、特性値といったパラメータの値を決定するには、与えられたさまざまな条件に最適化させるために、テストベンチや実車によるテスト走行を何度も繰り返す必要があります。たとえば、仕向地ごとに異なる排ガス規制への対応や、搭載される車種に応じた変更が必要になる場合もあります。このような、パラメータ値を調整する作業のことを「キャリブレーション」または「適合」と呼んでいます。

ECUキャリブレーションプロセスを効率化する「vCDM」～ECUキャリブレーションの品質向上と期間短縮を実現～

Vector Report



Vect

or R

epor

t

－キャリブレーションデータの一元管理は、なぜ重要なのでしょうか？

蛭子：少人数でキャリブレーション業務を行っていた時代であれば、Microsoft Excelなどの表計算ソフトやWindows標準の共有フォルダを使った管理方法でも問題はそれほど大きくなかったかもしれません。しかしECUの制御内容が複雑化し、複数のエンジニアがチームとしてキャリブレーションを行うようになってきた結果、従来の管理手法の限界が指摘されるようになりました。たとえば、あるExcelファイルの異なる項目に対して、担当のＡさんとＢさんがそれぞれ別々に更新したとしましょう。この場合、保存操作のタイミングによってどちらかが先に上書きされてしまい、機能のデグレードが起こってしまうことがあり得ます。また、エンジン制御ECUの場合では数万を超えるパラメータが設定されることも珍しくないため、そもそもExcelでの管理は難しいという問題もあります。　アクセスが同時にできない、チームで共有しづ

らい、人為的ミスが生じやすい、管理方法が統一できずにバラバラになってしまうなど、さまざまな課題を解決するためにキャリブレーションデータを一元的に管理する仕組みが必要となり、実際にそうした管理ツールに関する問い合わせも増えてきています。

◆「 vCDM」でキャリブレーションプロセスを標準化

－では、キャリブレーションデータ管理に関する課題のソリューションはどのようなものですか？

蛭子：キャリブレーションデータ管理ツールとしてベクターが提供している製品が「 vCDM」です。自動車のECU開発を熟知した弊社の知識と経験を基に、欧米の主要自動車メーカーやサプライヤーと共同で開発したソリューションで、キャリブレーションプロセス全体をサポートしているのが特徴です（図1）。

－最近の自動車は電気化／電子化が進んでおり、１台のクルマに搭載されるECU数も増加しています。そのような状況下で、キャリブレーション業務はどのような課題に直面しているのでしょうか？

蛭子：ECUの制御対象といえば、従来はエンジンやトランスミッションなどのパワートレインが中心でしたが、最近ではブレーキやサスペンションといったシャシー関連の制御も行いますし、ハイブリッドカーや電気自動車などではモーターやバッテリーの制御も必要です。そのため、車載ECUは年々複雑化や高度化が進んでおり、それぞれのECUで扱うパラメータの数も膨大になっています。しかも、顧客のさまざまな要求に応えるために開発期間の短縮化が進んでおり、膨大なテスト量を短い納期で達成するために、現場の開発作業はより厳しい状況になってきていると思われます。　また、自動車メーカーやサプライヤーは事業がグローバル化していますから、ECUの開発拠点、完成車を製造する量産拠点、さらには実際に販売される国や地域がそれぞれ異なるケースは決して珍しくありません。そうしたグローバルな体制のなかでキャリブレーション業務を円滑に進めていく必要があります。　このような状況で顕在化してきた課題のひとつがキャリブレーションデータ（パラメータセット）の管理です。キャリブレーション作業に関わる人数が少なければ人手による管理も可能かもしれませんが、キャリブレーションチームの人数や、対象とするパラメータの数が増えるにつれて、データ管理の一元化と自動化が強く求められるようになってきました。図1：「vCDM」を用いたキャリブレーションプロセス。設計チーム（図内左）から提

供されたECUソフトウェア類を登録したのち、バリアント管理、変更の自動記録、レポートによるレビューなどのキャリブレーションプロセスのサイクルを効率的に進められる


for Standardisation of Automation and Measuring Systems）」が定めた「 ASAM CDF」や「 ASAM MCD-2 MC(A2L)」などの形式が多く使われていますので、こうした規格の進化に素早く対応することが必要となります。　ベクターは、以前からECUの測定・適合の分野でもツールを展開しており、ASAMの設立メンバーの一員としても活動しているので、ASAMの規格をいち早く製品に取り込むことが可能なだけでなく、ベクターからの提案が仕様になるケースもあります。こうした、ECU開発やキャリブレーションに関する豊富な知識と実績を持っていることが、ベクター製品の強みであると考えています。　「 vCDM」をご使用いただく場合、新しいテクノロジーやOS環境への対応はすべてベクターが行いますので、お客様にとっては内製ツールのメンテナンス開発が不要になり、本来のキャリブレーション業務に専念していただけるというメリットが大いにあると思います。実際に、これまで管理ツールを内製されていたお客様が「 vCDM」を導入される事例も増えています。

シー制御やADAS開発、またECUソフトウェアの設計部門のお客様からの要望を頂くことも増えています。

◆機能や品質のデグレードを防ぎ、　効率を向上

－キャリブレーションデータ管理ツール分野におけるベクターの強みや、「 vCDM」の導入で得られるメリットを教えてください。

蛭子：キャリブレーションデータの管理ツールを自社で開発し、利用していらっしゃる自動車メーカーやサプライヤーも、もちろんあります。しかし、昨年マイクロソフトがWindows XPのサポートを終了した際に多くの企業が新しいWindowsのバージョンへの対応を余儀なくされたように、内製ツールでは規格がアップデートされた際に即座に自力で対応しなくてはなりません。またECUのキャリブレーションに必要なパラメータファイルやECU記述ファイルには、標準化団体である「 ASAM（Association

　「 vCDM」は、これまで担当者やプロジェクトごとにバラバラだったキャリブレーションプロセスの標準化と“見える化”を推進するツールで、欧州を中心に多くの自動車メーカーやサプライヤーに導入されており、キャリブレーション業務の効率化に貢献しています。

－「 vCDM」の主な機能を教えてください。

蛭子：「vCDM」にはキャリブレーションプロセスを構成するすべてのフェーズをサポートする機能が搭載されています。いくつか機能を挙げますと、モデルチェンジや仕向先の展開に対応したバージョンやバリアント管理（図3）、担当箇所以外の変更を防ぐアクセス権限設定、パラメータの競合検出と解決、直感的でわかりやすいパラメータの編集やパラメータセットの比較機能などです。　さまざまな地域や部署でキャリブレーションに関わるお客様からの要望を基に新機能として搭載される例も少なくありません。また最近ではパワートレインの実験部門だけでなく、シャ

図2：「vCDM」のユーザーインターフェイス。プロジェクトやデータセットの内容、バリアントの依存関係、変更履歴などを参照できる

図3：ECUパラメータとECUソフトウェアは仕向先やモデル展開に応じてセットで管理できるほか、依存関係の設定や変更も可能

ECUキャリブレーションプロセスを効率化する「vCDM」～ECUキャリブレーションの品質向上と期間短縮を実現～

インタビュー

Vector Report



Vect

or R

epor

t

図4：リポジトリーサーバーによるデータ整合の仕組みによって、キャリブレーション拠点の分散化にも対応

－「 vCDM」を導入したユーザーの具体的な成功事例はありますか？

蛭子：多くの自動車メーカーやサプライヤーが「 vCDM」を導入してキャリブレーション業務の効率化に成功されています。　あるお客様のケースでは、排ガス規制レベルの強化によってECUパラメータ数が年々増加していることや、搭載されるECUの増加や機能の高度化が進んでいること、キャリブレーションチームの人員が増加していることなどを課題として捉え、複雑化するキャリブレーションプロセスの効率化を目指して「vCDM」を導入されました。　その結果、キャリブレーションデータのデータベースの一元化やフォーマットの統一化、変更履歴などのエビデンスへのリンク付け、データマージ作業の簡素化と重複回避、人手で作成していた管理シートの廃止、情報の共有化による品質向上など、顕著な効果が得られたとのご評価を頂いています。

◆グローバルな協調開発を支援

－電気化／電子化が進む現在および将来のクルマ開発において、「 vCDM」はどのような役割を果たしていくのでしょうか。

蛭子：ECUの制御対象範囲が広がるにつれて、キャリブレーション業務に携わる人員や部門も増加の一途を辿っています。また、エンジンとトランスミッションなど複数の部門や、自動車メーカーとサプライヤーといった複数の企業間での協同作業、また海外を含む複数拠点での分散開発が当たり前になりつつあるなかで、チーム間での協調をいかにスムーズに図っていけるかが効率化への重要なポイントとなっていくでしょう。　「 vCDM」はそうした複数チームにまたがる協調作業を支援するための機能も搭載されていますので、将来にわたってキャリブレーションのデータ管理作業の効率化を図っていくことができます（図4）。そうした特徴は業界からも高く評価されており、先ほども申し上げたように欧

州では多くの自動車メーカーやサプライヤーが「 vCDM」を導入して成果を挙げています。日本国内でも導入や問い合わせが年々増えていまして、今後はメニュー表示や入力情報などの日本語化を順次進めながら、日本のお客様にとっても、より使いやすい環境を目指していきたいと思っております。　新しいツールの導入は操作方法や業務フローに慣れるまでに時間がかかることもあり、敷居が高いと感じられるかもしれません。しかし、煩雑なパラメータ管理作業から解放されるだけでなく、ファイルの上書き等で発生する機能の品質低下の防止、さらには開発期間の短縮にもつながることを考えれば、導入にかかるコスト以上に得られるメリットも大きいと思います。今後、キャリブレーション業務におけるチーム作業の効率化や連携をサポートするプラットフォームがますます必要となってくると思われますので、「vCDM」はECUキャリブレーション業務に必須のツールになっていくと考えています。

（聞き手・写真 /関行宏＝ライター・フォトグラファー）

画像の提供元

図1～4：ベクター・ジャパン

リンク

ベクターの「vCDM」http://www.vector-japan.co.jp/vCDM

ベクターのキャリブレーションソリューションhttp://jp.vector.com/vj_calibration_jp.html


ECUテストのプログラミングをもっと効率的に～ CAPLの基礎と使用上のヒント＆コツ～

パート1： CAPLの基礎CAPLはベクターが開発したプログラミング言語で、広く使われているベクターのソフトウェアツール「CANoe」と「CANalyzer」で使用します。本稿では、CAPLの基本的知識をはじめ、すべてのユーザーの理解度に応じたヒントやコツを、3部構成で解説していきます。このパート1ではCAPLの基礎について解説します。主にCAPLを初めて学ぶ方を対象にしていますが、十分な知識があるユーザーの方もCAPLを構成する際に生かせるヒントを見つけていただけると思います。パート2ではCAPLの高度な機能について考察し、最後のパート3ではパフォーマンスや必要なメモリについてのトピックを取り上げ、さらに、データベースと連想配列を使用する際のヒントやコツを紹介します。

Vector Academy


ECUテストのプログラミングをもっと効率的に～CAPLの基礎と使用上のヒント＆コツ～ Vector Academy

> CAPLプログラムは「イベント駆動型」です。つまり、CAPLプログラムは個々の関数の集まりであって、その関数の1つ1つが、メッセージの受信、シグナルの変化、タイマーの期限切れ、さらには「環境」の変化といった、解析対象のシステム内のイベントに反応します。たとえば、「EngineState」というメッセージに反応するには、「On message EngineState」を使用します (図1)

> CAPLプログラムは、解析対象のシステムのコンセプトに応じた固有のデータベースを使用します。このデータベース内でメッセージやシグナルの名前を定義し、その名前をプログラムコード内で直接使用できます。図1のメッセージの「EngineState」や、このメッセージ内のシグナルの「EngineSpeed」がこの名前にあたります

CAPLは初めてDOS版CANalyzerに導入されて以来、20年以上にわたり、単純な刺激入力から複雑なバスノードのシミュレーションまで幅広いタスクの効率的な実装に役立ってきました。（以下、本稿では「CANoe」をCANoeとCANalyzerの2製品の総称として使用します。）CAPLの使用目的は、「特定のタスクを可能な限りシンプルに記述、実行すること」であり、受信メッセージへの対応、シグナル値のチェックと設定、メッセージ送信などのタスクによく使用します。プログラムはこれらの用途に特化したもので、かつ、付加的なオーバーヘッドは一切必要ありません。

CANoeユーザーが通常行うプログラミング作業の多くは、図1の例のように短くて単純なものかもしれません。しかし、それほど単純には済まないタスクも数多く存在します。だからこそ、CAPLは長年にわたって拡張が加えられ、「可能な限りシンプルに」の原則に従って、複雑なタスクも解決できるプログラミング言語に進化してきています。「CAPL」は、「Communication Access

Programming Language」の略です。当初はCANだけでしたが、次第に拡張され、LIN、FlexRay、MOST、J1587、ARINC、CANopenなどのあらゆる車両バスシステムに対応するようになりました。他の多くのプログラミング言語と同様、

CAPLの構文規則はC言語に基づいています。CやC#言語、あるいは最近の多様なスクリプト言語の知識があれば、短期間でCAPLを使いこなせるようになります。ただし、CAPLプログラムにはCプログラムと一線を画す、独自の特徴がいくつかあります。

> CAPLプログラムには「ポインタ型」は使用しません。そのため、Cプログラミングでしばしば発生しがちな潜在的なプログラミングエラーやプログラムクラッシュの原因を根本から排除することができます。しかし、エラーを招きやすいとはいえ、ポインタの概念が非常に優れていることは確かです。そのためCAPLにはポインタに代わる機能がいくつか用意されています。動的メモリの代用となる連想配列もその1つです

CAPLとC言語に共通する重要な性質として忘れてはならないのが、CAPLは常にコンパイルされるという点です。つまり、CAPLは効率的に実行できる、柔軟性の高いマシンコードに変換されます。

CAPLとは？

CAPLはVector Informatik（ベクター本社）によって開発された、Cライクな手続き型プログラミング言語です。プログラムブロックの実行はイベントによって制御されます。CAPLプログラムは専用のブラウザーで開発およびコンパイルされます。これにより、システム変数をはじめ、データベースに含まれているあらゆるオブジェクト (メッセージ、シグナル、環境変数) へのアクセスが可能になります。さらに、CAPLは事前定義された関数を数多く用意しており、開発/テスト/シミュレーションツール「CANoe」や「CANalyzer」に活用できます。


例：単純なCAPLプログラム

次に、単純なCAPLプログラム (図1) を紹介します。これはバスモニタリングツールの基本的なタスクの1つを行うプログラムで、バス上のトラフィックを監視し、バス上で発生する2つのイベントを、ユーザーが観察 /モニタリングできるように処理します。これはサンプルの「 Easy.cfg」からのCANoeプログラム「Display.can」の短縮版サンプルです。図1はプログラムを示しています。それでは、まず全体的な機能の概略を、次に個々のセクションの詳細を説明していきます。

タスクの説明> ここでのタスクはCANバスを観察することです。このバスのノード、メッセージ、伝送シグナルといった要素は、データベースに記述されています

> 「EngineState」メッセージを受信すると、それに含まれる「EngineSpeed」シグナルを取得し、パネルに表示させます

> 「LightState」メッセージを受信すると、それに含まれる「HeadLight」と「Flashlight」のシグナルを取得し、グラフィック表示用パネルに表示させます

プログラムの詳しい説明

図1にある行番号はCAPLプログラムの一部ではなく、個々の行やセクションを参照しやすいよう挿入されたものです。また、図1では見た目をコンパクトにまとめるため、開きブラケットは改行せずに配置しています。

CAPLプログラムではグローバル変数とグローバル定数の定義が可能です。これは「 variables」セクション (1行目から5行目) で行われます。このプログラムでは、ここに記載されている定数と変数がグローバルに定義されています。これらはプログラム内の任意の場所で使用できますが、同じCANoeアプリケーション内の別のプログラムでは使用できません。他のセクションではイベントに対する反応 (7行目から17行目) と補助（ユーザー定義）関数 (19行目から28行目) が定義されています。

7行目から9行目はメッセージイベントプロシージャーの最小限の形を示しています。この関数はこのメッセージがバス上で伝送されるたびに呼び出されます。CANの場合、これが呼び出される正確な時点はCANコントローラーでのTXまたはRXの割り込みの時点、すなわちメッセージが正しく伝送された直後になります。特定の関数を呼び出すトリガーとなるメッセージは、「 this」構文で参照されます。

8行目では、受信されたばかりのメッセージ (this) から「 EngineSpeed」シグナルの値が読み出され、変換 (/1000.0) を経てシステム変数に割り当てられています。

11行目から17行目は「 LightState」メッセージのためのメッセージイベントプロシージャーを示していて、方向指示器に関する情報を伝送しています。この処理は「 EngineState」メッセージの処理に似ており、12行目では伝送直後のメッセージ (this) で「方向」フラグ (.dir) をチェックするなど、独自の特徴を備えています。このプログラムで考慮する必要があるのは受信したメッセージ (RX値 ) のみです。なぜなら、ノードから送信されたメッセージが、イベントプロシージャー (TX値 ) をもトリガーするためです。この場合、エラーメッセージが15行目に出力されます。シグナルをインターフェイス (各種の状態が

それぞれのビットマップで表示されるパネル) 上で表示させる処理はやや複雑であるため、その実装は独立した関数に任されています。13行目では、パラメーターとして求められる2つのメッセージシグナルを用いて、「 SetLightDsp」が呼び出されています。最後に、19行目から28行目では独立した関

数を定義しており、伝送されるシグナル値に応じて、Lightsの名前空間にあるシステム変数「 LightDisplay」にそれぞれの値を書き込んでいます。このデモ用コンフィギュレーションでは、この変数によってディスプレイパネルに適切なビットマップが選択されます。

図1：単純なCAPLプログラムの例



パート2： CAPLをより深く知り、効率的に使う

パート1では、プログラミング言語であるCAPLの基本的な概念を取り上げました。パート2では、イベントプロシージャーの時間的な挙動について説明します。また、すべてのユーザーがCAPLを「汎用プログラミング」と「条件付きコンパイル」の分野で効果的に活用できるよう、いくつかのヒントも紹介します。

実行モデル

CAPLとCあるいはC++との主な違いは、プログラム要素が呼び出されるタイミングとその方法にあります。たとえばCでは、処理シーケンスはすべて、一斉開始関数であるmain() から始まります。一方CAPLでは、すべてのプロシージャーが横並びで1つのプログラムに含まれ、それぞれが以下のような外部イベントに反応します。

> システムによるトリガー：これらのイベントには、on preStart、on start、 on preStop、on stopMeasurementや時間制御およびキーボードイベントのon timerとon keyなどの、実行する測定の初期化や後処理に役立つものが含まれています

> バス通信によるトリガー：通信やエラー処理に関連したバスイベントに反応するイベントプロシージャーにはさまざまなタイプのものがあり、それらはバスの種類に大きく依存します。これらのイベントには、CANのon messageやon busOffや、FlexRayのon frFrameやon frStartCycleなどがあります

> Value Objectへのアクセスによるトリガー：これらのオブジェクトには、CANoe/CANalyzerでグローバルに使用できるシステム変数と環境変数のほか、バス通信をデータ解釈したシグナル値が含まれます。この解釈は専用のデータベースによって行われます。このコンセプトについては、このシリーズのパート3で取り上げます

イベントプロシージャーはアトミック：

CANoeのシミュレーションモデルはイベント指向です。イベントプロシージャーでは、CANoeがすべてのアクションをモデルの観点から同時に、具体的にはトリガーイベントが発生したタイミングで実行します。PCで生じる実際の計算時間は無視されます。

シミュレーション時間とタイムスタンプ：

ただし、PCによって生成された実際のイベント、たとえばoutput() によるバス出力などには、リアルタイムクロックのタイムスタンプが与えられます。これらのイベントのシーケンスと時間ポイントは、バスのプロトコル、ドライバー、ハードウェアの特性から影響を受けます。仮想バスではそのような影響を及ぼすパラメーターの一部を排除できます。その場合バスイベントは同時に開始され、たとえばCANであれば、output() から複数のメッセージを出力する際、確実にアービトレーションを実施して送信できます。

システム変数の更新：ユーザーはCAPLを使ってプログラムの外に

ある環境変数やシステム変数を変更することも可能です。CAPLはイベント処理と同じタイミングで値を変更しますが、その変更はそのイベント処理が完了するまでは変数に反映されません。イベント処理中に読み取りアクセスを行うと、その変数に新しい値が設定されているように見えても、常に古い値が返されます。これにより、値の変化が、ある特定の時点での1回しか発生しえないというメリットがあります。


実行モデルは状況に依存：

CANoeやCANalyzerでは、さまざまな方法でCAPLが使用されます。そのため、その実行モデルも必ずしも一様ではありません。CANoeシミュレーションの仮想ノードはバス上に並行して存在し、それらは互いに完全に独立しています。トリガーイベントは常にすべてのプログラムにて有効です。対照的に、測定設定のノードやCANalyzerのノードは順次処理、すなわち各ノードが次のノードへと出力を渡していく形で処理されます。処理を進めるためには、渡されたイベントを明確に次のノードに渡さなければなりません。on * およびon [*] のプロシージャーは、その目的で用意されています。

その他、テストプロシージャーが外部イベントを待機できるタイプのテスト用プログラムがあります。CAPLの場合、そのようなイベントにはシミュレーション時間を用いて処理を再開します。対照的に、通常のイベントプロシージャーでは、ループ処理など待機状態が発生するとシミュレーションシステム全体が停止します。これはCAPLを使用する場合によくあるエラー原因の1つです。そのため、外部DLLのビジーウェイトやウェイトコマンドは使用しないようにしてください。

効率的なCAPLプログラミングのヒント

C言語のプリプロセッサーは強力なツールである一方、使用を誤ってエラーを招く場合もあります。したがってCAPLでは、C言語でよく知られているプリプロセッサーディレクティブの一部のみをC言語と同等のセマンティクスで提供します。

#include：

include文、変数、プロシージャーなど、CAPLプログラムのセクションがすべて揃った、任意のファイルを読み込みます。Cとは対照的に、includeファイルのテキストは、単にCAPLファイルに挿入されるのではなく、セクションに挿入さ

れます。includeファイルのすべてのセクションが、親となるCAPLファイルにあたかも最初から含まれていたかのように、全体に適用されます。CAPLではセクションの順序にはまったく意味はありません。そのため、コンパイラーは重複しているすべてのシンボルをエラーとして報告します。また、includeファイルと親ファイルのコードとデータは相互に使用することが可能です。先ほど重複シンボルは避けると述べました

が、これには1つ例外があります。on start、on preStart、on preStop、on stopMeasurement は、includeファイルと親ファイルの両方に存在することもあるということです。これらの関数では、最初にincludeファイルのコード、次に親ファイルのコード、というように順次実行されます。つまり、includeファイルは「データ型の宣言」、「変数の定義」、「 (インライン) 関数ライブラリーの提供」という3つのタスクの実行に使われることになります。

#pragmaライブラリー：

CAPLプログラムは、適切なCAPL DLLインターフェイスさえ実装すれば、他言語で作成されたWindows DLLを使用することができます。これらのDLLは直接、#pragma library(„capldll.dll“) というディレクティブでリンクできます。

マクロ：

CAPLには多数のマクロが事前に定義されており、ユーザーはそれらをコードや条件付きコンパイルで使用できます。コードで使用されるマクロは、コード内の任意の場所で制限なく使用できます。C言語とは対照的に、マクロは文字列定数、変数の識別子、関数名の中で自由に使用できます。マクロは常に%文字で始まり、%文字で終わります。また、基本的に汎用的なプログラムを記述するのに使用されます。利用可能なコードマクロには、使用中のノー

ド名、現在のチャンネルインデックス、現在のネットワーク名、バスのタイプが含まれます。このコードは %FILE_NAME% を含むファイル、または、%BASE_FILE_NAME% を含む現在

コンパイルされているプログラムファイルにアクセスできます。includeファイルの場合、後者コードは親ファイルを示します。以下に簡単な例を2つ示します。

w r i t e ( „T h e n o d e n a m e i s %NODE_NAME%“);

putValue(envChannel%CHANNEL%Var1, %CHANNEL%);

別途、コードセクションを条件付きでコンパイルするための #if、#else、#elif、#endif などのマクロも事前に定義されています。これらを使えばプログラム内で、プログラムタイプの仮想ノード、測定ノード、テストプログラムをはじめ、使用されているCANoeのバージョンも識別できます。下記は #pragma message を使用する例です。

#if (TOOL_MAJOR_VERSION == 7 && TOOL_MINOR_VERSION == 5 && TOOL_SERVICE_PACK < 2) || CANALYZER

#pragma message(„This program needs at least CANoe 7.5 SP 3“)

#endif

#pragma message：

#pragma message ディレクティブを使用すれば、ユーザーはコンパイル処理中に独自のメッセージ、つまり、現在コンパイルされているCAPLプログラムのバージョン番号などのメッセージを出力することができます。このメッセージはコンパイラーからのその他のメッセージ、警告、エラー、通常のメッセージなどと一緒に表示されます。



パート3：上級ユーザーのためのCAPL

最後となるパート3では、上級ユーザー向けのヒントとコツを紹介します。特にパート2で触れた、連想配列、パフォーマンス、必要なメモリ、データベースアクセスに関するオプションなどのトピックについて詳しくみていきます。

on message CAN1.*{ lastTime [this.id] = this.time; }

ユーザーの操作性を高めるため、CAPLでは連想配列変数用にドット表記を用いた以下のメソッドが用意されています。

> ContainsKey：特定のキーがすでに含まれているかを照会する

> Size ：含まれているキーの数を返す

> Remove：その連想配列から1つのキーを削除する

> Clear ：連想配列を完全に空にする

なお、RemoveおよびClearによってメモリが解放されます。

最後に、連想配列に対する特殊な形式for命令を紹介します。この形式では、lastTimeに実際に含まれているすべてのキーで反復処理を行います。

for ( long akey: lastTime) {[…]} …

連想配列

Cなどの言語と違い、CAPLは参照データ型のポインタオブジェクトを一切サポートしないため、動的メモリ管理はありません。そのおかげでCAPLは非常に堅牢で、メモリが限られていてデバッグも難しいような実行環境には最適です。特に、CANoeの「 CAPL-on-Board」機能にはこの特徴が有利に働きます。　「 CAPL-on-Board」はリアルタイム挙動を向上させるため、特定のハードウェアバスインターフェイス上で直接プログラムを実行する機能ですが、その際も、Windowsの実行環境でメモリが不足することはほとんどありません。ゆえにCAPLは、プログラム開始時にどれだけのデータ量が保存されるか分からなくても、データ保存のために連想配列を使うことができます。連想配列は、他のプログラミング言語のマッ

プや動的配列に相当するコンテナです。内部ではCAPLがこれらの配列用に効率的なハッシュテーブルを用いているため、事前にどのメッセージあるいはどのくらいの数の測定値が生じるのかが不明であっても、これらの特別な配列によってバスメッセージや測定値の保存が可能になります。

CAPLでは連想配列を単純配列として宣言しますが、通常のようにサイズを指定するのではなく、キーの型を指定します。以下に連想配列の例を2つ示します。

long lastTime [long]; char[30] translate[ char[] ]

変数 lastTimeは、longキーを long値にマッピングする配列です。一方、translateは、stringキー（長さ制限なし）を30文字までの文字列値にマッピングします。以下の例では、lastTimeを使用して、CANバス上で発生する個々のメッセージ IDの時間値を保存しています。


データベースへのアクセス

パート1で、CAPLにおけるバス固有のデータベースの基本的な使用について解説しましたが、これらデータベースを使うことで、メッセージとシグナルを名前で処理することができます。たいてい、シグナルは効率性を考慮してメッセージのデータペイロードの中に隙間なく定義されているため、プログラミングの観点から扱いが難しいという面があります。一般的にシグナルは、メッセージのデータペイロード内の恣意的なビット長やビット位置で表され、シグナルはIntel形式あるいはMotorola形式のいずれかで定義されます。シグナル名を用いたシンボルベースのアクセ

スにより、CAPLユーザーはこうした詳細を一切考慮せずに済みます。シグナル値の読出しや設定の際は、CAPLコンパイラーがビットのマスク、入れ替え、シフトなどのシグナルの正確なビットパターンを自動的に読み取ります。他のオブジェクトを定義してデータベースに

登録しておけば、CAPLプログラミングの作業が効率化し、ユーザーの使い勝手もよくなります。たとえば、シンボリックな値のテーブルをシグナル値と関連付けることにより、シグナル値のステータスを簡単なテキスト名を使って表現することが可能です（例：シグナル値’0’ = off, シグナル値’1’ = on）。さらに、データベースの作成者は、他の属性オブジェクトを自由に定義し、それらをプログラムのコード内で使用することができます。

CAPLでは、シンボル名に基づいてデータベースオブジェクトを直接使用することが可能です。ただし、プログラムを実装する時には、まだ使用したいオブジェクトが確定されていないこともあります。そのためCAPLでは、ネットワークノードから伝送されるメッセージ名や識別子などのシンボル名とプロパティーへ動的にアクセスできるようになっています。以下に簡単な例を示します。

message * m; int i, mx; mx=elcount(aNet::aNode.Tx); for (i = 0; i < mx; ++i) { m.id=aNet::aNode.TX[i]; write(DBLookup(m).Name); }

このシンボリックアクセスの手法と先に紹介した連想配列により、ユーザーは汎用的なプログラムを実装することができます。

パフォーマンス

大部分のCAPLプログラムは、複雑なリアルタイム条件を満たさなければなりません。CAPLでシミュレーションされるノードの実行モデルには、CAPLプログラムを任意の速度で実行できるというモデルコンセプトが採用されています（パート2を参照）。このような理想的な状態に近づくために、CAPLプログラムはそれを実行する特定のマイクロプロセッサーのマシン言語にコンパイルされます。さらに、複雑になりがちなシグナルへのアクセスには、最適化されたコードシーケンスが使用されます。以下に、ユーザーがパフォーマンス向上のため

に利用できるヒントをいくつか紹介します。

writeEx()

write関数は、CANoeやCANalyzerの書込みWindowに特定のテキストを表示するために使われますが、通常のバスイベント処理と比べて表示処理の優先度が低いため、表示が遅れる場合があります。よって、大量のデータを遅延なく表示するためのwriteEx関数も用意されています。これはトレースWindowやログファイルに直接書き込む場合などに使用します。writeExで生成されるテキスト出力はバスイベントとまったく同様に扱われるため、高い優先度で処理され、実バスイベントのタイムスタンプと同期しています。

イベントプロシージャー

CAPLプログラムはイベントに反応するプロシージャーの組み合わせで構成されています。これらのイベントの中には、発生頻度が非常に高いものがあります。そのため、解析の対象となるイベントを適切に定義すれば、プログラムのパフォーマンスは大幅に向上します。たとえば、特定のシグナルが含まれるFlexRayのスロットのみが対象なのであれば、すべてのFlexRayスロットに反応する “on frSlot *” と定義するよりも、特定のスロットとシグナルに反応する “on frSlot signalname” と定義した方がより効率的です。

シグナルの変化

イベントプロシージャーには、シグナル用とシステム変数用それぞれに対して、updateとchangeの2つのバージョンがあります。on signal_update と on sysvar_updateは、特定のデータオブジェクトへの書込みアクセスが発生するたび、たとえオブジェクトの値がまったく変化しない場合であっても、必ず呼び出されます。一方、on signal_change (on signalと略記 ) と on sysvar_change (on sysvarと略記 ) は、シグナルの変化のみに反応するため、シグナルの変化を扱う場合に高いパフォーマンス性を発揮します。つまりこのイベントプロシージャーは、値変更のトリガーとして最適です。



1994年よりCANoeおよびCANalyzerの開発者としてVector Informatikに勤務。

2012年よりCANoeおよびCANalyzerのCAPL機能関連のプロダクトマネージャーとしてVector Informatikに勤務。

執筆者

Marc Lobmeyer (Dipl.-Inf.)

Roman Marktl(Dipl.-Ing)

知っておくと便利な機能

本稿の締めくくりに、知っておくと便利な機能についていくつか紹介します。

> structを使用して、C言語に似たアプローチでストラクチャーを定義できます。コピー操作を行うと、struct内でIntel形式とMotorola形式の変換も行われます。この方法を使えば、柔軟なデータ変換が可能です。

> CAPL関数を呼び出す際、ユーザーはオプションで値パラメーターのほかに参照パラメーターを渡すことができます。参照パラメーターを使用すれば、1つの関数から複数の結果を返すことが可能になります。参照パラメーターはCAPL DLL内でも使用できます。

> CAPLプログラムは、万一使用を誤ってもクラッシュしません。汎用的なポインタを持たないという言語構造により、このような堅牢性が確保されています。また、配列の上限、スタックの上限、必要な処理時間などが実行時に自動チェックされることによって、より高い安定性が確保されています。

> 独立したコマンドライン版のコンパイラーが用意されています。このコマンドライン版は、スクリプト言語でシーケンスを自動化する際に非常に便利です。

最後に

問題指向のプログラミング言語の例として、CAPLを紹介してきました。CAPLのCライクな構文は、なじみやすく習得しやすい言語です。CAPL特有のシンボリックなデータベースやコンセプトによって、フィールドバスノードのシミュレーション、エミュレーション、テストを効率的に実行し、アプリケーションの開発をサポートします。ベクターは、以前のバージョンとの互換性を保ちつつ、新しいアプリケーション分野が開拓できるよう、今後もCAPLを慎重かつ継続的に拡張していきます。

本稿は、2 014年2～4月C i A発行の『C A N Newsletter』に掲載されたベクター執筆による記事内容を和訳したものです。

必要なメモリ

Cのようなたいていのブロック指向言語とは異なり、CAPLのローカル定義変数はすべて、デフォルトで静的変数となります。つまり、これらはすべてプログラムの開始時に作成され、その変数の保存に使われるメモリはプログラムが終了するまで解放されません。そのため、仮に多数のイベントプロシージャーが共有できるにもかかわらず、個別で同じタイプの大容量の変数を定義した場合、そのCAPLに大量のメモリが必要になることもあります。以下に例を示します。

testcase test789() { 　char outBuffer[1024]; 　[..]

こうしたテストプロシージャーを何千も備えたCAPLプログラムもありますが、実行されるのは一度に1つのみです。イベントプロシージャーごとに同じタイプの大容量のローカル変数を定義するよりも、その変数をグローバル変数としてVariablesセクションで1回だけ定義した方が、使用するメモリを大幅に削減することができます。メッセージ IDごとにイベントデータを保存す

るなど、非常にサイズの大きい配列を作ることは避けた方がいいでしょう。CANの拡張 IDは29ビットであるため、その配列が保存する値の数は5億を超えることもあり、そのような配列を定義するのはメモリの無駄遣いです。このような場合は、先に述べた連想配列を使うようにしてください。連想配列の場合、実際に使用される各キーにはメモリが必要となりますが、使用されないキーにはメモリは不要です。



ビデオデータおよびセンサーデータの取得と、ビデオ画像および俯瞰表示での可視化

News from Vector

New

s from V

ector


YouTube「ベクター・ジャパンチャンネル」公開中！ベクター・ジャパンの公式YouTubeチャンネル「ベクター・ジャパンチャンネル」では、製品の機能紹介をはじめ、お客様から要望の高いECUテストソリューションやVTシステム概要などの動画を配信中です。下記ベクターWebサイト「動画ポータル」ページからアクセスできます。登録不要/無料でご覧いただけますので、ぜひご視聴ください。

「PREEvision UserDay 2015 Tokyo」開催のお知らせベクターは、6月9日（火）に東京にて「PREEvision UserDay 2015 Tokyo」と題したセミナー形式のイベントを開催します。本イベントでは、ベクターの「PREEvision」のユーザーであるボッシュエンジニアリング株式会社様より、PREEvisionの使用事例をご講演いただきます。また、株式会社ローランド・ベルガー様、DNV GLビジネス・アシュアランス・ジャパン株式会社様より、業界注目のトピックであるE/Eアーキテクチャー開発環境に関する基調講演をしていただきます。PREEvisionユーザーの実際の使用事例を知ることができる、またとない機会となっております。本イベントは事前お申込み制となっており、当日のお申込み状況はベクターのWebサイトでご確認いただけます。すでにお申込みいただいた皆様におかれましては、誠にありがとうございます。当日、皆様のご来場をお待ちしております。

催事名：『PREEvision UserDay Tokyo 2015』◎会期： 2015年6月9日（火）　　　　[一般向けセッション]　　　　　　 10：00～13：25　　　　[保守契約ユーザー向けセッション]　14：15～18：00◎会場：ステーションコンファレンス東京（東京都千代田区丸の内1-7-12　サピアタワー6F　JR東京駅日本橋口直結）　

■PREEvision UserDay 2015 Tokyo 開催　　http://www.vector-japan.co.jp/pv-ud

「ベクター・コングレス 2015」開催のお知らせベクターでは、ものづくりの現場で活躍するお客様に業界の有用な情報をご提供するため、ベクター製品をご活用いただいているお客様による開発事例紹介を中心とした、セミナー形式のイベント「ベクター・コングレス」を開催しています。今年は10月2日（金）に名古屋で、そして10月22日（木）に東京で「ベクター・コングレス 2015」を開催いたしますので、ぜひご来場ください。イベント詳細については、ベクターのWebサイトでお知らせする予定です。多くの皆様のお越しを心よりお待ちしています。

「第7回国際カーエレクトロニクス技術展」に出展しましたベクターは2015年1月14日（水）～1月16日（金）に東京ビッグサイトにて開催された「第7回国際カーエレクトロニクス技術展」に出展いたしました。ベクターブースでは業界の最新動向を踏まえ、CAN FDや車載Ethernet、AUTOSARについてのプレゼンを実施し、多くの方に聴講していただきました。さらにブース内では先端技術（次世代車載ネットワーク、安全運転支援、AUTOSAR等）や開発効率化を図る（ECUテスト、車載ネットワーク、パワートレイン等）ベクターの各種ツール・ソリューションをご紹介させていただきました。今回も多数のお客様にお越しいただき、おかげさまで盛況のうちに終えることができました。ご来場いただきました皆様に、この場を借りて厚く御礼申し上げます。

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

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

■ベクター・ジャパンHP 　　お役立ち情報　　ベクター動画ポータル　ベクター動画ポータル　　https://jp.vector.com/vj_videos_jp.html

「vSignalyzerバージョン13.0」リリースあらゆるタイプの測定データを効率的に評価および解析できるツールである「vSignalyzerバージョン13.0」をリリースいたしました。

〈主な特長〉　● 高性能な印刷機能およびレポート機能　● CAN、CAN FD、LIN、FlexRayのバスロギングデータの解析　● シグナルフィルターとスペクトログラムビュー　● シンプル操作によるズーム機能　● 使いやすい統計関数　● グラフィックWindowにデータ解析結果をより分かりやすく表示　● ASCII形式の測定データの柔軟なインポート　● 同期情報を持たないマルチメディアファイルの統合　● 各種地図素材を用いたGPSデータの表示（オプション不要）　● CANapeで作成したプロジェクトも利用可能　● 圧縮されたシグナルを含むMDF4.1形式のサポート　● 複雑な設定のWindowを再利用するためのテンプレート機能　　詳しくは、ベクターのWebサイトをご覧ください。

「vADASdeveloper」リリースマルチセンサーADAS（先進運転支援システム）アプリケーション向けの実装、デバッグ、テスト用ツール「vADASdeveloper」をリリースいたしました。

〈主な特長〉　● アルゴリズム開発から複数センサーのデータ記録、スティミュレーション、処理結果の迅速な可視化まで、あらゆる局面に対応す　るソリューションを提供　● アルゴリズム開発にフォーカスしたソフトウェア開発プラットフォームを提供　● Visual Studioとの統合によるアルゴリズムのリアルタイムデバッグをサポート　● マルチセンサーアプリケーションのラピッドプロトタイピング開発を支援　● 既存の開発環境への組み込みが容易　● カメラおよびベクターのバスインターフェイスにアクセスするため　の豊富なセンサーコンポーネントを提供　● C/C++およびMATLAB/Simulinkソフトウェアコンポーネントを　簡単に組み込み可能　● MDFやADTF DATなどの一般的なデータ形式をサポート　●「BASELABS Create」コンポーネントライブラリのシームレスな　統合により、複雑なアルゴリズムを簡単に使用可能詳しくは、ベクターのWebサイトをご覧ください。

vSignalyzerを使用して測定データをすばやく簡単に評価


ビデオデータおよびセンサーデータの取得と、ビデオ画像および俯瞰表示での可視化

News from Vector

New

s from V

ector


YouTube「ベクター・ジャパンチャンネル」公開中！ベクター・ジャパンの公式YouTubeチャンネル「ベクター・ジャパンチャンネル」では、製品の機能紹介をはじめ、お客様から要望の高いECUテストソリューションやVTシステム概要などの動画を配信中です。下記ベクターWebサイト「動画ポータル」ページからアクセスできます。登録不要/無料でご覧いただけますので、ぜひご視聴ください。

「PREEvision UserDay 2015 Tokyo」開催のお知らせベクターは、6月9日（火）に東京にて「PREEvision UserDay 2015 Tokyo」と題したセミナー形式のイベントを開催します。本イベントでは、ベクターの「PREEvision」のユーザーであるボッシュエンジニアリング株式会社様より、PREEvisionの使用事例をご講演いただきます。また、株式会社ローランド・ベルガー様、DNV GLビジネス・アシュアランス・ジャパン株式会社様より、業界注目のトピックであるE/Eアーキテクチャー開発環境に関する基調講演をしていただきます。PREEvisionユーザーの実際の使用事例を知ることができる、またとない機会となっております。本イベントは事前お申込み制となっており、当日のお申込み状況はベクターのWebサイトでご確認いただけます。すでにお申込みいただいた皆様におかれましては、誠にありがとうございます。当日、皆様のご来場をお待ちしております。

催事名：『PREEvision UserDay Tokyo 2015』◎会期： 2015年6月9日（火）　　　　[一般向けセッション]　　　　　　 10：00～13：25　　　　[保守契約ユーザー向けセッション]　14：15～18：00◎会場：ステーションコンファレンス東京（東京都千代田区丸の内1-7-12　サピアタワー6F　JR東京駅日本橋口直結）　

■PREEvision UserDay 2015 Tokyo 開催　　http://www.vector-japan.co.jp/pv-ud

「ベクター・コングレス 2015」開催のお知らせベクターでは、ものづくりの現場で活躍するお客様に業界の有用な情報をご提供するため、ベクター製品をご活用いただいているお客様による開発事例紹介を中心とした、セミナー形式のイベント「ベクター・コングレス」を開催しています。今年は10月2日（金）に名古屋で、そして10月22日（木）に東京で「ベクター・コングレス 2015」を開催いたしますので、ぜひご来場ください。イベント詳細については、ベクターのWebサイトでお知らせする予定です。多くの皆様のお越しを心よりお待ちしています。

「第7回国際カーエレクトロニクス技術展」に出展しましたベクターは2015年1月14日（水）～1月16日（金）に東京ビッグサイトにて開催された「第7回国際カーエレクトロニクス技術展」に出展いたしました。ベクターブースでは業界の最新動向を踏まえ、CAN FDや車載Ethernet、AUTOSARについてのプレゼンを実施し、多くの方に聴講していただきました。さらにブース内では先端技術（次世代車載ネットワーク、安全運転支援、AUTOSAR等）や開発効率化を図る（ECUテスト、車載ネットワーク、パワートレイン等）ベクターの各種ツール・ソリューションをご紹介させていただきました。今回も多数のお客様にお越しいただき、おかげさまで盛況のうちに終えることができました。ご来場いただきました皆様に、この場を借りて厚く御礼申し上げます。

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

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

■ベクター・ジャパンHP 　　お役立ち情報　　ベクター動画ポータル　ベクター動画ポータル　　https://jp.vector.com/vj_videos_jp.html

「vSignalyzerバージョン13.0」リリースあらゆるタイプの測定データを効率的に評価および解析できるツールである「vSignalyzerバージョン13.0」をリリースいたしました。

〈主な特長〉　● 高性能な印刷機能およびレポート機能　● CAN、CAN FD、LIN、FlexRayのバスロギングデータの解析　● シグナルフィルターとスペクトログラムビュー　● シンプル操作によるズーム機能　● 使いやすい統計関数　● グラフィックWindowにデータ解析結果をより分かりやすく表示　● ASCII形式の測定データの柔軟なインポート　● 同期情報を持たないマルチメディアファイルの統合　● 各種地図素材を用いたGPSデータの表示（オプション不要）　● CANapeで作成したプロジェクトも利用可能　● 圧縮されたシグナルを含むMDF4.1形式のサポート　● 複雑な設定のWindowを再利用するためのテンプレート機能　　詳しくは、ベクターのWebサイトをご覧ください。

「vADASdeveloper」リリースマルチセンサーADAS（先進運転支援システム）アプリケーション向けの実装、デバッグ、テスト用ツール「vADASdeveloper」をリリースいたしました。

〈主な特長〉　● アルゴリズム開発から複数センサーのデータ記録、スティミュレーション、処理結果の迅速な可視化まで、あらゆる局面に対応す　るソリューションを提供　● アルゴリズム開発にフォーカスしたソフトウェア開発プラットフォームを提供　● Visual Studioとの統合によるアルゴリズムのリアルタイムデバッグをサポート　● マルチセンサーアプリケーションのラピッドプロトタイピング開発を支援　● 既存の開発環境への組み込みが容易　● カメラおよびベクターのバスインターフェイスにアクセスするため　の豊富なセンサーコンポーネントを提供　● C/C++およびMATLAB/Simulinkソフトウェアコンポーネントを　簡単に組み込み可能　● MDFやADTF DATなどの一般的なデータ形式をサポート　●「BASELABS Create」コンポーネントライブラリのシームレスな　統合により、複雑なアルゴリズムを簡単に使用可能詳しくは、ベクターのWebサイトをご覧ください。

vSignalyzerを使用して測定データをすばやく簡単に評価


測定、キャリブレーションから診断まで幅広いタスクを効率化するベクターソリューション包括的なツールサポートで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キャリブレーション

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

ベクター・ジャパンのWebサイト（下記URL）まで

www.vector-japan.co.jp/vj_vector_journal_jp.html

お問い合わせ

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

技術関連のお問い合わせ

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

I n f o r m a t i o n


Vector Journalについて

「Vector Journal」は、ベクター･ジャパンが発行する広報誌です。原則として5月および11月頃の年2回定期的に発行しています。お客様の事例を中心に、新しい技術動向やベクターの新製品などに関する情報をご紹介しており、無料でご購読いただけます。

東　京　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


測定、キャリブレーションから診断まで幅広いタスクを効率化するベクターソリューション包括的なツールサポートで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キャリブレーション

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

ベクター・ジャパンのWebサイト（下記URL）まで

www.vector-japan.co.jp/vj_vector_journal_jp.html

お問い合わせ

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

技術関連のお問い合わせ

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

I n f o r m a t i o n


Vector Journalについて

「Vector Journal」は、ベクター･ジャパンが発行する広報誌です。原則として5月および11月頃の年2回定期的に発行しています。お客様の事例を中心に、新しい技術動向やベクターの新製品などに関する情報をご紹介しており、無料でご購読いただけます。

東　京　TEL : 03-5769-6980

名古屋　TEL : 052-238-5020


［組込ソフトウェア関連製品］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


Documents

V J 10 - Vector › cms › content › know-how › VJ › PDF › ...Vector Journal Vol.10 01 06 10 15 20 26 34 40 48 Technical Article 発行元： ベクター・ジャパン 株式会社

V J 10 - Vector › cms › content › know-how › VJ › PDF › ...Vector Journal Vol.10 01 06 10 15 20 26 34 40 48 Technical Article 発行元：ベクター・ジャパン株式会社