01

ECUソフトウェアに実装される安全関連機能の割合は右肩上がりで増加しており、それとともに安全関連アプリケーションソフトウェアとAUTOSARベーシックソフトウェアのインタラクションの頻度も高まっています。これらのソフトウェアのパーティションが異なると、少なくともアクティブなタスクの切替えと、ハードウェアプラットフォームによってはメモリー保護ユニット（MPU： Memory Protection Unit）のリプログラミングも必要になり、インタラクションに要する処理時間が増えてしまいます。ただし、ASIL Dの要求に準拠して開発されたベーシックソフトウェアは、同一パーティション内での安全関連アプリケーションソフトウェアとの共存が可能であるため、タスクの切替え、MPUのリプログラミング、追加のデータのコピー操作を回避でき、パフォーマンスを大幅に向上できます。さらに、頻繁に使用される追加の安全要求をそのようなベーシックソフトウェアに実装すれば、ECUプロジェクトのたびにそれらを開発する必要がなくなります。図1は、これら2つのアプローチの違いを図解したものです。

背景

ISO 26262では、ソフトウェアに実装される機能の属性として、自動車用安全度水準（ASIL： Automotive Safety Integrity Level）が定義されています。ASILはその機能を実装する際の品質を表すもので、開発するアイテムのハザード分析及びリスクアセスメント（HARA）から導出され、安全目標に割り当てられて、それがさらに機能安全コンセプトおよび技術安全コンセプトから安全関連ソフトウェアの要求へと引き継がれます。特定のASILレベルの安全関連要求をソフトウェアコンポーネントに実装する場合、その開発にはISO 26262 Part 6から取得した、対応する手法を適用しなければなりません（図2）。ベーシックソフトウェアに含まれるこのような安全関連機能としてよく知られているものには、オペレーティングシステムによるメモリー保護、ウォッチドッグスタックによる時間モニタリング、AUTOSAR仕様に記載のある、エンドツーエンド（E2E：End-to-End）プロテクションを使用した通信保護などがあります[1]。

ASIL DのAUTOSARベーシックソフトウェアがもたらす安全とパフォーマンスISO 26262に準拠して開発された電子制御ユニット（ECU）では、しばしば安全関連のソフトウェアと非安全関連のソフトウェアが並行して使用されます。それらの相互干渉の回避には従来からパーティショニングが用いられてきましたが、そのようなパーティショニングは実行時のオーバーヘッドや複雑化を招くことが少なくありません。ISO 26262に完全に準拠して作られたAUTOSARベーシックソフトウェアを使用すれば、パーティションの数を最小限に抑えることができます。

02

Technical Article / August 2016

AUTOSAR basic software partly as QM software AUTOSAR basic software entirely as ASIL software

SWC SWC SWC SWCE2E

RTE

OS

Wat

chdo

g

BSW

MCAL

Hardware

ASIL-Software

QM-Software

SWC SWC SWC SWCE2E

RTE

OS

Wat

chdo

g

BSW

MCAL

Hardware

RTE

図1： QMおよびASILベーシックソフトウェアによるパーティショニングのコンセプト

AUTOSAR E2Eプロテクションは安全関連シグナルを守るために使用される最先端の手法です。これを使用すれば関連するすべてのフォールトを検出できるため、ベーシックソフトウェアの通信コンポーネントに安全要求は課せられません。E2Eプロテクションと通信コンポーネントのパーティショニングを避けるには、ISO 26262 Part 6の手法を通信コンポーネントにも適用する必要があります。これは、ASILレベルが低いソフトウェアには、上位のASILレベルに準拠して開発されたソフトウェアよりも多くのシステマチックフォールトが含まれると考えられるためです。パーティショニングがなければ、それらのフォールトが安全関連ソフトウェアに波及して、指定された安全要求の違反を招くだけでなく、ソフトウェアの安全関連データや安全関連タイミング要求との間に干渉が生じる恐れもあります。こういった干渉に起因する潜在的な障害は防がなければなりません。ISO 26262には、非安全関連のソフトウェアコンポーネントを安全関連機能に使用するのと同じ開発プロセスで開発するという解決策が示されており[2]、そのようなソフトウェアコンポーネントは、十分な「無干渉（Freedom from Interference）」を提供するとみなされます。

開発に及ぼす影響

このような議論から示唆されるのは、まずこういったソフトウェアのための広範かつ準形式的な設計の作成が必要だということです。一般的にはこれによって、ASIL Dの要求を満たすための開発工数が増えますが、設計と実装で工数が増えたとしても、検証、特にテストに要する負担の大きさに比べればわずかなものです。ソフトウェア安全分析の結果として、ISO 26262 Part 6の

Table 4から多様化アルゴリズム実装の要求が導き出されることがあります。システマチックフォールトを防ぐには、アルゴリズムを2種類の方法で実装しますが、ベクターはこのような多様化実装を、コンポーネントの優れたテスト容易性に基づいて回避しています。

これはテスト対象のソフトウェアコンポーネントにおける、サイクロマティック複雑度の低さから実証されます。なお、サイクロマティック複雑度は、ある機能の制御フローグラフに含まれるパスの算出値です。コンポーネントのテスト容易性に対する厳格な要求を満たすため、多くのコンポーネントでリファクタリング、すなわちソースコード構造の改良が必要になりました。そしてそのプロセスはまた、防御的プログラミングの改良、すなわち、チェックの追加とコンポーネント内のモジュール化による堅牢性の向上にも使用されました。

AUTOSARベーシックソフトウェアの広範な設定可能性も課題の1つです。ISO 26262はこの設定可能性を部分的にしか取り上げておらず、特に単体テストの分野では、考えられるコードバリアントは1つのみという前提が暗黙的になされています。ベーシックソフトウェアをSafety Element out of Context (SEooC) [3]として幅広いコンフィギュレーションで使用できるようにするには、このような設定可能性に対応できるアプローチを探す必要がありました。この設定可能性はプリプロセッサー条件の形である程度反映されています。ベクターはユースケースと設定パラメーター間の依存関係に基づいて、考えられるコンフィギュレーションを導き出したうえ、開発プロセスでは、実行時テストの終了基準に適用するものと同じ標準規格[4]をプリプロセッサー条件に適用し、またコンポーネント開発では、テスト用に追加の終了基準を定義しました。ランタイムテストの際には、プリプロセッサーのカバレッジを達成するのに必要な完全なコードカバレッジを、それぞれの種類のコンフィギュレーションで実現することが求められます。このプロセスの要となるのが静的なコード解析で、これによって

ある種のエラー、たとえばメモリーコラプションなどを、機能テストよりもはるかに高い信頼性で発見することができます。ベクターはコンフィギュアブルなソフトウェアの観点から、それ専用に、領域外アクセスや無効なポインターを検出するための、静的なコード解析を開発しました。

03

Technical Article / August 2016

Hazard and risik

analysis

Safety goal

Functional safety

requirements

Technical safety

requirements

Softwaresafety

requirements

derived

derived

derived

derived

Partition

implemented in

ASIL

Softwarecomponent B

ASIL

ASIL

Softwarecomponent A

ASIL

ASIL

ASIL

By using the same methods in thedevelopment of component B, acoexistence with A in the samepartition is possible.

ASIL

ASIL

Derived ASIL according to methods of ISO 26262.

図2： 安全要求や共存のニーズから発生した、ASILに準拠したソフトウェアコンポーネントの開発

ベーシックソフトウェアのバリアントが多いため、ユーザーは解析の際、生成済みコンフィギュレーションの自動検証を実施します。これによってベーシックソフトウェアの非安全関連部分と安全関連部分のメモリーでの無干渉を確実にします。

安全コンセプト

上で述べた安全指向の開発プロセスでISO 26262の関連する要求がほぼすべて満たされることから、これを使ってSEooCベーシックソフトウェアのための新しい安全要求を定義できます。ベクターは、ベーシックソフトウェアの下位レイヤーやハードウェアに起因する、不揮発性メモリー内のデータの損失や破損の検出、マスキングなど、ベーシックソフトウェア用の追加の安全要求を策定済みです。また、今後はソフトウェアアプリケーションの再起動やAUTOSARタイミング保護も、安全機構として使用できるようにするほか、初期化時にECUを所定の状態に設定する安全要求も仮定しています。パーティショニングのために必要な安全要求は、通常

引き続き求められます。たとえばすでに存在していることの多いQMソフトウェアは、新規の開発や認定取得（ISO 26262 Part 8 Clause 12）が費用対効果解析の結果から経済的でないことが判明しているため、統合が必要です。ベクターが仮定している安全要求は、それらを入念に解析し、そ

の基になっている前提を周知したうえで、ECUプロジェクトの安全コンセプトに使用できます。つまり、プロジェクト固有の安全コンセプトに使用できるのは、仮定されている安全要求に含まれる機能のみです。たとえば、通信コンポーネントについてベクターが仮定している安全要求は存在しないため、それらの開発手法がISO 26262に準拠していても、安全関連データの転送にはE2E保護が必要になります。そのため、プロジェクトのごく初期のフェーズから、仮定されている安全要求の一覧を利用できるようにしておくことが必要です。

統合

ベーシックソフトウェアのユーザーは、仮定されている安全要求の妥当性をプロジェクトのコンテキストで確認した後、納品物に同梱されているセーフティマニュアルを使用してベーシックソフトウェアの設定と統合を行います。ベーシックソフトウェアの単体テストは、そのサプライヤーがあらかじめ実施しているのが普通です。ただし、ISO 26262 [5]に記載されている統合および検証ステップはユーザーが実施しなければなりません。ベーシックソフトウェアの開発時にはコンフィギュレーションやアプリケーション、そして正確なターゲット環境に関する情報が十分でないため、ベーシックソフトウェアのサプライヤーがこれらのレベルのセーフティケースの作成に貢献することはできません。ユーザーはベーシックソフトウェアのセーフティケースを通じ

て、ISO 26262に準拠した開発プロセスが順守されていることの確証を得ます。そして、このセーフティケースを参照して、自身のセーフティケースの作成にあたります。その参照するセーフティケースは、ユーザーから提出されたコンフィギュレーションに基づいて作成されています。このコンフィギュレーションは、コンポーネントテストの妥当性確認のため、ベクターがチェックする必要があります。開発中は、すべての設定パラメーターの組合せをテストすることはできません。特殊なコンフィギュレーションも漏らさずテストするには、プロジェクト固有のテストが必要です。このアプローチは、認証会社（exida）による独立した、しかも模範

的なアセスメントにより、有効であると確認されています。このアセスメントでは、オペレーティングシステムとCAN、LIN、FlexRay通信用のコンポーネントのほか、システムおよびメモリークラスターのコンポーネントも評価されました。現時点でASIL Dに準拠して開発されているコンポーネントの概要を図3に示します。

展望

これまで述べたプローチから、ASIL Dのベーシックソフトウェアを使用すれば、実行時のオーバーヘッドとパーティションの数をいかに削減できるかがわかります。しかも、安全機構がベーシックソフトウェアにすでに含まれており、ユーザーがあらためてそれらを実装する必要がなくなるため、ECUプロジェクトの複雑さも軽減します。

04

Technical Article / August 2016

OS SYS DIAG MEM

CAN LIN FR ETH

IO LIBS

V2G

AVB

ComplexDriver

EXT

COM

AMD

MCAL

Microcontroller

OS*

COMM

BSWM

E2E Protection Wrapper*

SCHM

DCM

DEM

FIM

J1939DCM

EA

SCC

EXI

HTTP

DNS

XML Security

FEE

MEMIF

NVM*

J1939TP

J1939NM

J1939RM

CANXCP

CANTP

CANNM

CANSM

FRXCP

FRTP

FRARTP

FRNM

FRSM

ETHXCP

UDPNM

SD

DOIP

SOAD

LINXCP

LINTP

LINNM

LINSM

LINIF

DLT

DBG

XCP

CSM*

SafeRTE*

Application

E2E*

CRC*

CAL (CPL)

RTM

ADCDRV

CANDRV

CORTST

DIODRV

EEPDRV

ETHDRV

ETHSWTDRV

FLSDRV

FLSTST

FRDRV

GPTDRV

ICUDRV

IICDRV

LINDRV

MCUDRV

OCUDRV

PORTDRV

PWMDRV

RAMTST

CRY (HW)

SPIDRV*

WDGDRV* DRVEXT*

CANTRCV LINTRCV

FRTRCV

ETHTRCV

Vector Standard Software SafeBSW 3rd Party Software * with dedicated safety requirement

CANIF

CANTSYN

FRTSYN

FRIF

COM

COMXF

IPDUM NM

SECOC

PDURLDCOM

E2EXFSOMEIPXF

SBC*

AVTP

PTP

SRP

DIOHWAB

SENT

TCPIP

ETM

ETHSM

ETHTSYN

ETHIF

CRY (SW)

ECUM*

STBM

TM

WDGIF*

WDGM*

DRM

TLS

PSI5 DRV

図3： ASIL Dに準拠して開発されているAUTOSAR 4ベーシックソフトウェアのコンポーネントの現時点での概要

ベクターは自社の新しい安全指向プロセスに準拠したAUTOSAR 4ベーシックソフトウェアコンポーネントの開発を進め、可能な限り多くのアプリケーションケースに対応できる、最適なソリューションの提供を目指しています。AUTOSARコンポーネントには次々と変更が加えられており、我々は遠からずこの課題に直面することになります。また、自動車メーカーによる拡張機能や多彩な半導体メーカーのハードウェアドライバーも課題の1つです。それらはまだ必要な品質に到達しておらず、安全なベーシックソフトウェアと使用しようとすれば、多大な手間がかかるうえ、パフォーマンスも犠牲にしなければなりません。ベクターとexidaはさらなる取組みとして、安全関連ソフトウェアのコンテキストで使用でき、大きな認定取得コストが不要になるRTEの実装を進めています。

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部（東京） TEL: 03-5769-6980　FAX: 03-5769-6975（名古屋） TEL: 052-238-5020　FAX: 052-238-5077E-Mail: sales@jp.vector.com

ベクターの機能安全のためのソリューション(ISO 26262)の詳細：https://jp.vector.com/vj_safety_jp.html

本稿は、ドイツで発行された『HANSER automotive, July/August 2016』に掲載された記事内容を和訳したものです。

画像提供元： Vector Informatik GmbH

参考文献：[1] AUTOSAR Specification of SW-C End-to-End Communication Protection Library[2] ISO 26262 Part 9 Clause 6[3] ISO 26262 Part 10 Clause 9[4] ISO 26262 Part 6 Clause 12[5] ISO 26262 Part 6 Clauses 10 and 11Jonas Wolf (Dipl.-Ing.)

シュツットガルト大学で宇宙工学を学んだ後、2012年にベクターに入社。現在はプロダクトマネージメントエンジニアとして機能安全を担当。

Peter MüllerMannheim University of Applied Sciencesで機能安全の学位を取得後、TÜV Südに入社。2002年にexidaに入社し、2007年より主任審査員としてオートメーションおよび自動車分野の認証を担当。

執筆者：