組み込まれたシステムの実証方法
本発明は、組み込まれた電気的システムによりインプリメントされたサービスのための実証環境を設計する方法を提供する。該方法をインプリメントするために、そのサービスに１つ以上の「ユーザ要求」と「システム応答」を割り当てることが必要である。次に、そのサービスに、ユーザ要求とシステム応答の許された配列を設定する、動作に関するオートマトンを割り当てることが必要である。これがなされたとき、サービスのために骨子実証環境が自動的に生成される。該骨子実証環境は、前記動作に関するオートマトンのトラバーサルから生じさせられた検査オートマトン、初期条件のモデル、ユーザ要求のモデル、システム応答精度のモデル、環境モデルおよびデータフロー並びにこれらのモデルをいっしょに集める制御フローから構成される。骨子実証環境は、すべてのユーサ要求およびサービスの結果として生じるシステム応答をカバーする。さらに骨子実証環境は、設計実証ツールによる使用のために、コンピュータの読み出し可能なメモリ デバイスに記録される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システム設計の実証、特に組み込まれた電気的システムの実証方法の設計に関する。
【背景技術】
【０００２】
システム設計と検査のために種々のツールと方法が開発されている。1980年代の間、システム設計者が彼のシステムの動作環境を特定するのを許すように構造化ツールが開発され、その後、そのシステムの各パートの期待される動作を特定するために、階層アプローチが続いた。構造化分析方法は、この第１の期間の良い実例である。
【０００３】
しかしながら、複雑なシステムのためには、このことは十分でなく、設計ツールがシミュレーションを許す実行可能なツールになったことがすぐに明らかになった。しかしながら、このパラダイム シフトの間、初期のシステム要求とシステムの実行可能な特定との間のリンクは、最初は保護されなかった。もちろん、事実上の制限中のシミュレーションは、事実上の動作環境および実行可能なモードへの初期の要求からの追跡性における検査を妨げず、その後、検査事例は盛り込まれなかった。コード化は依然としてシミュレーションの後になされ、初期のモデル化ステップでなされた誤りの検知および修正が許される。
【０００４】
たくさんの人々を含む非常に大きな発展のために、初期の要求とシステムの特定との間のリンクが最も大切であったことがあとで明らかになり、その後、要求、モデル、コードの要素、および検査の間のリンクを確立するために要求管理システムが始まった。しかしながら、技術の現在の状態を表すこのステップで、要求、モデルおよび検査の間のリンクが公式ではなく、手動で維持されなければならない。ユニバーサル モデリング ラングウェッジ（ＵＭＬ）のようなアプローチは（モデル化と検査を要求する）異なるプロセス ステップを獲得する試みをするが、ＵＭＬフォーマリズムは異なる設計ステップの間の非公式なリンクよりも本当に現実的に支持するのにあまりにぼんやりしている。
【０００５】
同時に、自動化された検査検査発生計画は、実行可能なモデルの情報を利用するように試みるために発展したが、検査動作環境における要求の獲得の不在において、検査はある冒険的なアプローチとともにやみくもに行われ、そのような検査は１つのモデルのあるパートには非常に効率が良いが、他のパートを簡単に省くことがよく知られている。
【０００６】
手動でなされた検査の場合、検査中のコンポーネントが適切な初期の状態においてセットされたとき、実行可能な検査ベクトルを特定しなければならないが、一連の電子的制御ユニット（ＥＣＵ）のブラック ボックス検査を得ようとするのは非常に困難である。
【０００７】
現実の上級の検査機の組み入れがあまりに費用がかかるので、ハードウェアの設計が非常に最適化されるドメインのために、一連のコンポーネントのブラック ボックス検査はいつも必要であることが留意されるべきである。
【０００８】
また、いったんモデルが設計されると、ファンクションが割り当てられ、その後、特に、異なる要素が異なる供給者によって開発されなけらばならないとき、ファンクションのそれぞれ割り当てられた要素のためのまとまった検査を供給するという課題が来る。これは未解決の問題である。現在、支持されたアプローチは、異なるコンポーネントのプロトタイプを待ち、具体化し、その後、相互に作用し、デバッグすることである。これは現実のデバッグは、ハードウェア設計がフリーズしたときに始まり、ほとんど能率的でないプロセスを意味する。
【０００９】
故障許容ファンクションの場合、検査に故障の投入を含め、これをそのようなファンクションの割り当てられた特徴と結合させることもまた要求される。このステージで再び、ほとんど標準で決定論者でないアプローチが利用できる。
【００１０】
米国特許第5394347号において、ＥＦＳＭ（拡張された有限の状態機械）を採用する検査環境を設計する方法が開示されている。ＥＦＳＭにおいてユーザの要求とシステムの応答との間には相違はなく、すべてのユーザの要求とそれらの要求に対するシステムの応答はいつも変遷の中に溶け込む。この提案においては、システムのイベントがインプットであるが、また例えばベルを鳴らすというようなアウトプットをカバーする。それから少なくとも「バリアブル スタック」と「モデル スタック」のトラックを維持するのが必要なので、使用された技術がユーザの要求とシステムの応答とを区別しないということが米国特許第5394347号の不便な点である。さらに、これはまた、米国特許第5394347号においては、特定の正しいインプリメンテーションを実証することのみが可能であり、特定それ自体を実証することが不可能であるということを意味する。米国特許第5394347号における提案に対応してなされるシミュレーションは、特定において「力」として言及されたあらかじめ定義されたファンクションといっしょにセットされ得る、検査されるシステムの可変の動作環境として時間がみなされるので、リアル タイムではなされない。この機構は、信号処理のシミュレーションのためには十分ではない。
【００１１】
それゆえ、特に割り当てられたファンクション設計の場合において、システム モデルおよびその実現の種々の工程でのその物理的な表現を正確に実証するのを許すシステム検査の規則正しい設計のための改良された方法のための連続する必要性があるということがわかり得る。
【特許文献１】米国特許第5394347号
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、改良されたシステム設計の実証方法を提供し、特に組み込まれた電気的システムの実証方法の改良された設計方法を提供することにある。当該電気的システムは特に電子コンポーネントと電気回路の構成部分を含むことは正しく理解されるだろう。
【課題を解決するための手段】
【００１３】
したがって、本発明は、組み込まれた電気的システムによってインプリメントされるサービスのための実証環境を設計する方法を提供し、該方法は、
ａ）前記サービスに、１つ以上のユーザ要求およびシステム応答を割り当て、
ｂ）前記サービスに、動作に関するオートマトンを割り当て、前記動作に関するオートマトンは、前記ユーザ要求およびシステム応答の許された配列を記憶し、
ｃ）シミュレーション ツール上で実行可能なモデルの形で、前記サービスのための骨子実証環境を自動的に生成し、前記骨子実証環境は、前記動作に関するオートマトンのトラバーサルから生じた検査オートマトン、初期状態のモデル、ユーザ要求のモデル、システム応答精度のモデル、環境モデルおよびこれらのモデルをいっしょに集めるデータフローおよび制御フローを含み、前記骨子実証環境は、前記サービスのすべてのユーザ要求および結果として生じるシステム応答をカバーし、および
ｄ）設計実証ツールによる使用のためのコンピュータの読み出し可能なメモリー デバイスに前記骨子実証環境を記録する。
【００１４】
骨子を用いることにより、検査環境は、検査環境とモデルそれ自体の両方を実証するために、検査中のサービスのモデルといっしょにシミュレートすることができる。設計プロセスにおける非常に初期の誤りを修正することにより、本発明の方法は、システム設計と開発においてたくわえられる時間を与え、検査範囲と質も非常に改善する。前記サービスは、例えばブレーキ バイ ワイヤ等の安全クリティカルおよび／または故障許容システムのような、乗物に使用されるサービスを含むことができる。
【００１５】
検査動作中のファンクションを実証するためにシステム応答精度のモデルの出力を記憶し、分析できることは正しく理解されるだろう。システム応答精度のモデルの出力は、システムの応答が正確か、さもなければ不正確なとき、本当になる、典型的にはブール（Boolean）式である。
【００１６】
ユーザ要求とシステム応答精度のモデルは、以前に開発された骨子実証環境の少なくとも一部を記憶することによって、あらかじめ定義できることは正しく理解されるだろう。
【００１７】
その方法は、それをインプリメントする１つのファンクションを各ユーザ要求に割り当て、それをインプリメントする１つまたはそれ以上のファンクションを各システム応答に割り当てることを含むことができ、前記骨子実証環境のデータフローは、ユーザ要求とシステム応答の前記ファンクションを用いて形成される。
【００１８】
その方法は、その入力と出力がそのサービスをインプリメントするファンクションの少なくとも１つの入力と出力に対応する、ブラック ボックス インターフェースを前記サービスに割り当て、前記サービス ブラック ボックスの出力を前記骨子入力に、前記骨子出力を前記サービス ブラック ボックスの入力にインターフェースし、実証の結果を出すために、シミュレーション環境における骨子とサービス特定を全部揃え集めることを含むことができる。
【００１９】
その方法は、前記サービスのための実証環境を含み、同時に該サービスの実証されたモデルを含む、実証されたモデルを出力することを含むことができる。
【００２０】
その方法は、サービスのモデルをそのソフトウェアのインプリメンテーションで置き換えることを含むことができる。
【００２１】
その方法は、サービスのモデルをそのソフトウェアおよびハードウェアのインプリメンテーションで置き換え、前記ハードウェアのインプリメンテーションとインターフェースされた検査プラットフォーム上に前記実証環境を組み込むことを含むことができる。
【００２２】
その方法は、乗物におけるブレーキ バイ ワイヤ システムのような、故障許容システムにおけるすべての再生された目的のために、故障の体系的な投入を含むことができる。
【００２３】
その方法は、少なくとも１つのユーザ要求を共有する様々なサービスのための実証環境を割り当て、前記サービスのセットのための実証環境を生じるために、前記サービスの前記実証環境を混合することを含むことができる。
【００２４】
本発明はまた、プログラムがコンピュータ上で動作するとき、本発明のすべてのステップを遂行するためのプログラム コード手段を含むコンピュータ プログラムも提供する。本発明はまた、プログラム製品がコンピュータ上で動作するとき、本発明の方法を遂行するための、コンピュータの読み出し可能な媒体上に記憶されたプログラム コード手段を含むコンピュータ プログラム製品も提供する。
【００２５】
本発明はまた、システム設計の実証のために適合された設計ツールも提供し、前記設計ツールは、本発明による方法を用いることによって、組み込まれた電気的システムのための実証環境を出力するのに使用されるように設計され、あるいは本発明によるコンピュータ プログラム製品を用いてプログラムされている。
【００２６】
ソフトウェア コードのセクションが該モデルから生成されたとき、該モデルのパーツは、発生されたコードを実証するために、それらの対応するインプリメンテーションで置き換えることができる。前記システムのハードウェアがプロトタイプされるとき、ハードウェア イン ザ ループ環境のピースをインプリメントすることができ、前記検査環境を組み込む。このことは、たとえハードウェア環境が様々な電子的制御ユニット（ＥＣＵ）上に割り当てられるとしても真実である。
【００２７】
システムの配線が特定されるとき、ハードウェア イン ザ ループは、配線とコネクタの特定を実証するために、特に故障投入が用いられる安全クリティカル システムの場合において、使用することができる。
【発明を実施するための最良の形態】
【００２８】
本発明は添付の図面を参照して実施例のみによって述べられる。
図１は１つのサービスの使用の場合の仕様を示す。
図２は１つのサービスの機能的な説明を示す。
図３は１つのサービスの動作に関する記述を示す。
図４は本発明によって自動的に生成される検査環境の骨子を示す。
図５は図４における検査環境の一部である検査オートマトンを示す。
図６は１つのサービスの機能的な記述を示す。
図７は２つのＥＣＵと１つのネットワークを含む分配されたシステムを示す。
図８は３つのＥＣＵと１つの配線ネットワークを含む分配されたシステムを示す。
図９はコネクタ インターフェースを示す。
図10は電気的レベルでのフォールトのモデル化を示す。
図11は本発明による設計プロセスの１つの実施例を示す。
図12は安全クリティカル システムの設計プロセスの使用を示す。
図13はハードウェア イン ザ ループの検査環境を示す。
図14は例えばＣＡＮバスのようなローカル エリア ネットワークにおけるフレームの１つの異なる仕様のマチュリティを示す。
図15はイン ザ ループ シミュレーションと検査の一般的なパラダイムを示す。
および、図16はいくつかの組み合わされたサービスの検査環境の混合を示す。
【００２９】
電子システムは、電子的制御ユニット（ＥＣＵ）からなり、通信バス、センサ、アクチュエータ、および例えば配線、コネクタ、リレー、ヒューズ、バッテリ、発電機等の種々のシステム コンポーネントへパワーを供給する電気デバイスを通してネットワーク化することができ、またはネットワーク化しないことができる。
【００３０】
電子システムは、工場の労働者、カー ドライバ、自動車修理工、あるいはエンジニア等の顧客にサービスを提供する。例えば、考察中の電子システムが車に組み込まれる場合、本発明で論じられるようなシステムは、空調、車の動き、またはドア施錠のようなサービスをインプリメントできる。
【００３１】
電子システムはたくさんのサービスをインプリメントできるので、それらの場合においてサブシステムのセットとして純化することができ、各サブシステムは明確なサービスのセットを達成する。その説明においては、我々はそのような分解を考慮する必要はないだろうし、システムおよびそのシステムによってインプリメントされる１つまたはいくつかのサービスを簡単に考慮するだろう。無条件に特別なサービスを考慮して、その連合されたシステムはそのサービスのインプリメンテーションに関与するコンポーネントの中にあるだろう。
【００３２】
システムの実証は、できるだけ徹底的にシミュレーションと検査の手段によって供給することにあり、サービスの要求は、システムにおけるそれらのインプリメンテーションによって適切にカバーされることにある。サービスを実証することは、設計の種々のステージで種々のアプローチによって成し遂げることができる。そのサービスがモデル化されるとき、そのモデルはバーチャル環境において実証することができる。これは「モデル イン ザ ループ」と呼ばれる。その後、そのサービスをインプリメントするソフトウェアが生じさせられるとき、それはモデルにおいて収容させ、実証させることができる。これは「ソフトウェア イン ザ ループ」と呼ばれる。その後、ハードウェアが設計されるとき、その環境はそのシステムに対するインターフェースであるハードウェア環境において再びシミュレートすることができる。これは「ハードウェア イン ザ ループ 実証」と呼ばれる。さらに、そのシステムの環境は、「ハードウェア イン ザ ループ」環境、または単に「ＨＩＬ」と呼ばれる。
【００３３】
我々はまだ、検査ベクトルを生じることからなる通常のアプローチに言及していない。実際、この方法は、適切な検査を生み出すことが困難なので、「イン ザ ループ」環境の提示より劣る。本発明のアプローチは、現在に至るまで何の方法も与えられず、イン ザ ループの検査の設計は低コストでモデルを作るので、非常にうまくいく。検査環境骨子を産出することによって、我々は非常に低コストでこの大発見を与える。実際、ループにおけるモデルが論文において述べるとき、対話方式の環境モデルが設計される方法は、決して特定されず、そのシステムの設計者の義務である。図15に示されるように概略のアイデアは非常にシンプルである。検査中のモデル1501と環境モデル1503があり、それらはフロー1511と1513を通して情報のフローを交換する。そのシミュレーションは、そのシステムのモデルにおいてゲインの信頼を促進する。実際には、もし我々が定常的シミュレーションよりほかの何かを、そして我々の発明で提案したような自動の生成の不在において検査したいならば、そのようなモデルの設計は、非常に難しい。例えばブレーキ システムを検査するために、たくさんの場面を考慮に入れなければならない。そのサービスのモデルを実証するためにあとで適用できる、環境を検査するような最小の努力で生成を促進するために、このことが我々の発明の目的であり、そのソフトウェアがそのサービスおよびそのシステムの部分または全体を実行する。
【００３４】
本発明は、１つの組み込まれた電気的システムによりインプリメントされる１つのサービスのための実証環境を設計する方法を提供する。その方法をインプリメントするために、そのサービスに１つまたはそれ以上の「ユーザ要求」および「システム応答」を割り当てることが必要であり、ユーザ要求とシステム応答の両方が図１およびそれに伴う説明に開示される。
【００３５】
次に、そのサービスに、ユーザ要求とシステム応答の与えられた配列を用意する、動作に関するオートマトンを割り当てることが必要である。図３は、１つのサービスの動作に関するオートマトンの定義と内容を示す。
【００３６】
これが行われたとき、１つの骨子実証環境は、そのサービスのために自動的に生成され、その骨子実証環境は、前記動作に関するオートマトンのトラバースから生み出される検査オートマトン、初期状態のモデル、ユーザ要求のモデル、システム応答精度のモデル、環境モデル、およびこれらのモデルをいっしょに集めるデータフローおよび制御フローを含む。骨子実証環境は、そのサービスのすべてのユーザ要求と結果として生じるシステム応答をカバーする。骨子実証環境は図４に示され、そこには検査環境の一般的なフレームワークもまた示される。このフレームワークの特別な例は、このステップで自動的に発生される骨子である。
【００３７】
そのプロセスの有利な点は、我々が実証環境を設計する多くの時間を節約することであり、さらに我々の実証環境は、１つのサービスのユーザ要求とシステム応答のすべてを徹底的にカバーする。
【００３８】
さらに本発明の側面は、各ユーザ要求に、それをインプリメントする１つのファンクションを割り当て、また、各システム応答に、それをインプリメントする１つまたはそれ以上のファンクションを割り当てることを含む。この骨子実証環境のデータフローは、図２に関連して述べられるように、ユーザ要求とシステム応答のこれらのファンクションを用いて形成することができる。そのファンクションのデータフローおよび１つのサービスのデータフロー説明が、その骨子実証環境のためのデータフローにいかに変えるかが図４に示される。
【００３９】
本発明のさらなる側面は、以下のものを含む。
ｇ）サービスにブラック ボックス インターフェースを割り当てることを含み、その入力と出力はそのサービスをインプリメントするファンクションの少なくとも１つの入力と出力に対応し、
ｈ）そのサービス ブラック ボックスの出力を骨子入力に、骨子出力をサービス ブラック ボックスの入力にインターフェースし、そして、
ｉ）実証結果を生成するために、シミュレーション環境において骨子およびサービス仕様を完成し調整（correct）する。
【００４０】
サービスのブラック ボックス インターフェースは、実証環境のすべてのブロックのインターフェースを詳細に示す図４中のブロック417で示される。
【００４１】
本発明の方法はまた、サービスのための実証された環境を含み、同時にサービスの実証されたモデルを含む、実証されたモデルを出力することを含む。ループにおけるシミュレーション プロセスが詳細に述べられるとき、このシミュレーションが働く方法が図４中に示される。
【００４２】
本発明の他の側面の元で、サービスのモデルは、サービスをインプリメントするソフトウェアの実証の種々のステップが述べられる図１１に関連して述べられる、そのソフトウェアのインプリメンテーションで置き換えられる。
【００４３】
本発明の方法はまた、サービスのモデルをそのソフトウェアとハードウェアのインプリメンテーションで置き換え、ハードウェアのインプリメンテーションでインターフェースされる検査プラットフォーム上のその実証環境を組み込むことも含む。ハードウェアのインプリメンテーションを実証環境に挿入する方法は、ＥＣＵとネットワークの側面に関して、図７に関連して示され、図８においては実証における配線をまとめる。ネットワークのために伝える説明は、図１４中に具体的に挙げられ、１つまたはいつくかのＥＣＵのためにハードウェアの実証をインプリメントする機械は図13に関連して述べられる。
【００４４】
その方法は、乗物のブレーキ バイ ワイヤー システムのような、故障許容システムにおけるすべての再生された目的のための故障の体系的な投入も含む。故障許容システムを定義するのに続くプロセスは、図１２およびそれに伴う説明中に再び示される。それから、故障のモデル化と投入は、図９と１０に関して示される。他の実施例の元で、我々の発明は、少なくとも１つのユーザ要求を分けるサービスのための実証環境を混ぜることを許す。これは図１６中に示される。
【００４５】
図１においては、３つの使用事例の限定されない実施例が示される。これらの好例となる使用事例は、乗物のドアの施錠管理の説明の形態で、限定されないサービスの話をする。各使用事例のために、４つのパートにおける説明がなされる。第１のパート101、111、121は、それぞれの使用事例において適用できる状況である。第２のパート103、113、123は、それぞれの使用事例を述べるユーザ要求である。第３のパート105、115、125は、ユーザ要求によって誘発されるシステム応答である。第４のパート131、133、135は、ユーザ要求とシステム応答との間の呼び出し時間である。それらは最初のステージで必須ではない。
【００４６】
ユーザ要求は、検査が適用される分野がどんなものであろうとも絶対的なものであり得る。例えば自動車の分野において、車の衝突が起きたとき、我々はその衝突をユーザ要求であるとみなす。それはたとえ彼らの主導権でとりわけ要求されなくても、ユーザに代わって自動的にあるファンクションが誘発されるからである。実例は「燃料遮断」や「エア バッグ トリガー」かもしれない。我々は、ユーザは組み込まれたシステムのまわりのすべての外部の状況に対して責任があるとみなすだろう。前記もう１つの方法では、「ユーザ要求」は、「ユーザ要求およびユーザによって起こされあるいはユーザに影響を与える要求される状況」として広い意味に取ることができる。
【００４７】
使用の場合のためにたくさんの異なる初期状態を許容するため、状況は多少不明瞭である。例えばドア施錠 サービスのための状況は、すべてのドアが解錠されているかもしれないし、エンジンが動いているかもしれない。
【００４８】
システム応答が状態（state）でありユーザ要求が移行（transition）であることを考慮すると、使用の場合（Use Case）の１セットは、ムーア（Moore）のオートマトンへ変えることができる。正確なプロセスは、その使用の場合の状況に合う最初の状態から、その使用の場合のシステム応答に対応する１つの最終の状態へ、移行の１セットを使用の場合に関係づけることにある。サービスの動作に関する説明を得るため、システムの最初の状態を特定することが必要である。しかしながら、我々の発明は、ムーアのオートマトンのように動作を特定することができる限り、また、次の図面で示される他の制限の元では、特定する種々のプロセスをサポートする。
【００４９】
図２では、サービスの機能的なアーキテクチャーが描かれている。ユーザ要求はファンクション211、213および215によってインプリメントされ、状態において成し遂げられるためのシステム応答は、ファンクション241、243および245の間の１セットによってインプリメントされる。これらのファンクションは、それらあるいは先行あるいは一度モデル化された予定されている制限の間で、相互作用を有するかもしれない。ファンクションのセマンティックは図中に特定されておらず、ファンクションはその入力またはあるフィルタリングまたは両方のミックスの上の計算の操作であり得る。オートマトン201は環境から刺激221、223および225を受けることができ、その現在の状態により、状態を変えるかまたは変えない。例えば乗物が施錠されている状態で、もし解錠要求213がデータフロー223を介して「真」の値を送ると、オートマトンはトリガー233を介して、乗物のドアの解錠する結果として有する、「解錠」ファンクションが起動する状態へ動作することができる。実際の状態201により、ファンクション241、243および245は制御フロー231、233および235によってトリガーされることができ、これらの制御のそれぞれは１つの状態に入るとき予定されている。そのような動作は、シミュレーションのために環境が確立するやいなや、アドバンス フェーズにおけるシミュレーションを許す、マスワークス（Mathworks）の「マトラブ（Matlab）／シミュリンク（Simulink）」、またはロロジックス「ステイトメイト」（l'logix "Statemate"）のようなシミュレーション ツールによって正確にインプリメントすることができる。
【００５０】
図３に、ムーアオートマトンのサンプルが示される。状態321、323、325、327、341、343、345、347および349が、他のものの間で移行331、333、335、337、339を介して互いにリンクされている。このオートマトンのセマンティックを実施例によって説明する。例えばドア ロッキング サービスの例を継続して、状態343においては乗物が施錠され、状態341においては乗物が解錠されていることを想定する。それから移行337の間は、解錠の要求がトリガーされることを想定する。図２に概略が示された案をフォローし、移行337は刺激223によってトリガーすることができ、結果として生じる状態341はファンクション243によってトリガーすることができる。使用の場合とのリンクについては、状態341は応答状態105および移行337がユーザ要求103と対応することできるような結果として生じることができる。それから、状態343は最初の状態101と合わなけらばならない。
【００５１】
輪郭301と303はフェーズを示す。フェーズは共通の文脈上の情報を有する状態の１セットを集める。例えばエンジンが動作中のとき、クーリングだけを行うことができるので、「エンジン ランニング」は、クーリングのフェーズであり得る。異なるクーリング状態の数をいかに定義可能であろうとも、それらはすべて「エンジン ランニング」フェーズ中に集めることができる。フェーズはムーアオートマトンの読み易さを容易にするために有用であるが、本実施例に明確に用いることができないだろう。
【００５２】
最初のフェーズと状態は、状態チャートの形でトリガー311と313により特定される。これは323が、その第１のオペレーションのまったくのはじめでサービスの最初の状態であるということを意味する。また、各移行のために、移行を起動することができない元で、遅延を特定することができる。例えばアシューム（assume） 状態349は、例えば内側から後ろのドアをあけるという、あらかじめ決められた操作を子供が遂行できない「チャイルドロック」のように、内側から乗物の後ろのドアを施錠することにある。安全の理由のために、ドアが実際に施錠されているという確認は、施錠位置をモニターすることを通して遂行することができる。状態347が、ドアが結局はあかなかったことを信号で伝えることにあり、移行351が、施錠位置をモニターすることの結果として施錠が遂行されなかったとき、トリガーされることを考える。それからもし351が、リレーまたはアクチュエータの呼び出し時間により、ドアが実際に施錠される時間を持つ前に操作されると、移行351は不適当に起動され、システムを状態347へ矛盾して変える。そこでシステムがいったん状態349に入ると、後部のドアを施錠することに含まれるコンポーネントの最も悪いケースの実行呼び出し時間の前に移行351は操作すべきではない。そのような呼び出し時間は、マトラブ／シミュリンクのようなフォーマリズムを用いて、移行上に直接特定される。
【００５３】
本発明の実施例による検査環境の構造、または実証環境は図４に示され、そこで輪郭417は検査中のシステムを表す。このことはあとでさらに説明されるので、検査中のシステムは１つのモデル、ソフトウェアまたは１つの電気的システムの形態を有する。輪郭401は適用されつつある検査シナリオを示す。我々の発明の検査シナリオはその意味において網羅的であり、それは図３で示されたような動作に関するモデルのすべての状態および移行をカバーするだろう。
【００５４】
１つのサービスを検査するために、我々は、そのサービスの動作に関するオートマトンにおけるパスを強化するためそのサービスの環境をシミュレートし、現在の状態により、我々は意図されたサービス状態が実際のサービス状態であることを確かめるために検査を実施する。
【００５５】
この目的を達成するため、各ユーザ要求は検査要求と関係付けられる。それは、検査要求の１つが実行のために最初の状態をセット アップすることを除いては、一対一の対応であり、我々はこの特別な検査要求を最初の状態ブロックと呼ぶだろう。検査要求の目的は、その関係付けられたユーザ要求をシミュレートするように、検査中でそのサービスの入力を変えることである。例えばユーザ要求が「エンジンを停止させる」場合、その対応する検査要求は「停止されたエンジン」の値で、「エンジン状態」の入力値をセッティングすることにあるだろう。同様に、状態検査ファンクションは各状態に関係付けられ、状態検査ファンクションの目的は、関係付けられた状態が処理されたかどうかを検査することにある。
【００５６】
輪郭413と415は検査要求を表し、それらのそれぞれ１つはユーザ要求に関係付けられる。完全な描画においては、我々はユーザ要求と同じくらい多数の検査要求、プラス、輪郭をセッティングする１つの最初の状態を見つけるだろう。輪郭419と421は状態検査ファンクションを表す。
【００５７】
輪郭411は環境ループを表す。例えば検査中のサービスの１つのセンサが、検査中のそのサービスによって制御されるアクチュエータの位置をつかまえるならば、そのときはそのようなアクチュエータとその関係付けられたセンサとの間の関係は、環境ループにおいてインプリメントされるだろう。データのフローは、特に我々がアクチュエータの失敗に対応する状態を観察したい場合に、検査要求から環境ループへ戻るだろう。その場合、検査要求は、アクチュエータのモデル化における失敗を求めるために、環境ループへ情報を送る。このことは、アクチュエータとセンサがシミュレートされる限りは便利である。現実のコンポーネントのために、失敗はその対応する検査要求によって制御されたある特別なシステムによって得ることができる。検査環境が動作しているとき、検査結果は、各信号の記録または各状態検査ファンクションによる単純な認識からなるだろう491に記録される。
【００５８】
輪郭401は、検査 移行と状態検査要求の両方をトリガーするオートマトンを表す。このオートマトンは、検査要求が417から、シミュレートされた時間における瞬間であるどの瞬間でも、またはリアル タイムで見えるかを選択する。同時に、検査オートマトンは、どの瞬間でも検査中のサービスの出力を受けるだろう状態検査ファンクションを選択する。
【００５９】
制御フロー471はトリガーを許し、その検査要求と状態を検査するファンクションは、与えられた瞬間での検査中のサービスから明らかである。これは、他の検査要求が動作するのを妨げないが、それらの出力は単に無視される。
【００６０】
選択された検査要求が413のとき、フロー431は、検査中のサービスの入力と出力のデータフローの組を表す。フロー433は同じタイプのものであるが、検査要求415が選ばれたときである。
【００６１】
フロー441は検査中のサービスの入力を表す。これは検査417中のサービスによる441の消費に対応する。
【００６２】
フロー451は検査中のサービスの出力を表す。これは417による451の産出に対応する。
【００６３】
フロー461は検査中のサービスのフローを再び表す。このフローは状態検査ファンクション419における検査の目的のためにのみ使用することができ、変えることができない。しかしながら、検査の軌跡を記録するために追加のフローを生じさせることができ、491によってのみ消費させることができる。
【００６４】
初期条件ブロックは入力を持たず、その出力フローは検査中のサービスのための入力と出力の両方の初期値を含む。これらの初期値は実証の初期で環境ループ411によって消費される。
【００６５】
検査環境のダイナミック動作を理解するために、我々は、図４における種々のブロックとフローがいかに働くかを述べ、種々のフローを介していかに情報が変化し、種々のブロックによって変更されるのいくつかの例を与える。
【００６６】
例えば、検査要求413と状態検査ファンクション419が図４において現在トリガーされることを考えよう。それから、ループはブロック413、417、419および411の間で動作している。このループはデータフロー441、451、461、411により可能である。検査中のサービスからスタートし、サービス417がドア施錠サービスであること、およびそれが施錠されてない状態からスタートする施錠状態へちょうど変わったことを考える。施錠指令は451を介して送られ、それからプロセス419を検査する状態は施錠指令を受け取り、検査結果記録491へ受領通知（acknowledgment）を送る。しかし、ブロック419は出力フロー451を変化させず、461を介して環境ループ411へそれを転送する。環境ループ411においては、施錠指令は、ある遅延時間の後、ドア状態を施錠にセットする、施錠アクチュエータのモデルに受け取られる。それから、環境ループ411は（ドアが施錠されたという）情報を431を介して検査要求413へ送る。この情報はあたかも施錠状態センサにより出されたかのように受け取られる。乗物が単に解錠されたとき、ドア施錠のトリガーを意図する検査要求413は、ドアの施錠状態を検査417中のサービスへデータフロー441を介して転送する。それから検査中のサービスは、その環境から何の新しい要求も来ないときには状態が変化せず、ループは何の変化も無しで継続する。
【００６７】
もし我々が制御システムを取り扱おうとするなら、検査オートマトンによって何の変化も要求されないときでさえ、ある規定のループがその時間中動作するのを除いて、事態は変化しない。
【００６８】
検査オートマトンがいかに好ましくインプリメントされ得るかを説明するために、我々は施錠された乗物からスタートし、上述の検査シナリオがいかに進行するかをいま述べる。
【００６９】
乗物の現在の施錠された状態に対応して、状態検査ファンクション419が検査オートマトンにおいて状態403によってトリガーされたことを想定する。それから移行407が解錠要求に対応する検査要求415をトリガーすることを想定する。一旦、415がトリガーされると、検査中のサービスがいまその入力を415から受け取るように、フロー441が不活性（inactive）となり、フロー433と443が活性（active）となる。移行407が処理された後、検査オートマトンは、状態検査ファンクション421がトリガーされる状態405に入る。それから、検査中のサービス出力のみがいま421へ送られるように、フロー453と463は作動中になり、419出力は無視される。
【００７０】
新しいループはいま415、417、421、411およびそれから再び415である。検査要求は、417入力での解錠要求をシミュレートするように、環境を変化させつつある。反応として、ブロック417は、（もしすべてのことが適切に働くなら）検査結果記録491へ受領通知を送るであろう、状態検査ファンクション421へ解錠要求を送るだろう。ブロック421は、417出力を変化させず、データフローを直接環境ループ411へフロー461を介して転送する。解錠指令の結果として、前に施錠されたドア状態は解錠されるだろう。それからこの新しい状態は、センサ情報として検査要求415へフロー433を介して転送される。一旦、ドアが解錠されると、検査要求415はもはや他の要求がフロー443を介してシミュレートされないように無意味となり、そのループはスイッチが他の検査要求まで安定となる。
【００７１】
実証の最初のステップで、初期条件ブロックは起動され、最初の入力のセットを検査中のサービス417へ注入する。これが実証の用意をさせる。実証を成功のよいチャンスといっしょに達成されるために、初期条件は十分に安定な初期状態、例えばサービスが作動される状態を確立するために容易だろう。
【００７２】
我々は特定された種々のオブジェクトのセマンティックを説明し、そのシステムがいかに動力学的に動作するのかの例を与えた。しかしながら、完全の目的のために、時間がいかに分配されるかを説明する必要がある。実際、オートマトンの各移行は、呼び出し時間といっしょに特定される。同様に、検査中のサービスの動作に関するオートマトンの各移行は、図３に伴う説明において特定された呼び出し時間といっしょに定義される。検査オートマトンにおける呼び出し時間は、各移行の前に新しい検査要求へ特定される。もし検査要求が、検査中のサービスの一時的な状態をモニターするなら、それから呼び出し時間は、検査中のサービスの反応性との関係において非常に短い。
【００７３】
図４は我々の検査環境のための一般的なフレームワークであり、それは種々の輪郭がいかにインプリメントされるかによる、たくさんの方法で修正され、カスタマイズされるだろう。これは図11に関する解説において詳しく述べられるだろう。
【００７４】
シミュレーション レベルで、環境はマトラブ／シミュリンクのようなツールで発展したモデルによりインプリメントすることができる。これはモデル化レベルでバグを見つけるのを許す。そのようなシミュレーションを達成するため、全体的な（global）時間の定義を特定することができ、具体的な呼び出し時間を、環境ループにおいておよび検査中のサービスのモデルにおいて、検査オートマトンにおける各移行へ付け加えることができる。
【００７５】
この案にはいくつかの変形が可能である。第１に、ユーザ要求にいくつかの検査要求を加えること、あるいは種々の検査要求の間で共通のファンクションを分けること、あるいは検査要求をパラメーターで表す、あるいは検査要求の特定の内部に任意の変数を導入することが可能である。これらは、検査要求がいかに結局はインプリメントされるだろう変形であるが、これらのすべての変形は、シミュレーションに関係するいくつかのパラメーターが検査オートマトン、検査要求および状態検査ファンクションに一様に加えられるだろうことを除いて、図４に描かれたフレームワークと等価である。
【００７６】
図４に描かれたように検査環境または実証環境の例は、一旦、サービスがブロック417において特定されると、自動的に生成することができる。この非常に主要な例は、骨組み実証環境と呼ばれる。その骨組みにおいては、ブロック411、413、415、417、419および同様のものすべては、自動的に生成される。ブロック間のデータフローは、図４の描写といっしょにそれに応じて自動的に生成される。ブロック間のデータフローは図４の描写といっしょに状況に応じて自動的に生成される。これらのブロックの内部のデータフローもまた自動的に生成され、ブロックは入力もまた出力であるとき、同一性のごとくふるまう。他の入力はそのブロック内で終結する。
【００７７】
そのような自動生成は、例えばマトラブ／シミュリンクのようなシミュレーション環境において可能である。
【００７８】
図５では、検査オートマトンが表される。検査オートマトンの各状態は、検査中の動作に関するモデルのターゲット状態に対応し、検査オートマトンの各移行は検査要求に対応する。初期条件ブロックのためを除き、各検査要求はユーザ要求に対応することが思い出されるべきである。
【００７９】
我々の発明で述べたように、検査の目的は、状態を完全にカバーすることおよび検査中のサービスの動作に関するオートマトンの移行を許すであろう検査のシーケンスを提供することである。
【００８０】
検査オートマトンの各移行は、我々が検査したい動作に関するモデルにおける移行のシミュレーションに対応する。そこで検査状態と動作の状態との間の１対１対応がある。例えば、「乗物のドアを施錠する」という状態のために、検査状態は「我々は、システムが乗物のドアを施錠することを行わなければならない場合を検査する」のセマンテックを持つだろう。同様に、検査中の動作に関するモデルにおいて、「乗物解錠」の要求が与えられたとき、検査プランにおける対応する要求は「乗物解錠がユーザにより要求されたように環境が変更される」のセマンテックを持つだろう。これのすべては図４の描写から明らかである。
【００８１】
検査中のサービスにおける検査要求（初期条件ブロックのためを除く）とユーザ要求との間の１対１対応により、検査は、我々が検査環境からエミュレートしたいユーザ要求のシーケンスとみなすことができる。そこで、検査モデルを作る目的は、検査中のサービスにおけるユーザ要求と状態の詳細な補償範囲を提供することであり、またこれは、すべての状態に達し、検査中のサービスのすべての移行を通り過ぎるユーザ要求のシーケンスのリストを同定することにより達することができる。
【００８２】
我々はいま、グラフ理論におけるアルゴリズムの形式での検査の生成の好ましい実施を提示する。使用されたアルゴリズムは、適用されたグラフのように見えるオートマトンにおける詳細な最初の検査のように見える。グラフ理論において、状態はノードと呼ばれ、移行は矢印と呼ばれる。我々は同じソースと目標状態を持つ種々の移行を禁じないので、いくつかの矢印は２つの状態をリンクすることができることに留意されたい。
【００８３】
その考えは、グラフにおける各ノードへ、目標としてのそのノードといっしょに各矢印へ、それ自体を関係付けられるであろう、“ｐ”と呼ばれるプレデセッサのファンクションを作ることであり、１つのプレデセッサは、その矢印がそのプレデセッサからそのノードへ行くようなものである。プレデセッサは、特定された初期の状態もまた要求する。一旦、そのプレデセッサのファンクションが自動的に同定されると、詳細な検査シナリオがｐから帰納的に作られる。
【００８４】
まず、我々は適応されたグラフ上でのプレデセッサのファンクションの定義に向かう。
アルゴリズムの操作中に、各ノードは、それが前の操作の間にアルゴリズムによって処理されたことを意味する、状態Ｓ１または逆を意味するＳ２を持つことができる。状態Ｓ２を持つノードが与えられると、それはグラフにおけるそのノード“Ｎ”のすべての即座のサクセッサが“Ｎ”、またはその逆を意味するＥ２から始まってアクセスされたことを意味する、状態Ｅ１を持つことができる。ノード“Ｎ”のサクセッサは、ソース“Ｎ”を持つ矢印の目標であるノードである。各ノード“Ｎ”のために、“Ｎ”のサクセッサの数はｄ(Ｎ）と呼ばれる。もし我々が“Ｎ”から既にアクセスされた“Ｎ”のサクセッサの数をｎ(Ｎ）と呼ぶなら、その場合は“Ｎ”は、ｎ(Ｎ）がｄ(Ｎ）より完全に下である間は、状態Ｅ２を持つ。もしｎ(Ｎ）がｄ(Ｎ）と同じなら、その場合は“Ｎ”は状態Ｅ１を持つ。それが前のステップにおけるアルゴリズムによって処理されるが、まだ“Ｎ”から始まりアクセスされていない場合において、ノード“Ｎ”のサクセッサが同時にＳ２とＥ１であることに留意されたい。
【００８５】
アルゴリズムが再帰である：
初めに、ノード“Ｎ０”がアルゴリズムの初期のノードとして選ばれる。これは検査プランの初期状態に対応する。
アルゴリズムの与えられたステップで、ノード“Ｎｋ”が処理される（初期ステップでの“Ｎ０”のように！）。２つの場合が可能である：
もし“Ｎｋ”状態がＥ２なら、その場合は“Ｎｋ”から始まり、“Ｎｋ”の少なくとも１つのサクセッサはアクセスされない。それを“ＮＷ”と呼ぶ。
もし“ＮＷ”が状態Ｓ２を持つなら、その場合は“Ｎｋ”から“ＮＷ”へ各移行のためにＰ(“ＮＷ”)＝“Ｎｋ”をセットし、アルゴリズムは“ＮＷ”を処理する。
もし“ＮＷ”が状態Ｓ１を持つなら、ノード“Ｎｋ”へ戻り、“ＮＷ”は現在アクセスされている。
もし“Ｎｋ”状態が、“Ｎｋ”のすべてのサクセッサが現在処理されているＥ１なら、その場合はもし“Ｎｋ”のためのプレデセッサ“Ｎｙ”が存在するなら、アルゴリズムは再帰的に“Ｎｙ”に適用される。
アルゴリズムは“Ｎ０”が状態Ｅ１を持つとき、停止する。
さて、そのｐが立ち上がったら、我々はシナリオの構造に向かう。もしノードが他のプレデセッサでないなら、我々はそれをリーフ（leaf）と呼ぶ。シナリオは単に、ノード“Ｎ０”で始まり、すべての可能なリーフで終わる、状態と移行のすべての可能なシーケンスのリストである。各シナリオは、リーフから始まり、その後、“Ｎ０”へのバックトラッキングまでプレデセッサのファンクションを適用して作られる。精々１つの適用された移行が２つの状態をリンクする場合、この定義は十分である。しかしさらに、我々は２つのノードの間のすべての可能な移行が少なくとも１つのシナリオによってアクセスされるという可能性を持つ。この拡張はインプリメントするのにまったく簡単であり、我々はアルゴリズムの詳細を述べない。
【００８６】
前のステップはシナリオのリストを生じ、各シナリオは状態“Ｎ０”から始まり、他の状態“Ｎｉ”で終わる。もし可能なら、適用されたグラフの中で２つのノードをリンクさせる古典的なアルゴリズムを用いて、そのような各シナリオ、“Ｎｉ”から“Ｎ０”へのリターンパスのために、その後計算し、それをそのシナリオへ付け加える（そのパスは、移行の数によって最も短いものであることを必要としない）。それから我々は検査シナリオのリストを得、それぞれの１つは“Ｎ０”で始まり、“Ｎｉ”で終わる。いくつかのシナリオは、それらがある「ノン リターン」チェンジに対応することを意味する、“Ｎ０”へ戻らない可能性がある。これは、システムが動作を継続することができない、乗物が衝突するような非常に特別な場合を除いて、組み込まれたシステムにおいて非常にありそうもない。
【００８７】
そこで、検査シナリオの同定の終わりで、我々はシナリオのリストを得、各シナリオは一連の連続する状態と移行から成り、各シナリオは可能なとき、初期状態“Ｎ０”で始まり、“Ｎ０”で終わる。さらに、これらのシナリオは、サービスの動作に関するオートマトンのすべての状態およびすべての移行の完全なカバレッジを形成する。検査オートマトンの生成のために他のインプリメンテーションが可能である。我々は他の可能なインプリメンテーションのために［ＡＨＯ７４］に言及する。
【００８８】
図５に戻り、輪郭511、513および515は、上記の説明で特定された検査シナリオを表す。輪郭531、533、535、537、539、541、543、545（531から545）は、検査中のサービスの目標状態に対応する状態、および検査中のサービスの目標移行の活性化に対応する移行571から585を表す。
【００８９】
状態531での始まりに対応する初期条件は、選ばれた初期状態531との関連において設定されなければならない。初期状態は、初期始まり記号501と503から同定される。各信号のために、適した初期値が設定される。例えば、もしドア施錠サービスのための初期状態が、乗物がアイドリングし、すべてのドアが施錠されている状態であるなら、ドア施錠状態とエンジン状態は状況に応じて設定されなければならない。すべての検査は、同じシステム状態で始まり、終わる（可能なときはいつでも、いくつかの状態は到達可能でないかもしれない）。そこで、移行521と523は、２つのシナリオの間の無意味な移行である。各シナリオの終わりでの参照状態へ戻るという事実は、「連続的な検査」に対応するシミュレーションを止めることなしに、連続するシナリオを実行するのを許す。これは、図５の例において、状態531、545、551および561が検査中のサービスの同じ状態に対応するということを意味する。もちろん、もしある状態が参照状態に戻る可能性無しに到達するなら、シミュレーションは停止され、それから他のシナリオにおける初期条件で再び始まらなければならない。
【００９０】
図４で述べたように、タイミングは、時間を持つ検査されたファンクションを正確に反応させるか、タイムリーな一時的な移行を検査するかのいずれかの、検査のオートマトンの移行上に仕様が記載されている。タイミングは、特定された範囲において変化することができ、それから検査は、各移行のために特定された範囲の元で、ハザード呼び出し時間の生成と合わせられ得る。検査の移行上にトリガーを追加することも可能である。そのようなトリガーは、ユーザ要求のまたはシステム応答制限に対応する。例えば、もしユーザ要求が「100km/hのスピードに達する」ことなら、ぞの場合は100km/hのスピードに達したことを示す信号は、新しいユーザ要求を注意深く読むためにトリガーされ得る。検査のオートマトンにおいては、例えば新しいユーザ要求を操作する前でトリガー後に１秒待つ等の、遅延とトリガーの混合になり得る。図５に描かれたシナリオは、例えばユーザ要求がシステムの状態を変化させることができる各時間等、これが正当なとき、システムが正確に反応するということだけを検査する。しかしながら、あるユーザ要求が、与えられたコンテキストでの対応するシステム応答を何も持たなかったということが時々要求される。これはある種の「起こらない」使用の場合または不可能な使用の場合である。
【００９１】
検査プランは、不可能な使用の場合の検査を含むように、完全なものにすることができ、これらの使用の場合は、ある状態において何の答えもないユーザ要求に対応する。これをインプリメントするため、我々は無視されるであろうユーザ要求に対応する補充的な状態と移行といっしょに、検査シナリオを簡単に片付ける。そのような無視されたユーザ要求は、結果として生じる状態を変化させない。例えばもし移行579が、不可能な使用の場合に対応する無視されたユーザ要求をインプリメントするなら、その場合は状態537と539は、検査中のサービスの同じ状態に対応するだろう。もし動作を簡単にするなら、もしいくつかの移行が取り消されるなら、生成された検査シナリオはいまだ正当だが、部分的だろう。
【００９２】
図６では、機能的なレベルで検査中のサービスのレイアウトを述べる。動作に関するオートマトン201とファンクション211、213、215、241、243および245は、図２におけるこれらのブロックをリンクする各フローといっしょに、図２から取られる。図６では、我々は特に入力と出力のドライバを論じる。
【００９３】
ドライバ621はセンサ601から情報を取得し、この情報をファンクション211と215へ送る。211と215は種々のレートで流れを消費することができるということに留意されたい。ドライバ621は、例えばセンサ601からハイまたはロー信号を受け取り、与えられたサンプリング レートでファンクション211と215へ状況に応じて「０」または「１」の値を送る、論理入力であり得る。同様に、ドライバ623はセンサ603から情報を取得し、この情報をファンクション211、213および215、しかし245へも送る。623と645の間のリンクは、取得された情報は例えば制御ループのために検査中のサービスのシステム応答をインプリメントするファンクションによって直接消費されるという事実を説明する。
【００９４】
ドライバ661はアクチュエータ611に命令し、ファンクション241と243から各フロー641と643を介して情報を受け取る。これは、ファンクション241と243が検査中のサービスの種々の状態でアクチュエータ611に命令することができ、または再びファンクション241と243の両方は、アクチュエータ611が命令された各時間このアクチュエータ611の命令に関与するということを意味する。同様に、ドライバ663はアクチュエータ611に命令し、フロー645と647を介してファンクション241と243から情報を受け取る。検査中のサービスのこのモデル化は、種々の方法で図４のブロック417に挿入することができる。
【００９５】
１つの解決は、ブロック417にファンクションのみを挿入し、ドライバは挿入しないことである。その場合、417の入力と出力は、論理または「ディジタル」入力と出力であり、その実証は検査中のサービスの低レベルのソフトウェアとハードウェアを含まない。動作に関するオートマトンとファンクションのみが実証される。他のステップは、ドライバ621、623、661および663を含むことにある。その場合、実証は物理的レベルでなされる。その場合、ドライバもまた実証される。
【００９６】
もし417ブロックのコンテンツが図６に描かれたようなサービスなら、電子的制御ユニットも通信ネットワークも特定されないので、これは本質的には特定とソフトウェアの実証の目的のためである。これは電子的制御ユニットとネットワークがいかに実証されるかを詳しく述べるための図７の目的である。しかしながら、例えば速いプロトタイピング インプリメンテーションのコンテキストにおいてのような、検査中のサービスが特定のＥＣＵ（電子的制御ユニット）上に写像された場合、図６に描かれたサービスは、ハードウェアのループ検査のための基礎になり得る。
【００９７】
図７では、図６に描かれたサービオスは、ＥＣＵと通信ネットワークからなる物理的アーキテクチャー上に写像されたものである。記号701、703、705および707は、我々がネットワーク701と呼ぶ特定の通信ネットワークを意味する。このネットワークは例えばＣＡＮバスであり得る。輪郭751と753は電子的制御ユニットを意味する。実際、701は751におけるネットワーク入力フローに、703は751からのネットワーク出力フローに、705は753におけるネットワーク入力フローに、707は753からのネットワーク出力フローに対応する。
【００９８】
ＥＣＵ751の物理的インターフェースは、センサ601、アクチュエータ611、およびネットワーク インターフェースからなる。同様に、ＥＣＵ753の外部のインターフェースは、センサ603、アクチュエータ613、およびネットワーク インターフェースからなる。もし我々がＥＣＬ751と753内のブロックを注意深く見るなら、図６で描かれたサービスが割り当てられたことをわかることができる。動作に関するオートマトンは輪郭791と793内に分配され、我々は、分配ストラテジーは図６または２における初期の動作に関するオートマトンの入力と出力を保存するということを仮定するだろう。しかしながら、他の分配ストラテジーはサポートされる。また、ドライバは、それらの関係付けられたセンサまたはアクチュエータの写像のファンクション内に分配された。
【００９９】
ファンクション211、241および243はＥＣＵ751上に写像され、ファンクション213、215および245はＥＣＵ753上に写像された。写像によると、我々は、ＥＣＵ753内のドライバ623によって生じたフローはＥＣＵ751内のファンクション211によって消費され、これはドライバ717と711を介して、ＥＣＵ751と753間のネットワーク接続により可能であるということをわかることができる。そこで、図６のデータ フロー633はいまデータ フロー733の構成物としてインプリメントされ、ネットワーク ドライバ717を介して753からネットワーク上に出され、ネットワーク ドライバ711を介してＥＣＵ751内のネットワークから受け取られ、フロー721を介して211へ伝えられる。もしいま図４の輪郭417における検査中のサービスが図７におけるようにインプリメントされるなら、その場合は我々は例えばネットワーク上のメッセージ交換が適切にインプリメントされることを実証することができる。
【０１００】
図８では、図７で描かれたサービスのインプリメンテーションが配線の限定といっしょに拡張された。バス トポロジーおよびザ ウエー センサとアクチュエータはいま特定された異なるＥＣＵへリンクされる。ＥＣＵ751、753および801はそれぞれコネクタ827、825および829を介してネットワーク811へリンクされる。
【０１０１】
センサとアクチュエータ601、841、611は、コネクタ821とケーブル861を介してＥＣＵ751へリンクされる。コネクタ831は、例えばアクチュエータ603がコネクタ831と827を介してＥＣＵ753へ接続されるようにケーブル867、869へリンクする。センサとアクチュエータ コネクタは簡単化の目的のため、図に示されない。また、接地接続は表されておらず、それらはＥＣＵ、センサ、アクチェータの間でケーブルまたは単線を介して接地位置への接続に単にあるだろう。
【０１０２】
そのような描写が輪郭417内で検査されるとき、これは配線の特定において配線は何の不足がないことを確証することを許す。417のインターフェースはセンサとアクチュエータのコネクタのレベルで特定されるだろう。その場合、特定を実証するためにすべてのコンポーネントをシミュレートすることが可能である。またシミュレートされた部分を現実のＥＣＵとインターフェースすることも可能である。この問題は図11で論じる。
【０１０３】
図９Ａ〜９Ｃの部分からなる図９では、我々は、コネクタの定義と、その特定の実証の目的のために、後でそのインプリメンテーション上に、１つのコネクタがいかにモデル化され得るかに焦点を当てる。
【０１０４】
図９Ａでは、輪郭901と903は、例えばケーブル901内の配線921とケーブル903内の配線923等の、配線をいっしょに集めるケーブルを表す。コネクタ831は、雄コネクタ913と雌コネクタ911からなる。図では、雄と雌コネクタは接続されてない。雌コネクタ931のピンは、雄コネクタ933のピンに対応する。
【０１０５】
図９Ｂでは、我々は雄と雌コネクタ ピン933と931に焦点を当て、それらをコンタクト943と941を介して配線923と921にリンクさせるかを説明する。
【０１０６】
図９Ｃでは、我々は、モデル化レベルでの実証の間のコンタクトのインタープリテーションを表す。配線921はデータ フロー951として説明され、配線923はデータ フロー953としてインタープリトされ、雄と雌コネクタ ピンの間のコンタクトは、入力データ フロー951と出力データ フロー953といっしょのファンクション963としてインタープリトされる。
【０１０７】
通常のフォールト フリー コンタクトの場合、ファンクション963は同定としてインプリメントすることができる。フォールトのある接続の場合では、ファンクション963は、短絡または不安定な接触のような接触不良による一定のまたは任意のファンクションであり得る。
【０１０８】
図10Ａ〜10Ｄの部分からなる図10では、我々は、例えばフォールト トレラント ファンクションを検査する目的のために用いられる、フォールトの投入のインプリメンテーションを論じる。図10Ａでは、配線1003と1001は互いに非常に接近しており、それらはポイント1011で接触され、アクチェータ1021に電力を供給する、配線1001のための接地1031へ短絡という結果になる。
【０１０９】
図10Ｂでは、配線1001と1003を含むケーブルは、入力1041、1043、出力1045、1047を持つファンクションとしてインタープリトされる。1001の一端は1041として、1001の他端は1045としてインタープリトされる。同様に、1003の一端は1043として、他端は1047としてインタープリトされる。配線1001と1003を含むケーブルは、ファンクション1051としてインタープリトされる。接地への短絡は、入力が何であれ、アクチェータ1021へ0（0アンペア強度のインタープリテーション）を出力する、定数関数の形の1051のインプリメンテーションとしてインタープリトすることができる。このインタープリテーションは、フォールトの存在する実証の目的のためにフォールトが入る場合に対応する、短絡がフロー1081を介してファンクション1051に入るであろう場合にのみ適用可能であろう。
【０１１０】
図10Cでは、我々は１つの開回路を表す。配線1007と1009は、破壊された配線を共に形成する。1007の破壊されていない端部は、図10Dにおいて入力フロー1061として説明され、1009の破壊されていない端部は、出力フロー1063としてインタープリテイトされている。配線それ自体は、ファンクション1071としてインタープリトされている。断線配線の場合と電流が1061から1063へ普通に流れる場合、断線効果は、1063を、電気開回路をインタープリトし、この値を1063の消費体に伝達する特定の最低値に設定する。1063のそのような動作は、開回路に対応するフォールトのプロファイルが、フロー1083を介して1063に入るであろうときにのみ起こるだろう。
【０１１１】
そこで図９と10は、各コンポーネント（ケーブル、雄および雌のコネクタ）が、それらの物理的インプリメンテーションがなされる前に実証を遂行されるファンクションとデータフローとしていかにインタープリトされ得るかを示す。自動車システムのコンテキストにおいて、電気的ネットワークは比較的単純で、ループ フリーとデータフロー インタープリテーションはこれが最も一般的な場合において可能でないのに、可能である。また、フォールト モデルは、実際の電気回路の動作を簡単化し得る。我々が保証するのを必要とするただ１つのことは、フォールト モデルが実際のシステム フォールトの集まりよりも大きいということである。
【０１１２】
図11では、サービスと実証の種々のステップの設計プロセスが描かれている。設計の進歩の段階の間、特徴の最初のモデルの労作まで実証は不可能である。そこで、使用の場合の仕様1101、動作に関するオートマトンからなる動作に関する仕様1003、その動作に関するオートマトンの各状態の中でどのファンクションが動作しているのかを示す機能的な仕様1105が一旦立ち上がると、それからすぐサービスのモデルを得るために各ファンクションのモデルを作ることが可能である。一旦、このモデルが得られると、その入力と出力は、「一般原則として」センサ、アクチュエータおよび他のサービスとのやり取りである。
【０１１３】
このステップで、検査プランを自動的に生成することが可能であり、検査モデルは図４と５に描かれた。その場合、環境ループは、入力と出力としてそのモデルの入力と出力を取ることができる。これは例えば命令とデータ収集のドライバの統合を排除する。乗物のドア施錠サービスの場合、あり得る入力は、ユーザからの施錠要求のフォーマットされたメッセージであってもよく、あり得る出力は、乗物のドアを施錠するリレーの命令であってもよい。ブロック417に挿入されたモデルは、図２に表されたような形であってもよい。使用の場合のレベルと機能的なレベルでタイミング要求を推定するのが既に可能であるが、このステップでのタイミングは大ざっぱに推定される。しかしながら、このステップでのタイミングは物理的なアーキテクチャーから実証されないだろう。
【０１１４】
このレベルでの実証は「モデル イン ザ ループ」1171と呼ばれる。それは、例えばマトラブ／シミュリンク等のシミュレーション ワークショップを用いて遂行されることができる。その場合、各ファンクションは、シミュリンクの元で実行可能なモデルの形で特定され、各動作に関するオートマトンは、 シミュリンク／ステートフロー（Stateflow）の元で実行可能なモデルの形で特定される。形式化かは、種々のファンクションの間のすべてのスケジューリング インターフェースを特定することを許す。
【０１１５】
それから、次のステップで、アプリケーション ソフトウェアを書き込みすることが可能である。：低レベル ソフトウェアによってフォーマットされた、高レベル入力と出力が与えられる、サービスをインプリメントするソフトウェア。アプリケーション ソフトウェアにおいては、ファンクションと制御オートマトンは、オペレーティング システムによってスケジュールされるべきタスクに分配される。もし我々がオペレーティング システムのモデルでオペレーティング システムの置き換えるか、あるいは実証1171の間、用いられた環境をモデル化することにおけるオペレーティング システムの実行を収容するかのどちらかを行うなら、その場合は実証1171におけるモデルのピースを、対応する利用されたソフトウェアのピースで置き換えることによって、利用されたソフトウェアを実証することが可能である。これは、ソフトウェア イン ザ ループとも呼ばれる実証ステップ1173に対応する。
【０１１６】
その後、ドライバが特定される。それらは、低レベルの物理的信号を論理信号に変え、それらがセンサまたはアクチェータ ドライバに対応する事実により逆になる。それらが一旦ステップ1111において特定されると、それらはそれらの対応するセンサとアクチェータといっしょにモデル化され得る。それから、モデル ザ ループ シミュレーション1171を、ドライバおよび／またはセンサおよびアクチェータを含むシミュレーション1173に拡張することが可能である。ドライバがモデルに含まれる場合のみ、センサとアクチェータが、それらが形式化されるのを必要としないことを意味する、環境ループの一部であり、キャプチャーとコマンドの関係のみがモデル化されるのを必要とする。もし、センサとアクチェータ モデルが実証に含まれるなら、環境は、関係のあるアクチェータとセンサの間のリンクのモデルを含む。例えば、もし１つのセンサが、施錠がアクチェータにより正しく操作されたかどうかを検査するものなら、そのアクチェータとそのセンサの間のリンクは、アクチェータの与えられた開位置がセンサに解錠位置を送るというモデルになるだろうし、また逆もある。そのようなモデルを得る方法は、各コンポーネントの物理的動作をモデル化することである。
【０１１７】
実際には、センサとアクチェータが環境ループ内にある場合は、サービス ファンクションが適切に特定されたことを検査することが十分に詳しく述べられているので、このステップで最も有用である。さらに、センサとアクチェータの適切なモデルを得ることは、難しいかもしれず、また、我々の目的は、コマンドまたは取得された情報がうまく処理されることを実証することである。しかしながら、たとえセンサとアクチェータが、設計プロセスのこのステージで適切にモデル化されなくても、健全なコマンドとキャプチャーの範囲は、スペースと時間の両方において特定されることを必要とする。一旦、ドライバとコンポーネントの特性が特定されると、ステップ1113において、低レベル ドライバが、部分的にソフトウェア コンポーネントとして、部分的にハードウェア コンポーネントとしてインプリメントされる。
【０１１８】
いま低レベル ソフトウェアとそのスケジューリングを含む実証ステージ1181において、ソフトウェア イン ザ ループを反復することが可能である。設計ステップ1121において、ＥＣＵとネットワークが選ばれ、サービスの機能的説明は異なるＥＣＵ上に写像される。まず、異なるバス上にセットされたメッセージがインプリメントされるのは必要としない。各ＥＣＵは、接続された各バス上で他の接続されたＥＣＵにメッセージのセットを出す。一旦、写像がなされると、図７の形で描写された各サービス、ステップ1183を実証することが可能である。
【０１１９】
設計ステップ1123では、各バスのためのメッセージのセットが特定され、また実証1153は、通信とネットワーク管理のための低レベル ソフトウェアといっしょに、メッセージ交換のための低レベル ソフトウェアを含むことができる。また、一旦、ＥＣＵが特定されると、それらもまたインプリメントされ、すべてのＥＣＵがいっしょに、または少しのＥＣＵのためにハードウェア イン ザ ループがなされ得、それらの他のものは、ネットワークに接続された１つのＰＣ上にシミュレートされる。
【０１２０】
設計ステップ1131では、コンポーネント（センサ、アクチェータ、ＥＣＵ）は、乗物マップ上に幾何学的に写像され、その書き込みが設計される。図９で描写されたように、配線とコンポーネント コネクタを説明すると、それから図４の輪郭417の解釈を、その配線といっしょにインプリメントされたサービスに拡張することが可能である。このモデル イン ザ ループ検査は、実証ステップ1185において遂行される。この新しいフレームワーク内でソフトウェアを再び検査することは可能であり、ハードウェア イン ザ ループ検査は、実際の対象とする配線と共に実行し得る。
【０１２１】
最後の設計ステップにおいては、図９で説明したように、それらのモデル化といっしょに、接続されてないコネクタが特定され、再び全体のモデルとインプリメンテーションのピースは、モデル化、ソフトウェアのインプリメンテーションおよびインプリメンテーションハードウェアのレベルで、検査され得る。
【０１２２】
図12では、我々は、安全システムのための特定の開発プロセスに焦点をあてる。そのプロセスは次のステップからなり、使用の場合のリスト（図11の1101）と動作記述（図11の1103）の形式の元で、一旦、動作説明1201がなされる
１ 望ましくないイベントとそれらの重要性の同定（1203）
２ その現実のまたは仮想のセンサとアクチュエータで形成されたシステムの機能的特定（1205）
３ リンプホーム（Limp-home） モードの記述（1207）
４ 望ましくないイベントの現実のまたは仮想のアクチュエータへの関連付け（1209）
５ 機能的アーキテクチャー上の望ましくないイベントの精錬（refinement）（1211）
６ 安全要求精錬を伴った冗長度の導入（1213）
７ ハードウェア アーキテクチャーの定義（1215）
８ 電子的制御ユニット上のファンクションの写像（1217）
９ 有効な電子的アーキテクチャーのフォールト トレランスの実証（1219）
10 物理的コンポーネントと配線の幾何学的写像（1221）
11 有効な電気-電子的アーキテクチャーのフォールト トレランスの実証（1223）
このプロセスは線形であるように意図されない。少しのループは、プレゼンテーションにおいて隠される。例えばステップ６は、多数のやり直しを生じるかもしれない種々の方法によってインプリメントすることができる。また、種々のハードウェア アーキテクチャーは、目標が、与えられたフォールト トレラント要求の元でよりコストのかからないアーキテクチャーを見つけるように、ステップ７において調査することができる。ステップ８では、特にもしステップ９が、１つの写像が満足でなく、ある仕事をもっと要求することを立証するなら、種々の写像が調査される。また、ステップ10では、ノードの種々の位置を検査することができる。
【０１２３】
我々の記述の主な目的は、ステップ９と11を説明することである。安全分析が遂行される方法は、我々が完全性の目的のために、ステップ９と11を、１つのセルフ-コンテント設計プロセスへ関連付けるために、種々のステップを思い出すように、我々にとって目的の外にある。
【０１２４】
１．望ましくないイベントとそれらの重要性の同定
このステップは、安全分析の伝統的な部分である、機能的障害分析（Functional Failure Analysis：ＦＦＡ）のよく知られたステップである。１つのシステムのためのＦＦＡの結果は、上記イベントが生じたとき、結果の深刻度を伴う望ましくないイベントの同定である。
【０１２５】
２．その現実のまたは仮想のセンサとアクチュエータで形成されたシステムの機能的特定
このステージで、我々は、既に早くに述べた設計フォールトの定義を精錬することができる。設計フォールトは、機能的仕様において作られたフォールトである。
【０１２６】
３．リンプホーム モードの記述
モードの記述は、機能的アーキテクチャーに補足的である。１つのシステムは、データフロー［Fuchs98］をトリガーする、例えばステートチャート（Statechart）等の制御オートマトンからなるように記述することができる。最も高いレベルで、オートマトンは、初期化、ノーマル モード、リンプホーム モードおよび１つのモードから他へスイッチする動作等のシステム モードをインプリメントすべきである。
【０１２７】
例えば車のブレーキ システムの場合、前左のブレーキが機能しておらず、他のブレーキが適切に働いているなら、ブレーキングは、多くの場合、ブレーキを全然かけていないよりも悪い、乗物の安定性の低減という結果になるだろう。そこで、その場合、ブレーキングにおいて、信頼できるリンプホーム モードが、それぞれ適用されたブレーキ圧力を伴う前右と後左のブレーキでのブレーキングにあるだろう。その場合、乗物の速度は後に減少し、乗物は安定を維持するだろう。
【０１２８】
クリティカル システムでは、ノーマル モードがあるフォールトにより利用できない場合、リンプホーム
モードはたいていはグレードを下げられたサービスを提供する状態にあるだろう。これは我々が11においてスタートするステップである。
【０１２９】
４．望ましくないイベントの現実のまたは仮想のアクチュエータへの関連付け
各望ましくないイベントのためのＦＦＡの結果の部分集合のみを考慮する我々のプロセスでは、我々は、関与しているアクチュエータ、障害が望ましくないイベントを引き起こすであろうアクチュエータ、普通に機能する他のすべてのアクチュエータを考慮する。
【０１３０】
例えば乗物ブレーキ システムのために、我々は望ましくないイベントである「ブレーキ中の安定性の欠如」を考慮することができる。もしアクチュエータの１つがブレーキをかけてなく、他の３つがかけているなら、これは可能であろう。もし我々の対象が、システムが１つのフォールトにトレラントであるということなら、１つの分析は、例えば安定性の欠如がアクチュエータの１つの障害によるという結論を導くことができる。その場合、我々は「ブレーキ中の安定性の欠如」を各ブレーキ アクチュエータだけに関連付けるだろう。もしいま、我々が望ましくないイベントである「ブレーキが要求されているがブレーキがきかない」を考慮するなら、その場合はこの望ましくないイベントがすべてのブレーキのセットに明らかに関連付けられたように、どのアクチュエータも健全なコマンドを受けなかったということが明らかである。
【０１３１】
しかし、我々のブレーキ システムは制御オートマトンによってトリガーされるということ、およびブレーキ要求は「ブレーキ」状態へ導くオートマトンの移行であるということを想像されたい。もし移行が適切に実行されないなら、たとえ各ブレーキが適切に働いていても、望ましくないイベントは起こるだろう。そこで、１つの望ましくないイベントは１つの状態移行に、もし前記状態移行障害が前記望ましくないイベントを起こすことができるなら、結び付けることができる。このステップの終わりで、各望ましくないイベントは、深刻度と共に、１つまたはすべてのアクチュエータまたは状態移行結果の少しの部分集合に付け加えることができる。
【０１３２】
深刻度レベルのためのあり得る参照は、基準［IEC61508］に提供される。深刻度によれば、１つまたは２つのフォールトの存在におけるフェイル-サイレントまたはフォールト-トレランス レベルは、障害受領の予期される確率と共に、予期される。
【０１３３】
電気的ブレーキ システムの場合、アクチュエータは「フェイル-サイレント」であることが要求され、すなわち、１つのブレーキが、それが機能を果たさない物理的状態に置かれることができることが立証されるべきである。もし確率が予期されるなら、我々は、電気的ブレーキは、例えば１時間当り10−８のように非常に低い、単位時間当りの確率ｐを除いて、機能を果たさない物理的状態に置かれることができるということを言うだろう。
【０１３４】
５．機能的アーキテクチャー上の望ましくないイベントの精錬
最初に、センサ、アクチュエータおよびファンクション、並びにデータフローからなる機能的アーキテクチャーが与えられ、あるデータフローは電流をモデル化し、バッテリはセンサとしてモデル化される。
【０１３５】
我々は、前のステップ ａ）望ましくないイベントおよびリンクされたアクチュエータにおいて同定した。それから設計エンジニアは、前記アクチュエータを孤立して関連付けられた望ましくないイベントによる、フェイル-サイレントまたはフォールト-トレラントまたは各アクチュエータの種々の入力フローからの要求がないことを彼が予期するかどうかを示すことができる。
【０１３６】
例えば、ブレーキ システムの場合、ブレーキだけが存在するようになる要求として、各ブレーキのブレーキ力（制動力）コマンドはフォールト-トレラントに特定することができる。しかし、設計者は、１つの障害が検知された後、もしブレーキ システムが十分に敏速に反応することができるなら、フェイル-サイレント要求が十分であるということを単純に考慮するかもしれない。このタグを付けることは、我々の方法における１つの入力である、その機能的アーキテクチャーおよびそのプロパティによる。
【０１３７】
繰り返して、我々はそれから、同じ分析を各ファンクションと前記ファンクションのための各関連する望ましくないイベントに適用することによって、ファンクションとアクチュエータの安全要求を決定する。もし１つのファンクションが、機能的アーキテクチャーを介して、アクチュエータの１つのセットの制御に直接寄与するデータフローを生じさせるなら、その場合は我々は、そのファンクションのために、アクチュエータの前記セットの部分集合にリンクされたすべての望まれないイベントを、前記ファンクション上と前記ファンクションの入力上に安全要求を作り上げることを考慮する。さらに、我々はそのファンクションを、１つの前の安全分析から来るその出力上の各制限とみなさなければならない。
【０１３８】
６．安全要求精錬を伴った冗長度の導入
それから、各ファンクションのために、そのファンクションのインプリメンテイション モードは、これまでに生成された安全要求により、複製と要求された票決機構をインプリメントするために選ばれる。
【０１３９】
有効な機能的アーキテクチャーは初期のそれより大きい。もしフォールト トレランスまたはフェイル-サイレント要求が何も特定されないなら、その機能的アーキテクチャーは、このステップで変化しない。
【０１４０】
７．ハードウェア アーキテクチャーの定義
このステップで、我々は、システムをインプリメントするであろう電子的制御ユニットとネットワークを単純に特定する。安全分析が定量的である１つのコンテキストにおいて、単位時間当りの障害レートが予期される。
【０１４１】
８．電子的制御ユニット上のファンクションの写像
このステップで、例えば図11のステップ1121で説明したように、ファンクションが電子的制御ユニット上に写像される。
【０１４２】
９．有効な電子的アーキテクチャーのフォールト トレランスの実証
この実証は、図４におけるように検査環境によって遂行される。新規な点は、我々がいま動作がフォールトの存在において健全かどうかを検査することである。そこで各コンポーネントは、図10のポート1081と1083のようなフォールト導入ポートを装備している。それから１つの検査導入プランが特定される。我々が１つのフォールトの存在における動作を検査したい場合、図４におけるような実証環境はそのアーキテクチャーにおける各コンポーネントの各フォールトのために実行される。導入され得るフォールトは、図10に述べられているように、配線オープン、短絡であるが、しかし、例えばネットワーク オープン、送られなかったフレーム、ＥＣＵリセット、…などである。リストは、システムにおいて使用されるコンポーネントにより拡張するので限定的ではないが、主に電気的コンポーネントとそれらのインターフェースに制限されるだろう。
【０１４３】
フォールトがスタンダードなので（開回路、短絡、ＥＣＵのリセット）、それらのモデル化は、その実証が、フォールト モデルの導入からフォールト導入を伴う実証の実行へ自動的に遂行され得るようにスタンダードであることに留意されたい。フォールトの検査の順序は、実証が各フォールト発生のために実行されるので、あまり重要ではない。
【０１４４】
10．物理的コンポーネントと配線の幾何学的写像
このステップで、電子的制御ユニット、バッテリ、センサ、アクチュエータおよびさらに一般的な電気的コンポーネント間の配線パス、コネクタおよびケーブルが特定され、伝統的な工学プロセスが続く。
【０１４５】
11．有効な電気-電子的アーキテクチャーのフォールト トレランスの実証
これは、我々がいま網羅的な配線記述を含めることを除いて、ステップ９におけるのと同様なステップである。それからフォールトの導入は、ステップ10で付け加えられるすべての新しいコネクタと配線のピースのために付け加えられる。
【０１４６】
図13では、我々は検査環境装置について述べる。それは、検査中のＥＣＵ1321と1323、およびこれらのＥＣＵのための環境シミュレーションに関与する多数のコンポーネントからなる。そのような装置は、それらの機能的な要求に適切に合うＥＣＵ1321と1323を実証するのを許す。またこの図は、導入部と図11において述べられたようなハードウェア イン ザ ループ環境のインプリメンテーションを示すだろう。
【０１４７】
パーソナル コンピュータ1301は、ＰＣ1301上に実行された１つのモデルがＥＣＵ1321とインターフェースされるように、取得およびコマンド ボード1313を介してＥＣＵ1321とインターフェースされる。ボード1313は、ＰＣ1301からバス1333を介して操作される。ＥＣＵ1321とボード1313との間のインターフェースは、ケーブル1343とコネクタ1355および1371を介して遂行される。
【０１４８】
同様に、パーソナル コンピュータ1301は、ＰＣ1301上に実行された１つのモデルがＥＣＵ1323とインターフェースされるように、取得およびコマンド ボード1315を介してＥＣＵ1323とインターフェースされる。ボード1315は、ＰＣ1301からバス1335を介して操作される。ＥＣＵ1323とボード1315との間のインターフェースは、ケーブル1345とコネクタ1357および1373を介して遂行される。
【０１４９】
ＥＣＵ1321と1323とはローカル エリア ネットワーク1341を介して接続され、多数の他のＥＣＵはこのバスに接続することができる。それから現実のハードウェア イン ザ ループを遂行するために、バス1341上の他のＥＣＵをシミュレートすることが必要である。これは、ネットワークといっしょに、受領可能でない、各ＥＣＵの動作の一部のみが検査されるように、ネットワークの障害が起きた場合、ＥＣＵが通常はリンプ モードを含むので、実際は強制的であろう。
【０１５０】
そこでボード1311は、ネットワーク1341上の欠けているＥＣＵをシミュレートするのを許すネットワーク インターフェースである。このボードは、バス1331を介してＰＣ1301に接続されている。もちろん、もしバス1341が、最大限に利用された組み込まれたバスであるなら、バス1331、1333および1335は何の制限も受けない。それらは例えばＶＭＥバスであってもよい。
【０１５１】
ＥＣＵ1321と1323を検査するとき、図８上で形成されたようにモデルにおけるそれらの輪郭を孤立させるには、それからＰＣ1301上のモデルの残りを実行するには十分である。もちろん、取得およびコマンド ボード1315、1313および1315間のすべての物理的インターフェースはコンフィガーされる必要があるが、このスタッフは最新の技術の状態でマスターされた。例えばＤスペース ツールは解法を与える。図13の特別な場合として、特有のＥＣＵの検査プランが、図８のＥＣＵの輪郭を孤立させることによって、図４と８のモデルから生成され、与えられたサービスまたは与えられたサービスのセットのために、一方でＥＣＵを、他方でＥＣＵの検査環境を考慮する。
【０１５２】
図14では、我々はメッセージ セットのモデル化および概念を述べる。組み込まれたドメインにおいて、バスは主に、種々のプロトコルにより出され、受けられるフレームに関して述べられる。組み込まれた利用のために、ＣＡＮ（コントローラ エリア ネットワーク）が広く用いられる。
【０１５３】
最初のステップは、図14Aで示されるような運ばれたデータフローのタイプに特別な注意を払わないで、各フレームのコンテントを特定することである。これは、データ サイズまたはフレームの位置に関してのどの制限も無しに、それぞれデータ1、データ2、データ3およびデータ4のためのレコード1411、1413、1415および1417が単純にリストされている、輪郭1401内に示される。
【０１５４】
第２ステップは、図14.Bにおけるような現実のフレーム レイアウトを考慮することにある。それから、各データの正確なロケーションと共にフレームのオーバーヘッドが特定される。例えばロケーション1425でのデータ２は、そのフレームの第３オクテットのビット２から第４オクテットのビット５へ書き込まれるだろう。また、フレームにおける差し込みが小さいエンディアンか大きいエンディアンかどうかを知ることが要求される。
【０１５５】
モデル化の第３ステップは、１つのフレームにおけるデータの書き込みと読み出しを許す、ＡＰＩをモデル化することにあってもよい。
【０１５６】
第４および最後のステップは、バス ドライバ ハードウェア インターフェースのためのアセンブラ コードをインタープリトすることであろう。実際、第３と第１ステップは、たいへん役に立つ。
【０１５７】
図16は、我々がいくつかのサービスのための検査オートマトンを織り混ぜる倍医を示す。今日に至るまで、我々は１つのサービスのための検査環境の特定に焦点を合わせた。我々はいまいくつかのサービスのための検査オートマトンの混合に焦点をあてる。
【０１５８】
共通の使用の場合を共有するサービスの１つのセットを我々が検査する場合、同期が、これらのサービスの検査オートマトンの間で遂行されなければならない。検査中のすべてのサービスのために共通の使用の場合が同期して実行される制限と共に、検査は織り混ぜられなければならない。これは遂行するのが難しくない。しかしながら、この検査アプローチは、トランスバース インパクトを有する使用の場合が以前のステージで正しく同定された状態の元で妥当である。
【０１５９】
他のサービスと共に実証されるのが必要なサービスの良い例は、エネルギーの管理である。このサービスは、各サービスにより要求されたパワーが実際パワー管理サービスから利用可能であるかどうかを見るために、他のサービスとトランスバーサリーに検査されるべきである。
【０１６０】
その場合、１つの乗物のたくさんのサービスにより共有された使用の場合は、典型的に「ユーサがエンジンをスタートさせる」である。パワー管理サービスのために、これは、「アルタメーター（altemator）が動作しており、パワーがアルタメーター パワー ラインへ切り替えられる」のような１つのシステム応答の結果となる。輪郭1601がパワー管理サービス検査プランの引用であるということ、および移行1623が乗物のエンジンをスタートさせるユーザ要求であり、エンジンのスタート チェックは状態1615において遂行されるということを考慮しよう。状態1611、1613および1617は、パワー管理サービスの他の状態のための他のチェックに対応する。
【０１６１】
環境（climate）制御のような他のサービスのために、エンジン スタートは、カー エンジンがまだ停止しているのに、もしクーリングが要求されたら、「クーリングがスタート」のようなシステム応答の結果となる。輪郭1603は、クーリング サービス検査プランの引用であり、移行1623のような移行1641は、エンジン スタート要求に対応することを仮定されたい。
【０１６２】
両方のサービスを一緒にする場合、それぞれの検査オートマトンは輪郭1605におけるように併合（merge）され得る。移行1623と1641は、それらは単一のユーザ要求の周囲に同期されるので、移行1675に併合される。他の要求は影響を受けないと仮定すると、両方のサービスの検査オートマトンは、次のような併合された検査オートマトンに翻訳（translate）される。
【０１６３】
・状態1611は状態1651に翻訳される。
・状態1631は状態1653に翻訳され、移行1671は達する状態1631を許す冷却サービスの移行に対応する。
・状態1613は状態1655に翻訳される。
・移行1621は移行1673に翻訳される。
・移行1623と1641は移行1675に併合され、翻訳される。
・状態1617は状態1659に翻訳される。
・状態1635は状態1635に翻訳される。
・移行1625は移行1677に翻訳され、移行1643は移行1679に翻訳される。
【０１６４】
翻訳のセマンティクスは、同一の移行が併合される場合を除いて、操作の固有性である。初期の検査オートマトンの状態が一緒にされた方法は、ランダムに見える。実際、両方のプランの呼び出し時間の制限はこの混合を駆動する。もちろん、ある同期は、同じ時間が２つの同期した状態間の各１つの検査オートマトンにおいて経過するように、必要とされる。これらのすべては、一方の移行1621、1625と他方の移行1643が完全に独立しているという前提の元でなされる。そこで我々は、いくつかのサービスが、それらのそれぞれの１つの実証環境に応じて、いかに実証され得るかを示した。これは、異なるサービスのユーザ要求が独立しているかまたは同期され得るかのいずれかの前提の元で可能である。
【０１６５】
また、検査中のすべてのサービスの初期の状態は同じでなければならない。同じに実証されるすべてのサービスの検査オートマトンは、すべてのそれらのサービスのために、共通の初期の状態でスタートし、すべての単一の検査オートマトンの初期の状態は、併合された検査オートマトンにおける特有の初期の状態において併合される。
【０１６６】
本発明の方法は、該方法の様々なステップをインプリメントし、それによって最終的に、組み込まれた電気的システムのために提案された設計を供給することにおける使用のための実証環境を自動的に出力するために、コンフィガーされた１つのコンピュータによってインプリメントされることができる。実証環境は好ましくは、それから後で、関係する各サービスのために提案された設計を実証するための１つのコンピュータの助けられた設計ツールによって使用されるだろう１つのコンピュータ 読み出し可能なメモリ デバイス内に記録され、そのような設計ツールは同じかまたは異なるコンピュータのいずれか一方を構成する。
【０１６７】
方法のステップは、特に例えばＣＤ、ＤＶＤまたは同様物のような、コンピュータ 読み出し可能なメモリの形で、または設計ツールのハード ディスク上に直接、コンピュータ プログラム製品上に記録されることによって商品化される。それから該方法は、読み出し可能で、関係するコンピュータ／設計ツールによって実行可能なコンピュータ プログラムとして、そのメモリ デバイス上に記録されるだろう。
【０１６８】
用語解説：（導入された順番にほぼ従っている）
使用の場合（Use Case）：１つのサービスの使用の簡単なシナリオの記述。１つの使用の場合は、コンテキストの定義、ユーザ要求、システム応答からなり、また例えば終−終 実行時間のようなパフォーマンス要求も含んでもよい。
【０１６９】
ユーザ要求（User request）：サービスに対するユーザの要求
システム応答（System response）：ユーザ要求に関連するサービスの応答であり、そのサービスをインプリメントするシステムの手段が与えられるもの。
【０１７０】
使用の場合のコンテキスト（Use Case Context）：使用の場合が利用できる、例えば機械的および電気的コンポーネントの状態等のコンテキスト。
【０１７１】
ムーア オートマトン（Moore automata）：移行上にトリガーされたコマンドを有しないオートマトン。
【０１７２】
動作に関するオートマトン（Behavioral automata）：状態と移行が、連続するユーザ要求および観点するシステム応答をまねる制御オートマトン。
【０１７３】
状態（State）：例えば動作に関するオートマトンにおけるシステム応答をトリガーする、オートマトンの状態。いつくかの状態は、同じファンクションを実行することができる。動作に関するオートマトンにおいては、状態がシステム応答を実行する。
【０１７４】
骨子実証環境（Skeleton validation environment）：検査または実証環境のための、基本的な輪郭およびデータフローを含む、検査間王のモデルのテンプレート。
【０１７５】
移行（Transition）：例えば動作に関するオートマトンにおけるユーザ要求をインプリメントする、オートマトンの移行。動作に関するオートマトンにおけるいくつかの移行は、同じユーザ要求を実行することができる。
【０１７６】
ファンクション（Functions）：は、ユーザ要求、システム応答およびどのオートマトンによってトリガーされた他のアクションをインプリメントする簡単で実行可能なコンポーネントである。１つのファンクションは、入力と出力データフローを持ち、ある動作は入力値のファンクションにおける出力値をトリガーする。システムの設計フェイズの間、ファンクションは、結局はソフトウェアのピースまたはハードウェアのピースとしてインプリメントされることができる。
【０１７７】
検査要求（testing request）：は、ユーザ要求と関係付けられたファンクションである。検査要求は、サービス記述とインターフェースされ、そのサービス インプリメンテーションにおけるその関連するユーザ要求を活性化するようにそのサービス入力をシミュレートする。
【０１７８】
状態チェック ファンクション：は、動作に関するオートマトンの状態に関連付けられる。それは検査中のサービスの出力とインターフェースされ、前記サービスがその関連する状態を介して行くとき、肯定的な検査結果、さもなければ否定的な結果を出すようにインプリメントされるべきである。
【０１７９】
初期状態ブロック（Initial conditions block）：実証の初期状態における、すべてのシステム コンポーネントの状態に対応する、すべてのデータフローの初期化。
【０１８０】
環境ループ：全体のシステムが実行およびシミュレーションに関して自己満足であるように、モデルおよび／またはハードウェア イン ザ ループ 検査環境および／またはＥＣＵおよび／または配線および／またはコンポーネント間の実行ループ。
【０１８１】
検査環境または実証環境：検査中のサービスおよび／またはそのサービスの実証の目的のための検査中のサービスのシステムおよび／または設計プロセスの異なるステップでのそのシステムとインターフェースされる環境。
【０１８２】
検査オートマトン（testing automata）：検査中のサービスのためにユーザ インタラクションとコンテキスト スイッチを詳細に述べる検査環境の部分。
【０１８３】
検査中のサービス（Service under test）：実証環境がそのために開発されたサービス。
【０１８４】
骨子実証環境（Skeleton validation environment）：すべてのファンクションの中で検査中のサービスからの部分が同定ファションである、実証環境の特定の実施例。骨子の目的は、関連する検査オートマトンと共に実証環境の複合的なデータフローを生成することである。骨子が一旦自動的に生成されると、それはモデル イン ザ ループの間で完成され、実証され得る。
【０１８５】
ハ−ドウェア イン ザ ループ検査（Hardware in-the-loop testing）：ドライバは、低レベル信号および高レベル ソフトウェア変数とインターフェースする。ネットワーク ドライバの場合、ドライバ範囲は、ネットワーク フレーム内のデータを挿入することおよび引き出すこと、フレームの発信と受信をトリガーすることを含む。アナログ ディジタル入力の場合、関係付けられたドライバは、サンプリング レートとデータ フォーマットが与えられたディジタル フォーマット内にアナログ信号を置く。
【０１８６】
サービスの写像（Mapping of a service）：ＥＣＵとネットワークから構成されるハ−ドウェア アーキテクチャ上の１つのサービスのインプリメンテーションの間、サービス コンポーネントは、例えばこれらのＥＣＵ上のサービスをインプリメントするソフトウェアのピースのような、異なるＥＣＵ上に写像され、そのサービスをインプリメントするセンサおよび／またはアクチュエータは、異なるＥＣＵに付け加えられるか、写像される。
【０１８７】
コネクタ（Connector）：製造と組立が容易であろう小さなコンポーネントに配線を分配する目的のため、配線アーキテクチャ内に挿入された１つのコンポーネント。また、配線とＥＣＵ間のインターフェース。１つのＥＣＵは、それぞれ１つが１つの異なる配線でそのＥＣＵとインターフェースする少しのコネクタを持つことができるだろう。
【０１８８】
ケーブル（Cable）：例えば乗物の製造プロセスにおけるように、組立を容易にするためにいっしょに集められた配線の１つのセット。
【０１８９】
配線（Wiring）：配線、コネクタおよび関連する電気的コンポーネントの設計に対応する設計ステップ。電子的部品は、一般に含まれない。配線は、例えば乗物のドアの配線、または乗物のコックピットにおけるマルチメディア ファンクションの配線のような、リンクされたケーブルとコネクタの１つのセットでもある。
【０１９０】
参照
ＡＨＵ74：
アホ、ホップクロフト ジェイ イー、ウルマン ジェイ デーによる1974年、ザ デザイン アンド アナリシス オブ コンピュータ アルゴリズムズ、アディソン ウエズリー、リーディング、マス
カン（ＣＡＮ）：
カンの明細書、ボス
Fuchs98：
オンラインで利用できるSAEペーパー 980199
www4.informatik.tu-muenchen.de/publ/papers/FEMPS98.pdf
Harel87：
エルセヴィア サンエンス パブリッシャー Ｂ．Ｖ（ノース ホランド）、1987年
Rushby95
コンピュータ サイエンス ラボラトリ、SRI インターナショナル、メンロ パーク、CA
ＩＥＣ61508：
発行者：インターナショナル エレクトロテクニカル コミッション（ＩＥＣ）、1998年
Simu：
マトラブ／シミュリンク アンド マトラブ／ステートフロー：（機械電子工学システムのシミュレーションをサポートする利用可能な主な商品）
http://www.mathworks.com
HIL&Test：
Dspace、ハードウェア イン ザ ループ：（ハードウェア イン ザ ループのサンプルおよび検査技術および技術の状態についての多数の関連があるペーパー）
http://www.dspaceinc.com/ww/en/inc/home.htm
【図面の簡単な説明】
【０１９１】
【図１】１つのサービスの使用の場合の仕様を示す。
【図２】１つのサービスの機能的な説明を示す。
【図３】１つのサービスの動作に関する記述を示す。
【図４】本発明によって自動的に生成される検査環境の骨子を示す。
【図５】図４における検査環境の一部である検査オートマトンを示す。
【図６】１つのサービスの機能的な記述を示す。
【図７】２つのＥＣＵと１つのネットワークを含む分配されたシステムを示す。
【図８】３つのＥＣＵと１つの配線ネットワークを含む分配されたシステムを示す。
【図９】コネクタ インターフェースを示す。
【図１０】電気的レベルでのフォールトのモデル化を示す。
【図１１】本発明による設計プロセスの１つの実施例を示す。
【図１２】安全クリティカル システムの設計プロセスの使用を示す。
【図１３】ハードウェア イン ザ ループの検査環境を示す。
【図１４】例えばＣＡＮバスのようなローカル エリア ネットワークにおけるフレームの１つの異なる仕様のマチュリティを示す。
【図１５】イン ザ ループ シミュレーションと検査の一般的なパラダイムを示す。
【図１６】いくつかの組み合わされたサービスの検査環境の混合を示す。
【技術分野】
【０００１】
本発明は、システム設計の実証、特に組み込まれた電気的システムの実証方法の設計に関する。
【背景技術】
【０００２】
システム設計と検査のために種々のツールと方法が開発されている。1980年代の間、システム設計者が彼のシステムの動作環境を特定するのを許すように構造化ツールが開発され、その後、そのシステムの各パートの期待される動作を特定するために、階層アプローチが続いた。構造化分析方法は、この第１の期間の良い実例である。
【０００３】
しかしながら、複雑なシステムのためには、このことは十分でなく、設計ツールがシミュレーションを許す実行可能なツールになったことがすぐに明らかになった。しかしながら、このパラダイム シフトの間、初期のシステム要求とシステムの実行可能な特定との間のリンクは、最初は保護されなかった。もちろん、事実上の制限中のシミュレーションは、事実上の動作環境および実行可能なモードへの初期の要求からの追跡性における検査を妨げず、その後、検査事例は盛り込まれなかった。コード化は依然としてシミュレーションの後になされ、初期のモデル化ステップでなされた誤りの検知および修正が許される。
【０００４】
たくさんの人々を含む非常に大きな発展のために、初期の要求とシステムの特定との間のリンクが最も大切であったことがあとで明らかになり、その後、要求、モデル、コードの要素、および検査の間のリンクを確立するために要求管理システムが始まった。しかしながら、技術の現在の状態を表すこのステップで、要求、モデルおよび検査の間のリンクが公式ではなく、手動で維持されなければならない。ユニバーサル モデリング ラングウェッジ（ＵＭＬ）のようなアプローチは（モデル化と検査を要求する）異なるプロセス ステップを獲得する試みをするが、ＵＭＬフォーマリズムは異なる設計ステップの間の非公式なリンクよりも本当に現実的に支持するのにあまりにぼんやりしている。
【０００５】
同時に、自動化された検査検査発生計画は、実行可能なモデルの情報を利用するように試みるために発展したが、検査動作環境における要求の獲得の不在において、検査はある冒険的なアプローチとともにやみくもに行われ、そのような検査は１つのモデルのあるパートには非常に効率が良いが、他のパートを簡単に省くことがよく知られている。
【０００６】
手動でなされた検査の場合、検査中のコンポーネントが適切な初期の状態においてセットされたとき、実行可能な検査ベクトルを特定しなければならないが、一連の電子的制御ユニット（ＥＣＵ）のブラック ボックス検査を得ようとするのは非常に困難である。
【０００７】
現実の上級の検査機の組み入れがあまりに費用がかかるので、ハードウェアの設計が非常に最適化されるドメインのために、一連のコンポーネントのブラック ボックス検査はいつも必要であることが留意されるべきである。
【０００８】
また、いったんモデルが設計されると、ファンクションが割り当てられ、その後、特に、異なる要素が異なる供給者によって開発されなけらばならないとき、ファンクションのそれぞれ割り当てられた要素のためのまとまった検査を供給するという課題が来る。これは未解決の問題である。現在、支持されたアプローチは、異なるコンポーネントのプロトタイプを待ち、具体化し、その後、相互に作用し、デバッグすることである。これは現実のデバッグは、ハードウェア設計がフリーズしたときに始まり、ほとんど能率的でないプロセスを意味する。
【０００９】
故障許容ファンクションの場合、検査に故障の投入を含め、これをそのようなファンクションの割り当てられた特徴と結合させることもまた要求される。このステージで再び、ほとんど標準で決定論者でないアプローチが利用できる。
【００１０】
米国特許第5394347号において、ＥＦＳＭ（拡張された有限の状態機械）を採用する検査環境を設計する方法が開示されている。ＥＦＳＭにおいてユーザの要求とシステムの応答との間には相違はなく、すべてのユーザの要求とそれらの要求に対するシステムの応答はいつも変遷の中に溶け込む。この提案においては、システムのイベントがインプットであるが、また例えばベルを鳴らすというようなアウトプットをカバーする。それから少なくとも「バリアブル スタック」と「モデル スタック」のトラックを維持するのが必要なので、使用された技術がユーザの要求とシステムの応答とを区別しないということが米国特許第5394347号の不便な点である。さらに、これはまた、米国特許第5394347号においては、特定の正しいインプリメンテーションを実証することのみが可能であり、特定それ自体を実証することが不可能であるということを意味する。米国特許第5394347号における提案に対応してなされるシミュレーションは、特定において「力」として言及されたあらかじめ定義されたファンクションといっしょにセットされ得る、検査されるシステムの可変の動作環境として時間がみなされるので、リアル タイムではなされない。この機構は、信号処理のシミュレーションのためには十分ではない。
【００１１】
それゆえ、特に割り当てられたファンクション設計の場合において、システム モデルおよびその実現の種々の工程でのその物理的な表現を正確に実証するのを許すシステム検査の規則正しい設計のための改良された方法のための連続する必要性があるということがわかり得る。
【特許文献１】米国特許第5394347号
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、改良されたシステム設計の実証方法を提供し、特に組み込まれた電気的システムの実証方法の改良された設計方法を提供することにある。当該電気的システムは特に電子コンポーネントと電気回路の構成部分を含むことは正しく理解されるだろう。
【課題を解決するための手段】
【００１３】
したがって、本発明は、組み込まれた電気的システムによってインプリメントされるサービスのための実証環境を設計する方法を提供し、該方法は、
ａ）前記サービスに、１つ以上のユーザ要求およびシステム応答を割り当て、
ｂ）前記サービスに、動作に関するオートマトンを割り当て、前記動作に関するオートマトンは、前記ユーザ要求およびシステム応答の許された配列を記憶し、
ｃ）シミュレーション ツール上で実行可能なモデルの形で、前記サービスのための骨子実証環境を自動的に生成し、前記骨子実証環境は、前記動作に関するオートマトンのトラバーサルから生じた検査オートマトン、初期状態のモデル、ユーザ要求のモデル、システム応答精度のモデル、環境モデルおよびこれらのモデルをいっしょに集めるデータフローおよび制御フローを含み、前記骨子実証環境は、前記サービスのすべてのユーザ要求および結果として生じるシステム応答をカバーし、および
ｄ）設計実証ツールによる使用のためのコンピュータの読み出し可能なメモリー デバイスに前記骨子実証環境を記録する。
【００１４】
骨子を用いることにより、検査環境は、検査環境とモデルそれ自体の両方を実証するために、検査中のサービスのモデルといっしょにシミュレートすることができる。設計プロセスにおける非常に初期の誤りを修正することにより、本発明の方法は、システム設計と開発においてたくわえられる時間を与え、検査範囲と質も非常に改善する。前記サービスは、例えばブレーキ バイ ワイヤ等の安全クリティカルおよび／または故障許容システムのような、乗物に使用されるサービスを含むことができる。
【００１５】
検査動作中のファンクションを実証するためにシステム応答精度のモデルの出力を記憶し、分析できることは正しく理解されるだろう。システム応答精度のモデルの出力は、システムの応答が正確か、さもなければ不正確なとき、本当になる、典型的にはブール（Boolean）式である。
【００１６】
ユーザ要求とシステム応答精度のモデルは、以前に開発された骨子実証環境の少なくとも一部を記憶することによって、あらかじめ定義できることは正しく理解されるだろう。
【００１７】
その方法は、それをインプリメントする１つのファンクションを各ユーザ要求に割り当て、それをインプリメントする１つまたはそれ以上のファンクションを各システム応答に割り当てることを含むことができ、前記骨子実証環境のデータフローは、ユーザ要求とシステム応答の前記ファンクションを用いて形成される。
【００１８】
その方法は、その入力と出力がそのサービスをインプリメントするファンクションの少なくとも１つの入力と出力に対応する、ブラック ボックス インターフェースを前記サービスに割り当て、前記サービス ブラック ボックスの出力を前記骨子入力に、前記骨子出力を前記サービス ブラック ボックスの入力にインターフェースし、実証の結果を出すために、シミュレーション環境における骨子とサービス特定を全部揃え集めることを含むことができる。
【００１９】
その方法は、前記サービスのための実証環境を含み、同時に該サービスの実証されたモデルを含む、実証されたモデルを出力することを含むことができる。
【００２０】
その方法は、サービスのモデルをそのソフトウェアのインプリメンテーションで置き換えることを含むことができる。
【００２１】
その方法は、サービスのモデルをそのソフトウェアおよびハードウェアのインプリメンテーションで置き換え、前記ハードウェアのインプリメンテーションとインターフェースされた検査プラットフォーム上に前記実証環境を組み込むことを含むことができる。
【００２２】
その方法は、乗物におけるブレーキ バイ ワイヤ システムのような、故障許容システムにおけるすべての再生された目的のために、故障の体系的な投入を含むことができる。
【００２３】
その方法は、少なくとも１つのユーザ要求を共有する様々なサービスのための実証環境を割り当て、前記サービスのセットのための実証環境を生じるために、前記サービスの前記実証環境を混合することを含むことができる。
【００２４】
本発明はまた、プログラムがコンピュータ上で動作するとき、本発明のすべてのステップを遂行するためのプログラム コード手段を含むコンピュータ プログラムも提供する。本発明はまた、プログラム製品がコンピュータ上で動作するとき、本発明の方法を遂行するための、コンピュータの読み出し可能な媒体上に記憶されたプログラム コード手段を含むコンピュータ プログラム製品も提供する。
【００２５】
本発明はまた、システム設計の実証のために適合された設計ツールも提供し、前記設計ツールは、本発明による方法を用いることによって、組み込まれた電気的システムのための実証環境を出力するのに使用されるように設計され、あるいは本発明によるコンピュータ プログラム製品を用いてプログラムされている。
【００２６】
ソフトウェア コードのセクションが該モデルから生成されたとき、該モデルのパーツは、発生されたコードを実証するために、それらの対応するインプリメンテーションで置き換えることができる。前記システムのハードウェアがプロトタイプされるとき、ハードウェア イン ザ ループ環境のピースをインプリメントすることができ、前記検査環境を組み込む。このことは、たとえハードウェア環境が様々な電子的制御ユニット（ＥＣＵ）上に割り当てられるとしても真実である。
【００２７】
システムの配線が特定されるとき、ハードウェア イン ザ ループは、配線とコネクタの特定を実証するために、特に故障投入が用いられる安全クリティカル システムの場合において、使用することができる。
【発明を実施するための最良の形態】
【００２８】
本発明は添付の図面を参照して実施例のみによって述べられる。
図１は１つのサービスの使用の場合の仕様を示す。
図２は１つのサービスの機能的な説明を示す。
図３は１つのサービスの動作に関する記述を示す。
図４は本発明によって自動的に生成される検査環境の骨子を示す。
図５は図４における検査環境の一部である検査オートマトンを示す。
図６は１つのサービスの機能的な記述を示す。
図７は２つのＥＣＵと１つのネットワークを含む分配されたシステムを示す。
図８は３つのＥＣＵと１つの配線ネットワークを含む分配されたシステムを示す。
図９はコネクタ インターフェースを示す。
図10は電気的レベルでのフォールトのモデル化を示す。
図11は本発明による設計プロセスの１つの実施例を示す。
図12は安全クリティカル システムの設計プロセスの使用を示す。
図13はハードウェア イン ザ ループの検査環境を示す。
図14は例えばＣＡＮバスのようなローカル エリア ネットワークにおけるフレームの１つの異なる仕様のマチュリティを示す。
図15はイン ザ ループ シミュレーションと検査の一般的なパラダイムを示す。
および、図16はいくつかの組み合わされたサービスの検査環境の混合を示す。
【００２９】
電子システムは、電子的制御ユニット（ＥＣＵ）からなり、通信バス、センサ、アクチュエータ、および例えば配線、コネクタ、リレー、ヒューズ、バッテリ、発電機等の種々のシステム コンポーネントへパワーを供給する電気デバイスを通してネットワーク化することができ、またはネットワーク化しないことができる。
【００３０】
電子システムは、工場の労働者、カー ドライバ、自動車修理工、あるいはエンジニア等の顧客にサービスを提供する。例えば、考察中の電子システムが車に組み込まれる場合、本発明で論じられるようなシステムは、空調、車の動き、またはドア施錠のようなサービスをインプリメントできる。
【００３１】
電子システムはたくさんのサービスをインプリメントできるので、それらの場合においてサブシステムのセットとして純化することができ、各サブシステムは明確なサービスのセットを達成する。その説明においては、我々はそのような分解を考慮する必要はないだろうし、システムおよびそのシステムによってインプリメントされる１つまたはいくつかのサービスを簡単に考慮するだろう。無条件に特別なサービスを考慮して、その連合されたシステムはそのサービスのインプリメンテーションに関与するコンポーネントの中にあるだろう。
【００３２】
システムの実証は、できるだけ徹底的にシミュレーションと検査の手段によって供給することにあり、サービスの要求は、システムにおけるそれらのインプリメンテーションによって適切にカバーされることにある。サービスを実証することは、設計の種々のステージで種々のアプローチによって成し遂げることができる。そのサービスがモデル化されるとき、そのモデルはバーチャル環境において実証することができる。これは「モデル イン ザ ループ」と呼ばれる。その後、そのサービスをインプリメントするソフトウェアが生じさせられるとき、それはモデルにおいて収容させ、実証させることができる。これは「ソフトウェア イン ザ ループ」と呼ばれる。その後、ハードウェアが設計されるとき、その環境はそのシステムに対するインターフェースであるハードウェア環境において再びシミュレートすることができる。これは「ハードウェア イン ザ ループ 実証」と呼ばれる。さらに、そのシステムの環境は、「ハードウェア イン ザ ループ」環境、または単に「ＨＩＬ」と呼ばれる。
【００３３】
我々はまだ、検査ベクトルを生じることからなる通常のアプローチに言及していない。実際、この方法は、適切な検査を生み出すことが困難なので、「イン ザ ループ」環境の提示より劣る。本発明のアプローチは、現在に至るまで何の方法も与えられず、イン ザ ループの検査の設計は低コストでモデルを作るので、非常にうまくいく。検査環境骨子を産出することによって、我々は非常に低コストでこの大発見を与える。実際、ループにおけるモデルが論文において述べるとき、対話方式の環境モデルが設計される方法は、決して特定されず、そのシステムの設計者の義務である。図15に示されるように概略のアイデアは非常にシンプルである。検査中のモデル1501と環境モデル1503があり、それらはフロー1511と1513を通して情報のフローを交換する。そのシミュレーションは、そのシステムのモデルにおいてゲインの信頼を促進する。実際には、もし我々が定常的シミュレーションよりほかの何かを、そして我々の発明で提案したような自動の生成の不在において検査したいならば、そのようなモデルの設計は、非常に難しい。例えばブレーキ システムを検査するために、たくさんの場面を考慮に入れなければならない。そのサービスのモデルを実証するためにあとで適用できる、環境を検査するような最小の努力で生成を促進するために、このことが我々の発明の目的であり、そのソフトウェアがそのサービスおよびそのシステムの部分または全体を実行する。
【００３４】
本発明は、１つの組み込まれた電気的システムによりインプリメントされる１つのサービスのための実証環境を設計する方法を提供する。その方法をインプリメントするために、そのサービスに１つまたはそれ以上の「ユーザ要求」および「システム応答」を割り当てることが必要であり、ユーザ要求とシステム応答の両方が図１およびそれに伴う説明に開示される。
【００３５】
次に、そのサービスに、ユーザ要求とシステム応答の与えられた配列を用意する、動作に関するオートマトンを割り当てることが必要である。図３は、１つのサービスの動作に関するオートマトンの定義と内容を示す。
【００３６】
これが行われたとき、１つの骨子実証環境は、そのサービスのために自動的に生成され、その骨子実証環境は、前記動作に関するオートマトンのトラバースから生み出される検査オートマトン、初期状態のモデル、ユーザ要求のモデル、システム応答精度のモデル、環境モデル、およびこれらのモデルをいっしょに集めるデータフローおよび制御フローを含む。骨子実証環境は、そのサービスのすべてのユーザ要求と結果として生じるシステム応答をカバーする。骨子実証環境は図４に示され、そこには検査環境の一般的なフレームワークもまた示される。このフレームワークの特別な例は、このステップで自動的に発生される骨子である。
【００３７】
そのプロセスの有利な点は、我々が実証環境を設計する多くの時間を節約することであり、さらに我々の実証環境は、１つのサービスのユーザ要求とシステム応答のすべてを徹底的にカバーする。
【００３８】
さらに本発明の側面は、各ユーザ要求に、それをインプリメントする１つのファンクションを割り当て、また、各システム応答に、それをインプリメントする１つまたはそれ以上のファンクションを割り当てることを含む。この骨子実証環境のデータフローは、図２に関連して述べられるように、ユーザ要求とシステム応答のこれらのファンクションを用いて形成することができる。そのファンクションのデータフローおよび１つのサービスのデータフロー説明が、その骨子実証環境のためのデータフローにいかに変えるかが図４に示される。
【００３９】
本発明のさらなる側面は、以下のものを含む。
ｇ）サービスにブラック ボックス インターフェースを割り当てることを含み、その入力と出力はそのサービスをインプリメントするファンクションの少なくとも１つの入力と出力に対応し、
ｈ）そのサービス ブラック ボックスの出力を骨子入力に、骨子出力をサービス ブラック ボックスの入力にインターフェースし、そして、
ｉ）実証結果を生成するために、シミュレーション環境において骨子およびサービス仕様を完成し調整（correct）する。
【００４０】
サービスのブラック ボックス インターフェースは、実証環境のすべてのブロックのインターフェースを詳細に示す図４中のブロック417で示される。
【００４１】
本発明の方法はまた、サービスのための実証された環境を含み、同時にサービスの実証されたモデルを含む、実証されたモデルを出力することを含む。ループにおけるシミュレーション プロセスが詳細に述べられるとき、このシミュレーションが働く方法が図４中に示される。
【００４２】
本発明の他の側面の元で、サービスのモデルは、サービスをインプリメントするソフトウェアの実証の種々のステップが述べられる図１１に関連して述べられる、そのソフトウェアのインプリメンテーションで置き換えられる。
【００４３】
本発明の方法はまた、サービスのモデルをそのソフトウェアとハードウェアのインプリメンテーションで置き換え、ハードウェアのインプリメンテーションでインターフェースされる検査プラットフォーム上のその実証環境を組み込むことも含む。ハードウェアのインプリメンテーションを実証環境に挿入する方法は、ＥＣＵとネットワークの側面に関して、図７に関連して示され、図８においては実証における配線をまとめる。ネットワークのために伝える説明は、図１４中に具体的に挙げられ、１つまたはいつくかのＥＣＵのためにハードウェアの実証をインプリメントする機械は図13に関連して述べられる。
【００４４】
その方法は、乗物のブレーキ バイ ワイヤー システムのような、故障許容システムにおけるすべての再生された目的のための故障の体系的な投入も含む。故障許容システムを定義するのに続くプロセスは、図１２およびそれに伴う説明中に再び示される。それから、故障のモデル化と投入は、図９と１０に関して示される。他の実施例の元で、我々の発明は、少なくとも１つのユーザ要求を分けるサービスのための実証環境を混ぜることを許す。これは図１６中に示される。
【００４５】
図１においては、３つの使用事例の限定されない実施例が示される。これらの好例となる使用事例は、乗物のドアの施錠管理の説明の形態で、限定されないサービスの話をする。各使用事例のために、４つのパートにおける説明がなされる。第１のパート101、111、121は、それぞれの使用事例において適用できる状況である。第２のパート103、113、123は、それぞれの使用事例を述べるユーザ要求である。第３のパート105、115、125は、ユーザ要求によって誘発されるシステム応答である。第４のパート131、133、135は、ユーザ要求とシステム応答との間の呼び出し時間である。それらは最初のステージで必須ではない。
【００４６】
ユーザ要求は、検査が適用される分野がどんなものであろうとも絶対的なものであり得る。例えば自動車の分野において、車の衝突が起きたとき、我々はその衝突をユーザ要求であるとみなす。それはたとえ彼らの主導権でとりわけ要求されなくても、ユーザに代わって自動的にあるファンクションが誘発されるからである。実例は「燃料遮断」や「エア バッグ トリガー」かもしれない。我々は、ユーザは組み込まれたシステムのまわりのすべての外部の状況に対して責任があるとみなすだろう。前記もう１つの方法では、「ユーザ要求」は、「ユーザ要求およびユーザによって起こされあるいはユーザに影響を与える要求される状況」として広い意味に取ることができる。
【００４７】
使用の場合のためにたくさんの異なる初期状態を許容するため、状況は多少不明瞭である。例えばドア施錠 サービスのための状況は、すべてのドアが解錠されているかもしれないし、エンジンが動いているかもしれない。
【００４８】
システム応答が状態（state）でありユーザ要求が移行（transition）であることを考慮すると、使用の場合（Use Case）の１セットは、ムーア（Moore）のオートマトンへ変えることができる。正確なプロセスは、その使用の場合の状況に合う最初の状態から、その使用の場合のシステム応答に対応する１つの最終の状態へ、移行の１セットを使用の場合に関係づけることにある。サービスの動作に関する説明を得るため、システムの最初の状態を特定することが必要である。しかしながら、我々の発明は、ムーアのオートマトンのように動作を特定することができる限り、また、次の図面で示される他の制限の元では、特定する種々のプロセスをサポートする。
【００４９】
図２では、サービスの機能的なアーキテクチャーが描かれている。ユーザ要求はファンクション211、213および215によってインプリメントされ、状態において成し遂げられるためのシステム応答は、ファンクション241、243および245の間の１セットによってインプリメントされる。これらのファンクションは、それらあるいは先行あるいは一度モデル化された予定されている制限の間で、相互作用を有するかもしれない。ファンクションのセマンティックは図中に特定されておらず、ファンクションはその入力またはあるフィルタリングまたは両方のミックスの上の計算の操作であり得る。オートマトン201は環境から刺激221、223および225を受けることができ、その現在の状態により、状態を変えるかまたは変えない。例えば乗物が施錠されている状態で、もし解錠要求213がデータフロー223を介して「真」の値を送ると、オートマトンはトリガー233を介して、乗物のドアの解錠する結果として有する、「解錠」ファンクションが起動する状態へ動作することができる。実際の状態201により、ファンクション241、243および245は制御フロー231、233および235によってトリガーされることができ、これらの制御のそれぞれは１つの状態に入るとき予定されている。そのような動作は、シミュレーションのために環境が確立するやいなや、アドバンス フェーズにおけるシミュレーションを許す、マスワークス（Mathworks）の「マトラブ（Matlab）／シミュリンク（Simulink）」、またはロロジックス「ステイトメイト」（l'logix "Statemate"）のようなシミュレーション ツールによって正確にインプリメントすることができる。
【００５０】
図３に、ムーアオートマトンのサンプルが示される。状態321、323、325、327、341、343、345、347および349が、他のものの間で移行331、333、335、337、339を介して互いにリンクされている。このオートマトンのセマンティックを実施例によって説明する。例えばドア ロッキング サービスの例を継続して、状態343においては乗物が施錠され、状態341においては乗物が解錠されていることを想定する。それから移行337の間は、解錠の要求がトリガーされることを想定する。図２に概略が示された案をフォローし、移行337は刺激223によってトリガーすることができ、結果として生じる状態341はファンクション243によってトリガーすることができる。使用の場合とのリンクについては、状態341は応答状態105および移行337がユーザ要求103と対応することできるような結果として生じることができる。それから、状態343は最初の状態101と合わなけらばならない。
【００５１】
輪郭301と303はフェーズを示す。フェーズは共通の文脈上の情報を有する状態の１セットを集める。例えばエンジンが動作中のとき、クーリングだけを行うことができるので、「エンジン ランニング」は、クーリングのフェーズであり得る。異なるクーリング状態の数をいかに定義可能であろうとも、それらはすべて「エンジン ランニング」フェーズ中に集めることができる。フェーズはムーアオートマトンの読み易さを容易にするために有用であるが、本実施例に明確に用いることができないだろう。
【００５２】
最初のフェーズと状態は、状態チャートの形でトリガー311と313により特定される。これは323が、その第１のオペレーションのまったくのはじめでサービスの最初の状態であるということを意味する。また、各移行のために、移行を起動することができない元で、遅延を特定することができる。例えばアシューム（assume） 状態349は、例えば内側から後ろのドアをあけるという、あらかじめ決められた操作を子供が遂行できない「チャイルドロック」のように、内側から乗物の後ろのドアを施錠することにある。安全の理由のために、ドアが実際に施錠されているという確認は、施錠位置をモニターすることを通して遂行することができる。状態347が、ドアが結局はあかなかったことを信号で伝えることにあり、移行351が、施錠位置をモニターすることの結果として施錠が遂行されなかったとき、トリガーされることを考える。それからもし351が、リレーまたはアクチュエータの呼び出し時間により、ドアが実際に施錠される時間を持つ前に操作されると、移行351は不適当に起動され、システムを状態347へ矛盾して変える。そこでシステムがいったん状態349に入ると、後部のドアを施錠することに含まれるコンポーネントの最も悪いケースの実行呼び出し時間の前に移行351は操作すべきではない。そのような呼び出し時間は、マトラブ／シミュリンクのようなフォーマリズムを用いて、移行上に直接特定される。
【００５３】
本発明の実施例による検査環境の構造、または実証環境は図４に示され、そこで輪郭417は検査中のシステムを表す。このことはあとでさらに説明されるので、検査中のシステムは１つのモデル、ソフトウェアまたは１つの電気的システムの形態を有する。輪郭401は適用されつつある検査シナリオを示す。我々の発明の検査シナリオはその意味において網羅的であり、それは図３で示されたような動作に関するモデルのすべての状態および移行をカバーするだろう。
【００５４】
１つのサービスを検査するために、我々は、そのサービスの動作に関するオートマトンにおけるパスを強化するためそのサービスの環境をシミュレートし、現在の状態により、我々は意図されたサービス状態が実際のサービス状態であることを確かめるために検査を実施する。
【００５５】
この目的を達成するため、各ユーザ要求は検査要求と関係付けられる。それは、検査要求の１つが実行のために最初の状態をセット アップすることを除いては、一対一の対応であり、我々はこの特別な検査要求を最初の状態ブロックと呼ぶだろう。検査要求の目的は、その関係付けられたユーザ要求をシミュレートするように、検査中でそのサービスの入力を変えることである。例えばユーザ要求が「エンジンを停止させる」場合、その対応する検査要求は「停止されたエンジン」の値で、「エンジン状態」の入力値をセッティングすることにあるだろう。同様に、状態検査ファンクションは各状態に関係付けられ、状態検査ファンクションの目的は、関係付けられた状態が処理されたかどうかを検査することにある。
【００５６】
輪郭413と415は検査要求を表し、それらのそれぞれ１つはユーザ要求に関係付けられる。完全な描画においては、我々はユーザ要求と同じくらい多数の検査要求、プラス、輪郭をセッティングする１つの最初の状態を見つけるだろう。輪郭419と421は状態検査ファンクションを表す。
【００５７】
輪郭411は環境ループを表す。例えば検査中のサービスの１つのセンサが、検査中のそのサービスによって制御されるアクチュエータの位置をつかまえるならば、そのときはそのようなアクチュエータとその関係付けられたセンサとの間の関係は、環境ループにおいてインプリメントされるだろう。データのフローは、特に我々がアクチュエータの失敗に対応する状態を観察したい場合に、検査要求から環境ループへ戻るだろう。その場合、検査要求は、アクチュエータのモデル化における失敗を求めるために、環境ループへ情報を送る。このことは、アクチュエータとセンサがシミュレートされる限りは便利である。現実のコンポーネントのために、失敗はその対応する検査要求によって制御されたある特別なシステムによって得ることができる。検査環境が動作しているとき、検査結果は、各信号の記録または各状態検査ファンクションによる単純な認識からなるだろう491に記録される。
【００５８】
輪郭401は、検査 移行と状態検査要求の両方をトリガーするオートマトンを表す。このオートマトンは、検査要求が417から、シミュレートされた時間における瞬間であるどの瞬間でも、またはリアル タイムで見えるかを選択する。同時に、検査オートマトンは、どの瞬間でも検査中のサービスの出力を受けるだろう状態検査ファンクションを選択する。
【００５９】
制御フロー471はトリガーを許し、その検査要求と状態を検査するファンクションは、与えられた瞬間での検査中のサービスから明らかである。これは、他の検査要求が動作するのを妨げないが、それらの出力は単に無視される。
【００６０】
選択された検査要求が413のとき、フロー431は、検査中のサービスの入力と出力のデータフローの組を表す。フロー433は同じタイプのものであるが、検査要求415が選ばれたときである。
【００６１】
フロー441は検査中のサービスの入力を表す。これは検査417中のサービスによる441の消費に対応する。
【００６２】
フロー451は検査中のサービスの出力を表す。これは417による451の産出に対応する。
【００６３】
フロー461は検査中のサービスのフローを再び表す。このフローは状態検査ファンクション419における検査の目的のためにのみ使用することができ、変えることができない。しかしながら、検査の軌跡を記録するために追加のフローを生じさせることができ、491によってのみ消費させることができる。
【００６４】
初期条件ブロックは入力を持たず、その出力フローは検査中のサービスのための入力と出力の両方の初期値を含む。これらの初期値は実証の初期で環境ループ411によって消費される。
【００６５】
検査環境のダイナミック動作を理解するために、我々は、図４における種々のブロックとフローがいかに働くかを述べ、種々のフローを介していかに情報が変化し、種々のブロックによって変更されるのいくつかの例を与える。
【００６６】
例えば、検査要求413と状態検査ファンクション419が図４において現在トリガーされることを考えよう。それから、ループはブロック413、417、419および411の間で動作している。このループはデータフロー441、451、461、411により可能である。検査中のサービスからスタートし、サービス417がドア施錠サービスであること、およびそれが施錠されてない状態からスタートする施錠状態へちょうど変わったことを考える。施錠指令は451を介して送られ、それからプロセス419を検査する状態は施錠指令を受け取り、検査結果記録491へ受領通知（acknowledgment）を送る。しかし、ブロック419は出力フロー451を変化させず、461を介して環境ループ411へそれを転送する。環境ループ411においては、施錠指令は、ある遅延時間の後、ドア状態を施錠にセットする、施錠アクチュエータのモデルに受け取られる。それから、環境ループ411は（ドアが施錠されたという）情報を431を介して検査要求413へ送る。この情報はあたかも施錠状態センサにより出されたかのように受け取られる。乗物が単に解錠されたとき、ドア施錠のトリガーを意図する検査要求413は、ドアの施錠状態を検査417中のサービスへデータフロー441を介して転送する。それから検査中のサービスは、その環境から何の新しい要求も来ないときには状態が変化せず、ループは何の変化も無しで継続する。
【００６７】
もし我々が制御システムを取り扱おうとするなら、検査オートマトンによって何の変化も要求されないときでさえ、ある規定のループがその時間中動作するのを除いて、事態は変化しない。
【００６８】
検査オートマトンがいかに好ましくインプリメントされ得るかを説明するために、我々は施錠された乗物からスタートし、上述の検査シナリオがいかに進行するかをいま述べる。
【００６９】
乗物の現在の施錠された状態に対応して、状態検査ファンクション419が検査オートマトンにおいて状態403によってトリガーされたことを想定する。それから移行407が解錠要求に対応する検査要求415をトリガーすることを想定する。一旦、415がトリガーされると、検査中のサービスがいまその入力を415から受け取るように、フロー441が不活性（inactive）となり、フロー433と443が活性（active）となる。移行407が処理された後、検査オートマトンは、状態検査ファンクション421がトリガーされる状態405に入る。それから、検査中のサービス出力のみがいま421へ送られるように、フロー453と463は作動中になり、419出力は無視される。
【００７０】
新しいループはいま415、417、421、411およびそれから再び415である。検査要求は、417入力での解錠要求をシミュレートするように、環境を変化させつつある。反応として、ブロック417は、（もしすべてのことが適切に働くなら）検査結果記録491へ受領通知を送るであろう、状態検査ファンクション421へ解錠要求を送るだろう。ブロック421は、417出力を変化させず、データフローを直接環境ループ411へフロー461を介して転送する。解錠指令の結果として、前に施錠されたドア状態は解錠されるだろう。それからこの新しい状態は、センサ情報として検査要求415へフロー433を介して転送される。一旦、ドアが解錠されると、検査要求415はもはや他の要求がフロー443を介してシミュレートされないように無意味となり、そのループはスイッチが他の検査要求まで安定となる。
【００７１】
実証の最初のステップで、初期条件ブロックは起動され、最初の入力のセットを検査中のサービス417へ注入する。これが実証の用意をさせる。実証を成功のよいチャンスといっしょに達成されるために、初期条件は十分に安定な初期状態、例えばサービスが作動される状態を確立するために容易だろう。
【００７２】
我々は特定された種々のオブジェクトのセマンティックを説明し、そのシステムがいかに動力学的に動作するのかの例を与えた。しかしながら、完全の目的のために、時間がいかに分配されるかを説明する必要がある。実際、オートマトンの各移行は、呼び出し時間といっしょに特定される。同様に、検査中のサービスの動作に関するオートマトンの各移行は、図３に伴う説明において特定された呼び出し時間といっしょに定義される。検査オートマトンにおける呼び出し時間は、各移行の前に新しい検査要求へ特定される。もし検査要求が、検査中のサービスの一時的な状態をモニターするなら、それから呼び出し時間は、検査中のサービスの反応性との関係において非常に短い。
【００７３】
図４は我々の検査環境のための一般的なフレームワークであり、それは種々の輪郭がいかにインプリメントされるかによる、たくさんの方法で修正され、カスタマイズされるだろう。これは図11に関する解説において詳しく述べられるだろう。
【００７４】
シミュレーション レベルで、環境はマトラブ／シミュリンクのようなツールで発展したモデルによりインプリメントすることができる。これはモデル化レベルでバグを見つけるのを許す。そのようなシミュレーションを達成するため、全体的な（global）時間の定義を特定することができ、具体的な呼び出し時間を、環境ループにおいておよび検査中のサービスのモデルにおいて、検査オートマトンにおける各移行へ付け加えることができる。
【００７５】
この案にはいくつかの変形が可能である。第１に、ユーザ要求にいくつかの検査要求を加えること、あるいは種々の検査要求の間で共通のファンクションを分けること、あるいは検査要求をパラメーターで表す、あるいは検査要求の特定の内部に任意の変数を導入することが可能である。これらは、検査要求がいかに結局はインプリメントされるだろう変形であるが、これらのすべての変形は、シミュレーションに関係するいくつかのパラメーターが検査オートマトン、検査要求および状態検査ファンクションに一様に加えられるだろうことを除いて、図４に描かれたフレームワークと等価である。
【００７６】
図４に描かれたように検査環境または実証環境の例は、一旦、サービスがブロック417において特定されると、自動的に生成することができる。この非常に主要な例は、骨組み実証環境と呼ばれる。その骨組みにおいては、ブロック411、413、415、417、419および同様のものすべては、自動的に生成される。ブロック間のデータフローは、図４の描写といっしょにそれに応じて自動的に生成される。ブロック間のデータフローは図４の描写といっしょに状況に応じて自動的に生成される。これらのブロックの内部のデータフローもまた自動的に生成され、ブロックは入力もまた出力であるとき、同一性のごとくふるまう。他の入力はそのブロック内で終結する。
【００７７】
そのような自動生成は、例えばマトラブ／シミュリンクのようなシミュレーション環境において可能である。
【００７８】
図５では、検査オートマトンが表される。検査オートマトンの各状態は、検査中の動作に関するモデルのターゲット状態に対応し、検査オートマトンの各移行は検査要求に対応する。初期条件ブロックのためを除き、各検査要求はユーザ要求に対応することが思い出されるべきである。
【００７９】
我々の発明で述べたように、検査の目的は、状態を完全にカバーすることおよび検査中のサービスの動作に関するオートマトンの移行を許すであろう検査のシーケンスを提供することである。
【００８０】
検査オートマトンの各移行は、我々が検査したい動作に関するモデルにおける移行のシミュレーションに対応する。そこで検査状態と動作の状態との間の１対１対応がある。例えば、「乗物のドアを施錠する」という状態のために、検査状態は「我々は、システムが乗物のドアを施錠することを行わなければならない場合を検査する」のセマンテックを持つだろう。同様に、検査中の動作に関するモデルにおいて、「乗物解錠」の要求が与えられたとき、検査プランにおける対応する要求は「乗物解錠がユーザにより要求されたように環境が変更される」のセマンテックを持つだろう。これのすべては図４の描写から明らかである。
【００８１】
検査中のサービスにおける検査要求（初期条件ブロックのためを除く）とユーザ要求との間の１対１対応により、検査は、我々が検査環境からエミュレートしたいユーザ要求のシーケンスとみなすことができる。そこで、検査モデルを作る目的は、検査中のサービスにおけるユーザ要求と状態の詳細な補償範囲を提供することであり、またこれは、すべての状態に達し、検査中のサービスのすべての移行を通り過ぎるユーザ要求のシーケンスのリストを同定することにより達することができる。
【００８２】
我々はいま、グラフ理論におけるアルゴリズムの形式での検査の生成の好ましい実施を提示する。使用されたアルゴリズムは、適用されたグラフのように見えるオートマトンにおける詳細な最初の検査のように見える。グラフ理論において、状態はノードと呼ばれ、移行は矢印と呼ばれる。我々は同じソースと目標状態を持つ種々の移行を禁じないので、いくつかの矢印は２つの状態をリンクすることができることに留意されたい。
【００８３】
その考えは、グラフにおける各ノードへ、目標としてのそのノードといっしょに各矢印へ、それ自体を関係付けられるであろう、“ｐ”と呼ばれるプレデセッサのファンクションを作ることであり、１つのプレデセッサは、その矢印がそのプレデセッサからそのノードへ行くようなものである。プレデセッサは、特定された初期の状態もまた要求する。一旦、そのプレデセッサのファンクションが自動的に同定されると、詳細な検査シナリオがｐから帰納的に作られる。
【００８４】
まず、我々は適応されたグラフ上でのプレデセッサのファンクションの定義に向かう。
アルゴリズムの操作中に、各ノードは、それが前の操作の間にアルゴリズムによって処理されたことを意味する、状態Ｓ１または逆を意味するＳ２を持つことができる。状態Ｓ２を持つノードが与えられると、それはグラフにおけるそのノード“Ｎ”のすべての即座のサクセッサが“Ｎ”、またはその逆を意味するＥ２から始まってアクセスされたことを意味する、状態Ｅ１を持つことができる。ノード“Ｎ”のサクセッサは、ソース“Ｎ”を持つ矢印の目標であるノードである。各ノード“Ｎ”のために、“Ｎ”のサクセッサの数はｄ(Ｎ）と呼ばれる。もし我々が“Ｎ”から既にアクセスされた“Ｎ”のサクセッサの数をｎ(Ｎ）と呼ぶなら、その場合は“Ｎ”は、ｎ(Ｎ）がｄ(Ｎ）より完全に下である間は、状態Ｅ２を持つ。もしｎ(Ｎ）がｄ(Ｎ）と同じなら、その場合は“Ｎ”は状態Ｅ１を持つ。それが前のステップにおけるアルゴリズムによって処理されるが、まだ“Ｎ”から始まりアクセスされていない場合において、ノード“Ｎ”のサクセッサが同時にＳ２とＥ１であることに留意されたい。
【００８５】
アルゴリズムが再帰である：
初めに、ノード“Ｎ０”がアルゴリズムの初期のノードとして選ばれる。これは検査プランの初期状態に対応する。
アルゴリズムの与えられたステップで、ノード“Ｎｋ”が処理される（初期ステップでの“Ｎ０”のように！）。２つの場合が可能である：
もし“Ｎｋ”状態がＥ２なら、その場合は“Ｎｋ”から始まり、“Ｎｋ”の少なくとも１つのサクセッサはアクセスされない。それを“ＮＷ”と呼ぶ。
もし“ＮＷ”が状態Ｓ２を持つなら、その場合は“Ｎｋ”から“ＮＷ”へ各移行のためにＰ(“ＮＷ”)＝“Ｎｋ”をセットし、アルゴリズムは“ＮＷ”を処理する。
もし“ＮＷ”が状態Ｓ１を持つなら、ノード“Ｎｋ”へ戻り、“ＮＷ”は現在アクセスされている。
もし“Ｎｋ”状態が、“Ｎｋ”のすべてのサクセッサが現在処理されているＥ１なら、その場合はもし“Ｎｋ”のためのプレデセッサ“Ｎｙ”が存在するなら、アルゴリズムは再帰的に“Ｎｙ”に適用される。
アルゴリズムは“Ｎ０”が状態Ｅ１を持つとき、停止する。
さて、そのｐが立ち上がったら、我々はシナリオの構造に向かう。もしノードが他のプレデセッサでないなら、我々はそれをリーフ（leaf）と呼ぶ。シナリオは単に、ノード“Ｎ０”で始まり、すべての可能なリーフで終わる、状態と移行のすべての可能なシーケンスのリストである。各シナリオは、リーフから始まり、その後、“Ｎ０”へのバックトラッキングまでプレデセッサのファンクションを適用して作られる。精々１つの適用された移行が２つの状態をリンクする場合、この定義は十分である。しかしさらに、我々は２つのノードの間のすべての可能な移行が少なくとも１つのシナリオによってアクセスされるという可能性を持つ。この拡張はインプリメントするのにまったく簡単であり、我々はアルゴリズムの詳細を述べない。
【００８６】
前のステップはシナリオのリストを生じ、各シナリオは状態“Ｎ０”から始まり、他の状態“Ｎｉ”で終わる。もし可能なら、適用されたグラフの中で２つのノードをリンクさせる古典的なアルゴリズムを用いて、そのような各シナリオ、“Ｎｉ”から“Ｎ０”へのリターンパスのために、その後計算し、それをそのシナリオへ付け加える（そのパスは、移行の数によって最も短いものであることを必要としない）。それから我々は検査シナリオのリストを得、それぞれの１つは“Ｎ０”で始まり、“Ｎｉ”で終わる。いくつかのシナリオは、それらがある「ノン リターン」チェンジに対応することを意味する、“Ｎ０”へ戻らない可能性がある。これは、システムが動作を継続することができない、乗物が衝突するような非常に特別な場合を除いて、組み込まれたシステムにおいて非常にありそうもない。
【００８７】
そこで、検査シナリオの同定の終わりで、我々はシナリオのリストを得、各シナリオは一連の連続する状態と移行から成り、各シナリオは可能なとき、初期状態“Ｎ０”で始まり、“Ｎ０”で終わる。さらに、これらのシナリオは、サービスの動作に関するオートマトンのすべての状態およびすべての移行の完全なカバレッジを形成する。検査オートマトンの生成のために他のインプリメンテーションが可能である。我々は他の可能なインプリメンテーションのために［ＡＨＯ７４］に言及する。
【００８８】
図５に戻り、輪郭511、513および515は、上記の説明で特定された検査シナリオを表す。輪郭531、533、535、537、539、541、543、545（531から545）は、検査中のサービスの目標状態に対応する状態、および検査中のサービスの目標移行の活性化に対応する移行571から585を表す。
【００８９】
状態531での始まりに対応する初期条件は、選ばれた初期状態531との関連において設定されなければならない。初期状態は、初期始まり記号501と503から同定される。各信号のために、適した初期値が設定される。例えば、もしドア施錠サービスのための初期状態が、乗物がアイドリングし、すべてのドアが施錠されている状態であるなら、ドア施錠状態とエンジン状態は状況に応じて設定されなければならない。すべての検査は、同じシステム状態で始まり、終わる（可能なときはいつでも、いくつかの状態は到達可能でないかもしれない）。そこで、移行521と523は、２つのシナリオの間の無意味な移行である。各シナリオの終わりでの参照状態へ戻るという事実は、「連続的な検査」に対応するシミュレーションを止めることなしに、連続するシナリオを実行するのを許す。これは、図５の例において、状態531、545、551および561が検査中のサービスの同じ状態に対応するということを意味する。もちろん、もしある状態が参照状態に戻る可能性無しに到達するなら、シミュレーションは停止され、それから他のシナリオにおける初期条件で再び始まらなければならない。
【００９０】
図４で述べたように、タイミングは、時間を持つ検査されたファンクションを正確に反応させるか、タイムリーな一時的な移行を検査するかのいずれかの、検査のオートマトンの移行上に仕様が記載されている。タイミングは、特定された範囲において変化することができ、それから検査は、各移行のために特定された範囲の元で、ハザード呼び出し時間の生成と合わせられ得る。検査の移行上にトリガーを追加することも可能である。そのようなトリガーは、ユーザ要求のまたはシステム応答制限に対応する。例えば、もしユーザ要求が「100km/hのスピードに達する」ことなら、ぞの場合は100km/hのスピードに達したことを示す信号は、新しいユーザ要求を注意深く読むためにトリガーされ得る。検査のオートマトンにおいては、例えば新しいユーザ要求を操作する前でトリガー後に１秒待つ等の、遅延とトリガーの混合になり得る。図５に描かれたシナリオは、例えばユーザ要求がシステムの状態を変化させることができる各時間等、これが正当なとき、システムが正確に反応するということだけを検査する。しかしながら、あるユーザ要求が、与えられたコンテキストでの対応するシステム応答を何も持たなかったということが時々要求される。これはある種の「起こらない」使用の場合または不可能な使用の場合である。
【００９１】
検査プランは、不可能な使用の場合の検査を含むように、完全なものにすることができ、これらの使用の場合は、ある状態において何の答えもないユーザ要求に対応する。これをインプリメントするため、我々は無視されるであろうユーザ要求に対応する補充的な状態と移行といっしょに、検査シナリオを簡単に片付ける。そのような無視されたユーザ要求は、結果として生じる状態を変化させない。例えばもし移行579が、不可能な使用の場合に対応する無視されたユーザ要求をインプリメントするなら、その場合は状態537と539は、検査中のサービスの同じ状態に対応するだろう。もし動作を簡単にするなら、もしいくつかの移行が取り消されるなら、生成された検査シナリオはいまだ正当だが、部分的だろう。
【００９２】
図６では、機能的なレベルで検査中のサービスのレイアウトを述べる。動作に関するオートマトン201とファンクション211、213、215、241、243および245は、図２におけるこれらのブロックをリンクする各フローといっしょに、図２から取られる。図６では、我々は特に入力と出力のドライバを論じる。
【００９３】
ドライバ621はセンサ601から情報を取得し、この情報をファンクション211と215へ送る。211と215は種々のレートで流れを消費することができるということに留意されたい。ドライバ621は、例えばセンサ601からハイまたはロー信号を受け取り、与えられたサンプリング レートでファンクション211と215へ状況に応じて「０」または「１」の値を送る、論理入力であり得る。同様に、ドライバ623はセンサ603から情報を取得し、この情報をファンクション211、213および215、しかし245へも送る。623と645の間のリンクは、取得された情報は例えば制御ループのために検査中のサービスのシステム応答をインプリメントするファンクションによって直接消費されるという事実を説明する。
【００９４】
ドライバ661はアクチュエータ611に命令し、ファンクション241と243から各フロー641と643を介して情報を受け取る。これは、ファンクション241と243が検査中のサービスの種々の状態でアクチュエータ611に命令することができ、または再びファンクション241と243の両方は、アクチュエータ611が命令された各時間このアクチュエータ611の命令に関与するということを意味する。同様に、ドライバ663はアクチュエータ611に命令し、フロー645と647を介してファンクション241と243から情報を受け取る。検査中のサービスのこのモデル化は、種々の方法で図４のブロック417に挿入することができる。
【００９５】
１つの解決は、ブロック417にファンクションのみを挿入し、ドライバは挿入しないことである。その場合、417の入力と出力は、論理または「ディジタル」入力と出力であり、その実証は検査中のサービスの低レベルのソフトウェアとハードウェアを含まない。動作に関するオートマトンとファンクションのみが実証される。他のステップは、ドライバ621、623、661および663を含むことにある。その場合、実証は物理的レベルでなされる。その場合、ドライバもまた実証される。
【００９６】
もし417ブロックのコンテンツが図６に描かれたようなサービスなら、電子的制御ユニットも通信ネットワークも特定されないので、これは本質的には特定とソフトウェアの実証の目的のためである。これは電子的制御ユニットとネットワークがいかに実証されるかを詳しく述べるための図７の目的である。しかしながら、例えば速いプロトタイピング インプリメンテーションのコンテキストにおいてのような、検査中のサービスが特定のＥＣＵ（電子的制御ユニット）上に写像された場合、図６に描かれたサービスは、ハードウェアのループ検査のための基礎になり得る。
【００９７】
図７では、図６に描かれたサービオスは、ＥＣＵと通信ネットワークからなる物理的アーキテクチャー上に写像されたものである。記号701、703、705および707は、我々がネットワーク701と呼ぶ特定の通信ネットワークを意味する。このネットワークは例えばＣＡＮバスであり得る。輪郭751と753は電子的制御ユニットを意味する。実際、701は751におけるネットワーク入力フローに、703は751からのネットワーク出力フローに、705は753におけるネットワーク入力フローに、707は753からのネットワーク出力フローに対応する。
【００９８】
ＥＣＵ751の物理的インターフェースは、センサ601、アクチュエータ611、およびネットワーク インターフェースからなる。同様に、ＥＣＵ753の外部のインターフェースは、センサ603、アクチュエータ613、およびネットワーク インターフェースからなる。もし我々がＥＣＬ751と753内のブロックを注意深く見るなら、図６で描かれたサービスが割り当てられたことをわかることができる。動作に関するオートマトンは輪郭791と793内に分配され、我々は、分配ストラテジーは図６または２における初期の動作に関するオートマトンの入力と出力を保存するということを仮定するだろう。しかしながら、他の分配ストラテジーはサポートされる。また、ドライバは、それらの関係付けられたセンサまたはアクチュエータの写像のファンクション内に分配された。
【００９９】
ファンクション211、241および243はＥＣＵ751上に写像され、ファンクション213、215および245はＥＣＵ753上に写像された。写像によると、我々は、ＥＣＵ753内のドライバ623によって生じたフローはＥＣＵ751内のファンクション211によって消費され、これはドライバ717と711を介して、ＥＣＵ751と753間のネットワーク接続により可能であるということをわかることができる。そこで、図６のデータ フロー633はいまデータ フロー733の構成物としてインプリメントされ、ネットワーク ドライバ717を介して753からネットワーク上に出され、ネットワーク ドライバ711を介してＥＣＵ751内のネットワークから受け取られ、フロー721を介して211へ伝えられる。もしいま図４の輪郭417における検査中のサービスが図７におけるようにインプリメントされるなら、その場合は我々は例えばネットワーク上のメッセージ交換が適切にインプリメントされることを実証することができる。
【０１００】
図８では、図７で描かれたサービスのインプリメンテーションが配線の限定といっしょに拡張された。バス トポロジーおよびザ ウエー センサとアクチュエータはいま特定された異なるＥＣＵへリンクされる。ＥＣＵ751、753および801はそれぞれコネクタ827、825および829を介してネットワーク811へリンクされる。
【０１０１】
センサとアクチュエータ601、841、611は、コネクタ821とケーブル861を介してＥＣＵ751へリンクされる。コネクタ831は、例えばアクチュエータ603がコネクタ831と827を介してＥＣＵ753へ接続されるようにケーブル867、869へリンクする。センサとアクチュエータ コネクタは簡単化の目的のため、図に示されない。また、接地接続は表されておらず、それらはＥＣＵ、センサ、アクチェータの間でケーブルまたは単線を介して接地位置への接続に単にあるだろう。
【０１０２】
そのような描写が輪郭417内で検査されるとき、これは配線の特定において配線は何の不足がないことを確証することを許す。417のインターフェースはセンサとアクチュエータのコネクタのレベルで特定されるだろう。その場合、特定を実証するためにすべてのコンポーネントをシミュレートすることが可能である。またシミュレートされた部分を現実のＥＣＵとインターフェースすることも可能である。この問題は図11で論じる。
【０１０３】
図９Ａ〜９Ｃの部分からなる図９では、我々は、コネクタの定義と、その特定の実証の目的のために、後でそのインプリメンテーション上に、１つのコネクタがいかにモデル化され得るかに焦点を当てる。
【０１０４】
図９Ａでは、輪郭901と903は、例えばケーブル901内の配線921とケーブル903内の配線923等の、配線をいっしょに集めるケーブルを表す。コネクタ831は、雄コネクタ913と雌コネクタ911からなる。図では、雄と雌コネクタは接続されてない。雌コネクタ931のピンは、雄コネクタ933のピンに対応する。
【０１０５】
図９Ｂでは、我々は雄と雌コネクタ ピン933と931に焦点を当て、それらをコンタクト943と941を介して配線923と921にリンクさせるかを説明する。
【０１０６】
図９Ｃでは、我々は、モデル化レベルでの実証の間のコンタクトのインタープリテーションを表す。配線921はデータ フロー951として説明され、配線923はデータ フロー953としてインタープリトされ、雄と雌コネクタ ピンの間のコンタクトは、入力データ フロー951と出力データ フロー953といっしょのファンクション963としてインタープリトされる。
【０１０７】
通常のフォールト フリー コンタクトの場合、ファンクション963は同定としてインプリメントすることができる。フォールトのある接続の場合では、ファンクション963は、短絡または不安定な接触のような接触不良による一定のまたは任意のファンクションであり得る。
【０１０８】
図10Ａ〜10Ｄの部分からなる図10では、我々は、例えばフォールト トレラント ファンクションを検査する目的のために用いられる、フォールトの投入のインプリメンテーションを論じる。図10Ａでは、配線1003と1001は互いに非常に接近しており、それらはポイント1011で接触され、アクチェータ1021に電力を供給する、配線1001のための接地1031へ短絡という結果になる。
【０１０９】
図10Ｂでは、配線1001と1003を含むケーブルは、入力1041、1043、出力1045、1047を持つファンクションとしてインタープリトされる。1001の一端は1041として、1001の他端は1045としてインタープリトされる。同様に、1003の一端は1043として、他端は1047としてインタープリトされる。配線1001と1003を含むケーブルは、ファンクション1051としてインタープリトされる。接地への短絡は、入力が何であれ、アクチェータ1021へ0（0アンペア強度のインタープリテーション）を出力する、定数関数の形の1051のインプリメンテーションとしてインタープリトすることができる。このインタープリテーションは、フォールトの存在する実証の目的のためにフォールトが入る場合に対応する、短絡がフロー1081を介してファンクション1051に入るであろう場合にのみ適用可能であろう。
【０１１０】
図10Cでは、我々は１つの開回路を表す。配線1007と1009は、破壊された配線を共に形成する。1007の破壊されていない端部は、図10Dにおいて入力フロー1061として説明され、1009の破壊されていない端部は、出力フロー1063としてインタープリテイトされている。配線それ自体は、ファンクション1071としてインタープリトされている。断線配線の場合と電流が1061から1063へ普通に流れる場合、断線効果は、1063を、電気開回路をインタープリトし、この値を1063の消費体に伝達する特定の最低値に設定する。1063のそのような動作は、開回路に対応するフォールトのプロファイルが、フロー1083を介して1063に入るであろうときにのみ起こるだろう。
【０１１１】
そこで図９と10は、各コンポーネント（ケーブル、雄および雌のコネクタ）が、それらの物理的インプリメンテーションがなされる前に実証を遂行されるファンクションとデータフローとしていかにインタープリトされ得るかを示す。自動車システムのコンテキストにおいて、電気的ネットワークは比較的単純で、ループ フリーとデータフロー インタープリテーションはこれが最も一般的な場合において可能でないのに、可能である。また、フォールト モデルは、実際の電気回路の動作を簡単化し得る。我々が保証するのを必要とするただ１つのことは、フォールト モデルが実際のシステム フォールトの集まりよりも大きいということである。
【０１１２】
図11では、サービスと実証の種々のステップの設計プロセスが描かれている。設計の進歩の段階の間、特徴の最初のモデルの労作まで実証は不可能である。そこで、使用の場合の仕様1101、動作に関するオートマトンからなる動作に関する仕様1003、その動作に関するオートマトンの各状態の中でどのファンクションが動作しているのかを示す機能的な仕様1105が一旦立ち上がると、それからすぐサービスのモデルを得るために各ファンクションのモデルを作ることが可能である。一旦、このモデルが得られると、その入力と出力は、「一般原則として」センサ、アクチュエータおよび他のサービスとのやり取りである。
【０１１３】
このステップで、検査プランを自動的に生成することが可能であり、検査モデルは図４と５に描かれた。その場合、環境ループは、入力と出力としてそのモデルの入力と出力を取ることができる。これは例えば命令とデータ収集のドライバの統合を排除する。乗物のドア施錠サービスの場合、あり得る入力は、ユーザからの施錠要求のフォーマットされたメッセージであってもよく、あり得る出力は、乗物のドアを施錠するリレーの命令であってもよい。ブロック417に挿入されたモデルは、図２に表されたような形であってもよい。使用の場合のレベルと機能的なレベルでタイミング要求を推定するのが既に可能であるが、このステップでのタイミングは大ざっぱに推定される。しかしながら、このステップでのタイミングは物理的なアーキテクチャーから実証されないだろう。
【０１１４】
このレベルでの実証は「モデル イン ザ ループ」1171と呼ばれる。それは、例えばマトラブ／シミュリンク等のシミュレーション ワークショップを用いて遂行されることができる。その場合、各ファンクションは、シミュリンクの元で実行可能なモデルの形で特定され、各動作に関するオートマトンは、 シミュリンク／ステートフロー（Stateflow）の元で実行可能なモデルの形で特定される。形式化かは、種々のファンクションの間のすべてのスケジューリング インターフェースを特定することを許す。
【０１１５】
それから、次のステップで、アプリケーション ソフトウェアを書き込みすることが可能である。：低レベル ソフトウェアによってフォーマットされた、高レベル入力と出力が与えられる、サービスをインプリメントするソフトウェア。アプリケーション ソフトウェアにおいては、ファンクションと制御オートマトンは、オペレーティング システムによってスケジュールされるべきタスクに分配される。もし我々がオペレーティング システムのモデルでオペレーティング システムの置き換えるか、あるいは実証1171の間、用いられた環境をモデル化することにおけるオペレーティング システムの実行を収容するかのどちらかを行うなら、その場合は実証1171におけるモデルのピースを、対応する利用されたソフトウェアのピースで置き換えることによって、利用されたソフトウェアを実証することが可能である。これは、ソフトウェア イン ザ ループとも呼ばれる実証ステップ1173に対応する。
【０１１６】
その後、ドライバが特定される。それらは、低レベルの物理的信号を論理信号に変え、それらがセンサまたはアクチェータ ドライバに対応する事実により逆になる。それらが一旦ステップ1111において特定されると、それらはそれらの対応するセンサとアクチェータといっしょにモデル化され得る。それから、モデル ザ ループ シミュレーション1171を、ドライバおよび／またはセンサおよびアクチェータを含むシミュレーション1173に拡張することが可能である。ドライバがモデルに含まれる場合のみ、センサとアクチェータが、それらが形式化されるのを必要としないことを意味する、環境ループの一部であり、キャプチャーとコマンドの関係のみがモデル化されるのを必要とする。もし、センサとアクチェータ モデルが実証に含まれるなら、環境は、関係のあるアクチェータとセンサの間のリンクのモデルを含む。例えば、もし１つのセンサが、施錠がアクチェータにより正しく操作されたかどうかを検査するものなら、そのアクチェータとそのセンサの間のリンクは、アクチェータの与えられた開位置がセンサに解錠位置を送るというモデルになるだろうし、また逆もある。そのようなモデルを得る方法は、各コンポーネントの物理的動作をモデル化することである。
【０１１７】
実際には、センサとアクチェータが環境ループ内にある場合は、サービス ファンクションが適切に特定されたことを検査することが十分に詳しく述べられているので、このステップで最も有用である。さらに、センサとアクチェータの適切なモデルを得ることは、難しいかもしれず、また、我々の目的は、コマンドまたは取得された情報がうまく処理されることを実証することである。しかしながら、たとえセンサとアクチェータが、設計プロセスのこのステージで適切にモデル化されなくても、健全なコマンドとキャプチャーの範囲は、スペースと時間の両方において特定されることを必要とする。一旦、ドライバとコンポーネントの特性が特定されると、ステップ1113において、低レベル ドライバが、部分的にソフトウェア コンポーネントとして、部分的にハードウェア コンポーネントとしてインプリメントされる。
【０１１８】
いま低レベル ソフトウェアとそのスケジューリングを含む実証ステージ1181において、ソフトウェア イン ザ ループを反復することが可能である。設計ステップ1121において、ＥＣＵとネットワークが選ばれ、サービスの機能的説明は異なるＥＣＵ上に写像される。まず、異なるバス上にセットされたメッセージがインプリメントされるのは必要としない。各ＥＣＵは、接続された各バス上で他の接続されたＥＣＵにメッセージのセットを出す。一旦、写像がなされると、図７の形で描写された各サービス、ステップ1183を実証することが可能である。
【０１１９】
設計ステップ1123では、各バスのためのメッセージのセットが特定され、また実証1153は、通信とネットワーク管理のための低レベル ソフトウェアといっしょに、メッセージ交換のための低レベル ソフトウェアを含むことができる。また、一旦、ＥＣＵが特定されると、それらもまたインプリメントされ、すべてのＥＣＵがいっしょに、または少しのＥＣＵのためにハードウェア イン ザ ループがなされ得、それらの他のものは、ネットワークに接続された１つのＰＣ上にシミュレートされる。
【０１２０】
設計ステップ1131では、コンポーネント（センサ、アクチェータ、ＥＣＵ）は、乗物マップ上に幾何学的に写像され、その書き込みが設計される。図９で描写されたように、配線とコンポーネント コネクタを説明すると、それから図４の輪郭417の解釈を、その配線といっしょにインプリメントされたサービスに拡張することが可能である。このモデル イン ザ ループ検査は、実証ステップ1185において遂行される。この新しいフレームワーク内でソフトウェアを再び検査することは可能であり、ハードウェア イン ザ ループ検査は、実際の対象とする配線と共に実行し得る。
【０１２１】
最後の設計ステップにおいては、図９で説明したように、それらのモデル化といっしょに、接続されてないコネクタが特定され、再び全体のモデルとインプリメンテーションのピースは、モデル化、ソフトウェアのインプリメンテーションおよびインプリメンテーションハードウェアのレベルで、検査され得る。
【０１２２】
図12では、我々は、安全システムのための特定の開発プロセスに焦点をあてる。そのプロセスは次のステップからなり、使用の場合のリスト（図11の1101）と動作記述（図11の1103）の形式の元で、一旦、動作説明1201がなされる
１ 望ましくないイベントとそれらの重要性の同定（1203）
２ その現実のまたは仮想のセンサとアクチュエータで形成されたシステムの機能的特定（1205）
３ リンプホーム（Limp-home） モードの記述（1207）
４ 望ましくないイベントの現実のまたは仮想のアクチュエータへの関連付け（1209）
５ 機能的アーキテクチャー上の望ましくないイベントの精錬（refinement）（1211）
６ 安全要求精錬を伴った冗長度の導入（1213）
７ ハードウェア アーキテクチャーの定義（1215）
８ 電子的制御ユニット上のファンクションの写像（1217）
９ 有効な電子的アーキテクチャーのフォールト トレランスの実証（1219）
10 物理的コンポーネントと配線の幾何学的写像（1221）
11 有効な電気-電子的アーキテクチャーのフォールト トレランスの実証（1223）
このプロセスは線形であるように意図されない。少しのループは、プレゼンテーションにおいて隠される。例えばステップ６は、多数のやり直しを生じるかもしれない種々の方法によってインプリメントすることができる。また、種々のハードウェア アーキテクチャーは、目標が、与えられたフォールト トレラント要求の元でよりコストのかからないアーキテクチャーを見つけるように、ステップ７において調査することができる。ステップ８では、特にもしステップ９が、１つの写像が満足でなく、ある仕事をもっと要求することを立証するなら、種々の写像が調査される。また、ステップ10では、ノードの種々の位置を検査することができる。
【０１２３】
我々の記述の主な目的は、ステップ９と11を説明することである。安全分析が遂行される方法は、我々が完全性の目的のために、ステップ９と11を、１つのセルフ-コンテント設計プロセスへ関連付けるために、種々のステップを思い出すように、我々にとって目的の外にある。
【０１２４】
１．望ましくないイベントとそれらの重要性の同定
このステップは、安全分析の伝統的な部分である、機能的障害分析（Functional Failure Analysis：ＦＦＡ）のよく知られたステップである。１つのシステムのためのＦＦＡの結果は、上記イベントが生じたとき、結果の深刻度を伴う望ましくないイベントの同定である。
【０１２５】
２．その現実のまたは仮想のセンサとアクチュエータで形成されたシステムの機能的特定
このステージで、我々は、既に早くに述べた設計フォールトの定義を精錬することができる。設計フォールトは、機能的仕様において作られたフォールトである。
【０１２６】
３．リンプホーム モードの記述
モードの記述は、機能的アーキテクチャーに補足的である。１つのシステムは、データフロー［Fuchs98］をトリガーする、例えばステートチャート（Statechart）等の制御オートマトンからなるように記述することができる。最も高いレベルで、オートマトンは、初期化、ノーマル モード、リンプホーム モードおよび１つのモードから他へスイッチする動作等のシステム モードをインプリメントすべきである。
【０１２７】
例えば車のブレーキ システムの場合、前左のブレーキが機能しておらず、他のブレーキが適切に働いているなら、ブレーキングは、多くの場合、ブレーキを全然かけていないよりも悪い、乗物の安定性の低減という結果になるだろう。そこで、その場合、ブレーキングにおいて、信頼できるリンプホーム モードが、それぞれ適用されたブレーキ圧力を伴う前右と後左のブレーキでのブレーキングにあるだろう。その場合、乗物の速度は後に減少し、乗物は安定を維持するだろう。
【０１２８】
クリティカル システムでは、ノーマル モードがあるフォールトにより利用できない場合、リンプホーム
モードはたいていはグレードを下げられたサービスを提供する状態にあるだろう。これは我々が11においてスタートするステップである。
【０１２９】
４．望ましくないイベントの現実のまたは仮想のアクチュエータへの関連付け
各望ましくないイベントのためのＦＦＡの結果の部分集合のみを考慮する我々のプロセスでは、我々は、関与しているアクチュエータ、障害が望ましくないイベントを引き起こすであろうアクチュエータ、普通に機能する他のすべてのアクチュエータを考慮する。
【０１３０】
例えば乗物ブレーキ システムのために、我々は望ましくないイベントである「ブレーキ中の安定性の欠如」を考慮することができる。もしアクチュエータの１つがブレーキをかけてなく、他の３つがかけているなら、これは可能であろう。もし我々の対象が、システムが１つのフォールトにトレラントであるということなら、１つの分析は、例えば安定性の欠如がアクチュエータの１つの障害によるという結論を導くことができる。その場合、我々は「ブレーキ中の安定性の欠如」を各ブレーキ アクチュエータだけに関連付けるだろう。もしいま、我々が望ましくないイベントである「ブレーキが要求されているがブレーキがきかない」を考慮するなら、その場合はこの望ましくないイベントがすべてのブレーキのセットに明らかに関連付けられたように、どのアクチュエータも健全なコマンドを受けなかったということが明らかである。
【０１３１】
しかし、我々のブレーキ システムは制御オートマトンによってトリガーされるということ、およびブレーキ要求は「ブレーキ」状態へ導くオートマトンの移行であるということを想像されたい。もし移行が適切に実行されないなら、たとえ各ブレーキが適切に働いていても、望ましくないイベントは起こるだろう。そこで、１つの望ましくないイベントは１つの状態移行に、もし前記状態移行障害が前記望ましくないイベントを起こすことができるなら、結び付けることができる。このステップの終わりで、各望ましくないイベントは、深刻度と共に、１つまたはすべてのアクチュエータまたは状態移行結果の少しの部分集合に付け加えることができる。
【０１３２】
深刻度レベルのためのあり得る参照は、基準［IEC61508］に提供される。深刻度によれば、１つまたは２つのフォールトの存在におけるフェイル-サイレントまたはフォールト-トレランス レベルは、障害受領の予期される確率と共に、予期される。
【０１３３】
電気的ブレーキ システムの場合、アクチュエータは「フェイル-サイレント」であることが要求され、すなわち、１つのブレーキが、それが機能を果たさない物理的状態に置かれることができることが立証されるべきである。もし確率が予期されるなら、我々は、電気的ブレーキは、例えば１時間当り10−８のように非常に低い、単位時間当りの確率ｐを除いて、機能を果たさない物理的状態に置かれることができるということを言うだろう。
【０１３４】
５．機能的アーキテクチャー上の望ましくないイベントの精錬
最初に、センサ、アクチュエータおよびファンクション、並びにデータフローからなる機能的アーキテクチャーが与えられ、あるデータフローは電流をモデル化し、バッテリはセンサとしてモデル化される。
【０１３５】
我々は、前のステップ ａ）望ましくないイベントおよびリンクされたアクチュエータにおいて同定した。それから設計エンジニアは、前記アクチュエータを孤立して関連付けられた望ましくないイベントによる、フェイル-サイレントまたはフォールト-トレラントまたは各アクチュエータの種々の入力フローからの要求がないことを彼が予期するかどうかを示すことができる。
【０１３６】
例えば、ブレーキ システムの場合、ブレーキだけが存在するようになる要求として、各ブレーキのブレーキ力（制動力）コマンドはフォールト-トレラントに特定することができる。しかし、設計者は、１つの障害が検知された後、もしブレーキ システムが十分に敏速に反応することができるなら、フェイル-サイレント要求が十分であるということを単純に考慮するかもしれない。このタグを付けることは、我々の方法における１つの入力である、その機能的アーキテクチャーおよびそのプロパティによる。
【０１３７】
繰り返して、我々はそれから、同じ分析を各ファンクションと前記ファンクションのための各関連する望ましくないイベントに適用することによって、ファンクションとアクチュエータの安全要求を決定する。もし１つのファンクションが、機能的アーキテクチャーを介して、アクチュエータの１つのセットの制御に直接寄与するデータフローを生じさせるなら、その場合は我々は、そのファンクションのために、アクチュエータの前記セットの部分集合にリンクされたすべての望まれないイベントを、前記ファンクション上と前記ファンクションの入力上に安全要求を作り上げることを考慮する。さらに、我々はそのファンクションを、１つの前の安全分析から来るその出力上の各制限とみなさなければならない。
【０１３８】
６．安全要求精錬を伴った冗長度の導入
それから、各ファンクションのために、そのファンクションのインプリメンテイション モードは、これまでに生成された安全要求により、複製と要求された票決機構をインプリメントするために選ばれる。
【０１３９】
有効な機能的アーキテクチャーは初期のそれより大きい。もしフォールト トレランスまたはフェイル-サイレント要求が何も特定されないなら、その機能的アーキテクチャーは、このステップで変化しない。
【０１４０】
７．ハードウェア アーキテクチャーの定義
このステップで、我々は、システムをインプリメントするであろう電子的制御ユニットとネットワークを単純に特定する。安全分析が定量的である１つのコンテキストにおいて、単位時間当りの障害レートが予期される。
【０１４１】
８．電子的制御ユニット上のファンクションの写像
このステップで、例えば図11のステップ1121で説明したように、ファンクションが電子的制御ユニット上に写像される。
【０１４２】
９．有効な電子的アーキテクチャーのフォールト トレランスの実証
この実証は、図４におけるように検査環境によって遂行される。新規な点は、我々がいま動作がフォールトの存在において健全かどうかを検査することである。そこで各コンポーネントは、図10のポート1081と1083のようなフォールト導入ポートを装備している。それから１つの検査導入プランが特定される。我々が１つのフォールトの存在における動作を検査したい場合、図４におけるような実証環境はそのアーキテクチャーにおける各コンポーネントの各フォールトのために実行される。導入され得るフォールトは、図10に述べられているように、配線オープン、短絡であるが、しかし、例えばネットワーク オープン、送られなかったフレーム、ＥＣＵリセット、…などである。リストは、システムにおいて使用されるコンポーネントにより拡張するので限定的ではないが、主に電気的コンポーネントとそれらのインターフェースに制限されるだろう。
【０１４３】
フォールトがスタンダードなので（開回路、短絡、ＥＣＵのリセット）、それらのモデル化は、その実証が、フォールト モデルの導入からフォールト導入を伴う実証の実行へ自動的に遂行され得るようにスタンダードであることに留意されたい。フォールトの検査の順序は、実証が各フォールト発生のために実行されるので、あまり重要ではない。
【０１４４】
10．物理的コンポーネントと配線の幾何学的写像
このステップで、電子的制御ユニット、バッテリ、センサ、アクチュエータおよびさらに一般的な電気的コンポーネント間の配線パス、コネクタおよびケーブルが特定され、伝統的な工学プロセスが続く。
【０１４５】
11．有効な電気-電子的アーキテクチャーのフォールト トレランスの実証
これは、我々がいま網羅的な配線記述を含めることを除いて、ステップ９におけるのと同様なステップである。それからフォールトの導入は、ステップ10で付け加えられるすべての新しいコネクタと配線のピースのために付け加えられる。
【０１４６】
図13では、我々は検査環境装置について述べる。それは、検査中のＥＣＵ1321と1323、およびこれらのＥＣＵのための環境シミュレーションに関与する多数のコンポーネントからなる。そのような装置は、それらの機能的な要求に適切に合うＥＣＵ1321と1323を実証するのを許す。またこの図は、導入部と図11において述べられたようなハードウェア イン ザ ループ環境のインプリメンテーションを示すだろう。
【０１４７】
パーソナル コンピュータ1301は、ＰＣ1301上に実行された１つのモデルがＥＣＵ1321とインターフェースされるように、取得およびコマンド ボード1313を介してＥＣＵ1321とインターフェースされる。ボード1313は、ＰＣ1301からバス1333を介して操作される。ＥＣＵ1321とボード1313との間のインターフェースは、ケーブル1343とコネクタ1355および1371を介して遂行される。
【０１４８】
同様に、パーソナル コンピュータ1301は、ＰＣ1301上に実行された１つのモデルがＥＣＵ1323とインターフェースされるように、取得およびコマンド ボード1315を介してＥＣＵ1323とインターフェースされる。ボード1315は、ＰＣ1301からバス1335を介して操作される。ＥＣＵ1323とボード1315との間のインターフェースは、ケーブル1345とコネクタ1357および1373を介して遂行される。
【０１４９】
ＥＣＵ1321と1323とはローカル エリア ネットワーク1341を介して接続され、多数の他のＥＣＵはこのバスに接続することができる。それから現実のハードウェア イン ザ ループを遂行するために、バス1341上の他のＥＣＵをシミュレートすることが必要である。これは、ネットワークといっしょに、受領可能でない、各ＥＣＵの動作の一部のみが検査されるように、ネットワークの障害が起きた場合、ＥＣＵが通常はリンプ モードを含むので、実際は強制的であろう。
【０１５０】
そこでボード1311は、ネットワーク1341上の欠けているＥＣＵをシミュレートするのを許すネットワーク インターフェースである。このボードは、バス1331を介してＰＣ1301に接続されている。もちろん、もしバス1341が、最大限に利用された組み込まれたバスであるなら、バス1331、1333および1335は何の制限も受けない。それらは例えばＶＭＥバスであってもよい。
【０１５１】
ＥＣＵ1321と1323を検査するとき、図８上で形成されたようにモデルにおけるそれらの輪郭を孤立させるには、それからＰＣ1301上のモデルの残りを実行するには十分である。もちろん、取得およびコマンド ボード1315、1313および1315間のすべての物理的インターフェースはコンフィガーされる必要があるが、このスタッフは最新の技術の状態でマスターされた。例えばＤスペース ツールは解法を与える。図13の特別な場合として、特有のＥＣＵの検査プランが、図８のＥＣＵの輪郭を孤立させることによって、図４と８のモデルから生成され、与えられたサービスまたは与えられたサービスのセットのために、一方でＥＣＵを、他方でＥＣＵの検査環境を考慮する。
【０１５２】
図14では、我々はメッセージ セットのモデル化および概念を述べる。組み込まれたドメインにおいて、バスは主に、種々のプロトコルにより出され、受けられるフレームに関して述べられる。組み込まれた利用のために、ＣＡＮ（コントローラ エリア ネットワーク）が広く用いられる。
【０１５３】
最初のステップは、図14Aで示されるような運ばれたデータフローのタイプに特別な注意を払わないで、各フレームのコンテントを特定することである。これは、データ サイズまたはフレームの位置に関してのどの制限も無しに、それぞれデータ1、データ2、データ3およびデータ4のためのレコード1411、1413、1415および1417が単純にリストされている、輪郭1401内に示される。
【０１５４】
第２ステップは、図14.Bにおけるような現実のフレーム レイアウトを考慮することにある。それから、各データの正確なロケーションと共にフレームのオーバーヘッドが特定される。例えばロケーション1425でのデータ２は、そのフレームの第３オクテットのビット２から第４オクテットのビット５へ書き込まれるだろう。また、フレームにおける差し込みが小さいエンディアンか大きいエンディアンかどうかを知ることが要求される。
【０１５５】
モデル化の第３ステップは、１つのフレームにおけるデータの書き込みと読み出しを許す、ＡＰＩをモデル化することにあってもよい。
【０１５６】
第４および最後のステップは、バス ドライバ ハードウェア インターフェースのためのアセンブラ コードをインタープリトすることであろう。実際、第３と第１ステップは、たいへん役に立つ。
【０１５７】
図16は、我々がいくつかのサービスのための検査オートマトンを織り混ぜる倍医を示す。今日に至るまで、我々は１つのサービスのための検査環境の特定に焦点を合わせた。我々はいまいくつかのサービスのための検査オートマトンの混合に焦点をあてる。
【０１５８】
共通の使用の場合を共有するサービスの１つのセットを我々が検査する場合、同期が、これらのサービスの検査オートマトンの間で遂行されなければならない。検査中のすべてのサービスのために共通の使用の場合が同期して実行される制限と共に、検査は織り混ぜられなければならない。これは遂行するのが難しくない。しかしながら、この検査アプローチは、トランスバース インパクトを有する使用の場合が以前のステージで正しく同定された状態の元で妥当である。
【０１５９】
他のサービスと共に実証されるのが必要なサービスの良い例は、エネルギーの管理である。このサービスは、各サービスにより要求されたパワーが実際パワー管理サービスから利用可能であるかどうかを見るために、他のサービスとトランスバーサリーに検査されるべきである。
【０１６０】
その場合、１つの乗物のたくさんのサービスにより共有された使用の場合は、典型的に「ユーサがエンジンをスタートさせる」である。パワー管理サービスのために、これは、「アルタメーター（altemator）が動作しており、パワーがアルタメーター パワー ラインへ切り替えられる」のような１つのシステム応答の結果となる。輪郭1601がパワー管理サービス検査プランの引用であるということ、および移行1623が乗物のエンジンをスタートさせるユーザ要求であり、エンジンのスタート チェックは状態1615において遂行されるということを考慮しよう。状態1611、1613および1617は、パワー管理サービスの他の状態のための他のチェックに対応する。
【０１６１】
環境（climate）制御のような他のサービスのために、エンジン スタートは、カー エンジンがまだ停止しているのに、もしクーリングが要求されたら、「クーリングがスタート」のようなシステム応答の結果となる。輪郭1603は、クーリング サービス検査プランの引用であり、移行1623のような移行1641は、エンジン スタート要求に対応することを仮定されたい。
【０１６２】
両方のサービスを一緒にする場合、それぞれの検査オートマトンは輪郭1605におけるように併合（merge）され得る。移行1623と1641は、それらは単一のユーザ要求の周囲に同期されるので、移行1675に併合される。他の要求は影響を受けないと仮定すると、両方のサービスの検査オートマトンは、次のような併合された検査オートマトンに翻訳（translate）される。
【０１６３】
・状態1611は状態1651に翻訳される。
・状態1631は状態1653に翻訳され、移行1671は達する状態1631を許す冷却サービスの移行に対応する。
・状態1613は状態1655に翻訳される。
・移行1621は移行1673に翻訳される。
・移行1623と1641は移行1675に併合され、翻訳される。
・状態1617は状態1659に翻訳される。
・状態1635は状態1635に翻訳される。
・移行1625は移行1677に翻訳され、移行1643は移行1679に翻訳される。
【０１６４】
翻訳のセマンティクスは、同一の移行が併合される場合を除いて、操作の固有性である。初期の検査オートマトンの状態が一緒にされた方法は、ランダムに見える。実際、両方のプランの呼び出し時間の制限はこの混合を駆動する。もちろん、ある同期は、同じ時間が２つの同期した状態間の各１つの検査オートマトンにおいて経過するように、必要とされる。これらのすべては、一方の移行1621、1625と他方の移行1643が完全に独立しているという前提の元でなされる。そこで我々は、いくつかのサービスが、それらのそれぞれの１つの実証環境に応じて、いかに実証され得るかを示した。これは、異なるサービスのユーザ要求が独立しているかまたは同期され得るかのいずれかの前提の元で可能である。
【０１６５】
また、検査中のすべてのサービスの初期の状態は同じでなければならない。同じに実証されるすべてのサービスの検査オートマトンは、すべてのそれらのサービスのために、共通の初期の状態でスタートし、すべての単一の検査オートマトンの初期の状態は、併合された検査オートマトンにおける特有の初期の状態において併合される。
【０１６６】
本発明の方法は、該方法の様々なステップをインプリメントし、それによって最終的に、組み込まれた電気的システムのために提案された設計を供給することにおける使用のための実証環境を自動的に出力するために、コンフィガーされた１つのコンピュータによってインプリメントされることができる。実証環境は好ましくは、それから後で、関係する各サービスのために提案された設計を実証するための１つのコンピュータの助けられた設計ツールによって使用されるだろう１つのコンピュータ 読み出し可能なメモリ デバイス内に記録され、そのような設計ツールは同じかまたは異なるコンピュータのいずれか一方を構成する。
【０１６７】
方法のステップは、特に例えばＣＤ、ＤＶＤまたは同様物のような、コンピュータ 読み出し可能なメモリの形で、または設計ツールのハード ディスク上に直接、コンピュータ プログラム製品上に記録されることによって商品化される。それから該方法は、読み出し可能で、関係するコンピュータ／設計ツールによって実行可能なコンピュータ プログラムとして、そのメモリ デバイス上に記録されるだろう。
【０１６８】
用語解説：（導入された順番にほぼ従っている）
使用の場合（Use Case）：１つのサービスの使用の簡単なシナリオの記述。１つの使用の場合は、コンテキストの定義、ユーザ要求、システム応答からなり、また例えば終−終 実行時間のようなパフォーマンス要求も含んでもよい。
【０１６９】
ユーザ要求（User request）：サービスに対するユーザの要求
システム応答（System response）：ユーザ要求に関連するサービスの応答であり、そのサービスをインプリメントするシステムの手段が与えられるもの。
【０１７０】
使用の場合のコンテキスト（Use Case Context）：使用の場合が利用できる、例えば機械的および電気的コンポーネントの状態等のコンテキスト。
【０１７１】
ムーア オートマトン（Moore automata）：移行上にトリガーされたコマンドを有しないオートマトン。
【０１７２】
動作に関するオートマトン（Behavioral automata）：状態と移行が、連続するユーザ要求および観点するシステム応答をまねる制御オートマトン。
【０１７３】
状態（State）：例えば動作に関するオートマトンにおけるシステム応答をトリガーする、オートマトンの状態。いつくかの状態は、同じファンクションを実行することができる。動作に関するオートマトンにおいては、状態がシステム応答を実行する。
【０１７４】
骨子実証環境（Skeleton validation environment）：検査または実証環境のための、基本的な輪郭およびデータフローを含む、検査間王のモデルのテンプレート。
【０１７５】
移行（Transition）：例えば動作に関するオートマトンにおけるユーザ要求をインプリメントする、オートマトンの移行。動作に関するオートマトンにおけるいくつかの移行は、同じユーザ要求を実行することができる。
【０１７６】
ファンクション（Functions）：は、ユーザ要求、システム応答およびどのオートマトンによってトリガーされた他のアクションをインプリメントする簡単で実行可能なコンポーネントである。１つのファンクションは、入力と出力データフローを持ち、ある動作は入力値のファンクションにおける出力値をトリガーする。システムの設計フェイズの間、ファンクションは、結局はソフトウェアのピースまたはハードウェアのピースとしてインプリメントされることができる。
【０１７７】
検査要求（testing request）：は、ユーザ要求と関係付けられたファンクションである。検査要求は、サービス記述とインターフェースされ、そのサービス インプリメンテーションにおけるその関連するユーザ要求を活性化するようにそのサービス入力をシミュレートする。
【０１７８】
状態チェック ファンクション：は、動作に関するオートマトンの状態に関連付けられる。それは検査中のサービスの出力とインターフェースされ、前記サービスがその関連する状態を介して行くとき、肯定的な検査結果、さもなければ否定的な結果を出すようにインプリメントされるべきである。
【０１７９】
初期状態ブロック（Initial conditions block）：実証の初期状態における、すべてのシステム コンポーネントの状態に対応する、すべてのデータフローの初期化。
【０１８０】
環境ループ：全体のシステムが実行およびシミュレーションに関して自己満足であるように、モデルおよび／またはハードウェア イン ザ ループ 検査環境および／またはＥＣＵおよび／または配線および／またはコンポーネント間の実行ループ。
【０１８１】
検査環境または実証環境：検査中のサービスおよび／またはそのサービスの実証の目的のための検査中のサービスのシステムおよび／または設計プロセスの異なるステップでのそのシステムとインターフェースされる環境。
【０１８２】
検査オートマトン（testing automata）：検査中のサービスのためにユーザ インタラクションとコンテキスト スイッチを詳細に述べる検査環境の部分。
【０１８３】
検査中のサービス（Service under test）：実証環境がそのために開発されたサービス。
【０１８４】
骨子実証環境（Skeleton validation environment）：すべてのファンクションの中で検査中のサービスからの部分が同定ファションである、実証環境の特定の実施例。骨子の目的は、関連する検査オートマトンと共に実証環境の複合的なデータフローを生成することである。骨子が一旦自動的に生成されると、それはモデル イン ザ ループの間で完成され、実証され得る。
【０１８５】
ハ−ドウェア イン ザ ループ検査（Hardware in-the-loop testing）：ドライバは、低レベル信号および高レベル ソフトウェア変数とインターフェースする。ネットワーク ドライバの場合、ドライバ範囲は、ネットワーク フレーム内のデータを挿入することおよび引き出すこと、フレームの発信と受信をトリガーすることを含む。アナログ ディジタル入力の場合、関係付けられたドライバは、サンプリング レートとデータ フォーマットが与えられたディジタル フォーマット内にアナログ信号を置く。
【０１８６】
サービスの写像（Mapping of a service）：ＥＣＵとネットワークから構成されるハ−ドウェア アーキテクチャ上の１つのサービスのインプリメンテーションの間、サービス コンポーネントは、例えばこれらのＥＣＵ上のサービスをインプリメントするソフトウェアのピースのような、異なるＥＣＵ上に写像され、そのサービスをインプリメントするセンサおよび／またはアクチュエータは、異なるＥＣＵに付け加えられるか、写像される。
【０１８７】
コネクタ（Connector）：製造と組立が容易であろう小さなコンポーネントに配線を分配する目的のため、配線アーキテクチャ内に挿入された１つのコンポーネント。また、配線とＥＣＵ間のインターフェース。１つのＥＣＵは、それぞれ１つが１つの異なる配線でそのＥＣＵとインターフェースする少しのコネクタを持つことができるだろう。
【０１８８】
ケーブル（Cable）：例えば乗物の製造プロセスにおけるように、組立を容易にするためにいっしょに集められた配線の１つのセット。
【０１８９】
配線（Wiring）：配線、コネクタおよび関連する電気的コンポーネントの設計に対応する設計ステップ。電子的部品は、一般に含まれない。配線は、例えば乗物のドアの配線、または乗物のコックピットにおけるマルチメディア ファンクションの配線のような、リンクされたケーブルとコネクタの１つのセットでもある。
【０１９０】
参照
ＡＨＵ74：
アホ、ホップクロフト ジェイ イー、ウルマン ジェイ デーによる1974年、ザ デザイン アンド アナリシス オブ コンピュータ アルゴリズムズ、アディソン ウエズリー、リーディング、マス
カン（ＣＡＮ）：
カンの明細書、ボス
Fuchs98：
オンラインで利用できるSAEペーパー 980199
www4.informatik.tu-muenchen.de/publ/papers/FEMPS98.pdf
Harel87：
エルセヴィア サンエンス パブリッシャー Ｂ．Ｖ（ノース ホランド）、1987年
Rushby95
コンピュータ サイエンス ラボラトリ、SRI インターナショナル、メンロ パーク、CA
ＩＥＣ61508：
発行者：インターナショナル エレクトロテクニカル コミッション（ＩＥＣ）、1998年
Simu：
マトラブ／シミュリンク アンド マトラブ／ステートフロー：（機械電子工学システムのシミュレーションをサポートする利用可能な主な商品）
http://www.mathworks.com
HIL&Test：
Dspace、ハードウェア イン ザ ループ：（ハードウェア イン ザ ループのサンプルおよび検査技術および技術の状態についての多数の関連があるペーパー）
http://www.dspaceinc.com/ww/en/inc/home.htm
【図面の簡単な説明】
【０１９１】
【図１】１つのサービスの使用の場合の仕様を示す。
【図２】１つのサービスの機能的な説明を示す。
【図３】１つのサービスの動作に関する記述を示す。
【図４】本発明によって自動的に生成される検査環境の骨子を示す。
【図５】図４における検査環境の一部である検査オートマトンを示す。
【図６】１つのサービスの機能的な記述を示す。
【図７】２つのＥＣＵと１つのネットワークを含む分配されたシステムを示す。
【図８】３つのＥＣＵと１つの配線ネットワークを含む分配されたシステムを示す。
【図９】コネクタ インターフェースを示す。
【図１０】電気的レベルでのフォールトのモデル化を示す。
【図１１】本発明による設計プロセスの１つの実施例を示す。
【図１２】安全クリティカル システムの設計プロセスの使用を示す。
【図１３】ハードウェア イン ザ ループの検査環境を示す。
【図１４】例えばＣＡＮバスのようなローカル エリア ネットワークにおけるフレームの１つの異なる仕様のマチュリティを示す。
【図１５】イン ザ ループ シミュレーションと検査の一般的なパラダイムを示す。
【図１６】いくつかの組み合わされたサービスの検査環境の混合を示す。
【特許請求の範囲】
【請求項１】
組み込まれた電気的システムによってインプリメントされたサービスのための実証環境を設計する方法であって、
ａ）前記サービスに１つ以上のユーザ要求およびシステム応答を割り当て、
ｂ）前記ユーザ要求およびシステム応答の許された配列を設定する、動作に関するオートマトンを前記サービスに割り当て、
ｃ）シミュレーション ツール上で実行可能なプログラムの形で、前記動作に関するオートマトンのトラバーサルから生じる検査オートマトン、初期条件のモデル、ユーザ要求のモデル、システム応答精度のモデル、環境モデルおよびデータフロー並びにこれらのモデルをいっしょに集める制御フローからなり、すべてのユーザ要求および前記サービスの結果として生じるシステム応答をカバーする、前記サービスのための骨子実証環境を自動的に生成し、
ｄ）設計実証ツールによる使用のために、前記骨子実証環境をコンピュータの読み出し可能なメモリ デバイスに記録する
ことを含んでなる方法。
【請求項２】
各前記ユーザ要求に、それをインプリメントするファンクションを割り当て、各前記システム応答に、それをインプリメントする１つ以上のファンクションを割り当てることを含み、前記骨子実証環境のデータフローは、前記ユーザ要求およびシステム応答のファンクションを用いて作られる請求項１記載の方法。
【請求項３】
前記サービスにブラック ボックス インターフェースを割り当て、その入力および出力は、サービスをインプリメントするファンクションの少なくとも１つでの入力および出力に対応し、前記サービス ブラック ボックスの入力と共に、前記サービス ブラック ボックスの出力を、前記骨子インプットおよび前記骨子アウトプットにインターフェースさせ、実証結果を生成するために、シミュレーション環境における骨子およびサービス仕様を完成し、調整することを含む請求項２記載の方法。
【請求項４】
前記サービスのための実証環境を含み、同時に該サービスの実証されたモデルを含む、実証されたモデルを出力することを含む請求項３記載の方法。
【請求項５】
該サービスのモデルを、そのソフトウェア インプリメンテーションで代用することを含む請求項１乃至４のいずれか記載の方法。
【請求項６】
該サービスのモデルを、そのソフトウェアおよびハードウェア インプリメンテーションで代用し、前記ハードウェア インプリメンテーションとインターフェースされる検査プラットフォーム上に前記実証環境を組み込むことを含む請求項１乃至５のいずれか記載の方法。
【請求項７】
乗物のブレーキ バイ ワイヤシステムのような、フォールト トレラント システムにおける、すべての複製されたオブジェクトのための、フォールトの体系的な導入を含む請求項１乃至６のいずれか記載の方法。
【請求項８】
少なくとも１つのユーザ要求を共有する、いくつかのサービスのために実証環境を割り当て、前記サービスのセットのために実証環境を生成するために、前記サービスの前記実証環境を混ぜることを含む請求項１乃至７のいずれか記載の方法。
【請求項９】
プログラムがコンピュータ上で動かされるとき、請求項１乃至８のいずれか記載のステップのすべてを実行するためのプログラム コード手段を含むコンピュータ プログラム。
【請求項１０】
プログラム製品がコンピュータ上で動かされるとき、請求項１乃至８のいずれか記載の方法を実行するためのコンピュータの読み出し可能な媒体上に記憶されたプログラム コード手段を含むコンピュータ プログラム製品。
【請求項１１】
請求項１乃至８のいずれか記載の方法を用いることによって、または請求項９記載のコンピュータ プログラムを用いてプログラムされることによって、組み込まれた電気的システムのための実証環境を出力するための使用において設計された、システム設計の実証のために適合された設計ツール。
【請求項１】
組み込まれた電気的システムによってインプリメントされたサービスのための実証環境を設計する方法であって、
ａ）前記サービスに１つ以上のユーザ要求およびシステム応答を割り当て、
ｂ）前記ユーザ要求およびシステム応答の許された配列を設定する、動作に関するオートマトンを前記サービスに割り当て、
ｃ）シミュレーション ツール上で実行可能なプログラムの形で、前記動作に関するオートマトンのトラバーサルから生じる検査オートマトン、初期条件のモデル、ユーザ要求のモデル、システム応答精度のモデル、環境モデルおよびデータフロー並びにこれらのモデルをいっしょに集める制御フローからなり、すべてのユーザ要求および前記サービスの結果として生じるシステム応答をカバーする、前記サービスのための骨子実証環境を自動的に生成し、
ｄ）設計実証ツールによる使用のために、前記骨子実証環境をコンピュータの読み出し可能なメモリ デバイスに記録する
ことを含んでなる方法。
【請求項２】
各前記ユーザ要求に、それをインプリメントするファンクションを割り当て、各前記システム応答に、それをインプリメントする１つ以上のファンクションを割り当てることを含み、前記骨子実証環境のデータフローは、前記ユーザ要求およびシステム応答のファンクションを用いて作られる請求項１記載の方法。
【請求項３】
前記サービスにブラック ボックス インターフェースを割り当て、その入力および出力は、サービスをインプリメントするファンクションの少なくとも１つでの入力および出力に対応し、前記サービス ブラック ボックスの入力と共に、前記サービス ブラック ボックスの出力を、前記骨子インプットおよび前記骨子アウトプットにインターフェースさせ、実証結果を生成するために、シミュレーション環境における骨子およびサービス仕様を完成し、調整することを含む請求項２記載の方法。
【請求項４】
前記サービスのための実証環境を含み、同時に該サービスの実証されたモデルを含む、実証されたモデルを出力することを含む請求項３記載の方法。
【請求項５】
該サービスのモデルを、そのソフトウェア インプリメンテーションで代用することを含む請求項１乃至４のいずれか記載の方法。
【請求項６】
該サービスのモデルを、そのソフトウェアおよびハードウェア インプリメンテーションで代用し、前記ハードウェア インプリメンテーションとインターフェースされる検査プラットフォーム上に前記実証環境を組み込むことを含む請求項１乃至５のいずれか記載の方法。
【請求項７】
乗物のブレーキ バイ ワイヤシステムのような、フォールト トレラント システムにおける、すべての複製されたオブジェクトのための、フォールトの体系的な導入を含む請求項１乃至６のいずれか記載の方法。
【請求項８】
少なくとも１つのユーザ要求を共有する、いくつかのサービスのために実証環境を割り当て、前記サービスのセットのために実証環境を生成するために、前記サービスの前記実証環境を混ぜることを含む請求項１乃至７のいずれか記載の方法。
【請求項９】
プログラムがコンピュータ上で動かされるとき、請求項１乃至８のいずれか記載のステップのすべてを実行するためのプログラム コード手段を含むコンピュータ プログラム。
【請求項１０】
プログラム製品がコンピュータ上で動かされるとき、請求項１乃至８のいずれか記載の方法を実行するためのコンピュータの読み出し可能な媒体上に記憶されたプログラム コード手段を含むコンピュータ プログラム製品。
【請求項１１】
請求項１乃至８のいずれか記載の方法を用いることによって、または請求項９記載のコンピュータ プログラムを用いてプログラムされることによって、組み込まれた電気的システムのための実証環境を出力するための使用において設計された、システム設計の実証のために適合された設計ツール。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公表番号】特表２００７−５２８０６９（Ｐ２００７−５２８０６９Ａ）
【公表日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願番号】特願２００７−５０２３０４（Ｐ２００７−５０２３０４）
【出願日】平成１７年３月１０日（２００５．３．１０）
【国際出願番号】ＰＣＴ／ＥＰ２００５／００２６３８
【国際公開番号】ＷＯ２００５／０９１１７７
【国際公開日】平成１７年９月２９日（２００５．９．２９）
【出願人】（５０３０４１７９７）ルノー・エス・アー・エス (286)
【Ｆターム（参考）】
【公表日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願日】平成１７年３月１０日（２００５．３．１０）
【国際出願番号】ＰＣＴ／ＥＰ２００５／００２６３８
【国際公開番号】ＷＯ２００５／０９１１７７
【国際公開日】平成１７年９月２９日（２００５．９．２９）
【出願人】（５０３０４１７９７）ルノー・エス・アー・エス (286)
【Ｆターム（参考）】
[ Back to top ]