Download ePaper

HEV/EV - 経済産業省

HEV/EV - 経済産業省 HEV/EV - 経済産業省

from meti.go.jp More from this publisher

07.01.2013 Views

経済産業省 「平成 21 年度産業技術研究開発委託費 (産学連携ソフトウェア工学実践事業(高信頼組込みソフトウェア開発))」に関する委託事業事業報告書平成 22 年 3 月一般社団法人 JASPAR

経済産業省

「平成 21 年度産業技術研究開発委託費

(産学連携ソフトウェア工学実践事業(高信頼

組込みソフトウェア開発))」に関する委託事業

事業報告書

平成 22 年 3 月

一般社団法人 JASPAR

目次 >

1. はじめに ................................................................................................................ 1

1.1 本書の構成と概要 ......................................................................................................1

1.2 関連文書 ....................................................................................................................2

1.3 用語の定義 ................................................................................................................3

1.4 謝辞 ...........................................................................................................................6

2. 背景 ...................................................................................................................... 7

3. 欧州の活動状況 ..................................................................................................... 9

4. 本事業の目的 ....................................................................................................... 11

5. 本事業の実施内容 ................................................................................................ 12

5.1 自動車用制御基盤ソフトウェアの仕様策定と実装評価 ..........................................13

5.2 開発環境・ツールの仕様策定と実装評価 ................................................................14

5.3 プロセス実証 ...........................................................................................................15

5.4 実機適用に向けた実証 ............................................................................................16

6. 本事業の実施体制 ................................................................................................ 17

7. 本事業の’09 年度活動の概要と結果 ..................................................................... 24

7.1 自動車用制御基盤ソフトウェアの仕様策定と実装評価 ..........................................24

7.2 開発環境・ツールの仕様策定と実装評価 ................................................................58

7.3 プロセス実証 ...........................................................................................................87

7.4 実機適用に向けた実証 ......................................................................................... 105

8. 3カ年の活動総括 .............................................................................................. 170

8.1 自動車用制御基盤ソフトウェアの仕様策定と実装評価 ....................................... 170

8.2 開発環境・ツールの仕様策定と実装評価 ............................................................. 173

8.3 プロセス実証 ........................................................................................................ 177

8.4 実機適用に向けた実証 ......................................................................................... 187

9. おわりに ............................................................................................................ 188

10. 参考文献・参考ホームページ ............................................................................ 192

1. はじめに

1.1 本書の構成と概要

経済産業省の委託事業である「平成 21 年度産業技術研究開発委託費(産学連携ソフトウ

ェア工学実践事業(高信頼組込みソフトウェア開発))」に関する事業報告書は、以下の4種

類の内容から構成される。

・本事業を実施する上での背景情報(2章から3章)

・本事業の目的、実施内容および実施体制(4章から6章)

・本事業の活動概要と結果(7章)

・本事業のまとめ(8章、9章)

なお、本書中に記載されている社名、製品名などは、各社の登録商標または商標である。

1.2 関連文書

本書の関連文書は以下の通りである。

[1] 「平成 18 年度産業技術研究開発委託費(ソフトウェアエンジニアリングの実践強化に

関する調査研究)」に関わる個別調査研究 A5:自動車用制御基盤ソフトウェア関係調

査調査報告書

[2] 「平成 19 年度産業技術研究開発委託費(産学連携ソフトウェア工学実践事業(高信頼

組込みソフトウェア開発))」に関する委託事業事業報告書

[3] 「平成 20 年度産業技術研究開発委託費(産学連携ソフトウェア工学実践事業(高信頼

組込みソフトウェア開発))」に関する委託事業事業報告書

[4] 「平成 20 年度産業技術研究開発委託費(産学連携ソフトウェア工学実践事業(高信頼

組込みソフトウェア開発))」に関する委託事業事業報告書に付帯する別紙①

『AUTOSAR に沿った実開発の現状に関する調査報告書』

[5] 「平成 20 年度産業技術研究開発委託費(産学連携ソフトウェア工学実践事業(高信頼

組込みソフトウェア開発))」に関する委託事業事業報告書に付帯する別紙②『半導体

ベンダ･ベンチマーク調査報告書』

[6] 「平成 20 年度産業技術研究開発委託費(産学連携ソフトウェア工学実践事業(高信頼

組込みソフトウェア開発))」に関する委託事業事業報告書に付帯する別紙③

『JASPAR 活動成果の有効活用の為の知的財産管理に関する調査報告書』

[7] 「平成 21 年度産業技術研究開発委託費(産学連携ソフトウェア工学実践事業(高信頼

組込みソフトウェア開発))」に関する委託事業事業報告書に付帯する別紙①『「マイ

コンの故障検出性及びその仕様化の検討」に関する調査報告書』

1.3 用語の定義

本書で使用する用語の定義を記述する。

1) ARTEMIS: 第7次欧州研究開発フレームワーク計画(FP7、the Seventh Framework

Program for Research and Technological Development)において提唱された研究開

発への助成制度にて組織された、組込みコンピューティングシステム分野における官

民の新たな研究開発のパートナーシップ。EU の行政機関である欧州委員会(EC、

European Council)と産業界が共同で研究開発を進めている。Advanced Research &

Technology for Embedded Intelligence in Systems

2) Artop: AUTOSAR の開発ツールフレームワークの標準化を推進するために欧州の一

部ツールメーカと自動車メーカが中心となって設立した団体。AUTOSAR Tool

Platform

3) AUTOSAR: 自動車のソフトウェアの標準化のために欧州の自動車メーカと部品メ

ーが中心となって設立した団体。Automotive Open System Architecture

4) BSW: AUTOSAR ソフトウェア・アーキテクチャで規定された基本ソフトウェア。

Communication Module、Operating System 等。Basic Software

5) CAN:ボッシュ(Bosch)社が規格を行なった制御系車内 LAN インタフェース規格

の 1 つ。Controller Area Network

6) CANdb: ベクター(Vector) 社の CAN データベースファイル

7) CESAR: 第7次欧州研究開発フレームワーク計画の ARTEMIS において組織された、

組込みコンピュータシステム分野の機能安全についての検討を実施する団体。

Cost-efficient Methods and Processes for Safety relevant Embedded Systems

8) COM: AUTOSAR ソフトウェア・アーキテクチャで規定された通信モジュール

9) EAST-ADL: 欧州において標準化にむけた取組みが行われているアーキテクチャ記

述言語(ADL)

10) Eclipse: IBM 社によって開発された統合開発環境の1つ

11) ECU: 自動車において、エンジン、トランスミッション、その他の各種デバイスを

制御する電子制御ユニット。Electronic Control Unit

12) EPM: プロジェクト管理者(PM)とプロジェクトマネジメントオフィス(PMO)

を支援する観測型のプロジェクト管理支援システムおよび分析手法。Empirical

Project Monitor

13) ESMR: 独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センタ

ーで整備された組込みソフトウェア向けプロジェクトマネジメントガイド[計画書

編]。Embedded System Development Management Reference

14) ESPR: 独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センタ

ーで整備された組込みソフトウェア向け開発プロセスガイド。Embedded System

Development Process Reference

15) ESQR: 独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センタ

ーで整備された組込みシステム開発のための品質作りこみガイド。Embedded

System Development Quality Reference

16) ETSS: 独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センタ

ーで策定した組込みソフトウェア開発に関する指標。組込みスキル標準。Embedded

Technology Skill Standards

17) EV: 電気自動車。エンジンの代わりにモータとバッテリ、車載充電器、蓄電用のリ

チウム系のリチウムイオン電池やニッケル系などの蓄電池、制御装置などを備え、バ

ッテリに充電された電気で走行する車。Electric Vehicle

18) FIBEX: 「自動車業界のデータモデル、インタフェースおよびシンタックス仕様に

関する標準化委員会 ASAM(Association for Standardization of Automation and

Measuring Systems)」で規定されるメッセージベースのバス通信システム用のデー

タ交換フォーマット。XML をベースとし車載ネットワーク全体を記述するために必

要な情報がすべて含まれる。FIBEX は FlexRay バスシステムの標準規格として策定

されている。Fieldbus Exchange Format

19) FlexRay: FlexRay コンソーシアムが規格の策定を行っている制御系車内 LAN イン

タフェース規格の 1 つ

20) HEV: エンジンとモータを走行用の駆動源とするハイブリッド車。Hybrid Electric

Vehicle

21) IEC61508: 電気・電子・プログラマブル電子安全関連での機能安全に関する国際規

格

22) ISO26262: IEC61508 をベースとした自動車用の機能安全規格で現在審議中である。

23) ISO/IEC 9126-1: ソフトウェア品質の評価に関する国際規格 ISO 9126 で規定され

ている品質モデル

24) ISO/IEC 9126-4: ソフトウェア品質の評価に関する国際規格 ISO 9126 で規定され

ている利用時品質測定法

25) ITS: 情報技術を用いて人と自動車と道路を結び、交通事故や渋滞などの道路交通問

題の解決をはかる新しい交通システム。Intelligent Transport System

26) JASPAR: 日本国内の自動車メーカやサプライヤを中心とする日本自動車業界初のコ

ンソーシアム。Japan Automotive Software Platform and Architecture

27) LIN: 制御系車内 LAN インタフェース規格の1つ。Local Interconnect Network

28) MCAL: AUTOSAR ソフトウェア・アーキテクチャに対応したデバイスドライバ。

Microcontroller Abstraction Layer

29) OEM: 製造企業。本書の中では「自動車メーカ」を意味している。Original Equipment

Manufacturer

30) RTE: AUTOSAR ソフトウェア・アーキテクチャで規定されたソフトウェアコンポ

ーネント(SW-C)と BSW 層を結ぶインタフェース層。Run Time Environment

31) SEC: エンタープライズ系ソフトウェアと組込みソフトウェアの開発力強化のため

に独立行政法人情報処理推進機構(IPA)内に設立されたソフトウェア・エンジニア

リング・センター

32) Simulink: The MathWorks 社によって開発された、モデリング、シミュレーショ

ン、解析のためのマルチドメインシミュレーション、およびダイナミックシステム

33) SRA: 「欧州テクノロジー・プラットフォーム(ETP、European Technology

Platform)」における戦略研究計画

34) SW-C: AUTOSAR で扱うソフトウェアの単位。ソフトウェアコンポーネント

35) Tier1: 本書の中では「サプライヤ」を意味している。

1.4 謝辞

本事業を行うにあたり、独立行政法人情報処理推進機構ソフトウェア・エンジニアリン

グ・センターの研究員の方々に多大なるご協力をいただいた。

ここに記して、深く謝意を捧げる次第である。

2. 背景

現在、自動車における電子部品(車載電子制御システム)のコスト割合は車両原価の 20%

~31%を占めるようになっている(図 2-1)。平成 16 年の国内主要自動車メーカの自動車生

産台数は 1,428 万台(トヨタ:736 万台、日産:351 万台、ホンダ:341 万台)であるが、

自動車1台あたりの車両原価を仮に 100 万円とした場合、車載電子制御システムの市場規模

は年間約 2.8 兆円と算定される(1,428 万台 × 100 万円 × 20%)。

また、市場での普及が著しいハイブリッド・電気自動車等では更なる原価割合を占めてお

り、車載電子制御システムの市場規模は今後さらに大きくなることが予想されている。

自動車における電子部品のコスト割合

Compact Compact Car Car

Luxury Luxury Car

Car

Others

Electronics

20% 20

7

Others

図 2-1 自動車における電子部品のコスト割合

Electronics

31% 31

このような状況下において、日本の自動車産業が成長を維持継続するためには、現在日本

が強みとしている電子制御を応用した車載システムの高度化ならびに高品質化により、他国

の競合企業に対する優位性を維持することが重要であると考えられる。

特に、車載電子制御システムでは、電子制御ユニット(ECU:Electronic Control Unit)

におけるソフトウェア開発規模増加の問題が顕在化してきている。

図 2-2 に示すように 2001 年におけるソフトウェア開発規模は 1979 年に比べ、約 1,000 倍

となっており、今後も対数的に開発規模が増加していくことが予想されている。さらにこれ

に伴う複雑化の問題も顕在化してきている。そのため、開発効率化、品質向上に向けた取り

組みは、重要な課題となっている。

Software volume

(lines of “C” source code)

100M

10M

1M

100K

10K

1K

Approx. 2K lines

in 1979

Approx. 2M lines

in 2001

Whole vehicle

1980 1985 1990 1995 2000 2005 (year)

図 2-2 電子制御ユニットにおけるソフトウェア開発規模の推移

この開発効率化、品質向上に向けた取り組みとして、自動車用制御基盤ソフトウェアの標

準化の動きが活発化してきているが、この標準化においては欧州でのコンソーシアム活動

AUTOSAR(Automotive Open System Architecture)が先行している。

さらに、現在 AUTOSAR で検討されている自動車用制御基盤ソフトウェアを実装した場

合、国内製マイコンでは十分な性能を得ることはできない可能性が高い。このまま欧州主導

で自動車用制御基盤ソフトウェアが検討・国際標準化された場合、性能、品質両面で優位な

国内製マイコンにおける性能面での優位性低下が懸念される。

また、組込みソフトウェアを取り巻く環境が弱体であり、例えば、ソフトウェアの要求仕

様記述に関する標準的な図面がなく性能品質に関する定量的な議論ができない、ソフトウェ

ア技術者の市場流通が進まないなどといった問題が生じており、規格化に向けた素案作りが

必要となっている。

8

Driving system

3. 欧州の活動状況

現在、欧州における車載電子制御システムのソフトウェアにおける標準化の活動は、自動

車メーカ、サプライヤを中心とするコンソーシアム AUTOSAR が設立され、活動中である。

また、車載電子制御システムの通信分野における標準化についても同様にコンソーシアム

FlexRay が設立され、活動中である。

これらのコンソーシアム活動は、欧州連合(EU)予算で、前身となる基礎研究活動

(EAST-EEA 等)が実施されてきており、活動成果は国際標準化機構 ISO(International

Organization for Standardization)へ提案される可能性が極めて高いと考えられる。既に、

車載リアルタイム OS の標準化活動成果である OSEK/VDX 仕様(OSEK はドイツ語の"

Offene Systeme und deren schnittstellen fur die Elektronik im Kraftfahrzeug"であり、

VDX は" Vehicle Distributed eXecutive"の略である)は、車載 OS として ISO に提案された

前例がある。

しかしながら、これらの仕様および規格は、従来日本の自動車メーカやサプライヤが培っ

てきた開発プロセス、性能・品質確保の面において、必ずしも日本の自動車メーカの要求を

満たすものではない。今後これらの活動成果が欧州主導で ISO へ提案された場合、日本とし

ては開発の柔軟性を失い、日本の強みである性能・品質面で優位性を確保することが難しく

なることが予想される。

また、欧州では、標準化が進んでいるため、ETAS、ELEKTROBIT、Vector、DECOMSYS

社など、比較的小規模の自動車用ソフトウェアメーカがビジネスとして成立し、かつコンソ

ーシアム活動に早期から参加して開発を先行してきたため、現在は寡占状態となっている。

しかし、日本では自動車メーカ各社がそれぞれ異なる要求を出すことが多く、小規模なソ

フトウェアメーカは手を出しにくい状況となっており、結果として車載ソフトウェアの開発

は、自動車電装部品メーカしか対応できていないのが現状である。

そのため、現状のままでは、日本の自動車メーカの性能・品質要求を満たす標準化基盤ソ

フトウェアや関連ツールをタイムリに入手できなくなるリスクがある。したがって、日本国

内において自動車用制御基盤ソフトウェアへの要求を標準化することで、日本の強みを生か

した組込みソフトウェアのリソーセスを活用する仕組みを構築する必要があり、また、日本

における評価基準を規定し、評価することは、日本の自動車産業の優位性を保つ上でメリッ

トが大きい。

一方、国際安全規格である機能安全(functional safety)については、欧州の自動車メー

カ主導にて規格「IEC 61508」をベースにし、自動車分野向けに規格「ISO 26262」として

2009 年 7 月に国際規格(案)(DIS(Draft International Standard))が公開されており、

2010 年 6 月に国際規格(IS(International Standard))として発行される見込みである。

現在、国内では社団法人自動車技術会を中心として内容の検討が行われているが、これら

の活動と連携し、車載電子制御システム開発において不利益が生じないように検討および対

応を実施していく必要がある。

4. 本事業の目的

日本では、国内の自動車メーカやサプライヤを中心とする日本自動車業界初のコンソーシ

アムである JASPAR(Japan Automotive Software Platform and Architecture)を 2004 年

9 月に設立し、技術検討と標準化活動を実施している。

JASPAR では、車載電子制御システムのうち、共通基盤領域である、

①基盤ソフトウェア(JASPAR ソフトウェアワーキンググループ)

②車載通信プロトコル(JASPAR 車載 LAN ワーキンググループ)

③マイコン(JASPAR マイコンワーキンググループ)

などの活動を実施している。

近年、ソフトウェアは製造業やサービス業をはじめとしたあらゆる産業の競争力の源泉と

なっているが、他方で開発規模の増大や開発コストの増加の問題が顕在化し、ソフトウェア

の信頼性および生産性が重要な課題となってきている。特に、従来、日本のものづくりの強

みを活かしてきた組込みソフトウェアについては、その効率性向上による高信頼性確保に対

する関心が高まっている。

そこで、本事業では、高信頼なソフトウェア開発手法を実証・評価を行うため、自動車用

制御基盤ソフトウェアの開発およびその開発環境の整備を行う。また、ソフトウェアエンジ

ニアリングの確立、それに基づくソフトウェアおよびツールの開発により、自動車産業およ

び組込みソフトウェア産業などの競争力強化を図る。

5. 本事業の実施内容

前章 4 の目的を達成するために実施する内容を以下の 5.1 節、5.2 節、5.3 節、そして 5.4

節に示す。

ここで、本事業は平成 19~21 年度(2007~2009 年度)の3カ年で活動をおこなっている

ため、記載されている実施内容は、平成 19 年度および平成 20 年度の活動結果を踏まえて、

今年度(平成 21 年度)に実施したものである。

5.1 自動車用制御基盤ソフトウェアの仕様策定と実装評価

平成 20 年度にて実施した、リアルタイム制約を満足し、かつ高信頼性を確保した自動車

用制御基盤ソフトウェアの仕様策定、実装について、検証および評価を行い、その結果をフ

ィードバックし、仕様改良を実施する。

具体的な実施内容は以下の通りである。

(a) JASPAR BSW 実装については、最適かつ効率的な仕様とし、アダプテーション層、ミ

ドルウェア層、カーネル層について、それぞれ以下の開発を行う。

・アダプテーション層:RTE(Run Time Environment)インタフェース

・ミドルウェア層:ミドルウェア API、通信スタック

・カーネル層:カーネル API、リアルタイム OS、低レベルドライバ(マイコンドライ

バ(MCAL(Microcontroller Abstraction layer)と呼ぶこともある)、通信ドライバ、

I/O ドライバ)。

なお、各層のソフトウェア開発を支援するジェネレータツールも開発する。

(b) また、平成 20 年度より引き続きスキル面にも着目し、組込みスキル標準 ETSS *1

(Embedded Technology Skill Standards)に基づき、平成 20 年度に策定した自動車用

制御基盤ソフトウェア開発エンジニア向けのプロファイルにより、開発力を客観的に評

価するためのデータを取得する。

Reference)を基に開発プロセスを定義し、実施結果をまとめる。

(d) JASPAR BSW 実装の評価に当たっては、以下の ISO/IEC9126-1 品質 6 特性に基づく

評価項目を規定する。

・品質 6 特性:機能性、信頼性、使用性、効率性、保守性、移植性

(e) 上記(b)、(c)、(d)に沿った評価を実施し、評価結果を分析し、まとめる。

(f) 評価結果に基づく、基盤ソフトウェアの仕様の策定を行う。

(g) 策定した基盤ソフトウェア仕様に基づき、AUTOSAR への提案を想定した仕様改良案

をまとめる。

(h) 自動車の機能安全実現に向け、｢マイコンの故障検出性およびその仕様化の検討｣を行

う。

*1 独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センターの成果物

5.2 開発環境・ツールの仕様策定と実装評価

平成 20 年度にて実施した自動車用電子制御システムのソフトウェア開発に適したツール

の要件検討、仕様策定、プロトタイプ開発の結果を用いて、ソフトウェア開発の実証・評価

を行う。

具体的な実施内容は以下の通りである。

(a) 平成 20 年度に実施した自動車用制御基盤ソフトウェアに対応するソフトウェアの設

計/検証に必要なツール群を統合し、自動車用ソフトウェア開発プロセスに従った一連

の作業を統一環境で行える統合開発環境フレームワークの要件策定と仕様定義、および

プロトタイプについて、検証と評価を行う。

(b) 上述の基盤ソフトウェアを用いたソフトウェア開発を支援するソフトウェア設計ツー

ル/実装ツールについて、実車に搭載する JASPAR BSW 開発に適用して、検証と評価

を行う。

・検証と評価を行うツール:システム設計ツール、ソフトウェア設計ツール、各種コ

ンフィグレータ

ISO/IEC 9126-4 に基づく評価基準を用い、評価した結果を各仕様に反映する。

・評価基準策定対象ツール:統合開発環境フレームワーク、システム設計ツール、ソ

フトウェア設計ツール

5.3 プロセス実証

平成 20 年度より引き続き、自動車用電子制御システム開発に適したプロセスの定義・評

価を行う。具体的には、AUTOSAR 仕様、そして独立行政法人情報処理推進機構ソフトウ

ェア・エンジニアリング・センター(以下、SEC とする)成果の適用と評価により、システ

ム仕様記述の体系化および実現性の検証を行う。また、評価に関しては、前節 5.1 の JASPAR

BSW 開発を通じてデータを収集し、分析・評価を実施する。また、プロセスを管理・評価

するためのツール環境も整備する。

具体的な実施内容は以下の通りである。

(a) プロジェクト可視化に効果的と言われている EPM *1(Empirical Project Monitor)に

ついては、プラットフォーム開発における EPM ツールの要件定義と EPM-ETSS クロ

ス分析とフィードバックを行う。

(b) スキル面については、前節 5.1 の(b)で取得したデータと、平成 19 年度、平成 20 年度

に取得したデータを活用し、自動車用ソフトウェア開発エンジニアの開発力を客観的に

評価、これまでの総括および継続的なスキル診断・分析を行う。これにより JASPAR 版

ETSS を完成させ、運用マニュアルを策定する。また、スキルと進捗・成果物との相関

分析と、開発過程へのフィードバックを行う。

調査を実施し、実現性における課題の明確化・技術検討を実施し、システム仕様記述の

策定・体系化および妥当性の検証を行う。

(d) ESPR については、前節 5.1 の(c)の結果を用い、有効性の検証を行う。

*1 独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センターの成果物

5.4 実機適用に向けた実証

平成20 年度に実施した 5.1 節、5.2 節、そして 5.3 節の成果物に対する基盤ソフトウェア

の評価用ソフトウェア(下記①、②、③)を試作、検証を受けて、JASPAR BSW およびそ

れを開発するためのツールの適用について、実車搭載による実証、評価を行う。

①安全制御系

②ステアリング系制御

③ITS(Intelligent Transport System)系制御

6. 本事業の実施体制

本章では、前章の 5.1 節、5.2 節、5.3 節、そして 5.4 節に記載した4つの内容を実施する

体制について説明する。

経済産業省の公募委託事業「平成 19 年度産業技術研究開発委託費(産学連携ソフトウェ

ア工学実践事業(高信頼組込みソフトウェア開発))」の採択を受け、JASPAR 内に新しいワ

ーキンググループ「国プロ推進ワーキンググループ(以下、「国プロ推進 WG」)」を平成 19

年 4 月に発足させた。また、国プロ推進 WG 配下に3つのタスクフォース(以下、「TF」)

を同時に発足させた。

また、平成 20 年度より、前章の 5.4 節「実機適用に向けた実証」の活動を追加したため、

平成 20 年 4 月、国プロ推進 WG 配下に3つのチームを新たに発足させた。

国プロ推進 WG とその配下に設置された3つの TF、3つのチームの体制を、図 6-1 に示

す。

標準実装TF

リーダ: 岩井(デンソー)

サブリーダ: 井野(日産)

仕様グループ

実装グループ

評価グループ

主査: 安達(日産)

副主査: 佐藤(トヨタ)

JASPAR BSW仕様の策定

アーキテクチャチーム

ミドルウェアチーム

カーネルチーム

JASPAR BSWの実装

(ジェネレータ含む)

JASPAR BSWの評価

JASPAR運営委員会

国プロ推進WG

開発ツールTF

リーダ: 橋本(ホンダ)

サブリーダ: 佐藤(トヨタ)

仕様グループ

実装グループ

管理グループ豊通エレ、ガイア

アーキテクチャチーム

システム設計ツールチーム

ソフトウェア設計ツールチーム

17

JASPARツール仕様の策定

ソフトウェア検証ツールチーム

JASPARツールの実装

評価グループ JASPARツールの評価

ブリッジSE

プロセスTF

評価用ソフトチーム

安全制御系

評価用ソフトチーム

ステアリング系制御

評価用ソフトチーム

ITS系制御

リーダ: 城戸(トヨタ) リーダ: 加藤(日産) リーダ: 橋本(ホンダ)

図 6-1 JASPAR 国プロ推進 WG の体制

ガイア

※技術管理・技術事務

リーダ: 石井(トヨタ)

リーダ代行: 佐藤(トヨタ)

サブリーダ: 菅沼(デンソー)

システム仕様記述小委員会

システム仕様記述方法の定義、

およびツール要件の定義

ETSS小委員会

ETSSプロファイルの策定と評価

①自動車用制御基盤ソフトウェア

開発エンジニア向けプロファイル

②ツール開発エンジニア向け

プロファイル

EPM小委員会

EPM仕様の策定、および

ツール要件の定義

ESPR/ESMRの適用と評価

また、各 TF、各チームと前章 5 に記載した実施内容の対応関係を、表 6-1 にまとめて示

す。

表 6-1 各TF、各チームと実施内容の対応関係

TF 名、チーム名実施内容

標準実装 TF 自動車用制御基盤ソフトウェアの仕様策定と実装

評価

開発ツール TF 開発環境・ツールの仕様策定と実装評価

プロセス TF プロセス実証

評価用ソフトチーム(安全制御系) 実機適用に向けた実証 ①安全制御系

評価用ソフトチーム(ステアリング

系制御)

実機適用に向けた実証 ②ステアリング系制御

評価用ソフトチーム(ITS 系制御) 実機適用に向けた実証 ③ITS 系制御

次に、各 TF の体制を以下に示す(図 6-2、図 6-3、図 6-4)。

TFリーダ: デンソー岩井

TFサブリーダ: 日産井野

グループ名グループ名

仕様グループ

実装グループ

評価グループ

グループ名グループ名

仕様グループ

実装グループ

評価グループ

主なタスク

必要機能・API分

析

仕様策定(要件レ

ベル) ベル)

実装グループか

らの質問対応

仕様策定代行

プロトタイプ開発

評価代行

評価基準、評価

仕様策定、評価プ

ログラム作成

評価結果分析・ま

とめ

TFリーダ: ホンダ橋本

TFサブリーダ: トヨタ佐藤

主な活動内容

必要機能・要求分析

要件策定

実装グループからの

質問対応

プロセスTFとの連携

仕様策定

プロトタイプ開発

評価代行

評価基準、評価仕様

策定、評価プログラ

ム作成

評価結果分析・まと

め

チーム名チーム名

アーキテクチャチーム

ミドルウェアチーム

カーネルチーム

チームリーダ

デンソー岩井

日産松尾

NECエレ松井

グループリーダ: グループリーダ: ヴィッツ片岡

ヴィッツ、eSOL、永和、未来、OTSL、サニー、アックス

グループリーダ: グループリーダ: 日産井野

日産、トヨタ、ホンダ、デンソー、日立ICS、エレシス

19

サブリーダ

日産井野

デンソー岩井

ルネサス林

図 6-2 標準実装 TF の体制

チーム名チーム名

アーキテクチャ

チーム

システム設計ツー

ルチーム

ソフトウェア設計

ツールチーム

ソフトウェア検証

ツールチーム

チームリーダ

ホンダ橋本

CV 平鍋

ADaC 河原

YDC 穂山

グループリーダ:CV 平鍋

CV、ADaC、YDC、 eSOL、ガイオ

サブリーダ

デンソー佐藤

eSOL 織田

ガイオ速水

グループリーダ: グループリーダ: 日産井野

日産、トヨタ、ホンダ、デンソー、日立ICS、エレシス、CV

図 6-3 開発ツール TF の体制

メンバ

日産、日立ICS、トヨタ、デンソー、

ホンダ、エレシス、NECエレ

日産、CK、ホンダ、NS、デンソー、

eSOL、OTSL、サニー、NECエレ、

ルネサス

ヴィッツ、アックス、

NECエレ、ルネサス、富士通

トヨタ、日産、ホンダ、デンソー、

CV、キャッツ

トヨタ、日産、ホンダ、デンソー、

CV

ADaC、YDC 、eSOL、NECエレ、

、eSOL、NECエレ、

ルネサス、富士通

YDC、ガイオ

メンバ

TFリーダ: トヨタ石井リーダ代行: トヨタ佐藤

TFサブリーダ: デンソー菅沼

名称

システム

仕様記述

小委員会

ETSS

小委員会

EPM

小委員会

目的・活動項目

システム仕様記述デンソー菅沼

方法の定義、および、

ツール要件の定義

ETSSプロファイルの

策定・試行

EPM仕様の策定、お

よびツール要件の

定義

リーダ・サブリーダ

デンソー菅沼

トヨタ佐藤

キャッツ村上

●アドバイザー(※敬称略)

独立行政法人情報処理推進機構

ソフトウェア・エンジニアリング・センター

JARI(財団法人日本自動車研究所)

アイシン精機株式会社鈴村延保

図 6-4 プロセス TF の体制

20

■開発ツールTF

ホンダ、デンソー、CV、ガイオ

■プロセスTF

トヨタ、日産、ホンダ、マツダ、デンソー、

キャッツ、CV、FSI、ガイア

日産、ホンダ、マツダ、デンソー、

ガイア、キャッツ

SEC

トヨタ、デンソー、ガイア

SEC

主査門田浩

藤原由起子

メンバ

副主査田丸喜一郎

室修治

菊地奈穂美

神谷芳樹

大野克己

樋口登

なお、図 6-1、図 6-2、図 6-3 および図 6-4 に記載されている会社名は略称である。略称

と正式名称の対応関係を表 6-2 に示す。

表 6-2 体制図における参加企業の略称と正式名称の対応表

No 略称正式名称本社所在地 URL

JASPAR 幹事会社ならびに JASPAR 正会員企業

1 日産日産自動車株式会社〒220-8686 神奈川県横浜市西区高島 1 丁目

1 番 1 号

http://www.nissan.co.jp/

2 トヨタトヨタ自動車株式会社〒471-8572 愛知県豊田市トヨタ町 1 番地 http://www.toyota.co.jp/

3 ホンダ

4 デンソー

5 マツダ

株式会社本田技術研究所〒351-0113 埼玉県和光市中央 1-4-1 http://www.honda.co.jp/RandD/

株式会社デンソー〒448-8661 愛知県刈谷市昭和町 1-1 http://www.denso.co.jp/

マツダ株式会社〒730-8670 広島県安芸郡府中町新地 3-1 http://www.mazda.co.jp/

6 日立 ICS 株式会社日立情報制御ソリ〒319-1221 茨城県日立市大みか町五丁目 1 http://www.hitachi-ics.co.jp/

ューションズ

番 26 号

7 CK カルソニックカンセイ株式〒331-0823 埼玉県さいたま市北区日進町二 http://www.calsonickansei.co.jp/

会社

丁目 1917 番地

8 エレシス株式会社ホンダエレシス〒240-0005 神奈川県横浜市保土ヶ谷区神戸

町 134 番地横浜ビジネスパー

クハイテクセンター

http://www.elesys.co.jp/

9 NS 日本精機株式会社〒940-8580 新潟県長岡市東蔵王 2-2-34 http://www.nippon-seiki.co.jp/

10 NEC エレ NEC エレクトロニクス株式

会社

11 富士通富士通マイクロエレクトロ

ニクス株式会社

〒211-8668 神奈川県川崎市中原区下沼部

1753

〒222-0033 神奈川県横浜市港北区新横浜ニ

丁目 10番23 野村不動産新横浜

ビル

21

http://www.necel.com/

http://jp.fujitsu.com/microelectronics/fml/

No 略称正式名称本社所在地 URL

12 ルネサス株式会社ルネサステクノ〒100-0004 東京都千代田区大手町 2-6-2 日

ロジ

本ビル

13 アックス株式会社アックス〒604-0857 京都府京都市中京区烏丸通二条

上ル蒔絵屋町 280 番地マニュ

ライフプレイス京都 8F

14 ADaC 株式会社アドバンスドデー〒170-0004 東京都豊島区北大塚1丁目 13

タコントロールズ

番 4 号日本生命大塚ビル

15 eSOL イーソル株式会社〒164-8721 東京都中野区本町 1-32-2 ハー

モニータワー

16 ヴィッツ株式会社ヴィッツ〒460-0008 愛知県名古屋市中区栄 2-13-1

白川第 2 ビル

17 永和株式会社永和システムマネ〒918-8231 福井県福井市問屋町 3 丁目 111

ジメント

番地

18 OTSL 株式会社 OTSL 〒460-0002 愛知県名古屋市中区丸の内

3-6-41 Liv ビル 7F

19 ガイア株式会社ガイア・システ〒141-0022 東京都品川区東五反田 3-14-13

ム・ソリューション

高輪ミューズビル

20 ガイオガイオ・テクノロジー株式会〒221-0052 神奈川県横浜市神奈川区栄町

社

5-1 横浜クリエーションスクエ

ア 4F

21 キャッツキャッツ株式会社

〒222-0033 神奈川県横浜市港北区新横浜

2-11-5 川浅ビル

22 サニー

22

http://japan.renesas.com/

http://www.axe-inc.co.jp/

http://www.adac.co.jp/

http://www.esol.co.jp/

http://www.witz-inc.co.jp/

http://www.esm.co.jp/

http://www.otsl.jp/

http://www.gaiaweb.co.jp/

http://www.gaio.co.jp/

http://www.zipc.com/

株式会社サニー技研〒664-0858 兵庫県伊丹市西台 3-1-9 http://www.sunnygiken.co.jp/

23 CV 株式会社チェンジビジョン〒110-0005 東京都台東区上野 2-7-7 上野

HS ビル 8 階

http://www.change-vision.com/

24 FSI 富士ソフト株式会社〒231-8008 神奈川県横浜市中区桜木町 1-1 http://www.fsi.co.jp/

No 略称正式名称本社所在地 URL

25 未来

株式会社未来技術研究所〒460-0007 愛知県名古屋市中区新栄 3-3-2 http://www.ftl.co.jp/

26 YDC 横河ディジタルコンピュー

タ株式会社

事務局(JASPAR 事務局、WG 事務局の順)

1 豊通エレ株式会社豊通エレクトロニ

クス

2 ガイア株式会社ガイア・システ

ム・ソリューション

〒180-8750 東京都武蔵野市中町 2 丁目 9 番

32 号

〒451-6033 愛知県名古屋市西区牛島町 6-1

名古屋ルーセントタワー33F

〒141-0022 東京都品川区東五反田 3-14-13

高輪ミューズビル

23

http://www.yokogawa-digital.com/

http://www.toyotsu-electronics.co.jp/

http://www.gaiaweb.co.jp/

7. 本事業の’09 年度活動の概要と結果

7.1 自動車用制御基盤ソフトウェアの仕様策定と実装評価

7.1.1 3カ年計画

標準実装 TF の3カ年計画は以下のとおりである。

� 2007 年度(平成 19 年度):環境整備

AUTOSAR BSW 仕様分析、プロトタイプ実装・評価

JASPAR BSW 要件定義

開発体制・環境構築

� 2008 年度(平成 20 年度):開発

JASPAR BSW 仕様策定

JASPAR BSW 実装・評価

� 2009 年度(平成 21 年度):検証

JASPAR BSW 検証・評価

JASPAR BSW 仕様へのフィードバック

また、上記の計画におけるスケジュールを図 7-1 に示す。

全体日程

マイルストーン

BSW仕様

BSW実装

BSW評価

担当

仕様グループ

実装グループ

評価グループ

Q1

2007年度

図 7-1 標準実装 TF 3カ年計画スケジュール

24

2008年度 2009年度

Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

環境整備フェーズ開発フェーズ検証フェーズ

評価レポート

要求分析仕様検討

設計・実装単体評価

評価仕様インテグ評価

評価レポート評価レポート

JASPAR BSW要件定義 JASPAR BSW仕様策定 JASPAR BSW仕様検証

ドラフト版

AUTOSAR BSWプロトタイプ実装

AUTOSAR BSW評価

プロト版

JASPAR BSW開発

設計・実装

評価システム構築

β版

見直し見直し

β版

JASPAR BSW評価

見直し

JASPAR BSW評価(単体) JASPAR BSW評価(統合)

システム統合評価

V1.0

レポートレポートレポート

7.1.2 ’09 年度の活動スケジュール

標準実装 TF の’09 年度活動スケジュールを図 7-2 に示す。

大きく3つのフェーズに分けており、4月から9月に JASPAR BSW の検証、10 月から

12 月に JAPSAR BSW の改良を行い、1月から3月にまとめを実施する。

全体日程

マイルストーン

BSW

仕様策定

仕様グループ

BSW実装

BSW評価

25

’09年度

担当 4 5 6 7 8 9 10 11 12 1 2 3 4

アーキテクチャ

チーム

ミドルウェア

チーム

カーネル

チーム

実装グループ

評価グループ

検証フェーズ

アーキテクチャ仕様見直し

RTE仕様見直し

ミドルウェア仕様見直し

カーネル仕様見直し

インテグ評価

仕様書ドラフト3

評価レポート(中間)

改良フェーズ

見直し

相互接続評価

仕様書V1.0

評価レポート(最終)

まとめフェーズ

まとめ

α版(機能限定)

β版正式版

JASPAR BSW改良&他マイコン対応

見直しまとめ

ドキュメント整備

見直しまとめ

図 7-2 ’09 年度標準実装 TF 活動スケジュール

まとめ

事業報告書

7.1.3 活動概要1-JASPAR BSW 仕様について

今年度(’09 年度)は、’08 年度に実施した JASPAR BSW 仕様策定、JASPAR BSW 実装・

評価の活動結果を踏まえ、JASPAR BSW の検証・評価と JASPAR BSW 仕様へのフィード

バックを実施した。

JASPAR BSW 検証・評価の活動概要については次節 7.1.4 で述べることとし、ここでは

3カ年の活動にて策定・フィードバックを行ってきた JASPAR BSW 仕様の根幹となってい

る以下の2点について要点をまとめる。

・JASPAR BSW プロファイルコンセプト

・JASPAR ソフトウェア・アーキテクチャ

(1) JASPAR BSW プロファイルコンセプト

’08 年度は、’07 年度にまとめた JASPAR BSW 仕様の策定に必要となる上位コンセプトお

よび要件定義をもとに、JASPAR BSW 仕様策定を実施した。

以下、’07 年度、’08 年度からの再掲も含まれるが、JASPAR BSW 仕様策定のための全体

的な考え方を示す。

a JASPAR BSW プロファイルコンセプトの導入

’07年度に実施したAUTOSAR BSWの仕様分析、プロトタイプ実装・評価より、

AUTOSAR BSWは、実開発・実運用に当たっては、様々な課題があることが判明した。

これらの課題を解決するため、JASPAR BSWにおいては、プロファイルという概念を提

案するに至った。

JASPAR BSWプロファイルとは、「満艦飾のAUTOSAR仕様より、実ECUに必要な機

能を絞り込んだ機能サブセット」である。

例えば、AUTOSAR仕様は、CAN通信、FlexRay通信、LIN通信等の通信仕様、OS仕様、

メモリ管理、MCAL仕様、システム管理等の仕様で構成されるが、実ECUに実装される仕

様は、全て必要とは限らない。AUTOSARの思想では、それらの選択は、ECUの実装者に

任されるが、多数の機能、膨大なコンフィグデータの中から、実装者にとって最適な機能・

コンフィグデータの組み合わせを選び出すことは非常に困難となっている。

そこで、JASPAR BSW プロファイルでは、予め Profile-A は、{機能 1、機能 2、機能 3、

機能 4、機能 5}、Profile-B は、{機能 1、機能 2、機能 3}、Profile-C は、{機能 1}のみとい

った具合に仕様作成側で定義をしておくことで、ECU の実装者にとって最適な仕様を提

供する事を狙いとしている(図 7-3 参照)。

プロファイル

通信仕様

-CA N

-Fle xRay

-LIN

-PD URouter

OS仕様

-メモリ保護

-タイミング保護

機能1

○

機能4 機能3

×

メモリ管理

MCAL仕様

システム管理

-ECUStateManager

-Lib.....

○

機能2

機能1

機能2

機能3

機能4

機能5

図 7-3 JASPAR BSW プロファイル

27

:

機能選択イメージテーブル

Profile-A

○

Profile-B

○

Profile-C

○

JAPSAR BSW プロファイルの狙い

JASPAR BSW プロファイルの狙いは、ECU の実装者にとって最適な仕様を提供する事

にあるが、具体的には以下の3つになる。

1) 性能の向上

冗長な仕様を削除することで「消費リソース削減」と「パフォーマンス向上」を実

現する。

2) コンフィグ作業の効率化

膨大なパラメータ設定作業をプロファイルに応じたテンプレートファイル提供で効

率化する。

3) 再利用の促進

実 ECU に最適化された仕様により再利用しやすくする。

c JASPAR BSW プロファイルの位置づけ

JASPAR BSW プロファイルは、実運用・実開発に適した標準化を推進していくといっ

た JASPAR の上位ビジョンに基づいた考え方であり解決策である。

さらに、このプロファイルに基づき各モジュール毎の必要機能・API を選定する。

よって、JASPAR BSW プロファイルは、上位ビジョンと要求仕様の中間に位置づけら

れ、全ての JASPAR BSW 仕様の考え方のベースとなる(図 7-4 参照)。

JASPAR

ビジョン

JASPAR

BSWプロファイル

JasPar JASPAR BSW BSW

要求仕様

実運用・実開発に適した標準化を推進

実ECUに最適な機能サブセットの定義

各モジュール毎の必要機能・API を選定

図 7-4 JASPAR BSW プロファイルの位置づけ

d 本プロファイリングに用いる二つのアプローチ

次に、この考え方に基づき、実際にどうやって具体的にプロファイリング(プロファイ

ルを実施すること)するかの検討を、’07 年度に標準実装 TF のメンバにて実施した。

しかし、本 TF に参画するステークホルダは異なる立場、異なる考え方を持っているた

め、統一したプロファイルにすることが困難であった。

例えば、自動車メーカの視点、サプライヤの視点、半導体メーカの視点、そして、ソフ

トウェアメーカの視点は、お互いに異なっている。

そこで、大きく自動車メーカ視点とサプライヤ視点に分類し、以下の2つのアプローチ

で整理することとした(図 7-5 参照)。

1) 対象ドメインアプローチ

①要求領域である適用対象アプリケーションドメインのニーズより、必要な機能をプ

ロファイリングするアプローチ

②トップダウン

③自動車メーカ視点

④RTE、上位サービス層

具体的には、AUTOSAR のアプリケーションドメイン分類を参考し、以下の4つの

ドメインに分類した。

ⅰ) Body and Comfort

ⅱ) Powertrain

ⅲ) Chassis Control

ⅳ) Safety Systems

その際、Infotainment は当面対象外とした。

2) ECU アプローチ

①実現領域である ECU、マイコン、通信等のシーズより、必要な機能をプロファイ

リングするアプローチ

②ボトムアップ

③サプライヤ視点

④ECU 抽象化層、マイコン抽象化層、OS

ECU 規模・性能は、使用するマイコンの性能に大きく依存するため、以下、3つ

のクラスのマイコンを想定した分類とした。

ⅰ) 16 ビット、32 ビットローエンド(for Small ECU)

ⅱ) 32 ビットミドルクラス(for Medium ECU)

ⅲ) 32 ビットハイエンド(for Large ECU)

OEM

要求領域

対象ドメイン

Services Layer

実現領域

App lication Layer

Microcontroller

図 7-5 プロファイリングのアプローチ

31

ECU規模

ドメインアプローチ

AUTOS AR Runtime Environment (RTE)

ECU Abstr action Layer

M icrocontr oller Abstraction Layer

ECUアプローチ

双方向

Co

mp

lex

Dr i

ver

s

Supplier

Functionality level(ECU Size)

e JASPAR BSW プロファイルイメージ

以上、対象ドメインアプローチと ECU アプローチより、下図のように JASPAR BSW

プロファイルのイメージをまとめた。

Large set

Small set Medium set

Class-LB Class-LP Class-LC

④安全制御系

プロファイル

Class-LS

②パワトレ制御系 ③シャシー制御系

プロファイルプロファイル

Class-MB Class-MP Class-MC Class-MS

①ボディ制御系

プロファイル

Class-SB Class-SP Class-SC Class-SS

Body and Comfort Powertrain Chassis Control Safety Systems

Application Domain

図 7-6 BSW プロファイルイメージ

32

※Infotainmentは当面対象外とする

4ドメイン×3機能レベル(ECU サイズ)で 12 クラスに分割し、実運用を考え、代表

クラスのみ対象とすることとした。

f 具体的な JASPAR BSW プロファイル

さらに、上述のイメージを具体的な ECU、マイコン、通信バスを想定したプロファイ

ルにまとめた。その際、JASPAR 内の車載 LAN ワーキンググループで検討を進めている

RTB(Real Time Bus)、FTB(Fault Tolerant Bus)等の通信バス構成への対応づけもふ

まえ、通信プロファイルという別のプロファイルに切り出してまとめることとした。

具体的な JASPAR BSW プロファイルを表 7-1 に示す。

プロファイル

想定ECU例

想定マイコン

通信バス

(参考)

対応通信プ

ロファイル

表 7-1 具体的な JAPSAR BSW プロファイル

ボディ制御系

プロファイル

(Body and

Comfort)

A/C、灯火

ドアコン

エアバッグ

16ビット

32ビットローエ

ンド

MS-CAN、LIN

CAN Only

パワトレ制御系

プロファイル

(Powertrain)

エンジン

トランスミッション

32ビットミドルク

ラス

HS-CAN、

FlexRay-RTB

CAN-FlexRay

GW

33

シャシー系

プロファイル

(Chassis

Control)

ABS

ESP

32ビットミドルク

ラス

HS-CAN、

FlexRay-RTB

FlexRay Only

(RTB)

A/C: Air Conditioner。エアコン。

ABS: Antilock Brake System。アンチロック・ブレーキ・システム。

ESP: Electronic Stability Program。横滑り防止装置。

MS-CAN: Middle Speed CAN。中速CAN。

HS-CAN: High Speed CAN。高速CAN。

GW: Gateway。ゲートウェイ。

安全制御系

プロファイル

(Safety

Systems)

X-by-Wire系

ECU

32ビットハイエン

ド

FlexRay-FTB

FlexRay Only

(FTB)

g プロファイリングする対象機能と進め方

AUTOSARが対象とする機能は、ECUで必要な全機能に渡るため、非常に範囲が広い。

そのため、「JASPAR BSWプロファイルで対象とする機能がどこまでなのか」を検討し

た。また、二つのアプローチの進め方も標準実装TFのメンバで議論を行い、以下の結論と

した。

1) 対象機能に関して

AUTOSAR BSWで提供する全機能(通信、メモリ、システム、I/O)を対象とするが、

まずは、通信機能に限定して進め(通信プロファイル)、対象機能を順次OSなどに拡大

していく進め方とする。

2) 対象ドメインアプローチの進め方

自動車メーカ中心にAUTOSAR仕様から実アプリケーションに必要な機能を抽出す

る。

3) ECUアプローチの進め方

サプライヤ、ベンダ中心にAUTOSAR仕様からECU規模・性能面を考慮してリーズナ

ブルな機能を抽出する。

(2) JASPAR ソフトウェア・アーキテクチャ

a アーキテクチャ要件抽出のプロセス

JASPAR のソフトウェア・アーキテクチャを定義するに当たり、目標となるソフトウェ

ア・アーキテクチャに対しての要件を抽出した。このソフトウェア・アーキテクチャ要件

は、ソフトウェアの構造を決定するための拠り所であり、完成したアーキテクチャを評価

する際の重要な指標となる。

また、ソフトウェア・アーキテクチャ要件は、図 7-7 に示す通り、上位コンセプトより

導出される。コンセプトとは、ビジョン・取組み方針・狙いと言ったプロジェクトレベル

に至る概念である。本プロジェクトにおいては、AUTOSAR アーキテクチャをベースによ

り実開発・実運用に適したアーキテクチャを目指し、プロファイルと言うコンセプトを定

義した。つまり、このプロファイルコンセプトによって本ソフトウェア・アーキテクチャ

要件は導出される。

� ビジョン

コンセプト要件仕様

� 取組み方針

� 狙い

JASPAR ソフトウェア

アーキテクチャ要件

35

各種ソフトウェア仕様

図 7-7 アーキテクチャ要件抽出のプロセス

JASPAR ソフトウェア・アーキテクチャ要件

上述のプロセスにおいて導出された JASPAR のソフトウェア・アーキテクチャ要件を以

下に示す。プロファイルコンセプトをベースに、将来性も加味し、AUTOSAR をベースに

実運用・実開発に適したアーキテクチャ構築を目指す。

①シンプル

理解しやすい。

②高性能

階層化によるオーバヘッドが小さい。

③高い柔軟性

既存システムからの移行が容易

④スケーラブル

16 ビットボディ制御系から 32 ビットハイエンド統合制御系までサポート

⑤高い再利用性

機能単位での再利用が可能、分業がやり易い。

⑥AUTOSAR 準拠

業界標準である AUTOSAR に準拠する。

⑦将来技術への対応

マルチコアに対応可

c JASPAR ソフトウェア・アーキテクチャ

上記の要件より、JASPAR のソフトウェア・アーキテクチャを、図 7-8 のように定義し

た。

本アーキテクチャは AUTOSAR と同様、階層構造を取り、「アプリケーション層」、「ア

ダプテーション層」、「ミドルウェア層」、「カーネル層」の4つの層(レイヤ)に分割され

ている。

BSW

1) アプリケーション層

アプリケーションが配置される層である。通常、アプリケーションは、ソフトウェ

アコンポーネントで構成される。

2) アダプテーション層

アプリケーションと BSW を繋ぐ層である。通常、RTE が実装される。

3) ミドルウェア層

アプリケーション層とカーネル層の中間に位置する層であり、BSW の上位層にあ

たる。JASPAR ミドルウェアが実装される。システム管理、メモリ管理、通信サービ

ス、I/O ドライバの BSW クラスタで構成される(図 7-9)。

4) カーネル層

ソフトウェアの最下位層に位置し、BSW の下位層にあたる。JASPAR カーネルが

実装される。リアルタイム OS と低レベルドライバで構成される。

Applications

SW-C SW-C SW-C SW-C

JASPAR RTE

37

SW-C: Software Component

アプリケーション層

アダプテーション層

JASPAR Middlewares ミドルウェア層

JASPAR Kernel

ハードウェア

図 7-8 JASPAR ソフトウェア・アーキテクチャ概要

カーネル層

BSW

Applications

SW-C SW-C SW-C SW-C

システム管理

クラスタ

OS

クラスタ

CAN通信

クラスタ

JASPAR RTE

JASPAR Middlewares

メモリ管理

クラスタ

ミドルウェアAPI

JASPAR Kernel

JASPARカーネルAPI

FR通信

クラスタ

ハードウェア

通信サービス

クラスタ

AUTOSAR

MCAL

38

JASPAR

拡張MCAL

SW-C: Software Component

I/Oドライバ

クラスタ

個別

MCAL

図 7-9 JASPAR ソフトウェア・アーキテクチャ詳細

アプリケーション層

アダプテーション層

ミドルウェア層

カーネル層

また、本アーキテクチャは、AUTOSAR に比べて、機能単位での再利用性が容易なように、

大きな機能の塊(かたまり)単位でソフトウェア構造を分割していることが特徴である。こ

の機能の塊をクラスタと呼ぶこととする。

� システム管理クラスタ

ECU システムを管理するクラスタである。

� メモリ管理クラスタ

EEPROM 等の Non Volatile RAM(不揮発性メモリ、電源を切っても記憶情報が保

持される特徴を持つ)を管理するクラスタである。

� 通信サービスクラスタ

CAN 通信、FlexRay 通信、LIN 通信の通信機能を司るクラスタである。

� I/O ドライバクラスタ

センサやアクチュエータ等の I/O を制御するクラスタである。

� OS クラスタ

OS を制御するクラスタである。

� CAN 通信クラスタ

CAN 通信機能を司るクラスタである。

� FR 通信クラスタ

FR 通信機能を司るクラスタである。

7.1.4 活動概要2-JASPAR BSW 検証・評価

今年度は JASPAR BSW の検証・評価を実施した。

(1) モジュール単体評価

モジュール単体評価では、JASPAR R1.0J 仕様におけるクラスタ単体での性能面(処理速

度、リソース消費量などの効率性)について、AUTOSAR R3.0 仕様のモジュールと比較し

て評価を行った。

評価対象となる JASPAR R1.0J 仕様のクラスタと、比較対象となる AUTOSAR R3.0 仕様

のモジュールの対応を表 7-2 に示す。また、JASPAR ソフトウェア・アーキテクチャ上での

評価対象クラスタの位置づけと、AUTOSAR ソフトウェア・アーキテクチャ上での比較対象

モジュールの位置づけを図 7-10 に示す。

表 7-2 比較評価対象のモジュールおよびクラスタ対応一覧

比較対象 AUTOSAR R3.0 仕様モジュール評価対象 JASPAR R1.0J 仕様クラスタ

RTE モジュール RTE モジュール(※1)

OS モジュール OS モジュール(※1)

COM モジュール COM クラスタ

PDUR モジュール

CAN SM モジュール CAN クラスタ

CAN IF モジュール

CAN DRV モジュール

FlexRay SM モジュール FlexRay クラスタ

FlexRay IF モジュール

FlexRay Trcv モジュール

FlexRay DRV モジュール

※1 RTE および OS はモジュールとして開発を行った。このため、モジュール単体評価で

は「RTE モジュール」・「OS モジュール」と記載する。

アプリケーション層

RTE層

システムサービス層

OS

オンボード

デバイス

抽象化層

μC

ドライバ層ドライバ層ドライバ層

ハードウェア層

メモリ

サービス層サービス層サービス層

メモリ

ハードウェア

抽象化層

メモリ

ドライバ層ドライバ層ドライバ層

※FR:FlexRayの略

AUTOSARソフトウェアアーキテクチャ JASPARソフトウェアアーキテクチャ

通信サービス層

通信

ハードウェア

抽象化層

通信

ドライバ層ドライバ層ドライバ層

RTE

CAN SM

CAN IF

CAN DRV

COM

PDUR

FR SM

FR IF

FR Trcv

FR DRV

: 比較対象モジュール

40

I/O

ハード

ウェア

抽象化層

I/O

ドライバ層ドライバ層ドライバ層

Complex Drivers

アプリケーション層

アダプテーション層

ミドルウェア層

カーネル層カーネル層カーネル層

OS

ハードウェア層

図 7-10 比較評価対象のモジュールおよびクラスタ

RTE

COM

: 評価対象クラスタ

評価対象クラスタ

以下に各モジュールの評価結果に対する考察、および今後の課題を記述する。

CAN FlexRay

a RTE モジュールに対する考察

JASPAR 仕様での設計自由度向上、および、設計自由度向上に伴う実装者工夫により、

RTE モジュールは大幅な ROM/RAM 消費量の削減を実現している。

車載電子制御システムは複数の SW-C(ソフトウェア・コンポーネント)で構成される

ため、リアルタイム性を向上するためには、データを共有する SW-C をできるだけ同一

ECU 上に配置することが望ましい。このため、図に示す ECU 内連携に着目する。

ECU 内連携

Application

Software

Component

AUTOSAR

Interface

AUTOSAR Runtime Environment (RTE)

Standardized

Interface

Operating

System

Standardized

Interface

Actuator

Software

Component

AUTOSAR

Interface

Standardized

AUTOSAR

Interface

Services

Standardized

Interface

ECU-Hardware

Basic Software

図 7-11 RTE モジュール着目ポイント

SW-C が2個(最小構成)の場合と、SW-C が 64 個(最大構成)の場合をピックアップ

し、データ数と ROM/RAM 消費量の関係を図 7-12 に示す。なお、1データあたり4バイ

トのデータとする。

41

Actuator

Software

Component

AUTOSAR

Interface

Standardized

Interface

Communication

Standardized

Interface

60000

50000

40000

30000

20000

10000

ROM 消費量(byte) RAM 消費量(byte)

0

0 100 200 300 400 500 600

75%削減

AUTOSAR

R3.0[SWC=64]

AUTOSAR

R3.0[SWC=2]

JASPAR

S1[SWC=64]

JASPAR

S1[SWC=2]

図 7-12 データ数に対する ROM/RAM 消費量

ROM/RAM 共にデータ数の増加に対して同様の傾向にあり、AUTOSAR 仕様版 RTE に

比べて JASPAR 仕様版 RTE の ROM/RAM 消費量の増加がゆるやかである。

さらに、AUTOSAR 仕様版 RTE の SW-C が2個の場合と JASPAR 仕様版 RTE の SW-C

が 64 個の場合を比較する。データ数が非常に少ない場合は AUTOSAR 仕様版 RTE の方

が ROM/RAM 共に消費量は少ないが、ROM ではデータ数 10 個程度から、RAM ではデ

ータ数 40 個程度から JASPAR 仕様版 RTE の方が ROM/RAM 共に消費量は少なくなる。

データ数を 500 個程度とした場合、ROM では 75%、RAM では 50%、JASPAR 仕様版

RTE の方が ROM/RAM 消費量を削減している。

参考として、データ数1つあたりの ROM/RAM 消費量を表 7-3 に示す。

42

6000

5000

4000

3000

2000

1000

0

0 100 200 300 400 500 600

50%削減

AUTOSAR

R3.0[SWC=64]

AUTOSAR

R3.0[SWC=2]

JASPAR

S1[SWC=64]

JASPAR

S1[SWC=2]

表 7-3 1データあたりの ROM/RAM 消費量

AUTOSAR

JASPAR

104バイト

24バイト

43

ROM

RAM

8バイト

4バイト

これらのことより、JASPAR 仕様版 RTE の方が、多くの SW-C、多くのデータ数を、

より少ない ROM/RAM 消費量で実現可能である。このため、削減された ROM/RAM をア

プリケーションで利用可能となり、アプリケーションの設計自由度も向上すると考えられ

る。

これらの ROM/RAM 消費量削減は、JASPAR 仕様による設計自由度の向上、および、

設計自由度が向上したことに伴う実装者工夫によるもので、JASPAR 仕様の優位性を示す

ものである。

以上のことより、ROM/RAM 消費量の大幅な削減を実現でき、低コストマイコンへの

JASPAR 仕様版 RTE の適用が可能になった。また、JASPAR 仕様が有用であることも確

認できた。

なお、アプリケーション構成のプロファイル化をすることで、効率のよい RTE を生成

可能となり、更なる ROM/RAM 消費量の削減、および、処理速度の向上が期待できる。

今後、JASPAR 仕様として検討していきたい。

OS モジュールに対する考察

JASPAR 仕様での設計自由度向上、および、設計自由度向上に伴う実装者工夫により、

OS モジュールは大幅な処理速度の向上を実現している。

車載電子制御システム、特にリアルタイム制約を要求するシステムにおいて、OS の処

理時間は支配的であり、大幅な処理速度の改善が必要であった。OS モジュールの処理速

度向上について記載する。なお、OS の各 API における処理速度の向上は同様の傾向にあ

るため、タスク起動処理に着目する。タスク起動処理における処理速度の向上を図 7-13

に示す。

時間(μsec)

25.0

20.0

15.0

10.0

5.0

0.0

タスク起動の処理時間

AUTOSAR JASPAR

図 7-13 タスク起動処理の高速化

AUTOSAR 仕様版 OS に比べて、JASPAR 仕様版 OS は、90%と大幅に処理速度が向上

している。これは、モータ制御などリアルタイム制約を要求が高い車載電子制御システム

において、利用可能な目安時間としている 5μsec を下回っており、必要な処理速度の向上

が実現できたと判断する。

タスク起動処理における処理速度向上の主要因を図 7-14 に示す。

44

90%高速化

O

S

45

RTE

タスク起動要求

AUTOSAR JASPAR

OSモード開始処理

タイミング保護処理

タスク起動

OSモード開始処理

40%削減

50%削減

タスク起動処理タスク起動処理

図 7-14 タスク起動処理の高速化主要因

JASPAR 仕様での設計自由度向上により、タイミング保護機能を未サポートとしている。

これにより、タスク起動時のタイミング保護処理が不要となることから、50%の処理時間

削減を実現している。また、設計自由度向上に伴う実装者工夫により、OS モード開始処

理が簡略化されたことから、40%の処理時間削減を実現している。

これらの処理速度向上は、JASPAR 仕様による設計自由度の向上、および、設計自由度

が向上したことに伴う実装者工夫によるもので、JASPAR 仕様の優位性を示すものである。

以上のことより、JASPAR 仕様に準拠することで制御に必要な機能を満たしたうえで、

大幅な処理速度の向上を実現でき、リアルタイム制約を要求する車載電子制御システムで

の利用が可能になった。また、JASPAR 仕様が有用であることも確認できた。

なお、マルチコアマイコンに対応することで、機能を分散することが可能となり、総合

的な処理速度の向上が期待できる。今後、JASPAR 仕様として検討していきたい。

c 通信モジュールに対する考察

JASPAR 仕様の特徴である信頼性機能が通信機能に対して導入されている。ここでは、

特に導入した機能が多く、それにより信頼性機能の中では多くの処理時間を必要としてい

る受信処理について記載する。

信頼性機能の導入は、次世代の通信規格として期待されている FlexRay 通信に対して適

用しており、FlexRay クラスタの受信処理に着目する。受信処理の全体像および FlexRay

クラスタの信頼性機能を図 7-15 に示す。また、各クラスタの受信処理時間、および、信

頼性機能の受信処理時間を図 7-16 に示す。なお、1フレーム(32byte)で 32 シグナルの

データを受信したときの、受信処理時間とする。

RTE

OS

COMクラスタ

コピー

ｱﾝﾊﾟｯｸ

FlexRayクラスタ

ハードウェア化

検討機能

※黄色の処理が

信頼性機能

シグナル

PDU

S1 S2 SN

受信順番確認

ﾁｪｯｸｻﾑ確認

CCからデータ取得

マイコン

FlexRayデータ受信

46

S1 S2 SN

S1 S2 S3 ・・・・・・・ SN

データ長確認

NULLフレーム確認

フレーム確認

スロット確認

図 7-15 受信処理と信頼性機能

時間(μsec)

100

80

60

40

20

0

JASPAR

アーキテクチャ

受信処理時間

RTEクラスタ

COMクラスタ

FlexRay信頼性機能

7%増加 FlexRayクラスタ

47

RTEデータ

コピー

アンパック

機能

JASPAR

信頼性機能

アーキテクチャ

図 7-16 各クラスタと信頼性機能の受信処理時間

受信処理における信頼性機能として、FlexRay クラスタに6件の確認処理が実装されて

いる。FlexRay クラスタ内での処理時間では、25%と比較的多くの処理時間を必要として

おり、改善課題とも考えられる。

なお、受信処理には他のクラスタの処理時間も必要となるため、受信処理全体で比較を

してみる。JASPAR 仕様の信頼性機能あり版は、JASPAR 仕様の信頼性機能なし版に対し

て、7%と非常に少ない処理時間の増加で、信頼性機能を実現している。

以上のことより、JASPAR 信頼性機能追加を少ない処理時間の増加で実現しており、車

載システムへの適用が可能になった。

なお、ソフトウェアで実現している信頼性機能の一部(特にハードウェアに近いスロッ

ト確認・フレーム確認・NULL フレーム確認・データ長確認など)をハードウェア化する

ことで、更なる処理速度の向上が期待できる。半導体メーカに対して信頼性機能のハード

ウェア化の検討を要望する。

(2) インテグ(結合)評価

インテグ(結合)評価では、開発したモジュールを結合した状態での主に非機能面に着目

した評価を行う。また、非機能面とは、処理速度、リソース消費量等の効率性や使用性、移

植性等を示す。

a 評価要領

今年度は効率性に着目して評価を実施した。しかし、今回はプロトタイプ開発の為、モ

ジュールの完成度が低く、モジュールインテグ時にモジュール間のインタフェース不整合

等の機能面の問題が発生することが予想される。したがって、効率性を評価する前に、機

能面の評価(機能テスト)も実施した。

また、インテグ作業の手戻りを少なくするため、インテグ作業を段階的に進めた。図 7-17

のとおり、先ず、カーネル部分を構築してから、周辺をインクリメンタルに結合した。

Step1

カーネル層

(OS+MCAL)

ハードウェア

Step2

ミドルウェア層

(通信ミドル)

カーネル層

(OS+MCAL)

ハードウェア

48

アプリケーション層

(SWC)

アダプテーション層

(RTE)

ミドルウェア層

(通信ミドル、I/O)

カーネル層

(OS+MCAL)

ハードウェア

カーネル構築ミドルウェア結合アプリ結合(w/RTE)

図 7-17 インテグレーションプロセス例(インクリメンタルリンク)

また本評価においては、この「クラスタ単位での評価」、「BSW 全体の評価」(全体)と

評価の粒度を分けて行った。

AUTOSAR BSW は複数のモジュールで構成されるが、機能毎にまとまったモジュール

の塊(かたまり)で分類される。その塊をクラスタと呼び、図 7-18 に示すように、RTE

クラスタ、システムクラスタ、メモリクラスタ、通信クラスタ、I/O クラスタ、MCAL ク

ラスタと6つのクラスタに分類される。さらに、適宜、クラスタは階層化され、一番トッ

プのクラスタをクラスタあるいは基本クラスタ、下位のクラスタをサブクラスタと呼ぶ。

例えば、OS はシステムクラスタに含まれるが、独立性が高いため、サブクラスタとして

システムとは分離して扱う。通信クラスタも通信プロトコルに応じて CAN クラスタ、

FlexRay クラスタ、LIN クラスタのサブクラスタに分割される。

システムクラスタ

System

Services

Onboard

Device

Abstraction

Microcontor

oller Drivers

メモリクラスタ

Memory

Services

Memory

Hardware

Abstract ion

Memory

Drivers

RTEクラスタ

RTE

MCALクラスタ

49

通信クラスタ

Communication

Services

Communication

Hardware

Abstraction

Communication

Drivers

図 7-18 AUTOSAR BSW のクラスタ分け

I/Oクラスタ

各評価ドメイン別に定めた評価項目に対して評価を実施するため、実 ECU に近い環境を

再現できるように、実アプリケーションを模擬した評価用アプリケーション(エンジン制御、

モータ制御)を使用して測定を行った。

I/O Hardware

Abstract io n

I/O

Drivers

以下にインテグ(結合)評価結果に対する考察、および今後の課題を記述する。

Complex Device Drivers

評価結果からの考察

JASPAR 仕様 BSW のインテグレーション評価結果から、AUTOSAR 仕様の最適化

および実装効率の向上により、処理速度およびリソース消費の改善率 10%超(対

AUTOSAR 仕様 BSW)という目標を達成できることがトヨタ・デンソーチーム/ホン

ダ・ホンダエレシス両チームの評価結果から確認できた(表 7-4)。特に、通信処理速度

に関する改善幅が大きかった。

一方、エンジン制御系アプリケーションのインテグレーション評価結果や単体評価結

果と比較した場合、モータ制御系アプリケーションでは、リソース消費量に関して

JASPAR 仕様による改善幅が少なかった。これは、モータ制御系アプリケーションが高

ハードリアルタイム制約(100μsec での制御)を有していることから、モジュール実装

時に処理速度を重視したためであると考えられる。これらの結果から以下の2点を課題

としてあげる。

①今後、自動車メーカ・サプライヤが BSW をソフトウェアメーカから調達する際に

は、開発初期段階で当該 BSW に対する要求仕様を明確にすると共に、要求性能を

満たす BSW を正しく選定する必要がある。

②今後、自動車メーカ・サプライヤが BSW をソフトウェアメーカに対し開発依頼す

る際には明確な要求仕様(機能面に加え性能面も)を提示する必要がある。

トヨタ/デンソー

ホンダ/エレシス

日産

表 7-4 リソース改善率

(AUTOSAR 仕様 BSW と JASPAR 仕様 BSW の各社比較評価結果)

ROM消費

-32%

-23%

-3%

50

RAM消費

-37%

-54%

-8%

処理速度

-49%

-26%

-25%

c 3カ年の活動を通じての成果

これまでのインテグ(結合)評価の結果から、実車適用に耐え得る実用性を重視した、

標準仕様を策定することができた。

上記標準仕様により、欧州では実現が困難となっているマルチベンダによる BSW 実装

を実現することができた。また、開発を支援するための各種実装ガイドラインを策定する

ことで、実作業面の手順化を行うことができた。

自動車用制御基盤ソフトウェア(JASPAR BSW)のインテグ(結合)評価結果、特に

効率性面については、JASPAR 仕様の効果とソフトウェアメーカの実装工夫効果が混在し

ているため、各々の要素が効率性に与える影響について考察する必要がある。

国プロ推進 WG 評価用ソフトウェアチームでは、BSW に対する要求として、

・「リアルタイム制約に対する要求」

・「ソフトウェアの規模、通信容量の影響」

・「ボディ系のような小型 ECU への適応可否」

などを考慮して、以下の3つのシステムへの適用を試みた(図 7-19)。

図 7-19 評価用ソフトチームの適用範囲

その結果、開発された JASPAR 仕様 BSW が実車への適用が可能なレベルにあることに

加え、個別システムにおいて以下のことも検証できた。

・安全制御系 : 次世代通信(FlexRay)にシステム進化させる適応性

・ステアリング系制御 : 新規高信頼・冗長制御システムでの実現性

・ITS 系制御 : 普及に向けた現行システムへの置き換え可能性

また、今回の基盤ソフトウェアを量産適用する場合の課題を以下の通り抽出できた。

・ROM/RAM リソース消費量および処理速度等、コード効率の更なる向上

・開発支援ツールチェーンの操作性/完成度の向上

・AUTOSAR 仕様との互換性の確保および未対応モジュールへの対応

さらに、今回の開発を通じ、ソフトウェア、ツール、半導体、部品、自動車の各メーカ

が連携して自動車用制御基盤ソフトウェアを車載制御システムに適用(共同開発)する際

の実績を積むことができた。多くの企業が協力して、「仕様策定 ⇒ 実装 ⇒ インテグ(結

合)評価 ⇒ フィードバック」を分担し、それぞれの役割に応じ、多くの課題解決に協力

して取り組むことができた。その一方で、各社が役割を超えて貢献するケースは少なく、

持ち回り作業に対応する印象も受けた。今後は、開発初期段階の目標設定と共有化に加え、

各社分担を今回よりも一層明確に、具体的にした上で、各社作業を開始すること、作業開

始後も定期的に目標の変更有無を確認することが成功の一つの鍵になるものと考える。

(3) 実装時のガイドラインの策定

a ガイドラインの目的

’07 年度、ソフトウェアメーカ各社の開発成果物をインテグレーションする段階で、各

社間のリリースルールの曖昧さ、モジュール使用方法や AUTOSAR 仕様の理解不足が原

因で、インテグレーションに非常に時間がかかった。

このため、’08 年度と’09 年度にインテグレータ向けにガイドラインを策定した。ソフト

ウェアメーカ各社がガイドラインに沿ってリリースを行い、モジュール使用方法、

AUTOSAR 仕様をガイドラインによってインテグレータ側に明示することで、十分なイン

テグレーションができることを目的とした。

b ガイドラインの種類と概要

1) リリース編ガイドライン

本ガイドラインでは、ソフトウェアメーカ各社で統一するフォルダ構成、インストー

ル手順、パッケージ化手順を示している。

新規参入のソフトウェアメーカであっても、本ガイドラインに従ったパッケージを作

成することで、インテグレータが認識しているインストールイメージを再現できる。ま

た、インテグレータ側でもファイルのコピーや移動が不要になる。

2) アプリケーション実装編ガイドライン

本ガイドラインでは、コンフィグレーション、ジェネレート、ビルドの手順について

順を追って示している。

インテグレータは本ガイドラインに記された手順に従うことで、ソフトウェアメーカ

が想定する環境を構築できる。

また、各モジュールを使用できるまでの手順を示し、モジュール動作までに試行錯誤

することなく、インテグレーション作業に入ることが可能である。

3) BSW 実装編ガイドライン

AUTOSAR 仕様が不明確なためソフトウェアメーカが独自に解釈した箇所、もしくは

ソフトウェアメーカ間で AUTOSAR 仕様の認識が異なる箇所について記載している。

仕様理解についてはインテグレータとソフトウェアメーカでも差異があることが予想

されるため、インテグレーション前に、本ガイドラインに目を通すことで、インテグレ

ーション内容とソフトウェアモジュールの不一致が抽出でき、不要なインテグレーショ

ン時間を削減できる。

4) BSW インテグレーション編ガイドライン

本ガイドラインでは、BSW インテグレーションの流れに沿って、BSW の方式設計に

参考となる各クラスタおよびモジュールの役割や、詳細設計時に参考となる BSW イン

テグレータが作成するモジュールの作成方法を記載している。

BSW インテグレーション編ガイドラインの主な構成を以下に示す。

・必要なソフトウェアのインストール

・システム構成と必要クラスタ

・ BSW クラスタの生成

・ BSW インテグレータによる BSW モジュールの作成

・ビルド手順

BSW インテグレーション環境を構築するために必要となる、7件のインストール概

要を記載している。また、BSW インテグレータが作成するモジュールについては、8

件の具体例を記載している。

インテグレータは本ガイドラインに沿って作業をすることで、JASPAR ツールチェー

ンを利用し、ソフトウェアメーカがリリースしたクラスタをインテグレーションするこ

とができる。

5) 拡張 MCAL-API 作成ガイドライン

AUTOSAR で規定されている MCAL は、基本的な I/O のみであり、実際の ECU ソ

フト構築にあたっては、これ以外の周辺 I/O 用のコントロールソフトを作る必要がある。

これを拡張 MCAL と呼び、この拡張 MCAL の構築手法をガイドラインとしてまとめ

た。

これにより、AUTOSAR で規定されていない I/O をコントロールするソフトウェアの

記述方法が統一でき、再利用性が向上する。このガイドラインに従い、富士通マイクロ

エレクトロニクスがデバッグモニタ用拡張 MCAL を作成した。

7.1.5 ’09 年度の活動総括

今年度は、3カ年計画の最終フェーズである検証フェーズの位置づけで、JASPAR BSW

の仕様の検証を各グループ・チームの役割から推進し、仕様の改善に取り組んだ。特に、本

TF 活動の根幹であるプロファイル・クラスタコンセプトの検証・改善活動に注力した。ま

た、開発ツール TF との連携を強化し、プロファイル・クラスタコンセプトに基づいたツー

ルチェーンを構築することができた。

(1) JASPAR BSW 仕様の策定

a 自動車用制御基盤ソフトウェア推奨要求定義書の策定

予定通り、プロファイル・クラスタコンセプトを織り込んだ JASPAR BSW 要求仕様書

(『自動車用制御基盤ソフトウェア推奨要求定義書』)の策定を完了した。これにより、

JASPAR の提案する自動車用制御基盤ソフトウェアの要求をソフトウェア設計できるレ

ベルまで文書化する事ができた。

b プロファイル・クラスタコンセプトの検証

また、プロファイル・クラスタコンセプト導入効果に関しては、実装グループと協力し

て、仕様面・実装面の両面より検証し、効果を確認した。例えば、仕様面では、本コンセ

プトを導入することで、適用製品にとっては不要な機能を削減する事が可能となり、煩雑

なコンフィグレーション作業の効率化やソフトウェアの性能向上が図られた。

c FlexRay 通信向け信頼性要件の織り込み

FlexRay 通信を採用した実製品への適用に必須となるフェイルセーフ機能等の信頼性要

件を洗い出し、本仕様に織り込んだ。これにより、今回策定した要求仕様による BSW の

信頼性が向上し、高信頼な FlexRay 通信システムを構築することが可能となった。本来、

AUTOSAR ではアプリケーションで実現していた機能を BSW で実装することで、今まで

AUTOSAR 仕様ではできなかったハードウェアに近い信頼性確保に関する処理を実現で

きた。

(2) JASPAR BSW の実装

a プロトタイプ実装・単体評価

本活動も予定通り、上述の JASPAR BSW 要求仕様に基づくプロトタイプ実装・単体評

価を完了した。特に、昨年度の残存課題である OS の割り込み処理の高速化に関しては、

プロファイルに合わせ AUTOSAR 仕様の実装依存の部分を明確化し仕様化することで解

決した。また、昨年度の工数不足で実装できなかった信頼性要件の実装も単体評価まで含

めて実施できた。

マルチベンダ相互接続評価

今年度の新たな試みとして、実装ベンダのみで BSW を構築し、通信バス上に ECU を

模擬した評価ボードを複数接続して試験評価するマルチベンダ相互接続評価と呼ばれるシ

ステム統合評価を実施した。狙いとしては、今回各社が開発した BSW が全体システムと

して仕様通りに動作するかの確認と実装ベンダのスキル向上の二つである。非常に苦労し

たが何とか評価まで漕ぎ着け、TF 全体の成果に貢献できた。本評価結果は、BSW 全体の

評価の重要なデータとなった。

c 実装ベンダの実装スキル向上

クラスタコンセプトによる設計自由度の向上は、実装ベンダの実装スキルに大きく影響

する。つまり、スキルのある実装ベンダにとっては、AUTOSAR 仕様に比べ、より性能が

高い実装を可能とするが、スキルのない実装ベンダにとっては、全く逆の結果となる場合

がある。数回の実装作業を体験することで実装ベンダにも実装ノウハウが溜まり、実装ス

キル向上による改善効果も大きいと考える。

d 開発ガイドラインによる実装ノウハウの形式知化

今回の実装・評価活動を通じて、実装ベンダによる暗黙知である実装ノウハウを、マル

チベンダ開発による共通領域の観点より、複数の開発ガイドラインにまとめ形式知化した。

例えば、マルチベンダ開発で発生するソフトウェア部品の開発・運用に関する問題点・課

題を解説するための実装ルールや配布ルールをガイドラインとしてまとめた。

その効果に関しても、時間の都合上、全てのガイドラインの評価はできなかったが、一

部、今回のプロトタイプ開発作業で試行・評価を行った。その結果、ベンダ間に共通する

開発作業および運用作業の効率化が図られ、効果を確認することができた。本開発ガイド

ラインは、今後、新しく同様の開発を行う実装ベンダにとって有益であると考える。

(3) JASPAR BSW の評価

a 評価用アプリケーションでの評価

本年度も、3チームで分担して実製品を模擬した評価用アプリケーションを使用して、

JASPAR BSW の結合評価を実施した。その結果、AUTOSAR R3.0 仕様をそのまま実装

した昨年度に比べ、消費リソースや処理速度の性能面で改善が図られ、目標とした

AUTOSAR ソフトウェアに対して 10%以上の性能改善効果を達成した。各チームでの測

定データによる分析により、プロファイル・クラスタコンセプトによる効果を確認した。

b 実製品適用に向けた課題解決

今回の評価結果より、AUTOSAR 仕様の適用対象としては課題であったモータ制御等の

リアルタイム制約が厳しい製品やリソース制約が厳しいボディ系製品に対しても、その製

品に応じたプロファイルを選択する事で適用可能であることが検証できた。ただし、まだ、

検証実績が少ないため、今後も継続して評価を行い、仕様にフィードバックをかけていく

必要があると考える。

c 開発ツール TF との連携

一方、開発ツール TF との連携に関しては、本プロファイル・クラスタコンセプトに基

づいたツールチェーンが完成し、煩雑であったコンフィグレーション時のパラメータ設定

数を半減されることに貢献した。また、本標準実装 TF と合同での評価を実施し、効果を

検証した。

7.2 開発環境・ツールの仕様策定と実装評価

7.2.1 3カ年計画

開発ツール TF の3カ年計画は以下の通りである。

� 1年目:AUTOSAR 仕様の分析、既存ツールの評価、およびツール仕様の策定

� 2年目:1年目に策定したツール仕様に基づくプロトタイプツールの開発

� 3年目:プロトタイプツールを用いたソフトウェア開発の実証

また、3カ年計画のスケジュールを図 7-20 に示す。

図 7-20 開発ツール TF 3カ年計画スケジュール

7.2.2 活動の目的とゴール

本年度の活動の目標は3カ年計画の3年目として、プラットフォームベース開発において

必要とされる自動車用制御基盤ソフトウェアを利用してソフトウェア開発を行う上で必須と

なるツール群について、’08 年度にプロトタイプ開発を行った各々のツールの評価結果をフ

ィードバックすることにより、仕様及びプロトタイプ開発するツールの完成度を上げること、

および実運用における課題抽出と実運用に向けた提案を行うことである。

さらに、今年度は標準実装 TF にて策定を進めてきた JASPAR BSW の特徴であるプロフ

ァイル、クラスタなどのコンセプトに対応し、ツールとしての使い良さ、生産性向上を計る

ための設定パラメータの削減などにも取り組む。

一方、AUTOSAR 仕様において定義されていない複数のツールの接続、統一された操作環

境を実現するためのツールフレームワークおよび検証ツールとの連携を可能とするインタフ

ェースについての’08 年度の調査結果を反映した要求仕様の策定とプロトタイプ開発および

それらの評価も行う。

以下に本年度の目標を示す。

’08 年度より引き続き、標準実装 TF で策定する自動車用制御基盤ソフトウェア仕様を用い

た自動車用電子制御システム開発に適したツールの要件検討、仕様策定、プロトタイプ開発、

評価を行う。

また今年度は使用品質の向上、より実用に向けたニーズに対応するためツールフレームワ

ークおよび検証ツールの要求仕様の策定とプロトタイプ開発およびそれらの評価をあわせて

行う。その際、評価に関しては ISO/IEC 9126-4 利用品質特性に基づく評価項目を規定し、

評価を実施する。

(a) ’08 年度に実施した自動車用制御基盤ソフトウェアに対応するソフトウェアの設計/検

証に必要なツール群を統合し、自動車用ソフトウェア開発プロセスに従った一連の作業

を統一環境で行える統合開発環境フレームワークの要件策定と仕様定義、及びプロトタ

イプについて検証、評価を行う。

(b) 上述の基盤ソフトウェアを用いたソフトウェア開発を支援するソフトウェア設計ツー

ル/実装ツールのプロトタイプについて検証、評価を行う。

・検証、評価を行うツール:システム設計ツール、ソフトウェア設計ツール、各種コン

フィグレータ

価基準を実施した結果を各仕様に反映する。

(d) ’08 年度に策定したプロトタイプ開発を実施する各種ツールの利用品質特性を評価する

ISO/IEC 9126-4 に基づく評価基準を用い、評価を実施した結果を各仕様に反映する。

・評価基準策定対象ツール:統合開発環境フレームワーク、システム設計ツール、ソフ

トウェア設計ツール

7.2.3 活動項目

前節 7.2.2 に記述したように、プラットフォームベース開発を担う自動車用制御基盤ソフ

トウェアの標準化を進めている AUTOSAR の仕様を基に、そこから必要な機能の絞込みを

行うと共に、不足する機能を追加していくといった観点で以下に挙げる項目について活動を

進める。

1. プラットフォームベース開発に必須となるツール群の定義と基本となる要件、要求仕

様の策定

AUTOSAR R3.0 の開発方法論およびツールに関連する仕様の分析結果、および標準

実装 TF で策定するプロファイル、クラスタコンセプトに沿った JASPAR 仕様のプラッ

トフォームベース開発に必要なツールチェーンの定義を行い、各々の開発工程に必要な

ツールの要件およびツール間のインタフェースに必要な情報の定義を実施する。

2. プラットフォームベース開発に必須となるツールの有用性を客観的に評価することが

可能な評価基準の策定

ツールの性能向上、競争力向上を目的として、客観的に開発ツールの有用性を評価可

能な評価基準を策定する。またその基準を用いて開発したプロトタイプツールの評価を

実施することにより策定したツールの要件、仕様のレベルアップを図るための課題の抽

出を行う。

3. AUTOSAR 仕様において定義されていない複数のツールの接続、統一された操作環境

を実現するためのツールフレームワークの要求仕様の策定とプロトタイプの開発。

AUTOSAR ツールのフレームワークとして、本 TF で開発中のシステム設計ツール、

ソフト設計ツール等のフレームワークとして、オープンソースであり多くのツールのフ

レームワークとして採用されている Eclipse をベースとした JASPAR ツールフレームワ

ークの仕様策定とプロトタイプ開発を行う。また本事業でプロトタイプ開発を行ってい

る各々のツールを組み込むための仕様、ガイドラインも合わせて策定する。

4. 標準実装 TF でプロトタイプ開発する自動車用制御基盤ソフトウェアを用いたソフト

ウェア開発に必要となる自動車用制御基盤ソフトウェアのパラメータ設定に対応するコ

ンフィグレータのプロトタイプ開発、および JASPAR BSW に対応した機能拡充。

今年度、標準実装 TF で開発を進める OS、COM、RTE、PDUR、CAN-IF、CAN-SM、

FlexRay-IF、FlexRay-SM の 8 種類の自動車用制御基盤ソフトウェア及び MCAL のパ

ラメータ設定を行うコンフィグレータを AUTOSAR R3.0 仕様の分析結果を基にプロト

タイプ開発する。さらに昨年度の評価結果のフィードバックを反映し、プロファイル、

クラスタコンセプトに沿った JASPAR 仕様に適合した設定すべきパラメータを削減可

能な機能の追加と JASPAR ツールフレームワーク対応を行う。

5. AUTOSAR 仕様において定義されていない検証ツールとの連携を可能とするインタ

フェースの要求仕様の策定とプロトタイプ開発

ソフトウェア開発に用いられる設計ツールと既存の検証ツール間の情報交換のユース

ケースの分析結果を基に、検証ツールインタフェース仕様の策定およびプロトタイプ開

発を行い、既存の検証ツールとの連携による仕様の妥当性についての評価を行う。プラ

ットフォームベース開発を担う自動車用制御基盤ソフトウェアの標準化を進めている

AUTOSAR の仕様を基に、そこから必要な機能の絞込みを行うと共に、不足する機能を

追加していくといった観点で、以下に挙げる6つの項目について活動を進める。

7.2.4 活動スケジュール

’09 年度の活動スケジュールを図 7-21 に示す。

全体日程

マイルストーン

ツール仕様策定

仕様グループ

ツール実装

実装グループ

ツール評価

評価グループ

担当

各チーム

分担

アーキテクチャ

チーム

システム設計

チーム

ソフト設計

チーム

ソフト検証

チーム

各分担

評価グループ

’08年度

3 4 5 6

評価

レポート

フレームワーク

仕様策定

エキスポートツール

仕様定義

63

’09年度

7 8 9 10 11 12 1 2 3

フレームワーク設計仕様見直し

JASPAR BSW対応フレームワーク対応

仕様定義仕様定義

JASPAR BSW対応フレームワーク対応

仕様定義仕様定義

仕様修正

まとめ

ツールプロトタイプ

JASPAR BSW対応

ツールプロトタイプ

フレームワーク対応ツールプロトタイプ修正

リリースリリースリリース

ツール評価

準備

ツール評価

準備

まとめ

ツール評価

図 7-21 ’09 年度開発ツール TF 活動スケジュール

評価

レポート

7.2.5 活動の概要

(1) プラットフォームベース開発に必須となるツール群の定義と基本となる要件、要求仕様

の策定

AUTOSAR R3.0 の開発方法論およびツールに関連する仕様の分析結果、および標準実装

TF で策定するプロファイル、クラスタコンセプトに沿った JASPAR 仕様のプラットフォー

ムベース開発に必要なツールチェーンの定義を行い、各々の開発工程に必要なツールの要件

およびツール間のインタフェースに必要な情報の定義を実施した。

AUTOSAR の開発方法論を図 7-22 に示す。また、AUTOSAR 開発方法論において、各作

業に対応した開発ツールを表 7-5 に示す。

(ステップ①)

まず”System Configuration Input”が定義される必要がある。これはシステム設計、もしくはアーキテクチ

ャ・タスクである。SW-C およびハードウェアが選ばれ、全体のシステム制約が識別される必要がある。

AUTOSAR では、これらの初期システム設計を決定する際、形式記述への簡略化のために、テンプレート、も

しくは情報交換フォーマットを用いる。よって、”System Configurations Input”を定義するということは適切

なテンプレートを記入、もしくは編集することを意味する。

これにより、以下のパッケージ情報が訳される。

・Software Components:各 SW-C はソフトウェア API(data type、port、interface 等)の記述が必要であ

る。

・ECU Resources:各 ECU は(processor unit、memory、peripheral、sensor、actuator 等に対する)仕

様が必要である。

・System Constraints:ここでは(bus signal、topology、mapping of belonging together components 等に

対する)制約を含めている。

テンプレートが一から記入されるか、もしくは再利用(多少の編集も含まれる)が可能であるかは、使用ケー

スに依存する。基本的には AUTOSAR 方法論は高いレベルでの再利用が可能となっている。また全ての状態に

おいて、編集は編集ツールを用いてサポートされる必要がある。

(ステップ②)

“Configure System”の作業は、主にリソース、タイミング要件を考慮しながら、SW-C を ECU に対してマッ

ピングすることである。この作業のアウトプットは”System Configuration Description”となる。この記述は全

てのシステム情報(bus mapping、topology)、各 SW-C がどの ECU に位置しているかを含んでいる。

(ステップ③)

さらに、次の作業がシステム内の各 ECU に対して行われる必要がある。”Extract ECU-Specific Information”

の作業が、”System Configuration Description”から固有 ECU に必要な情報を抽出する。これらの情報は、そ

の後、”ECU Extract of System Configuration”に用いられる。

(ステップ④)

“Configure ECU”の作業は、(Task Scheduling、BSW Configuration、Task への Runnable Entity の割り当

て等)実装に必要な情報を全て追加する。”Configure ECU”の作業の結果は、”ECU Configuration Description”

に含まれ、ここでは固有 ECU に対してローカルな情報を全て集める。この固有 ECU に対する実行可能なソフ

トウェアはこの情報から作ることが可能となる。

(ステップ⑤)

最後の作業、”Generate Executable”では、”ECU Configuration Description”に記述された ECU のコンフィ

グにより実行対象が生成される。この作業では、一般的に、(RTE、Basic Software 等の)生成コード、(コン

パイル生成コード、ソースコードとして利用可能なコンパイル SW-C 等の)コンパイル・コードを含み、全てを

リンクした実行対象とする。

図 7-22 AUTOSAR 方法論

図 7-22 におけ

る作業番号

表 7-5 AUTOSAR 開発方法論の各作業に対応する開発ツール

作業名対応する開発ツール

② Configure System System Design Tool

③ Extract ECU-Specific Information ECU Extract Tool

④ Configure ECU ECU Configuration Tool

AUTOSAR R3.0 の開発方法論およびツールに関連する仕様の分析結果を基に、プラット

フォームベース開発に必要なツールチェーンの定義を行い、各々の開発工程に必要なツール

の要件およびツール間のインタフェースに必要な情報の定義を実施した。

また、標準実装 TF で策定するプロファイル、クラスタコンセプトに沿った JASPAR 仕様

のプラットフォームベース開発に必要なツールチェーンの定義を行い、各々の開発工程に必

要なツールの要件およびツール間のインタフェースに必要な情報を定義した。

以下に、JASPAR としてまとめたツールフレームワークの上位コンセプトを述べる。

a JASPAR ツールフレームワーク・コンセプト

JASPAR ソフトウェア・アーキテクチャをサポートするための開発ツールの分析・評価

において、マルチベンダの開発ツールにより構築されるツールチェーンにおける相互運用

性の確保や仕様の新版リリースへの追従、操作性の向上などには上述のとおり様々な課題

があることが分かった。このような課題を解決するため、JASPAR 開発ツールに対し

JASPAR ツールフレームワークという概念を提案する。

b JASPAR ツールフレームワーク

車載ソフトウェア開発をサポートするための開発ツールが AUTOSAR および関連する

仕様に対応するためには、AUTOSAR モデルの取り扱いなどに代表される、相互運用上の

問題を発生しかねない多くの対応を開発ツールの開発者が実施する必要がある。こういっ

た標準仕様に対する互換性の問題は、複数の開発ツールを組み合わせた運用を行う際には

非常に大きな障害ともなりえる。

次に、利用者からの視点においては、各開発ツールにはそれぞれのベンダが得意とする

分野や注力するポイントによる差別化があり、利用者としては状況に応じた適切なツール

の選定を行えることは重要である。このような複数のツールにより構築されたツールチェ

ーンの個々のツールが選択可能でベンダロックインされず、かつ、ツール横断的なモデル

の整合性確認や変更通知などによりシームレスに連携できることが望ましい。

一方、車載ソフトウェアの開発プロセス全体から見た場合に AUTOSAR が対象として

いるのは主に実装レベルであり、ツールチェーン全体としては現時点で JASPAR の開発ツ

ールが対象としているより広範囲なツールが必要とされることも視野に入れなくてはなら

ない。このような状況に対応するためには JASPAR の範囲を超える活動における成果も取

り込んで有効活用できることが望ましく、それらの成果物が基盤とする可能性が高い標準

的なプラットフォーム上で動作し、拡張性に優れた柔軟なアーキテクチャを踏襲している

開発ツールを実装する必要がある。

そこで、図 7-23 のようなツールチェーンを構築する際に必要となるプラットフォーム

や共通的なソフトウェア基盤の実装、開発ツールの設計におけるガイドラインなどを

JASPAR ツールフレームワークとして定義する。

System

Configuration

Tool

RTE

Configuration

Editor

OS

Configuration

Editor

XXXX

Generator

JASPAR開発ツール

ECU

Extract

Tool

COM

Configuration

Editor

JASPAR Tool Framework

標準的なプラットフォーム

67

既存資産

移行ツール

ブリッジベース

の設計ツール

ユーザー定義の

妥当性検証ツール

カスタムツール

図 7-23 開発ツールの基盤を提供するツールフレームワーク

c JASPAR ツールフレームワークのねらい

先に述べたように、JASPAR ツールフレームワークの狙いは、開発ツールの開発者と利

用者の双方に有用なソフトウェア基盤を提供する事にあるが、具体的には次の3点である。

� 相互運用性の向上

複雑な仕様に対する共通的なソフトウェア基盤を提供することで、仕様解釈のあいま

いさを低減し、相互運用性の問題を起こりにくくする。

� 開発ツールの多様性の向上

初期開発コストや互換性維持コストを低減することで、開発ベンダが参入する際の障

壁の低減を実現する。同様に、開発ツールの利用者が個別に開発するレガシーディスク

リプション形式からの移行などを目的としたカスタムツールの初期開発コストの低減

も目指す。

� 操作性や利便性の向上

各社が協力して操作性の差異の低減やスケーラビリティの向上に取り組む基盤を提供

することで、開発ツールの利用者に対しての利便性の向上を実現する。

d 周辺情報

AUTOSAR に対しては Artop1と呼ばれるフレームワークがオープンソースに近いライセンス(利用には AUTOSAR のライセンス契約が別途必要となる)でリリースされてい

る。また、プロセス TF で調査を行っている EAST-ADL2 に対しては、仕様のデモンスト

レータ2がオープンソースとして公開されている。これらは JASPAR ツールフレームワー

クの要求仕様の定義に際しての重要なリファレンス情報として参考にしている。

1 AUTOSAR Tool Platform: http://www.artop.org/

2 PapyrusUML: http://www.papyrusuml.org/

(2) プラットフォームベース開発に必須となるツールの有用性を客観的に評価することが

可能な評価基準の策定

ツールの性能向上、競争力向上を目的として、客観的に開発ツールの有用性を評価可能な

評価基準を策定した。また、その基準を用いて開発したプロトタイプツールの評価を実施す

ることにより策定したツールの要件、仕様のレベルアップを図るための課題の抽出を行った。

今年度(’09 年度)の評価対象は、JASPAR ツールチェーン(JPTC)、システム設計ツー

ル、OS コンフィグレータ、COM コンフィグレータ、および検証情報 Export ツールである。

昨年度(’08 年度)実施した評価のフィードバックをふまえ、『ユーザの設計負荷の軽減とリ

リース時の完成度向上の実現』を課題として掲げ、評価を実施した。

まず評価基準は、図 7-24 に示すとおりとした。ここで、ISO/IEC 9126-4 の使用品質評価

では、4つの観点、すなわち、有効性、生産性、安全性、満足度から品質を評価するが、そ

のうち、安全性については今回の評価対象であるコンフィグレータに該当する項目がないた

め、有効性、生産性、満足度の3点について評価を実施した(図 7-25)。有効性と生産性は

定量的な測定、満足度は定性的な測定を行った。有効性は、目標を達成する正確さと完全性

であり、達成率、エラー率を測定した。生産性は、有効性のレベルと消費資源の関係であり、

達成時間を評価した。満足度は、ユーザの主観的な反応であり、製品の使用に関するユーザ

の姿勢を査定した。以下に評価項目を示す。

A)有効性

・平均完了率

各タスクを誤りなく完了した参加者の比率

・平均目標達成率

各タスクが完全に誤りなく達成された平均範囲での比率

B)効率性

・タスク時間

各タスクの完了に要する平均時間

・完了率効率

平均完了率÷平均タスク時間

・目標達成効率

平均目標達成率÷平均タスク時間

・マニュアルの参照回数

各タスクの試験を進める際にマニュアルを参照した回数

70

C)満足度

1)操作に対する反応がよい

2)どのように操作すべきかわかりやすい

3)入力しやすい

4)表示がみやすい

5)優れた機能がある

6)気の利いた機能がある

7)ヘルプやマニュアルを見なくても操作できる

8)信頼性が高い

9)車載ソフトウェアの開発プロセスにマッチしている

JASPARプロファイル、クラスタへの対応と設定値の

固定化等による入力項目の削減

ツール間の連動性と統一操作環境を実現する

上流ツール(システム仕様)情報のインポート

完成度向上のためのリリースプロセスの確立

ユーザの設計負荷の軽減とリリース時の完成度向上

●評価の目的

・’09年度の活動目標に対する評価を行う

・使い勝手向上のためのフィードバックを得る

■評価対象

・JPTC(ジェネレータブリッジ含む)

・システム設計ツール

・ECUコンフィグレータ(RTE/OS/MCAL)

・ECUコンフィグレータ(COM)

・検証情報Exportツールブリッジ

●評価項目

【基本シナリオ】

・JPTCの起動からジェネレータの起動、検証情報Exportツール

の起動までを1つのシナリオに沿って評価する。

・’08年度のシナリオと同等のシナリオで評価する。

【追加シナリオ】

・’09年度の活動目標に関連した開発項目を中心に評価する。

基本シナリオについては’08年度の評価との比較も行う

▼タスク完了率

・作業がどれほどの割合で完了したか

▼試験時間

・ツールによる作業完了にかかる時間

▼マニュアル参照回数

・作業におけるマニュアル参照頻度

▼ミス発生回数

・作業実施にかかるミスの回数

▼参照性の向上に関する項目

・操作が分かりやすい

・表示が見やすい

・マニュアル無しで操作できる

▼操作性の向上に関する項目

・操作の応答性が高い

・入力しやすい

▼機能性向上に関する項目

・優れた機能がある

・気の利いた機能がある

・プロセスにマッチ

▼その他

・信頼性が高い

・全体に対する満足度

図 7-24 ツール評価基準

71

有効性

生産性

満足度

測定法

タスクの有効性

タスク完了率

エラー頻度

タスク時間

タスク効率

経済生産性

生産的比率

相対的ユーザ効率

満足度スケール

満足度アンケート

自由使用

タスク目標のどれほどの比率を

正確に達成したか

タスクのどれほどの比率が完了

されたか

エラー頻度はどれほどか

タスクの完了にどれほどの時間

がかかるか

ユーザの効率はどの程度なのか

ユーザーの費用対効果はどれ

ほどか

ユーザが生産的活動を実行する

時間的比率はどれほどか

熟練者と比べるとユーザの効率

はどれほどか

ユーザはどの程度満足してるか

ユーザは具体的なソフトウェア

機能にどの程度満足しているか

潜在的ユーザのどれほどの比率

がシステムの使用を選択するか

好感度

操作性

ヘルプ必要性

機能性

サポート必要性

性能

学習容易性

有効性

効率性

信頼性

楽しさ・親しみ

操作しやすい・わかりやすい

やりたいことができる

反応がよい

データ喪失しない・安心感

ヘルプが必要な度合

サポートが必要な度合

基準に達する学習時間

ツール利用で削減した時間

目標達成するのに有効か

9126-4ベース Z8521ベース(案)

図 7-25 使用品質の構成要素

’09 年度の評価結果の概要を以下に示す。

a 有効性について

有効性の評価結果について述べる。

まず、有効性に関しては、’08 年度の評価において、未完了項目が非常に多かったため、

品質を確保するためにリリースガイドラインの策定を行った。

また、ツール間のバージョンの不整合に起因する未完了項目に対しては、

� ツール群のパッケージ化

� JPTC からのプラグイン変更機能の提供

により完了率の向上を目論んだ。

本年度の評価項目全体の完了率と前年度との比較を表 7-6 に示す。表において水色でハ

イライトされている項目は、前年度よりも完了率が向上したことを示している。

表 7-6 本年度の完了率と前年度との比較

本年度(%) 前年度(%)

ツール全体基本基本

JPTC 93.0 ーー

システム設計 98.8 99.5 94.0

OS

88.6 97.5 72.0

COM

86.5 86.3 77.0

検証情報Export 87.5 ーー

本年度の評価項目「全体」の完了率を見ると、いずれも高いものとなっている。また、

評価項目「基本」で示す基本シナリオの完了率についても、前年度と比較した場合、全て

のツールにおいて向上している。特に、前年度に発生したツール間のバージョンの不整合

による OS コンフィグレータ、COM コンフィグレータの完了率が低くなった問題につい

ては、同様の問題が発生することはなく、品質を確保するための施策(リリースガイドラ

インの策定)に効果があったということができる。

効率性について

次に効率性の評価結果について述べる。

本年度の効率性の評価結果を表 7-7 に、効率性の前年度比を表 7-8 に示す。表において

水色でハイライトされている項目は、前年度よりも効率性が向上したことを示している。

JPTC

システム設計

OS

COM

検証情報Export

本年度

前年度

本年度

前年度

本年度

前年度

本年度

全体

46.1

69.2

-

105.4

-

60.1

-

36.9

システム設計

OS

COM

表 7-7 効率性の評価結果

平均試験時間(分)

基本

-

53.0

72.2

44.4

62.2

45.1

62.0

-

表 7-8 効率性の前年度比

平均試験

時間(%)

73.4

71.2

72.7

73

マニュアルマニュアル平均ミスミス

参照回数参照間隔発生回数発生間隔

(回) (分/回) (回) (分/回)

2.75 16.7 1.45 31.7

4.30 16.0 1.65 41.8

6.90 10.5 2.00 36.1

2.35 44.9 2.35 44.9

1.60 23.0 1.60 38.8

1.50 40.1 1.00 60.1

1.70 23.0 1.60 38.8

1.25 29.5 0.20 184.5

マニュアル

参照間隔(%)

152.4

195.2

174.3

ミス発生

間隔(%)

115.8

115.7

154.9

効率性について前年度との比較を行うと、システム設計ツール、OS コンフィグレータ、

COM コンフィグレータの平均試験時間、マニュアル参照間隔、ミス発生間隔は、いずれ

も向上していることが分かる。また、JPTC、検証情報 Export においても、他のツールと

の比較からすると、特別な問題を抱えているという結果にはなっていない。ただし、JPTC

については、起動時間が長い点を指摘するコメントが多かったため改善の検討をする必要

がある。

c 満足度について

満足度の評価結果について述べる。

満足度の評価結果を図 7-26 にレーダチャートで、表 7-9 に一覧表で示す。

プロセスにマッチ

信頼性

全体として

マニュアルなしでの操作

操作応答性

5

4

3

2

1

0

気の利いた機能がある

74

操作の分かりやすさ

入力しやすさ

優れた機能がある

表示のみやすさ

図 7-26 満足度の評価結果 [悪い 1-2-3-4-5 良い]

表 7-9 満足度の評価結果

操作応答操作が分入力しやす表示が見優れた機

性かりやすいいやすい能がある

JPTC

システム設計

ECU(OS)

ECU(COM)

検証情報

気の利いマニュアル信頼性がプロセス

た機能なしの操作高いにマッチ

JPTC

3.56 2.95 3.39 3.17 3.29 3.24 2.94 3.29 3.38

システム設計 3.80 3.25 3.65 3.30 3.68 3.71 3.10 3.29 3.43

OS 3.50 3.25 3.55 3.65 3.61 3.63 3.30 3.12 3.57

COM

3.50 2.70 3.11 2.58 3.59 3.63 3.22 3.24 3.57

検証情報Export 3.61 2.84 3.00 3.00 3.13 2.88 2.59 3.44 3.29

上記の評価結果をみると、概ね 3 以上の良い評価を得られている。

3以上 3未満

全体として

ツール毎に見てみると、システム設計ツールおよび OS コンフィグレータについては、

結果は良好、目だった問題も見当たらない。一方、COM コンフィグレータについては、「操

作の分かりやすさ」、「表示の見やすさ」の満足度が 3 未満と低く、コメントとしてもそれ

を裏付けるものが散見された。同様に、JPTC、検証情報 Export ツールについても「操作

の分かりやすさ」および｢マニュアルなしでの操作｣の評価が低い。

3.17

3.68

3.45

3.26

3.00

これらについては、改善を要するわけだが、特に「操作の分かりやすさ」、「表示の見や

すさ」については、ツールにおいて最低限度備えていなければ使用に支障を来たす重要な

要素であるだけに、重点的に見直すことが求められる。

また、個別の機能では、優れた機能・気の利いた機能として、システム設計ツールの検

証機能、OS コンフィグレータのウィザードや Excel 出力機能を評価するコメントが多か

った。これらは、実運用においても効果的に使用できる機能であり、こういった機能が求

められていることが分かる。

次に、前年度・前々年度との比較を表 7-10 に示す。

表 7-10 前年度・前々年度との比較

操作応答操作が分入力しや表示が見優れた機気の利いマニュアル信頼性がプロセスに全体とし

性かりやすいすいやすい能があるた機能なしの操作高いマッチて

システム設計本年度 3.80 3.25 3.65 3.30 3.68 3.71 3.10 3.29 3.43 3.68

前年度 4.30 3.00 3.23 3.23 3.92 3.54 3.46 3.46 3.00 3.34

OS

COM

本年度 3.50 3.25 3.55 3.65 3.61 3.63 3.30 3.12 3.57

前年度 3.75 2.75 2.93 3.13 3.25 3.13 2.63 2.69 3.00

前々年度 3.40 2.40 2.40 2.60 2.60 2.40 3.00 2.60 2.20

本年度 3.50 2.70 3.11 2.58 3.59 3.63 3.22 3.24 3.57

前年度 3.43 3.00 3.28 3.57 3.07 3.07 3.50 2.29 3.00

前々年度 3.63 3.13 3.13 3.75 3.13 3.13 3.75 3.25 3.00

75

前年比上前年比下

前年度との比較においては、7割以上の項目で良い評価を得ることができている。また、

値としては前年度より下がっている項目でも、システム設計ツールの「操作応答性」、「優

れた機能」、OS コンフィグレータの「操作応答性」については、コメントの内容としては

良いものが多かった。COM コンフィグレータについては、前述のとおり、「操作の分かり

やすさ」、「表示の見やすさ」は評価を大きく下げた結果となっている。コメントとしては

良いが、値としては下がっている項目があることから、評価者の求めるレベルが高くなっ

ていることも考えられるが、そこから得られるフィードバックを反映させていくことで、

より有意義な改善を進められると考えている。

3.45

3.00

2.40

3.26

3,07

3.13

d 評価結果からの考察

1) 成果

車両開発の競争力を向上させるための開発ツールの作成のために、個々のツールの機

能向上と併せて、本年度は、前年度からのフィードバックを元に、『ユーザの設計負荷

軽減とリリース時の完成度向上』という課題を掲げて活動を行った。これらについて、

評価アンケートの結果を鑑みると、個々のツールの有効性・効率性・満足度は向上、前

年度に構築したツールチェーンについては、本年度はフレームワークを導入したことに

より統一操作環境が実現され、一定の成果を得ることができたと考える。

2) 課題と提言

①『ユーザインタフェースを始めとする参照性の向上』

「操作の分かりやすさ」・「表示の見やすさ」・「マニュアルなしでの操作」といった

ユーザインタフェースを始めとする参照性に関する事項について、問題指摘が散見さ

れた。完了できなかった項目、試験時間を要した項目のほとんどがこれに起因してい

るものであった。これについては、初年度からもユーザビリティの向上と設計安全性

を考慮するという課題が掲げられ、改善を実施してきているものの、課題が残されて

いる結果となっている。

②『実運用の観点からの機能強化』

規模が大きくなることから、生産性を求める要望が目立った。こちらについては、

実運用の規模、プロセスを考慮した機能強化が必要である。例えば、システム設計の

コミュニケーション情報の自動生成機能について、ネットワーク情報に基づいたコミ

ュニケーション情報の自動生成後、それらに対する設定等をするにあたり対象となる

要素を特定できなければならないが、現状ではそれが困難であり、実運用で適用する

にはトレーサビリティの向上を図らなければならないことが挙げられる。

また、評価アンケートの結果と同様、操作等の分かりやすさに関する指摘が多く、

前項に挙げた施策『ユーザインタフェースを始めとする生産性の向上』の必要性を強

調する結果となっている。

③『導入支援』

・チュートリアルの充実

ツール利用歴がない場合、試験時間を大幅に要することが分かった。完了率は高い

ことから、マニュアルを参照すれば操作方法は分かるが、直感的ではないことが考え

られる。これについては、ユーザインタフェースの改善と共に、チュートリアルの充

実を図ることが施策として考えられる。

・方法論を始めとする AUTOSAR 概要の教育

AUTOSAR 理解度との関係において、ほとんど知識を有しない場合の完了率が低く

なることが分かった。こちらに関しては、その方法論や用語の知識を備えていれば完

了率が大幅に向上することから、導入に際して、方法論を始めとする AUTOSAR の

概要の教育をエンジニアに対して行うことで改善が期待できる。

(3) AUTOSAR 仕様において定義されていない複数のツールの接続、統一された操作環境を

実現するためのツールフレームワークの調査と要求仕様の策定とプロトタイプの開発

AUTOSAR ツールのフレームワークとして、本 TF で開発中のシステム設計ツール、ソフ

ト設計ツール等のフレームワークとして、オープンソースであり多くのツールのフレームワ

ークとして採用されている Eclipse をベースとした JASPAR ツールフレームワークの仕様策

定とプロトタイプ開発を行った。また本事業でプロトタイプ開発を行っている各々のツール

を組み込むための仕様、ガイドラインも合わせて策定した。

’08 年度に AUTOSAR ツールのフレームワークとして先行する Artop の調査を実施し、本

TF で開発中のシステム設計ツール、ソフト設計ツールのフレームワークとしての採用可否

を検証するとともに、フレームワークとして備えるべき要件の抽出を行い、その上で要求仕

様を策定した。

2008 年 10 月、AUTOSAR に対応するツールメーカなどで構成される団体により Artop

と呼ばれるツールフレームワークが公開された。これは以前に Open Tool Framework (OTF)、

AUTOSAR Tool Development Kit (ATDK)と呼ばれていたものと同等である。’08 年度の活

動では周辺技術調査としてこのツールフレームワークの調査を行い、AUTOSAR により定義

されている範囲の仕様に対する要求仕様策定時の参考とした。

これらの課題の整理や初期プロトタイプの実装、周辺技術などの調査から、開発ツールの

開発者に対して提供する基盤となるソフトウェアコンポーネントに必要な要求を分析するこ

とで、開発ツールの開発者と利用者の双方に有用なフレームワーク要求仕様の策定を行った。

この要求仕様には以下のようなものが含まれている。

� ’08 年度年度までに収集した課題の一覧

� フレームワークのアーキテクチャ要求

� 開発ツールの統一プラットフォーム要求仕様

� フレームワークのコンポーネント要求仕様

� 開発ツールを対象としたガイドラインの要求仕様

上記の結果を踏まえ、’08 年度では要求仕様の策定により JASPAR ツールフレームワーク

が備えるべき機能や方針が明確化できたことから、’09 年度ではさらにブレークダウンした

JASPAR ツールフレームワークの詳細仕様の策定を実施した。

JASPAR ツールフレームワークの構成を図 7-27 に示す。

ツ

ー

ル

仕様記述

ツール

各社ツール

パツ

ッー

ケル

ーチ

ジェ

ー

ン

JASPAR

AUTOSAR

要求の要求の

追跡

System

Configuration

Tool

パラメータ

削減情報

ECU

Extract

Tool

パラメータ

削減情報

JASPARツールフレームワーク

79

XXX

Configuration

Editor

Eclipse

パラメータ

削減情報

XXXX

Generator

図 7-27 JASPAR ツールフレームワークの構成

検証ツール

I/F

検証ツール

Verification

Tool

JASPAR ツールフレームワークは Eclipse を基盤としている。Eclipse を基盤とした理由

は下記の通りである。

� ツール間で API 設計を行えば、導入するだけで連携がとれるプラグイン機構が用意

されていること

� ツール間の API 設計は、個々のツールが全く異なるプラットフォームで開発されて

いる場合と比較してかなり容易であること

� ツールを開発するプラットフォームための機能、部品が充実していること

� 既に多数のツールが Eclipse をベースとして開発が進んでいること

� Artop も基盤に Eclipse を採用していることから、Artop を基盤とした AUTOSAR

ツールとの連携も視野に入れられること

(4) 標準実装 TF でプロトタイプ開発する自動車用制御基盤ソフトウェアを用いたソフトウ

ェア開発に必要となる自動車用制御基盤ソフトウェアのパラメータ設定に対応するコ

ンフィグレータのプロトタイプ開発、および JASPAR BSW に対応した機能拡充

今年度、標準実装 TF で開発を進めた OS、COM、RTE、PDUR、CAN-IF、CAN-SM、

FlexRay-IF、FlexRay-SM の8種類の自動車用制御基盤ソフトウェアおよび MCAL のパラ

メータ設定を行うコンフィグレータを AUTOSAR R3.0 仕様の分析結果を基にプロトタイプ

開発した。

さらに昨年度の評価結果のフィードバックを反映し、プロファイル、クラスタコンセプト

に沿った JASPAR 仕様に適合した設定すべきパラメータを削減可能な機能の追加と

JASPAR ツールフレームワーク対応を行った。

(5) AUTOSAR 仕様において定義されていない検証ツールとの連携を可能とするインタフ

ェースの要求仕様の策定とプロトタイプ開発

ソフトウェア開発に用いられる設計ツールと既存の検証ツール間の情報交換のユースケー

スの分析結果を基に、検証ツールインタフェース仕様の策定およびプロトタイプ開発を行い、

既存の検証ツールとの連携による仕様の妥当性について評価を行った。

日本のメーカが求める高品質なソフトウェアを開発するためには、実証検証時の負荷を減

らすために各工程での検証(V&V プロセス)が必要だが、この分野の大部分は共通したツ

ールを使用せず、仕様のすりあわせで実現されているのが現状であった(図 7-28)。

システム

要求定義

システム

アーキテクチャ設計

ソフトウェア

要求定義

ソフトウェア

アーキテクチャ設計

ソフトウェア

詳細設計

実装

図 7-28 検証ツール間インタフェースの対象領域

一方、AUTOSAR 仕様においては、検証ツールとのインタフェース仕様が定義されていな

いため、検証ツールを使用するためには手作業による大量のパラメータ設定が必要であった。

81

ソフトウェア

結合テスト

ソフトウェア

単体テスト

ソフトウェア

総合テスト

システム

結合テスト

HILS

SPILS

SILS

システム検証ツール

システム

テスト

プロトコルアナライザ

オシロスコープ

モニタツール

ソフトウェア検証ツール

ラピッドプロトタイプ

デバッガ・ICE

コード検証ツール

静的解析ツール

単体テストツール

このような背景から、以下の2点を目的として、検証ツールインタフェース仕様の策定お

よび検証情報 Export ツールのプロトタイプ開発を実施した(図 7-29)。ここで検証情報

Export ツールとは、AUTOSAR 情報(XML ファイル)から既存の検証ツールで使用するこ

とができる検証ツール間インタフェース(XML ファイル)を抽出するものである。

� 設計ツールから検証ツールまでのツールチェーンを構成し、ユーザが容易に検証を

行える環境を構築する。

� 設計情報を検証ツール用に一元化し、複数の検証ツールが対応できる環境を構築す

る。

Extract of

System

Configuration

Description

.XML

ECU

Configuration

Description

.XML

設計ツール

生成物から

情報を抽出

検証情報

Export

ツール

対象シグナル

物理値演算

関連ファイル

82

検証ツール間

インタフェース

設定追加

.XML

ハードウェア

環境設定

ファイル

.CSV .CSV

図 7-29 検証情報 Export ツール

システム検証ツール

◆バスモニタ

◆適合ツール

ソフトウェア検証ツール

◆CPUシミュレータ

◆デバッガ・ISS

コード検証ツール

仕様のみ規定

検証情報 Export ツール実装および既存の検証ツールとの連携による仕様の妥当性につい

て評価を行った結果、以下の成果を得ることができた。

� 設計ツールから検証ツールへのツールチェーンを構成でき、シームレスな検証作業

が可能となった。

� 設計ツールからの同一情報により複数の検証ツールが動作することが確認できた。

7.2.6 ’09 年度の活動総括

(1) 成果

’09 年度は、’07 年度に AUTOSAR R2.1 仕様、’08 年度に AUTOSAR R3.0 仕様に基づい

て策定した仕様およびプロトタイプ実装を基に JASPAR 版の基本ソフトウェアに対応した

ツールの仕様策定とプロトタイプツールの開発を行った。

仕様策定においては’08 年度のツール評価の結果をフィードバックし、ツールの使用品質

の向上を図った。また、今年度は標準実装 TF にて策定されたプロファイル、クラスタの概

念に沿ったツールのプロトタイプ開発を行い、昨年度以来明らかになってきた開発負荷、つ

まりは AUTOSAR の特徴である汎用性を確保するための大量のパラメータ設定について削

減する仕様を織り込んだ。この結果、ソフト設計ツール(コンフィグレータ)の設定項目 778

パラメータを 198 パラメータに削減することができ、580 パラメータ(75%)を自動設定す

ることができた。

もうひとつの大きな取組として、JASPAR ツールの特徴である各ベンダが得意な領域のツ

ールを組み合わせたツールチェーンを容易に実現するためのフレームワークの開発、および

マルチベンダ構成故のツールの統一した操作性を確保するための施策を進めた。ツールのフ

レームワークとしてデファクトとなりつつある Eclipse をベースとし、開発したツールを容

易に組込むための仕組みの仕様策定、プロトタイプ実装を行った。

またマルチベンダ構成のために統一することが難しい操作性、ルックアンドフィールなど

のユーザインタフェースといった作業効率、生産性に係わる部分についてはフレームワーク

だけで対応することが難しいため、ガイドラインを策定し極力統一感が出せるような取組み

も行ってきた。

さらに、これらツールのリリース時の完成度の向上を図るために、リリースにあたっての

確認作業をマニュアル化したリリースガイドラインの策定およびひとつのファイルにパッケ

ージ化し、ツールフレームワーク環境と各々のツールを一体化してインストールできる仕組

みも用意し、利用者への利便性を進めた。これらの取組によりマルチベンダ構成であるが、

統一感のあるツールチェーンの構築を行える基本が確立できたと考えている。

JASPAR ツール群の特徴として’08 年度より取り組んできた検証系のツールについて、今

年度は検証ツール間インタフェースを評価する目的で CPU シミュレータ、バスモニタのプ

ロトタイプ実装を行い検証ツール間インタフェースの実用性についての評価を行った。

その結果としては、従来では検証ツールを使うために多くの設定を行う必要があったが検

証ツール間インタフェースの情報を利用することで設定項目が大幅に削減され、検証作業を

進める上での作業時間の短縮が確認できた。

一方、上流ツール(システム仕様)情報のインポートについては、AUTOSAR の仕組みと

設計工程の上流に位置づけられる制御仕様を結合させるために不可欠な作業である。システ

ム仕様としては、制御アルゴリズムなどを記述した Simulink モデル、ネットワークの設計

情報である FIBEX や CANdb の情報等がある。今年度はトライアルとして昨年度より設定

項目の多さからニーズの高かった CANdb の情報をインポートし、システム設計ツール、お

よびソフト設計ツールにおける設定項目の大幅な削減を実現できた。

’07 年度より行ってきたツールの客観的な評価を行うためのツール評価基準について

は、’08 年度の結果を踏まえ、より評価のし易さを考慮した評価方法とした。また’08 年度は

ソフト設計ツール(コンフィグレータ)とシステム設計ツールの評価であったが今年度は本

事業にて開発したフレームワークまで含めたツールチェーンとしての評価も実施した。

今年度の評価ではフレームワークの導入により統一操作環境を実現したことから、有効

性・効率性・満足度の評価は概ね向上した。

一方、操作の分かりやすさ・表示の見やすさ・マニュアルなしでの操作といったユーザイ

ンタフェースを始めとする参照性に関する事項については、問題指摘が散見されている。初

年度からもユーザビリティの向上と設計安全性を考慮するという課題が掲げられ、改善を実

施してきているものの課題が残されている結果となった。

また、AUTOSAR 理解度との関係において、ほとんど知識を有しない場合の完了率が低く

なることが分かり、多少の知識を有すれば完了率が大幅に向上することから、導入に際し、

エンジニアの教育を併せて検討することにより改善が期待できることが分かった。

’09 年度の活動では、以下の仕様策定、および、プロトタイプ実装を行った。

� 要求仕様の策定

� フレームワーク要求仕様

� System Design Tool 要求仕様

� ECU Extract Tool 要求仕様

� ECU Configuration Tool 要求仕様

� インタフェース仕様の策定

� System Design Tool-ECU Extract Tool 間インタフェース仕様

� ECU Extract Tool-ECU Configuration Tool 間インタフェース仕様

� ECU Configuration Tool-ECU Generation Tool 間インタフェース仕様

� 検証ツール間インタフェース仕様

� プロトタイプ実装

� システム設計ツール(アーキテクチャ設計、システム設計)

� ソフトウェア設計ツール(コンフィグレータ)

� JASPAR ツールフレームワーク

� 検証情報 Export ツール

� CPU シミュレータ

� バスモニタ

� ガイドラインの策定

� UI(ユーザインタフェース)ガイドライン

� リリースガイドライン

� パラメータ設定ガイドライン

� モデル開発チュートリアル(FlexRay 通信編)

� モデル開発チュートリアル(CAN 通信編)

� モデル開発チュートリアル(Gateway 通信編)

’09 年度のプロトタイプ実装により、実 ECU を開発する環境が整った。評価用ソフトチー

ムが実証実験を行うにあたり、今回開発を行ったプロトタイプツールを用いてソフトウェア

の開発を完了できたことから、ツールの有用性が確認できたと考える。

(2) 今後の課題

’09 年度は、’07 年度および’08 年度の課題解決に向け多くの施策を行ってきた。策定した

ツール評価基準を利用し、評価した結果のフィードバックからツールフレームワークの開発、

リリース時の完成度向上、開発効率向上のための操作性、グラフィック・ユーザ・インタフ

ェース統一のためのガイドラインの策定などに取り組んできた。しかし未だ不十分な点も散

見された。

課題としては以下があげられる。

� マルチベンダ構成でのユーザインタフェース統一などユーザビリティの向上

� 実運用の観点(規模、品質、生産性向上)を意識した機能強化

� システム仕様記述とのインタフェースの確立と設計妥当性の確認

今年度これらの項目が課題として残った原因のひとつがマルチベンダ故のツールメーカ各

社の競争領域にある。ツールメーカにとっての競争領域は「いかに生産性を向上できるか」

にあり、ユーザインタフェースは各社のポリシーから統一することが難しかった。

この課題の解決にはソフトウェア設計者のニーズを明確にするとともに、ツールメーカが

ユーザの立場にたった開発を行うための指針となるユーザインタフェースのガイドラインを

拡充していくことが不可欠である。

実運用に向けては、個々の自動車メーカまたはサプライヤの開発プロセスの違いに柔軟に

対応できる仕組みづくりが必要となる。各社の開発プロセスの違いにより自動車メーカ-サ

プライヤ間のインタフェースの違い、差分開発への対応が必要になる。また実開発における

規模の増大に対応する生産性向上のための機能等も必要になると考える。さらに考慮すべき

項目として、ソフトウェア開発の品質向上に向け、設計ミス、設計の妥当性等が確認出来る

ことが望まれる。

今年度はシステム仕様記述小委員会をプロセス TF、開発ツール TF 合同で活動を行ってき

た。システム仕様記述小委員会の調査結果(7.3.7 参照)が述べているように、実開発にお

いてはソフトウェア開発のより上流工程とのインタフェースが重要になる。今年度は

CANdb のデータをインポートする機能を実現したが、自動車のソフトウェア開発で良く用

いられる Simulink モデルとのインタフェース、さらには EAST-ADL で標準化が進むような

モデルとのインタフェースが必要となる。ソフトウェアの生産性向上のためにはそれら上流

ツールのモデルおよびデータ等が自動的にインポートできる環境が望まれる。また日本のプ

ロセスの特徴である差分開発に対して、ツールとして対応すべき点も多くあると考えられる

ので、ツールの競争力向上に向け、さらなる検討を行っていくべきである。

7.3 プロセス実証

7.3.1 プロセス TF の目的

プロセス TF の目的は、車載電子制御システム開発について国レベルで共有すべきプロセ

スを定義することである。

自動車用制御基盤ソフトウェア(プラットフォーム)の開発は、車載ソフトウェアの開発

費用の低減と技術促進を図るうえで避けて通れない課題であり、わが国自動車産業の国際競

争力の維持にも関わる問題である。このため、プラットフォームベース開発については自動

車メーカを初め各企業が協力しあうことを前提とした『非競争領域』と認識されている。

この非競争領域について、自動車メーカ、サプライヤ、ツールメーカ、半導体メーカ、そ

してソフトウェアメーカなどの関連会社間において、以下の3点を構築することが、プロセ

ス TF の最終的な目的となる。

①役割定義

②インタフェース定義・仕様記述･ソフト部品流通･認証等

③各役割内でのリファレンス・アクティビティ、スキル要件等

インタフェース

(約束事)

ツールメーカ

自動車メーカ

サプライヤ

半導体メーカ

図 7-30 車載電子制御システム開発の体制

87

インタフェース

(約束事)

インタフェース

(約束事)

インタフェース

(約束事)

ソフトウェア

メーカ

7.3.2 プロセス TF が取り扱う課題

プロセス TF では非競争領域において自動車メーカ、サプライヤ、ツールメーカ、半導体

メーカ、そしてソフトウェアメーカなどの関連会社が協調すべき仕事の約束事(インタフェ

ース)を明確化することが目的となる。また、協調すべき仕事を明確にしたうえで、関連会

社間で適正な競争が行われる状態を作ることも目的となる。

プロセス TF では、この目的を達成するための様々な要件を課題として取り扱う。以下で

目的と課題について説明する。

(目的)

� 自動車分野に適した目指すべきプラットフォームベース開発が定義されている。

� 役割が明確になっている。

� 役割間のインタフェースが明確になっている。

� 各役割内でのリファレンス(標準/ガイドライン)が明確になっている。

(課題)

� 以上を実現するためのプロセスとして以下の視点での共有すべき約束事を決める。

� 開発レジーム/スキーム(仕様記述、管理プロセス、開発標準など)

� 人材(スキル、教育など)

� ビジネスモデル(ソフト部品流通、認証など)

7.3.3 3カ年計画

プロセス TF の3カ年計画は以下のとおりである。

� 1年目:プロセス要件定義

� 2年目:要件に基づくプロセス策定

� 3年目:プロセスの実証・標準化

また、上記の計画におけるスケジュールを図 7-31 に示す。

全体日程

マイルストーン

プロセス

仕様策定

プロセス評価

プロジェクト

管理

担当

仕様グループ

評価グループ

管理グループ

Q1

2007年度

89

2008年度 2009年度

Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

分析･要件定義フェーズ仕様策定フェーズ実証･標準化フェーズ

評価レポート

要求分析要件定義

評価･分析

評価レポート評価レポート

プロセス試行要件に基づくプロセス定義実証･標準提案

BSW/ツール開発適用

試行結果

レポート

プロジェクト計画･進捗管理試行

システム開発試行

評価･分析

プロセス案

PFベース開発プロセス見直し･ドラフト作成

レポート

システム開発適用評価

ツール･検証環境まとめ

レポートレポートレポート

適用･計測

ツール開発

統合評価

図 7-31 プロセス TF 3カ年計画スケジュール

評価･分析

V1.0

V1.0

7.3.4 ‘09 年度の目的・ねらい

(1) ’09 年度までの活動状況

プロセス TF では、非競争領域における車載電子制御システムを開発する上での各社・役

割間の約束事を明確にするために、’07 年度は主にソフトウェアの開発工程を対象に、’08 年

度はソフトウェア開発を実践するための仕様を策定する工程を対象に検討を進めてきた。

車両レベル

システムレベル

ECUトポロジ

レベル

ECUレベル

ソフトレベル

半導体レベル

システムA システムA

システムB システムB

ECU ECU AA

システムC システムC

PFソフト PFソフト

エレキエレキ

アプリアプリ

ECU ECU BB

OEM 1 st -Tier

OEM 1 ベンダ

st-Tier ベンダ

※OEM:自動車メーカ

※1stTier:サプライヤ

※ベンダ:ツールメーカ、半導体メーカ、ソフトウェアメーカ

図 7-32 各年度の主な活動領域

90

08年度の注力点

【システム開発】

07年度の注力点

【ソフト開発】

また、テーマが多岐に渡るため、テーマ毎に小委員会を設置して集中的に検討する形式と

し、プロセス TF が全体を統括管理する体制として活動を実施した。

スケジュールと体制の関係を、図 7-33 に示す。

全体日程

マイルストーン

プロセス

仕様策定・評価

プロジェクト

管理

担当

開発プロセス

ETSS

EPM

Q1

2007年度

91

2008年度 2009年度

Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

分析･要件定義フェーズ

評価レポート

【全体要件】 AUTOSAR・A-SPICE調査

@プロセスTF

【ソフト開発】 ESPR・MR適用評価

@プロセスTF

【ソフト開発】スキル定義/技術要素

@ ETSS小委員会

【ソフト開発】スキル評価

@ ETSS小委員会

【ソフト開発】 EPM予実管理手法定義

@ EPM小委員会

仕様策定フェーズ

評価レポート

【全体要件】欧州プロセス調査

@プロセスTF

【システム開発】技術調査

@ システム仕様記述小委員会

【ソフト開発】 ESPR・MR適用事例分析

@プロセスTF

【システム開発】スキル定義/開発技術

@ETSS小委員会

【ソフト開発】スキル評価方法改善

@ ETSS小委員会

【ソフト開発】スキル評価

@ ETSS小委員会

【ソフト開発】 EPM予実管理手法評価

@ EPM小委員会

図 7-33 プロセス TF の進め方

実証･標準化フェーズ

評価レポート

【システム開発】技術評価・要件定義

@ システム仕様記述小委員会

【システム・ソフト開発】スキル改善

@ETSS小委員会

【システム・ソフト開発】スキル評価方法改善

@ETSS小委員会

【システム・ソフト開発】スキル評価

@ETSS小委員会

【ソフト開発】 EPM予実管理手法改善

@ EPM小委員会

(2) ’07 年度の結果と課題

’07 年度は、車載電子制御システム開発プロセスの要件定義を行った。

欧米と比較し、我が国の自動車産業は、系列会社による摺り合わせ開発、サプライヤ・中

小メーカを含めた分業型開発といった開発プロセス上の特徴を持っている。このような状況

をふまえ、今後主流となるプラットフォーム型開発に対して、現状の日本の強みを活かした

車載電子制御システム開発プロセスの要件を定義することを目的に活動を進めた。

そして、以下のような結果と課題を得た。

� 目指すべきプロセスの姿

� マルチサプライヤによるプロダクトライン型プラットフォームベース開発

� コア資産としてプロダクト(アーキテクチャ、コンポーネント)、メソドロジ、

プロセス、ツールを提供。コア資産を活用することにより量産プロダクトを開

発する世界(プロダクトライン型開発)

� 論理モデルと物理モデルに切り分けて設計。論理を物理にマッピングする際、

物理制約を入力にツールでオートコンフィグレートする世界(プラットフォー

ムベース開発)

� 日本の特性に適したプロセス

� 統合システム化による複数サプライヤによる共同開発を実現するための仕様の

インタフェースが定義されている。

ただし、インタフェースはドメインの特性に応じたインタフェースであり、こ

のインタフェースを基本に自動車メーカとサプライヤの関係性による摺り合わ

せ開発がなされる。

� 実現に向けた課題

� 日本におけるマルチサプライヤ型開発に適したプロセス

� 自動車メーカ-サプライヤ間のインタフェースの定義と体系化

� ソフトウェア流通プロセス

� 流通ソフトウェアの認証のしくみ

� IP(Intellectual Property、知的財産)ベースのビジネスモデルの確立

� 開発の主役たるエンジニアの育成・調達

� エンジニアのスキル定義

� 育成・調達の仕組み

再利用資産開発差分開発

アプリソフト

SW-C

ベンダ

標準ソフト

ベンダ

ツール

ベンダ

AUTOSAR

再

利

用

資

産

例:

ソフトコンポ

競争力の源泉

(AUTOSARと同じ)

※I/F:インタフェース

※OEM:自動車メーカ

車両

開発

電子制御

開発

ECU開発

OEM

サプライヤ

1.自動車領域の活動

1.車両装備企画

2.システム機能

2.電子制御領域の活動

1.制御仕様(論理設計)

2.ECUマッピング段階的なI/F

(類型化)

3.ECU統合の活動領域

コンポーネントの

1.ECU仕様

リファクタリングに

2.エレキ仕様

よるコンポーネント

3.SW-C仕様マッピング最適化

技術の開発が必要

93

Car fea tu res

Car func t ions

Function design

Mapping of funct ions on ECU

Def in i t ion o f commmatr ix

ECUsystemspec

SWspec / HWspec

SW dvpt / HW dvpt

I/Fを基準に

双方向で摺合わせ

Specification of Feature Definition of Authoring Tools

ドメインの特質に応じて類型化したI/Fを基準に、

OEM・サプライヤの得意領域に応じて摺り合わせ開発

→ 日本の強みを残しつつ、効率化を実現

図 7-34 ’07 年度活動結果

(3) ’08 年度の結果と課題

’07 年度の課題を受け、’08 年度は日本におけるマルチサプライヤ型開発を実現するために

最優先で共有化すべき自動車メーカとサプライヤ間のインタフェースの定義、体系化を主た

るテーマとして活動を行なった。

また、引き続き SEC 成果の適用評価を進め、車載電子制御システム開発に適した運用を

模索すると共に、結果を SEC へフィードバックを実施した。

� システム仕様記述

� 既存技術の調査・分析

� AUTOSAR におけるシステム仕様

� AUTOSAR 対応ツールのメソドロジ

� 関連技術調査

� プロセス系

� アーキテクチャ記述言語

� システム仕様記述の要件定義

� システム仕様記述に対するニーズの明確化

� システム仕様記述の体系整理

� ツール要件の定義

� SEC 成果のさらなる適用評価

� ETSS

� システム領域の技術要素を定義し、スキル診断を実施

� EPM

� プラットフォームベース開発における EPM ツールの要件定義とプロトタイピ

ング

� ESPR、ESMR

� ’07 年度成果である標準実装 TF の ESMR 準拠プロジェクト開発計画書、そし

て ESPR 準拠の各プロセスにおける仕様書について、定量的・定性的側面から

詳細分析を実施

� プロセス構築定義における期待事項の整理と SEC へのフィードバック

そして、以下の結果と課題を得た。

a システム仕様記述

システム仕様記述に対するニーズを洗い出し、自動車メーカとサプライヤ間のインタフ

ェースとして受け渡すべき情報、および、それらの表現形式を定義するために、EAST-ADL

を中心に調査を進めた。EAST-ADL は、コンセプトレベルとしての完成度が高く、

EAST-ADL を参考に検討を進め、システム仕様記述の要件を明確にした。

� システム仕様記述に対するニーズ

自動車メーカからのヒアリング結果を集約し、システム仕様記述のニーズを明らかにし

た。

� 自動車メーカ/サプライヤがそれぞれ果たすべき役割・責任範囲を明確にしたい。

� 定義すべき項目が明確であること

� ドメイン特性や自動車メーカ/サプライヤの得意領域などの条件によって、

最適なインタフェースの候補が数種類あること

� 表記法が明確であること

� システム仕様開発の段階で品質を確保したい。

� 派生開発での効率的な開発のためにモデル・仕様書の再利用を促進したい。

� 効率的なツール、および、その組み合わせ方を知りたい。

� システム仕様記述の要件

AUTOSAR、EAST-ADL2 をはじめとする欧州でのシステム仕様記述に関する体系を参

考に、上述のニーズを勘案した結果、以下のような要件を定義した。

� 業務のインタフェースを明確とする階層レベルに沿ったシステム仕様を定義

� 車両レベル:車両全体の機能を定義

� 分析レベル:ハードウェアを意識しない機能の構造を定義

� 設計レベル:ハードウェア、ECU、ソフトへと分配された機能の構造を定義

� 実装レベル:ATUOSAR ソフトウェアの構造を定義

� 操作レベル:ソフトウェアの実行コード

� 様々な観点でのシステム仕様を定義

� 構造:機能の構造を定義

� 要求:機能、品質、実装制約を定義

� 振る舞い:機能毎の動作仕様を定義

� タイミング:機能が動作する時間制約や協調関係を定義

� 派生:車両・機能のバリエーションを定義

� 機能安全:故障に対する仕様を定義

� 実現に向けた課題

上記要件に沿ったシステム仕様を実現するにあたり、以下の課題が残っている。これら

を解決・実現することが、日本の競争力となりうる。

� 大規模システムにおける振る舞いの記述・検証

統合システムにおいて、大まかな機能間での関係性を定義し、妥当性を検証す

ることが求められる。現状、EAST-ADL2 においては、分割した機能の内部を振

る舞いモデルとして Simulink 等を使って記述しシミュレーションすることで妥

当性検証する方法を提唱している。システム全体の振る舞いは、分割した機能の

振る舞いをつなぎ合わせて検証することとしている。このため、統合システムの

ような大規模かつ複雑なシステムでは使用するモデルも膨大となり、コスト面や

環境面などにおいて実用上困難な状況が予想される。

� 実装制約のヌケモレのない定義と仕様の記述・検証

設計レベルにおいて、実装制約を考慮した設計をする。ここでは、ネットワー

ク上の制約や CPU の処理負荷、リソースの消費量、センサ・アクチュエータの

分解能といった条件を考慮した設計となり、場合によっては上位仕様を満足でき

ない場合も発生する。実装制約をヌケモレなく「定義 → 検証 → 上位仕様へフ

ィードバック → 再設計 → 再検証」するといった一連のプロセスの実現性を検

討する必要がある。

� 派生開発の方法論、管理プロセス

派生をあらかじめ考慮したシステム仕様を定義することにより、その後の展開

車両開発の生産性は飛躍的に向上することは自明である。派生として定義すべき

項目は明らかであるが、定義するためのプロセス・方法論は世間をみてもまだ研

究段階である。また、展開車両開発時に、バリエーションを選択し、あるいは追

加・削除・変更した場合のトレーサビリティを管理することも重要である。

� 上記要件を満たすツールチェーン開発

このような要件をトータルで満たす、車載電子制御システム開発に適したツー

ルチェーンが必要となる。特に、シミュレーション、トレーサビリティ管理のよ

うに、ツールなくしては実現できない要件もある。

SEC 成果の適用評価

1) ETSS

� 成果

� ETSS 自動車版プロファイルの構成要素となるスキルを定義した。

� システム仕様を開発する人材に必要となるスキル(開発技術)を定義した。

� 管理技術の診断項目を精査し、より本質的なスキルを診断できるようにした。

� 自動車向けに適合した運用の仕組みを構築した。

� スキル診断の精度を向上するための運用方法を定義し、効果を実証した。

� 残課題

� ETSS 自動車版プロファイル(JASPAR 版 ETSS)の適用評価、およびブラッシ

ュアップ

2) EPM

� 成果

� SEC 標準の EPM に予実管理を組み合わせ分析した結果、その効果を検証するこ

とができた。

� 計画に対する進捗推移のパターン化ができた。

� ’07 年度に構築した環境を標準実装 TF での実開発に適用し、データを収

拾・分析した。

� 毎週、分析結果を標準実装 TF へフィードバックし、データの根拠を明確

にした。

� ETSS の診断結果との相関を分析し、予実管理と ETSS の関連についての仮説を

構築できた。

� ETSS 結果分析による組織の特徴と EPM 予実管理分析の結果には相関関係

がある。

� 残課題

� 進捗データ、開発履歴を組み合わせた分析&フィードバックをリアルタイムに実

施し有効性を検証

� 中間成果物(ESMR・ESPR)を観測し、更に詳細な分析を実施し、有効性を検

証

� エンピリカルを実現する開発環境要件の定義(現状の標準ツールへの改訂要求)

� マルチベンダ型開発の開発状態をマネジメントするための観測項目の定義

3) ESPR/ESMR

� 成果

� ’07 年度成果である標準実装 TF の ESMR 準拠プロジェクト開発計画書、そして

ESPR 準拠の各プロセスでの仕様書について、定量的・定性的側面から詳細分析

を実施した。

� ESMR-開発計画書に関する分析

� ’07 年度成果の ESMR 準拠プロジェクト開発計画書に関する記述量・記述

内容に関する分布データを取得し、SEC へフィードバックを行った。

� ESMR 準拠プロジェクト開発仕様書記述テンプレートの改善を SEC と調

整し実施した。

� ESMR 準拠プロジェクト開発計画書作成時のチェックリスト作成を SEC

と調整し実施した。

� ESPR-各プロセスでの仕様書に関する分析

� ’07 年度成果の ESPR 準拠の各プロセスでの仕様書に関する記述量・記述

内容に関する分布データを取得し、SEC へフィードバックを行った。

� ESPR 準拠の各プロセスでの仕様書記述テンプレートの改善を SEC と調

整し実施した。

� ESPR 準拠の各プロセスでの仕様書作成時のチェックリスト作成を SEC

と調整し実施した。

� プロセス構築定義における期待項目を整理し、SEC へフィードバックを実施(プ

ラットフォーム型開発、プロトタイプ型開発、マルチベンダ型開発といった V 字

型開発に収まりきらないスタイルのプロセス・テーラリング方法の検討、定義と

事例の充実)

� 残課題

� プロセス構築手法(SEC 提案)の有効性検証

� プロセス定義・運用のための作業手順

� プロジェクトのプロセス特性を把握する方法

� ESMR/ESPR 改善版ドキュメントテンプレートの実証による有効性検証

� ESMR/ESPR 記述チェックリストの実証による有効性検証

4) 欧州調査

� 成果(※下記の知見を得た)

� 産学官の活動が自律分散的に進んでおり、ETP(European Technology Platform、

欧州テクノロジー・プラットフォーム)がうまく横の連携を取っている。

� 産業界からのボトムアップの取り組みを円滑に進めるために、欧州政府は資金援

助のみの形態を取っている。

7.3.5 活動項目

’09 年度の具体的な活動項目は以下の通りである。

� システム仕様記述

� 既存技術の調査・分析

� AUTOSAR におけるシステム仕様

� AUTOSAR 対応ツールのメソドロジ

� 関連技術調査

� プロセス系

� アーキテクチャ記述言語

� システム仕様記述の要件定義

� システム仕様記述に対するニーズの明確化

� システム仕様記述の体系整理

� ツール要件の定義

� SEC 成果のさらなる適用評価

� ETSS

� システム領域の技術要素を定義し、スキル診断を実施

� EPM

� プラットフォームベース開発における EPM ツールの要件定義とプロトタイピ

ング

� ESPR、ESMR

� ’07 年度成果である標準実装 TF の ESMR 準拠プロジェクト開発計画書、そし

て ESPR 準拠の各プロセスにおける仕様書について、定量的・定性的側面から

詳細分析を実施

� プロセス構築定義における期待事項の整理と SEC へのフィードバック

7.3.6 活動スケジュール

プロセス TF の’09 年度活動スケジュールを図 7-35 に示す。

大きく「企画・開発準備」、「プロトタイピング」、「評価・F/B(フィードバック)」、そし

て「まとめ」の4つのフェーズに区切り、各活動を推進する。特に、「企画・開発準備」フェ

ーズでは、他の TF と共同で集中検討会を実施し、活動内容のすり合わせを行なう。

’09/4 5 6 7 8 9 10 11 12 ’10/1 2 3

フェーズ企画・開発準備プロトタイピング評価・F/B まとめ

プロセスTF

計画立案・体制構築進捗管理・関連組織との調整

報告書

システム仕様

記述小委員会

ETSS小委員会

EPM小委員会

サンプル準備・体制整備

計画立案

スキル基準改訂

方向付け

運用見直し

方向付け

サンプル作成・評価Ⅰ サンプル作成・評価Ⅱ

文献調査Ⅰ 文献調査Ⅱ

欧州視察調査

報告書骨子

JASPAR版ETSS 運用方法まとめ

新メンバ向けスキル診断スキル診断

計画立案

調査製作 FB 残課まとめ

調査改善残課まとめ

100

評価・F/B

修正

報告書

分析まとめ

品質面を加味した分析手法の立案→08年度データにより分析試行

EPM被験者ヒアリング

定例分析(計画・進捗)

図 7-35 ’09 年度プロセス TF 活動スケジュール

報告書

7.3.7 ’09 年度の活動総括

(1) システム仕様記述

a 活動の背景

プロダクトライン型のプラットフォームベース開発プロセスの構築に向け、システム連

携機能や分野をまたぐシステム開発には、単にソフトウェア構造を標準化するだけでなく、

自動車メーカ-サプライヤ間等のプロセスの標準化が重要な課題であった。

車載プラットフォームベース開発向けに標準化された EAST-ADL は有効な解決策と考

えられ、その歴史的な背景や技術的なバックグラウンドも含め調査を進めるに至った。

b 本年度の成果

� EAST-ADL 調査結果

� EAST-ADL を中心とした欧州の活動成果全体をみると、ツールチェーン試作を通じ

て EAST-ADL のコンセプト実証がほぼ完了している。

� 一社単独のトップダウンによる開発に対する準備立てが概ねできており、今後はタ

イミングを中心に V 字左上流における検証技術の強化が進む模様である。

� 逆に派生開発については、コア資産の表現方法についてのみ検討は進んでいるが、

実適用のための取組みが検討されている事例はみつからなかった。

� 技術的な課題

� 差分開発時に必要となる、差分記述方法、プロセスに対する検討がなされていない。

また差分開発において必要となる、膨大な設計情報を分業の枠組みで管理するため

の仕組み、差分情報管理、マルチベンダデータ管理、整合性管理、トレーサビリテ

ィ管理などがほとんど検討されていない。これらが実適用上の技術課題になると考

えられる。

� 運用上の課題

� 差分情報の記述方法に関する取り決めがないことに加え、各抽象レベルで記述すべ

き項目に幅があること、などから実運用に必要な項目が規定されていないため、こ

れらが差分開発時のデータ交換の運用上の課題となると考えられる。

� 欧州動向

� EAST-ADL を採用した多数の研究プロジェクトが動いており、プロジェクトをまと

める軸の役割をはたしている。オープンソースを中心にツールプラットフォームの

共用化が進んでおり、ツールチェーンのプロトタイプによる実証プロジェクトを容

易にする機能をはたしている。

� 欧州では基本戦略(ARTEMIS/SRA)が共有化されており、それに基づく標準化に

101

より多額の資金が投入され産官学で連携がとれる仕組み作りが具体化している。ま

た、研究成果の産業界への出口の仕組みも形作られている。

� 仕様記述においては CESAR など車載にとどまらないマルチドメインの活動に広げ

られた活動が新たにスタートしている。

c 今後の課題

� 欧州動向を継続的にリアルタイムに把握するための仕組み作りと、欧州資産の徹底

的な活用(Artop、CESAR など)

� 差分開発フェーズを中心に、BSW を使うシーンを想定した企業間・構造間のイン

タフェースの標準化

� 差分開発フェーズでの開発を効率化するための開発環境(ツールチェーン)の構築

� 産業を下支えする新たな産業の創出(ツールメーカ、ソフトウェアメーカ)

102

(2) その他 SEC 成果の評価

a ETSS

� 活動の背景

� SEC 標準 ETSS に基づき、自動車版 ETSS としてスキル標準を策定してきた。ま

た、診断・結果の分析・施策構築といった ETSS 運用上の課題を明らかにし、運用

しやすい仕組みを構築してきた。

� 活動項目

これらの結果を踏まえ、今年度は、以下の活動を推進した。

� 標準実装 TF、開発ツール TF 参画ベンダのデータを収集し、自動車版 ETSS の有

効性、および、運用方法の妥当性を検証する。

� 昨年度のスキル診断結果を踏まえ、スキル基準を修正、レベルアップする。

� 国プロ推進 WG での活動成果を広く展開すべく『運用マニュアル』としてまとめる。

� 本年度の成果

� 自動車版 ETSS の有効性

以下の結果により、自動車版 ETSS の実運用面での有効性を導出した。

� 自動車版 ETSS にて標準実装 TF、開発ツール TF 参画ベンダのスキルを計測

した結果、昨年度からのスキルの変化を把握できた。実際のチームメンバから

のヒアリング結果を突合することにより、ETSS 診断結果の妥当性を検証する

ことができた。

� 運用時の大きな課題として、自己申告型での診断精度向上が挙げられる。昨年

度提案した演習問題を用いたスキル判断基準のレベル合わせの手法を今年度

も用い、個人による診断のばらつきを少なくすることができることがわかった。

� スキル基準の修正・レベルアップ

より現場感の高いスキルへと修正、レベルアップした。

� 自動車用ソフトの特徴である、ベースからの差分開発でのスキル要件を抽出・

加筆した。

� 高信頼性ソフト開発としての特徴を整理する枠組みを整理した。

� 運用マニュアルの作成

国プロ推進 WG での結果を他産業も含めて広く展開するためのまとめが完了した。

� SEC 標準の ETSS をベースに、自動車版を策定する上での考え方や要領をま

とめることにより、他産業でのスキル基準定義の指針を示すことができた。

� また、診断結果の分析方法を示し、プロジェクトチーム立案に結果を用いるた

めの指針を示すことができた。

103

� 残課題

� スキル診断のデータを継続的に蓄積し、データの利活用を拡張

� 高信頼性ソフト開発(例:機能安全)の特徴を踏まえたスキル基準としての改訂

b EPM

� 活動の背景

� 自動車メーカ/サプライヤのように、複数のベンダから部品(ソフトウェアコンポ

ーネント)を調達し結合する開発では、複数の部品が全て計画通り開発・納品され

ることが必要不可欠となる。このため、自動車メーカ/サプライヤの管理者は、部

品開発の進捗状況を、できるだけ負担が少なく、かつ、正確な情報として入手した

い。

� EPM 小委員会では、昨年度まで、ベンダの管理者が自社内での部品開発を管理す

るためのデータを可視化、指標化してきた。

� 本年度は、自動車メーカ/サプライヤの管理者にターゲットを絞り、ベンダの部品

開発状況を定量的に把握するための指標を探求する。

� 活動項目

� SEC が提唱する品質指標(ESQR)を参考に、部品開発状況を表す定量データ(成

果物ベース)を選定し、標準実装 TF よりデータを抽出する。

� 標準実装 TF の実際の活動状況や成果物について関係者の意見を参考にまとめ、抽

出した定量データの絞り込みを行い、指標化する。

� 併せて、ETSS とのクロス分析を実施する。

� 本年度の成果

� 品質指標(ESQR)を参考した成果物ベースの定量データが、自動車メーカ/サプ

ライヤの管理者視点での部品開発の進捗管理に活用できる可能性が高いことを検証

した。

� 残課題

� 自動車メーカ/サプライヤの管理者にとって有用な指標のさらなる絞り込み

� 上記機能を実現するための EPM ツールの拡張

104

7.4 実機適用に向けた実証

7.4.1 はじめに

ここでは、本事業において、策定あるいは開発された

①自動車用制御基盤ソフトウェア(JASPAR BSW)仕様

②開発環境・ツール

③プロセス

の成果物に対して、評価用ソフトウェアを試作し、実装することにより、実機適用を想定し

た評価を実施した。以下、結果概要について述べていく。

まず、評価用ソフトウェアの対象アプリケーション選定に際しては、JASPAR BSW に対

する要求としてある

・リアルタイム制約

・ソフトウェアの規模、通信容量

を考慮した。

検討の結果、図 7-36 に示すような3つの評価用ソフトウェアを選定した。

・安全制御系

・ステアリング系制御

・ITS(Intelligent Transport Systems)系制御

ソフトウエア規模、通信容量

小さい

大きい

ITS系

制御

低い高い

リアルタイム制約に対する要求

105

安全

制御系ステアリング系

制御

図 7-36 評価用ソフトウェアの対象アプリケーション比較

そして、これら3つの評価用アプリケーションの評価にあたっては、’08 年度に JASPAR

国プロ推進 WG の配下に新設された3つの評価用ソフトチームがそれぞれ担当した(図

7-37)。

標準実装TF

リーダ: 岩井(デンソー)

サブリーダ: 井野(日産)

仕様グループ

実装グループ

評価グループ

主査: 安達(日産)

副主査: 佐藤(トヨタ)

JASPAR BSW仕様の策定

アーキテクチャチーム

ミドルウェアチーム

カーネルチーム

JASPAR BSWの実装

(ジェネレータ含む)

JASPAR BSWの評価

JASPAR運営委員会

国プロ推進WG

開発ツールTF

リーダ: 橋本(ホンダ)

サブリーダ: 佐藤(トヨタ)

仕様グループ

実装グループ

管理グループ豊通エレ、ガイア

アーキテクチャチーム

システム設計ツールチーム

ソフトウェア設計ツールチーム

106

JASPARツール仕様の策定

ソフトウェア検証ツールチーム

JASPARツールの実装

評価グループ JASPARツールの評価

ブリッジSE

プロセスTF

評価用ソフトチーム

安全制御系

評価用ソフトチーム

ステアリング系制御

評価用ソフトチーム

ITS系制御

リーダ: 城戸(トヨタ) リーダ: 加藤(日産) リーダ: 橋本(ホンダ)

ガイア

※技術管理・技術事務

リーダ: 石井(トヨタ)

リーダ代行: 佐藤(トヨタ)

サブリーダ: 菅沼(デンソー)

システム仕様記述小委員会

システム仕様記述方法の定義、

およびツール要件の定義

ETSS小委員会

ETSSプロファイルの策定と評価

①自動車用制御基盤ソフトウェア

開発エンジニア向けプロファイル

②ツール開発エンジニア向け

プロファイル

EPM小委員会

図 7-37 JASPAR 国プロ推進 WG 評価用ソフトチーム

EPM仕様の策定、および

ツール要件の定義

ESPR/ESMRの適用と評価

7.4.2 安全制御系

(1) システム概要

本活動ではレクサス LS460(図 7-38)の運転支援システム(図 7-39)に、JASPAR BSW

および FlexRay(図 7-40)を適用・評価する。評価用ソフト(安全制御系)チームは、周

辺監視系センサ ECU を担当するトヨタチームと運転支援 ECU を担当するデンソーチーム

で構成される。

図 7-38 LS460

図 7-39 LS460 運転支援システム構成

107

周辺監視系バス FlexRay(5Mbps)

運転支援

ECU

運動制御系CAN(制・駆動)

運動制御系CAN(ステア)

ボディ系CAN(ボディ)

図 7-40 LS460 評価車両バス構成

108

前方

ﾐﾘ波ﾚｰﾀﾞ

ﾄﾞﾗｲﾊﾞﾓﾆﾀ

ｶﾒﾗ

後方

ﾐﾘ波ﾚｰﾀﾞ

ｽﾃﾚｵｶﾒﾗ

(2) 活動概要

a 評価用ソフトウェア・ハードウェアの構成

周辺監視センサ ECU および運転支援 ECU のソフトウェア構成を図 7-41 および図

7-43 に示す。

周辺監視センサ ECU のハードウェアは、図 7-42 のように作成した。ハードウェア仕

様を表 7-11 に示す。

運転支援 ECU に使用するハードウェアは、ラピッド環境であるプロトタイプ ECU(図

7-44)を使用する。ラピッド環境とは、制御仕様作成から実車評価までの一連の仕様開発

サイクルを迅速に進めることを目的に開発された開発環境である。ハードウェア仕様を表

7-12 に示す。

図 7-41 周辺監視センサ ECU-JASPAR BSW(R1.0J)

109

図 7-42 周辺監視センサ ECU

表 7-11 周辺監視センサ ECU ハードウェア仕様

項目スペック

MCU NEC エレクトロニクス社製 V850E/PHO3

MCU クロック 16MHz(PLL にて 128MHz 動作可能)

FlexRay トランシ

ーバ

NEC エレクトロニクス製トランシーバ(μPD72751 DS2.0)×2

※ECU 外部からの終端 ON/OFF 可能

ESD 保護ツェナー NEC エレクトロニクス社製 RD100S Vz=100V

終端抵抗

KOA 製 RK73H1JTTD510D 1/10W 51Ω±0.5%

村田製 GRM3192C2A472JA01D 4700pF/100V ±5%

CMC TDK 製 ACT45B-510-2P 2200Ω@10MHz 51uH@100KHz

CAN トランシーバ

Philips 製 TJA1040T×1

※ECU 外部からの終端 ON/OFF 可能

ESD 保護ツェナー NEC エレクトロニクス社製 RD16S Vz=16V

終端抵抗

KOA 製 RK73H1JTTD620D 1/10W 62Ω±0.5%

村田製 GRM188B11E473KA01D 0.047uF/50V ±10%

CMC TDK 製 ACT45B-510-2P 2200Ω@10MHz 51uH@100KHz

インジケータ 7セグ LED×2、汎用 LED×4

SW 入力 DIP SW×8 点、RESET×1

デバッグ用 I/F NEC MiniCudbe 対応×1

通信系コネクタ

D-SUB9 ピンコネクタ CAN、FlexRay×2 (FlexRay コネクタ

間はデイジーチェーン接続)

電源外部電源 +12V、内部 3.3V/1.5V、消費電流は 1A 以下

筐体アルミ製 150mm(W)×100mm(D)×35mm(H)

外付け WDT 未実装

110

図 7-43 運転支援 ECU-JASPAR BSW(R1.0J)

111

図 7-44 運転支援 ECU(プロトタイプ ECU)

112

表 7-12 運転支援 ECU ハードウェア仕様

項目スペック

プロセッサ VIA C7/VIA Eden V4 bus processor

NanoBGA2 package 1GHz

128K L1 and 128K L2 cache

チップセット VIA VX700 all-in-one system media processor

メインメモリ 1 DDR2 400/533 So-DIMM ソケット

Up to 1GB memory

CF CARD 1 SLOT CF ソケット(EIDE I/F)

ストレージ UltraDMA 133/100/66/33

One 44-pin right-angle IDE connector

One SATA connector

標準 I/O RS232C×2

USB ポート 4ポート(Ver.2.0)

Ethernet I/F 100BASE-T 1 ポート

RGB

車載 I/F A/D コンバータ 16bit×16ch

D/A コンバータ 12bit×8ch

PWM 8ch

入出力ポート

入力 16ch(LVTTL)

出力 24ch(LVTTL)

CAN I/F 4 チャンネル

FlexRay I/F 2 チャンネル

BIOS Original Bootloader LPC 4Mbit(SST 49LF004B)

動作温度 -10℃~65℃

動作湿度湿度 80%以下(非結露)

電源 DC12V ±10% 5A 以下

外形 W230、H88、D231

113

車両への搭載

実車に周辺監視センサ ECU および運転支援 ECU をトランクに搭載した。搭載した様

子を図 7-45 に示す。

周辺監視センサ ECU(前方ミリ波レーダ、ドライバモニタカメラ、後方ミリ波レーダ、

ステレオカメラの計4台)と運転支援 ECU は FlexRay により接続(図 7-45 の青色に発

光しているケーブルが FlexRay)し、各センサから取込んだ車両の周辺情報を運転支援

ECU に送受信し、制動・駆動系システムを制御する構成となっている。

なお、今回は量産に使う実 ECU ではなく、システム先行開発で使用するラピッドプロ

ト環境を適用かつ一般展示用に開発したため、ECU 筐体をスケルトン化するなどしてト

ランクルームに配置し、ECU 基盤も含めた外部に見えるような搭載とした。

運転支援 ECU

図 7-45 実車(LS460)に搭載した ECU

114

周辺監視サンサ ECU

(3) 計画

’08 年度、’09 年度の評価計画を図 7-46、図 7-47 に示す。

’08 年度は AUTOSAR BSW(R2.0、R3.0)の結合評価を行い、周辺監視センサ ECU と

運転支援 ECU 各々の単体での機能評価を行った後、相互の通信接続評価を実施した。

’09 年度は JASPAR BSW(JASPAR 仕様 R1.0J)の結合評価を行い、それぞれ作成した

ECU に載せて単体評価をおこない、相互の通信接続評価を実施した。その後、実車(LS460)

での搭載・評価を実施した。

標準実装TF

標準実装 TF

トヨタチーム

サニー技研

周辺監視センサGW

周辺監視センサG

デンソーチーム

未来技術研究所

運転支援ECU

運転支援 ECU

4

5 6 7 8 9 10 11 12 1 2 3

R3.0(β版)

R3.0(1.0版)

システム、通信仕様開発

結合評価(R2.0)

ECU単体評価(R2.0)

ポーティング

図 7-46 安全制御系チーム ’08 年度日程

115

結合評価(R3.0)

評価ECU

ECU単体評価(R3.0)

ECU接続評価評価完

通信評価用

評価ECU

アプリ開発

報告書作成

図 7-47 安全制御系チーム ’09 年度日程

116

(4) 体制

’09 年度の安全制御系チームの開発体制を図 7-48 に示す。

標準実装 TF

・R1.0J

モジュール

・障害報告 etc

トヨタチーム(周辺監視センサ) デンソーチーム(運転支援 ECU)

責任者:城戸

リーダ:梶尾

・指示

・報告

サニー技研

田代、渡辺、山田

米田、中本

図 7-48 安全制御系チーム ’09 年度開発体制

117

・システム通信仕様

・ECU 単体評価仕様

・ECU 接続評価仕様

・質疑応答

・開発進捗

・運転支援 ECU

責任者:岩井

リーダ:佐藤

・指示

・報告

未来技術研究所

船曳、岡田

高木、服部、野中、植村

(5) 評価結果

a JASPAR BSW 評価結果

’09 年度は JASPAR BSW(R1.0J)を利用することにより、’08 年度に利用した対

AUTOSAR BSW(R3.0)に比べて性能を改善することができた。結果を表 7-13 に示す。

表 7-13 JASPAR BSW(R1.0J)の性能結果

評価項目 AUTOSAR BSW(R3.0)

’08 年度

118

JASPAR BSW(R1.0J)

’09 年度

CPU 負荷 4.32% 3.45% ▲20%

ROM 容量 45Kbyte 26Kbyte ▲42%

RAM 容量 5.6Kbyte 4.4Kbyte ▲21%

b JASPAR ツール評価結果

プロファイル、クラスタに対応した JASPAR ツールを適用することで、コンフィグレー

ション設定項目数を 63%削減、設計の効率化を図ることができた(表 7-14)。

表 7-14 ツール設定項目数

評価項目 AUTOSAR BSW(R3.0)

’08 年度

JASPAR BSW(R1.0J)

’09 年度

設定項目数 320 120 ▲63%

c プロセス評価結果

JASPAR BSW(R1.0J)を利用した開発において、表 7-15 のように質疑および障害が発

生した。’08 年度に比べて、質疑および障害が減っており、国プロ推進 WG 参加メンバが

開発する JASPAR BSW の品質がスキル(図 7-49)とともに改善・向上していると推定

できる。

表 7-15 質疑および障害発生件数

項目質疑障害

’09 年度 JASPAR BSW(R1.0J) 11 件 3件

’08 年度 AUTOSAR BSW(R3.0) 55 件 38 件

図 7-49 ’09 年度国プロ推進 WG 継続参加メンバのスキル変化

(プロセス TF 提供:ETSS スキル診断結果より)

119

d ラピッド環境評価結果(運転支援 ECU)

後述するシステム評価において、JASPAR BSW を搭載したラピッド環境(運転支援

ECU)は実車上で正しく動作することが確認でき、ラピッド環境上においても JASPAR

BSW が利用可能であることが確認できた。

ただし、V850/PH03 に実装された JASPAR BSW と比較すると、CPU 性能面において

ラピッド環境は V850/PH03 と比較して格段に高いが、全体としての処理速度は CPU 性

能ほどの差異が見られない。特に、受信処理時間において差異が見られる。これはラピッ

ド環境が LinuxOS 上で動作しており、AUTOSAR OS が搭載された JASPAR BSW より

もリアルタイム性能が劣るため、受信タスク起床に時間がかかっていることが原因である

(表 7-16)。

今回のシステムではリアルタイム性能が厳しく求められなかったため問題が無かったが、

リアルタイム性能が要求されるシステムにおいては、リアルタイム OS への換装が必要で

ある。

表 7-16 CAN 送受信処理時間比較表

項目 V850/PH03 ラピッド環境

送信処理時間〔μsec〕 10.080 2.582

受信処理時間〔μsec〕 11.190 303.972

送信完了割込み時間〔μsec〕 5.987 4.620

受信割込み時間〔μsec〕 14.177 14.177

120

e システム評価結果

実車にて、運転支援システムのレーダークルーズコントロール(全車速追従機能付き)

(図 7-50)の評価・実証を行った。

図 7-51 にその様子を示す。図中、先行車に追従する後方の車両が今回 JASPAR 成果を

適用した車両である。

レーダークルーズコントロール(全車速追従機能付き)の性能評価を、実装データを計

測し、評価を実施したが(加速時(図 7-52)、減速時(図 7-53))、量産の運転支援シス

テムと同等の追従性能を確認することできた。

図 7-50 レーダークルーズコントロール(全車速追従機能付き)

図 7-51 実車(LS460)にて動作検証

121

図 7-52 検証結果(レーダークルーズコントロール追従走行加速時)

図 7-53 検証結果(レーダークルーズコントロール追従走行減速時)

122

(6) まとめ

JASPAR 成果物である JASPAR BSW(R1.0J)、JASPAR FlexRay 仕様を運転支援 ECU お

よび周辺監視センサ ECU に適用した。実車にて評価・実証を行い、現行の運転支援システ

ムと同等の機能・性能を実現でき、実車に適用しても問題ないことが確認できた。

今回利用した、JASPAR BSW(R1.0J)を適用することにより、クラスタ化された効果で、

AUTOSAR BSW(R3.0)に比べリソース(ROM 容量、RAM 容量、CPU 負荷)を約 20~40%

削減することができた。具体的には、クラスタ化することによって通信ジョブやフレーム情

報といったコンフィグテーブルの最適化が可能となったことが主な要因であると考えられる。

またJASPAR BSW(R1.0J)の設計にはプロファイル、クラスタに対応した JASPAR ツー

ルを適用する事で、コンフィグレーション設定項目数を 63%削減、設計の効率化を図る事が

できた。

今後、JASPAR BSW を実開発にて適用していくには、更なる性能改善および設計から検

査工程にいたるプロセスの徹底、ドキュメントの充実などの品質改善、JASPAR プロファイ

ル・クラスタに対応したツールチェーンの完成度向上などが重要であると考えている。

123

7.4.3 ステアリング系制御

(1) システム概要

本活動で対象とするシステムは以下の通りである。

・前輪と操舵ハンドル間に機械的結合のないステア・バイ・ワイヤ・システムである。

・このシステムは電動モータにより前輪の転舵角度位置、操舵ハンドルの反力を制御する。

・前輪の転舵角度位置、操舵ハンドルの反力はそれぞれ個別の ECU により制御される。

・各 ECU は FlexRay 通信によりつながれ、分散、協調制御を行う。

・また、各 ECU は時間管理されたタイムトリガマネージメント上でアプリケーションの

処理を行う。

システム構成図を図 7-54 に示す。

図 7-54 システム構成

124

(2) 活動概要

本活動の概要を説明する。ステアリング系制御チームは、ITS 系制御チームや安全制御系

チームに対し、(ソフトウェア規模や通信容量は小さいものの、)リアルタイム制約に対する

要求が高いアプリケーションであるステア・バイ・ワイヤ・システムに標準実装 TF の成果

物である JASPAR BSW を適用する開発を通して、JASPAR BSW の開発と評価・検証を行

う。

’08 年度は JASPAR BSW の評価・検証を行うための基準となるレガシー版のソフトウェ

ア開発と評価用ソフトウェア開発を行う為の開発環境構築を行った。これを受けて’09 年度

では JASPAR 版のソフトウェア開発及び実装、さらにこれらの評価・検証を行う。

125

(3) 計画

図 7-55 に開発に着手した’08 年度からの2カ年計画を、図 7-56 に’09 年度計画を示す。

ステアリング系制御

チーム

ステアリング系

制御チーム

’08年度

126

’09年度

4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3

ECU

実験車両試作

ハード設計ハード設計

レガシー版設計/

インテグレート

まとめ報告

レガシー評価

図 7-55 ステアリング系制御チーム 2カ年計画

まとめ報告

JASPAR版設計/

インテグレート

成果

台上評価実車評価発表会

’09年

’10年

4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月

ベース部

仕様設計

アプリケーション部

仕様設計

JASPARソフトウェア開発

コーディング評価

インテグレート

コーディング評価機能試験

検証車両開発

実証実験準備走行事前確認試験走行

図 7-56 ステアリング系制御チーム ’09 年度活動計画

事業報告書作成

成果発表会

(4) 体制

本活動におけるステアリング系制御チームの開発体制を説明する。自動車メーカ、サプラ

イヤ、さらに組込みソフトウェア/ツールメーカ、半導体メーカを記載した開発体制を表

7-17 に示す。また本開発で使用した BSW の各部位の開発担当を表 7-18 に示す。

自動車メーカ

サプライヤ

組込みソフトウェアメーカ

ツールメーカ

半導体メーカ

表 7-17 ステアリング系制御チーム開発体制

日産自動車(株)

日立オートモティブシステムズ (株)

カルソニックカンセイ(株)

イーソル(株)

(株)OTSL

(株)日立情報制御ソリューションズ

NECエレクトロニクス(株)

(株)ルネサステクノロジ

表 7-18 ステアリング系制御チーム BSW 担当

BSW部位担当企業

RTE イーソル(株)

COMクラスタイーソル(株)

FlexRayクラスタイーソル(株)

OS (株)日立情報制御ソリューションズ

MCAL NECエレクトロニクス(株)

127

(5) 活動の成果

ステアリング系制御チームの JASPAR 版ソフトウェアでは以下の通信やモータ制御に関

する JASPAR 先進コンセプトを適用することで、実用性や信頼性の向上と省リソース化の両

立ができることを確認した。

� プロファイル OS

� FlexRay 通信の JASPAR 通信プロファイル

� JASPAR 通信クラスタ

� JASPAR プロファイル RTE

� JASPAR 信頼性要件

� モータ制御拡張 MCAL

以下にステアリング系制御チームで適用したプロファイル OS とモータ制御拡張 MCAL

について簡単に説明する。また、これらを含め上記の内容を適用した JASPAR 版ソフトウェ

アとレガシーソフトウェアとの比較を中心に行った評価結果も示す。

128

a プロファイル OS

ステアリング系制御チームのステア・バイ・ワイヤ・アプリケーションは、AUTOSAR

OS を用いて時刻同期(FlexRay 通信対応)の実現性を検討した結果、SC2 相当の機能が

必要であることが判明した。しかし、標準実装 TF の ’07 年度における OS 評価結果より

SC2 そのままでは負荷が重いという結果となった。そこでさらに OS の機能をプロファイ

ルし、日産自動車独自のプロファイルによる OS 仕様を策定した。また実装面でも改善を

行い、処理負荷の軽減を図った。

プロファイル OS の仕様を表 7-19 に示す。

OSEK OS

スケジュール・テーブル

スタック・モニタリング

保護フック

タイミング保護

グローバル・タイム

同期化サポート

メモリ保護

特徴

OS アプリケーション

サービス保護

高機能低

SC1

��

※SC:スケーラビリティ・クラス

表 7-19 プロファイルした OS の仕様

短

日産

ﾌﾟﾛﾌｧｲﾙ

��

SC2

��

処理時間

129

SC3

��

SC4

��

長

ハードウェア要求

高優先度割り込みタイマ

グローバル・タイム

MPU(Memory Protection Unit)

拡張 MCAL

JASPAR BSW の実用性を高めるため、標準実装 TF で開発を行うモータ制御拡張 MCAL

に対して、ステアリング系制御チームが連携して NEC エレクトロニクスと仕様策定を実

施した。

図 7-57 に示すように、拡張 MCAL のコンセプトは性能と汎用性/再利用性の両方を確

保した実用的なものを目指すことにある。

高高

性能性能性能

性能性能

低低

HEV/EV システム :HEV/EV のパワートレイン系の大型モータ

XByWire システム :Steer-By-Wire、Break-By-Wire 等の中型モータ

従来電装システム :電子制御スロットル、自動スライドドア等の小型モータ

HEV/EV

システム

低低

モータ拡張MCAL対象領域

XByWire

システム

汎用性汎用性汎用性汎用性汎用性汎用性

130

従来電装

システム

図 7-57 拡張MCAL のコンセプト

高高

ノウハウノウハウノウハウノウハウノウハウノウハウ

低低

c 評価結果

開発した車載制御システムは約 2000 項目の「障害注入含む機能試験」を合格し、従来

と同等の機能・性能を備えていることを実際の走行を含めて実証した。図 7-58 に実車走

行の様子を示す。また、前述した通信やモータ制御に関する JASPAR の先進的コンセプト

を適用することで、実用性や信頼性の向上と省リソース化の両立ができることを確認した。

図 7-58 走行シーン

以下に JASPAR BSW を適用したソフトウェア及びレガシー手法で開発したソフトウェ

ア、各々を用いて実施した各評価の比較結果を示す。

ステア・バイ・ワイヤ・システムではモータ制御、さらにその上位に転舵角度位置制御

等を行っている。そこで以下に示すような評価を実施した。

� モータ制御性能評価

� ステアリング制御性能評価

� 周波数特性評価

図 7-59 にモータ制御性能評価結果を示す。JASPAR BSW を適用したソフトウェアに

おいてもレガシー手法で開発したソフトウェアと同等の性能(回転数に応じたモータトル

ク)が出ていることが確認できる。なお、JASPAR BSW には前述のモータ制御拡張 MCAL

を適用しており、本拡張 MCAL の仕様の妥当性も確認できた。

131

低モータトルク高

レガシー版 JASPAR版

低モータ回転数高

低モータトルク高

車載制御システムの作動シーン

132

低モータ回転数高

図 7-59 モータ制御性能評価結果

図 7-60 にステアリング制御性能評価結果を示す。操舵ハンドル操作に応じて決められ

る前輪の指令角度に対して実確度が転舵角度位置制御により一致しており、良好な制御性

能であることが確認できる。

角度

加速度

ハンドル角度

前輪角度黄:指令角度青:実角度

車両横加速度

図 7-60 ステアリング制御性能結果

時間

図 7-61 に車両の周波数特性評価結果を示す。この評価は車両のステアリング特性を評

価する上で代表的なものであり、操舵ハンドル角度に対する車両ヨーレート(旋回方向へ

の回転角の変化速度)の応答を横軸に周波数、縦軸にゲインと位相差で示している。ステ

アリング応答性が悪いと操舵ハンドル操作に対して車両ヨーレートが遅れ位相差が大きく

なる。

評価結果を見ると、JASPAR BSW を適用したソフトウェアはレガシー手法で開発した

ソフトウェアと同等の性能(周波数に応じたゲインや位相差)が出ていることが確認でき

る。これらの結果から JASPAR BSW を適用したソフトウェアは、モータ制御、ステアリ

ング制御ともに十分な性能であると言える。

低ゲイン高

大位相差小

133

・・・レガシー版

・・・JASPAR版

低周波数高

図 7-61 周波数特性結果

d リソース評価結果

図 7-62 は ROM/RAM における BSW 領域とアプリケーション領域の割合である。レガ

シーソフトウェアに対して JASPAR BSW は 20p~33p アップと BSW 領域が比較的大き

な割合を占める結果となった。

仕様

JASPAR

版

レガシー

版

レガシー版

との差

※p:ポイント

ROM

20p

134

40%

BSW領域

アプリケーション領域

RAM

20% 19%

33p

52%

図 7-62 BSW 領域とアプリケーション領域の割合

しかし、図 7-63 のアプリケーションと BSW を足し合わせたトータルでのリソース評

価結果を見ると、限られた CPU リソース内で車載制御システムのソフトウェアが実現で

きていることが確認できる。リソース差は 11p~17p であり、レガシーソフトウェアが性

能優先で開発されていることを考えても、汎用性/再利用性に優れる JASPAR BSW の性

能は十分と判断する。特にリアルタイム制約に対する要求の高いステア・バイ・ワイヤ・

システムにおいては、処理負荷における実用性が確認できたことを評価する。

仕様

JASPAR

版

レガシー

版

レガシー版

との差

※p:ポイント

処理負荷

11p

135

ROM

13p

RAM

78% 45% 75%

67% 32% 58%

図 7-63 リソース評価結果

17p

(6) まとめ

a ’09 年度のまとめ

’09 年度の活動は JASPAR BSW をステア・バイ・ワイヤ・システムへ適用することを

中心に行った。また、’08 年度に開発したレガシー版ソフトウェアを基準とした比較/評

価を行うことで、今後の実用化に向けた課題を整理した。

今回用いた評価用ソフトウェア構成を図 7-64 に示す。本図通信部の各モジュールの中

で灰色のモジュールがプロファイル対象であることを示し、さらに赤色の実線枠で各々が

クラスタ化されていることを示す。緑色は JASPAR FlexRay 信頼性要件として追加され

た機能を示す。

図 7-64 評価用ソフトウェア構成

136

本活動(2カ年)全体のまとめ

ステアリング系制御チームでは、ステア・バイ・ワイヤ・システムに標準実装 TF の成

果物である JASPAR BSW を適用する開発を通して、JASPAR BSW の開発と評価・検証

を行った。初年度の’08 年度は JASPAR BSW の評価・検証を行うための基準となるレガ

シー版のソフトウェア開発と評価用ソフトウェア開発を行う為の開発環境の構築、さら

に’09 年度実車検証に向けて ECU および実験用車両の試作も実施した。検証フェーズであ

る’09 年度では JASPAR BSW をステア・バイ・ワイヤ・システムへ適用し、評価・検証

を行った。

ステア・バイ・ワイヤ・システムはモータ制御、さらにその上位に転舵角度位置制御、

反力制御、ECU 間の分散/協調制御と複雑なソフトウェア構成となっている。さらに基

本構成を同じとする複数の ECU によりシステムが成立している。そのため、’08 年度に開

発したレガシー版のソフトウェアにおいても CPU の処理負荷が 60%超となっており、

JASPAR BSW 適用に向けて、より効率的で実用的な(使用性の高い)仕様にしていくこ

とが重要となっていた。一方で、実車両での検証を実施するため、信頼性の向上を図る必

要もあった。これらより、以下の点に留意して仕様を策定した。

� 効率化を目的として以下の内容を適用する。

・プロファイル OS

・FlexRay 通信の JASPAR 通信プロファイル

・JASPAR 通信クラスタ

・JASPAR プロファイル RTE

� 信頼性を目的として以下の内容を適用する。

・JASPAR FlexRay 信頼性要件

� 実用性を目的として以下の内容を適用する。

・モータ制御拡張 MCAL

これらプロファイルやクラスタ、拡張 MCAL の適用に加え、OS のさらなる改良を行う

といった活動を通して、信頼性要件を付加しても、本システムでの成立性に目処を立てる

ことができた。このように車載制御システムが十分な機能/性能を実現できていることか

らも JASPAR BSW の有用性が確認できた。

ツールに関しては、AUTOSAR 仕様の理解が必要である等の課題もあるが、多数あるパ

ラメータが一括で設定ができる等の利便性があり、本活動において効率的開発へ貢献でき

た。

137

また、本活動を通して、自動車、部品、組み込みソフトウェア、半導体、ツールの各メ

ーカが車載制御システムの開発実績を積み、メーカ間のネットワークを広げることができ

たのは大変有意義であった。

一方、今回の実証では比較的大きなシステムへの適用であったこと、また選定当時トッ

プクラスの性能を持つマイコンを使用したこと、一部機能ではコンプレックスドライバを

使用していることなど、今回限定的となっている部分もあり、中/小規模車載電子制御シ

ステムへの広範囲な普及を考えると、さらなる BSW の改善(リソースの削減)ができる

ことが望ましい。

138

7.4.4 ITS 系制御

(1) システム概要

本活動で対象とするシステムを説明する(図 7-65 参照)。

アダプティブ・クルーズ・コントロール(ACC)とは、高速道路または加速・減速の繰り

返しの少ない自動車専用道路などで運転するとき、アクセルペダルやブレーキペダルを踏ま

なくても、先行車との車間距離を一定に保ちながら、定速で走行できるシステムである。

先行車が減速したときは、車間距離を一定に保ちながら自動で減速する。また、先行車が

加速したときは、車間距離を保ちながら自動で設定車速まで加速する。車間距離は走行車速

に比例して制御され、自車の速度が遅くなれば車間距離は短くなり、自車の速度が速くなれ

ば車間距離は長くなる。

なお、先行車の急な減速などにより、車間距離を一定の間隔に保てないときは、警告ブザ

ーと警告表示で運転者に知らせる。

ACC の車間距離の測定は、レーダーセンサから発信した電波を先行車に当てることにより

行う。

ACC システムにより、高速クルージング時の運転手の負担を軽減する。

139

図 7-65 ACC システム関連の表示および操作スイッチ 3

次に ACC 機能による車両の挙動を説明する(図 7-66 参照)。

①定速走行

アクセルペダルを踏まなくても、セットした車速(45~100km/h)で、定速走行をする。

②減速走行

セットした車速より遅い先行車が現れたときは、先行車の速度に合わせて自動で減速す

る。先行車の速度まで減速したあとは、先行車の速度変化に合わせた追従走行をする。な

お、先行車の急な減速や、他車の割り込みなどで、先行車と接近しすぎたときは、接近警

報(警告ブザーと警告表示)が作動する。

3・MAIN スイッチ:ACC システムを”ON”または”OFF”にするときに使用する。

・RES/ACCEL スイッチ:ACC システム解除後、セットした設定車速に戻すとき、また、

設定車速を上げるときに使用する。

・SET/DECEL スイッチ:設定車速をセットするとき、また、設定車速を下げるときに使用

する。

・CANCEL スイッチ:ACC システムを解除するときに使用する。

・ディスタンススイッチ:先行車との車間距離を調整するときに使用する。

140

③追従走行

セットした車速(45~100km/h)を上限として、先行車の速度に応じた車間距離を保ち

ながら追従走行をする。

④加速走行

先行車がいなくなると、セットした車速(45~100km/h)まで自動的にゆっくり加速す

る。セットした速度まで加速したあとは、定速走行をする。

141

図 7-66 ACC 機能による車両の挙動例

142

次に、ACC システムを実現する部品を図 7-67 に示す。

ACC ECU は車両のレーダーセンサと接続されており、先行車の検出と先行車との車間距

離の算出を行っている。加えて、スロットルアクチュエータ(走る)を制御するエンジン制

御 ECU とブレーキアクチュエータ(止まる)を制御するブレーキ制御 ECU と CAN 通信を

行い、エンジン制御 ECU とブレーキ制御 ECU と ACC ECU が連携して、車両の加速、減

速制御を実現する。よって、ACC ECU では車載ネットワークの通信を含めた応答性、信頼

性が重要である。

ブレーキ

アクチュエータ

スロットル

アクチュエータ

ミリ波レーダ

メーター

図 7-67 ACC システムを実現する部品

143

ACC ECU

運転者は常にまわりの状況に目を配りながら、メーターを見て、自動車を運転する。メー

ターシステムは、スピードメーターやタコメーターをはじめとして、燃料計、水温計などの

計器類だけでなく、オートマチック車のシフトポジション、車両の故障有無、パーキングブ

レーキ、ランプの点灯表示など色々な情報を表示する(図 7-68)。現在はこれらの情報に加

えて、マルチインフォメーションディスプレイを利用して、車両の様々な情報や車両の異常

を伝える機能を有する(図 7-69)。メーターシステムを通じて運転者は自動車の走行状況を

正しく把握できる。

図 7-68 車両の様々な情報を表示するメーターシステムの例

図 7-69 車両の様々な情報を表示するマルチインフォメーションシステムの例

よって、メーターシステムは、車載ネットワークを通じて、車の情報が集約される特徴を

もち、車の頭脳的役割を担うボディ電装系システムの代表的存在である。メーターシステム

を制御するソフトウェアは他システムとの通信量も多く、ソフトウェア規模も大きい。ACC

システムとの関係に着目すると、メーターシステムは運転者から ACC システムの設定を行

144

うスイッチ類からの情報取得とともに、ACC ECU と CAN 通信を行い、ACC システムの情

報をマルチインフォメーションディスプレイ表示で運転者に提供する役割を担っている。

本活動では、ACC システムとメーターシステムを試作対象とした。ACC システムとメー

ターシステムと他量産システムとの構成を図 7-70 に示す。

ミリ波レーダ

エアバック

システム

ドア

システム

・・・

図 7-70 システム構成

145

スロットル

アクチュエータ

エンジン

制御ECU

試作対象

ACC

ECU

試作対象

メーター

システム

ブレーキ

アクチュエータ

ブレーキ

制御ECU

ACC作動状態表示

ACC ECU で動作するソフトウェアを ACC 制御ソフトウェアといい、メーターシステム

で動作するソフトウェアをメーター制御ソフトウェアという。ACC 制御ソフトウェアは

ACC 制御アプリケーションと BSW から成り立つ。メーター制御ソフトウェアはメーター制

御アプリケーションと BSW から成り立つ(図 7-71)。

本活動では、標準実装 TF にて開発した AUTOSAR BSW(R3.0)を採用した ACC 制御ソフ

トウェアとメーター制御ソフトウェアを開発し、車両における BSW の影響を確認する。

加えて、標準実装 TF にて開発した JASPAR 版 BSW を採用した ACC 制御ソフトウェア

とメーター制御ソフトウェアを開発し、車両における BSW の影響を確認し、AUTOSAR

BSW(R3.0)と JASPAR BSW(R1.0J)との比較を行い、JASPAR BSW(R1.0J)の優位性を確認

する。

ACC ECU

ACC制御ソフトウェア

ACC制御アプリケーション

BSW(基本ソフトウェア)

146

メーターECU

メーター制御ソフトウェア

メーター制御アプリケーション

BSW(基本ソフトウェア)

図 7-71 ACC 制御ソフトウェア、メーター制御ソフトウェア構成

(2) 計画

本活動の全体計画を図 7-72 に示す。

’08 年度はレガシーアプリケーションを分析し、基本ソフトウェアを導入できる制御アプ

リケーションの開発を行い、制御アプリケーションの一部分と標準実装 TF にて開発した

AUTOSAR BSW(R3.0)をインテグレートし部分評価した。

’09 年度は制御アプリケーションと標準実装 TF にて開発した AUTOSAR BSW(R3.0)をイ

ンテグレートし単体評価と実車評価を行った。加えて、同じ制御アプリケーションと標準実

装 TF にて開発した JASPAR BSW(R1.0J)をインテグレートし単体評価と実車評価を行った。

’08年度

147

’09年度

分担 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3

ACC ECU

試作・評価

メーター

システム

試作・評価

実車評価

レガシー

アプリ分析

部分アプリ設計/

実装/インテグ

AUTOSAR

BSW評価

部分アプリ設計/

実装/インテグ

AUTOSAR

BSW評価

結合

評価

結合

評価

’08年度まとめ報告

メーター・ACC

結合テスト

通信テスト

アプリ設計/

実装/インテグ

アプリ設計/

実装/インテグ

図 7-72 ITS 系制御チーム全体計画

結合

評価

(AUTOSAR BSW使用)

JASPAR

BSW評価

JASPAR

BSW評価

車両準備

イン

テグ

結合

評価

(AUTOSAR BSW使用)

結合

評価

(JASPAR BSW使用)

イン

テグ

結合

評価

(JASPAR BSW使用)

’ 09年度まとめ報告

メーター・ACC

実車評価

(AUTOSAR BSW使用と

JASPAR BSW使用)

(3) 体制

本活動の体制を図 7-73 に示す。

ACC 制御アプリケーション

開発チーム

サプライヤ:

株式会社ホンダエレシス

組込みソフトウェアメーカ:

株式会社永和システムマネジメント

株式会社ヴィッツ

半導体メーカ:

株式会社ルネサステクノロジ

自動車メーカ: 株式会社本田技術研究所

図 7-73 ITS 系制御チーム開発体制

148

メーター制御アプリケーション

開発チーム

サプライヤ:

日本精機株式会社

組込みソフトウェアメーカ:

株式会社ヴィッツ

半導体メーカ:

富士通マイクロエレクトロニクス株式会社

(4) 評価ソフトウェアの概略

a ACC 制御ソフトウェア概要

本活動の対象である ACC 制御ソフトウェアに関して説明する。

1) ACC 制御アプリケーション構成

ACC 制御アプリケーションの機能ブロックを表 7-20 に示す。

表 7-20 ACC 制御アプリケーションの機能ブロック

分類機能ブロック名称 ’08 年度評価対象 ’09 年度評価対象

入力機能アナログセンサ入力

機能

149

- ○

入出力機能高速 CAN 機能 ○ ○

ポート出力機能 - ○

シリアル通信機能 ○ ○

システム制御機能システム制御機能 ○ ○

サブシステム制御

機能

レーダーセンサ機能 ○ ○

ACC 機能 ○ ○

追突軽減ブレーキ

(CMBS)機能

※CMBS:Collision Mitigation Brake System

- ○

制御統合機能 - ○

表示機能 - ○

フェールマネージャ - ○

2) AUTOSAR BSW(R3.0)構成

全体評価(’09 年度評価)における ACC 制御ソフトウェアの AUTOSAR BSW(R3.0)

構成を表 7-21 に示す。

表 7-21 ACC 制御ソフトウェアの AUTOSAR BSW(R3.0)構成一覧

評価対象クラスタ提供メーカ概要

RTE RTE 永和システムアプリケーションと BSW のイ

ンタフェースを行う

通信 COM 未来技研 CAN 通信を行う

PDUR

CANSm OTSL

CANIf

CAN ドライバルネサス

システム OS ヴィッツ

MCAL ADC ルネサス AD 変換を行う

Complex

Driver

DIO 汎用入出力を行う

PORT ポートの初期設定を行う

MCU MCU の制御を行う

GPT 汎用タイマの制御を行う

シリアル通信ホンダエレシス

永和システム:株式会社永和システムマネジメント

未来技研:株式会社未来技術研究所

OTSL:株式会社 OTSL

ルネサス:株式会社ルネサステクノロジ

ヴィッツ:株式会社ヴィッツ

ホンダエレシス:株式会社ホンダエレシス

150

3) JASPAR BSW(R1.0J)構成

全体評価(’09 年度評価)における ACC 制御ソフトウェアの JASPAR BSW(R1.0J)

構成を表 7-22 に示す。

表 7-22 ACC 制御ソフトウェアの JASPAR BSW(R1.0J)構成一覧

評価対象クラスタ提供メーカ概要

RTE RTE 永和システムアプリケーションと BSW のイ

ンタフェースを行う

通信 COM クラスタ未来技研 CAN 通信を行う

CAN クラスタ OTSL

システム OS ヴィッツ

MCAL ADC ルネサス AD 変換を行う

Complex

Driver

DIO 汎用入出力を行う

PORT ポートの初期設定を行う

MCU MCU の制御を行う

GPT 汎用タイマの制御を行う

シリアル通信ホンダエレシス

拡張 MCAL デバッグモニタ富士通

永和システム:株式会社永和システムマネジメント

未来技研:株式会社未来技術研究所

OTSL:株式会社 OTSL

ルネサス:株式会社ルネサステクノロジ

ヴィッツ:株式会社ヴィッツ

ホンダエレシス:株式会社ホンダエレシス

富士通:富士通マイクロエレクトロニクス株式会社

151

メーター制御ソフトウェア概要

本活動の対象であるメーター制御ソフトウェアに関して説明する。

1) メーター制御アプリケーション構成

メーター制御アプリケーションの機能ブロックを表 7-23 に示す。

152

表 7-23 メーター制御アプリケーションの機能ブロック

分類機能ブロック名称 ’08 年度評価対象 ’09 年度評価対象

入力機能システム入力機能 ○ ○

燃料センサ入力機能 - ○

外気温センサ入力機

能

153

- ○

スイッチ入力機能 - ○

警告入力機能 - ○

タイマ入力機能 - ○

入出力機能高速 CAN 機能 ○ ○

低速 CAN 機能 ○ ○

システム制御機能システム制御機能 ○ ○

サブシステム制御

機能

スピード機能 ○ ○

タコ機能 ○ ○

TEMP 機能 - ○

燃料機能 - ○

インジケータ機能 - ○

アラーム機能 - ○

調光機能 - ○

LCD 表示制御機能 - ○

ODO/TRIP 機能 - ○

外気温機能 - ○

経過時間機能 - ○

平均車速機能 - ○

平均燃費機能 - ○

瞬間燃費機能 - ○

航続可能距離機能 - ○

ACC/CMBS 機能 - ○

スマートエントリー

機能

- ○

SH-AWD 機能 - ○

Sleep/Wakeup 機能 - ○

2) AUTOSAR BSW(R3.0)構成

全体評価(’09 年度評価)におけるメーター制御ソフトウェアの AUTOSAR

BSW(R3.0)構成を表 7-24 に示す。

表 7-24 メーター制御ソフトウェアの AUTOSAR BSW(R3.0)構成一覧

評価対象クラスタ提供メーカ概要

RTE RTE 永和システムアプリケーションと BSW のイ

ンタフェースを行う

通信 COM eSOL CAN 通信を行う

PDUR 未来技研

CANSm OTSL

CANIf

CAN ドライバ富士通

システム OS ヴィッツ

MCAL ADC 富士通 AD 変換を行う

Complex

Driver

PWM パルス幅変調出力を行う

DIO 汎用入出力を行う

PORT ポートの初期設定を行う

MCU MCU の制御を行う

GPT 汎用タイマの制御を行う

ICU インプットキャプチャ

SMC NS ステッピングモータの制御を

行う

LCD LCD の制御を行う

DAC スピーカーの制御を行う

永和システム:株式会社永和システムマネジメント

eSOL:イーソル株式会社

未来技研:株式会社未来技術研究所

OTSL:株式会社 OTSL

富士通:富士通マイクロエレクトロニクス株式会社

ヴィッツ:株式会社ヴィッツ

NS:日本精機株式会社

154

3) JASPAR BSW(R1.0J)構成

全体評価(’09 年度評価)におけるメーター制御ソフトウェアの JASPAR BSW(R1.0J)

構成を表 7-25 に示す。

表 7-25 メーター制御ソフトウェアの JASPAR BSW(R1.0J)構成一覧

評価対象クラスタ提供メーカ概要

RTE RTE 永和システムアプリケーションと BSW のイ

ンタフェースを行う

通信 COM クラスタ eSOL CAN 通信を行う

CAN クラスタ OTSL

システム OS ヴィッツ

MCAL ADC 富士通 AD 変換を行う

Complex

Driver

PWM パルス幅変調出力を行う

DIO 汎用入出力を行う

PORT ポートの初期設定を行う

MCU MCU の制御を行う

GPT 汎用タイマの制御を行う

ICU インプットキャプチャ

SMC NS ステッピングモータの制御を

行う

LCD LCD の制御を行う

DAC スピーカーの制御を行う

拡張 MCAL デバッグモニタ富士通

永和システム:株式会社永和システムマネジメント

eSOL:イーソル株式会社

OTSL:株式会社 OTSL

富士通:富士通マイクロエレクトロニクス株式会社

ヴィッツ:株式会社ヴィッツ

NS:日本精機株式会社

155

(5) 評価結果

a ACC 制御ソフトウェアの評価概要

ACC 制御ソフトウェアに対する評価内容・結果を説明する。

AUTOSAR BSW(R3.0)を利用した ACC 制御ソフトウェアと JASPAR BSW(R1.0J)を利

用した ACC 制御ソフトウェアにおいて、機能要件、システム成立性、非機能要件を評価

した。

� 機能要件:HILS(シミュレーションを活用して、自動車用 ECU の検証を行う装置)・

テスト用機材などを利用して、AUTOSAR BSW(R3.0)を利用した ACC 制御ソフトウ

ェアと JASPAR BSW(R1.0J)を利用した ACC 制御ソフトウェアが量産 ACC システ

ムと同等の機能・応答性を実現することを検証した。

� システム成立性:AUTOSAR BSW(R3.0)を利用した ACC 制御ソフトウェアと

JASPAR BSW(R1.0J)を利用した ACC 制御ソフトウェアにおいて、処理の時間制約

違反が発生しないかなど、システムとして成立していることを検証した。

� 非機能要件:量産 ACC ソフトウェア、AUTOSAR BSW(R3.0)を利用した ACC 制御

ソフトウェア、JASPAR BSW(R1.0J)を利用した ACC 制御ソフトウェアにおいて、

性能・使用リソースなどを比較評価した。

156

メーター制御ソフトウェアの評価概要

メーター制御ソフトウェアに対する評価内容・結果を説明する。

AUTOSAR BSW(R3.0)を利用したメーター制御ソフトウェアと JASPAR BSW(R1.0J)

を利用したメーター制御ソフトウェアにおいて、機能要件、システム成立性、非機能要件

を評価した。

� 機能要件:量産車両通信データを利用して、AUTOSAR BSW(R3.0)を利用したメータ

ー制御ソフトウェアと JASPAR BSW(R1.0J)を利用したメーター制御ソフトウェア

が量産システムと同等の機能を実現することを検証した。

� システム成立性:AUTOSAR BSW(R3.0)を利用したメーター制御ソフトウェアと

JASPAR BSW(R1.0J)を利用したメーター制御ソフトウェアにおいて、処理の時間制

約違反が発生しないかなど、システムとして成立していることを検証した。

� 非機能要件:AUTOSAR BSW(R3.0)を利用したメーター制御ソフトウェア、JASPAR

BSW(R1.0J)を利用したメーター制御ソフトウェアにおいて、性能・使用リソースな

どを比較評価した。

157

c 実車の評価概要

本活動の対象である ACC 制御ソフトウェア、メーター制御ソフトウェアを実車に適応し

た JASPAR カーを試作した。JASPAR カーに対する評価内容・結果を説明する。

図 7-75 では ACC システムによる追従走行時の車速制御結果を示す。レーダーセンサの情

報から ACC 制御ソフトウェアで算出された目標車速に対して、自車の車両の加速が行われ、

目標車速となるように制御されていることがわかる。

図 7-74 ACC システムによる車速制御結果(追従走行)

社内テストコースにて、ACC システム動作時の自車の速度変化、先行車と自車との距離、

自車の加減速G、メーターシステムへの表示などを同車種の量産車両と JASPAR カーを比

較し、運転者のフィーリングの違いなどを確認し、量産車両と JASPAR カーの機能が同等

レベルであることを確認した。

社外テストコースにて、デモ走行を実施した(図 7-75)。

158

図 7-75 デモ走行風景

159

d 拡張 MCAL

ITS 系制御チームは JASPAR BSW の実用性確認のため、標準実装 TF で開発したデバ

ッグモニタ拡張 MCAL を採用した。ACC 制御ソフトウェア、メーター制御ソフトウェア

に同じデバッグモニタ拡張 MCAL を組み込み、外部デバッグツールとしてパソコンとシ

リアル通信で接続し、規定されたインタフェースコマンドを用いて制御ソフトウェア情報

の読み出し、書き込みができた(図 7-76)。これにより、拡張 MCAL の汎用性/再利用

性を確認できた。

試作対象

ACC

ECU

試作対象

メーター

システム

デバッグモニタ拡張MCALを組み込み

シリアル通信

図 7-76 デバッグモニタ概略

160

外部のパソコンから、

規定のインタフェースコマンドを用いて、

制御ソフトウェアの情報読み出し、

書き込みができることが確認できた

e BSW 評価結果

AUTOSAR BSW(R3.0)を利用した ACC 制御ソフトウェアと JASPAR BSW(R1.0J)を利

用した ACC 制御ソフトウェアにおいて、BSW 性能改善結果を表 7-26 に示す。JASPAR

BSW(R1.0J)は AUTOSAR BSW(R3.0)に比べて、性能が改善されたことがわかる。

表 7-26 BSW 性能改善結果

評価項目 AUTOSAR BSW(R3.0)

’08 年度

161

JASPAR BSW(R1.0J)

’09 年度

CPU 負荷 44.00% 26.46% ▲39%

ROM 容量 87.3Kbyte 53.6Kbyte ▲38%

RAM 容量

(スタック使用量除く)

※▲は改善率を表す。

4.70Kbyte 1.66Kbyte ▲64%

AUTOSAR BSW(R3.0)を利用した ACC 制御ソフトウェアと JASPAR BSW(R1.0J)を利

用した ACC 制御ソフトウェアにおいて、BSW、RTE が占めるリソース消費割合を図 7-77、

図 7-78 に示す。

[KByte]

500

400

300

200

100

0

AUTOSAR

BSW(R3.0)利用

JASPAR

BSW(R1.0J)利用

アプリケーション RTE BSW

図 7-77 ACC 制御ソフトウェア ROM 容量

25%

[KByte]

15

10

5

0

AUTOSAR

BSW(R3.0)利用

162

JASPAR

BSW(R1.0J)利用

アプリケーション RTE BSW

図 7-78 ACC 制御ソフトウェア RAM 容量

17%

(6) まとめ

本活動では制御アプリケーションと標準実装 TF にて開発した AUTOSAR BSW(R3.0)を

インテグレートし単体評価と実車評価をした。加えて、同じ制御アプリケーションと標準実

装 TF にて開発した JASPAR BSW(R1.0J)をインテグレートし単体評価と実車評価をした。

’08 年度の活動では、AUTOSAR BSW(R3.0)を利用し、部分評価した結果、ソフトウェア

モジュールの完成度とソフトウェアモジュールの性能に課題があった。’09 年度の活動では、

クラスタやプロファイルを規定した JASPAR 仕様とソフトウェアメーカの技術力向上によ

り、モジュールの完成度が向上し、インテグレーション時の後戻り作業を減らすことができ

た。加えて、JASPAR BSW(R1.0J)を利用した制御ソフトウェアは AUTOSAR BSW(R3.0)

を利用した制御ソフトウェアに比べ、制御系システム(ACC)、ボディ電装系システム(メ

ーター)にかかわらず、性能、使用リソース面で大幅な改善が見られ、JASPAR BSW(R1.0J)

の有用性が実証できた。

本活動によって、標準実装 TF にて開発した車載制御基盤ソフトウェアが、要件の異なる

制御系システム(ACC)とボディ電装系システム(メーター)の双方において従来と同等の

機能を実現できていることを実証できた。

車載制御基盤ソフトウェアの量産システムへの実用を考えると、現時点では開発した基盤

ソフトウェアを継続的に保守できる体制が整っておらず、会社の垣根を超えて共通に利用し

ていくことができない。今後の課題として、車載制御基盤ソフトウェアの量産システムへの

実用に向け、性能の向上だけでなく、品質保証を継続的に維持する仕組み・枠組み、基盤ソ

フトウェアを共通で活用していくプロセスの確立が望まれる。

163

7.4.5 公開実証実験

(1) 開催趣旨

一般社団法人JASPARは経済産業省支援の下、共通領域である高信頼な車載制御共通基盤

ソフトウェアについて、業界横断的に共同開発した。高機能の次世代自動車の開発競争が激

しさを増す中、コストを抑えながら車載ソフトウェアの機能と信頼性を高め、日本の自動車

関連産業の国際競争力強化を図る狙いがある。

今回の公開実証実験については、産業界への普及啓蒙を通じて、事業成果物である車載制

御用基盤ソフトウェアや開発ツール、分析・評価を行ったソフトウェアエンジニアリング手

法等の普及を促し、自動車等の製造業及び組込みソフトウェア産業の活性化を促進すること

を目的とする。

(2) 公開実証実験の概要

主催:経済産業省、一般社団法人 JASPAR

開催日:2010 年 2 月 4 日(木)

・ 9:00~ 9:20 事業成果説明会(日本科学未来館イノベーションホール)

・ 9:00~10:30 実車によるデモンストレーション(青海西臨時駐車場)

・14:15~16:30 技術セミナー (日本科学未来館みらい CAN ホール)

※ロビー展

開催日:2010 年 2 月 5 日(金)~2 月 12 日(金)

場所 :経済産業省本館財務省側1階ロビー

概要 :パネル展示、映像資料上映、メーターユニット・ECU 展示

164

(3) 実施状況報告

a 事業成果説明会

映像資料等を用いて本事業概要を説明した。

165

実車によるデモンストレーション

本事業で作成した車載制御共通基盤ソフトウェアを適用した評価用ソフトウェアを搭載

した実車によるデモンストレーションを実施した。

経済産業省より近藤洋介大臣政務官等にご出席いただき、一部の方にはデモ車両に同乗、

ステアリング系制御システムを実際にご操作いただいた。

それにより、車載制御共通基盤ソフトウェアに適用したステアリング系制御システムが

従来と同等の機能・性能を備えている検証結果を、実際の走行を通じてあらためて確認す

ることができた。

【主な出席者】

組織名所属・役職等

経済産業省

IPA/SEC

JASPAR

(各社役員)

JASPAR 理事

166

氏名

(敬称略)

大臣政務官近藤洋介

商務情報政策局局長石黒憲彦

商務情報政策局情報処理振興課課長東條吉朗

独立行政法人情報処理推進機構理事長西垣浩司

ソフトウェア・エンジニアリング・センター所長松田晃一

日産自動車㈱副社長山下光彦

本田技研工業㈱会長青木哲

㈱デンソー副社長徳田寛

豊田通商㈱専務取締役髙梨建司

イーソル㈱専務取締役長谷川勝敏

㈱チェンジビジョン代表取締役社長平鍋健児

㈱サニー技研代表取締役社長上月富夫

理事(トヨタ自動車㈱常務役員) 宮田博司

理事(㈱本田技術研究所常務取締役) 川口祐治

理事(豊田通商㈱執行役員

兼㈱豊通エレクトロニクス代表取締役社長)

岡本康

顧問(トヨタ自動車㈱顧問兼富士通テン副社長) 重松崇

【参加メディア数】

種別取材数報道数詳細(報道されたもの)

テレビ 5 2 NHK、TV 東京

(昼のニュース、ワールドビジネスサテライト)

新聞 7 5 日経、日経産業、中部経済、中日、

サンケイビジネスアイ

業界紙 3 4 日刊工業、電波新聞、日刊自動車新聞、交通毎日新聞

専門雑誌 5 2 EDN Japan、日経 BP Tech-On!(Web 記事)

合計 20 13

167

c 技術セミナー

一般を対象とし、技術セミナーを実施した。

本事業でプロジェクトを先導してきた主査、副主査、TF リーダが講師となり、産業界

を初めとする多方面からの参加者に対し、本事業の内容および成果について講演、理解い

ただくことができた。また、併設された展示コーナーでも活発に質問、意見等をいただく

ことができた。

【参加状況】

項目申込数来場数

事前申込 148 100

当日申込 7 7

合計 155 107

168

7.4.6 ’09 年度の活動総括

’08 年度は選定した3つのアプリケーション毎に基本部分の評価用ソフトウェアを開発し、

開発したソフトウェアに対してシステムレベルで機能要件の確認を行った。その中で

AUTOSAR 仕様の解釈の不整合やツールの不備、AUTOSAR を適用するソフトウェアの処

理負荷増大に対する危惧などの課題の抽出がなされた。

’09 年度はそれらを踏まえて JASPAR 仕様 BSW を適用した評価用ソフトウェアの開発を

行い、AUTOSAR 仕様との比較による’08 年度課題の改善確認を含む評価、検証を実施した。

評価結果は前述の3つの評価用ソフトチームの報告にある通り、JASPAR 仕様 BSW は

AUTOSAR 仕様と比較して仕様の解釈の不整合なく、特に効率性の面において優位性がある

こと、また、JASPAR 仕様 BSW を適用した各評価用ソフトウェアは従来ソフトウェアと同

等の機能/性能をシステムとして実現できていることが確認できた。

また、プロセス TF による開発進捗の見える化や開発ツールの活用により、短期間で走行

可能な評価用ソフトウェアの開発を実現することができた。

以上より標準実装 TF、開発ツール TF、プロセス TF の活動成果は実機適用を想定した評

価を通して有用であったと判断できる。

加えて、自動車、部品、ソフトウェア、半導体の各メーカが連携、分担して短期間で走行

可能な評価用ソフトウェアを開発できたことは、今後の車載制御ソフトウェア開発の水平分

業の可能性を示唆するものである。

ただし、自動車における量産開発及び JASPAR 仕様 BSW の広範囲な普及に向けては BSW、

開発ツールの更なる性能改善を継続すること、品質保証の仕組みや開発プロセスの確立が望

まれる。

169

8. 3カ年の活動総括

8.1 自動車用制御基盤ソフトウェアの仕様策定と実装評価

標準実装 TF の3カ年の活動を通じて得た成果と今後の課題について述べる。

8.1.1 3カ年の成果

(1) プロファイル・クラスタコンセプトによる車載に適した基盤ソフト仕様

AUTOSAR ソフトに比べ、性能面・信頼性面で優位性を持った車載に適した制御基盤ソフ

トウェア仕様を策定し、実装することができた。本活動で提案するプロファイル・クラスタ

コンセプトは、性能を犠牲にして汎用性に偏り気味であった AUTOASR 仕様を実開発・実

運用の視点より見直しを行い、実用に耐えうる性能を確保した基盤ソフト仕様の策定を可能

とした。性能改善効果としては、全体では目標とした AUTOSAR 仕様に対しての 10%を達

成し、多いものでは 40%の改善効果があるものもあった。特に、コストの理由から、16 ビ

ット等の低スペックマイコンを使用するボディ製品向けには、今回、策定した最小セットの

プロファイルは、非常に有効である。他の AUTOSAR 製品と混在をする場合でも、OS は必

須ではないため、ROM や RAM の消費リソースを極力抑える事が可能となる。

(2) 高信頼要件の織り込みによる優位性の確保

さらに、車載ソフトで特に重要である信頼性に関しても、安全系プロファイルにより、実

製品で必要となる FlexRay 通信での信頼性機能を予め仕様に織り込む事で FlexRay 通信シ

ステムの信頼性を確保することができた。また、本機能はマルチベンダ開発での通信システ

ム構築過程において頻繁に発生する通信トラブル回避にも有益である。また、十分ではない

が、ISO26262 等の自動車分野での機能安全規格への対応には有効である。

(3) 開発ガイドラインによる実装ノウハウの形式知化

マルチベンダでの車載ソフトウェア開発に必要となる共通領域の実装ルールや関連ノウハ

ウを開発ガイドラインとして文書化した。例えば、共通領域の実装ルールとは、ソフトウェ

ア部品間の実装インタフェースに関する決め事である。AUTOSAR 仕様では、この決め事は

競争領域と捕らえ、実際のプロジェクトで定義することを想定している。しかし、実プロジ

ェクトでは、マルチベンダで各々ソフトウェア部品を開発するケースが多く、予めルールを

定義しておかないと、ソフトウェア部品を組み合わせて BSW を仕立てる際にインタフェー

ス不整合が起こり、開発の手戻りが発生する場合が多い。そのため、本 TF の活動では、こ

れらの定義を予めガイドラインとしてルール化することで手戻りを回避すること狙いとして

いる。

また、このルールは、必ずしも自明ではなく、実際に開発を行った経験からでてくるもの

が多い。いわば暗黙知であり、本ガイドラインとはこれを形式知化したものである。本来、

日本では、これらの実装ノウハウを暗黙知としたため、すり合わせ開発が非常に得意であっ

170

た。しかし、今後の海外ベンダも巻き込んだマルチベンダ開発においては、こうした開発ガ

イドラインを活用して分業することが重要と考える。さらに、今回作成した開発ガイドライ

ンは、マルチベンダ開発での組込みソフトウェア開発の共通項も含まれているため、今回の

自動車分野だけでなく、他業界においても参考になると考える。

(4) 試作品の開発・評価作業を通してのスキル向上

3カ年を通して試作品を開発し評価を繰り返したことで、参加企業の本分野での開発スキ

ル向上が図られた。本 TF は、実開発のプレーヤーである自動車メーカ、サプライヤ、ソフ

トウェアメーカ、半導体メーカが参画しているため、試作品開発ではあるが、実際の開発に

近い体験ができたと考える。そのため、参加メンバは、それぞれの役割・立場から、議論や

検討に加わり、相互研鑽することで、自らのスキル向上に繋がったと考える。

また、各役割からメンバを選定しグループ分けを行ったため、各グループ内の議論や各グ

ループ間の議論が効率的かつ汎用的であった。その結果、本試作品開発を通じて統計的な開

発メトリクスの収集・評価を可能とし、プロセス TF への ESPR、ETSS、EPM 等の仕組み

の評価に貢献できたと推察している。

(5) 自動車メーカ・サプライヤと連携した自動車業界全体でのソフト開発の仕組み作り

本活動を通じて、自動車分野での特徴である自動車メーカとサプライヤとの密な分業開発

の課題を再認識し、そのための解決策を部分的ではあるが、自動車向け制御基盤ソフトウェ

アの要求仕様や開発ガイドラインと言った文書で具現化することができた。それらは、すり

合わせ開発を得意としてきた日本の開発スタイルをさらに発展させ、かつ、欧米の組み合わ

せ開発スタイルをうまく融合していくうえで、必要なステップであると信じている。また、

本 TF のような業界内の横断的な活動は、今後のより高度で複雑な車載電子制御システム開

発において、益々、重要になると考えている。

171

8.1.2 今後の課題

(1) 実開発への適用に向けた継続的な基盤ソフトウェア仕様の改良

前章でも述べたが、実際の製品開発に適用するためには、まだ検証が不十分であり、取り

組むべき共通課題も残っている。今回、策定した仕様を、実車評価も含めて、単体評価から

結合評価まで実施したが、期間や工数の制約上、限られた環境・条件下でしか実施できなか

ったのは否めない。本来であれば、様々な実環境を想定した上で、多くの評価を実施すべき

であるが、こうした標準化活動の場だけでは現実的ではない。そのため、一旦、標準化活動

で策定した仕様を公開し、実プロジェクトに適用・運用した上で、現場における課題を抽出

して、それを標準仕様にフィードバックすると言ったプロセスが必要である。さらに、仕様

の完成度を上げるためには、そのプロセスを数回繰り返すことが効果的である。AUTOSAR

においては、既にプロジェクトが 6 年経過しており、初版の仕様に基づいた製品化もされて

いる。恐らく、こうしたプロセスが 2 回は繰り返されていると想定する。従って、実開発に

適用できるレベルの基盤ソフトウェア仕様を完成させるためには、今後も仕様の改良は継続

的に続けていく必要がある。

(2) 機能安全規格への対応

もう一つの課題としては、昨今、高度かつ先進的な安全系システムの普及により重要とな

ってきた機能安全規格への対応が挙げられる。今回の活動においても、FlexRay 通信スタッ

クに注力し、JASPAR の考える信頼性要件を追加したが、機能安全規格への対応には十分で

ない。それは、本3カ年プロジェクトがスタートした時点では、まだ ISO26262 の仕様が公

開されていなかったため、本 TF で検討ができる状況ではなかったからである。しかし、昨

年度、WD (Working Draft、作業原案)が一般公開され、また、その要件を織り込んだ

AUTOSAR R4.0 の仕様も昨年末に公開されたため、来年度からは、具体的な検討が日本で

できる状況が整った。

172

8.2 開発環境・ツールの仕様策定と実装評価

’07 年度から取り組んだ3カ年の活動を振り返る。

’07 年度の計画として

� プラットフォームベース開発に必須となるツール群の要件策定

� ツールの妥当性検証を行うための評価基準の策定

を掲げ、以下の活動を実施した。

� AUTOSAR R2.1 仕様の開発方法論およびツールに関連する仕様の分析

� ツール群の定義と要件、要求仕様の策定とソフト設計ツール(コンフィグレータ)

のプロトタイプ開発

� 評価基準の策定

ソフト設計ツールはグラフィカル・ユーザ・インタフェースを持たず、コマンドライン入

力により設定する使いにくいものであった。’07 年度の課題としてユーザビリティ向上と設

計安全性を考慮したユーザインタフェースの実現とツールチェーン、フレームワークの構築

を挙げた。

’08 年度は’07 年度の結果を受け以下の計画にて推進した。

� 統合開発環境フレームワークの要件策定および仕様定義

� ツールチェーンを実現するツールの仕様策定、ツール間インタフェース仕様の策定、

およびそれらのプロトタイプ開発

� 各ツールの利用品質特性の評価基準の策定とその評価結果を各仕様に反映

実施した活動は以下の通りである。

� バージョンアップされた AUTOSAR R3.0 の開発方法論およびツールに関連する仕

様の分析

� システム設計ツール、ソフト設計ツール、ツール間インタフェース仕様の策定とプ

ロトタイプ開発

� ツールフレームワークの調査および要求仕様の策定

� ツールの有用性を客観的に評価することが可能な評価基準の策定

その結果、’08 年度は AUTOSAR の方法論に沿った開発が可能なツールチェーンを構築す

ることができた。しかしこの段階で、パラメータ設定数が膨大になることが現実化するとと

もに、ツールリリース時のツール間の不整合等が顕在化した。ここから’08 年度の課題をユ

ーザの設計負荷軽減とリリース時の完成度向上と定め、最終年度の活動目標とした。

173

’09 年度は以下の目標を掲げた。

� ツール間の連動性と統一操作環境の実現

� ユーザ設計負荷軽減

� 上位ツール(システム仕様)のインポート

� 完成度向上のためのリリースプロセス確立

活動内容および結果は、前節 7.2.6 にて述べたとおりである。

ここで、本 TF にて、当初掲げた3つのゴールについて、その活動および結果について述

べる。

(1) プラットフォームベース開発に対応するツールに必要な要件、仕様の策定

プラットフォームベース開発に必要なシステム設計、ソフト設計各ツールの要求仕様、ツ

ール間インタフェースの設計仕様を策定、プロトタイプを開発、その評価を行った。

3カ年の活動により実車走行を行う実証実験のソフトウェア開発に必要な各種ツールを組

み合わせたツールチェーンを実現することができ、またツールチェーンをマルチベンダ構成

で容易につくることが可能なフレームワークをプロトタイプ開発した。また、これらのツー

ル、フレームワークについての評価を実施し、有効性、効率性、満足度は毎年度向上したこ

とが確認できた。

(2) ISO/IEC 9126-4 などの評価基準を基に開発ツールの競争力向上に寄与する評価基準の

策定

ソフトウェア製品を対象とした評価について以下の項目について言及されているため、

ISO/IEC 9126-4 を利用して評価基準を策定した。

� ソフトウェア品質測定法をどのように適用するか

� 各特性の基本的な測定法のセット

� ソフトウェア製品ライフサイクルの中で測定法をどのように適用するか

策定した評価基準を用いて行った評価の結果を次年度の活動計画に折りこむことで開発し

たツールの有効性、効率性、満足度が前年比で向上していることから、有益な評価基準を策

定することができたと考える。

174

(3) 上記活動を通して技術者の技術力向上を計り競争力のあるツール開発が可能なベンダ

の育成

日本のツールメーカは欧米のツールメーカと比較すると小規模な企業が多く、全体のツー

ルチェーンを1社で構築できる規模にはない。そこでツールメーカ毎に得意とする分野が異

なる複数社でツールチェーンを構築するマルチベンダ構成でのツールチェーンの構築を進め

た。本プロジェクトに参加したツールメーカは仕様の理解から始め、ツールチェーンを構築

し最終的には実車実証実験のためのソフトウェア開発が可能なレベルとなった。毎年度ツー

ルの評価を行うことでニーズの見直しを行った結果、上述したようにその結果は毎年度向上

した。これは、自動車メーカ/サプライヤのニーズに対応可能な技術力、ノウハウを各ツー

ルメーカが獲得した結果である。

一方、3年間の活動を通してマルチベンダ構成でツールチェーンを構成する場合に、開発

全体を統括・管理する仕組みが必要なことも明らかとなった。上流から下流まで1社のツー

ルで構成されるツールチェーンと比較し、ツール毎の使い勝手や完成度の違いが、ユーザが

ソフトウェアの開発を進めるにあたっての生産性に影響を及ぼす。この課題に対応するため

には、以下にあげる4つの施策が有効であることが、ツール評価の結果からも実証されてい

る。そして、それらの遂行を確実に実行するためには、ツールチェーン全体を管理する仕組

み・組織を作り対応していくことが望まれる。

� 各ツールのベースとなるツールフレームワークの提供

ツール間の連携を行うためのデータ構造の一元化により、あるツールで更新した内容が

他のツールにも自動反映される仕組みを実現するなどユーザにとって有効な機能。他方、

ウィンドウやメニューのテンプレートなどツールを開発する上で不可欠となる基本機能を

提供することは、ツール開発者に対しては開発負荷を低減できるとともに、利用するユー

ザにも異なるツールに同じ GUI が利用でき、生産性の向上が見込める。

� 各ツールの競争領域を残しつつ決められたルールで開発する仕組みの構築

上述したフレームワークだけでは対応が難しいツール開発各社の独自領域については、

ガイドライン等を使い、ウィンドウの配置やメニューの構造など統一感を持たせるための

仕組みをつくることが必要である。

� ツールチェーンとしてのリリースに向けた試験環境の整備、進捗管理とリリース可否

の判断

複数のツールを各ツールの開発タイミングでリリースしてしまうと、他ツールとの整合

性の確認やツールのインテグレーション等の負担をユーザが負わなければならなくなる。

これはマルチベンダ構成のツールチェーンの避け難い弱点である。これに対してはリリー

175

スに向けた基準を設けること、すなわち個々のツールの完成度の向上のみならず、結合状

態での動作を保証する試験環境、試験方法を定めることで対応が可能であり、それを組織

的に実行できる体制の構築が必要と考えられる。

� ユーザからのフィードバックを反映する仕組み

ツールの完成度を上げていく、また競争力のあるツールとして進化させるためには、「ユ

ーザからの指摘、要望をいかにツールに迅速にフィードバックしていくか」が重要である。

マルチベンダ構成のツールでは、どのツールの問題かをユーザサイドで解析し対応するこ

とは難しい。またツールを組み合わせた場合の問題、フレームワークの問題など、個々の

ツールだけでは対応できないものも多く考えられる。そのため、ユーザの対応を一本化す

るようなワンストップサービスが有効であり、それらサービスを実行する仕組み・体制が

望まれる。

本事業による3カ年の活動により、プラットフォームベース型ソフトウェア開発に必要な

知識、ノウハウを得ることができ、今後のツール開発の基礎は確立できたと考える。またそ

れらツールを日本のツールメーカが独自開発し、実証実験のためのソフトウェアを開発し実

証実験を行うに至ったことから、日本のツールメーカの技術力、ノウハウが向上したと言っ

ても過言ではないだろう。

最後に、今後、前節 7.2.6 に述べた課題を解決し、実用に向けた取組みを進めていく上で

考慮すべき点を挙げておく。

1.ユーザニーズの取り込み、開発者へのフィードバックを容易に行える仕組みの確立

2.実運用観点(規模、品質、生産性向上)の機能強化を継続

3.本事業にて開発したツールチェーンとシステム仕様記述とのインタフェース確立の

ため、他 TF とのより一体化した計画の立案と活動

4.開発効率向上のために、設計の各フェーズで設計妥当性を確認可能なツールの開発

(シミュレータ等)

5.差分開発をサポートするための仕様管理、構成管理、バリエーション管理などを一

体化させたツールフレームワークの構築と ISO26262 などの機能安全対応として必

要となるトレーサビリティへの対応

以上5点について考慮して更なる機能、品質の向上を図り実用化に向けた活動を継続して

いくことを期待する。

176

8.3 プロセス実証

8.3.1 システム仕様記述

プロセス TF では、JASPAR の目指す開発プロセス要件に沿う記述言語として、EAST-ADL

に着目し、日本の自動車開発への適用が可能かどうかを実際の記述の試行と様々な調査を通

じて検証してきた。この結果、EAST-ADL が非常に有用であり、既存の手法に代わりうるも

のであることがわかった。

しかし、EAST-ADL は有用な特徴を持っている一方で、日本の車載電子システム開発に十

分に対応できていない点も見受けられた。今後、EAST-ADL について実用上の様々な課題に

取り組むことは日本の自動車産業・組込みソフトウェア産業の競争力強化に直結すると考え

られる。今後取り組むべき課題として以下、説明する。

(1) 大規模システムにおける振る舞いの記述・検証

統合システムにおいて、大まかな機能間での関係性を定義し、妥当性を検証することが求

められる。現状、EAST-ADL2 においては、分割した機能の内部を振る舞いモデルとして

Simulink 等を使って記述しシミュレーションすることで妥当性検証する方法を提唱してい

る。システム全体の振る舞いは、分割した機能の振る舞いをつなぎ合わせて検証することと

している。このため、統合システムのような大規模、複雑内システムでは、使用するモデル

も膨大となりコスト面、環境面、等において実用上困難な状況が予想される。

(2) 実装制約のヌケモレない定義と仕様として記述・検証

設計レベルにおいて、実装制約を考慮した設計をする。ここでは、ネットワーク上の制約

や CPU の処理負荷、リソースの消費量、センサ・アクチュエータの分解能といった条件を

考慮した設計となり、場合によっては上位仕様を満足できない場合も発生する。実装制約を

ヌケモレなく定義、検証し、上位仕様へとフィードバックして、再度設計、検証するといっ

たプロセスの実現性を検討する必要がある。

(3) 派生管理

派生をあらかじめ考慮したシステム仕様を定義することにより、その後の展開車両開発の

生産性は飛躍的に向上することは自明である。派生として定義すべき項目は明らかであるが、

定義するためのプロセス・方法論は世間をみてもまだ研究段階である。また、展開車両開発

時に、バリエーションを選択し、あるいは追加・削除・変更した場合のトレーサビリティを

管理することも重要である。

(4) 要求管理

要求として、何をどのように伝達すべきかを体系的に整理することが重要である。現状で

177

は開発対象となる制御システムへの本質的な要求と、ある設計行為を得て次工程に伝えるべ

き情報のいずれも「要求」と呼ぶことが多い。これらを解きほぐし、整理する必要がある。

(5) 新規機能開発と量産展開車両開発の棲み分け

実際の開発現場を見ると、新規機能開発はラピットプロトタイプで、機能の成立性(アル

ゴリズム)を確立することに主眼が置かれる。一方、量産展開車両開発を見ると、いかに再

利用しやすい形でモデルを定義するか、あるいは、フォールトトレラントを抜けもれなく検

討しているか、といった点まで設計が必要となり、同じシステムモデルといっても検討した

い観点がことなる。それぞれが何をどこまで責任を持つかを明確にし、その間のインタフェ

ースとなる仕様を定義する必要がある。

(6) 上記要件を満たすツールチェーン

これまで述べてきたような要件をトータルで満たす、車載電子制御システム開発に適した

ツールチェーンが必要となる。

①バックエンドとしての情報リポジトリー

仕様として記述すべき情報の一元管理を目的としたリポジトリー

②フロントエンドの仕様記述ツール

モデリングツール、シミュレーションツール、トレーサビリティ管理ツールなど

178

8.3.2 ETSS

3年間のプロジェクトでの ETSS の成果と、今後取り組むべき課題について以下に述べる。

まず、プロセス TF では以下の知見を『JASPAR 版 ETSS ガイド』として文書化すること

ができた。

・車載ソフトウェア開発に必要な技術者スキル(JASPAR 版スキルプロファイル)

・国プロ推進 WG 内での実証実験によるスキルの見える化と診断精度向上の手法

・実証実験を通じて得た適用時のノウハウ(ノウハウは他分野に展開可能)

また、ETSS の開発元である SEC には、本事業での活動を通じて車載電子開発領域に適用

可能であることを確認してもらうことができ、適宜フィードバックを行って今後の ETSS の

ブラッシュアップに役立ててもらうことができた。本事業でのフィードバック内容を活かし、

今後の ETSS にノウハウとして反映していただきたい。

また、3年間の活動によって、ETSS の有効性の確認と JASPAR 版 ETSS の利用実績を

つくることができた。今後は、本事業で作成した ETSS をいかに容易に運用するか、を検討

するフェーズに入る。具体的には、以下の「ツール化」や「テスト化」といった作業が考え

られる。

(1) ツール化

a 診断ツールの提供

データが増加すれば診断作業が膨大になるため、診断ツールにより作業を自動化する。

スキル基準はドメインごとに策定するので、ドメイン固有部分への対応も必須である。

b 運用ツールの提供

データが増加すれば診断にかかるコストが増大するため、運用ツールにより、作業負担

を軽減する。

c 構成管理

ツール化において診断結果の履歴管理が必要なのはいうまでもないが、スキル基準も見

直しが入っていくために構成管理が必要となる。と同時に、これらの組み合わせも管理す

る必要がある。

d 分析ツール

「こういう分析をするとこういう結果が得られる。」という分析ノウハウの提供が必要で

ある。そして、分析ノウハウを文書として提供するだけではなく、ごく簡単に分析するた

179

めの仕組みをツール化することが必要である。

ツールのイメージとしては、決まった分析ができるだけではなく、ノウハウを追加する

ことで分析手法をカスタマイズできるようなもの(メタツール)を想定している。

さらに、実運用においては、本事業のようなコストのかけ方は不可能と思われるため、こ

れを低減して展開可能にするための仕組みが必要となる。こうした点を念頭におくと、少な

くとも上記4項目は必要である。

(2) テスト化

a スキル計測

現在のスキル診断は、チームごと・会社ごとで実施されるため、絶対的な評価基準とし

て利用するにはこころもとない点がある。絶対評価としての精度を保つにはチームリーダ

によるチェック、チーム間・会社間の評価のすり合わせが必要であるが、実運用にあたっ

て、ここまでコストをかけることは難しいと思われる

そこで、例えば TOEIC のように、スキル診断をテストによって実施し点数化する仕組

みを準備すれば、この問題を解決できると思われる。具体的には、テストおよび点数化(=

評価)をサービスとして提供する団体が担えばよい。最終的には教育・学生への展開も視

野にいれ日本の競争力向上の基軸とすることも可能である。

b テスト提供団体の準備

団体はいろいろ想定できるが、現状では SMA(組込みスキルマネージメント協会)や

SEC がそうした役割を担えるものと考える。

180

8.3.3 EPM

3年間のプロジェクトでの EPM の成果と、今後取り組むべき課題について述べる。

成果については以下の通りである。

� マルチベンダ型の開発の支援・可視化を目的とした EPM 環境要件を作成

ソフトウェア開発における成果物を管理する構成管理ツール(Subversion)およびプロ

ジェクト上の課題・障害を管理するための障害管理ツール(影舞)を運用できるようセッ

トアップした。また、各チームのコミュニケーションを円滑にし、履歴が残せるようメー

リングリストを管理系ツールと同様のサーバに構築した。

今後のマルチベンダ型開発を視野に入れ、参加各社が共有して使える領域(パブリック

領域)を設けることで各チームの成果物の統合を容易に行えるようにし、すり合わせをう

まく進められるようにした。

これにより、開発案件の発注元となる自動車メーカ・サプライヤからも容易に進捗を可

視化できるようにした。

� EPM 管理系ツールの運用ルールを定義

マルチベンダ型開発を束ねるリーダ(自動車メーカ・サプライヤ)がどのような管理を

すべきかといった観点で管理系ツールの運用ルールを定義した。運用ルールについては、

開発者に必要以上の負担をかけると成果物そのものの生産性に影響を与えるため、ヒアリ

ングを通じて当初に見込んだ内容を見直しながら最終的な運用ルールを決定した。

� 予実管理と成果物をリアルタイムに観測するための手法を定義

チーム単位でのマネジメントに有効な進捗管理手法を立案し、実データに基づき検証し

た結果、実プロジェクトにおいても有効活用できるとの感触を得た。また、プロジェクト

の危険予測について、危険が顕在化するパターンを数例把握することができた。

今後、さらに様々なパターンを蓄積できれば、プロジェクトの将来を予測し、危険が顕

在化する前に防止するマネジメントが可能になる。

� 成果物の完成度から進捗状況を把握する手法を定義

成果物の完成度から進捗状況を把握する手法を検討し、定義することができた。ここで

は、マルチベンダ型開発のリーダが利用することを念頭において、全体を俯瞰(チームを

横断的に評価)して管理できる方法を検討した。

成果物の完成度を評価する指標としては SEC が推進している品質指標(ESQR)を利用

した。ESQR は本来、ソフトウェアの品質を評価する指標であるが、今回はこの指標をマ

イルストンやタスクにおける完了基準とした。

181

� EPM における ETSS スキルデータの活用

EPM で観測される計画の履行度合いや成果物(量)の達成度が ETSS のスキルデータ

と一定の相関をもつことが確認できた。これについて、さらに精度が高くなれば、過去の

EPM で収集したデータと ETSS のスキルデータをもとに、プロジェクトの発足時に計画

の妥当性を判断する、といった利用方法も可能である。

以上のように、今回のプロジェクトにおいて EPM の有効性については十分に確認できた。

特に、基本的な EPM の観測手法である計画・進捗に関するデータの分析に加え、他の SEC

成果物(ETSS・ESQR)との併用により、新たに様々な分析手法が立案できることがわか

った。この点は今後の EPM の可能性を考えるうえで非常に大きな収穫であったと認識して

いる。

こうした成果の一方で、新たな課題も明らかとなった。今回のプロジェクトでは、様々な

実験・試行から EPM の有効性を確認できたものの、今後、実運用にむけては以下の通り、

いくつかの課題が残されている。

� 観測手法の自動化(ツール化)

今回のプロジェクトで定義した EPM 観測手法について、開発者に負担をかけることな

く利用できるようツール化を検討すべきである。

ツール化にあたって必要となる仕組みは以下の通りである。

� 予実管理データの自動収集の仕組みおよび状況を知らせる仕組み

� 運用から外れた場合の警告を関係者に発し、運用ルールを守る仕組み、または運用

外の操作ができない仕組み

� 役割毎(自動車メーカ・サプライヤ)に提出するレポートを自動作成する仕組み

� 品質指標(ESQR)の基礎データを自動収集する仕組みおよび、可視化する仕組み

� 実運用に即した短いスパンでの評価実施

今回のプロジェクトはマイルストンごとの評価を実施したが、実運用にむけて、さら

に短いスパンでの評価ができるようにし、マネージャーができるだけ直近の情報を得ら

れるよう検討していく必要がある。

� システムごとの品質指標の定義(ESQR)

SEC が推進する ESQR の指標値は開発対象となるシステムによって補正して活用す

ることを推奨しているが、これについては車載電子制御システム開発を含め、様々な組

込みシステム・ドメインについての ESQR 指標値の更なる知見・データの蓄積が望まれ

る。

自動車開発向けの指標値が示されれば EPM でも ESQR をより有効に利用することが

182

できる。

� 品質そのものに対する観測手法の実証実験

今回行った成果物における分析のなかで、品質の悪化に結びつくような兆候も一部で

あるが分析結果から推察することができた。品質悪化の兆候から障害発生までの一連の

経過を把握できる仕組みがあれば、品質悪化を未然に防止するための観測要件を立案で

きるものと考える。

� 開発者個々のスキルデータを加味した管理手法の実証実験

EPM で個人の作業内容を可視化することで、開発者個々の成果への貢献度や計画の

順守度を把握できると考えられる。これを ETSS のスキルデータと紐づけることで実際

の開発者個人のパフォーマンスを明らかにし、スキルデータの裏づけとすることができ

る。

� 本事業における EPM 観測手法の書籍化

本事業における EPM 関連の活動の成果を集約し、ガイドブックとしてまとめたい。

これにより、自動車業界において EPM の普及を進めるとともに、他業界での EPM 導

入の際の一助としたい。

183

8.3.4 プロセス TF からの提言 ~今後の日本の組込み産業の目指すべき方向~

3年間の活動では様々な知見が得られたと同時に今後議論すべき課題が明らかとなった。

プロセス TF からの提言として、今回のプロジェクトで得られた知見から、今後の日本の組

込み産業が目指すべき方向とそれに向かうための具体的な施策を提起したい。

システム仕様記述の分野では、特に、欧州における資産の開発・利活用・産官学連携の仕

組みについて非常に示唆的な部分が確認できた。これについては、今後のわが国の組込み産

業においても大いに参考にすべき点や、逆にここが強化できれば日本の強みとなるのではな

いか、という部分を指摘したい。

まず、欧州において展開されている ARTEMIS･AUTOSAR･ATESST 等のプロジェクトの

基本姿勢をみてみると、非常にわかりやすく壮大な基本戦略に基づいて進められていること

がわかる。プロジェクトを構成するメンバも EU 各国の政府・企業・研究機関など、多岐に

わたっており、これらの機能的な連携に基づいてプロジェクトが進められているのも特徴で

ある。

さらに、EU 内では独占企業を排除するとの方針から、プロジェクトの成果物はオープン

化・標準化が前提となっている。このため、各国の連携のもとで多国間での成果物の活用が

行われている。EU 外での成果物の活用に関しても、比較的寛容である。今後、わが国にお

いても欧州のプロジェクトの動向には常に目を配るとともに、有用な成果物については早期

にキャッチアップできるような施策を検討していく必要がある。

プロセス TF において調査した所感として、欧州のプロジェクトは全体としてコンセプト

主導であり、資産の活用を前提としたフロントローディングによる効率化が基本思想となっ

ているように思われた。

しかし、現実のシステム開発には様々な問題があり、常に、コンセプトで示された通りに

開発が進むわけではない。欧州においても、コンセプトで示された理想と、現実に発生する

問題についてどのように折り合いをつけていくかは各国・各社に委ねられているのが現状で

ある。同じ自動車業界においてさえ、実製品開発においては足並みが乱れる例も散見されて

いるため、実製品開発のフェーズに強みを持つ日本は、この領域をさらに強化することで、

今後も強みを発揮できるものと考えられる。

今後の欧州の自動車産業の競争力の源泉として注目すべきものは安全(さらに発展し安心

を含めたディペンダブル/高信頼性のある)なシステム構築であり、現在は大型プロジェク

ト(CESAR 等)による安全基準の構築と、各社でのノウハウの蓄積を進めていると思われ

る。これについて日本の組込み産業は十分な対応ができておらず、早急に検討を開始しなけ

184

ればならない。

システム仕様記述の部分からは、今後の組込み産業の目指すべき方向性として以下の4点

を提起したい。

1) 産官学共同のリサーチセンターの設置

諸外国(特に欧州)の資産・標準について日本国内で常に利用可能な状態を維持させ

るため、動向ウォッチングと使うノウハウをためるための仕組み作りが必要である。

2) インタフェースの標準化

BSW を使うシーンを想定し、企業間・構造間のインタフェースの標準化が必要であ

る。

・車両システム開発者、電子システム開発者、ソフトウェア(コンポーネント)開発

者、ハードウェア(コンポーネント)開発者、ツールメーカ等

3) ツールチェーンの構築

欧州の資産を活用しながら、日本の強みである摺り合せ型開発を活かす開発環境(ツ

ールチェーン)の構築が必要である。

4) 産業基盤の強化

自動車産業をはじめとする組込み産業を下支えする新たな担い手(ツールメーカ、ソ

フトウェアメーカ)を創出・育成すべきである。

次にSEC 成果物について、本事業における3年間の適用・評価を行った結果では、ESPR、

ESMR、ETSS、EPM のいずれも有用であるとの結論を得た。特に一社単独によるウォータ

フォール型のソフトウェア開発においては、いずれの成果物もうまく適用できるものと思わ

れる。

ただし、本事業のような会社を跨ぐ開発(マルチベンダ型開発)では未だ課題が残されて

いる。例えば ETSS では誰が診断を実施しても診断精度が保てるような仕組みをさらに検討

すべきであるし、ESPR では様々な開発対象・開発体制に合致するよう記載事例を提示する

などの工夫が必要である。

今後、自動車業界では共通のプラットフォームに基づくマルチベンダ型開発が主流になる

と思われるため、会社間・部署間を跨ぐ開発形態への対応は確実に必要な要件である。開発

元の SEC には、是非とも対応を望みたい。

185

また、システム領域については、車載ソフトウェアは複雑かつ大規模であるため、SEC 成

果物を一部業界向けにカスタマイズしていく必要があった。今後、SEC 成果物には、システ

ム領域も折り込んでフォローしてもらえるとさらに有用に利用できる。

いくつかの課題はあるが、SEC 成果物はプロジェクトの下地(各種ドキュメントの雛形・

管理手法)としては有効である。『勘と経験』に頼りがちな組込みシステム開発のなかで、今

回のプロジェクトのようにエンジニアリング手法として SEC 成果物に有効性が見出せたこ

とは非常に意義のあることと考える。

今後も JASPAR では SEC との協力関係のもとで、継続的に成果物の適用・評価を行って

いきたい。これよって SEC 成果物のブラッシュアップにつなげていただければ幸いである。

186

8.4 実機適用に向けた実証

評価用ソフトチームにおける活動総括(2カ年)を以下に述べる。

’08 年度は選定した3つのアプリケーション毎に基本部分の評価用ソフトウェアを開発し、

開発したソフトウェアに対してシステムレベルで機能要件の確認を行った。その中で

AUTOSAR 仕様の解釈の不整合やツールの不備、AUTOSAR を適用するソフトウェアの処

理負荷増大に対する危惧などの課題の抽出がなされた。

’09 年度はそれらを踏まえて JASPAR 仕様 BSW を適用した評価用ソフトウェアの開発を

行い、AUTOSAR 仕様との比較による’08 年度課題の改善確認を含む評価、検証を実施した。

評価結果は前述の3つの評価用ソフトチームの報告にある通り、JASPAR 仕様 BSW は

AUTOSAR 仕様と比較して仕様の解釈の不整合なく、特に効率性の面において優位性がある

こと、また、JASPAR 仕様 BSW を適用した各評価用ソフトウェアは従来ソフトウェアと同

等の機能/性能をシステムとして実現できていることが確認できた。

また、プロセス TF による開発進捗の見える化や開発ツールの活用により、短期間で走行

可能な評価用ソフトウェアの開発を実現することができた。

以上より標準実装 TF、開発ツール TF、プロセス TF の活動成果は実機適用を想定した評

価を通して有用であったと判断できる。

加えて、自動車、部品、ソフトウェア、半導体の各メーカが連携、分担して短期間で走行

可能な評価用ソフトウェアを開発できたことは、今後の車載制御ソフトウェア開発の水平分

業の可能性を示唆するものである。

ただし、自動車における量産開発及び JASPAR 仕様 BSW の広範囲な普及に向けては BSW、

開発ツールの更なる性能改善を継続すること、品質保証の仕組みや開発プロセスの確立が望

まれる。

187

9. おわりに

自動車の制御システムは、市場からの環境、安全、利便性能に対する高い要求に応えるた

め、それぞれの制御システムが通信で結合され、統合的に制御されるようになっている。こ

れら統合制御などを実現するには高度で複雑な制御ロジックが開発され、このロジックを実

現する組込みソフトウェア量が加速的に増加している。したがって、組込みソフトウェアの

開発は、非常に多くの開発資源を必要とし、製造原価に大きな割合を占めるようになってい

る。このような問題は製造業だけではなく、サービス業などのあらゆる産業で生じている。

強みを活かせる領域へのシフト

高価値領域での開発力向上

による競争力の強化

競争領域をモジュール・

プラットフォーム化し、

人材・資金を強みの活か

せる高価値領域へシフト

市場・技術の進化により

拡大する競争領域

競争領域

高価値領域

共通領域

競争領域

188

高価値領域

共通領域

高価値

領域へ

シフト

高価値領域

共通領域

サプライヤが担う競争領域

図 9-1 基盤ソフトウェアの整備による競争力強化策

高価値

領域へ

シフト

そこで平成 19 年度(2007 年度)から平成 21 年度(2009 年度)の3年間において、高信

頼なソフトウェア開発手法として以下の4項目について取り組んだ。これらの活動により、

車載制御ソフトウェアの共通プラットフォームを構築することができ、開発コスト削減や、

開発期間を短縮させることが可能となる。さらに、図 9-1 のように共通領域の拡大は、人材・

資金を高付加価値領域に集中させる効果も期待できる。

今回のプロジェクトは、自動車用組込みソフトウェアの国際標準化に向けて前進したこと

はもちろんのこと、組込みソフトウェア開発の効率向上に関する様々なノウハウを検証する

ことができた。このように、本事業は自動車産業及び組込みソフトウェア産業の競争力強化

の一助となった。しいては、組込みソフトウェア開発技術力の向上は、高信頼な電子制御技

術によって実現される安心・便利・快適な社会に変えてゆくための原動力であり、今回のプ

ロジェクト成果は社会の更なる発展に向けて大きく貢献すると考える。

(1) 自動車用制御基盤ソフトウェアの仕様策定と実装評価

(2) (1)の制御基盤ソフトウェアによる車載制御組込みソフトウェアを開発するためのツ

ールの仕様策定と実装評価

(3) 開発プロセスの実証実験

(4) (1)の自動車用基盤ソフトウェア及び、(2)の開発ツールを用いた車載制御システムに

よる実証実験

(1) 自動車用制御基盤ソフトウェアの仕様策定と実装評価

JASPAR 仕様の基盤ソフトウェア開発は、2007 年度は AUTOSAR R2.1 仕様をベースと

した実装開発により、本事業参加企業の車載電子制御用ソフトウェアの開発技術力・知識の

強化を図った。2008 年度は AUTOSAR R3.0 仕様ベースとした実装開発と、JASPAR コン

セプトであるプロファイル、クラスタ、拡張 MCAL の基本技術の開発を行った。

2009 年度は、JASPAR コンセプトの有用性を確認するため、今回実証実験に用いる車載

電子制御システムに供試することを最優先課題として開発を進めた。また客観的評価として、

ISO/IEC 9126-1 の品質6特性に基づく AUTOSAR 仕様との比較を実施した。

図 9-2 は JASPAR で開発した JASPAR 基盤ソフトウェアと AUTOSAR 基盤ソフトウェ

アを品質6特性に基づき評価した結果であり、信頼性、使用性、効率性で JASPAR 基盤ソフ

トウェアが優れていることが確認できる。

項目 AUTOSAR JASPAR

機能面機能性 ○ ○

◎

信頼性 △

非

に適用評価

機使用性 × △

能効率性 △ ◎

面保守性 △ △

FlexRay通信※

移植性 △ △

※次世代車載用通信ネットワークの一種

189

信頼性

使用性

機能性

4

3

2

1

0

移植性

図 9-2 基盤ソフトウェア評価結果

AUTOSAR

JASPAR

効率性

保守性

(注記)本評価結果は、本事業に参加した中小の組込みソフトウェア

メーカが実装した通信スタックを中心に評価した結果である。

(2) (1)の制御基盤ソフトウェアによる車載制御組込みソフトウェアを開発するためのツー

ルの仕様策定と実装評価

2007 年度、2008 年度は AUTOSAR 仕様に基づき、基盤ソフトウェアを用いた組込みソ

フトウェア開発するためのツール開発を実施した。JASPAR では、AUTOSAR のメソドロ

ジとして定義されるツール仕様に対し、システム設計ツール、ソフトウェア設計ツール、各

種コンフィグレータの3段階を経て、組込みソフトウェアが生成されるツール群として定義

した。これらツール開発では、各ツールにおいて設計パラメータが多く、初期設定されたパ

ラメータの受理を上手く行わないと、設計者の作業負担が大きいことが分かった。

2009 年度は、組込みソフトウェア設計者の負荷低減と、JASPAR コンセプト機能を実現

するためのツール機能拡張開発を行った。また、検証に必要なツール群との連携についても

トライアルをした。そして、これらツール群の使用品質向上に向け、統合ツール開発環境を

構築し ISO/IEC 9126-4 利用品質特性に基づく評価項目を規定、評価を実施した。

JASPAR の統合ツール環境ではパラメータの設定数は、AUTOSAR に対し 75%削減する

ことができ、明らかに設計者の負荷を軽減することができている。また、統一操作環境の実

現により、利用品質特性として、有効性、効率性、満足度について良い評価を得た。そして

検証系ツールの連携として、CPU シミュレータ、バスモニタのインタフェースを試作した結

果、設定作業が大幅に削減される効果が確認できた。

(3) 開発プロセスの実証実験

自動車用制御基盤ソフトウェア開発に関わるソフトウェアエンジニアのスキルを3年間に

渡り取得し、自動車用ソフトウェア開発エンジニアの開発力の推移を客観的に評価した。そ

の結果を図 9-3 に示すが、明らかに参加エンジニアのスキル向上が見られる。これは、大手

自動車部品サプライヤや自動車メーカのエンジニアとソフトウェアベンダのエンジニアが一

緒に開発を取り組んだことにより、自動車制御ソフトウェアに関する知識が直接伝わったこ

とによるものと考えられる。また、これら3年間の ETSS 活動である、技術項目、運用方法

等について、自動車版 ETSS としてまとめた。

190

○参加企業のスキル向上

技術要素開発要素管理技術

図 9-3 ETSS 診断結果

191

ﾊﾟｰｿ

ﾅﾙビジ

ネス

基盤ソフトウェアによるプラットフォームベース開発における自動車メーカとサプライヤ

間等のプロセスの標準化が重要な課題であり、欧州の EAST-ADL で行われている取り組み

について調べた。EAST-ADL を中心とした欧州の活動成果をみると、ツールチェーン試作を

通じてコンセプト実証がほぼ完了している。ただし、自動車で重要となる派生開発について

は、検討があまり進んでいないようである。プラットフォームベースのプロセスについては、

EAST-ADL の成果を有効に活用し、差分開発に対する取り組みに特化して検討を行うべきだ

と思う。

(4) (1)の自動車用基盤ソフトウェア及び、(2)の開発ツールを用いた車載制御システムによる

実証実験

①安全制御系

②ステアリング系制御

③ITS 系制御

の3つのアプリケーションに対し、今回開発した基盤ソフトウェアと開発ツールを適用した。

そして、自動車用基盤ソフトウェアは、異なる車載制御システムに組み込まれても、各シス

テムは従来と同等の機能/性能を実現できることを実証した。また、本プロジェクトで開発

された自動車用基盤ソフトウェアが、AUTOSAR 仕様と比較して性能改善していることを確

認した。

10. 参考文献・参考ホームページ

(1) 参考文献

[1] 組込みソフトウェア向け開発プロセスガイド IPA/SEC 編,2007 年,翔泳社

[2] 組込みソフトウェア向けプロジェクトマネジメントガイド[計画書編] IPA/SEC 編,

2006 年,翔泳社

[3] 組込みスキル標準 ETSS 概説書 [2008 年度版] IPA/SEC 編,2008 年,翔泳社

[4] エンピリカルソフトウェアエンジニアリングの勧め IPA/SEC 編,2007 年,翔泳社

(2) 参考ホームページ

[5] AUTOSAR

http://www.autosar.org/

[6] ATESST

http://www.atesst.org/

[7] Artop(AUTOSAR Tool Platform)

http://www.artop.org/

[8] CESAR

http://www.cesarproject.eu/

[9] PapyrusUML

http://www.papyrusuml.org/

192

HEV/EV - 経済産業省

HEV/EV - 経済産業省 ... View more HEV/EV - 経済産業省

Delete template?

Save as template ?

HEV/EV - 経済産業省 HEV/EV - 経済産業省