現在、安全性の高いあらゆるシステムの根底には、IC(半導体集積回路)が存在しているはずです。例えば、センサーの制御に使われる IC は、そのためのロジックを備えています。また、センサーそのものが IC をベースとして実現されるようになりつつあります。IC は、最終段にある素子を駆動して安全な状態を達成します。また、ソフトウェアが実行されるプラットフォームにもなります。IC の集積度が高まれば、その内部はより複雑になります。それと引き換えに、システム・レベルの実装は簡素化されます。集積度が高いほど、部品点数は少なくなり、診断用のテストの実施間隔を狭めることができます。その結果、診断のカバレッジを拡大できる可能性が高くなり、システムの信頼性が向上します。つまり、手が届くレベルのコストを支払うことにより、安全性を向上させることが可能になるということです。なかには、集積度を高めると複雑さが増すので望ましくないという意見もあります。しかし、IC が複雑になる代わりに、モジュールやシステムのレベルではかなりの簡素化が実現されます。プロセス制御、機械類、エレベーター、可変速駆動システム、有毒ガスの検知器については、それぞれに向けた機能安全の規格が定められています。その一方で、IC に特化した機能安全規格というものは存在しません。そうではなく、IEC 61508 やその他の下位の規格に、細かい要件や情報が分散して記載されているという状態にあります。本稿では、既存の機能安全規格を IC 向けに解釈するための指針を示します。
はじめに
一般に、IC は IEC 61508 を満たすように開発されます。また、ISO 2626 への準拠が目標になる場合もあります。これらの規格に加えて、追加の要件が下位の規格に定められているケースもあります。機能安全規格に準拠した開発、評価を行うと、ともすれば複雑になりがちな IC であっても、十分に安全であるという確証を得ることができます。もともと、IEC 61508 は、一般市場向けに量産される IC ではなく、カスタム・メイドのシステムを対象として作成されたものでした。本稿では、IC の機能安全に関する既知の要件について説明します。IEC 61508 と産業分野での適用方法に焦点を絞りますが、その内容の多くは、自動車、航空電子機器、医療機器などの分野でも同様に扱うことができます。
機能安全
機能安全というのは、その名のとおり安全性の一種です。信頼性に着目したものであり、必要に応じてシステムが安全に関連するタスクを実行することを特徴とします。機能安全は、電気安全や機械安全、本質安全といったものとは異なります。それらは受動的な形で安全性を求めるものですが、機能安全では能動的な形で安全性を実現します。例えば、ガードドアを開けた操作員が怪我をしないようにモーターが素早く停止したり、人間が近くにいる場合にはロボットが速度や力を落として動作したりといった具合です。
規格
機能安全の規格として最も重要なものは IEC 61508 です1。この規格の第 1 版は 1998 年に、第 2 版は 2010 年に制定されました。そして、2017 年には第 3 版への改訂に向けた作業が開始されています。同版が完成するのは 2022 年の見込みです。第 1 版が制定されてから 20 年が経過していることから、IEC 61508 の基本規格は、自動車(ISO 26262)、プロセス制御(IEC 61511)、PLC(IEC 61131-6)、機械類(IEC 62061)、可変速駆動システム(IEC 61800-5-2)など、他の多くの分野に対応するよう改変されます。IEC 61508 は非常に広範にわたる内容を網羅しています。各規格は、より限定された分野に向けた内容を解釈するうえで役に立ちます。
機能安全規格としては、他にも ISO 13849 や DO178B/DO254などが存在します。これらは IEC 61508 から派生したものではありません。しかし、IEC 61508 について十分に理解していれば、それらの規格を参照する際、驚くような内容に遭遇することはないでしょう。
安全なシステムにおいて、システムの稼働時に安全を満たすための処理を実行するのが安全機能です。安全機能には、安全性を達成/維持するために実行しなければならない動作が定義されます。標準的な安全機能には、入力サブシステム、論理サブシステム、出力サブシステムが含まれます。一般に、潜在的に安全性を欠く状態が検知されたら、検知した値を基に何らかの仕組みで判断が実施されます。その結果、危険が生じる可能性があると判断された場合には、あらかじめ定義された安全な状態にシステムを移行するよう、出力サブシステムに対して指示が行われます。
安全でない状態から安全な状態に移行するまでにかかる時間は重要です。例えば、安全機能は次のような要素によって構成されます。機械に取り付けられているガードが開いていることを検出するセンサー、データを処理する PLC、機械に入れられた手が作動部に到達する前にモーターを停止する安全トルクオフ入力を備える可変速駆動システムなどです。これらを組み合わせて安全機能が実現されます。
SIL
SIL は Safety Integrity Level(安全度水準)の頭文字をとったものです。これは、システムの安全性能を表す尺度となります。システムが抱えるリスクが、許容されるリスクを下回るようにするために、対象となるシステムの水準が SIL として決定されます。IEC 61508 では、SIL は 1、2、3、4 の 4 段階に分かれています。1 段階上がるごとに安全性が高くなります。SIL 4は、危険にさらされる人間の数が一般的に 1 人までにとどまる機械類や工場のオートメーション・システムは対象にしていません。数百人から数千人の規模で被害が生じ得る原子力や鉄道などの分野に適用されるものです。機能安全規格は他にも SIL に相当するものが存在します。例えば、自動車にはASIL(Automotive Safety Integrity Levels) A、B、C、D と ISO13849 が適用されます。そのパフォーマンス・レベル(PL) a、b、c、d、e は、SIL 1 ~ SIL 3 に対応づけることができます。
IEC 61508 SIL | ISO 26262 ASIL | 航空電子機器レベル | ISO 13849 PL | 原子力カテゴリ |
1 | A | D | b l l e — |
A l l l C |
2 | B | C | ||
3 | C/D | B | ||
4 | — | A |
単体の IC に SIL 3 を上回る水準があり得るという考え方について、筆者は懐疑的です。しかし、IEC 61508-2:2010 の附属書 Fには、SIL 4 の欄が設けられています。
3 つの主要な要件
機能安全は、IC の開発に対して 3 つの主要な要件を課しています。以下、各要件について順に説明します。
要件 1: 厳格な開発プロセスに従う
IEC 61508 は、ライフサイクル全体を扱う規格です。安全に関するコンセプトから要件の把握、保守、製品の廃棄までのすべてを対象としています。ただ、それらすべてのフェーズが IC に関連するわけではありません。どの部分が関連するのかを見極めるには、トレーニングと経験が必要になります。IEC 61508には、レビューや監査などの要件とともに、ASIC 用の V モデルが規定されています。安全性の保証まではできませんが、安全なシステムや IC を生み出してきた実績に基づくシステムが示されています。
すでに、ほとんどの IC メーカーは、新製品の開発方法について厳格な基準を設けています。IC の設計に不備があった場合、その修正には多大なコストがかかるからです。微細プロセスを採用している場合、フォトマスク一式だけでも 50 万米ドル(約5300 万円)を超えるコストがかかる場合があります。また、リード・タイムが長いことから、すでに IC の設計には適切な検証と妥当性確認の段階を設けた厳格な開発プロセスが導入されています。機能安全の大きな特徴の 1 つは、安全性を実現するだけでなく、安全であることを実証しなければならない点にあります。そのため、非常に優れた IC メーカーであっても、通常の開発プロセスに対して安全を確保するためのプロセスを追加し、安全に向けた適合性が達成されているという証拠を示すことが求められます。
開発プロセスの段階で作り込まれる故障を、決定論的原因障害(Systematic Fault)と呼びます。これを修正するには、設計を変更するしかありません。この種の故障には、要件の把握に問題があって生じる故障、EMC(電磁両立性)性能の不足による故障、不十分なテストに起因する故障などがあります。
IEC 61508-2:2010 の附属書 F には、IEC の委員会に所属する専門家らによって、IC の開発に適用することが望ましいと判断された専用の手法が列挙されています。同附属書に記載された表F.2 は FPGA と CPLD 、表 F.1 はデジタル ASIC 向けのものです。各手法は、SIL に応じて R(推奨)または HR(強く推奨)に分類されています。また、一部については代替となる手段が示されています。適切な開発プロセスを設けている IC サプライヤであれば、特に驚くような要件はありません。ただ、SIL 3 を満たすには 99 % の故障カバレッジが必要になります。これは、ブロック周辺に多数の回路が集積される小さなデジタル製品やミックスド・シグナル製品にとっては厳しい要件となります。IEC61508 の第 2 版の要件は、デジタル IC のみを対象としていますが、その多くはアナログ IC やミックスド・シグナル IC にも適用できます(ISO 26262 の次期改訂版にも類似の表が記載されます。アナログ IC とミックスド・シグナル IC に対応する表が設けられる予定です)。
表 F.1 と表 F.2 に加えて、冒頭の説明文からも重要な情報が得られます。例えば、「使用実績によって妥当性が証明されたツールを使用することが望ましい」という記述があります。また、「複雑さの点で類似するプロジェクトで 18 ヵ月間にわたって適用されていれば妥当であると判断してよい」とも記載されています。つまり、IEC 61508-3 で取り上げられているすべてのツールの要件を適用する必要はないということです。
使用実績による妥当性は、IC をそれまでに適切に使用した実績があり、用途や現場の故障率を把握しているモジュール/システムの設計者であれば証明できる可能性があります。一方、ICの設計者やメーカーにとって、それはかなり難しい作業です。最終的な用途や、解析のために返品される故障品の割合について、十分な知識を持っているわけではないからです。
ソフトウェア
ソフトウェアには経年劣化は生じません。つまり、ソフトウェアにおけるすべてのエラーは決定論的なものです。そのため、オンチップのソフトウェアについては、IEC 61508-3 に記載された要件について検討する必要があります。オンチップのソフトウェアとしては、マイクロコントローラや DSP に実装されるカーネル、ブートローダなどが一般的です。なかには、ステート・マシンではなく論理ブロックを実装するために、IC メーカーが事前にプログラムした小さなマイクロコントローラを集積しているマイクロコントローラや DSP も存在します。そうした事前にプログラムされたソフトウェアも、IEC 61508-3 の要件を満たす必要があります。アプリケーション・レベルのソフトウェアについては、IC メーカーではなくモジュール/システムの設計者が責任を持つことになります。ただ、コンパイラや低レベルのドライバなどのツールは、IC のサプライヤが提供しなければならない可能性があります。そうしたツールが、安全関連のアプリケーション・ソフトウェアの開発に使用されるケースもあるでしょう。その場合には、ユーザが IEC 61508-3:2010の 7.4.4 節に記載されたツールに関する要件を満たせるように、IC メーカーが十分な情報を提供する必要があります。
筆者は、C 言語をはじめとする多数のプログラミング言語を使用した経験を持ちます。ただ、Verilog によるプログラミングには習熟していません。Verilog と VHDL は、デジタル IC の設計に用いられる代表的なハードウェア記述言語( H D L ) です。HDL で記述した成果物がソフトウェアであるか否かについては、議論の余地があります。ともあれ、IEC 61508-2:2010 の附属書 F に従っておけば十分です。筆者の経験から言うと、附属書 F に従っていれば、IEC 61508 の他の要件(ライフサイクル・フェーズなど)との組み合わせにおいて、HDL をソフトウェアと見なすかどうかはあまり関係ありません。いずれにせよ、開発者は、求められるすべての作業を行う必要があるからです。興味深い関連規格に、IEC 625662 があります。この規格は、HDL を用いて開発された原子力分野向けの安全機能を対象としたものです。
要件 2: 本質的に信頼できるものにする
IEC 61508 は、PFH(単位時間当たりの時間平均危険側故障頻度)または PFD(作動要求時の機能失敗確率)の形式で信頼性に関する要件を課します。これらの上限は、成人が自然死で死亡する確率と、職場や日常業務でその確率が大きく上昇することがあってはならないという考え方に基づいて定められます。SIL 3 の安全機能については、PFH の上限は 1 時間当たり10-7 となります。つまり、危険側故障頻度は 1000 年に約 1 回までと定められています。FIT(10 億時間稼働させた場合の故障回数)で表せば、100 FIT となります。
一般に、安全機能は、入力ブロック、論理ブロック、作動ブロックで構成されています。これらすべてのブロックに、上記の PFH の許容値を割り振ることを考えると、1 つの IC の PFHは 1 桁(10 FIT 未満)に抑えなければならないケースもあり得ます。ここで、冗長性を備えるアーキテクチャを採用すれば、CCF(共通原因故障)に対する懸念を加味して抑えられたその値を引き上げることができます。それぞれ 100 FIT の 2 つの要素によって、10 FIT の 1 つの要素と同等の信頼性を提供することが可能です。ただし、冗長性を持たせるには、実装面積、消費電力、コストの増大を許容しなければなりません。
当社(アナログ・デバイセズ)をはじめとする IC メーカーは、販売するすべての製品について、加速寿命試験に基づく信頼性の情報を提供しています。当社の場合、analog.com/jp/reliabilitydata で情報を公開しています。信頼性の評価は、実験室において人工的に作られた条件の下で行われます。そのことが理由となって、懐疑的な目を向けられることがあります。そこで、SN 295003 や IEC 623804 など、業界で広く採用されている規格に従うことが推奨されます。ただし、これらの規格には、以下に示すいくつかの問題点があります。
- 99 % の信頼水準で信頼性が予測されており、信頼水準が 70% のデータしか求めない IEC 61508 と比べて、悲観的な想定になっています。
- ランダム故障モードと決定論的原因故障モードが区別されません。IEC 61508 では、それぞれに対して異なる対処が求められます。
- 更新頻度は高くありません。
- サプライヤごとに品質に違いが生じることが許容されません。
SN 29500 などの規格では、オンチップのトランジスタの実際の信頼性が示されています。それぞれ 50 万個のトランジスタから成る 2 個の IC を使用して安全機能を実装する場合、システム全体の FIT が 140 であれば各 IC の FIT は 70 になります。ここで、これら 2 個の IC を、100 万個のトランジスタで構成される 1 個の IC に置き換えるとします。すると、この 1 個の IC の FIT はわずか 80 となり、40 % ほど低下することになります。
IC において、ソフト・エラーは無視されがちな事柄です。ソフト・エラーは、電源を投入すれば回復するという点で、従来の信頼性予測の範疇からは外れています。ソフト・エラーは、宇宙からの中性子やパッケージ材料からのアルファ粒子が RAM やフリップフロップ(FF)のセルに衝突し、保持されている電荷量を変化させることによって生じます。ECC(2 ビットの誤り検出、1 ビットの誤り訂正)を適用すれば、RAM のエラーを検出してシームレスに訂正することができます。ただ、そうすると速度が低下して、オンチップのエラーが増加します。パリティ・チェックを適用するのであれば追加されるオーバーヘッドは少なくて済みますが、誤りの訂正はシステム設計者が解決しなければならない課題になります。パリティ・チェックや ECCを適用しない場合、ソフト・エラーの発生率は従来のハード・エラーの発生率の 1000 倍にも達する可能性があります(IEC 61508 では、RAM の FIT の値を 1000 FIT/MB としています)。FFは論理回路の実装に使用されます。そのソフト・エラーに対処する手法はいくつか存在しますが、いずれも十分なものではありません。しかし、ウォッチドッグ・タイマーを使用する手法や、計算において時間に冗長性を持たせる手法を併用すれば、効果を高めることができます。
要件 3: フォールト・トレラントにする
どれだけ信頼性の高い製品であっても、問題が生じる可能性はあります。フォールト・トレランスは、その現実を受け入れて対処するものです。フォールト・トレランスは、主に 2 つの要素によって実現されます。1 つは冗長性を利用することです。もう 1 つは診断を利用することです。どちらも、IC やその開発プロセスの信頼性がどれだけ高かったとしても故障は生じるという前提に基づいています。
冗長性は、同一の構造または異なる構造を、オンチップまたはオフチップに用意することによって実現します。IEC 61508-2:2010 の附属書 E には、同一の構造を利用することによって、オンチップのデジタル回路に十分に冗長性を持たせることができる手法が列挙されています。同附属書は、デュアル・ロックステップ方式のマイクロコントローラを対象にしていると見受けられます。以下に示すオンチップの要素に関する独立性についての指針は示されていません。
- アナログ回路、ミックスド・シグナル回路
- チップ上の要素とそれに対応するオンチップの診断機能
- 異なる構造を利用して冗長性を得るタイプのデジタル回路
ただし、これらに対して附属書 E を適切に解釈できるケースがあります。同附属書には、オンチップの CCF の指標である βICという計算値が示されています。そして、CCF の原因である βが 25 % 未満であれば、十分に分離されていると判断してよいと書かれています。IEC 61508-6:2010 の各表に記されているのは 1 %、5 %、10 % といった数値なので、25 % というのはかなり高い値です。
診断機能は、まさに IC の能力を発揮できる領域です。オンチップの診断機能には、次のようなメリットがあります。
- オンチップの各ブロックにおいて発生することが予想される故障モードに応じて設計を行うことができます。
- 外部ピンの使用本数はわずかで済むので、プリント回路基板の面積はさほど増加しません。
- 高いレートで実行できます(診断テストの最小実施間隔を短くできます)。
- 診断機能を実装しない場合と比べて、冗長性を持たせるためのコンポーネントの必要性が低下します。
つまり、オンチップの診断機能を利用すれば、システムのコストと実装面積を最小限に抑えることができます。一般に、診断機能は、オンチップの監視対象とはまったく別の実装として実現されます。そのため、監視対象と同時に同じように故障する可能性は低くなります。分離した状態で実装されているにもかかわらず、診断機能と監視対象に同時に同じような問題が生じたとすれば、多くの場合、EMC、電源、温度に関連する障害が発生していると考えられます。規格には要件は定められていませんが、診断の最終的な手段であるオンチップの電源モニターとウォッチドッグ回路については懸念もあります。外部の評価機関の中には、そうした診断機能はオフチップに実装することを強く推奨しているところもあります。
一般に、シンプルな IC に対する診断は、リモートのマイクロコントローラ/DSPによる制御をベースとして実現されます。測定はオンチップで行われますが、その結果はチップ外に送信され、外部で処理されます。
IEC 61508 では、診断カバレッジの必要最小限のレベルとしてSFF(安全側故障割合)が定められています。安全側と危険側の故障を考慮する SFF は、安全側の故障を無視する DC(診断カバレッジ)と関連はするものの、異なる指標です。実装された診断機能が適切に働くか否かという指標は、定量化されたFMEA(故障モード影響解析)または FMEDA(故障モード影響診断解析)を用いて測定することができます。また、IC 内に実装された診断機能によって、IC 外部のコンポーネントをカバーすることも可能です。さらに、IC 内の要素がシステム・レベルの診断によってカバーされるケースもあります。IC の開発者がFMEDA を実行する場合、その開発者は最終的な用途の詳細までは把握していないと仮定しなければなりません。これは、ISO26262 の用語で SEooC(Safety Element Out of Context)として知られるものです。ユーザは、その仮定が自分のシステムにも当てはまると認識したうえで、IC レベルの FMEDA を利用する必要があります。
IEC 61508-2:2010 の表 A.1(と、表 A.2 ~ A.14)は、IC の解析を行う際に検討する必要のある故障についての適切な指針となります。IEC 60730:20105 の附属書 H には、これに関してより有意義な情報が記載されています。
IC の開発オプション
機能的に安全なシステムに使用する IC の開発には、複数の選択肢があります。規格には、それに準拠する IC しか使ってはならないという要件はありません。しかし、モジュール/システムの設計者は、選択した IC が、対象となるシステムでの使用に適していることを確認する必要があります。
適用可能なオプションは、以下のとおりです。
- 外部の評価機関を利用し、安全マニュアルを参照して IEC61508 に完全に準拠して開発を行います。
- 外部の評価機関は利用せず、安全マニュアルを参照して IEC61508 に準拠して開発を行います。
- 安全データシートを公開している半導体企業の標準的な開発プロセスに従って開発を行います。
- 半導体企業の標準的な開発プロセスに従って開発を行います。
ここで、IEC 61508 に準拠せずに開発された部品の安全マニュアルは、安全データシートなどと呼ばれることがあります。安全マニュアルに準拠して開発された部品との混同を避けるために、このように呼ばれています。
上記 1 つ目のオプションは、半導体メーカーにとって最もコストのかかる選択肢です。ただ、モジュール/システムの設計者にとっては最も好都合である可能性があります。IC の安全に関する概念に示された用途がシステムの用途と一致していれば、モジュール/システムを外部機関で評価する際に問題に遭遇するリスクが低下します。SIL 2 の安全機能を設計するために追加で行わなければならない作業は、20 % にも上る可能性があります。半導体メーカーは、機能安全に対応してはいないものの、すでに厳格な開発プロセスを適用していることが少なくないでしょう。そのようなプロセスを導入していない場合は、おそらくそれ以上の追加の作業が必要になります。
2 つ目のオプションは、外部機関による評価のコストがかからないことを除くと、1 つ目のオプションと同様の対応が必要になります。このオプションは、顧客がモジュール/システムについて社外で認定を受けるつもりでいて、なおかつ IC がシステムの重要な要素である場合に適している可能性があります。
3 つ目のオプションは、IC がすでに提供されており、安全データシートを参照することで、モジュール/システムの設計者がより高いレベルの安全設計に必要な追加の情報を入手できる場合に最も適しています。これには、実際に適用された開発プロセスの詳細、IC の FIT データ、診断機能の詳細、製造施設に関する ISO 9001 の認証結果などの情報が含まれます。
実際に、IC の開発に最もよく使われるのは 4 つ目のオプションです。このような手法で開発された IC を採用してモジュール/システムを設計する場合、追加のコンポーネントやコストが必要になります。おそらく、その IC は、シングルチャンネルのアーキテクチャで実現されているでしょう。つまり、比較が可能なデュアルチャンネルのアーキテクチャを使用する診断機能は備えていないはずなので、追加の対応が必要になるということです。安全データシートが存在しないので、モジュール/システムの設計者は、保守的な仮定に基づき、IC をブラック・ボックスとして扱わなければなりません。
また、半導体企業は、規格に対する独自の解釈を構築しておく必要があります。アナログ・デバイセズの場合、そのことを目的とするものとして、「ADI61508」と「ADI26262」という社内文書を作成しています。ADI61508 は、IEC 61508:2010 の 7つの部分を取り上げ、IC の開発という観点からその要件を解釈したものになっています。
SIL 2、SIL 3 に対応する開発
IC は、SIL 3 のすべての決定論的な要件に従って開発される場合があります。IEC 61508-2:2010 の表 F.1 には SIL 3 に関連する事柄が記載されています。それらすべての内容に従い、SIL 3のレベルを満たすための設計レビューやその他の解析がすべて実施されるということです。それでも、ハードウェア・メトリクスが SIL 2 のレベルしか満たしていないというケースがあります。このような回路は SIL 2/3 と表現されます。より一般的に言えば、SIL M/N と定義することができます。ここで、M はハードウェア・メトリクスについて主張できる最大の SIL レベル、N は決定論的な要件について主張できる最大の SIL レベルです。SIL 2/3 の 2 個の IC を使用すれば、SIL 3 のモジュール/システムを実装することができます。SIL 2 の要素を 2 つ並列に配置すれば、構成全体のハードウェア・メトリクスは SIL 3 にアップグレードされます。各要素は、決定論的な要件についてはすでに SIL 3 のレベルにあるからです。一方、IC が SIL 2/2 であった場合、それを 2 個並列に配置してもせいぜい SIL 3/2 にしか到達しません。つまり、SIL 3 を達成することはできません。
IC にハードウェア・メトリクスを適用
安全機能のほぼすべてが IC によって実装されている場合を除くと、SFF、DC、PFH のリミット値を半導体に対して規定するのは非常に困難です。ここでは SFF を例にとります。SIL 3 を達成するには、99 % を超える SFF が必要です。ただ、これは IC ではなく安全機能全体に関する数値です。SFF が 98 % の IC であれば、SIL 3 の安全機能の実装に使用できます。ただ、それを使用してしまうと、システムの他の部分でさらに高いカバレッジを達成しなければならなくなります。IC の安全マニュアルや安全データシートには、システム・レベルの FMEDA で使用するための λDD、λDU、λ の値を記載する必要があります。
理想的には、システム・レベルの解析用に IC の要件が示されているべきです。ただ、実際にはそうでない場合が多く、開発は実質的に SEooC、つまりはコンテキスト外の安全要素となります。SEooC において、IC の開発者は、システム内における IC の使用方法について仮定を行う必要があります。続いて、システム/モジュールの設計者は、それらの仮定と実際のシステムを比較して、IC の機能安全がシステムに対して十分かどうかを確認します。それらの仮定に応じ、診断機能を IC に実装するのか、システム・レベルで実装するのかということが決まる可能性があります。そのため、IC のレベルでの機能にも影響が及びます。
セキュリティ
安全なシステムを構築するには、いわゆるセキュリティの確保も重要です。IEC 61508 や ISO 26262 には、セキュリティ関連の指針としては「IEC 62443 シリーズを参照せよ」との記述しかありません6。しかし、IEC 62443 は、個々の IC というよりも、PLC 全体といったより大きなコンポーネントを対象にしたものだと言えます。幸い、機能安全規格の決定論的原因故障を排除するための要件のほとんどは、セキュリティにも適用できます。ハードウェアによって、ハードウェアの信頼の基点(Root of Trust)や、PUF(物理複製困難関数)のような機能を提供できるケースがあります。安全性とセキュリティに関して、PUF は重要な意味を持ちます。
まとめ
IEC 61508 は、IC から石油精製所に至るまで、あらゆるものの開発を網羅する規格です。これとは別に、機械類やプロセス制御などに特化した規格も存在します。また、IEC 61508 の第 2版には IC に関する指針もある程度示されていますが、IC に特化した規格は存在しません。具体的な要件が定められていないことから、さまざまな解釈が自由に行われてしまい、複数の顧客や外部の評価機関から期待されることとの間で整合性を欠いてしまう可能性があります。
そこで各業界では、より高いレベルの規格において、IC に対する業界固有の要件を定める傾向にあります。そうした要件は、EN 504027 などの規格に実際に記載されていますが、ISO26262 の 2016 年版のドラフト8には、IC を対象として Part 11という新たな章が追加されています。
IEC 61508 の第 3 版は、2021 年頃に制定される予定です。同版では、IC に関する指針が拡大/明確化されることが期待されます。幸い、筆者は IEC TC65/SC65A MT61508-1/2 と MT 61508-3 の規格策定に関与することができました。そのため、IEC61508 の第 3 版における取り組みに参加する機会を得る予定です。将来の改訂版では、IC のみを対象とする Part 8 が設けられ、すべての業界で一貫性が得られるようになるかもしれません。そうすれば、すべての業界の要件を満たす IC を開発することが可能になります。
ただ、そうなったとしても、機能安全の要件を満たす IC を設計するために、IC メーカーにとって必要なすべての情報が規格に盛り込まれることにはなりません。セキュリティや EMC などに関連する要件は、やはりシステム・アプリケーションに関する知識から導き出す必要があります。