JP6803709B2 - 車両制御装置および車両制御システム - Google Patents

Description

本発明は、車両制御装置および車両制御システムに関する。

本技術分野の背景技術として、特開２０１６−０１３７８２号公報（特許文献１）がある。この公報には、「定時タスクの実行を適切に管理する車載電子制御装置を提供する。」ことを課題とし、解決手段として、「車載電子制御装置は、所定時間間隔で起動される定時タスクの処理Ａ、Ｂ、Ｃのうち必須の処理Ａを実行してから（Ｓ４００）、定時タスクが次回起動されるまでの現在時刻からの残り時間Ｘを算出し（Ｓ４０４）、定時タスクよりも優先度が上位の上位タスクが残り時間Ｘの間で実行される実行時間Ｚを残り時間Ｘの長さに応じて算出する（Ｓ４０８、Ｓ４１０、Ｓ４１２）。車載電子制御装置は、残り時間Ｘと実行時間Ｚとの差（Ｘ−Ｚ）を定時タスクの実行可能時間として算出し、実行可能時間に基づいて処理Ｂ、Ｃのうち処理Ｂを実行するか否かを判定する（Ｓ４１４）。車載電子制御装置は、Ｓ４１４の判定結果に基づいて処理Ｂの実行を管理する（Ｓ４１６、Ｓ４１８）。」と記載されている。

また別の背景技術として、特開２００５−０７１１４１号公報（特許文献２）がある。この公報には、「タスク構成が大きく変わらない限りタスク数が増加してもスタックの総容量を増加する必要がないと共に、高いスタック利用効率が得られるスタック管理方法を提供する。」ことを課題とし、解決手段として、「中断中の全タスクが共用可能なタスクスタックを設け、そのタスクスタックの記憶領域を所定のブロック長を持つ複数のブロックから構成して、前記データを前記ブロックに分けて記憶するようにする。あるタスクの実行を中断するために前記共有スタック内のデータを前記タスクスタックに退避する際には、前記共有スタック内のデータ量に応じて未使用の前記ブロックに記憶させ、当該ブロックの識別データと当該タスク用の識別データを記憶する。前記ブロック識別データと前記タスク識別データを用いて前記データを前記共有スタックに復帰する。」と記載されている。

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

上記背景技術ではタスクを優先度制御、時間駆動型スケジューリングにより動作させる場合に、タスクの有する条件に基づき効率的にシステムを動作させる方法について記載されている。

しかし、制御システムを高信頼化させるために用いられる時間駆動型スケジューリングなど、ある定められた時間内に動作させるタスクを固定するスケジューリング方式において、システム設計時のタスク統合を容易化させる方法については述べられていない。

特に制御周期が短いタスク（例：１ｍｓ周期）と、実行時間の長いタスク（例：５ｍｓ）を統合する場合には、実行時間の長いタスクを分割する必要があり、設計が困難である。

本発明は上記課題を鑑みて為されたものであり、タスクの統合を容易化させる車両制御装置および車両制御システムを提供する。

上記課題を解決するために、本発明の一実施の態様は、例えば特許請求の範囲に記載されている技術的思想を用いればよい。例えば、時間によりタスクを起動する制御を行う車両制御装置において、各タスクの起動時間に実行状態である実行中タスクを確認して、該実行中タスクが継続実行可能であるか否かを判定し、前記実行中タスクが継続実行可能と判定される場合には、前記実行中タスクの一時停止を行い、前記実行中タスクが継続実行可能でないと判定される場合には、前記実行中タスクの終了を行う。

本発明によれば、時間駆動スケジューリングを実現する際に、タスクの統合を容易化させることが可能となる。

本発明の第１の実施例にかかるスケジューリング実行時の判定フローである。 システムの例である。 車両制御システム構成の例である。 コントローラの構成例である。 コントローラのソフトウェアモジュール構成の例である。 タスクの状態遷移例である。 時分割制御のスロットとタスク実行の例である。 スケジュールテーブルの例である。 動作ログの例である。 本発明の第２の実施例にかかるタスク管理部のデータコピーの例である。 本発明の第３の実施例にかかる設計情報の例である。 本発明の第４の実施例にかかるスケジューリング実行時の判定フローである。 タスクの設計情報および動作情報の例である。 タスクの実行結果の例である。

以下、本発明に好適な実施形態の例（実施例）を説明する。本実施例は、主には車両システムにおける車両制御システム、および車両制御装置について説明しており、車両システムにおける実施に好適であるが、車両システム以外への適用を妨げるものではない。

＜車両制御システムの構成＞
図２は本実施例の車両制御システムおよび車両制御装置を有する車両システムの概要である。１は自動車など内部に車両制御システムを有する車両システム、２は例えば車載ネットワーク（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ、ＣＡＮＦＤ：ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ−ｒａｔｅ、Ｅｔｈｅｒｎｅｔ（登録商標）、等）とコントローラ（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ等）により構成される車両制御システム、３は、車両システム１の外部と無線通信（例えば携帯電話の通信、無線ＬＡＮ、ＷＡＮ、Ｃ２Ｘ（Ｃａｒ ｔｏ Ｘ：車両対車両または車両対インフラ通信）等のプロトコルを使用した通信、またはＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍを用いた通信）を行い、外界（インフラ、他車、地図）の情報または自車に関する情報を取得・送信などの無線通信を実施、または診断端子（ＯＢＤ）やＥｔｈｅｒｎｅｔ端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などを有し、車両制御システム２と通信を実施する通信装置、４は、例えば２と異なる、または同一のプロトコルを用いたネットワークにより構成される車両制御システム、５は、車両制御システム２の制御に従い、車両運動を制御する機械および電気装置（例えばエンジン、トランスミッション、ホイール、ブレーキ、操舵装置等）の駆動を行うアクチュエータ等の駆動装置、６は、外界から入力される情報を取得し、後述する外界認識情報を生成するための情報を出力する、カメラ、レーダ、ＬＩＤＡＲ、超音波センサなどの外界センサ、および、車両システム１の状態（運動状態、位置情報、加速度、車輪速度等）を認識する力学系センサにより構成される認識装置、７は、ネットワークシステムに有線または無線で接続され、ネットワークシステムから送出されるデータを受信し、メッセージ情報（例えば映像、音）など必要な情報を表示または出力する、液晶ディスプレイ、警告灯、スピーカなどの出力装置、８は、ユーザが車両制御システム２に対して、操作の意図や指示を入力する入力信号を生成するための、例えばステアリング、ペダル、ボタン、レバー、タッチパネル、等の入力装置、９は、車両システム１が外界に対して、車両の状態等を通知するための、ランプ、ＬＥＤ、スピーカ等の通知装置、を示している。

車両制御システム２は、その他の車両制御システム４、無線通信部３、駆動装置５、認識装置６、出力装置７、入力装置８、通知装置９などと接続され、それぞれ情報の送受信を行う。

図３は、車両制御システム２のＨ／Ｗ（Ｈａｒｄｗａｒｅ）構成例を示している。３０１は車載ネットワーク上のネットワーク装置を接続するネットワークリンクであり、例えばＣＡＮバスなどのネットワークリンク、３０２はネットワークリンク３０１および駆動装置５や認識装置６や３０１以外のネットワークリンク（専用線含む）に接続され、駆動装置５や認識装置６の制御および情報取得、ネットワークとのデータ送受信を行うＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：電子制御ユニット）、３０３は複数のネットワークリンク３０１を接続し、それぞれのネットワークリンクとデータの送受信を行うゲートウェイ（以下ＧＷ）、を示している。

ネットワークトポロジの例は、図３に示す２つのバスに複数のＥＣＵが接続されているバス型の例以外にも、複数のＥＣＵが直接ＧＷに接続されるスター型や、ＥＣＵが一連のリンクにリング状に接続されているリンク型、それぞれの型が混在し複数のネットワークにより構成される混在型、等がある。ＧＷ３０３とＥＣＵ３０２については、それぞれＧＷ機能を有するＥＣＵ、またはＥＣＵの機能を有するＧＷと、がある。

ＥＣＵ３０２はネットワークから受信したデータをもとに、駆動装置５への制御信号の出力、認識装置６からの情報の取得、ネットワークへの制御信号および情報の出力、内部状態の変更、などの制御処理を行う。
図４は、本発明にかかるネットワーク装置であるＥＣＵ３０２またはＧＷ３０３の内部構成の一例である。４０１はキャッシュやレジスタなどの記憶素子を持ち、制御を実行するＣＰＵ、ＧＰＵ、ＦＰＧＡなどのプロセッサ、４０２はネットワークリンク３０１またはネットワークや専用線で接続された駆動装置５または／および認識装置６に対してデータの送受信を行うＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）、４０３は図示しないクロックなどを使用し、時間および時刻の管理を行うタイマ、４０４はプログラムおよび不揮発性のデータを保存するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、４０５はプログラムおよび揮発性のデータを保存するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、４０６はＥＣＵ内部での通信に用いられる内部バス、を示している。

プロセッサはマルチコアと呼ばれる内部に１つ以上の複数の演算装置を持つものを含む。またタイマについては図に示す通りネットワーク経由でアクセスするものと、プロセッサ自身が有する場合の両方がある。

次にプロセッサ４０１で動作するソフトウェアモジュールの構成について図５に示す。５０１はソフトウェアモジュール全体の制御、特に後述するタスクを管理するタスク管理部、５０２は、通信Ｉ／Ｆ４０２の動作および状態を管理し、内部バス４０６を介し通信Ｉ／Ｆ４０２に指示を行う通信管理部、５０３は、タイマ４０３を管理し、時間に関する情報取得や制御を行う時間管理部、５０４は後述する動作ログを管理する動作ログ管理部、５０５は車両制御システム２を動作させるための演算や制御等を実行するためのタスク、５０６は車両制御に必要な情報を保持するデータテーブル、５０７は後述するスケジュールテーブル、５０８は後述する動作ログ、を表している。

これら図５の構成についてはプロセッサ４０１上の動作概念を示したものであり、動作時に必要な情報はＲＯＭ４０４およびＲＡＭ４０５から適宜取得、またはＲＯＭ４０４およびＲＡＭ４０５に適宜書き込み、を行い動作する。

＜タスク＞
タスク５０５は、スレッド、アプリケーション、プロセス、ソフトウェアコンポーネント（ＳＷＣ）とも呼ばれるソフトウェアモジュールの動作単位の一つであり、前述した通信管理部５０２および時間管理部５０３、動作ログ管理部５０４等もタスクである場合もある。

タスクは後述する状態遷移により実行状態となった場合にプロセッサ４０１により実行され、各タスクに割り当てられた制御（プログラムの実行）を行う。例えば通信管理部５０３またはＩ／Ｏ４０２を介してネットワークおよび駆動装置または認識装置からデータを入手、データテーブル５０６のデータに対して必要な処理の実行、通信管理部５０３またはＩ／Ｏ４０２を介してネットワークまたはＩ／Ｏにデータを出力する、等の処理を行い、車両制御システムを動作させる。

タスク間でデータを共有する場合には、データテーブル５０６の特定の領域に書き込み側タスクが書き込みを行い、また読み込み側タスクが前記特定の領域からデータを読み出すことによりデータの共有を行う。このデータに対するアクセスを行う場合に、後述する排他制御を実施する。

＜排他制御＞
タスク間でのデータの共有や動作の調停を行うため、各タスクは共有リソース（例えばプロセッサ４０１やメモリ領域（ＲＡＭ４０５、データテーブル５０６、等）、Ｉ／Ｏ４０２に対する排他制御を実施する。排他制御には、はセマフォ、ミューテックス、フラグ等を使用し、例えばあるタスクがセマフォを保有（減算）することにより、他のタスクは同じセマフォを保有できなくなる等の管理を行う。これにより、共有リソースへの排他制御を実現する。

＜タスクの状態遷移＞
図６にタスクの状態遷移の例について示す。タスク管理部５０１は前記タスク５０５に対して、このような状態遷移に基づき管理を行う。

まずタスク管理部５０１が新規に生成したタスクは、最初に休止状態に移行され、その後タスク管理部５０１が前記タスクを起動し、実行可能状態に遷移させる。

実行可能状態においては、例えば時間駆動スケジューリングにおいて、該当タスク（例えばタスクＴ１）が実行可能な時間（スロット）になった場合には、タスク管理部５０１はタスクＴ１が実行権を獲得したとし、実行状態に遷移させる。実行状態になったタスクについてはプロセッサ４０１にて前記タスクの処理を実行する。

その後、前記タスクが実行可能な時間が終了した場合、もしくは前記タスクの処理が終了し前記タスクが実行権を放棄する命令を発行した場合には、タスク管理部５０１はタスクＴ１を実行可能状態へと遷移させる。その際にタスク管理部５０１は次に実行すべきタスクが存在する場合には、次に実行すべきタスクを実行可能状態から実行状態へと遷移させる。

一方、実行状態にあるタスクが例えばリソースの要求を行い、排他制御によりリソースが取得できなかった場合には、タスク管理部５０１は前記タスクを待機状態へと遷移させる。待機状態に遷移したタスクはリソースが取得できるまでは待機状態となる。その後、別のタスクがリソースを解放するなどにより、前記待機状態のタスクがリソースを取得可能な状態になった場合には、タスク管理部５０１は前記リソースを要求して待機状態となっていたタスクを実行可能状態に遷移させる。

実行可能状態、実行状態、または待機状態であるタスクが、例えばタスク管理部５０１や他のタスク等から強制終了の命令を受けた場合には、前記命令を受けたタスクは休止状態となり、再びタスク管理部５０１から起動の命令を受けるまでは休止状態となる。タスク管理部５０１から起動の命令を受けた休止状態のタスクは、実行可能状態へと遷移する。

このようにタスクについてはタスク管理部５０１からの命令を受け、または自ら実行権の放棄、リソースの要求等を行うことによりこれらの状態遷移を行う。

ここでマルチコアなどの環境においては、前記実行状態のタスクが複数存在する場合もあるが、状態遷移としては同様に実施される。

待機状態においては、タスクの管理情報（スタック、ヒープ、前記タスクが管理するデータテーブルの領域、保有しているリソース）等は次の実行可能状態まで引き継がれ、休止状態では上記管理情報の一部および全てが初期化される。そのため待機状態から実行可能状態および実行状態になるまでの時間は短いが、休止状態から実行状態になるまでには時間がかかり、また休止状態となる前の管理情報を引き継げないため、タスクの処理が不連続となる場合がある。

また一方で、休止状態になり管理情報を初期化することにより、無限に同じ処理を繰り返す様な不正な状態から、初期状態などの不正で無い状態に戻すことも可能となる。

＜時分割制御＞
タスクの実行について、時分割で制御した場合の例について図７に示す。図７（ａ）は横軸が時間を示しており、それぞれの時間がスロット（ウィンドウ）として区切られ、それぞれのスロットにＩＤ（ここではＳ１からＳ１１）が割り振られている。ここで各スロットでは割り当てられたタスクのみが動作可能とすることで、時分割でのタスクの実行が可能となる。ある時刻で実行するタスクを選択する動作をスケジューリングと呼ぶ。

スケジューリングに用いるスケジュールテーブル５０７の構成について図８に示す。スケジュールテーブル５０７はスロットＩＤ、スロットの開始時刻、スロットの終了時刻、スロットに割り当てられたタスクのＩＤ、後述する跨り判定に使用する時間エラー判定フラグ、により構成されている。このようにして各スロットの時間と、その時間内で動作可能なタスクが予め割り振られている。

タスクの動作例について図７（ｂ）に示す。ここでタスク管理部５０１は時刻０．０において例えば前記タイマ４０３を用いたアラームにより動作開始する様に設定しておき、そのタイミングでスケジューリングを実施する。前記アラームにより動作開始したタスク管理部５０１は、現在時刻が０．０であると確認し、スロットＩＤがＳ１であることから、タスクＩＤがＴ１のタスクの状態を確認し、実行状態にするように処理を行う。その後タスク管理部５０１は次のスロット開始時刻（この例では時刻０．２）にアラームを設定して動作を終了する。その後タスクＴ１は処理を行い、処理が終了した場合には自らリソース要求等により待機状態に移行する。このようにして決められた時刻でのスケジューリングによるタスク実行処理を行う。

スケジュールテーブル５０７にはここでは開始時刻と終了時刻の両方を記載しているが、開始時刻のみでも良い。その場合には各スロットの終了時刻は次のスロットの開始時刻にて表現される。そのようにすることにより、スケジュールテーブル５０７のデータ量を削減可能である。

スロットにタスクが割り当てられていない場合には、専用のタスクＩＤにて現在のスロットにはタスクが割り当てられていないことを記載する。（図８のタスクＩＤ：ＮＡ）

＜跨り判定＞
次に跨り判定の処理について図１を用いて説明する。跨りとは、スロットの終端でタスクの処理が終了しない場合に強制終了するだけでなく、スロット内で処理が終了しないことが許可されるタスクを予め想定し、次の実行可能なスロットまでタスクの処理を一時停止させることである。

タスク管理部５０１が前記時分割制御に記載のスロット開始時刻のアラームにて動作開始した場合に、タスク管理部５０１は前のスロットのタスクが実行状態か否かの判定を行う（Ｓ１０１）。判定は、現在実行中のタスクのＩＤ、または前のスロットのタスクが待機状態に移行する際のリソースを要求しているか否か、等により行う。前のスロットのタスクが実行状態で無い場合には（Ｓ１０１のｎｏ）、次のタスクの実行時刻をスケジュールテーブル５０７から取得してアラームを設定し（Ｓ１０２）、現在のスロットのタスクをスケジュールテーブル５０７から取得して実行状態にする処理を行う（Ｓ１０３）。

前のスロットのタスクが実行状態である場合には（Ｓ１０１のｙｅｓ）、前のスロットの時間エラー判定フラグの内容を判定する。前記時間エラー判定フラグが“する”の場合（Ｓ１０４のｙｅｓ）、前のスロットのタスクを強制終了させる。その際には後述する方法でエラー情報を含む動作ログを作成し（Ｓ１０５）、現在実行状態のタスクを強制終了させて休止状態にする（Ｓ１０６）その後は通常時同様、次のタスクの実行時刻をスケジュールテーブルから判定してアラームを設定し（Ｓ１０２）、現在のスロットのタスクをスケジュールテーブルから判定して実行状態にする処理を行う（Ｓ１０３）。

一方で、前記時間エラー判定フラグが“しない”の場合（Ｓ１０４のｎｏ）、前のスロットのタスクについては待機状態にする（Ｓ１０７）その後は通常時同様の処理を実行する（Ｓ１０２、Ｓ１０３）。

このようにして時分割制御による跨り処理を実行することにより、タスクに設定された時間エラー判定フラグの状態に応じて、タスクを待機状態にすることや強制終了を行い、他のウィンドウを跨るタスクの処理について実行可能となる。

Ｓ１０３において、現在スロットのタスクを実行する際には、実行するタスクの現在の状態に応じて処理を行う。例えば待機状態（自らリソースの取得要求による待機状態、またはタスク管理部により待機命令）であれば、それぞれの待機状態に応じたリソースの開放や実行可能状態への遷移命令により動作を再開する。また休止状態であれば、起動により実行可能状態と遷移させる。

前のスロットのタスクが実行状態であった場合の処理として、タスク管理部５０１は、強制終了の代わりに一度待機状態にさせ、次のタスクを実行状態にした後等に休止状態にさせても良い。そのようにすることにより次のタスクを早く実行状態にすることが可能になる。

＜子タスクの管理＞
前記跨り処理においては、それぞれのタスクが生成した子タスクについても同様に管理することが必要となる。例えばスロットＩＤＳ３にて、タスクＴ３が子タスク（例えばタスクＴ３Ａ）を生成した場合、跨り処理においては子タスクも同様に待機状態にする必要がある。そのためタスク管理部５０１は、待機状態にする処理をタスクＴ３およびタスクＴ３Ａの双方に実施する。また同様に待機状態からの再開も、タスクＴ３およびタスクＴ３Ａの双方に実施する。これにより、タスクが子タスクを生成した場合にも、同様に跨り判定に基づく処理が可能となる。

上記子タスクへの処理については、子タスクを生成したタスクが、前記子タスクのＩＤをタスク管理部５０１に通知する、または各タスクが待機状態に遷移する命令を受けた場合に、各タスクの管理の基で、子タスクを待機状態に移行する、といった方法により実現可能である。

＜動作ログ＞
動作ログの作成方法について図９を用いて説明する。ここでは各スロットでのタスクの開始時刻、終了時刻、タスクＩＤ、終了時の状態について記録する例を示している。これら状態を動作ログ管理部５０８はタスク管理部５０１からタスクの状態遷移のタイミング等で受信し、動作ログ５０８として記録する。特に終了時の状態について前記跨り判定処理においてエラーログおよび跨り時の動作を記録しておくことにより、異常が発生したため強制終了したか、終了しなかったが想定通りの跨り処理が発生したかを動作ログから確認することが可能となる。

動作ログについては、前記通信管理部５０２およびネットワークリンク３０１および通信装置３等を介して外部に出力することにより、車両制御システムの状態を外部から監視可能となる。

本発明にかかる第２の実施例について説明する。第１の実施例と異なる点は、タスク管理部５０１が、タスク間で共有アクセスするデータについてコピーを行う点である。

図１０はタスク５０５とタスクがアクセスするデータテーブル５０７内部の領域について示したものである。ここで領域Ａはタスク１とタスク２が共にアクセスを行い、セマフォ等による排他制御が必要な領域である。そしてタスク２は跨りを行うタスクである。このような場合に、タスク２が領域Ａへのアクセスを行うためセマフォを獲得している際に、タスク２が前記跨り判定時の処理において一時停止を行った場合、タスク１が領域Ａにアクセスできず、デッドロック等を起こす可能性がある。

そこでタスク管理部５０１は、タスク２など跨りを行うタスクの実行開始時には、共有領域のデータについて、別の領域（例えば領域Ｂ）にコピーを行う。このようにすることにより、タスク２は排他制御を行うリソースにアクセスする必要が無くなり、デッドロックを防ぐことが可能となる。

また同様にタスク２の終了時、またはタスク２の次のタスクの実行開始前、またはタスク１の実行開始前に、前記領域Ｂのデータについて領域Ａに書き戻すことにより、タスク１からのデータアクセスに対しても正しく値を返すことが可能となる。

ここでタスク２の動作については、セマフォの獲得（排他制御リソースへのアクセス権限取得）命令についてタスク管理部５０１を介してアクセスし、アクセスするデータについて排他制御を行わない領域にコピーを行った場合には、前記タスク管理部５０１が前記セマフォの獲得命令を実行しない様に隠蔽することにより、上記コピーを行う場合と行わない場合とでタスク２のソースコードを置き変えすることなくソフトを移植することが可能となる。

この例でタスク２がアクセスするデータ領域を領域Ａから領域Ｂに変更する方法としては、仮想メモリの様なアクセス方式に対して物理メモリのマップを変更する、タスク２の保持するデータアクセスのアドレス、またはポインタを書き換える、ソースコードやオブジェクトコードの変数名（ラベル）を書き換える、等の手段により実現可能である。

ここでタスク管理部５０１がデータをコピーする時間については、タスク２のスロットの開始時間をｔ２、コピーの所要時間をｔｃとした場合、前のタスクが終了している場合には時刻ｔ２−ｔｃに開始を行うことが望ましい。そのようにすることにより、データのコピーを行う場合でも、タスクの実行開始時間を遅らせずに実行可能となる。同様にタスク２のスロットの開始時間前に上記書き戻し処理（所要時間ｔｃｒ）を行う場合には、その時間についても考慮し、ｔ２−ｔｃ−ｔｃｒの時間に処理を開始することが望ましい。

本発明にかかる第３の実施例について説明する。本実施例においては、スケジュールテーブル５０７について設計情報や動作時に測定した情報から自動的に作成を行う。

設計情報１１０１の例について図１１に示す。ここでは各タスクの設計情報について、タスクのＩＤ、制御周期、（最悪時）実行時間、跨り許可の有無、といった情報を与える。これら情報を基にスケジュールテーブル５０７を作成する。

これにより、例えばタスクＩＤがＴ３のタスクは、跨り許可がＯＫとなっていることから、例えば図８に示す様なスケジュールテーブルを作成し、跨りが発生するスロット（Ｓ３およびＳ５）について、時間エラー判定を“しない”とするフラグを付与する。このようにすることにより、設計情報１１０１から、スケジュールテーブル５０７を作成することが可能になる。

この例において設計情報１１０１でタスクＩＤがＴ２のタスクは跨り許可をＯＫとしているが、跨りを発生させずに配置可能であるため、時間エラー判定を“しない”とするフラグを付与しない。

またこの例において、タスクＩＤがＴ３のタスクの跨り許可がＮＧであった場合には、スケジュールテーブル５０７の自動作成時に、跨りＮＧのためスケジューリングテーブル作成が不可能である旨のエラーメッセージを通信管理部５０２を介してネットワークリンク３０１や通信装置３に出力する。

ここで跨り許可ＮＧとするタスクについては、例えば安全関連機能など、跨り等による処理の中断が好ましくないタスクについて跨り許可ＮＧという指示を与えることにより、自動作成時でも安全関連機能は跨りを発生させず、処理の遅延が発生しない設計が可能になる。

またスケジュールテーブルの作成については、上記設計情報１１０１からの作成だけでなく、ネットワークリンク３０１からの取得も可能である。これにより機能の更新時において、処理装置内部で計算するだけでなく、外部ネットワークからスケジュール情報を設定することも可能となる。

上記スケジュールテーブル５０７の自動作成については、車両制御システムの設計時や初回の起動時だけでなく、例えば車両制御システム２の起動時（イグニッションのＯＮ等）に毎回計算することや、車両制御システム２の構成が変更になった場合に、前記設計情報１１０１の制御周期や実行時間の再計算および再取得も含めて実行することも可能である。これによりシステムの状態の変化に合わせて、スケジュールテーブル５０７を再計算し、システムの状態に合わせたスケジュールテーブルの構築が可能となる。

本発明の第４の実施例にかかるスケジューリング実行時の判定フローについて、時間エラー判定フラグを用いず、設計情報である予定実行時間による自動判定を行う例について図１２を用いて説明する。第１の実施例と異なる点は、図１におけるＳ１０４の時間エラーフラグによる判定が、Ｓ１２０１の累積実行時間と想定実行時間による判定に置き換わっている点である。

ここで動作例について、図１３に記載されたタスクごとの制御周期および予定実行時間を基に、図１４に示す開始および終了時刻で各タスクが動作している例について説明する。

この場合で例えば時刻０．４において、タスクＴ２は、設計情報１１０１の示す予定実行時間（０．２）を超過しているため、Ｓ１２０１の判定のｙｅｓにより、前のスロットのタスク（Ｔ２）を強制終了させる。一方で時刻１．０において、タスクＴ３の累積実行時間（０．６ｍｓ）は図１３で示す設計情報の予定実行時間（２．２ｍｓ）を超過していないため、Ｓ１２０１の判定はｎｏとなり、跨り処理を行う。

このようにしてスケジュールテーブルによる時間エラー判定フラグを用いない場合でも、タスクごとの設計情報の予定実行時間と累積実行時間を比較することにより跨り判定を行うことが可能となる。

この場合、図１３に示す設計情報１３０１についてはスケジュールテーブル５０７、またはデータテーブル５０６などと同様にＥＣＵ内部に保有する。

以上説明した実施例によれば、時間駆動によるスケジューリングにおいて、他のタスクのスロットを跨る必要があるタスクが存在している場合に、タスクに跨り処理を許可する情報を付与し、跨り処理を許可されたタスクに対しスロットの終端で動作していた場合に一時停止する処理を行う。即ち、特定のタスクについては、タスクのウィンドウ時間を過ぎた場合でも強制終了させずにタスクの実行を一時中断する。これにより、時間駆動スケジューリングを実現する際に、実行時間の長いタスクを分割する再設計を不要にするなど、タスクの統合を容易化させつつかつ制御システムのタスクの動作時間に影響を与えないことが可能になる。これにより、時間駆動スケジューリングで動作する高信頼なシステムでタスクを統合することが容易となる。

また、前記タスクが子タスクを生成する処理を行う場合でも同様に跨り処理を行うことが可能となる。また、これら処理について動作ログを記録することにより、タスクが跨り等を行った場合でも外部からその動作が確認可能となる。

また別の実施例においては、タスク間で共有するデータがある場合に、前記データを予め別の領域に移すことにより、跨り処理時のタスクのリソース保持を防ぐことが可能となる。またそのタイミングを予めコピー時間を考慮したタイミングで実施することにより、タスクの実行開始を遅らせることなく実行状態に移行することが可能となる。

また別の実施例においては、スケジュールテーブルについて設計情報や測定した動作の情報から自動的に跨り処理を含むテーブルを作成することが可能となる。

さらに別の実施例では、跨り処理を実施するフラグを有しない場合でも、タスクの予定実行時間と累積実行時間から跨り処理を行うか否かを判定し、上記跨り処理を実現することが可能となる。

１…車両システム、２…車両制御システム、３…通信装置、４…車両制御システム、５…駆動装置、６…認識装置、７…出力装置、８…入力装置、９…通知装置、３０１…ネットワークリンク、３０２…ＥＣＵ、３０３…ＧＷ、４０１…プロセッサ、４０２…Ｉ／Ｏ、４０３…タイマ、４０４…ＲＯＭ、４０５…ＲＡＭ、４０６…内部バス、５０１…タスク管理部、５０２…通信管理部、５０３…時間管理部、５０４…動作ログ管理部、５０５…タスク、５０６…データテーブル、５０７…スケジュールテーブル、５０８…動作ログ、１１０１…設計情報、１３０１…設計情報

Claims (10)

1. 時間によりタスクを起動する制御を行う車両制御装置において、
   各タスクの起動時間に実行状態である実行中タスクを確認して、該実行中タスクが継続実行可能であるか否かを判定し、
   前記実行中タスクが継続実行可能でないと判定される場合には、前記実行中タスクの終了を行い、
   前記実行中タスクが継続実行可能と判定される場合には、
   実行中タスクが実行されているスロットとは異なる、次に実行可能なスロットまで前記実行中タスクの一時停止を行い、前記次に実行可能なスロットになったタイミングで前記実行中タスクの実行を再開することを特徴とする車両制御装置。
2. 請求項１に記載の車両制御装置において、
   前記継続実行可能である場合の判断は、前記実行中タスクの起動時間からの累積実行時間により判定することを特徴とする車両制御装置。
3. 請求項１に記載の車両制御装置において、
   前記実行中タスクの子タスクについても実行中タスクと同様に判定後の処理を行うことを特徴とする車両制御装置。
4. 請求項１に記載の車両制御装置において、
   各スロットにおけるタスクの実行時間および終了時の動作を記録することを特徴とする車両制御装置。
5. 請求項１に記載の車両制御装置において、
   継続実行可能であるタスクを起動した際に、前記タスクおよび他タスクが共にアクセスするデータについて前記該タスクのみがアクセスする領域にコピーすることを特徴とする車両制御装置。
6. 請求項５に記載の車両制御装置において、
   前記領域へのコピーは、タスクの実行開始時間より以前に実行することを特徴とする車両制御装置。
7. 請求項１に記載の車両制御装置において、
   該実行中タスクが継続実行可能であるか否かを判定するために用いるスケジューリングテーブルを設計情報から作成することを特徴とする車両制御装置。
8. 請求項７に記載の車両制御装置において、
   前記スケジューリングテーブルにおける継続実行可能であるか否かを、安全性の判定に基づいて設定することを特徴とする車両制御装置。
9. 請求項７に記載の車両制御装置において、
   前記スケジューリングテーブルの作成において、設計情報のタスクの制御周期または実行時間を測定またはネットワークから取得し、スケジューリングテーブルを作成することを特徴とする車両制御装置。
10. 請求項７に記載の車両制御装置を含み、
    前記スケジューリングテーブルの作成において、設計情報のタスクの制御周期または実行時間を測定またはネットワークから取得し、各車両制御装置がスケジューリングテーブルを作成することを特徴とする車両制御システム。

Images