自動車用機能安全規格ISO26262の紹介
ISO26262 Automotive Functional Safety Standard
茂野 一彦＊
Kazuhiko Shigeno

自動車用機能安全規格ISO26262が2011年11月に制定された。これを受けて、自動車業界ではこの規格の適用を標準化する動きがある。
こうした状況の中で、自動車メーカのみならず自動車メーカに部品を納入しているサプライヤの中には、ISO26262の要件を満たすため、いち早く体制を整え、規則を整備し、規格に基づくプロセスを構築して第三者機関による認証を取得したところもある。
当社も近いうちにこういった事業者を顧客とする部門において、規格の要件を満たす対応を迫られる可能性が高い。そこで、そもそもISO26262とはどのような規格かを紹介する。
November 2011 International Organization for Standardization standardized the ISO 26262
Automotive Functional Safety Standard, Since then there has been a global movement to adopt it
as a standard of the automotive industry. In this industry, not only the car manufacturers but also
some of car component suppliers have already organized their systems, establishing necessary
rules and precisely fitting process to the standard, and then gaining ISO 26262 certification by
third parties.
Also our company, being involved in the above industry, may have to meet the requirements of
ISO 26262 in the near future. So now we are having an idea of the standard and will explain here
the outline of it.

1．まえがきコントローラを監視する安全装置の役割のことを指す。
通常、安全装置にはコンピュータが使われ、コントロー

現在、自動車業界では、電気／電子部品とそこに搭載

ラに故障などが発生した場合は、このコンピュータが制されるMPU（マイコン）のソフトウェア開発において、御対象を停止したり、ユーザに警告を出したりする。安

自動車用機能安全規格ISO26262の適用が標準化されよ

全装置によって実現されているこうした安全性のことを、うとしている。

「機能安全」と呼ぶ。機能安全とは、いわばコンピュー

当社の車事業を扱う部門においても、今後、ISO26262

タなどを使った安全装置による安全対策といえる。機能に対応する車載機器の制御ソフトウェア開発を請け負う

安全の例としてよく引用されるのは、鉄道の踏み切りで場合、顧客からISO26262に基づく要件を満たすよう求ある。踏み切りは、警報システムの機能によって鉄路をめられる可能性が高い。

走る列車と鉄路に平面交差する道路を通る車両や人とのそこで、そもそもISO26262とはどのような規格であ

衝突を防いでいる。

るのか。そのポイント（２章〜７章）と、当社の業務になお、安全性そのものは、こうした電子的な安全装置

関わりの深いソフトウェア開発において何が求められるの付加によって担保するのではなく、危険そのものの設か（８章〜11章）を紹介する。

計上の除去や機械構造的なフェールセーフ機構などによ

2．機能安全って担保するのが一般的である。これを「本質安全」と呼ぶ。本質安全の例でよく引用されるのは、鉄道と道路

機能安全とは、安全機能や安全対策によって、許容での立体交差である。これは機械構造的に鉄路を走る列車

きないリスクから免れるための技術の総称である。機能と道路を通る車両や人とが衝突する危険そのものを取り安全（functional safety）の「機能」とは、制御対象や除いている。

＊関西事業部 姫電プロジェクト室

MSS技報・Vol.23

28

機能安全の考え方は、石油化学プラント、原子力発という）を定め、ASILのレベルに応じた方策によるシ

電、産業機械、航空機、鉄道、自動車、医療機器など、ステムの開発を行って、結果的に事故発生のリスクを低多岐にわたるクリティカルな（事故が発生すると人命が減している。

脅かされたり、環境に重大な影響が及ぶような）システ

4．ISO26262とはムに適用されている。
ここでは、自動車の機能安全について取り上げる。
3．機能安全規格制定の経緯「ISO26262」とは、車載電子システム向けの機能安
全規格である。
車載電子システム、つまり車両に搭載する電気／電子

機能安全の規格化の動きは、1990年代から始まった。

機器とコンピュータ（ソフトウェアを含む）がISO26262

その背景には産業のあらゆる分野で電子化が進み、ソフの直接的な対象である。対象とする車両は重量3.5ton以

トウェア（特に組み込みソフトウェア）で動作する機器

下の乗用車で、２輪車やトラック、障害者用などの特殊が非常に増えてきたことがある。即ち「複雑で大規模な用途向け車両は含まれていない。

ソフトウェアを含むシステムにリスク・ゼロはあり得な

ISO26262の目的は「安全」の確保であり、その実現い」という共通認識が安全やソフトウェアの専門家の間のためには、ISO26262の直接的な対象となる電子シスに広がり、電子系に関する安全基準を各社が独自に策テムに限らず、システムを構成する他の要素も含めた安定・運用する方法ではもはや限界があるとされた。こう全性の考慮が必要となる。その上で、ISO26262の適用した動きを受けて、プロセス産業における電気／電子／

箇所を明確にし、システム全体における車載電子システ

ソフトウェアの機能安全に関わる国際規格「IEC 61508」

ムの安全性を体系的に確保する必要がある。

が2000年に制定された。
IEC61508で は、 シ ス テ ム を 構 成 す る リ レ ー やPLC

ISO26262の全体構成を図１に示す。
太枠で囲んだ矩形がPart（部）を示しており、図から（Programmable logic controller）などの安全装置（リわかるように、この規格はPart １〜Part10で示された

スク低減手段）が、その安全機能を果たす確からしさ

計10個のPartから構成されている。その中にある細枠の（信 頼 度） と い う 確 率 論 的 な 指 標 を 安 全 度 水 準SIL

矩形は各Partにおける規定の節（項目）であり、個々の（Safety Integrity Level）として定義している。即ち、プロセスに対応する。

システムを構成する安全にかかわる部品の故障率を低くすれば、それによって構成されるシステム全体も故障率が低いという定量的な確率論に基づく規格である。
しかし、SILの定義に確率的な要素が入るのは、適切Part １は規格で使われる用語の定義を行っている用語集である。
Part ２の機能安全の管理では、安全関連系の開発に関わる組織や人員が満たすべき要件を規定する。

でないという考え方がある。なぜ不適切なのか。それはPart ３のコンセプトフェーズではASIL決定の手続き

機能安全規格がハードウェアだけでなくソフトウェアもとしてのアイテム（注1）定義、ハザード分析とリスクアセ

扱っているからである。ハードウェアであれば、初期故

スメント、ASILとともに設定される安全目標から機能

障や磨耗故障以外の偶発故障はほぼランダムに発生する

安全コンセプト（注2）を作成する手続きを行う。

ため、設計エラーを別とすれば、確率論的な扱いは非常Part ４のシステムレベルの製品開発では、Part ３でにうまく当てはまる。これに対し、ソフトウェアの不具得られた機能安全コンセプトを技術安全コンセプト（注3）

合（バグ）は、その発生を確率的には扱いにくい。例えに詳細化し、システム設計に反映する。そして、ハード

ば、ソフトウェアの設計にバグが混入していた場合、そウェアとソフトウェアに該当する安全要件を仕様化するの発生経路や条件が整えば、不具合の現象は100％現れ

工程（図１の４- ５、４- ６、４- ７）とハードウェア／ソ

（1）

る 。

フトウェアの開発成果物を統合して評価（検証および妥当

そこで、IEC61508の確率論に偏重した機能安全の問性確認）を行う工程（図１の４- ８〜４-11）を策定する。

題点を改めたのが、2011年11月に制定された自動車用安Part ５のハードウェアレベル製品開発では、確率論

全規格ISO26262である。
ISO26262では、確率論に基づく定量的なハザード分
析をハードウェアに限定し、システム全体としては対象
製品の使用状況、使用方法の定性的な分析結果に基づくハザードを特定する。そして、このハザードを評価する
指標（これをASIL（Automotive Safety Integrity Level）

29（注１） ISO26262を適用する車両レベルの機能を実装するシステム。
（注２） 安全目標の達成に必要な機能安全要件を導き出し、それに基づいた要件をアイテムの暫定的なアーキテ
クチャの構想、および外部方策に適切に割り当てること。
（注３） アイテムレベルの機能安全要件をシステムレベルに詳細化した技術的な安全要件仕様。

Part１ 用語集
Part２ 機能安全の管理
2-5

2-6

全体安全管理Part３ コンセプトフェーズ

3-5

アイテム定義3-6

安全ライフサイクルの開始

3-7

ハザード分析とリスクアセスメント

3-8

機能安全コンセプト

コンセプトフェーズと製品開発における安全管理2-7

製品リリース後の安全管理

Part４ システムレベルの製品開発
4-5

システムレベルでの製品開発の開始

4-6

4-11 生産のためのリリース

7-5

生産

4-10 機能安全アセスメント

7-6

運用，サービス（メンテナンスと修理）および廃棄

技術安全要件仕様
4-9

4-7

Part７ 生産と運用

システム設計4-8

安全妥当性確認

アイテム統合と試験

Part５ ハードウェアレベルの製品開発

Part６ ソフトウェアレベルの
製品開発

5-5

ハードウェアレベルでの製品開発の開始

6-5

ソフトウェアレベルでの製品開発の開始

5-6

ハードウェア安全
要件仕様

6-6

ソフトウェア安全要件仕様

5-7

ハードウェア設計

6-7

ソフトウェアアーキ
テクチャ設計5-8

ハードウェアアーキ
テクチャ指標評価

6-8

ソフトウェア単体
設計と実装

5-9

偶発的ハードウェア
故障による安全目標
侵害の評価

6-9

ソフトウェア単体試験

5-10 ハードウェア統合と試験

6-10 ソフトウェア統合と試験
6-11 ソフトウェア安全要件の検証

Part８ 支援プロセス
8-5

開発委託における要求事項

8-10 文書化

8-6

安全要件の仕様と管理

8-11 ソフトウェアツールの認定

8-7

構成管理

8-12 ソフトウェアコンポーネントの認定

8-8

変更管理

8-13 ハードウェアコンポーネントの認定

8-9

検証

8-14 使用実績による論証

9-5

ASIL テーラリングに関する要件のデコンポジション

9-7

従属故障分析

9-6

要素共存のための基準

9-8

安全分析

Part９ ASIL 指向および安全指向分析

Part10 ISO26262 のガイドライン
凡例

図１

ISO26262の全体構成に基づくハードウェアの偶発的故障発生確率（注4）の計算、

2-5

2：Part 番号
5：Part 毎の節番号

Part ６のソフトウェアレベルにおける製品開発では、（注5）

技術安全コンセプトに沿って開発する安全メカニズム

Ｖ字プロセスに従って、技術安全コンセプトに従ったソの実装、および、その結果として得られる安全目標を侵害

フトウェア安全要件の導出、ソフトウェアアーキテクチャ

する確率の定量的評価に基づいた設計と試験を行う。

設計、ソフトウェア単体設計と詳細化を実施し、それをMSS技報・Vol.2330

基にコーディング（実装）を行った後は、ソフトウェア

6．ASILの決定

単体試験、ソフトウェア統合（モジュール結合）と試験、ソフトウェア安全要件の検証を行う。
Part ７は量産やサービス、市場の監視、さらには廃棄するまでの安全要件を規定する。
Part ８はサプライヤへの開発委託、支援系プロセス

ISO26262では、リスクの指標としてASILを使用する。
ASILは、リスクアセスメントの結果得られる３つの指標（S、E、C）から決定する。
S：過酷度（Severity）（安全要件の管理、構成管理、変更管理、検証、文書化）

これは、アイテム故障の振る舞いの結果によってドラ

および、ソフトウェアツール認定、ソフトウェアコンポー

イバまたは他の交通関係者が受ける傷害の重さの見積もネント（注6）認定、ハードウェアコンポーネント（注7）認定りである。危険事象のそれぞれに対し、表１にしたがっに関する要件を規定し、複数のプロセスに対して横断的てS0、S1、S2、S3の過酷度のクラスの１つを割り付ける。

に関与する。
Part ９はASILの取り扱いと技術的な分析手法の指針

この指標は、医学的なガイドラインなどをもって見積もられる。

を規定し、Part ８と同様、複数のプロセスに対して横断的に関与する。
Part10は規格の本編であるPart １〜９で記載困難ま
たは書ききれなかった特定項目の解説および事例を示し

表１
クラス

内容

S0

傷害なし

たガイドラインである。

過酷度のクラス
S1

S2

S3

軽度および中程度の障害

重度および生命を脅かす障害（生存の可能性がある。
）

生命を脅かす
傷害（生存がはっきりしない）

次章以降で、ISO26262の体系に則り、ハザード分析とリスクアセスメントから機能安全のソフトウェア開発

E：ハザードの発生頻度（probability of Exposure）に至る流れを概説する。

これは、想定される運転状況の期間、もしくは、ある（注４） ハードウェア部品の寿命中に確率分布に従い発生す
る、予期できない故障の発生確率。
（注５） 電気・電子ハードウェア、ソフトウェアやその他の技術によって、安全状態を確保するために障害を検出したり、故障を制御したり、または異常警告を発してリスクを回避したりする技術的解決策。
（注６） 一つまたは複数のソフトウェアユニット（ソフトウェ
ア関数）。
（注７） 一つまたは複数のハードウェアユニット（ハードウェ
ア部品）。

状況の発生頻度のどちらかの指標による見積もりである。危険事象のそれぞれに対し、表２にしたがってE0、E1、E2、E3、E4の発生頻度のクラスの１つを割り付ける。
この指標は、対象となる危険事象のシナリオ（危険事
象から事故に至るまでの流れ）に基づき、道路環境、天候、車両周辺状況、時間帯、運転操作などから判断される。
表２

5．ハザード分析とリスクアセスメント
ISO26262では、ハザードを「アイテムの機能不全の振る舞いにより引き起こされる危害になりうる原因」、ハザードの発生頻度のクラス

クラス

E0

E１

E2

E3

E4

内容

可能性
なし

可能性が
非常に低
い

可能性が
低い

可能性が
中程度

可能性が
高い

リ ス ク を「危 害 が 発 生 す る 確 率 と そ の 危 害 の 過酷度（Severity）との組み合わせ」と定義している。

C：回避可能性（Controllability）

安全は元から備わっているものではなく、目標を立て

これは、ドライバまたは他の潜在的リスクのある人て達成するものであり、規格はその目標の指標を示すもが、特定の危害を回避するために危険事象に対し十分にのである。ハザード分析とリスクアセスメントの目的

抑制することができる確率の見積もりである。危険事象

は、不合理なリスクを避けるために、アイテムの機能不のそれぞれに対し、表３にしたがってC0、C1、C2、C3

全（故障）が引き起こすハザードを特定および分離し、の発生頻度の１つを割り付ける。

危険事象の防止または緩和に関連した安全目標を立てる

表３

ことにある（2）。
ハザード分析では、状況分析とハザード識別を実施す
ることにより、危険事象につながる可能性のあるアイテ
ムに潜在する危険につながる振る舞いを識別する。ハザー
ド識別にはFMEA（Failure Mode and Effect Analysis）
やHAZOP（HAZards and OPerability study）といった手法が使われる。

31

回避可能性のクラス

クラス

C0

C1

C2

C3

内容

一般的に
回避可能

容易に
回避可能

通常は
回避可能

回避困難または回避不可

この指標は、ドライバあるいは他の被害を被る可能性

7.1

安全目標の設定のある交通参加者が、発生している危険事象を制御で

５章、６章で説明した、ISO26262を適用するアイテ

き、被害を回避することができる可能性の見積もり評価

ムに対するハザード（危険源）の分析とリスクアセスメ

である。

ントおよびASILの決定は、受入れ不可能なリスクを避こうして危険事象のそれぞれに割り付けたS、E、Cの各クラスから、表４にしたがってASILを決定する。
表４において、QM（Quality Management）は機能

け、アイテムの安全目標を決定するために実施する。安
全目標とは、特定の運転状態において、危険事象につながるハザードに対処するための機能的な要求である。

安全を適用しなくてもよい通常の品質管理である。安全

安全目標にはハザード分析で評価された各々の危険事

ライフサイクルを実施する組織はISO／TS16949（自動象と関連するハザードに対して決定したASILを割り付

車産業向け品質マネジメント規格）、ISO9001（品質マけ、IDを付加する。

ネジメント規格）または同等の規格に準拠した組織レベ
ルの品質管理が必要であるとされる。
表４
過酷度の
クラス

S1

S2

S3

7.2

安全目標に従うため、機能安全コンセプトにおいて、ASILの決定表

ハザードの発生
頻度のクラス

アイテムの機能安全要件を規定する。

回避可能性のクラス
C1

機能安全要件の設定（機能安全コンセプト）

C2

C3

機能安全コンセプトとは、安全目標の達成に必要な機

E1

QM

QM

QM

能安全要件を導き出し、それに基づいた要件をアイテム

E2

QM

QM

QM

の暫定的なアーキテクチャの構想、および外部方策（他

E3

QM

QM

ASIL A

E4

QM

ASIL A

ASIL Bのアイテムに対してリスクを軽減する解決策）に割り当

E1

QM

QM

QM

E2

QM

QM

ASIL A

機能安全要件とは、安全目標に基づくアイテムの安全

E3QM

ASIL A

ASIL Bな振る舞いの仕様および実装に依存しない安全方策（有E4ASIL A

ASIL B

ASIL C

E1QM

QM

ASIL A

E2

QM

ASIL A

ASIL B

E3

ASIL A

ASIL B

ASIL C

E4ASIL B

ASIL CASIL D

7．製品開発における機能安全要件の継承
本章では、アイテムの安全要件がどのように継承されるかを説明する。

てることである。

害な影響を軽減するためのアクティビティまたは解決策）である。
安全目標と機能安全要件の関係は図３に示すような階層構造となっている。
7.3

技術安全要件の設定（技術安全コンセプト）

機能安全要件をアイテムに組み込んで実現するためには、技術安全コンセプトによってアイテムレベルの機能

図２に安全要件の継承フローを示す。

安全要件をシステムレベルに必要な技術安全要件に詳細化しなければならない。

安全目標の設定

技術安全要件とは、機能安全要件を実装するためにシステムが備えるべき技術的な安全方策である。
技術安全コンセプトとは、技術安全要件をどのように機能安全要件の設定（機能安全コンセプト）

実現すべきかを示す仕様である。
機能安全要件の詳細化は、アイテムを構成する要素ご

技術安全要件の設定（技術安全コンセプト）

システム設計とに技術安全要件を仕様として策定することで行う。
7.4

システム設計システム設計では、技術安全要件を含んだシステム要
求仕様の実装方法を設計する。ここでは安全要件だけでハードウェア安全要件の設定と機能安全のハードウェア開発

図２

ソフトウェア安全要件の設定と機能安全のソフトウェア開発

安全要件の継承フローなく、非安全要件（表４のASIL決定表で QMと判定された要件）も考慮する。技術安全要件を実装するには、システム設計の検証可能性、機能安全を達成するための技術的能力、およびシステム統合中の試験実施可能性も考慮する必要がある。

MSS技報・Vol.23

32

ハザード分析とリスク
アセスメントの結果

安全目標１
ASIL x

安全目標２
ASIL x

安全目標 N
ASIL x機能安全要件 1
割り当てられた ASIL

機能安全要件２

サブシステムへの配置

割り当てられた ASIL

サブシステムへの配置

機能安全要件３
割り当てられた ASIL

図３

サブシステムへの配置

安全目標と機能安全要件の階層構造

技術安全要件を実装に必要な仕様にまとめたものがシステム仕様である。

7.6

ソフトウェア安全要件の仕様化

ソフトウェア安全要件は、故障によって技術安全要件

システム仕様の各要件はハードウェアとソフトウェアに分類し、更に詳細化する。また、ハードウェア・ソフ

の逸脱を引き起こす機能を対象とし、ソフトウェアの実装・検証が可能なレベルまで詳細化して定義する。

トウェアインターフェース（HSI）を設計し、技術安全

ソフトウェア安全要件の仕様化においては、指定されコンセプトと一貫性のとれたハードウェアとソフトウェたシステムとハードウェア構成、ハードウェア・ソフト

アの分担と相互作用を明確化する。

ウェアインターフェース、ハードウェア安全要件、時間

また、システム仕様については、技術安全コンセプト
に対する遵守と完全性を検証しなければならない。

的制約、アイテムから見た外部とのインターフェース（注9）、
ソフトウェアに影響する車両、システムまたはハードウェ
アの各動作モードを考慮する。

7.5

ハードウェア安全要件の設定と機能安全のハードウェア開発

ハードウェアの安全要件は、ハードウェアに割り当て

また、ソフトウェア安全要件の仕様は、技術安全コン
セプト、システム仕様、ハードウェア・ソフトウェアイ
ンターフェース仕様との適合性と一貫性を検証しなけれられた技術安全要件から得る。主に、ハードウェアの内ばならない。

部故障を制御する安全メカニズム（注８） 電気・電子ハードウェア、ソフトウェアやその他の技術によって、安全状態を確保するために障害を検出したり、故障を制御したり、または異常警告を発してリスクを回避したりする技術的解決策（注９） 例えばペダル操作のブレーキシステムというアイテ
ムと、その外部に位置づけられたABS（アンチロッ
ク・ブレーキシステム）とのインターフェースな
ど。

（注8）

の安全要件を保証する。
ISO26262が求めるハードウェア設計のポイントは、
ハードウェアアーキテクチャ指標の評価と偶発的ハード
ウェア故障による安全目標逸脱の評価を定量的に実施することである。
ハードウェアアーキテクチャ指標とは、ハードウェア

8．機能安全のソフトウェア開発の偶発的故障に対するハードウェアアーキテクチャの効
果（ロバスト性）を評価するための指標であり、規格が定める計算式で決まる定量的数値である。
偶発的ハードウェア故障による安全目標逸脱の評価と機能安全への対応によって、ソフトウェアの開発は従来の方法と比べて何が変わるのか。本章ではこの点について述べる。

は、確率論に基づく安全性の論理的な裏づけをもって安全メカニズムの有効性を評価することである。

8.1

ソフトウェア安全要件のトレーサビリティ

ISO26262では、各ハザードのリスク低減を安全目標として設定し、それらが確実に実装／試験されたかどう

33

かを開発工程全体にわたって追跡できるようにすること

ソフトウェアアーキテクチャレベルのエラー検出でを求めている。これを安全要件のトレーサビリティと呼は、ASIL Dにおいて、入出力データの範囲チェック、ぶ。トレーサビリティは要件にID番号を付けて識別する。

データ妥当性のチェック、外部モニタリング、制御フロー

ソフトウェア開発においては、ID番号を使って、ソ監視、ソフトウェア冗長設計が必須となる。

フトウェア安全要件仕様（ソフトウェア機能仕様に相ソフトウェアアーキテクチャレベルのエラー処理で当）の安全要件、ソフトウェアアーキテクチャ設計仕様

は、ASIL Dにおいて、エラー発生時の縮退機能、並列のソフトウェアコンポーネント、ソフトウェア単体設計の冗長性が必須となる。

仕様の関数を紐付けする（図４）。これによって安全要

ソフトウェア単体設計では、ASIL Dにおいて、関数件の関連が明示的となり、上位要件に対する下位要件のにおける１つの入口１つの出口、ヒープ領域など動的に抜け洩れや、関数の不具合が及ぼす要件への影響などを、確保されるオブジェクトの制限、変数初期化の実施、同検証や試験で効果的に発見して対処することができる。

一変数名の禁止、グローバル変数の使用制限、ポインタ

要件のトレーサビリティ管理には、ソフトウェア開発の使用制限、暗黙の型変換の禁止、隠れデータフロー／などで用いられる要件管理ツール

制御フローの禁止（注11）、無条件ジャンプの禁止、再帰呼を使用する。

（注10）（注10） 米IBM社の「Rational DOORS」や米PTC社の「MKS
Integrity」などがある。

び出しの禁止がある。
（各設計手法の詳細については、ソフトウェア設計技法
等の書籍を参照されたい。）

8.2

モデリング設計について、ISO26262では深く触れて

設計手法

ISO26262では、より高いASILが求められるソフトウェいない。自動車のモデリング設計（モデルベース開発）

アに対しては、より厳しい制約の設計手法が求められる。

では、MATLAB／Simlinkが代表的な手法とされるが、ソフトウェアアーキテクチャ設計では、ASIL Dの場

モデリング設計を行うことが、イコール、機能安全に寄合、ソフトウェアコンポーネントの階層化、ソフトウェ

与するわけではない。

アコンポーネントサイズの制限、適切なスケジューリン

モデリングに拠らないソフトウェア開発におけるコー

グ、ソフトウェアコンポーネントの結束性、結合制限、ドの品質と同様、モデリング設計においてもモデルの品

割込み制限が必須要件である。

質を高めることが、それによって作られる製品（アイテ

こうしたソフトウェア設計における各種の手法は、構ム）の安全性に寄与する。

造化設計手法などに出ている考え方で、特に目新しいも

ISO26262では、モデルを設計する際のガイドラインのではないが、ISO26262ではASILレベルに対応して、について、コーディングのガイドラインと組み合わせる

必須となる手法の適用を明示している。

かたちで、要件を定めている。

上位要件

下位要件
ソフトウェアアーキテクチャ
設計仕様

ソフトウェア安全
要件仕様
ソフトウェア
安全要件

ソフトウェアコンポーネント

ソフトウェア単体
設計仕様
関数
ID

ID
ID

ID

ID
ID
ID
ID

ID

ID
ID
ID

紐付け

（注11） 隠れデータフロー／制御フローの禁止とは、制御フローが複数の意味を持つことを禁止することである。設計者の認識していない制御が実装されることにより、問題が発生するリスクが増加する。例えば、次の例が隠された制御フローに該当する。
【例】設計者Aが関数Aの制御フローでグローバル変
数Xを１ずつ加算していき、Xが10になったと
き変数Yに１を代入するという設計を行ったとする。一方、別の設計者Bが関数Bで、本来なら依存関係がない関数Aの変数Xを、変数Zに１を代入するための判定条件として参照する制御フローを組むと、変数Xは設計者Aが認識していない隠れたフローに対しても影響を及ぼす。
即ち、この状況で設計者Aが変数Xに対して制御を変更すると、設計者に認識されることな
く関数Bに対して影響が及んでしまう。こうした影響を回避するため、隠れデータフロー／
制御フローは禁止されている。

ID

トレーサビリティ

図４

ソフトウェア安全要件の継承とトレーサビリティ

MSS技報・Vol.23

34

8.3

検

証

びコールカバレッジ（注18）の100％実施がASIL Dで求めら検証（verification）とは「要求に対して

正しく

成果物が作成されたこと」の確認であり、レビューなど
によって上位要件が抜け洩れなく下位要件に展開されているかという観点で実施する。
ISO26262では、ソフトウェアアーキテクチャ設計、
ソフトウェア単体設計と実装（コーディング）において、ASILレベルに応じた検証が規定されている。
ソフトウェアアーキテクチャ設計の検証では、ASIL Aの場合、ウォークスルーだけでよいが、ASIL Dでは、
インスペクション、動的箇所（実行可能モデル）に基づ
くシミュレーション、プロトタイピング、制御フロー／
データフロー解析（注12）を必須手法としている。
ソフトウェア単体設計と実装（コーディング）の検証
では、ASIL Aの場合、ウォークスルーだけでよいが、ASIL Dでは、インスペクション、準形式検証（モデルに基づくシミュレーションなどを用いた検証）
、制御フ

れている。
（注14） コードが実行可能か、ROM／RAM／レジスタなどのリソースがどの程度使用されているかを確認する試験である。
（注15） モデルベース開発によって作成された実行可能なモ
デルのシミュレーションと自動生成されたコードに同じ試験ケースを与え、その実行結果を比較し、確認を行う試験である。
（注16） すべてのコード中の条件や判定に対して、一度はコードを実行する。この際、判定の条件は判定の出力が独立するように試験を行う。条件の数をnとした時、全条件の組合せを試験するC2カバレッジ（複合条
件網羅率）の試験ケース数が２のｎ乗個となるのに対し、MC/DCのケース数はｎ＋１個で済む。即ち、条件が多くなるほどC2カバレッジよりコスト的に有利となる。
（注17） ソフトウェア全体の機能数と実行された機能の割合である。これにより、実行機能の網羅性を確認する
ことができる。
（注18） 全体の関数（または機能）と実行された関数（または機能）の割合である。これにより、呼び出された関数の網羅性を確認することができる。

ロー／データフロー解析（注13）、静的コード解析が必須手法となっている。

8.5（注12） ソフトウェアアーキテクチャ設計の検証に使用する
制御フロー／データフロー解析は、例えば、エラー
検出時にシステムがフェールセーフ状態へ遷移でき
ること、機能障害の場合、冗長機構が有効になることなどを確認する。この解析により、安全メカニズ
ムの制御フローが正しい順序で行われていることを検証することができる。
（注13） ソフトウェア単体設計と実装の検証に使用する制御
フロー／データフロー解析とは、制御の流れやデー
タの流れを確認することである。ソフトウェア単体
設計に基づいた制御フローやデータフローの実装が行われていることの解析を行う。

ソフトウェアツールの認定

ISO26262は、開発の使用目的として導入する各種のソフトウェアツール（以下、単にツールと表記）に対して信頼性評価指標を定め、その指標に適合すると認められるものが開発に使用できるとしている。
先ず、ツールが認定の対象になるかどうかの選別を行う。
それには、TI（Tool Impact）、TD（Tool error Detection）、
TCL（Tool Confidence Level）という指標を使用する。
TIとは、特定のツールが誤動作した場合に、開発中の安全関連のアイテムまたはエレメントにおいてエラーが取り込まれたりエラーの検出に失敗したりする可能性8.4である。TI1とTI2の２段階で評価する。TI1はツール誤

妥当性確認

妥当性確認（validation）とは「要求に対して
い正し

成果物が作成されたこと」の確認を行うことであり、試験によって要件を満足した成果物が作られている動作によるアイテムまたはエレメントへの影響が全くな
いと論証できる場合に選択する。TI2はそれ以外の場合（即ち何らかの影響がある場合）に選択する。
TDとは、ツールが誤動作して、対応する誤出力を生かという観点で実施する。
ASIL Dでは、ソフトウェア単体試験、ソフトウェア

じさせることを防止する手段、または、ツールが誤動作

統合試験とも、要件に基づく試験、インターフェース試

して、対応する誤出力を生じさせたことを検出する手段

験、不具合混入試験、リソース試験（注14）、バックトゥバッ

における信頼性である。TD1、TD2、TD3の３段階でク試験評価する。TD1は、誤動作とそれに対応する誤出力を防（注15）が必須となる。

試験ケースの導出方法では、要件分析、同値クラスの止または検出できる信頼性の度合いが高い場合に選択す

作成と分析、境界値分析が、ASIL Dの必須要件である。

る。TD2は、同様の信頼性の度合いが中程度の場合に選ソフトウェア単体試験の網羅率（カバレッジ）については、ASIL AがC0カバレッジ（命令網羅率）の100％実施でよいのに対し、ASIL DではC1カバレッジ（分岐択する。TD3は、それ以外の全ケースで選択する。
こうして求めたTIとTDに対して、表５に示すマトリックスでTCLを決定する。

網羅率）およびMC/DC（Modified Condition/Decision

TCL1と判定されたツールは認定しなくても使用できる。

Coverrage）

TCL2およびTCL3と判定されたツールは、次の４種（注16）の100％実施が求められている。

ソフトウェア統合試験では、機能カバレッジ

およ

（注17）

35

類の認定方法を適用する。

表５

TCLの決定表

るが、自動車用MPUにソフトウェアパーティショニン

TD1

TD2

TD3

グ 技 術 を 適 用 す る 場 合、 現 時 点 で は コ ス ト 面 か ら、

TI1

TCL1

TCL1

TCL1

MPUのメモリ保護ユニットを利用したOSによる方法が

TI2

TCL1

TCL2

TCL3

①使用実績による信頼性の向上

最も有望であるとされている。
8.7

プロセス改善

ツールにおいて規格が定める使用実績に関する証拠が組み込みソフトウェアの分野では、CMMI、Automotive

提供される場合に限り、使用実績による信頼度の向上が

SPICEといった各種プロセス改善規格への取り組みを継論証されるものとするなどの方法。

続的に実施することが求められる。

②ツール開発プロセスの評価
ツールの開発に適用される開発プロセスが、適切な規ISO26262においてもプロセス改善が求められているが、これは、基本的に既存のプロセス改善の延長線上に格に適合しているかを評価するなどの方法。

ある。CMMIのレベル２、Automotive SPICEのレベル③ツールの妥当性確認

３程度の認証がとれていればよいとされる。

規格が定める判定指標を満たす妥当性確認を行う方法。
④安全規格に従った開発

ISO26262ではPart ２機能安全の管理（図１）の中で、技術的観点から成果物を検証する確証レビュー、プロセ

ツールの開発が、例えばISO26262、IEC61508、RTCA

ス的観点から機能安全活動の実装状況を確認する機能安DO-178（航空システムや装置の安全規格）といった規

全監査、アイテムの安全性について機能安全の適合性を格に対応しているかを検証する方法。

評価する機能安全アセスメントの３点セットをまとめた

これらの認定方法の適用は、ツールで開発するアイテ
ムまたはエレメントのASILによって異なる。
TCL2の場合、ASIL A/B/Cでは①と②が、ASIL Dでは③と④が必須である。
TCL3の場合、ASIL A/Bでは①と②が、ASIL C/Dでは③と④が必須である。

確証方策に対して、ASILに対応した独立性をもって実施するよう規定している。
独立性は４段階が定義されており、最も軽いレベルは「確証方策を異なった人物で実施したほうがよい」という程度であるが、最も重いレベルは「異なった部署ある
いは組織の人物（即ち、第三者）によって実行されなけれ

なお、ツールをベンダーから購入する場合、ツールのばならない」となる。確証方策の内容にもよるが、ASIL

利用者が認定を行うのは現実的に困難である。そこで、レベルが高ければ、独立性も高いレベルが求められる。

ISO26262に適合した第三者認証済みのツールを導入す

なお、第三者の組織については、品質保証部といったることが現実的であると言える。

社内の独立した部門でもよいし、社外の第三者認証機関
でもよい。営業戦略上、名の通った第三者認証機関に監

8.6

保護機能による不具合の波及の防止

ISO26262では、特定のソフトウェアコンポーネントに不具合があった際、それが別のソフトウェアコンポー
ネントに悪影響を及ぼすのを防ぐための仕組みを「ソフトウェアパーティショニング」として規定する。この技査を依頼するサプライヤやツールベンダーが多い。代表的な第三者認証機関の１つに、ドイツ・TÜV SÜD（テュフ・ズード）社がある。
9．安全文化術はASILの異なる複数のソフトウェアコンポーネント

ISO26262では、組織として安全活動を保証する仕組を、同一のMPU上で共存させるような場合に利用できみの構築を求めており、そのためには、組織として安全る。例えば、ASIL AとASIL BとASIL Cのソフトウェ

な製品開発が継続できるプロセスインフラの構築が求めアがあったとする。これをパーティションなしで１個のられる。プロセスインフラの構築にあたっては、「人はMPUと１個のリソース（共有メモリ）で動作させる場

誰でも間違いをおかす可能性がある」という性悪説に立合、３つのソフトウェアは共に、最高ASILであるASIL

ち、仕組みの構築を考える必要がある。

Cを適用しなければならず、結果として必要以上に高い

そ こ で 登 場 す る 重 要 な 概 念 が「安 全 文 化（Safety

開発コストをかけなければならない。一方、リソースに

Culture）」であり、ISO26262は、組織（および個人）がパーティションがあれば、１つのMPUでも個々のソフ安全を重視する企業の風土を構築していくことである。

トウェアコンポーネントに最適なASILを適用することができ、無駄な開発コストを避けることができる。
ソフトウェアパーティショニング技術にはいろいろあ

安全文化とは、組織として安全に関してあるべき姿（目的に対して十分な効果があり、関係者が内容を十分に理解して合意が得られている状態）の規則やプロセス

MSS技報・Vol.23

36

が構築され、適切な教育や啓発活動によって個々の担当

11．分散開発（開発委託）の要件

者の中に「安全に関する共通の常識」として浸透させるべきものであり、これは一朝一夕にして定着できるもの

機能安全を適用するアイテムやエレメント（ソフトウェではない。そのため、ISO26262は、組織の標準プロセ

アを含む）を開発委託する場合、受託するサプライヤ

スを定義し、各プロジェクトの特性に合わせたテーラリ（ソフトウェア受託会社を含む）もISO26262が求める要

ング（標準プロセスの仕立て直し）を行う仕組みと、継件を満たさなければならない。

続的なプロセス改善活動を求めている。

開発を委託する前には、開発委託者とサプライヤとのISO26262はプロセ ス の 構 築 が 最 終 的 な 目 標 ではな

間で開発インターフェース合意書（DIA（Development

い。プロセスが組織の求める目標を達成することによっInterface Agreement））を取り交わす必要がある。DIAてプロセスの構築が意味を持つ。

には、開発委託者とサプライヤの双方のセーフティマネー
ジャ、安全ライフサイクルのテーラリング（注19）、開発委

10．ISO26262推進に必要な組織体制

託者とサプライヤそれぞれの活動とプロセス、双方で交ISO26262推進に必要とされる組織体制例を図５に示す。
これは、CMMIやAutomotive SPICEの体制にセーフ
ティマネジメントチームを加えた体制となっている。

換する情報や活動などが含まれる。
開発活動中のサプライヤは、進捗、リスクを増大する
課題、不具合を開発委託者へ報告しなければならない。

この体制は、規格の中で直接要求されていることではサプライヤによって満たすことのできない安全要件があないが、ISO26262対応を推進していくためには、推進る場合は、安全コンセプトを再検討し、安全要件を見直体制の構築が不可欠である。

す必要がある。

CMMIやAutomotive SPICEによるプロセス改善でアイテムの安全性に影響を与える可能性のある変更

は、ソフトウェア改善推進組織となるSEPG（Software

は、影響分析を行うために開発委託者とサプライヤが互Engineering Process Group）を置く。ソフトウェア開いに通知しあう必要性がある。そして、安全の妥当性確

発のプロセスに限定することなく、プロセス改善を推進

認を開発受託者が行うのか、サプライヤが行うのかを決する組織をEPG（Engineering Process Group）とも呼

めておかなければならない。

ぶ。このEPGがISO26262の推進役として果たす役割は、（注19） ISO26262が示す安全ライフサイクルとは、製品のコンセプトから開発、生産、運用、廃棄に至る製品
ライフサイクル全体を通じた安全管理のライフサイ
クルである。
安全ライフサイクルのテーラリングとは、ISO26262
で定められた安全ライフサイクルを組織の特性に合わせて仕立てなおす行為である。組織によっては各フェーズの活動を統合したり、分割したり、反復したり、または別のフェーズで実施したりする。

機能安全に関する活動を含めた開発活動全体に対し、適切な組織標準プロセスを構築し、それを実施する各担当者に必要な教育をおこなうことである。また、さらに組
織標準プロセスを維持するために、必要なデータや情報を収集してプロセスを改善することである。

品証部門長

開発部門長

（注）

QA（品質保証）チーム

セーフティ
マネジメントチーム

専任 QA

セーフティマネージャ

ASIL D 対応では，開発部 門 か ら 独 立 し た QAが必須。
QA の役割：・ソフトウェア
プロセス監査・ソフトウェア安全
設計のアセスメント

SEPG ／ EPG

開発チーム

専任
SEPG ／ EPG
対象プロジェクト A

システム担当ハードウェア担当

対象プロジェクト B
兼任者が参画兼任者が参画
対象プロジェクト C

ソフトウェア担当（注）小さな部門やプロジェクトでは、セーフティマネジメントチームを
開発チームの中に含めてもよい。

図５

37

（3）
ISO26262推進に必要な組織体制（例）その他、ISO26262では分散開発に関するいくつかの参考文献

要件を定めている。
12．むすび⑴ 「クルマの電子安全始まる

ISO26262を超えて」日経エレクトロニクス2011.1.10号

ISO26262は2011年11月に制定されたが、特に欧州や⑵ 「ISO26262におけるハザード分析およびリスクアセ

米国などの海外自動車メーカ各社は、早くから機能安全スメント」自動車技術，Vol.66，No.9（2012）に取り組んできたこともあって、ISO26262の要件に対⑶ 「ISO26262実践ガイドブック［入門編］」日経BP社，応した成果物やプロセスをサプライヤへ要求している。

第１版１刷

また、国内の自動車メーカ各社もISO26262に基づく安全要件を求めつつある。そうした状況の中で自動車メー
カに部品を納入しているサプライヤの中には、ISO26262の要件を満たすため、いち早く体制を整え、規則を整備
し、規格に基づくプロセスを構築して第三者機関による認証を取得したところもある。
当社も、安全にかかわる車載機器の制御ソフトウェア
開発の請負業務を担当する部門において、今後、ISO26262
対応の整備が必要になるものと思われる。

MSS技報・Vol.23

38