Embed Size (px)
Citation preview
機安研
ISO 26262自動車－機能安全
解説改版： 2013年 1月 11日
作成： 機械安全研究所
この文書は技術者の研究のために作成したものです
営利・非営利を問わず一部あるいは全部のコピーならびに無断引用は認めません
当文書の内容は機械安全研究所の見解です
これにより生じるいかなる損害にも責任は負いません
目次
1. まえがき .................................................................................................................................................... 3
2. 規格の適用範囲 ......................................................................................................................................... 3
3. ISO 26262 の方言 ...................................................................................................................................... 3
3.1. フォールトの種類 ............................................................................................................................... 4
3.2. 故障の種類 .......................................................................................................................................... 5
3.3. 故障の評価基準 ................................................................................................................................... 6
4. 安全ライフサイクル .................................................................................................................................. 7
5. 機能安全マネジメント ............................................................................................................................... 7
5.1. 安全の文化 .......................................................................................................................................... 7
5.2. プロジェクト管理者 ( プロジェクトマネージャー ) .............................................................................. 7
5.3. 安全管理者（セーフティーマネージャー） ........................................................................................ 8
5.4. 安全計画 .............................................................................................................................................. 8
5.5. 安全活動の開始 ................................................................................................................................... 8
5.6. DIA (Development Interface Agreement: 開発インターフェース協定 ) ............................................... 8
5.7. 供給者 ................................................................................................................................................. 9
5.8. 確認方策 .............................................................................................................................................. 9
6. 開発アイテムの特定 .................................................................................................................................. 9
7. 安全ライフサイクルの開始 ........................................................................................................................ 9
8. ハザード分析とリスクアセスメント ......................................................................................................... 9
9. 安全要求仕様書 ....................................................................................................................................... 11
機安研10. 機能安全コンセプト .............................................................................................................................. 11
11. システム開発（前半） ........................................................................................................................... 11
11.1. システム設計 .................................................................................................................................. 12
12. ハードウェア設計 .................................................................................................................................. 12
12.1. ハードウェア安全要求仕様 ............................................................................................................. 12
12.2. ハードウェアコンポーネントの再使用 ........................................................................................... 12
12.3. 使用実績による適性証明 ................................................................................................................. 13
12.5. ハードウェアエレメントの設計 ...................................................................................................... 13
12.6. 安全分析 .......................................................................................................................................... 13
13. ソフトウェア設計 .................................................................................................................................. 14
13.1. ソフトウェア安全要求仕様 ............................................................................................................. 14
13.2. ソフトウェアコンポーネントの再使用 ........................................................................................... 14
13.3. ソフトウェアアーキテクチャ設計 .................................................................................................. 14
13.4. ソフトウェアコンポーネント ......................................................................................................... 15
13.5. ソフトウェアユニットの設計 ......................................................................................................... 15
13.6. ソフトウェアツール ........................................................................................................................ 15
13.7. ソフトウェア統合 ........................................................................................................................... 15
13.8. ソフトウェアコンフィギュレーション ........................................................................................... 16
14. システム開発（後半） ........................................................................................................................... 16
14.1. ソフトウェアとハードウェアの統合とテスト ................................................................................ 16
14.2. 妥当性確認 ...................................................................................................................................... 16
15. SEooC (Safety Element out of Context) ................................................................................................ 17
15. 機能安全アセスメント ........................................................................................................................... 17
16. 機能安全監査 ......................................................................................................................................... 17
17. 生産許可 ................................................................................................................................................ 17
18. 生産 ....................................................................................................................................................... 17
19. 変更管理 ................................................................................................................................................ 17
20. 運用、保守、廃棄 .................................................................................................................................. 17
機械安全研究所 2/22
機安研
1. まえがき
自動車の機能安全の規格である ISO 26262を読むに当たって理解を助ける内容になっている。全ての規格
要求事項を網羅するわけではない。各要求内容に関しては規格そのものを読むこと。ISO 26262は 10のパ
ートからなるが、ここではパートにとらわれず、規格の要求を理解しやすい並びで記載する。原則的には、製
品の安全ライフサイクルに従い時系列的に並べる。
2. 規格の適用範囲
量産され、車両重量が 3.5トンまでの乗用車に組み込まれる、安全関連 E/E(電気/電子)システムに適用され
る。ここに、乗用車とは、ドライバーに加えて 8名の乗車で立って乗らないものとなっている。ちなみに、「安
全関連系 E/Eシステム」の定義はなく、漠然と｢安全ゴール達成のため｣のE/Eシステムを指し、乗用車メー
カーが｢安全関連系｣といえばそのシステムが安全関連系ということになる。安全関連として使用予定の汎
用部品に関しては、SEooC (Safety Element out of Context)という言葉が使用され、この規格を適用するこ
とが出来るようになっている。
3. ISO 26262の方言
ここでは、この規格特有ともいえる用語(方言)の説明を行う。一般常識で理解できると思われる用語に関し
ては記載しない。なお、用語定義そのものは規格を参照すべきである。
機能安全
ISO 26262では、「E/Eシステムの機能不全な挙動に起因する危険源による、非合理的なリスクが無いこと」
と狭義に定義されている。広義には、何らかの機能を用いて安全を確保することである。機能は必ず壊れる
ものと考え、機能が壊れた場合に「如何に安全を確保するか？」、それが出来ない場合は、「如何に危害を少な
くするか？」が肝要である。より大きな危害を防ぐ機能には、より高い信頼性が求められる。しかし、その機
能の故障確率が低ければ事足りるというものではない。
ハザード
一般的には「危害を生じる原因」を指し、JIS等では｢危険源｣と訳されているが、ISO 26262では、「アイテム
の不具合なふるまいで生じる、危害となりえる原因」になっている。
例：アイテムの出力が上昇する、アイテムの反応が遅くなる・・・など
ハザード分析およびリスクアセスメント
機械安全(ISO 12100)では、ハザード分析はリスクアセスメントに含まれるので、単に｢リスクアセスメン
ト｣と呼ばれている。この「リスクアセスメント」のアウトプットは、リスクが受容可能か否かの「YesかNo」
機械安全研究所 3/22
機安研となる。ISO 26262では、「ハザード分析およびリスクアセスメント(HA&RA)」と呼ばれている。アイテムの
危険事象を見つけて分類し、それから生じる不合理なリスク防止のために安全目標と ASILを設定する作業
と定義されている。進め方も ISO 12100の方法とは若干異なるので ISO 12100に馴染んだ方は注意を要す
る。
セーフティーケース
製品が仕様（規格に限定すれば、規格要求）を満たしていることを示す文書類で、一般的には開発を通じて
各工程の作業結果として残される成果物の蓄積がこれに相当する。技術文書、あるいは、適合文書。
ASIL （自動車安全度水準）
他の機能安全で SILという言葉が使われている。SILはその対象物(例えば E/Eシステム)の信頼性を含む完
成度(安全度)のことを言う。この自動車(Automotive)版で独自の判断基準を元に AからDの 4つに分類され
る。
ASILデコンポジション
ASILを分解するというよりも、一つのエレメントが担う安全要求を分解することにより、分解された安全
要求を担う複数のより低い ASILのエレメントを冗長的に配置して当初の安全要求を実現すること
アイテム
自動車レベルで機能を発揮するシステムもしくはシステムの配列で ISO 26262の対象になる
システム
少なくとも入力（センサー）、処理（コントローラー）、および、出力（アクチュエーター）がお互いに関
連する、エレメントの組合せ
エレメント
コンポーネント、ハードウェア、ソフトウェア、ハードウェアパーツ、ソフトウェアユニットを含むシステム
もしくはシステムの一部。最小機能を有するひとまとまり
コンポーネント
論理的および技術的に分離可能で、かつ、一つ以上のハードウェアパーツもしくは一つ以上のソフトウェア
ユニットから成る、システムレベルには至らないまとまり
機械安全研究所 4/22
機安研ハードウェアパーツ
それ以上分解できないハードウェア。ハードウェアの最小単位。抵抗とかコンデンサのこと。
ソフトウェアユニット
単独で試験可能なソフトウェアの最小単位 他の規格ではモジュールと呼ばれることもある
フォールト
faultのこと。JISではフォルトではなくフォールトと呼ばれる。エレメントやアイテムの故障を引き起こす
ことができる異常な状態。幾つかの種類に分類される
故障
failureの JIS訳。要求された機能を実行する、エレメントの能力の停止、あるいは、エレメントの停止に伴う
システムの機能異常であり、システムの異常にともなうエレメントやアイテムの機能異常。幾つかの種類に
分類される
3.1. フォールトの種類
規格の「用語の定義」にあるフォールトを説明
安全側フォールト
発生しても安全目標を侵害する確率を著しく増加させないフォールト
単点フォールト
安全メカニズムでカバーされないエレメント内のフォールトで、直接安全ゴールを脅かす一つのフォール
ト。この言葉は「単一フォールト」を連想させるが この規格では、｢安全ゴールを脅かす｣一つのフォールト
だけをさす
二点フォールト
他の一つの独立したフォールトとの組合せで、二点故障をもたらす一つの独立したフォールト
多点フォールト
他の複数の独立したフォールトとの組合せで、多点故障をもたらす一つの独立したフォールト
検出されるフォールト
そのフォールトが潜在化することを防ぐ安全メカニズムにより、規定された時間内にその存在が検出され
るフォールト
機械安全研究所 5/22
機安研知覚されるフォールト
規定の時間間隔内にドライバーによりその存在が気付かれるフォールト
一過性フォールト
一度発生した後に消滅するフォールト
恒久フォールト
発生したら除去もしくは修理されるまで残るフォールト
残留フォールト
それ自体が安全ゴールの侵害をまねくフォールトの一部で、ハードウェアエレメント内に起こり、安全メカ
ニズムでカバーされないフォールトの一部。一般的には、安全側フォールトでも潜在化する場合は、残留フ
ォールトというのだが、この規格では「安全ゴールの侵害を招く」フォールトに限定される
潜在フォールト
その存在が安全メカニズムで検出されず、多点フォールト検出間隔内にドライバーにも気付かれない多点
フォールト 残留フォールトが単点フォールトであるのに対して、潜在フォールトは多点フォールト
系統的フォールト
故障が特定の条件下において決定論的に発生するフォールト、工程や設計方策の適用によってのみ防止さ
れる、決定論的原因フォールトと呼ばれることもある
3.2. 故障の種類
規格の「用語の定義」にある故障を説明する
偶発ハードウェア故障
ハードウェアエレメントの寿命中に予期できずに起こる確率分布に従う故障
系統的故障
特定の原因に決定論的に関連し、設計変更や生産工程の変更、運用手順の変更、文書化もしくは他の関連す
る要素によってのみ削除できる故障。 他の規格では、決定論的原因故障とも呼ばれる
機械安全研究所 6/22
機安研独立故障
同時もしくは連続発生の確率がそれらの無条件な確率の結果として説明できる故障群。 他の影響を受け
ずに生じる故障
従属故障
同時もしくは連続発生の確率がそれらの無条件な確率の結果として説明できない故障群。お互いに何らか
の影響がある故障群。
共通原因故障 CCF
一つの特定の事象や根本原因の結果として生じる、同じアイテム内のふたつ以上のエレメントの故障
連鎖故障
同じアイテムの他の一つもしくは複数のエレメントの不具合を引き起こす、あるアイテムの一つのエレメ
ントの故障 共通原因故障ではない従属故障
単点故障
単点フォールトに起因し、直接安全ゴール侵害をもたらす故障。（診断率 0％の場合、単点故障は残留故障と
同じになる。（注：「残留故障」は、規格で定義されていない））
二点故障
二つの独立したフォールトの組合せに起因し、直接安全ゴール侵害をもたらす故障。（二点故障は多点故障
の一部）
多点故障
複数の独立したフォールトの組合せに起因し、直接安全ゴール侵害をもたらす故障。通常、三つの独立した
フォールトが同時に起こることは無いと考えてよい。
3.3. 故障の評価基準
偶発ハードウェア故障の確率的基準（PMHF: Probabilistic Metric for random Hardware Failure）
単点フォールトに起因するハードウェア故障の判定に用いることのできる基準。ASIL C, Dに対して証明が
要求され、Ｂに推奨されるハードウェアの偶発故障による故障確率。アイテム、システム、あるいは、エレメ
ントに対する値。規格内の表に示される値（D: <10-8/h, C: <10-7/h, (B)<10-7/h）、フィールドデータ、もしく
は、定量的分析手法により求められる。
機械安全研究所 7/22
機安研故障率クラス
単点フォールトの判定に用いることのできる等級。PMHFが、アイテム、システム、あるいは、エレメントを
対象にしているのに対し、故障率クラスはそれらを構成するハードウェアパーツを対象にしている。論理的
裏づけが無い限り、故障率クラス１＝10-10/h、故障率クラス 2=10-9/h・・・故障率クラス i=10(i-1)/h(但し
i>3)。故障率クラスは、当該部品の信頼性管理手法とともに用いられることになる。
信頼性管理手法
ハードウェアパーツの故障率が低いことを確認するための品質管理手法。a) 過剰設計や物理的分離、b) 受
け入時における故障低減のための特別な試験、c) バーンイン試験、d) 専用管理手法、e) 安全関連の特殊な性
能の付与の５手法が規格に規定されている。故障率クラスと共に用いられたり、ハードウェアパーツに対す
る診断率が 90％未満の場合に用いられる。
診断率(DC)
安全メカニズムにより検出あるいは制御されるハードウェアエレメントの故障率の割合。ISO 26262では、
単点フォールト（残留フォールト）と多点フォールト(潜在フォールト)に対して定義される。
単点フォールト基準(SPFM: Single Point Fault Metric)
アイテムやエレメントの単点および残留フォールトに対する強度を示す基準。高い値は、単点および残留フ
ォールトの割合が低いことを意味する。要求値は、過去の信頼できるアイテムやエレメントの値、もしくは
ASIL B: ≧90%, ASIL C: ≧97%, ASIL D: ≧99%
HWSR
HWSRSMPF
HWSR
HWSRRFSPF
,
,
,
,
)()(
1
この式の％値
潜在フォールト基準(LFM: Latent-Fault Metric)
アイテムやエレメントの潜在フォールトに対する強度を示す基準。高い値は、潜在フォールトの割合が低い
機械安全研究所 8/22
1001 ,,
estRF
RFDCK
1001 ,,,,
estLMPF
LMPFDCK
機安研ことを意味する。要求値は、過去の信頼できるアイテムやエレメントの値、もしくは、
ASIL B: ≧60%, ASIL C: ≧80%, ASIL D: ≧90%
HWSRRFSPF
HWSRSectedorperceivedMPF
HWSRRFSPF
HWSRlatentMPF
,
,det__,
,
,,
1
この式の％値
4. 安全ライフサイクル
機能は必ず壊れるものである。製品(自動車)の安全確保のために用いられる安全機能は、製品の寿命を通し
て有効に機能することが要求される。そのためには、安全機能が、設計開発段階のみならず製品の寿命期間
を通して有効であるように管理されなければならない。このことを念頭において、製品のゆりかご（企画段
階）から墓場（廃棄）までのライフサイクルを管理しようとの考えから生まれたのが安全ライフサイクル
である。
ライフサイクルは、「どのような(安全関連)製品を開発するか」という全体像から始まり、「それをどのように
実現するか」という概念やシステム構成を経て、回路設計やソフトウェアコーディングという部分的な作業
に移るという「全体から部分への動き」があり、引き続きそれら回路やソフトウェアを統合し製品へとくみ
上げていくという｢部分から全体への動き｣がある。生産開始後は、保全(車検、点検)や設計変更などをへて、
最終的に製品が廃棄されるに段階にいたる。
このような、｢全体から部分へ｣その後「部分から全体へ」といった管理体制は、Vモデルと呼ばれ、ISO 26262
では、システム全体の開発、ハードウェア開発、ソフトウェア開発など各所でこの考え方に基づいた要求が
なされている。論理的な裏づけがあれば、必ずしもVモデルに従う必要は無い。これを、ISO 26262では｢安
全ライフサイクルのテーラリング｣と呼んでいる。
5. 機能安全マネジメント
系統的フォールトやそれに起因する系統的故障は、設計開発段階において、あるいは、生産工程の変更など
によってのみ対応できる。特に設計開発段階において、検証により問題を発見し対応することは重要である
このために、安全に関する何らかの活動(安全活動)に当たっては、あらかじめ計画を立てることが要求され
る。計画は、安全ライフサイクルの進行に伴い、サブフェーズと呼ばれる各工程の詳細な計画を追加するこ
とにより進化を続ける。計画に従って行動した結果は検証されなければならないが、この計画自体も検証の
対象になる。
全ての安全活動は、当初の計画に従って漏れなく遂行されなければならない。そして、その結果は記録(文書
化)されなければならない。この文書化は、結果の検証という目的のみならず、将来の設計変更時に変更の影
響を解析したり、開発の正当性を示したり、類似モデルの開発に利用するためなどにも有益で、そのことか
らもトレーサビリティーを確保し文書間の関連を明確にしなければならない。
ISO 26262の全体および部分(サブフェーズ)の活動は、このように、計画、実行、検証、ならびに、それらの文
書化と文書におけるトレーサビリティーの確保が要求される。
機械安全研究所 9/22
機安研
5.1. 安全の文化
ISO 26262では、他の規格ではお目にかからない、組織における「安全の文化」を要求している。規格要求を
満足するための規定類の整備、組織内のコミュニケーション、問題解決のプロセス、それらを実行するに充
分な人員確保、各人員の能力管理などの品質管理的な項目から、異端意見の排除の防止など日常的な組織活
動まで含む要求となっている。
5.2. プロジェクト管理者(プロジェクトマネージャー)
アイテムの開発開始に当たり、プロジェクト管理者が任命される。プロジェクト管理者には、計画された安
全活動が行なわれることを確認し、最終的にアイテムを ISO26262に適合させる責任がある。その一環とし
て、プロジェクト管理者は、組織がアイテムの機能安全目標を達成するに充分な人員を擁することを検証し
また、安全管理者が任命されることを確認しなければならない。プロジェクト管理者は、プロジェクトの進
行を大所高所から管理する立場となる。
5.3. 安全管理者（セーフティーマネージャー）
安全管理者は、プロジェクト管理者と同一人物であっても構わない。プロジェクト管理者が大所高所から管
理するのに対して、安全管理者は｢現場の管理者｣といった立場になる。安全管理者は、安全計画の策定に責
任を有するとともに、その実施に当たり部門間の調整に当たる。安全計画の進捗を監視し必要があれば、計
画の見直しにも責任を有する。当然全ての業務が安全管理者で行えるものではないので、テスト計画、妥当
性確認の計画、検証計画、機能安全アセスメントの計画など詳細に関しては組織内において責任が割り当て
られるであろう。割り当てられた部門あるいは担当者は、その進捗の監視に関しても責任を負うことになる
とともに、安全管理者への連絡も行うことになる。
5.4. 安全計画
全ての安全活動は、安全ライフサイクル全体にわたるものであれ各サブフェーズにおける活動であれ、事前
に計画される必要がある。安全ライフサイクルをテーラリングした場合は、各サブフェーズにおける活動に
対する理解を関係者が共有するためも、各サブフェーズにおける活動の定義が必要になる。計画には各サブ
フェーズの活動だけでなく、妥当性確認や機能安全監査、機能安全アセスメントの計画も含まれることにな
る。計画は、プロジェクトの進行に伴い、各サブフェーズの詳細計画が加わることにより、進化を続ける。
安全計画には、新規設計、従来品の再使用あるいは設計変更の区別を記載する必要がある。実績のあるアイ
テムをそのまま再使用する場合や、設計変更して使用する場合など、サブフェーズの省略や異なる方法で実
行するテーラリングが可能になる。再使用の場合は、使用環境の影響、変更の場合は、加えて、変更自体の影
響を解析し、適用すべき(あるいは、省略できる)サブフェーズを決定することになる。ASILデコンポジショ
ンの結果や、アイテムとは別にエレメントだけを開発する場合なども安全活動のテーラリングが可能にな
る。いずれの場合も、テーラリングが妥当である旨の裏づけが必要になる。
機械安全研究所 10/22
機安研ASIL B,C,Dの場合、安全計画は、有資格者(安全管理者とは限らない)により承認されなければならない。そ
の有資格者は、計画に示されている確認行為(テストや検証など)の行為者が該当する ASILに対して適切で
あることを確認しなければならない。
何らかの不都合が発見された時は、速やかに安全管理者などに報告されなければならない。
5.5. 安全活動の開始
安全計画により、安全活動が組み立てられ、計画に沿って順次各サブフェーズが開始される。各サブフェー
ズの活動は、それに先立つ活動からの充分な情報を得てから開始しなければならない。これは推測や見切り
発車で安全活動を開始することによる、許容できないリスクの発生を防止するためである。
5.6. DIA (Development Interface Agreement: 開発インターフェース協定)
自動車に限らず多くの製品は、1 社で全て設計開発が行われる訳ではなく多くの企業体が参加する。この規
格では、このような開発体制を「分散開発」と呼び、供給側を｢供給者｣、受給側を｢顧客｣と呼んでいる。自動車
の安全制御の場合、異なる組織により設計された製品（アイテム）が組み合わされて一つの安全系を形作
る。アイテムが担う役割やアイテム間のインターフェースなどは直接安全機能に影響する。ISO 26262では
顧客と供給者がDIAと呼ばれる、開発に関する情報インターフェースに関する協定を結ぶことが要求され
る。
DIAには、安全計画やその実行・文書化に関する同意や、双方の安全担当窓口(安全管理者や各活動の責任者
など)となる人物、やり取りされる安全関連情報など、安全に関するお互いの責任が具体的に述べられる。
5.7. 供給者(協力会社)
顧客は、供給者の開発・製造能力を評価して選定することになる。また、供給者も顧客の要望にこたえるこ
とができるかどうかの判断を行う。このため、顧客が供給者に提出する見積もり依頼には、開発アイテムが
担う安全機能やそれが ISO 26262に適合すべきこと、もし既に分かっているのであればそのアイテムに要
求される ASILなどの記載が要求される。
5.8. 確認方策
各サブフェーズでの成果物は、それが正しく充分であるかどうか確認されなければならない。確認者の能力
が充分であることは、能力管理で明らかになっている。確認方策の対象物とそのASILにより確認者の独立
性に関する要求が異なる
例１：ハザード分析とリスクアセスメントの報告書の場合は、たとえ同じ部署に優秀な人物が居てもその
人物が確認作業をすることは認められず、他部署あるいは他組織の人物が行わなければならない。
例２：セフティーケースの完全性の確認の場合は、ASILにより異なる独立性が認められる。
機械安全研究所 11/22
機安研6. 開発アイテムの特定
どのような製品でも、開発の端緒は企画であろう。安全関連アイテムの場合は、企画段階で、それが担うべき
安全機能、使用される環境や他のアイテムとの相互作用などを明確にする必要がある。関係者が、開発され
るアイテムに対する認識を共有し、引き続いて行われる活動を支援することになる。
7. 安全ライフサイクルの開始
安全ライフサイクルの開始に当たって、対象アイテムが新規開発であるか、再使用もしくは設計変更である
かを明確に認識する。新規開発の場合は、ハザード分析とリスクアセスメントが行われることになる。再使
用あるいは設計変更をして用いる場合は、関係する因子（仕様環境、他のアイテムとの関係、設計変更内容
など）が及ぼす影響を評価する事になる。影響を受けるかもしれない蓄積された作業成果物(技術資料)は関
連するサブフェーズを通じて改編されることになるが、そのまま再使用できる作業成果物が存在する場合
は、それに関連するサブフェーズを省略することができる。このようにして、安全ライフサイクルのテーラ
リングが行われる。
8. ハザード分析とリスクアセスメント
ISO 26262では、規格としては珍しく、推定される危害を元にして要求される ASILを求める方法が規定と
して書かれている。ただし、どのような状態を軽微としどのような状態を重篤とするかといった判断基準は
参考として書かれているに過ぎない。
第 1段階は、アイテムがその寿命中に遭遇し、アイテムが正常に機能しなかった場合に危険な状態が生じる
と思われる状況を、自動車が正しく使われた場合のみならず予測できる誤った使用も含んでリストアップ
する。過去の市場での問題などが参考になる。広い分野の関係者がその経験などを持ち寄りリストアップす
ることが望ましい。
第 2段階は、ハザードの特定で、ハザードを自動車レベルで観測される振る舞いの言い方で表し、そのとき
の自動車の状況と関連付け、その結果生じる危険事象を記述する。
第 3段階では、危険事象の等級付けで、ISO 26262では、危害の重大さ(シビアリティ：S)、その状況に遭遇す
る程度（エクスポージャー：E）、その状況における自動車の操縦性（コントローラビリティー：C）の３
つの観点から危険事象を等級付けることになる。各要素は、その程度により以下のように等級付けされる。
重大さ
S0： 障害なし
S1： 軽度ないし中程度の障害
S2： 重度ないし生命を脅かす障害（生存の可能性有り）
S3： 生命を脅かす障害(生存不明)、致命傷
遭遇の程度
E0： 信じられない
E1： 非常に低い確率
機械安全研究所 12/22
機安研E2： 低い確率 （E1の 10 倍程度）
E3： 中程度の確率（E2の 10 倍程度）
E4： 高い確率（E3の 10 倍程度）
操縦性
C0： 一般的に操縦可能
C1： 簡単に操縦可能
C2： 普通に操縦可能
C3： 操縦が困難、あるいは、操縦不能
このように各等級とも説明が抽象的で、判断に迷う。このため ISO 26262では Part 3の付属書Ｂで等級毎に
もう少し具体的な例を挙げて説明がなされている。特に重篤度に関しては AISとの対比が行われ、自動車関
係者には使いやすいと思われる。付属書Ｂは、「参考」であるものの、等級付けには必要である。
第 4段階では、前段階での等級付けの組み合わせから、当該安全機能に要求されるASILを決定する。ASIL
は AからＤまでの 4段階あり、Ｄが最も高い安全度水準になる。組合せの半数はＱＭになる。QMは、品質管
理(Quality Management)を意味し、ISO 9000シリーズや、ISO/TS 16949などによる品質管理システムによ
り管理されることを意味し、ISO 26262への適合要求は無いことを意味する。
ここで決定された ASILは、「初期の ASIL」と呼ばれ、後々まで付いて回ることになる。
安全目標は各々の危険事象に対して決定されるが、上記評価を通じて同様の安全目標が特定された場合、そ
れらを結合して一つの ASILを割り当てても良い。このようなことは、同じ危険事象が異なる状況で起きる
場合などが該当する。状況が異なることにより異なった ASILが同じ危険事象に割り当てられる可能性もあ
る。このような場合、その危険事象には高いほうの ASILが割り当てられることになる。
9. 安全要求仕様書
この段階で、開発アイテムが特定され、アイテムに要求される安全機能が明らかになり、安全機能達成に必
機械安全研究所 13/22
操縦性
危害の重大さ 状況に遭遇する程度 C1 C2 C3
S1 E1 QM QM QM
E2 QM QM QM
E3 QM QM A
E4 QM A B
S2 E1 QM QM QM
E2 QM QM A
E3 QM A B
E4 A B C
S3 E1 QM QM A
E2 QM A B
E3 A B C
E4 B C D
機安研要な ASILを含む安全目標が明確になった。一つのアイテムに複数の安全目標の異なる ASILが割り当てら
れることもある。同一の安全目標が、複数の安全状態への遷移あるいは安全状態の維持により達成される場
合もある。このような場合、該当する全ての安全状態を明記する必要がある。
安全目標達成に必要な項目を安全要求といい、単に ASILのみならず他のエレメントとの相互関係や反応時
間なども含む事になる。全ての安全要求はアイテムの安全要求仕様書としてまとめられることになる。安全
要求仕様書は、自然言語による記載でよいが、上位の ASIL(CやD)では、より誤解の少ない方法による記載
が必要になる。
安全要求は、その対象により、アイテムの安全要求から始まり、最終的には最小単位のエレメントに割り振
られる安全要求になる。結果的にアイテムからエレメントに至る階層構造を形作ることになるだろう。どの
レベルにおいても、要求内容が明確で理解が容易である事、同一レベルの他の安全要求と矛盾しないことな
どが必要である。階層化された安全要求は、その上位・下位方向ともにトレーサビリティーが確保されなけ
ればならない。また、どの仕様においても、仕様は、規定の方法で明確に、誰でも分かるように作成されなけ
ればならない。
記述された個々の安全要求は、安全ライフサイクルを通じて識別される必要がある。識別方法は自由である
例えば、安全要求毎に識別記号を付与し、文書に記載された安全要求の記述にその識別記号を添えることで
もよい。
10. 機能安全コンセプト
機能安全コンセプトとは、安全要求仕様書に示された各安全要求がアイテムを構成するエレメント、あるい
は、外部方策や他の方策（メカ部品など）に割り振られることとなっているが、現実には、アイテムに要求
される安全要求をどのように実現するか（すなわち、安全コンセプト）を考えながら、全体の構成を作り上
げることになる。安全要求の実現には、単に危険回避のみならず危害の緩和、他の状態への遷移、ドライバー
への警告、機能を低下させながらも維持するなど、各種方法がある。自動車の安全では、driver-in-the-loopの
考え方が一般的であり、安全確保の一端をドライバーが担うことを認めている。ISO 26262もこの考え方を
認めている。この点は、工作機械などの機械の安全性に対する考え方と大きく異なる。適切な方法を選択す
る必要がある。
この段階でエレメントの配置を決めることができた。エレメントの配置が決まれば、フォールトトレランス
（故障耐性）は明らかになる。要求されるASILは既に分かっているので、充分なフォールトトレランスが
確保できるかどうかの判断を行うことができる。要求 ASILから各エレメントに要求される故障確率なども
この時点でおおむね明らかにできる。設計上の経験から、もし、エレメントが要求される故障率を満たすこ
とができないと思われる場合などは、ASILデコンポジションを検討し、エレメントに要求される ASILを下
げた回路構成に変更する必要があるかもしれない。エレメント間のインターフェースもこの時点でその概
要が決まってくる。
このようにして、アイテム全体の回路構成が決まってくる。無理が無く、合理的で実現可能な回路構成であ
ることが確認される。この時点では、各アイテムの詳しい仕様はまだ決まっていない。
機械安全研究所 14/22
機安研
11. システム開発（前半）
アイテムは、往々にして複数のシステムから構成される。各々のシステムに対して安全計画を立て、計画に
沿って開発することになる。システムを構成するエレメントが他のシステムによって使用される場合もあ
るので、他のシステム開発の安全計画との整合性も必要になる。
システム開発は、大きく２つに分けることができる。一つは、各々のハードウェアやソフトウェア開発の前
段階であるシステム設計に至る工程で、他は各々のハードウェアやソフトウェアが出来上がり、それらをシ
ステムとして組み上げていく統合工程になる。
11.1. システム設計
システムは、入力、処理、出力の少なくとも三つのエレメントから構成される。同じエレメントが他のシステ
ムと共有されることもある。システムは、安全機能のみならずその反応時間や他のシステムやエレメントと
のインターフェース、システムの動作環境などを考慮して設計される。これらの関連事項からシステムに対
する安全要求が作成される。これを技術安全要求と呼ぶ。システム設計の第 1段階は、技術安全要求を明確
にすることである。
機能安全コンセプト段階で回路構成が決まりその妥当性が検証されているので、それと矛盾がないような
システム構成になる。もし、何らかの理由で回路構成の変更が必要な場合は、機能安全コンセプト段階へ戻
って、再検討する。
ASILや回路構成により差異はあるものの、それなりの故障検出機能が必要になるかもしれない。回路構成
によっては外部方策の不具合を検出する必要があるかもしれないし、外部方策（例えばドライバー）へ不
具合情報を伝達（例えば、警告表示）する必要があるかもしれない。特に、「隠れた故障」が重複し、危険な状
態になることを避けるため、故障を検出し「隠れた故障」を無くすことが重要となる。これらの安全に関する
機能を安全メカニズムと呼び、技術安全要求の項目の一つとなる。
このようにして作成された技術安全要求は、機能安全コンセプトや初期の回路構成との間で矛盾が無いこ
とが検証された後、各システムを構成するエレメントへと割り振られる。エレメントに割り振られた技術安
全要求に従ってソフトウェアやハードウェアが開発されることになる。エレメントは、単純で適度な大きさ
を持ち、試験による評価や保守が可能でなければならない。
12. ハードウェア設計
安全計画は、ハードウェアエレメントレベルでの開発のための活動に関する詳細を含むように、かつ、ソフ
トウェアやシステム開発のサブフェーズとの矛盾がないように改訂される。改訂された計画に従いハード
ウェア設計が進められる。
12.1. ハードウェア安全要求仕様
ハードウェア安全要求仕様が、システム設計の工程でハードウェアエレメントに割り当てられた技術安全
機械安全研究所 15/22
機安研要求を元に作られる。この安全要求仕様には、ハードウェアエレメント自体のみならず、他のエレメントを
含む外部故障の検出ならびにその結果の出力に関する安全要求、それらに要求される反応時間など、安全メ
カニズムに関する要求も含まれる。当然ながら、当該ハードウェアの偶発故障や故障検出に関する故障率あ
るいは故障率クラス、ならびに、診断率、単点フォールト基準、潜在フォールト基準、および、故障耐性などの
目標値も安全要求仕様に含まれる。他のエレメントや安全メカニズムとの関連がある潜在フォールト基準
や故障耐性などは、それらとの関係やインターフェースも安全要求仕様の対象になる。
出来上がった安全要求仕様は、上位の技術安全コンセプトやシステム設計仕様、ハードウェアそのものの仕
様との矛盾がなく、かつ、必要事項を満たしていることなどに関して検証されることになる。ISO 26262で
は、ハードウェアとソフトウェアのインターフェース(HSI: Hardware Software Interface)の検証に当たり、
ハードウェアの開発者とソフトウェアの開発者は協力することが要求されている。
12.2. ハードウェアコンポーネントの再使用
既に開発され使用されているハードウェアコンポーネントを再使用することにより、安全ライフサイクル
をテーラリングできる。対象は、複雑なハードウェアコンポーネントと基本的なハードウェアパーツの中間
に位置するハードウェアコンポーネントになる。複雑なハードウェアコンポーネントには、一般的な安全ラ
イフサイクルが適用される。基本的なハードウェアパーツには、一般の品質管理(QM)が適用される。
対象となるハードウェアコンポーネントは、テストや分析により故障モード、偶発故障に関する確率などが
検証される。使用環境などの違いも影響解析などで確認する必要がある。適性確認の計画を立て、それに従
った安全活動により、要求される安全機能を有することが確認される。最終的に適性確認報告書が作成され
安全目標を満たすことが検証される。
12.3. 使用実績による適性証明
ISO 26262が発効される前に開発され、従って ISO 2626に従って開発されていなくても、充分な使用実績
があり、その市場データから信頼性が確認できるアイテムやエレメントの使用は、そこに組み込まれたソフ
トウェアも含んで、認められる。この場合、使用された目的や環境とこれから使用される目的や環境が同じ
か、極めて類似していることが条件になる。
実績があるとはいえ、偶発故障に関する検証や、安全目標を満たすことの検証、他のエレメントやアイテム
の統合に関しては、ISO 26262の規定に従って行う必要がある。
12.4. 市場データの分析
既存のアイテムやエレメントの再使用は、それらの影響解析や変更管理が行われていることが条件になる。
最低でも対象となる車両の年間運用時間の平均以上の時間を観察して算出する必要がある。データはカイ
二乗分布を用いて下側 70%の有意水準で推定され、ASIL D: <10-9/h, ASIL C: <10-8/h, ASIL B: <10-8/h, ASIL
A: <10-7/hが確認されなければならない。この値は、PMHFの要求値よりも一桁小さくなっている。この精度
を算出するには、それなりの延べ運転時間が必要になり、ASIL Dの場合、1.2x109時間といわれている。この
機械安全研究所 16/22
機安研時間を待たずに推定を行う必要がある場合の例外処置も規定されている。その場合でも、観察を続け、必要
な観察時間が達成された時点で必要な信頼性が再計算されなければならない。
12.5. ハードウェアエレメントの設計
同一のエレメントが安全関連以外の一般機能のために使用されることもあるので、設計に当たっては、その
両方を考慮して進める必要がある。また、同一のエレメントが他の安全システムで使用される場合は、要求
される一番高い ASILに適合する必要がある。ハードウェアエレメントが複数のサブエレメントから構成さ
れ、サブエレメントに異なる ASILが要求され場合は、サブエレメント間の独立性を明確にするか、それが出
来ない場合には最も高い ASILが適用されることになる。
このようにして、エレメントあるいはサブエレメントの構成が決定した段階で、故障耐性が要求を満たすこ
とを確認し、その後 詳細な回路設計が始まる。
12.6. 安全分析
回路が決まったら、安全分析を行い、各種フォールトや故障の影響を解析し；
１）仕様で要求されるシステムやエレメントの故障率、あるいは、ハードウェアパーツの故障率クラス、診
断率を満たすこと、および；
２）単点フォールト基準、潜在フォールト基準などを満たすことが検証される。
規格ではこの工程は、上位 ASIL((B),C,D)にだけ要求されるが、ハードウェアパーツのフォールトの影響を
認識しておくことは極めて重要なので、安全回路においては常に分析を行うことを推奨する。
ハードウェアパーツの故障率データは、信頼できる故障率データベースや部品メーカーが有する信頼性デ
ータ、あるいは、専門家が認めたデータなどを用いることができる。単点故障のみならず、多点故障や共通原
因故障、従属故障、ならびに、一過性故障なども分析する。ただし、一般的に、お互いに独立した多点故障の場
合、２点までの故障を想定すればよい。
診断率に関しては、安全分析により求めることもできるが、代表的な回路の診断率は規格の付属書に書かれ
ているので、その値を用いて検討することもできる。
エレメントの寿命中にハードウェアパーツやハードウェアコンポーネントの交換や調整が必要な場合は、
その情報が生産後の運用・サービスに届かなければならない。
13. ソフトウェア設計
設計開始に当たっては、ハードウェア同様、開発計画の設定からはじめることになる。ハードウェア設計と
の調和やシステム設計との統一性が要求される。ソフトウェアには、偶発故障は無くあるのは系統的故障
（いわゆるバグ）だけなので、その対策となるマネジメントが重要になる。ASILの程度に応じて、用いる手
法や方策が決められており、高い ASILには検出精度の高い、あるいは、間違い程度の低い手法や方策が要求
される。各設計開発工程に要求される手法や方策に関しては、ISO 26262を参照することになる。
ISO 26262では、Vモデルによる開発を基本にしている。他の開発手法の使用も可能であるが、その正当性
機械安全研究所 17/22
機安研を証明しなければならない。
設計活動の開始の前に、担当各位がソフトウェア作成において従うべき、コーディング規約（コーディング
ガイドライン）が要求される。その内容は、ASILにより異なるが、複雑さの防止、強い型付けなど一般に規
定される内容になっている。コーディング規約の様式は自由である。自社の現状用いている規約が ISO
26262の要求に合うことを確認すればよい。SPICEなどは、ソフトウェアエンジニアの技能確認に用いるこ
とが出来るが、必須要求ではない。
13.1. ソフトウェア安全要求仕様
ソフトウェア設計のゴールである安全要求仕様を、技術安全コンセプトやシステム設計に従い、かつ、ハー
ドウェア設計との整合性を有するように作成する。
ハードウェア・ソフトウェア・インターフェース（以下、HSI）に関する仕様も定める必要がある。HSIに
関しては、ハードウェアを正確に制御できるレベルまで規定する必要があり、相互の依存性に関するまでの
記述が必要になる。
出来上がった仕様は、コンセプト設計やシステム設計、ハードウェアとの整合性が検証されなければならな
い。ハードウェアで行ったと同様に、HSIの検証はハードウェア開発の担当者と共同で行わなければならな
い。
13.2. ソフトウェアコンポーネントの再使用
既存のソフトウェアコンポーネントが再使用される場合、その仕様や検証資料など、それが系統的故障を防
ぐように開発されたということを裏付ける資料が必要である。そのような条件の下、適性評価の計画が立て
られそれに従って作業が進められることになる。カバレッジや異常時の振る舞いなどを含め、安全要求を満
たすことが検証されるのは、新規開発の場合と同じである。
13.3. ソフトウェアアーキテクチャ設計
安全要求仕様を満足すべく、ソフトウェアアーキテクチャを作成する。これは、引き続き行われるソフトウ
ェアコンポーネントやソフトウェアユニットの開発を正確にかつ、効果的に行うためでもある。ASILの低
い場合（A,B）は非形式記法が認められるが、高い場合（B,C,D）は準形式記法が要求される。形式記法は 、
ASIL Dにおいても強く推奨されるわけではない。アーキテクチャ設計においては、検証の容易さ、設定変更
への対応性、試験のしやすさ、メンテナンスのしやすさなどを考慮する。また、機能安全に関する設計の原則
である、モジュール性、カプセル化、単純性などを用いて複雑さによる問題の発生を回避するようにする。こ
れらに関する手法も ASILに対応して規定されている。
最終的には、ソフトウェアユニットレベルまで特定できるようにアーキテクチャ設計を行う必要がある。
アーキテクチャ設計の検証に関しても、ASILに従った手法が規定されている。
機械安全研究所 18/22
機安研13.4. ソフトウェアコンポーネント
ソフトウェアは、幾つかのソフトウェアコンポーネントから構成される。ソフトウェアコンポーネントの場
合、新規開発以外に、既存のコンポーネントをそのまま、あるいは、変更して用いることもある。ソフトウェ
アを構成するソフトウェアコンポーネントに関しては、この種別を明らかにしておく。これにより、安全ラ
イフサイクルのテーラリングが可能になる。
ソフトウェア安全要求は、ソフトウェアコンポーネントに割り振られ、更に、ソフトウェアユニットへと分
解される。幾つかの安全要求が同じソフトウェアコンポーネントに割り振られる場合は、一番高いASILを
満たすようにしなければならない。また、ソフトウェアコンポーネント間の独立性（パーテーション）を確
保できない場合も、影響を受けるであろう最高の ASIL要求を満たす必要がある。パーテーションを司るソ
フトウェアがもしあれば、境界を挟む高いほうの ASILの要求を満たす必要がある。
13.5. ソフトウェアユニットの設計
ソフトウェア設計の記述は、ASILに応じ厳密な記述が求められる。ISO 26262の場合、自然言語による記述
と、Aや Bでは非形式記述、CやDでは準形式記述を組み合わせて用いることになる。
ソフトウェアユニットの仕様は、レジスタの使用状態やデータの保存に関する制限なども含み、詳細な記述
を行う。ISO 26262では、幾つかの設計原則が ASILに応じて規定されているのでそれを満たす設計を行う
必要がある。それらにより、単純で理解可能であるなどの基本的原則を満たすソフトウェアユニットが開発
される。
設計されたソフトウェアユニットは、これも ASILに応じて規定されている手法により、HSI要求への適合、
設計仕様への適合などが検証される。
コーディングされたソフトウェアユニットは、ASILに応じた規定の方法で試験されることになる。
試験は、事前に計画を立て、合否判定基準も明確にした上で行われる。これらの試験を通じてソフトウェア
のセーフティーケースが蓄積される。試験においては、必要な機能を有することの確認のみならず、想定外
の機能を有しないことも確認する必要がある。この目的で、適切なツールを用いたカバレッジの測定が行わ
れる。これら一連の試験は、できるだけ実使用に近い環境で行われることが望ましい。
13.6. ソフトウェアツール
ソフトウェア開発に用いるツールのエラーが安全性に影響を与える場合、そのソフトウェアツールの信頼
性に関する要求、ならびに、その使用方法に関する規定がある。
ソフトウェアツールの信頼性に関しては、ISO 26262特有の TCL(Tool Confidence Level)という概念が用い
られる。TCLは、これも ISO 26262特有の概念で、TI(Tool Impact)というツールが開発しているアイテムに
与える影響の度合いと、TD(Tool error Detection)というツールの故障や誤出力防止の度合いの組合せで決
定される。TCLの程度に応じて、その評価方法が規定されている。低い水準では使用実績が認められる。高い
水準では妥当性確認やソフトウェア開発における機能安全マネジメントの評価が必要になる。これらの評
価は、検証対象になり、また、文書化されなければならない。
機械安全研究所 19/22
機安研使用に当たっては、ソフトウェアの説明書などを明らかにし、どのソフトウェアツールをどのような環境で
使用するかなど、あらかじめ明らかにしておく。これは、ツール使用の再現性を確実にするためでもある。
13.7. ソフトウェア統合
ソフトウェアユニットの完成の後は、それらの統合作業になる。ご他聞に漏れず、統合に当たって計画を立
て、ソフトウェアユニット相互間やHSIに関する項目などを仕様に織り込んでから実行に移す。この段階で
も、統合テストの手法、テストケースを導き出すための手法、意図しない機能がないことを確認するための
カバレッジ測定手法などが規定されているのでそれを満たす方法を用いることになる。ソフトウェアユニ
ットのテストと同様に、最終使用環境とテスト環境の違いは分析されなければならない。
全ての統合が完了すると、最終的に、ソフトウェアが安全要求を満たすことが検証される事になる。計画お
よび仕様決定の後、実行される。この段階になると、ASILに拘わらずソフトウェアは対象となるハードウェ
アに組み込んで試験しなければならない。その試験環境も ASILに応じて規定される。
13.8. ソフトウェアコンフィギュレーション
設定可能なソフトウェアにコンフィギュレーションのためのデータを用いて安全関連の制御に用いる場合
を考えた規定もある。設定可能なソフトウェアはもちろんのこと、コンフィギュレーションデータやキャリ
ブレーションデータに対しても検証が必要である。これらのデータは、それが用いられるソフトウェアの最
大の ASILを満たす必要がある。これらの検証は、計画・仕様化・実行・文書化の流れの元で行われる。
14. システム開発（後半）
ハードウェアとソフトウェアが完成すると、それらを統合してエレメント、エレメントを統合してシステム
システムを統合してアイテム、最後は、アイテムを統合して車両レベルに至る。これらの統合に際して統合
およびテスト計画の詳細が安全計画に盛り込まれる。各機能安全要求や技術安全要求は、これらの統合を通
じて少なくとも１度は検証されるように計画する。テストケースを導き出す手法は、ASILに応じて規定さ
れているので、それらの手法を用いることになる。
14.1. ソフトウェアとハードウェアの統合とテスト
系統的フォールトを見つけ出すことが、統合テストの大きな目的となる。このためのテスト手法が ASILに
応じて規定されている。ある程度の組合せが出来上がると、安全メカニズム、インターフェース、故障診断、
丈夫さの確認も可能になる。このためのテスト手法もASILに応じて規定されているので、統合のレベルに
応じてこれらの手法を用いてテストすることになる。
更に統合が進むと、システムレベルから車両レベルに至るテストを行うことになる。ここでも、同様にASIL
に応じたテスト手法が規定されているので、それらを用いてテストを進める。
機械安全研究所 20/22
機安研14.2. 妥当性確認
妥当性確認は、車両レベルで行うことになる。いつもの事ながら、安全計画に妥当性確認計画の詳細を盛り
込んでから作業開始になる。各安全目標の確認作業を行い、その結果が評価されることになる。
15. SEooC (Safety Element out of Context)
異なる顧客の異なる使い方に対して用意される一般的なエレメントやシステム、ハードウェアコンポーネ
ントのことを、ISO 26262では、SEooCと呼んでいる。アイテムレベルになると車両が関係してくるので
SEooCには含まれない。SEooCは、想定された使用に基づいて開発されることになるだけで、一般的な安全
関連の開発と変わるところはない。妥当性確認は、車両への組み込みを待って行われることになる。
15. 機能安全アセスメント
安全計画に従って少なくとも１度は機能安全アセスメントを行う。上位 ASIL((B),C,D)の場合は、各工程で、
定められた項目が確認されることになる。プロジェクト単位の活動になり、各工程で作成されるべき書類、
言い換えれば、各工程の作業結果の評価が主になる。ASILに応じてアセッサーの独立性が要求される。
16. 機能安全監査
機能安全アセスメントがプロジェクト単位の活動であるのに対して、機能安全監査は、機能安全マネジメン
トの仕組みを評価することが目的となる。プロジェクトに関係なく、決められた計画に従って行われる。
17. 生産許可
妥当性確認の評価を含み、すべての工程の完了、および、機能安全アセスメントの結果が合格であれば、生産
許可の文書が責任者により署名され発行されることになる。責任者は、関連文書を確認することができ、か
つ、安全目標が達成されたことを確認する。
18. 生産
単に生産といっても、電気部品の組み立てから車両への組み込みまでの範囲が含まれる。生産は生産計画に
則って行われる。安全関連部品の場合、保管や輸送、ならびに、組み込みに対して特別な要求があるかもしれ
ない。また、それらの作業者に対して事前の訓練が必要になるかもしれない。これらを考慮して、生産計画が
立てられる。生産ラインでソフトウェアがハードウェアに書き込まれるのであれば、両方のバージョン管理
や書き込み装置や書き込み方法、テスト装置やテスト方法なども管理対象になる。
不具合が発見された場合は、開発責任部門へ連絡され対処されなければならない。設計変更が必要な場合に
は、決められた変更管理の下で行なわれる必要がある。
19. 変更管理
生産開始後も、諸般の事情により、設計変更が必要になる。安全関連部分の設計変更に関しては、変更が及ぼ
機械安全研究所 21/22
機安研す影響を解析し、安全目標に影響しないことが確認される。変更される部分だけでなく周囲との相互関連も
考慮する事になる。安全ライフサイクルを通じて蓄積された文書類をたどって確認、あるいは、必要に応じ
てテストなど行う。変更される場合も、そのトレーサビリティーが維持されなければならない。
変更依頼部門からは、変更が必要な理由などを述べた変更依頼文書が発行されるだろう。設計部門では、設
計変更の必要性の判断と共に、設計変更を行っても安全目標が影響を受けない旨の確認が行われたことを
示す文書、および、変更内容や変更のタイミングが記入された文書が発行されるだろう。
20. 運用、保守、廃棄
安全性能を維持するために、車両の運用を通じて点検や保守、あるいは、修理が必要になるかもしれない。ま
た、廃棄に当たり、行なうべき事があるかもしれない。そのような情報は、ドライバーに対してはユーザーマ
ニュアルなどに、サービスステーションに対してはサービスマニュアルなどに記載され提供されることに
なる。必要に応じ、各作業方法やツール、手段などの記述が必要になる。安全方策として安全機能の「縮退」を
行なう場合などは、ドライバーに対する情報提供も必要になるだろう。サードパーティー製品の使用により
安全が損なわれる場合もあるかもしれないのでそれに対する警告が必要かもしれない。当然、交換部品の供
給体制も整えておく必要がある。
ドライバーへの情報提供に関して、ISO 26262では、世間で一般的ではない斬新な安全方策を用いた場合な
ど、ドラーバーがその機能に不慣れなために起こるかもしれない危険な状態を防ぐための警告や説明を要
求している。
メーカーからの情報提供だけでなく、市場からの情報収集の体制も整える必要がある。市場で生じた不具合
で、開発に原因がある場合は、遅滞なく開発部門へと連絡され対処されなければならない。また、アイテムの
使用実績証明のための不具合情報の収集システムの構築も必要であろう。
廃棄に当たり、行うことがあれば廃棄指示に含める。各種エラーログの吸い上げは、現状の問題発見、および
将来の開発のための貴重な情報となる。問題が発見された場合は、設計変更手順に則り処置される。
機械安全研究所 22/22
