マルチコアマイコンへの対応で進化するAUTOSAR Classic Platform（後編）：AUTOSARを使いこなす（20）（3/5 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第20回では、前回に引き続き、AUTOSAR Classic Platformにおけるマルチコアマイコンへの対応について解説する。

[櫻井剛，MONOist]

現実に見えてきたECU統合

　連載第3回では、AUTOSAR導入の背後にある一般的な性質に関する私見をまとめたもの（表2）をご紹介しました。

	性質の概要
1．	自動化の効果への依存（の拡大、以下同様）
2．	再利用の効果への依存（再利用の対象はコードだけに限らない）
3．	高度な技術的内容のブラックボックス化
4．	バイナリ形式のソフトウェアの利用拡大
5．	既存のものと性質の異なる何かからの移行
6．	より頻繁な、水平/垂直方向の情報/成果物の授受
7．	形式化された情報の授受の拡大
8．	形式化された情報の利用の拡大
9．	自動生成コードへの依存
10．	外部調達品の利用拡大
11．	既製品の利用（COTS: 商用オフザシェルフを含む）
12．	多目的製品（汎用品）の利用
13．	設定により振る舞いの変わるソフトウェアの利用
14．	標準規格の利用
15．	変化し続けるものの利用
16．	インタフェースと振る舞いの分離
17．	ソフトウェアの配置自由度の向上
18．	リアルタイムOS（RTOS: Real Time Operating System）の採用（日本ではいまだ課題になることが……）
表2　AUTOSAR導入の背後にある一般的な性質（改訂版）

　一方、本CP Flexibilityコンセプトに関して、R20-11のRelease Overview文書では「to split today's monolithic AUTOSAR Classic Platform binary into several software clusters that can be independently developed, integrated, tested, and programmed.」としか書かれていませんので分かりにくいのですが、ヒントは「モノリシック」「独立して」の2つのキーワードです。

　これらから、何か見えてくるものはないでしょうか？

　例えば、以前はソフトウェアの単体流通／納入の機会はさほど多くはなかったので、SW-Cに関する可搬性や配置自由度の向上といってもピンとしない方も多かったと思います^※6）。

※6）ECU統合、可搬性、配置自由度：実際、AUTOSARやJASPARなどの会合では国内の自動車メーカーのE/Eアーキテクチャ部門の方々にご意見を伺った際には、2〜3年前であっても「そんなニーズは全くない」と断言されるばかりでした。私自身は2000年代前半にECU統合プロジェクトを実際に経験していたこともあり、また、欧州ではそういった話をよく耳にしましたので、「まだニーズが全くない？　本当に？」と半信半疑でしたが……。

　しかし、今はECU統合が現実に見えています。

　ECU統合となれば、統合対象のECUソフトウェアはそれぞれ「分散開発」ですし、可搬性の確保や配置自由度の向上なしに、それぞれ独立して開発してスムーズに統合することは困難でしょう。

　もちろん、AUTOSAR以外の独自のやり方で実現することができないわけではありません。

　しかし、その「独自のやり方」を維持していくことができるのか、「独自のやり方」に新たなプレイヤーを招き入れる／初めてコラボする際の初期コストや準備期間が許容可能なのか（手順書やテンプレートだけではなく、人財育成のための教育研修なども必要になります）、既存ツールの支援なしで実際に回していけるのかなど、いくらでも障壁を挙げていくことはできます^※7）。

※7）ツールによる支援：「ツールなしでも、工夫次第でどうにかなるのでは？」というような、指摘の体裁を取りながら、実はその実現可能性や議論の停止性の保証（明確な指摘クローズ条件の提示）が何もない指摘があったと耳にするたび、「大戦中の精神論」とつぶやきたくなります。

　ECU統合に関する私自身の古い経験を思い返してみると、双方にとって初の統合だったため、自社アーキテクチャを互いに限定開示^※8）するところからスタートし、どちらのアーキテクチャやワークフローなどに合わせるかの議論を経てSW更新／統合のプロセスまでのたたき台を作り上げ合意するまでに、かなりの時間を費やしましたし、「動く土台」を双方に提供するまでにもそれなりに時間がかかりました（「効率が悪い」だの「肝心の本来機能の開発が進んでいないじゃないか」だのと、上長や、周囲の「従来アーキ」でのベテラン勢から散々たたかれ、「土台に対する評価の低さ」を、身をもって理解したのを懐かしく思い出します）。

　今は保有するソフトウェア資産が膨大な量に膨れ上がっているでしょうから、合意にたどり着くのはより一層大変でしょう。しかし、標準化活動を積極的に活用しているところでは、普段から（＝組む相手方が決まる前から）開示範囲の限定^※8）に備え、また、プロジェクトが本格的に立ち上がる前に、合意やツールなどの準備を「前倒し」（フロントローディング）できている、とみることもできるのです^※9）。

※8）開示範囲の限定：当時、自社での開発経験しかありませんでしたから、何が「守るべき自社固有ノウハウなのか？」が分からず、何を開示してよい / 悪いのかを判断することすら困難でした。「隠す必要もない当たり前のものかどうか」を判断できるようになるために、「世の中の当たり前」を把握する機会の1つとして標準化活動も有用だと気づいたのは、JASPARやAUTOSARでの活動に携わるようになってからです。

※9）フロントローディングと垂直立ち上げ：振り返ってみると、十数年前にやたら流行っていた「垂直立ち上げ」は、十分な準備のもとで成功した事例もたくさんあるのでしょうが、中には「準備に対する支援（予算 / 工数など）はしないけど、立ち上げるって予告しておいたのだから、できて当たり前だよ、できたからといって特に評価しないよ」という意味で使われていたことも少なくありません。そして、その後によく耳にした「フロントローディング」も、必要な支援が付きにくく、ご苦労なさっておいでの方も少なくないという現実を見ていると、実質的に同じメッセージに見えてしまいます（何の助けにもならない威勢の良い掛け声だけ？　それこそ、連載第12回で述べた「自分以外への押し付け」「We = You（pl.）」の構図だよね？　アイ（I）はどこに行った？　のような辛らつなせりふが頭に浮かぶとともに、先行きに不安を覚えます）。