自 動 車

自動車ソフトウェアの標準仕様“A U T O S A R ”の評価
堀川加

櫓健一 ・目＊崎元太・渡武・松本達治辺章

代

Evaluation of Automotive Software Standard “AUTOSAR” ─ by Kenichi Horikawa, Genta Mesaki, Akiyo Watanabe,
Takeshi Karo and Tatsuji Matsumoto ─ Automotive Open System Architecture (AUTOSAR) has established standard
specifications of automotive software including layered software architecture and development methodology. We havemade a prototype of our body ECU software in accordance with AUTOSAR standard specification to compare
properties, such as ROM and RAM sizes and execution speed, with software produced by our current platform. In thisreport, model-based development methods are also evaluated along with AUTOSAR standard specification.
Keywords: AUTOSAR, RTE, basic software, model based development, automotive, ECU, standard specification

1.

緒言

近年、自動車の電子制御化が急速に進んでいる。それに御、エンジン制御、パワートレイン制御、走行制御、情報伴い、自動車１台に搭載されるソフトウェアの開発規模はシステムなど多岐に渡り、①②③はその一例である。電子

この 20 年間で約 1,000 倍に膨れ上がった（1）。しかし、ソ制御の中心である ECU の内部にはマイクロコントローラ

フトウェアの大規模化・複雑化は、生産性と品質の低下を（以下、マイコン）と呼ばれるコンピュータが組み込まれ招き、自動車産業界全体の深刻な課題となっている（2）。ている。高機能化に伴い、１台の自動車に 70 個以上のこの課題の解決のため、標準化団体 AUTOSAR※１が設立された。AUTOSAR はソフトウェアアーキテクチャや開発メソドロジなどの標準仕様を規定した 。
（3）

AUTOSAR の標準仕様は非常に先進的であり、現状の課ECU が搭載されている場合もある。
この ECU のソフトウェアは基本ソフトウェアとアプリケーションソフトウェア（以下、アプリケーション）から構成される。アプリケーションは ECU の機能そのものと題をうまく解決できている。しかし、一方で各社が現在使言ってよく、ボディ ECU のアプリケーションはドアロッ用している基本ソフトウェアよりもオーバヘッドが大きくク、ヘッドライト、ワイパー等である。近年ではオートラなるため、AUTOSAR に移行するとマイコンの処理速度やイト、オートワイパー、セキュリティ制御などとアプリRAM などのメモリ容量が従来よりも多く必要になり、部ケーションの多機能化が進んでいる。一方、基本ソフト品コストが増加すると考えられる。

ウェアは ECU そのものの機能というよりは、マイコンの我々は当社が製造しているボディ ECU（Electronic管理サービス、リアルタイムオペレーティングシステム、Control Unit、電子制御ユニット）のソフトウェアを、通信サービスなど、アプリケーションを動作させるためのAUTOSAR 標準仕様に準拠して開発した場合の、メリッインフラストラクチャ的な部分である。

ト・デメリットの評価が必要であると考え、試作評価を行った。本稿では、この評価結果について述べる。

近年、自動車の高機能化が進んでおり、自動車の総原価に占めるエレクトロニクス関連部品の比率はハイブリッド車の場合では半分近くにまで高まっており、ECU の開発に2.

背２－１

おいてソフトウェアの開発工程が全行程の８割以上とも言景われている（2）。このように自動車におけるソフトウェアは自動車のソフトウェア

近年、自動車では下記のような環境性能・安全性・快適性の向上が急速に進ん製品開発において重要な位置を占めるようになっている。
そして、高機能化を実現するため、ソフトウェアの大規模化・複雑化が進展している。例えば当社製品のソースでいる。
①環境性能：燃費向上・排出ガス低減のためのエンジン制御、ハイブリッド車等

コード行数はこの 10 年間で 10 倍近い増加を示しており、一つの ECU のソフトウェアのソースコードが 20 万行に達す②安 全 性：エアバッグ、アンチロックブレーキ等るものもある。大規模化と複雑化は生産性と品質の低下を③快 適 性：オートエアコン、自動変速機、遠隔制御ド招き、業界全体の深刻な課題となっている。例えば、20 万アロック等
これらは電子制御により実現され、電子制御はボディ制−（ 92 ）− 自動車ソフトウェアの標準仕様“AUTOSAR”の評価

個の部品からなる機械が ECU のソフトウェアであると考えれば、その開発において生産性と品質を維持することの困難さは想像できるであろう。

管理、AD 変換や PWM 出力、不揮発データの管理、続い後述する省電力制御機能なども標準化された。これにて、自動車のソフトウェア開発が抱える課題について具体

より、部品メーカはアプリケーションの開発に更に注

２－２

自動車ソフトウェア開発が抱える課題的に述べる。

力できるようになった。

①基本ソフトウェアの開発：従来、基本ソフトウェアは②R TE（Run Time Environment）：従来のアプリケー

部品メーカやカーメーカにより独自に開発されており、ションは制御ロジックとアプリケーション外部とのイ

当社も独自に開発している。しかし、自動車の商品力ンタラクションからなる。アプリケーションの可搬性は基本ソフトウェアの優劣よりも、アプリケーションを向上させるには、アプリケーションを制御ロジックの優劣で決まる部分が大きく、差別化が図りにくい基のみにして、アプリケーション外部とのインタラク本ソフトウェアの独自開発は負担になっていた。そこションは別モジュールに移すことが考えられる。アプ

で、基本ソフトウェアを標準化して業界全体で共有すリケーションの割付変更の際は、そのインタラクショることが考えられた。こうすることで、基本ソフトンのモジュールだけを修正すればよく、アプリケーウェアの開発に投じていた人的資源をアプリケーショションの修正は不要である。これはソフトウェアの分ンの開発に投入できる。過去に、欧州では OSEK/VDX

野では一般的な手法であり、当社独自の基本ソフト（4）によるオペレーティングシステムや通信サービスの標ウェアでも既に同様の仕組みを導入している。

準化が行われたが、より広い範囲での標準化による開AUTOSAR ではこの仕組みを RTE と呼び、標準化し発の更なる効率化が必要と考えられた。

た。他にオペレーティングシステム、グラフィカルな②アプリケーションの可搬性の確保：自動車のシステム開発ツール、ソースコードの自動生成機能なども併せ開発では多くの場合、直近の同車種や他車種のシステて導入した。

ムをベースにして、ECU の個数、搭載箇所、ECU への③仕様記述の標準化： AUTOSAR ではアプリケーションアプリケーションの割付を見直す形で開発される。例のインタフェースを定義する定義ファイルの書式が標

えば、ベースとした車種では 2 個の ECU に分割して割準化され、AUTOSAR 準拠の開発ツールでグラフィカ付けていたアプリケーションを、新しい車種では 1 個ルに記述できる。従来の自然言語主体の文書の代わりの ECU にまとめる割付をして開発する場合がある。まに、この定義ファイルを授受することで、カーメーカ、た、逆に分割して開発する場合もある。ECU の数・規部品メーカ間での仕様の伝達が明確になり、開発効率模・搭載機能数が増加するにつれて、アプリケーショを向上することができる。

ンの割付の変更規模と複雑さが増す。このような割付

これらは当社の基本ソフトウェアよりも優れていると考変更の際、従来のソフトウェア開発ではアプリケーえられ、実際にボディ ECU を試作して評価することが必ションの修正が必要だった。もし、アプリケーション要と考えた。

を修正することなく、アプリケーションの ECU 間での割付を変更できれば生産性を大きく向上させることができる。ソフトウェア工学では、ソフトウェアの異な※２という。
る環境への移しやすさを可搬性（Portability）③企業間での仕様の伝達：従来、カーメーカと部品メーカ間では、仕様書と呼ばれる文書により仕様が伝達さ

3.

ボディ ECU に AUTOSAR を適用した場合の問題点
一方、ボディ ECU に AUTOSAR を適用した場合の問題点も考えられ、以下にそれらについて述べる。
３－１

計算量、ROM サイズ、RAM サイズの増加製れていた。自然言語主体の仕様書では、曖昧な部分や品の競争力を維持するためには、部品コストの低減が必要

不完全な部分がどうしても発生し、それが不具合とな不可欠である。マイコンは ECU の中で最も高価な部品であり、手戻りや品質の低下を招いていた。

り、一般的にその価格はマイコンの動作クロック周波数がこれらの課題を解低いほど、ROM サイズ、RAM サイズが小さいほど低価格決するため、欧州では自動車関連メーカが中心となって、である。動作クロック周波数は単位時間あたりの計算量に２－３

AUTOSAR の特徴と利点

AUTOSAR という標準化団体が設立された。AUTOSAR は比例する。計算量を低減できれば、動作クロック周波数を自動車のソフトウェアのアーキテクチャや開発メソドロジ低く抑えることができ、低コスト化できる。そこで、当社の標準化を行うことで生産性と品質の課題を解決しようとの基本ソフトウェアも計算量、ROM サイズ、RAM サイズした。以下に、標準化の概要とメリットを述べる。

を小さくすることを重要な要件の一つにして開発している。

①基本ソフトウェア： OSEK/VDX では前述のように基また、AUTOSAR では仕様の標準化に伴うオーバヘッド

本ソフトウェアの一部であるオペレーティングシステが大きい。そのため、マイコンの処理能力を高く、メモリムと通信サービスについてのみ標準化された。

容量を大きくする必要があり、大幅なコスト増につながるAUTOSAR では基本ソフトウェア全般にわたり標準化と考えられる。

を進めた。例えば、CPU 動作クロックなどのマイコン

更に、AUTOSAR ではオペレーティングシステムが必須

2 0 0 9 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 5 号 −（ 93 ）−の構成要素になっており、これもオーバヘッドが大きくな際規格である ISO-9126（5）を用いた。ISO-9126 では品質モる要因と考えられる。オペレーティングシステムの利用にデルを機能性（functionality）、信頼性（reliability）、使より、大規模な ECU ソフトウェアを開発する場合には生用性（usability）、効率性（efficiency）、保守性（main産性を向上させることができる。しかし、小規模 ECU でtainability）、可搬性（portability）の６特性と約 30 の副は大規模 ECU よりも、コスト増の影響が大きくなるため、特性で表現している。我々はこの品質モデルを用いて、ボオペレーティングシステムを搭載しないのが一般的であディ ECU ソフトウェアの評価項目を検討した（表１）。今る。当社の製品でも小規模 ECU ではオペレーティングシ

回は新規開発に限定した評価項目を抽出したため、評価項ステムを搭載していない。

目が機能性、信頼性、効率性に集中している。実際の開発
ボディ ECU の特徴にでは仕様変更や、他の車種への流用作業が発生するため、は低消費電流モードによる省電力制御機能がある。エンジ保守性や可搬性が重要になり、これらの評価も必要になる。

３－２

省電力制御の実現性

ン ECU などの ECU は基本的にはエンジン動作時にだけ動作すればよい。一方、ボディ ECU はドアロック、室内灯、ヘッドライト、セキュリティなどの機能を持つが、これらの機能はエンジン停止時にも動作が必要である。しかし、品質特性ティに至っては、ユーザが車両を離れている間も動作を続うと、次回のエンジン始動時にエンジンがかからなくなっ入力SWのノイズ除去の適切性

正確さ

処理周期のばらつき（最大遅れ時間）、モータ出力時間・モータ停止時間の正確性、断線判定の精度

フォールト
トレランス

効率性てしまう問題点がある。
従って、エンジン停止時のボディ ECU の消費電流は小さいほどよい。この時、消費電流の大部分はマイコンによるものである。そしてマイコンの消費電流は、マイコンの評価項目の例

適切性ける必要があり、長期間バッテリの電力のみで動作することが求められる。しかし、バッテリを過度に消耗してしま副特性

信頼性のみで動作しなければならない。ドアロックやセキュリ

ボディ ECU ソフトウェア評価項目（概略）

機能性エンジン停止時は発電機が発電しないため、バッテリ電力

表1

通信異常時に誤動作しないこと

復元力

通信・電源復帰時に動作回復するまでの時間

時間挙動

起動時間、各機能の応答時間、低消費電流モードでの各機能の応答時間

資源活用度

CPU負荷率、ROM使用量、RAM使用量、低消費電力モード時の消費電流

動作クロック周波数が高いほど大きい。動作クロックを停止するか、極めて低い周波数にすることで消費電流を大幅また、評価項目の検討とあわせて今回の試作開発での試に低減でき、この状態を低消費電流モードと呼ぶ。
そこで、ボディ ECU ではバッテリの充電量を温存しつ
つ、長期間の動作を続けるために、マイコンの処理が不要

作 ECU の仕様を検討し、ドアロックとヘッドライトの制御機能の搭載を決定し、詳細仕様を定めた。と判断した時に、低消費電流モードに移行する。そして、通常の動作が必要になった場合は通常の動作クロック周波数に復帰する。
AUTOSAR では基本ソフトウェアで省電力制御機能を用

5.

評価結果
図 1 に試作したソフトウェアの設計の概念図を示す。

意している。しかし、前述したように、標準仕様に準拠しまた、写真１の確認用のハードウェアを開発し、これを用た基本ソフトウェアにはオーバヘッドがある。我々はこのいてテストと測定を行った。

オーバヘッドにより、通常モードへの復帰判断にかかる時間が増大するおそれがあると考えた。この時間を省電力制御時の応答時間と呼ぶことにする。この応答時間が増加す

表２に主な評価結果を示す。

製品版の ECU では消費電流が小さくなるように電子部品を選定して、最適なハードウェア設計にするが、今回のれば、ユーザの行った操作に対する応答が遅くなる。ある評価用ハードウェアでは設計時間の問題からその様な設計程度以上遅くなると、ユーザは使い心地が悪いと感じたり、にしなかった。そのため、今回は消費電流の評価を行って故障が発生したと感じたりすることになり、商品性の観点いないので別途行う必要がある。

から好ましくない。
以上のように、省電力制御時の消費電流と応答時間は省電力制御の重要な評価項目である。

５－１

処理周期のばらつき

処理周期の正確さは機能の安定した動作には欠かせないので、理想的な周期に対する最大遅れ時間を機能性の正確さの項目の一つとした。
測定したところ AUTOSAR 導入後も 0.1 ミリ秒であり大き4.

評価項目の検討
試作評価にあたって、まず、評価項目の検討を行った。

評価項目の整理には、ソフトウェア品質の評価に関する国−（ 94 ）− 自動車ソフトウェアの標準仕様“AUTOSAR”の評価な遅れは発生しなかった。従って、ボディ ECU に適用しても問題ないと考えられる。なお、従来品は測定精度の0.1 ミリ秒未満であった。この差はオペレーティングシス
テムの導入により発生したものと考えられる。

ドアロックAP SW-C

ドアロックACT SW-C

ロック
判定
結果

SW
データ

DIO
駆動
要求

ロック
判定
結果

電源監視SW-C

高速運動SW-C

なかった。そして、基本ソフトウェアによる増分の大部分

ライトAP SW-C

ライトACT SW-C

はオペレーティングシステムであった。

点灯
判定
結果

SW
データ

点灯
判定
結果

PWM
駆動
要求

COM
PDUR
CANIF
CAN

が容易になるメリットはあるものの、AUTOSAR の基本ソ
フトウェアを搭載、即ちオペレーティングシステムの搭載

RTE

OS

従って、オペレーティングシステムの導入により、開発

フィルタリング処理

IoHwAbs

PORT

DIO（PWM処理）
出力

送信

受信

入力

入力

入力

出力

ドア開
データ

集中
ロックSW
データ

キー
シリンダ
ロックSW

ライト
SW

ドア開
データ

ドアロック
モータ

ライト

により、以前よりも多くのメモリ資源が必要になり、現状
ではこのコストアップは受け入れられない。将来、ソフト

ADC

ウェアの規模が大きくなれば、AUTOSAR による必要メモ

入力

リの増加は相対的に小さくなり、コストアップも小さくな（バルブ電流）るので、導入の可能性が増すと思われる。
５－３図1

試作したソフトウェアの設計の概念図

低消費電流モードでの応答時間

低消費電流モードでの応答時間を測定したところ従来品に比べて３～５倍も長く、応答性がかなり悪くなっていることが判った。
その理由を分析したところ、二つの原因が分かった。
①排他制御の処理時間の増加
基本ソフトウェアやアプリケーションでは、割込み処理による異常動作を防ぐために排他制御を行う必要がある。AUTOSAR の基本ソフトウェアはいかなる使い方でも異常動作が発生しないよう、従来品の基本ソフトウェア以上に排他制御を多用している。さらに、排他制御の実現にオペレーティングシステムが提供する排他制御機能を利用しており、その１回あたりの排他制御の処理時間が従来品の基本ソフトウェアよりも長い。
さらに、低消費電力モード中はマイコンの動作クロック周波数を低く設定しており、排他制御を動作ク

写真 1開発したボディ ECU 評価用ハードウェアロック周波数が低い状態で実行するため、実行時間が大幅に増加していた。
②マイコンの動作クロックを扱うドライバの問題

表2

機能性品質
副特性
特性

評価項目

マイコンの動作クロック周波数の切替は基本ソフト

主な評価結果ウェアが行い、今回評価した AUTOSAR ではあらゆる測定結果

処理周期の従来品：0.1ms未満（測定不能）
正確さ ばらつき
測定値：0.1ms（最大遅れ時間）

効率性

時間
挙動

低消費電流モード 従来品の約５倍（通信によるウェイクアップの場合）
での各機能の応答時間
従来品の約３倍（スイッチ入力によるウェイクアップの場合）

マイコン負荷率

資源
効率性 ROM使用量
RAM使用量

従来品の1.8倍（定常時）
従来品の2.5倍（高負荷時）
従来品の3.5倍
従来品の2.2倍周波数への切替を保証している。一方、半導体メーカ
はマイコンの安定動作のため、切替時の安全な処理順序を開示している。特定の組み合わせの切替では、これらの指示に従わなくてもよい場合もあるが、AUTO
SAR の基本ソフトウェアでは半導体メーカの指示に忠実に従った切替処理が用意され、組み込まれている。
従来の基本ソフトウエアでは使用する周波数で必要な指示にのみに対応し、必要かつ最小の処理で実現されているのに比べると、AUTOSAR はその点オーバーヘッドが大きい。また、AUTOSAR では切替処理の途中で安全な切替のため我々が使用している低消費電流モードの動作クロック周波数（約 32KHz）よりもさらに低い周波数（約 8KHz）で動作させていた。以上にROM サイズ、RAM サイズ、マより、切替処理にかかる時間が大幅に増加していた。

イコン負荷率は AUTOSAR 導入により約 2 ～ 4 倍に悪化し実際の開発ではこれらのオーバヘッドを軽減させた。そこで詳細に分析すると、アプリケーションはほとんて、応答性を向上しなければならない。そのために、ど増加しておらず、基本ソフトウェアの増加が原因である基本ソフトウェアの開発元と協力して、基本ソフトことが分かった。具体的には、アプリケーションの ROMウェアを最適化（カスタマイズ）する作業が重要と考

サイズは従来品も AUTOSAR 版も約 3K バイトであり差がえられる。

５－２

資源効率性

2 0 0 9 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 5 号 −（ 95 ）−6.

AUTOSAR にモデルベース開発手法を併用した時の評価のハンドコードが不要であった。なお、基本ソフト現行のソフトウェア

ウェアはオブジェクト供給であり、行数は不明である。

開発手法は設計書を中心とした開発手法である。仕様書かそのため、表ではハンドコード以外の行数は記載して

６－１

モデルベース開発手法

らソースコードに至るまでに数種類の設計書を記述する
が、設計書は動作させて確認することができない。ソースコードが完成した後に初めて動作させながら設計の正しさを確認することができるようになる。

いない。
②アプリケーションはモデルベース開発技法の自動コード生成によりハンドコードが不要だった。
③基本ソフトウェアとアプリケーションの中間に位置す

一方、モデルベース開発手法では開発の初期段階から実る RTE は、AUTOSAR の RTE 生成機能によりソース現すべき機能をモデルと呼ばれる設計図を作成し、その後コードが自動で生成できたため、ハンドコードが不要の各設計段階でもモデルを作成する。モデルはツールを用いて動作させることができ、それにより設計の正しさを確だった。
ROM、RAM サイズをアプリケーション部分に限定して認することができる。開発の初期段階から動作に基づく検比較すると、表４のとおり、従来手法よりも若干小さく証が可能になるため、不具合の早期発見が可能になり、開なっている。なお、ソフトウェア全体では表３に示すとお発効率や品質を向上させることができる。また、モデルかり、従来の２～３倍と非常に大きくなっており、この要因

ら自動コード生成を行うこともできるので、ソースコードは主に AUTOSAR の基本ソフトウェアである。

作成工程の省力化も可能である。
６－２

AUTOSAR とモデルベース開発手法

AUTO

SAR は前述のように、設計データの受け渡しの書式を標準化しており、アプリケーションのインタフェース定義も標表3

モデルベース開発手法併用時の測定値（全体）準化されている。設計者は AUTOSAR のシステム記述ツールを用いてアプリケーションのインタフェースを記述し、そのデータを AUTOSAR 標準仕様に準拠したモデルベース開発手法のツールに取り込んで使うことができる。開発をハンドコード行数

従来手法

モデルベース開発手法

22,641行

305行ROMサイズ（Kbytes）

18.4

53.6

RAMサイズ（Kbytes）

3.97.9

進めていく中で、モデルベース開発手法のツールとの連携が AUTOSAR の強みであることが分かり、モデルベース開発手法併用の効果検証も必要と考えた。そこで、これまで報告した試作と同一仕様のアプリケーションをモデルベース開発手法併用の開発環境を用いて設計して、連携の効果を検証した。
６－３

モデルベース開発手法併用の評価結果

モデ

ルベース開発手法併用評価の測定結果を表３に示す。
表の「従来手法」とは当社製の基本ソフトウェアを用いて、従来手法によりソフトウェアを開発した場合である。

表4

モデルベース開発手法併用時の測定値（アプリ部分）

従来手法

モデルベース開発手法

ソース ハンドコード
コード 自動生成
行数
合計

2,524行

0行

0行

4,537行

2,524行

4,537行

ROMサイズ（bytes）

3,144

3,056

RAMサイズ（bytes）

9276

表の「モデルベース開発手法」とは AUTOSAR の基本ソ
フトウェアとモデルベース開発のツールを併用した場合である。
表の「ハンドコード行数」はプログラマが直接記述したソースコードの行数である。「従来手法」では基本ソフトアプリケーションの ROM、RAM サイズが従来手法よりも若干だが小さい理由は以下のように考えられる。
プログラマがソースコードを直接記述する従来手法の開ウェアは当社で開発しているので、その行数に含んでいる。

発では、不具合になりやすいソフトウェア設計を排除する

一方、AUTOSAR 版では、基本ソフトウェアは基本ソフト目的などのため、コーディング規約と呼ばれるソースコー開発を専業とする企業から購入して利用したためその行数ドの記述ルールが設けられている。例えば C 言語の１つのに含んでいない。

関数の行数に上限を設定している。大きすぎる関数は、可従来手法のハンドコード行数が 22,641 行であるのに対読性が低下するため、不具合を発見、除去しにくくなり、して、「モデルベース開発手法」ではその約 1%の 305 行で保守性が低下するからである。コーディング規約を適用しあり、ハンドコードの必要がほとんどないことが確認できた場合、一般にはより多くの ROM が必要になる。例えばた。今回、プログラマがソースコードを記述したのは、電1 つの大きな関数を複数の小さい関数に分割して記述する

源投入時のマイコンの初期化などごく一部に限られた。

ことが必要になる。そして、一般的には関数間での関数呼この削減は以下のような理由による。

び出しが増加するためプログラムの ROM サイズが増加す①基本ソフトウェアを購入したため、基本ソフトウェアるのである。

−（ 96 ）− 自動車ソフトウェアの標準仕様“AUTOSAR”の評価

一方、自動コード生成の場合、ソースコードの作成は自用 語 集ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

動コード生成ツールにより行われ、ソースコードの作成の※1

過程で人為的な不具合が入ることはない。また、保守の際

Automotive Open System Architecture の略。自動車用AUTOSAR

も基本的には自動コード生成ツールに入力するモデルに対ソフトウェアの部品化および共通化を目的とした団体。ドして改変を行うため、直接ソースコードを読む必要がない。

イツの DaimlerChrysler や BMW AG、Robert Bosch

これらの理由から、自動コード生成による開発では一般的GmbH などが中心になり設立。現在は、日本の多くの自動にコーディング規約を適用する必要がない。但し、自動車関連企業も参加している。

コード生成ツールには様々な設定項目があり、これを調整することでコーディング規約にある程度従った、可読性の高いソースコードを生成させることも可能である。
今回は自動コード生成でそのような調整をしなかったた

※2

可搬性

移植性という訳語を使う場合もあるが、本稿では可搬性で統一している。

め、可読性は若干低下したが、その分 ROM、RAM サイズを抑えられた。なお、現在の自動コード生成ツールでも人間のプログラマに劣る場合もあり、そのような場合ではROM、RAM サイズが増加する。我々は他の事例でもアプ・OSEK/VDX は、ドイツ Continental AG の米国及びその他の国における商標または登録商標です。

リケーションの試作評価を行っており、その事例では自動コード生成の ROM サイズが従来手法よりも大きくなる場合があることを確認している。
また、今回の試作では、ツール間の連携の有効性も確認できた。即ち、AUTOSAR のシステムを記述するツールとモデルベース開発ツールの間の設計データの交換がAUTOSAR によるデータ形式の標準化により、電子的に行えることが確認できた。連携する複数の開発ツールのことをツールチェーンというが、今後の自動車のソフトウェア開発の分野ではこうしたツールチェーンによる開発が急速に発展し、更に効率的な開発が進められていくものと考えられる。

7.

結言

我々は自動車ソフトウェアの国際的な標準仕様であるAUTOSAR に準拠したボディ ECU ソフトウェアを試作し

参考

文

献

（1） 小川計介、「標準化で開発効率を高める車載ソフト巨大化に立ち向かう」、日経 Automotive Technology 2007 年 11 月号、pp82-97（2） 徳田昭雄、田村太一、「車載ソフトウェアの標準化と AUTOSAR の動向」、 立命館経営学、第 45 巻第 5 号、 PP.153-169, Jan（2007）（3）“AUTOSAR specification”R2.1, 3.0, 3.1（AUTOSAR 発行の標準仕様書）、http: //www.autosar.org からダウンロード可能（4）“OSEK/VDX specification”（OSEK/VDX 発行の OSEK OS などの標準仕様書）、http: //www.osek-vdx.org/ からダウンロード可能（5） JIS ハンドブック 2003 JIS X 0129-1: 2003（ISO-9126）、 日本規格協会

執筆堀川た。実際にソフトウェアを開発することで、世界最先端の者 ----------------------------------------------------------------------------------------------------------------

健 一＊：㈱オートネットワーク技術研究所
ソフト開発センター
自動車 ECU のソフトウェア開発に従事

標準仕様とソフトウェア開発技法を獲得することができた。また、マイコン負荷率などを定量的に測定し、部品コストの増加につながるため、現状のソフトウェア規模ではAUTOSAR 導入によるメリットは少ないと感じた。だからこそ、基本ソフトウェアのオーバヘッドを軽減させるなどしてコストを削減することが重要であると考えている。しかし、ECU ソフトウェアの開発経験の少ない開発チームでもソフトウェアを開発できたことから、優れたアーキテク目崎

元 太 ：㈱オートネットワーク技術研究所 ソフト開発センター

渡辺章 代 ：㈱オートネットワーク技術研究所 ソフト開発センター

加櫓

武 ：㈱オートネットワーク技術研究所 ソフト開発センター
主任研究員

達 治 ：㈱オートネットワーク技術研究所 ソフト開発センター
センター長­------------------------------------------------------------------------------------------------------------------------------------松本＊主執筆者

チャや開発手法により生産性を向上させられることを実感した。さらに、本稿後半で述べたように、モデルベース開発手法との親和性の良さも確認できた。これらの評価結果は、当社の今後の ECU 製品のソフトウェア開発に生かしていく所存である。

2 0 0 9 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 5 号 −（ 97 ）−