**********************************************************************
セッションS5-b チュートリアル
テーマ：AUTOSAR車載ソフト開発 〜 ツール&BSWの隅々まで知ろう 〜
講師：柳下 知昭(キャッツ)，黒岩 佑介(イーソル)，
　　　荒木 大(インターデザイン・テクノロジー)
日時：2010/9/3 10:30〜12:00
参加人数：18名（終了時）
**********************************************************************

○ 本セッションの概要

AUTOSARを利用した車載ソフト開発において，ツール，BSW(Basic SoftWare)を利用して，
どのようなことが出来るのか，どこまで出来るのかを紹介する．


○ 内容

1. AUTOSARって，何？
2. 上流システム設計ツール
3. ECU設計ツール
4. シミュレーター
5. デモ
6. 質疑・応答


0. 車載ソフトウェア開発の課題

　車は，移動手段ではなく，リッチなプライベート空間として認識されている．
　　→ 様々な機能を備えるようになった．

　◇ ソフトウェア量の増大
　　　　→ コード数は1000万行を超えている．
　　　　 　いわゆる，「人海戦術」での開発は難しい．

　◇ 複雑性の増加

　　　　◆ ECU(Electrical Control Unit)の物理的な増加
　　　　　　　→ 物理的なスペースの不足
　　　　
　　　　◆ 1つのECUで複数の機能を賄う
　　　　　　　→ 複雑性の更なる増加

　◇ コストの削減


1. AUTOSARとは？

　※ AUTOSAR(AUTomotive Open System ARchitecture)：AUTOSAR開発パートナーシップ

　◇ AUTOSARの目的

　　　・ 増加する電気/電子システムの複雑性の管理
　　　・ 製品の変更，アップグレード，アップデートの柔軟性の向上
　　　・ プロダクトライン内，プロダクトライン間でのスケーラビリティの向上
　　　・ 電気/電子システムの品質と信頼性の向上
　　　・ 上流設計工程でのエラーの検出

　◇ AUTOSARの利点

　　　◆ AUTOSARが指定するフォーマットでのデータ交換
　　　　　・ ツールチェーンの構築

　　　◆ BSWの活用
　　　　　・ 付加価値を増加させないコンポーネント再実装の省略
　　　　　　　　→ 再利用性の向上

　　　◆ ハードウェア抽象
　　　　　・ SWとHWの分離
　　　　　　　　→ HW変更の際のアプリケーションへの影響を少なくする

　　　◆ RTE(EunTime Environment)
　　　　　・ 通信の抽象化
　　　　　・ アプリケーション再配置の容易化

　　　◆ インターフェースの標準化
　　　　　・ OEM(Original Equipment Manufacturer)，サプライヤ間でのインター
　　　　　　フェース増加の抑制
　　　　　・ 汎用インターフェースカタログを活用することでの実装の容易化
　　　　　・ OEMを超えたモジュールの再配置促進
　　　　　・ 異なるサプライヤからのコンポーネントの交換性向上

　◇ AUTOSARの歴史

　　　◆ 2002年夏：欧州OEM，サプライヤが中心となり発足

　　　　　コアメンバ：BMW，BOSCH，Continental，DAIMLER，Ford，OPEL，
　　　　　　　　　　　PSA PEUGEOT CITROEN，TOYOTA，VOLKSWAGEN AG

　　　◆ 2007年 3月：AUTOSAR R2.1 リリース
　　　
　　　◆ 2008年 3月：AUTOSAR R3.0 リリース

　　　◆ 2009年12月：AUTOSAR R4.0 リリース

　　　※ 日本では，JASPAR(Japan Automotive Software Platform and Architecture)が
　　　 AUTOSARを活用する為，実装・調査対象とした．

　◇ AUTOSARへの参加者

　　　◆ 日本からも多くの企業が参加(参照：http://www.autosar.org/)

　◇ AUTOSARからのアウトプット

　　　◆ モデル・スキーマ

　　　　　・ UMLツール：エンタープライズアーキテクトのモデルフォーマット
　　　　　・ スキーマ：XMLファイルフォーマットを規定するもの

　　　◆ インターフェース

　　　　　・ 膨大な数のインターフェース仕様書がリリース

　　　◆ アーキテクチャ

　　　　　・ 基本的なアーキテクチャをAUTOSARで規定
　　　　　・ RTEがキモ
　　　　　　　→ RTEより上位階層がアプリケーション部分(各社が機能実装)
　　　　　　　→ RTEより下位階層がBSW部分
　　　　　　　　　※ Conplex Driver部分でこれまでの既存資産を活用

　　　◆ メソドロジ

　　　　　1. システム全体の設計
　　　　　2. 機能をECUに分割
　　　　　3. 分割されたECU毎に設計
　　　　　4. コード生成

　◇ キャッツとイーソルのツールサポート範囲を連携

　　　◆ ZIPC AUTOSAR(キャッツ)：AUTOSARメソドロジ上流部分を担当
　　　　(メソドロジの1.と2.)

　　　◆ eSOL ECUSAR(イーソル)：AUTOSARメソドロジ下流部分を担当
　　　　(メソドロジの3.と4.)


2. 上流システム設計ツール：ZIPC AUTOSAR

　◇ ツールチェーン

　　　◆ ツールチェーンの意味・重要性

　　　　　・ AUTOSARメソドロジにある複雑，多様な作業を 1社でまかなうのは困難
　　　　　　　→ 工程に合わせて上手くツールを使いこなしていく

　　　◆ ツールチェーンの実現

　　　　　・ ファイルを変換して，やり取りする → 最もベーシック
　　　　　・ (共通のデータフォーマット)ファイルを直接やり取りする
　　　　　　　→ AUTOSARのスキーマを用いれば可能
　　　　　・ 理想：統合環境(Eclipse等)上で行き来する(パースペクティブで切替可能)
　　　　　・ 理想：1つのデータを共有してツールが動作

　　　　　※ キャッツ，イーソル社のツールチェーンでは，AUTOSARスキーマでファイル
　　　　　　を直接やり取り

　◇ システム オーサリング ツール：ZIPC AUTOSAR

　　　◆ アウトプット：(ECU分割を規定した)XMLファイル

　　　◆ 特徴
　　　　　・ システムオーサリングツール
　　　　　・ スクリプトによる自動処理
　　　　　・ 豊富なバリデーション機能
　　　　　・ ZIPCとの連携　　　　
　　　　　・ 差分開発支援機能
　　　　　・ トレーサビリティツールとの連携
　　　　　・ プロダクトラインツールとの連携

　　　◆ ツール概観

　　　　　・ トポロジ図，インターフェース図，コンポジション図，ランナブル図を
　　　　　 利用したグラフィカルなモデリングツール

　　　◆ スクリプトによる自動処理

　　　　　・ GUI・マウス中心の設計ツールは便利な反面，煩雑になることも
　　　　　　　→ スクリプト言語Pythonを利用した定型処理

　　　　　・ 具体的には：
　　　　　　　☆ モデル操作の自動化
　　　　　　　☆ 設計データの帳票への出力

　　　◆ 豊富なバリデーション機能

　　　　　・ バリデータによるモデルのチェック

　　　　　・ 該当箇所へのジャンプ機能による修正支援の実現

　　　　　・ 具体的には：
　　　　　　　☆ 問題ビューというビューで問題が一覧される
　　　　　　　☆ ダブルクリックで問題のある個所にジャンプ
　　　　　　　☆ 独自のバリデーションルールもスクリプトでカスタマイズ可能

　　　◆ ZIPCとの連携

　　　　　・ AUTOSARは構造だけを定義する → 振る舞いは別
　
　　　　　・ 目的：状態遷移表(設計ツール：ZIPC)設計手法との連携

　　　　　・ 具体的には：
　　　　　　　☆ システム設計ツール → 振る舞い設計ツールへの連携

　　　◆ 差分開発支援機能

　　　　　・ スクラッチからの開発ではなく，差分開発が主流
　　　　　　　→ SWCの再利用性の向上
　　　　　　　→ SWCに紐付けされているインターフェース，タイプ，
　　　　　　　　インターナルビヘイビアを適切に再利用しなければならない

　　　　　・ 目的：インテリジェントな分割・マージ機能の実現

　　　　　・ 具体的には：
　　　　　　　☆ 必要な要素は，一緒に再利用
　　　　　　　☆ マージ先で同一になるべき要素はきちんとマージ
　　　　　　　☆ スクリプトでカスタマイズすることで，詳細要望への対応

　　　◆ トレーサビリティツールとの連携

　　　　　・ 差分開発での部品の再利用範囲の管理
　　　　　　　→ 部品がどこで使われているのか，どのシステムで使用しているのか
　　　　　　　　を管理する

　　　　　・ 目的：トレーサビリティ管理の実現

　　　　　・ 具体的には：
　　　　　　　☆ SWCと外部モデルとのトレーサビリティの管理を実現
　　　　　　　☆ 外部モデル間のトレーサビリティも同時に実現

　　　◆ プロダクトラインツールとの連携

　　　　　・ 差分開発，プロダクトライン開発では再利用しやすいSWCを設計を考える

　　　　　・ 目的：再利用しやすいSWCを設計

　　　　　・ プロダクトライン開発を考慮したSWC設計
　　　　　　　→ ZIPC Feature：フィーチャモデリングツール


　◇ 前半まとめ

　　　◆ 上流設計環境の充実

　　　　　・ ツールチェーンの実現
　　　　　・ 構造設計ツール + 振舞設計ツールの連携
　　　　　・ 差分開発支援機能の充実
　　　　　・ トレーサビリティの確保

　　　コメント：日本のシステムエンジニアは優秀な方が多く，なんとかしてしまうこと
　　　　　　　が多いと思われるが，ツールを上手く利用して生産性を上げることも重要
　　　　　　　だと考えられる．
　　　　　　　モデルベース開発の為に，その開発環境が充実してきていることを見て頂
　　　　　　　ければ幸い．

3.  ECU設計ツール

　◇ AUTOSAR BSW概要説明

　　　◆ 前提：

　　　　 現在の車載ソフトウェアは多くのECUが協調して動作する分散システムより実現
　　　　されている．
　　　　BSWとは，ミドルウェアのようなもの．

　　　◆ 今までのミドルウェア

　　　 　独自仕様に基づいており，HW，システム仕様と一対一対応により開発されてきた．
　　　　　 → 再利用性が低く，機能拡張などのメンテナンスにも多大な工数が必要

　　　　　 ∵ コスト面の問題，ECUがあまり良いものを使えなかった．
　　　　　　　　→ ROM/RANの容量削減，速度向上のため，HW依存性の強いソフトを作成
　　　　　　　　　する必要性

　　　◆ AUTOSAR仕様の目的

　　　　　・ 増加する電気/電子システムの複雑性の管理
　　　　　・ 製品の変更，アップグレード，アップデートの柔軟性の向上
　　　　　・ プロダクトライン内，プロダクトライン間でのスケーラビリティの向上
　　　　　　　→ インターフェース標準化による再利用性の向上
　　　　　　　→ 機能仕様の標準化による実装の容易性向上と，機能選択の容易性向上
　　　　　　　→ ECUに対するアプリケーションの再配置の容易性向上
　　　　　・ 電気/電子システムの品質と信頼性の向上
　　　　　　　→ モジュール化による再利用性の向上による不用意なバグ混入の回避

　　　◆ AUTOSAR仕様のコンセプト

　　　　　・ インターフェースの標準化：
　　　　　　　ミドルウェアをモジュールに分割し，インターフェースの標準化と機能
　　　　　　　分割を行う
　　　　　　　　→ AUTOSARレイヤードアーキテクチャ

　　　　　・ アプリケーションの再配置：
　　　　　　　通信を抽象化することでアプリケーションをインフラストラクチャから
　　　　　　分離し，アプリケーションの再配置を容易にする
　　　　　　　　→ VFB(Virtual Function Bus)

　　　◆ AUTOSARレイヤードアーキテクチャ

　　　　　・ Application Layer，RTE，BSW，Microcontrollerの 4階層に分け，BSWは
　　　　　 さらにグループ化，
　　　　　 そのグループ内でもさらにいくつかのモジュールに分けられる．

　　　　　※ eSOL ECUSAR対応部分：通信系(CAN通信，Flexlay通信)
　　　　　　　・ Communication Service：
　　　　　　　　　車載ネットワーク(CAN，LIN，FlexRay)のためのモジュールグループ
　　　　　　　・ Communication Hardware Abstraction：
　　　　　　　　　通信コントローラの位置とハードウェアレイアウトから抽象化を行
　　　　　　　　　う為のモジュールのグループ
　　　　　　　・ Communication Drivers：
　　　　　　　　　on-boardデバイスとの通信(SPIハンドラ)，または車両内通信デバ
　　　　　　　　　イス用ドライバ

　　　◆ 語句の定義

　　　　　・ マイクロコントローラ：CPUと思えば十分
　　　　　・ ECU(Electric Control Unit，電子制御ユニット
　　　　　　　　(過去，エンジン制御ユニット))：
　　　　　　　マイクロコントローラと周辺デバイスを含んだユニット

　　　◆ マイクロコントローラ抽象化層

　　　　　・ BSWの最下層(ドライバと呼ばれる部分)
　　　　　・ HW依存部．マイクロコントローラの機能を抽象化する
　　　　　　　→ これより上位層は，マイクロコントローラから独立
　　　　　　　　　(内部レジスタアクセスなど)

　　　　　　　　Microcontroller Drivers，Memory Drivers，Communication Drivers，
　　　　　　　　I/O Drivers

　　　◆ ECU抽象化層

　　　　　・ マイクロコントローラには依存しないが，ECUに依存する層
　　　　　・ 目的：ECUハードウェアレイアウト(オンチップドライバ，外部周辺機器の
　　　　　　　　　ドライバ)を抽象化
　　　　　　　→ 外部周辺機器ドライバへのアクセスはSPIハンドラドライバを使用

　　　　　　※ ECUハードウェア依存：外部周辺機器へのアクセスなど

　　　　　　　　Complex Drivers，I/O Hardware Abstraction，
　　　　　　　　Communication Hardware Abstraction，
　　　　　　　　Memory Hardware Abstraction，Onboard Device Abstraction

　　　◆ サービス層

　　　　　・ 大部分がハードウェアから独立
　　　　　・ 様々な種類のバックグラウンドサービスを提供

　　　　　　　　Communication Service，Memory Service，System Service

　　　◆ RTE(RunTime Environment)

　　　　　・ BSWからアプリケーションソフトウェアを抽象化し，その間のデータ，
　　　　　　情報通信を処理
　　　　　・ ランナブルの起動タイミングを制御
　　　　　　　→ ランナブル：アプリケーションが動作する場所．
　　　　　　　　ここに具体的な処理を記述する．

　　　◆ アプリケーション層

　　　　　・ 複数のSWCから構成

　　　◆ VFB(Virtual Function Bus)

　　　　　・ ハードウェア，ネットワークリソースを仮想化したバス
　　　　　・ ECU内通信，EUC間通信の両方を処理
　　　　　・ RTEはVFBを実現する手段
　　　　　　　→ SWCやBSW，OS間のインターフェースを提供
　　　　　　　→ SWC間のデータおよび情報通信は，すべてRTEが取次ぎ，処理
　　　　　　　→ SWCは専用のコンポーネントを介して通信を行うため，
　　　　　　　　通信インターフェースはこれらのポートに割当られなければならない．

　　　◆ ECU内通信とECU間通信の実現方法

　　　　　1. SWC間の通信は，ECUの配置を気にすることなく，SWC間のコンポーネントを設定
　　　　　2. SWCのECUへの自由な配置(同じECUに割当られれば内部通信，異なるECUに
　　　　　　割当られれば外部通信となる)
　　　　　3. RTEはその設定を読み取り，具体的な処理を記述する

　　　　　　※ ECU内通信は変数アクセス，ECU間通信は下位のモジュールを用いて外部
　　　　　　　通信を行う

　　　◆ 各モジュールの機能一部紹介

　　　　　・ Communication(COM)：フィルタリング，送信モード，不正値シグナル，
　　　　　　シグナルグループ，デッドラインモニタリング
　　　　　・ PDU Router(PduR)：複数の通信プロトコルへのルーティング，
　　　　　　PDUゲートウェイ(FlexRay → CANへ送信)
　　　　　・ FlexRay Interface(FrIf)：FlexRay送受信処理，Joblistによる送受信
　　　　　　オペレーション
　　　　　・ CAN Interface(CanIf)：CAN送受信処理，ソフトウェアフィルタリング

　　　　　※ Joblistによる送受信オペレーション
　　　　　　　FlexRay通信はタイムトリガであり，全ノードが同期して動作．
　　　　　　　同期した時間の中で，どの時間に処理を行うかをリストとして定義する
　　　　　　　ことが可能．
　　　　　　　各ECUが割り当てられている送信タイミングに間に合うようオペレーショ
　　　　　　　ンをし，送信を行う．


　◇ ECUコンフィグレーションツール(eSOL ECUSAR)の紹介

　　・ eSOL ECUSAR/BSW：　　BSWジェネレータ(ソースコード出力)
　　・ eSOL ECUSAR/Config： コンフィグレーションツールのベース
　　・ eSOL ECUSAR/Plug-In：様々なカスタマイズ機能を実現

　　・ コンセプト：ユーザにAUTOSAR仕様を意識させない
　　　　　→ ZIPC AUTOSARからの出力を入力とし，簡易ウィザードにより細かい設定
　　　　　　は飛ばし，自動的に基本的な設定を可能とする
　　　　　　細かい設定はプラグインで実現

　　◆ 特徴

　　　　・ ユーザの手をかけない
　　　　　　→ 簡易ウィザードにより，自動的なデフォルト設定をすることでユーザ
　　　　　　　の負荷軽減
　　　　・ AUTOSAR仕様を知らなくても設定可能
　　　　　　→ 誰が見ても分かるように，判り易く画面を構成
　　　　・ ECUネットワーク情報ファイルによってシステム設計(ECU単体)が可能
　　　　　　→ ECU単体の対応ではあるが，独自フォーマットであるECUネットワーク
　　　　　　　情報を用いることで，システム設計相当の設定が可能
　　　　・ グラフィカルな表示で設定状況を直感的に理解可能
　　　　　　→ 設定状況の確認をグラフィカルな表示によって，直感的に理解可能
　　　　・ ジェネレイトされるBSWは軽量/高速なもの
　　　　　　→ 設定により不要となる処理部分は出力しないなどの軽量化
　　　　　　→ 設定に依存する処理部分をパターン化するなどの工夫により，
　　　　　　　処理速度を向上


　◇ 後半まとめ

　　◆ AUTOSAR仕様のすべてを理解するのはかなり困難

　　◆ 仕様書の量が膨大であり，コンセプトも今までの開発とは異なる．
　　　　→ 新しい知識が必要

　　◆ eSOL ECUSARを使用すれば，誰でも簡単にAUTOSARの導入が可能


4. シミュレーター

　◇ 概要

　　ZIPC AUTOSAR，eSOL ECUSARにより生成されたアプリケーションのシミュレーション
　を行う
　シミュレータの紹介．AUTOSAR仕様のソースコードをシミュレーション可能．


　◇ 組込みソフトのシミュレータ

　　◆ MILS(model in the loop simulation)
　　　　・ 数式モデルを使った試験/評価
　　　　・ MATLAB/Simulink(Mathworks)

　　◆ SILS(Software in the loop simulation)
　　　　・ Cソースコードを使った試験/評価
　　　　・ Visual Spec for Embedded(インターデザイン)

　　◆ PILS(Processor in the loop simulation)
　　　　・ オブジェクトコード，バイナリコードを使った試験/評価
　　　　・ COMET(シノプシス)，NO.1 シミュレータ(ガイオ) など

　　◆ HILS(Hardware in the loop simulation)
　　　　・ 実機のECUを使った試験/評価
　　　　・ dSPACE，CRAMAS(富士通テン) など


　◇ 従来のSILS方式と課題

　　◆ Windows用のソフトとして動作させる
　　　　→ そのままコンパイルしてしまうと，組込み用のコードと書き方が異なる
　　　　→ ターゲットとなるマイコンとは演算時間などが異なる

　◇ Visual Specのシミュレータ

　　◆ 生成されたCコードを解析し，実際のターゲットマイコン上でどのように動いてい
　　　くかをキチンと見ることができるようにするもの
　　　　→ 仮想環境でも，実際のボードの上で動いているものと同じ動作

　◇ ターゲットマイコンの演算時間の模擬

　　1. ソースコードをターゲットコンパイルに入力し，アセンブリコードを生成
　　2. アセンブリコードから使われている命令を抽出．
　　3. 各命令にどのくらいの時間がかかるかを解析
　　4. ターゲットボードを模擬した時間制限付きのCコードを生成

　　◆ 対応プロセッサ，ターゲットコンパイラ

　　　・ ARM7，ARM9：　　　　am-elf-gcc，RealView，Green Hills Software
　　　・ Toshiba TX49：　　　Green Hills Software
　　　・ MIPS64 5Kf：　　　　Green Hills Software
　　　・ NEC V850ES，V850E1：Green Hills Software
　　　・ RENESAS SH-2E：　　 ルネサス SuperHファミリ用 C/C++ shc

　◇ Visual Spec for Embeddedの特徴

　　　・ 高速なシミュレーション
　　　・ 豊富なデバッグ・解析機能
　　　・ 試験のバッチ処理化・自動化が容易
　　　・ 仮想モデルの流通が容易

　◇ Visual Spec for Automotive

　　　・ Visual Spec for Embedded を車載システム設計向けに機能強化

　　　◆ 車載標準プラットフォームに対応
　　　　　・ CAN2.0，OSEK，車載マイコン
　　　　　・ ECUソフトウェア，RTOS(OSEK)，CANパスの性能計測/評価の容易化

　　　◆ 新規機能
　　　　　・ カバレッジ計測機能
　　　　　・ CAPLコード活用機能
　　　　　　　→ CANoe(ベクター社製)のCAPL言語コードをECU試験のテストベンチと
　　　　　　　　して利用するための機能

　◇ シミュレータを使った，車載ソフトウェアの試験/評価

　　　◆ 生成されたソースコードのECUイメージのデバッグ

　　　◆ AUTOSAR対応のECU，未対応のECUから構成されるソフトがどのような振舞を
　　　　するのかを試験

　　　◆ カバレッジ測定，テスト網羅性の向上

　　　◆ 共通のシミュレータを使うことでシミュレーションモデルの使いまわしが可能
　　　　　→ 単体ECUの試験 → 生成されたシミュレーションモデルをOEMに配布 
　　　　　→ 他のECUモデルと繋ぎ，統合試験が可能

　◇ まとめ

　　　◆ AUTOSARの普及により，車載ソフト開発は部品化/共通化が進む
　　　　　・ ソフトウェア規模の拡大により，テスト工数が増大する
　　　　　・ 個別/全体としての品質・性能確保のための検証手段がより重要になる

　　　◆ 従来の試験方法の限界
　　　　　・ 実機による試験では問題分析が難しい場合がある

　　　◆ モデルベースが必須武器
　　　　　・ 上流工程での設計仕様(モデル)を，下流の検証工程まで活用する

　　　◆ モデル/シミュレータを使ったソフトウェア試験
　　　　　・ SILS + 高速シミュレーション技術

　　　◆ シミュレータの普及に向けて
　　　　　・ モデルの汎用性・品揃えの確保/仮想モデルの流通が課題


5. デモ

　◇ Visual Spec for Atomotiveによる，生成済みのAUTOSARソースコードのシミュ
　　レーション

　◇ ZIPC AUTOSAR，eSOL ECUSARのツールチェインによるシステム開発(ラジコンカー)
　　のデモ


6. 質疑・応答

Q. (デモで紹介された)コードを埋め込むときの操作について，示されたデモではコード
　がないが，コードがある場合はどのようなイメージか？

A. アプリケーションのソースコードは用意されている．ソースコードのRunnable部分に，
　ジェネレイトしたソース
　コードを加える．何らかの処理を行う関数(関数でなくてもよい)をユーザが作成し，
　それをRunnable部分でコールする．Runnable内がユーザの実装範囲となる．
　Runnableは周期的に呼び出される設定となっている．


Q. OSを使う場合は，タスクの関数呼出しが作成されるのか？

A. OSがある場合は，Runnableがタスクから呼ばれるようになる．タスクがRunnableを
　呼ぶところまでをRTEが実装する．


Q. 割込み周りは？

A. 割込みからのRunnable機能は今のところ対応していない．


Q. Runnableの呼出し周期はシステム側で書いているものを使っているのか？

A. そのRunnableを持ったSWC内(のプロパティ)で定義されている．


■ まとめ

各まとめを参照のこと．


以上．