1. まえがき
自動車関連機器のハードウエアにおいて安全要求 を満たすためには，機能安全設計プロセスに従って開 発・設計を進める必要がある。当社ではソフトウエア 部門が先行して，機能安全設計プロセスの構築を行っ てきたが，ハードウエアについても規格の調査を通じ てプロセス構築に向けた課題・対応方針を検討してお り，その取り組みと今後の展望について報告する。
2. 機能安全規格ISO26262の概要 2. 1 ISO26262の状況
ISO26262は，欧州が中心となった取り組みにより 2011年11月に第1版が発行された。国内では，欧州に 顧客を持つ一部のサプライヤーが，2014年に量産開始 する車載システムの開発にISO26262の適用を開始し た。現在の車載機器開発においては，ISO26262に準 拠した開発が主流となっている。
2. 2 規格の全体構成とハードウエアの位置 付け
ISO26262は表1に示す10項のパートから構成される。
表1．ISO26262の構成
Part Title
Part 1 用語集 Part 2 機能安全の管理 Part 3 コンセプトフェーズ
Part 4 システムレベルにおける製品開発 Part 5 ハードウエアにおける製品開発 Part 6 ソフトウエアにおける製品開発 Part 7 生産および運用
Part 8 支援プロセス
Part 9 自動車用安全度水準（ASIL）指向及び安全指向の分析 Part 10 ISO26262ガイドライン
※ISO26262-5：2011 AnnexB FigureB. 1より引用
ISO26262は，これらのパートに分類されているた めに，自動車メーカーや車載機器メーカー，部品メー カーなど，各企業の役割に応じて適用すべきパートが 明確になっている。ハードウエアを開発する場合は，
上記Part 5（ハードウエアにおける製品開発）に従って 開発を進める。Part 5は表2に示すサブパートで構成
表2．ISO26262 Part5の構成
Part Title
PartX-1 適用範囲 PartX-2 引用規格 PartX-3 用語，定義，略語 PartX-4 準拠の用件
Part5-5 ハードウエアレベルの製品開発開始 Part5-6 ハードウエア安全要求の仕様 Part5-7 ハードウエア設計
Part5-8 ハードウエアアーキテクチャーメトリックの評価 Part5-9 ランダムハードウエア故障メソッド１，メソッド２ Part5-10 ハードウエア統合テスト
※PartX：Part2～ 9共通
ハードウエア開発における機能安全プロセスに関し ては4章にて説明する。
2. 3 ASILと故障分類
ここで，ISO26262で基本にして重要な特徴である ASIL（安全性要求レベル）と故障分類について説明 する。
（1） ASIL （Automotive Safety Integrity Level）
ASILは，車載電子システムで起こり得るさまざ まな潜在危険（ハザード）を避けるために達成し なければならない安全性のレベルをA～Dの4段 階で示すものであり，Aが一番低く，Dが一番高 いレベルを表す（ASIL Dが一番高い安全性を求 められる）。ASILの決定は，以下に示すS，E，
Cの3つの指標から該当するクラスを割り当て，
表3のASIL決定表から決定する。
① S：重大度（Severity）
以下のようにハザードによって受ける傷害の重 さをS0～S3の4クラスで表す。
クラス S0 S1 S2 S3
内容
障害無し 軽度及び中
程度の障害 重度及び生命 を脅かす障害
（生 存 可 能 性 有り）
重度及び生命 を脅かす障害
（生存不明）
② E：曝露可能性（Probability Exposure）
以下のように発生頻度をE0～E4の5クラスで表す。
クラス E0 E1 E2 E3 E4
内容 可能性無
し 可能性が
非常に低 可能性が
低い 可能性が
中程度 可能性が 高い
車載機器のハードウエア設計向け
機能安全設計プロセスの調査
山辺 祐治，岩本 慎司，谷田 学靖
③ C：回避可能性（Controllability）
以下のようにハザードが発生したときの回避可 能性をC0～C3の4クラスで表す。
クラス C0 C1 C2 C3
内容 一般的に回
避可能 容易に回避
可能 通常は回避
可能 回避困難又
は回避不可
表3．ASIL決定表 重大度（S）
クラス 曝露可能性
（E） 回避可能性（C） クラス
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
※表中のQM（Quality Management）は，機能安全適 用不要の通常の品質管理。
ASILのレベルが高いほど，機能安全を担保する方 策の実現難易度も高くなるため，安全要求を冗長化 することでASILを減免（ASILデコンポジション）する ことができる。条件として，冗長化により分担したエ レメント間で独立性が確立されていることが必要に なる。表4に分担ルールを示す。QM（X）との分担は ASIL品質の範囲を限定することが可能である。
表4．ASILデコンポジション 決定表から定義されたASIL デコンポジション後
ASIL D
ASIL C（D）＋ASIL A（D）
ASIL B（D）＋ASIL B（D）
ASIL D（D）＋QM（D）
ASIL C ASIL C（C）＋QM（C）
ASIL B（C）＋ASIL A（C）
ASIL B ASIL B（B）＋QM（B）
ASIL A（B）＋ASIL A（B）
ASIL A ASIL A（A）＋QM（A）
※表中の（X）はデコンポジション前のASILである。
（2）故障分類
図1．ハードウエアエレメントの故障モード
ハードウエアエレメントの故障モードを図1に示す。
各フォールトの内容は以下のとおりである。
① SPF（Single Point Fault）
SM（Safety Mechanism，安全機構）では保証さ れない障害（フォールト）。単一の発生で直接的 にSG（Safety Goal，安全目標）を逸脱するもの。
② RF（Residual Fault）
SMでは保証されないフォールトの一部。SPFの 残り。
③ MPF（Multiple Point Fault）
複数の独立したフォールトの組合せによってSG を逸脱するもの。
④ LMPF（Latent MPF）
SMや運転手によって検出・検知できないMPF。
⑤ PMPF（Perceived MPF）
運転手によって推測（検知）可能なMPF。
⑥ DMPF（Detected MPF）
SMによって検出可能なMPF。
なお，ハードウエアアーキテクチャーメトリックの 評価として，ASILに対応したSPFM（SPF Metric）と LFM（Latent Fault Metric）の目標値が決められてお り，それを表5に示す。また，SPFMとLFMの計算式 を以下に示す。
※各故障率λについては，図1参照のこと。
SPFM＝1－∑（λSPF＋λRF）/∑λ
LFM ＝1－∑（λLMPF）/∑（λ－λSPF－λRF）
表5．SPFMとLFMの目標値
SPFM目標値 LFM目標値
ASIL D ≧99％ ≧90％
ASIL C ≧97％ ≧80％
ASIL B ≧90％ ≧60％
3. システムレベルの要求分析概要
Part5のハードウエアレベルの機能安全の設計を行 うにあたっては，まずはPart4において以下のシステ ムレベルの機能安全設計が必要である。ハードウエア レベルの機能安全の設計に至るまでの概要は，以下 である。
図2．機能ブロック図
図3．安全機構の導出イメージ
（1） FSR：Functional Safety Requirement
車の安全な機能を実現するために，機能安全要 求（FSR）を作成する（図2）。
（2） TSR：Technical Safety Requirement
FSRを基に電子制御ユニットに対して，システ ムレベルで技術的な要求分析を行い，技術安全 要求（TSR）を作成する。
（3） TSC：Technical Safety Concept
TSRを基に 安 全 分 析を行 い，SPF・LF（Latent Fault）を改善するため，安全機構を追加し技術安 全コンセプト（TSC：Technical Safety Concept）
を作成する。コンセプトの実現方策をハードウエ ア，ソフトウエアに割り当てる（図3）。
自動車メーカーからのFSRに対して自動車部品メー カーがシステムレベルの要求分析を行う。分析結果か ら安全方策がハードウエア・ソフトウエアに割り当て られる。割り当てられたハードウエア要求の開発を行
4. 機能安全規格のハードウエアの製品開発 4.1 プロセスのギャップ分析
図4．ハードウエア設計プロセスの比較
機能安全非対象である当社のハードウエア開発フ ローとISO26262 Part5ハードウエアレベル開発フロー を図4に示す。ISO26262を適用した機器を開発するた めには，開発フローに，機能安全設計に対応した設計 プロセスを追加する必要がある。以下，ハードウエア の機能安全設計に必要な設計プロセスについて説明 する。
当社の現行ハードウエア開発は，ISO9001の品質マ ネージメントシステムに則って，不良品0化に向けた 仕組み，体制，プロセスで行なっており（不良品が仮 に発生した場合は，速やかな処置，原因追究，改善を 行い，不良を減らすための改善活動を含む），不良品 を出さないことを主眼においた設計となっている。
それに対しISO26262では，「ものは壊れる」を前提 に，壊れても安全を侵害しない，人に危害を与えない ための設計を目的としている（偶発的な故障が発生し ても，安全な製品を開発することが目的である）。
当社の機能安全非対象ハードウエア開発フローで は，図4の比較図で分かるように，ISO26262における 以下のプロセスが無い。
① Part5-5
当社の品質計画時に安全計画を作成するプロセス。
② Part5-6
要求分析時にハードウエア安全要求を作成する プロセス。
③ Part5-8
ハードウエアアーキテクチャーメトリックを評 価するプロセス。
④ Part5-9
を評価するプロセス。
したがって，今後当社の開発業務でISO26262適用
（機能安全対象）になったものについては，現行の品 質マネージメントシステムによる高信頼性設計に，上 記①～④のプロセスを追加する必要がある。4.1.1項以 降でこれら追加プロセスの概要について述べる。
4. 1. 1 ハードウエアの製品開発の開始
通常の開発計画とは別に機能安全の開発を行って いくための計画（システムレベルの安全計画にハード ウエアレベルの計画をリファイン）を行う必要がある。
4. 1. 2 ハードウエア安全要求の仕様
3章で導出されたTSCをインプットにハードウエア の機能安全を実現するための要求＝ハードウエア安全 要 求（HSR：Hardware Safety Requirement）を 作 成 すること，及びハードウエア－ソフトウエアインター フェー ス（HSI： Hardware-Software Interface）を 作 成するプロセスである。
4. 1. 3 ハードウエアアーキテクチャーメ トリックの評価
シングルポイントフォールト（SPF：Single Point Fault），
潜在障害（LF：Latent Fault）のリスクを明確にし，ア イテムの安全性を客観的に評価するプロセスである。
4. 1. 4 ランダムハードウエア故障による SG侵害の評価
安全目標（SG：Safety Goal）を侵害する可能性を評 価するために，ランダムハードウエア故障が目標値以 内であるかを評価するプロセスである。
4. 2 機能安全要求の分析とメトリック評価
安全分析は，製品に潜む危険の抽出や故障したと きに発生する可能性のある危険事象（ハザード）を抽 出して，それらへの対策を施すためのものである。
ここではハードウエア安全分析報告書を作成する プロセスとして，安全方策を検証する安全分析手法 であるFTA（Fault Tree Analysis），FMEA（Failure Mode and Effect Analysis），HAZOP（Hazard and Operability Study）を使用している。
今回，安全分析手法と評価の習得として，車載電 子システムをモデルケースとして安全分析とメトリッ ク評価を実施したので報告する。
4. 2. 1 分析概要
安全分析例のシステム概要・要求を下記（1）～（3）に 示す。この例のハードウエア（以下，HWという）にお ける安全分析を4.2.2項で示す。
（1） システム概要
入力： 温度センサーを用いてバルブ内の温度を 測定し，その情報をマイコンが受け取る。
制御： バルブ内の温度が危険値に達していない かの判定を行う。
出力： 既定の温度を超えた場合，バルブを開く 制御信号を送る。
（2） 機能の要求
（1） の内容からHSRを導出するまでの概要を①
～⑦に示す。
① 安全目標を設定する
SG： 温度が100℃を超えた場合，バルブがXms より長い時間クローズ状態にならないこと。
安全状態：バルブがオープンであること。
FTTI（Fault Tolerant Time Interval）：Xms
② 機能安全要求を設定する
FSR ： 温度検出し，温度が90℃を超えたときに バルブを開くこと。
③ システムの技術安全要求を設定する
FSRを満たすためのシステムにおけるTSRを設 定する。
TSR-1： 温度センサーが90℃以上あることを検出 する。
TSR-2： 温度センサーの検出値を判定し90℃を超 えた場合，バルブ開指示を実行する。
TSR-3：バルブ開制御を行う。
TSR-4：バルブ開閉制御の故障検知を行う。
④ TSR-1の要求を割り当てる（HW）
HSR-1： 温度センサーを用いてバルブの温度を測 定し，温度判定部（マイコンのソフトウ エア（以下，SWという）で実現）に送る。
⑤ TSR-2の要求を割り当てる（SW）
SSR-2： 温度測定の結果が90℃を超えているか判 定する。90℃を超えたときバルブを開く 指示を出力する。
⑥ TSR-3の要求を割り当てる（HW）
HSR-3：指示に従い，バルブの開閉を行う。
⑦ TSR-4の要求を割り当てる（HW及びSW）
HSR-4： バルブの故障を検知するため，バルブ入 力部の電圧測定値を故障検知部（マイコ
ンSWで実現）に送る。
SSR-4： バルブの故障であるかを電圧値から判定 する。
（3） ハードウエア機能ブロック図
ハードウエア機能ブロック図の抜粋を図5に示す。
図5．ハードウエア機能ブロック図
4. 2. 2 安全分析
（1） HAZOP （Hazard and Operability Study）
HAZOPは，対象となる機能の期待される振る 舞いに対し，ガイドワードと呼ばれる設計意 図から逸脱した事象を想定して原因と影響を抽 出する解析手法である。HAZOPのガイドワー ドを表6に示す。分析結果の一部を表7に示す。
表6．HAZOPガイドワード
ガイドワード 意味
無 No/None 全く起こらない 多/大 More 最大値を超える 少/小 Less 最小値を下回る
逆 Reverse 反したことが起こる 類 As Well As 余分なことが起こる 部 Part Of 一部のみ達成
他 Other than 全く達成されず，異なることが起こる その他ガイドワードで表されない事象 に適用
早 Sooner Than 意図より早く実行される 遅 Later Than 意図より遅く実行される 長 Longer Than 意図より長く実行される 短 Shorter Than 意図より短く実行される
表7．HAZOP分析結果 ブロック・
I/F名 ブロック・
I/F概要 分類 HAZOP
ガイドワード 故障モード 想定される 故障モードの
発生要因
システムへの
影響 対策 SG 侵害の 可能性 温度セン
サー 温度に応じ た電圧を出 力
SG1 NO, NOT,
NONE － － － － －
MORE 設計値より 高い抵抗値温度センサー
異常
温度センサーから の入力情報（抵抗 値）が90℃に達し てバルブは開制御 されるが，実温度 は90℃を下回っ ているためSGを 侵害しない
－ ×
LESS 設計値より 低い抵抗値温度センサー
異常
温度センサーか らの入力情報（抵 抗値）が90℃に 達してバルブは 開制御されるが，
実 温 度 は 既 に 90℃を超えてい るためSGを侵害 する
温度測定 自 己診断の追加
（電圧範囲内 か確認）
○
REVERCE － － － － －
PART OF － － － － －
AS WELL AS － － － － －
OTHER THAN － － － － －
SOONER THAN － － － － －
LATER THAN － － － － －
LONGER THAN － － － － －
SHORTER THAN － － － － －
ここでは，ガイドワードのMOREを基に，温度セン サーの抵抗値が設計値より高くなる故障モードを想定 した時，システムの影響としては実際の温度超過より 早くにバルブが開くためSGを侵害しないという結論 になる。
それに対し，ガイドワードのLESSでは，温度セン サーの抵抗値が設計値より低くなる故障モードを想定 した時，原因は同様に温度センサーの異常と推定され るが，システムの影響としては実際の温度超過より遅 くにバルブが開くため，これは安全機能の実行が遅れ る（必要な時に安全機能が働いていない）ということ であり，SGを侵害するという結論になる。したがっ て安全対策が必要となり，ここでは温度測定の自己診 断回路が必要となる。
（2） FTA （Fault Tree Analysis）
FTAは，フォールトとなる事例を基に，その フォールトが発生する要因を，フォールトツ リーを用いて抽出するトップダウンの解析手法 である。FTAの一部を図6に示す。
図6．FTA分析結果
ここでは，SGに反するハザードとして温度が100℃
を超えた時にバルブがXmsより長い時間クローズ状態 になる，という状態を最上位として解析を行っている。
故障モードとして以下の①～③があり，それぞれに 対し故障を検知するSMを設けることで，安全を確保 するようにしている。
①バルブ開制御部の入力値異常
②温度90℃判定部のタイマー異常
③ 温度測定部のA/D変換値異常／温度センサー部の 異常
（3） FMEA （Failure Mode and Effect Analysis）
FMEAは，システムを構成する全ての要素を対 象とし，システム上考えられる故障と影響を抽 出するボトムアップの解析手法である。FMEA の一部を表8に，評価項目の点数を表9に示す。
表8．FMEA分析結果 システムブロック
故障モード SG 可能性侵害
評価
ブロック名 機能 影響 安全方策
度 発生 度 検出
度 重要 度
センサー温度 温度に応じた 電圧を出力
設計値より
高い抵抗値 × 4 2 3 24 －
設計値より
低い抵抗値 ○ 5 2 3 30
温度測定 自 己診断の追 加（電圧範 囲内か確認）
温度測定温度に応じた A/D 変換電圧を
設計値より 高い電圧値
に変換 × 4 2 3 24 －
設計値より 低い電圧値
に変換 ○ 5 2 3 30
温度測定 自 己診断の追 加（電圧範 囲内か確認）
表9．評価点数
■影響度
5：即時にSGを侵害 4： SG侵害の可能性小
（安全機構の故障）
3： SG侵害の可能性小
（3つ以上の同時故障）
2： SG侵害の可能性無
（一部機能無）
1：影響無
■発生頻度 5： 頻発
（1回/Lot）
4： 稀発生
（1回/週）
3： 稀発生
（1回/月）
2： 稀発生
（1回/年）
1：無
■検出度 5：検出不可能 4：検出困難大 3：検出困難小 2：検出容易 1：検出可能100%
FMEAはFTAと異なり，全ての構成要素に対し故 障モードを抽出する作業から入る。そして故障モード それぞれに対し，影響度，発生度，検出度について 重み付けの点数付けを行い，危険度合いを定量的に 表して安全目標への侵害の恐れがあるものを導出し，
各々に対して安全機能を検討している。
4. 2. 3 HWアーキテクチャーメトリックの 評価
HWアーキテクチャーメトリックの評価とは「HWの 偶発故障（ランダムHW故障）」に対する「HWアーキテ クチャーの効果（ロバスト性）」の指標（表5に示す）に 対する評価である。図7にランダムHW故障の定量評 価結果を示す。
2.3（2）で示した計算式でSPFM，LFMを求め，こ れらがASILに応じた目標値を達成する必要がある。
図の上部に記載のメトリック評価欄に示すように，
SPFMはASIL Cの90%以上に対し91.2%，LFMは60%
以上に対し89.1%で判定はpassである。
5. HW設計ガイドラインの策定
ISO26262規格の各Partは，設計からテストへとV字 プロセスに沿っており，大きな流れとしては理解しや すいが，Part内で実施すべき作業が分かり難いものと なっている。
今回の取り組みで，Part5における開発フロー及び 各作業のガイドラインをできるだけ分かりやすく示す ため，実例と注意すべきポイントについて整理した。
また，開発を進める上で押えておかないといけない INPUT（前提条件）とOUTPUT（成果物）の関係が一 目で分かるように，マトリックス図へ整理した。
開発フロー，ガイドライン，INPUT-OUTPUT対応 マトリックスを図8～ 10に示す。図10のマトリックス の左側に示す項目がINPUT情報，上側に示す項目が
すべきOUTPUTを丸印で示している。また，黒丸が ISO26262プロセス対応，白丸が当社でのHW開発プロ セス対応になっている。
図7．ランダムHW故障の定量評価結果
図8．機能安全対象機種のHW開発フロー
図9．機能安全対象機種のHW開発ガイドライン
図10．INPUT-OUTPUT対応マトリックス
今後は，本ガイドラインのブラッシュアップを進め ながら，実作業レベルへブレークダウンして行く予定 である。
岩
いわもと本 慎
し ん じ司
1987年入社。
カーエレクトロニクスに関するハードウエア開発に従事。
現在，第4事業部LSI応用技術部技術第2課に所属。
谷
た に だ田 学
のりやす靖
1999年入社。
カーエレクトロニクスに関するシステム開発に従事。
執 筆 者 紹 介 山
や ま べ辺 祐
ゆ う じ治
1987年入社。
カーエレクトロニクスに関するハードウエア開発に従事。
現在，第4事業部LSI応用技術部技術第2課に所属。
6. むすび
ISO26262は車載電子システムの機能的な安全性を 担保するための国際標準であり，安全設計項目は自動 車メーカーや自動車部品メーカーのシステム開発の段 階で決定／実行されている。一方，当社においては過 去のカーナビゲーションシステム開発は機能安全設計 が要求されていないハードウエア開発業務が主だった ため，機能安全設計プロセスへの取り組みを現在進 めているところである。
今後の課題は，ハードウエア設計ガイドラインの 完成度を上げることであり，実践から得られるノウ ハウを活用するとともに，2018年12月に発行された ISO26262 第2版への対応を行う予定である。
謝 辞
技報執筆にあたり，ご指導賜った三菱電機（株）生 産システム本部 設計システム技術センターの皆様に，
深く感謝の意を表する。
