自動車向け機能安全規格ISO 26262をOEM，サプライヤ各社の活動に適用する際の課題への対応を議論し，共通理解を得るために共同研究エンジンWG活動を実施した．本稿では2011年度～2022年度の活動事例について，パワートレーンシステムやHEVシステム等 複数のECUで構成される複合システムを事例に行った規格解釈について紹介する．
1. 背景
本WGは国内の車両メーカ（以降OEMと記す）と部品メーカ（以降サプライヤと記す）で構成される．本WGは一般的なエンジン制御システムを題材にOEMとサプライヤの協調領域について，実運用課題への対応を議論し，規格解釈を実施，共通理解を得るために，機能安全要求（FSR：Functional Safety Requirement），技術安全要求（TSR：Technical Safety Requirement）導出の考え方，テスト手法，および他システムからの安全要求に基づく機能安全設計の適用事例について検討を進めてきた．
2. 活動事例の紹介
高度運転支援システム（ADAS：Advanced Driver Assistance Systems）や，自動運転システム（ADS：Automated Driving Systems）の開発が進む中，複雑化，分散化が進む車載電気/電子（以降，E/Eと記す）システムにおいてISO 26262の活動対象となるアイテム定義（開発対象システムの仕様や依存関係を定義すること）や，安全要求の配置，安全機構に関する規格解釈や実運用課題を検討するため，パワートレーンシステム，HEVシステム等複数のECUで構成される複合システムを事例に規格解釈を実施した．
本稿では，「将来のE/Eアーキテクチャに対応した安全機構の考察（セントラル型アーキテクチャを事例とした安全機構の検討）」，「フォールトトレランス（一つ又は複数の指定されたフォールトの存在下で指定した機能を提供する能力（ISO 26262-1:2018より引用））なシステムへの機能安全に関する解釈」および「複雑化するシステムにおけるアイテム定義の考察」を事例に議論の概要を紹介する．
2.1 将来のE/Eアーキテクチャに対応した安全機構の考察
近年，ADASやHEVシステムの様に車載電子制御システムが大規模複雑化しており，複数のシステムが連携して構成される複合システムが増加している．複合システムでは，車載ECU数が増加し，車における電子制御機能（ソフトウェア（SW）／ハードウェア（HW））が増大している．現在，車載E/Eアーキテクチャは，主に，エンジン，ブレーキ，ステアリングなどの個別で機能を実現するようなドメイン型である．しかし，将来的には，処理を一つのECUに束ねるセントラル型が導入され，車の前後，左右をセントラECUとつなげるような配置トポロジに依存するゾーンアーキテクチャに変わっていくと考えられている．このように車載E/Eアーキテクチャが変化して，ドメイン間の相互関係が複雑化するなか，E/Eアーキテクチャに関するアイテム定義～機能安全コンセプト導出（FSC：Functional Safety Concept）などの機能安全（FuSa：Functional Safety）活動が，単一システムでアイテムを定義できた従来通りの考え方，解釈のままでよいかについて，事例を元にフィージビリティスタディを実施した．
図1のセントラルアーキテクチャの事例を用いて検討した結果，従来のドメイン型E/Eアーキテクチャと同じように，機能を一つのECUに集約したセントラル型アーキテクチャでも機能安全への対応が可能であることがわかった．ただし，故障時に安全を実現するための設計思想（機能継続か機能縮退か機能停止か），機能のリアルタイム性，故障対処時の時間的な制約（例えばフォールトトレラント時間間隔）などが異なる複数の機能をセントラル型として一つにまとめることで，機能安全設計の難易度がかえって上がる場合もあり，セントラル型を検討する場合には，分散型での開発以上に，複数機能間のインタラクション，制約事項を，より深く考慮する必要があることが課題として上げられた．
図1 セントラルアーキテクチャの一例
2.2 フォールトトレランスなシステムへの機能安全に関する解釈
ステアバイワイヤにおける車速制限に関するエンジンへの自動車用安全度水準（ASIL：Automotive Safety Integrity Level）付与について事例を元に検討した．冗長構成のステアバイワイヤシステムで，冗長の一方で故障が発生した場合に，故障していないもう一方で機能を継続するために車速を制限して制御可能性を上げ，ASIL対応能力を確保する事例が，ISO 26262-Part.10のClause12に示されている．完全冗長なシステムの場合，チャンネルA（またはチャンネルB）の故障ではハザードには至らない．さらに単独故障時の処置として車速制限を実施する場合，要求ASILは何になるのか検討することが必要となった．このような場合の機能安全対応について検討するため，冗長で構成されるシステムにおけるASIL付与の考え方について事例を元に規格解釈を実施した．
図2のステアバイワイヤシステムの事例を用いて検討した結果，完全冗長なシステムの場合，初期は単独システムで検討を開始し，ASIL Dを付与する（システムにASIL Dを割り振る，の意）．ISO 26262-Part.10では速度制限機能（例えばエンジン制御機能）にASIL Dを割り振る例の記載がある．一方，冗長構成の一つに故障が発生し，残された一つで機能継続する場合はレイテント状態（故障が潜在化した状態）となるので，レイテント対策（例えば警告ランプによる通知）を実施すれば，速度制限機能に安全要求を割り振らないという考え方も適用できることが判った．また，デコンポジションの手法を用いてASILを下げる場合は，独立性の要件の検討などについて、さらに深掘りが必要であることが課題として上げられた．
図2 ステアバイワイヤにおける冗長システムの一例
図2のように，完全冗長なシステムの場合、チャンネルA（またはチャンネルB）の故障ではハザードには至らない。このような場合，一例として次の①～④の4点を考慮して，機能安全対応を検討する必要がある．
2.3 複雑化するシステムにおけるアイテム定義の考察
2020年度および2021年度「複数システム連携におけるアイテム境界部の安全設計方策の検討」，「複数システム連携における安全機構の規格解釈と設計注意点の検討」を実施したアイテム定義とASIL検証に関して，2022年度，更に考察し，複雑化するシステムにおけるアイテム定義（グランドアイテム（仮称）（以下，単に「グランドアイテム」と記す））について事例を元に規格解釈を実施した．
図3に複雑化するシステムにおけるアイテム定義の検討例を示す．アイテム定義について，全体を1つのアイテムとする考え方と個々をアイテムとする考え方の中間的な考え方として，全体を1つのアイテムとしつつ，全体を構成する個々アイテムも定義するグランドアイテムという考え方を検討した．グランドアイテムという考え方により，個々のアイテム定義では考慮が十分しにくい通信系や従属故障の機能安全対応について網羅でき，かつグランドアイテム開発者は，全体として個々のアイテム間の相互作用にも配慮するので，個々のアイテム開発者は自アイテムの機能安全活動に注力できる．
図3 複雑化するシステムのアイテム定義の事例
3. まとめ
ISO 26262リリース時点から，規格の解釈および実開発への適用について事例ベースで議論し，協調領域に関する気付きを得ることができた．活動を通じて得られた知見を各社に持ち帰り開発に活かし，各社内での機能安全規格の解釈に関する相談ごとの解決にも役立てることができた．結果，トレーン制御システムに関する機能安全設計のstate-of-the-art（最先端）について共有することができ，関係者の技術レベルのさらなる向上に貢献できたと考える．
4. 今後の課題
ISO 26262発行当初と比べ，車載E/Eシステムは，より高機能複雑化しており，かつ，意図した機能の安全性（SOTIF：Safety Of The Intended Functionality）規格（ISO 21448），サイバーセキュリティ（CS）規格（ISO/SAE 21434）の発行など，車載E/Eシステムに係わる新たな規格が発行されている．SOTIFやCSの国際規格の内容も踏まえたISO 26262の規格解釈について，今後，制御システムの大規模化，複雑化や電動化に伴う規格解釈上の課題について，より深い議論が必要となる場合もあると思われる．
5. 最後に
本WG活動，ISO 26262を適用する上での実運用課題について事例を元に議論し，規格解釈を通して得られた知見を各社開発の現場で有効活用されることを期待するものである．
6．注意事項
本稿では，さまざまな前提条件を仮定して，検討した事例（案）をまとめている．実際の開発に適用する場合には，システム開発における諸事情を勘案する必要がある．
そのため，本書を利用して検討される成果物，あるいは設計されるシステムで発生するいかなる問題に対してJARIはその責任を負わない．また，本書に示す事例は，あくまでも１つの検討事例であり，参考資料扱いとする．事例は，具体的な製品をイメージしたものではあるが，仮想的な製品であり，実際の製品とは無関係である．事例は技術的な正しさを保証するものではなく，書き方を規定するものでもない．
謝辞
2011年～2022年まで，パワートレーン領域へのISO 26262適用に伴う実運用課題について，本WGに参加いただいた皆様に感謝いたします．
