JP2004220326A

JP2004220326A - 制御ソフトウエア構造およびこの構造を用いた制御装置

Info

Publication number: JP2004220326A
Application number: JP2003006976A
Authority: JP
Inventors: Minoru Okada; 稔岡田; Masahiro Goto; 正博後藤; Akihito Iwai; 明史岩井; Hiraki Matsumoto; 平樹松本
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2003-01-15
Filing date: 2003-01-15
Publication date: 2004-08-05
Also published as: US20040143656A1; DE102004002020A1

Abstract

【課題】ＥＣＵ間において機能の再配置等を行った際においても制御アプリケーションソフトウエアの再利用性を向上させた制御ソフトウエア構造およびこの構造を用いた制御装置を提供することを目的とする。
【解決手段】複数の電子制御装置をネットワークを介して分散協調制御する制御ソフトウエア構造で、各システム制御を実現するための各制御アプリケーションソフトにはデータ管理機能および時間同期機能を無くし分散制御アプリケーションフレームワーク中に、電子制御装置に同一の当該データ管理機能および時間同期機能を配置した。
【選択図】図３

Description

【０００１】
【発明の属する技術分野】
本発明は、制御アプリケーションソフトの再利用性を向上した制御ソフトウエア構造およびこの制御ソフトウエア構造を用いた制御装置に関する。
【０００２】
【従来の技術】
従来、ネットワークを介した分散協調制御では、ネットワークを介した各システム間、制御アプリケーションソフトと通信ソフトとの間の、時間的な同期処理、各制御アプリケーションソフトの位置情報処理、制御アプリケーションソフトの実行順序管理等が、明示的に制御アプリケーションソフト内にて実行されている。（たとえば、特許文献１参照）
このような場合、たとえば車両における車載協調分散制御では、制御要求指示データと、車両・車外状態共通データなどが通信仕様定義、およびＥＣＵソフトウエア実装形態に対して明示的に分離されていない状況にある。そのため、通信仕様定義において同じ意味を持つデータが複数定義され、非常に冗長になっており、通信負荷の肥大化を招いている。あるいは、ＥＣＵソフトウエア実装形態においても、制御要求指示データと、車両・車外状態に関する共通データが分離されていない。このため、車両制御の各機能を車種等毎に他のＥＣＵに別途再配置しなければならない場合、他のＥＣＵからの要求タイミングや通信バスの状況によって処理順序が変わってしまう可能性が変化し、その結果がその機能の制御あるいは／およびシステム全体の制御に影響を及ぼす可能性がある。
【０００３】
【特許文献１】
特表平８−５００９２２号公報
【０００４】
【発明が解決しようとする課題】
このような自体を回避するために、車両制御の機能を再配置した際も制御アプリケーションの各々に対してあらためて制御実行等の順序の管理情報を再設計し、制御アプリケーションにおいて順序管理を実行できるようにしなければならない。すなわち、制御アプリケーションにおいて順序の管理を行うようにすると、車種毎等に機能を他のＥＣＵに再配置した場合には、その都度全制御アプリケーションに対して順序管理等を再設計する必要があり、ソフトウエアの再利用性が低下している現状にある。
【０００５】
以上の点を鑑み、本願発明では、ＥＣＵ間において機能の再配置等を行った際においても制御アプリケーションソフトウエアの再利用性を向上させた制御ソフトウエア構造およびこの構造を用いた制御装置を提供することを目的とする。
【０００６】
【上記課題を解決するための手段】
上記課題を達成するために本願発明では、複数の電子制御装置をネットワークを介して分散協調制御する制御ソフトウエア構造において、各電子制御装置に備えられた各システムを実現するための各制御アプリケーションソフトよりデータ管理機能および時間同期機能を分離し、前記各制御アプリケーションソフトの下位の分散制御プラットフォーム中に、前記複数の電子制御装置に対して同一の当該データ管理機能および時間同期機能を配置したことを特徴とする。
【０００７】
従来では、各制御システムを実現するための制御アプリケーションソフト自体にシステム実行の際に用いられるデータの管理機能およびデータ等の送受信、演算タイミング等の時間同期機能を備えるようにしていたため複数のシステムをネットワークを介して関連させて実行させる制御構造ではある部分の制御アプリケーションソフトを変更すると、全てのアプリケーションソフトを再設計する必要があったが、本願発明では、制御アプリケーションソフトからデータ管理機能と時間同期機能を無くして、ネットワーク側である下位の分散制御プラットフォームに配置したため、ある制御アプリケーションソフトを変更したとしても、この分散制御プラットフォームのみを再設計すれば良く、他の制御アプリケーションソフトの再利用性が高まる。
【０００８】
また、請求項２に記載の如く、第１の電子制御装置と第２の電子制御装置とをネットワークを介して分散協調制御する制御ソフトウエア構造において、前記第１の電子制御装置は、少なくとも１つのシステムを実現するための少なくとも１つの制御アプリケーションソフトと、前記制御アプリケーションソフトから分離されたデータ管理機能を備えた分散制御プラットフォームと、前記制御アプリケーションソフトから前記分散制御プラットフォームを介して指示されるアクチュエータ駆動指令を受けたり、あるいは／および、前記分散制御プラットフォームにデータを送信するドライバソフトと、を備え、前記第２の電子制御装置は、少なくとも１つのシステムを実現するための少なくとも１つの制御アプリケーションソフトと、前記制御アプリケーションソフトから分離されたデータ管理機能を備えた分散制御プラットフォームと、前記制御アプリケーションソフトから前記分散制御プラットフォームを介して指示されるアクチュエータ駆動指令を受けたり、あるいは／および、前記分散制御プラットフォームにデータを送信するドライバソフトと、を備え、前記第１の電子制御装置における分散制御プラットフォームと前記第２の電子制御装置における分散制御プラットフォームとが共通化されていることを特徴とする制御ソフトウエア構造およびこの構造を用いた制御装置を採用するようにしてもよい。
【０００９】
この場合には、請求項１に対して述べた他の制御アプリケーションソフトの再利用性の向上に加えて、第１及び第２の電子制御装置の双方に同一の分散制御プラットフォームを備えているため、たとえば第１の電子制御装置の方のみに分散制御プラットフォームを備えた場合と比較して、ネットワークを介して各電子制御装置がデータを取得する場合等の処理負荷を軽減することができ、応答遅れを抑制することが可能となる。
【００１０】
また、請求項３に記載の発明では、複数の電子制御装置をネットワークを介して分散協調制御する制御ソフトウエア構造において、各電子制御装置は、各システムを実現するための各制御アプリケーションソフトと、当該各制御アプリケーションソフトに備えられていないデータ管理機能を備える分散制御プラットフォームと、ドライバソフトと、を備え、前記分散制御プラットフォームには各電子制御装置共通に、前記システムを実現するための要求指示データを一時記憶するデータキューと、前記システムを実行する際の状態データを一時記憶する状態共通データ部と、を備えることを特徴とする。
【００１１】
このように、分散制御プラットフォームにおいて制御アプリケーションソフトで使用するデータである要求指示データと状態データとを管理するようにしたので、制御アプリケーションソフトからデータ管理機能を分離でき、制御アプリケーションソフトの再利用性を高めることが可能となる。
【００１２】
また、請求項４に記載の発明では、複数の電子制御装置をネットワークを介して分散協調制御する制御ソフトウエア構造において、各電子制御装置は、各システムを実現するための時間同期機能を有さない各制御アプリケーションソフトと、当該各電子制御装置に共通に、前記システム間、前記各制御アプリケーションソフト間および各電子制御装置間の通信を行う各通信ソフト間の時間同期を行う機能を有する分散制御プラットフォームと、前記制御アプリケーションソフトから前記分散制御プラットフォームを介して指示されるアクチュエータ駆動指令を受けたり、あるいは／および、前記分散制御プラットフォームにデータを送信するドライバソフトと、を備えたことを特徴とする。
【００１３】
ネットワークにより複数の電子制御装置を関連させてシステムが構築された場合、各システムにおける制御アプリケーションソフトにおける演算処理タイミングあるいは演算に用いるデータ自体の時間同期性を確保しなければ、制御に支障をきたす可能性があるが、本発明の如く制御アプリケーションソフトではなく分散制御プラットフォームに時間同期機能を持たせることにより、制御アプリケーションソフトを交換した場合においても他の制御アプリケーションソフトは再設計することなく利用することが可能である。
【００１４】
請求項５に記載の発明では、状態データが各前記電子制御装置において一括して更新される。たとえばドライバソフトから各制御アプリケーションソフトに送付される状態データが時間的にずれて送受信されると、制御アプリケーションソフトにおける演算が取得された時間がずれた一貫性のない状態データに基づいた演算となることがありえる。しかし、状態データの更新を各電子制御装置に対して一括して同時期に行うようにすれば、各電子制御装置の制御アプリケーションソフト等における演算結果の精度あるいは／および一貫性を保証することが可能となる。
【００１５】
請求項６に記載の発明では、要求指示データには予め優先度が設定されていることを特徴とする。たとえば、複数の電子制御装置の制御アプリケーションソフトから随時要求指示データがデータキューに送信されてくる場合、どの順番でデータキューからその要求指示データを必要とする制御アプリケーションソフトに送信するかの調停が必要となることが予想できる。しかし、あらかじめ要求指示データ自体に優先順位付けが成されていれば、あらためて調停をするための機能を必要としない。なお請求項７に記載の如く、各電子制御装置ひいては各制御アプリケーションソフトから送信される要求指示データあるいは／および各制御アプリケーションソフトが受信する要求指示データの全てを分散制御プラットフォームのデータキューを介して送受信されることで、車種等毎に制御アプリケーションソフトが変更されたとしても、その変更された要求指示データの優先順位のみを変更されていない制御アプリケーションソフトにおける要求指示データとの相関で決定すればよく、設計工数の低減を実現できる。
【００１６】
請求項８に記載の発明では、分散制御プラットフォームには前記制御アプリケーションソフトがどのＥＣＵに配置されているかの位置情報が設定されていることを特徴とする。たとえば、各電子制御装置の制御アプリケーションソフトからの要求の送受信をする場合、どの電子制御装置にどの制御アプリケーションソフトが存在するかという情報は各電子制御装置に持たせることもできる。しかしながらこの場合、車種毎等でネットワークにつながる電子制御装置の一部を交換した場合あるいは／および制御アプリケーションソフトの一部を交換した場合、ネットワークにつながる交換していない電子制御装置あるいは／および制御アプリケーションソフトの全ての位置情報を書きかえる必要がでてくる。ところが本発明の如くすれば、各電子制御装置ひいては各制御アプリケーションソフトに共通の分散制御アプリケーションソフトのみを書きかえれば良く、再設計作業は一括して実施できる。
【００１７】
請求項９に記載の発明では、時間同期機能は、前記制御アプリケーションソフトにおける処理のデッドライン時間に応じて定められた送信タイミングに基づきデータを送信することにより各電子制御装置における時間同期を図ることを特徴とする。通常電子制御装置にはスケジューリング機能すなわち制御アプリケーションソフトの起動あるいは／および演算タイミングの順番を管理する機能が含まれている。ただし、これのみではたとえばある制御アプリケーションソフトにおける演算が終了しないうちに他の制御アプリケーションソフトでの演算が開始されてしまう等の不具合が生じる。すなわち前に終了されているべき演算の終了前で他の演算が始まると、演算に用いるデータ等が既に終了されているさらに前のデータに基づいて実行されることとなり、データの一貫性が無くなる恐れがある。しかしながら、本発明では、送信タイミングをデッドライン時間に基づいて規定したため、データの一貫性も保証することができるようになる。言い換えれば本発明では各制御アプリケーションソフト間ひいては各電子制御装置間におけるデータの一貫性を確保するための機能を各制御アプリケーションソフトに設けず、分散制御プラットフォームに設けているものであって、本発明でいう時間同期機能は前述のデータの一貫性を確保するための機能と言い換えることもできる。
【００１８】
請求項１０に記載の発明では、状態共通データ部とデータキューは制御アプリケーションソフトの各々に対応して設けられており、データキューとして、他の前記制御アプリケーションソフトからの要求指示データを受ける要求受付データキューと、他の前記制御アプリケーションソフトへの前記要求指示データの発行を行うための要求発行データキューとを備えていることを特徴とする。このように各制御アプリケーションソフトにおいて生成される要求指示のデータを自身の制御アプリケーションソフトが発行する要求指示データか自身が受ける要求指示データかを分離して管理することによって、分散制御プラットフォームの設計を容易にすることができる。
【００１９】
なお、分散制御プラットフォームは、前記制御アプリケーションソフトの各々に対して備えられているようにしてもよい。
【００２０】
【発明の実施の形態】
図１は、本発明の全体構成の概要を表すイメージ図である。
【００２１】
ＥＣＵ（以下電子制御装置という）１とＥＣＵ２とはネットワーク５００で接続されている。ＥＣＵ１には、制御アプリケーションソフト１０、分散制御プラットフォーム２０およびドライバソフト３０が存在する。同様にＥＣＵ２においても制御アプリケーションソフト４０、分散制御プラットフォーム５０およびドライバソフト６０が存在する。
【００２２】
制御アプリケーションソフト１０，４０は各々、１つあるいは複数のシステムを実現するためのものである。システムの例としては、たとえば、車両制御におけるアンチスキッド制御システム、トラクションコントロールシステム、車体挙動安定化システム、ブレーキアシストシステム、エンジンコントロールシステム等を挙げることができる。なお、１つのＥＣＵに複数のシステムを存在させる場合には、１つのＥＣＵに複数の制御アプリケーションソフトが存在することになる。
【００２３】
分散制御プラットフォーム２０，５０は、図２、図３において後述するように各ＥＣＵ共通の同一構造を有するものであり、内部構成として、車両・車外状態共通データベース、データキュー等を有し、各ＥＣＵ間あるいは／および各制御アプリケーションソフト間における起動あるいは演算順位を規定・管理するスケジューリングや制御アプリケーションソフトがどのＥＣＵに配置されているかの配置情報を踏まえた位置透過性を確保するための機能が設けられている。また、スケジューリングによる順番管理とともに各制御アプリケーションソフトあるいは／および電子制御装置間の時間同期性を図るための機能も備えられている。
【００２４】
ドライバソフト３０，６０は、分散制御アプリケーションフレームワークを介して各制御アプリケーションソフトからの指令を受け、各制御アプリケーションソフトに従属する図示しないアクチュエータ（ＡＣＴ）を駆動するものである。また、各アクチュエータが取得した検出情報を受け、前述の分散制御アプリケーションフレームワーク中の車両・車外状態共通データベースに送信する役割も果たす。
【００２５】
図２は、図１における分散制御プラットフォーム２０，５０を主眼として見たイメージ図である。すなわち、各ＥＣＵにおける分散制御プラットフォームは同様の構造を備えており、単にＥＣＵ共通で１つの分散制御プラットフォームを備えているように捉えることができる。なお、図１と同等の構成には同様の符号を付し、説明を省略する。
【００２６】
図１で説明したように、各ＥＣＵ１，２における分散制御プラットフォーム２０，５０は全く同様の構造であるため、単に１つのソフトとして見なすことができる。そして、この分散制御プラットフォーム２０（５０）には、各ＥＣＵ共通すなわち各制御アプリケーションソフト１０，４０に同様の車両・車外状態共通データベースが設けられ、たとえば制御アプリケーションソフト１０、４０は、実線矢印２００で示すように車両・車外状態共通データベースから状態データを受ける。また、たとえば制御アプリケーションソフト１０において加工されたシステムの実行の要求指示データは、点線矢印３００で示すように制御アプリケーションソフト１０からソフトウエアバス５０１を介して分散制御プラットフォーム２０（５０）におけるデータキューに一旦入れられた後、ソフトウエアバス５０１を介して制御アプリケーションソフト４０に送信される。また、ドライバソフト３０、６０において各アクチュエータから取得された状態データは、実線矢印２００’に示す如く車両・車外状態データベースに送信され、更新される。この更新は、全ＥＣＵにおける分散制御アプリケーションフレームワーク中の車両・車外状態共通データベースの各々に共通して一括に実行される。
【００２７】
なお、分散制御プラットフォーム２０（５０）は、システム構成情報すなわちシステムスケジューリングや制御アプリケーション配置情報を備えている。このシステムスケジューリングとは、各ＥＣＵ間あるいは／および各制御アプリケーション間における演算タイミングや起動タイミング等の順序のことである。また、制御アプリケーション配置情報とは、どのＥＣＵにどの制御アプリケーションが配置されているかの位置情報のことである。そして、各ＥＣＵにおける分散制御プラットフォーム２０（５０）の構造は各々、前述の時間同期を図る機能、位置透過性に関する機能およびスケジューリング機能、車両・車外状態共通データベースおよびデータキューを備える点で共通の構造を採用している。すなわち、制御アプリケーションソフトの各々に対して車両・車外状態データベースおよびデータキューを備える場合等は、単一のＥＣＵに備えられる制御アプリケーションソフトの数によりそれぞれのＥＣＵの分散制御プラットフォームにおいて備えられる車両・車外状態共通データベースおよびデータキューの数も変わってくるが、構造としては同一なものと解釈する。
【００２８】
なお、車両・車外状態共通データベースおよびデータキューは、各制御アプリケーションソフトの各々に対してそれぞれ設けられるようにしてもよいし、各ＥＣＵに対して１つづつ設けられるようにしてもよい。あるいは、車両・車外状態共通データベースを介される状態データの特性およびデータキューを介される要求指示データの特性に応じて車両・車外状態共通データベースおよびデータキューを配置するようにしてもよい。たとえば時間管理を一括して行った方が良い特性を有する状態データあるいは／および要求指示データを１つの群としてこの群に対応するように車両・車外状態共通データベースおよび／あるいはデータキューを各ＥＣＵ内に備えるようにしてもよい。この場合には各制御アプリケーションソフトの各々に対応して車両・車外状態共通データベースおよび／あるいはデータキューが備えられていない場合もありえる。
【００２９】
図３は、図１、図２を具現化した制御ソフトウエア構造およびこのソフトウエアを用いた制御装置を示す図である。なお、図１、図２と同等の構成には同様の符号を付し、説明を省略する。また、図３では図１、図２とは異なり、ＥＣＵを３つ備える例を示している。
【００３０】
ＥＣＵ１の分散制御プラットフォーム２０に車両・車外状態共通データベース２２とデータキュー２３が存在する。ＥＣＵ２においても分散制御プラットフォーム５０に車両・車外状態共通データベース５２、５４とデータキュー５３、５５が存在する。なお、車両・車外共通データベース５２とデータキュー５３は制御アプリケーションソフト４０に対応して設けられ、車両・車外状態共通データベース５４とデータキュー５５は制御アプリケーションソフト４１に対応して設けられている。このように、車両・車外状態共通データベース、およびデータキューは各々の制御アプリケーションソフトに対して各々１つづつ設けられている。ＥＣＵ３においても制御アプリケーションソフト７０に対応して分散制御プラットフォーム８０に車両・車外状態共通データベース８２とデータキュー８３が存在する。
【００３１】
ＥＣＵ１ないし３の各々の分散プラットフォーム２０，５０，８０に設けられる車両・車外状態共通データベース２２、５２、５４、８２には、各アクチュエータ等から全く同じ状態データがドライバソフトを介して送信され、共通の状態データとして蓄積・更新される。
【００３２】
なお、この状態データ１０１〜１０４は、制御アプリケーションソフト１０，４０，４１，７０で実現されるシステムにおいて必要とされる状態データであり、たとえば車両制御の場合、車体速度値、車輪速度値、エンジン回転数値、燃料噴射量値、車体加速度値等を挙げることができる。なおこのような状態データは、いずれかのシステムで必要なものであって、且つ複数のシステムで必要とされる場合においても、一義的な値として持てるものが好ましい。たとえば、車体挙動安定化システムとエンジンコントロールシステムとアンチスキッド制御システムとを備える場合、車体速度値は各システム共通の状態データ値であるべきであり、また車輪速度値、エンジン回転数値、燃料噴射量値、車体加速度値等も各システム共通の状態データ値であるべきである。
【００３３】
データキュー２３、５３，５５、８３は、制御アプリケーションソフト間の受け渡し時に、システムを実行するための要求指示データを一時記憶するためのものである。すなわち、制御アプリケーションソフト間で直接要求指示データの授受を行うと、制御アプリケーションソフト自体はデータの順位付けをする機能がないため、要求指示データを受ける側の制御アプリケーションソフトにおいて受けた要求指示データの順位付けをすることもできない。そこで、要求指示データの順位付け機能を分散プラットフォームに設け、一旦データを記憶するデータキューにおいて優先順位付けが行われる。すなわち、ネットワークで連結される全アプリケーションソフトにおける要求指示データ自体に予め優先度を持たせておき、この優先度に応じてデータキューで順位付けが成されるようにする。なお、車両制御における要求指示データの例としては、トルク要求指示値等を上げることができる。たとえば、エンジンコントロールシステムにおけるトルク要求指示値とはエンジン駆動トルク（あるいは車軸駆動トルク）であり、アンチスキッド制御システムにおけるトルク要求指示値とは、車輪の制動トルクとなる。このように、各システムに共通のディメンジョンの制御実行のための要求指示値を要求指示データとしてもよい。なお、これにかかわらず要求指示データとしては、各システム毎の独立した要求指示値を採用することにしてもよいし、前述の各システムに共通の要求指示値と各システム独特の要求指示値とを混在させるようにしてもよい。
【００３４】
また、データキュー２３，５３，５５，８３は、各々において要求指示データを各制御アプリケーションソフトから受ける受付用データキューと、各制御アプリケーションソフトへの要求指示データの発行を行う発行用データキューとをそれぞれ備えており、前述の如く要求指示データに予め定められた優先度に応じて、各受付用データキューにおいて受付、各発行用データキューにおいて制御要求指示の発信が行われている。
【００３５】
次に、分散制御プラットフォームおよびドライバソフトを介して各制御アプリケーションソフト間において送受信される状態データ１０１〜１０４およびシステム実行のための要求指示データ１０５の流れの一例を図３および図４に基づいて説明する。
【００３６】
図４の表に示すように本例においては、各制御アプリケーションソフト１０、４０、７０からの制御の要求指示に優先順位付けがなされている。すなわち制御アプリケーションソフト１０からの制御要求指示（点線矢印３００で示す）が最優先であり、次に制御アプリケーションソフト４０からの制御要求指示（点線矢印３０１で示す）が優先度２であり、最後に制御アプリケーションソフト７０からの制御要求指示（点線矢印３０２で示す）が優先度３である。なお、本例では制御アプリケーションソフト４１は他の制御アプリケーションソフトから制御要求指示を受けるのみで、制御アプリケーションソフト４１からの制御要求指示は出さないものとする。
【００３７】
まず、状態データ１０１〜１０４の流れについて説明する。なお、各状態データの流れのうち各ＥＣＵ内での流れは実線２００で示し、各ＥＣＵ間のネットワーク５００における流れは一点破線２０１で示す。
【００３８】
状態データ１０１〜１０４のうち状態データ１０１、１０３、１０４はネットワーク５００、ドライバソフト３０、６０、９０を介して各アクチュエータ等が定期的に検知した値であって、各車両・車外状態共通データベース２２，５２，５４、８２には共通の値として更新・記憶されている。また、状態データ１０２は制御アプリケーションソフト１０において演算等により加工された値が車両・車外状態共通データベース２２に記憶されている状態である。
【００３９】
まず、これらの状態データ１０１〜１０４のうち、状態データ１０２と１０３とがドライバソフト３０のメッセージフレーム３１に送られる。そしてこのメッセージフレーム３１はネットワーク５００を介してＥＣＵ２のドライバソフト６０と、ＥＣＵ３のドライバソフト９０に同時に送信される。そして、ドライバソフト６０とドライバソフト９０は、同時にメッセージフレーム３１の中の必要な状態データを各々、車両・車外状態共通データベース５２と車両・車外状態共通データベース８２とに格納する。すなわちＥＣＵ２においてはメッセージフレーム３１から状態データ１０２と状態データ１０３の双方を車両・車外状態共通データベース５２に記憶させ、ＥＣＵ３においてはメッセージフレーム３１の状態データ中、状態データ１０２のみを車両・車外状態共通データベース８２に記憶させる。このように、どの状態データを必要とするかおよび状態データを送信するタイミングは、各ＥＣＵ毎に管理する。その際、そのＥＣＵ内に実装されている各制御アプリケーションソフトが必要とする状態データのみを各ＥＣＵ単位あるいは制御アプリケーションソフト単位で管理する。よって状態データ１０３は、車両・車外状態共通データベース２２における値と車両・車外状態共通データベース５２，５４，８２とで同じ値が記憶されているため、メッセージフレーム３１に載せられても良いし、載せられなくてもよいが、制御アプリケーションソフト１０から制御アプリケーションソフト４０、７０に対して、次の演算タイミングでは、複数の状態データのうち、この状態データ１０２と状態データ１０３を使うように指示する場合には、メッセージフレームに載せる必要がある。しかしながら、この場合各ＥＣＵ単位、各制御アプリケーションソフト単位で車両・車外状態共通データベースを設置・管理すると、各車両・車外状態共通データベース間の状態データ授受の時間的な同期の一貫性が問題となる。この点については、全ＥＣＵ同等である分散プラットフォーム中に時間同期を図る機能を図５に示すように備えるようにして解決する。なお時間同期方法については図５に基づいて後述する。また、この時間同期の問題は後述する制御要求指示についても同等である。
【００４０】
次に、制御アプリケーションソフト４０において前もって演算等加工された状態データ１０４に相当する状態データ値が制御アプリケーションソフト４０より車両・車外状態共通データベース５２に送信される。そして、この状態データ１０４は車両・車外状態共通データベース５２より制御アプリケーションソフト４１に対応する車両・車外状態共通データベース５４に送信され、その後制御アプリケーションソフト４１に送信される。
【００４１】
次に、車両・車外状態共通データベース８２から制御アプリケーションソフト７０に向けて状態データ１０２が送信される。そして、制御アプリケーションソフト７０から車両・車外状態共通データベース８２に対してあらかじめ制御アプリケーションソフト７０内で演算等加工された状態データ１０１に相当する値が車両・車外状態共通データベース８２に送信される。
【００４２】
次に制御要求指示の流れについて説明する。なお、各ＥＣＵ内における制御要求指示の流れは点線３００、３０１等の点線で示し、各ＥＣＵ間のネットワーク状での流れはニ点破線３１０で示す。制御要求指示３００は、まず制御アプリケーションソフト１０から要求指示データ１０５をデータキュー２３に送信される。この制御要求指示はドライバソフト３０におけるメッセージフレーム３２にＥＣＵ２のドライバソフト６０にネットワーク５００を介して送信される。そしてこのドライバソフト６０から制御アプリケーションソフト４１に対応するデータキュー５５に送信される。
【００４３】
次に制御アプリケーションソフト４０からデータキュー５３への制御要求指示３０１により要求指示データ１０６が送信され、この要求指示データ１０６は制御アプリケーションソフト４１において使用されるためにデータキュー５５に送信される。そしてデータキュー５５から制御アプリケーションソフト４１に要求指示データ１０６が送信される。
【００４４】
次にＥＣＵ３においてデータキュー８３に記憶されている要求指示データ１０５が制御アプリケーションソフト７０に送信される。
【００４５】
図５に基づいて、各ＥＣＵ間および／あるいは各制御アプリケーションソフト間における時間の同期性の保証について説明する。なお、図５では説明の簡略化のため、制御アプリケーションソフト１０と制御アプリケーションソフト４０の２つについて説明するが、制御アプリケーションソフトが３つ以上ある場合でも同様の考え方を採用することができる。
【００４６】
図５に示すように、各制御アプリケーションソフトには制御アプリケーションソフト内での処理を確実に終了させなければならないデッドライン時間Ｔ１、Ｔ２が定義されている。なお、このデッドライン時間Ｔ１、Ｔ２は各々の制御アプリケーションソフトの処理演算内容等により統計的に確立されるものである。そしてこのデッドライン時間内に処理された演算結果が送信タスクに応じてメッセージ送信される。各制御アプリケーションソフトは定期的に（例えば６ｍｓ周期）に起動される言いかえれば演算開始されるため、デッドライン時間を各制御アプリケーションソフトに定義しておくと、送信タスクによる定期送信も可能となる。
【００４７】
また、制御アプリケーションソフトにおける処理演算中に他のノード等で計算された結果を受信して車両・車外状態共通データベースが更新され、これにより各制御アプリケーションソフトの処理に悪影響を与えないために、各アプリケーションソフトの起動時あるいは終了時等タイミングを限定して、且つ各車両・車外状態共通データベース２２，５２，５４，８２を一括して状態データの更新を行う。このようにシステム間の時間同期を、各制御アプリケーションソフトがもつデッドライン時間をベースに行えば、システムスケジューリングによる時間同期性の保証を確実に行うことができる。また、このような時間同期性を図る機能を分散制御プラットフォームに備えるようにすることで、各制御アプリケーションソフトにおける処理負荷の変化、あるいは割り込み処理や高優先度タスク処理等の外部要因による時間的な変動に影響されず、システム間での協調制御が可能となる。なお、時間同期の機能とは、データの一貫性を必要とする各制御アプリケーションソフト間あるいは／および各電子制御装置間におけるデータの一貫性を確保する機能を意味する。すなわち、時間同期を図ることができることで、データの一貫性も確保できることになる。なお、データの一貫性、時間同期機能の意味合いについても図５に詳述するが、簡単に言えば、各制御アプリケーションソフトにおける各々のアプリケーションソフトの演算タイミングが異なる場合、あるいは各センサ類の検出結果の各電子制御装置への受信タイミングあるいは演算タイミングが異なる場合、あるいは各電子制御装置における内部タイマのずれ、等により、たとえば（ｎ−＊）回目の演算タイミング（あるいは受信タイミング）により演算された結果のデータとｎ回目の演算タイミング（あるいは受信タイミング）により演算されたデータ例えば現在の演算タイミングで演算されたデータとを混在させて使用して別の演算等を行うことを防止する機能を言う。
以下に図５に基づく制御アプリケーションソフト１０，７０における処理タイミングについての具体例を説明する。
【００４８】
時刻ｔ１において制御アプリケーションソフト７０における処理が実行開始されはじめ、まずは自身が車両・車外状態共通データベース８２の状態データ１０２、データキュー８３の要求指示データ１０６の更新を行う。すなわちＥＣＵ３からＥＣＵ１に対して、新しい状態データ１０２および要求指示データ１０６を送信してもらう。制御アプリケーションソフト７０における処理の実行中の時刻ｔ２において制御アプリケーションソフト７０に比べて優先順位が高い制御アプリケーションソフト１０の処理が開始される。そして、自身の制御アプリケーションソフト１０の処理のデッドライン時間はＴ１で規定されている。この制御アプリケーションソフト１０における処理の初期時にも自身の車両・車外状態共通データベース２２およびデータキュー２３内の状態データおよび要求指示データの更新を行う。そして、制御アプリケーションソフト１０における処理は確実にデッドラインＴ１時点である時刻ｔ４までの間の時刻ｔ３に終了し、時刻ｔ４において送信タスクを受けてＥＣＵ３に対して送信がなされる。なお処理の最後には、自身の制御アプリケーションソフト１０から加工された状態データおよび要求指示データを車両・車外状態共通データベース２２およびデータキュー２３に送信する。
【００４９】
また、下位の制御アプリケーションソフト７０における処理も処理開始からデッドライン時間Ｔ２までの間である時刻ｔ５までに処理を終了する。なお処理の最後には、自身の制御アプリケーションソフト７０から加工された状態データを車両・車外状態共通データベース８２に送信する。
【００５０】
本発明は上述までの実施例に限定されることなく種々変形可能である。
【００５１】
たとえば、上述までの実施例では、車両・車外状態共通データベース２２、５２，５４，８２への各ドライバソフトを介して行われる状態データの送信および更新は時間同期性を確保するため一括して行われていたが、たとえば、現時点ある制御アプリケーションソフトにおける処理中であってこの処理中にデータ更新が行われるとシステムに支障をきたす可能性がある場合には、その状態データに対してのみ更新を待ち状態とし、制御アプリケーションソフト起動時、あるいは／および終了時に状態データを送信・更新するようにしてもよい。なお、制御アプリケーションソフトの処理中にデータ更新が行われるとシステムに支障をきたす可能性がある場合とは、たとえば制御アプリケーションソフト内における処理に状態データが用いられており、この状態データが演算処理中に更新されると、演算処理の元データの時間的な同期が取れなくなる場合等が考えられる。このような自体は、制御ソフトウエア構造の設計時に予め予測することが可能であるため、状態データの更新・送信の優先度を設定する際に、予め設定しておくようにするのが望ましい。
【００５２】
また、たとえば図３に示すＥＣＵ２には、同一のＥＣＵに複数の制御アプリケーションソフトが存在する。このような制御アプリケーションソフトの配置情報を分散制御アプリケーションフレームワーク中の分散制御プラットフォーム等に備えるようにし、この配置情報をもとに同一のＥＣＵ内に要求指示データあるいは状態データを送信する相手である制御アプリケーションソフトが存在する場合には、ネットワークを介さずに直接相手の車両・車外状態共通データベースを更新し、あるいは要求指示データを直接相手のデータキューに登録するようにしてもよい。あるいは、直接相手に更新あるいは登録するのではなくネットワークを介するようにしてもよい。
【図面の簡単な説明】
【図１】本発明の全体構成の概要を表すイメージ図である。
【図２】図１における分散制御アプリケーションフレームワーク２０，５０を主眼として見たイメージ図である。
【図３】図１、図２を具現化した制御ソフトウエア構造およびこのソフトウエアを用いた制御装置を示す図である。
【図４】図３における各ＥＣＵ内外のデータの送受信の状態および優先度を示す表である。
【図５】各ＥＣＵ間の時間機能を図るために分散制御プラットフォームが備える機能を説明するタイミングチャートである。
【符号の説明】
１、２，３…電子制御装置（ＥＣＵ）
１０，４０，４１，７０…制御アプリケーションソフト
２０、５０、８０…分散制御プラットフォーム
３０、６０、９０…ドライバソフト
２２、５２、５４、８２…車両・車外状態共通データベース
２３、５３、５５、８３…データキュー
１０１、１０２、１０３、１０４…状態データ
１０５、１０６…要求指示データ
５００…ネットワーク

Claims

複数の電子制御装置をネットワークを介して分散協調制御する制御ソフトウエア構造において、
各電子制御装置に備えられた各システムを実現するための各制御アプリケーションソフトよりデータ管理機能および時間同期機能を分離し、前記各制御アプリケーションソフトの下位の分散制御プラットフォーム中に、前記複数の電子制御装置に対して同一の当該データ管理機能および時間同期機能を配置したことを特徴とする制御ソフトウエア構造およびこの構造を用いた制御装置。
第１の電子制御装置と第２の電子制御装置とをネットワークを介して分散協調制御する制御ソフトウエア構造において、
前記第１の電子制御装置は、
少なくとも１つのシステムを実現するための少なくとも１つの制御アプリケーションソフトと、
前記制御アプリケーションソフトから分離されたデータ管理機能を備えた分散制御プラットフォームと、
前記制御アプリケーションソフトから前記分散制御プラットフォームを介して指示されるアクチュエータ駆動指令を受けたり、あるいは／および、前記分散制御プラットフォームにデータを送信するドライバソフトと、
を備え、
前記第２の電子制御装置は、
少なくとも１つのシステムを実現するための少なくとも１つの制御アプリケーションソフトと、
前記制御アプリケーションソフトから分離されたデータ管理機能を備えた分散制御プラットフォームと、
前記制御アプリケーションソフトから前記分散制御プラットフォームを介して指示されるアクチュエータ駆動指令を受けたり、あるいは／および、前記分散制御プラットフォームにデータを送信するドライバソフトと、
を備え、
前記第１の電子制御装置における分散制御プラットフォームと前記第２の電子制御装置における分散制御プラットフォームとが共通化されていることを特徴とする制御ソフトウエア構造およびこの構造を用いた制御装置。
複数の電子制御装置をネットワークを介して分散協調制御する制御ソフトウエア構造において、
各電子制御装置は、各システムを実現するための各制御アプリケーションソフトと、当該各制御アプリケーションソフトに備えられていないデータ管理機能を備える分散制御プラットフォームと、ドライバソフトと、を備え、
前記分散制御プラットフォームには、前記システムを実現するための要求指示データを一時記憶するデータキューと、前記システムを実行する際の状態データを一時記憶する状態共通データ部と、を前記各電子制御装置共通に備えることを特徴とする制御ソフトウエア構造およびこの構造を用いた制御装置。
複数の電子制御装置をネットワークを介して分散協調制御する制御ソフトウエア構造において、
各電子制御装置は、
各システムを実現するための時間同期機能を有さない各制御アプリケーションソフトと、
当該各電子制御装置に共通に、前記システム間、前記各制御アプリケーションソフト間および各電子制御装置間の通信を行う各通信ソフト間の時間同期を行う機能を有する分散制御プラットフォームと、
前記制御アプリケーションソフトから前記分散制御プラットフォームを介して指示されるアクチュエータ駆動指令を受けたり、あるいは／および、前記分散制御プラットフォームにデータを送信するドライバソフトと、
を備えたことを特徴とする制御ソフトウエア構造およびこの構造を用いた制御装置。
前記状態データは、各前記電子制御装置において一括して更新されることを特徴とする請求項３に記載の制御ソフトウエア構造およびこの構造を用いた制御装置。
前記要求指示データには予め優先度が設定されていることを特徴とする請求項３および請求項５に記載の制御ソフトウエア構造およびこの構造を用いた制御装置。
前記各電子制御装置ひいては前記各制御アプリケーションソフトから送信される前記要求指示データあるいは／および前記各制御アプリケーションソフトが受信する前記要求指示データの全てが前記分散制御プラットフォームのデータキューを介して送受信されることを特徴とする請求項３または請求項５または請求項６のいずれかに記載の制御ソフトウエア構造およびこの構造を用いた制御装置。
前記分散制御プラットフォームには前記制御アプリケーションソフトがどのＥＣＵに配置されているかの位置情報が設定されていることを特徴とする請求項１ないし請求項７のいずれかに記載の制御ソフトウエア構造およびこの構造を用いた制御装置。
前記時間同期機能は、前記制御アプリケーションソフトにおける処理のデッドライン時間に応じて定められた送信タイミングに基づきデータを送信することにより各電子制御装置における時間同期を図ることを特徴とする請求項１または請求項４に記載の制御ソフトウエア構造およびこの構造を用いた制御装置。
前記状態共通データ部と前記データキューは前記制御アプリケーションソフトの各々に対応して設けられており、前記データキューとして、他の前記制御アプリケーションソフトからの前記要求指示データを受ける要求受付データキューと、他の前記制御アプリケーションソフトへの前記要求指示データの発行を行うための要求発行データキューとを備えていることを特徴とする請求項３または請求項５ないし請求項７のいずれかに記載の制御ソフトウエア構造およびこの構造を用いた制御装置。
前記分散制御プラットフォームは、前記制御アプリケーションソフトの各々に対して備えられていることを特徴とする請求項１ないし請求項１０のいずれかに記載の制御ソフトウエア構造およびこの構造を用いた制御装置。