JP6796040B2 - アクセス制御装置 - Google Patents

Description

本発明は、アクセス制御装置に関する。

制御装置では優先度が異なる様々なタスクが実行される。優先度が低いタスクにより優先度が高いタスクの動作を妨げないことが求められる。特許文献１には、実行開始予定時刻が予測可能な第１のタスクと共有資源を占有使用する時間長が既知である第２のタスクとが資源を共有するシステムにおいて、前記第１のタスクの優先度が前記第２のタスクの優先度よりも高いという条件の元でタスクのスケジューリングを行うタスク実行制御装置であって、前記第２のタスクによる共有資源の占有に先立って、前記第１のタスクの次回実行開始予定時刻と前記第２のタスクが前記共有資源を解放すると予想される解放予定時刻とを求める時間算出手段と、前記次回実行開始予定時刻と前記解放予定時刻とを比較して、前記解放予定時刻より前記次回実行開始予定時刻が早ければ、前記第２のタスクに前記共有資源の占有を許さず、一方、前記解放予定時刻より前記次回実行開始予定時刻が早くなければ、前記第２のタスクに前記共有資源の占有を許す資源管理手段、を有するタスク実行制御装置が開示されている。

特開２００３−１３１８９２号公報

特許文献１に記載されている発明では、優先度の低いタスクの共有データへの排他取得による他タスクの動作への影響を防ぐことができない。

本発明の第１の態様によるアクセス制御装置は、実行の優先度により分類され相対的に優先度が低い第１タスクおよび相対的に優先度が高い第２タスクを含むアプリケーション部と、前記第１タスクおよび前記第２タスクを実行する実行部と、実行されるタスクごとに、タスクごとのあらかじめ定められた長さの時間であるスロットを割り当て、前記第１タスクに割り当てた前記スロットにおいて、前記スロットの末尾の第１の所定時間をアクセス監視時間に設定するシステム状態管理部と、前記第１タスクおよび前記第２タスクによりアクセスされる共有データ部と、前記アクセス監視時間における前記第１タスクによる前記共有データ部へのアクセスを禁止するデータアクセス制御部とを備える。

本発明によれば、優先度の低いタスクの共有データへの排他取得による他タスクの動作への影響を防ぐことができる。

車両システム２００１の概要図 車両制御装置２００２の全体ブロック図 タスクの状態遷移図 タスクの実行例を示す図 スケジューリングテーブル５０１の一例を示す図 タスク実行制御部２０６の詳細な構成を示す図 スケジューリング部１０８の動作を示すフローチャート タスクの動作を示すフローチャート データアクセス監視時間を説明する図 システム状態管理部１１１の動作を表すフローチャート タスク状態管理部１０７の動作を表すフローチャート 第１タスク１０１による共有データ部２０５へのアクセスを示す模式図 跨りタスクのアクセス監視時間を説明する図 アクセス監視時間の設定例を示す図 データアクセス制御部１０５の動作を表すフローチャート 一般的な共有データへのアクセス手順を示すフローチャート 第２の実施の形態におけるデータアクセス制御部１０５の動作を表すフローチャート 第３の実施の形態におけるシステム状態管理部１１１の動作を表すフローチャート 第５の実施の形態におけるＣＰＵ２０８の構成を示す図 システム状態テーブル１９０１の一例を示す図 システム状態テーブル１９０１の書き換えを説明する図 第２タスク１０２による共有データ部２０５へのアクセス要求が重複した状況を示す図 第５の実施の形態におけるシステム状態管理部１１１の動作を表すフローチャート 第６の実施の形態における車両制御装置２００２の動作の概要を示す図 第７の実施の形態における車両制御装置２００２のブロック図 タイマフラグ監視部２３０３の動作を説明する図 第８の実施の形態における動作ログ管理部２１３の動作を表すフローチャート 動作ログ１１０１の一例を示す図

―第１の実施の形態―
以下、図１〜図１６を参照して、アクセス制御装置である車両制御装置の第１の実施の形態を説明する。

＜車両システムの構成＞
図１は車両制御装置２００２を搭載する車両システム２００１の概要図である。車両システム２００１は、車両制御装置２００２と、無線通信部２００３と、駆動装置２００４と、認識装置２００５と、出力装置２００６と、入力装置２００７と、通知装置２００８とを備える。車両制御装置２００２は車両を制御する電子制御装置、すなわちＥＣＵ（Electronic Control Unit）である。無線通信部２００３は地図などの情報を取得する。駆動装置２００４は、車両制御装置２００２の動作指令に基づき、車両の運動を制御するために、たとえばエンジン、ホイール、ブレーキ、操舵装置などを駆動する。認識装置２００５は、外界から入力される情報を取得し、外界認識情報を生成するための情報を出力する、たとえばカメラやセンサーなどである。出力装置２００６は、車両の速度や警告などの情報を表示する。入力装置２００７は、運転者が車両操作の指示を入力する、たとえばペダル、ハンドルなどである。通知装置２００８は、車両システム２００１が外界に対して車両の状態等を通知する、たとえばランプ、ＬＥＤ、スピーカなどである。

＜自動運転ＥＣＵの構成＞
図２は車両制御装置２００２の全体ブロック図である。ただし詳細なブロック図は後に改めて示す。車両制御装置２００２は、ソフトウエア２１６とハードウエア２１５とから構成される。ソフトウエア２１６は、後述するＣＰＵ２０８が不図示のＲＯＭに格納されるプログラムをメモリ２０９に展開して実行されることにより実現される。

ハードウエア２１５は、中央演算装置であるＣＰＵ２０８と、不揮発性の記憶装置であるメモリ２０９と、リアルタイム制御のタイミングを管理するタイマ２１０と、ネットワークにアクセスするネットワークアダプタ２１１と、センサーや自動ブレーキ装置などの周辺装置２１２とを備える。ＣＰＵ２０８はコアを１つのみ備える、いわゆるシングルコアＣＰＵである。ただしＣＰＵ２０８が複数のコアを備えるが、後述するアプリケーション部２１４の実行には１つのコアしか使用しない場合も本実施の形態の範囲に含まれる。ソフトウエア２１６は、アプリケーション部２１４と、共有データ部２０５と、タスク実行制御部２０６と、動作ログ管理部２１３と、オペレーティングシステムであるＯＳ２０７とを備える。

アプリケーション部２１４は、センサーデバイス等の周辺装置から外部情報を処理するセンサーフュージョン２０１と、自動運転のための地図情報を処理するマップフュージョン２０２と、追突回避、追従運転、および車線逸脱防止を実現するＡＤＡＳ（Advanced Driving Assistant System）２０３と、自動駐車を実現するオートパーキング２０４などを含んで構成される。ただしここで説明したアプリケーション部２１４の構成は一例であり、少なくとも１つのアプリケーションが含まれていればよい。なおそれぞれのアプリケーションは、複数のタスクから構成され、各タスクには優先度が設定される。

共有データ部２０５は、アプリケーション部２１４に格納されるそれぞれのアプリケーションで使用されるデータを管理する。共有データ部２０５はたとえばメモリ２０９に格納領域を確保し、その格納領域におけるデータの読み書きを管理する。タスク実行制御部２０６は、アプリケーションを構成するそれぞれのタスクの実行を制御する。タスク実行制御部２０６の詳しい構成および動作は後述する。動作ログ管理部２１３は、それぞれのタスクの動作を記録する。タスク実行制御部２０６はスケジューリング部１０８の指定したタイミングに基づきタスク状態管理部１０７により後述する各タスク１０１、１０２に対して、後述する状態遷移に基づき管理を行う。

＜タスク＞
ＯＳ２０７は、アプリケーション部２１４に含まれるアプリケーションを実行するために、アプリケーションを実行単位であるタスクに分けて実行する。ＯＳ２０７は複数のタスクを略同時に実行可能であるが、厳密にはＣＰＵ２０８の計算資源を時分割で利用する。換言するとＯＳ２０７は、時間の経過にしたがって次々とタスクを実行する。それぞれのタスクは、あらかじめ定められた長さの時間である「スロット」内で実行される。

タスクは実行の重要性が平等ではなく、その処理内容に応じて、実行時間を保証しなければならない優先度が高いタスクと、実行時間が多少遅れてもよい優先度が低いタスクがある。ＩＳＯ２６２６２では機能安全の視点からタスクを危険事象の低いものから高いものの順にＱＭ（Quality Management）、ＡＳＩＬ（Automotive Safety Integrity Level）−Ａ、ＡＳＩＬ−Ｂ，ＡＳＩＬ−Ｃ，ＡＳＩＬ−Ｄに分類している。すなわち大きく分類すると、安全性担保という点において実行時間を保証しなければならないタスクはＡＳＩＬ、安全保障に関係がなく実行時間が多少遅れてもよいタスクはＱＭとなる。また本実施の形態では、実行時間の保証の必要性を優先度の高さで言い換える場合があり、たとえば分類がＱＭであるタスクは「優先度が低いタスク」、分類がＡＳＩＬ−Ｄであるタスクは「優先度が高いタスク」とも呼ぶ。

＜タスクの状態遷移＞
図３はタスクの状態遷移図である。タスクの状態は、以下の４つの状態に分類される。第１の状態は実行状態（ＲＵＮＮＩＮＧ）３０１である。実行状態３０１とは、ＣＰＵ２０８が割り当てられタスクが実行している状態である。第２の状態は実行可能状態（ＲＥＡＤＹ）３０２である。実行可能状態３０２とは、タスクを実行する条件は整っているが、当該タスクよりも優先順位が高いタスクが実行状態であるため、実行できない状態である。第３の状態は待機状態（ＷＡＩＴＩＮＧ）３０３である。待機状態３０３とは、何らかの条件が整うまで、実行を中断した状態である。第４の状態は休止状態（ＤＯＲＭＡＮＴ）３０４である。休止状態とは、タスクがいまだ起動されていないか、終了した状態である。

タスクの状態遷移を説明する。新規に生成されたタスクは休止状態３０４で開始され、タスクが起動されると実行可能状態３０２へと遷移する。そのタスクに割り当てられた時刻になるとディスパッチされて実行状態３０１へと遷移し、タスク処理を実行する。タスクの実行が完了、または割り当てられたスロットの時間が終了すると、タスク状態は実行可能状態３０２へ遷移する。タスクがリソース要求を行い、排他制御によりリソースの取得ができない場合には、待機状態３０３に遷移される。その後リソースが解放され、そのタスクがリソースを取得可能となると、タスク状態が待機状態３０３から実行可能状態３０２へと遷移される。タスクが強制終了命令を受けた、またはタスク自身が終了処理を行うと、タスク状態は休止状態３０４へと遷移される。

＜時間駆動スケジューリング＞
図４は、時間駆動スケジューリングにて制御したタスクの実行例を示す図である。時間駆動スケジューリングとは、ＯＳ２０７が決められた実行順により決められた時刻に決められた時間だけタスクを実行することである。図４は横軸が時間経過を表しており、図示ＳＬ１〜ＳＬ９は、それぞれのスロットに付与されたＩＤ（以下、「スロットＩＤ」）である。図４下部の拡大図に示すように、各スロットの開始直後はタスク実行制御部２０６が処理を行い、その後にタスクが実行される。なお図４では最後のスロットＩＤがＳＬ９であるが、さらにＳＬ１０、ＳＬ１１、、、と続いてもよい。それぞれのタスクは、割り当てられたスロットの時間内で実行される。なお図４に示すｔ＿１〜ｔ＿３は、実行されるタスクを識別するＩＤ（以下、「タスクＩＤ」）である。一連の最後のスロットへ到達すると、最初のスロットであるＳＬ１に戻りスケジューリングが継続される。

図５は、時間駆動スケジューリングに用いられるスケジューリングテーブル５０１の一例を示す図である。スケジューリングテーブル５０１は複数のレコードから構成され、各レコードは、スロットＩＤ、開始時刻、終了時刻、タスクＩＤ、および時間エラー判定フラグのフィールドを有する。スロットＩＤのフィールドにはそのレコードのスロットＩＤが格納される。開始時刻および終了時刻のフィールドには、そのレコードのスロットの開始時刻および終了時刻が格納される。ただしこの時刻はＳＬ１の開始時刻をゼロとしたものである。タスクＩＤのフィールドには、そのレコードにおいて実行されるタスクのタスクＩＤが格納される。時間エラー判定フラグのフィールドには、後述するスケジューリング部１０８が参照するフラグが格納される。時間エラー判定については後に詳述する。

スケジューリングテーブル５０１は各タスクの実行周期、想定される最長の実行時間、安全要求レベル等の情報に基づいてあらかじめ作成される。スケジューリングテーブル５０１の１サイクルの長さは全タスクの実行周期を満たす長さにて作成される。サイクルの終端へ到達した場合、ＳＬ１に戻りスケジューリングを継続する。たとえば図５に示す例では、最後のスロットＩＤがＳＬ１２であり、終了時間が「５．１ｍｓ」なので、１サイクルの長さは５．１ｍｓである。そしてＳＬ１２の次にＳＬ１が実行される。

＜車両制御装置の構成＞
図６は、タスク実行制御部２０６の詳細な構成を示す図である。ただし図６では、アプリケーション部２１４は、安全要求レベルの低い複数の第１タスク１０１と安全要求レベルの高い複数の第２タスク１０２とを含むとして説明する。この第１タスク１０１および第２タスク１０２は、アプリケーション部２１４に含まれるいずれかのアプリケーションを構成するタスクである。ただし以下では、第１タスク１０１と第２タスク１０２とをまとめて、単に「タスク」とも呼ぶ。

タスク実行制御部２０６は、データアクセス制御部１０５と、システム状態判定部１０６と、タスク状態管理部１０７と、スケジューリング部１０８とを備える。データアクセス制御部１０５は、後述するアクセスフラグを利用して、タスクからの共有データ部２０５へのアクセス要求を制御する。システム状態判定部１０６は、システム状態を管理する後述するシステム状態管理部１１１を参照してシステムの状態を判定する。タスク状態管理部１０７は、タスクの状態を管理する。スケジューリング部１０８は、データアクセス制御部１０５、システム状態判定部１０６、およびタスク状態管理部１０７と協調してタスクのスケジュール管理を行う。

ハードウエア２１５は、アクセス時間監視部１０９と、スロット時間監視部１１０と、システム状態管理部１１１とを備える。アクセス時間監視部１０９はタイマ２１０により実現され、設定されたアクセス監視時間への到達を監視する。アクセス監視時間については後述する。スロット時間監視部１１０はタイマ２１０により実現され、設定されたそれぞれのスロット時間への到達を監視する。システム状態管理部１１１は不図示のハードウエア回路により実現され、アクセス時間監視部１０９およびスロット時間監視部１１０と協調してシステム状態を管理する。

なおここでは、アクセス時間監視部１０９、スロット時間監視部１１０、およびシステム状態管理部１１１は、ハードウエアから構成されると説明したが、ソフトウエアを含むことを排除するものではない。ただしソフトウエアを含む場合はソフトウエア２１６とはリソースが独立しており、アクセス時間監視部１０９、スロット時間監視部１１０、およびシステム状態管理部１１１の動作タイミングがソフトウエア２１６の動作タイミングに影響を与えないこととする。

＜スケジューリング部の動作＞
図７は、スケジューリング部１０８の動作を示すフローチャートである。各スロットの開始時刻になると、タイマ２１０からの動作指令によりスケジューリング部１０８が動作を開始する。以下に説明する各ステップの実行主体はＣＰＵ２０８である。

スケジューリング部１０８はまず前のスロットのタスクが実行完了しているか否かの判定を行う（Ｓ１０１）。前のスロットのタスクが実行完了していると判断する場合は（Ｓ１０１：ｙｅｓ）、スケジューリング部１０８は、スケジューリングテーブル５０１における現在のスロットの終了時刻にスケジューリング部１０８が動作開始するようにタイマ２１０をセットする（Ｓ１０２）。そしてスケジューリング部１０８は現在のスロットに割り当てられたタスクを実行状態へ遷移させる（Ｓ１０３）。スロットにタスクが割り当てられていない場合には、そのスロットではタスクを動作させない。このようにして決められた時間でのタスク実行処理を行うことで、各タスクの実行時間を確保する。実行状態へ遷移されたタスクの処理については後に図８を参照して説明する。

前のスロットのタスクが実行完了していないと判断する場合は（Ｓ１０１：ｎｏ）、スケジューリング部１０８はスケジューリングテーブル５０１におけるそのスロットの時間エラー判定フラグを参照し、”しない”の場合（Ｓ１０４：Ｎｏ）には前スロットのタスクを待機状態３０３へ遷移させる（Ｓ１０５）。なお待機状態３０３へ遷移させる対象となるタスク、換言するとスケジューリングテーブル５０１において時間エラー判定が”する”であるタスクを「跨りタスク」と呼ぶ。跨りタスクは１つのスロット内で処理が完了しない長い時間を要するタスクであり、複数のスロットにわたって動作する。時間エラー判定フラグが”する”の場合（Ｓ１０４：ｙｅｓ）、前のスロットのエラーフラグを立て（Ｓ１０６）、前のスロットのタスクを休止状態３０４へ遷移させる（Ｓ１０７）。強制終了には時間を要するため、Ｓ１０７にてタスクを一時的に待機状態３０３へ遷移させ、空いているスロットで休止状態３０４へ遷移させてもよい。Ｓ１０５またはＳ１０７の実行が完了すると、前述のＳ１０２に進む。

＜タスクの動作＞
図８は、実行状態にされたそれぞれのタスクの動作を示すフローチャートである。まずタスクは、共有データ部２０５へのアクセスを含むタスク処理を実行し（Ｓ３０１）、その実行が完了すると実行完了フラグを立ち上げる（Ｓ３０２）ことで実行完了したことを示すスケジューリング部１０８に示す。スケジューリング部１０８は直前のスロットにおいて実行されたタスクの実行完了フラグを参照し、実行完了フラグが立ちあげられていればそのタスクを実行可能状態３０２へと遷移する。タスクは、次に実行を開始する際に実行完了フラグを立ち下げる（Ｓ３０３）。ただしスケジューリング部１０８が実行完了フラグを立ち下げてもよい。

＜タスクのデータアクセス監視時間＞
図９は、タスクのデータアクセス監視時間を説明する図である。図９では、第１タスク１０１および第２タスク１０２を実行する状況を示している。そして第１タスク１０１は、割り当てられたスロット時間Ｔ１ａからＴ１ｄの間で動作する。第１タスク１０１に割り当てられたスロットでは、スロットの最後であるＴ１ｂからＴ１ｄにデータアクセスを監視するアクセス監視時間を設ける。このアクセス監視時間の長さはデータアクセス時間、すなわちタスクによる共有データ部２０５へのアクセスに要する時間である、たとえばＴ１ｂからＴ１ｃよりも長い時間である。このアクセス監視時間の長さは、タスクによらず一定である。なお第２タスク１０２は安全要求レベルが高いので、第２タスク１０２に割り当てられたスロットにはアクセス監視時間は設定されない。

本実施の形態では、アクセス監視時間である時間を「アクセス監視状態」、アクセス監視時間ではない時間を「アクセス非監視状態」と呼ぶ。そしてアクセス監視状態またはアクセス非監視状態をとる状態を「システム状態」とよぶ。すなわち図９の下部に示すように、システム状態は平時はアクセス非監視状態であり、第１タスク１０１が属するスロットの終了所定時間前から、第１タスク１０１が属するスロットの終了時間までがアクセス監視状態となる。

＜システム状態管理部の動作＞
図１０は、システム状態管理部１１１の動作を表すフローチャートである。以下では図９も参照してシステム状態管理部１１１の動作を説明する。以下に説明する各ステップの実行主体はＣＰＵ２０８である。

システム状態管理部１１１は、各スロットの開始時、たとえば図９の時刻Ｔ１ａにそのスロットで実行されるタスクが第１タスク１０１であるか否かを判断し（Ｓ４００Ａ）、実行されるタスクが第１タスク１０１であると判断する場合はＳ４０１に進む。実行されるタスクが第１タスク１０１ではない、すなわち第２タスク１０２が実行されると判断する場合はスロットの終了時刻をスロット時間監視部１１０に設定して（Ｓ４００Ｂ）、タイマ２１０による計数を開始させてＳ４０４に進む。Ｓ４０１ではシステム状態管理部１１１は、アクセス監視時間の開始時刻をスロット時間監視部１１０に設定し、かつスロットの終了時刻をスロット時間監視部１１０に設定して計数を開始させる。

システム状態管理部１１１はアクセス時間監視部１０９のレジスタ状態を監視し、そのレジスタ状態から設定したアクセス監視時間に到達したか否かを判断し（Ｓ４０２）、アクセス監視時間に到達していないと判断する場合はＳ４０２に留まる。システム状態管理部１１１は、アクセス監視時間に到達したと判断する場合は、システム状態をアクセス非監視状態からアクセス監視状態へ遷移させる（Ｓ４０３）。

システム状態管理部１１１はスロット時間監視部１１０のレジスタ状態を監視し、そのレジスタ状態から設定したスロットの終了時刻に到達したか否かを判断し（Ｓ４０４）、スロットの終了時刻に到達していないと判断する場合はＳ４０４に留まる。システム状態管理部１１１は、スロットの終了時刻に到達したと判断する場合は、システム状態をアクセス監視状態からアクセス非監視状態へ遷移させる（Ｓ４０５）。続くＳ４０６ではシステム状態管理部１１１はシステムを終了させるか否か、たとえば車両制御装置２００２を搭載する車両のイグニションキースイッチがオフにされたか否かを判断する。システム状態管理部１１１は、システムを終了させないと判断する場合はＳ４００Ａに戻り、システムを終了させると判断する場合は図１０に示す動作を終了する。

＜タスク状態管理部の動作＞
図１１は、タスク状態管理部１０７の動作を表すフローチャートである。タスク状態管理部１０７は、呼び出される際にどの状態へ遷移させるかも併せて指定される。すなわちタスク状態管理部１０７は、待機状態、休止状態、実行可能状態のいずれかの指定とともに呼び出される。

タスク状態管理部１０７は待機状態への遷移を指定されている場合は（Ｓ５０１：ＹＥＳ）、タスクを待機状態へ遷移させる（Ｓ５０２）。指定された状態が待機状態ではないと判断する場合は（Ｓ５０１：ＮＯ）、休止状態への遷移を指定されているか否かを判断する（Ｓ５０３）。タスク状態管理部１０７は、休止状態への遷移を指定されていると判断する場合はタスクを休止状態へ遷移させ（Ｓ５０４）、休止状態への遷移を指定されていないと判断する場合はタスクを実行可能状態へ遷移させる（Ｓ５０５）。

＜共有データ部へのアクセス＞
図１２は、第１タスク１０１による共有データ部２０５へのアクセスを示す模式図である。データアクセス制御部１０５は、第１タスク１０１が共有データ部２０５へアクセスを試みると、システム状態判定部１０６を介してシステム状態管理部１１１が管理するシステム状態を取得する。データアクセス制御部１０５は、システム状態がアクセス非監視状態であると判断する場合は第１タスク１０１による共有データ部２０５へのアクセスを許可する。データアクセス制御部１０５は、システム状態がアクセス監視状態であると判断する場合は第１タスク１０１による共有データ部２０５へのアクセスを拒否し、さらにタスク状態管理部１０７を用いて第１タスク１０１を休止状態３０４へと遷移させる。ただしデータアクセス制御部１０５は、システム状態がアクセス監視状態である場合に、第１タスク１０１のタスク状態を休止状態３０４へと遷移せず、待機状態３０３へ遷移もしくは無限ループを実行させ、時間エラー判定させてもよい。

＜跨りタスクのデータアクセス制御＞
図１３は、跨りタスクのアクセス監視時間を説明する図である。図１３に示す例では第１タスク１０１および第２タスク１０２を実行する状況を示している。そして第１タスク１０１は、複数のスロットにまたがって動作し、具体的には時刻Ｔ２ａ〜Ｔ２ｄまでのスロット、および時刻Ｔ２ｅ〜Ｔ２ｈまでのスロットで動作する。すなわち本例における第１タスク１０１は跨りタスクである。跨りタスクが割り当てられたスロットにおいても、安全要求レベルの低いタスクに割り当てられたスロット全てにおいて、スロットの最後にデータアクセス監視用のアクセス監視時間が設けられる。図１３に示す例では、時刻Ｔ２ｂ〜Ｔ２ｄ、および時刻Ｔ２ｆ〜Ｔ２ｈがアクセス監視時間である。また図１３の下段に示すように、アクセス監視時間にあわせてシステム状態がアクセス監視状態に設定される。

第１タスク１０１が共有データ部２０５へアクセスを試みると、システム状態がアクセス監視状態である場合にはデータアクセス制御部１０５は次の処理を行う。すなわちデータアクセス制御部１０５は、第１タスク１０１による共有データ部２０５へのアクセスを禁止し、タスク状態管理部１０７により第１タスク１０１のタスク状態を待機状態へと遷移させる。ただしシステム状態がアクセス監視状態である場合に、第１タスク１０１のタスク状態を待機状態３０３へと遷移させず、無限ループを実行させ、時間エラー判定にて待機状態３０３へ遷移させてもよい。第１タスク１０１による共有データ部２０５へのアクセスは、第１タスク１０１の続きのスロットのアクセス監視時間以外、すなわち時刻Ｔ２ｅ〜Ｔ２ｆにて開始される。第１タスク１０１が共有データ部２０５へアクセスを試みた際に、システム状態がアクセス非監視状態である場合には第１タスク１０１による共有データ部２０５へのアクセスを実施する。

＜割り当てスロットに基づいたアクセス監視時間配置＞
図１４は、アクセス監視時間の設定例を示す図である。以下では、アクセス監視時間は安全要求レベルの高いタスクの起動タイミングに左右されず、安全要求レベルの低いタスクのスロット時間によって決定されることを説明する。

図１４に示す例では、第３タスクは第１タスク１０１と同様に安全要求レベルが低い。第１タスク１０１は時刻Ｔ３ａ〜Ｔ３ｄ、および時刻Ｔ３ｊ〜Ｔ３ｌにて動作する。第３タスクは時刻Ｔ３ｆ〜Ｔ３ｈに動作する。アクセス監視時間は第１タスク１０１および第３タスクにそれぞれ割り当てられたスロットの末尾である時刻Ｔ３ｂ〜Ｔ３ｄ，時刻Ｔ３ｆ〜Ｔ３ｈ、および時刻Ｔ３ｊ〜Ｔ３ｌに配置される。このように、安全要求レベルの低いタスクのスロット時間に基づいてアクセス監視時間を配置することにより、共有データ部２０５へのアクセスの有無やアクセス対象の詳細に関する情報が無い場合においても、排他中のタスク切り替えによる影響を防ぐことが可能となる。

＜データアクセス制御部１０５の動作＞
図１５は、データアクセス制御部１０５の動作を表すフローチャートである。以下に説明する各ステップの実行主体はＣＰＵ２０８である。

データアクセス制御部１０５は、タスクから共有データ部２０５へのアクセス要求を受け取ると、システム状態判定部１０６にてシステム状態を確認する（Ｓ２０１）。データアクセス制御部１０５は、システム状態がアクセス非監視状態であると判断すると（Ｓ２０１：Ｎｏ）、共有データ部２０５へのアクセス状況を示すアクセスフラグを「アクセス中」へ遷移させ（Ｓ２０２）、共有データ部２０５へのアクセスを実行する（Ｓ２０３）。データアクセス制御部１０５は、タスクによる共有データ部２０５へのアクセスが完了すると、アクセスフラグを「非アクセス中」へと遷移させる（Ｓ２０４）。

データアクセス制御部１０５は、システム状態がアクセス監視状態の場合には（Ｓ２０１：ｙｅｓ）、スケジューリングテーブル５０１にて現在のスロットの時間エラー判定フラグの内容を判定する（Ｓ２０５）。時間エラー判定フラグが“しない”の場合（Ｓ２０５：Ｎｏ）は、データアクセス制御部１０５は、タスク状態管理部１０７にタスクの状態を待機状態３０３へ遷移させる（Ｓ２０６）。そしてデータアクセス制御部１０５は、続きのスロットにてタスク状態が実行状態３０１へ遷移した後にデータアクセスを行う（Ｓ２０２，Ｓ２０３，Ｓ２０４）。時間エラー判定フラグが“する”の場合（Ｓ２０５：Ｙｅｓ）はデータアクセス制御部１０５は、現在のスロットのマージン内エラーフラグをＯＮに遷移させ（Ｓ２０７）、実行状態３０１のタスクを強制終了させて休止状態３０４にする（Ｓ２０８）。ただし強制終了には時間を要するため、Ｓ２０８にてタスクを一時的に待機状態３０３へ遷移させ、空いているスロットで休止状態３０４へ遷移させてもよい。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）車両制御装置２００２は、実行の優先度により分類され相対的に優先度が低い第１タスク１０１および相対的に優先度が高い第２タスク１０２を含むアプリケーション部２１４と、実行されるタスクごとに、タスクごとのあらかじめ定められた長さの時間であるスロットを割り当て、第１タスク１０１に割り当てたスロットにおいて、スロットの末尾の第１の所定時間をアクセス監視時間に設定するシステム状態管理部１１１と、第１タスク１０１および第２タスク１０２によりアクセスされる共有データ部２０５と、アクセス監視時間における第１タスク１０１による共有データ部２０５へのアクセスを禁止するデータアクセス制御部１０５とを備える。

車両制御装置２００２は、いずれのタスクが共有データ部２０５へアクセスするか否か、さらには共有データ部２０５に含まれるいずれのデータにアクセスするのかなどの情報を有していない。しかし第１タスク１０１が割り当てられたスロットの末尾にアクセス監視時間を設けたので、優先度が低い第１タスク１０１が共有データ部２０５へアクセスしたことを原因として、他のタスクによる共有データ部２０５へのアクセスが妨げられる事態を防止することができる。図１６を参照して想定される従来の問題点を説明する。

図１６は、一般的な共有データへのアクセス手順を示すフローチャートである。一般的な共有データへのアクセスとして、共有データへアクセスするタスクは排他取得、換言すると共有データへのアクセス権を取得する（Ｓ６０１）。次にデータ処理を行い（Ｓ６０２）、最後に排他を開放、換言すると共有データへのアクセス権を開放して（Ｓ６０３）一連の処理を終了する。もしも図１６に示す処理を行っているタスクのスロットが、データ処理の途中で終了すると、排他開放が行われないまま他のタスクに処理が移行する。その場合は、そのタスクの処理が再開されない限り排他開放が行われず、それまでは他のタスクは排他取得ができず、共有データへのアクセスが不可能となる。

従来はこのような問題を有していたが、車両制御装置２００２は第１タスク１０１に割り当てられたスロットの末尾の所定時間をアクセス監視時間とし、アクセス監視時間における共有データ部２０５へのアクセスを禁止したので、上述した問題を回避できる。すなわち車両制御装置２００２では、第１タスク１０１がアクセス権を保持したままスロットの終期を迎えることがないので、第１タスク１０１の排他取得による他のタスクへの共有データ部２０５へのアクセスに関する悪影響を防止できる。さらにこの利点は、本実施の形態のように、車両制御装置２００２がタスクごとの共有データ部２０５へのアクセスの有無を有していない場合にも得られる。すなわち車両制御装置２００２は、排他制御に用いる共有データ部２０５のアクセス情報の有無にかかわらず、安全要求レベルの低い第１タスク１０１の排他取得による他タスクの動作への影響を防ぐことができる。

（２）アクセス監視時間は、第１タスク１０１が共有データへのアクセスに要する時間よりも長い。そのため第１タスク１０１が共有データ部２０５へアクセスするための時間が十分にあるアクセス監視時間の開始以前は第１タスク１０１による共有データ部２０５へアクセスを認める。そしてアクセス監視時間の直前に第１タスク１０１が共有データ部２０５へのアクセスを開始した場合にも、アクセス監視時間は第１タスク１０１が共有データへのアクセスに要する時間よりも長いので、そのスロット内で排他開放までを完了させて他タスクの動作への影響を防ぐことができる。

（３）データアクセス制御部１０５は、アクセス監視時間に共有データ部２０５へのアクセスを試みた第１タスク１０１を終了状態に遷移させる。そのため次の処理である共有データ部２０５へアクセスができない第１タスク１０１の動作を終了させ、ＣＰＵ２０８のリソースを節約することができる。

（４）データアクセス制御部１０５は、複数のスロットに跨って実行される第１タスク１０１が、最終スロット以外でアクセス監視時間に共有データ部２０５へのアクセスを試みると、第１タスク１０１を次のスロットの開始時刻まで待機させる。そのため複数のスロットに跨って実行される第１タスク１０１に、次に実行するスロットにおいて共有データ部２０５へアクセスさせることができる。

（５）優先度は、タスクに要求される機能安全のレベルに基づいて決定される。具体的には、要求される機能安全レベルが高い、たとえばＡＳＩＬ−Ｄのタスクは優先度を高く設定し要求される機能安全レベルが低い、たとえばＱＭのタスクは優先度を、低く設定する。これにより、機能安全レベルが高いタスクは優先的に実行される。

（変形例１）
第１の実施の形態では、優先度は２通りしか設定されなかった。しかし３通り以上の優先度が設定されてもよい。その場合は最も高い優先度とそれ以外の優先度に分類して処理を行う。たとえば１〜５の優先度を設け、数字が大きいほど優先されるべき場合に、優先度１〜４のタスクは、第１の実施の形態における優先度が低いタスク、すなわち第１タスク１０１に相当する。そして優先度５のタスクのみが第１の実施の形態における優先度が高いタスク、すなわち第２タスク１０２に相当する。

（変形例２）
第１の実施の形態では、タスクに要求される機能安全レベルに基づいて優先度が決定された。しかし他の指標によりタスクの優先度を決定してもよい。たとえば、他のタスクへの影響の大きさやユーザの嗜好、または機能安全レベルとそれらの組み合わせによりタスクの優先度を決定してもよい。

―第２の実施の形態―
図１７を参照して、アクセス制御装置である車両制御装置の第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、スロット内に共有データ部２０５へのアクセスが完了しない場合を考慮する点で、第１の実施の形態と異なる。すなわち第２の実施の形態では以下のようなタスクを想定する。すなわち、あるタスクがアクセス監視時間が始まる前に共有データ部２０５へのアクセスを開始し、アクセス監視時間が開始してもそのアクセスは終了しなかった。さらにそのタスクは、アクセス監視時間が終了しても、換言するとそのスロットの終了時刻に到達しても共有データ部２０５へのアクセスが終了しなかった。

本実施の形態では、データアクセス制御部１０５のアクセスフラグを活用する。アクセスフラグはたとえばメモリ２０９に格納される情報である。第１の実施の形態において説明したように、データアクセス制御部１０５は、タスクの要求に応じて共有データ部２０５へのアクセスを許可する場合に、アクセスフラグを「アクセス中」に遷移させ、データアクセス完了時にアクセスフラグを「非アクセス中」に遷移させる。データアクセス制御部１０５は、アクセス監視時間の終了時にアクセスフラグが「アクセス中」であることを検出すると、車両制御装置２００２を再起動することにより、全ての排他制御をリセットさせる。

これによりアクセス監視時間を超えてデータアクセスを行った場合の排他による他タスクへの影響を最小限に抑え、早期の回復が可能となる。またアクセス監視時間開始時にタスク状態が実行状態かつアクセスフラグが「アクセス中」である場合は、異常発生と判断しタスク状態管理部１０７によりタスクを待機状態へ遷移させてもよい。また、再起動する対象は車両制御装置２００２に限らず、実装されるその他のシステム全体で再起動させてもよい。

＜データアクセス制御部１０５の動作＞
図１７は、第２の実施の形態におけるデータアクセス制御部１０５の動作を表すフローチャートである。Ｓ２０３までの処理は第１の実施の形態と同様なので説明を省略する。Ｓ２０３において共有データ部２０５へのアクセスを開始させると、データアクセス制御部１０５はタスクによる共有データ部２０５へのアクセスが終了したか否かを判断し、アクセスが終了したと判断する場合は（Ｓ２１１：ＹＥＳ）、Ｓ２０４に進む。データアクセス制御部１０５はアクセスが終了していないと判断する場合は（Ｓ２１１：Ｎｏ）、アクセス監視時間が終了したか否かを判断し、アクセス監視時間が終了したと判断する場合（Ｓ２１２：Ｙｅｓ）は車両制御装置２００２を再起動する（Ｓ２１３）。データアクセス制御部１０５は、アクセス監視時間が終了していないと判断する場合は（Ｓ２１２：Ｎｏ）、Ｓ２１１に戻る。

上述した第２の実施の形態によれば、次の作用効果が得られる。
（６）車両制御装置２００２は、タスクによる共有データ部２０５へのアクセス状態を示すアクセスフラグと、タスクが共有データ部２０５へのアクセスを開始するとアクセスフラグをオンにし、タスクが共有データ部２０５へのアクセスを終了するとアクセスフラグをオフにするデータアクセス制御部１０５とを備える。データアクセス制御部１０５は、アクセス監視時間の終了時にアクセスフラグがオンであると車両制御装置２００２を再起動させる。そのためアクセス監視時間を超えてデータアクセスを行った場合の排他による他タスクへの影響を最小限に抑え、早期の回復が可能となる。

―第３の実施の形態―
図１８を参照して、アクセス制御装置である車両制御装置の第３の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、第２タスク１０２に割り当てられたスロットにアクセス監視時間を設ける場合がある点で、第１の実施の形態と異なる。

本実施の形態では、安全要求レベルの高い第２タスク１０２により他タスクへ影響を与えることが許されない場合の車両制御装置２００２の動作を説明する。すなわち本実施の形態では、第２タスク１０２に割り当てられたスロットの次のスロットが第２タスク１０２に割り当てられている場合にも、先の第２タスク１０２に割り当てられたスロット最終部にデータアクセス監視用のアクセス監視時間を設ける。これにより、安全要求レベルの高い第２タスク１０２が誤動作を起こした場合に他の安全要求レベルの高い第２タスク１０２への影響を防ぐことが可能となる。

＜システム状態管理部１１１の動作＞
図１８は、第３の実施の形態におけるシステム状態管理部１１１の動作を表すフローチャートである。第１の実施の形態と同様の処理には同一のステップ番号を付して説明を省略する。システム状態管理部１１１は、Ｓ４００Ａにおいて否定判定をすると、現在のスロットと次のスロットの両方に第２タスク１０２が割り当てられているか否かを判断する（Ｓ４００Ｃ）。本ステップを肯定判定する場合はシステム状態管理部１１１はＳ４０１に進み、否定判定する場合はＳ４００Ｂにすすむ。以下の動作は第１の実施の形態と同様なので説明を省略する。

上述した第３の実施の形態によれば、アクセス監視時間の配置対象を変更することにより、安全要求レベルの高いタスクによる他タスクへの影響を防止することが可能となる。

―第４の実施の形態―
アクセス制御装置である車両制御装置の第４の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、スケジューリングテーブル５０１を自動生成する点で、第１の実施の形態と異なる。

不図示の開発ツールは、スケジューリングテーブル５０１を自動生成する。開発ツールは、各タスクの周期、最悪実行時間、安全要求レベル等の設計情報からスケジューリングテーブル５０１を自動生成する。自動生成時には安全要求レベルの情報をもとに、各スロットの最終部にデータアクセス監視用のアクセス監視時間を設けるかを決定する。アクセス監視時間を設ける場合には、アクセス監視時間を含めたスロット時間の配置が行われる。

上述した第４の実施の形態によればスケジューリングテーブル５０１が自動生成されるので、アクセス監視時間の必要有無を考えずにアプリケーション設計が可能となる。

―第５の実施の形態―
図１９〜図２３を参照して、アクセス制御装置である車両制御装置の第５の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、車両制御装置２００２のＣＰＵ２０８が複数のコアを備える点で、第１の実施の形態と異なる。

本実施の形態におけるＣＰＵ２０８は、図１９に示すように第１コア１７０１、第２コア１７０２、および第３コア１７０３を備える、いわゆるマルチコアＣＰＵである。ただしＣＰＵ２０８が備えるコアの数は２以上であればよく、その個数は限定されない。いずれのコアも、安全要求レベルの低い第１タスク１０１、および安全要求レベルの高い第２タスク１０２を実行し、それぞれのタスクが共有データ部２０５にアクセスする。また本実施の形態では、システム状態を全体監視状態、個別監視状態、非監視状態の３つに分類する。

図２０は、システム状態テーブル１９０１の一例を示す図である。システム状態テーブル１９０１は各コアが個別監視状態か非監視状態かの情報及び、“全コア用アクセス監視カウンタ”を保持する。全コア用アクセス監視カウンタは０からコア数の間を増減する。そして全コア用アクセス監視カウンタの値が１以上である状態を「全体監視状態」と呼ぶ。すなわち第１の実施の形態におけるアクセス監視状態およびアクセス非監視状態は、本実施の形態における個別監視状態および非監視状態に対応し、各コアにおける共有データ部２０５へのアクセス可否を示す。全体監視状態は、車両制御装置２００２の全体、すなわちすべてのコアに影響し、全体監視状態ではすべてのコアにおける第１タスク１０１による共有データ部２０５への新規のアクセスが禁止される。

本実施の形態では、システム状態管理部１１１は、第１タスク１０１だけでなく第２タスク１０２にも監視時間を設定する。ただし第２タスク１０２の監視時間は、アクセス時間の２倍以上となるように設定される。

図２１を参照してシステム状態テーブル１９０１がどのように書き換えられるかを説明する。第１タスク１０１用スロットにおけるアクセス監視時間の開始時（Ｔ４ｂ）において、システム状態管理部１１１は第１コアのシステム状態を個別監視状態へと遷移させる。第１タスク１０１用スロットにおけるアクセス監視時間の終了時（Ｔ４ｃ）において、システム状態管理部１１１は第１コアのシステム状態を非監視状態へと遷移させる。前述のとおり、個別監視状態のコアでは、第１タスク１０１における共有データ部２０５への新規のアクセスが禁止される。第２タスク１０２用スロットにおけるアクセス監視時間の開始時（Ｔ４ｅ）において、システム状態管理部１１１によりそのコアのシステム状態を個別監視状態へと遷移させるとともに、全コア用アクセス監視カウンタを１インクリメントさせて全体監視状態に遷移させる。第２タスク１０２用スロットにおけるアクセス監視時間の終了時（Ｔ４ｈ）において、システム状態管理部１１１によりそのコアのシステム状態を非監視状態へと遷移させ、全コア用アクセス監視カウンタを１デクリメントさせる。このデクリメントにより全コア用アクセス監視カウンタの値がゼロになると、全体監視状態は解除される。

前述のとおり、全コア用アクセス監視カウンタが１以上の場合は、全体監視状態となるのですべてのコアにおける第１タスク１０１による共有データ部２０５への新規のデータアクセスが禁止される。複数のコア１７０１、１７０２、１７０３の第２タスク１０２により共有データ部２０５へのデータアクセス要求がある場合は、データアクセス制御部１０５は、実行しているスロットの終了時間までが最も短い第２タスク１０２によるデータアクセスを優先する。ただし全体監視状態でない場合、すなわちいずれのコアにおいてもスロットの終了までに共有データ部２０５へアクセスに十分な時間がある場合は、データアクセス制御部１０５は、要求を受けた順番に第２タスク１０２に共有データ部２０５へアクセスさせてもよい。これにより、アクセス監視時間より前に他コアの第１タスク１０１がアクセスした際にも、第１タスク１０１によるデータアクセス完了後に第２タスク１０２によるデータアクセスを実行する時間を確保可能となる。そのため、メニーコア環境における第１タスク１０１のデータアクセスによる第２コア１７０２への影響を防ぐことが可能となる。図２２を参照して具体的に説明する。

図２２は、第２タスク１０２による共有データ部２０５へのアクセス要求が重複した状況を示す図である。図２２では図示左から右に向かって時間が経過しており、上から第１コア１７０１、第２コア１７０２、第３コア１７０３の状態を示す。ただし図２２は模式図であり、時間軸の長さは均一ではない。たとえば図２２では第３コア１７０３のアクセス時間が他に比べて非常に長く描画されているが、これは作図上の問題によるものであり、全てのアクセス時間は略同一である。第１コア１７０１と第２コア１７０２は第２タスク１０２を実行し、第３コア１７０３は第１タスク１０１を実行している。第１コア１７０１におけるスロットの終了時刻はｔ６であり、第２タスク１０２の監視時間から算出して時刻ｔ３から全体監視時間となる。第２コア１７０２におけるスロットの終了時刻はｔ７であり、第２タスク１０２の監視時間から算出して時刻ｔ５から全体監視時間となる。時刻ｔ０において、第３コア１７０３において第１タスク１０１が共有データ部２０５へアクセスを行っている。このアクセスは時刻ｔ４まで継続する。

時刻ｔ１において下向きの三角形で示すように、第２コア１７０２では第２タスク１０２による共有データ部２０５へアクセス要求が発生した。続く時刻ｔ２において下向きの三角形で示すように、第１コア１７０３では第２タスク１０２による共有データ部２０５へアクセス要求が発生した。そして時刻ｔ３において第１コア１７０３では全体監視時間が開始された。第３コア１７０３の第１タスク１０１による共有データ部２０５へアクセスが完了する時刻ｔ４において、データアクセス制御部１０５は第２コア１７０２よりも第１コア１７０１の方がスロットの終了までの時間が短いと判断し、第１コア１７０１の第２タスク１０２に共有データ部２０５へアクセスさせる。その後、時刻ｔ５に第１コア１７０１による共有データ部２０５へアクセスが終了すると、データアクセス制御部１０５は第２コア１７０２による共有データ部２０５へアクセスを開始させる。

（システム状態管理部１１１の動作）
図２３は、第５の実施の形態におけるシステム状態管理部１１１の動作を表すフローチャートである。図２３では第１の実施の形態と同様の動作には同一のステップ番号を付して説明を省略する。システム状態管理部１１１は、各スロットの開始時にそのスロットで実行されるタスクが第１タスク１０１であるか否かを判断し（Ｓ４００Ａ）、実行されるタスクが第１タスク１０１であると判断する場合は（Ｓ４００Ａ：Ｙｅｓ）、Ｓ４０１Ａに進む。実行されるタスクが第１タスク１０１ではない、すなわち第２タスク１０２が実行されると判断する場合は（Ｓ４００Ａ：Ｎｏ）、Ｓ４００Ｂにおいて次の処理を行う。

すなわちシステム状態管理部１１１は、スロットの終了時刻をスロット時間監視部１１０に設定するとともに、アクセス監視時間の開始時刻を第２タスク１０２用の監視時間に基づき算出してアクセス時間監視部１０９に設定して計数を開始させる（Ｓ４００Ｂ）。そしてシステム状態管理部１１１は監視時間であると判断すると（Ｓ４０２Ｂ：Ｙｅｓ）、そのコアのシステム監視状態を個別監視状態へ遷移させるとともに、全コア用アクセス監視カウンタをインクリメントし、システム状態を全体監視状態に遷移させ（Ｓ４０３Ｂ）、Ｓ４０４へ進む。ただしすでにシステム状態が全体監視状態である場合は全コア用アクセス監視カウンタのインクリメントのみを行う。

Ｓ４０１Ａではシステム状態管理部１１１は、アクセス監視時間の開始時刻を第１タスク１０１用の監視時間に基づき算出してその時刻をアクセス時間監視部１０９に設定し、かつスロットの終了時刻をスロット時間監視部１１０に設定して計数を開始させてＳ４０２に進む。Ｓ４０２ではシステム状態管理部１１１は監視時間であると判断すると（Ｓ４０２Ａ：Ｙｅｓ）、そのコアのシステム監視状態を個別監視状態へ遷移させてＳ４０４に進む（Ｓ４０３Ａ）。Ｓ４０４ではスロット時間であると判断すると、そのコアのシステム監視状態を非監視状態に遷移させるとともに、全コア用アクセス監視カウンタをデクリメントする（Ｓ４０５Ａ）。このデクリメントにより全コア用アクセス監視カウンタの値がゼロになった場合は、全体監視状態が解除される。

上述した第５の実施の形態によれば、次の作用効果が得られる。
（７）タスクを実行するＣＰＵ２０８のコアを複数備え、システム状態管理部１１１は、第２タスク１０２に割り当てたスロットにおいて、スロットの末尾の第２の所定時間を全体監視時間に設定し、全体監視時間の長さは個別監視時間以上の長さである。データアクセス制御部１０５は、ＣＰＵ２０８のコアごとにアクセス監視時間であるか否かを判断し、全体監視時間における全てのコアで実行される第１タスク１０１による共有データ部２０５へのアクセスを禁止する。そのため、ＣＰＵ２０８が複数のコアを備えて複数のタスクを並列して実行可能な場合に、コアごとにアクセス監視時間を設けることで、安全要求レベルの低いタスクによる安全要求レベルの高いタスクへの影響を防止することができる。また第２タスク１０２のスロット末尾において全体監視時間を設け全てのコアにおける第１タスク１０１の共有データ部２０５へのアクセスを制限することで、いずれのコアで実行されている第２タスク１０２も共有データ部２０５へのアクセスを優先させ、実行の遅延を防止することができる。

（８）データアクセス制御部１０５は、複数のコアにおいて第２タスク１０２が共有データ部２０５へのアクセスを試みると、実行しているスロットの終期までの時間が全体監視時間未満である第２タスク１０２による共有データ部２０５へのアクセスを優先させる。そのため第２タスク１０２同士の共有データ部２０５へのアクセスが重複した場合に、実行終了までの時間が短いタスクによるアクセスを優先し、第２タスク１０２による共有データ部２０５へのアクセスを可能な限り提供する。

（第５の実施の形態の変形例）
全体監視時間は、タスクが共有データ部２０５へのアクセスに要する時間と、コア数との積よりも長い時間としてもよい。これにより、他のコアで実行されている第２タスク１０２のデータアクセスによる影響を防ぐことができる。

―第６の実施の形態―
図２４を参照して、アクセス制御装置である車両制御装置の第６の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、システム状態管理部を備えない点で、第１の実施の形態と異なる。

本実施の形態では、システム状態管理部１１１の代わりにハードウエアタイマの複数のモードとモードに対応する複数のフラグを併用してシステム状態管理を行う。タイマは設定された時間となったことを示すフラグを保持している。

図２４は本実施の形態における動作の概要を示す図である。図２４を参照してタイマの動作を説明する。第一のモードである連続実行モードではカウンタが設定時間（Ｔ５ｄ）になるとフラグ１をマッチング状態へと遷移し、カウンタを０へとリセットして再度カウントを開始する。カウントが開始されるとフラグ１は非マッチング状態へと遷移する。このモードをスロット時間の監視に用いることで、タスクを定められた時間で起動する。

第二のモードである単発実行モードではカウンタが設定時間（Ｔ５ｂ）になるとフラグ２をマッチング状態へと遷移し、再度時間を設定される（Ｔ５ｄ）までカウンタを停止させる。このモードをアクセス監視時間の監視に用いる。スロットの開始時（Ｔ５ａ）にアクセス監視時間の開始時刻を設定する。タスクがデータアクセスを試みる際にはシステム状態判定部１０６がフラグ２を参照し、フラグ２がマッチング状態の場合にはアクセス監視状態と判定、データアクセス制御部１０５がタスクのデータアクセスを禁止する。

上述した第６の実施の形態によれば、複数のタイマモード併用により、システム状態の管理をハードウエアタイマのみで実現できる。

―第７の実施の形態―
図２５〜図２６を参照して、アクセス制御装置である車両制御装置の第７の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、ＦＰＧＡを用いる点で、第１の実施の形態と異なる。

（構成）
図２５は第７の実施の形態における車両制御装置２００２のブロック図である。本実施の形態では、アクセス時間監視部１０９、スロット時間監視部１１０、およびシステム状態管理部１１１はＦＰＧＡ（field-programmable gate array）上に構成される。また第１の実施の形態の構成に加えて、ＦＰＧＡ上にタイマフラグ監視部２３０３をさらに備える。

図２６は、タイマフラグ監視部２３０３の動作を説明する図である。タイマフラグ監視部２３０３はアクセス時間監視部１０９およびスロット時間監視部１１０とタイマの時間を常に比較する。そしてタイマフラグ監視部２３０３は、アクセス時間監視部１０９とタイマが一致すると（図２６の時刻Ｔ６ｂ）ｍｏｎｉｔｏｒフラグをマッチング状態に遷移させ、スロット時間監視部とタイマが一致すると（時刻Ｔ６ｄ）ｓｌｏｔフラグをマッチング状態に遷移させる。システム状態管理部１１１は、ｍｏｎｉｔｏｒフラグおよびｓｌｏｔフラグの状態遷移を監視し、ｍｏｎｉｔｏｒフラグがマッチング状態に遷移すると（時刻Ｔ６ｂ）システム状態をアクセス監視状態に遷移させる。またシステム状態管理部１１１は、ｓｌｏｔフラグがマッチング状態に遷移されると（時刻Ｔ６ｄ）システム状態をアクセス非監視状態に遷移させる。

上述した第７の実施の形態によれば、ＦＰＧＡを用いた時間監視及び状態管理により、ひとつのタイマで複数の時間を監視可能となる。

―第８の実施の形態―
図２７〜図２８を参照して、アクセス制御装置である車両制御装置の第８の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、動作ログ管理部２１３の動作を明確にしている点で、第１の実施の形態と異なる。

図２７は、動作ログ管理部２１３の動作を表すフローチャートである。動作ログ管理部２１３は、各スロットにおけるタスクの開始時刻、終了時刻、タスクＩＤ及びスロット終了時の状態を取得（Ｓ７０１、Ｓ７０２）して記録する（Ｓ７０３）。特に終了時の状態を記録しておくことにより、タスクが正常に動作しているか、長い動作時間を有する跨りタスクか、異常が発生したことによる強制終了か、アクセス監視時間内でのデータアクセスによる終了か、アクセス監視時間内でのデータアクセスによる跨り中断かを動作ログに保持する。

図２８は、動作ログ管理部２１３が記録した動作ログ１１０１の一例を示す図である。動作ログ１１０１には、各スロットにおける開始時刻、終了時刻、タスクＩＤ、および終了時の状態が記録される。

上述した第８の実施の形態によれば、動作ログを記録することにより、各時間におけるタスクの状態を確認可能となる。また、他タスクへ影響を起こすタイミングでのデータアクセスを試みたタスクの発見が可能となる。

上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１０１…第１タスク
１０２…第２タスク
１０５…データアクセス制御部
１０６…システム状態判定部
１０７…タスク状態管理部
１０８…スケジューリング部
１０９…アクセス時間監視部
１１０…スロット時間監視部
１１１…システム状態管理部
２０５…共有データ部
２０６…タスク実行制御部
２０８…ＣＰＵ
２１０…タイマ
２１３…動作ログ管理部
２１４…アプリケーション部
２１５…ハードウエア
２１６…ソフトウエア
５０１…スケジューリングテーブル
１１０１…動作ログ
１９０１…システム状態テーブル
２００１…車両システム
２００２…車両制御装置
２３０３…タイマフラグ監視部

Claims (8)

1. 実行の優先度により分類され相対的に優先度が低い第１タスクおよび相対的に優先度が高い第２タスクを含むアプリケーション部と、
   前記第１タスクおよび前記第２タスクを実行する実行部と、
   実行されるタスクごとに、タスクごとのあらかじめ定められた長さの時間であるスロットを割り当て、前記第１タスクに割り当てた前記スロットにおいて、前記スロットの末尾の第１の所定時間をアクセス監視時間に設定するシステム状態管理部と、
   前記第１タスクおよび前記第２タスクによりアクセスされる共有データ部と、
   前記アクセス監視時間における前記第１タスクによる前記共有データ部へのアクセスを禁止するデータアクセス制御部とを備えるアクセス制御装置。
2. 請求項１に記載のアクセス制御装置において、
   前記アクセス監視時間は、前記第１タスクが前記共有データ部へのアクセスに要する時間よりも長いアクセス制御装置。
3. 請求項１に記載のアクセス制御装置において、
   前記データアクセス制御部は、前記アクセス監視時間に前記共有データ部へのアクセスを試みた前記第１タスクを終了状態に遷移させるアクセス制御装置。
4. 請求項１に記載のアクセス制御装置において、
   前記データアクセス制御部は、複数の前記スロットに跨って実行される前記第１タスクが、最終スロット以外で前記アクセス監視時間に前記共有データ部へのアクセスを試みると、前記第１タスクを次のスロットの開始時刻まで待機させるアクセス制御装置。
5. 請求項１に記載のアクセス制御装置において、
   タスクによる前記共有データ部へのアクセス状態を示すアクセスフラグと、
   タスクが前記共有データ部へのアクセスを開始すると前記アクセスフラグをオンにし、タスクが前記共有データ部へのアクセスを終了すると前記アクセスフラグをオフにするフラグ管理部とをさらに備え、
   前記データアクセス制御部は、前記アクセス監視時間の終了時に前記アクセスフラグがオンであると前記アクセス制御装置を再起動させるアクセス制御装置。
6. 請求項１に記載のアクセス制御装置において、
   前記タスクを実行する前記実行部を複数備え、
   システム状態管理部はさらに、前記第２タスクに割り当てた前記スロットにおいて、前記スロットの末尾の第２の所定時間を全体アクセス監視時間に設定し、前記第２の所定時間は前記第１の所定時間以上の長さであり、
   前記データアクセス制御部は、前記実行部ごとに前記アクセス監視時間であるか否かを判断し、前記全体アクセス監視時間における全ての前記実行部で実行される前記第１タスクによる前記共有データ部へのアクセスを禁止するアクセス制御装置。
7. 請求項６に記載のアクセス制御装置において、
   前記データアクセス制御部は、複数の前記実行部において前記第２タスクが前記共有データ部へのアクセスを試みると、前記スロットの終期までの時間が短い前記第２タスクによる前記共有データ部へのアクセスを優先させるアクセス制御装置。
8. 請求項１に記載のアクセス制御装置において、
   前記優先度は、前記タスクに要求される機能安全のレベルに基づいて決定されるアクセス制御装置。

Images