プレスアーティクル

Technical Article
大型車両とAUTOSAR
∼ J1939 の AUTOSAR への統合∼
自動車業界でAUTOSARの採用が広く定着してきた昨今、大型車両分野もAUTOSARに目を向け始めており、大型車
両メーカーもAUTOSARのモジュール概念を適用して開発コストを節約したいと考えています。自動車業界で使用さ
れている静的なネットワークとは異なり、大型車両ではJ1939規格に基づいた動的な通信が使用されています。 本
稿では、 J1939をAUTOSARに統合する利点と制約について考察します。
SAE J1939は、大型車両業界のネットワークと通信のために確
AUTOSARの狙い ― ソフトウェアの再利用
立された標準規格です。 J1939は、直接使用される場合と、派生
Association) は海洋分野で使用されています。ヨーロッパやその他
の特定の地域の大型トラック業界では、J1939の一部しか使用してい
AUTOSAR規格の開発には、主に2つの動機があります。1つは、ハー
ドウェアとプロトコルドライバーの標準化で、これはECUサプライヤー
の変更を容易にします。もう1つは、アプリケーションソフトウェアの
モジュール化で、ますます複雑化するECUの取り扱いを容易にします。
ません。一般の自動車業界と比べ、大型車両業界は生産量が少ない
プロトコルおよびハードウェアドライバーは、ベーシックソフトウェア
標準規格の形で使用される場合とがあります。 例えば、ISOBUSは
農業や林業の分野で、NMEA2000 (National Marine Electronics
®
ため、ハードウェアのコストや倉庫保管のコストよりもソフトウェア開
モジュール (BSW module) の形で標準化され、アプリケーションソ
発に掛かる費用の比率が高くなります。そのため、ソフトウェアの再
フトウェアはソフトウェアコンポーネント (SWC) の形でモジュール化
利用に注力することは理にかなっています。しかし実際は、ほとんど
および抽象化されます。 図1は、J1939アプリケーション用ベーシッ
の開発者が個々のECUに新たにコードを書いています。ハードウェア
クソフトウェアの一部と、ランタイム環境 (RTE) およびアプリケーショ
やプロトコルドライバーさえも、多くのプロジェクトで毎回開発され
ンレイヤーを示しています。
ており、それはドライバーやアプリケーションソフトウェアのパーツを
再利用するための共通の標準規格がないことに起因しています。
March 2014
1
Technical Article
AUTOSARのソフトウェアコンポーネントモデル
AUTOSARは静的なバス通信モデルを考慮して設計されました。しか
し、静的な通信モデルであったため、初期の頃は大型車両分野では
AUTOSARシステムのアプリケーションソフトウェアは、各エレメン
AUTOSARが使用されていませんでした。 AUTOSARがJ1939に初め
トが階層的に整理されたコンポーネントに細かく分類されます。アプ
て対応したのは、2009年末にリリースされたAUTOSARバージョン4.0
リケーション側から見ると、コンポーネント間の通信がAUTOSARの
でした。このバージョンにおいて、Vector Informatik GmbH (ベク
バーチャルファンクションバス (VFB) を超えて行われ、実際のECUの
ター本社：
ドイツ、シュツットガルト) は、ヨーロッパのトラックメーカー
トポロジーを隠します。コンポーネントはこれらの通信の要求をイン
と協力し、J1939のトランスポートプロトコル用AUTOSARベーシック
ターフェイス (ポート) 経由で定義し、データエレメントまたはデータ
ソフトウェアモジュールを規定しました。しかし、その頃すでに、ほ
操作をグループ化します。 VFBはこれらのポートを抽象レベルで接続
とんどのJ1939アプリケーションにとってAUTOSAR4.0によるJ1939
します。アプリケーションソフトウェアコンポーネントがECUに割り当
要件のサポートが充分ではないことは明らかでした。
てられた後 (図2)、RTEは個々のECUのためのVFBの役割を担います。
つまり、RTEはアプリケーションソフトウェアコンポーネントのすべて
の通信インターフェイスを、コンポーネントとベーシックソフトウェア
AUTOSAR 4.1で拡張されたJ1939要件のサポート
間や他のECUとの間に実装します。
AUTOSARバージョン4.1は、2013年3月にリリースされました。
J1939に関する最も重要な変更は、より高いレイヤーからCAN IDの
大型車両のためのAUTOSAR ― 始まり
パーツにアクセスできるようになったことでした。この変更により、
動的なネットワークで効率的な通信が可能になります。メッセージを
当 初、AUTOSARは 乗 用 車 の 必 要 性に照 準を合 わ せ た 規 格 で
あったため、静的な通信マトリクスを使用しています。 そのため、
受信すると、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」
図2：
図1：
ライブラリーからECUへのソフトウェアコンポーネントの
大型車両用AUTOSARアーキテクチャーからの抜粋
割り当て
March 2014
2
Technical Article
> J1939-81に 準じた、 簡 単 な アドレス 割り当 て 方 法 用「J1939
Event Manager」に保存されたフォールト情報へのアクセスをUDS診
Network Management」
> J1939-73に準じた、診断用「J1939 Diagnostic Communication
Manager」
断と共有している点です。これにより、両診断プロトコル用の診断情
報を確実に統一管理することができます。
J1939のAUTOSAR 4.1への統合におけるギャップ
AUTOSARバージョン4.1のJ1939 Request Managerは、 要求お
よびアクノリッジメッセージの送受信を処理します。この目的を達成
AUTOSARはバージョン4.1からJ1939対応へ の一歩を踏み出し
するため、J1939 Request ManagerはRTE経由で、関連するBSWモ
ましたが、農林機械においては特に、まだ少々のギャップがありま
ジュールまたはアプリケーションソフトウェアコンポーネントへ、イン
す。 AUTOSARで明らかに欠落しているのは、実行時にアドレス変更
ターフェイスを提供します。さらに、送信された要求のタイムアウト
を可能にする自己設定およびコマンド設定可能なECUへの対応です
モニタリングも行います。
(図3)。さらに、AUTOSARは、J1939ベースのISO 11783 (ISOBUS)
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
> NMEA 2000®のFastPacket
> ISO 11783-6のETP
ユニバーサル端末やファームウェア管理、類似コンポーネント用
のアプリケーションプロトコルの実装も望まれています。
また、AUTOSARは、Request2メッセージやTransferメッセージ、
NAME管理やその他の診断メッセージを用いた要求‐応答の拡張プロ
トコルにも未対応です。 そして、J1939の標準化されたシグナルと
メッセージへの簡単なアクセスのためのソリューションも備えていま
せん。
展望
現在、AUTOSARに前述のギャップを埋めるような動きはありませ
ん。しかし、特に農業や林業を管理する業界において、より多くの商
用車自動車メーカーがAUTOSARに関わる動きを見せています。その
結果、長期的に見れば、ISOBUSへの拡張もAUTOSARで標準化され
ることが見込まれます。
それまでは、ツールやベーシックソフトウェアメーカーは暫定的な
ソリューションで対応していくでしょう。例えば、Vector Informatik
図3：
表1：
AUTOSAR 4.1が対応するJ1939診断メッセージ
March 2014
ISOBUSにおける動的なアドレス割り当て：接続したばかりの
ECU Cがアドレス10を占有したため、 ECU Aはアドレスを変更
3
Technical Article
GmbHでは、現在、充分に動的なアドレス割り当てや、アプリケーショ
提供元：
ンをJ1939のメッセージやシグナルのカタログに容易にリンクさせる
見出し画像、図1 ∼ 3および表1：Vector Informatik GmbH
ためのサポートを開発しています。また、ETPおよびFastPacketトラ
ンスポートプロトコルの実装も計画されています。
リンク：
ベクターのAUTOSARソリューション「MICROSAR」(英語版サイト)
http://vector.com/vi_microsar_en.html
本稿は2013年11月にドイツで発行されたHanser automotiveに
掲載されたベクター執筆による記事を和訳したものです。
ベクター ･ジャパン
www.vector-japan.co.jp
執筆者：
Martin Schlodder (Dipl. Inf.)
テュービンゲン大学でコンピューターサイエ
ンスを学 び、2004年 からVector Informatik
GmbHにてJ1939ソフトウェアを開発。 J1939
のAUTOSAR統合のためのワーキンググループ
にもメンバーとして参加。
March 2014
4