信頼性の高いシステムを開発するには、システム開発中にセキュリティと安全性の懸念を認識する必要があります。 これらはシステム要件と一緒に引き出されないと多くの懸念が見落とされるため、後から追加することは危険です。 残念ながら、SysMLのようなシステムズエンジニアリングの言語は、通常、セキュリティと安全性は考慮されず無視されるので、開発チームが作業をさまざまな形式、言語、ツールに分割することを余儀なくされます。トレーサビリティが制限され、バージョン管理が制限され、ツールが提供できる自動化の使用が制限されます。 この資料では、セキュリティと安全性の側面を他のシステム開発手法と統合する、自動車を対象としたモデルベースのアプローチを紹介します。 これは、言語ユーザーが拡張できる包括的なドメイン固有のモデリング言語を介して実現されます。 このアプローチを、従来のシステム設計および分析フェーズとともに、セキュリティと安全性の懸念がどのように認識されるかについての実際的な例で示します。
 

 

I. 　INTRODUCTION

信頼性の高いシステムを開発するには、システム開発時に安全面を考慮する必要があります。 重要な利害関係者の懸念が損なわれる可能性があるため、後でそれらを追加することは困難であり、エラーが発生しやすくなります。 残念ながら、SysML [12]などのシステムズエンジニアリング言語は通常、セキュリティと安全性は考慮されず無視されるため、開発チームは作業を個別のサブセクションに分割することを余儀なくされます。安全性とセキュリティはさまざまな形式と言語で定義され、明確なトレーサビリティ、共同作業、およびツールが提供できる他の自動化の使用が制限されます。　
この資料では、 安全性とセキュリティの側面を、これら以外のシステム開発に統合する、自動車分野を対象としたモデルベースのアプローチを紹介します。 これは、システムズエンジニアリングのコンセプトと安全性およびセキュリティのコンセプトを組み合わせたモデリング言語によって実現されます。 そしてモデリングはブロックや信号接続などを使用してシステムを指定することだけでなく、言語レベルで、攻撃や脆弱性などのセキュリティ関連の側面と、危険なイベントや機能の欠陥などの安全関連の側面も考慮されます。 したがって、システムの仕様とモデリングに関連する他の側面と同様に、安全性とセキュリティは第一級に扱われて、開発言語に直接存在します。
 
統合言語開発に関する私たちの作業は、自動車会社、研究者、およびツールプロバイダーとの数年にわたる共同作業に基づいています[2]。 システム設計でセキュリティと安全性の懸念がどのように認識されるかについて、実際的な例を使用してアプローチを示します。トレーサビリティをカバーし、ISO26262 [4]、FTA[8]およびFMEA[13]などのいくつかの関連する安全関連の方法、および脆弱性スコア[3]などのセキュリティ関連の手法を自動的に実行します。統合されたモデルベースのアプローチは、開発されるシステムに対して安全性とセキュリティが確実に行われるようにし、編集、トレース、バージョン管理、さまざまな分析とレポートなどの、ツールが提供できる自動化でエンジニアを支援します。
はじめに、モデリング言語がどのように定義され、既存の言語と統合されているかを説明することで、我々のソリューションを紹介します。 次に、実際の例を使用して、このアプローチを示すケーススタディが続きます。まず、既存の自動車用モデリング言語が、ソーシャルエンジニアリングの側面と技術的な側面の、双方からの攻撃をカバーするために、セキュリティモデリングでどのように拡張されるかについて説明します。続いて、ISO26262で定義されている機能安全に厳密に従った安全のための言語拡張について説明します。 また両方の言語拡張についての例も示します。 最後に、安全とセキュリティのための言語の定義に関する経験を共有します。
 

II.　モデリング言語とその統合の定義

このセクションでは、モデリング言語の記述（定義）の実現性（II-A）と、自動車のコンテキストで安全/セキュリティの側面を作成する際に考慮された基本的なモデリングのコンセプトの概要を、現存する言語で説明します（II-BおよびII-C）。 そして、統合モデリングアプローチの主な利点の概要で締めくくります（II-D）。
 

A.　メタモデリング：使用できる構造と構文の説明

プログラミング言語やモデリング言語を含むすべてのコンピュータベースの言語は、いくつかの形式で定義されています。 モデルベースの開発の場合、言語は通常、メタモデルによって定義されます[6]。 メタモデルは、モデルを作成するために使用できる構造と構文を記述します。図１は、 SysMLから取得したメタモデルの非常に小さな断面です。「Block」には、ブロックがブラックボックス要素として扱われるかどうかを定義する「isEncapsulated」と呼ばれる1つのブールプロパティがあります[12]。 このメタモデルに基づくと、「Block」には、そのスーパータイプ「Class」によって定義されるプロパティのような他のプロパティはありません。これらの「Class」固有のプロパティは、この小さなメタモデルから省略されています。
 

図1.　SysMLメタモデルの断片
 
言語定義には通常、作成されたモデルが構文的に完全で、正しく、一貫していることを保証するための制約も含まれています。 これらの制約の一部はメタモデルで直接表現されますが、その他の制約は追加のスクリプトまたは制約定義で定義されます。 前者の例は属性（attribute）が必須ということであり、後者の例は要素が特定の数の接続を持たなければならないというものです。
 
SysMLやUMLなどの汎用モデリング言語の定義には、「Class」や「Block」などの数百の要素と、「isEncapsulated」などのプロパティが含まれています。 それらは大きな言語と見なすことができますが、どちらも安全性やセキュリティに関連する側面をカバーしていません。 たとえば、安全工学の一般的な方法は、フォールトツリーを定義してフォールトツリー分析（FTA）を実行することです[8]。 フォールトツリーは、独立したSysMLとは無関係な独自のメタモデルを持つ言語です。 図2は、フォールトツリーのメタモデルを示しています。
 

図2.　フォールトツリーモデリング言語の完全なメタモデル
 
このメタモデルは僅かな要素から成りますが、それでも完全なFTA言語を定義しています。イベントには2つのタイプがあります。フォールトツリーのルートとして機能する「Component event」と、ある程度の確率でエラーを引き起こすいくつかの「Basic events」です。 どちらの要素にも、抽象スーパータイプ「Event」から継承される「Eventname」プロパティと「Description」プロパティがあります。 さらに、「Basic events」には、イベントが発生する可能性のある頻度を示す「Probability」プロパティがあります。 3番目の要素は、これら3つの要素間の関係を示す「Gate」です。 Gateには、ブール論理のAND、ORなどの値を持つ「Gatekind」プロパティがあります。 最後に、「Link」要素を使用すると、ルートコンポーネントイベントを「Gate」に関連付けることができ、それらを他のゲートまたは基本イベントに再度リンクできます。
メタモデルと関連する制約の定義に加えて、モデリング言語には、人間がモデルを作成して読み取るための表記法も必要です。 表記記号を指定することで、目的に応じたモデリングサポートを提供します。
図3は、図2で定義されたメタモデルに基づくツールでのフォールトツリーモデリングの例を示しています。このモデリングエディタと関連機能は、言語定義に基づいて自動的に提供されます。 モデルの例では、「Flat burns down」は単一のルート要素であるコンポーネントイベントであり、5つの異なる基本イベントを持つ2つの異なるタイプのゲートがあります。 基本的なイベントには障害の可能性があるため、ツールはその後、コンポーネントの障害の確率を計算できます。
フォールトツリーモデリングが、フォールトの他のサブツリーへのリンクなど、他の側面をサポートする必要がある場合は、メタモデルを拡張できます。 したがって、メタモデルへのアクセスを提供するツール（図2のように）を使用すると、ユーザーは、ツールベンダーからの機能制限に我慢することや、その改善を待つ必要なく、モデリング機能を直接拡張できます。 これにより、エンジニアはニーズに正確に適合し、システムの指定方法を制御できるツールを利用できます。 ツールを使用するエンジニアが、直接モデリング言語の開発、改善、進化に関われるということです。
ただし、この例では、フォールトツリーとSysMLのメタモデルが切り離されています。その理由は、そもそもSysMLの定義は、リスクと安全性の懸念を把握することを目的としていなかったためです。 ただし、これら2つの言語間の関係は識別できます。 たとえば、システムブロックの障害を測定できるように、フォールトツリーのルートコンポーネントはSysMLのブロックの少なくとも1つを参照する必要があります。 また、自動車システムの機能安全に取り組んでいる場合は、モデリングサポートは、すべて安全基準で定義されている「Item」、「Hazard」、「HazardousEvents」を表現できる必要があります[4]。 本資料で紹介するモデリングアプローチでは、システムと安全性の間のこの望ましい接続は、セキュリティモデリングも含めて、言語定義によって完全にサポートされています。
次に、自動車システムの開発用に作成されたEAST-ADL言語を使用して、自動車システムに関連するセキュリティと安全性の懸念をカバーする言語拡張機能を紹介します[2]。 ところで、この言語拡張の原則と実践は、特定のモデリング言語に限定されるものではなく、他への応用も同じように可能です。
 

図3. 　図2で定義されたメタモデルに基づくフォールトツリーモデリング。
 

B. 　このアプローチのセキュリティ関連機能

C. 　このアプローチの安全関連機能

機能安全の側面を統合するために、自動車に適用されている機能安全規格ISO26262に準拠しました[4]。 ISO 26262と同様に、「Item」は「Hazards」に関連しており、これらは「Hazardous events」に関連しており、「Severity」、「Exposure」、「Controllability」に基づいて分類できます。 これらの要素はすべて、モデリングオブジェクトやそのプロパティなど、メタモデルの要素でもあります。 図5は、EAST-ADLで定義されている安全性の信頼性モデリングの完全なメタモデルの概要を示しています。
信頼性パッケージには、予備的なハザード分析リスク評価（HARA:Hazard Analysis Risk Assessment）による安全要件の定義と分類、安全ライフサイクルでの役割に応じた安全要件の追跡と分類、および安全制約を使用した安全要件の形式化のサポートが含まれます。 信頼性パッケージ自体は、自動車アーキテクチャモデリング言語EAST-ADLの拡張であり、各フィーチャー、各機能、ハードウェア、および関連する割り当てのモデリングサポートをすでにカバーしています。 この完全なメタモデルは、現在レビュー中の新しいバージョンとともにhttps://east-adl.info/Specification.htmlで説明されています。
メタモデルは、システムアーキテクチャ仕様との統合がどのように確立されるかを示しています。「Item」（ISO 26262で定義）は、車両の機能に接続されています。 図5に示すように、この接続の制約も定義されており、必須になっています（多重度は1 .. *）。 EAST-ADLのメタモデルでは、これらの個々の機能とそのサブ機能は、それらのコンテキストを介して、Hardware Component TypesやFunction Typesなどのシステムアーキテクチャの任意の要素に接続されます。 安全性のための信頼性モデリングを接続するもう1つの形式は、EAST-ADLですでに定義されている「Requirement」を適用し、それを「Safety Goals」および「Feature Flaws」と関連付けることです。
システム内の障害伝播を形式化して評価するために、信頼性パッケージには、エラーモデリングのサポートとSafety Caseでの安全性の証拠の整理も含まれています。 これらは、図5には示されていませんが、メタモデルを介して定義されます。このようなシステム開発のための統合により、ノミナルシステム、およびエラーモデルは、トレースリンクを使用してメタモデルで定義されます。 また、モデリングの労力を最小限に抑えるために、システムモデルに基づく自動エラーモデル生成が可能です。これについては、セクションIVの例で説明します。
 

D. 　統合言語のメリット

セキュリティと安全性の懸念をシステム開発用の言語に統合すると、それぞれに分離された言語、およびツールと形式を使用することに比べて、いくつかの利点があります。

• トレースと分析：システムズエンジニアリングモデルまたは安全/セキュリティ関連モデルの変更をトレースして分析できます。 たとえば、安全関連の「Item」とその「Hazard」に関連する可能性のあるシステム設計のすべての要素を特定できます。 同様に、機能を削除するなどしてシステム設計が変更された場合、関連するセキュリティモデルまたは安全モデルも、不要であると識別されて削除されます。
• コラボレーション：システム設計とセキュリティおよび安全性の側面へのアクセスにより、素早いフィードバックループでのコラボレーションが可能になります。 モデリングツールがファイルベースではなく、共有リポジトリを採用する場合は、リアルタイムでのコラボレーションも可能です。 また、安全エンジニアがシステム設計を表示できるが変更はできないといった、アクセスとコラボレーションを何らかの形で管理する設定も可能です。
• バージョン管理：すべてのモデルを一緒にバージョン管理できます。 特定の時点の全体像を把握するために、さまざまな形式やバージョン管理システムを操作して、さまざまなソースからデータを収集する必要はありません。
• モデルが同じメタモデルを共有すると、現在設計されているシステムの初期安全モデルを自動的に作成するなど、モデルチェックとモデル変換を実行できます。 このように、安全エンジニアはすべての安全モデルを手動で作成する必要がなく、安全分析が計画されたシステムに基づいていることをより確実にすることができます。 トレース機能により、計画されたシステムで行われた変更を追跡することもできます。 また、セクションIIIの例で説明するように、脆弱性スコアを計算するなど、セキュリティの側面を分析できます。
• 最後に、そして最も重要なこととして、セキュリティと安全性の設計は、同じモデル構造を共有するシステム設計と密接に関連するようになります。

 

III. 　セキュリティの例

実際のアプリケーションを説明するために、考えられる攻撃の例として、マルウェア注入の2つのシナリオを示します。1つはソーシャルエンジニアリング攻撃によるもので、もう1つは車両間攻撃によるものです。 最初の例では、攻撃者が自律型車両の車車間通信を攻撃してマルウェアをインストールします。 2番目の攻撃者は、ソーシャルエンジニアリング攻撃を使用して、所有者をだまして悪意のあるソフトウェアをインストールさせます。
 
図6は、自律走行車両で車車間通信を使用して、攻撃する車両を介して攻撃される車両にマルウェアを侵入させる最初のケースと、どのような適切な対策が利用できるかを示しています。自律型車両は、可能な限り安全に交通をナビゲートするために、自分自身とその周囲をよく知っている必要があります。これには、多くのセンサーとその評価データだけでなく、緊急時に他の車両（Vehicle 2 Vehicle）またはその環境（Vehicle 2 Everything）と通信する機能も必要です。自律走行の分野で多くの開発プロジェクトがすでに行われており、運転の安全性を高めることを目指しています。ただし、外部からの攻撃の可能性を生じさせるのは、まさにここでの追加の通信インターフェイスです。攻撃者は、信頼できる車両または環境オブジェクトを装うだけで、攻撃される車両へのデータ接続を確立できます。攻撃者はこのデータ接続を使用してマルウェアをインストールしたり、機密性の高いユーザーデータを盗んだりできます。したがって、車両との通信が事前に十分に認証されていることと、送信されたデータがマルウェアの直接インストールや、メモリオーバーフローを介した内部プログラム構造へのアクセスなどの攻撃の可能性についてチェックされていることを確認する必要があります。
 

図6. 　V2V通信を介したマルウェアの注入
 
2番目の例は、車両の所有者に悪意のあるソフトウェアでインフォテインメントシステムを更新させることを目的としたソーシャルエンジニアリング攻撃を示しています。世界中で高度なデジタル化が進んでいるため、人と直接会うことなくオンラインで行われることがますます増えています。 USBにダウンロードしたファイルからインフォテインメントシステムのアップデートをインストールすることも可能です。ただし、これはまさに、ソーシャルエンジニアリング攻撃の被害者が、破損したソフトウェアをシステムにインストールしてしまい、それがさらなる攻撃へのゲートウェイとして機能するという危険が存在する場所です。図7にそのような例を示します。攻撃者はまず、対象となる被害者の車種、ライセンスプレート番号、およびその他の詳細をスパイします。次に、所有者が簡単に自分でインストールできる、車両の車載コンピュータに必要なサービスアップデートに関する情報が連絡されます。被害者がそれを信じた場合、攻撃者は偽のWebサイト、CD、またはUSBスティックを介してソフトウェアを送信します。被害者は悪意のあるソフトウェアをインストールし、攻撃者はバックドアを介してシステムにアクセスし、たとえば、ハンズフリーキットを介して被害者が行った通話を聞いたり、ナビゲーションシステムを使用して被害者の場所を追跡したりできます。
これに対する対策は、たとえば、公式の自動車工場だけが特別な装置でバイパスできる更新ロックだけでなく、新しいものは必要ないというインフォテインメントシステム自体からの警告であり、何かがインストールされる前に被害者に警告することです。 これをモデル化するために、ソーシャルエンジニアリング攻撃用のSAMメタモデルの最新の拡張機能が使用されました（https://www.in.th-nuernberg.de/professors/BerglerMa/SAM/）。
 
セキュリティのモデリングサポートは、攻撃されたコンポーネントのCVSSスコアの計算と表示をカバーします。 図7では、Base(ベース)スコアと Temporal(テンポラル)スコアの両方が脆弱性に対して「high」であり、それぞれ値は8.8と8.1です。 計算は省略できますが、モデリング時に表示することで、セキュリティエンジニアは、設計の早い段階で考えられる弱点を特定し、対策を開始することが容易になります。
 
SAMは、攻撃のプロパティと脆弱性の間の非常に詳細な相互関係や、それらとアーキテクチャとの関係をキャプチャする包括的な脅威モデリングをサポートしているため、実際には不明であるか、実用的な理由で詳細をキャプチャする必要がないものもあるので、SAMを使用したモデリングは段階的なアプローチが理にかないます。 したがって、さまざまなレベルのモデリングの詳細を紹介します。レベル1は攻撃者の動機のみをモデル化しますが、レベル2と3はより詳細な情報に基づいているため、脅威の状況をより適切に表現できます。 もちろん、このより詳細な表現には、より高度な開発努力が伴います。 モデリングツールは、セキュリティエンジニアが次に検討できる要素を通知することにより、仕様を完成させるのにも役立ちます。
 

図7.　ソーシャルエンジニアリング攻撃によるマルウェアの注入
 

図8.　SAMでの攻撃のレベル1表現
 
レベル1は、SAMを使用する場合のエントリーレベルです。 問題の攻撃について攻撃者の動機のみがわかっている場合に使用されます。 この情報により、状況の実際的な概要、自動車用ソフトウェアシステムのアーキテクチャへの参照、および攻撃の重大度の評価がすでに可能になります。これは、管理の観点から特に重要です。 図8のように、レベル1では動機のみが指定されます。 具体的には、これは「AttackMotivation」のサブクラスの1つ（または複数）、つまり「Harm」、「InformationRetrieval」、「ProductModification」、または「FinancialGain」のいずれかです。
ここでは、攻撃の動機とアイテムのリンクが中心的な役割を果たします。 これは、攻撃によってどのアイテムが危険にさらされているかを考慮することから始めます。 レベル1では、詳細はまだわかっていないため、アイテムは包括的な用語である可能性があります。 たとえば、特定の攻撃では車のバスシステムを攻撃する必要があることが知られています。 ただし、影響を受けるアイテムを正確に特定することはまだできません。 したがって、アイテムのグループを含む「bus system」アイテムを作成できます。 ただし、このアイテムは他の自動車用ソフトウェアアーキテクチャへの接続を形成するため、指定する必要があります。 このアイテムがないと、脅威のモデリングは切り離され、他のアーキテクチャとの関連性がなくなります。
 
レベル2では、より詳細な脅威分析を行うことができます。 特に属性「breaksSecurityGoal」に関して、攻撃の詳細がわかったらすぐに、レベル2での系統的な方向付けが推奨されます。 攻撃に関する（選択された）詳細の収集は、一方ではそれほど時間のかかるものではありませんが、他方ではレベル1と比較して脅威の状況の非常に優れた評価を提供します。分析の焦点はもはや人間の経験ではなく、技術的な実現可能性にあるからです。エンティティAttackは、AttackMotivationの属性breaksSecurityGoalsを継承します。 ただし、攻撃の1つの動機は複数のサブ攻撃に分割でき、異なるbreaksSecurityGoalsを持つ可能性があることに注意することが重要です。
breaksSecurityGoalsに加えて、followUpAttacksへの参照もモデル化する必要があり、影響を受けるアイテムへの参照を確立する必要があります。 攻撃に関連するリスクは、定性的（どのSecurityGoalsが破られているか）または定量的（いくつのSecurityGoalsが破られているか）に評価できます。 これは、攻撃の動機に基づいてのみ分析が実行されるレベル1と比較して改善された評価を表しています。
 

図9.　SAMでの攻撃のレベル2表現
 
攻撃の重大度のより良い評価は、スコアの計算から得られます。たとえば、Common Vulnerability Scoring System（CVSS、レベル3を参照）に類似します。 レベル2は、このスコアを計算するのに十分な詳細ではありませんが、セキュリティ専門家の経験に基づく初期評価を作成し、スコアエンティティに文書化することができます。このスコアは経験に基づくため、経験値が利用できない場合は、スコアを省略できます。
 

ISO/SAE 21434は、車両システムへのサイバー攻撃の完全なリスク評価分析を確実にするために2021年から導入されています[5]。 この規格は、車両システムのネットワーク化が進んでいるため、サイバー攻撃に対抗する必要があるために開発されました。 この規格は、UNECE規制R 155「サイバーセキュリティおよびサイバーセキュリティ管理システム」に関連しています。 ISO 21434の適用は、認証を容易にするための構成要素と見なされます。 ただし、ISO 21434はR 155のすべての要件を網羅しているわけではありません。さまざまな利害関係者が理解できるSAMのレポートシステムを開発するには、ISO 21434に基づいてこれを行うのが理にかなっています。ISO/SAE 21434準拠の脅威分析とリスク評価を実行する主な手順は、次のとおりです（理想的な線形実行の順序で）。
 
1.アイテムの定義（セクション9.3）
2.資産の識別（セクション15.3）
3.脅威シナリオの特定（セクション15.4）
4.衝撃評価（セクション15.5）
5.攻撃経路分析（セクション15.6）
6.攻撃の実現可能性の評価（セクション15.7）
7.リスク値の決定（セクション15.8）
8.リスク対応の決定（セクション15.9）
9.サイバーセキュリティの目標（セクション9.4）[WP-09-03＆RQ-09-07]
10.サイバーセキュリティクレーム[WP-09-04＆RQ-09-06]
11.サイバーセキュリティのコンセプト（セクション9.5）
 
これらのほとんどは、ポイント1、2、3、4、9、10、および11を含め、すでにSAMによって実装されています。したがってISO 21434に基づくレポートシステムを作成するには、5、6、7、および8のみをSAMに追加する必要があります。9から11は、ドメイン固有だけでなく全体的に適用され、サイバーセキュリティの側面もカバーしているという事実によっても満たされます。
 

IV. 　安全例

次に安全性に焦点を当て、安全性のためのメタモデル拡張により可能な信頼性モデリング、エラーモデリング、および自動FTA/FMEA分析について説明します。 図10に、PowerWindowControllerの信頼性モデルを示します。 この信頼性モデルは、メタモデルで定義されている機能安全規格ISO 26262に厳密に準拠しています（図5を参照）。 図10の上部では、PowerWindowControllerがアイテムと見なされています。 次に、ハザード「ウィンドウ障害物が検出されません」が指定され、HazardousEvent「ウィンドウが停止しません」に関連付けられます。 この危険なイベントは、ウィンドウアクションが要求されるユースケースに関連しています。 また、図10には記載されていませんが、トラフィックの状況、環境、または動作モードにリンクされている他のシナリオにリンクされている場合もあります。 言い換えると、モデルはISO 26262に基づいて定義されたメタモデルに従います。
この例では、Severity、Exposure、Controllability、およびASIL値が定義されているハザード分析の作業についても説明します。 信頼性モデルは、安全な状態「PreventMovement」で安全目標も定義します。 要件モデルですでに定義されている要件＃7および＃9を使用して、ASILレベルを許容レベル（B）に下げます。
統合されたメタモデルのおかげで、安全設計はシステムモデリングから分離されていません。 統合は、メタモデルに従って、1つ以上の機能を参照できるPowerWindowControllerと呼ばれる「Item」によって実現されます。 この例では、このアイテムは車両のPowerWindow機能を参照しています。 この機能は、EAST-ADLのフィーチャーモデルで定義されており、図11に示されています。
 

図10.　PowerWindowControllerの信頼性モデル
 
Power Windowの機能は、その機能アーキテクチャとともにシステムズエンジニアによって定義されます（図12を参照）。 フィーチャーモデルの各フィーチャーは、機能アーキテクチャの個々の要素にマップされます。 これにより、システム設計と安全設計の間のトレーサビリティが可能になります。
ただし、図12のようなシステム設計は、faults、failures、failure ratesなどの一般的な安全面を識別およびキャプチャしないため、安全設計には直接適していません。設計モデルには、安全作業に関係のない情報も含まれており、安全エンジニアにとって不必要な複雑さが加わります。 たとえば、図12に示す小さなシステムについて考えてみます。これは、PowerWindowコントローラーの機能アーキテクチャ、つまりその機能、ポート、およびそれらの間の接続を示しています。 機能は分類され、より詳細な内部階層構造を持ち、それらのポートにはインターフェイスとデータタイプがあります。 関数の分類やデータタイプの定義など、これらの側面の一部は安全設計には直接関係しませんが、実装（AUTOSAR ARXML、Simulinkモデルなど）を生成するために必要です。
 

図11.　パワーウィンドウのフィーチャーモデル
 
faultsやfailure logicなどの安全関連情報を設計モデルに直接追加すると、詳細が多すぎてモデルがすぐに複雑になるため、多くの場合、実用的ではありません。 安全性分析では、設計とは異なり、通常、さまざまな分析シナリオをカバーするいくつかのモデルが必要です。 1つの解決策は、設計仕様から初期安全モデルを生成することです。 たとえば、図13は、このような変換の結果を示しています。図12に示すシステム設計から作成された初期エラーモデルです。次に、エラーモデルは、failures、faults、およびerror typesに焦点を当てた安全性分析のために詳細に説明されます。 次に、安全エンジニアは、このモデルにエラー動作を追加したり、安全性の他の側面を追加したりできます。たとえば、図13のように、障害物検出のエラーを分析するために、FailureOutポートが追加されます（モデルの右上に、伝播用の青い太い境界線があります）。　
エラーモデリングを使用すると、安全エンジニアは実際のシステム設計を変更することなく、さまざまな障害や障害ロジックを指定できます。 それでも、エラーモデルから名目上の計画されたシステムの説明へのリンクがあります。 エラーモデルは障害ロジック（ブールおよび時間）を指定できるため、モデルは自動化されたフォールトツリー分析（FTA）および故障モード影響分析（FMEA）の基礎としても機能します[8][13]。 これは、（前の図3のように）手動でフォールトツリー図を作成するのではなく、それらが生成されることを意味します。 この目的のために、エラーモデルを、FTA/FMEAツールに必要な形式に変換するモデル変換を実装しました。 変換が完全に自動化されているため、FTAとFMEAを実行するためのコストと労力が大幅に削減されます。 図14は、エラーモデルからFMEAの分析ツールへの変換を実行した結果を示しています。
モデルベースのアプローチによる安全性が重要な機能の開発は、信頼性モデルでのハザード分析とリスク評価から始まり、FMEAのエラーモデルで詳細に説明され、安全目標と安全要件の検証で終わります。 モデルには必要な情報が含まれているため、機能的および技術的な安全性のコンセプトや、安全性目標の検証と妥当性確認などのドキュメントを生成できます（[14]などで実行）。
これらの自動化により、安全作業がより簡単かつ迅速に実行できるようになるだけでなく、エラーが発生しやすい手動のルーチンタスクが削減されます。 おそらく最も重要なことは、安全性分析からのフィードバックをシステム設計で早期に認識できるようにすることです。
 

図12.　PowerWindowコントローラーの機能アーキテクチャ
 

図13.　PowerWindowコントローラーの機能アーキテクチャ
 

V.　言語定義の経験

セキュリティと安全性のモデリングを実装する今回の取り組みは、MetaEdit＋というメタモデリングツールで実装済みであったEAST-ADL(自動車システム開発言語)をベースにしました。 このため、拡張機能（図4および5のように）を指定し、それらを既存のメタモデルにリンクするだけで済みました。 MetaEdit+ での作業とプロセスは、メタモデルの拡張と安全性とセキュリティとの統合に適した言語構造 (メタモデル要素) を持っている限り、AADL や SysML などの他の言語でも同じです。
 

図14.　フォールトツリー分析と故障モード影響分析の結果
 
言語定義の手順は次のとおりです。
 
1.拡張機能のメタモデルを定義し、それらを既存の言語定義とリンクします。リンクにより、モデル要素間の再利用、参照、およびトレースが可能になります。
2.仕様の一貫性を維持し、構文の完全性と正確性を確保するための制約を設定します。
3.ドメインに適合する、または類似する表記法を定義します（たとえば、安全性、セキュリティ）。
4.モデルのチェックとトレース用のジェネレーターを実装し、FMEAやCVSSのデータなどのさまざまな種類の成果物を生成します。
 
最初の2つのステップについて、この資料のセクションIIでメタモデルで実現されることを説明しました。 ステップ3の表記を定義することはシンボル定義を扱い、Moody[10]による作業はここで直接適用できます。 表記法の実際の実装は、プログラミングが必要なものもあれば、追加の作業をあまり必要とせずに画像としてインポートできるものもあるため、ツールによって異なります[9]。
ステップ4のジェネレーターでは、モデルチェック、トレース、レポート、コード生成の自動化、シミュレーションなど、更なる自動化も行えます。今回の例では、ジェネレーターは、故障モード影響分析（FMEA）を実行し、脆弱性スコアを計算するための外部ツールを対象としました。 どちらの場合も生成されるフォーマットの仕様が利用可能であり、ジェネレーターの実装は容易です。 2番目の種類のジェネレーターは、トレースレポートまたはその他のさまざまなドキュメントで作業を報告するジェネレーターでした。 これらは同じMetaEdit+ツールで実行されました。　
モデリングサポートを作成する作業は、主に適切なレベルの抽象化を識別してテストすることです。 安全モデリングサポートの工数は測定しませんでしたが、セキュリティモデリングサポートでは初期メタモデル（図4のように）を作成した後、モデリングツールの実装は2週間で1人で行われました。 検証と妥当性確認は、別の担当者によって一般的なモデリングを介して行われました。
ツールが言語定義へのアクセスを提供する場合、モデリングサポートはニーズに基づいて段階的に拡張できることは非常に重要です。 たとえば、セキュリティと安全性に対応するメタモデル定義は、モデリング要件の変更と言語の使用法からの学習を経て進化しました。 これは、本資料で提案したアプローチが、今後可能性のある新しい要件にも対処できるということです。 メタモデルとジェネレーターを定義できることは、[14]で説明されるように、企業固有のニーズをサポートします。 また、ADASシステムの開発において、EAST-ADLのモデリングサポートが安全対策などのコンセプトで拡張されているケースも認識しています。
 

VI. 　CONCLUSIONS

安全性とセキュリティの懸念をシステム開発に統合するためのモデルベースのアプローチを紹介しました。 これは、従来のシステムおよびソフトウェアモデリング言語で慣れ親しんだものと同じように、言語レベルで安全性とセキュリティのモデリングサポートを提供する統合モデリング言語を介して実現されます。このアプローチが実際の例で適用されることを示しました。 この統合の利点は次のとおりです。
 

• 共同開発：システム設計へのアクセス、およびセキュリティと安全性の側面へのアクセスにより、高速フィードバックループでコラボレーションを強化します。
• 開発されたシステムのさまざまな側面間で、モデリング時でもトレースと分析が可能です。
• すべての作業項目を一緒にバージョン管理できます。特定の時点の全体像を把握するために、さまざまな形式やバージョン管理システムを操作して、さまざまなソースからデータを収集する必要はありません。
• 自動分析と変換：現在計画されているシステム設計の初期安全モデルを自動的に作成するなど、結合されたモデルをチェックおよびモデル変換の入力として使用できます。
• セキュリティと安全性の設計は、同じモデル構造を共有するシステム設計と密接に関連するようになります。

 
EAST-ADLとその拡張機能を使用すると、これらの利点はすでに利用可能です[2]が、他のモデリング言語が拡張される場合も同じ原則を適用できます。 たとえば、EAST-ADLの代わりにSysMLを拡張するか、EAST-ADLの信頼性メタモデルの代わりにRAAML[11]のメタモデルを拡張します。
 

REFERENCES

[1] Bergler, M. et al. Social Engineering Exploits in Automotive Software Security: Modeling Human-targeted Attacks with SAM. Proceedings of the 31st European Safety and Reliability Conference (ESREL 2021), 2021
[2] EAST-ADL, 2021, http://www.east-adl.info/Specification.html [Accessed 21 April 2022].
[3] First, Common Vulnerability Scoring System version 3.1: Specification Document, 2019, https://www.first.org/cvss/specification-document [Accessed 21 April 2022].
[4] ISO Functional Safety, 26262-1, 2018
[5] ISO/SAE 21434:2021 - “Road vehicles - Cybersecurity engineering” https://www.iso.org/standard/70918.html [Accessed 16 May 2022]
[6] Kelly, S., Tolvanen, J.-P., Domain-Specific Modeling: Enabling full code generation, Wiley-IEEE Computer Society Press, 2008
[7] Kritzinger, D., Fault tree analysis, in Aircraft System Safety, Elsevier, 2017
[8] Lee, W. S., Grosh, D. L., Tillman, F. A., Lie C. H., Fault Tree Analysis, Methods, and Applications - A Review. IEEE Transactions on Reliability, Volume: R-34, Issue: 3, Aug. 1985.
[9] MetaCase, MetaEdit+ User’s Guide. [Online]. Available at: https://metacase.com/support/55/manuals/, 2018 [Accessed 21 April 2022].
[10] Moody, D., The Physics of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering, IEEE Transactions on Software Engineering, vol. 35, no. 6, 2009.
[11] OMG, Risk Analysis and Assessment Modeling Language (RAAML), https://www.omg.org/spec/RAAML/1.0/Beta1/PDF, 2021 [Accessed 21 Jan 2022].
[12] OMG, System Modeling Language, version 1.6. [online] Available at: https://www.omg.org/spec/SysML/, 2019 [Accessed 21 April 2022]
[13] Reifer, D., Software Failure Modes and Effects Analysis, IEEE Transactions on Reliability, Volume: R-28, Issue: 3, 1979.
[14] Sari, B., Fail-Operational Safety Architecture for ADAS/AD Systems and a Model-driven Approach for Dependent Failure Analysis. Springer, 2020.
[15] SEI, Architecture Analysis and Design Language (AADL), https://www.sei.cmu.edu/our-work/projects/display.cfm?customel_datapageid_4050=191439,191439　[Accessed 13 May 2022]
[16] Zoppelt, M. Tavakoli Kolagari, R., SAM: A Security Abstraction Model for Automotive Software Systems, ISSA/CSITS@ESORICS, 2018.
[17] Zoppelt, M., Tavakoli Kolagari, R., UnCle SAM: Modeling Cloud Attacks with the Automotive Security Abstraction Model, 2019.