前述の章「安全に関する基本概念」でGuide 51が24年も経って「安全」という用語の定義を変えていることでも分かるように、定義次第では規格策定者の意図と異なる方向に誘導されることや理解の相違につながる可能性があるためPart1は重要である。一般的な用語とISO 26262で使用されている用語の定義が異なる場合があるので注意して用語集を確認頂きたい。一例として安全規格のグループ規格であるISO 13849-2(制御システムの安全関連部第2部：妥当性確認)で妥当性確認は「静的、動的試験の両方、その他の方法を用いて、意図する安全機能を実施し、意図しない機能が発生することがないようにすべての部品が正しく相互に動作することを示すプロセスである」と定義されているが、ISO 26262では第4部で安全目標が達成できているかどうかを統合されたアイテムが実装されている代表車両で動的に確認するタスクのみで妥当性確認という用語が使用されている。

第2部では、安全関連製品を扱う組織に対して機能安全を達成していくための組織体系に関する要求事項、プロジェクトによる製品開発中に機能安全を達成していくための要求事項、市場における安全アノマリーの有無を監視していく運用時の要求事項と、全安全ライフサイクルを通して実施すべき安全管理の側面を規定している。
安全関連製品を開発/生産/運用する組織は、行動規範として安全確保が常に優先されるような安全文化の醸成、安全活動に従事する者の能力管理、安全管理のベースとしてIATF 16949に代表される品質管理システム(QMS)導入が要求される。
プロジェクトによる開発段階においては、機能安全の達成に責任を持つプロジェクト管理者と安全計画化とその調整に責任を持つ安全管理者の任命、安全活動と安全管理活動、安全活動で作成されるべき成果物、役割分担、安全活動実施のために必要な能力やリソースなど機能安全を達成するための戦略をまとめた安全計画の立案、安全計画の実行と監視、確証方策による機能安全達成の評価が要求される。
最後の節として、市場においてシステム運用中に安全目標が侵害されるような安全アノマリーが発生していないかどうかを監視するモニタリングシステムの構築、安全アノマリーが確認された場合の対応プロセスの確立が要求される。

車両レベルにおいてリスクアセスメントを実施し、リスク低減の目標や開発指針を定める、ISO 26262において極めて重要な章である。また前述の章「安全に関する基本概念」に沿って安全規格が策定されていることがよく分かるPartである。

タスクとしては、アイテムの定義、ハザード分析とリスクアセスメント、ASILと安全目標の決定、機能安全コンセプト構築(機能安全要求とシステムへの安全要求割付け)の実施が要求されている。機能安全コンセプトは当該システムサプライヤへの要求事項として提供されることになるが、安全関連活動を完成車メーカ、システムサプライヤ、Tier2サプライヤ間でどのように役割分担するかは開発インタフェース協定(Development Interface　Agreement : DIA)で定義されるのが一般的である。

安全コンセプトは完成車メーカから提供されることが多いため、サプライヤにとって第3部の規格内容を把握しなくてもよいと思われるかもしれないが、前述のとおり第3部はリスクアセスメントからリスク低減活動の流れを記述した唯一のPartであるため、システム(この場合システムにはSEooC：Safety Element out of Contextのコンセプトを持つ製品を含む)を熟知しているサプライヤは第3部の内容を踏まえて、制約の決定、リスクの見積もり、リスクの評価を行い、システムで実現すべき本質的安全設計(安全機構を実装するのみでなく)、付加的保護方策、使用上の情報の順番でリスク低減方策の検討を実施した結果を安全コンセプトとしてまとめて製品開発コンセプトに組込むことが重要と考える。自動車産業の特徴で考えれば、利用者はリスクを低減するための方策(防護具の着用など)を準備することや、リスクを低減するための訓練を受けること、ユーザーズマニュアルに基づきシステムからの異常警告時にリスク低減行動をとることはほぼ期待できないため、現実的には機能による安全または安全な機能の導入、すなわち本質安全設計が達成手段となると思われる。

第4部では設計フェーズとして、機能安全コンセプトをもとに技術レベルでの安全要求の仕様化、技術安全要求を達成可能な実現手段の選定とシステムアーキテクチャ設計への反映を行った結果、ハードウェア、ソフトウェア開発に安全要求と、安全計画を含む安全に関する開発方針を提供することを目的としている。評価フェーズではシステムエレメントの設計/実装/評価フェーズを経て完成された各システムエレメントを統合戦略に基づいて順番に統合し、適切な評価環境を利用して各安全要求、内外部インタフェース、安全機構の性能、ロバストネスの検証を目的とした3段階の統合テストと、すべての要素が統合されアイテムが搭載されたターゲット車両での安全目標の達成確認を目的とした安全妥当性評価が行われる。
Automotive SPICE v3.1で定義されているエンジニアリングプロセスと対比すると、システム要件分析SYS.2、システムアーキテクチャ設計SYS.3、システム統合および統合テストSYS4、システム適格性確認テストSYS5のプロセスに該当する。機能安全を達成するために組織の標準プロセスを準備する際にはAutomotive SPICEなど国際的なプロセス参照モデルに基づいたプロセスを構築し、リスク低減のために安全関連の開発に適用するプロセスを追加できるように規定しておくとよい。
システム安全設計では一般的にMSR(Monitoring & System Response)、FDIR(Fail Detection, Isolation and Recovery)といった、故障を検出しシステム動作を安全方向へ切り替えるものが安全機構として組み込まれる。またシステマティック故障を減少させるためにアーキテクチャ設計においては過去に実績のある技術の再利用が推奨されている。これはFMEAにおける発生頻度(Occurrence)のレーティングが新規設計の適用に比べて過去の設計再利用が低くなることと同様の考え方である。安全機構のみならず安全に関連する機能にはシンプルで十分枯れた技術を適用することも潜在的なリスクの低減に貢献する。これはコンポーネント設計でも同様で、コンポーネント設計者へ複雑さの回避と実績のある設計の適用が非機能要求として伝える必要がある。

第5部では、システムレベルでの安全設計方針の決定を受けてハードウェア技術で構成される安全機構を実装し、テストすることが求められる。活動開始時にシステムレベルで決定している計画、および安全活動に関する非機能的な安全要求を考慮してハードウェア開発における安全計画の立案、設計フェーズでは技術安全コンセプトをもとにしたハードウェア安全要求の仕様化、ハードウェア安全要求を具現化するハードウェア設計、ハードウェアアーキテクチャが十分リスク低減されるよう設計されているか検証する定量的アプローチによるメトリクス評価、ランダムハードウェア故障に起因する安全目標侵害の可能性が十分に低減されているかを検証する定量的アプローチによる評価の実施が求められる。評価フェーズではハードウェアエレメントを戦略に基づいて統合し、適切な評価環境を利用してハードウェア安全要求の準拠を検証することが求められる。
E/Eシステムの構成要素であるソフトウェアと違い、偶発故障が潜在することがハードウェアの特徴であり、第5部では定量的アプローチによるハードウェアアーキテクチャ評価が要求されている。ハードウェアエレメント自体が持つ故障モードを分類し、それぞれの故障モードに対する故障率と安全機構による診断カバレッジ(DC)によって、残存フォールトを考慮したシングルポイントフォールトのリスク評価および、マルチプルポイントフォールトを考慮したレイテントフォールトのリスク評価、そして安全目標が侵害されるリスクが十分に低減されているかを確率的分析手法またはカットセット分析のいずれかを使用した安全目標侵害確率の評価が実施され、ASILで与えられる目標値を達成するようハードウェアを設計する必要がある。

第6部では設計フェーズとして、システムレベルでの安全設計方針の決定を受けてソフトウェア技術で構成される安全機構を実装し、テストすることが求められる。活動開始時にはシステムレベルで決定している計画、および安全活動に関する非機能的な安全要求を考慮してソフトウェア開発における安全計画の立案、設計フェーズでは技術安全コンセプトをもとにしたソフトウェア安全要求の仕様化、ソフトウェア安全要求を具現化するソフトウェアアーキテクチャ設計、アーキテクチャ設計に基づきソフトウェアコンポーネントの実装設計と実装および実装評価が求められる。評価フェーズではソフトウェアエレメントを戦略に基づいて統合し、適切な評価環境を利用してソフトウェア安全要求の準拠を検証することが求められる。
第6部のソフトウェア開発においては、これまでに標準化されているソフトウェア不具合低減に寄与する技術や手法、Automotive SPICEに代表されるプロセス参照モデルの適用、デザインパターンの選定、構文解析による構造評価、一般的テスト手法(命令、分岐カバレッジ)などを導入することで要求事項に対応することが可能であるが、それらをリスク低減のためにどのような考え方で導入あるいは利用したかを説明できることが重要である。安全関連で特徴的な項目として、必要に応じてソフトウェアに配置された技術安全要求が侵害されるような決定論的故障があった場合に追加の安全機構が求められる点、ソフトウェア安全設計およびその評価を支援するためにソフトウェア安全分析の実施が求められる点があげられる。

第7部では生産及び運用中における安全活動の実施と管理が求められる。生産フェーズでは機能安全達成に大きく寄与する安全関連特別特性や生産に対する安全要求が開発フェーズで識別され、生産中における安全関連特別特性の管理が生産計画の立案、生産工程設計、生産管理計画に反映し、実行することが求められる。運用、保守、廃棄いずれのフェーズにおいても、関わるエンドユーザーあるいはサービス工程に対してユースケースの中で発生しうるリスクの回避あるいは低減することを目的とした安全活動の計画、実施あるいはユーザーへの情報提供(ユーザーによるリスク回避行動が期待できる場合)が求められる。
品質マネジメントシステムにおいて製品の品質に大きく寄与する特性、パラメータを品質特殊特性と呼び、それらが生産上特に管理が必要な項目であることを、特殊特性記号を用いて明確にしている。設計FMEA、工程FMEAの実施により、どのパラメータが生産上の重要管理項目であるかを識別する。安全関連で考えるとASILが同様の位置づけである。ASILが設定されている管理項目に関しては生産上のミスが入らないように配慮した生産ライン設計や日常の工程管理が必要になってくる。

第8部における要求事項は多岐にわたる。一般的なプロセス参照モデルの支援系プロセスエリアとして定義されている内容と合致する項目が多いが、安全関連特有の側面を持つ項目もある。

 

第5節では安全関連の製品開発工程を部分的に委託する場合にかかる要求事項を定義している。委託先の機能安全対応能力評価、委託元と委託先の役割分担、双方の役割を遂行するために必要な情報、インタフェースなどを定義し双方で合意した開発インタフェース協議の締結、委託先の機能安全アセスメントの実施が求められる。

 

第6節では安全要求が後工程で正しく理解されるまたは検証されることを目的として、安全要求記述に用いる記法や安全要求の特性や属性を定義し、また安全要求の管理方法を明確にしている。安全要求の重要な特性として要求記述に曖昧さがないこと、単純であること、テスト可用であることがあげられる。安全要求の管理としては双方向トレーサビリティの確立、ステータス管理を含む構成管理を行うことで安全要求変更時の影響分析や安全要求の変更管理を可能としている。

 

第7節ではある時点の成果物、あるいは成果物間の内容が一貫した状態でその組合わせが再現可能であることを保証するために安全関連成果物の構成管理を実施することが求められる。また構成管理された結果、前のバージョンと現在のバージョンの関係と差異がトレースできることも求められている。構成管理を確実にするために構成管理の方針や戦略、役割、利用する構成管理システム、ベースライン管理などをまとめた構成管理計画書の策定が必要になってくる。

 

第8節では安全関連の作業成果物に対する変更が必要になった場合に、変更実施前にその変更が及ぼす影響を分析し、適切な判断のもと変更要求の対応要否が決定され、変更の実施と結果の追跡がされることが求められる。変更管理を確実にするために変更管理の方針や戦略、役割、変更要求に対する評価方法、変更の追跡方法などをまとめた変更管理計画書の策定が必要になってくる。

 

第9節では安全活動で生成される作業成果物に対して、要求事項に準拠していることを確認することが求められる。検証を確実にするために、検証に用いる手法、ツール、合否判定基準などをまとめた検証計画書および検証に用いるテストケースやチェックリストをまとめた検証仕様書の策定が必要になってくる。

 

第10節では文書化に関する要件が定義されている。安全性論証を支える根拠、エビデンスとなりうる情報を体系的に記録することが求められる。それらの情報が文書化されることを確実にするために文書管理計画書の策定が必要になってくる。構成管理と合わせて文書化に関する計画を策定するとよい。

 

第11節では安全活動に用いるソフトウェアツールで得られる出力や結果が意図しない結果になった場合に製品安全への影響、および自工程あるいは次工程以降での検出可能性を評価することが求められる。この評価の結果、影響が大きく、検出可能性も期待できない場合はソフトウェアツールの認定作業が必要とされる。認定作業の手法は、使用実績のエビデンスを得ること、ツール開発が適切な標準プロセスに準拠して行われたことのエビデンスを得ること、ツールのユースケースを考慮したツール妥当性評価を行うこと　が与えられている。

 

第12節ではソフトウェアコンポーネントを再利用する場合に適用すべき要求事項が定義されている。再利用にあたり、そのソフトウェアコンポーネントに求められる要求や機能性、ユースケースを明らかにし、そのソフトウェアコンポーネントが意図したとおりに使用できるかを評価したエビデンスを用いて再利用可否の認定をすることが求められる。

 

第13節ではハードウェアコンポーネントを再利用する場合に適用すべき要求事項が定義されている。再利用にあたり、そのハードウェアコンポーネントに求められる要求や機能性、ユースケースを明らかにし、そのハードウェアコンポーネントが意図したとおりに使用できるかを評価したエビデンスを用いて再利用可否の認定をすることが求められる。

 

第14節では既存のアイテムやエレメントを再利用する際に信頼のおける使用実績データが利用できる場合に安全活動を最小化するためのフレームワークが与えられている。しかし現実的にはこの節の要求事項に沿った使用実績による論証の適用は難しいとされている。

第9部では設計フェーズにおいてASILがコンポーネントに割り当てられる際に用いなければならない規定、および安全分析に関する規定が提供されている。

 

第5節ではASILデコンポジションのフレームワークが提供されている。複数の冗長化した機構で安全要求を達成する場合は安全要求に割り当てられたASILを提供されたフレームワークに基づいて各機構に分割することができる。これは冗長化された機構のうち、いずれかの機能が失陥したとしても残りの機構で安全要求が達成できる場合に限って適用できるフレームワークとなっている。

 

第6節ではエレメント内に異なるレベルのASILを持つ安全要求が配置された場合に適用しなければならない基準が提供されている。ASILを持たない機能、あるいは低次のASILを持つ機能失陥が、高次のASILを持つ機能失陥を引き起こす可能性がないと証明できない限りは、高次のASILを割り付ける必要がある。

 

第7節では従属故障の分析に関する要求事項が提供されている。異なるレベルのASILを持つエレメント間に従属故障がないと証明することができればそれぞれ元のASILで開発することができるが、従属故障がないことが証明できない場合は影響しあうエレメント間で最大のASILを割り当ててそれぞれのエレメントを開発する必要がある。

 

第8節では設計フェーズで利用可能な安全分析の手法および安全分析実施時の要求事項を提供している。設計フェーズのアーキテクチャ評価として演繹的分析手法と帰納的分析手法の使用、ハードウェアメトリクス評価では定量的安全分析手法の使用が要求されているが、この節では一般的な安全分析のうちいくつかを事例として提供している。

第10部はISO 26262を利用するために有用となる情報がガイドラインとして提供されている。第2部から第9部にかけて提供されている要求事項のうち、理解しづらい箇所についていくつか事例をあげて解説されている。