機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例

一般論文

機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例
三田事業所

1. まえがき

技術第２部 技術第１課
西川 綾、前田 頼正

最初に機能安全コンセプトを検討し、機能安全要求（FSR:Functional Safety Requirement）
を定義する。

近年、自動車業界においては高機能化の要求が求められており、マイコンに搭載するソフトウェアは年々大規模化している。
それに伴い複雑になったソフトウェアの品質が製品の安全性に大きく影響を及ぼすようになっている。
このような背景から自動車業界における電気/電子（E/E）
システ
ムの安 全 性に関する国 際 規 格として機 能 安 全 規 格
ISO26262が発行された。
当所でソフトウェア開発を行っている車載充電器（OBC:
On Board Charger）
は、電気自動車（EV）やプラグインハ
イブリットカー（PHEV）の駆動用高圧バッテリを充電する装置である。EV/PHEVの充電時に充電機能が故障した
場合、発煙・発火などを伴う危険事象が発生する可能性がある。
そのため、OBCにISO26262への対応要求があり、ISO26262に対応したソフトウェア開発を行っている。
ISO26262では、製品に要求される安全レベルに応じて、

図1. 開発フロープロダクトが備えるべき機能や、プロセスにおいて実施すべ

次 に F S R の 実 現 方 法を検 討し、技 術 安 全 要 求

き内容が定義されており、これらに基づいて開発を実施す（TSR:Technical Safety Requirement）として仕様化する。

る。特徴的な要求事項としてソフトウェアアーキテクチャ設

ソフトウェアレベルにおける開発では、ソフトウェアに割り計でのソフトウェア安全分析及びソフトウェア従属故障分付けられたT S Rを詳 細 化し、ソフトウェア安 全 要 求析がある。本稿では、
ソフトウェアアーキテクチャ設計とソフ（SSR:Software Safety Requirement）を定義する。以降

トウェア安全分析の事例を紹介する。

は通常の開発と同様に、ソフトウェアアーキテクチャ設計、ソフトウェアユニット設計と実装を行う流れとなる。SGから

2. ISO26262概要
機能安全とは「E/Eシステムの機能不全のふるまいにより引き起こされるハザード（危険）が原因となる不合理なリスクの不在」と定義されている。
これはE/Eシステムに故障が発生しても、安全機構（SM:Safety Machanism）を設けることでハザードを許容可能なレベルまで低減することを指す。
図1に従ってISO26262の開発フローを説明する。最上位の要求として安全目標（SG:Safety Goal）と、その安全性要求レベル（ASIL：Automotive Safety IntegrityLevel）が定義される。
システムレベルにおける開発では、78

SSRまでの仕様例を表1に示す。
表1. 仕様例

機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例

ソフトウェアの機能不全によりSSRの要求を満たせなくな

表2. SSR例

ると、ハザードに繋がる可能性がある。予めソフトウェア安全分析を行うことで危険事象を抽出し、対策を施すことが要求される。
ソフトウェア安全分析によりSGの侵害に繋がる危険事象が見つかった場合は、対策として追加でSMを盛り込み、改めて分析を行う必要がある。

3. ソフトウェアアーキテクチャ設計
今回開発したソフトウェアにおける設計事例を説明する。開発の目的は、充電機能に関連する開発済みのソフトウェアにSMを追加し、ISO26262に準拠させることである。
SGとFSRは車両メーカで検討され、TSRへの展開は三菱電機（株）の担当である。本稿では、これらの説明は割愛
し、当社が担当したSSRに対するアーキテクチャ設計とソフトウェア安全分析について説明する。
設計方針として、安全が要求される機能と要求されない機能で、関数の集合であるコンポーネント（SWC）を分け、

図2. SSR配置例

既存機能に対して極力変更を行わないこととした。
最初にSSRのインプットであるTSRを、ASILによって分CPUに配置されている既存機能は、安全に関連するコ類した。ASILは一般的な品質管理で許容されるレベルンポーネントと、そうでないコンポーネントが混在していた。各（QM）と、安全機構が必要になるレベル（QM以外）に分コンポーネントの機能を分析し、ASILがQMとなるSSRのみ類される。QMの場合はISO26262を適用した開発が不要を割り当てた。
これによって、CPUに配置する既存機能のコなため、既存のコンポーネントに割り当てた。QM以外の場ンポーネントについては、独立性の確保が不要となるアー

合は、ISO26262を適用した開発が必要なため、新規に作キテクチャ設計とした。各コアに対するコンポーネントの配成するコンポーネントに割り当てた。

置結果を図3に示す。

ソフトウェアにQMとQM以外のコンポーネントが混在する場合、ISO26262では、両者の間に独立性の確保が要求される。
このような構成を実現するため、独立性に関する要求を追加して、TSRからSSRを定義した。
OBCは、ISO26262に対応するために、CPUコアを二つ搭載したマイコンを採用している。既存機能はメインコアであるCPUに配置されているため、新規に作成する安全関連機能はサブコアであるPCU（Peripheral ControlUnit）に配置することで、パーティショニングを実施した。以
上を踏まえて定義したSSRを表2に、各コアへの配置結果を図2に示す。
図3. 各コアのコンポーネント配置

79

機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例

PCUとCPUに配置したSSR間の独立性を確保するため、以下に示すアーキテクチャとした。
・CPUとPCU間のデータ授受はGlobal RAMを介してのみ行う。
・CPUからPCUに伝えるデータと、PCUからCPUに伝えるデータを異なる領域に配置する。
・各領域に対して、各コアはデータの書き込み又は読み込みの一方向のアクセスのみ行う。
・マイコンのメモリプロテクションユニットを使用して、各コ
アからの許可されていない領域に対する書き込みを防止し、メモリアクセスの独立性を担保する。
Global RAMを介したコア間のデータフローを含む、
コンポーネント図を図4に示す。

図5. ソフトウェア安全分析手順

4.2 ソフトウェア安全分析事例
ISO26262では、安全分析手法として定性的FMEA、定性的FTA、HAZOP、定性的ETAが示されている。
シ
ステムやハードウェアは定量的分析手法が適用可能であるが、ソフトウェアは定量的な分析が難しいため、定性的分析手法を用いる。
今回の開発では、HAZOPのガイドワードを用いて、ソフトウェアFMEAを実施した。
HAZOP（Hazard and Operability Study）
は、分析対象に対し、予め決められたガイドワードを用いて、ハザー
図4. コア間のデータ授受ド及び後工程への影響や検出可能性について分析する手法である。HAZOPのガイドワード例を表3に示す。

4. ソフトウェア安全分析

表3. HAZOPガイドワード

4.1 ソフトウェア安全分析とはソフトウェアの機能不全により、SSRの要求を満たせない場合は、システムがハザードに繋がる可能性がある。事前に各コンポーネントについて、SGの侵害に繋がる危険事象を特定し、ソフトウェアアーキテクチャ設計の妥当性やSMに漏れがないことを検証する。
ソフトウェア安全分析の手順を図5に示す。
ソフトウェア安全分析及びソフトウェア従属故障分析を行った結果、対策が必要となった場合は新たなSMを追加し、ソフトウェアアーキテクチャを見直す。追加の対策が不要になるまで分析を繰り返し実施する。
HAZOPのガイドワードを用いたソフトウェアFMEAの事
例を表4に示す。

80

機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例

表4. ソフトウェアFMEA事例

ソフトウェアFMEAは、以下の（1）～（5）の手順で分析

ところ、コンポーネントの機能不全がSGの侵害に結び付くを実施した。

故障モードがあるものの、他のSSRで対策済みであり、ソフ（1）分析対象の抽出トウェアに新たなSMを設ける必要はないとの結果になっ分析対象となる信号の抽出を行う。本事例では、入出た。
これは、システムレベルの開発において、SG侵害となる力信号を対象とした。

故障モードに対して、予めSMを設けているためである。

（2）故障モードの検討

ISO26262では、ソフトウェア安全分析でSMの追加が必要

HAZOPガイドワードに従って、抽出した各信号がどのよとなった場合は、SSRに仕様化することが求められている。

うな故障モードとなるか検討する。

今回の事例では、本来導出されるべきSMとそのSSRを明（3）SG侵害の影響シナリオの検討確にするため、手順（4）を追加してソフトウェア安全分析を検討した故障モードから、各SGを侵害する影響シナリオ実施した。

を分析して整理する。
（4）盛り込み済みの対策仕様の抽出
侵害有となった影響シナリオに対して、既に対策が盛り4.3 ソフトウェア従属故障分析
CPUとPCUに配置した安全関連コンポーネント間の込まれている場合は、該当するSSRを記入する。

パーティショニングが、SSRで定義された独立性要求を満（5）対策たしているか確認するため、アーキテクチャレベルでソフトSG侵害有になった場合は対策を検討する。対策についてはシステムレベルも含めて検討を行い、ソフトウェアレベルで対策する場合は新たなSSRを定義する。

ウェア従属故障分析を実施した。
従属故障とは一つのコンポーネントの機能不全により、他のコンポーネントも機能不全となるような故障モードを指す。
従属故障には、カスケード故障と共通原因故障の二種類

手順（4）はISO26262で要求されていない手順である。の故障モードがある。
カスケード故障は一つのコンポーネン

当初、ISO26262に従ってソフトウェア安全分析を実施した

トの機能不全により、他のコンポーネントが影響を受けて機81

機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例能不全となる故障モードを指す。
共通原因故障は関連する全関連コンポーネントが非安全関連コンポーネントの機能コンポーネントが共通の原因により、両方とも機能不全とな不全の影響を受けないことを確認する。
このため、全てのコる故障モードを指す。
従属故障の例を図6に示す。

ンポーネントに対して分析が必要である。以下の（1）～（3）の手順で分析を実施した。
（1）従属故障チェック項目の定義
他のコンポーネントとの関連項目を共通リソースとし、想定される従属故障の分類と故障モードを定義する。
表5. ソフトウェア従属故障チェック項目図6. 従属故障例

4.4 ソフトウェア従属故障分析事例（2）影響先コンポーネントの抽出

ソフトウェア従属故障分析の事例を表6に示す。
ソフト

従属故障チェック項目に基づき、共通原因故障の場合

ウェア従属故障分析は、ソフトウェアFMEAとは異なり、安は、リソースを共有する他のコンポーネントを抽出する。
カス

表6. ソフトウェア従属故障分析事例

82

機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例

ケード故障の場合は、コンポーネントの機能不全により影響を受ける他のコンポーネントを抽出する。
（3）対策内容の検討抽出されたコンポーネントの従属故障に対して、対策の要否を判断する。既に対策済みの場合はその対策内容を記載する。新たに対策が必要な場合は、対策内容を検討する。
今回はマイコン機能の活用や既存機能で対策可能な場合は問題なしと判断した。対策が必要と判断された故
障モードは、共通原因故障の原因になる開発環境の不具合である。
これについては、後工程のデザインレビューとテストによる検証を実施し、問題なしと判断した。

5. むすび
本稿では、ISO26262に対応したソフトウェアアーキテクチャ設計と、ソフトウェア安全分析の事例を紹介した。今回の事例では、マイコンの機能を用いてパーティショニングを行うことで、ISO26262の要求事項に対応したソフトウェアを開発するとともに、既存機能に対する変更を最小化することができた。
ISO26262の対応が求められる開発では、ソフトウェア安全分析やソフトウェア従属故障分析の要求事項を理解し、ソフトウェア安全要求の分析段階で、設計戦略を立てることが重要である。
これにより、後工程での仕様追加や設計変更を防止し、効率的な開発が可能となる。
近年、車載機器の開発において、ISO26262の対応した製品開発は当たり前のものとなりつつある。今後、より一層ISO26262に対する理解を深めて開発事例を蓄積し、三菱電機（株）とともに、より安全で効率的な車載機器の開発に貢献していく。
最後に本開発に際して、貴重な御意見、御指導を頂いた三菱電機（株）の方々に深く感謝を申し上げる。

参考文献（1）D NV GL ビジネス・アシュアランス・ジャパン株式会
社,ISO26262エンジニアリングコース ソフトウェア編

執筆者紹介
西川綾

ニシカワ アヤ2006年入社。主に車載用充電器のソフトウェア開発に従事。現在、三田事業所技術第２部技術第１課。
前田 頼正

マエダ ヨリマサ

2003年入社。主に車載用充電器のソフトウェア開発に従事。現在、三田事業所技術第２部技術第１課。

83