JP5187194B2 - マルチプロセッサシステム - Google Patents

Description

本発明は、複数のプロセッサエレメントを備えるマルチプロセッサシステムに係わり、特に、外部環境によって動作モードが変化する制御対象装置に組み込まれたマルチプロセッサシステムに係わる。

近年、自動車のＩＴ化が進んできており、様々な制御を実現するためのシステムが開発されている。この場合、従来のシステムでは、図１Ａに示すように、１つのアプリケーションに対して１つのＥＣＵ（Electronic Control Unit）が割り当てられる構成（以下、分散処理型システム）が多かった。図１Ａに示す例では、６つのアプリケーション（前方監視、ナイトビジョン、右側方監視、左側方監視、ドライバ監視、後方監視）に対してそれぞれ対応するＥＣＵ（１ａ〜１ｆ）が割り当てられている。そして、各ＥＣＵが独立して処理を実行する。したがって、分散処理型システムにおいては、下記の３つのメリットが得られる。
（１）ＥＣＵ毎に独立してプログラムを開発できる。
（２）障害が発生した場合の復旧が容易。
（３）新たな機能の追加は、新たなＥＣＵを追加するだけで実現される。

ところが、分散処理型システムでは、処理すべきアプリケーションが増加すると、ＥＣＵの個数も増加するので、ワイヤーハーネスの増加に伴う重量増加、実装体積の増加、消費電力の増大等の問題が生じる。そこで、この問題を解決するために、図１Ｂに示すように、外部環境を検出するための複数のセンサと１個の集中処理ユニット２とをＬＡＮで接続し、集中処理型ユニット２が複数のアプリケーションを並列に実行する構成（以下、集中処理型システム）が提案されている。

集中処理型システムにおける従来の構成としては、図２Ａ〜図２Ｃに示す３つの方式が知られている。以下、集中処理型システムにおいて６つのアプリケーションＡ〜Ｆを処理する場合について説明する。

図２Ａに示す第１の方式では、集中処理ユニット２が備えるプロセッサは１つだけである。そして、アプリケーションＡ〜Ｆは、リアルタイムＯＳのタスク切替え機能を利用して、時分割で処理される。この場合、要求される応答時間を満足するためには、すべてのアプリケーションを処理してもなおプロセッサの処理能力に余裕がある必要がある。ここで、必要となる処理能力は、近似的には、図１Ａに示した処理ユニット１ａ〜１ｆの処理量の総和に時分割処理のオーバーヘッドを加えることにより求められる。したがって、処理すべきアプリケーションの数が増えると、高性能、高価格、高消費電力のプロセッサが必要となる。

図２Ｂに示す第２の方式では、集中処理ユニット２は、マルチプロセッサシステムである。ここでは、集中処理ユニット２は、４個のプロセッサエレメント（ＰＥ０〜ＰＥ３）を内蔵する。そして、アプリケーションＡ〜Ｆは、リアルタイムＯＳを利用して、プロセッサエレメントＰＥ０〜ＰＥ３に動的に割り当てられる。よって、この方式においても、必要な応答性を確保するためには、４つのプロセッサエレメントを用いて６つのアプリケーションを実行してもなお処理能力に余裕のあることが要求される。そして、この場合に必要な処理能力は、概ね、第１の方式と同じである。このため、第２の方式においても、高性能なマルチプロセッサが必要となり、低コストおよび低消費電力を実現することは困難である。

図２Ｃに示す第３の方式では、集中処理ユニット２は、実行すべきアプリケーションの数と同数のプロセッサエレメントを備える。すなわち、アプリケーションＡ〜Ｆは、それぞれプロセッサエレメントＰＥ０〜ＰＥ５に固定的に割り当てられている。この構成においては、各プロセッサエレメントは、時分割処理を行う必要がなく、予め決められたアプリケーションを実行するだけでよいので、システム構成は比較的簡単である。

このように、集中処理型システムは、分散処理型システムの問題点を解決するために提案されている。しかし、第１および第２の方式では、分散処理型システムの特徴（１）〜（３）を満足することができない。また、第３の方式は、上記（１）および（２）は満足するが、上記（３）を満足することができない。

なお、関連する技術として、特許文献１、２には、複数のプロセッサを備えるコンピュータシステムの信頼性を高める技術が開示されている。
特開２００６−１１９９２号公報 特開２００２−２５９１５５号公報

本発明の目的は、プログラムの開発、障害の復旧、機能の追加が容易なマルチプロセッサシステムを提供することである。
本発明のマルチプロセッサシステムは、複数のプロセッサエレメントと制御対象装置とを有する。そして、本発明のマルチプロセッサシステムは、前記制御対象装置の動作状況に基づいて複数のアプリケーションプログラムの中から実行すべきアプリケーションプログラムを動的に選択する選択手段と、前記選択手段により選択されたアプリケーションプログラムを前記複数のプロセッサエレメントに割り当てる割当て手段、を有する。

上記マルチプロセッサシステムにおいて、制御対象装置の動作状況が変化すると、選択手段は、新たな動作状況に対応するアプリケーションプログラムを選択する。そして、割当て手段は、選択されたアプリケーションプログラムを複数のプロセッサエレメントに割り当てる。したがって、制御対象装置の動作状況に応じて必要なアプリケーションプログラムを選択的に実行することができる。このとき、各アプリケーションプログラムは、特定のプロセッサエレメントに固定的に割り当てられるのではなく、任意のプロセッサエレメントに割当て可能である。

よって、各アプリケーションプログラムは、他のアプリケーションプログラムから独立して開発することができ、修正作業が容易である。また、複数のプロセッサエレメントの中の一部が故障しても、実行すべきアプリケーションプログラムを残りの正常なプロセッサエレメントに割り当てることができる。さらに、アプリケーションの追加は、ハードウェア構成を変更することなく、割当てシーケンスを変更することにより実現される。

分散処理型システムを模式的に示す図である。 集中処理型システムを模式的に示す図である。 従来の集中処理型システムの構成を示す図（その１）である。 従来の集中処理型システムの構成を示す図（その２）である。 従来の集中処理型システムの構成を示す図（その３）である。 本発明の概要を説明する図である。 実施形態のマルチプロセッサシステムのハードウェア構成を示す図である。 走行状況判定テーブルおよび優先処理情報テーブルの実施例である。 実施形態のマルチプロセッサシステムのソフトウェア構成を示す図である。 走行状況を判定する手順を示すフローチャートである。 アプリケーションをプロセッサエレメントに割り当てる処理のフローチャートである。 走行状況の変化に応じてアプリケーションを変更する様子を模式的に示す図である。 アプリケーション数がプロセッサエレメント数よりも多い場合の割当て方法を示すフローチャートである。 優先処理情報テーブルの実施例である。 異なる能力を持ったプロセッサエレメントが含まれている場合の優先処理情報テーブルの実施例である。 異なる能力を持ったプロセッサエレメントが含まれている場合の割当て手順を示すフローチャートである。

本発明の実施形態のマルチプロセッサシステムは、制御対象装置に組み込まれて使用される。ここで、制御対象装置は、特に限定されるものではないが、例えば、自動車、航空機、鉄道車両、船舶などを想定する。以下の説明では、制御対象装置が自動車であるものとする。

近年の自動車は、一般に、その走行を制御するために様々なアプリケーションを搭載している。例えば、車間距離を測定して自動的にブレーキを働かせる機能、ドライバの動作を監視して必要に応じてアラームを発生する機能などが広く知られている。ところが、これらのアプリケーションは、必ずしも、そのすべてが同時に必要とされるわけではない。すなわち、例えば、高速走行時には衝突防止機能は重要であるが、低速走行時には必ずしも必要ではない。また、ナイトビジョン機能は夜間では重要であるが、昼間は必要ない。このように、自動車の個々の走行状況においては、搭載されているすべてのアプリケーションの機能は必要ではないという点に着目し、本発明の実施形態の制御システムでは、自動車の走行状況に応じて実行すべきアプリケーションが動的に選択される。以下、図３を参照しながら、本発明の実施形態の概要を説明する。

図３において、マルチコアプロセッサユニット１１は、複数のプロセッサエレメント（ＰＥ０〜ＰＥ３）を備える。各プロセッサエレメントＰＥ０〜ＰＥ３は、それぞれ割当てられたアプリケーションプログラムを実行することにより対応する機能を提供する。なお、この実施例では、アプリケーションとして、前方監視（衝突検知）、前方監視（白線検知）、ナイトビジョン、側方監視、後方監視、ドライバ監視、エアバック用乗員監視、室内快適制御、セキュリティ監視などが予め用意されているものとする。

実施形態の自動車は、外部環境および動作状態を検出するための各種センサ１０１を搭載している。搭載しているセンサは、例えば、走行速度を検出する車速センサ、ステアリングの操舵角を検出する舵角センサ、加速度を検出するＧセンサ、ヨーレートセンサ、日射センサ等である。また、この自動車は、動作モードを指定するためのモードスイッチ１０２を備える。モードスイッチとしては、例えば、ＡＣＣ（Adaptive Cruise Control）、ＰＣＳ（Pre-Crash Safety）、ＶＤＣ（Vehicle Dynamic Control）を働かせるか否かを指示するスイッチ、ウインカーを動作させるか否かを指示するスイッチ、ライトを点灯させるか否かを指示するスイッチ、自動変速機に指示を与えるための入力ユニットなどを備える。

走行状況判定テーブル１２には、各種センサから得られるセンサ情報および各種モードスイッチから得られるモード情報に基づいて自動車の走行状況を判定するための情報が格納されている。すなわち、センサ情報およびモード情報を利用して走行状況判定テーブル１２を参照することにより、走行状況を検出することができる。なお、この実施例では、本発明に係わるマルチプロセッサシステムが自動車に組み込まれることを前提としているので、「走行状況」が検出されるが、一般には、動作状況が検出されることになる。

優先処理情報テーブル１３には、走行状況パターン毎に、実行すべきアプリケーションを指定する情報が登録されている。ここで、実行すべきアプリケーションは、走行状況パターン毎に、優先順位が付与されている。

選択部１４は、優先処理情報テーブル１３を参照し、走行状況に応じて実行すべきアプリケーションを選択する。なお、走行状況は時々刻々と変化するので、選択部１４は、変化する走行状況に応じて、実行すべきアプリケーションを動的に選択することになる。

割当て部１５は、選択部１４により選択されたアプリケーションをプロセッサエレメントＰＥ０〜ＰＥ３に割り当てる。そして、プロセッサエレメントＰＥ０〜ＰＥ３は、それぞれ割り当てられたアプリケーションを実行する。これにより、自動車を制御するための複数の機能が並列に提供される。

このように、実施形態のシステムでは、自動車の走行状況に応じて対応するアプリケーションが動的に選択されて実行される。したがって、実施形態のシステムでは、「用意されているアプリケーションの総数」よりも「マルチコアプロセッサユニット１１に内蔵されているプロセッサエレメントの個数」が少ない場合であっても、各走行状況において必要となるアプリケーションの数は「用意されているアプリケーションの総数」よりも一般的に少ないため、必要となるアプリケーションを実行することができる。そして、実施形態のシステムによれば、下記の効果が得られる。
（１）図１Ａに示した分散処理型システムと同様に、３つのメリット（プログラムの開発が容易、障害の復旧が容易、機能の追加が容易）が得られる。この点では、図２Ａ〜図２Ｃに示す従来の集中処理型システムよりも優れている。
（２）各アプリケーションごとにそれぞれＥＣＵを設ける必要がないので、分散処理型システムと比較して、低コスト化、小型化、軽量化、低消費電力化において優れている。
（３）分散処理型システムまたは図２Ｃに示す構成では、走行状況によっては実質的に動作していないＥＣＵが存在することとなるが、実施形態のシステムではプロセッサ資源が効率的に使用される。
（４）各センサから得られるセンサ情報を統合して処理するセンサフュージョンが可能となり、高度な処理を提供することができる。

図４は、実施形態の制御システムを実現するマルチプロセッサシステムのハードウェア構成を示す図である。ここでは、このマルチプロセッサシステムは、自動車の走行を制御するためにその自動車に組み込まれて使用されるものとする。

マルチコアプロセッサユニット１１は、４個のプロセッサエレメントＰＥ０〜ＰＥ３を備える。なお、マルチプロセッサシステムが備えるプロセッサエレメントの個数は、特に限定されるものではない。そして、各プロセッサエレメントＰＥ０〜ＰＥ３は、それぞれメモリバス２１に接続されると共に、Ｉ／Ｏバス２２に接続されている。また、各プロセッサエレメントＰＥ０〜ＰＥ３は、Ｉ／Ｏバス２２を介してローカルエリアネットワーク（ＬＡＮ１、ＬＡＮ２）に接続されている。なお、ローカルエリアネットワーク上には、図１Ｂに示すように、各種センサ（カメラを含む）が接続されており、各プロセッサエレメントＰＥ０〜ＰＥ３は、このローカルエリアネットワークを介して各センサが収集するセンサ情報を受け取ることができる。

メモリ３１は、例えばＳＤＲＡＭであり、メモリバス２１に接続されている。メモリ３１には、図３を参照しながら説明した走行状況判定テーブル１２および優先処理情報テーブル１３が設けられる。また、アプリケーションプログラムは、不揮発性メモリ３２からこのメモリ３１にロードされる。なお、各プロセッサエレメントＰＥ０〜ＰＥ３は、それぞれメモリバス２１を介してメモリ３１にアクセスすることができる。

不揮発性メモリ３２は、例えばフラッシュＲＯＭであり、Ｉ／Ｏバス２２に接続されている。なお、不揮発性メモリ３２は、メモリ３１にロードすべき情報（アプリケーションプログラム、走行状況判定テーブル１２、優先処理情報テーブル１３を含む）を保持している。

受付ユニット３３は、各センサにより得られるセンサ情報および各モードスイッチにより得られるモード情報を定期的に収集する。収集したセンサ情報およびモード情報は、走行状況レジスタ３４に書き込まれる。そして、センサ情報またはモード情報の少なくとも一つが変化したことを検出すると、受付ユニット３３は、自動車の走行状況が変化したことを表す状況変化信号を出力する。そして、割込みコントローラ３５は、状況変化信号を受信すると、動作状態管理モジュール３６を備えるプロセッサエレメントに対して、走行状況の変化に起因する割込み信号を送信する。なお、センサ情報および／またはモード情報は、自動車に搭載されている制御系のネットワークを介して受付ユニット３３に与えられるようにしてもよい。

プロセッサエレメントは、走行状況の変化に起因する割込み信号を受信すると、動作状態管理モジュール３６を起動する。動作状態管理モジュール３６は、走行状況判定テーブル１２および優先処理情報テーブル１３を参照し、実行すべきアプリケーションを選択する。そして、選択したアプリケーションをそれぞれ対応するプロセッサエレメントに割り当てる。これにより、自動車の走行状況に応じたアプリケーションが実行されることになる。

なお、動作状態管理モジュール３６は、図４に示す例ではプロセッサエレメントＰＥ３に設けられているが、他のプロセッサエレメントに設けられてもよい。ただし、動作状態管理モジュール３６は、優先度の低いアプリケーションが割り当てられるプロセッサエレメントに設けられることが好ましい。例えば、アプリケーション割当て規則として、最も優先度の高いアプリケーションをプロセッサエレメントＰＥ０に割り当て、２番目、３番目に優先度の高いアプリケーションをそれぞれプロセッサエレメントＰＥ１、ＰＥ２に割り当てることが決められているシステムにおいては、動作状態管理モジュール３６は、プロセッサエレメントＰＥ３において動作することが好ましい。

図５は、走行状況判定テーブル１２および優先処理情報テーブル１３の実施例である。走行状況判定テーブル１２においては、センサ情報およびモード情報の組合せに対してそれぞれ対応する走行状況が定義されている。ここで、この実施例では、各センサ情報は、閾値との比較結果により表される。例えば、車速センサに係わるセンサ情報は「高速／低速」により表され、日射センサに係わる情報は「強／弱」により表される。また、モード情報は、基本的に「オン／オフ」により表される。そして、１セットのセンサ情報およびモード情報を取得すると、それに一意に対応する走行状況が得られる。図５に示す例では、「車速：高速」「舵角：小」「日射：強」「加速度：小」「ヨーレート：小」「スロットル：小」「ＨＬ：オフ」「ＡＣＣ：オン」「ＰＣＳ：オン」「ウインカー：オフ」が検出されたときには、「走行状況１（ハイウェイモード１）」が得られる。

優先処理情報テーブル１３においては、各走行状況に対して、実行すべきアプリケーション、および実行すべきアプリケーションの優先順位が定義されている。図５に示す例では、例えば、走行状況１においては、実行すべきアプリケーションは「前方監視Ｈ」「側方監視Ｌ」「ドライバ監視」である。そして、「前方監視Ｈ」に対して最も高い優先度が与えられ、「側方監視Ｌ」に対して２番目に高い優先度が与えられ、「ドライバ監視」に対して最も低い優先度が与えられている。なお、「Ｈ」は高精度の制御を意味し、「Ｌ」は精度の低い制御を意味する。さらに、各アプリケーションが実行されたときのプロセッサエレメントの負荷率もあわせて記述されている。

このように、走行状況判定テーブル１２においては、センサ情報およびモード情報の組合せに対して「走行状況」が定義されている。また、優先処理情報テーブル１３においては、「走行状況」毎に、実行すべきアプリケーションおよびその優先順位が定義されている。よって、センサ情報およびモード情報を利用してこれらのテーブルを参照すれば、実行すべきアプリケーション（およびその優先順位）が一意に導き出される。

なお、図５に示す実施例では、走行状況判定テーブル１２および優先処理情報テーブル１３が分離されている。よって、この構成によれば、走行状況の判定および実行すべきアプリケーションの選択を互いに独立して行うことができる。ただし、本発明はこの構成に限定されるものではなく、これらのテーブルの内容を統合した１つのテーブルを設けるようにしてもよい。

図６は、実施形態のマルチプロセッサシステムのソフトウェア構成を示す図である。図６に示すように、各プロセッサエレメント上でリアルタイムＯＳが動作する。このリアルタイムＯＳは、プロセッサエレメント間通信ライブラリを備えている。また、このリアルタイムＯＳ上で各アプリケーションが動作する。そして、この実施形態のマルチプロセッサシステムでは、ＯＳレイヤとアプリケーションレイヤとの間のレイヤで動作する動作状態管理モジュール３６を備える。なお、本動作管理モジュール３６はOSの中の機能として組み込まれていても良い。動作状態管理モジュール３６は、後で詳しく説明するが、走行状況判定テーブル１２および優先処理情報テーブル１３を参照し、実行すべきアプリケーションを選択し、選択したアプリケーションをそれぞれ対応するプロセッサエレメントに割り当てる。図６に示す例では、アプリケーションＡ、Ｂ、Ｅ、Ｇが選択され、それぞれプロセッサエレメントＰＥ０、ＰＥ１、ＰＥ２、ＰＥ３に割り当てられている。

なお、動作状態管理モジュール３６は、１つのプロセッサエレメントに実装するようにしてもよいし、複数のプロセッサエレメントに実装するようにしてもよい。
次に、図４を参照しながら、上記構成のマルチプロセッサシステムの動作を説明する。なお、ここでは、プロセッサエレメントＰＥ３において動作状態管理モジュール３６が動作するものとする。また、メモリ３１には、図５に示す走行状況判定テーブル１２および優先処理情報テーブル１３が格納されているものとする。

（１）受付ユニット３３は、定期的に、センサ情報およびモード情報を収集する。新たに収集した情報は、先に収集した情報と比較される。ここで、先に収集した情報は、走行状況レジスタ３４に保持されている。そして、先に収集した情報および新たに収集した情報が互いに一致しなかったときは、自動車の走行状況が変化したものと判断し、状況変化信号を出力する。そして、割込みコントローラ３５は、状況変化信号を受信すると、動作状態管理モジュール３６を備えるプロセッサエレメントＰＥ３に対して、走行状況の変化に起因する割込み信号を送信する。また、このとき、新たに収集されたセンサ情報およびモード情報は、走行状況レジスタ３４に書き込まれる。

（２）プロセッサエレメントＰＥ３は、この割込み信号が与えられると、動作状態管理モジュール３６を呼び出す。動作状態管理モジュール３６は、Ｉ／Ｏバス２２を介して受付ユニット３３にアクセスし、走行状況レジスタ３４から最新のセンサ情報およびモード情報を読み出す。そして、動作状態管理モジュール３６は、センサ情報およびモード情報に対応する走行状況を識別する走行状況番号を走行状況判定テーブル１２から抽出する。

（３）動作状態管理モジュール３６は、走行状況判定テーブル１２から抽出した走行状況番号を利用して優先処理情報テーブル１３にアクセスする。これにより、現在の走行状況において実行すべきアプリケーションおよびその優先順位が得られる。

（４）動作状態管理モジュール３６は、実行すべきアプリケーションをその優先順位に従ってプロセッサエレメントＰＥ０〜ＰＥ３に割り当てる。このとき、これらのアプリケーションは、優先度の高い順番に、プロセッサエレメントＰＥ０、ＰＥ１、ＰＥ２、ＰＥ３に割り当てられるようにしてもよい。この場合、例えば、図５に示す走行状況１においては、「前方監視Ｈ」「側方監視Ｌ」「ドライバ監視」が、それぞれプロセッサエレメントＰＥ０、ＰＥ１、ＰＥ２に割り当てられる。また、走行状況２においては、「前方監視Ｈ」「ナイトビジョン」「側方監視Ｌ」「ドライバ監視」が、それぞれプロセッサエレメントＰＥ０、ＰＥ１、ＰＥ２、ＰＥ３に割り当てられる。これにより、走行状況に応じたアプリケーションが実行されることになる。

（５）自動車の走行状況が変化したときには、センサ情報またはモード情報の少なくとも一部が変化しているはずである。したがって、最新のセンサ情報またはモード情報を利用して上記（１）〜（４）を実行することにより、走行状況の変化に応じて新たなアプリケーションがプロセッサエレメントＰＥ０〜ＰＥ３に割り当てられる。すなわち、自動車の走行状況に応じて、実行すべきアプリケーションが動的に切り替えられる。

図７は、走行状況を判定する手順を示すフローチャートである。なお、ステップＳ１〜Ｓ４は受付ユニット３３（および、割込みコントローラ３５）により実行され、ステップＳ５〜Ｓ７は動作状態管理モジュール３６により実行される。

ステップＳ１〜Ｓ２では、センサ情報およびモード情報を定期的に収集し、走行状況が変化したか否かをチェックする。走行状況が変化した場合は、ステップＳ３において、マルチコアプロセッサユニット１１に対して割込み信号を出力する。そして、ステップＳ４において、ステップＳ１で収集したセンサ情報およびモニタ情報を走行状況レジスタ３４に書き込む。

ステップＳ５は、走行状況の変化に起因する割込み信号を待ち受けるステップである。そして、この割込み信号を受信すると、動作状態管理モジュール３６が起動される。ステップＳ６では、走行状況レジスタ３４に保持されているセンサ情報およびモード情報を読み出す。そして、ステップＳ７において、走行状況判定テーブル１２を参照することにより、現在の走行状況を識別する走行状況番号を取得する。このように、図７に示すフローチャートの処理を実行することにより、現在の走行状況が検出される。

図８は、アプリケーションをプロセッサエレメントに割り当てる処理のフローチャートである。なお、この処理は、図７に示すフローチャートのステップＳ７に続いて動作状態管理モジュール３６により実行される。また、ここでは、動作状態管理モジュール３６がプロセッサエレメントＰＥ３において動作するものとする。さらに、各走行状況における実行すべきアプリケーションの数がプロセッサエレメントの数と同数またはそれよりも少ないものとする。

ステップＳ１１〜Ｓ１２では、取得した走行状況番号を利用して優先処理情報テーブル１３を参照する。これにより、実行すべきアプリケーションおよびそれらの優先順位が検出される。ステップＳ１３〜Ｓ１４では、実行すべきアプリケーションを優先順位に従ってプロセッサエレメントに割り当てる。この場合、まず、優先順位の最も高いアプリケーションがプロセッサエレメントＰＥ０に割り当てられる。続いて、２番目に優先順位の高いアプリケーションがプロセッサエレメントＰＥ１に割り当てられる。以下、同様に、優先順位が３番目、４番目のアプリケーションがプロセッサエレメントＰＥ２、ＰＥ３に割り当てられる。ただし、実行すべきアプリケーションが３個以下であれば、アプリケーションが割り当てられないプロセッサエレメントが存在することになる。また、実行すべきアプリケーションが５個以上ある場合は、実行されないアプリケーションが存在することとなる。

ステップＳ１５では、ＰＥ／アプリケーション割当てテーブルを作成する。ここでは、プロセッサエレメントＰＥ０、ＰＥ１、ＰＥ２、ＰＥ３に対してそれぞれアプリケーションＡ、Ｂ、Ｃ、Ｄが割り当てられたものとする。

ステップＳ１６では、プロセッサエレメントＰＥ３においてＯＳを呼び出し、PE間通信ライブラリを使用したリモートタスク終了機能を利用してプロセッサエレメントＰＥ０〜ＰＥ２のタスクを終了させる。ステップＳ１７では、プロセッサエレメントＰＥ３においてＯＳを呼び出し、プロセッサエレメントＰＥ３のタスクを終了させる。

ステップＳ１８では、プロセッサエレメントＰＥ３においてＯＳを呼び出し、PE間通信ライブラリを使用したリモートタスク起動機能を利用してプロセッサエレメントＰＥ０にアプリケーションＡを起動させる。同様に、ステップＳ１９、Ｓ２０では、プロセッサエレメントＰＥ１、ＰＥ２にそれぞれアプリケーションＢ、Ｃを起動させる、ステップＳ２１では、プロセッサエレメントＰＥ３においてＯＳを呼び出し、アプリケーションＤを起動させる。上記手順により、アプリケーションＡ〜ＤがそれぞれプロセッサエレメントＰＥ０〜ＰＥ３により実行される。

図９は、走行状況の変化に応じてアプリケーションを変更する様子を模式的に示す図である。ここでは、自動車の走行状況が状態１から状態２に移行した場合が描かれている。走行状況１においては、プロセッサエレメントＰＥ０〜ＰＥ３において「前方監視（衝突検知）」「前方監視（白線検知）」「側方監視」「ドライバ監視」が実行されている。走行状況２に移ると、プロセッサエレメントＰＥ０〜ＰＥ３は、「前方監視（衝突検知）」「ナイトビジョン」「前方監視（白線検知）」「側方監視」を実行するようになる。

図１０は、他の割当て方法を示すフローチャートである。なお、このフローチャートの処理は、実行すべきアプリケーションの数がプロセッサエレメントの数よりも多い場合に実行される。また、ここでは、検出された走行状況が図１１に示す状態ｋであったものとする。

まず、ステップＳ１１〜Ｓ１２においては、優先処理情報テーブル１３を参照し、実行すべきアプリケーションを検出する。このとき、各アプリケーションの優先順位および負荷率も検出される。ステップＳ１３、Ｓ３１では、優先順位が１〜４番目のアプリケーション（すなわち、アプリケーションＡ〜Ｄ）をそれぞれプロセッサエレメントＰＥ０〜ＰＥ３に割り当てる。

ステップＳ３２では、プロセッサエレメントへの割当てがなされていないアプリケーションが残っているかチェックする。そして、そのようなアプリケーションが残っていたときは、ステップＳ３３において、各プロセッサエレメントの処理能力をチェックする。ここでは、プロセッサエレメントＰＥ０〜ＰＥ３にそれぞれアプリケーションＡ〜Ｄが既に割り当てられている。よって、プロセッサエレメントＰＥ０、ＰＥ１、ＰＥ２、ＰＥ３の残りの処理能力は、それぞれ、２０％、５０％、５０％、６０％となっている。

ステップＳ３４では、プロセッサエレメントへの割当てがなれていないアプリケーション（ここでは、アプリケーションＥ、Ｆ）を、処理能力の残っているプロセッサエレメントに割り当てる。ここでは、プロセッサエレメントＰＥ０は、処理能力が２０％しか残っていない。すなわち、プロセッサエレメントＰＥ０は、アプリケーションＥ、Ｆを実行することができない。よって、アプリケーションＥは、プロセッサエレメントＰＥ１に割り当てられる。また、ステップＳ３２〜Ｓ３４を再実行することにより、アプリケーションＦは、プロセッサエレメントＰＥ２に割り当てられる。

以降の処理は、基本的に、図８を参照しながら説明した手順と同じである。すなわち、ステップＳ３５においてＰＥ／アプリケーション割当てテーブルの作成が終了すると、ステップＳ３６〜Ｓ３７において各プロセッサエレメントのタスクを終了させる。続いて、ステップＳ３８〜Ｓ４１において、各アプリケーションＡ〜Ｆを起動させる。

このように、図１０に示す割当て方法によれば、プロセッサエレメントの個数よりも多くのアプリケーションを並列に実行することができる。よって、マルチプロセッサシステムの低コスト化が図れる。また、各プロセッサエレメントに割り当てられるアプリケーションの総処理量がそのプロセッサエレメントの処理能力を超えないので、各アプリケーションのリアルタイム性が確保される。

ところで、マルチプロセッサシステムが備える各プロセッサエレメントの処理能力は、必ずしも互いに同じである必要はない。すなわち、予め用意されているアプリケーションの中の一部が、ある特定のプロセッサエレメントによってのみ実行可能（或いは、ある特定のプロセッサエレメントによって実行されることが好適）である構成であってもよい。

例えば、プロセッサエレメントＰＥ０は、「前方監視Ｈ」を効率よく処理する機構を備え、プロセッサエレメントＰＥ３は、「ナイトビジョン」を効率よく処理する機構を備えているものとする。すなわち、「前方監視Ｈ」はプロセッサエレメントＰＥ０に割り当てられることが好ましく、「ナイトビジョン」はプロセッサエレメントＰＥ３に割り当てられることが好ましいものとする。この場合、これらの特定のアプリケーションついては、図１２に示すように、優先処理情報テーブル１３において、割り当てるべきプロセッサエレメントが固定的に定義される。

図１３は、異なる能力を持ったプロセッサエレメントが含まれている場合の割当て手順を示すフローチャートである。ここでは、優先処理情報テーブル１３において、実行すべきアプリケーションに含まれるアプリケーションＢが、プロセッサエレメントＰＥ０に固定的に対応づけられているものとする。

異なる能力を持ったプロセッサエレメントが含まれている場合の割当て手順は、基本的には、図８（または、図１０）に示した手順と同じである。ただし、ステップＳ５１において、実行すべきアプリケーションの中に特定のプロセッサエレメントが指定されているアプリケーションが含まれているか否かがチェックされる。そして、そのようなアプリケーションが存在する場合には、ステップＳ５２において、そのアプリケーションを指定されているプロセッサエレメントに割り当てる。この例では、他のアプリケーションに先だって、アプリケーションＢがプロセッサエレメントＰＥ０に割り当てられる。

ステップＳ５３〜Ｓ５４は、残りのアプリケーションについて、ステップＳ１３〜Ｓ１４と同様に処理を行う。これにより、プロセッサエレメントＰＥ０、ＰＥ１、ＰＥ２、ＰＥ３に対して、それぞれアプリケーションＢ、Ａ、Ｃ、Ｄが割り当てられる。以降の処理は、図８（または、図１０）を参照しながら説明した手順と基本的に同じである。

＜その他の実施形態＞
（１）マルチプロセッサシステムにおいて実行している処理の内容を表示装置に表示するようにしてもよい。表示装置には、例えば、実行中のアプリケーションが表示される。この場合、走行状況の変化に伴って実行するアプリケーションが変化すると、表示内容も変わることになる。

（２）センサ情報としてナビゲーションシステムからの情報を取得するようにしてもよい。
（３）動作状態管理モジュールは、優先順位の最も低いアプリケーションを実行するプロセッサエレメント上で動作するようにしてもよい。この場合、優先順位の高いアプリケーションの応答性が保証しやすくなる。

（４）走行状況の変化に応じてアプリケーションの割当てを変更する際には、各プロセッサエレメントをいったんリセットした後に再ブートを行うようにしてもよい。
（５）あるアプリケーションの処理量が大きい場合、或いは実行すべきアプリケーションの数がプロセッサエレメントの個数よりも少ない場合等には、１つのアプリケーションを複数のプロセッサエレメントに割り当てるようにしてもよい。

（６）上述の実施例では、センサ情報およびモード情報の双方に基づいて走行状況が判定されているが、センサ情報またはモード情報の一方に基づいて走行状況を判定するようにしてもよい。

Claims (4)

1. 複数のプロセッサエレメントを備え、制御対象装置に組み込まれて使用されるマルチプロセッサシステムであって、
   前記制御対象装置の外部環境または動作状態を検出するセンサから得られるセンサ情報および前記制御対象装置の動作モードを指定するモード情報を受信する受信手段と、
   前記センサ情報およびモード情報の組合せにより定義される複数の動作状況と各動作状況において実行すべきアプリケーションプログラムとの対応関係を表す対応関係情報を格納する格納手段と、
   前記センサ情報およびモード情報を利用して前記格納手段を参照することにより、複数のアプリケーションプログラムの中から対応する複数のアプリケーションプログラムを動的に選択する選択手段と、
   前記選択手段により選択された複数のアプリケーションプログラムを前記複数のプロセッサエレメントに動的に割り当てる割当て手段、を有し、
   前記対応関係情報は、前記センサ情報およびモード情報の組合せにより定義される各動作状況に対して、実行すべきアプリケーションプログラムおよび各アプリケーションプログラムの優先順位を指定する情報を含み、
   前記選択手段および前記割当て手段は、前記複数のプロセッサエレメントの中の予め決められた１つのプロセッサエレメントに設けられ、
   前記割当て手段は、前記選択手段により選択された複数のアプリケーションを、前記選択手段および前記割当て手段が設けられていないプロセッサエレメントから割り当てていき、
   前記選択手段によって選択されたアプリケーションの数が前記プロセッサエレメントの数以上であるときは、前記割当て手段は、前記選択手段によって選択されたアプリケーションを、前記選択手段および前記割当て手段が設けられているプロセッサエレメントにも割り当てる
   ことを特徴とするマルチプロセッサシステム。
2. 請求項１に記載のマルチプロセッサシステムであって、
   前記対応関係情報は、前記センサ情報およびモード情報の組合せにより定義される各動作状況に対して、実行すべきアプリケーションプログラムとして前記プロセッサエレメントの個数と同数またはそれよりも少ない数のアプリケーションプログラムを指定する
   ことを特徴とするマルチプロセッサシステム。
3. 請求項１に記載のマルチプロセッサシステムであって、
   前記対応関係情報は、実行すべきアプリケーションプログラムの中に特定のアプリケーションプログラムが含まれている場合には、該特定のアプリケーションプログラムを特定のプロセッサエレメントに固定的に割り当てる情報を含む
   ことを特徴とするマルチプロセッサシステム。
4. 制御対象装置の動作を制御する制御システムであって、
   複数のプロセッサエレメントと、
   前記制御対象装置の外部環境または動作状態を検出するセンサと、
   前記制御対象装置の動作モードを指定する情報を入力する入力手段と、
   前記センサから得られるセンサ情報および前記入力手段から得られるモード情報の組合せにより定義される動作状況に基づいて、予め用意されている複数のアプリケーションプログラムの中から実行すべきアプリケーションプログラムを動的に選択する選択手段と、
   前記選択手段により選択されたアプリケーションプログラムを前記複数のプロセッサエレメントに割り当てる割当て手段、を有し、
   前記動作状況は、前記センサ情報およびモード情報の組合せにより定義される各動作状況に対して、実行すべきアプリケーションプログラムおよび各アプリケーションプログラムの優先順位を指定する情報を含み、
   前記選択手段および前記割当て手段は、前記複数のプロセッサエレメントの中の予め決められた１つのプロセッサエレメントに設けられ、
   前記割当て手段は、前記選択手段により選択された複数のアプリケーションを、前記選択手段および前記割当て手段が設けられていないプロセッサエレメントから割り当てていき、
   前記選択手段によって選択されたアプリケーションの数が前記プロセッサエレメントの数以上であるときは、前記割当て手段は、前記選択手段によって選択されたアプリケーションを、前記選択手段および前記割当て手段が設けられているプロセッサエレメントにも割り当てる
   ことを特徴とする制御システム。

Images