JP2019020870A

JP2019020870A - 車両制御装置

Info

Publication number: JP2019020870A
Application number: JP2017136710A
Authority: JP
Inventors: 勇気田中; Yuuki Tanaka; 敏史大塚; Toshifumi Otsuka; 祐石郷岡; Hiroshi Ishigooka; 成沢　文雄; Fumio Narisawa; 文雄成沢; 裕弘小田; Yasuhiro Oda; 永井　祐介; Yusuke Nagai; 祐介永井; 悠史福島; Yuji Fukushima
Original assignee: Hitachi Automotive Systems Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2017-07-13
Filing date: 2017-07-13
Publication date: 2019-02-07
Anticipated expiration: 2037-07-13
Also published as: WO2019012997A1; JP6861591B2

Abstract

【課題】
時間駆動スケジューリングにおける排他制御による他タスクへの影響を防止する。
【解決手段】
時間駆動スケジューリングでタスクの実行を管理する際に、排他制御に用いる共有資源のアクセス情報を用いずに行う。安全要求レベルの高い高優先度タスクに先行して実行される安全優先度レベルの低い低優先度タスクに割り当てられる実行スロットの最終部に、共有資源へのアクセス開始を保留するアクセス監視時間を設けることにより課題を解決する。
【選択図】図１

Description

本発明は、車両制御装置及び制御システムの時間駆動スケジューリングに関する。

本技術分野の背景技術として、特開２００３−１３１８９２号公報（特許文献１）がある。この公報には、「排他制御による影響を受けず決められたタイミングで実行されるようにするタスク実行制御装置を提供する」ことを課題とし、解決手段として、「セマフォ管理部は、タスクＣの共有資源獲得時に、タスクＣの資源解放予想時刻を、タスクＡの次の起動予定時刻と比較して、前者が後者より早ければタスクＣに資源占有を許す。また、タスクＣが資源占有中に第３のタスクＢによる割り込み処理が生じた場合、優先度管理部は、タスクＢの「割込処理時間」の累計が許容限度に達した時点でタスクＣの優先度をタスクＡと同じ優先度に上げるようスケジューリング部を制御する。」と記載されている。

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

上記背景技術ではタスクを優先度スケジューリングにより動作させる場合に、排他制御による高優先度タスクへの影響を防止する方法について記載されている。

しかしながら、各タスクがどの共有資源にアクセスするか公開されていない場合において、排他制御による影響を防止して各タスクを統合することは困難である。タスク統合を容易化する技術に時間駆動スケジューリングがある。時間駆動スケジューリングではタスクの起動タイミングとＣＰＵ資源を保証することが課題である。

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

上記課題を解決するために、本発明の一実施の態様は、例えば特許請求の範囲に記載されている技術的思想を用いればよい。具体的には、安全要求レベルの低いタスクに割り当てられた実行スロットの最終部に共有データへのアクセス開始を保留するアクセス監視時間を設けることにより解決可能である。

本発明によれば、車両制御装置において、時間駆動スケジューリングを実現する際に、他タスクと共有するデータアクセスへの考慮を不要にするなど、タスクの統合を容易化させつつかつ制御システムのタスクの動作時間に影響を与えないことが可能になる。これにより、時間駆動スケジューリングで動作する高信頼なシステムでタスクを統合することが容易となる。

車両制御装置内部の構成例である。車両制御装置の構成例である。タスクの状態遷移の例である。時間駆動制御のスロットとタスク実行の例である。スケジュールテーブルの例である。スケジューリング部の動作フロー例である。データアクセス監視のアクセス監視時間の例である。跨りタスクにおけるデータアクセス監視のアクセス監視時間の例である。アクセス監視時間の配置例である。共有データへアクセス時の動作フロー例である。動作ログの例である。タスクの動作フロー例である。システム状態管理部の動作フロー例である。タスク状態管理部の動作フロー例である。共有データ群の動作フロー例である。動作ログ管理部の動作フロー例である。マルチコア環境における車両制御装置の構成例である。マルチコア環境におけるアクセス監視時間の例である。システム状態テーブルの例である。車両システムの構成例である。アクセス監視状態における動作例である。

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

＜車両システムの構成＞
図２０は本実施例の車両制御装置を有する車両システムの概要である。２００１は自動車など内部に車両制御装置を有する車両システム、２００２は車両を制御するための車両制御装置、２００３は地図などの情報を取得する無線通信部、２００４は車両制御装置２００２の制御に従って車両運動を制御する、たとえばエンジン、ホイール、ブレーキ、操舵装置等の駆動を行う駆動装置、２００５は外界から入力される情報を取得し、外界認識情報を生成するための情報を出力するカメラやセンサーなどの認識装置、２００６は車両の速度や警告など必要情報を表示する出力装置、２００７はペダル、ハンドルなど車両操作の指示を入力するための入力装置、２００８は車両システム２００１が外界に対して、車両の状態等を通知するための、ランプ、ＬＥＤ、スピーカ等の通知装置、を示している。

＜車両制御装置の構成＞
様々な自動車の自動運転技術が実現されつつある。多くの自動運転技術はコンピュータによる制御装置により実現されている。図２は車両制御装置２００２のブロック図である。アプリケーション２１４としてセンサーデバイス等の周辺装置から外部情報を処理するセンサーフュージョン２０１、自動運転のための地図情報を処理するマップフュージョン２０２、他の車両などに追突しそうになる直前に自動ブレーキを作動させて停止させたり前を走る車両と一定の間隔を保ったまま追従したり車線からはみ出さないようにステアリングを制御するといった機能を実現するADAS(Advanced Driving Assistant System)２０３、自動駐車を実現するオートパーキング２０４などがある。またアプリケーションで利用されるデータは共有データ群２０５により処理・管理が一元化されている。これにより各アプリケーションでのデータ管理機能を省くことができ自動運転での自動車の制御に求められる高速な応答を実現している。これらのアプリケーションはタスク実行制御部２０６によりリアルタイム性を保ちながら時間駆動スケジューリングによって実行される。タスク実行制御部２０６はスケジューリング部１０８の指定したタイミングに基づきタスク状態管理部１０７により後述する各タスク１０１、１０２に対して、後述する状態遷移に基づき管理を行う。

オペレーティングシステムは組み込みOS２０７が使用されている。ハードウェア２１５はCPU２０８、メモリ２０９、リアルタイム制御のタイミングをとるためのタイマ２１０、ネットワークにアクセスするためのネットワークアダプタ２１１、そしてセンサーなどの外部状況を監視するものや自動ブレーキ装置などの周辺装置２１２から構成される。また、各タスクの動作を記録するため、動作ログ管理部２１３がある。

＜タスク＞
OSが管理対象とするプログラムの並行実行の単位、すなわち一つのタスク中のプログラムは逐次的に実行されるのに対して、異なるタスクのプログラムは並行して実行が行われる。ただし、並行して実行が行われるというのは、アプリケーションからみた概念的な動作であり、実装上はOSの制御のもとで、それぞれのタスクが時間駆動で実行される。タスクは１アプリケーションにつき最低１個生成される。

タスクには処理の内容に応じて実行時間を保証しなければならないものと、実行時間が多少遅れてもよいものがある。ISO26262では機能安全の視点からタスクを危険事象の低いものから高いものへ順にQM(Quality Management)、ASIL-A(Automotive Safety Integrity Level-A)、ASIL-B(Automotive Safety Integrity Level-B),ASIL-C(Automotive Safety Integrity Level-C),ASIL-D(Automotive Safety Integrity Level-D)に分類している。大きく分類すると安全性担保という点において実行時間を保証しなければならないタスクはASIL、安全保障に関係がなく実行時間が多少遅れてもよいタスクはQMとなる。

＜タスクの状態遷移＞
図３はタスクの状態遷移図である。タスクの状態は、以下のように分類される。
１．実行状態(RUNNING)３０１: CPUが割り当てられタスクが実行している状態。
２．実行可能状態(READY)３０２: タスクを実行する条件は整っているが、当該タスクよりも優先順位が高いタスクが実行状態であるため、実行できない状態。
３．待機状態(WAITING)３０３: 何らかの条件が整うまで、実行を中断した状態。
４．休止状態(DORMANT)３０４: タスクがいまだ起動されていないか、終了した状態。

まず、新規に生成したタスクは最初に休止状態３０４に移行し、タスク起動によって実行可能状態３０２へと遷移する。時間駆動スケジューリングにおいては、タスクに割り当てられた時間（スロット）の開始タイミングにてディスパッチされ、実行状態３０１へと遷移、タスク処理を実行する。タスクの実行が完了、もしくは割り当てられたスロットの時間が終了した場合、タスク状態を実行可能状態３０２へ遷移する。

タスクがリソース要求を行い、排他制御によりリソースの取得ができない場合には、タスク状態を待機状態３０３へと遷移させる。その後リソースが解放され、該タスクがリソースを取得可能となった場合には、タスク状態を待機状態３０４から実行可能状態３０２へと遷移させる。タスクが強制終了命令を受けた、もしくはタスク自身が終了処理を行った場合、タスク状態は休止状態３０４へと遷移される。

＜時間駆動スケジューリング＞
時間駆動スケジューリングとは決められた実行順により、決められた時刻に決められた時間だけタスクを実行するOSのタスク実行スケジューリングである。時間駆動スケジューリングにて制御した場合のタスク実行の例を図４に示す。図４は横軸が時間経過を表しており、スロットＩＤ（ここではＳＬ１からＳＬ９）が割り振られることで分割されている。タスクは割り当てられたスロットの時間内で処理実行（ここではt_1, t_2, t_3）が可能である。最後のスロットへ到達した場合、最初のスロット（ＳＬ１）に戻りスケジューリングを継続する。

時間駆動スケジューリングには図５に示すスケジューリングテーブル５０１を使用する。スケジューリングテーブルの構成はスロットＩＤ、スロットの開始時刻、スロットの終了時刻、タスクＩＤ、時間エラー判定フラグ、タスクが自ら待機状態へ遷移するための排他ＩＤから構成される。スケジューリングテーブル５０１は各タスクの実行周期、最悪実行時間、安全要求レベル等の情報に基づいて作成される。スケジューリングテーブル５０１の１サイクルの長さは全タスクの実行周期を満たす長さにて作成される。サイクルの終端へ到達した場合、スロット１に戻りスケジューリングを継続する。

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

タスクの動作フローを図１２に示す。タスクの処理（Ｓ３０１）が実行完了する際に実行完了フラグを立ち上げ（Ｓ３０２）、自タスクに割り当てられた排他を取得し（Ｓ３０３）、待機状態３０３に遷移することで実行完了したことを示す。スケジューリング部１０８は前スロットのタスクの実行完了フラグを参照することで動作完了しているかの判定を行う。また、該タスクに割り当てられた排他を解除することで、該タスクを実行可能状態３０２へと遷移、スケジューリング部１０８が待機状態３０３へ遷移することで該タスクは実行状態３０１へと遷移する。実行完了フラグはスケジューリング部１０８により立ち下げる、もしくは該タスクの次スロットにて再開時に該タスクが立ち下げる。

＜時間エラー判定＞
タスクの動作が割り当てられたスロットの時間内で完了しない場合の処理を説明する。前のスロットのタスクが実行完了していない場合（Ｓ１０１のｎｏ）、時間エラー判定フラグを参照し、“する”の場合には前スロットのタスクを待機状態３０３へ遷移させる（Ｓ１０５）。この処理を行うタスクを跨りタスクと呼ぶ。跨りタスクは１つのスロット内で処理が完了しない長い時間を要するタスクであり、複数のスロットにわたって動作を行う。

時間エラー判定フラグが“しない”の場合（Ｓ１０４のｙｅｓ）、前のスロットのエラーフラグを立て（Ｓ１０６）、前のスロットのタスクを休止状態３０４へ遷移させる（Ｓ１０７）。強制終了には時間を要するため、Ｓ１０７にてタスクを一時的に待機状態３０３へ遷移させ、空いているスロットで休止状態３０４へ遷移させても良い。

＜車両制御装置の構成＞
タスクの実行を管理する制御装置の構成例について図１を用いて説明する。図１は図２の車両制御装置内部の１構成例である。安全要求レベルの低い第１タスク１０１と安全要求レベルの高い第２タスク１０２が存在する。安全要求レベルの低いアプリケーションの処理は第１タスク１０１となり、安全要求レベルの高いアプリケーションの処理は第２タスクとなる。

タスク実行制御部２０６はタスクからの共有データ群２０５へのアクセス要求を制御するデータアクセス制御部１０５及びシステム状態を管理するシステム状態管理部１０６、タスク状態を管理するタスク状態管理部１０７及びこれらと協調してタスクスケジューリングを行うスケジューリング部１０８から構成される。

＜タスクのデータアクセスにおける問題＞
共有データ群２０５へのアクセスにおける問題について図１５を用いて説明する。タスクには実行時間を保証しなければならないASILに分類されるタスクと、実行時間が多少遅れてもよいQMに分類されるものがある。複数のタスクが実行されるときにタスク間で共通のアクセスを行う共有データ群２０５がある場合は、同時アクセスが発生しないように排他制御（Ｓ６０１、Ｓ６０３）を行わなければならない。しかしながらQMタスクが実行され共有データ群を占有アクセスしている間に、実行時間を保証しなければならないASILタスクの実行時刻となり、ASILタスクの実行が開始されたとしてもQMタスクと同一の共有データ群２０５をアクセスする場合、ASILタスクは共有データ群２０５へのアクセスが排他制御によりASILタスクは待機状態とされてしまう。時間駆動スケジューリングではこのようなASILタスクの実行遅延を回避しなければならない。

＜タスクのデータアクセス監視時間＞
タスクのデータアクセス監視時間について図７及び図１３を用いて説明する。安全要求レベルの低い第１タスクと安全要求レベルの高い第２タスクが存在する場合、第１タスクは割り当てられたスロット時間T1aからT1dの間で動作する。安全要求レベルの低いタスクに割り当てられたスロットでは、スロットの最後（T1bからT1d）にデータアクセス監視用のアクセス監視時間を設ける。アクセス監視時間は想定されるデータアクセス時間（T1bからT1c）より長い時間を設ける。アクセス監視時間の開始時（T1b）にシステム状態管理部１０６がシステム状態をアクセス非監視状態からアクセス監視状態へ遷移させ（Ｓ４０２）、アクセス監視時間の終了時（T1d）にシステム状態をアクセス監視状態からアクセス非監視状態へ遷移させる（Ｓ４０３）。

＜アクセス監視状態＞
アクセス監視状態によるタスクのデータアクセス制御を図１４及び図２１を用いて説明する。第１タスクが共有データ群２０５へアクセスを試みる際に、システム状態がアクセス監視状態である場合には第１タスクによる共有データ群２０５へのアクセスをデータアクセス制御部１０５が禁止し、タスク状態管理部１０７により第１タスクのタスク状態を休止状態３０４へと遷移させる（Ｓ５０４）。システム状態がアクセス監視状態である場合に、第１タスクのタスク状態を休止状態３０４へと遷移せず、待機状態３０３へ遷移もしくは無限ループを実行させ、時間エラー判定させてもよい。第１タスクが共有データ群２０５へアクセスを試みる際に、システム状態がアクセス非監視状態である場合には第１タスクによる共有データ群２０５へのアクセスを実施する。

＜跨りタスクのデータアクセス制御＞
跨りタスクのデータアクセス制御について図８を用いて説明する。複数のスロットにまたがって動作する安全要求レベルの低い第１タスクと、安全要求レベルの高い第２タスクが存在する場合、第１タスクは割り当てられたスロット時間T2aからT2dで動作し、続きの動作をT2eからT2hの間で行う。

跨りのあるタスクのスロットにおいても、安全要求レベルの低いタスクに割り当てられたスロット全てにおいて、スロットの最終部（T2bからT2d及びT2fからT2h）にデータアクセス監視用のアクセス監視時間を設ける。

第１タスクが共有データ群２０５へアクセスを試みる際に、システム状態がアクセス監視状態である場合にはデータアクセス制御部１０５が第１タスクによる共有データ群２０５へのアクセスを保留し、タスク状態管理部１０７により第１タスクのタスク状態を待機状態へと遷移させる（Ｓ５０２）。システム状態がアクセス監視状態である場合に、第１タスクのタスク状態を待機状態３０３へと遷移させず、無限ループを実行させ、時間エラー判定にて待機状態３０３へ遷移させてもよい。保留された共有データ１０４へのアクセスは第１タスクの続きのスロット(T2eからT2f)にて開始される。第１タスクが共有データ群２０５へアクセスを試みる際に、システム状態がアクセス非監視状態である場合には第１タスクによる共有データ群２０５へのアクセスを実施する。

＜割り当てスロットに基づいたアクセス監視時間配置＞
アクセス監視時間の配置は安全要求レベルの高いタスクの起動タイミングに左右されず、安全要求レベルの低いタスクのスロット時間によって決定される。図９を用いて説明する。第１タスクと安全要求レベルが同様な第３タスクが存在する場合、第１タスクはT3aからT3d及びT3jからT3lにて動作する。第３タスクはT3fからT3hにて動作する。アクセス監視時間は第１タスク及び第３タスクにそれぞれ割り当てられたスロット最終部（T3bからT3d,T3fからT3h及びT3jからT3l）に配置される。安全要求レベルの低いタスクのスロット時間に基づいてアクセス監視時間を配置することにより、共有データへのアクセスを行うタスク情報が無い場合においても、排他中のタスク切り替えによる影響を防ぐことが可能となる。

＜データアクセス時動作＞
タスクがデータアクセスを試みた際の動作フローについて図１０を用いて説明する。タスクからデータアクセス要求をデータアクセス制御部１０５が受け取ると、システム状態管理部１０６にてシステム状態を確認（Ｓ２０１）し、システム状態がアクセス非監視状態（Ｓ２０１のｎｏ）の場合には共有データ群２０５へのアクセス状況を示すアクセスフラグをアクセス中へ遷移させ（Ｓ２０２）、共有データ群２０５へのアクセスを実行する（Ｓ２０３）。共有データ群２０５へのアクセス完了の後、アクセスフラグを非アクセス中へと遷移させる（Ｓ２０４）。システム状態がアクセス監視状態（Ｓ２０１のｙｅｓ）の場合には、スケジュールテーブル５０７にて現在のスロットの時間エラー判定フラグの内容を判定する（Ｓ２０５）。前記時間エラー判定フラグが“しない”の場合（Ｓ２０５のｎｏ）、タスク状態管理部１０７にてタスクの状態を待機状態３０３へ遷移させ（Ｓ２０６）、続きのスロットにてタスク状態が実行状態３０１へ遷移した後にデータアクセスを行う（Ｓ２０２，Ｓ２０３，Ｓ２０４）。前記時間エラー判定フラグが“する”の場合（Ｓ２０５のｙｅｓ）、現在のスロットのマージン内エラーフラグをONに遷移させ（Ｓ２０７）、現在実行状態３０１のタスクを強制終了させて休止状態３０４にする（Ｓ２０８）。強制終了には時間を要するため、Ｓ２０８にてタスクを一時的に待機状態３０３へ遷移させ、空いているスロットで休止状態３０４へ遷移させても良い。

＜動作ログ＞
動作ログの作成方法について図１１及び図１６を用いて説明する。各スロットにおけるタスクの開始時刻、終了時刻、タスクＩＤ及びスロット終了時の状態を取得（Ｓ７０１、Ｓ７０２）・記録する（Ｓ７０３）。特に終了時の状態を記録しておくことにより、タスクが正常に動作しているか、長い動作時間を有する跨りタスクか、異常が発生したことによる強制終了か、アクセス監視時間内でのデータアクセスによる終了か、アクセス監視時間内でのデータアクセスによる跨り中断かを動作ログから確認可能となる。

以上説明した実施例によれば、時間駆動によるスケジューリングにおいて、排他制御に用いる共有データ群のアクセス情報の有無にかかわらず、安全要求レベルの低いタスクの排他取得による他タスクの動作への影響を防ぐことが可能となる。また、これら処理について動作ログを記録することにより、他タスクへ影響を起こすタイミングでのデータアクセスを試みたタスクの発見が可能となる。

本発明にかかる第２の実施例について説明する。本実施例では、アクセス監視時間を超えてデータアクセスを行うタスクが存在する場合の例を示す。本実施例においては、第１タスク１０１もしくは第２タスク１０２が共有データ群２０５へデータアクセス中であることを示すアクセスフラグを用いたシステム制御を行う。タスクのデータアクセス開始時にデータアクセス制御部１０５にてアクセスフラグを“アクセス中”に遷移させ、データアクセス完了時にアクセスフラグを“非アクセス中”に遷移させる。アクセス監視時間の終了時にアクセスフラグが“アクセス中”の場合、車両制御装置２００１を再起動することにより、全排他をリセットさせる。これによりアクセス監視時間を超えてデータアクセスを行った場合の排他による他タスクへの影響を最小限に抑え、早期の回復が可能となる。またアクセス監視時間開始時にタスク状態が実行状態かつアクセスフラグが“非アクセス中”である場合、異常発生中と判断しタスク状態管理部１０７によりタスクを待機状態へ遷移させてもよい。また、再起動する対象は車両制御装置２００１に限らず、実装されるその他のシステム全体で再起動させてもよい。

以上説明した実施例によれば、データアクセス中かの状況を管理することにより、アクセス監視時間を超えてのデータアクセスによる他タスクの動作への影響を防止することが可能となる。

本発明にかかる第３の実施例について説明する。本実施例では、安全要求レベルの高い第２タスクにより他タスクへ影響を与えることが許されない場合の例について説明する。本実施例においては、安全要求レベルの低い第１タスク１０１に割り当てられたスロットの最終部にデータアクセス監視用のアクセス監視時間を設けるだけでなく、安全要求レベルの高い第２タスク１０２に割り当てられたスロットの次のスロットが同様の安全要求レベルであった場合にも、第２タスク１０２に割り当てられたスロット最終部にデータアクセス監視用のアクセス監視時間を設ける。これにより、安全要求レベルの高い第２タスク１０２が誤動作を起こした場合に他の安全要求レベルの高い第２タスク１０２への影響を防ぐことが可能となる。

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

本発明にかかる第４の実施例について説明する。本実施例では、開発ツールから本特許のスケジューリングテーブル５０１を生成する際の実施例を説明する。本実施例においては、各タスクの周期、最悪実行時間、安全要求レベル等の設計情報からスケジューリングテーブル５０１を自動生成する。自動生成時には安全要求レベルの情報をもとに、各スロットの最終部にデータアクセス監視用のアクセス監視時間を設けるかを決定する。アクセス監視時間を設ける場合には、アクセス監視時間を含めたスロット時間の配置が行われる。これにより、アクセス監視時間の必要有無を考えずにアプリケーション設計が可能となる。

本発明の第５の実施例について図１７、図１８および図１９を用いて説明する。第１コアから第Ｎコアまでの複数のコア１７０１、１７０２、１７０３が共有データ群へデータアクセスを行う制御装置において、各コアは安全要求レベルの低い第１タスク１０１と安全要求レベルの高い第２タスク１０２を有する。時間駆動スケジューリングで制御されている各コアにおいて、各スロットの最終部(T4bからT4dおよびT4eからT4h)にアクセス監視時間を有する。第１タスク１０１用スロットにおいて、アクセス監視時間は「アクセス時間(T4bからT4c) ＜アクセス監視時間(T4bからT4d)」となるように配置する。

第２タスク１０２用スロットにおいて、アクセス監視時間は「アクセス時間×２(T4eからT4g) ＜アクセス監視時間(T4eからT4h)」となるように配置する。本実施例においては、各コアの状態を管理するシステム状態テーブル１９０１を使用する。システム状態テーブルは各コアがアクセス監視状態かアクセス非監視状態かの情報及び、"全コア用アクセス監視カウンタ"を保持する。全コア用アクセス監視カウンタは０からコア数の間を増減する。第１タスク１０１用スロットにおけるアクセス監視時間の開始時(T4b)にて、システム状態管理部１０５により該コアのシステム状態をアクセス監視状態へと遷移させる。

第１タスク１０１用スロットにおけるアクセス監視時間の終了時(T4c)にて、システム状態管理部１０５により該コアのシステム状態をアクセス非監視状態へと遷移させる。アクセス監視状態のコアでは、第１タスク１０１における共有データ群２０５への新規データアクセスを禁止する。第２タスク１０２用スロットにおけるアクセス監視時間の開始時(T4e)にて、システム状態管理部１０５により該コアのシステム状態をアクセス監視状態へと遷移させ、システム状態管理部１０５により全コア用アクセス監視カウンタを１インクリメントさせる。第２タスク１０２用スロットにおけるアクセス監視時間の終了時(T4h)にて、システム状態管理部１０５により該コアのシステム状態をアクセス非監視状態へと遷移させ、全コア用アクセス監視カウンタを１デクリメントさせる。全コア用アクセス監視カウンタが１以上の場合、すべてのコアにおける第１タスクによる共有データ群２０５への新規データアクセスを禁止する。複数のコア１７０１、１７０２、１７０３により共有データ群２０５へのデータアクセス要求がある場合、システム状態がアクセス監視状態のコアの第２タスク１０２によるデータアクセスを優先する。これにより、アクセス監視時間より前に他コアの第１タスク１０１がアクセスした際にも、第１タスク１０１によるデータアクセス完了後に第２タスク１０２によるデータアクセスを実行する時間を確保可能となる。これにより、メニーコア環境における第１タスク１０１のデータアクセスによる第２コア１０２への影響を防ぐことが可能となる。また、第２タスク１０２用スロットにおけるアクセス監視時間は「アクセス時間×コア数＜アクセス監視時間」となるように配置してもよい。これにより、他コアの第２タスク１０２のデータアクセスによる影響を防ぐことが可能となる。

以上説明した実施例によれば、複数のコアが存在する場合において、各コアにアクセス監視時間を設けることで、安全要求レベルの低いタスクによる安全要求レベルの高いタスクへの影響を防止することが可能となる。

１０１第１タスク
１０２第２タスク
１０５データアクセス制御部
１０６システム状態管理部
１０７タスク状態管理部
１０８スケジューリング部
２０１センサーフュージョン
２０２マップフュージョン
２０３ＡＤＡＳ
２０４オートパーキング
２０５共有データ群
２０６タスク実行制御部
２０７組み込みＯＳ
２０８ＣＰＵ
２０９メモリ
２１０タイマ
２１１ネットワークアダプタ
２１２周辺装置
２１３動作ログ管理部
２１４アプリケーション
２１５ハードウェア
３０１実行状態
３０２実行可能状態
３０３待機状態
３０４休止状態
５０１スケジューリングテーブル
１１０１動作ログ
１７０１第一コア
１７０２第二コア
１７０３第三コア
２００１車両システム
２００２車両制御装置
２００３無線通信部
２００４駆動装置
２００５認識装置
２００６出力装置
２００７入力装置

Claims

定められた時間に基づいて第１タスク及び第２タスクを起動し、排他制御下にある共有データ群を介して、制御を実施する車両制御装置において、
前記定められた時間とは別にデータアクセス時間に基づいて定義されるアクセス監視時間を備え、定義された前記アクセス監視時間に基づいてシステム状態をアクセス監視状態に遷移させ、前記アクセス監視時間の終了時には遷移前の状態に遷移させるシステム状態管理部と、前記アクセス監視状態の際には新たなデータアクセスを禁止するデータアクセス管理部と、を有することを特徴とする車両制御装置。
前記第１タスクの実行スロットの最終部に前記データアクセス時間より長い前記アクセス監視時間を有することを特徴とする、請求項１に記載の制御装置。
前記第１タスクによる排他を伴うデータアクセス開始時にシステム状態がアクセス監視状態の場合、前記第１タスクを終了状態に遷移させるタスク状態管理部を有することを特徴とする、請求項１に記載の制御装置。
複数に分離された実行スロットにて継続実行可能なタスクを起動した際に、前記タスクの最終スロット以外の実行スロットにおいても各分離された実行スロットの最終部に前記アクセス監視時間を有することを特徴とする、請求項１に記載の制御装置。
前記継続実行可能なタスクの分離された実行スロットにおいて、前記タスクによる排他を伴うデータアクセス開始の際にシステム状態を確認し、アクセス監視状態である場合には前記タスクを待機状態に遷移させるタスク状態管理部を有することを特徴とする、請求項１に記載の制御装置。
前記タスクが共有データにアクセス中であることを示すアクセスフラグを有し、データアクセス開始時に前記アクセスフラグをアクセス中に遷移させ、データアクセス終了時に前記アクセスフラグを非アクセス中に遷移させるフラグ管理部を有し、定義された前記アクセス監視時間の終了時に前記アクセスフラグがアクセス中である場合に、システムを再起動させ全ての排他を解除する機構を有することを特徴とする、請求項１に記載の制御装置。
安全要求レベルの低い第１タスクと安全要求レベルの高い第２タスクを有することを特徴とする、請求項１に記載の制御装置。
安全要求レベルが同じ第１タスク及び第２タスクを有することを特徴とする、請求項１に記載の制御装置。
マルチコア環境において、第一タスクと第二タスクを有し、データアクセス時間に基づいて定義されるアクセス監視時間を備え、定義された前記アクセス監視時間内ではタスクによる新たなデータアクセスを禁止するデータアクセス管理部を有することを特徴とする制御装置。