車載 OS について語る
Ryo Takahashiはじめに
他分野のエンジニアに「1回のミーティングで車載OSについて教えて」と相談されることがあったため、その説明の際に使ったメモ書きを共有する。一応、最初に予防線を張っておくと、私自身、車載ソフトウェア業界に身を置くが、「いわゆる車載OS分野の専門家か？」というとそうでもないし、やや距離のある分野の方への説明なので、ツッコミはお手柔らかにお願いしたい。
Ryo TakahashiISO-26262機能安全について
OSという耽美な響きからGeekでTechな話を期待されたかもしれないが、まず国際標準の話から説明を始める。というのも、この点が生命・財産に関わるソフトウェアと、そうでないソフトウェアを分かつ、大きな前提のため、ここはスキップできない。
機能安全とは？
国際標準とは世界で統一的なコミュニケーションを図るための規格であり、Terminologyについては他のどんな文書より定義が厳密なものだが、「1回のミーティング」という枠でASAPで概要を伝えるなら、下記PDF、とりわけP.12をお勧めする。つまり、故障(Failure)が起こる前提で、そのリスクを社会に受け入れ可能なレベルで管理するのが機能安全(Functional Safety)である。
(引用: 機能安全と安全部品 ~ISO-26262の概要~)
では、結局どう設計すれば良いのか？
この点について、物凄く簡略かつ分かりやすく説明しているページとして、cadense社の「車載電子システム向け機能安全メソドロジ」をお勧めする。特に、セーフティメカニズムの説明が分かりやすく、結局のところ、設計フェーズにおいて下記メカニズムの導入が重要となる。
エラー訂正符号（ECC）
巡回冗長検査（CRC）
ハードウェア冗長
組み込み自己テスト（BIST）
ASILって何ですか？
この業界では、ASILという言葉をよく聞くが、ASILとはAutomotive Safety Integrity Level (ASIL)であり、その部品が許容可能なリスク範囲に収まるために「どの程度徹底して安全施策を施さなければならないか」のレベルである。ISO-26262では、頭ごなしに「どの部品も全力を尽くせ」などという非現実的なことを言わず、部品が引き起こすハザードに応じて適切な労力を割くよう、各部品をレベル分けする。特に、下記のAPTIV社の図は一発でASILの世界観が分かってお勧めである。
(引用: What is ASIL-D ?)
私は下流工程の人間なので、結局何をすれば良いか分からないですが…
結局のところ、従来的なソフトウェアの実装の際に重要になるのは、コーディング規約遵守、テストカバレッジ達成、文書作成である(最初に「従来的な」という限定表現を入れたのはAIにはISO-21448という別の規格があるから。この話はまた今度)。後者2つについては何処の業界でも共通的な作業だが、最初のコーディング規約遵守については、黒物家電やWeb業界では求められないレベルの厳密さを求められる。具体的には、C/C++の仕様の曖昧な部分を潰し、可読性を担保したMISRA C/C++という言語サブセットが存在し、この遵守が求められる。実のところ、ISO-26262自体ではMISRAを強制していないし、様々な批判もあるこの規約だが、2023年現在、ASILあり車載製品でビジネスを行おうとした場合、MISRAを無視することは難しい (非 MISRA を認証している ISO certificate body があったら、是非知りたい)。それに、可読性はある程度趣味の世界だが、曖昧性排除という観点で全力を尽くすと、恐らく Yet Another MISRAになる。もちろん、最近では「Rustこそ安全では？」という勢力はいて、Ferrous Systemsなどはそのための活動を頑張られている。OS、ミドルウェア、アプリ、全レイヤに関わる話なので、一朝一夕にとはいかないだろうが、心から応援したい。
これ守らなかったら、どうなるの？
時に国際標準の対応に苦労して、多くの業界人が「これ守らなかったら、どうなるの？」というチャレンジ精神を抱くが、国際標準の多くは世界各国の法規とリンクしており、公道でのビジネスやOEMとのビジネスを考えた時、国際標準を無視するのはあまり現実的ではない。例えば、AIに関連するISO-21448は、下記の図の通り、国連欧州経済委員会で制定された「自動車線維持システム(ALKS)法規基準」(UNR157)にリンクしている。
(引用: ISO 21448 SOTIF（Safety of the intended functionality）意図した機能の安全性―概要編―
)
その他、「10分で雰囲気を知りたい」という人には下記ページをお勧めする。
機能安全をもっと理解し、戦いに身を投じたいです !!
以上の通り、非常に奥が深い分野であり、上記レベルの表面的な理解ではプロとして不十分なため、この分野に興味のある方には下記書籍をお勧めしたい
正直なところ、ISO-26262自体は非常に強制力が強く、過去に決められた国際標準について、新進気鋭な技術者は「今後はこうあるべきだ」と憤ることも少ないが、上記書籍は頭ごなしに既存の規格を押し付けるのではなく、尖った若者への配慮も十分にされていて、個人的に非常に好感を持っている。
Ryo Takahashiミドルウェア
「車載OSって何ですか？」という問いに対して、古典的なOSカーネルを念頭に説明する人もいれば、Google Playのようなアプリ配布基盤/ランタイムに言及する人もいる。このように、ますます定義が曖昧な用語だが、昨今POSIXより上のミドルウェアのレイヤを車載OSの一部という人は少なくないと思う。
ROS
車載OS→動くモノのミドルウェア→Robot Operating Systemという発想でROSを想起する人は多いだろう。実際、ROS 2が誕生して以降、ROSは車載ソフトウェア業界において、日に日に重要になっている。しかし、上記のASIL準拠 or notという議論から、ロボティックス業界のソフトウェア資産をそのまま車載ソフトウェアに適用するのは難しい。もちろん、「ROSの資産をできる限り、効率良くISO-26262の世界に持ち込む」という勢力は存在して、例えばApex.AIさんはそのための基盤開発を日々頑張られている。ポイントとしては、下記図のように、リッチ過ぎるROSの機能をISO-26262のために"Feature set reduction"しているところだと思う。
(引用: Apex.AI Safe and certified software for autonomous mobility)
AUTOSAR
では、ROSの使用が難しいなら、車載ソフトウェアが世界中でバラバラに作られているかというと、そんなことはなくて、かつてのTRONやPOSIXのように標準化を進める団体も存在する。それがAUTOSARである。AUTOSARは、欧州系完成車・車載機器メーカが発足した団体であり、通信方式や開発言語、アプリの実行環境に関して規定している。概要については、MONOistの連載「AUTOSARを使いこなす」がやたらと素晴らしい。AUTOSAR自体は規格であり、技術的には、誰でもAUTOSAR準拠のミドルウェアを作れるが、国内的にはデンソー出資のAUBASS社などが頑張られている。
ROS vs AUTOSAR ?
こういう書き方をすると各所に怒られそうだが、様々なスタンスの方が現状いらっしゃって、状況は単純な二項対立ではない。例えば、こちらの名古屋大学・三菱電機の方々共著のレポート「車載知能制御システム向けソフトウェア設計手法の提案」では、下記のように製品フェーズによってROS 2からAUTOSAR-APに移行することを前提としている。
ROS2 はロボットアプリケーションの作成を支援するミドルウェアおよびツール群であり，ライブラリやシミュレーション環境が充実している．そのため，初期の開発段階で使用することに適しており，プロトタイプ開発で使用される．一方，AUTOSAR-AP は世界的に標準化が進められている車載システムの仕様のため，最終段階の製品開発に使用される．
また、ROSの実用化に腐心されているApex.AIも、ROSとAUTOSARが共存するアーキテクチャを提言しており、業界でのポジショニングにも寄るが、両方を意識することが重要である。
一方で、両方を意識するとは言っても、周辺の評価ツールや基盤ソフトウェアも、どのようなミドルウェアを用いるかに強く強く引っ張られるので、この議論は現在最も戦略性を求められるイシューである。
Ryo Takahashi狭義のOS
「OSってLinuxやBSDの話じゃないのか」と言う方もいると思うが、もちろんこれらの狭義のOSも重要である。ただ、多分に漏れず、ここでもASIL or notが大きな分かれ目となる。今一度、上記APTIV社の図を見直して欲しい。
IVI (In-Vehicle Infotainment)
現在、クルマのスマート化の文脈で、情報と娯楽の両方を提供するInfotainmentなるシステムが注目を浴びている。端的にいえば、カーナビの進化系だが、ここにはASILのない、Quality Management(QM)だけの世界が存在する。ここではMISRAが必須でないため、LinuxやAndroid Automotive、Flutterなど、非車載業界で主流のソフトウェア資産が流用できる。ただし、他の車載部品との通信など、車載固有の領域は存在するため、そのための拡張は行われており、下記AGLというOSSプロジェクトは正にそのど真ん中である。
では、「Linux=QM onlyか？」というと、将来は変わる可能性があって、例えばRed Hat社はASIL-Bを目指す意向を表明している。
AD/ADAS (自動運転/高度運転支援)
一方、AD/ADASのようなASILど真ん中の世界ではMISRAが前提となり、QNX、eMCOS、その他MISRA対応可能なRTOS(e.g. ThreadX, FreeRTOS, Zephyr, etc)などのOSが候補となる。ちなみにだが、QNXはかつてiPhone以前に次世代携帯電話業界を席巻した、BlackBerry社製のプロプライエタリOSである。市場の趨勢に応じて、業種転換を達成して、再びトッププレイヤーに返り咲く経営判断、心から尊敬する。
パフォーマンス重視のコア
AD/ADASでは、CPUの種類に応じて、使われるOSや設定が大きく変わる。古典的にはADAS=Microcontrollerな印象も強いが、昨今では画像処理やニューラルネットワークなどのハイパフォーマンス系のアプリが重要となり、ARM Cortex-AやNVIDIA Graceもよく使用される。ここでは下記要素が利用可能であり、比較的開発が容易である。
- 揮発メモリ: DRAM+多層キャッシュ、MMU
- ファイルシステム: UFS/eMMC
- アクセラレータ: NPU, GPU, DSP
また、昨今ではOSもSMPが主流となり、正直なところ、スマートフォンとあまり大きな差はない。「SMPって何ですか？」って方には、下記eSOL社の説明がお勧めである。
リアルタイム性重視のコア
認識と行動計画を行った後、最後の制御の段階になると、求められる要件が変わってくる。Deterministic Behaviorがより重要になり、AD/ADAS業界はこの要件をARM Cortex-RなどのCPUを用いて対処している。Cortex-Rは、Raspberry Piなどを愛用するDIY勢には馴染みがないと思うが、Cortex-Aにはない下記のような機能を提供する。
- Tightly Coupled Memory(TCM)+MMU不使用による確定的メモリアクセス
- L1キャッシュやバスでのECC
- Lockstepシステム開発を支えるデュアルコア構成
特に下の2点は、ISO-26262のセーフティメカニズムを実現するために必要不可欠な役割を果たしており、この点でCortex-Rは機能安全の核と言える存在である。また、Deterministic Behaviorが何よりも重要であるため、この世界のスケジューラはLinuxなどよりかなりシンプルである。OSのスケジューラについては、Preemption、Context、Time Slice、Timer Interruptなどの言葉がピンと来ないと厳しい世界なので、正直、ここに自信がない方は下記のページと書籍で何となくのイメージを持つことをお勧めする。
その他
コンテナ技術について
少し前に「アメリカ空軍がF-16にKubernetesを載せた」という話があり、「その内、自動車もKubernetesでソフトがデプロイされるんやろうな」という話なったが、上述の通り、公道 x 製品化となるとその道のりは決して簡単なものではない。では、「コンテナ技術は車載に無縁なのか？」というと、そんなことはなくてARM社が最近では下記のプロジェクトを立ち上げている。
この活動もRust同様、車載ソフトウェアのモダン化の一環であり、今日明日本格的に始動するかというと、私個人はそんなことないと思うが、クルマの電脳化は10~20年(もっと？)の計なので、内部の人間はこの手の活動をアジリティ高く追い続ける必要がある。
Ryo Takahashiさいごに
という訳で、「1回のミーティングで車載OSについて教えて」という友人のご相談から、いくつかググって、自分なりにコメント入れてみました。当然、このレベルの薄い理解度だと実際の仕事にはならない訳ですが、車載OSというある種のビジネス・ワードについて、「何処の話しているんですか？」の指差しに使っていただければ幸いです。