(57)【特許請求の範囲】
【請求項１】
コンピュータベースの方法であって、
グラフィックベース論理制御仕様を階層的に妥当性確認するためのプロセッサによって、第１フィーチャを含む前記制御仕様の第１アプリケーションの機能的階層を識別するステップであって、前記第１フィーチャが第１モジュールを含み、該第１モジュールが前記第１フィーチャよりも下の層又は低いレベルにあり、該第１フィーチャが前記第１アプリケーションよりも下の層又は低いレベルにある、ステップと、
前記第１モジュールの構造と、該第１モジュールの機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該第１モジュール上で第１モジュール・テストケースを前記プロセッサによって実行するステップと、
前記第１モジュール・テストケースを実行した後、前記第１フィーチャの構造と、該第１フィーチャの機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該第１フィーチャ上で第１フィーチャ・テストケースを前記プロセッサによって実行するステップと、
前記第１フィーチャ・テストケースを実行した後、前記第１アプリケーションの機能的要件が満たされていることを妥当性確認すべく、前記第１アプリケーションに対して第１アプリケーション・テストケースを前記プロセッサによって実行するステップと
を含む、コンピュータベースの方法。
【請求項２】
第２フィーチャの構造と、該第２フィーチャの機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該第２フィーチャに対して第２フィーチャ・テストケースを前記プロセッサによって実行するステップであって、前記機能的階層は前記第２フィーチャを含み、該第２フィーチャの妥当性確認は前記第１フィーチャの結果の妥当性確認を含む、ステップを更に含む、請求項１に記載のコンピュータベースの方法。
【請求項３】
前記第１フィーチャが複数のモジュールを含み、当該方法が、前記複数のモジュールの各々の構造と、該複数のモジュールの各々の機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該複数のモジュール上で複数のモジュール・テストケースを前記プロセッサによって実行するステップを更に含む、請求項１に記載のコンピュータベースの方法。
【請求項４】
さらに、テキストベース・コードをグラフィックベース論理に翻訳することを含む、請求項１に記載のコンピュータベースの方法。
【請求項５】
さらに、グラフィックベース論理をテキストベース・コードに翻訳することを含む、請求項１に記載のコンピュータベースの方法。
【請求項６】
さらに、前記制御仕様内の複数のアプリケーションの全てを妥当性確認することを含む、請求項１に記載のコンピュータベースの方法。
【請求項７】
さらに、前記第１アプリケーションの第１フィーチャの機能的階層を前記プロセッサによって識別することを含む、請求項１に記載のコンピュータベースの方法。
【請求項８】
さらに、前記制御仕様の終端で開始し且つ始端まで妥当性確認することを含む、請求項１に記載のコンピュータベースの方法。
【請求項９】
さらに、電子制御ユニット全体を妥当性確認することを含む、請求項１に記載のコンピュータベースの方法。
【請求項１０】
前記電子制御ユニットは車両の電子制御ユニットである、請求項９に記載のコンピュータベースの方法。
【請求項１１】
各フィーチャの独自の機能的要件を妥当性確認すべく、独自のフィーチャ・テストケースが開発される、請求項１に記載のコンピュータベースの方法。
【請求項１２】
前記階層的妥当性確認のプロセスが、モジュール・レベルからフィーチャ・レベルへ、そしてアプリケーション・レベルへ流れる、請求項１に記載のコンピュータベースの方法。
【請求項１３】
テストケースの妥当性確認のオーバーラップが実質的に網羅的な妥当性確認カバレージを提供する、請求項１に記載のコンピュータベースの方法。
【請求項１４】
各フィーチャは前記グラフィックベース論理制御仕様内に機能を含む、請求項１に記載のコンピュータベースの方法。
【請求項１５】
国際標準化機構（ＩＳＯ）の仕様に対して前記制御仕様を妥当性確認するのに使用される、請求項１に記載のコンピュータベースの方法。
【請求項１６】
前記グラフィックベース論理制御仕様のエレメントがユーザーインターフェイス上でレンダリングされる、請求項１に記載のコンピュータベースの方法。
【請求項１７】
第２アプリケーションの機能的要件が満たされていることを妥当性確認すべく、該第２アプリケーション上で第２アプリケーション・テストケースを前記プロセッサによって実行することを更に含む、請求項１に記載のコンピュータベースの方法。
【請求項１８】
システムであって、
グラフィックベース論理制御仕様を階層的に妥当性確認するように構成されたプロセッサと、
該プロセッサと通信するように構成された有形の非一時的なメモリと
を具備し、
該有形の非一時的なメモリは該メモリ上に記憶された命令を有し、
該命令は、前記プロセッサによる実行に応答して、
グラフィックベース論理制御仕様を階層的に妥当性確認するためのプロセッサによって、第１フィーチャを含む前記制御仕様の第１アプリケーションの機能的階層を識別するステップであって、前記第１フィーチャが第１モジュールを含み、該第１モジュールが前記第１フィーチャよりも下の層又は低いレベルにあり、該第１フィーチャが前記第１アプリケーションよりも下の層又は低いレベルにある、ステップと、
前記第１モジュールの構造と、該第１モジュールの機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該第１モジュール上で第１モジュール・テストケースを前記プロセッサによって実行するステップと、
前記第１モジュール・テストケースを実行した後、前記第１フィーチャの構造と、前記第１フィーチャの機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該第１フィーチャ上で第１フィーチャ・テストケースを前記プロセッサによって実行するステップと、
前記第１フィーチャ・テストケースを実行した後、前記第１アプリケーションの機能的要件が満たされていることを妥当性確認すべく、前記第１アプリケーションに対して第１アプリケーション・テストケースを前記プロセッサによって実行するステップと
を含む作業を前記プロセッサに実施させる、システム。
【請求項１９】
非一時的な有形のコンピュータ可読記憶媒体を含む製造物品であって、該非一時的な有形のコンピュータ可読記憶媒体は該記憶媒体上に記憶された命令を有し、
該命令は、グラフィックベース論理制御仕様を階層的に妥当性確認するように構成されたコンピュータベース・システムによる実行に応答して、
該コンピュータベース・システムによって、第１フィーチャを含む前記制御仕様の第１アプリケーションの機能的階層を識別するステップであって、前記第１フィーチャが第１モジュールを含み、該第１モジュールが前記第１フィーチャよりも下の層又は低いレベルにあり、該第１フィーチャが前記第１アプリケーションよりも下の層又は低いレベルにある、ステップと、
前記第１モジュールの構造と、該第１モジュールの機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該第１モジュール上で第１モジュール・テストケースを前記プロセッサによって実行するステップと、
前記第１モジュール・テストケースを実行した後、前記第１フィーチャの構造と、前記第１フィーチャの機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、該第１フィーチャ上で第１フィーチャ・テストケースを前記コンピュータベース・システムによって実行するステップと、
前記第１フィーチャ・テストケースを実行した後、前記第１アプリケーションの機能的要件が満たされることを妥当性確認すべく、前記第１アプリケーションに対して第１アプリケーション・テストケースを前記コンピュータベース・システムによって実行するステップと
を含む作業を前記コンピュータベース・システムに実施させる、非一時的な有形のコンピュータ可読記憶媒体を含む製造物品。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、制御仕様を妥当性確認する上での改善に関し、より具体的には、グラフィックベース実行可能論理制御仕様（graphically based executable logic control specification）を階層的に妥当性確認するシステム及び方法に関する。
【背景技術】
【０００２】
新しい車載フィーチャ（in-vehicle feature）に対して需要が高まるにつれて、乗員の快適性、安全性、娯楽性、及び性能全体を増大させるように、数多くの電子制御モジュールが自動車内に導入されつつある。フィーチャ、例えば電子パワーステアリング、エンジン管理システム、アンチロック・ブレーキング・システム、エアバッグ・システム、トランスミッション・システム、及びナビゲーション・エンターテインメント・システムの性能パラメータは、電子制御ユニット（ＥＣＵ）によってモニタリングされ制御される。車両レベルのＥＣＵ設計、及び小規模なハードウェア又はソフトウェアの変更のための試験は高価であり、そしてコンピュータ集約型である。歴史的に見て、モジュール・レベルのテストは、不十分であることが判っており、ＥＣＵ全体を妥当性確認するのに使用されることができない。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
従って、基準に適合するように設計を妥当性確認する、より効率的且つ包括的なシステム及び方法が望まれる。
【課題を解決するための手段】
【０００４】
上に開示された要求は、開示されるシステム及び方法によって成功裡に満たされる。本開示は、概して、ＩＳＯ基準のような基準に準拠するように設計された、グラフィックベース実行可能論理制御仕様を階層的に妥当性確認するシステム及び方法に関する。
【０００５】
種々の模範的な実施態様では、コンピュータベースの方法と、システムと、命令が記憶された非一時的な（non-transitory）有形のコンピュータ可読記憶媒体を含む製造物品とが開示される。このコンピュータベースの方法は、グラフィックベース論理制御仕様を階層的に妥当性確認するためのプロセッサによって、第１フィーチャを含む制御仕様の第１アプリケーションの機能的階層を識別することを含んでよい。このコンピュータベースの方法は、前記第１フィーチャの構造と、第１フィーチャの特定の機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、第１フィーチャ上で特定の第１フィーチャ・テストケースをプロセッサによって実行することを含んでよい。また、このコンピュータベースの方法は、第１アプリケーションの機能的要件が満たされていることを妥当性確認すべく、第１アプリケーションに対して特定の第１アプリケーション・テストケースをプロセッサによって実行することを含んでよい。
【０００６】
コンピュータベースの方法は、第２フィーチャの構造と、第２フィーチャの特定の機能的要件が満たされていることとのうちの少なくとも一方を妥当性確認すべく、第２フィーチャに対して特定の第２フィーチャ・テストケースをプロセッサによって実行することを含む。機能的階層は第２フィーチャを含んでよい。加えて、第２フィーチャの妥当性確認は第１フィーチャの結果の妥当性確認を含んでよい。第１フィーチャは概して１つ以上のモジュールを含む。コンピュータベースの方法は、テキストベース・コードをグラフィックベース論理に翻訳すること、及び／又はグラフィックベース論理をテキストベース・コードに翻訳することを含んでよい。このコンピュータベースの方法は、制御仕様内の全てのアプリケーションを妥当性確認すること、及び／又は車両のＥＣＵのような電子制御ユニット全体を妥当性確認することを含んでよい。車両はいかなるタイプの車両であってもよい。
【０００７】
加えて、このコンピュータベースの方法は、第１アプリケーションの第１フィーチャの機能的階層をプロセッサによって識別することを含んでよい。妥当性確認のプロセスは、制御仕様の終端（end）で開始し且つ始端（beginning）まで妥当性確認してよい。各フィーチャの独自の機能的要件を妥当性確認すべく、独自のフィーチャ・テストケース（feature test case）が開発されてよい。種々の模範的な実施態様の場合、階層的妥当性確認（hierarchical validation）のプロセスは、モジュール・レベルからフィーチャ・レベルへ、そしてアプリケーション・レベルへ流れる。コンピュータ的制約（computational constraint）に基づいて、機能的階層が細分化されてよい。テストケース発見事項（test case findings）をオーバーラップさせることによって、実質的に網羅的な妥当性確認カバレージ（exhaustive validation coverage）を達成することができる。１つの実施態様では、各フィーチャはアプリケーション及び／又はグラフィックベース論理制御仕様内の機能であってよい。
【０００８】
このコンピュータベースの方法は、国際標準化機構（ＩＳＯ）の仕様に対して制御仕様を妥当性確認するのに使用されてよい。グラフィックベース論理制御仕様のデータはユーザーインターフェイス上でレンダリングされてよい。コンピュータベースの方法は、第１アプリケーションの特定の機能的要件が満たされていることを妥当性確認すべく、第１アプリケーション上で特定の第１アプリケーション・テストケースをプロセッサによって実行することを含んでよい。
【０００９】
以下の図面及び詳細な説明を検討すれば、本開示の他のシステム、方法、特徴、及び利点が当業者に明らかになるであろう。斯かる全ての付加的なシステム、方法、特徴、及び利点は、この説明内に含まれ且つ本開示の範囲内に含まれ、添付の特許請求の範囲によって保護されることが意図されている。図面に示された構成部分は、必ずしも原寸に比例してはおらず、本開示の特徴をよりよく説明するために誇張されることがある。図面において、同様の参照符号は、種々異なる図面全体を通して同様の部分を示す。
【図面の簡単な説明】
【００１０】
【図１Ａ】図１Ａは、車両内で使用される、妥当性確認されたＥＣＵの模範的実施態様を示す図である。
【図１Ｂ】図１Ｂは、車両内で使用される、妥当性確認されたＥＣＵの模範的実施態様を示す図である。
【図２】図２は、模範的な高レベルの、グラフィックベース実行可能論理制御仕様の機能的階層を示す図である。
【図３Ａ】図３Ａは、１つ以上の機能的階層を妥当性確認するための模範的なプロセス・フローを示す図である。
【図３Ｂ】図３Ｂは、１つ以上の機能的階層を妥当性確認するための模範的なプロセス・フローを示す図である。
【図３Ｃ】図３Ｃは、１つ以上の機能的階層を妥当性確認するための模範的なプロセス・フローを示す図である。
【図４】図４は、１つ以上の機能的階層を妥当性確認するための模範的プロセス・フローを示す図である。
【図５】図５は、機能的なチェックをするように構成されたテストケースを実施するための模範的なプロセス・フローを示す図である。
【図６】図６は、妥当性確認の情報を集約するための模範的なプロセス・フローを示す図である。
【図７】図７は、カバレージの改善された信頼性のための模範的なプロセス・フローを示す図である。
【図８】図８は、模範的な．ｍｄｌデータ構造を示す図である。
【図９】図９は、模範的な高レベルの、グラフィックベース実行可能論理制御仕様の機能的階層を示す図である。
【発明を実施するための形態】
【００１１】
自動車業界において、電子制御ユニット（ＥＣＵ）は、自動車の種々様々な部品／場所で自動車の種々異なる構成部分内に配置されたセンサから来た信号を読む埋め込み型電子装置、例えばデジタル・コンピュータである（図１Ａ参照）。この信号データに依存して、ＥＣＵは、自動車内の種々様々なユニット（例えばエンジン）及び自動作業を制御し、また自動車内に使用されるいくつかの重要な構成部分の性能に対するチェックを続ける。
【００１２】
ＥＣＵは概してハードウェア及びソフトウェア（ファームウェア）を含む。ハードウェアはプリント回路基板（ＰＣＢ）上の種々の電子構成部分を含んでいてよい。これら構成部品は、さらに、ＥＰＲＯＭ又はフラッシュ・メモリ・チップとともにマイクロコントローラ・チップを含んでいてよい。ソフトウェア（ファームウェア）は、マイクロコントローラによって処理される一組の低レベル・コードであってよい。
【００１３】
多くの場合、この業界では、ＥＣＵ（エンジン制御ユニット）はＥＣＭ（エンジン制御モジュール）と呼ばれることもある。ＥＭＳ（エンジン管理システム）としても知られるＥＣＭは、種々のエンジン機能、例えば燃料噴射、点火のタイミング、及びアイドル速度制御システムを制御する、内燃機関内のＥＣＵである。この制御は、種々のセンサから受信されるデータ（例えばエンジンクーラントの温度、空気流、クランク位置など）に基づくことができる（図１Ｂ参照）。ＥＣＭは、自動車が運転されるのに従ってエンジンについて「学習」することもある。「学習」は実際には、エンジン上のセンサ及び／又はアクチュエータの許容差変化を追跡するためにＥＣＵが用いるプロセスである。ＥＣＭはこれらの「学習」された値を、バッテリーバックアップされたＲＡＭに記憶するので、次回エンジンを始動させたときに最初からやり直す必要はない。航空用途では、これらのシステム（ＥＣＭの均等物）は一般に「ＦＡＤＥＣｓ」（Full Authority Digital Engine Control：フルオーソリティ・デジタル・エンジン制御）と呼ばれる。図１Ａ及び１Ｂを参照すると、ＥＣＵ２００を含む車両例が示されている。図１Ｂに示されているように、ＥＣＵ２００は、センサから入力を受信し、且つ、ユーザー、例えば車両のドライバーから直接入力を受信するように構成され得る。
【００１４】
完全なＥＣＵ２００の作成は、厳密なプランニング、試験、及び検証を必要とする集約的プロセスである。しばしば、ＥＣＵ２００又はＥＣＵ２００の一部の設計は、ビジュアル・プログラミング言語（ＶＰＬ）、モデルベース開発（ＭＢＤ）及び／又はグラフィックベース実行可能論理を用いることによって支援され得る。コンピューティングにおいて、ビジュアル・プログラミング言語は、プログラム・エレメントをテキスト的に指定することによるのではなく、これらをグラフィック的に操作することによって、ユーザーにプログラムを作成させる任意のプログラミング言語である。ＶＰＬは、視角的表現、構文のエレメント又は二次表記として使用されるテキスト及びグラフィック・シンボルの空間的配列によるプログラミングを可能とする。例えば、（データフロー又はダイヤグラム・プログラミングとして知られる）多くのＶＰＬは「ボックス及び矢印」の考えに基づいている。ここでは、ボックス又は他のスクリーン・オブジェクトは存在物（entity）として扱われ、これらは、関係を表す矢印、線、又は円弧によって結合される。
【００１５】
ＶＰＬは、さらに、用いられる視角的表現のタイプ及び範囲に従って、アイコンベース言語、フォームベース言語、及びダイアグラム言語に分類され得る。視角的プログラミング環境はグラフィック又はアイコン・エレメントを提供する。これらのエレメントは、プログラム構築用のいくつかの特定の空間的文法（spatial grammar）に従ってインタラクティブな方法でユーザーによって操作されることができる。
【００１６】
ＥＣＵ２００のＶＰＬベースの設計及び作業は、仕様に適合するように意図され得る。検証及び妥当性確認は、製品、サービス、又はシステム、例えば完成したＥＣＵ２００又はＥＣＵ２００の一部が要件及び仕様を満たし且つその所期目的を実現することをチェックするために一緒に用いられる独立した手続きであり得る。いくつかの事例では、これらはＩＳＯ９０００のような品質管理システムの構成要素である。種々の実施態様の場合、第三者によって検証及び／又は妥当性確認を実施することができる。検証は、製品、サービス、又はシステム（又はこれらの一部、又はこれらのセット）が一組の初期設計要件、仕様、及び規制を満たすことをチェックすることができる。開発段階において、検証手続きは、製品、サービス、又はシステムの一部又は全体をモデリングし又はシミュレートするために特別なテストを実施し、次いでモデリング結果の再検討又は分析を実施することを伴う。開発後の段階において、検証手続きは、具体的には時間経過とともに初期設計要件、仕様、及び規制を満たし続けることを保証するように考え出されたテストを規則的に繰り返すことを伴う。これは、製品、サービス、又はシステムが、開発段階開始時に課せられた規制、仕様、又は条件に準拠しているか否かを評価するために用いられるプロセスである。検証は、開発時、スケールアップ時、又は生産時に行うことができる。これは内部プロセスであることが多い。
【００１７】
妥当性確認は、製品、サービス、又はシステム（又はこれらの一部、又はこれらのセット）、例えば完成したＥＣＵ２００又はＥＣＵ２００の一部のための開発及び検証手続きが、初期要件、仕様、及び規制を満たす製品、サービス、又はシステム（又はこれらの一部、又はこれらのセット）をもたらすことをチェックするのに使用され得る。新しい開発フロー又は検証フローに際しては、フローのモデリング及びシミュレーションの利用によって、製品、サービス、又はシステム（又はこれらの部分、又はこれらのセット）の無効な又は不完全な検証又は開発を招くおそれのある欠陥又はギャップを予測することを伴ってよい。次いで、一組の妥当確認の要件、仕様、及び規制を、製品、サービス、又はシステム（又はこれらの一部、又はこれらのセット）のための開発フロー又は検証フローを適格とするためのベースとして用いることができる。付加的な妥当性確認の手続きは、具体的には、既存の適格な開発フロー又は検証フローに対してなされた修正が初期設計要件、仕様、及び規制を満たす製品、サービス、又はシステム（又はこれらの一部、又はこれらのセット）を生成する効果を有することを保証するように設計された手続きを含むことができる。これらの妥当性確認は、フローを適格な状態に保つのを助ける。これは、製品、サービス、又はシステムがその意図された要件を達成する高度な保証を提供する証拠を確立するプロセスである。このプロセスはしばしば、エンドユーザー及び他の製品利害関係者による目的適合性の受け入れを伴う。検証及び／又は妥当性確認のための書面による要件、並びにこの開示に従ってコンプライアンスを判断するための正式な手続き又はプロトコルを作成してよい。
【００１８】
ＥＣＵ２００の設計が、存在し得るいずれの順列においても仕様に適合することを検証することは、不可能ではないにしても極めて困難であり、最先端のコンピュータ・システムに対してですら重い負荷をかける。一般的には、種々の模範的実施態様において、本システムは、仕様の従来の終端から仕様の始端までを妥当性確認する。例えば、本システムは、グラフィックベース実行可能論理に対する機能的階層妥当性確認を用いて、ＥＣＵ２００全体の制御仕様を妥当性確認する。模範的な実施態様では、そして図２を参照すると、この階層アプローチは、モジュール・レベル５０からフィーチャ・レベル７５へ、そしてアプリケーション・レベル１００へ移ることにより、ＥＣＵ２００全体の制御仕様を妥当性確認することができる。
【００１９】
モジュール・レベル５０はフィーチャ８０内に最低レベルを含んでよい。モジュール５５は実際の制御論理を表していてよく、すなわち、モジュール５５の機能的要件は概して論理自体を含むであろう。複数のモジュール５５の組み合わせは結果として、評価し得るより高次の機能的要件をもたらし得る。複数のモジュール５５の組み合わせはフィーチャ８０をもたらし得る。モジュール・レベル５０で実施された妥当性確認は、低レベル制御仕様及び低レベル機能的要件、例えば構造に関連する制御仕様及び機能的要件を含んでよい。フィーチャ・レベル７５はアプリケーション１０５内の機能を含んでいてよい。フィーチャ８０は機能及び／又はサブアッシーとして概念化されることができる。例えばフィーチャ８０と関連する機能的要件は、車両のモードを制御するものであってよい。車両のモードを制御するフィーチャ８０は数多くのモジュール５５を含んでよい。各モジュールはこの機能内のエレメントを判断して制御する。フィーチャ・レベル７５は、機能的階層、例えばモジュール５５及びモジュール５５群を含んでよい。モジュール５５の二重使用（機能的階層間のオーバーラップ（overlap））は考えられていないので、蓄積階層的アプローチ（accumulative hierarchical approach）を実施することによって達成される結果は信頼性を伴う。フィーチャ・レベル７５は、特定の中レベルの機能的要件を含んでよい。フィーチャ・レベル７５は実際の制御論理を組み合わせることによって機能を実施することを含んでよい。フィーチャ・レベル７５は、複雑性に基づくモジュール５５から成る複数の層を含んでいてよい。アプリケーション・レベル１００は仕様全体を含んでよい。アプリケーション・レベル１００は、機能的階層（例えばフィーチャ８０及び／又はフィーチャ８０群）を含んでいてよい。アプリケーション・レベル１００は、一般的な機能を実施すべく、フィーチャ８０の組み合わせを含むことができる。
【００２０】
種々の実施態様の場合、このシステムは、２つの妥当性確認カテゴリー、すなわち低レベル妥当性確認と高レベル妥当性確認とを利用する。低レベル妥当性確認は、構造問題及び低レベル機能問題（例えば範囲違反、ブロック設計問題、デッドコードなど）の識別を含んでよい。この低レベル妥当性確認は、モジュール設計の機能上の正確性を達成するように構成されることができる。
【００２１】
高レベル妥当性確認は、フィーチャ８０及びアプリケーション１０５の機能的階層を妥当性確認することによって、制御設計問題（例えば正しくない制御理論、意図されない設計エラーなど）を識別して訂正することができる。この高レベル妥当性確認は、制御設計の正確性を達成するように構成されてよい。
【００２２】
一般的に、２つの妥当性確認段階及び／又はレベル、すなわちフィーチャ・レベル７５及びアプリケーション・レベル１００が存在する。フィーチャ・レベル７５は構造要件及び機能的要件を含んでよい。アプリケーション・レベル１００は機能的要件を含んでよい。
【００２３】
図３Ａを参照すると、模範的プロセス・フローが示されている。このプロセス・フローは、左から右へ、上から下へ読むことができる（与えられた矢印に従う）。グラフィックベース実行可能論理内で示された計算は概して左から右へ流れることに留意されたい。しかしながら、確立された機能的階層の妥当性確認は、種々の模範的実施態様において右から左へ実施されるように意図されている。
【００２４】
最初に、これらアプリケーション・レベル１００のグラフィックベース実行可能論理の機能的階層が識別される。次に、機能的階層内に含まれるフィーチャ８０が識別される。各フィーチャ８０の構造を評価するための個別化されたテストケースが作成されてよい（例えばテストケース１ａ．１）。加えて、それぞれのフィーチャ８０と関連する機能的要件（例えば機能的要件（ＦＲ）１ａ．１）も識別される。関連付けられたテストケース（例えば１ａ．１）は機能的要件のこのテストを含んでいてよい。次に、階層内の次のフィーチャ８０の構造を評価するための個別化されたテストケースが識別されてよい（例えばテストケース１ａ．２）。加えて、それぞれのフィーチャ８０と関連する機能的要件（例えば機能的要件（ＦＲ）１ａ．２）も識別される。関連付けられたテストケース（例えば１ａ．２）は機能的要件のこのテストを含んでいてよい。このプロセスは、このレベルでの機能的階層内のフィーチャ８０に対するテストケース（１ａ）の全てが生成されるまで繰り返される。
【００２５】
作成されるテストケース（例えばテストケース１ａ．１）に応じて、そのテストケースにおける妥当性確認、例えばテストケース１ａ．１を実施してよい。この妥当性確認の試験は、構造が正しいことと、任意の関連機能的要件が満たされていることとをテストすることができる。この妥当性確認の試験を通ったフィーチャ８０に応じて、機能的階層における次のフィーチャ８０の妥当性確認の試験を実施する。この妥当性確認の試験は、機能的階層内で実施された、前に完成された先行する機能的要件の妥当性確認に関して包括的であってよい。この包括的プロセスはコンピュータ要件を低減する。また、不連続な構造及び／又は機能的要件に対して特異的な個別化されたテストケースは、コンピュータ要件全体を低減する。また、種々の実施態様において、一旦モジュール５５又はフィーチャ８０が妥当性確認されると、より高いレベルの機能的要件の実施だけが必要となる。換言すれば、種々の実施態様において、このレベルに続くより低いレベルの妥当性確認は必要ではなく、またモジュール５５又はフィーチャ８０上で実施されることもない。
【００２６】
妥当性確認される機能的階層内の全てのフィーチャ８０に応じて、アプリケーション１０５のテストケースを決定し、フィーチャ７５レベルにおいて実施されたテストケースと同様に、アプリケーション１００レベルでこれを実施することができる。アプリケーション１００レベルでは、テストケースは、概して、フィーチャ・レベル７５の妥当性確認においてカバーされてきた構造チェックとは関係しない。
【００２７】
本システムの種々のエレメントは、コンピュータベースのシミュレータ上で実施されてよく、且つ／又はシミュレーション・ソフトウェア、例えばSimulink（登録商標）内部に含有されていてよい。フィーチャ・レベル７５におけるテストケースは、カバレージ・ターゲット、例えばSimulink設計検証（ＳＬＤＶ）レベルに到達し、次いでこの階層的アプロートを用いて、修正条件決定カバレージ（ＭＣＤＣ）レベルに進むように構成されていてよい。修正条件決定カバレージは、論理が通り得る実質的に全てのパスを含み、且つ／又は制御仕様の全ての機能的要件をカバーし得る。種々様々な実施態様の場合、満たされるようにするＭＣＤＣターゲット及び／又は違反されないようにする機能的要件に応じてモジュールを妥当性確認する。機能的要件の違反は、モジュール５５のエラーに対処し且つ／又はモジュール５５のエラーを訂正することをもたらす。
【００２８】
アプリケーション・レベル１００におけるテストケースはさらに、特定の機能チェック（ユーザー、センサ、例えばＬＡ４ラムダ・メーターなど）のために構成されていてもよい。フィーチャ７５レベル及びアプリケーション１００レベルは、機能的要件が違反されないとき、妥当性確認されることができる。機能的要件違反は、制御設計エラーに対処し又は制御設計エラーを解決することをもたらし得る。最終的なフィーチャ８０の妥当性確認テスト（例えば完成したフィーチャ８０）についての機能的な妥当性確認及びアプリケーション・レベル１００の妥当性確認はこの段階で実施され得る。
【００２９】
図３Ａを改めて参照すると、いくつかの実施態様において、フィーチャ・レベル７５はフィーチャ８０の低レベル及び高レベルの妥当性確認（フィーチャ８０の構造及び機能的妥当性確認）を含んでよい。例えばフィーチャ８０の機能的階層にはＭＣＤＣが対応し、完成したフィーチャ８０にはＭＣＤＣプラス・ファンクショナル（ＭＣＤＣ plus functional）が対応する。論理が評価されるとき、機能的要件が付加され且つ／又は評価されてよい。各機能的要件は複数の機能的階層を含んでよい。機能的階層が機能的要件を含まない場合には、機能的要件は妥当性確認のフロー目的のための別の機能的階層に含まれてよい。
【００３０】
図３Ｂを参照すると、アプリケーション・レベル１００上で実施されているテストケースのグラフィック表示が示されている。例えばテストケース３．１〜３．５はそれぞれ、独自の識別された機能的階層を示している。各機能的階層と関連付けられた機能的要件をテストし且つ／又は妥当性確認すべく、テストケースを開発することができる。図３Ｃを参照すると、図３Ｂにおいて確立されたテストケースが実行されている。例えばテストケース３．１を実施する。テストケース３．１がエラーを返さなければ、その後、テストケース３．２を実施してよい。また、これは、右から左へ移動し且つ仕様の終端で始まるプロセスの一例である。このテストケース（３．２）は、随意に、テストケース３．１、（３．２＋３．１）の結果を含んでもよい。こうして、各テストケースを処理するコンピュータ・システムに過剰の負荷をかけることなく、知識体系が増大される。
【００３１】
図４を参照すると、種々の実施態様において、フィーチャ８０の機能的階層は制御仕様内で定義されない場合がある。コンピュータ的制約に基づいて、ユーザーは機能的要件に基づいて機能的階層を選択してもよい。例えば、機能的階層が１つのモジュール５５（又はコンピュータで管理可能な数のモジュール５５）を含む状況の場合、妥当性確認は１つのテストの実施で達成されることができる。機能的階層が広すぎ且つ／又は複雑である状況の場合には、妥当性確認のために機能的階層をより小さな単位に細分化すべきである。
【００３２】
図５を参照すると、種々の実施態様において、アプリケーション・レベル１００はアプリケーション・レベル１００の機能的階層を含む。アプリケーション・レベル１００の機能的階層は、フィーチャ・レベル７５の全ての機能的階層上で妥当性確認されることができる。アプリケーション・レベル１００についてのテストケースは、改善された実質的に網羅的なテスト・カバレージのために、新しい機能テストケース、及びフィーチャ８０の最終的な機能的階層カバレージテストケースを含むべきである。論理が評価されるとき、機能的要件が付加され且つ／又は評価されてよい。例えば、各機能的要件は複数の機能的階層を利用することができる。
【００３３】
図６を参照すると、概して、前述のように、妥当性確認システムは、終端で始まり、アプリケーション・レベル１００の機能的階層に進む。機能的階層内部の各フィーチャ８０に対して、フィーチャ・レベル７５の妥当性確認を実施してよい。機能的階層内部の全てのフィーチャ８０が妥当性確認されるのに応じて、機能的階層に対応するアプリケーション・レベル１００の妥当性確認を行ってよい。この妥当性確認は、アプリケーション・レベル１００の機能的階層の蓄積型妥当性確認の上に形成されることができる。機能的要件違反が機能的階層内で見いだされるのに応じて、当該モジュール上で低レベルの妥当性確認を実施してよく、且つ／又は、高レベルの妥当性確認をその機能的階層上で再び実施すべきである。いくつかの状況では、フィーチャ８０の妥当性確認は、アプリケーション・レベル１００の機能的階層順序に従わなくてもよい。
【００３４】
図７を参照すると、種々の模範的実施態様では、実質的に可能な限り最良のカバレージ（ＭＣＤＣ）がモジュール５５に対して達成されるのに応じて、付加的な独自の試験の結果として、網羅的カバレージを改善することができる。この付加的な試験は、妥当性確認の精度の信頼性を改善するために実施されることができる。この付加的な試験は、網羅的カバレージの信頼性を改善すべく、フィーチャ・レベル７５及び／又はアプリケーション・レベル１００において実施されることができる。
【００３５】
各機能的階層について、できる限り最良のカバレージのテストケースを別々に生成してよい。これらのテストケースはユーザーによって定義され又は形式的方法によって定義されてもよい。テストケースは、まだ妥当性確認されていないレベルに対して生成されてよい。前に妥当性確認された論理を、目下のターゲット論理と組み合わせ、こうして妥当性確認された論理を、より多くのテストケースが処理されるのに伴って経時的に蓄積して収集してよい。また、階層レベルが上がるとともに、機能的要件を付加して妥当性確認することができる。できる限り最良のカバレージのテストケースと、特定の機能チェックのために生成されたテストケースとを使用して、機能的要件を妥当性確認することができる。換言すれば、このシステムは、フィーチャ・レベルの機能的階層を妥当性確認し、次いで、同じ概念を利用してアプリケーション・レベル１００の機能的階層の妥当性確認へ移動する。種々の実施態様において、システムはグラフィックベース論理を用いて実施される。
【００３６】
仕様の終端で始まり且つ始端まで妥当性確認することにより、より高いレベルの機能的要件をチェックするための妥当性確認された機能的階層を維持しつつ、妥当性確認されていない機能的階層が、できる限り最良のカバレージ技術を利用して妥当性確認されることが可能になる。各機能的階層に対するテストケースを別々に生成することによって、処理要件が低減され、そしてターゲットされた機能的階層に対するカバレージ結果がもたらされる。このことは、全ての適格な機能的要件（典型的にはより高いレベルの機能的要件）を含みつつ、各機能的階層が直接（より低いレベルの機能的要件）妥当性確認されることを可能にする。このシステムは、コンピュータ的又は数学的な制約により形式的方法を適用できないときに、より広範囲の網羅的試験を達成することを可能にする。このプロセスがアプリケーション・レベル１００の機能的階層の全てに対して完成されるのに応じて、仕様全体は、できる限り最良のカバレージ及び網羅的メトリクス（exhaustive metrics）まで妥当性確認される。このプロセス及びシステムは、例えばＩＳＯコンプライアンスのために、ＥＣＵ２００全体のアプリケーション論理を妥当性確認することができる。このＩＳＯコンプライアンスは、任意の好適なＩＳＯ仕様に対するものである。このＥＣＵ２００は車両、例えば陸上の車両、ウォータークラフト又は航空機において使用されてよい。ＥＣＵ２００は、自動車、電動自転車、オートバイ、スクーター、四輪車、ａｔｖ、モーターホーム、列車、船舶、ボート、航空機、及び／又は宇宙船に使用されてよい。
【００３７】
グラフィックベース実行可能論理は任意の所望のときにテキスト論理に変換され且つテキスト論理から変換されることができる。例えば、ＥＣＵ２００全体が妥当性確認されるのに応じて、論理はグラフィックベース実行可能論理からテキストベースの論理へ翻訳されてよい。また、ＥＣＵ２００全体が妥当性確認されるのに応じて、論理はループ内のソフトウェア及び／又は更なる検証／妥当性確認のためのループ・シミュレーション内のハードウェアに移されてよい。また、この開示内容の種々の態様を、ラピッド・プロトタイピングと組み合わせることにより、ＥＣＵ２００論理及び／又はＥＣＵ２００のエレメントをさらにテストすることができる。
【００３８】
妥当性確認システムの１つの実施態様に関して説明されたステップは、これに加えて又はこれの代わりに、他の実施態様のいずれかに組み込まれてよい。例えば、図３Ａに関連して記載されたステップは任意の他の実施態様において用いられてよい。当業者にはこれも明らかなように、本明細書中に開示された例との関連において記載された種々の例示的な論理ブロック、モジュール、及びアルゴリズム・ステップを電子ハードウェア、コンピュータ・ソフトウェア、又は両方の組み合わせとして実施することができる。このような機能をハードウェアとして実施するかソフトウェアとして実施するかは、具体的な用途、及びシステム全体に課せられる設計上の制約に依存する。当業者ならば、それぞれの具体的な用途に対して種々様々な方法で上記機能を実施し得るが、このような実施の決定は、開示された装置及び方法の範囲を逸脱させるものとして解釈してはならない。
【００３９】
本明細書中に開示された例との関連において記載された方法のステップは、ＥＣＵ２００に関するものとして開示されている。しかしながら、この方法は、任意のグラフィックベース実行可能論理、及び／又はグラフィックベース実行可能論理制御仕様の階層妥当性確認に適用することもできる。例えば、図８及び９を参照すると、任意のタイプの制御仕様に対応するアプリケーション・レベル及びフィーチャ・レベルにおける．ｍｄｌファイル及び機能的階層が示されている。
【００４０】
システム、方法、及びコンピュータ・プログラム製品が提供される。「種々の実施態様」、「１つの実施態様」、「実施態様」、「一例としての実施態様」などの言及は、記載された実施態様が特定のフィーチャ、構造、又は特徴を含んでもよいが、どの実施態様も特定のフィーチャ、構造、又は特徴を必ずしも含むわけではないことを示唆する。さらに、このような言い回しは、同じ実施態様を必ずしも意味しない。さらに、特定のフィーチャ、構造、又は特徴が或る実施態様との関連において記載されているとき、このようなフィーチャ、構造、又は特徴が、明示的に記載されているか否かにかかわらず他の実施態様との関連においてもたらされることは当業者の知識の範囲内にあると考えられる。説明を読んだ後、どのようにして開示内容を代替の実施態様において実施するかが当業者には明らかになるだろう。
【００４１】
本明細書中に開示された例との関連において記載された方法又はアルゴリズムのステップは、ハードウェア内、プロセッサによって実行されたソフトウェア・モジュール内、又はこれら２つの組み合わせにおいて直接的に具現化されることができる。ソフトウェア・モジュールは、ＲＡＭメモリ、フラッシュ・メモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、又は当業者に知られている任意の他の形態の記憶媒体内に存在してよい。模範的な記憶媒体がプロセッサにカップリングされるので、プロセッサは記憶媒体から情報を読み出し、そして記憶媒体へ情報を書き込むことができる。代替的に、記憶媒体はプロセッサと一体的であってよい。プロセッサ及び記憶媒体は特定用途向け集積回路（ＡＳＩＣ）内に存在し得る。
【００４２】
システム及び方法は、機能ブロック成分、スクリーンショット、任意の選択及び種々の処理ステップの観点から本明細書中に記載される。このような機能ブロックは、指定された機能を実施するように構成された任意の数のハードウェア及び／又はソフトウェア成分によって実現されることができることが理解されるべきである。例えば、システムは、種々の集積回路成分、例えばメモリ・エレメント、処理エレメント、論理エレメント、及びルックアップ・テーブルなどを採用してよい。これらは、１つ以上のマイクロプロセッサ又は他の制御デバイスの制御下で種々様々な機能を実施することができる。同様に、システムのソフトウェア・エレメントは、任意のプログラム言語又はスクリプト言語、例えばVPL、C、C++、C#、Java（登録商標）、JavaScript、VBScript、Macromedia Cold Fusion、COBOL、Microsoft Active Server Pages、アセンブリ、PERL、PHP、awk、Python、Visual Basic、SQL Stored Procedures、PL/SQL、任意のUNIX（登録商標）シェル・スクリプト、及び拡張マークアップ言語(XML)で実装されてよく、種々のアルゴリズムは、データ構造、オブジェクト、プロセス、ルーティン又は他のプログラミング・エレメントの任意の組み合わせで実装される。さらに、システムがデータ伝送、シグナル伝達、データ処理、ネットワーク制御、及びこれらの均等物のために任意の数のコンベンショナルな技術を採用し得ることに留意されたい。
【００４３】
当業者に知られているように、システムは、既存のシステム、アドオン製品、アップグレードされたソフトウェア、スタンドアローン型システム、分配型システム、方法、データ処理システム、データ処理用デバイス、及び／又はコンピュータ・プログラム製品をカスタマイズしたものとして具現化され得る。さらに、システムは、記憶媒体内で具現化されるコンピュータ可読プログラムコード手段を有する、非一時的なコンピュータ可読記憶媒体上のコンピュータ・プログラム製品の形態を成していてもよい。ハードディスク、ＣＤ−ＲＯＭ、光学記憶装置、磁気記憶デバイス及び／又はこれらの均等物などを含む任意の好適なコンピュータ可読記憶媒体を利用してよい。
【００４４】
本発明の模範的な実施態様を例示様式で開示してきた。従って、全体を通して採用された用語は非限定的な態様で読まれるべきである。本明細書の教示に対する小さな修正が当業者に明らかであるが、ここで保証される特許の範囲内に制限しようと意図されるものは、関与する技術分野の進歩の範囲内に合理的に含まれる全ての実施態様であり、その範囲は、添付の請求項及びこれらの均等物を考慮することを除いて、限定されるべきではないことを理解されたい。
【図１Ａ】
0005706463.tif 000002
【図１Ｂ】
0005706463.tif 000003
【図２】
0005706463.tif 000004
【図３Ａ】
0005706463.tif 000005
【図３Ｂ】
0005706463.tif 000006
【図３Ｃ】
0005706463.tif 000007
【図４】
0005706463.tif 000008
【図５】
0005706463.tif 000009
【図６】
0005706463.tif 000010
【図７】
0005706463.tif 000011
【図８】
0005706463.tif 000012
【図９】
0005706463.tif 000013