加QNX Software Systemは2014年6月に「QNX OS for Automotive Safety 1.0」を発表したが、この製品が11月7日に発売開始された。これに併せて同日、都内でこの詳細についての説明会が開催されたので、その内容をお届けしたい。

まず説明に立ったのは中鉢善樹氏(Photo01)である。まず氏は、最近のトレンドを紹介しながら(Photo02)、そうしたトレンドを実現するためのシステムにはFunctional Safetyが必要であり、このためには認証取得が重要であることを説明した(Photo03)。

Photo01:QNX ビジネスデベロップメントマネージャ、アジア太平洋地区自動車分野担当の中鉢善樹氏

Photo02:制御ユニットが別系統になっていれば、たとえばインフォテイメントがリブートしても走行にはそれほど支障がない訳だが、高機能化と低価格化への要求は厳しいから、これを1つのシステムでというニーズが当然の様にでてくる

Photo03:別に認証が無いとFunctional Safetyが実現出来ないわけではないが、法的な制約もあり、Functional Safetyを実装した場合には、これが安全規格を満たしていることを認証取得という形で示さないとこれからは自動車が販売できなくなってゆく

その一方で、最近の車載インタフェースはどんどん進化しており(Photo04)、こうしたものをOSの側で取り込んでゆく必要が出てきている(Photo05)。またもう1つのトレンドとして、カーナビ→スマホへの移行や2020年を目処にした自動運転技術の加速なども、自動車向けのシステム全体を更新するためのきっかけになりえる。

Photo04:ここはこれまで同社が手がけてきた部分でもある

Photo05:赤が安全系のシステム、青が非安全系のシステムであるが、たとえばPhoto04にもあるように、デジタルクラスタでスマートフォン連携の表示を行うなど、段々両者の垣根が低くなりつつある

こうしたトレンドに向けた同社の製品が今回発売を開始したQNX OS for Automotive Safetyになるわけだが、その部分の説明は続くZheng氏に任せ、中鉢氏は最後にAPACのAutomotive Supportの体制について簡単に紹介(Photo07)、すでに十分なサポート体制を整えている事を説明した。

Photo06:これまで高級車向けだったADASシステムが、どんどん低価格化すると共に普及してゆく事になる

Photo07:この話は、後のインプリメントのところに繋がる

続いてYi Zheng氏(Photo08)から製品説明が行われた。最初の話はGoogleの自動運転車(Photo09)で、これはあくまでも研究レベルのもので今すぐ実車に搭載できるものではないが、それでもここから段階的に自動運転車の実現に向けての開発が進むことになる。

Photo08:QNX本社のYi Zheng氏(Product Manager)

Photo09:Googleのおかげで、自動運転とかそれに伴う色々なものにフォーカスがあたるようになった事は非常に喜ばしい、との事。まぁそれはそうだろう

こうした開発が進むということは、より多くのシステムが車に搭載されるということであるが、するとこんな問題が派生的に出てくることになる。こうした諸々に対する安全性を担保するにあたり、Functional Safetyの考え方が求められているのは説明の必要はないだろう(Photo11)。

Photo10:2007年に米国で起きたトヨタのカムリの暴走による死亡事故の訴訟では、ETCS(電子制御スロットル)のソースコードに欠陥があったという原告側調査機関によるレポートが2013年に出たことは記憶にあたらしい。今後はこうした事が厳しく追及されることになる

Photo11:従来の静的な状態での安全性の確保では、すでに間に合わなくなっているということでもある

さて、ここからが本題である。QNX OS for Automotive SafetyはISO 26262 ASIL-Dの認証を取得したRTOSである(Photo12)。

Photo12:根本的な話として、従来ISO26262 ASIL-Dを取得するようなシステムにはOSが使われてこなかった。ただ、いつまでもOS無しのままでも良いか、というのが同社の問いかけでもある

ISO26262を取得した製品は、ことハードウェアに関する限りはかなり存在するが、ソフトウェアに関してはそう多くない。この結果として、ISO26262を要求されるような用途にOSを導入することが可能になった(Photo13)という事になる。加えて同社はすでに自動車業界に十分な実績がある(Photo14)。もちろんこれはインフォテイメント向けのOSで、機能安全に関する部分は搭載されていない。ところが、これとは別にQNXは産業機器向けに、すでにIEC 61508 SIL3を取得したOSをリリースしており(Photo15)、今回はインフォテイメント向けのOSに、IEC 61508 SIL3を取得した際の知見を生かしながらISO26262 ASIL-Dの認証を追加した、ということになる(Photo15)。実のところ、IEC 61508の認証取得の際に、ソフトウェアの故障確率を定量的に測定できる事を証明し、かつ実際に確率を測定して示すことでIEC 61508 SIL3が取得できた(Zheng氏)という話もあり、こうしたスキームがそのまま今回の製品にも生かされた形である。

Photo13:3番目の項目は、要するに仮想化によって機能安全系とそれ以外(場合によっては機能安全同士)を別パーティションに分割できるという話である

Photo14:2014年3月にはSDP 6.6がリリースされている

Photo15:もともとIEC 61508は産業インフラ向けの機能安全規格であり、必ずしも車に適当とは言えない部分もある。そこで車向けに作り直したものがISO26262であるが、これが制定される前はIEC 61508を車向けに適用していた事例もあり、その意味では異なる規格とは言え、共通性はそう低くない

また先ほどのPhoto10にも関わる話だが、いわゆる「GPL汚染」を避ける事も訴訟対策としては重要であるし、こうした安全系のシステムの場合は必ずしもOpen Sourceであることは顧客に対してのアピールポイントにならない。今回の製品のカーネルは既存のQNX SDPそのままであり(認証の取得に手間がかかる関係で、今回はまだSDP 6.6相当ではなくSDP 6.5 SP1相当だそうである)、これはQNXの独自のもの(つまりQNX Neutrino)で、これはOpen Sourceでもなんでもないのだが、それゆえのメリットがむしろこの場合には大きい、というのがZheng氏の主張である。

Photo16:もちろんQNXのコードに絶対他のコードが混じらないという保障はないのだが、それをなるべく防ぐと共に問題があったら速やかにそれの履歴を遡れるような体制を整えているとする

さて、説明そのものはこの程度であったが、質疑応答をベースにもう少し補足説明を行いたい。基本的にQNX OS for Automotive Safetyは先に述べたとおり、Functional Safetyの分野にRTOSを導入したいというニーズに答えるものである。ただし特定のハードウェアには依存しない。

というのは、元になったIEC 61508向けのQNX OSの場合、そもそもそうした産業機器向け専用のASICというかASSPなどは無いから、システムを構築する顧客は自分でASICなりASSPなりを使って安全基準を満たすハードウェアを作り、その上でQNX OSを動かすという形になる。これは自動車向けでも同じことで、既存の適当な自動車向け半導体を組み合わせてISO26262の安全基準を満足するハードウェアを作り、その上でこの製品を動かすという形の動作を考えている。逆に言えば、すでに自動車向けにISO26262 ASIL-Dの認証を取ったMCUには依存しないというか、短期的に対応するといった考えは特にないらしい。現実問題として、現在ISO26262 ASIL-Dに対応するアーキテクチャは

  • PowerPC(Freescale/STMicroelectronics)
  • Cortex-R(TI/Spansion)
  • TriCore(Infineon)

といったところで、QNX SDPが主なターゲットとしているCortex-Aシリーズとちょっと異なっている。ではこのあたりの擦りあわせをするのか? とおもいきや、特にそういう話は考えていないそうで、実際最初のターゲットはCortex-A15あたりをベースにした自動車向けSoCということになるそうだ。もちろんQNXは最終的に顧客がISO26262を取得するためのコンサルティングサービスを提供するが、これは当然ながらソフトウェアのパートになり、ハードウェアまで含めた包括コンサルティングは考えていないとの事だった。

ところでPhoto12には、"ISO26262 ASIL D システムでの使用に対し認証を取得した初のリアルタイム オペレーティング システム"という文言が踊っているが、実はこれはちょっと微妙な表現である。ISO26262 ASIL-Dを取得したOSという意味では、たとえばVectorのMICROSAR OS SafeContextが2013年3月に取得しているからだ。

ただこれはTMS570プロセッサでしか利用できない(つまり汎用OSとは言いがたい)し、AUTOSAR OSをどう位置づけるかで判断が変わってくる。そこでAUTOSAR OSをどう思うかZheng氏に尋ねたところ、「たしかにQNXはAUTOSAR OSとは互換性が無いから、既存のAUTOSARアプリケーションは動かないが、これらはメンテナンスモードに入っており、今から新規でAUTOSARアプリケーションを作ろう、という顧客はあまり居ないと思う」という返事であった。要するにPhoto05に出てくるような、Sensor Fusionとかスマートフォン連携、将来的には自動運転に繋がってゆくようなADAS機能はこれからアプリケーションを書き始めるわけで、こうしたマーケットをこの製品で積極的に取ってゆきたい、という事ではないかと思う。

余談になるが、「もし顧客がISO26262 ASIL-Dに対応済のMCUとこの製品を組み合わせたいと思った場合、半導体メーカーとQNXの両方からISO26262のコンサルティングを受けることになる。その場合、誰がこの2つの提供するものをマージする作業を担うのか?」と尋ねたところ「メーカーがやるか、Tier 1がやるかのどちらかだと思う」とした上で「どちらがやるにしてもすごい大変な作業だと思う。もしそういうことが出来るコンサルタント会社があったら、すごく儲かるでしょうね(笑)」と返ってきた。その位にISO26262の認証取得は大変な作業であり、それゆえにこの製品で市場に切り込んで行けると同社が確信していることが良く判る返事であった。