特許 7409567 自動車用コンピュータの制御方法、及び車両用電子制御装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-25

(45)【発行日】2024-01-09

(54)【発明の名称】自動車用コンピュータの制御方法、及び車両用電子制御装置

(51)【国際特許分類】

   B60R 16/02 20060101AFI20231226BHJP

   G06F 9/48 20060101ALI20231226BHJP

【ＦＩ】

B60R16/02 660X

G06F9/48 300B

【請求項の数】 11

(21)【出願番号】P 2023533039

(86)(22)【出願日】2021-12-09

(86)【国際出願番号】 JP2021045351

(87)【国際公開番号】W WO2023281766

(87)【国際公開日】2023-01-12

【審査請求日】2023-02-20

(31)【優先権主張番号】P 2021114366

(32)【優先日】2021-07-09

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【識別番号】110000578

【氏名又は名称】名古屋国際弁理士法人

(72)【発明者】

【氏名】今井 宏治

【審査官】佐々木 智洋

(56)【参考文献】

【文献】特開２０１３－００３７２４（ＪＰ，Ａ）

【文献】特開２００８－１２３４３９（ＪＰ，Ａ）

【文献】特開２０１４－０８１８４７（ＪＰ，Ａ）

【文献】特開２０１４－１７０４７７（ＪＰ，Ａ）

【文献】特開２０１６－１５７２４７（ＪＰ，Ａ）

【文献】特開２０１６－１８１８６８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｂ６０Ｒ １６／０２

Ｇ０６Ｆ ９／４８

(57)【特許請求の範囲】

【請求項1】

車両の安全に関する値であって前記車両の加減速、操舵に関する値を演算するスレッドを表す少なくとも１つの機能安全スレッド、及び前記機能安全スレッドを除くスレッドを表す少なくとも１つの非機能安全スレッド、を予めスケジューラで定義された優先順位に基づく並列処理で実行可能な車両用コンピュータ（１１）にて実行される自動車用コンピュータの制御方法であって、
前記機能安全スレッドの異常を検知し、
前記機能安全スレッドの異常が検知された場合に、前記スケジューラを変更して前記優先順位を変更する
自動車用コンピュータの制御方法。

【請求項2】

請求項１に記載の自動車用コンピュータの制御方法であって、
前記異常が検知されてから当該車両に危険事象が発生するまでの推定時間をＦＴＴＩ（Fault Tolelant Time Interval）として、前記異常が検知された場合、前記ＦＴＴＩ内は、前記機能安全スレッドの実行優先順位を前記非機能安全スレッドの実行優先順位よりも相対的に高くするスケジュールの変更を行う
自動車用コンピュータの制御方法。

【請求項3】

請求項１又は請求項２に記載の自動車用コンピュータの制御方法であって、
前記異常が検知された場合、予め設定された異常処置が完了するまで、前記非機能安全スレッドの実行を中断する
自動車用コンピュータの制御方法。

【請求項4】

請求項２に記載の自動車用コンピュータの制御方法であって、
カーネルの割り込み制御を使用し、前記機能安全スレッドの異常の有無を検出して、前記異常が検知された場合に、前記スケジュールを変更する
自動車用コンピュータの制御方法。

【請求項5】

請求項４に記載の自動車用コンピュータの制御方法であって、
前記機能安全スレッドの異常が検出されているか否かを診断する機能安全機構をスレッドとして実装し、前記異常が検出されているか否かに応じて前記スケジューラの変更の要否を判定し、前記スケジューラの切り替えを行う
自動車用コンピュータの制御方法。

【請求項6】

請求項４又は請求項５に記載の自動車用コンピュータの制御方法であって、
少なくとも前記カーネルの割り込み制御にて実施される割込スレッドには、実行すべき指示を受けてから当該スレッドが実行されるまでの時間の上限を表す限界待ち時間が設定されており、
前記割込スレッドの限界待ち時間は、前記ＦＴＴＩ未満になるように設定される
自動車用コンピュータの制御方法。

【請求項7】

請求項６に記載の自動車用コンピュータの制御方法であって、
前記割込スレッド、前記機能安全スレッド、及び前記非機能安全スレッドには、前記限界待ち時間が設定されており、
前記割込スレッドが実行されるまでの時間が、前記割込スレッド以外の他のスレッドの限界待ち時間が超過した場合、当該他のスレッドに対応するシステムを縮退させる
自動車用コンピュータの制御方法。

【請求項8】

請求項６又は請求項７に記載の自動車用コンピュータの制御方法であって、
複数の機能安全スレッドにおいて異常を検知し、
前記異常を検知したスレッド毎に、前記割込スレッドを実行し、この際、限界待ち時間に対する残り時間が小さい順に、前記割込スレッドの実行優先順位を高する様にスケジューラの内容を変更する
自動車用コンピュータの制御方法。

【請求項9】

請求項６から請求項８の何れか１項に記載の自動車用コンピュータの制御方法であって、
前記割込スレッド毎に自動車安全水準レベルが対応付けられており、
複数の機能安全スレッドにおいて異常を検知し、
前記異常を検知したスレッド毎に、前記割込スレッドを実行し、この際、前記自動車安全水準レベルが高い順に、前記割込スレッドの実行優先順位を高する様にスケジューラの内容を変更する
自動車用コンピュータの制御方法。

【請求項10】

車両の安全に関する値であって前記車両の加減速、操舵に関する値を演算するスレッドを表す少なくとも１つの機能安全スレッド、及び前記機能安全スレッドを除くスレッドを表す少なくとも１つの非機能安全スレッド、を予めスケジューラで定義された優先順位に基づく並列処理で実行可能な車両用電子制御装置（１０）であって、
前記機能安全スレッドの異常を検知するように構成された異常検知部（Ｓ１３０，Ｓ１５０，Ｓ１７０）と、
前記機能安全スレッドの異常が検知された場合に、前記スケジューラを変更して前記優先順位を変更する順序変更部（Ｓ１０，Ｓ２０，Ｓ３０，Ｓ１８０）と、を備える
車両用電子制御装置。

【請求項11】

請求項１０に記載の車両用電子制御装置（１０）であって、
前記順序変更部は、前記異常が検知されてから当該車両に危険事象が発生するまでの推定時間をＦＴＴＩ（Fault Tolelant Time Interval）として、前記異常が検知された場合、前記ＦＴＴＩ内は、前記機能安全スレッドの実行優先順位を前記非機能安全スレッドの実行優先順位よりも相対的に高くするスケジュールの変更を行うように構成された
車両用電子制御装置。

【発明の詳細な説明】

【関連出願の相互参照】

【0001】

本国際出願は、２０２１年７月９日に日本国特許庁に出願された日本国特許出願第２０２１－１１４３６６号に基づく優先権を主張するものであり、日本国特許出願第２０２１－１１４３６６号の全内容を本国際出願に参照により援用する。

【技術分野】

【0002】

本開示は、自動車用コンピュータの制御方法、及び車両用電子制御装置に関する。

【背景技術】

【0003】

下記特許文献１には、実行中のプログラムに異常が生じたか否かを判定し、プログラムに異常が生じた場合に、プログラムの処理順序を、通常制御スケジューリングパターンから安全制御スケジューリングパターンに切り替える車両用電子制御装置が開示されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特許第５４４６４７７号公報

【発明の概要】

【0005】

特許文献１では、安全監視プログラムで通常制御プログラムを含むプログラムの異常が検出されるが、異常を検出した後は、スケジュールが安全制御スケジューリングパターンへ切替られる。しかし、切り替え後のプログラムの実行の元となるタイムパーテションされたプログラムには、通常制御プログラムの監視を実行するスレッドは含まれるが、本来機能を実行するスレッド（例えば非機能安全要件）は、含まれていないと推察される。この結果、安全制御スケジュールパターンへ切替後は、異常が発生していない本来機能も含めて、全て縮退制御していると推察される。

【0006】

発明者の詳細な検討の結果、この構成では、安全制御を優先して実行できるものの、安全制御スケジュールで非優先となるスレッドが長時間完了できないなど、非優先となるスレッド、特に非機能安全要件のスレッドへの悪影響が生じやすいという課題が見出された。

【0007】

より詳細には、上記特許文献１の技術は、安全監視プログラムで、異常が検出されたときに、非機能安全要件のスレッドと機能安全要件のスレッドをパーテショニングする。そして、機能安全対応設計を機能安全スレッドのみに注力することにより、システム設計のコストダウンを狙っている。反面、安全制御スケジューリングパターンに切り替えられた後の非機能安全スレッドのリアルタイム性については、言及されていない。また、上記特許文献１の請求項１には、安全制御スケジューリングパターンへ移行した後のタイムパーテションでは、通常制御プログラムを除くと記載されているので、極論すれば、非機能安全要件のスレッドはすべて縮退処理となるとも解釈できる。

【0008】

本開示の１つの局面は、全てのスレッドが規定時間内に実行されやすいスレッド自動車用コンピュータの制御方法、或いは車両用電子制御装置を提供できるようにすることにある。

【0009】

本開示の一態様は、機能安全スレッド、及び少なくとも１つの非機能安全スレッド、を予めスケジューラで定義された優先順位に基づく並列処理で実行可能な車両用コンピュータにて実行される自動車用コンピュータの制御方法である。機能安全スレッドは、車両の安全に関する値を演算するスレッドを表す。また、非機能安全スレッドは、機能安全スレッドを除くスレッドを表す。

【0010】

自動車用コンピュータの制御方法では、機能安全スレッドの異常を検知し、機能安全スレッドの異常が検知された場合に、スケジューラを変更して優先順位を変更する。

【0011】

このような制御方法によれば、機能安全スレッドに異常が生じた場合だけ、スレッドを実行する際の優先順位を変更できる。機能安全スレッドの安全機構が異常を検出して異常処置を実行するスレッドが他のスレッドが実行中のため実行待ちになっていても、両スレッドの相対的実行優先順位を変更して、機能安全の安全を担保する許容時間内に処理を完了しやすくすることができる。かつ、非機能安全スレッドについても本来機能を縮退させる機会を極力減らすことができる。

【0012】

つまり、スケジューラを変更して異常検出時のスケジュールに切り替える場合、機能安全要件のスレッドの規定の処理を実行後に非機能安全要件の規定の処理の実行を許容するので、非機能安全要件の不要な縮退を避けるスケジューリングが可能となる。よって、全てのスレッドが規定時間内に実行されやすい構成とすることができる。

【図面の簡単な説明】

【0013】

【図1】車両制御システムの構成を示すブロック図である。

【図2】制御演算部の機能ブロック図である。

【図3】スレッド実行制御処理のフローチャートである。

【図4A】スレッド実行優先順位判定処理の前半部分のフローチャートである。

【図4B】スレッド実行優先順位判定処理の後半部分のフローチャートである。

【図5】優先順位ルールの一例を示す説明図である。

【図6】第１作動例を示すタイミングチャートである。

【図7】第２作動例を示すタイミングチャートである。

【図8A】正常時スケジューラ実行処理の前半部分のフローチャートである。

【図8B】正常時スケジューラ実行処理の後半部分のフローチャートである。

【図9A】異常時スケジューラ実行処理の前半部分のフローチャートである。

【図9B】異常時スケジューラ実行処理の後半部分のフローチャートである。

【図10A】異常時スケジューラＡＮ［１］実行処理の前半部分のフローチャートである。

【図10B】異常時スケジューラＡＮ［１］実行処理の後半部分のフローチャートである。

【図11A】異常時スケジューラＡＮ［２］実行処理の前半部分のフローチャートである。

【図11B】異常時スケジューラＡＮ［２］実行処理の後半部分のフローチャートである。

【発明を実施するための形態】

【0014】

［１．本開示の概要］
［１－１．背景］
ＣＡＳＥ（Connected、Autonomous、Shared & Services、Electric）、Ｍａａｓ（Mobility as a Service）社会においては、機能安全、セキュリティ、ＳＯＴＩＦ（Safety of the Intended Functionality）等の諸要件が三つ巴になったより複雑なシステムの中で、諸要件の相互作用や排他的制御を考慮する必要がある。その際、システムの機能安全を第１に、性能や利便やコストとのバランスを考え、商品性を向上するアーキテクチャを設計することが、システム・製品の差別化を考えるうえで有意義である。

【0015】

特に、ＯＴＡ（Over The Air）や５Ｇ技術を活用した拡張性のある、つながるシステムが存在する。つながるシステムでは、車両に実装したソフトウェアがＳＯＰ(Start Of Production;量産の開始)時点と、ＳＯＰ後のライフサイクルの間に、システムに搭載されるアプリケーションが逐次変化して行くことが予測される。その変化の都度、例えば当初実装されたソフトウェアに更新プログラムを充てる都度、プログラムの実行検証をベースからやり直すのは、非効率で経済的ではない。また、セキュリティインシデント対策を考慮したソフトウェアライフサイクルにおいては、この傾向がより顕著となることが予測される。

【0016】

さらに、車両においても、今後は、非論理的と言われるＡＩも多く実装される。一旦、システム異常が発生した時の論理性と論証を重視される機能安全の担保は、システム異常や構成部品故障、セキュリティインシデント又は性能限界、或いは、ミスユースにおいてもロバスト性の高いシステムアーキテクチャを要求される。

【0017】

［１－２．機能安全エレメント実装上の課題］
今後も、車両に実装されるいろいろなアプリケーションでは、ドメイン化（例えば、分散化）と統合化とが車両のセグメント毎に最適化されるようにトライされると思われる。この際、統合化されたアプリケーションをプロセスに分割し、最終的には、ＣＰＵコア（以下、単にコアともいう）やメモリ或いは入出力群を共有化するスレッドを疑似並列的にスケジュール制御するニーズは不可欠である。この様子は、ＰＣソフトウェアに実装されるＯＳのタスクマネージャの制御に類似している。

【0018】

機能安全エレメントの実装の場合は、車両機能（以下、アイテム）に対して、その機能を実現するための構成要素（以下、エレメント）に異常が発生したとき、安全目標（ＳＧ：Safety Goal）を設定する。そして、安全機構（ＳＭ:Safety Mechanism）を付加し、許容された時間（ＦＴＴＩ：Fault Tolelant Time Interval）以内に安全目標を、機能安全以外のエレメントと無干渉になることを担保して実行させる。この手順は、セキュリティやＳＯＴＩＦが要求されたシステムでも例外ではなく実施されうる。本開示では、機能安全のＳＭの実行を担保するため、ＣＰＵコアを共有する他のスレッドのコア処理が競合する場合においても、動的スケジューリングの設計手法を活用し、機能安全のＳＭの実行を担保する設計アーキテクチャを提供する。

【0019】

［１－３．本開示でのアーキテクチャ採用の効果］
一方、従来のソフトスケジューリングにおいては、タイムトリガ制御（例えば周期制御を含む）、或いは各スレッドをパーテションし、カーネル特権による割り込み制御が行われるのが一般的である。いずれの場合も機能安全の安全要求仕様（例えば、ＦＴＴＩ等）と直接的に関連付けられたスケジューリングをディスパッチするわけではない。

【0020】

一般的な自動車用のソフトウェアのプロセスでは、想定されたアプリケーションの内部の動作状態がスレッドレベルまで、カバレッジされて検証し、有害なバグのない状態で、ＳＯＰ時に実装されてリリースする。また、一般的な機能安全エレメントの組込実装では、ソフトウェアの継続に深刻なランタイムエラーが発生した時のみ冗長な他のデバイスからのリセット制御を期待する（例えば、ウォッチドッグリセット）。そして、その他のアプリケーションプログラムの機能上の診断異常（例えば、センサ、負荷、内部機能構成パーツのダイアグ診断）では、各タスクのワースト実行時間や実行周期の組合せを考慮したタスクスケジュール設計をする。タスクスケジュール設計には、例えば、プライオリティ設定、デッドライン監視等が含まれる。

【0021】

この場合は、前述のように、ＳＯＰ後に、当初想定していなかったシステムにつながるアプリケーションが当初設計したタイムスケジュールに影響があるかどうかを、仕様変化点の都度チェックする。このため、必要により、アーキテクチャ自体に設計変更をかける必要性が発生する。また、この可能性を極力回避するために、システムの異常時にはより安全側に振った仕様が採用され、この結果、車両として過度に縮退制御が多くなり商品性が低下する懸念もある。

【0022】

そこで、本開示では、ＳＯＰ後に、想定されていなかった事象が、車両とつながる世界から入ってきた不測の場合においても、システムの異常時には、機能安全の安全機構（ＳＭ）の処理を優先するアーキテクチャを提供する。想定されていなかった事象には、当初想定されていなかったアプリケーション追加又は商品の売り手側も想定していないエンドユーザによるアプリケーション接続やインシデント発生が含まれる。また、想定外の外乱（例えば、ネットワーク異常、ＡＩモジュールのデッドロック等）が含まれる。

【0023】

本開示のアーキテクチャによれば、ＯＴＡで変更されたソフトウェアプログラムの設計変更や検証を簡単にすることができる。また、システム異常時の機能安全担保のための安全要求仕様として車両の縮退制御を緩めることにより、商品性が向上する効果が期待できる。また、ベース開発で、経験度の高い設計者がアーキテクチャを確立しておけば、以降のソフトウェアの保守は比較的経験度の浅い設計者において容易に信頼度の高いブランチ開発が可能となるメリットがある。この結果、より再利用性が高くロバスト性の高いソフトウェアライフサイクルが省工数で構築できる。

【0024】

［２．実施形態の構成と本開示の構成との対応関係］
実施形態において、制御演算部１１が実行する処理は、本開示での自動車用コンピュータの制御方法に相当する。また、実施形態において、制御演算部１１が実行する処理のうち、Ｓ１３０，Ｓ１５０，Ｓ１７０の処理は、本開示での異常検知部による機能に相当し、Ｓ１０，Ｓ２０，Ｓ３０，Ｓ１８０の処理は、本開示での順序変更部による機能に相当する。

【0025】

［３．実施形態］
以下、図面を参照しながら、本開示の実施形態を説明する。

【0026】

［３－１．構成］
図１に示す車両制御システム１は、例えば乗用車等の車両に搭載され、ＥＣＵ１０を備える。ＥＣＵ１０は、電子制御装置であり、特に、本実施形態では車両用の電子制御装置である。

【0027】

車両制御システム１は、センサ類２１、各種アクチュエータ２２を備えてもよい。また、車両制御システム１は、車両外のクラウドサーバ２３と通信可能に構成されてもよい。ＥＣＵ１０、センサ類２１、各種アクチュエータ２２、クラウドサーバ２３は、通信バス５或いは図示しない無線ネットワーク等を介して互いに通信可能に構成される。なおＥＣＵ１０には、後述する電源回路及びウォッチドッグタイマ３６が含まれる。

【0028】

ＥＣＵ１０は、制御演算部１１と、入出力部１２と、メモリ１３と、を備える。また、ＥＣＵ１０は、制御演算部１１が実行する機能の一部として、車両アプリケーション機能１６を備える。なお、車両アプリケーション機能１６を実現するプログラムの中では、非機能安全機能要件と機能安全機能要件とに従い関連するスレッドがパーテションされる。

【0029】

制御演算部１１は、例えば、ＣＰＵとして構成される。制御演算部１１は、メモリ１３に格納されたプログラムを実行することで、車両アプリケーション機能１６等の各種機能を実現する。制御演算部１１が実行する各種機能には、自動車用コンピュータの制御方法を利用する処理が含まれる。制御演算部１１は、疑似並列処理で、複数のスレッドを時分割で実施する。以下、複数のスレッドをスレッド群と表記する。

【0030】

なお、制御演算部１１は、異常検知、異常検知に対応して安全を担保するための異常処置、スレッド自体のランタイムエラー検知、ランタイムエラー検知に対応するための異常処置等、各機能を実現するための演算を実施する。

【0031】

入出力部１２は、例えば、通信バス５等を用いた通信を行う通信モジュールとして構成され、ＥＣＵ１０に入出力されるデータについての入出力制御を行う。

【0032】

車両アプリケーション機能１６は、図２に示すように、コア間制御スレッド制御部３２、コア内制御スレッド制御部（機能安全要件）３３（以下、機能要件部３３という）、コア内制御スレッド制御部（非機能安全要件）３４（以下、非機能要件部３４という）とを備える。

【0033】

コア間制御スレッド制御部３２は、下記機能を備える。すなわち、
（Ａ１）コア、メモリ１３、入出力部１２、ランタイムをディスパッチする機能、詳細には、動的スケジューラとしての機能（例えば、ＭＭＵ／ＭＰＵと連携してスレッド制御を行う場合もある）、
（Ａ２）各コアプログラム（例えばアプリケーション）により実行するスレッドを調停する機能、詳細には、コアプログラムの起動、縮退、無視、自己リセット、外部リセット等の処理を含む、
（Ａ３）電源回路及びウォッチドッグタイマ３６に対してウォッチドック信号を出力する機能、
（Ａ４）機能要件部３３及び非機能要件部３４に対してリソース、スケジュールの配分指示を行う機能、
を備える。

【0034】

上記コア間制御スレッド制御部３２の各機能は、ＥＣＵ１０がプログラムを実行することによって実現される。

【0035】

次に、機能要件部３３は、機能安全要件に関するスレッド（以下、機能安全スレッド）を取り扱う。機能安全スレッドとは、車両の安全に関する値（例えば、車両の加減速、操舵に関する値等）を演算するスレッドを表す。

【0036】

機能要件部３３は、下記機能を備える。すなわち、
（Ｂ１）メモリ１３、入出力部１２、ランタイムをディスパッチする機能、詳細には、動的スケジューラとしての機能（例えば、ＭＭＵ／ＭＰＵと連携してスレッド制御を行う場合もある）、
（Ｂ２）異常が発生したスレッドの実行優先順位を相対的に上げるようにスケジューラを変更する機能、
（Ｂ３）コア間制御スレッド制御部３２に対して、コア占有時間率、安全機構要件、 ＦＴＴＩ、自動車安全水準レベル（以下、ＡＳＩＬ：Automotive Safety Integrity Level）、デッドライン情報等の実行優先順位を制御する情報源を送信する機能、
を備える。

【0037】

上記機能要件部３３の各機能は、ＥＣＵ１０がプログラムを実行することによって実現される。

【0038】

次に、非機能要件部３４は、機能安全スレッド以外のスレッドである非機能安全スレッドを取り扱う。非機能要件部３４は、下記機能を備える。すなわち、
（Ｃ１）メモリ１３、入出力部１２、ランタイムをディスパッチする機能、詳細には、動的スケジューラとしての機能（例えば、ＭＭＵ／ＭＰＵと連携してスレッド制御を行う場合もある）、
（Ｃ２）実行中のスレッドの中断や実行待ちスレッドの実行優先順位を相対的に下げるようにスケジューラを変更する機能、
（Ｃ３）コア間制御スレッド制御部３２に対して、コア占有時間率等の実行優先順位を制御する情報源を送信する機能、
を備える。

【0039】

上記非機能要件部３４の各機能は、ＥＣＵ１０がプログラムを実行することによって実現される。

【0040】

なお、コア間制御スレッド制御部３２、機能要件部３３、非機能要件部３４は、スレッドの実行継続が機能安全の安全目標（ＳＧ）の侵害につながるような異常が生じた際に実行継続不可通知を送信し、実行継続不可通知はそれぞれで共有される。

【0041】

［３－２．処理］
［３－２－１．スレッド実行制御処理］
次に、制御演算部１１、特にコア間制御スレッド制御部３２が実行するスレッド実行制御処理について、図３のフローチャートを用いて説明する。スレッド実行制御処理は、機能要件部３３及び非機能要件部３４のそれぞれで設定されたスレッド実行優先順位テーブルを取得し、これらのテーブルに基づく順序で処理を実行させる処理である。スレッド実行制御処理は、例えば、予め設定された周期で実施される。

【0042】

スレッド実行制御処理では、まず、Ｓ１０で、制御演算部１１は、機能要件部３３で判定及び書き替えられたスレッド実行優先順位テーブルの取り込みをする。スレッド実行優先順位テーブルは、図５にて示す優先順位ルールで設定される。なお、優先順位ルールについては後述する。

【0043】

続いて、Ｓ２０で、制御演算部１１は、非機能要件部３４で判定及び書き替えられたスレッド実行優先順位テーブルの取り込みをする。続いて、Ｓ３０で、制御演算部１１は、コア間制御スレッド制御部３２の機能を用いて、実行するスレッドのコアと動的スケジューラのディスパッチ内容更新、及び各コアプログラム（例えばアプリケーション）で実行するスレッドの調停をする。

【0044】

ディスパッチ内容更新では、制御演算部１１は、各コアのスレッド実行情報に基づき、各コアで選択された動的スケジューラに対して、使用するハードウェア資源（例えば、コア、メモリ１３、入出力部１２、ランタイム）の割り当ての見直しを行う。なお、コア間制御スレッド制御部３２の機能は、一般的なパーソナルコンピュータでいうところのタスクマネージャのような役割を担う。

【0045】

また、スレッドの調停では、制御演算部１１は、コア稼働率の低いコアの有効活用等を実施する。また、制御演算部１１は、各コアの異なるプログラム間で共有するメモリ１３や入出力部１２が競合しないように、無干渉を担保する。詳細には、制御演算部１１は、各コアの動的スケジューラと連携して、メモリ１３、読み書き属性、ランタイム等を調停する。

【0046】

なお、制御演算部１１は、コアプログラムの起動、縮退、無視、自己リセット、外部リセット等の処理を実施する。その後、図３のスレッド実行制御処理を終了する。

【0047】

［３－２－２．スレッド実行制御処理］
次に、制御演算部１１が実行するスレッド実行優先順位判定処理について、図４Ａ及び図４Ｂのフローチャートを用いて説明する。スレッド実行優先順位判定処理は、機能要件部３３及び非機能要件部３４の機能を用いて、機能安全スレッドの異常の有無に応じて適切なスケジュールを選択し、コア間制御スレッド制御部３２に、選択したスケジュールを利用するように要求する処理である。スレッド実行制御処理は、例えば予め設定された周期毎に実施される。なお、制御演算部１１が備えるコアが複数の場合は、本処理はコアごとに実行される。また、本処理は、図５にて示す常時周期割り込みとして記載された機能安全（以下、常時ＳＭ）にて実行される。

【0048】

スレッド実行制御処理では、まず、Ｓ１１０で、制御演算部１１は、スケジューラタイマ割り込みで実行するスレッド群の実行待ちはあるか否かを判定する。スケジューラタイマ割り込みには、機能安全スレッドに異常が検知された場合に実施されることが含まれる。機能安全スレッドの異常とは、機能安全スレッドの機能の異常検出だけでなく、例えば、機能安全スレッドが規定時間（すなわち、デッドライン）以内に正常に終了しない事象、実行エラーを生じる事象等が該当する。

【0049】

制御演算部１１は、Ｓ１１０で割り込みのスレッド群の実行待ちがないと判定した場合には、Ｓ１２０へ移行し、割り込みタイマ処理を実行した後、図４Ａ及び図４Ｂのスレッド実行優先順位判定処理を終了する。

【0050】

一方、制御演算部１１は、Ｓ１１０でスケジューラタイマ割り込みのスレッド群の実行待ちがあると判定した場合には、Ｓ１３０へ移行し、機能安全スレッドの異常が、スレッド群の実行を継続できない異常か否かを判定する。すなわち、機能安全の安全目標（以下、ＳＧ）を侵害するか否かを判定する。スレッド群の実行を継続できない異常か否かは、例えば、異常の種別が予めスレッド群の実行を継続できない異常に対応付けられているか否かによって判定される。

【0051】

制御演算部１１は、Ｓ１３０でスレッド群の実行を継続できない異常であると判定した場合には、Ｓ１４０へ移行し、コア間制御スレッド制御部３２へスレッド群の実行制御を要求し、システムの縮退制御を実施する。ここでは、例えば、カーネルの割り込み制御にて実施される機能安全スレッドであって、予め準備された割込スレッドを実施してもよい。このように機能安全を担保した後、図４Ａ及び図４Ｂのスレッド実行優先順位判定処理を終了する。

【0052】

一方、制御演算部１１は、Ｓ１３０でスレッド群の実行を継続できる異常あると判定した場合には、Ｓ１５０へ移行し、ＩＯポート等へのイベント割り込みのスレッド群の実行待ちがあるか否かを判定する。ここでのイベント割り込みには、ハードウェアでの強制割り込みを除く。

【0053】

制御演算部１１は、Ｓ１５０でイベント割り込みのスレッド群の実行待ちがあると判定した場合には、Ｓ１６０へ移行し、ソフトウェアマスカブルな強制割り込み処理した後、Ｓ１７０に移行する。

【0054】

一方、制御演算部１１は、Ｓ１５０でイベント割り込みのスレッド群の実行待ちがないと判定した場合には、Ｓ１６０をスキップしてＳ１７０へ移行する。続いて、Ｓ１７０で、制御演算部１１は、機能安全要件の異常を検知し、異常処置待ちであるか否かを判定する。異常処置待ちとは、異常の検知後に、異常に対する処置が完了されていない状態を表す。

【0055】

制御演算部１１は、Ｓ１７０で機能安全要件の異常を検出し、異常処置待ちであると判定した場合には、Ｓ１８０へ移行する。Ｓ１８０では、機能安全の安全機構要件の設定が、ＦＴＴＩに対する残り時間優先か、安全度レベル優先か、によって、実行待ちのスレッドの実行優先順位のスケジュールを変更する。つまり、後述する実行優先順位テーブルのうちの、異常時に対応するテーブルである、異常時ＡＮ、ＦＴＴＩ優先書き替えＡＮ［１］、ＡＳＩＬ優先書き替えＡＮ［２］の何れかが選択される。

【0056】

このスケジュールの変更では、非機能安全要件の一時中断と機能安全要件の異常処置について優先的に実行するよう要求される。この要求は、コア間制御スレッド制御部３２へスレッド群の実行制御を要求することで実現される。この要求によって、カーネルの割り込み制御が実施され、早期に機能安全スレッド（すなわち本開示での割込スレッド）が実施される。Ｓ１８０の後、図４Ａ及び図４Ｂのスレッド実行優先順位判定処理は終了する。

【0057】

一方、制御演算部１１は、Ｓ１７０で機能安全要件の異常検出でない、或いは機能安全要件の異常処置待ちでないと判定した場合には、Ｓ１９０へ移行する。Ｓ１９０では、機能安全の安全機構について、全て正常判定時のスケジュールを選択し、コア間制御スレッド制御部３２へスレッド群の実行制御を要求する。つまり、異常が発生していない場合、或いは、異常発生後の処置が終了した場合には、後述する実行優先順位テーブルのうちの、正常時に対応するテーブルである、正常時Ｎが選択される。

【0058】

続いて、Ｓ２００で、制御演算部１１は、非機能安全要件の異常を検出し、異常処置待ちであるか否かを判定する。制御演算部１１は、Ｓ２００で非機能安全要件の異常を検出していない、或いは非機能安全要件の異常処置待ちでないと判定した場合には、Ｓ２１０へ移行する。

【0059】

Ｓ２１０では、制御演算部１１は、非機能安全要件の処理をコア間制御スレッド制御部３２へスレッド群の実行制御を要求し、基本機能（例えば、前述した本来機能に相当）の処理継続を担保する。この際、処理順序は機能安全のスレッドの異常を検知していない場合と同様であるため、商品性の低下がない。Ｓ２１０の後、図４Ａ及び図４Ｂのスレッド実行優先順位判定処理は終了する。

【0060】

一方、制御演算部１１は、Ｓ２００で非機能安全要件の異常を検出し、異常処置待ちであると判定した場合には、Ｓ２２０へ移行し、非機能安全要件の異常処置についてコア間制御スレッド制御部３２へスレッド群の実行制御を要求する。その後、図４Ａ及び図４Ｂのスレッド実行優先順位判定処理は終了する。

【0061】

［３－２－３．優先順位ルール］
ここで、優先順位ルールについて図５を用いて説明する。優先順位ルールは、機能要件部３３及び非機能要件部３４が図４Ａ及び図４Ｂのスレッド実行優先順位判定処理で選択可能な複数のスケジュールと、スケジュール毎に各スレッドの実行優先順位との対応関係を示す。スケジュールについては、以下、スレッド実行優先順位テーブル、或いは単にテーブルともいう。

【0062】

複数のテーブルとして、例えば、正常時Ｎ、異常時ＡＮ、ＦＴＴＩ優先書き替えＡＮ［１］、ＡＳＩＬ優先書き替えＡＮ［２］が準備されている。これらのテーブルでは、初期診断スレッド、ソフトウェアマスカブルなハードウェア割り込みスレッド、実行周期割り込みスレッドの順で実行されるように実行優先順位が記載されている点が共通する。しかし、実行周期割り込みスレッド内には複数のスレッドが対応付けられており、実行周期割り込みスレッド内の各スレッドの実行優先順位がテーブル毎に異なるように設定される。

【0063】

例えば、機能安全スレッドに異常がない正常時には、「正常時Ｎ」と表記されたテーブルが選択される。このテーブルでは、アプリケーションスレッド層の非機能安全要件が対応付けられた、非機能安全スレッド０１，０２の優先順位が、機能安全要件が対応付けられた、機能安全スレッドｍ１，ｎ１，ｎ２の優先順位よりも高く設定される。

【0064】

また、機能安全スレッドに異常がある場合には、例えば、「異常時ＡＮ」と表記されたテーブルが選択される。このテーブルでは、機能安全スレッドｍ１，ｎ１，ｎ２の優先順位が非機能安全スレッド０１，０２の優先順位よりも高く設定される。

【0065】

その他、機能安全スレッドに異常がある場合には、状況に応じて、ＦＴＴＩ優先書き替えＡＮ［１］、ＡＳＩＬ優先書き替えＡＮ［２］が選択されうる。

【0066】

なお、優先順位ルールは、任意に書き替え可能であってもよい。例えば、形式的な設計仕様書から自動プログラムを用いて、実行形式のコードをフラッシュメモリに実装することによって、機能仕様書に従いライフサイクルの中で設計変更する可能性のある部分を書き替える仕組みを構築することも可能である。特に、実行待ちスレッド毎のＦＴＴＩに応じて、動的に各テーブルを書き換えてもよい。

【0067】

［３－２－４．第１作動例］
図６を用いて本実施形態の構成での第１作動例を説明する。本作動例は、機能安全のＳＭよりも優先度の高いスレッド０１の実行周期内で、ＳＭの処理が全て完了しないスレッドｍ１とスレッドｎ１に対して同時に異常検知された場合のスレッド実行手順の一例を示す。第１作動例では、機能安全要件であるＦＴＴＩに対する実行残時間を比較し、機能安全上より早く処置すべきスレッドの優先度を上げて処理するスケジューリング例である。

【0068】

つまり、制御演算部１１は、機能安全スレッドの異常が検知された場合、ＦＴＴＩ内は、機能安全スレッドの実行優先順位を非機能安全スレッドの実行優先順位よりも相対的に高くするようにスケジュールの変更を行う。この際、優先的に実行される機能安全スレッド（すなわち割込スレッド）は、限界待ち時間がＦＴＴＩ未満になるようなテーブルが選択される。

【0069】

なお、図６では、３つのスレッドのタイマ割り込みが同期したタイミングを矢印で図示している。このように、３つのスレッドが実行待ち状態である場合は、最も、優先度が高いスレッドから実行される。

【0070】

前述したテーブルとしては、ＦＴＴＩ優先書き替えＡＮ［１］が選択されている。なお、各スレッドのランタイムがそれぞれ対応する待ち時間タイマ（すなわち本開示での限界待ち時間）を超過した場合は縮退処理を実行するように設定される。

【0071】

スレッド０１の実行後、スレッドｍ１及びスレッドｎ１で異常が検知される。この際、実行優先順位に変更がない場合、図６の点線にて示すように、スレッド０１，ｍ１，ｎ１の順で実行される。何らかの原因で、先に実行するスレッド０１が延長したことを想定すると、スレッドｍ１，ｎ１にて異常処置（すなわち割込スレッド）を実施し、それぞれにＦＴＴＩが設定されている場合、このスレッドの順序では、スレッドｎ１がＦＴＴＩの要件を満たさない。

【0072】

そこで、スレッド０１は、スレッドｍ１とスレッドｎ１が異常を検知した場合は、スレッドｍ１及びスレッドｎ１よりも実行優先順位がスケジューラにより下げられる。なお、スレッド０１は、機能安全の異常検知機能（ＳＭ）の正常時において、スレッドｍ１及びスレッドｎ１よりも、実行優先順位が高く設定されている。

【0073】

この結果、図６の実線にて示すように、スレッド０１に対して、スレッドｎ１、スレッドｍ１の順に処理が可能となり、スレッド０１の実行は、スレッドｎ１、スレッドｍ１の規定の異常処置が完了するまで遅延される。つまり、スレッド０１の実行は、スケジュールで規定された異常処置のスレッドを完了するまで遅延され、所定のスケジュール内でのスレッドの異常処置が完了後、スレッド０１の実行に移る。この際、必ずしも、全ての異常処置が完了するまでスレッド０１の実行が遅延されるわけではない。なお、スレッド０１は、通常のデッドライン監視タイマを超過しないようにスケジューリングされることが好ましい。

【0074】

［３－２－５．第２作動例］
第１作動例では、機能安全要件も非機能安全要件も同一のスケジューラの管理下で各関連スレッドが制御される前提で記載している。つまり、主としてコア間制御スレッド制御部３２が備えるスケジューラの機能を用いて、スレッドの実行順序を管理している。しかし、図７の第２作動例に示すように、非機能安全要件に関連したスレッドを制御するスケジューラと、機能安全要件に関連したスレッドを制御するスケジューラとを独立させてもよい。つまり、機能要件部３３のスケジューラの機能及び非機能要件部３４のスケジューラの機能をそれぞれ用いて、コア間制御スレッド制御部３２がこれらを調停することで、スレッドの実行順序を管理している。

【0075】

この構成では、個々のスケジューラの管理下で、全ての機能安全要件に関連するスレッドを集約し、機能安全の安全機構の実行をいかなる排他的侵害要因からも保護し安全を担保するように構成することができる。この場合、スケジューラを含むコア間制御スレッド制御部３２は、最高ＡＳＩＬの機能安全要件として構成することが望ましい。

【0076】

このような構成にした場合は、非機能安全要件と機能安全要件が無干渉になることが、設計構造的に担保される。このため、機能安全要件内の各スレッドのＡＳＩＬの違いや、ＦＴＴＩのランタイム上の優先度のみにフォーカスして、マルチスレッドのリソーセスを適切にディスパッチすることがより容易に構造設計可能となる。

【0077】

換言すれば、機能安全要件と非機能安全要件が確実にパーテショニングされ、ソフトウェアの再利用性が高くなる。この結果、ソフトウェアライフサイクルにおける機能安全に適合するためのアーキテクチャ変更及び検証工数の節約と実装したソフトウェアのロバスト性の向上の両立を図ることができる。なお、マルチスレッドのリソーセスには、例えば、メモリ１３、スケジュール、入出力部１２が該当する。

【0078】

また、第２作動例の構成は、例えば下記のように設計される。

【0079】

各種機能安全要件のＦＴＴＩを担保するために、最大割り込み許容間隔（すなわち、最も遅れて処理してもＦＴＴＩは担保できる間隔）から、集約した機能安全関連スレッド群の最小割り込み周期をスケジューリングする。例えば、２，４，８，１６ｍｓの周期的スレッドを集約した場合、２ｍｓを一般ＯＳから独立したタイマ割り込みとして設計する。

【0080】

非機能安全要件関連のスレッド内での割り込み禁止時間は、余裕をとって２ｍｓより十分小さくし、２ｍｓ周期割り込みを担保する設計とする。

【0081】

［３－２－６．正常時スケジューラ実行処理］
制御演算部１１が実行する正常時スケジューラ実行処理について、図８Ａ及び図８Ｂのフローチャートを用いて説明する。正常時スケジューラ実行処理は、機能安全スレッドの異常が発生していない状況での正常時Ｎのテーブルに従って実行される処理である。正常時スケジューラ実行処理は、例えば、予め設定された周期毎に実施される。

【0082】

正常時スケジューラ実行処理では、まず、Ｓ３１０で、制御演算部１１は、実行周期割り込み、ここでは、（最小時間間隔）Ｘ（２の０乗）の実行待ちであるか否かを判定する。制御演算部１１は、Ｓ３１０で実行周期割り込みの実行待ちでないと判定した場合には、Ｓ４１０へ移行する。

【0083】

一方、制御演算部１１は、Ｓ３１０で実行周期割り込み（最小時間間隔）Ｘ（２の０乗）の実行待ちであると判定した場合には、Ｓ３２０へ移行し、非機能安全スレッド０１の実行待ちであるか否かを判定する。

【0084】

例えば、制御演算部１１は、Ｓ３２０で非機能安全スレッド０１の実行待ちであると判定した場合には、Ｓ３３０へ移行し、非機能安全スレッド０１をディスパッチして当スレッドを実行するためのカーネルコールを実行する。この際、当スレッドより優先度の低いスレッドが実行中であっても、そのスレッドを一時中断（すなわちプリエンプション）して当スレッドの実行を優先する。その後、図８Ａ及び図８Ｂの正常時スケジューラ実行処理を終了する。

【0085】

一方、制御演算部１１は、Ｓ３２０で非機能安全スレッド０１の実行待ちでないと判定した場合には、Ｓ３４０へ移行し、非機能安全スレッド０２の実行待ちであるか否かを判定する。

【0086】

制御演算部１１は、Ｓ３４０で非機能安全スレッド０２の実行待ちであると判定した場合には、Ｓ３５０へ移行し、非機能安全スレッド０２をディスパッチして当スレッドを実行するためのカーネルコールを実行する。一方、制御演算部１１は、Ｓ３４０で非機能安全スレッド０２の実行待ちでないと判定した場合には、Ｓ４１０に移行する。

【0087】

続いてＳ４１０で、制御演算部１１は、実行周期割り込み（最小時間間隔）Ｘ（２のｍ乗）の実行待ちであるか否かを判定する。制御演算部１１は、Ｓ４１０で実行周期割り込みの実行待ちでないと判定した場合には、Ｓ５１０へ移行する。

【0088】

一方、制御演算部１１は、Ｓ４１０で実行周期割り込みの実行待ちであると判定した場合には、Ｓ４２０へ移行し、機能安全スレッドｍ１の実行待ちであるか否かを判定する。

【0089】

制御演算部１１は、Ｓ４２０で機能安全スレッドｍ１の実行待ちであると判定した場合には、Ｓ４３０へ移行し、機能安全スレッドｍ１をディスパッチして当スレッドを実行するためのカーネルコールを実行する。その後、図８Ａ及び図８Ｂの正常時スケジューラ実行処理を終了する。

【0090】

一方、制御演算部１１は、Ｓ４２０で機能安全スレッドｍ１の実行待ちでないと判定した場合には、Ｓ５１０に移行する。

【0091】

制御演算部１１は、Ｓ５１０で実行周期割り込み（最小時間間隔）Ｘ（２のｎ乗）の実行待ちであるか否かを判定する。制御演算部１１は、Ｓ５１０で実行周期割り込みの実行待ちでないと判定した場合には、図８Ａ及び図８Ｂの正常時スケジューラ実行処理を終了する。

【0092】

一方、制御演算部１１は、Ｓ５１０で実行周期割り込みの実行待ちかであると判定した場合には、Ｓ５２０へ移行し、機能安全スレッドｎ１の実行待ちであるか否かを判定する。

【0093】

制御演算部１１は、Ｓ５２０で機能安全スレッドｎ１の実行待ちであると判定した場合には、Ｓ５３０へ移行し、機能安全スレッドｎ１をディスパッチして当スレッドを実行するためのカーネルコールを実行する。この際、当スレッドより優先度の低いスレッドが実行中でも、一時中断して当スレッドの実行を優先する。その後、図８Ａ及び図８Ｂの正常時スケジューラ実行処理を終了する。

【0094】

一方、制御演算部１１は、Ｓ５２０で機能安全スレッドｎ１の実行待ちでないと判定した場合には、Ｓ５４０へ移行し、機能安全スレッドｎ２の実行待ちであるか否かを判定する。

【0095】

制御演算部１１は、Ｓ５４０で機能安全スレッドｎ２の実行待ちであると判定した場合には、Ｓ５５０へ移行し、機能安全スレッドｎ２をディスパッチして当スレッドを実行するためのカーネルコールを実行する。その後、図８Ａ及び図８Ｂの正常時スケジューラ実行処理を終了する。

【0096】

一方、制御演算部１１は、Ｓ５４０で機能安全スレッドｎ２の実行待ちでないと判定した場合には、図８Ａ及び図８Ｂの正常時スケジューラ実行処理を終了する。

【0097】

［３－２－７．異常時スケジューラ実行処理］
制御演算部１１が実行する異常時スケジューラ実行処理について、図９Ａ、図９Ｂ、図１０Ａ、図１０Ｂ、図１１Ａ、及び図１１Ｂ（以下、図９Ａ～図１１Ｂ）のフローチャートを用いて説明する。図９Ａ～図１１Ｂに示す異常時スケジューラ実行処理では、優先順位ルールに従って、正常時スケジューラ実行処理とはスレッドの実行順序が異なるように変更されている。なお、図１０Ａ及び図１０Ｂに示す異常時スケジューラＡＮ［１］の実行処理は、ＦＴＴＩ優先書き替えＡＮ［１］が選択された場合の処理に該当する。また、図１１Ａ及び図１１Ｂに示す異常時スケジューラＡＮ［２］の実行処理は、ＡＳＩＬ優先書き替えＡＮ［２］が選択された場合の処理に該当する。換言すれば、図１０Ａ及び図１０Ｂに示す異常時スケジューラＡＮ［１］及び図１１Ａ及び図１１Ｂに示す異常時スケジューラＡＮ［２］は、図５で示した「スケジューラ選択テーブル」にそれぞれ該当する。

【0098】

図９Ａ及び図９Ｂに示す異常時スケジューラＡＮの実行処理では、Ｓ４１０～Ｓ５５０の処理が、Ｓ３１０～Ｓ３５０の処理よりも前に実行される。図１０Ａ及び図１０Ｂに示す異常時スケジューラＡＮ［１］の実行処理では、まず、Ｓ５１０の処理が実施され、その後、Ｓ５４０～Ｓ５５０、Ｓ５２０～Ｓ５３０、Ｓ４１０～Ｓ４３０、Ｓ３１０～Ｓ３５０の順に処理が実施される。

【0099】

図１１Ａ及び図１１Ｂに示す異常時スケジューラＡＮ［２］の実行処理では、Ｓ５１０～Ｓ５５０、Ｓ４１０～Ｓ４３０、Ｓ３１０～Ｓ３５０の順に処理が実施される。

【0100】

［３－３．効果］
以上詳述した第１実施形態によれば、以下の効果を奏する。

【0101】

（３ａ）本開示の一態様は、機能安全スレッド、及び少なくとも１つの非機能安全スレッド、を予めスケジューラで定義された優先順位に基づく並列処理で実行可能な車両用コンピュータ（例えば制御演算部１１）にて実行される自動車用コンピュータの制御方法である。並列処理には、マルチコアによる並列処理を含むスケジューリング、あるコアによる時分割による疑似並列処理が含まれうる。機能安全スレッドは、車両の安全に関する値を演算するスレッドを表す。また、非機能安全スレッドは、機能安全スレッドを除くスレッドを表す。

【0102】

自動車用コンピュータの制御方法では、機能安全スレッドの異常を検知し、機能安全スレッドの異常が検知された場合に、スケジューラを変更してスレッドの実行優先順位を変更する。

【0103】

このような制御方法によれば、機能安全スレッドに異常が生じた場合だけ、スレッドを実行する際の優先順位を変更できる。よって、機能安全スレッドが正常判定している間は、車両の本来機能を優先したスケジューリングが可能となる。

【0104】

つまり、優先順位が変更される状況を、機能安全スレッドに異常が生じた場合に限定するので、全てのスレッドが限界待ち時間内に実行されやすくする様なスケジュール設計が容易となる。

【0105】

より詳細には、スレッドの実行優先順位を制御する構成によれば、相対的にスケジューラの優先順位テーブルの書替えを実施する。このため、前述した安全機構が異常を検出して異常処置を実行するスレッドが他のスレッドが実行中のため実行待ちになっていても、両スレッドの相対的実行優先順位を変更して、機能安全の安全を担保する許容時間内に確実に処理を完了できる。かつ、非機能安全スレッドについても本来機能を縮退させる機会を極力減らすことができる。

【0106】

すなわち、本願構成では、機能安全スレッドが異常を検出した場合に、規定の機能安全要件を最優先に処理したうえで、異常原因と直接関係しない本来機能（非機能安全要件）は、極力縮退を回避することができる。また、リアルタイム性を確保したスケジュール設計を実現できる。

【0107】

なお、機能安全スレッドでは、例えば、機能安全要求仕様を実現してもよい。この場合の本来機能と安全機構をソフトウェアモジュールにして半導体メモリ内に実装した際の実行優先順位を定義する最小実行単位であり、スケジューラにより、一般的には、使用するコアやメモリ及び入出力等ハードウェア資源が時分割で紐付けられる。なお、機能安全要求仕様とは、安全目標や安全機構（例えば、フェールセーフ機構やＦＴＴＩ）が技術安全要求（ＴＳＲ：Technical Safety Requirement）や技術安全コンセプト（ＴＳＣ：Technical Safety Concept）により一般的には定義されてもよい。なお、ＴＳＲは、システムの異常が発生した時に安全担保のため、どのような安全保護機能が必要かを要求するための技術仕様書である。また、ＴＳＣは、その安全保護機能をいかに実現するかを技術仕様書としてまとめたものである。

【0108】

（３ｂ）本開示の一態様では、異常が検知された場合、予め設定された異常処置が完了するまで、非機能安全スレッドの実行を中断するように構成される。非機能安全スレッドの実行は、動的スケジューラで更新された期間のみ実行する関連スレッドの優先順位がカーネルにより制御される、実行すべき機能安全スレッド、或いは異常時に実施される割込スレッドの実行が完了するまで中断される。なお、非機能安全スレッドの実行は、全ての異常処置が完了するまで非機能安全スレッドを中断するのではない。

【0109】

このような方法によれば、異常処置が完了するまで非機能安全スレッドの実行を中断するので、規定の異常処置を最優先で実行し、規定の異常処置が完了後は、中断した非機能安全スレッドの実行に戻ることが可能である。

【0110】

（３ｃ）本開示の一態様では、異常が検知されてから車両に危険事象が発生するまでの推定時間をＦＴＴＩ（Fault Tolelant Time Interval）とする。異常が検知された場合、ＦＴＴＩ内は、機能安全スレッドの実行優先順位を非機能安全スレッドの実行優先順位よりも相対的に高くするようにスケジュールの変更を実施する。

【0111】

このような方法によれば、ＦＴＴＩを考慮して非機能安全スレッドを一時的に中断することができる。

【0112】

（３ｄ）本開示の一態様では、カーネルの割り込み制御を使用し、機能安全スレッドの異常の有無を検出して、異常が検知された場合に、スケジュールを変更する。

【0113】

このような方法によれば、カーネル割り込み制御を実施するので、早急に異常に対処することができる。

【0114】

（３ｅ）本開示の一態様では、機能安全スレッドの異常が検出されているか否かを診断する機能安全機構（ＳＭ）をスレッドとして実装し、異常が検出されているか否かに応じてスケジューラの変更の要否を判定し、スケジューラの切り替えを行う。

【0115】

このような方法によれば、スケジューラの変更の要否を判定して、スケジューラの変更が必要な場合にスケジューラの切り替えを行うことができる。なお、スケジューラの切り替えの要否判定は、スケジューラの切り替えが間に合う適切なタイミングで実施されるとよい。

【0116】

また、スケジューラ切替の主な制御方法として図５で示すように、機能安全常時ＳＭを全ての周期的割り込みに配置する方法（例えば、最短周期割り込みに配置）を採用できる。或いは、ＨＷ割り込みハンドラで機能安全ＳＭを起床させる構造とする方法を採用できる。

【0117】

（３ｆ）本開示の一態様では、少なくともカーネルの割り込み制御にて実施される割込スレッドには、実行すべき指示を受けてから当該スレッドが実行されるまでの時間の上限を表す限界待ち時間が設定される。割込スレッドの限界待ち時間は、ＦＴＴＩ未満になるように設定される。

【0118】

このような方法によれば、ＦＴＴＩまでに割込スレッドが実行することができるので、より安全に割込スレッドを実行することができる。

【0119】

（３ｇ）本開示の一態様では、割込スレッド、機能安全スレッド、及び非機能安全スレッドには、実行すべき指示を受けてから当該スレッドが実行されるまでの時間の上限を表す限界待ち時間が設定されている。割込スレッドが実行されるまで（Twait_SRを超過する前）に、割込スレッド以外の他のスレッドの限界待ち時間（Twait_NSR）が超過した場合、当該他のスレッドに対応するシステムを縮退させる。システムの縮退では、例えば、本来機能の一部を制限する制限モード、自動運転のシステム異常時であれば、運転者による手動運転を要求する交替制御モード等が実施されうる。

【0120】

このような方法によれば、非機能安全スレッド等の他のスレッドが限界待ち時間以内に実行できない場合に、他のスレッドに対応するシステムを縮退させるので、より安全と利便を両立して車両を制御することができる。

【0121】

（３ｈ）本開示の一態様では、複数の機能安全スレッドにおいて異常を検知してもよい。異常を検知したスレッド毎に、割込スレッドを実行し、この際、限界待ち時間に対する残り時間が小さい順に、割込スレッドの実行優先順位を高するように（すなわち、割込スレッドの実行優先順位がより高くなるように）スケジューラの内容を変更する。

【0122】

このような方法によれば、複数の機能安全スレッドにおいて異常が検知されたことに伴い、複数の割込スレッドを実行する場合に、限界待ち時間に対する残り時間が小さい順に割込スレッドを実行できる。よって、割込スレッドの何れかが限界待ち時間以内に実行されない事態になることを抑制することができる。

【0123】

（３ｉ）本開示の一態様は、少なくとも１つの機能安全スレッド、及び少なくとも１つの非機能安全スレッド、を予めスケジューラで定義された優先順位に基づく並列処理で実行可能な車両用電子制御装置（本開示での制御演算部１１）である。

【0124】

異常検知部は、機能安全スレッドの異常を検知するように構成される。順序変更部は、機能安全スレッドで異常が検知され、異常処置が必要になった場合に、スケジューラを変更して優先順位を変更する。

【0125】

このような構成によれば、機能安全スレッドに異常が生じた場合だけ、スレッドを実行する際の優先順位を変更できる。

【0126】

（３ｊ）特に、車両用電子制御装置は、コアを複数個実装して、スレッドがコアやメモリ等ハードウェア資源をスケジューラにより時分割で共有するシステムを構成できる。このようなシステムにおいては、機能安全スレッドの安全機構が異常を検出した際、他のスレッドの実行を一時中断して、システム許容時間内に異常処置を完了したり、時間的に余裕のあるコアやメモリの資源を優先的に使用したりすることが可能となる。

【0127】

このような構成によれば、システム全体として実行時間がクリティカルになる、つまり、スレッドが許容時間内に終了しない状況が頻発する、という潜在的なケースをより減らすことがき、ロバスト性の高いシステムが構築可能となる。また、システム全体の安全担保に関して、実行時間の余裕のあるシステム設計により、システム機能の縮退設計の必要性を削減し、システム本来の機能を確保することにより、商品性を向上することが容易となる。

【0128】

［４．他の実施形態］
以上、本開示の実施形態について説明したが、本開示は前述の実施形態に限定されることなく、種々変形して実施することができる。

【0129】

（４ａ）上記実施形態では、機能安全スレッド毎にＦＴＴＩが対応付けられたが、これに限定されるものではない。例えば、ＦＴＴＩに換えて、或いはＦＴＴＩに加えて、機能安全スレッド毎に自動車安全水準レベル（ASIL：Automotive Safety Integrity Level）が対応付けられていてもよい。この場合、複数の機能安全スレッドにおいて異常を検知し、異常を検知したスレッド毎に、割込スレッドを実行し、この際、自動車安全水準レベルが高い順に、割込スレッドの実行優先順位を高する様にスケジューラの内容を変更してもよい。例えば、制御演算部１１は、自動車安全水準レベルが高い順に各スレッドが実行されるように図５に示す異常時スケジューラＡＮ［２］を動的に書き換えるとよい。

【0130】

このような方法によれば、自動車安全水準レベルが高い順に、スレッドを実行するので、より優先して実行すべきスレッドを優先して実行することができる。

【0131】

（４ｂ）上記実施形態では、ＥＣＵ１０を構成する各構成要素１１，１２，１３，１６の配置について言及していないが、例えば、各構成要素１１，１２，１３，１６の実際のデバイスは、１つ又は複数のＳＯＣ（System On Chip）で構成することができる。

【0132】

また、例えば、図２に示す車両アプリケーション機能１６の各機能は、破線部３１内の機能がＯＳを実装する１つのＳＯＣによって実現され、破線部３１外の機能が前記ＳＯＣとは別のＳＯＣによって実現されてもよい。すなわち、コア間制御スレッド制御部３２、及び機能要件部３３の機能がＯＳを実装する１つのＳＯＣで実現され、非機能要件部３４の機能が前記ＳＯＣとは別のＳＯＣで実現されてもよい。

【0133】

このような構成によれば、オーバーヘッドを減少させ、リアルタイム性を向上させることができる。

【0134】

（４ｃ）本開示に記載の制御演算部１１及びその手法は、コンピュータプログラムにより具体化された１つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御演算部１１及びその手法は、１つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御演算部１１及びその手法は、１つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと１つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された１つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。制御演算部１１に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、１つあるいは複数のハードウェアを用いて実現されてもよい。

【0135】

（４ｄ）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。

【0136】

（４ｅ）前述した車両制御システム１の他、当該車両制御システム１の構成要素となる車両制御装置等の装置、当該装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体、自動車用コンピュータの制御方法を含む各種方法など、種々の形態で本開示を実現することもできる。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9A】

【図9B】

【図10A】

【図10B】

【図11A】

【図11B】