**********************************************************************
セッション ：s5b
テーマ ：AUTOSARの基礎
講師 ：山本 健太 株式会社デンソークリエイト
日時 ：2020/08/21(金) 15:10～16:20
参加人数 ：46名
**********************************************************************
・本講義の目的
AUTOSARに関する基礎的な知識を獲得すること
・本講義のゴール
AUTOSARの導入・使用に対する目的やうれしさを知る
AUTOSARの開発の流れ、ツールに関する情報を知る
AUTOSARの基本的な機能、構成および用語を理解する
■AUTOSARの概要
The Automotive Open System Architectureの略
自動車メーカーやサプライヤが中心に設立
車載電気・電子システムアーキテクチャにおけるオープンな業界標準の構築
下記のパートナーシップがある
・コアパートナー
⇒組織の運営、管理を行う。仕様の決定権を持つ。
・ストラテジーパートナー
⇒コアパートナーやプレミアムパートナーとともに仕様を策定する
・プレミアムパートナー
⇒組織への参加、策定中仕様へのアクセスする権利がある
・ディベロップメントパートナー
⇒専門知識を持ち、策定された使用のアクセス、利用が可能
・他（アソシエイトメンバー、アテンディ）
○車載ソフトウェアの開発の現状
ソフトウェアの実装量が増大している
⇒昔はECUが個別で動いていたが、協調して動かすようになっている
⇒うまくやるために複雑化している
・複雑化する開発プロセス
・品質、コストへの厳しい要求
⇒これらの問題を解決するための標準化の取り組みを行いAUTOSARが生まれた。
○AUTOSARの特徴
・AUTOSAR方法論：開発方法論の標準化
V字プロセスの設計やコード生成といったところを標準化している
⇒各設計工程や単体システム開発工程ではXMLファイルを作成する
・アプリケーションインタフェース：機能間でやり取りする情報の標準化
アプリケーションを構成する各機能のソフトウェアコンポーネント間インタフェースを標準化
Virtual Function Bus(仮想機能バス)を使用し、コンポーネントは下回りがどのようなものか意識せずに、
あくまで自分が出すインタフェースとそこに流れるデータを定義していく
・レイヤードアーキテクチャ：ソフトウェアアーキテクチャの標準化
アプリケーションを再配置、再利用するためのソフト構造を標準化
共通ソフトウェアプラットフォームの提供
⇒AUTOSARでは「アプリケーション層」「RTE(Runtime Environment)」「BSW(Basic Software)」「マイコン（MCU）」
を分けて、層間のインタフェースを定義することで上下の層に変更があっても、自層は変更をしなくてよくなる。
○AUTOSARを導入するメリット
・ソフトウェアの再利用、再配置が容易になるため、品質の向上、コスト削減に貢献できる
・欧州をはじめとしたOEMメーカー、サプライヤと対等に話ができる
○AUTOSARで提供する標準化のソリューションは５種類
・Acceptance Tests For Classic Platform
⇒Classic Platformのソフトの受け入れのテストを定義している
・Application Interface
⇒ソフトウェアコンポーネントが使用できるインタフェースを定義
・Classic Platform(CP)
⇒リアルタイム性と安全性のある組込み向けのソリューション
・Adaptive Platform(AP)
⇒高性能なECU向けのソリューション
・Foundation
⇒クラシックやアダプティブの共通の仕様
開発におけるメインのソリューションは「Classic Platform」「Adaptive Platform」
○Classic Platformについて
車両内のソフトウェアのリアルタイム性や信頼性を満たしつつ、開発コストや再利用性を高めるために、
開発プロセスや仕様の標準化したもの
⇒あるソフトウェアが別のソフトウェアを壊さない
⇒システムは規定時間内に応答を返す
○Adaptive Platformについて
運転支援技術や自動運転技術が高まるにつれて、車載内だけに留まらない新しい課題が増えてきており、
Classic Platformでは対応が難しくなってきているので、新たにAdaptive Platformを新しいソリューションとして立ち上げた
Classic PlatformとAdaptive Platformを比較したとき、どちらが優れているという話でなく適材適所で使い分ける必要がある。
■Classic Platformの開発の流れ
○開発の流れ
AUTOSAR方法論に基づき上流設計から詳細設計，実装まで一連の流れを標準化し、
通信ネットワーク，ECU，マイコンの設定を順序立てて行う
1.車両アーキテクチャ設計：車両全体を設計する
2.車両システム設計：車両全体を設計する
3.ECU単体システム設計：ECU単体の情報を抽出する
⇒OEMによっては従来開発の入力を利用するケースもある
4.ECU単体システム開発：ECU単体のソフトウェアを設計する
⇒I/Fが標準化されることで、SW-Cを再利用可能になる
⇒BSWのコンフィグレーションも市販ツールで可能になる
5.実装：関数をコーディングする
⇒COMの差異はRETで吸収し、SW-CはCOMに作用されずに実装できる
⇒規定された形式でXMLファイルを作成し、次工程の入力とする
まとめ：開発の流れに大きな違いはない
⇒成果物を標準化することでツールの開発工数が削減され、インターフェースを標準化することで
SW-Cの再利用が可能となった。
■AUTOSAR開発のツールチェーン
AUTOSAR方法論では、各アクティビティに対して使用するツールが規定されている
⇒ツールは15種類ある
AUTOSARツールチェーンのうれしさ
・ツールの接続によるやりたいことに適合したツール環境の構築ができる
・自動化による手間の削減や、品質が向上する
・RTEの自動生成によるVFBの実現できる
・設計情報を管理できる
・シミュレーションツールとの連携によって早期にテストが実施できる
AUTOSARツールチェーンの課題
・ツールチェーンの不成立
⇒ツールの対象範囲やAUTOSAR解釈の違いなど
・変更の影響範囲をコントロールしにくい
・作業にツールが必須となる
・設計内容が確認しにくい
■AUTOSAR固有用語
○Software Component (SW-C)
車両の機能を構成する要素
⇒ハードに依存しないソフトウェアモジュール
⇒Software Componentは9つ種類がある
○Virtual Functional Bus (VFB)
ハード構成を意識せずに機能設計するための仮想バス
⇒SW-C間の通信プロトコル、ハードウェア、タイミング設計等は考慮しない
○Port
SW-C間でやり取りするための口
○Port Interface
SW-C間でやり取りするための口
⇒ECU内/ECU外通信、使用するプロトコルはここでは考慮しない
⇒提供側のPortをPPort、要求側のPortをRPortという
○コネクタ
SW-Cのポート同士をつなぐ存在
⇒接続可能なポートは以下の条件を満たす必要がある
■BSWの概要
BSW（Basic SoftWare）の略
RTEとMicrocontrollerを繋ぐ層
○BSWの構成
1.Service Layer：アプリケーションが共通に使用する機能を提供
５つのサービスがある
・System Services：OSが持っている機能を提供
・Memory Services：メモリへのアクセス機能を提供
・Cypto Services：セキュリティ演算の機能を提供
・Off-board Communication Services：通信の中でも車外とつながる機能を提供
・Communication Services：従来の通信の機能を提供している
2.ECU Abstraction Layer：MCALが提供するデータ値をアプリケーションが使用 できるように抽象化
ECU同士の差分を抽出する
・Onboard Device Abstraction
・Memory Hardware Abstraction
・Crypto Hardware Abstraction
・Wireless Communication HW Abstraction
・Communication Hardware Abstraction
・I/O Hardware Abstraction
3.Microcontroller Abstraction Layer：デバイスドライバを標準化し、ハードウェアに依存するデータ値を抽象化
各LayerはStackと呼ばれるサービスの種別毎にさらに分割される
・Microcontroller Drivers
・Memory Drivers
・Communication Drivers
・I/O Drivers
・Crypto Drivers
・Wireless Communication Drivers
4.Complex Drivers：AUTOSARで定義されていない機能を提供
○BSW Stack概要
・Communication
⇒車載ネットワークシステム、ECUオンボード通信システム、ECU内SW間通信へのアクセスを標準化する
・Off-board Communication Services
⇒車輌ワイヤレスネットワークシステムを用いたV2X通信へのアクセスを標準化する
⇒外部ワイヤレスEthernetコントローラの制御にも対応している
・System
⇒標準化可能な機能OS、タイマ、エラーメモリ管理
⇒ECU特有のサービスECU状態管理、ウォッチドッグ管理
⇒各種ライブラリ固定/浮動小数点演算、E2E、CRC、Crypto、 Bi制御、その他拡張機能
・Memory
⇒内部/外部不揮発性メモリへのアクセスを標準化する
⇒対象デバイスはEEPROM/FlashROM
⇒データ冗長化や書き込み回数を考慮した制御も可能
・Crypto
⇒暗号化機能へのアクセスを標準化する
⇒ハードウェアによる暗号化、ソフトウェアによる暗号化双方をサポートする
⇒外部Cryptコントローラの制御にも対応
・Input/Output(I/O)
⇒ECUオンボードの周辺機器へのアクセスを標準化する
⇒Port：物理ポートの入出力、機能等を設定
⇒Dio：汎用入出力ポート制御
⇒Adc：A/D変換制御
⇒Pwm：Pulse width modulator制御
⇒Icu：Input Capture制御
⇒Ocu：OutputCompare制御
○実際の開発で感じたこと
実際に開発した工程
・ECU単体システム設計
・ECU単体システム開発
・コード生成
★うれしさ
・コンフィグレーションするだけでコードが自動的に生成される
・Communication StackやDiagnosticのように標準規格に従う機能は、 製品毎に違いが少ないため、
BSWを再利用でしやすい
・OEMとの仕様調整がAUTOSARをベースとするため容易になる
★課題
・ベンダ毎の仕様解釈の違い、独自仕様に起因したインテグ問題
⇒フォーマットが違うことで異なるベンダのツールが使用できない
⇒ツールベンダー独自のI/F、型を持つ場合があり、異なるベンダのソフト同士を結合できない
⇒ベンダ毎に仕様準拠状況、制約が異なるため、ベンダの変更に対する影響が 大きい 等々
・購入した3rd Party製ソフトの品質保証
⇒使っても本当に大丈夫か検証する必要がある
・AUTOSAR仕様ではOEM要件（機能/非機能関わらず）が 少なからずある
■質疑応答
Q1：AUTOSARのツールの課題として設計内容が一覧しできず確認しにくいとあるが、
一気に見ることができるツールはないイメージは無いで良いか？
A1：ひとつずつ項目をクリックしたらプロパティが出てくるのでそれを確認する形が多い
Q2：日本のOEMはAUTOSARで仕様を渡してこず、サプライヤがAUTOSAR化するかたちで、
負担となっていると伺っているが、山本さんの体感は如何でしょうか？
A2：OEMにもよる。独自路線を貫くOEMもあり苦労している。
Q2-2：それは前からか？
A2-2：2、3年前ぐらいから携わっているOEMはAUTOSARに寄せた仕様を出してきていた
Q3：既存のClassic PlatformでBSWとかで自動生成だけでなくハンドコードを組み込むことがあるという認識だが、
AdaptiveでそのようなことをしたときにClassicとの違いはあるか？
A3：違いはあると思うが、そこまで違いはあるかはわからない。