AUTOSARの勘所

#第1章 AUTOSARとは何か？　
～結局のところ何？プログラム？規定？資料？入れ物？～

一言で言うと車に乗っけるプログラムを効率よく作るために制定されている、
結構融通の利くフォーマット集、ってので如何でしょうか。

しかしながら下記のように団体を指す場合もあったり、、

AUTOSARとは欧州において、自動車用ソフトウェア・プログラムの標準化を行っている団体（オートザー）。
車の電子制御化の進展に伴うネットワーク（車載LAN）開発の効率化を図り、
基本ソフトを国際標準化して開発コストを削減しようとするもの。ダイムラークライスラー（当時）、BMW、ボッシュなどが中心となって2003年に設立された団体で、日本の標準化団体であるJASPARからは、トヨタがコア・メンバとして参加している。

この他にも開発パートナーシップのことだと言われていたり、、

　2003年7月に公式に設立されたAUTOSAR（Automotive Open System Architecture）は、自動車業界全体における車載ソフトウェアの再利用や授受の促進により、自動車の電気電子（E／E）システムで増大し続ける複雑さへの対処を改善することを目的とした開発パートナーシップ（development partnership）である。約200の会員企業および団体から構成されている。

エンジニア同士の会話ではAUTOSARといいつつも、
AUTOSARに準拠したモジュール(プログラムの集まり)を指すこともあります。

つまり文脈によって判断する必要がある、ふわふわした面倒臭いやつということかな！

#第2章 なぜAUTOSARが誕生した？！　
　～普及の背景を探ろう～

ざっくりまとめると、コード量増えてきたのに標準化できてないから開発やテストに時間がかかる。それがソフトウェア開発の標準化を後押しして、誕生してきたのがAUTOSARである。
ってな感じでどうでしょうか。

ざっくりすぎて不安だと言われる方は下記を参照ください。。

たとえ同じ仕様書に基づく同一機能であったとしても、アプリケーション部分のソフトウェアの「実装」は、開発を手掛けるECUサプライヤーごとに、それぞれ別なものになってしまう（これは特に珍しいことではない）。
　こうした場合、実装と評価の作業（場合によっては、さらに仕様詳細の擦り合わせ作業）の重複が発生してしまう。もちろん、それを防ぐために、仕様書だけでなく、自動生成のためのモデルやソフトウェアのコードをセットで配布することも実際に行われている。
　しかし、マイコン性能に応じた対処や、ソフトウェアプラットフォーム（あるいは土台部分）とのインターフェイスの合わせ込みのためのコード書き換えなどの理由により、ECUサプライヤー側での組み込み作業工数が当初予想よりも多く掛かることも少なくはない。
　そもそも、ECUの構造は自動車業界全体で共通の認識が存在しているとはいい難い。
　ソフトウェアの土台部分についても、自動車メーカー側から指定されたものを使用するというケースがすでに一般的であるが、ECUサプライヤー各社が独自に用意し、各自動車メーカー向けに合わせ込みを行うケースもまた一般的である。
　そのため、さまざまなモジュールを統合して正しく動作させるためのいわゆる「インテグレーション」の作業では、自動車メーカーにより指定される土台部分の相違などによって、アプリケーション部分と土台部分との関係（接続方法や機能的な分担など）に関する予想外の重複や隙間への対処が必要となってしまうこともある。当然、当初から想定している事態ではないため、対処のためにごく限られた時間しか割くことができないということもあり得る。このことは、たとえ、モデルベース開発がすでに一般的であって、かつ、その都度ソフトウェアを新規開発するよりも、各種パラメーターの適合などを行う比率が高いというような分野であっても、同様である。
　また、構造や土台における相違は、複数の自動車メーカー向けにECUを供給しようとする場合の障害の1つにもなっている。もちろん、いくら汎用のものであったとしても、最終的には個別の要求に合わせ込まなければならない。そして、いうまでもなく、広い範囲で使うことができるという汎用性と、それを利用するうえで必要とされる資源やコストとの間には、一般にトレードオフの関係があるため、個別のケースでの利用可能な資源やコストに関する要求が厳しい自動車分野では、「いかなるケースにも適用可能な汎用品」が常に利用可能であると期待することはできない。そもそも、「個別の要求への合わせ込み」は、汎用製品を利用あるいは提供し続けていくうえでの永遠の課題でもある。構造や土台における相違は、その上に載せるものにいかに広い汎用性を持たせるか、ということを考えるうえで、「周囲の状況として想定すべきもの」を特定しにくい状況を生み出している。
　量産後も、新機能追加、あるいは、より安価な電子部品への切り替えといったことも、「ソフトウェア」に関連する「制約（実装内容の変更や再インテグレーションの工数など）」により、さほど自由に行うことができるわけではない。
車載エレクトロニクス業界のバイブルとも言われる調査報告書であるHANSEN REPORTによれば、メルセデスのベンツSクラス-2014年モデルに搭載されるECUのマイクロプロセッサは200個以上、車載ソフトウェアのコード数は最大で6500万行に及ぶそうです。2000年のコード行数は最大でおよそ100万行でしたが、その当時から2015年には1億行に達するという予測がありました。このことからも、前出のベンツSクラスの6500万行というのは予測の範囲内であると言えます。
この車載ソフトウェアコード量の劇的な急伸に対し、開発工数とそのコストの懸念が、自動車業界における問題です。

ふぅ。

#第3章 技術面の概要

当たり前ですがAUTOSARにどう関わるのかで、必要な理解度は全然違います。
例えば
○AUTOSARモジュールと自社製品モジュールを組み合わせたソフトの改修
○AUTOSARモジュールの改修
○AUTOSAR対応configツールの使用/作成
○元々AUTOSAR対応されていないソフトにAUTOSARを導入する場合
　この導入の場合でも
　・RTEとBSWの中のmcalのみ導入
　・RTEとBSWの中のmcal、OS、MEMを導入
　などなど開発現場によってパターンは数多く存在するかと思います。
　
その中でも勘所としては、
AUTOSARでのECUソフトは大きく分けてAPLとRTEとBSWの3つあるということでしょう。

これがどういう構造になってるかというと、、
こんなやつや

こんなものも良く目にするかと

そしてAUTOSARのメインソフトであるBSWに関しては
下記のように細かく機能が分かれていたりします。

さすがに全機能を抑えることは無謀無茶無理なので、
3つのソフトの概要を抑えて終了にしたいと思います。

#####APL
アプリケーション層は、モジュール化された複数のソフトウエアコンポーネント（Software Componet：SW-C）で構成される。SW-Cは、これまでECU単位で開発されていた各自動車システムを制御する機能に相当する。ただし、従来の車載ソフトウエアとは異なり、ハードウエアに依存しないので、異なるハードウエア構成のECUでも再利用することができる。

#####RTE
APLとBSWのつなぎ役。
アプリケーション層内のSW-CとSW-Cとの間、SW-CとBSWの間をつなぐインターフェースである。既存の車載ソフトウエアでは、SW-C間で直接情報をやりとりしているが、AUTOSARでは、RTEを通して情報をやりとりすることになる。もちろん、SW-CとBSWとの間の情報のやりとりについても、RTEを通して行われることになる。
#####BSW
「どの自動車メーカー向けの、どのECUサプライヤーが作った、どの種類のECUにでも入っている、土台部分の基本ソフトウェア」であり、OS、通信スタック（CAN、LIN、FlexRay、Ethernetなど）、不揮発性メモリースタック、診断、入出力、モード管理などの各種機能を提供するソフトウェアモジュール群。
これらのモジュールも再利用が可能であり、汎用品として販売することもできる。

#さいごに
改めてAUTOSARとは。。。

####1. あくまで標準「規格」であり、それ自身は強制力を持つものではない
しばしば、「これは、AUTOSARに対する違反ではないのか？」という問いがあるようで。。
標準と名が付くものには法的拘束力があるのではないか、という不安からなのでしょうが実際には、法規制や個別の契約上の指定事項となった場合を除いては、規格単体では強制力を持たない（ISOなども同様）。
####2. あくまで標準「規格」であり、標準「 製品」ではない
AUTOSAR仕様書には多数の実装依存部分がある。また、その実装（製品）には、それぞれ仕様に対する拡張が加えられる場合がある。また、実装には品質など各種要因が付け加わる。したがって、同じ規格に基づくものであったとしても、製品における差は存在するものと仮定しなければならない。このことから、複数のモジュール供給元からの製品を組み合わせて使用することは、単一の供給元からのものを組み合わせて使用するよりも難しくなる可能性がある（トラブル解析など）。なお、AUTOSARには、いわゆるリファレンス実装（reference implementation）は存在しないが、自動車メーカーごとのものが存在することもある。

####3. あくまで「手段」「 道具」であり、「目的」ではない
AUTOSARを使うことそのものは、最終的な目的ではない。それを利用して、最終的な目的を実現するための手段あるいは道具である。
当然、AUTOSARでは足らない部分があれば、それに対応するための処置を、AUTOSARで想定された範囲に対する「拡張」として個別に講じていく必要がある。

#参考文献
AUTOSARで変わる車載ソフトウエア開発
https://monoist.atmarkit.co.jp/mn/articles/0910/01/news123.html

はじめてのAUTOSAR(Mentor)
https://www.mentorg.co.jp/news_and_views/automotive/2014/spring.html

はじめてのAUTOSAR(Vector)
https://assets.vector.com/cms/content/know-how/VJ/PDF/For_Beginners_AUTOSAR.pdf