自動車の未来のための安全ソフトウェア - 自動運転の飛躍的 ......02 technic...

01

バーに通知したりします。すると、ドライバーが新たに生じたこの状態に対応しなければならず、それが緊急事態であれば車を止めることが必要になります。システムがリセット、または完全に無効化されれば、それは安全状態に移行したと見なされます。この ようなシステムをフェイルセーフシステムと呼びます。フェイルセーフシステムのソフトウェアは、指定された許容時間内にハードウェアとソフトウェアのフォールトを検出しなければなりません。特定のソフトウェア機能に対するデッドラインモニタリング、あるいは受信したデータの整合性や最新性の追加のチェック（E2E：エンドツーエンド保護）といったメカニズムがよく使用 されます。

故障時の運転の継続

コーヒーを淹れて一服することがドライバーに許されるのであれば、バックアップソリューションとして彼らをあてにすることは できず、そこには電子的な代替機能が必要になります（図1）。 このようなシステムでは、各チャンネルがそれぞれのフォールトを自ら検出できることが前提条件です。フォールトが発生すると、有効だったチャンネルが無効化され、2番目のチャンネルがその

高速道路を時速100キロで走行するキャンピングカー。ドライ バーは運転席にはおらず、奥の方でコーヒーを淹れています。 車は自動制御されているのです。このシナリオは今のところは フィクションですが、これが現実になる日もそう遠くありません。ただし、これを可能にするには、まだ多くの変更が車両システムに必要です。センサーを増やして環境を適切に認識する必要が あるのに加え、制御装置（ECU）を高速通信で接続し、そこから得られる膨大な情報を処理しなければなりません。しかし、それで十分なのでしょうか。たとえばソフトウェア開発にはどのような影響が考えられるでしょうか。単にこれまでと同じ開発でよいのでしょうか。今日、車両に搭載されているシステムは、そのほぼすべてが単一チャンネルで動作する設計となっています。単一チャンネルで あるということは、センサーからロジック、そしてアクチュエー ターに至るチェーン内の要素の1つにフォールトが発生すれば、 そのシステム全体が機能しなくなることを意味します。センサーやマイクロコントローラーなどの二重化による冗長化は行われていますが、その目的はあくまでもこのチェーンのフォールトを確実に検出することであり、フォールトを検出すれば、通常はそのECUをリセットしたり、システム全体のスイッチを切り、ドライ

自動運転の進歩に伴い、システムとそのハードウェア、そしてソフトウェアにはさらに高い信頼性が求められるようになりました。特に ソフトウェアについては、現在自動車業界で確立されている方法でこれに対応するのは非常に困難です。今後セーフティケースを作成していくには、どういった議論、手法、エビデンスが必要なのでしょうか。そしてそれは、AUTOSARベーシックソフトウェアにどのような影響を与えるのでしょうか。

自動運転の飛躍的進歩に求められる 将来性を考慮したAUTOSARベーシックソフトウェア

自動車の未来のための安全ソフトウェア

02

Technical Article / September 2018

車両の制御を引き継ぎます（図2A）。このようなシステムはフェイルオペレーショナルシステムと見なすことができます。システムやハードウェアの開発では、システムの個々のパーツは どこかのタイミングで、ある特定の確率で故障することが証明 されており、この確率については多様な数学的モデルが存在します。これらの手法を使用すれば、システムの安全性を評価し、それを論証することが可能になります。ここで重要なのは、数学的 モデルが存在するという事実です。以下では、確率で計算できる枠を超えた、2種類の故障について説明します。これからのシステムでは、コストや複雑化の抑制などの理由で、 2つのチャンネルのソフトウェア間で少なくとも部分的に同じものが使用されることがありえます。これによって生じるのが従属 故障、特に共通要因故障の問題です。このような故障がシステムに発生すると、2つの独立したチャンネルが同時に機能しなくなり（図2B）、そのシステム全体がタスクを実行できなくなる恐れがあります。これを解決するには、異なるメーカーのソフトウェアを使用するなどの多様性を取り入れるのも方法の1つですが、実際の実装時の相違点は注意して調べなければなりません。技術的な理由や商業的な理由、あるいは単に他の実装が存在しないという理由から、多様性の余地がないこともよくあります。共通 要因故障は発生確率が低く無視できるという意見もありますが、この主張を裏付ける確率モデルは存在するのでしょうか。

ランダムハードウェア故障についても同じ疑問が生じます。このキャンピングカーの制御システムは問題なく機能しているものの、現在有効なチャンネルで突然、ランダムハードウェア故障が検出されたとします。システムは正しく反応し、有効だったチャンネルを無効化します。同時に、ホットスタンバイモードで動作していたチャンネルが制御の引継ぎを試みます。ワークロードが急に変化するため、通信制御の切り替えには予想よりも時間がかかり、そこで通信が途切れます。このような故障の連鎖は即座に 検出はできるものの、適正な故障対策は取られていないのが 一般的です。リセットを行うと制御アプリケーションの状態情報はすべて失われてしまい、十分なデータが再送信された時には、コーヒーを淹れていたドライバーにとっては手遅れかもしれま せん。これは非常に特殊なタイプのデュアルポイント故障であって、 無視してかまわないという意見もあることでしょう。ただし、このような故障の連鎖は、レイテントフォールトとして捉えるのが 合理的でもあります（図2C）。ASIL D（自動車用安全度水準）では、全レイテントフォールトの90%を検出することが求められます。しかし、ソフトウェア内のフォールトを定量的に推定することは可能でしょうか。

図1: 考えられるフェイルオペレーショナルシステムのアーキテクチャーの1つ。冗長性は故障時の冗長チャンネルへの切替えに使用されます。

03

Technical Article / September 2018

AUTOSARベーシックソフトウェアには、通信とその他の基本 機能に対して安全要求が課せられます。安全関連ソフトウェアの開発では一般に、工数の過半数をテスト作業が占めます。そのためフェイルオペレーショナルシステムの 開発工数は、劇的に増加することが見込まれます。また、ソフト ウェアの特性の中にはテストが難しいものがあります。最悪実行時間(Worst-case execution time, WCET)のテストはそのようなものの1つです。並行処理に関わる動的な挙動も同様に、競合状態を防止するための掘り下げた解析を必要とします。どちらのタイプの解析も、最先端のツールがなければ不可能です。さらに、受入れ可能なレベルにまで初期リスクを減らすのに必要な、十分な措置が取られたかの論証は、ISO 26262で求められている制御／データフローの解析を行うことで裏付けられます。

未来のための安全ソフトウェア

フェイルセーフシステム向けのAUTOSARベーシックソフトウェアは、完全なASIL D認証済みAUTOSARベーシックソフトウェアであるベクターのMICROSAR（図3）を筆頭に、数年前から入手

ソフトウェアに対するフォールトアボイダンス

ソフトウェアのフォールトはいずれもシステマチックフォールト です。システマチックフォールトについて一般に許容可能な確率モデルを構築する試みは、現在に至るまで成功していません。 そのため、ソフトウェアにはフォールトアボイダンスを導入し、 システムレベルの解析から得られる、確率に基づく論証の有効性を損なわないようにしなければなりません。これにはフォールト検出だけでは不十分です。車両の制御が不可能になったことを システムが検出したとしても、キャンピングカーのドライバーには打つ手がありません。フォールトが発生した場合も、ドライバーが頼りにするのはキャンピングカーを制御するシステムなのです。複雑なソフトウェアでは、フォールトアボイダンスはどのように 実現できるのでしょうか。システマチックフォールトは適切な 開発プロセスによってのみ防止できます。機能安全規格であるISO 26262では、最低限のアクティビティーと手法が定義されています。フェイルオペレーショナルシステムはフェイルセーフ システムとは大きく異なり、フォールトを検出および緩和する 機能に加えて、さらに多くの機能が機能安全対象となります。

図2: 各種故障・フォールトとその影響

可能となっています。綿密なデータ／制御フローの解析と、ISO 26262に準拠したテストにより、 メモリにおける無干渉 (freedom from Interfer-ence）が実証されます。フェイルセーフシステム内の通信の不具合はエンドツーエンドの保護によって検出されます。このようなシステムは、パーティショニングのみを基盤とするシステムに比べて、 フェイルオペレーショナルの要求への備えが完璧に整っています。ただし、システマチック故障を完璧に回避する には、さらなる解析を行わなければなりません。たとえばMICROSARオペレーティングシステム では、最大実行時間を決定可能にすること、 そしてできる限り多くの決定論的な挙動を提供 することに一層の力点が置かれています。しかし、その場合ですら、現実的な上限を定めるのは容易ではないことが初期の解析から判明しています。同じことは、競合状態の回避を目的とした、並行して発生する挙動の解析についてもいえます。今日のシステムには、将来的に路上での自動運転を可能にする最新のソフトウェアとテクノロジーが着々と織り込まれていますが、ソフトウェアメーカー、自動車メーカー、そしてその1次／2次部品メーカーには、取り組むべき課題が依然として多く残されています。自動運転のキャンピングカーの奥に下がって コーヒーを楽しめるようになるまで、ドライバーはあと数年はハンドルを握る必要があるようです。

04

Technical Article / September 2018

Jonas Wolf (Dipl.-Ing.)シュツットガルト大学で宇宙工学を学んだ後、2012年より主任 プロダクトマネージャーとして機能安全を担当。

本稿は2018年9月にドイツで発行された『Elektronikautmotive/Special Edition “Safety & Security”』に掲載された記事内容を和訳したものです。

画像提供元：Vector Informatik

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部E-Mail: sales@jp.vector.com

図3：MICROSAR Safe – 安全関連ECU開発のためのAUTOSARベーシックソフトウェア