(57)【要約】本発明は，実装されたコンポーネントからなるソフトウェアを有する電子制御ユニットと，複数のアプリケーションを選択的に接続するために，情報交換に関して最適化された複数のソフトウェアインターフェイス（１０１，１０２，１０３，１０４，１０５，１０６）に関し，ソフトウェアは，接続可能なアプリケーションのために，コンポーネントのアプリケーション固有の少なくとも１つのソフトウェアコードを有し，ソフトウェアコードは，アプリケーションの接続により起動される。さらに，本発明は，電子制御ユニット（１００）用のソフトウェアアーキテクチャを仕様化する適切な方法に関する。【選択図】１
2007507017.tif 000002
【特許請求の範囲】
【請求項１】
実装されたコンポーネントからなるソフトウェアを有する電子制御ユニットであって：
前記電子制御ユニットは，複数のアプリケーションを選択的に接続するために，情報交換に関して最適化された複数のソフトウェアインターフェイスを備え，
前記ソフトウェアは，各々の接続可能なアプリケーションのために，コンポーネントのアプリケーション固有の少なくとも１つのソフトウェアコードを有し，
前記ソフトウェアコードは，前記アプリケーションの接続により起動されることを特徴とする，電子制御ユニット。
【請求項２】
前記ソフトウェアは，前記ソフトウェアコンポーネントの相互アクセスの可能性に関して階層的な層アーキテクチャを有し，各々の前記ソフトウェアコンポーネントは，１つの層に対応付けられることを特徴とする，請求項１に記載の電子制御ユニット。
【請求項３】
前記層アーキテクチャは，ハードウェア依存性のソフトウェアコンポーネントと，ハードウェア非依存性のソフトウェアコンポーネントとの分離を実現することを特徴とする，請求項２に記載の電子制御ユニット。
【請求項４】
前記ソフトウェアインターフェイスは，各々に接続可能な前記アプリケーションに応じて，「オンボード」インターフェイスと「オフボード」インターフェイスとに区分されることを特徴とする，請求項１，２または３のいずれか１項に記載の電子制御ユニット。
【請求項５】
前記ソフトウェアは，前記ソフトウェアインターフェイスに伝達されている情報に応じて，複数の可能な駆動状態から各々に１つの駆動状態を取り，前記駆動状態に固有の機能性のみを支援することを特徴とする，請求項１〜４のいずれか１項に記載の電子制御ユニット。
【請求項６】
前記ソフトウェアは，駆動状態として，「ソフトウェア更新」，「ソフトウェア設定」，「ソフトウェア診断」，「アフターラン」，「監視」または「電源オン」の各状態を取りうることを特徴とする，請求項１〜５のいずれか１項に記載の電子制御ユニット。
【請求項７】
請求項１〜６のいずれか１項に記載の電子制御ユニット（１００）を自動車エレクトロニクス，特に車両の駆動シーケンス制御用に適用すること。
【請求項８】
電子制御ユニット（１００）用のソフトウェアアーキテクチャを仕様化する方法であって：
前記方法により定義されたソフトウェアインターフェイス，ソフトウェアコンポーネント，ソフトウェア層およびソフトウェア駆動状態の仕様化に応じて，前記ソフトウェアコンポーネントは，前記ソフトウェア層と前記ソフトウェア駆動状態とに対して自動的に対応付けられ，
さらに，前記対応付けに基づいて実現された相互作用の分析および検査によって，前記対応付けが検証されることを特徴とする，電子制御ユニット用のソフトウェアアーキテクチャを仕様化する方法。
【請求項９】
前記対応付けが不十分な場合，前記ソフトウェアコンポーネントは定義されたサブコンポーネントに，および／または前記ソフトウェア層は定義されたサブ層に，および／または前記ソフトウェア駆動状態は定義されたサブ状態に区分されて，自動的に新たな対応付けがなされることを特徴とする，請求項８に記載の方法。
【請求項１０】
プログラムコード手段を有するコンピュータプログラムであって:
前記コンピュータプログラムは，コンピュータ上またはコンピュータシステム上で前記プログラムコードの要素が実行された場合，請求項８または９のいずれか１項に記載の方法を自動的に実施することを特徴とする，コンピュータプログラム。
【請求項１１】
プログラムコード手段を有するコンピュータプログラム製品であって：
前記コンピュータプログラム製品は，コンピュータ読取り可能なデータ媒体上に記憶された前記プログラムコードを有し，
前記プログラムコードがコンピュータ上で実行された場合，請求項８または９のいずれか１項に記載の方法が実施されることを特徴とする，コンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，独立請求項に記載される，電子制御ユニットおよび電子制御ユニット用のソフトウェアアーキテクチャを仕様化する方法に関する。さらに，本発明は，請求項１０に記載される，ソフトウェアアーキテクチャを仕様化する方法を実施するプログラムコード手段を有するコンピュータプログラムに関する。
【背景技術】
【０００２】
電子制御ユニットの機能の複雑化と，例えば車両複合体の内部の制御ユニット相互の間，および外部のアプリケーションとの間におけるネットワークおよび相互作用の進展化は，この種の制御ユニットに対するソフトウェア要求を著しく増大させている。これは，車両複合体の制御ユニットのみならず，例えばオートメーション等，他の技術分野に係る制御ユニットおよびモジュールのネットワークおよび相互作用についても同様である。
【０００３】
ソフトウェア開発では，ソフトウェア要求に基づいて，該当するソフトウェアアーキテクチャの分析および仕様化を始める。この場合，まず，該当する電子制御ユニットに実装されるソフトウェアの境界が定められ，もしくは仕様化されねばならない。
【０００４】
車両複合体に対する制御ユニットの適用に際しては，開発段階において，製造またはサービス段階で用いられる制御装置，例えば生産制御装置（Seriensteuergeraete）等と異なり，開発制御装置，プロトタイプ制御装置，マスタ制御装置またはアプリケーション制御装置とも称される制御ユニットが用いられることが知られている。これらの制御装置は，通常，特に各種の開発アプリケーション用に修正された所謂オフボードインターフェイスによって，生産制御装置とは差別化され，大半のオフボードインターフェイスは，ハードウェアおよびソフトウェア調整（Software-Anpassungen）に接続されている。そして，ツールと制御装置のマイクロコントローラとの間の通信は，各種のインターフェイスを介して行われる。そして，例えば，検査，較正，診断およびフラッシュプログラミング等，機能の方法は，ＡＳＡＭで標準化されている。
【発明の利点】
【０００５】
請求項１に記載される本発明に基づく電子制御ユニット，請求項８に記載される本発明に基づく方法，および請求項１０に記載される該当するコンピュータプログラムが提案される。他の望ましい実施形態は，該当する従属請求項に記載される。
【０００６】
請求項１によれば，実装されたコンポーネントからなるソフトウェアを有する電子制御ユニットが提供され，この電子制御ユニットは，複数のアプリケーションを選択的に接続するために，情報交換に関して最適化された複数のソフトウェアインターフェイスを備え，このソフトウェアは，接続可能なアプリケーションのために，コンポーネントのアプリケーション固有の少なくとも１つのソフトウェアコードを有し，このソフトウェアコードは，アプリケーションの接続により起動される。
【０００７】
一般に情報は，ソフトウェアインターフェイスを介して伝達されている情報と，ソフトウェアコンポーネントのソフトウェアコードの遂行もしくは起動に影響を及ぼす情報との２種類に区分され，一方がデータ情報，他方がコントロールもしくは制御情報である。そして，ソフトウェアインターフェイスでは，データインターフェイスと，コントロールもしくは制御インターフェイスとが適切に区分されうる。ソフトウェアシステム内の情報処理は，データフローもしくは制御フローと称される。例えば，マイクロプロセッサでは，所謂ＣＡＮ（Controller Area Network）メッセージ，すなわちＣＡＮバスを介して伝達されているメッセージが伝達されている場合，まずマイクロプロセッサにメッセージが伝達されている旨を通知する，割込み（Interrupt）とも称される信号が与えられる。この場合，これは，制御情報となる。一方，例えば伝達されている信号値等からなるＣＡＮメッセージの内容は，データ情報となりうる。この区分は，ソフトウェアシステムの入出力インターフェイス，およびソフトウェアシステムの内部コンポーネントのインターフェイスでも同様である。
【０００８】
本発明に基づく電子制御ユニットの他の望ましい実施形態では，ソフトウェアインターフェイスは，各々に接続可能なアプリケーションに応じて，「オンボード」インターフェイスと「オフボード」インターフェイスとに区分される。電子制御ユニットは，一般に例えば車両複合体等の上位の複合体に埋込まれている。これらの複合体に基づいて電子制御ユニット用のソフトウェアの境界が定められ，もしくは決定される。電子制御ユニット用のソフトウェアに属するオブジェクト，およびソフトウェアの周囲またはコンテクストに属するオブジェクトが正確に定義される。そして，さらに，電子制御ユニットに備えられる入出力インターフェイスが定められる。そして，さらに，本発明の範囲で「オンボード」インターフェイスと称される，複合体内部のアプリケーション用のソフトウェアインターフェイスと，一方で，本発明の範囲で「オフボード」インターフェイスと称される，複合体外部のアプリケーション用のソフトウェアインターフェイスとが正確に定められる。「オンボード」インターフェイスは，例えば，セットポインタセンサ，センサおよびアクチュエータ用，ならびに複合体内部の通信，例えば車両等の複合体内部の他の電子システムとの間の通信に用いられる所謂オンボード通信用のインターフェイスである。
【０００９】
本発明に基づく制御ユニットは，「オフボード」インターフェイスとして，オフボード通信に必要とされる全てのソフトウェアインターフェイスを備える。電子制御ユニットは，例えば車両複合体に埋込まれている場合，開発段階の進行，製造または車両サービス段階において，車両外部の電子ユニットとの間の通信に必要とされる全てのソフトウェアインターフェイスを備える。この場合，外部のユニットは，例えば，検査，較正，診断またはプログラミング等の所定の機能を実行するツールでありうる。各々のツールは，接続を可能とする「オフボード」インターフェイス記述を必要とする。この記述は，例えばデータファイル，所謂記述データファイルの形式で格納されている。この中には，一方で「オフボード」インターフェイスのハードウェアおよびソフトウェア情報が記述されており，他方で例えば信号，変数およびパラメータのメモリアドレス等，ツールが電子制御ユニットのデータにアクセスするための情報が格納されている。
【００１０】
この場合，電子制御ユニットの特に望ましい実施形態では，電子制御ユニット用のソフトウェアは，ソフトウェアコンポーネントの相互アクセスの可能性に関して階層的な層アーキテクチャを有し，各々のソフトウェアコンポーネントは１つの層に対応付けられている。層は，層内部ではソフトウェアコンポーネントが任意に相互アクセスでき，異なる層間ではインターフェイスを介して厳しいアクセス規制が適用されることを特徴としている。層は，それに該当する抽象化レベルに応じて区分されている。より高い抽象化レベルの層は，より低い抽象化レベルの層にアクセスしうる。一方，より低い層からより高い層へのアクセスは，厳格に規制され，または許容されない。
【００１１】
よって，ソフトウェアコンポーネントは，タスクに関連付けられた，すなわち機能的な層に厳格に区分されている。しかし，この場合，層アーキテクチャは，ハードウェア非依存性のソフトウェアコンポーネントとハードウェアウェア依存性のソフトウェアコンポーネントとの分離を実現することが望ましい。これは，これにより本来の制御ユニットの機能性の分離，すなわちアプリケーションソフトウェア等のハードウェア非依存性のソフトウェアコンポーネントと，プラットフォームソフトウェア等のハードウェア依存性のソフトウェアコンポーネントとの分離が実行されることを意味している。これにより，各々のソフトウェアコンポーネントの形成，保守および再利用が著しく容易となる。プラットフォームソフトウェアもしくは該当するソフトウェアコンポーネントは，各種のプロジェクトに適用されうる。よって，本発明に基づいて情報交換に関して最適化されたソフトウェアインターフェイスでは，制御ユニットに対するアクセスが統一されている。よって，標準化された方法もしくは標準インターフェイス用に調整されたツールは，開発段階，製造およびサービス段階において，例えば高速プロトタイピング，デバッギング，検査および較正等に適用されうる。さらに，アプリケーションソフトウェアのソフトウェアコンポーネントは，ハードウェアに依存することなく仕様化され，よって各種の制御ユニットプラットフォームに移植されうる。
【００１２】
電子制御ユニットの他の好ましい実施形態では，ソフトウェアは，ソフトウェアインターフェイスに伝達されている情報に応じて，複数の可能な駆動状態から各々に１つの駆動状態を取り，該当する駆動状態に固有の機能性のみを支援する。ソフトウェアコンポーネントの設定およびソフトウェア更新は，製造およびサービス段階において，例えばソフトウェアに固有の駆動状態，開ループ制御／閉ループ制御（Steuerungs-/Regelungs-）機能，および監視機能の大半において，安全上の理由から実施が部分的にのみ許容され，または全く許容されない。
【００１３】
本発明に基づく電子制御ユニットの望ましい実施形態では，ソフトウェアは，駆動状態として，「ソフトウェア更新」，「ソフトウェア設定（Software-Parametrierung-）」，「ソフトウェア診断」，「アフターラン」，「監視」，「電源オン」または「リンプホーム（limphome）」の各状態を取りうる。制御ユニットの取る状態は，ソフトウェアインターフェイスに伝達されている情報に依存している。電子制御ユニットが例えば車両に埋込まれている場合，駆動状態「電源オン」は，例えば車両の点火装置がオンにされることで取られる。そして，この駆動状態では，電子制御ユニットの例えば全ての表示機能性が任意に提供される。ソフトウェアが駆動状態「ソフトウェア更新」を取る場合，製造およびサービス段階において，「オフボード」診断用インターフェイスを介して，例えばフラッシュプログラミングのみが支援される。駆動状態「ソフトウェア設定」は，製造またはサービス段階において，所謂「オフボード」診断用インターフェイスを介してソフトウェア設定を調節するために設けられている。車両複合体の場合，これは，例えば距離および速度表示のキロメートル−マイル間での切替え，または言語変異間の切替えである。ソフトウェアの駆動状態「ソフトウェア診断」では，ソフトウェアは，センサおよびアクチュエータ診断用の機能等の診断機能性と，欠陥メモリの読出しおよび消去とを支援する。この機能性は，この駆動状態のみで提供され，もしくはソフトウェア側では，ソフトウェアのこの駆動状態のみで支援されることが望ましい。
【００１４】
さらに，ソフトウェアは，例えば車両においてエンジンキーを所定の位置に回した後，駆動状態「監視」を取り，これにより監視機能性がソフトウェア側で支援される。最終的に，ソフトウェアは，例えば電子制御ユニットが埋込まれている車両のエンジンを切った後，駆動状態「アフターラン」を取りうる。そして，この場合，例えばメモリ機能性と比較的時間を要する監視機能性とが支援される。その上さらに，駆動状態「リンプホーム」も考えられ，この駆動状態は，例えば安全面で重要なコンポーネントが故障することによってソフトウェア側で取られ，ソフトウェアは，制限された機能性の下で駆動可能な機能性を支援する。
【００１５】
駆動状態の他に，各々の駆動状態間で許容される移行および移行条件も決定されていることが望ましい。この場合，仕様化のために状態機械が用いられることが望ましい。
【００１６】
さらに，本発明は，自動車エレクトロニクス分野において，本発明に基づく電子制御ユニットを車両の駆動シーケンス制御用の電子制御ユニットに適用することを含むことが望ましい。
【００１７】
その上さらに，本発明は，電子制御ユニット用のソフトウェアアーキテクチャを仕様化する方法を提供する。この場合，第１のステップでは，定義されたソフトウェアインターフェイスが仕様化される。これは，ここでは先述したソフトウェアの「オンボード」インターフェイスおよび「オフボード」インターフェイスが決定されることを意味する。第２のステップでは，ソフトウェアコンポーネントと，このインターフェイスとが仕様化される。この場合，ソフトウェアコンポーネント間の通信も定められる。他のステップでは，ソフトウェア層および可能なソフトウェア駆動状態が定められる。これに続くステップでは，ソフトウェアコンポーネントがソフトウェア層とソフトウェア駆動状態とに対して自動的に対応付けられ，引き続いて，対応付けに基づいて実現された相互作用の分析および検査により対応付けが検証される。
【００１８】
本発明に基づく方法の望ましい実施形態では，対応付けが不十分な場合，ソフトウェアコンポーネントは定義されたサブコンポーネントに，および／またはソフトウェア層は定義されたサブ層に，および／またはソフトウェア駆動状態は定義されたサブ状態に区分されて，自動的に新たな対応付けがなされる。
【００１９】
本発明に基づく方法によれば，電子制御ユニット用のソフトウェアアーキテクチャの仕様化に際して，ソフトウェアコンポーネント，ソフトウェア層およびソフトウェア駆動状態に係る仕様化の間において，複数の相互作用の存在が考慮される。ソフトウェアアーキテクチャの開発に際しては，これらの要因を考慮することによって，ソフトウェアが全てのアプリケーションに対して普遍的に適用可能となり，かつ電子制御ユニットの適用に際しては，適用時に実施すべき初期調整を必要としない。
【００２０】
さらに，本発明によれば，プログラムコード手段を有する，コンピュータプログラムおよびコンピュータプログラム製品が提供され，コンピュータ上またはコンピュータシステム上でプログラムコード手段が実行された場合，本発明に基づく方法が自動的に実施される。
【実施例の説明】
【００２１】
本発明の他の利点は，以下の図面を用いて詳細に説明される。
【００２２】
図１は，電子制御ユニット１００を示す。電子制御ユニット１００は，特に複数の制御ユニット，センサおよびアクチュエータを備える，例えば車両等の上位の複合体に埋め込まれている。制御ユニット１００の内部コンポーネントのインターフェイス，すなわち制御ユニット１００内部のインターフェイスの他に，上位の複合体内部のアプリケーション用のインターフェイス，すなわち「オンボード」インターフェイスもある。図１に示される制御ユニット１００では，「オンボード」インターフェイスとして，ＣＡＮインターフェイス１０１およびＭＯＳＴ（Media Oriented Systems Transport）インターフェイス１０２が示され，これらを介して情報が相互に交換されうる。ＣＡＮインターフェイスには，例えば車両等の上位の複合体のセンサおよびアクチュエータ等が接続されうる。ＣＡＮインターフェイスもしくはＭＯＳＴインターフェイス用の付属ドライバは，１０１Ａもしくは１０２Ａで示される。さらに，アナログ（１０３）とデジタル（１０４）の入出力（アナログＩ／Ｏ，デジタルＩ／Ｏ）は，各々の付属ドライバ１０３Ａと１０４Ａとともに示される。その他，インターフェイス１０５，１０６および１０７が示され，これらに例えば各種の表示アプリケーション１０８が接続され，制御ユニットの該当するドライバ１０９から情報を得る。この場合，表示アプリケーションは，例えばセットポインタ装置１０８Ａ，ディスプレイ装置１０８ＢまたはＬＥＤ装置１０８Ｃでありうる。そして，本例では，ドライバ１０９Ａがセットポインタドライバ，１０９Ｂがディスプレイドライバ，また１０９ＣがＬＥＤドライバとして形成されている。制御ユニットの他の機能，例えば計算機能または処理機能は，実施対象となる該当するオブジェクトとともに１２０で示される。
【００２３】
図２には，電子制御ユニット１００のソフトウェアアーキテクチャが示される。この場合，各々のソフトウェアコンポーネントは，１つの層に対応付けられている。ここでは，例えばプラットフォーム層１１０およびアプリケーション層１１１である。ここで，プラットフォーム層１１０には，さらにＣＡＮドライバ１１３，およびＭＯＳＴネットワークサービス１３１に付属するＭＯＳＴドライバ１２２が含まれる。この場合，ハードウェア依存性のソフトウェアコンポーネント，所謂プラットフォームソフトウェア１１０と，ハードウェア非依存性のソフトウェアコンポーネント，所謂アプリケーションソフトウェア１１１との分離も生じる。この場合，プラットフォームソフトウェア１１０は，駆動システム，例えばＯＳＥＫ−ＯＳと，ハードウェア非依存性の各種の選択可能なソフトウェアコンポーネントをハードウェア依存性のソフトウェアコンポーネントに接続するために，一般的に標準化されたインターフェイスを定義する所謂ＨＡＬ（Hardware Abstraction Layer）とを含む。ＨＡＬは，この場合，例えば先述したセットポインタドライバ１２３，ディスプレイドライバ１２４，ＬＥＤドライバ１２５およびＩ／Ｏドライバ１２６を有する。層１１１内のハードウェア非依存性のソフトウェアコンポーネントは，例えば車両の駆動シーケンス制御用のソフトウェア機能１１５を有する。この場合，例えば，表示機能，および／または計算機能，および／または処理機能，もしくは開ループ制御および／または閉ループ制御機能（Steuer-und/oder Regelfunktionen）Ｆ１〜Ｆ５は，１１５で統合され，一方で，これらの機能の実施対象となる該当するオブジェクトＯ１〜Ｏ１３は，１１４で統合されうる。プラットフォームソフトウェア１１０とアプリケーションソフトウェア１１１との間のソフトウェア内部のインターフェイスＳＩＳＳは，この場合，概略的に示されており，これらの正確な位置と接続に関しては，限定的に解釈されるものではない。すなわち，例えばＨＡＬとオブジェクト１１４との間の接続ＳＩＳＳ１およびＳＩＳＳ２は，例として概略的に示される。これは，他のソフトウェア内部のインターフェイスＳＩＳＳ３〜ＳＩＳＳ６でも同様であり，それぞれ他の接続と位置でも同様に可能である。しかし，層１１０および１１１の内部では，各種のコンポーネントが相互にネットワーク化されており，一方で，例えば，プラットフォームソフトウェア１１０では，フラッシュローダ（flashloader）１１２を除いて，最上位のコンポーネントのみがアプリケーションソフトウェア用のインターフェイスＳＩＳＳを備えるという原則が明示されている。そして，例えば，ＣＡＮドライバ１１３に伝達されている情報をアプリケーションソフトウェア１１１に直接伝達可能なインターフェイスは，存在しない。
【００２４】
一般に情報は，先述したとおり，ソフトウェアインターフェイス，例えば先述したソフトウェア内部のインターフェイスＳＩＳＳを介して伝達されている情報と，ソフトウェアコンポーネントのソフトウェアコードの遂行もしくは起動に影響を及ぼす情報との２種類に区分される。この場合，一方がデータ情報，他方がコントロールもしくは制御情報である。そして，ソフトウェアインターフェイスでは，データインターフェイスと，コントロールもしくは制御インターフェイスとが適切に区分されうる。この区分は，ここでＳＥＳＳすなわちソフトウェア外部のインターフェイスと称されるソフトウェアシステムの入出力インターフェイスと，図２に例示されるソフトウェアシステムの内部コンポーネントのインターフェイスＳＩＳＳとでも同様である。
【００２５】
この場合，ソフトウェアインターフェイスは，各々に接続可能なアプリケーションに応じて，「オンボード」インターフェイスと「オフボード」インターフェイスとに区分されて，さらに細分化される。電子制御ユニットは，一般に例えば車両複合体等の上位の複合体に埋込まれている。これらの複合体に基づいて電子制御ユニット用のソフトウェアの境界が定められ，もしくは決定される。電子制御ユニット用のソフトウェアに属するオブジェクト，およびソフトウェアの周囲またはコンテクストに属するオブジェクトが正確に定義される。そして，さらに，電子制御ユニットに備えられる入出力インターフェイスが定められる。そして，さらに，本発明の範囲で「オンボード」インターフェイスと称される，複合体内部のアプリケーション用のソフトウェアインターフェイスと，一方で，先述したとおり本発明の範囲で「オフボード」インターフェイスと称される，複合体外部のアプリケーション用のソフトウェアインターフェイスとが正確に定められる。「オンボード」インターフェイスは，例えば，セットポインタセンサ，センサおよびアクチュエータ用，ならびに複合体内部の通信，例えば車両等の複合体内部の他の電子システムとの間の通信に用いられる所謂オンボード通信用のインターフェイスである。この場合，インターフェイスＳＥＳＳは，例えば車両内部のハードウェア用としてＨＡＬを用いるＳＥＳＳ１およびＳＥＳＳ２等のオンボードインターフェイス，または，例えば外部の診断装置用としてＣＡＮドライバ１１３を介するインターフェイスＳＥＳＳ４等のオフボードインターフェイスである。しかし，インターフェイスＳＥＳＳ４は，例えばアクタ，センサまたはＣＡＮバスを介する他の制御ユニット用として，車両内部の，すなわちオンボードインターフェイスともなりうる。ＭＯＳＴインターフェイス１１２とＳＥＳＳ３とでも同様である。
【００２６】
本例では，例えば，ＩＳＯ診断プロトコルとＩＳＯネットワーク層とが１２７と１２８とで示される。１２９はプラットフォームソフトウェア１１０内の相互作用層（interaction layer）ＯＳＥＫ−ＣＯＭ，１３０はネットワーク管理（Netzwerkmanagement）ＯＳＥＫ−ＮＭを示す。
【００２７】
先述した階層構造の層アーキテクチャは，ここでは２つの層１１０および１１１で例示され，各々のソフトウェアコンポーネントは，１つの層に対応付けられている。層は，層内部ではソフトウェアコンポーネントが任意に相互アクセスでき，異なる層間ではインターフェイスを介して厳しいアクセス規制が適用されることを特徴としている。層は，それに該当する抽象化レベルに応じて区分されている。より高い抽象化レベルの層は，より低い抽象化レベルの層にアクセスしうる。一方，より低い層からより高い層へのアクセスは，厳格に規制され，または許容されない。他の層は，この場合，例えばセンサ層またはアクタ層ともなりうるが，ここでは説明の簡略化のために明示されていない。
【００２８】
よって，ソフトウェアコンポーネントは，タスクに関連付けられた，すなわち機能的な層に厳格に区分されている。しかし，この場合，層アーキテクチャは，ハードウェア非依存性のソフトウェアコンポーネントと，ハードウェアウェア依存性のソフトウェアコンポーネントとの分離を実現することが望ましい。これは，本来の制御ユニットの機能性の分離，すなわちアプリケーションソフトウェア等のハードウェア非依存性のソフトウェアコンポーネントと，プラットフォームソフトウェアのハードウェア依存性のソフトウェアコンポーネントとの分離が，先述した利点により実行されることを意味しており，本発明に基づいて情報交換に関して最適化されたソフトウェアインターフェイスでは，制御ユニットに対するアクセスが統一されている。
【００２９】
この場合，ソフトウェアは，ソフトウェアインターフェイスに伝達されている情報に応じて，複数の可能な駆動状態から各々に１つの駆動状態を取り，該当する駆動状態に固有の機能性のみを支援する。駆動状態としては，例えば，「ソフトウェア更新」，「ソフトウェア設定」，「ソフトウェア診断」，「アフターラン」，「監視」，「電源オン」または「リンプホーム」の各状態を取ると考えられる。制御ユニットの取る状態は，先述したとおりソフトウェアインターフェイスに伝達されている情報に依存している。
【００３０】
駆動状態の他に，各々の駆動状態間で許容される移行および移行条件も決定されている。この場合，仕様化のために状態機械が用いられることが望ましい。
【００３１】
層内では，その上さらに，対応付けが不十分な場合，サブ層またはサブコンポーネントを設けることができ，ソフトウェアコンポーネントは定義されたサブコンポーネントに，および／またはソフトウェア層は定義されたサブ層に，および／またはソフトウェア駆動状態は定義されたサブ状態に区分されて，これに基づいて自動的に新たな対応付けがなされる。
【００３２】
よって，本発明に基づく方法によれば，電子制御ユニット用のソフトウェアアーキテクチャの仕様化に際して，ソフトウェアコンポーネント，ソフトウェア層およびソフトウェア駆動状態に係る仕様化の間において，複数の相互作用の存在が考慮される。これらの要因をソフトウェアアーキテクチャの開発に際して考慮することによって，ソフトウェアが全てのアプリケーションに対して普遍的に適用可能となり，かつ電子制御ユニットの適用に際しては，適用時に実施すべき初期調整を必要としない。
【図面の簡単な説明】
【００３３】
【図１】本発明に基づく電子制御ユニットの実施形態を概略的に示す。
【図２】本発明に基づく電子制御ユニットの他の実施形態におけるソフトウェアアーキテクチャを概略的に示す。
【図１】
2007507017.tif 000003
【図２】
2007507017.tif 000004
【国際調査報告】
2007507017.tif 000005
2007507017.tif 000006
2007507017.tif 000007
2007507017.tif 000008
2007507017.tif 000009
2007507017.tif 000010
2007507017.tif 000011
2007507017.tif 000012
2007507017.tif 000013
2007507017.tif 000014