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

機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例
1. まえがき
近年、自動車業界においては高機能化の要求が求められており、マイコンに搭載するソフトウェアは年々大規模化している。それに伴い複雑になったソフトウェアの品質が製品の安全性に大きく影響を及ぼすようになっている。このような背景から自動車業界における電気/電子（E/E）システムの安全性に関する国際規格として機能安全規格ISO26262が発行された。当所でソフトウェア開発を行っている車載充電器（OBC:On Board Charger）は、電気自動車（EV）やプラグインハイブリットカー（PHEV）の駆動用高圧バッテリを充電する装置である。EV/PHEVの充電時に充電機能が故障した場合、発煙・発火などを伴う危険事象が発生する可能性がある。そのため、OBCにISO26262への対応要求があり、ISO26262に対応したソフトウェア開発を行っている。ISO26262では、製品に要求される安全レベルに応じて、プロダクトが備えるべき機能や、プロセスにおいて実施すべき内容が定義されており、これらに基づいて開発を実施する。特徴的な要求事項としてソフトウェアアーキテクチャ設計でのソフトウェア安全分析及びソフトウェア従属故障分析がある。本稿では、ソフトウェアアーキテクチャ設計とソフトウェア安全分析の事例を紹介する。
2. ISO26262概要
機能安全とは「E/Eシステムの機能不全のふるまいにより引き起こされるハザード（危険）が原因となる不合理なリスクの不在」と定義されている。これはE/Eシステムに故障が発生しても、安全機構（SM:Safety Machanism）を設けることでハザードを許容可能なレベルまで低減することを指す。図1に従ってISO26262の開発フローを説明する。最上位の要求として安全目標（SG:Safety Goal）と、その安全性要求レベル（ASIL：Automotive Safety IntegrityLevel）が定義される。システムレベルにおける開発では、最初に機能安全コンセプトを検討し、機能安全要求（FSR:Functional Safety Requirement）を定義する。図1. 開発フロー次にF S Rの実現方法を検討し、技術安全要求（TSR:Technical Safety Requirement）として仕様化する。ソフトウェアレベルにおける開発では、ソフトウェアに割り付けられたT S Rを詳細化し、ソフトウェア安全要求（SSR:Software Safety Requirement）を定義する。以降は通常の開発と同様に、ソフトウェアアーキテクチャ設計、ソフトウェアユニット設計と実装を行う流れとなる。SGからSSRまでの仕様例を表1に示す。表1. 仕様例機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例三田事業所　技術第２部　技術第１課西川　綾、 前田　頼正78機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例一般論文ソフトウェアの機能不全によりSSRの要求を満たせなくなると、ハザードに繋がる可能性がある。予めソフトウェア安全分析を行うことで危険事象を抽出し、対策を施すことが要求される。ソフトウェア安全分析によりSGの侵害に繋がる危険事象が見つかった場合は、対策として追加でSMを盛り込み、改めて分析を行う必要がある。3. ソフトウェアアーキテクチャ設計今回開発したソフトウェアにおける設計事例を説明する。開発の目的は、充電機能に関連する開発済みのソフトウェアにSMを追加し、ISO26262に準拠させることである。SGとFSRは車両メーカで検討され、TSRへの展開は三菱電機（株）の担当である。本稿では、これらの説明は割愛し、当社が担当したSSRに対するアーキテクチャ設計とソフトウェア安全分析について説明する。設計方針として、安全が要求される機能と要求されない機能で、関数の集合であるコンポーネント（SWC）を分け、既存機能に対して極力変更を行わないこととした。最初にSSRのインプットであるTSRを、ASILによって分類した。ASILは一般的な品質管理で許容されるレベル（QM）と、安全機構が必要になるレベル（QM以外）に分類される。QMの場合はISO26262を適用した開発が不要なため、既存のコンポーネントに割り当てた。QM以外の場合は、ISO26262を適用した開発が必要なため、新規に作成するコンポーネントに割り当てた。ソフトウェアにQMとQM以外のコンポーネントが混在する場合、ISO26262では、両者の間に独立性の確保が要求される。このような構成を実現するため、独立性に関する要求を追加して、TSRからSSRを定義した。OBCは、ISO26262に対応するために、CPUコアを二つ搭載したマイコンを採用している。既存機能はメインコアであるCPUに配置されているため、新規に作成する安全関連機能はサブコアであるPCU（Peripheral ControlUnit）に配置することで、パーティショニングを実施した。以上を踏まえて定義したSSRを表2に、各コアへの配置結果を図2に示す。表2. SSR例図2. SSR配置例CPUに配置されている既存機能は、安全に関連するコンポーネントと、そうでないコンポーネントが混在していた。各コンポーネントの機能を分析し、ASILがQMとなるSSRのみを割り当てた。これによって、CPUに配置する既存機能のコンポーネントについては、独立性の確保が不要となるアーキテクチャ設計とした。各コアに対するコンポーネントの配置結果を図3に示す。図3. 各コアのコンポーネント配置79機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例PCUとCPUに配置したSSR間の独立性を確保するため、以下に示すアーキテクチャとした。・ CPUとPCU間のデータ授受はGlobal RAMを介してのみ行う。・ CPUからPCUに伝えるデータと、PCUからCPUに伝えるデータを異なる領域に配置する。・ 各領域に対して、各コアはデータの書き込み又は読み込みの一方向のアクセスのみ行う。・ マイコンのメモリプロテクションユニットを使用して、各コアからの許可されていない領域に対する書き込みを防止し、メモリアクセスの独立性を担保する。Global RAMを介したコア間のデータフローを含む、コンポーネント図を図4に示す。図4. コア間のデータ授受4. ソフトウェア安全分析4.1 ソフトウェア安全分析とはソフトウェアの機能不全により、SSRの要求を満たせない場合は、システムがハザードに繋がる可能性がある。事前に各コンポーネントについて、SGの侵害に繋がる危険事象を特定し、ソフトウェアアーキテクチャ設計の妥当性やSMに漏れがないことを検証する。ソフトウェア安全分析の手順を図5に示す。ソフトウェア安全分析及びソフトウェア従属故障分析を行った結果、対策が必要となった場合は新たなSMを追加し、ソフトウェアアーキテクチャを見直す。追加の対策が不要になるまで分析を繰り返し実施する。図5. ソフトウェア安全分析手順4.2 ソフトウェア安全分析事例ISO26262では、安全分析手法として定性的FMEA、定性的FTA、HAZOP、定性的ETAが示されている。システムやハードウェアは定量的分析手法が適用可能であるが、ソフトウェアは定量的な分析が難しいため、定性的分析手法を用いる。今回の開発では、HAZOPのガイドワードを用いて、ソフトウェアFMEAを実施した。HAZOP（Hazard and Operability Study）は、分析対象に対し、予め決められたガイドワードを用いて、ハザード及び後工程への影響や検出可能性について分析する手法である。HAZOPのガイドワード例を表3に示す。表3. HAZOPガイドワードHAZOPのガイドワードを用いたソフトウェアFMEAの事例を表4に示す。80機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例ソフトウェアFMEAは、以下の（1）～（5）の手順で分析を実施した。（1） 分析対象の抽出分析対象となる信号の抽出を行う。本事例では、入出力信号を対象とした。（2） 故障モードの検討HAZOPガイドワードに従って、抽出した各信号がどのような故障モードとなるか検討する。（3） SG侵害の影響シナリオの検討検討した故障モードから、各SGを侵害する影響シナリオを分析して整理する。（4） 盛り込み済みの対策仕様の抽出侵害有となった影響シナリオに対して、既に対策が盛り込まれている場合は、該当するSSRを記入する。（5） 対策SG侵害有になった場合は対策を検討する。対策についてはシステムレベルも含めて検討を行い、ソフトウェアレベルで対策する場合は新たなSSRを定義する。手順（4）はISO26262で要求されていない手順である。当初、ISO26262に従ってソフトウェア安全分析を実施したところ、コンポーネントの機能不全がSGの侵害に結び付く故障モードがあるものの、他のSSRで対策済みであり、ソフトウェアに新たなSMを設ける必要はないとの結果になった。これは、システムレベルの開発において、SG侵害となる故障モードに対して、予めSMを設けているためである。ISO26262では、ソフトウェア安全分析でSMの追加が必要となった場合は、SSRに仕様化することが求められている。今回の事例では、本来導出されるべきSMとそのSSRを明確にするため、手順（4）を追加してソフトウェア安全分析を実施した。4.3 ソフトウェア従属故障分析CPUとPCUに配置した安全関連コンポーネント間のパーティショニングが、SSRで定義された独立性要求を満たしているか確認するため、アーキテクチャレベルでソフトウェア従属故障分析を実施した。従属故障とは一つのコンポーネントの機能不全により、他のコンポーネントも機能不全となるような故障モードを指す。従属故障には、カスケード故障と共通原因故障の二種類の故障モードがある。カスケード故障は一つのコンポーネントの機能不全により、他のコンポーネントが影響を受けて機表4. ソフトウェアFMEA事例81機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例能不全となる故障モードを指す。共通原因故障は関連するコンポーネントが共通の原因により、両方とも機能不全となる故障モードを指す。従属故障の例を図6に示す。図6. 従属故障例4.4 ソフトウェア従属故障分析事例ソフトウェア従属故障分析の事例を表6に示す。ソフトウェア従属故障分析は、ソフトウェアFMEAとは異なり、安全関連コンポーネントが非安全関連コンポーネントの機能不全の影響を受けないことを確認する。このため、全てのコンポーネントに対して分析が必要である。以下の（1）～（3）の手順で分析を実施した。（1） 従属故障チェック項目の定義他のコンポーネントとの関連項目を共通リソースとし、想定される従属故障の分類と故障モードを定義する。表5. ソフトウェア従属故障チェック項目（2） 影響先コンポーネントの抽出従属故障チェック項目に基づき、共通原因故障の場合は、リソースを共有する他のコンポーネントを抽出する。カス表6. ソフトウェア従属故障分析事例82機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例ケード故障の場合は、コンポーネントの機能不全により影響を受ける他のコンポーネントを抽出する。（3） 対策内容の検討抽出されたコンポーネントの従属故障に対して、対策の要否を判断する。既に対策済みの場合はその対策内容を記載する。新たに対策が必要な場合は、対策内容を検討する。今回はマイコン機能の活用や既存機能で対策可能な場合は問題なしと判断した。対策が必要と判断された故障モードは、共通原因故障の原因になる開発環境の不具合である。これについては、後工程のデザインレビューとテストによる検証を実施し、問題なしと判断した。5. むすび本稿では、ISO26262に対応したソフトウェアアーキテクチャ設計と、ソフトウェア安全分析の事例を紹介した。今回の事例では、マイコンの機能を用いてパーティショニングを行うことで、ISO26262の要求事項に対応したソフトウェアを開発するとともに、既存機能に対する変更を最小化することができた。ISO26262の対応が求められる開発では、ソフトウェア安全分析やソフトウェア従属故障分析の要求事項を理解し、ソフトウェア安全要求の分析段階で、設計戦略を立てることが重要である。これにより、後工程での仕様追加や設計変更を防止し、効率的な開発が可能となる。近年、車載機器の開発において、ISO26262の対応した製品開発は当たり前のものとなりつつある。今後、より一層ISO26262に対する理解を深めて開発事例を蓄積し、三菱電機（株）とともに、より安全で効率的な車載機器の開発に貢献していく。最後に本開発に際して、貴重な御意見、御指導を頂いた三菱電機（株）の方々に深く感謝を申し上げる。参考文献（1） DNV GL ビジネス・アシュアランス・ジャパン株式会社,ISO26262エンジニアリングコース ソフトウェア編執筆者紹介西川　綾 ニシカワ　アヤ2006年入社。主に車載用充電器のソフトウェア開発に従事。現在、三田事業所技術第２部技術第１課。前田　頼正 マエダ　ヨリマサ2003年入社。主に車載用充電器のソフトウェア開発に従事。現在、三田事業所技術第２部技術第１課。83機能安全規格に基づいた車載充電器のソフトウェアアーキテクチャ設計事例