JP2020086807A - 車両制御装置およびプログラム実行方法 - Google Patents

Abstract

【課題】 複数のコアに搭載されたアプリケーションソフトウェアのモジュールが、プラットフォームのＡＰＩを複数のコアから利用する際、ＲＯＭ使用量、演算負荷、応答性等の面でバランスの取れた処理を実施する。【解決手段】複数のコア１は、モジュール１１とモジュールからのソフトウェア部品１２のＡＰＩ呼出しを受け付ける要求受付部１３とを備え、第１のコア１−１は、ソフトウェア部品１２と、ソフトウェア部品に、アプリケーションソフトウェアの処理結果をメモリの所定領域３１に書き込む第１の処理を実行させる第１のＡＰＩ呼出しを行う要求処理部１４とを備え、要求受付部は、モジュールから第１のＡＰＩ呼出しを受けて、モジュールの処理結果をメモリ３のバッファ領域３２に書き込み、要求処理部は、第１のＡＰＩ呼出しを行い、バッファ領域に書き込まれたモジュールの処理結果を所定領域に書き込む。【選択図】図４

Description

本発明は、マルチコアマイクロプロセッサを搭載する車両制御装置、およびかかる車両制御装置におけるプログラム実行方法に関する。

車載ＥＣＵ（Electronic Control Unit）ソフトウェアにおいて、法規等で定められた車載自己診断要求など、共通で必要となる機能に対して標準化が進められ、プラットフォームのソフトウェア部品として機能が提供されている。例えば、車載向け標準ソフトウェアのプラットフォームであるＡＵＴＯＳＡＲ（AUTomotive Open System ARchitecture）では、診断情報管理部としてＤＥＭ（Diagnosis Event Manager）と呼ばれるソフトウェア部品が提供されている。

しかしながら、車載ＥＣＵで求められる安全、燃費、排気といった各種性能向上の実現のため、ソフトウェア部品の肥大化、複雑化が進んでいる。その対処方法の１つとして、複数のプロセッサを有するマルチコアマイクロプロセッサ（以下、マルチコアマイコンという）を採用することにより、トータルの演算性能を高めることができる。

マルチコアマイコンを利用するためには、どのコアでどの機能を演算させるかという機能のコア割付を管理する必要がある。多くのコアが搭載されたマルチコアマイコンではコア割付の管理に限界があり、並列化コンパイラを利用し、自動的にコア割付を行う技術が適用され始めている。

特開２００５−０７１１０９号公報 特開２０１８−０４９４０６号公報

プラットフォームのソフトウェア部品を利用するアプリケーションソフトウェアは、通常、ソフトウェア部品が提供するＡＰＩ（Application Programming Interface）を介して機能の利用を行う。このＡＰＩがマルチコアマイコンの各コアから同時に利用されると、データの競合が発生するため、ＡＰＩ呼び出しの競合を回避するための仕組みが必要である。ＡＰＩ呼び出しの競合あるいはデータの競合の回避に伴う問題点について、アプリケーションソフトウェアの診断モジュールが、プラットフォームのソフトウェア部品である診断情報管理部を、ＡＰＩを用いて利用する場合を例として説明する。

図１は、複数のコア１−１〜ｎからＡＰＩ呼び出しによる競合を避けるための車両制御装置の実装の一例である。この構成は、プラットフォームの診断情報管理部１２を利用するアプリケーションソフトウェア中のすべての診断モジュール１１を一つのコア（この例ではコア１−１）からアクセスされるようにコア割付を行い、診断情報管理部１２の処理が単一のコアで完結する構成である。この構成であればコア１−１以外のコアからＡＰＩが呼び出されることがなく、データの競合が抑止できる。しかしながら、開発が進み、新たな診断モジュールを追加したい場合が生じた場合にも、既に診断モジュール１１が割り付けられているコア１−１に割り付けなければならないという制約が発生してしまう。

図２は実装の別の例であり、１つのコア１−ｉ（ｉ＝１〜ｎの任意の数）に対して、１つの診断情報管理部１２−ｉを割り当てる。この構成では、各コアにおいて共通のＡＰＩを呼び出すことが可能であるが、同じソフトウェア部品（診断情報管理部）１２−ｉをそれぞれのコアに実装する必要があるため、ソフトウェアを格納するＲＯＭ（Read Only Memory）の使用量が増大するという課題が生じる。また、各コアの診断情報管理部１２−ｉはコア共用ＲＡＭ３に書き込みを行う際、データ競合を抑止するために、例えば、特許文献１に記載されているようなデータのバリア同期をとる必要があり、これにより、処理が遅延するおそれがある。

図３は実装のさらに別の例であり、特許文献２に記載の、１つのコア（ここではコア１−１）配下にあるソフトウェア部品１２を、当該コア１−１及び他のコア１−ｊ（ｊ＝２〜ｎの任意の数）から直接操作する構成例である。この構成では、ＲＯＭの使用量をおさえることが可能であるが、他のコア配下のＡＰＩを呼び出す際に同時に実行されないよう、コア間の調停、例えば、先に実行されている処理を優先し、後から実行する側はその処理の完了まで待つ、などの対応が必要となるため、図２の構成と同様に処理の遅延は避けられない。

車両制御装置では、マルチコアマイコンの各コアの定時タスクの処理があらかじめ定められた期間（サイクル周期）内に完了することを保証することが求められる。例えば、サイクル周期が１０ｍｓと定められているならば、各コアが実行するあるサイクルでの定時タスクの処理は１０ｍｓ以内に完了し、次のサイクルでのタスクが開始できる状態になっていなければならない。１０ｍｓ毎に実行される定時タスクの処理に１０ｍｓ以上を要してしまうと、次回のサイクルでは定時タスクを正しく実行できなくなり、システムが破綻してしまう。そのため、定時タスクに要する時間がサイクル周期よりも小さくなるよう、タスク設計を行う必要がある。例えば、サイクル周期が１０ｍｓであり、タスクが完了する時間が７ｍｓ時点であるとすると、残り３ｍｓはアイドル時間として、次の１０ｍｓタスクが開始されるまでの待ち時間とできるので、定時タスクの余裕度の指標として管理可能である。

しかしながら、ＡＰＩ呼び出しの競合、あるいはデータ競合が生じる場合には、調停のために大きなオーバーヘッドが生じる可能性があり、並列化によりトータルの演算性能を高めるという効果を十分に活用することができない。

本発明の一実施態様である車両制御装置は、第１のコアを含む複数のコアと複数のコアから読み書き可能なメモリとを有するマイクロプロセッサを有し、マイクロプロセッサにより、ソフトウェアプラットフォームから提供されるソフトウェア部品を利用するアプリケーションソフトウェアが実行される車両制御装置であって、複数のコアは、アプリケーションソフトウェアのモジュールとモジュールからのソフトウェア部品のＡＰＩ呼出しを受け付ける要求受付部とを備え、第１のコアは、ソフトウェア部品と、ソフトウェア部品に、アプリケーションソフトウェアの処理結果をメモリの所定領域に書き込む第１の処理を実行させる第１のＡＰＩ呼出しを行う要求処理部とを備え、複数のコアの要求受付部は、モジュールから第１のＡＰＩ呼出しを受けて、モジュールの処理結果をコアごとに割り当てられたメモリのバッファ領域に書き込み、第１のコアの要求処理部は、第１のＡＰＩ呼出しを行い、コアごとに割り当てられたメモリのバッファ領域に書き込まれたモジュールの処理結果をメモリの所定領域に書き込む。

複数のコアに搭載されたアプリケーションソフトウェアのモジュールが、プラットフォームのＡＰＩを複数のコアから利用する際、ＲＯＭ使用量、演算負荷、応答性等の面で、トレードオフのバランスが取れた処理を実施できる。

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本発明の課題を説明するための図である。 本発明の課題を説明するための図である。 本発明の課題を説明するための図である。 実施例１におけるシステム構成例である。 情報のデータ構造の一例である。 要求受付部が実行する処理の流れを示すフローチャートである。 書込み要求処理部が実行する処理の流れを示すフローチャートである。 診断情報管理部の処理を示すフローチャートである。 本実施例の効果を説明するための図である。 本実施例の効果を説明するための図である。 実施例２におけるシステム構成例である。

以下、添付された図面を参照し、本発明を実施するための実施の形態について説明する。ここでは、アプリケーションソフトウェアの診断モジュールが、プラットフォームの診断情報管理部のＡＰＩを利用する場合を例にとって説明する。具体的には、プラットフォームの診断情報処理部は、ＡＵＴＯＳＡＲのソフトウェア部品であるＤＥＭを想定している。

図４は、実施例１に係るマルチコアマイコンを適用した車両制御装置のシステム構成例である。本実施例の車両制御装置５は複数のコア１−１〜ｎと、各コア１−１〜ｎからアクセス可能なコア共用ＲＡＭ（Random Access Memory）３と、不揮発メモリ４とを備える。なお、各コアは図示しないメモリに格納された命令を実行するための演算器やタイマ管理器などを有しており、それぞれが特定の機能にかかわる処理を実行する。

各コアは、命令を実行することにより機能する機能ブロックを含んでいる。この例では、コア１−ｉ（ｉ＝１〜ｎの任意の数）は、汎用入力回路や出力回路の故障を検出する診断モジュール１１−ｉ、及び要求受付部１３−ｉを備えている。要求受付部１３−ｉは、当該コア１−ｉの診断モジュール１１−ｉからのコア共用ＲＡＭ３の共通診断情報領域３１に格納された診断結果の参照要求や、診断モジュール１１−ｉが実施した診断結果をコア共用ＲＡＭ３に書き込む書込み要求を受け付ける。コア１−１は、それらに加えて、共通診断情報領域３１への診断結果の書込み要求を行う書込み要求処理部１４、ＡＵＴＯＳＡＲのＤＥＭに相当する診断情報管理部１２を備える。本システム構成において、書込み要求処理部１４及び診断情報管理部１２を備えているのはコア１−１のみである。

コア共有ＲＡＭ３は、コア１−１〜ｎより読み書き可能となっている。コア共有ＲＡＭ３にはコア毎の要求受付部１３−ｉから書込み要求のなされた診断結果を一時的に格納するバッファ領域３２−ｉと、診断モジュール１１−ｉ〜ｎの診断結果を格納する共通診断情報領域３１とを含む。共通診断情報領域３１は、後述するように、バッファ領域３２−１〜ｎに書き込まれた診断モジュール１１−１〜ｎの診断結果が最終的に書き込まれるコア共有ＲＡＭ３の領域である。ただし、共通診断情報領域３１の一部のデータは、その重要度にしたがって、不揮発メモリ４にも格納される。

各コアの診断モジュール１１−ｉの診断結果はＤＥＭのＡＰＩ名を使用して、同じコアの要求受付部１３−ｉに渡される。ＤＥＭのＡＰＩには読出し用ＡＰＩ及び書込み用ＡＰＩの２種類が用意されており、要求受付部１３−ｉは受け取ったＡＰＩに応じて既定の処理を実施する。

図６は、各コアの要求受付部１３−ｉが実行する要求受付処理の流れを示すフローチャートである。本フローは前述のように当該コアの診断モジュール１１−ｉからのＡＰＩ呼び出しにより、当該コアにおいて実行される。

まず、受付処理（Ｓ１０１）を行った要求が読出し要求の場合（Ｓ１０２でＮＯ）、コア共有ＲＡＭ３に直接アクセスし、共通診断情報領域３１から所望の診断結果を取得し、診断モジュール１１−ｉに応答する（Ｓ１０３）。読出しに関しては、コア間での調停が必要ないため、要求された診断結果を診断モジュール１１−ｉに応答してフローを終了する。このときの各コアの要求受付部１３−ｉとコア共用ＲＡＭ３との情報のやり取りは、図４の一点鎖線によって示されている。

一方、受付処理（Ｓ１０１）を行った要求が書込み要求の場合（Ｓ１０２でＹＥＳ）、要求受付部１３−ｉは処理状況を格納するコア共有ＲＡＭ３内のバッファ領域３２−ｉを特定するために必要な、呼び出しを実行したコア（すなわち、自コア）情報（Ｓ１０４）、及び診断モジュール１１−ｉに呼び出されたときの格納時期情報（Ｓ１０５）を取得する。Ｓ１０５は、法規制で診断結果を発生順に保存するよう求められており、その要求を遵守するために行われる。格納時期情報の取得は、例えばタイマ管理器より提供されるフリーランタイマ値をキャプチャすることで行うことができる。

そして、コア共有ＲＡＭ３におけるバッファ領域３２−ｉに、診断モジュール１１−ｉから書き込み要求のあった診断結果を書込み（Ｓ１０６）、フローを終了する（Ｓ１０７）。このときの各コアの要求受付部１３−ｉとコア共用ＲＡＭ３との情報のやり取りは、図４の破線によって示されている。

図５に、要求受付部１３−ｉからコア共有ＲＡＭ３のバッファ領域３２−ｉに書き込まれるデータ構造の一例を示す。診断モジュール１１−ｉが書込み要求を行う一単位が診断結果７０であり、診断結果７０には、判定結果とともに、不良解析等のため当該判定結果が生じたときの付加的な情報が含まれている。診断ＩＤ７１は、診断内容を一意に特定するため、診断モジュール１１が実行する診断に割り当てられた識別情報である。判定結果７２は、当該診断を実行した結果であり、故障判定、異常なし判定の双方を含む。環境情報７３は、診断を実行したときの環境データである。環境データには、例えば、診断を行ったときの車速等の車両データや外気温等の周辺環境データが含まれる。格納時期情報７４は、診断実行時期を示すタイムスタンプである。例えば、図６のフローチャートにおけるＳ１０５で取得したフリーランタイマ値である。

また、同じサイクルにおいて、要求受付部１３−ｉから複数の診断結果７０について書込み要求が発生する場合がある。要求受付部１３−ｉからの１サイクルにおける書込み要求数７５が、バッファ領域３２−ｉに記録される。すなわち、各コアの定時タスクが終了した時点で、バッファ領域３２−ｉには、書込み要求数７５に相当する数の診断結果７０が記憶されている。

本実施例のシステム構成では、要求受付部１３−ｉにてコア共用ＲＡＭ３のバッファ領域３２−ｉに格納された診断結果は、コア１−１の書込み要求処理部１４によって診断情報管理部１２に引き渡される。図７は、書き込み要求処理部１４が診断情報管理部１２に通知する書込み要求処理の流れを示すフローチャートである。本処理は各サイクルにおける書込み要求処理部１４の定時タスクとして周期的に実行することとするが、コアの処理終了などをトリガとする割込み処理で行うことも可能である。

書込み要求処理部１４では、まずコア１−１〜ｎの処理の終了を監視する（Ｓ２０２）。全てのコアの処理が終了していない場合には（Ｓ２０２でＮＯ）、書込み要求処理を行うことなくフローを終了する（Ｓ２１１）。例えば、コア毎の診断処理の終了を示すフラグ記憶領域をコア共用ＲＡＭ３内に設け、各コアの診断モジュール１１−ｉが定時タスクを終了すると当該フラグ記憶領域に終了フラグを記憶させる。書込み要求処理部１４は各コア１−１〜ｎの終了フラグを読み取ることにより、各コアの診断モジュール１１−ｉの定時タスクの終了を監視することができる。

全てのコア１−１〜ｎの定時タスクの終了が確認されると、書込み要求処理を開始する（Ｓ２０２でＹＥＳ）。まず各コアからの書込み要求数（図５を参照）を取得し、書込み総数を確認する（Ｓ２０３）。その後、共通診断情報領域３１への書込み順番を決定するため、バッファ領域３２−１〜ｎに格納された各診断結果７０の格納時期情報７４の情報を取得し（Ｓ２０４）、格納時期の早い順に診断結果７０をソートする（Ｓ２０５）。ソート完了後は（Ｓ２０６でＹＥＳ）、その順に従って診断結果７０をバッファ領域３２−１〜ｎより読出し（Ｓ２０７）、診断情報管理部１２に書込み用ＡＰＩを用いて書込み要求を通知する（Ｓ２０８）。

要求総数分の書込み処理要求回数を確認し（Ｓ２０９）、要求総数の書込み処理が完了（Ｓ２０９でＹＥＳ）した後に、バッファ領域３２−１〜ｎ内の診断結果を削除し（Ｓ２１０）、フローを終了する（Ｓ２１１）。

図８は書込み要求処理部１４からの書込み用ＡＰＩにて呼び出された診断情報管理部１２が実行する診断情報管理処理の流れを示すフローチャートである。書込み用ＡＰＩの引数として渡された診断結果を受け付け（Ｓ３０２）、コア共用ＲＡＭ３内の共通診断情報領域３１を更新する（Ｓ３０３）。また、診断の種類によっては不揮発メモリ４の更新が必要となる。更新対象の場合、不揮発メモリ４のデータ（診断結果）を更新し（Ｓ３０４，Ｓ３０５）、フローを終了する。

このように本実施例では、コア共用ＲＡＭ３の共通診断情報領域３１への書込み及び、不揮発メモリ４へのアクセスにかかわる処理は、コア１−１に一本化して行うため、複数のコアが同時に共通診断情報領域３１にアクセスすることによって干渉が生じるのを、確実に回避することができる。

図９、図１０を用いて本実施例のシステムの効果を説明する。図９は比較例として図２に示すシステム構成でのタイムチャート、図１０は本実施例である図４に示すシステム構成でのタイムチャートである。いずれの場合も、各コアは定時タスクとして複数の診断処理を行っている。この例ではコア１は診断１−１〜３を、コア２は診断２−１〜３を、コアｎは診断ｎ−１〜２を、１サイクル時間において実行している。各診断処理はサイクルごとに常に判定まで達するわけではなく、判定に達した場合のみコア共用ＲＡＭ３への書込み要求がなされる。この例では、タスクＮにおいては診断１−１、診断２−２が、タスク（Ｎ＋１）においては診断１−３、診断２−３、診断ｎ−２が判定に達し、診断結果をコア共用ＲＡＭ３に書き込む必要が生じている。このように、定時タスクにおける書込み要求の発生タイミングについてはあらかじめ予見することができない。

比較例（図９）の場合、タスクＮにおいては、各コアから発生する書込み要求のタイミングで遅滞なくそれぞれコア共用ＲＡＭ３の共通診断情報領域３１への書き込みに成功しているが、タスク（Ｎ＋１）においては、各コアから発生する書込み要求のタイミングが干渉し、各コアからの書込み要求間で調停を行う必要が生じている。このため、タスクのサイクル時間を調停のためのオーバーヘッドを考慮して設定しなければシステムが破綻する。一方、本実施例（図１０）の場合、コア共用ＲＡＭ３の共通診断情報領域３１への書き込みはすべてのコアの診断処理が終了した後に一括して更新を行うため、調停処理が不要となっている。したがって、共通診断情報領域３１への書き込みに要する時間がとれるようにタスクのサイクル時間を設定することができ、サイクル時間をより短い時間に設定することが可能になる。

実施例２は、車両制御装置に搭載する診断モジュールのソフトウェアの開発に好適な形態である。実施例１では、車両制御装置に適用されるマルチコアマイコンの各コアに診断モジュール１１と要求受付部１３を実装したが、実施例２では、これらを、診断モジュールを開発する外部環境（例えば、ＰＣ（Personal Computer））に組み込んで使用する。なお、本実施例の構成要素のうち、実施例１との共通部分については同一の符号を付し、重複する説明は省略するものとする。

図１１は、実施例２に係るマルチコアマイコンを適用した車両制御装置５と、コア１内の一部の処理を外部環境６上で動作する環境とを組み合わせた構成例である。車両制御装置５の構成は実施例１と同様である。この例では、コア１−１に外部環境６にて開発中の診断モジュール６１にトリガをかけて実行させる試験用モジュール１５が搭載されている。一方、外部環境６は、命令を実行することにより機能する機能ブロックとして、診断モジュール６１と、診断モジュール６１からの車両制御装置５のコア共用ＲＡＭ３の共通診断情報領域３１に格納された診断結果の参照要求や、診断モジュール６１が実施した診断結果をコア共用ＲＡＭ３に書き込む書込み要求を受け付ける要求受付部６３とを備える。要求受付部６３は各コア１−ｉの要求受付部１３−ｉと同じ機能を有する。また、コア共用ＲＡＭ３には、診断モジュール６１の実行した診断結果を一時的に格納する外部環境用バッファ領域３３が設けられる。

これにより、外部環境６は車両制御装置５のマルチコアマイコンの各コアと同様に扱うことができる。要求受付部６３が実行する要求受付処理の流れを示すフローチャートは図６に示される通りである。ただし、書込み要求の場合、処理状況を格納するコア共有ＲＡＭ３内のバッファ領域３２は、試験用モジュール１５が搭載されたコアのバッファ領域となる。したがって、この場合はバッファ領域３２−１に書き込まれることになる。そのため、外部環境６には、あらかじめ試験用モジュール１５よりコア情報（この場合は、コア１−１の情報）が引き渡され、外部環境６で管理している。また、格納時期情報の取得（Ｓ１０５）は、例えば車両制御装置内のタイマ管理器より提供されるフリーランタイマ値をキャプチャすることにより行う。

要求受付部にて格納された処理の状態は、書込み要求処理部を経由し診断情報管理部に引き渡される。書込み要求処理部では各コア処理の終了を監視する（Ｓ２０２）。全てのコアの処理が終了していない場合は、書込み要求処理を終了する。なお、外部環境の処理終了は試験用モジュールの配置されたコアの処理終了で判定することができる。

書込み要求処理部１４の処理、診断情報管理部１２の処理は実施例１と同じであり、各コア１の診断モジュール１１からの診断結果も外部環境６の診断モジュール６１からの診断結果も区別なく扱われる。なお、この例では試験用モジュール１５がコア１−１に搭載された例を示したが、任意のコアに搭載されていてもよい。この場合は、外部環境６の診断モジュール６１からの診断結果は、試験用モジュール１５が搭載されたコアに割り当てられたバッファ領域に一時的に書き込まれることになる。

このように、車両制御装置を外部環境とを組み合わせた状態においても、ＡＰＩの呼出しの競合、またはデータの競合を回避することができる。

１：コア、３：コア共有ＲＡＭ、４：不揮発メモリ、５：車両制御装置、６：外部環境、１１，６１：診断モジュール、１２：診断情報管理部、１３，６３：要求受付部、１４：書込み要求処理部、１５：試験用モジュール、３１：共通診断情報領域、３２：バッファ領域、７０：診断結果、７１：診断ＩＤ、７２：判定結果、７３：環境情報、７４：格納時期情報、７５：書込み要求数。

Claims (10)

1. 第１のコアを含む複数のコアと複数の前記コアから読み書き可能なメモリとを有するマイクロプロセッサを有し、前記マイクロプロセッサにより、ソフトウェアプラットフォームから提供されるソフトウェア部品を利用するアプリケーションソフトウェアが実行される車両制御装置であって、
   複数の前記コアは、前記アプリケーションソフトウェアのモジュールと前記モジュールからの前記ソフトウェア部品のＡＰＩ呼出しを受け付ける要求受付部とを備え、
   前記第１のコアは、前記ソフトウェア部品と、前記ソフトウェア部品に、前記アプリケーションソフトウェアの処理結果を前記メモリの所定領域に書き込む第１の処理を実行させる第１のＡＰＩ呼出しを行う要求処理部とを備え、
   複数の前記コアの前記要求受付部は、前記モジュールから前記第１のＡＰＩ呼出しを受けて、前記モジュールの処理結果を前記コアごとに割り当てられた前記メモリのバッファ領域に書き込み、
   前記第１のコアの前記要求処理部は、前記第１のＡＰＩ呼出しを行い、前記コアごとに割り当てられた前記メモリのバッファ領域に書き込まれた前記モジュールの処理結果を前記メモリの前記所定領域に書き込む車両制御装置。
2. 請求項１において、
   複数の前記コアの前記要求受付部は、前記モジュールから、前記ソフトウェア部品に、前記メモリの前記所定領域から前記アプリケーションソフトウェアの処理結果を読み出す第２の処理を実行させる第２のＡＰＩ呼出しを受けて、前記メモリの前記所定領域から前記アプリケーションソフトウェアの処理結果を読み出す車両制御装置。
3. 請求項１において、
   前記アプリケーションソフトウェアは、所定のサイクル時間内に実行される定時タスクを実行するソフトウェアであって、
   前記サイクル時間ごとに、前記第１のコアの前記要求処理部は、前記アプリケーションソフトウェアのモジュールが搭載された複数の前記コアの処理が終了した後に、前記第１のＡＰＩ呼出しを行う車両制御装置。
4. 請求項３において、
   前記第１のコアの前記要求処理部は、前記サイクル時間内に前記第１の処理を完了する車両制御装置。
5. 請求項１において、
   複数の前記コアの前記要求受付部は、前記モジュールの処理結果を格納時間情報とともに前記コアごとに割り当てられた前記メモリのバッファ領域に書き込み、
   前記第１のコアの前記要求処理部は、前記格納時間情報に基づき、時系列に前記モジュールの処理結果を前記メモリの前記所定領域に書き込む車両制御装置。
6. 請求項１において、
   不揮発メモリを有し、
   前記第１の処理は、前記アプリケーションソフトウェアの処理結果の少なくとも一部を前記不揮発メモリに書き込む車両制御装置。
7. 第１のコアを含む複数のコアと複数の前記コアから読み書き可能なメモリとを有するマイクロプロセッサを有する車両制御装置において、前記マイクロプロセッサにより、ソフトウェアプラットフォームから提供されるソフトウェア部品を利用するアプリケーションソフトウェアを実行するプログラム実行方法であって、
   複数の前記コアに搭載された前記アプリケーションソフトウェアのモジュールは、前記ソフトウェア部品に前記アプリケーションソフトウェアの処理結果を前記メモリの所定領域に書き込む第１の処理を実行させる第１のＡＰＩ呼出しを行い、
   前記第１のＡＰＩ呼出しを行った前記コアに搭載された要求受付部は、前記モジュールの処理結果を前記コアごとに割り当てられた前記メモリのバッファ領域に書き込み、
   前記第１のコアに搭載された要求処理部は、前記第１のＡＰＩ呼出しを行い、前記コアごとに割り当てられた前記メモリのバッファ領域に書き込まれた前記モジュールの処理結果を前記メモリの前記所定領域に書き込むプログラム実行方法。
8. 請求項７において、
   前記アプリケーションソフトウェアは、所定のサイクル時間内に実行される定時タスクを実行するソフトウェアであって、
   前記第１のコアの前記要求処理部は、前記サイクル時間ごとに、前記アプリケーションソフトウェアのモジュールが搭載された複数の前記コアの処理が終了した後に、前記第１のＡＰＩ呼出しを行うプログラム実行方法。
9. 請求項８において、
   前記第１のコアの前記要求処理部は、前記サイクル時間内に前記第１の処理を完了するプログラム実行方法。
10. 請求項７において、
    前記マイクロプロセッサの複数の前記コアには、試験用モジュールが搭載される第２のコアを含み、
    前記第２のコアの前記試験用モジュールは外部環境にトリガをかけることにより、前記外部環境に搭載された前記アプリケーションソフトウェアのモジュールを実行させ、
    前記外部環境に搭載された前記アプリケーションソフトウェアのモジュールの処理結果は、前記第２のコアに割り当てられた前記メモリのバッファ領域に書き込まれるプログラム実行方法。

Images