AUTOSAR アーキテクチャでは、アプリケーション ソフトウェアは RTE の上に位置し、相互接続された AUTOSAR SWC で構成され、これらのコンポーネントはアプリケーション ソフトウェア機能のさまざまなコンポーネントを原子的にカプセル化します。
図 1: アプリケーション ソフトウェア
AUTOSAR SWC はハードウェアに依存しません。したがって、利用可能なあらゆる ECU ハードウェアに統合できます。 ECU 内および ECU 内での情報交換を促進するために、AUTOSAR SWC は RTE 経由でのみ通信します。
AUTOSAR SWC には、内部機能を提供する多くの関数と変数が含まれています。 AUTOSAR SWC の内部構造、つまり変数と関数呼び出しは、ヘッダー ファイルを通じて一般公開されないようになっています。外部 RTE 呼び出しのみがパブリック インターフェイスで有効になります。
図 2: SWC
AUTOSAR SWC実行時に呼び出す必要がある関数も含まれています。これらの C 関数は、AUTOSAR では Runnable と呼ばれます。
ランナブルは単独で実行することはできません。OS の実行可能エンティティに割り当てる必要があります。このような割り当ては、Runnable の関数呼び出しを OS タスク本体に挿入することで実行できます。
ランナブルは、呼び出し側 OS タスクのコンテキストで周期的および/またはイベント駆動型で実行されます。 Runnables によるタスクの割り当ては、図 3 および図 4 に従って実行されます。
#図 3: AUTOSAR 階層型ソフトウェア アーキテクチャ - ランナブル マッピング#2. OS-アプリケーション
#図 4: SWC と OS アプリケーションのマッピング
AUTOSAR OS アプリケーションは、まとまった機能単位を形成する OS オブジェクト (タスク、ISR、スケジュール、カウンタ、アラームなど) のコレクションです。同じ OS アプリケーションに属するすべてのオブジェクトは相互にアクセスできます。
OS アプリケーション内の OS オブジェクトは、異なる AUTOSAR SWC に属する場合があります。 RTE は、OS アプリケーションのすべてのメンバーが無制限にアクセスできるメモリ領域を実装し、SWC 間の効率的な通信を促進します。
OS アプリケーションには 2 つのカテゴリがあります:
信頼できる OS アプリケーション: 「信頼できる OS アプリケーションの実行を許可する」監視または保護機能は実行時に無効になります。OS モジュールのメモリおよび API に無制限にアクセスできる場合があります。信頼できる OS アプリケーションは、実行時にタイミング動作を強制する必要はありません。プロセッサによってサポートされている場合、特権モードでの実行が許可されます。
SWC の内部関数呼び出しと変数は、その定義が外部インターフェイスのヘッダー ファイルによって提供されないため、他の SWC には公開されていません。そのため、変数を介した直接通信や他の SWC の実行が行われます。計画できません。コード。
図 5 のコード共有の例は、これを示しています。コード共有は SWC 内でのみ許可され、OS アプリケーションの SWC 間で共有することはできません。他の SWC との通信は RTE 経由で実行する必要があります。 Runnable4 は SWC2.2 に属する機能を実行できない場合があります。
図 5: OS アプリケーションでのコード共有
AUTOSAR ECU のアプリケーション ソフトウェアは、安全関連 SWC と安全関連以外の SWC で構成できます。異なる ASIL レベルを持つ SWC 間の無干渉性は、ISO26262 の要件に従って保証される必要があります。
AUTOSAR OS は、OS アプリケーションを専用のメモリ領域に配置することで、メモリ関連の障害の影響を受けません。このメカニズムはメモリ分割と呼ばれます。 1 つの OS アプリケーションのメモリ パーティションで実行されるコードは他のメモリ領域を変更できないため、OS アプリケーションは相互に保護されます。 AUTOSAR OS 仕様の対応する要件を表 1 に示します。
表 1: AUTOSAR OS-OS-アプリケーションのメモリ パーティション
アプリケーション ソフトウェアは、異なる ASIL レベルの SWC で構成できます。ただし、異なる ASIL 評価を持つ SWC を同じ OS アプリケーションに割り当てないでください。メモリ パーティショニングでは、同じ OS アプリケーションに割り当てられた SWC 間の干渉耐性は提供されません。 OS は、他の OS アプリケーションが不正なアクセスを実行するのを防ぐだけです。障害のある SWC が同じ OS アプリケーション内の他の SWC のメモリ領域を変更することを妨げません。
注: タスクレベルのパーティショニングの詳細については、「後続のパーティショニング」を参照してください。
5. SWC でのメモリ パーティショニング混合 ASIL SWC は、異なる ASIL 評価の Runnable で構成される場合があるため、これらの Runnable の実行間を干渉しないサポートが必要です。環境。次の理由により、SWC の異なるランナブルを異なるメモリ パーティションで実行することはできません。
メモリ パーティションは OS アプリケーション レベルで実行されます。図 3 と図 4 に示すように、SWC は 1 つの OS アプリケーションにのみ割り当てることができるため、メモリ パーティションは 1 つだけ存在します。また、SWC Runnables は OS アプリケーションのタスクからのみ呼び出すことができます。
図 6 に示すように、SWC ランナブルは複数の OS アプリケーションのタスクに分散できません。
#図 6: SWC とパーティション
メモリ パーティションは使用できません同じ SWC 内の別々の Runnable。 SWC に異なる ASIL を持つランナブルを含める必要があり、これらのランナブルを干渉することなく独立して実行する必要がある場合、OS アプリケーション レベルでのメモリ パーティショニングでは十分ではなく、タスク レベルでメモリ パーティショニングを実行する必要があります。この方法を図 7 に示します。
とタスク レベルメモリ パーティション関連の要件は、AUTOSAR OS 仕様の表 2 にリストされています。 「かもしれない」という弱い単語の使用は、AUTOSAR OS ではタスクレベルのパーティショニングの実装がオプションであることを示しています。したがって、すべての AUTOSAR OS 実装がタスク レベルのメモリ パーティショニングをサポートしているわけではありません。
#表 2: AUTOSAR OS 要件 – タスク レベルのメモリ パーティショニング
6.メモリ パーティショニングの実装
メモリ パーティショニング メカニズムを使用して、システムおよびソフトウェア レベルでさまざまな技術的セキュリティ概念を実装できます。図 8 は、すべての基本ソフトウェア モジュールが信頼/監視モードのメモリ パーティション (図 8 で赤で強調表示) で実行される実装例を示しています。一部の SWC は論理的にグループ化され、別個の非信頼/ユーザーモード メモリ パーティション (緑色で強調表示) に配置されます。選択したソフトウェア モジュールは、ベース ソフトウェア モジュールと同じトラステッド/マネージド モード メモリ パーティションに属します (図 8 で赤で強調表示されている 4 番目の SWC を参照)。複数の非信頼/ユーザー モード パーティションが存在し、それぞれに 1 つ以上の SWC が含まれる場合があります。
非トラステッド/ユーザーモード メモリ パーティションでの SWC の実行は制限されており、他のメモリ領域を変更できませんが、トラステッド/モニタ メモリ パーティションでの SWC の実行は制限されません。
安全関連アプリケーションに使用される最新のマイクロコントローラーは、専用ハードウェア (メモリー保護ユニット (MPU)) によるメモリーの分割をサポートしています。
注: メモリ スライシングは、MPU または同様のハードウェア機能を備えたマイクロコントローラーに実装されると想定されています。
一般的な MPU 実装では、信頼できないアプリケーションがマイクロコントローラーのアドレス空間の複数のパーティションにアクセスできる可能性があります。アクセス制御は、読み取り、書き込み、および実行アクセスの組み合わせとして定義されます。 MPU 構成はモニター モードでのみ許可されます。
注: 一部のマイクロコントローラー実装では、MPU がプロセッサ コアに統合されています。したがって、MPU は関連するコアへのアクセスのみを制御します。他のバス マスター (DMA コントローラーや他のコアなど) は、このセグメント化された MPU インスタンスによって制御されません。
次の表と使用例は、メモリ保護ユニットの構成がシステム要件から導出される場合に考えられる一連のシナリオを示しています。注: この表は、使用されている特定のハードウェア デバイスの機能については完全ではない可能性があります。
#表 3: メモリ保護構成スキーム
## アイコンの説明:
XX – 保護が必要です
O – オプションの保護
注: パフォーマンスの観点から、バスの競合、インターフェイスの調停などによる副作用が発生する可能性があります。
ユースケース 1: SWC は同じパーティション内にあります。
機能安全メカニズム メモリ パーティショニングは、メモリおよびメモリ マップされたハードウェアへのアクセスを制限することで保護を提供します。あるパーティションで実行されたコードは、別のパーティションのメモリを変更できません。メモリ パーティションは、メモリ マップド ハードウェアだけでなく、読み取り専用メモリ セグメントも保護できます。さらに、ユーザー モードで実行される SWC は、再構成などの CPU 命令へのアクセスが制限されます。
メモリ分割メカニズムは、マイクロコントローラ ハードウェア (メモリ保護ユニットやメモリ管理ユニットなど) のサポートによって実装できます。不正なメモリ アクセスを検出して防止するには、マイクロコントローラー ハードウェアを OS によって適切に構成する必要があります。次に、信頼できない/ユーザー モード メモリ パーティションで SWC の実行を監視します。
非信頼/ユーザーモード パーティションでメモリ アクセス違反または CPU 命令の競合がある場合、誤ったアクセスはブロックされ、マイクロコントローラー ハードウェアは例外をスローします。 OS と RTE は、パーティションのシャットダウンを実行するか、このパーティションのすべてのソフトウェア パーティションを再起動することにより、誤ったソフトウェア パーティションを排除します。
注: OS の実際の応答は、保護フックの実装を通じて構成できます。詳細については、OS SWS[i] のドキュメントを参照してください。
注: AUTOSAR ドキュメント「アプリケーションレベルのエラー処理手順」[ii] には、エラー処理に関する追加情報が記載されています。ドキュメントでは、エラー処理がどのように実行されるか、必要なデータ (代替値など) がどこから取得できるかについて説明されています。さらに、このドキュメントには、AUTOSAR で OS アプリケーション/パーティションの終了と再起動を実行する方法に関する詳細な手順 (ユーザー マニュアル) が記載されています。
1. 同じ ASIL 評価を持つ SWC のメモリ パーティション。
ISO26262 標準では、異なる ASIL レベルの SWC 間の免疫が必要です [iii]。ただし、この規格では、同じ ASIL 定格を持つ SWC 間の干渉耐性は要求されていません。
多数の SWC で構成される OS アプリケーションの使用を許可します。単一の SWC が競合を引き起こし、メモリ パーティション全体がシャットダウンまたは再起動される場合、このメモリ パーティションで機能している他のすべての SWC も影響を受けます。
#2. メモリ パーティショニングは、信頼できる OS アプリケーションでは使用できません。
信頼/監視モードのメモリ パーティションの実行は、OS および一部の MMU/MPU ハードウェア実装によって制御されません。
#3. タスク レベルはメモリ パーティショニングをサポートしていません。
#タスクレベルのパーティショニングの実装は、AUTOSAR OS の実装には必要ありません。したがって、OS アプリケーションの干渉耐性はサポートされない可能性があります。
#4. メモリのパーティショニングによるパフォーマンスの損失。
アプリケーション ソフトウェアのアーキテクチャとマイクロコントローラー ハードウェアおよび OS の実装によっては、メモリ パーティションを使用するとパフォーマンスが低下する可能性があります。このペナルティは、単位時間あたりに実行されるコンテキスト切り替えの数に応じて増加します。
5. 基本的なソフトウェア パーティションはありません。
ベース ソフトウェアの現在の仕様では、さまざまなベンダーのさまざまな ASIL レベルを持つベース SWC のメモリ パーティショニングが指定されていません。
以上がメモリの分割と実装された機能安全メカニズムの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
