【文献】
武安政明、徳永雄一,車載制御ソフトウェア向けデータ保護機構,電子情報通信学会技術研究報告,日本,一般社団法人電子情報通信学会,2014年04月18日,Vol.114, No.22,pp.33−36(DC2014-7),ISSN 0913-5685
(58)【調査した分野】(Int.Cl.,DB名)
前記信頼度管理部は、前記保護データ部に対して書き込まれたデータが妥当でないと前記妥当性検証部が判断したときは、前記保護データ部に対してデータを書き込んだタスクの前記信頼度を前記閾値未満に下げる
ことを特徴とする請求項6記載の車両制御装置。
【発明を実施するための形態】
【0011】
<実施の形態1:車両システムの構成>
図1は、本発明の実施形態1に係る車両制御装置100を備える車両システム10の概略図である。車両システム10は、車両制御装置100、無線通信部11、駆動装置12、認識装置13、出力装置14、入力装置15、通知装置16を備える。
【0012】
車両制御装置100は、車両の動作を制御する装置であり、例えば自動運転ECU(Electronic Control Unit)として構成されている。無線通信部11は、地図などの情報を車外から取得する。駆動装置12は、車両制御装置100の制御にしたがって車両運動を制御する。駆動装置12は、たとえばエンジン、ホイール、ブレーキ、操舵装置などを駆動する。認識装置13は、外界から入力される情報を取得し、外界認識情報を生成するための情報を出力する。認識装置13は、例えばカメラやセンサなどデバイスである。出力装置14は、車両速度や警告などの情報を表示する。入力装置15は、ペダル、ハンドルなど車両操作の指示を入力するための装置である。通知装置16は、車両システム10が外界に対して車両の状態などを通知するためのデバイスであり、例えばランプ、LED、スピーカなどによって構成されている。
【0013】
<実施の形態1:車両制御装置の構成>
図2は、車両制御装置100の構成図である。車両制御装置100は、ソフトウェア210とハードウェア220によって構成されている。ソフトウェア210は、アプリケーション部110、タスク実行制御部120、システム管理部130、共有データ管理部140、動作ログ管理部150、OS(Operating System)160を有する。ハードウェア220は、CPU(Central Processing Unit)221、メモリ222、タイマ223、ネットワークアダプタ224、周辺装置225を有する。
【0014】
アプリケーション部110は、車両制御装置100が実行するアプリケーションプログラムの集合である。プログラムを実際に実行するのはCPU221であるが、以下では記載の便宜上、各プログラムを動作主体として説明する場合がある。アプリケーションプログラムとしては例えば、センサーフュージョン211、マップフュージョン212、ADAS(Advanced Driving Assistant System)213、オートパーキング214などがある。センサーフュージョン211は、センサなどの周辺装置225から外部情報を取得する。マップフュージョン212は、自動運転のための地図情報を処理する。ADAS213は、(a)他の車両などに追突しそうになる直前に自動ブレーキを作動させて停止させる、(b)前を走る車両と一定の間隔を保ったまま追従する、(c)車線からはみ出さないようにステアリングを制御する、などの自動運転機能を実現する。オートパーキング214は、自動駐車を実現する。
【0015】
タスク実行制御部120は、アプリケーション部110が有する各プログラムを、時間駆動スケジューリングによりリアルタイム性を保ちながらタスクとして実行する。共有データ管理部140は、タスク実行制御部120が実行するタスク間で共通して使用するデータを一元的に管理する。これにより各アプリケーションはデータ管理処理を省くことができるので、自動運転において求められる高速な応答を実現できる。システム管理部130は各タスクの動作を制御する方法を管理する。これら機能部の詳細については後述する。動作ログ管理部150は、各タスクの動作を記録する。OS160は例えば組込OSである。
【0016】
メモリ222は、CPU221が一時的に使用するデータを格納する。タイマ223は、リアルタイム制御のタイミングをとるためのものである。ネットワークアダプタ224は、ネットワークにアクセスするインターフェースである。周辺装置225は、センサなどの外部状況を監視するデバイス、自動ブレーキ装置などのアクチュエータ、などの装置である。
【0017】
<実施の形態1:タスクスケジューリングについて>
車両制御装置100の詳細について説明する前に、タスクスケジューリングに関する概要をまず説明する。OSが管理対象とするプログラムの並行実行の単位、すなわち1つのタスク中のプログラムは逐次的に実行されるのに対して、異なるタスクのプログラムは並行して実行される。ただし、並行して実行されるというのは、アプリケーションからみた概念的な動作であり、実装上はOSの制御のもとで、それぞれのタスクが時間駆動で実行される。タスクは1アプリケーションにつき最低1個生成される。
【0018】
タスクは、処理の内容に応じて実行時間を保証しなければならないものと、実行時間が多少遅れてもよいものがある。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となる。
【0019】
図3は、タスクの状態遷移図である。タスクの状態は、以下のように分類される。(1)実行状態(RUNNING)301:CPUが割り当てられタスクが実行している状態。(2)実行可能状態(READY)302:タスクを実行する条件は整っているが、当該タスクよりも優先順位が高いタスクが実行状態であるため、実行できない状態。(3)待機状態(WAITING)303:何らかの条件が整うまで、実行を中断した状態。(4)休止状態(DORMANT)304:タスクがいまだ起動されていないか、終了した状態。タスク実行制御部120は各タスクの状態を制御する。
【0020】
新規に生成したタスクは最初に休止状態304に移行し、タスク起動によって実行可能状態302へと遷移する。時間駆動スケジューリングにおいては、タスクに割り当てられた時間(スロット)の開始タイミングにおいてタスクがディスパッチされ、実行状態301へと遷移し、タスク処理を実行する。タスクの実行が完了、もしくは割り当てられたスロットの時間が終了した場合、タスク状態は実行可能状態302へ遷移する。
【0021】
タスクがリソースを要求し、排他制御によりリソースを取得できない場合は、タスク状態を待機状態303へ遷移させる。その後リソースが解放されて当該タスクがそのリソースを取得できるようになった場合は、タスク状態を待機状態303から実行可能状態302へ遷移させる。タスクが強制終了命令を受けた、もしくはタスク自身が終了処理を実施した場合、タスク状態は休止状態304へ遷移される。
【0022】
図4は、時間駆動スケジューリングによりタスクの実行順を制御する例を示すタイムチャートである。時間駆動スケジューリングとは、あらかじめ決められた実行順にしたがって、あらかじめ決められた時刻において、あらかじめ決められた時間長だけタスクを実行する、OSのタスク実行スケジューリング手法である。
図4の横軸は時間経過であり、スロットID(ここではSL1からSL9)が割り振られることにより、各タイムスロットに分割されている。タスク(ここではt_1、t_2、t_3)は割り当てられたスロットの時間内で処理される。最後のスロットへ到達した場合、最初のスロット(SL1)に戻りスケジューリングを継続する。
【0023】
図5は、スケジューリングテーブル1231の例である。後述するスケジューリング部123は、スケジューリングテーブル1231を用いて、各タスクの実行スケジュールを管理する。スケジューリングテーブル1231はデータフィールドとして、スロットID、スロット開始時刻、スロット終了時刻、タスクID、時間エラー判定フラグ、排他IDを有する。排他IDは、タスクが自ら待機状態へ遷移するために用いる。スケジューリング部123は、各タスクの実行周期、最悪実行時間、安全要求レベルなどの情報に基づいてスケジューリングテーブル1231を作成する。スケジューリングテーブル1231の1サイクルの長さは、全タスクの実行周期を満たす長さとなるように作成される。サイクルの終端へ到達した場合、最初のスロットに戻りスケジューリングを継続する。
【0024】
<実施の形態1:車両制御装置の詳細>
図6は、車両制御装置100の詳細を説明する図である。便宜上、アプリケーション部110が実行するタスクを、第1タスク111と第2タスク112に分類した。タスク実行制御部120は、安全要求レベルの低いアプリケーションを第1タスク111として処理し、安全要求レベルの高いアプリケーションを第2タスク112として処理するものとする。
【0025】
タスク実行制御部120は、データアクセス制御部121、保護適用判定部122、スケジューリング部123、タスク状態管理部124を有する。データアクセス制御部121は、共有データ管理部140が保持している共有データに対する書込アクセス要求を各タスクから受け付けて各タスクに代わってその共有データにアクセスする。保護適用判定部122は、タスクがアクセスする共有データの正常性を保護する必要があるか否かを判定する。スケジューリング部123は、スケジューリングテーブル1231を用いてタスクをスケジューリングする。タスク状態管理部124は、各タスクの状態を管理する。これら機能部の詳細については後述する。
【0026】
共有データ管理部140は、共有データ部141、妥当性検証部142、保護通信データ部143を有する。共有データ部141は、タスク間で共有するデータを保持する。保護通信データ部143は、正常性を保護する必要があるデータを保持する。妥当性検証部142は、正常性を保護する必要があるデータが妥当であるか否かを検査し、正常なデータのみ保護通信データ部143から共有データ部141へ移動させる。これら機能部の詳細については後述する。
【0027】
システム管理部130は、スロット分類管理部131、スロット分類通知部132、スロット時間監視部133を有する。スロット時間監視部133は、タスクがスロットの時間内で完了するか否かを監視する。スロット分類管理部131は、各スロットがデータの正常性を保護する必要があるか否か(本発明においてこれをスロット分類と呼ぶ)を管理する。スロット分類通知部132は、現在のスロット分類を保護適用判定部122へ通知する。これら機能部の詳細については後述する。
【0028】
図7は、スケジューリング部123の動作を説明するフローチャートである。スケジューリング部123は、各スロットの開始時刻になるごとに、タイマ223にしたがって本フローチャートを開始する。以下
図7の各ステップについて説明する。
【0029】
(
図7:ステップS101)
スケジューリング部123は、前のスロットのタスクが実行完了しているか否か判定する。完了している場合はステップS106へスキップし、完了していない場合はステップS102へ進む。
【0030】
(
図7:ステップS102)
スケジューリング部123は、スケジューリングテーブル1231が記述している当該タスクの時間エラー判定フラグを参照する。フラグが「する」であればステップS104へ進み、それ以外であればステップS103へ進む。
【0031】
(
図7:ステップS102:補足)
時間エラー判定フラグは、当該タスクがスロット時間内に完了したか否かを判定する場合は「する」にセットされている。すなわちそのタスクは、スロット時間内に完了することが予定されている。時間エラー判定フラグが「する」以外である場合、そのタスクは複数のスロットにまたがって実行されることが予定されている。ステップS103〜S105はこのことを前提にしている。
【0032】
(
図7:ステップS103)
スケジューリング部123は、タスク状態管理部124を介して、前のスロットのタスク状態を待機状態へ遷移させる。本ステップを実施する場合、前のスロットのタスクはスロット時間内に完了しないことが予定されているからである。
【0033】
(
図7:ステップS104〜S105)
スケジューリング部123は、前のスロットのエラーフラグを立てる(S104)。スケジューリング部123は、タスク状態管理部124を介して、前のスロットのタスクを強制終了して休止状態へ遷移させる(S105)。強制終了には時間を要するので、S105においてタスクを一時的に待機状態へ遷移させ、空いているスロットで休止状態へ遷移させてもよい。
【0034】
(
図7:ステップS106〜S107)
スケジューリング部123は、スケジューリングテーブル1231が記述している終了時刻においてスケジューリング部123が動作開始するように、タイマ223をセットする(S106)。スケジューリング部123は、タスク状態管理部124を介して、現在のスロットに割り当てられたタスクを実行状態へ遷移させる(S107)。スロットにタスクが割り当てられていない場合には、そのスロットではタスクを動作させない。スケジューリング部123は以上のステップにしたがって、決められたスロット時間内でタスクを実行する。
【0035】
図8は、タスクの動作手順を説明するフローチャートである。本フローチャートは各タスクが共通的に実施する動作を説明する。タスクは、当該タスクの内容(内部処理と呼ぶ)を実行する(S801)。タスクは現タイムスロットにおける処理を実行完了すると、スケジューリング部123が参照することができる実行完了フラグを立ち上げる(S802)。タスクは、自身に割り当てられたセマフォなどの排他制御機構のキューに入り、待機状態に遷移する(S803)。スケジューリング部123は、タスクの排他制御機構を解放することにより、当該タスクを実行可能状態へ遷移させるとともに、当該タスクの実行完了フラグを立ち下げる(S804)。これに代えて当該タスクが次のタイムスロット開始時において前の実行完了フラグを立ち下げてもよい。タスクは車両制御装置100が停止するまで、以上の処理を繰り返す(S805)。
【0036】
図9は、スロット分類テーブル1311の例である。スロット分類管理部131は、スロット分類テーブル1311に各スロットのスロット分類を記述することによりこれを管理する。スロット分類テーブル1311はデータフィールドとして、スロットID、タスクID、スロット分類を有する。スロット分類は各スロットに割り当てられている。例えば各タスクの安全要求レベルに対応するスロット分類を各スロットに割り当てることができる。ここでは2種類の分類(ASILとQM)を例示した。以下の説明においてもこの分類を用いる。
【0037】
図10は、スロット分類通知部132の動作を説明するフローチャートである。スロット分類通知部132は、スロット時間が開始するときスロットIDを次スロットのIDに更新する(S1001)。スロット分類通知部132は、スロット分類管理部131を介して、現在のスロットIDに対応するスロット分類を取得する(S1002)。スロット分類通知部132は、取得したスロット分類を保護適用判定部122へ通知する(S1003)。
【0038】
図11は、保護適用判定部122の動作を説明するフローチャートである。タスクから共有データ管理部140に対する書込アクセス要求があった場合、保護適用判定部122はスロット分類通知部132から現スロットのスロット分類を受信する(S1101)。保護適用判定部122は、スロット分類がQMであるか否かを判定する(S1102)。スロット分類がQMであれば保護適用が必要であり(S1103)、それ以外であれば保護適用は不要である(S1104)。保護適用判定部122は判定結果をデータアクセス制御部121へ通知する(S1105)。
【0039】
図12は、データアクセス制御部121の動作を説明するフローチャートである。タスクから共有データ管理部140に対する書込アクセス要求があった場合、データアクセス制御部121は保護適用判定部122から判定結果を受信し(S1201)、保護適用要否を判定する(S1202)。データアクセス制御部121は、保護適用が必要であれば保護通信データ部143に対してデータを書き込み(S1203)、保護適用が不要であれば共有データ部141に対してデータを書き込む(S1204)。
【0040】
図13は、妥当性検証部142の動作を説明するフローチャートである。保護通信データ部143へデータが書き込まれた場合、妥当性検証部142は保護通信データ部143に対して書き込まれたデータの妥当性を検証する(S1301)。ここでいう妥当性チェックは例えば、(a)データが想定されている範囲内に収まっているか否かをチェックする、(b)パリティチェックなどの妥当性検証手段を用いる、などのことである。その他適当な妥当性検証を実施することもできる。妥当性検証部142は、データが正常であれば共有データ部141へそのデータを書き込む(S1302)。データが異常であればそのデータを削除し(S1303)、現在スロットの異常通信フラグをONにする(S1304)。
【0041】
<実施の形態1:まとめ>
本実施形態1に係る車両制御装置100は、安全要求レベルが高い第2タスク112(ASIL)を実行する際には共有データ部141に対してデータを書き込み、安全要求レベルが低い第1タスク111(QM)を実行する際には保護通信データ部143に対してデータを書き込む。妥当性検証部142は、保護通信データ部143に対して書き込まれたデータを検証した上で、共有データ部141に移行する。これにより、第2タスク112については遅延を防止しつつ、第1タスク111についてはデータの正常性を維持し、リアルタイム性とデータ正常性を両立することができる。
【0042】
<実施の形態2:車両制御装置の構成>
図14は、本発明の実施形態2に係る車両制御装置100の詳細を説明する図である。本実施形態2においては、タスクの信頼性を判断し、信頼できるタスクについては妥当性チェックを実施しないこととする。妥当性検証部142/スロット分類管理部131/スロット分類通知部132/保護適用判定部122以外の動作は実施形態1と同様であるので、以下では主に差異点について説明する。
【0043】
図15は、信頼度テーブル1312の例である。スロット分類管理部131は、スロット分類テーブル1311に加えて信頼度テーブル1312を保持する。信頼度テーブル1312は各タスクの信頼度を管理するデータテーブルであり、データフィールドとしてタスクID、信頼度カウンタ、信頼フラグを有する。信頼度カウンタの初期値は0であり、後述するフローチャートによってカウント値が変化する。信頼フラグは各タスクの現在の信頼度レベルを表す。QMタスクの初期値は「評価実施中」、ASILタスクの初期値は「信頼」である。
【0044】
図16は、妥当性検証部142の動作を説明するフローチャートである。ステップS1601、S1602、S1604は、ステップS1301〜S1303とそれぞれ同じである。妥当性検証部142はステップS1602に続いて、現在スロットの正常通信フラグをONにする(S1603)。妥当性検証部142はステップS1604に続いて、現在スロットの異常通信フラグをONにする(S1605)。
【0045】
図17は、スロット分類管理部131の動作を説明するフローチャートである。スロット分類管理部131は、スロット終端において本フローチャートを開始し、妥当性検証部142による検証結果を利用してタスクの信頼度を管理する。以下
図17の各ステップについて説明する。
【0046】
(
図17:ステップS1701)
スロット分類管理部131は、現在のスロットの信頼フラグが「非信頼」である場合は、信頼度カウンタを更新せずステップS1709へスキップする。それ以外であればステップS1702以降を実施する。
【0047】
(
図17:ステップS1702〜S1704)
スロット分類管理部131は、現在の異常通信フラグがONであれば(S1702)、現在のスロットの信頼フラグを「非信頼」にセットし(S1703)、信頼度カウンタをリセットする(S1704)。現在の異常通信フラグがOFFであればステップS1705へ進む。
【0048】
(
図17:ステップS1705〜S1708)
スロット分類管理部131は、現在の正常通信フラグがONであれば(S1705)、信頼度カウンタを1つインクリメントし(S1706)、信頼度カウンタが規定値以上に達すれば(S1707)、信頼フラグを「信頼」にセットする(S1708)。現在の正常通信フラグがOFFであるか、または信頼度カウンタが規定値未満であれば、ステップS1709へスキップする。
【0049】
(
図17:ステップS1709)
スロット分類管理部131は、信頼フラグと信頼度カウンタをセットした後、妥当性検証部142が立ち上げた異常通信フラグと正常通信フラグをOFFにする。
【0050】
図18は、スロット分類通知部132の動作を説明するフローチャートである。スロット分類通知部132は、スロットIDを現在値に更新した後(S1801)、現スロットのスロット分類(S1802)と信頼フラグ(S1803)をスロット分類管理部109から取得する。スロット分類通知部132は、取得したスロット分類(S1804)と信頼フラグ(S1805)を保護適用判定部122へ通知する。
【0051】
図19は、保護適用判定部122の動作を説明するフローチャートである。保護適用判定部122は、スロット分類通知部132から現スロットのスロット分類と信頼フラグを受信する(S1901)。スロット分類がQMかつ信頼フラグが「信頼」以外の場合、保護適用が必要と判定する(S1902、S1903、S1904)。スロット分類がQM以外もしくは信頼フラグが「信頼」の場合、保護適用は不要と判定する(S1902、S1903、S1905)。保護適用判定部122は、判定結果をデータアクセス制御部105へ通知する(S1906)。
【0052】
<実施の形態2:まとめ>
本実施形態2に係る車両制御装置100は、安全要求レベルが低い第1タスク111(QM)を実施する際には、信頼フラグによりその信頼度を判定し、信頼できる場合は妥当性チェックを省略する。また安全要求レベルが高い第2タスク112(ASIL)については、実施形態1と同様に信頼度によらず妥当性チェックを省略する。これにより、安全性を確保しつつ実行時間を確保することができる。
【0053】
本実施形態2においては、スロット分類がASILであるタスク(第2タスク112)については妥当性チェックを省略することとしたが、ASILタスクのうち全部または一部については妥当性チェックの対象としてもよい。例えば、ステップS1902において保護適用不要とみなす閾値レベルを、ASIL−Dよりも高くすることにより、全てのASILタスクおよびQMタスクがステップS1903を経由することになる。すなわち信頼度カウンタによりタスクの信頼度を判定することになる。
【0054】
<実施の形態3>
図20は、動作ログ151の例である。動作ログ管理部150は、後述するフローチャートにしたがって各タスクの動作ログ151を記録する。動作ログ151はデータフィールドとして、開始時刻、終了時刻、タスクID、終了時の状態、を有する。動作ログ151を記録することにより、各時刻におけるタスクの状態を確認することができる。また、異常なデータ通信を試みたタスクを発見することができる。特に終了時の状態を記録しておくことにより、タスクが正常に動作しているか、時間違反が発生したことによる強制終了か、異常通信を発生させたか、などを確認することができる。
【0055】
図21は、動作ログ管理部150の動作を説明するフローチャートである。動作ログ管理部150は、各タイムスロットにおいてタスクの開始時刻/終了時刻/タスクIDを取得する(S2101)。動作ログ管理部150は、タスクの終了時の状態を取得する(S2102)。動作ログ管理部150は、取得した各情報を動作ログ151として出力する(S2103)。
【0056】
<実施の形態4>
スケジューリングテーブル1231、スロット分類テーブル1311、信頼度テーブル1312は、自動生成することもできる。例えば各タスクの周期や最悪実行時間などの設計データにしたがって、スケジューリングテーブル1231を自動生成することが考えられる。さらに、生成したスケジューリングテーブル1231を各タスクの安全要求レベルを用いて、スロット分類テーブル1311を自動生成することができる。信頼度テーブル1312は、各タスクの安全要求レベルから自動生成することができる。
【0057】
各テーブルの自動生成は、例えば車両制御装置100に搭載するプログラムを開発するための開発ツールの機能として実装することができる。これにより、各タスクの保護適用要否を考慮することなくプログラムを開発できるので、開発効率向上に資する。
【0058】
<本発明の変形例について>
本発明は上記実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換える事が可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について他の構成の追加・削除・置換をすることができる。
【0059】
以上の実施形態において、車両制御装置100の構成について説明したが、時間駆動スケジューリングによってタスクを実行するその他の制御システムにおいても、本発明と同様の手法を用いることができる。
【0060】
以上の実施形態において、スロット分類としてQMとASILを説明したが、スロット分類はこれに限られるものではない。例えばQMとASILに代えてまたはこれらに加えて、他社開発アプリケーション/自社開発アプリケーション、非安全タスク/安全タスク、などのスロット分類を用いてもよい。
【0061】
実施形態4において、タスクの安全要求レベルに応じてテーブルを自動生成することを説明したが、スロット分類と同様に、その他の情報を用いてテーブルを自動生成してもよい。例えば他社開発アプリケーション/自社開発アプリケーションの区分に応じて、スロット分類テーブル1311を自動生成することが考えられる。