ISO 26262第2版、何が変わったのか？：半導体／IP業界にとって（1/2 ページ）

ISO 26262規格の最新版「ISO 26262:2018」（ISO 26262 第2版）は、これまでとどう変わったのでしょうか。半導体／IPサプライヤーの視点から、ISO 26262 第2版を紹介します。

[Kurt Shuler（Arteris IP），EE Times]

　もしあなたがどういう形であれカーエレクトロニクスの設計に携わっているのであれば、恐らく一般の方よりはISO 26262規格のことをよく理解しているでしょう。あなたの組織がカーエレクトロニクス設計の土台にしているISO 26262規格は2011年に発行された初版のものかもしれません。最新版は、正式にはISO 26262:2018として知られ、一般にISO 26262第2版と呼ばれています。

ISO 26262:2018（ISO 26262第2版）規格の概要 （クリックで拡大） 出典：ISO/FDIS

　規格は進化していくべきものですが、いったい何が、どのような理由で変わったのでしょう？　私は長年にわたってISO 26262規格策定作業グループのメンバーを務めています。特にIPに関してこの規格がどう解釈されるべきかという問題に取り組んできたのですが、正直なところ、非常に苦労しました。私の見解では、この規格はもともと、チップは1つの組織内で完全にゼロから作られるという暗黙の前提に基づいて書かれており、これはもはや時代遅れの考えです。IPベースの設計や、複数の企業またはサイトにまたがる設計に関してのガイダンスも十分ではありませんでした。そのためIPサプライヤーにとっての代用策は、Safety Element out of Context（SEooC）という仕組みを活用することでした。しかしこれは人の解釈を当てにしすぎたものでした。初版ではこのコンセプトに関する説明がほとんどなされてないため、インテグレーターにとって重要なことが何なのかをコンポーネントベンダーが、逆にコンポーネントベンダーにとって重要なことが何なのかをインテグレーターがそれぞれ自分たちで判断する必要がありました。

　私がこれらの問題について委員会に幾度となく文句（泣きごと？）を言ったところ、彼らはついに私を作業グループに招き入れてくれました。混乱していたのは私一人ではなく、他の人々も賛同してくれました。結果的に私たちはかなりの成果を上げられたように思います。私たちの努力は、最新の規格において、これまでよりはるかに明快で体系的で実際的な例を示すという形で実を結びました。最新版のパート11には、半導体および、半導体IP業界で働く私たちにとってとても有用で詳細な例が盛り込まれたと思っています。

自動運転に対応するために

　車の自動運転化が進んでいく中で安全規格がどのように適用されるのだろうか、と思っていらっしゃる方もいるでしょう。私が作業グループに参加した2013年当時の共通的な見方は、もし自動走行で何かが故障したら、ライトが点滅したり、ビープ音が鳴ったりして、ドライバーに運転の主導権が戻されるのだろう、というものでした。しかし技術進歩の速さは予想をはるかに超え、バックアップシステムに主導権を握らせた方が安全かもしれないというところまできています。業界は「fail operational（＝故障しても運転を継続できる、の意）」という新語を編み出してこれに言及しています（ちょうどこちらにNXP Semiconductorsの分かりやすい説明があります）。システムはもはやただ静かに止まるのではなく、フォールトトレラント、すなわち障害を許容するものになるのです。自動運転時代が迫ってきている今こそ、システムが故障した時にドライバーに頼るのではなく、より迅速に反応するバックアップシステムを用意しておかなければなりません。

　システムの自律性が高まるにつれて新たな安全上の懸念も生じます。例えシステムエラーや無作為なエラー（宇宙線が原因のものなど？）がなかったとしても、システムが安全上の問題を招いた時はどうなるのでしょう？　システムの意図された機能が安全上の問題を招くとしたら？　新しい自動化技術によって生み出されるこの種の問題はISO 26262第2版では扱われていません。第2版では引き続き、安全関連リスクに対するハードウェアとソフトウェアのレジリエンスならびに、それらハードウェアとソフトウェアの作成に使用されるプロセスに重点を置いています。先に述べたシステム安全上の懸念は、一般にSOTIF（Safety Of The Intended Functionality：ISO/PAS 21448:2019）と呼ばれている新しい規格の中で扱われる予定です。

　機械学習（ML）システムが必然的にそうであるように、システムの主要コンポーネントが非決定性である時に、許容可能な安全レベルをどうすれば保てるのでしょう？　MLシステム間ではどういった冗長性が許容可能で、故障率はどのように算出すればいいのでしょう？　こうしたシステムを私たちはどのようにテストし、認証すべきなのでしょう？　さらに言えば、実際にシステムが主導権を握るSAEレベル3〜5では一体どのような要件になるのでしょう？　ISO 26262が1度に全部を網羅しようとしていないのはある意味、理にかなっています。

セキュリティ問題への対応

　セキュリティの問題も2011年当時には大きな懸念事項ではありませんでしたが、今では明らかに議論の的になっています。どのようにしてセキュリティを安全分析に組み込むべきなのでしょう？　最新版のパート2「機能安全の管理」では、機能安全担当組織、サイバーセキュリティ担当組織、その他機能安全に関連する組織の間に「有効なコミュニケーションチャネル」を構築し、維持することを設計担当組織に要求することによって、この問題に一歩踏み込んでいます。具体的に何をすればこの要求事項を満たすことになるのかについては明記されていませんが、これはISO26262では珍しいことではありません。一般的には、インテグレーターが「必要かつ十分」と考えるものをサプライヤーに提供してもらうべくバー（基準）を設定します。もしあなたがサプライヤーで、それを不公平だと思うなら、多くの事実を挙げて自らの立場を交渉し、相互理解をはぐくむ必要があります。ゲームに参加したいなら、そうするしかありません。