「SIL」「ASIL」とは？機能安全対応に欠かせない基礎知識と支援ツールの活用法

機能安全の国際規格である「IEC 61508」や「ISO 26262」に準拠した開発が求められる中で、「SIL（Safety Integrity Level）」や「ASIL（Automotive Safety Integrity Level）」という用語を耳にする機会が増えていますが、これらの指標は、単なる定義にとどまらず、ソフトウェアやシステム開発における安全対策のレベルを決定づける重要な基準です。
本記事では、SILとASILの違いや基本的な考え方をわかりやすく解説するとともに、機能安全対応を効率化・標準化するための支援ツールについてもご紹介します。

機能安全とは

機能安全とは、安全を確保するような機能を導入することにより、許容不可能なリスクが存在しない状態を達成することです。そして、その機能安全を実装するために有効な手法の規定したものが機能安全規格となります。鉄道や自動車など、それぞれの業界などに向けた様々な機能安全規格が存在しています。
機能安全規格であるIEC 61508やISO 26262などでは、許容可能なリスクまで低減させる（機能安全を達成させる）機能の実装に際して、実施すべき内容を示すための指標が存在します。この指標をIEC 61508ではSIL(Safety Integrity Level)、ISO 26262ではASIL(Automotive Safety Integrity Level)で表します。SIL、ASILをもとにシステム/ハードウェア/ソフトウェアの各作業に要求される内容が変わってくるため、適切に決定していかなければなりません。

ASIL（Automotive Safety Integrity Level）とは

ASILとは、不合理なリスクを回避するために、アイテムの故障を引き起こすハザードを特定し、危険事象の防止、緩和の目標を立てるための指標となるものです。 ASILは、暴露の確立、コントローラビリティ、シビアリティの３種のパラメータにより決定されます。
3種のパラメータの組み合わせに応じて、A～Dの4段階で表され、Aが一番低く、Dが一番高いパラメータとなります。また、ASIL未満のリスクレベルのものはQMと呼ばれます。

• ASIL D：リスクが最も高い
• ASIL B / C：中程度のリスク
• ASIL A：リスクが比較的低い
• QM（Quality Management）：ASIL未満のリスクレベルで、一般的な品質管理に従う

ASIL決定は以下のようなイメージ図となります。

ISO 26262では、ASILごとの分類により、必要な開発プロセスや検証・テストの厳密さが異なります。これらの分類は、システムに潜むリスクの大きさに応じて決定され、具体的には、状況の分析、ハザードの識別、危険事象の分類といったステップを経て、ASILが導き出されます。
このあと、それぞれの作業で求められる内容やポイントについて、概要を解説していきます。

状況分析、ハザードの識別

状況の分析では対象としたアイテムがどのような場合にハザードが起こるのか、その際の動作状況や動作モードを想定します。動作状況はアイテムが安全な挙動を期待する限界を取り扱うとよいです。
ハザードの識別ではその状況で起こりえるハザードを想定します。その際のハザードと動作状況によりどのような危険事象になるのかの特定も行います。ハザードの識別では、適切な技法を使用し決定します。(STAMP/STPA,FMEA等々)

危険事象の分類

特定した状況とハザードの組み合わせに対し、3種のパラメータを割り当てます。

・暴露の確立(Exposure)

ハザードに関連する動作の実行頻度を表すパラメータです。運転状況の特性に応じて運用状況の期間、もしくは運用状況の発生頻度のどちらかの指標を用いて見積もります。下記の表に基づき、E0,E1,E2,E3,E4のいずれかを割り付けます。

E0は自然災害や極度に珍しい状況に対して割り当てられます。

・コントローラビリティ(controllability)

ハザードが発生したときにハザード回避、制御の可能性を表すパラメータです。下記の表に基づき、C0,C1,C2,C3のいずれかを割り付けます。

・シビアリティ(severity)

運転者や周辺の人命にどのような影響があるのかを表すパラメータです。シビアリティを決定するのには、米国自動車医学会が発行するAIS(Abbreviated Injury Scale)を使用されます。下記の表に基づき、S0,S1,S2,S3のいずれかを割り付けます。

それぞれ各パラメータの決定には、論理的根拠を持って行わなければなりません。論理的根拠が薄い場合には、高めのパラメータを割り付けておきます。

ASILの決定方法

決定した暴露の確率(E)、コントローラビリティ(C)、シビアリティ(S)と以下の表を元にASILを決定します。

ASILが割り当てられなかった場合は、安全に関する要求はありませんがQM(Quality Management)レベルとして適切な品質管理の仕組みに基づいた対応を行う必要があります。普段の開発から実施すべき、ソフトウェアの品質を確保するためのCMMIやA-SPICEのような標準規格、または相応するような企業の標準規格等に則った開発プロセスでソフトウェアの品質を高める必要があります。
ASIL Dは、IEC 61508におけるSIL 3と同程度と解釈されています。

安全目標

識別した各ハザードを防ぐ、または、緩和するための最上位の安全要求となります。分類した危険事象毎に決定します。安全目標は技術的な解決の面の観点からではなく、機能的な目標として決定します。「～によって意図しない加速が起きないこと」ではなく、「意図しない加速が起きないこと」のように機能的な目標として決定します。

SIL（Safety Integrity Level）とは

SILとは、機能安全規格「IEC 61508」に基づいて定義された、システムの安全性を測るための指標です。考え方はASILと同様ですが、SILは自動車に限定されず、産業機器やプラントなど幅広い分野に適用されています。
SILは、確率的な指標(危険側機能失敗平均確率、危険側故障の平均頻度)を基に決定されます。IEC 61508では、安全関連機能は動作の要求頻度により以下の3つのモードに分けられます。

• 低頻度要求モード
• 高頻度要求モード
• 連続モード

確率的な指標はこの要求頻度によって異なる指標が使用され、低頻度要求モードでは「危険側機能失敗平均確率」、高頻度要求モードと連続モードでは「危険側故障の平均頻度」が使用されます。
低頻度要求モードでは安全関連系の機能を作動させようとしたときの機能失敗確率が、危険事象の起こる確率に対して十分に低い必要があります。そのため、危険側機能失敗平均確率が用いられます。
高頻度要求モード、連続モードでは時間当たりの機能平均失敗確率も危険事象の起こる確率に対して十分に低い必要があります。そのため、1時間当たりの危険側故障の平均頻度が用いられます。
これらの低頻度作動要求モード、高頻度作動要求モードどちらか該当する方に合わせてSILの決定を行います。SILは1～4段階で表され、1が一番低く、4が一番高い要求となります。

低頻度作動要求モード

低頻度作動要求モードでは、規定の安全状態に移行させるための要求が年1回以下である機能が該当します。車であれば、エアバッグなどの機能が相当します。そのような機能に対しては、以下の表を用いて決定します。

機能失敗平均確率であるため安全機能に動作要求があった場合に、安全機能が動作しない平均の確率を算出しSILの決定を行います。

高頻度作動要求モード

高頻度作動要求モードでは、規定の安全状態に移行させるための要求が年1回より大きい機能が該当します。車であればアクセルなどが相当します。そのような機能に対しては、以下の表を用いて決定します。

危険側故障率であるため、1時間あたりの壊れやすさを算出しSILを決定します。

「SIL」と「ASIL」の違い

機能安全に関する評価指標として「SIL」と「ASIL」がありますが、それぞれ適用される業界や評価手法に違いがあります。以下に、主な違いを表で整理しました。

このように、ASILとSILは似た概念でありながら、評価手法や適用分野が異なるため、用途や業界に応じて正しく使い分けることが重要です。

機能安全対応を支援するツール

機能安全規格への対応は、個々の技術的な実装だけでなく、プロセス全体の整備と検証活動の信頼性確保が求められます。
特にSILやASILといったレベルを達成するには、計画から実装・テスト・レビュー・記録に至るまで、開発のあらゆる局面において”仕組み”として安全性を担保することが重要です。
こうした背景から、機能安全対応を支える各種ツールの導入が注目されています。
たとえば、開発プロセスの標準化やトレーサビリティの確保を支援するプロセス管理ツールや、信頼性が求められる検証工程をサポートする認証済みのテストツールなどが挙げられます。
以下では、これらのツールがどのように機能安全対応を支援するのか、それぞれの役割とメリットをご紹介します。

プロセスの可視化と管理を支援する”プロセス管理ツール”

機能安全規格に対応するには、単に技術的な安全対策を講じるだけでなく、「誰が」「いつ」「どのように」作業を行ったのかを文書で記録し、開発プロセス全体を一貫して管理する必要があります。特に、認証機関の審査ではプロセスの正当性やトレーサビリティが重視され、属人的な対応では対応しきれない場面も少なくありません。
そこで注目されているのが、プロセス管理ツールの導入です。こうしたツールを活用することで、開発工程の可視化やタスクの標準化、文書管理の一元化といった仕組みを構築でき、結果として機能安全対応を”仕組み”で支えることが可能になります。
プロセス管理ツール「Stages」では、Automotive SPICEやISO/SAE 21434、ISO 26262などの国際規格とのマッピング機能を備え、複雑化するプロセス管理をシンプルにします。ご興味のある方は、ぜひこちらから製品の詳細をご確認ください。

認証済みの”テストツール”で検証品質を確保する

機能安全対応におけるもう一つの重要な要素が「検証（テスト）活動の信頼性」です。開発したソフトウェアが安全要求を満たしていることを証明するには、テストツール自体が信頼できるものである必要があります。そのため、ISO 26262などの安全規格では、ツールの信頼性を評価し、必要に応じて「認証済みのツール」を使用することが推奨されています。
当社の提供するDT+シリーズの「DT+FS」は、第三者機関の認証を取得しており、機能安全対応におけるテスト工程を強力にサポートします。製品の信頼性向上と開発効率の両立を目指すなら、ぜひ当社のソリューションをご活用ください。

まとめ

今回の記事では、機能安全規格の要求事項で満たすべき内容を判断するための指標である「ASIL（ISO 26262）」と「SIL（IEC 61508）」について記載しました。機能安全の開発の中では、実施すべき作業が変わってくるという意味でこれらの指標が重要になってきます。開発する機能安全の重要性の違いを意識するためにも、指標がどういうものかを知っておきましょう。
さらに、こうした機能安全対応をより確実に進めるためには、適切なツールの活用が欠かせません。プロセス全体の管理や検証活動の信頼性を支えるツールは、規格要求の効率的な達成と品質向上に大きく貢献します。ぜひ、プロセス管理ツールや認証済みのテストツールなどの導入もご検討いただき、安全で信頼性の高い製品開発を実現してください。
また、当社では機能安全の適用サポートも行っております。導入や運用に関するご相談もお気軽にお寄せください。

---

＜参考文献＞

IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems
ISO 26262, Road vehicles-Functional safety-