本記事では、SDV（software-defined vehicle）で何が変わるのか？また、それに関連するAUTOSAR導入の背後にある一般的な性質について、弊社のSafety/Security シニアエキスパートでありAUTOSARの仕様策定にも参画している櫻井から紹介します。
最近の自動車分野でのバズワードといえば、SDVでしょう。
訳語としてはソフトウェア定義型自動車あるいはソフトウェア定義自動車が使われているようですが、それらや、software-defined vehicleやsoftware-defined mobilityという英語の表現を見ても「いったい、これは何を意味するの?」と思われる方はたくさんいらっしゃると思います。
歴史を振り返ってみると、自動車におけるマイコンやソフトウェアの利用は1970年代にまでさかのぼるとのことです (※1)。
その頃のマイコンの利用はエンジンECUのみで、他の文献によればソースコード行数も2000行程度だったそうですが、時とともにECU規模も総数も増大し、ECU間通信ネットワーク技術を用いて相互につながるようになりました。ソースコード行数は図1に示すように指数関数的に増大し今や1億行ともいわれています。また、AI利用が進み、もはやソースコード行数だけでは規模を表現できなくなってしまっています。
図1: データで見るソフトウェアの規模の増大
2000年代初頭には、自動車分野でのソフトウェアの重要性の理解がだいぶ高まり、筆者が標準化活動に現在も参加しているAUTOSAR (AUTomotive Open System ARchitecture) やJASPAR (Japan Automotive Software Platform and Architecture) が設立されました。
また、AUTOSAR設立から10周年となった2013年には、イノベーションにおける、エレクトロニクスとソフトウェアの寄与比率は90%に達するとの評価が示されています (※2)。SDVと騒がれるようになった近頃急に、ソフトウェアの重要性が高まったというわけでもないのです。
(※1) 国立科学博物館産業技術史資料情報センター 産業技術史資料共通データベース (HITNET) にて、
「自動車 マイコン」で検索した結果より。
(※2) 10 years AUTOSAR: The Worldwide Automotive Standard for E/E Systems, ATZextra (2013-10-23)
では、SDVで何が変わるのでしょうか?
もしかしたら、それを考える上での材料として、「AUTOSARの導入の背後にある一般的な性質」もお役に立てるかもしれません。
もはや最近では「自動車のソフトウェア開発にはつきもの」となっているAUTOSARに関して、2018年よりアイティメディア様MONOistにて、「AUTOSARを使いこなす」と題する連載執筆の機会をいただいております (AUTOSAR関連で執筆した連載の3本目です)。
その第3回では、「AUTOSAR導入の背後にある一般的な性質」をご紹介いたしました。
そこに、RTOSの利用という、特に国内の一部の方々にとっての障壁 (第24回) を加えて整理し直したのが以下の18項目です (表1)。
表1: AUTOSAR CP導入の背後にある一般的な性質
| A1 | 自動化の効果への依存 (の拡大、以下同様) |
| A2 | 再利用の効果への依存 ※再利用の対象はプログラムコードだけに限らない |
| A3 | 高度な技術的内容のブラックボックス化 (による分業・作業並列化の効果への依存の拡大) |
| A4 | バイナリ形式のソフトウェアの利用拡大 ※解析への対抗や、「変化なし」という説明の活用 |
| A5 | 既存のものとは何らかの性質の異なる「何か」への移行 |
| A6 | より頻繁な、異なる立場間 (水平 / 垂直のそれぞれの方向) での、情報 / 成果物の授受 |
| A7 | 形式化された情報の利用への依存 |
| A8 | 形式化された情報の授受への依存 |
| A9 | 自動生成コードへの依存 |
| A10 | 外部調達品への依存 |
| A11 | 既製品の利用 (COTS: 商用オフザシェルフを含む) |
| A12 | 多目的・多用途製品 (汎用品) の利用 ※多様なコンテキストで利用できるものを、コンテキストを明らかにしながら、そこに当てはめ |
| A13 | 設定により振る舞いや構造 (ex. interface) の変わるソフトウェアの利用 |
| A14 | 標準化活動における合意に基づく、標準規格や成果とそれらに含まれる知財の利用 |
| A15 | 変化し続けるものの利用 ※reusable / updateableの裏返し |
| A16 | Interfaceと振る舞いのさらなる分離 ※interfaceや振る舞いの多階層化も含めて |
| A17 | ソフトウェアの配置自由度の向上 ※特に理由がなければ、どこで実行しても良い |
| A18 | リアルタイムOS (RTOS: Real Time Operating System) の利用 ※一部ではまだ障壁? |
これらは互いに独立でもなく、また、抽象度の階層が異なるものもまじりあっており整理の余地はありますが (整理しすぎると今度はイメージをつかみにくくなるというお声もいただいていますので、意図的にこれでとどめております)、もしも「SDVの背後にある一般的な性質」を書き出してみたとしたら、これら「AUTOSAR導入の背後にある一般的な性質」の内容の多くが含まれるのではないでしょうか (※3)。
(※3）これらの性質に該当することが、これまで全く行われてこなかったということでは決してありません。何らかの形で、多かれ少なかれ行われていたことと思います。ただ、AUTOSAR導入によって、さらに広く行われるようになったということは間違いないでしょう。そして、これらの性質がもたらすものには、うれしいこともあれば、うれしくないこともあります。そして、ある立場ではうれしいことも、別の立場ではうれしくない、ということも起こるでしょう。各種制約や価値観 (常識を含む) に左右されます。ですから、「AUTOSAR導入によるうれしさ」を、誰にでも分かりやすく、実感の持てる形で一般論としてまとめようといくら努力しても、結果には必ずモヤモヤ感が付きまとうのです。これは、「SDVのうれしさ」でも同様でしょう。
また、SDVではさらに、たとえば以下のような要素が含まれてくるでしょう (表2 ※ここでは一部のみのご紹介です)。
表2: SDVの背後に表れうる追加の性質 (AUTOSAR CP導入の背後にある一般的な性質への追加)
| S1 | 「ソフトウェア」の意味合いの変化・範囲の拡大 (プログラムコードだけではなくAIデータも) |
| S2 | Edge computingへの依存 |
| S3 | Remote accessibilityへの依存 (Connectivity) |
| S4 | System-of-systemsとしてのインテグレーション (※4) ・検証・保証・補償と不適切な利用の阻止 |
| S5 | モノではなくサービス・機能 (feature)・性能に対する価値の評価や説明 |
| S6 | より頻繁でより広範囲のUpdate (ECU SWのみならず従来HWで実現した機能や、ネットワークの振る舞いなども - SDN: software-defined network) (※5) |
| S7 | 想定期間のupdateabilityを支えることに最適化したHWアーキテクチャ計画 |
| S8 | より汎化されたプレイヤー・アクターの集団 (※6) による、複雑なシステムの取り扱い方や期待の進化 (作る側と利用する側双方において) |
| S9 | より汎化されたプレイヤー・アクターのそれぞれに対するUXの個別最適化 (※7) |
| S10 | より汎化されたプレイヤー・アクターの巻き込みと相互の存在承認と合意の確立 |
(※4) インテグレーション完了条件 (integration goal) の定義という課題は一層困難になっていくでしょう。
(※5) なお、AUTOSAR CPではupdateはアーキテクチャ要素の対象外でした
(※6) 自然人, 法人, システムやAI (人格の観点では電子人 (Electronic Person) という表現もあるようですね) という
多様なプレイヤー・アクター同士がつながった広義のネットワーク。
(※7) 利用者側だけではなく、例えば、開発者それぞれに適した、APIを含む広義の開発環境の提供なども含む。
これらを議論・検討の起点とし、さらに深掘りすることで見えてくるものは、多数あるはずです。
ここでは、「A3) 高度な技術的内容のブラックボックス化 (による分業・作業並列化の効果への依存の拡大)」を例にとってみていきましょう。
AUTOSARやCOVESAなどで標準化の議論が進められているVehicle API / Automotive APIと呼ばれるものは、そのAPIによりさまざまな要素を捨象 (あるいは抽象化) することで、それら捨象された内容 (= ブラックボックスの中身) に関する深い知見を持たなくとも、さまざまな機能やサービスを開発できるようにしてくれます。ブラックボックスの蓋を開くことなくブラックボックスのままで手軽に利用できる、というわけです。
ただし、それは順調に進んでいる時だけに限られます。
順調でなくなれば、APIというブラックボックスの蓋を開け、中に手を突っ込み対処していくことが必要になります。
「自分の関心領域はここだけだ」としていて、中に手を突っ込み対処する際の備えがなければ、手詰まりになってしまいます。
ですから、APIを「壁」として扱う姿勢ではなく、積極的に「中の対処をできる人ともつながれるように、あらかじめ準備しておく」という姿勢が求められることが、見えてくるはずです。
実際、トラブルが起きたときに対処できる自信が持てないのであれば、その仕事に安心して携わることできないのは当然ですし、リスクマネジメントの観点で問題視されることも、これまた当然です。
現在提供している「AUTOSAR Classic Platform (CP) 入門トレーニング」では、AUTOSARというソフトウェアプラットフォームの技術面の解説をするだけではなく、その運用に役立つ上記のようなヒント・解説も含んでおります。コースにもよりますが、Q&A時間枠をご用意することも可能ですし、さらに踏み込んだコンサルティングサービスもご提供しております。
「AUTOSARを使いこなす」ことについて、その多義性を踏まえた見直しを行うことは、SDVの時代への備えにもつながります。
すでにAUTOSARを用いた開発のご経験をお持ちの方も、さらなる「使いこなし」のために、これを機にご受講いただいてはいかがでしょうか?
【本記事の続編はこちら】
SDVの時代を踏まえ、「AUTOSARの使いこなし」を見直してみませんか? (2)
【櫻井のMONOist連載はこちら】
AUTOSARを使いこなす（MONOist）
イーソル株式会社 ソフトウェア事業部 エンジニアリング本部 エンジニアリング管理部
Safety/Security シニアエキスパート
櫻井 剛
