目次
1. AUTOSAR マルチコア オペレーティング システム
1. AUTOSAR マルチコア オペレーティング システム
1.1、OSアプリケーション
ＡＵＴＯＳＡＲマルチコアオペレーティングシステムはパーティション機構を採用しており、マルチコアプロセッサの各コアには少なくとも１つのＯＳアプリケーション（ＯＳアプリケーション）が割り当てられる。各 OS アプリケーションには、タスク、割り込みサービス、カウンター、アラーム、ディスパッチ テーブルなどの関連要素が含まれており、これらを総称してオペレーティング システム オブジェクト (OS オブジェクト) と呼びます。
各 OS アプリケーションはアクセス権を定義する必要があり、AUTOSAR オペレーティング システムには、信頼できる OS アプリケーションと信頼できない OS アプリケーションという2 種類の OS アプリケーションがあります。信頼できる OS アプリケーションに含まれるオブジェクトには、すべてのフラッシュ、LMU (ローカル メモリ ユニット)、CSA (コンテキスト保存領域)、周辺ユニットを含むほとんどのメモリに対する読み取りおよび書き込み権限がありますが、他の非アクティブなスタック権限は読み取れません。信頼できない OS アプリケーションに含まれるオブジェクトには、現在アクティブなスタック、現在の OS アプリケーションのデータ、LMU 内の共有データなど、いくつかのメモリの読み取りと書き込みの権限しかありません。
信頼できる OS アプリケーションと信頼できない OS アプリケーションのオブジェクトの読み取りおよび書き込み権限を次の図に示します。Corel を例にとると、濃い影の部分は、信頼できる OS アプリケーションと信頼できない OS アプリケーションのオブジェクトに読み取りと書き込みの権限があることを示し、明るい影の部分は、信頼できる OS アプリケーションのオブジェクトに読み取りと書き込みの権限があるが、信頼できない OS アプリケーションのオブジェクトを示します。オブジェクト内の は読み取りと書き込みの権限を持っておらず、白い部分はどちらにも読み取りと書き込みの権限がないことを意味します。
1.2、マルチコアOSのソフトウェアパーティション
パーティショニング (パーティショニング)は、特定のパーティションの障害が同じ ECU 上の他のパーティションに影響を与えるのを防ぐ目的で、 マルチコア オペレーティング システムの一部の機能または要素をハードウェア レベルで分割することです。AUTOSARマルチコアオペレーティングシステムでは、その実装方法は、メモリ空間領域に異なるメモリ間隔を定義し、その中でそれぞれのパーティションのソフトウェアコードを実行することにより、相互干渉を防ぎます。
AUTOSAR OSでは、OSアプリケーションを通じてメモリを分割することで簡易メモリ保護機能を実現できます。一般にOSのアプリケーションはパーティションに対応するように設計されており、パーティションの例を下図に示しますと、OS-Application Aに対応するメモリパーティションPartition1にはセキュリティレベルのないTask1が割り当てられ、セキュリティレベルが設定されているタスクTask2とTask3が割り当てられています。ソフトウェアと複合ドライバは両方とも、OS アプリケーション B に対応するメモリ パーティション Partition2 内のグループに割り当てられ、2 つのパーティションは互いに独立しています。パーティションは、対応する OS アプリケーションがアクセスできるメモリ アドレス範囲を定義します。
トラステッド OS アプリケーション Os Application_Core0-Nontrusted では、下図に示すように、タスクを異なる OS-Application にマッピングすることで、セキュリティ レベルの異なるタスクと非セキュア タスク間のメモリ空間をソフトウェア レベルで実現できます。セキュリティ クラスが存在するクラスとタスクの間のメモリ空間。
1.3. タスクのスケジュール設定
タスクのスケジューリング方法に関しては、AUTOSAR マルチコア オペレーティング システムは OSEK システムとまったく同じであり、タスクや割り込みの優先順位を主な要因として決定されます。同一プロセッサコア上では優先度の高いタスクや割り込みが先にスケジュールされ、同じ優先度の場合は特定の起動順序に従って決定されます。異なるプロセッサ コア上では、タスクのスケジューリングは相互に影響しません。つまり、AUTOSARマルチコア オペレーティング システムはマルチコア プラットフォーム上で並行して実行されます。車載用マルチコアオペレーティングシステムであるAUTOSARオペレーティングシステムでは、タスクや割り込みが静的に割り当てられており、システム運用中に動的に移動することができない理由は前回の記事で説明しました。
AUTOSAR マルチコア オペレーティング システムのタスク スケジューリング図を次の図に示します。スケジューリング ルールによれば、複数のタスクが同時に呼び出された場合、つまり同時に実行可能状態になった場合、図に示すように、最も優先度の高いタスクが最初に実行状態になります (タスク T2)。コア 0 ではタスク T3、コア 1 ではタスク T3、コア 2 ではタスク T3 タスク T5 では、3 つのタスクが同時に実行状態になります。各コアのタスクは独立して実行され、それらの優先順位は相互に影響しません。
さらに、AUTOSAR マルチコア オペレーティング システムは、タスクのスケジューリング モードの選択をサポートします。スケジューリング モードは、フル スケジューリングと拒否スケジューリングの 2 つのモードに分けられます。フル スケジューリング モードでは、タスクは通常の実行状態中に優先度の高いタスクまたは割り込みによってプリエンプトされますが、拒否スケジューリング モードでは、タスクは他のタスクまたは割り込みによってプリエンプトされません。上記の現象から、タスク割り当てプロセスでは、アプリケーションで重要な役割を果たす重要なタスクには高い優先度を割り当てる必要があり、同様に重要なタスクの周期が短いほど、割り当てられる優先度は高くなります。
1.4. コア間のタスク同期
マルチコア AUTOSAR OS では、コア間でイベントをトリガーできます。これは、コア間の同期がイベント トリガーの形式で実現できることも意味します。
下図に示すように、Core0 のタスク R1 が実行されると、setEvent を通じて Corel の R2 が起動されます。このイベントは、変数の書き込み、読み取り、またはタスクの実行の終了などであり、R2 は権限を取得できます。 Corel のタスク スケジューリングが許可する場合、R2 は CPU の実行能力を取得できます。このようにして、Core0とCorelのタスク同期機構を実現することができる。この方法は、イベントによってトリガーされるタスクや、定期的に実行されるタスクの同期に適しています。定期的に実行されるタスクは、アラームまたはスケジューラを使用して定期的にイベントをトリガーするだけで済みます。(イベントトリガー)
以下は、イベント トリガー を使用したマルチコア タスクの同期のテストです。Core0 の Alarm を使用して、タスク Core0_Task_1 を 1 ミリ秒の周期で定期的にトリガーします。Core0_Task_1 でsetEventを呼び出してCorel_Task_2 をトリガーし、両方のタスクのピン P2.0 と P2.1 をそれぞれ反転します。両方のタスクが正しく、同時にトリガーされた場合、P2.0 ピンと P2.1 ピンは 500 Hz の周期の PWM 波を出力します。試験結果は下図に示されており、図の上の波形がP2.0、下の波形がP2.1です。
テスト結果から、Core0_Task_1 と Corel_Task_2 が同時にトリガーされ、予想どおり周波数が 500 Hz であることがわかります。
もう 1 つの方法は、スケジューラを使用してタスクの同期を実現することです。次の図に示すように、アラームは 1 つのタスクのみをトリガーできるため、タスクの同期は実現できません。スケジューラは、異なるコアの複数のタスクを同時にトリガーできます。このメソッドは、定期的に実行されるタスクの同期にのみ使用されます。次の図と次の図は、スケジューラを使用して開始タスクを同期するテストを示しています。まず、1 ミリ秒の周期のスケジュールを追加して構成し、次にそのスケジュールを使用して 2 つのコアのタスク Core0_Task_1 と Corel_Task_2 をそれぞれトリガーし、2 つのタスクのピン P2.0 と P2.1 を反転します。
両方のタスクが正しく、同時にトリガーされた場合、P2.0 ピンと P2.1 ピンは 500 Hz の周期の PWM 波を出力します。試験結果は下図に示されており、図の上の波形がP2.0、下の波形がP2.1です。
テスト結果から、Core0_Task_1 と Corel_Task_2 が同時にトリガーされ、予想どおり周波数が 500 Hz であることがわかります。
1.5、カウンター、アラーム、スケジュール
AUTOSAR マルチコア オペレーティング システムでは、システム コンポーネントのカウンタ ( Counter ) がタスク スケジューリングの時間基準として使用され、ハードウェア プラットフォームも密接に関連しています。上記によると、アプリケーションのシステム コンポーネントの 1 つであるカウンターは1 つのコアに排他的です。つまり、異なるコア上のカウンターを異なるコアでのタスク スケジューリングのベンチマークとして使用することはできません。
AUTOSAR オペレーティング システムにおけるタスクのスケジューリングは、アラーム (Alarm) またはスケジューリング テーブル (Schedule Table) を通じて実現されます。一般に、アラームとディスパッチ テーブルは両方とも、同じコア上の対応するカウンタに従ってトリガーされ、特殊な状況下では、他のコア上のアプリケーションによって呼び出される場合もあります。たとえば、AUTOSAR 標準関数 SetRealAlarm をカーネル 0 で呼び出して、カーネル 1 のアラームのオフセットを設定することができます。次の図に示すように、カウンタ、アラーム、およびスケジューリング テーブルが連携して、AUTOSAR オペレーティング システムのタスク スケジューリング メカニズムを形成します。
1.6、スピンロックと共有リソース
AUTOSAR マルチコア オペレーティング システムは、コア間のリソースの相互排他 を実現し、データの一貫性を確保するためにスピンロック メカニズムを設計しましたが、このメカニズムはコア内のリソースの相互排他には適していません。タスクまたは 2 番目のタイプの割り込みがスピン ロックに正常に適用されると、他のコア上のすべてのタスクおよび 2 番目のタイプの割り込みはスピン ロックに正常に適用できず、停滞状態になり、スピン ロックの占有者が解放されるのを待ちます。それは解放されました。この時点では他のコアは動作しているため、CPU 負荷率は低下しません。したがって、スピン ロックの使用には注意が必要であり、他のコアのリソースの無駄を防ぐために、実行時間の長いタスクにスピン ロックを適用することはお勧めできません。スピン ロックの使用がより複雑な場合、不当なデッドロック状態につながる可能性もあります。上記の現象に応じて、プロセッサコア間の通信や共有データを可能な限り削減し、結合の強いタスクを同一コアに割り当てる必要があります。次の図に示すように、スピン ロックを占有している間に優先度の低いタスクが優先度の高いタスクによってプリエンプトされると、スピンの設定に従って優先度の高いタスクも同じスピン ロックを申請する必要がある場合、ロック機構は、優先度の低いタスクがロックを解除するまで待つ必要があります。AUTOSAR オペレーティング システムのタスク スケジューリング メカニズムによれば、動作中に優先度の高いタスクが優先度の低いタスクによって中断されることはできません。したがって、この時点では、カーネル 0 はデッドロック状態にあります。上記の状況を防ぐために、AUTOSAR オペレーティング システムは、タスクまたは割り込みがスピン ロックを占有する場合、すべての割り込みを自動的に一時停止します。つまり、タスクがスピン ロックに正常に適用された後は、そのタスクまたは割り込みはどのタスクでも使用されなくなります。割り込みプリエンプション。
以下の図に示すように、実行プロセス中にコア 0 上のタスクがスピン ロック B の占有を申請する前にスピン ロック A の占有を申請する必要があり、同時にコア 1 上の特定のタスクがスピン ロック A の占有を申請する必要があります。実行中のプロセス中のスピン ロックの占有 スピン ロック B を適用し、次にスピン ロック A の占有を適用します。2 つのタスクが同じ時刻に実行を開始した場合、スピン ロック A はコア 0 のタスクによって占有され、スピン ロックが占有される可能性が非常に高くなります。ロック B は、コア 1 のタスクによって占有されています。タスク占有、このとき、2 つのコア上のタスクは互いにロックします。つまり、スピン ロックのネストされた呼び出しによってデッドロックが発生します。
この現象の発生を防ぐには、関連技術者がシステム設計時にネストされたスピンロック リクエストを無効にするか、ネストされたスピンロック リクエストを厳密な順序で無効にする必要があります。下図からわかるように、スピンロックへのシーケンシャルアクセスではデッドロックは発生しませんが、ループバックアクセスが形成されるとデッドロックが発生します。上記のルールに従って、システムを設計するときは、デッドロック現象を回避するために、タスクによるアプリケーションのスピン ロックの占有は可能な限りネストやループバックを避ける必要があります。
SpinLock へのループバック アクセスによって発生するデッドロック
AUTOSAR マルチコア オペレーティング システムでは、コア内のリソースの相互排他を実現し、データの整合性を確保するために、共有リソースメカニズムが設計されていますが、このメカニズムはコア間のリソースの相互排他には適していません。タスクまたは第 2 種割り込みが正常に適用されてコアの共有リソースを占有すると、コア上のすべてのタスクおよび第 2 種割り込みは共有リソースに正常に適用できず、実行状態から待機状態に戻ります。共有リソースが占有されるか解放されるのを待っています。
スピンロックとは異なり、共有リソースの申請者は共有リソースが占有されていることが分かると待ち状態に戻り、ロックは発生しません。また、前の記事で説明したメカニズムに従って、AUTOSARマルチコア オペレーティング システムは、OSEKオペレーティング システムの優先度上限モードを継承して、タスク トリガーの優先順位のエラーを防ぎます。
1.7、コア間通信IOC
AUTOSAR仕様では、コア内通信、コア間通信、外部通信の3種類の通信方式が定義されており、前2つを総称して内部通信と呼びます。異なるカーネル内のアプリケーションがデータを送信する必要がある場合、オペレーティング システムはそれらのアプリケーションのために共有メモリキャッシュ領域を開き、通信当事者のアプリケーションはこの領域への読み書きによってデータ送信を完了します。ただし、キャッシュ領域のデータは読み取りの過程で更新され、データの不整合が発生する可能性があります。
上記の問題を解決するために、AUTOSAR マルチコア オペレーティング システムは、コア間通信のための IOC (Inter OSApplication Communication) メソッドを提供します。IOC はカーネル内通信とは異なり、次の図に示すように、カーネル内通信はランタイム環境層で行われますが、IOC はオペレーティング システムで行われます。アプリケーション プログラムが上記の共有キャッシュ領域を読み書きするとき、他のコア上のアプリケーションが同時にアクセスできないようにスピン ロックが適用されます。通常、IOC ではスピン ロックの複数の呼び出しが行われないため、本書の研究では、Vector MicroSAR が提供するミニ スピン ロック (Minilock) メカニズムを使用できます。ミニ スピン ロックの機能はスピン ロックと同じですが、占有するシステム リソースが少なく、実行時間がスピン ロックよりも短く、設定が簡単であるため、所要時間を短縮するのに役立ちます。 IOC通信用。
上記内容によれば、タスクが共有データ領域にアクセスする際に、データの整合性を確保し、コア間通信に要する時間を可能な限り短縮するために、ミニスピンロック機構を利用することができる。
1.8. OS オブジェクト内の要素の相互作用
AUTOSAR マルチコア オペレーティング システムは、タスク、割り込み、アラーム、イベントなどの要素で構成されており、それらの要素間の相互作用により、オペレーティング システムが規則正しく実行されます。広義には、AUTOSAR OS はイベント駆動型のオペレーティング システムであり、次の図に示すように、Alarm はアラーム イベントとみなすことができます。
上の図と前の章の内容を組み合わせると、タスクはアラーム、スケジュール、他のタスクまたは割り込みによってアクティブ化でき、イベントはアラーム、スケジュール、タスク、または割り込みによって設定できることがわかります。あるタスクや割り込みが共有リソースを取得すると、その共有リソースはロックされ、他のタスクや割り込みはアクセスできなくなります。
1.9. マルチコアOSの起動と終了
AUTOSAR ソフトウェア アーキテクチャでは、シングルコア オペレーティング システムであってもマルチコア オペレーティング システムであっても、起動を制御する EcuM (ECUState Management) と BswM (BSW Mode Management) という 2 つの管理モジュールと密接に関係しています。オペレーティングシステムの初期化、動作、シャットダウンなどの状態とその過程。AUTOSAR オペレーティング システムの起動と終了のプロセスを次の図に示します。
下図に示すように、ECU は起動 (STARTUP)、通常動作 (UP)、スリープ (SLEEP)、シャットダウン (SHUTDOWN) の 4 つの状態で動作します。ECU は電源投入前に SHUTDOWN 状態にあり、電源投入後に STARTUP ステージに入ります。これには StarPreOS と StartPostOS の 2 つのステージが含まれます。StartPreOS ステージは、ECU が OS を初期化するための準備作業を行います。主なアクションは次のとおりです。コールアウト: プログラマブル割り込みレベルの優先順位を設定します; コールアウト: EcuM_AL_DriverInitZero はビルド後のパラメータを設定せずに BSW モジュールを初期化し、コードのこの部分は手動で追加されます。
コールアウト: 関数 EcuM_DeterminePbConfiguration() を呼び出して、ビルド後のデータへのポインターを返します。
データ構成の一貫性をチェックし、エラーがある場合は、EcuM_ErrorHook; コールアウト: EcuM_AL_DriverInitOne を呼び出して、Mcu、IO、GPT、Watchdog およびその他のモジュールを初期化します。
リセット理由を取得します。
デフォルトのシャットダウン オブジェクトを選択します。
コールアウト: EcuM-LoopDetection を呼び出して、ECU がループによってリセットされているかどうかを確認し、OS を起動します。
StartPostOS ステージは OS 起動後のステージであり、主に BSW スケジューラの初期化と BswM モジュールの初期化の 2 つのアクションを実行します。まとめると、スタートアップフェーズのプロセスは次の図に示されます。
上図に示すように、ECUは電源投入後、まずマイコンの起動ブートプログラム(BootMenu)を実行し、次にCinitを実行してスタックを割り当て、その後EcuMが制御を引き継いでStartPreOSを実行します。 EcuM は、コールアウト コード セグメントを実行し、OSを起動します。このとき、OS は制御を引き継ぎ、OS の起動とそのコールバック関数を実行し、OS が自動的に起動する必要があるタスク (通常は初期化タスク) を開始し、 EcuM_StartupTwo ( ) ; EcuM が再び制御を引き継ぎ、StartPostOSを実行してECUとOSを完了し、 OS 内の他のタスクの実行が許可されます。ECUの制御はBswMに移管されます。マルチコアの起動はOSの有無に関わらずハードウェアと密接な関係があり、通常はハードウェアがマスターコア(Master Core)としてコアを起動し、スレーブコア(Slave Core)がソフトウェアによって起動されます。この方法をマスタースレーブモード(Master-Slave Startup Behavior)といいます。AUTOSAR 仕様では、マルチコア OS を起動するためのマスター/スレーブ モードが定義されています。マルチコアOSの具体的な起動プロセスを下図に示します。
マルチコアOSの起動プロセス
OSの起動と同様に、OSのシャットダウンもEcuMによって行われます。シャットダウンプロセス中にウェイクアップイベントが発生した場合、ECUはシャットダウン直後に再起動します。シャットダウン プロセス中に、システムは [シャットダウン ターゲット] を選択します。これには、 [オフ] 、[スリープ] 、および[リセット]が含まれます。ECU をシャットダウンする具体的なプロセスを次の図に示します。
マルチコア システムでは、現在 AUTOSAR 4.x は 1 つのコアのみのシャットダウンをサポートしていません。つまり、シャットダウン コマンドが発行されるか致命的なエラーが発生する場合は、すべてのコアをシャットダウンする必要があります。OSをシャットダウンする具体的な手順を以下の図に示します。
上の図に示すように、タスクに Shutdown All Cores を呼び出す権限がある場合、シャットダウン信号がすべてのコアに送信されます。シャットダウン プロセスが開始されると、すべての割り込みサービスとタスクはアクティブ化されなくなり、シャットダウン前に完了する必要があるプログラムはEcuMによって完了することが保証されます。シャットダウンが完了する前に、OS アプリケーション シャットダウン フックは対応するコールバック プログラムを完了し、すべてのコアが同期ポイントに達するまで待機してシャットダウン コールバック プログラムを実行します。
2. マルチコアOSの注意事項
2.1、最小展開単位
シングルコア オペレーティング システムでランナブルをタスクにマッピングする場合、最小の割り当て単位はランナブルであり、基本的に同じサイクルのすべてのランナブルが同じタスクに割り当てられるため、タスクの切り替えによって生じる追加の負荷が軽減されます。AUTOSAR で指定されているマルチコア オペレーティング システムについては、その最小割り当て単位は実行可能ではなく、SWC が実行可能です (下図に示すように)。SWC は特定の機能を実現する論理概念であり、この論理機能を実現するエンティティは複数のランナブルです。したがって、これは、同じ SWC に属するランナブルが実行のために同じコアに割り当てられる必要があることも意味します。
前回の記事では、シングルコア アプリケーションの展開からマルチコア オペレーティング システムに移行する方法を紹介しました。この方法の考え方は、同じタスク内の各ランナブルのデータ フローを分析し、データ フローの方向に従ってランナブルを複数のコアに割り当てることです。その主な原理は、データ フローが分岐するときに、各分岐を複数のコアに分割して、各タスクの最悪の場合の実行時間 (WCET) を短縮できることです。この方法はシンプルで実装が簡単で、シングルコア オペレーティング システムで実行されているタスク セットをマルチコア オペレーティング システム プラットフォームに直接変換でき、安定性を検証するために多大なエネルギーを費やす必要はありません。マルチコア オペレーティング システム上のソフトウェア。ただし、このメソッドの最小割り当て単位は引き続き実行可能であり、データ フロー ブランチが同じ SWC 内にある場合、このメソッドはその役割を果たすことができません。この方法を使用してマルチコア アプリケーションを展開する必要がある場合は、実行可能ファイルのマッピング中に SWC を分割して再構築し、元の機能する SWC を分解して、展開の観点から SWC を再構築する必要があります。この方法はプロセスにおいて AUTOSAR 仕様に準拠していませんが、実装プロセスにおいて WCET を効果的に削減し、CPU 負荷を軽減できます。ソフトウェア コンポーネント (SWC) の展開を次の図に示します。
上記によると、コア間ロード バランシングを実現するための基礎は、SWCのコア間割り当てを通じて行われます。最小の割り当て単位は、実行可能ファイルではなく SWC です。したがって、この方法でマルチコア タスクをデプロイする場合、リファクタリングは必要ありませんSWC の ECU 構成段階で直接マッピングするだけです。
2.2. コア間通信とその影響
マルチコア オペレーティング システム間に通信がない場合、マルチコア オペレーティング システムは、独立して実行されている複数のシングルコア オペレーティング システムと同等になります。ただし、マルチコア オペレーティング システムに展開されることが多いアプリケーションは、相互に情報を交換する必要があります。たとえば、複数のコアが同じセットのハードウェア周辺機器リソースを共有します。Vector の AUTOSAR ソフトウェア パッケージでは、基盤となる周辺機器を扱うとき、非マスター コアはハードウェア抽象化層のリソースを直接操作できませんが、相互接続に依存する必要があります。コア通信 マスターと通信する IOC 基礎となるハードウェア ドライバーを制御するカーネル通信 下の図と下の図は、Vector MICROSAR のメインコア AUTOSAR アーキテクチャとマルチコア オペレーティング システム アーキテクチャを示しています。
このうち、マイクロコントローラー抽象化層は、マイクロコントローラーのハードウェア抽象化層です。Core0 はメイン コア、Corel はスレーブ コアで、Core0 は入出力ハードウェア抽象化層 (IOHWAB) を通じてマイクロコントローラー抽象化層のサービスを呼び出します。Corel がマイクロコントローラー抽象化レイヤーを制御する必要がある場合、そのサービスを直接呼び出すことはできませんが、IOC を使用して Core0 と通信し、マイクロコントローラー抽象化レイヤーのサービスを取得する必要があります。別の例としては、2 つのコアにある SWC がデータを交換する必要がある場合、コア間通信にも IOC を使用する必要があります。
コア間通信の登場により、元々独立していたコア同士が相互に影響を与えるようになる。この影響は主に、コア間通信による通信時間によるコアの負荷率の増加によるものです。マルチコア プロセッサのハードウェア アーキテクチャの分析と IOC 通信メカニズムの分析を通じて、通信時間の消費は主に 2 つの部分で構成されていることがわかります。1 つはハードウェア リソースにアクセスする際のハードウェア アーキテクチャによって生じる追加の時間消費であり、IOC通信メカニズムでSpinlock を。Runnble の実行時間は、下図に示すように、計算時間、タスク切り替え時間、通信時間の3 つに大別されます。計算時間は通常の論理演算に必要な時間を指し、タスク切り替え時間はオペレーティング システムがタスクの優先順位に従って実行できる準備ができたタスクを配置するのにかかる時間を指し、通信時間はメモリからのデータの読み取りまたは時間を指します。書き込みを完了するために必要です。ハードウェアが異なると、ユニットデータの読み書きにかかる時間が異なり、データの一貫性の観点からスピンロックを使用する必要があり、複数のコアが同じハードウェアリソースに一定時間アクセスする必要がある場合、競合が発生します。アクセスの順序は、アクセスを開始した時刻とアクセスを開始したコアの優先度に応じて決定する必要があり、コア間で通信するデータ量が多く、頻繁に通信する場合、特にサイクルの小さいタスクでは、 CPUに負荷がかかり、効果が大幅に高まります。したがって、複数のコア間でタスクを分散する場合は、コア間タスクの結合と CPU 動作の負荷を軽減するために、コア間通信の数と頻度を減らすことに特別な注意を払う必要があります。
さらに、コア間通信ではデータの一貫性を確保する必要があります。データの一貫性は、アプリケーションが正常に実行され、結果が正しいことを保証するために必要な条件の 1 つです。いわゆるデータの整合性とは、プログラムの実行過程において、途中での改ざんやタイミングの悪いデータ更新などにより、その値が期待と一致しないことを保証することです。AUTOSAR では、コア間通信のデータの一貫性を確保するために、IOC 通信メカニズムを通じてコア間通信を実行する必要があります。
2.3. 片言に注意する
SWC はアプリケーション層の分割不可能な原子単位であり、エンティティを実行するためのキャリアとして使用できます。
ソフトウェアコンポーネントはポート１０８を介して接続され、ポート１０８は仮想バスＶＦＢ１０８を介して接続され、論理データ相互作用を実現する。さまざまな通信方法に従って、ポートは S/R (送信/受信) ポートと C/S (クライアント/サーバー) ポートに分割できます。S/R はデータの送受信に使用され、1:n および n:1 のデータ送信をサポートし、複数のデータ要素を送信できます。整数や浮動小数点型などの単純なデータ型のデータ送信だけでなく、配列や構造体などの複雑なデータ型の送信もサポートします。データがバス上で転送される場合、データ要素を信号にマッピングする必要があります。このタイプのインターフェイスの C コードはパブリック変数として具体化されるため、このタイプのポートには 1 つ以上のデータ要素 (データ要素) を割り当てる必要があります。C/Sはサービスの呼び出しに使用され、クライアントがリクエストを送信した後、サーバーがデータを処理し、その出力がクライアントに送信されることで、機能モジュールの相互呼び出しを実現します。このタイプのポートは、1:1 および 1:n 通信、同期通信および非同期通信をサポートし、ECU 内および ECU 間通信をサポートします。このインターフェースの C コードは、関数のインターフェースとして実装されます。さらに、AUTOSAR は、キャリブレーション ポートやカスタム モジュール ポートなど、他のタイプのポートも提供します。ポートの作成方法を次の図に示します。
AUTOSAR では、プログラムの特定の実行単位を記述するために実行エンティティRE (Runnable Entity)の概念が導入され、 Cコードの関数として具体化されます。アプリケーション層では、ランタイム エンティティがソフトウェア コンポーネントに割り当てられ、ベース ソフトウェア層では、ランタイム エンティティがタスクに割り当てられます。各実行エンティティには 1 つ以上のトリガー条件があり、RTE はトリガー条件に従って実行エンティティをスケジュールします。一般的なトリガー イベントには、データ受信、タイムアウト、関数呼び出しが含まれます。実行中のエンティティには、実行中のエンティティのポート アクセス権を表す 1 つ以上のポートがあります。実行中のエンティティの設計インターフェイスを次の図に示します。
データ型とデータ マッピングは、アプリケーション層のデータ操作の便宜のために定義されています。AUTOSAR は、アプリケーション データ型(Application Data Types) 、特定の実装データ型(Implementation DatalTypes)および基本データ型(Basic Data Types)の 3 つのデータ型を提供します。アプリケーション データ型にはセマンティクスはありますが、構文はありません。上位層のソフトウェア設計の便宜のために定義されています。名前が示すとおりの機能があります。具体的に実装されたデータ型にマッピングする必要があります。具体的に実装されたデータ型はセマンティクスと構文の両方を持ち、C コード内で同じ名前の変数が生成されます。このタイプのデータ型はライブラリから選択することも、基本データ型によって作成して分布計算によって制約することもできます。手法もデータも。基本データ型には構文があり、セマンティクスはなく、操作することはできません。主に特定の実装データ型を作成するために使用されます。データ マッピングとは、アプリケーションのデータ型を特定のデータ型にマッピングすることを指します。データ型作成インターフェイスを次の図に示します。
