(57)【要約】【課題】ハードウェアの変更によってトリガ設計を行わなくても再利用できる車両用電子装置のソフトウェアシステムおよびソフトウェア設計方法を提供する。【解決手段】機能トリガ５１０〜５１３とソフトウェアトリガ６０４〜６０６を分け、機能トリガ５１０をソフトウェアタスク６０１〜６０３に対して対応付ける。そして、機能トリガ５１０〜５１３とソフトウェアトリガ６０４〜６０６をソフトウェア設計時に繋ぎ合わせる。このようなソフトウェア構造にすることにより、機能設計の際に、ハードウェアを全く意識することなく機能設計を行うことが可能となる。つまり、ハードウェアの変更や機能配置の変更をしてもその影響を受けないようにできるため、コンポーネントの再利用性を実現することができる。【選択図】図６
2007253792.tif 000002
【特許請求の範囲】
【請求項１】
車両制御ネットワークに備えられる車両用電子制御装置のソフトウェアシステムにおいて、
車両に関する制御を実行する機能（５０１〜５０９）が含まれた複数個のコンポーネント（１０１〜１０６）を備え、該コンポーネントが前記車両用電子制御装置に実装されるようになっており、
前記車両用電子制御装置に実装されたソフトウェアによって起動されるタスク（６０1〜６０３）に対して前記複数個のコンポーネントの前記機能を実行させる機能トリガ（５１０〜５１３）が対応付けられ、該タスクが前記機能トリガを発生させることで前記複数のプログラムもしくは制御ロジックを実行するように構成されていることを特徴とする車両用電子制御装置のソフトウェアシステム。
【請求項２】
前記タスクは、イベントタスク（６０１）と定期タスク（６０２、６０３）であり、前記イベントタスクは前記車両制御ネットワークもしくは前記車両用電子制御装置というハードウェアに起因して発生するイベントトリガ（６０４）に基づいて起動され、前記定期タスクは、前記車両用電子制御装置に備えられるタイマ機能もしくは前記車両制御ネットワークを通じて伝えられる同期タイマに起因して発生する一定周期の定期トリガ（６０５、６０６）であることを特徴とする請求項１に記載の車両用電子制御装置のソフトウェアシステム。
【請求項３】
前記定期タスクは、前記コンポーネントが動作しているか否かという状態を示す情報を保持し、動作していないという情報が保持されているときには、前記定期トリガに基づいて前記定期タスクが起動しても前記機能トリガを出力しないようになっていることを特徴とする請求項２に記載のソフトウェアシステム。
【請求項４】
車両制御ネットワークに備えられる複数の車両用電子制御装置に対してソフトウェアシステムを組み込むソフトウェア設計方法であって、
車両に関する制御を実行する機能（５０１〜５０９）を数個のコンポーネント（１０１〜１０６）に分割するステップと、
前記複数個のコンポーネントを上位から下位に階層構造化するステップと、
前記複数個のコンポーネントに対して、該複数個のコンポーネントそれぞれを実行させる機能トリガを割り当てることで実行シーケンスを設計するステップと、
前記複数個のコンポーネントをそれぞれ前記複数の車両用電子制御装置のいずれかに実装するステップと、
前記複数のコンポーネントに備えられる機能を詳細化するための分析を行うと共に該機能を構造化するステップと、
前記構造化された機能を実行する機能トリガを設定するステップと、
前記機能トリガを発生させるソフトウェアタスク（６０１〜６０３）に対して、前記機能トリガを対応付けて配置するタスク設計を行うステップと、を含んでいることを特徴とするソフトウェア設計方法。
【請求項５】
前記ソフトウェアタスクとして、イベントタスク（６０１）と定期タスク（６０２、６０３）を設け、これらソフトウェアタスクの実行される周波数に基づいて、該ソフトウェアタスクを実行するためのソフトウェアトリガ（６０４〜６０５）を割り当てることを特徴とする請求項４に記載のソフトウェア設計方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なるプラットフォーム上へ移植されるアプリケーション（機能を実現するためにさまざまな演算を行うプログラムのまとまり）ソフトウェアに適用される車両用電子制御装置のソフトウェアシステムおよびその設計方法に関するものである。
【背景技術】
【０００２】
従来、特許文献１において、アプリケーションソフトウェアを異なるプラットフォーム上へ移植（再利用）するソフトウェア構造が提案されている。
【０００３】
インターフェースとボディから成るコンポーネントという限られた機能範囲を持つことで、他のコンポーネントとは無関係という枠組みでアプリケーションソフトウェアを作成できるようにし、アプリケーションソフトウェアの再利用とプラットフォームの独立性を実現している。
【０００４】
また、コンポーネントの処理を開始するトリガ（イベントルーチン）設計においても、コンポーネント毎にトリガを設計する事でソフトウェアの再利用を可能としている。
【特許文献１】特開特開２００１−１０９６２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、車両制御開発では単にコンポーネント毎にトリガ設計するだけでは再利用性を実現できないという問題がある。これは、トリガを設計する際、トリガ発生の元となるハードウェアを意識して設計する必要があるためである。
【０００６】
例えば、トリガを定期的に発生させる場合、すなわち、そのトリガで起動する機能を定期的に動作させる場合、一般的にマイクロプロセッサ（以下、マイコンという）のタイマ機能を使用してそのトリガを発生させる。また、他のＥＣＵに実装されている機能と同期してトリガを発生させるような場合、ＦｌｅｘＲａｙに代表されるタイム・トリガ型の通信プロトコルの同期性を利用してトリガを発生させることも考えられる。例えば、定期的に、しかも他のＥＣＵに実装されている機能と同期してトリガを発生させる場合、その通信コントローラの持つタイマを利用して発生させる。さらに、他のＥＣＵに実装されている機能からの制御要求に同期してトリガを発生させる場合、ネットワークを通じて送られてくる制御要求の受信により発生させる。
【０００７】
したがって、これらいずれの場合においても車両制御設計におけるトリガ設計ではハードウェアを意識して設計する必要があり、機能（アプリケーション）を実装するハードウェアが変わると、トリガ設計をやり直さなければならず、再利用できないという問題が発生する。
【０００８】
本発明は上記点に鑑みて、ハードウェアの変更によってトリガ設計を行わなくても再利用できる車両用電子装置のソフトウェアシステムおよびソフトウェア設計方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明では、車両に関する制御を実行する機能（５０１〜５０９）が含まれた複数個のコンポーネント（１０１〜１０６）を備え、該コンポーネントが車両用電子制御装置に実装されるようになっており、車両用電子制御装置に実装されたソフトウェアによって起動されるタスク（６０1〜６０３）に対して複数のプログラムもしくは制御ロジックを実行させる機能トリガ（５１０〜５１３）が対応付けられ、該タスクが機能トリガを発生させることで複数のプログラムもしくは制御ロジックを実行するように構成されていることを特徴としている。
【００１０】
このようなソフトウェア構造にすることにより、機能設計の際に、ハードウェアを全く意識することなく機能設計を行うことが可能となる。つまり、ハードウェアの変更や機能配置の変更をしてもその影響を受けないようにできるため、コンポーネントの再利用性を実現することができる。
【００１１】
例えば、タスクをイベントタスク（６０１）と定期タスク（６０２、６０３）で構成し、車両制御ネットワークもしくは車両用電子制御装置というハードウェアに起因して発生するイベントトリガ（６０４）に基づいてイベントタスクを起動し、車両用電子制御装置に備えられるタイマ機能もしくは車両制御ネットワークを通じて伝えられる同期タイマに起因して発生する一定周期の定期トリガ（６０５、６０６）にて定期タスクを起動することができる。
【００１２】
この場合、定期タスクにてコンポーネントが動作しているか否かという状態を示す情報を保持し、動作していないという情報が保持されているときには、定期トリガに基づいて定期タスクが起動しても機能トリガを出力しないようすることもできる。
【００１３】
このように、コンポーネントが動作中あるか否かの状態を示す情報を保持し、この情報に基づいて機能トリガを発生させるか否かを決める仕組みを取り入れることで機能の動作と実体となる実行単位（Ｒｕｎｎａｂｌｅ  Ｅｎｔｉｔｙ）の動作の整合を計ることが出来る。
【００１４】
また、本発明を車両制御ネットワークに備えられる複数の車両用電子制御装置に対してソフトウェアシステムを組み込むソフトウェア設計方法として把握することもできる。
【００１５】
この場合、車両の制御に用いられる機能を、該車両に関する制御を実行するための複数個のコンポーネント（１０１〜１０６）に分割するステップと、複数個のコンポーネントを上位から下位に階層構造化するステップと、複数個のコンポーネントに対して、該複数個のコンポーネントそれぞれ実行させる機能トリガを割り当てることで実行シーケンスを設計するステップと、複数個のコンポーネントをそれぞれ複数の車両用電子制御装置のいずれかに実装するステップと、複数のコンポーネントに備えられる機能（５０１〜５０９）を詳細化するための分析を行うと共に該機能を構造化するステップと、構造化された機能を実行する機能トリガを設定するステップと、機能トリガを発生させるソフトウェアタスク（６０１〜６０３）に対して、機能トリガを対応付けて配置するタスク設計を行うステップと、を含んでいることを特徴とする。
【００１６】
このようなソフトウェア設計によれば、機能設計の際に、ハードウェアを全く意識することなく機能設計を行うことが可能となる。つまり、ハードウェアの変更や機能配置の変更をしてもその影響を受けないようにできるため、コンポーネントの再利用性を実現することができる。
【００１７】
なお、上記各手段の括弧内の符号は、後述する実施形態に記載の具体的手段との対応関係を示すものである。
【発明を実施するための最良の形態】
【００１８】
（第１実施形態）
本発明の第１実施形態について、図に基づいて説明する。
【００１９】
図１は、車両制御ネットワークシステムに備えられる機能構造の一部を示した概念図である。もちろん、車両制御ネットワークシステムには、図１に示される機能構造以外にも様々な機能が備えられるが、ここでは本実施形態での説明に用いる機能のみを図１中に示してある。
【００２０】
図１に示されるように、車両制御ネットワークシステムに備えられる機能（コンポーネント）として、例えば、最上流に車両コーディネータ１０１があり、その下流に車両挙動コーディネータ１０２がある。そして、車両挙動コーディネータ１０２の下流にパワートレインコーディネータ１０３が配置され、さらにこのパワートレインコーディネータ１０３の下流にエンジン制御コンポーネント１０４とトランスミッション制御コンポーネント１０５が配置されている。また、車両挙動コーディネータ１０２には、パワートレインコーディネータ１０３に加えてブレーキ制御コンポーネント１０６も配置されている。
【００２１】
車両コーディネータ１０１は、ドライバ操作（アクセルペダルやブレーキペダルの操作）による情報からドライバが車両に対して要求する動作の要求量、例えば要求加減速度や要求ヨーレートといった形で算出し、下位の車両挙動コーディネータ１０２に渡す。
【００２２】
車両挙動コーディネータ１０２では、上位の車両コーディネータ１０１から渡されるドライバの要求に基づいた車両運動の要求を安定的に実現する瞬間的な車両挙動要求を演算する。例えば要求車軸トルクや要求制動トルク等の要求値をそれぞれパワートレインコーディネータ１０３やブレーキ制御コンポーネント１０６に渡す。
【００２３】
パワートレインコーディネータ１０３では、上位の車両挙動コーディネータ１０２から渡される要求車軸トルク等の要求値を実現するために必要な要求エンジントルクや要求ギア等の要求値を演算し、それぞれエンジン制御コンポーネント１０４やトランスミッション制御コンポーネント１０５に渡す。これにより、各制御コンポーネント１０４、１０５は、要求値を実現するように対象となるアクチュエータ、例えばエンジンスロットルやオートマッチックトランスミッション（以下、ＡＴという）を制御する。
【００２４】
同様に、ブレーキ制御コンポーネント１０６も上位の車両挙動コーディネータ１０２から渡される要求制動トルクを実現するために上記のような制御を行い、例えばＡＢＳアクチュエータにおけるポンプ駆動用のモータや各種制御弁を駆動することで、各車輪に対して制動力を発生させる。
【００２５】
図２は、図１で示した車両機能構造を構成する各コンポーネントの処理シーケンスを示した図である。
【００２６】
車両コーディネータ１０１は、定期的に発行される機能トリガ２１１により起動し、所定の期間Ｔ１で処理を実行する。この期間中に、車両コーディネータ１０１から下位の車両挙動コーディネータ１０２に対して制御要求が発行され、ドライバが車両に対して要求する動作の要求量が伝えられる。
【００２７】
車両挙動コーディネータ１０２は、車両コーディネータ１０１から発行された制御要求を機能トリガ２１２として起動し、所定の期間Ｔ２で処理を実行する。この期間中に、車両挙動コーディネータ１０２から下位のパワートレインコーディネータ１０３とブレーキ制御コンポーネント１０６に対して制御要求が発行され、要求車軸トルクや要求制動トルク等の要求値が伝えられる。
【００２８】
パワートレインコーディネータ１０３は、車両挙動コーディネータ１０２から発行された制御要求を機能トリガ２１３として起動し、所定の期間Ｔ３で処理を実行する。この期間中に、パワートレインコーディネータ１０３から下位のエンジン制御コンポーネント１０４とトランスミッション制御コンポーネント１０５に対して制御要求が発行され、要求エンジントルクや要求変速段等の要求値が伝えられる。
【００２９】
エンジン制御コンポーネント１０４は、車両挙動コーディネータ１０２から発行される制御要求の発行タイミングと関係なく独立で定期的に発行される機能トリガ２１４により起動し、所定の期間Ｔ４で処理を実行する。
【００３０】
トランスミッション制御コンポーネント１０５は、車両挙動コーディネータ１０２から発行される制御要求の発行タイミングと関係なく独立で定期的に発行される機能トリガ２１５により起動し、所定の期間Ｔ５で処理を実行する。
【００３１】
同様に、ブレーキ制御コンポーネント１０６は、車両挙動コーディネータ１０２から発行される制御要求の発行タイミングと関係なく独立で定期的に発行される機能トリガ２１６により起動し、所定の期間Ｔ６で処理を実行する。
【００３２】
図３は、車両制御ネットワークシステムの構成図である。各ＥＣＵ３０１〜３０４が通信線３０５を介して接続されることでネットワークが構築され、相互にデータを通信することで車両全体を制御する。
【００３３】
エンジンを制御するエンジンＥＣＵ３０１とＡＴを制御するＡＴ−ＥＣＵ３０２とブレーキを制御するブレーキＥＣＵ３０３と車両の挙動を安定させるための演算を行い、要求値を各ＥＣＵに送信する車両挙動（Ｖｅｈｉｃｌｅ  Ｍｏｔｉｏｎ）ＥＣＵ３０４など、車の制御に関わるＥＣＵ３０１〜３０４が通信線３０５に接続され通信を行う。
【００３４】
図４は、図２で示した機能構造を構成する各機能（コンポーネント）を図３で示した車両制御ネットワークシステムを構成する各ＥＣＵに分散配置したときの一例を示している。
【００３５】
図４では、車両コーディネータ１０１と車両挙動コーディネータ１０２は車両挙動ＥＣＵ３０４に配置され、ブレーキ制御コンポーネント１０６はブレーキＥＣＵ３０３に配置され、パワートレインコーディネータ１０３とエンジン制御コンポーネント１０４はエンジンＥＣＵ３０１に配置され、トランスミッション制御コンポーネント１０５はＡＴ−ＥＣＵ３０２に配置される。
【００３６】
なお、ここでは各機能は、その機能が１つにまとまった形態で各ＥＣＵに組み込まれているが、必ずしも１つにまとまった形態とされる必要はなく、１つの機能を複数のＥＣＵに分割して組み込む形態とすることもできる。
【００３７】
図５は、エンジンＥＣＵ３０１に配置されたパワートレインコーディネータ１０３とエンジン制御コンポーネント１０４の各機能を詳細化するための分析を行い、分析した機能を構造化したものと、それらの起動トリガを表したものである。
【００３８】
パワートレインコーディネータ１０３に含まれる機能を詳細に分析し、それを構造化すると、プログラム・制御ロジック５０１〜５０４のように分割される。このように分割された機能の１つ１つがソフトウェア上の実行単位に相当するもので、この実行単位をＲｕｎｎａｂｌｅ  Ｅｎｔｉｔｙ（ＲＥ）と呼ぶ。同様に、エンジン制御コンポーネント１０４は、ＲＥ５０５〜５０９に分割される。
【００３９】
また、図中の矢印５１４〜５２２はデータの流れを示し、各ＲＥ５０１〜５０４およびＲＥ５０５〜５０８で演算された結果を次のＲＥに渡す様を示しており、ＲＥの実行順序も表している。ただし、矢印５１４は、パワートレインコーディネータ１０３の上位に位置する車両挙動コーディネータ１０２からの制御要求であり、コンポーネント間のＩ／Ｆでもある。
【００４０】
同様に、矢印５１８もパワートレインコーディネータ１０３からエンジン制御コンポーネント１０４への制御要求に相当する。矢印５１０〜５１３は、ＲＥ５０１〜５０９を実行する機能トリガで、機能トリガ５１０によりＲＥ５０１、５０２が実行され、機能トリガ５１１によりＲＥ５０３、５０４が実行され、機能トリガ５１２によりＲＥ５０５〜５０７が実行され、機能トリガ５１３によりＲＥ５０８、５０９が実行されることを示している。
【００４１】
機能トリガ５１０は、パワートレインコーディネータ１０３の上位に相当する車両挙動コーディネータ１０２からの制御要求を受けたことに同期して発生するトリガ（ＰＴ＿ＥＶＥＮＴ＿Ｔｒｉｇｇｅｒ）である。機能トリガ５１１は、８ｍｓｅｃ毎に発生するトリガ（ＰＴ＿８ｍ＿Ｔｒｉｇｇｅｒ）である。機能トリガ５１２は、４ｍｓｅｃ毎に発生するトリガ（ＰＴ＿４ｍ＿Ｔｒｉｇｇｅｒ）である。そして、機能トリガ５１３も、８ｍｓｅｃ毎に発生するトリガ（ＰＴ＿８ｍ＿Ｔｒｉｇｇｅｒ）である。
【００４２】
図６は、エンジンＥＣＵ３０１に実装されるＲＥ５０１〜５０９及びこれらを実行する機能トリガ５１０〜５１３とタスクとの関係を示したタイミングチャートである。また、図７は、各タスク（ソフトウェアタスク）６０１〜６０３と機能トリガ５１０〜５１３との対応付けと、機能トリガ５１０〜５１３とそれに起因して動作する各ＲＥ５０１〜５０９との対応関係を示した模式図である。
【００４３】
タスク６０１〜６０３は、各ＥＣＵに実装されているＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）等のソフトウェアによって起動されるもので、図６に示されるようにソフトウェアトリガ６０４〜６０６が各タスクの起動要因となる。これらソフトウェアトリガ６０４〜６０６はハードウェアに起因したトリガで、例えば、ソフトウェアトリガ６０５、６０６はマイコンの内部タイマによって生成されるか、もしくは通信線３０５がＦｌｅｘＲａｙの様なタイム・トリガ型であれば、その同期タイマによって生成される。
【００４４】
例えば、図６に示すように、割り込み処理を実行するようなイベントタスク６０１の実行トリガとしては、ネットワークデータの受信に起因して発生するソフトウェアトリガ６０４（Ｔｒｉｇｇｅｒ＿Ｅｖｅｎｔ＿Ａ）が用いられる。
【００４５】
なお、図６中において、ソフトウェアトリガ６０５、６０６や定期タスク６０２、６０３に対して添え字（ａ〜ｄ）を付してあるが、一定周期毎に繰り返し発生するソフトウェアトリガ６０５、６０６やそれに基づいて動作する定期タスク６０２、６０３の対応関係を見やすくするために行ったものである。
【００４６】
そして、図７に示されるように、各タスク６０１〜６０３には、各ＲＥ５０１〜５０９の動作要因となる機能トリガ５１０〜５１３が割り当て（対応付け）られ、その機能トリガ５１０〜５１３によって各ＲＥ５０１〜５０９が動作する。
【００４７】
続いて、上述した図１〜６を参照して本実施形態におけるソフトウェア設計方法について説明する。
【００４８】
車両制御開発では、まず図１に示すような機能構造を設計する。機能構造は車両全体の機能を分割し、機能を実現するための演算に必要な車両の可観測量（例えば車速など）や他の機能からの要求値及び他の機能へ出力する要求値などのＩ／Ｆを規定してコンポーネントを構成し、各コンポーネント間の関係を明確にして、階層構造化する。本実施形態では、図１に示すように車両の駆動及び制動、それらを使用したスタビリティを実現する機能構造を階層構造化したものを例に挙げている。
【００４９】
さらに、車両全体としての機能が正常に動作するよう各コンポーネントの実行条件、タイミング、すなわち実行シーケンスを設計する。具体的には各コンポーネントを動作させるトリガ、機能トリガを割り当てる。そして各機能トリガは定期及び制御要求等のイベントといった形で、その発生条件を定義する。図２は、本実施形態における実行シーケンスを示したものに相当する。このとき、各コンポーネントの機能トリガ２１１〜２１６はハードウェアを全く意識せず、機能実現の観点からのみ設定される。
【００５０】
機能構造設計の後、車両制御ネットワークシステムを構成する各ＥＣＵに各コンポーネントを実装していく。例えば、本実施形態の場合、車両制御ネットワークシステムが図３に示す構造となっているため、各コンポーネントを図４に示すように配置する。
【００５１】
このとき、ネットワークに流れるデータも決まる。本実施形態では車両挙動コーディネータ１０２がブレーキ制御コンポーネント１０６とパワートレインコーディネータ１０３に対して発行する制御要求とパワートレインコーディネータ１０３がトランスミッション制御コンポーネント１０５に対して発行する制御要求がネットワークでやり取りされる。
【００５２】
また、図中には記されていないが車両にはその状態量を観測するための各種センサが備えられている。各種センサは各ＥＣＵに接続され、各種センサの検出信号は各コンポーネントにおける制御量の演算等に用いられる。こうした車両の可観測量もネットワークで通信され、どの可観測量が通信されるかは機能配置によって決定される。
【００５３】
各ＥＣＵにコンポーネントを配置した後、ソフトウェア設計を行う。本実施形態では、ソフトウェア設計の一例として、エンジンＥＣＵ３０１のソフトウェア設計を行う場合について説明する。
【００５４】
エンジンＥＣＵ３０１には、図４に示したように、パワートレインコーディネータ１０３とエンジン制御コンポーネント１０４が配置されているので、各コンポーネントに含まれる機能を詳細化するための分析を行ったのち、その各機能の実行単位にとなるＲＥを構造化し、さらに各ＲＥを実行する機能トリガを設定する。図５は、そのソフトウェア構造を示したものである。
【００５５】
図２の処理シーケンスで示したように、パワートレインコーディネータ１０３は上位の車両挙動コーディネータ１０２からの制御要求をトリガとして実行される。この制御要求が図５におけるデータ５１４であり、この要求が発行された事により同期して発生するトリガが機能トリガ５１０に当たる。この機能トリガ５１０が発生することによりパワートレインコーディネータ１０３が実行される。すなわち、パワートレインコーディネータ１０３を構成しているＲＥ５０１〜５０４が実行される。
【００５６】
但し、コンポーネントの実行タイミングで、それを構成するＲＥのすべてがそのタイミングで実行されるとは限らない。例えば１６ｍｓｅｃ毎に実行されるコンポーネントの一部に温度などを元に所望の演算をするＲＥが存在する場合について考えてみる。通常、温度センサはレスポンス、つまり検出信号の発生周波数が遅いため、そのような周波数の遅いデータを使用した演算を１６ｍｓｅｃという早い周期で実行しても意味がない。そのため、温度などを元に所望の演算をするＲＥのみ、例えば１００ｍｓｅｃ毎に演算し、その結果をその他の１６ｍｓｅｃ毎に動作するＲＥに渡しても、そのコンポーネント自体の制御には全く問題ない上、ＣＰＵへの処理負荷を軽減することができる。
【００５７】
したがって、上記のように各コンポーネントに含まれる機能を詳細化してＲＥの構造化を行ったときに、その結果として各機能の周波数がその機能の上位に存在する機能などに基づいて決められる場合には、それに応じた機能トリガ設計を行うのが好ましい。
【００５８】
本実施形態ではパワートレインコーディネータ１０３を構成するＲＥのうち、ＲＥ５０１、５０２を上位からの制御要求に同期したイベントタイプの機能トリガであるイベントトリガ５１０で実行し、その他のＲＥ５０３、５０４は８ｍｓｅｃで定期的に発生する機能トリガである定期トリガ５１１で実行する。エンジン制御コンポーネント１０４についても同様で、エンジン制御コンポーネント１０４を構成するＲＥのうち、ＲＥ５０５、０６、５０７を４ｍｓｅｃで定期的に発生する機能トリガである定期トリガ５１２で実行し、ＲＥ５０８、５０９を８ｍｓｅｃで定期的に発生する機能トリガである定期トリガ５１３で実行する。これらの機能トリガはハードウェアを全く意識せず、機能実現の観点からのみ設定する。
【００５９】
各ＥＣＵに実装される機能の詳細設計（機能の分割や機能トリガの設計）が決まったら、タスク設計を行い、図６に示すように各タスクに機能トリガを配置する。本実施形態では、タスクとして、イベントタスク６０１、定期タスク６０２、定期タスク６０３を設定した例を示してある。これらのタスクは、それぞれソフトウェアトリガ６０４〜６０６に起因してＯＳ等によって起動し、ソフトウェアトリガ６０４〜６０６はハードウェアに起因して発生する。イベントトリガであるソフトウェアトリガ６０４はネットワークデータの受信に起因する。これは、パワートレインコーディネータ１０３の上位にある車両挙動コーディネータ１０２からの制御要求が、車両挙動コーディネータ１０２が車両挙動ＥＣＵ３０４に配置されているため、その制御要求はネットワークを通じてもたらされ、そのネットワークデータ受信同期して動作する。
【００６０】
したがって、ソフトウェアトリガ６０４を要因として動作するイベントタスク６０１は、車両挙動コーディネータ１０２からの制御要求（ネットワークデータ受信）に同期して動作することになる。
【００６１】
また、定期トリガであるソフトウェアトリガ６０５、６０６はマイコンの持つタイマ機能に起因して発生するトリガである。本実施形態では、ソフトウェアトリガ６０５は４ｍｓｅｃ毎に発生し、ソフトウェアトリガ６０６は８ｍｓｅｃ毎に発生する。なお、この定期トリガは、通信線３０５がＦｌｅｘＲａｙの様なタイム・トリガ型であれば、その同期タイマーに起因するトリガであってもよい。よって定期タスク６０２は４ｍｓｅｃ毎に動作し、定期タスク６０３は８ｍｓｅｃ毎に動作する。
【００６２】
以上のように、ハードウェアに起因するソフトウェアトリガ６０４〜６０６の発生でＯＳが対応するタスク６０１〜６０３を起動する。そして、各タスク６０１〜６０３にはＲＥ５０１〜５０９を動作させる機能トリガ５１０〜５１３を割り当てる。イベントタスク６０１には機能トリガ５１０が割り当てられ、イベントタスク６０１の動作により機能トリガ５１０が発生し、この機能トリガ５１０によりＲＥ５０１、５０２は車両挙動コーディネータ１０２からの制御要求に同期して動作する。
【００６３】
ここで、例えば、パワートレインコーディネータ１０３において、ＲＥ５０３、５０４による機能の実行周期を機能設計の段階で７．５ｍｓｅｃとして設計したとする。すなわち機能トリガ５１１は７．５ｍｓｅｃ周期で起動するトリガとして設計される。このとき、ＲＥ５０３、５０４を８ｍｓｅｃ周期で動作しても機能の実現において問題ない場合には、ＲＥ５０３、５０４を動作させる機能トリガ５１１を８ｍｓｅｃ毎で動作する定期タスク６０２に割り当てても良い。
【００６４】
ＲＥ５０１とＲＥ５０２はパワートレインコーディネータ１０３の制御ロジックであり、上位にある車両挙動コーディネータ１０２から発行される制御の要求値となるデータ５１４（図５参照）、例えば、要求車軸トルクを表すデータを受け取り、車両におけるパワートレインの状態に応じて受け取った要求車軸トルクを加工する。
【００６５】
例えば、現在の出力トルク、車速などの車両状態から実現可能な要求値になるよう要求車軸トルクを加工するなどの演算を行う。また、定期タスク６０２には機能トリガ５１１が割り当てられ、定期タスク６０２の動作により機能トリガ５１１が発生し、この機能トリガ５１１により４ｍｓｅｃ毎にＲＥ５０５〜５０７が動作する。
【００６６】
ＲＥ５０５〜５０７はエンジン制御コンポーネント１０４の制御ロジックであり、上位にあるパワートレインコーディネータ１０３から発行される制御の要求値となるデータ５１８（図５参照）、例えば、要求エンジントルクを表すデータを受け取り、実際のアクチュエータの制御量を演算する。例えば、スロットル開度、噴射量、点火時期などの制御量を演算し、これらの制御量を基に図示しないエンジンを構成するアクチュエータ、電子制御スロットル、電子制御式燃料噴射装置、電子制御式イグニッション装置などのアクチュエータを作動させ、上位から発行された要求エンジントルクを実現する。
【００６７】
定期タスク６０３には機能トリガ５１１と機能トリガ５１３が割り当てられ、定期タスク６０３の動作により機能トリガ５１１と機能トリガ５１３が発生し、機能トリガ５１１により８ｍｓｅｃ毎にＲＥ５０３、５０４が動作する。
【００６８】
ＲＥ５０３、５０４は、ＲＥ５０１、５０２と同様、パワートレインコーディネータ１０３の制御ロジックであり、ＲＥ５０１、５０２で演算（車両挙動コーディネータ１０２から発行された要求車軸トルクを車両状態に応じて加工）した要求車軸トルクを実現させるため、受け取った要求車軸トルクに基づいて、下位のエンジン制御コンポーネント１０４とトランスミッション制御コンポーネント１０５への制御要求値となる要求エンジントルクと要求変速段を演算する。
【００６９】
そして、演算された要求エンジントルクのデータ５１８は、下位のエンジン制御コンポーネント１０４へ渡されるが、パワートレインコーディネータ１０３とエンジン制御コンポーネント１０４は共にエンジンＥＣＵ３０１に実装されているため、エンジンＥＣＵ３０１内部で受け渡しが為される。
【００７０】
一方、演算された要求変速段のデータは、下位のトランスミッション制御コンポーネント１０５へ渡されるが、トランスミッション制御コンポーネント１０５がＡＴ−ＥＣＵ３０２に実装されているため、通信線３０５を介してネットワークを介して渡される。また、定期トリガ５１３により８ｍｓｅｃ毎にＲＥ５０８、５０９が動作する。
【００７１】
ＲＥ５０８とＲＥ５０９は、ＲＥ５０５〜５０７と同様、エンジン制御コンポーネント１０４の制御ロジックであり、ＲＥ５０５〜５０７が行うアクチュエータの制御量を演算するために必要なデータを演算する。例えば、図中にはないがエンジンに備えられているエンジン回転数センサやエンジン水温センサ、エアフロセンサなどのセンサ値を基に推定エンジントルクなどを演算し、それらを示すデータ５２２をＲＥ５０７へ受け渡す。
【００７２】
なお、図６中において、定期タスク６０３−ｂにおいて、イベントタスク６０１が機能トリガ５１０を発行したときに定期タスク６０３が発行していた機能トリガ５１１とその機能トリガによって動作するＲＥ５０３、５０４を点線で表してある。これは、このタイミングでは機能トリガ５１１の発生及びＲＥ５０３、５０４の実行が為されないことを意味している。
【００７３】
ＲＥ５０３、５０４共にパワートレインコーディネータ１０３の一部であるが、そもそもパワートレインコーディネータ１０３は車両挙動コーディネータ１０２からの制御要求、すなわち機能トリガ５１０が発行されて動作するコンポーネントであるので、定期タスク６０３−ｂ動作時にはパワートレインコーディネータ１０３は動作していない。
【００７４】
しかし、定期タスク６０３は定期的に動作するので、その都度必ず機能トリガ５１１を発生させてしまうとパワートレインコーディネータ１０３が機能していないのに、その実体となるＲＥ５０３、５０４が実行されてしまう。そこで、パワートレインコーディネータ１０３が動作中あるいは停止中等の状態を示す情報を保持し、タスク６０３では、この情報を見て機能トリガ５１１を発生させる仕組みを入れることで機能の動作と実体となるＲＥの動作の整合を計ることが出来る。もちろん、コンポーネント（機能）の動作状態に関わらずＲＥを実行しても良い。
【００７５】
以上のように、機能（コンポーネント）を動作させる機能トリガ５１０〜５１３とソフトウェア上で実際にプログラムを実行するソフトウェアトリガ６０４〜６０６を分け、機能トリガ５１０をソフトウェアタスク６０１〜６０３に対して対応付けしている。そして、機能トリガ５１０〜５１３とソフトウェアトリガ６０４〜６０６をソフトウェア設計時に繋ぎ合わせている。
【００７６】
このようなソフトウェア構造にすることにより、機能設計の際に、ハードウェアを全く意識することなく機能設計を行うことが可能となる。つまり、ハードウェアの変更や機能配置の変更をしてもその影響を受けないようにできるため、コンポーネントの再利用性を実現することができる。
【００７７】
例えば、本実施形態でも説明した通り、通信線３０５にＦｌｅｘＲａｙの様なタイム・トリガ型を採用し、高い精度で分散配置された各コンポーネントを同期して動作させようとした場合でも、その通信コントローラの内部タイマに起因したソフトウェアトリガ６０４〜６０６によるタスク設計を行い、機能トリガ５１０〜５１３をそれらのタスク６０１〜６０３に割り当てることで実現する。したがって、機能設計内容を変更する必要は全くない。
【００７８】
また、車両挙動コーディネータ１０２をパワートレインコーディネータ１０３と同じエンジンＥＣＵ３０１に配置した場合、ネットワークデータ受信に起因して発生していたソフトウェアトリガ６０４を、制御要求の更新（ＲＡＭの更新）に起因して発生させるように変更するだけでよく、同様に機能構設計内容を変更する必要はない。
【００７９】
（他の実施形態）
上記実施形態では、車両制御ネットワークシステムに備えられる機能構造の一例として、ドライバの要求に基づいた車両運動の要求を安定的に実現する車両挙動の制御を司る各機能について説明したが、説明した機能構造以外にも様々な機能が備えられる。そのような機能構造全般に対して、本発明を適用することが可能である。
【図面の簡単な説明】
【００８０】
【図１】本発明の第１実施形態における車両制御ネットワークシステムに備えられる機能構造の一部を示した概念図である。
【図２】図１で示した車両機能構造を構成する各コンポーネントの処理シーケンスを示した図である。
【図３】車両制御ネットワークシステムの構成図である。
【図４】図２で示した機能構造を構成する各機能（コンポーネント）を図３で示した車両制御ネットワークシステムを構成する各ＥＣＵに分散配置したときの一例を示した模式図である。
【図５】エンジンＥＣＵに配置されたパワートレインコーディネータとエンジン制御コンポーネントの各コンポーネントをソフトウェアとして実装する際の実行単位とそれらの起動トリガを示した模式図である。
【図６】エンジンＥＣＵに実装されるＲＥ及びこれらを実行する機能トリガとタスクとの関係を示したタイミングチャートである。
【図７】各タスクと機能トリガとの対応付けと、機能トリガとそれに起因して動作する各ＲＥとの対応関係を示した模式図である。
【符号の説明】
【００８１】
１０１…車両コーディネータ、１０２…車両挙動コーディネータ、１０３…パワートレインコーディネータ、１０４…エンジン制御コンポーネント、１０５…トランスミッション制御コンポーネント、１０６…ブレーキ制御コンポーネント、２１１〜２１６機能トリガ、３０１…エンジンＥＣＵ、３０２…ＡＴ−ＥＣＵ、３０３…ブレーキＥＣＵ、３０４…車両挙動ＥＣＵ、３０５…通信線、５０１〜５０４…制御ロジック、５１０…イベントトリガ（機能トリガ）、５０１〜５０９…ＲＥ、５１１〜５１３…定期トリガ（機能トリガ）、５１４〜５２２…データ、６０１…イベントタスク、６０２、６０３…定期タスク、６０４〜６０６…ソフトウェアトリガ。
【図１】
2007253792.tif 000003
【図２】
2007253792.tif 000004
【図３】
2007253792.tif 000005
【図４】
2007253792.tif 000006
【図５】
2007253792.tif 000007
【図６】
2007253792.tif 000008
【図７】
2007253792.tif 000009