JP2007310670A - 車載電装システムの開発支援装置及び設計不具合検証方法 - Google Patents

Abstract

【課題】複数の制御装置に跨る統合制御により所定の動作を実行する車載電装システムの設計不具合を開発プロセスの上流工程で適切に検証できるようにし、開発手戻りを極力低減させて効率的な開発が行えるようにする。
【解決手段】ハーネス結線モデルやＣＡＮコミュニケーションモデルの作成で得られるワイヤブラウザ情報やＣＡＮ台帳（第１の設計情報）と、制御モデルの作成で得られる信号名称変換表（第２の設計情報）とを用いて、インターフェース変換層コンピュータ３０において複数の制御モデル間での信号の送受信を定義した接続ファイルを作成する。そして、この接続ファイルの整合性、または、実車相当のシミュレーション環境によるシステム全体のシミュレーション試験の試験結果に基づいて、システム全体の仕様策定（第１の設計段階）や個々のＥＣＵの詳細仕様の策定（第２の設計段階）における仕様漏れなどの設計不具合を検証する。
【選択図】図１２

Description

本発明は、複数の制御装置に跨る統合制御により所定の動作を実行する車載電装システムの開発を支援するための開発支援装置及び設計不具合検証方法に関する。

ソフトウェアの開発プロセスとしては、一般に、JISX0160(ISO/IEC1207)のソフトウェア・ライフサイクル・プロセスの開発プロセスに規定されているＶ字型開発プロセスモデル（SLCP）が知られている。この開発プロセスは、要求分析から始まり、システム設計、アーキテクチャ設計、モジュール設計および実装、そして、個別モジュールテスト、統合試験、検証に終わる、所謂ウォーターフォール的な開発プロセスである。

このＶ字型開発プロセスでは、通常、要求仕様に合わせた設計の不具合などに起因する最終的な製品の不具合が、ソフトウェアを製品に実装した後の個別モジュールテストや統合試験などで検証されるため、不具合発生時の設計仕様へのフィードバックに時間がかかり、再度、製品を試作し直す必要があるためにコストも増大するという問題がある。そこで、このような問題への対策として、仕様策定段階で、策定する仕様に相当するシミュレーションモデルを作成し、シミュレーション計算することにより設計検証を行うことが提案されている（例えば、特許文献１，２，３等を参照。）。
特開２００４−３８７４１号公報 特開２００５−９２５９８号公報 特許第３０９６７９６号公報

上述したＶ字型開発プロセスは、車両に搭載される車載電装システム、特に複数の制御装置（ＥＣＵ：Electronic Control Unit）に跨る統合制御により所定の動作を実行する車載電装システムの開発にも適用されている。このような車載電装システムの開発は、開発対象が大規模でタスクが細分化されているためウォータフォール型となり、開発体制としてもシステム全体から詳細への設計が段階的で、複数の開発部署やサプライヤで分担されることになるため、その開発プロセスは、一般的にＶ字型開発プロセスとなる。

ところで、以上のような車載電装システムの開発にＶ字型開発プロセスを適用した場合には、例えばシステムＬＳＩなどの単一のハードウェアの開発では想定し得ない特有の問題が生じる。すなわち、以上のような車載電装システムでは、システム全体としての動作が複数のＥＣＵに跨る統合制御により実現されるため、上述した特許文献１，２，３などで提案されているように、ＥＣＵの動作をシミュレートするモデルを作成して設計段階で検証を行うようにしても、システム全体の動作を正確に検証することはできず、ＥＣＵ間の予期せぬ不整合などを設計段階で検証することができない。

すなわち、車載電装システムにおける複数のＥＣＵは、ワイヤハーネスで相互に接続されて信号の授受を行ったり、ＣＡＮ（Controller Area Network）などの通信によりメッセージの交換などを行うことで、互いに協調してシステム全体の動作を制御するが、個別のＥＣＵごとのモデルによるシミュレーションでは、ワイヤハーネスによる接続設計の結果やＣＡＮなどの通信による接続設計の結果はモデルの中に含まれないため、ＥＣＵ間のワイヤハーネスの接続設計や通信設計が、意図した通りの動作を実現できるように正しく設計されているかを設計段階で検証することができない。

このため、設計段階における設計不具合が最終的な統合試験を経て初めて発覚する場合があり、いわゆる開発手戻りによる効率の低下やコスト増大が懸念される。

本発明は、以上のような従来の実情に鑑みて創案されたものであって、複数の制御装置に跨る統合制御により所定の動作を実行する車載電装システムの設計不具合を開発プロセスの上流工程で適切に検証できるようにし、開発手戻りを極力低減させて効率的な開発が行えるように支援する車載電装システムの開発支援装置及び設計不具合検証方法を提供することを目的としている。

本発明は、車載電装システム全体の動作を統合制御する複数の制御装置の動作を各々シミュレートする複数の制御モデルを作成するとともに、システム全体の仕様を策定する第１の設計段階で得られる第１の設計情報と、第１の設計段階で策定された仕様に従って個々の制御装置毎の詳細仕様を策定する第２の設計段階で得られる第２の設計情報とに基づいて、複数の制御モデル間での信号の送受信を定義した接続ファイルを作成し、これら複数の制御モデルと接続ファイルとを用いて複数の制御装置に跨る統合制御をシミュレートして、車載電装システム全体の動作を試験する。そして、第１の設計情報と第２の設計情報とに基づいて作成した接続ファイルの整合性、または、複数の制御モデルと接続ファイルとを用いた統合制御のシミュレーションによる車載電装システム全体の動作試験結果に基づいて、第１の設計段階または第２の設計段階における設計不具合の有無を検証するようにした。

本発明によれば、複数の制御モデル間での信号の送受信を定義した接続ファイルの整合性、または、複数の制御モデルと接続ファイルとを用いた統合制御のシミュレーションによる車載電装システム全体の動作試験結果に基づいて、第１の設計段階または第２の設計段階における設計不具合の有無が検証されるので、開発手戻りを極力低減させることができ、車載電装システムの開発効率を向上させることができる。

以下、本発明の具体的な実施形態について、図面を参照しながら詳細に説明する。

［本発明の概要］
本発明は、複数の制御装置（以下、ＥＣＵと表記する。）に跨る統合制御により所定の動作を実行する車載電装システムの開発において、車両メーカが、システム全体の仕様策定及び個々のＥＣＵの詳細仕様の策定を行った後、個々のＥＣＵの実装設計及び試作をサプライヤに要求する前の段階で、仕様漏れなどの設計不具合の有無を事前に検証することで、開発手戻りを極力低減させて効率的な開発が行えるようにするものである。

本発明が適用される開発プロセスは、図１に示すように、要求分析から始まり、車両メーカによるシステム全体の仕様策定（第１の設計段階）、個々のＥＣＵの仕様策定（第２の設計段階）を経て、サプライヤによる個々のＥＣＵの実装設計、試作、サプライヤテストが行われ、その後、車両メーカによる試作機を用いた総合試験、実車評価が行われる、所謂Ｖ字型開発プロセスである。このような開発プロセスにおいて、本発明では、車両メーカでの仕様策定の後に、車載電装システム全体として仕様の確からしさを確認するためのシミュレーション試験を行う。

具体的には、まず、車両メーカによるサプライヤへの要求仕様、つまり、開発対象となる車載電装システムを統合制御する複数のＥＣＵの詳細仕様を、それぞれ所定のシミュレーションツールを用いてモデル化して、各ＥＣＵの動作を各々シミュレートする複数の制御モデルを作成する。そして、作成した複数の制御モデルを用いて、車両全体として仕様の確からしさを確認するために、例えば、特開２００５−１８１１１３号公報にて開示されるようなシミュレーション環境を構築し、このシミュレーション環境上で各制御モデルを接続して車載電装システム全体のシミュレーション試験を行う。このとき、シミュレーションモデルとして個々のＥＣＵの制御仕様をモデル化した制御モデルだけでなく、実際の車両と同等に、各ＥＣＵ間のインターフェースの設計情報（ワイヤハーネスによる接続設計の情報や通信による接続設計の情報）もモデル化し、一車両分のシミュレーション環境を構築する。その際、各制御モデルを作成する際に生成した各ＥＣＵのハーネス設計情報および信号名称変換表、さらには、ＥＣＵ間での通信をモデル化した通信モデル（例えばＣＡＮコミュニケーションモデル）の作成の際に使用するＣＡＮ台帳などを再利用して、複数の制御モデル間での信号の送受信を定義した接続ファイルを作成する。そして、この接続ファイルを用いて、上述したシミュレーション環境でのシミュレーション試験を実現する。

ここで、車載電装システム全体の仕様策定（第１の設計段階）や個々のＥＣＵの詳細仕様の策定（第２の設計段階）において仕様漏れなどの設計不具合が発生している場合、その設計不具合は、上述した複数の制御モデル間での信号の送受信を定義した接続ファイルの不整合として現われる場合がある。また、仕様漏れなどの設計不具合が発生していれば、上述したシミュレーション環境でのシミュレーション試験において、車載電装システムの動作が異常となる。そこで、本発明では、上述したシミュレーション環境を構築するための作業として作成される接続ファイルの整合性、または、上述したシミュレーション環境による車載電装システム全体のシミュレーション試験の試験結果に基づいて、車載電装システム全体の仕様策定（第１の設計段階）や個々のＥＣＵの詳細仕様の策定（第２の設計段階）における仕様漏れなどの設計不具合を検証するようにしている。

［全体構成］
本発明の開発支援装置は、例えば図２に示すように、モデリング開発層コンピュータ１０と、アーキテクチャ開発層コンピュータ２０と、インターフェース変換層コンピュータ３０と、システム検証層コンピュータ４０と、共通データベース５０とをネットワークＮＴで結んだコンピュータシステムにより実現される。このうち、モデリング開発層コンピュータ１０は、複数のＥＣＵの制御モデルを作成するコンピュータであり、アーキテクチャ開発層コンピュータ２０は、通信モデル（例えばＣＡＮコミュニケーションモデル）やハーネス結線モデルなどを作成するコンピュータである。また、インターフェース変換層コンピュータ３０は、接続ファイルを作成するコンピュータであり、システム検証層コンピュータ４０が、上述したシミュレーション環境での車載電装システム全体のシミュレーション試験を行うコンピュータである。このコンピュータシステムでは、以上の各コンピュータがネットワークＮＴを介して共通データベース５０に接続され、この共通データベース５０を用いて各コンピュータ間でデータを共有することにより、仕様策定からシミュレーション試験までの各設計フェーズでの作業を効率的に行えるようになっている。なお、図２に示す構成は、本発明の開発支援装置を実現するコンピュータシステムでの機能構成ごとに単一のコンピュータを割り当てた仮想的なハードウェア構成であり、実際のハードウェア構成としては、コンピュータの数や組み合わせなどは任意に設定可能であり、開発体制に応じて最適な構成を採用すればよい。以下、このコンピュータシステムを構成する各コンピュータの詳細について、具体的な例を挙げながら個別に説明する。

［モデリング開発層コンピュータ］
モデリング開発層コンピュータ１０は、開発対象となる車載電装システムを統合制御する複数のＥＣＵの制御モデルを作成する。具体的には、このモデリング開発層コンピュータ１０では、例えば、Statemate（商品名；I-Logix社製）、MATLAB/Simulink（商品名；Mathworks社製）などの所定のシミュレーションツールを用いて、第２の設計段階で策定された各ＥＣＵの詳細仕様を元に以下の要求をソフトウェア化して、図３に示すようなＥＣＵの制御モデルをＥＣＵごとにそれぞれ作成する。なお、図３は制御モデルの最上位層を表すものであり、左側の破線で囲まれた部分Ｓ１がＥＣＵへの入力信号、右側の破線で囲まれた部分Ｓ２がＥＣＵからの出力信号を示す。また、図３において、中央の破線で囲まれた部分Ｍは、ＥＣＵ本体の動作を模擬し、矢印に従い状態遷移と信号送受信が行われ、遷移先の機能が実行されることを示している。

・トリガとなる入出力信号に依存する状態遷移
ＥＣＵの持つ各機能ごとに、図４に示すように、トリガとなる入出力信号に依存する状態遷移を記述する。なお、図４に示す例では、破線で囲まれた部分Ｔに記載のものが状態遷移のトリガである。また、状態遷移はＸＸＸ／ＹＹＹがフォーマットとなり、ＸＸＸで記述される条件が成立するとＹＹＹで記述されるアクションが実施され、図４の矢印の方向に状態遷移が生じる。

・ＥＣＵの各入出力ピンから入出力される信号の名称、型名、値のとりうる範囲
ＥＣＵに入出力される信号について記述する。制御モデルで取り扱っている信号の名称や型名（データタイプ）は、例えば図５に示す形式となる。なお、上述したStatemate（商品名；I-Logix社製）、MATLAB/Simulink（商品名；Mathworks社製）などのシミュレーションツールでは、使用する信号をこのような専用の管理モジュールで管理しているため、それらの情報を利用することができる。

なお、ＣＡＮなどの通信によりＥＣＵに入出力される信号の名称は、通信モデル（例えばＣＡＮコミュニケーションモデル）の作成の際に使用するＣＡＮ台帳などに記載される信号名と一致させる。また、上記信号がＣＡＮ信号の場合は型名をintとし、モデル側の信号の型がintでない場合は、エラーとする。

ここでは、ＥＣＵの各入出力ピンに対応する電気的信号に信号名称をつけ変数として取り扱っているため、設計情報として、例えば図６に示すようなＥＣＵのピン番号と信号名称との対応表、すなわち、信号名称変換表が生成されることになる。ただし、この段階では複数のＥＣＵ間の繋がりは考慮されないので、信号名称変換表におけるピン番号の欄は記入されずに空欄のままである。また、ここでは、ＥＣＵに入出力される信号が、ＣＡＮなどの通信による信号とワイヤハーネスの信号とで区別されることなく、全てリストアップされる。そして、ワイヤハーネスや通信信号への割付は、アーキテクチャ開発層コンピュータ２０にて実施される。なお、この信号名称変換表は、インターフェース変換層コンピュータ３０が、複数の制御モデル間での信号の送受信を定義した接続ファイルを作成する際に再利用される。

［アーキテクチャ開発層コンピュータ］
アーキテクチャ開発層コンピュータ２０は、開発対象となる車載電装システムを統合制御する複数のＥＣＵ間のインターフェースの設計情報をモデル化し、ＥＣＵ間でのＣＡＮなどの通信を模擬する通信モデルや、ワイヤハーネスによるＥＣＵ間の結線を模擬するハーネス結線モデルを作成する。具体的には、このアーキテクチャ開発層コンピュータ２０では、ＥＣＵ間での通信プロトコルとしてＣＡＮを採用する場合、例えば、CANoe（商品名；Vector社製）などの所定のシミュレーションツールを用いて、第１の設計段階で策定されたＥＣＵ間のＣＡＮによるデータ送受信を摸擬するモデル（ＣＡＮモデル）を作成し、また、例えば、Cabling Designer（商品名；株式会社 図研 製）などの所定のシミュレーションツールを用いて、第１の設計段階で策定されたＥＣＵ間のワイヤハーネスを介した信号送受信を摸擬するモデル（ハーネス結線モデル）を作成する。

・ＣＡＮコミュニケーションモデル
ＣＡＮコミュニケーションモデルは、例えば図７に示すように、車両に搭載される全ＥＣＵのＣＡＮ送受信仕様をモデル化しており、実車と同等の通信状態を摸擬している。なお、図７中のブロック（ノード）が各ＥＣＵを摸擬しており、各ノード間で送受信されるＣＡＮ送受信データの仕様は、図８に示すようなＣＡＮ台帳と呼ばれるメッセージリストに、以下の情報とともに記載される。
１．通信メッセージ名（Message Name）
２．信号名（Signal Name）
３．送信モデル名（Transmitter ECU）
４．受信モデル名（Receiver ECU）
５．その他送信周期、ＩＤなど

つまり、ＣＡＮコミュニケーションモデルにおける各ノードは、以上のようなＣＡＮ台帳と呼ばれるメッセージリストに記載されている情報を元にモデル化されている。なお、このＣＡＮ台帳は、上述したモデリング開発層コンピュータ１０で作成される信号名称変換表と同様、インターフェース変換層コンピュータ３０が接続ファイルを作成する際に再利用される。

・ハーネス結線モデル
ハーネス結線モデルは、以下に示すパラメータを記述して、例えば図９に示すように、ワイヤハーネスによるＥＣＵ間の結線の状態をモデル化しており、実車と同等のワイヤハーネスによる信号送受信を摸擬している。
１．車載ワイヤハーネスのＩＤ（回路番号、WireLabel）
２．接続元の部品名称(PartsName_From)
３．接続先の部品名称(PartsName_To)
４．接続元の部品の接続ピン番号(pinNumber_From)
５．接続先の部品の接続ピン番号(pinNumber_To)
６．部品内部の接続ＩＤ（どのピンと、どのピンとが内部で接続されているかを示すＩＤ）

このハーネス結線モデルでは、所持しているデータを、例えば図１０に示すようなワイヤブラウザ情報と呼ばれる表形式で出力することができる。このワイヤブラウザ情報は、上述した信号名称変換表やＣＡＮ台帳と同様、インターフェース変換層コンピュータ３０が接続ファイルを作成する際に再利用される。

なお、ここではワイヤハーネスにより接続される各ＥＣＵの接続ピンの繋がりが記述されるため、図６に示したようなＥＣＵのピン番号と信号名称との対応関係を示す信号名称変換表において、空欄のままとされていたピン番号の欄に該当するピン番号が記入され、図１１に示すように、ピン番号と信号名との対応付けがなされる。なお、この信号名称変換表において、ＣＡＮ通信でやり取りされる信号については、ピン番号の欄にＣＡＮバスを示すＩＤとして「C」を記入し、複数のＣＡＮバスが車両に存在する場合には、ネットワークを特定するＩＤも添え字として記入する。図１１に示す例では、信号名称「DDDD_dddd」がＣＡＮ通信でやり取りされる信号であり、これに対応するピン番号の欄には、ＣＡＮバスＮｏ．１を示すＩＤ「C1」が記入されている。

［インターフェース変換層コンピュータ］
インターフェース変換層コンピュータ３０は、例えば図１２に概念図で示すように、モデリング開発層コンピュータ１０で作成された信号名称変換表や、アーキテクチャ開発層コンピュータ２０で作成されたワイヤブラウザ情報、ＣＡＮ台帳などを利用して、モデリング開発層コンピュータ１０で作成された各制御モデル間での信号の送受信を定義した接続ファイルを作成する。具体的には、インターフェース変換層コンピュータ３０は、信号生成部３１において、ワイヤブラウザ情報に基づいて複数のＥＣＵ間のワイヤハーネスによる接続状態を確認して部品名称−ピン番号接続対応表を生成し、この部品名称−ピン番号接続対応表と信号名称変換表とから、信号変換部３２において、ワイヤハーネス上を送受信される信号名の変換を行って、ワイヤハーネス経由向けの接続ファイルを作成する。また、インターフェース変換層コンピュータ３０は、信号生成部３３において、ＣＡＮ台帳に基づいて複数のＥＣＵ間でＣＡＮ通信により送受信されるメッセージの内容を確認し、ＣＡＮ通信向けの接続ファイルを作成する。

本発明では、上述したように、車両全体としての仕様の確からしさを確認するために、システム検証層コンピュータ４０において例えば特開２００５−１８１１１３号公報にて開示されるようなシミュレーション環境を構築し、このシミュレーション環境上においてモデリング開発層コンピュータ１０で作成した制御モデルを接続し、複数ＥＣＵに跨る統合制御をシミュレートして車載電装システム全体の動作を試験する。このシミュレーション試験に用いるシミュレーション環境は、以下のような特徴を有している。
１．シミュレーション環境上に存在するデータを任意に格納できる共有エリアと、それを保有するサーバを利用することにより、異なるシミュレーションツールによる制御モデル間のデータの送受信を自由に行うことができる。
２．車両用の通信バス（例えばＣＡＮバス）とワイヤハーネスなど、２系統以上の伝送路をそれぞれ模擬するバスの環境を準備している。
３．クロックサーバと呼ばれる同期モデルから、ＥＣＵを摸擬する各制御モデルに対して同期信号を送信することで、各制御モデルを同期させてシミュレーションを行えるようにしている。
４．制御モデル間の送受信信号による関連付けが、共有エリア上に置かれる接続ファイルと呼ばれる表形式の結線ファイルで管理されている。

以上のように、開発対象となる車載電装システム全体の動作のシミュレーション試験に用いるシミュレーション環境では、当該シミュレーション環境上に存在する全ての制御モデルの入出力信号を、共有エリアへのエリアアクセスにて一括で操作できる。したがって、複数の制御モデル間での信号の送受信を定義した接続ファイルを作成して共有エリアに保存することで、複数のＥＣＵに跨る統合制御をシミュレートするためのシミュレーション環境が構築されることになる。

接続ファイルの内部構成は、例えば図１３に示すような形式とされ、シミュレーション環境上に存在する全ての制御モデルを対象として、各制御モデル間での信号の送受信が、以下のように定義されている。

・指定する共有エリアへ信号を送信する制御モデルを定義
・指定する共有エリアから信号を受信する制御モデルを定義
・指定する共有エリアへ送信される信号名を定義
・指定する共有エリアから受信される信号名を定義
・指定する共有エリアにおいて送受信される信号のデータタイプを定義
・指定する共有エリアのアドレスを定義

この接続ファイルの内容は、ＣＡＮ通信経由とワイヤハーネス経由といったように、２種類以上の通信形態向けの接続情報で構成されており、インターフェース変換層コンピュータ３０は、モデリング開発層コンピュータ１０で作成された信号名称変換表や、アーキテクチャ開発層コンピュータ２０で作成されたワイヤブラウザ情報、ＣＡＮ台帳などを利用して、この接続ファイルを自動的に生成し、正確にかつ短時間のうちにシミュレーション環境を構築できるようにしている。

ここで、インターフェース変換層コンピュータ３０による接続ファイルの作成手順について、ワイヤハーネス経由向けと、ＣＡＮ通信向けとに分けて、具体例を挙げながら詳細に説明する。

（Ａ）ワイヤハーネス経由向けの接続ファイルの作成手順
ワイヤハーネス経由向けの接続ファイルを作成するには、まず、アーキテクチャ開発層コンピュータ２０で作成されたワイヤブラウザ情報（ハーネス結線モデルから出力される表形式データ）を用いて、各ハーネスがどの部品（ＥＣＵや周辺部品）のどのピンから出ているか、また、そのハーネスがどの部品のどのピンに向かって配線されているかの確認が行われる（図１２における信号生成部３１での処理に相当）。例えば、図１４（ａ）に例示するハーネス結線モデルから出力されるワイヤブラウザ情報は図１４（ｂ）のようになり、このワイヤブラウザ情報を用いて以下に示す処理を行うことで、図１５（ａ），（ｂ）に示すような確認後のデータ（部品名称−ピン番号接続対応表）を生成する。

図１６は、ワイヤブラウザ情報を用いて部品名称−ピン番号接続対応表を生成する処理の一般的な手順を示すフローチャートである。まず、ステップＳ１０１において、ハーネス結線モデルから出力されるワイヤブラウザ情報を準備する。このワイヤブラウザ情報は、Ｎ行構成の表形式データシートであるとする。なお、Ｎの値はその対象システムの規模に依存するものである。

次に、ステップＳ１０２において、部品名称及びピン番号レベルで配線の確認を行うに際し、図１４（ａ）に例示したようなハーネス結線モデルの中の周辺部品のモデルについても接続確認を行うか判断を行う。ここでの周辺部品とは、リレーやヒューズなど、ＥＣＵ以外の電気的に内部接続がなされている部品のことを意味する。ここで、周辺部品のモデルについて接続確認を行わないと判断した場合は、ステップＳ１０３において、周辺モデル接続フラグを「０」とする。この場合、ＥＣＵ同士のみに着目した接続関係が最終的に確認されることになる。一方、周辺部品のモデルについても接続確認を行うと判断した場合は、ステップＳ１０４において、周辺モデル接続フラグを「１」とする。この場合には、ＥＣＵ同士だけでなく、ＥＣＵだけでなく周辺部品も含めた接続関係まで確認されることになる。

次に、ステップＳ１０５において、ステップＳ１０１で準備したワイヤブラウザ情報を上位行から読み始める。ここでは１行目から読み始めるべく、行変数ｎを１に初期化する。

次に、ステップＳ１０６において、ワイヤブラウザ情報のｎ行目の部品名称（PartsName_From，PartsName_To）、ピン番号(pinNumbes_From，pinNumbes_To)、接続ＩＤ（接続ID_From，接続ID_To）を読み込み、メモリ上に格納する。

次に、ステップＳ１０７において、ステップＳ１０６で読み込んだ部品名称がグラウンド（GND）であるかどうか判断する。ここで、部品名称がGNDであればその行の経路の確認は終了し、次の行に進む。一方、部品名称がGNDでなければステップＳ１０８に進む。

次に、ステップＳ１０８において、ステップＳ１０２での周辺部品のモデル接続判断に従って処理の分岐を行う。周辺モデル接続フラグが「１」の場合、つまり周辺部品についても接続確認を行う場合、現在確認を行っている行のPartName_From，pinNumber_Fromがそれぞれそのまま接続元の部品名称、ピン番号となるため、ステップＳ１１０へと処理を進める。一方、周辺モデル接続フラグが「０」の場合、つまり周辺部品の接続確認を行わない場合は、ステップＳ１０９へと処理を進める。

周辺モデル接続フラグが「０」でステップＳ１０９に進んだ場合、ステップＳ１０９において、確認している部品に接続ＩＤが付帯されているかどうかの確認を行う。ここで接続ＩＤとは、ＥＣＵ以外の部品（例：コネクタ、ジャンクションボックス、リレー）に付帯されるＩＤであり、任意の部品について同じＩＤが振られている２端子以上の端子は内部で接続されていることを表している。ここでは、接続元の部品について、接続ＩＤ（接続ID_From）の欄が空欄となっているか否かを確認し、接続ID_Fromの欄が空欄となっている、つまり接続元の部品についての接続ＩＤが付帯されていない場合はステップＳ１１０へと処理を進め、接続ID_Fromの欄に何らかの値が記載されている、つまり、接続元の部品についての接続ＩＤが付帯されている場合にはステップ１１１へと処理を進める。

ステップＳ１０８で周辺モデル接続フラグが「１」、或いはステップＳ１０９で接続ID_Fromの欄が空欄となっていると判断されてステップＳ１１０に進んだ場合、ステップＳ１１０において、その行（ｎ行目）のPartsName_From，pinNumber_Fromをそれぞれ接続元の部品名称および、ピン番号と認識し、接続元部品ｎ、接続元ピン番号ｎとする。

一方、ステップＳ１０９で接続ID_Fromの欄に何らかの値が記載されていてステップＳ１１１に進んだ場合、ステップＳ１１１において、ｎ行目以上の接続ID_Toの欄を検索し、ステップＳ１１２において、その接続ID_Fromと同じ値の接続ID_Toが記載されている行が存在するか否かの確認を行う。そして、その接続ID_Fromと同じ値の接続ID_Toが記載されている行がｉ行目に存在したとすると、ｉ行目の接続先部品、ピン番号と接続していることになり、ｎ行目の接続元部品をｉ行目の接続元部品とすべく、ステップＳ１１３において、接続元部品ｉ、接続元ピン番号ｉにｎ行目の接続元部品、接続元ピン番号を格納する。一方、接続ID_Fromと同じ値の接続ID_Toが記載されている行が存在しない場合には、ステップＳ１１４において、ｎ行目の接続ID_Fromをメモリ上に記憶する。

次に、ステップＳ１１５において、ステップＳ１０２での周辺部品のモデル接続判断に従い、再度、処理の分岐を行う。周辺モデル接続フラグが「１」の場合、つまり周辺部品についても接続確認を行う場合、現在確認を行っている行のPartName_To，pinNumber_Toがそれぞれそのまま接続先の部品名称、ピン番号となるため、ステップＳ１１７へと処理を進める。一方、周辺モデル接続フラグが「０」の場合、つまり周辺部品の接続確認を行わない場合は、ステップＳ１１８へと処理を進める。

周辺モデル接続フラグが「０」でステップＳ１１６に進んだ場合、ステップＳ１１６において、接続先の部品について、接続ＩＤ（接続ID_To）の欄が空欄となっているか否かを確認し、接続ID_Toの欄が空欄となっている、つまり接続先の部品についての接続ＩＤが付帯されていない場合はステップＳ１１７へと処理を進め、接続ID_Toの欄に何らかの値が記載されている、つまり、接続先の部品についての接続ＩＤが付帯されている場合にはステップ１１８へと処理を進める。

ステップＳ１１５で周辺モデル接続フラグが「１」、或いはステップＳ１１６で接続ID_Toの欄が空欄となっていると判断されてステップＳ１１７に進んだ場合、ステップＳ１１７において、その行（ｎ行目）のPartsName_To，pinNumber_Toをそれぞれ接続先の部品名称および、ピン番号と認識し、接続先部品ｎ、接続先ピン番号ｎとする。

一方、ステップＳ１１６で接続ID_Toの欄に何らかの値が記載されていてステップＳ１１８に進んだ場合、ステップＳ１１８において、ｎ行目以上の接続ID_Fromの欄を検索し、ステップＳ１１９において、その接続ID_Toと同じ値の接続ID_Fromが記載されている行が存在するか否かの確認を行う。そして、その接続ID_Toと同じ値の接続ID_Fromが記載されている行がｊ行目に存在したとすると、ｊ行目の接続先部品、ピン番号と接続していることになり、ｎ行目の接続先部品をｊ行目の接続先部品とすべく、ステップＳ１２０において、接続先部品ｊ、接続先ピン番号ｊにｎ行目の接続先部品、接続先ピン番号を格納する。一方、接続ID_Toと同じ値の接続ID_Fromが記載されている行が存在しない場合には、ステップＳ１２１において、ｎ行目の接続ID_Toをメモリ上に記憶する。

次に、ステップＳ１２２において、接続元部品ｎ，ｉ，ｊ、接続先部品ｎ，ｉ，ｊ、接続元ピン番号ｎ，ｉ，ｊ、接続先ピン番号ｎ，ｉ，ｊを、それぞれｎ，ｉ，ｊ行目のPartsName_From，PartsName_To，pinNumber_From，pinNumber_Toに書き込み、ステップＳ１２３において、図１５（ａ），（ｂ）に示すような部品名称−ピン番号接続対応表に反映させる。なお、図１５（ａ）は、周辺部品の接続確認を行わない場合に作成される部品名称−ピン番号接続対応表であり、図１５（ｂ）は、周辺部品についても接続確認を行う場合に作成される部品名称−ピン番号接続対応表である。

次に、ステップＳ１２４において、ｎの値をインクリメントして確認する行を下に１行シフトし、次の行の処理に進む。このとき、確認していた行が最終行であったか否かをステップＳ１２５で判断し、最終行でなければ次の行に対して以上の処理を繰り返し、最終行まで繰り返した後、すなわち全てのハーネス接続の確認が終了した段階で、一連の処理を終了する。

以上の手順に従った処理により、例えば、図１４（ａ）のハーネス結線モデルにおける矢印の部分の結線が図１４（ｂ）のワイヤブラウザ情報の太線で囲まれた部分のように記載されているケースにおいて、ＥＣＵ１とＥＣＵ２との接続関係は、周辺部品の接続確認を行わない場合には図１５（ａ）の部品名称−ピン番号接続対応表において太線で囲んだ部分のように記載され、周辺部品についても接続確認を行う場合には図１５（ｂ）の部品名称−ピン番号接続対応表において太線で囲んだ部分のように記載される。なお、この例では、周辺部品の内部接続はピン番号１と４、ピン番号２と５がそれぞれ接続ＩＤにて接続定義されている。

ここで、図１４（ａ）の矢印で示す結線部分に着目して上述した処理の概要を説明すると、以下のようになる。すなわち、まず、図１４（ｂ）に示すワイヤブラウザ情報から、ＥＣＵ１のピン番号１番からＡＡ０１というハーネスが出ていることを確認する。次に、ＡＡ０１のハーネスの先には、周辺部品のピン番号１番が接続されていることを確認する。ここで、周辺部品の接続確認を行わない場合には、周辺部品のピン番号１番が、内部接続ＩＤとして１という値を持っていることを確認しておく。

次に、接続ＩＤが１である項目を図１４（ｂ）のワイヤブラウザ情報から検索し、周辺部品の１番ピンと内部で接続されているのが４番ピンであることを確認する。さらにこの段階で、周辺部品の４番ピンからＡＢ０１というハーネスが出ていることを確認する。

最後に、ＡＢ０１のハーネスの先には、ＥＣＵ２の１番ピンが接続されていることを確認する。以上の結果から、ＥＣＵ１の１番ピンとＥＣＵ２の１番ピンとが周辺部品を内部貫通して接続されていることが導き出され、その接続関係が、図１５（ａ）の部品名称−ピン番号接続対応表において太線で囲んだ部分のように記載される。

また、周辺部品についても接続確認を行う場合には、上述した周辺部品の内部接続ＩＤの確認は行わず、ＡＡ０１のハーネスの先に周辺部品のピン番号１番が接続されていることを確認する。その後、下の行に確認作業を進め、周辺部品のピン番号４番からＡＢ０１というハーネスが出ていることを確認し、ＡＢ０１のハーネスの先には、ＥＣＵ２の１番ピンが接続されていることを確認する。以上の結果から、ＥＣＵ１の１番ピンと周辺部品の１番ピン、周辺部品の４番ピンとＥＣＵ２の１番ピンとがそれぞれ接続されていることが導き出され、その接続関係が、図１５（ｂ）の部品名称−ピン番号接続対応表において太線で囲んだ部分のように記載される。

以上の操作を他のハーネス結線部分に対しても行うことで、ワイヤハーネスによる全ての接続状態を抽出して、図１５（ａ）または図１５（ｂ）に示したような部品名称−ピン番号接続対応表を作成することができる。なお、このような操作は、インターフェース変換層コンピュータ３０において、ソフトウェアにより図１６に示したフローが実行されることで自動で行われ、図１５（ａ）または図１５（ｂ）に示したような部品名称−ピン番号接続対応表が自動的に作成される。

ここまでで、部品名称とピン番号とによるＥＣＵ間の接続関係を抽出できたが、次に、各ピン番号と、その間のハーネス上を送受信される信号名の変換を行う（図１２における信号変換部３２での処理に相当）。この変換を行う際には、モデリング開発層コンピュータ１０で作成された信号名称変換表が用いられる。例えば、図１５（ａ）に例示した部品名称−ピン番号接続対応表から、図１７（ａ）に示す信号名称変換表を用いて信号名の変換を行うことで、図１７（ｂ）に示すようなワイヤハーネス経由向けの接続ファイルが生成される。

図１８は、以上の処理の一般的な手順を示すフローチャートである。まず、ステップＳ２０１において、図１５（ａ）のような部品名称−ピン番号接続対応表と、モデリング開発層コンピュータ１０で作成された図１７（ａ）に示すような信号名称変換表とを準備する。なお、部品名称−ピン番号接続対応表はＮ行構成の表形式データシートであり、信号名称変換表はＭ行構成の表形式データシートであるとする。

次に、ステップＳ２０２において、ステップＳ２０１で準備した部品名称−ピン番号接続対応表を上位行から読み始める。ここでは１行目から読み始めるべく、行変数ｎを１に初期化する。

次に、ステップＳ２０３において、部品名称−ピン番号接続対応表のｎ行目の部品名称（PartsName_From，PartsName_To）、ピン番号(pinNumbes_From，pinNumbes_To)を読み込み、メモリ上に格納する。

次に、ステップＳ２０４において、部品名称−ピン番号接続対応表のｎ行目に対し、ステップＳ２０１で準備した信号名称変換表を適用してピン番号と信号名称との対応をとるべく、Ｍ行構成の信号名称変換表のｍ行目に対し、対応が取れる信号名の検索を行う。ここではｍ＝１と初期化を行い、１行目から検索を進める。

次に、ステップＳ２０５において、信号名称変換表上のｍ行目のデータから、部品名称−ピン番号接続対応表のｎ行目のデータに対応する変換可否を検索するため、信号名称変換表のｍ行目のデータ、partsName，pinNumber，Signal name，Data typeを読み込み、メモリ上に記憶する。

次に、ステップＳ２０６において、送信側及び受信側それぞれの部品名称とピン番号について、部品名称−ピン番号接続対応表のｎ行目のデータと信号名称変換表上のｍ行目のデータ間でデータが一致するか否かの判断を行う。そして、これらのデータが一致していれば、ステップＳ２０７において、信号名称変換表上のｍ行目のpartsNameを、部品名称−ピン番号接続対応表の送信／受信の一致した方のモデル名ｎとして書き込む。また、信号名称変換表上のｍ行目のSignal name、Data typeについても同様に、部品名称−ピン番号接続対応表の送信／受信の一致した方のデータ名ｎ、データタイプｎとして書き込む。

一方、送信側及び受信側それぞれの部品名称とピン番号について、部品名称−ピン番号接続対応表のｎ行目のデータと信号名称変換表上のｍ行目のデータが一致しない場合、ステップＳ２０８において、その不一致が、信号名称変換表上のｍ行目のピン番号の欄にＣＡＮ信号のフラグであるＣが記載されていることによるものか否かを判断する。そして、信号名称変換表上のｍ行目のピン番号の欄にフラグＣが記載されていることによるデータ不一致であれば、次のステップＳ２０９に処理を進め、信号名称変換表上のｍ行目のピン番号の欄にフラグＣが記載されていることによるデータ不一致でなければ、ステップＳ２１３へと処理を移行する。

ステップＳ２０９では、その行の送信側／受信側データについて、Data typeがintとなっているか否かか判断する。ここで、送信側／受信側データのData typeがintとなっていれば、ステップＳ２０７に進んで、信号名称変換表上のｍ行目のpartsName、Signal name、Data typeを、それぞれ部品名称−ピン番号接続対応表の送信／受信の一致した方のモデル名ｎ、データ名ｎ、データタイプｎとして、それぞれメモリ上に書き込む。一方、送信側／受信側データのData typeがintとなっていなければステップＳ２１０に進み、ステップＳ２１０においてエラー処理を行う。その後、ステップＳ２１１において、処理を終了するか否かのユーザによる判断に応じて、終了の場合はエラーメッセージを出力して終了する。一方、終了しない場合は、ステップＳ２１２において、エラー行をロギングして、次の行に処理を進める。このステップＳ２１２でロギングしたデータは、全処理が終了した後に出力される。

本エラーは、設計段階においてモデリング開発層コンピュータ１０で作成した信号名称変換表において、ＣＡＮ信号であると指定した信号のデータタイプに誤りがある場合に発生するものである。したがって、このエラーを検出することで、ＥＣＵ間でのＣＡＮ通信による信号送受信エラーが発生することを事前（システム検証前）に検出することができる。また、本エラーは、同じく設計段階における信号名称変換表作成時に、int型でないハーネス送受信信号に対し、ＣＡＮ信号であるとするＣフラグを割り当てた際に発生するエラーでもある。したがって、このエラーを検出することで、ワイヤハーネスとＣＡＮバスとの間の物理的に実現しないバス同士の結線ミスを事前（システム検証前）に検出することができる。

ステップＳ２０８において部品名称−ピン番号接続対応表と信号名称変換表との間のデータ不一致がフラグＣの記載によるものでないと判断されてステップＳ２１３に進んだ場合、ステップＳ２１３において、ｍの値をインクリメントして、信号名称変換表の次の行に対して、対応が取れる信号名の検索を進める。このとき、それまでの処理の対象としていた行が最終行であったか否かをステップＳ２１４で判断し、最終行でなければ信号名称変換表の次の行に対してステップＳ２０５以降の処理を繰り返す。そして、最終行まで検索を進めても一致が確認できない場合はステップＳ２１５に進み、ステップＳ２１５においてエラー処理を行う。その後、ステップＳ２１６において、処理を終了するか否かのユーザによる判断に応じて、終了の場合はエラーメッセージを出力して終了する。一方、終了しない場合は、ステップＳ２１７において、エラー行をロギングして、次の行に処理を進める。このステップＳ２１７でロギングしたデータは、全処理が終了した後に出力される。

本エラーは、部品名称およびピン番号でハーネス結線状態を確認した結果に対し、各ピン番号に対し対応する信号名がない場合に発生するエラーである。このエラーは、下記の１〜３の要因により生じうるエラーである。
１．実車ではハーネス結線が行われているにも関わらず、制御モデルでは接続がなされない。
２．制御仕様をモデル化した制御モデルに必要な信号数に対し、ハーネスピン数が過多となり無駄部品が生じている。
３．信号名称変換表にピン番号を記載する際に、ピン番号を誤記している。

これらの要因のうち１の要因で発生するエラーについては、このエラーを検出することで、制御モデルの不具合を検出できるため、その他のモデル化された箇所に対して影響がないかトラブルシュートを行うきっかけとすることができる。

また、２の要因で発生するエラーについては、このエラーを検出することで、ハーネス結線の結線過剰によるコスト問題を解決することができる。

また、３の要因で発生するエラーについては、このエラーを検出することで、ピン番号誤記による結線不具合を検出することができ、ハーネス結線間違いを未然（システム検証前）に防ぐことができる。

次に、ステップＳ２１８において、以上の処理によりステップＳ２０７においてメモリ上に書き込まれた、送信側モデル名ｎ、受信側モデル名ｎ、送信データ名ｎ、受信データ名ｎ、データタイプｎを、それぞれ接続ファイルのｎ行目の送信側モデル名、受信側モデル名、送信データ名、信データ名、データタイプに書き込み、ステップＳ２１９において、図１７（ｂ）に示すような接続ファイルに反映させる。なお、共有データエリア、エリアアドレスには任意の値を書き込む。

次に、ステップＳ２２０において、ｎの値をインクリメントして部品名称−ピン番号接続対応表の信号変換を行う行を下に１行シフトし、次の行の処理に進む。このとき、処理の対象としていた行が最終行であったか否かをステップＳ２２１で判断し、最終行でなければ次の行に対して以上の処理を繰り返し、部品名称−ピン番号接続対応表の最終行まで処理が終了した段階で、一連の処理を終了する。この結果として、ワイヤハーネス経由向けのＮ行構成の接続ファイルが生成される。

以上の手順に従った処理により、例えば、図１５（ａ）の部品名称−ピン番号接続対応表において太線で囲んだ部分のＥＣＵ１とＥＣＵ２との間のハーネス結線に関し、図１７（ａ）の信号名称変換表において太線で囲んだ行と対応させることで信号名の変換が行われ、図１７（ｂ）の接続ファイルにおいて太線で囲んだ行のように記載される。

ここで、図１５（ａ）のＥＣＵ１とＥＣＵ２との間のハーネス結線に着目して上述した処理の概要を説明すると、以下のようになる。すなわち、まず、図１５（ａ）に示す部品名称−ピン番号接続対応表に記載されているＥＣＵ１の１番ピンとＥＣＵ２の１番ピンとの接続関係について、図１７（ａ）の信号名称変換表から、ＥＣＵ１の１番ピンについて記載されている行と、ＥＣＵ２の１番ピンについて記載されている行とを検索する。そして、ＥＣＵ１の１番ピンについて記載されている行の信号名称とデータタイプ、ＥＣＵ２の１番ピンについて記載されている業の信号名称とデータタイプとをそれぞれ確認する。そして、ＥＣＵ１の１番ピンに対応する信号名称を接続ファイルの送信データ名、ＥＣＵ２の１番ピンに対応する信号名称を接続ファイルの受信データ名に書き込み、さらに、ＥＣＵ１の１番ピンとＥＣＵ２の１番ピンとに対応するデータタイプを接続ファイルのデータタイプに書き込む。

以上の操作を全てのＥＣＵ間のハーネス結線に対して行うことで、制御モデル間のワイヤハーネスを介した信号の送受信を定義した、図１７（ｂ）のような接続ファイルが作成されることになり、この接続ファイルを用いることで、上述した実車相当のシミュレーション環境でＥＣＵ間のワイヤハーネスを介した信号の送受信をシミュレートすることが可能となる。なお、以上のような操作は、インターフェース変換層コンピュータ３０において、ソフトウェアにより図１８に示したフローが実行されることで自動で行われ、図１７（ｂ）に示したような接続ファイルが自動的に作成される。また、このインターフェース変換層コンピュータ３０による接続ファイルの作成時には、何らかの要因で適切な信号変換が行われない場合、すなわち接続ファイルに不整合が生じる場合には、エラー処理が行われて処理が終了するため、ハーネス結線に関する設計不具合を事前に検証できるという利点も有している。

（Ｂ）ＣＡＮ通信向けの接続ファイルの作成手順
次に、ＣＡＮ通信向けの接続ファイルを作成する手順を説明する。ＣＡＮ通信向けの接続ファイルの作成には、アーキテクチャ開発層コンピュータ２０でＣＡＮコミュニケーションモデルを作成する際に使用したＣＡＮ台帳（図８参照）を用いる。すなわち、インターフェース変換層コンピュータ３０では、図１２に示した信号生成部３３での処理として、例えば、図８に例示したＣＡＮ台帳を用いて、モデリング開発層コンピュータ１０で作成された制御モデル間の通信による信号の送受信を定義して、図１９に示すようなＣＡＮ通信向けの接続ファイルを作成する。

図２０は、ＣＡＮ通信向けの接続ファイルを作成する処理の一般的な手順を示すフローチャートである。まず、ステップＳ３０１において、アーキテクチャ開発層コンピュータ２０でＣＡＮコミュニケーションモデルを作成する際に使用したＣＡＮ台帳を準備する。このＣＡＮ台帳は、Ｎ行構成の表形式データシートであるとする。なお、Ｎの値はその対象システムの規模に依存するものである。

次に、ステップＳ３０２において、ステップＳ３０１で準備したＣＡＮ台帳を上位行から読み始める。ここでは１行目から読み始めるべく、行変数ｎを１に初期化する。

次に、ステップＳ３０３において、ＣＡＮ台帳のｎ行目から、通信メッセージ名（CAN Message Name）、信号名（Signal Name）、送信モデル名（Transmitter ECU）、受信モデル名（Receiver ECU）を読み込み、メモリ上に格納する。

次に、ステップＳ３０４において、ステップＳ３０３でメモリ上に書き込まれた、
次に、ステップＳ２１８において、以上の処理によりステップＳ２０７においてメモリ上に書き込まれた、Transmitter ECU，Receiver ECU，Message Name_SignalName(Message NameとSignalNameとを結合した名称) を、それぞれ接続ファイルのｎ行目の送信側モデル名、受信側モデル名、送信データ名に書き込み、ステップＳ３０５において、図１９に示すような接続ファイルに反映させる。なお、接続ファイルｎ行目の受信データ名には送信データ名と同じものを書き込み、また、共有データエリア、エリアアドレスには任意の値を書き込む。

次に、ステップＳ３０６において、ｎの値をインクリメントしてＣＡＮ台帳のデータを読み込む行を下に１行シフトし、次の行の処理に進む。このとき、処理の対象としていた行が最終行であったか否かをステップＳ３０７で判断し、最終行でなければ次の行に対して以上の処理を繰り返し行う。そして、以上の処理をＣＡＮ台帳の最終行まで繰り返した段階で、一連の処理を終了する。この結果として、ＣＡＮ通信向けのＮ行構成の接続ファイルが生成される。

ここで、図８に示したＣＡＮ台帳を用いて図１９のような接続ファイルを作成する場合を例に挙げて上述した処理の概要を説明すると、以下のようになる。すなわち、まず、図８に示すＣＡＮ台帳から、送信側モデル名としてTransmitter ECU、受信側モデル名としてReceiver ECUをそれぞれ確認する。さらにＣＡＮ台帳から、それらの間で送受信される信号名としてMessage NameとSignal Nameとを確認する。ここで、これらのモデル間で送受信される信号名が、例えば、Message Name=AAAA、Signal Name=aaaaの場合、送信信号名および受信信号名は、これらを結合してAAAA_aaaaとする。そして、これらのデータを、ＣＡＮ通信向けの接続ファイルの該当する行に書き込む。なお、ＣＡＮ信号の場合、データタイプはint（３２ビット整数型）とする。

以上の操作を全てのＥＣＵ間におけるＣＡＮ通信に対して行うことで、制御モデル間のＣＡＮ通信による信号の送受信を定義した、図１９のような接続ファイルが作成されることになり、この接続ファイルを用いることで、上述した実車相当のシミュレーション環境でＥＣＵ間のＣＡＮ通信によるメッセージ交換をシミュレートすることが可能となる。なお、以上のような操作は、インターフェース変換層コンピュータ３０において、ソフトウェアにより図２０に示したフローが実行されることで自動で行われ、図１９に示したような接続ファイルが自動的に作成される。したがって、上述した実車相当のシミュレーション環境の構築を極めて効率よく且つ短時間で行うことが可能となる。

以上、インターフェース変換層コンピュータ３０によるワイヤハーネス経由向け及びＣＡＮ通信向けの接続ファイルの作成について説明したが、この接続ファイルの作成は、例えば、FlexRay（Daimler Chrysler AGの登録商標）プロトコルに従った通信や、Bluetoothなどによる無線通信等、他の通信形態でのＥＣＵ間の通信についても応用することが可能であり、各通信形態ごとに、送信モデル、受信モデル、信号名、信号の型を同様の方法で抽出することにより接続ファイルを作成して、上述した実車相当のシミュレーション環境を構築することができる。

［システム検証層コンピュータ］
システム検証層コンピュータ４０は、開発対象となる車載電装システムの車両全体として仕様の確からしさを確認するために、例えば図２１に示すようなシミュレーション環境上で、車載電装システム全体のシミュレーション試験を行う。具体的には、このシステム検証層コンピュータ４０では、アーキテクチャ開発層コンピュータ２０で作成されたＣＡＮコミュニケーションモデル（図２１中の通信モデルＡ，Ｂ，Ｃ，Ｄ）やハーネス結線モデルを反映させてシミュレーション環境を構築し、このシミュレーション環境上にモデリング開発層コンピュータ１０で作成された複数の制御モデル（図２１中の制御モデルＡ，Ｂ，Ｃ，Ｄ）を接続し、更に、インターフェース変換層コンピュータ３０で作成された接続ファイルを用いて、車載電装システム全体のシミュレーション試験を行う。

このシステム検証層コンピュータ４０によるシミュレーション試験により検証される内容には、以下のようなものがある。
・２つ以上のＥＣＵに跨る通信メッセージの整合確認
・通信プロトコルの確認
・２つ以上のＥＣＵに跨る統合制御により実現される機能の整合確認

ここで、以上のようなシステム検証層コンピュータ４０により実施されるシミュレーション試験の簡単な例として、ヘッドランプ点灯機能の検証を行う場合を例に挙げて、図２１を用いて具体的に説明する。この例では、シミュレーション環境の構成として、ヘッドランプスイッチＯＮの信号を読み取るＥＣＵの制御モデルＡ、ヘッドランプを実際に点灯させるアクチュエータを駆動するＥＣＵの制御モデルＢ、その他の制御モデルＣ，ＤをＣＡＮバスおよびハーネス送受信用バスの２系統のバスに接続した環境を構成する。各ＥＣＵに相当する制御モデルは、各ＥＣＵの機能が仕様通りにモデル化されているものとする。また、このシミュレーション環境では、上述した各制御モデルのほかに、車両モデルＶＭと計測用マシンＭＭとが接続されている。車両モデルＶＭは、車両運動のシミュレーションを行って、車両の状態を表す各種信号を各制御モデルに送信するものであり、実車に搭載されている各種センサに相当するものである。また、計測用マシンＭＭは、ユーザがシミュレーション試験のための操作入力を行ったり、制御モデルの制御に応じた動作の確認を行ったりするためのユーザインターフェースであり、実車に搭載されている各種操作スイッチ類やアクチュエータ類に相当するものである。

（１）先ず、ユーザが、計測用マシンＭＭを用いてヘッドランプスイッチＯＮに相当する操作入力を行うと、計測用マシンＭＭがヘッドランプスイッチＯＮ信号を出力する（実車では、ドライバがヘッドランプスイッチをＯＮし、センサがその情報を読み取ることに等しい）。このとき、制御モデルＡは、ハーネス送受信用バス経由での制御指令待ちの状態にある。また、このシミュレーション試験を行っている間、車両モデルＶＭは、必要に応じて車両運動のシミュレーションを行い、車両の状態を表す信号を、ハーネス送受信用バス経由で各制御モデルＡ，Ｂ，Ｃ，Ｄに対して随時送信する。

（２）計測用マシンＭＭから出力されたヘッドランプスイッチＯＮ信号は、ハーネス送受信用バス経由で制御モデルＡに送信される。そして、制御モデルＡがこのヘッドランプスイッチＯＮ信号を受信する。

（３）制御モデルＡは、計測用マシンＭＭからのヘッドランプスイッチＯＮ信号を受信すると、ヘッドランプの点灯指示があったことを判定し、ヘッドランプリクエスト信号を生成する。そして、生成したヘッドランプリクエスト信号を、通信モデルＡに伝送する。

（４）通信モデルＡは、制御モデルＡからのヘッドランプリクエスト信号を受信すると、このヘッドランプリクエスト信号をＣＡＮのプロトコルに合致するデータ形式に変換する。そして、変換したデータをＣＡＮバス上に送出する。このとき、通信モデルＢは、ＣＡＮバス経由でのデータ待ちの状態にあり、通信モデルＡからＣＡＮバス上にデータが送出されると、これを受信する。

（５）通信モデルＢは、ＣＡＮバス経由で通信モデルＡから送信されたデータを受信すると、受信したデータを制御モデルＢで扱えるデータ形式に変換する。そして変換したデータを制御モデルＢへと伝送する。

（６）制御モデルＢは、通信モデルＢからのデータを受信すると、ヘッドランプの点灯指示があったことを判定し、ヘッドランプを点灯させるアクチュエータへの駆動制御信号を生成する。そして、生成したアクチュエータ駆動制御信号を、ハーネス送受信用バスを介して計測用マシンＭＭに送信する（実車では、制御モデルＢに対応するＥＣＵがヘッドライトのアクチュエータを動かすことに等しい）。

（７）計測用マシンＭＭは、制御モデルＢからハーネス送受信用バス経由で送信されたアクチュエータ駆動制御信号を受信すると、例えばヘッドランプが点灯している様子をグラフィカルに表示することにより、制御モデルＡ，Ｂ間のデータ通信やこれら制御モデルＡ，Ｂによる統合制御が正常に行われていることをユーザに報知する。これにより、ユーザは、実際の車両において、ヘッドランプ点灯機能が正常に作動することを確認することができる。

システム検証層コンピュータ４０では、以上のフローで車載電装システムのシミュレーション試験が行われるが、このように２系統のバスを用いることで、実車両を模擬した環境で評価を行うことができる。また、図２１には図示していないが、シミュレーション環境上にクロックサーバを設置して、このクロックサーバから各制御モデルＡ，Ｂ，Ｃ，Ｄに対して同期クロックを送信するようにすれば、上記（１）〜（７）のステップは１サイクルとして同期の取れたシミュレーションとなる。

また、以上のような車載電装システムのシミュレーション試験により、設計段階における仕様漏れなどの設計不具合が発生していれば、シミュレーションの結果が異常となるので、その不具合を検出することが可能となる。例えば、上述したヘッドランプ点灯機能のシミュレーション試験を例に挙げると、シミュレーション結果の異常としては、以下のようなものが挙げられる。

・計測用マシンＭＭからのヘッドライトＯＮ操作に対し、応答がない。

このようなシミュレーション結果の異常が発生した場合には、その原因として以下の原因が考えられ、次のような仕様不備が検討される。

１．計測用マシンＭＭ、制御モデルＡ，Ｂ及び、通信モデルＡ，Ｂのうち１つ以上のモデルから信号が出力されていない。このシミュレーション環境は、信号名称変換表等の設計情報を利用し、アーキテクチャ設計で設計された結線通りに各モデルが接続されているため、この不具合の発生原因は結線仕様の不具合にあり、アーキテクチャ設計における仕様漏れが検討されることになる。

２．ハーネス送受信信号同士のデータタイプが一致していない。この不具合の発生原因としては、制御モデルから生成される信号リスト（信号名称変換表）の不備、つまりは制御モデルの信号管理の不備が考えられ、個々のＥＣＵの詳細設計における仕様漏れが検討されることになる。

３．各制御モデルのＯＮ／ＯＦＦ判断ロジック仕様に不具合がある。この場合は、制御モデルＡ，Ｂの構造自体に不備があると考えられ、各制御モデルＡ，Ｂの構造についての検証が行われることになる。

・ヘッドライトＯＮ時において、計測用マシンＭＭからのヘッドライトＯＮ操作に対し、ＯＦＦしてしまう。

このようなシミュレーション結果の異常が発生した場合には、その原因としては各制御モデルにおけるＯＮ／ＯＦＦ判断ロジック仕様の不具合が考えられ、各制御モデルＡ，Ｂの構造についての検証が行われることになる。

システム検証層コンピュータ４０では、上述したシミュレーション環境における車載電装システムのシミュレーション試験を行うことで、以上のような設計段階における仕様漏れなどの設計不具合を検出することができるとともに、トラブルシュートを行うことができる。したがって、このようなシミュレーション試験は、接続して初めてわかる複数のＥＣＵ間の統合制御の機能や結線仕様について、事前に評価を行うという観点から非常に有効な手法である。

［共通データベース］
本発明の開発支援装置を実現するコンピュータシステムでは、上述したように、モデリング開発層コンピュータ１０、アーキテクチャ開発層コンピュータ２０、インターフェース変換層コンピュータ３０、システム検証層コンピュータ４０の各コンピュータが、ネットワークＮＴを介して共通データベース５０に接続されており、各設計フェーズで使用するモデルや評価結果等のデータを、この共通データベース５０を用いて管理できるようにしている。

共通データベース５０は、例えば図２２に示すように、コンピュータシステムのモデリング開発層コンピュータ１０、アーキテクチャ開発層コンピュータ２０、インターフェース変換層コンピュータ３０、システム検証層コンピュータ４０にそれぞれ対応させて、モデル格納エリア５１、インターフェース設計情報格納エリア５２、接続ファイル格納エリア５３、システム検証結果格納エリア５４を有している。

モデル格納エリア５１には、各ＥＣＵ設計者が設計した仕様に従ったＥＣＵの制御モデル、すなわち、モデリング開発層コンピュータ１０によりＥＣＵの要求仕様をモデル化して作成した制御モデルが格納される。また、インターフェース設計情報格納エリア５２には、アーキテクチャ設計者が設計したシステム全体としての仕様に従ったインターフェース設計情報、すなわち、アーキテクチャ開発層コンピュータ２０でのＣＡＮコミュニケーションモデルの作成に使用したＣＡＮ台帳や、アーキテクチャ開発層コンピュータ２０で作成したハーネス結線モデルから出力されるワイヤブラウザ情報が格納される。

また、接続ファイル格納エリア５３には、インターフェース変換層コンピュータ３０で作成された接続ファイルが格納される。また、システム検証結果格納エリア５４には、システム検証層コンピュータ４０でのシミュレーション試験によるシステム検証結果が格納される。

以上の構造を有する共通データベース５０では、システム検証層コンピュータ４０で上述したシミュレーション試験を行った場合には、モデリング開発層コンピュータ１０やアーキテクチャ開発層コンピュータ２０から、モデル格納エリア５１やインターフェース設計情報格納エリアだけでなく、システム検証結果格納エリア５４にもアクセス可能とされる。これにより、システム検証層コンピュータ４０でのシミュレーション試験によるシステム検証結果として仕様漏れなどの設計不具合が検出された場合には、その検証結果を各ＥＣＵ設計者やアーキテクチャ設計者にフィードバックして、設計の不具合を解消させることができる。

また、この共通データベース５０では、インターフェース変換層コンピュータ３０で作成する接続ファイルに不整合が生じて、エラーが発生した場合には、モデリング開発層コンピュータ１０やアーキテクチャ開発層コンピュータ２０から、モデル格納エリア５１やインターフェース設計情報格納エリアだけでなく、接続ファイル格納エリア５３にもアクセス可能とされる。これにより、設計段階での仕様漏れなどの設計不具合により接続ファイルの不整合が生じた場合にも、その結果を各ＥＣＵ設計者やアーキテクチャ設計者にフィードバックして、設計の不具合を解消させることができる。

なお、共通データベース５０に格納されている全ての設計情報は、システム検証層コンピュータ４０でのシミュレーション試験により開発対象となる車載電装システムの動作が正常となることが確認されて次の開発段階（実装設計工程）への移行が判断された後は、権限者による解除が無い限り変更できなくなるように、アクセスに制限を設けることが望ましい。

［実施形態の効果］
以上、具体的な例を挙げながら詳細に説明したように、本発明を適用して構成されるコンピュータシステムでは、モデリング開発層コンピュータ１０で開発対象となる車載電装システムを統合制御する複数のＥＣＵの制御モデルを作成するとともに、これら複数の制御モデルを実車と同等のシミュレーション環境に接続して実車相当のシミュレーション試験を行うために、アーキテクチャ開発層コンピュータ２０でハーネス結線モデルやＣＡＮコミュニケーションモデルを作成し、これらハーネス結線モデルやＣＡＮコミュニケーションモデルを作成するための設計情報（第１の設計情報）であるワイヤブラウザ情報やＣＡＮ台帳と、制御モデルを作成して得られる設計情報（第２の設計情報）である信号名称変換表とを用いて、インターフェース変換層コンピュータ３０において複数の制御モデル間での信号の送受信を定義した接続ファイルを作成する。そして、システム検証層コンピュータ４０において、モデリング開発層コンピュータ１０で作成された複数の制御モデルをシミュレーション環境上に接続し、インターフェース変換層コンピュータ３０で作成された接続ファイルを用いて、車載電装システム全体のシミュレーション試験を行ってその動作を検証する。この際、本発明を適用したコンピュータシステムでは、インターフェース変換層コンピュータ３０で接続ファイルが正常に作成されたか否か、或いは、システム検証層コンピュータ４０でのシミュレーション試験の結果が正常か否かにより、車載電装システム全体の仕様策定（第１の設計段階）や個々のＥＣＵの詳細仕様の策定（第２の設計段階）における仕様漏れなどの設計不具合を検証するようにしている。そして、設計不具合があればそれを各設計段階にフィードバックできるようにしている。

したがって、本発明を適用したコンピュータシステムを利用して車載電装システムの開発を行うようにすれば、車両メーカでの仕様策定の後、サプライヤへ個別のＥＣＵの実装設計を依頼する前の段階で仕様漏れなどの設計不具合を検出することができ、開発手戻りを極力低減させて、車載電装システムの開発効率を向上させることができる。

また、本発明を適用したコンピュータシステムによれば、ワイヤブラウザ情報やＣＡＮ台帳、信号名称変換表を用いて作成される接続ファイルの整合性から、設計段階における仕様漏れなどの設計不具合が検証されるので、個々のＥＣＵの設計検証だけでなく、ワイヤハーネスの結線情報やＣＡＮなどの通信接続情報を含めたきめ細かな設計検証が可能となる。さらに、接続ファイルは、ワイヤブラウザ情報やＣＡＮ台帳、信号名称変換表から自動的に作成されるので、この接続ファイルの整合性から設計不具合を検証することで、設計検証を効率よく且つ短時間で行うことができる。

また、本発明を適用したコンピュータシステムによれば、各設計フェーズでの作業を行うためのモデリング開発層コンピュータ１０、アーキテクチャ開発層コンピュータ２０、インターフェース変換層コンピュータ３０、システム検証層コンピュータ４０が、それぞれネットワークＮＴを介して共通データベース５０に接続されており、共通データベース５０を用いて各コンピュータ間でデータを共有することができるので、仕様策定からシミュレーション試験までの各設計フェーズでの作業を効率的に行うことができる。

なお、以上説明したコンピュータシステムは、本発明を適用した一実施形態を例示したものであり、本発明の技術的範囲は、以上の実施形態の説明で開示した内容に限定されるものではなく、これらの開示から容易に導き得る様々な代替技術も含まれることは勿論である。例えば、上述したコンピュータシステムは、車両メーカ内での閉じたシステムを前提とした構成となっているが、例えば、サプライヤが実装設計の作業を行うための実装設計層コンピュータなどもコンピュータシステムに組み込むようにしてもよい。この場合には、システム検証が完了して設計不具合がないことが確認されたＥＣＵの制御モデルのみを実装設計層コンピュータが取り込めるようにすることで、サプライヤでの実装設計工程などの下流工程での作業効率向上や、開発品質の確保を実現することができる。

本発明が適用される開発プロセスの概要を示す図である。 本発明を適用して構成されるコンピュータシステムの概要を示すシステム構成図である。 ＥＣＵの動作をシミュレートする制御モデルを示す模式図である。 ＥＣＵの制御モデルにおける入出力信号に対する状態遷移を説明する図である。 ＥＣＵの制御モデルで取り扱われる信号の名称や型名を説明する図である。 ＥＣＵの制御モデル作成時に生成される信号名称変換表を示す図である。 ＣＡＮコミュニケーションモデルの概要を示す模式図である。 ＣＡＮコミュニケーションモデルの作成に使用されるＣＡＮ台帳を示す図である。 ハーネス結線モデルの一例を示す模式図である。 ハーネス結線モデルから出力されるワイヤブラウザ情報を示す図である。 ハーネス結線モデル作成時に更新された信号名称変換表を示す図である。 インターフェース変換層コンピュータによる処理の概要を説明する図である。 ワイヤブラウザ情報とＣＡＮ台帳と信号名称変換表とから作成される接続ファイルを示す図である。 ワイヤハーネス経由向けの接続ファイルを作成する手順を説明するための図であり、（ａ）はハーネス結線モデルの一例を示す図、（ｂ）はワイヤブラウザ情報の一例を示す図である。 ワイヤハーネス経由向けの接続ファイルを作成する手順を説明するための図であり、（ａ）は周辺部品の接続確認を行わない場合に作成される部品名称−ピン番号接続対応表を示す図、（ｂ）は周辺部品についても接続確認を行う場合に作成される部品名称−ピン番号接続対応表を示す図である。 ワイヤブラウザ情報から部品名称−ピン番号接続対応表を作成する一般的な手順を示すフローチャートである。 ワイヤハーネス経由向けの接続ファイルを作成する手順を説明するための図であり、（ａ）は信号名称変換表の一例を示す図、（ｂ）は作成される接続ファイルの一例を示す図である。 部品名称−ピン番号接続対応表と信号名称変換表とから接続ファイルを作成する一般的な手順を示すフローチャートである。 ＣＡＮ通信向けの接続ファイルを作成する手順を説明するための図であり、作成される接続ファイルの一例を示す図である。 ＣＡＮ台帳からＣＡＮ通信向けの接続ファイルを作成する一般的な手順を示すフローチャートである。 車載電装システム全体のシミュレーション試験を行うためのシミュレーション環境を示す模式図である。 共通データベースの構成を示す図である。

符号の説明

１０ モデリング開発層コンピュータ
２０ アーキテクチャ開発層コンピュータ
３０ インターフェース変換層コンピュータ
３１ 信号生成部
３２ 信号変換部
３３ 信号生成部
４０ システム検証層コンピュータ
５０ 共通データベース

Claims (7)

1. 複数の制御装置に跨る統合制御により所定の動作を実行する車載電装システムであって、システム全体の仕様を策定する第１の設計段階と、当該第１の設計段階で策定された仕様に従って個々の制御装置毎の詳細仕様を策定する第２の設計段階とを経て開発される車載電装システムの開発を支援する開発支援装置において、
   前記複数の制御装置の動作を各々シミュレートする複数の制御モデルを作成する制御モデル作成手段と、
   前記第１の設計段階で得られる第１の設計情報と、前記第２の設計段階で得られる第２の設計情報とに基づいて、前記複数の制御モデル間での信号の送受信を定義した接続ファイルを作成する接続ファイル作成手段と、
   前記制御モデル作成手段で作成される複数の制御モデルと前記接続ファイル作成手段で作成される接続ファイルとを用いて前記複数の制御装置に跨る統合制御をシミュレートして、前記車載電装システム全体の動作を試験するシステム動作試験手段とを備え、
   前記接続ファイル作成手段により作成される接続ファイルの整合性、または、前記システム動作試験手段による試験結果に基づいて、前記第１の設計段階、または、前記第２の設計段階における設計不具合の有無を検証することを特徴とする車載電装システムの開発支援装置。
2. 前記第１の設計情報には、少なくとも、前記複数の制御装置間のワイヤハーネスによる接続状態を示す情報が含まれ、前記第２の設計情報には、少なくとも、前記個々の制御装置毎のピンと当該ピンを用いて入出力される信号との対応関係を示す情報が含まれていることを特徴とする請求項１に記載の車載電装システムの開発支援装置。
3. 前記接続ファイル作成手段は、前記第１の設計情報と前記第２の設計情報とに基づいて前記制御モデル間のワイヤハーネスを介した信号の送受信を定義して、前記接続ファイルを作成することを特徴とする請求項２に記載の車載電装システムの開発支援装置。
4. 前記第１の設計情報には、少なくとも、前記複数の制御装置間で通信により送受信されるメッセージの内容を示す情報が含まれていることを特徴とする請求項１乃至３の何れかに記載の車載電装システムの開発支援装置。
5. 前記接続ファイル作成手段は、前記第１の設計情報に基づいて前記制御モデル間の通信による信号の送受信を定義して、前記接続ファイルを作成することを特徴とする請求項４に記載の車載電装システムの開発支援装置。
6. 前記制御モデル作成手段と、前記接続ファイル作成手段と、前記システム動作試験手段とが、複数のコンピュータとこれら複数のコンピュータからアクセス可能なデータベースとを用いて実現されていることを特徴とする請求項１乃至５の何れかに記載の車載電装システムの開発支援装置。
7. 複数の制御装置に跨る統合制御により所定の動作を実行する車載電装システムであって、システム全体の仕様を策定する第１の設計段階と、当該第１の設計段階で策定された仕様に従って個々の制御装置毎の詳細仕様を策定する第２の設計段階とを経て開発される車載電装システムの設計不具合の有無を検証する設計不具合検証方法であって、
   前記複数の制御装置の動作を各々シミュレートする複数の制御モデルを作成する制御モデル作成ステップと、
   前記第１の設計段階で得られる第１の設計情報と、前記第２の設計段階で得られる第２の設計情報とに基づいて、前記複数の制御モデル間での信号の送受信を定義した接続ファイルを作成する接続ファイル作成ステップと、
   前記制御モデル作成ステップで作成される複数の制御モデルと前記接続ファイル作成ステップで作成される接続ファイルとを用いて前記複数の制御装置に跨る統合制御をシミュレートして、前記車載電装システム全体の動作を試験するシステム動作試験ステップとを有し、
   前記接続ファイル作成ステップで作成される接続ファイルの整合性、または、前記システム動作試験ステップでの試験結果に基づいて、前記第１の設計段階、または、前記第２の設計段階における設計不具合の有無を検証することを特徴とする車載電装システムの設計不具合検証方法。

Images