JP2016224646A - ログ保存条件生成装置、ログ保存条件生成方法 - Google Patents

Abstract

【課題】ソフトウエアモジュールの性質に応じてログ情報の取得条件を設定できる。【解決手段】本発明にかかるログ保存条件生成装置は、自動車用電子制御装置、すなわちＥＣＵに含まれる複数のソフトウエアモジュールのログ情報を保存する条件、すなわちログ取得条件を生成する。ログ保存条件生成装置は、複数のソフトウエアモジュールの性質、すなわち性質表、および取得ルールが入力される入力部と、ソフトウエアモジュールの性質および保存ルールに基づき、各々のソフトウエアモジュールに関するログ情報を取得するタイミング、および取得する情報を決定する条件生成部、すなわち生成部とを備える。【選択図】図２

Description

本発明は、ログ保存条件生成装置、およびログ保存条件生成方法に関する。

近年、組込みソフトウェアの大規模化、複雑化が進んでおり、既存のソフトウエアモジュールを組合せて機能を実現することが一般に行われる。自動車などの車両制御装置に用いられるＥｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ（ＥＣＵ）も同様であり、ＥＣＵでは、複数のベンダーが開発した品質レベルの異なるソフトウエアモジュールが混在する構成が多くみられる。ＥＣＵに不具合が発生した際に、その原因を究明するためにログ情報を保存することが有用であるが、ＥＣＵが使用できるリソースは非常に限定的なので、多くの情報をログとして出力することができない。
特許文献１には、正常データと異常データとを比較して相違集合を算出し、障害発生条件を算出できるかを判断し、障害発生条件の算出の可否に基づき取得する入出力信号を変化させる発明が開示されている。

特開２００９−２２２４５３号公報

特許文献１に記載の発明では、ソフトウエアモジュールの性質に応じたログ取得の設定ができない。

本発明にかかるログ保存条件生成装置は、自動車用電子制御装置に含まれる複数のソフトウエアモジュールのログ情報を保存する条件を生成するログ保存条件生成装置である。本発明にかかるログ保存条件生成装置は、複数のソフトウエアモジュールの性質、および保存ルールが入力される入力部と、ソフトウエアモジュールの性質および保存ルールに基づき、各々のソフトウエアモジュールに関するログ情報を取得するタイミング、および取得する情報を決定する条件生成部とを備える。
本発明にかかるソフトウエアモジュールのログ情報を保存する条件をコンピュータが生成するログ保存条件生成方法は、自動車用電子制御装置を構成する複数のソフトウエアモジュールのログ情報を保存する条件を生成する方法である。本発明にかかるソフトウエアモジュールに関するログ情報を保存する条件を生成する方法は、入力される、ベンダー、品質レベル、検証観点の少なくとも１つを含むソフトウエアモジュールの性質、および入力される保存ルールに基づき、複数のソフトウエアモジュールに関するログ情報を取得するタイミング、および取得する情報をコンピュータが決定する。

本発明によれば、ソフトウエアモジュールの性質に応じてログ情報の取得条件を設定できる。

ＥＣＵの構成を示すブロック図 ログ保存条件生成装置およびＥＣＵの概念図 性質表の一例を示す図 ルールの一例を示す図 ログ取得条件の一例を示す図 保存されるログ情報の一例を示す図 第２の実施の形態に係るログ保存条件生成装置およびＥＣＵの概念図 ソフトウエアモジュール同士の接続、および機能ブロックの構成の一例を示す図 接続表の一例を示す図 第２の実施の形態における生成部の動作を示すフローチャート 第３の実施の形態におけるＥＣＵの構成を示すブロック図 第３の実施の形態に係るログ保存条件生成装置およびＥＣＵの概念図

（第１の実施の形態）
以下、図１〜６を参照して、本発明によるログ保存条件生成装置の第１の実施の形態を説明する。

図１は、車両に搭載される自動車用電子制御装置、すなわちＥＣＵの構成を示すブロック図である。車両には複数のＥＣＵが搭載されるが、図１には１つのＥＣＵのみを記載している。ＥＣＵ１００は、ＣＰＵ１０、ＲＡＭ１１、およびフラッシュメモリ１２から構成される。フラッシュメモリ１２は、当該ＥＣＵ１００のログ情報が保存されるログ保存領域１３を含む。フラッシュメモリ１２には、ＥＣＵ１００を動作させるプログラム１４が保存される。プログラム１４は、ＲＡＭ１１に展開されてＣＰＵ１０により実行される。このプログラム１４は、後述するＡ〜Ｔの２０のソフトウエアモジュール（以下、モジュール）から構成される。たとえば、プログラム１４は１つの実行可能ファイルであり、Ａ〜Ｔの各々のソフトウエアモジュールは、オブジェクトファイルである。ソフトウエアモジュールは相互に通信を行い、情報の授受や関数の起動などを行う。以下では、仮想的な通信路であるノードによりモジュール同士が接続されているとする。

図２は、第１の実施の形態に係るログ保存条件生成装置およびＥＣＵ１００の概念図である。
図２では、プログラム１４を構成するソフトウエアモジュールＡ〜Ｔのうち、一部のみを図示している。いずれのソフトウエアモジュールも構成が同じなので、以下ではソフトウエアモジュールＡを用いて説明する。それぞれのソフトウエアモジュールが取得するログ情報は、ログ保存領域１３に保存される。

ソフトウエアモジュールＡは、ログ取得条件１１１と、ログ管理関数１１２と、その他のプログラム１１３とを含む。ログ管理関数１１２は、ログ取得条件１１１の記述に従ってログ情報を取得し、ログ保存領域１３に保存する。たとえば、ログ管理関数１１２のソースコードにはログ情報を取得する条件は記載されておらず、ログ管理関数１１２のソースコードとログ取得条件１１１に記載された情報とを結合させてからソフトウエアモジュールＡがコンパイルされる。これにより、オブジェクトファイルであるソフトウエアモジュールＡは、ログ取得条件１１１の記述に従ってログ情報を取得し、ログ保存領域１３に保存する。
ログ管理関数１１２にはログ取得条件１１１が含まれていないため、以下のような利点を有する。たとえばログ管理関数１１２を含むモジュールを制作委託する場合に、モジュールの制作を委託する段階ではログ情報を取得する条件を網羅的に示せばよく、ログ情報を取得する条件を確定させる必要がない。

ログ取得条件１１１は、後述するログ保存条件生成装置１０２により生成される。
ログ保存条件生成装置１０２は、入力部１０２ａおよび不図示のＣＰＵ、ＲＯＭ、ＲＡＭを備える計算機である。ＣＰＵは、ＲＯＭに保存されている後述する動作を行うプログラムをＲＡＭに展開して実行する。生成部１０２ｂは、このプログラムの機能を機能ブロックとして表したものである。入力部１０２ａは、通信インタフェースまたはキーボードであり、後述する性質表１０３および取得ルール１０４が入力される。

性質表１０３は、ソフトウエアモジュールの性質を示した一覧表であり、開発ベンダー、品質レベル、検証観点から構成される。「開発ベンダー」は、少なくとも自社か否かを判断できる情報である。「品質レベル」は、品質を表す指標であり、たとえば当該モジュールが適合するＩＥＣ６１５０８の安全度水準に基づき決定される。「検証観点」は、当該モジュールにおいて検証が完了しているテスト観点、すなわち正常に動作することが確認されたテスト項目である。

図３に性質表１０３の一例を示す。図３には、ソフトウエアモジュールＡ〜Ｔについて、開発ベンダー、品質レベル、検証観点の一覧が示されている。「開発ベンダー」は、ソフトウエアモジュールの製造が、自社であるα社、または自社ではないβ社、γ社のいずれであるかが示される。「品質レベル」は、ＩＥＣ６１５０８の安全度水準が３以上の場合には「高い」、それ以外の場合は「低い」と示される。「検証観点」は、形式検証、状態遷移試験、負荷試験、タイミング試験、のうち検証が完了しているテスト観点には○の印が示される。性質表１０３には、ソフトウエアモジュールＡは、自社であるα社により開発され、品質レベルは低く、タイミング試験による検証が行われていることが示されている。

取得ルール１０４は、ソフトウエアモジュールの性質に基づきログ取得条件１１１を生成する条件の一覧である。取得ルール１０４により、たとえばベンダーが自社でない場合、品質レベルが低い場合、および検証観点が少ない場合の少なくとも１つを満たす場合に、ログ情報を取得する頻度を増加させる、またはログ情報として取得する情報を増加させる旨が規定される。
図４に取得ルール１０４の一例を示す。取得ルール１０４は、ログ取得条件と、ソフトウエアモジュールの性質との組み合わせから構成される。
ログ取得条件は、タイミングと、取得内容と、消去条件とから構成される。

タイミングは、ログ情報を取得するタイミングを示すものであり、たとえば「エラー発生時」、「一周期ごと」、「変数の変化時」の３つがある。「エラー発生時」は、ソフトウエアモジュールが組み込まれているＥＣＵに、何らかのエラーが発生するたびにログ情報が取得されることを示す。「一周期ごと」は、ＥＣＵの所定の制御周期ごとにログ情報が取得されることを示す。「変数の変化時」は、当該ソフトウエアモジュールが保持する変数が変化した時にログ情報が取得されることを示す。

取得内容は、ログ情報として取得する内容を示すものであり、たとえば「タイムスタンプ」、「処理内容」、「変数の値」の３つがある。「タイムスタンプ」とは、時間に関する情報を示すものであり、現在時刻または稼働開始からの経過秒数を示す。「処理内容」とは、ソフトウエアモジュールが最後に実行した処理の内容を示すものであり、たとえば“モジュールＣを呼びだした”旨や“モジュールＤに値５を出力した”旨である。「変数の値」とは、当該ソフトウエアモジュールが保持する変数の名称とその値の組合せを示す。

（動作例）
ログ保存条件生成装置１０２の動作例を説明する。
ログ保存条件生成装置１０２の生成部１０２ｂは、入力部１０２ａに性質表１０３および取得ルール１０４が入力されると、以下の動作を行う。すなわち、生成部１０２ｂは、性質表１０３に記載されたモジュールごとに取得ルール１０４に記載されたいずれかのソフトウエアモジュールの性質に該当するか否かを判断する。生成部１０２ｂは、該当する性質があるとそのモジュールのログ取得条件１１１として出力する。生成部１０２ｂは、該当する性質がない場合はログ取得条件１１１をブランクにする。この場合、そのモジュールのログ情報は取得されない。

図５は、図３に示した性質表１０３と図４に示した取得ルール１０４に基づいて、生成部１０２ｂが生成したソフトウエアモジュールＡ〜Ｔのログ取得条件１１１を示す。たとえばソフトウエアモジュールＡは、自社かつ品質が低いというソフトウエアモジュールの性質に該当するので、変数が変化するたびに、タイムスタンプ、および変数の値が取得され、１年後に消去される。
ログ管理関数１１２は、ログ取得条件１１１の記述に従ってログ情報を取得し、ログ保存領域１３に保存する。ログ保存領域１３には、ログ管理関数１１２が取得したログ情報に加えて、ログ情報の通し番号、およびログ情報を取得したモジュールの名称が保存される。

図６は、ログ保存領域１３に保存されるログ情報の一例を示す図である。図６は、図５に示すログ取得条件に対応しており、モジュールＡはタイムスタンプと変数の値が保存され、モジュールＢはタイムスタンプ、処理内容、および変数の値が保存され、モジュールＣは処理内容が保存される。

上述した実施の形態によれば、次の作用効果が得られる。
（１）本発明にかかるログ保存条件生成装置１０２は、自動車用電子制御装置、すなわちＥＣＵ１００に含まれる複数のソフトウエアモジュールのログ情報を保存する条件、すなわちログ取得条件１１１を生成する。ログ保存条件生成装置１０２は、複数のソフトウエアモジュールの性質、すなわち性質表１０３、および取得ルール１０４が入力される入力部１０２ａと、ソフトウエアモジュールの性質および保存ルールに基づき、各々のソフトウエアモジュールに関するログ情報を取得するタイミング、および取得する情報を決定する条件生成部、すなわち生成部１０２とを備える。
ログ保存条件生成装置１０２をこのように構成したので、ソフトウエアモジュールの性質に応じてログ情報の取得条件を設定できる。
複数のベンダーにより開発されたソフトウエアモジュールが混在する場合に、最も品質レベルの低いモジュールに水準を合せて全モジュールのログを出力すると、過剰にログが出力される。しかし、ログ保存条件生成装置１０２はソフトウエアモジュールの性質に応じて、それぞれのログ情報の取得条件を設定できるので、このような問題が生じない。
ログ保存条件生成装置１０２は、オペレータによる操作を必要とせずにログ取得条件１１１を生成することができる。

（２）性質表１０３に記載されるソフトウエアモジュールの性質とは、ベンダー、品質レベル、検証観点の少なくとも１つを含む。
そのため生成部１０２ｂは、モジュールのベンダーが自社であるか否か、品質レベルの高低、および検証観点に基づき、ログ情報の取得条件を設定できる。
（３）品質レベルとは、ＩＥＣ規格６１５０８における安全度水準である。
そのため、客観的な基準を用いて品質レベルを評価することができる。

（変形例１）
第１の実施の形態では、入力部１０２ａから性質表１０３および取得ルール１０４が入力された。しかし、性質表１０３および取得ルール１０４のいずれか一方が、ログ保存条件生成装置１０２のＲＯＭに保存されていてもよい。
（変形例２）
第１の実施の形態では、性質表１０３の「品質レベル」は、ＩＥＣ６１５０８の安全度水準に基づき決定された。しかし、他の基準に基づいて決定されてもよい。

（第２の実施の形態）
図７〜１０を参照して、本発明によるログ保存条件生成装置の第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、一部のソフトウエアモジュールのみがログ管理関数を備える点で、第１の実施の形態と異なる。

図７は、第２の実施の形態に係るログ保存条件生成装置１０２およびＥＣＵ１００の概念図である。ログ保存条件生成装置１０２には、性質表１０３および取得ルール１０４に加えて、後述する接続表１０５も入力される。
以下では、ある機能を実現する複数のソフトウエアモジュールのグループを機能ブロックと呼ぶ。いずれのソフトウエアモジュールも、同じ機能ブロック内の他のソフトウエアモジュールの要求に応じて処理内容や変数の値を送信する。ログ保存条件生成装置１０２が決定したソフトウエアモジュールのみログ管理関数１１２を備える。

図８に、ソフトウエアモジュール同士の接続、および機能ブロックの構成の一例を示す。前述のとおり、仮想的な通信路であるノードによりモジュール同士が接続される。図８に示すソフトウエアモジュールの名称は、一文字目が属する機能ブロックの識別子、２文字目が機能ブロック内の識別子である。たとえば、機能ブロックＡは、３つのソフトウエアモジュールＡａ、Ａｂ、Ａｃから構成される。図８にはＡ〜Ｇの７つの機能ブロックが記載される。

モジュールＡａは、同一機能ブロック内のモジュールＡｂおよびモジュールＡｂとノードにより接続される。モジュールＡａは、機能ブロックＢに属するモジュールＢａ、およびインタフェースとノードにより接続される。インタフェースは、機能ブロック同士の接続を提供する。すなわちモジュールＡａは、インタフェースを通じて機能ブロックＢ〜Ｇと接続される。
ログ保存条件生成装置１０２には、性質表１０３および取得ルール１０４に加えて、モジュール間の接続および機能ブロックの構成を示す接続表１０５が入力される。

図９は、図８に示したモジュール同士の接続、および機能ブロックの構成に対応する接続表１０５である。図９では機能ブロックＡ〜Ｂに属するモジュールの接続、すなわちモジュール間のノードの有無が○印の有無で表現される。図９では機能ブロックＣ〜Ｇに属するモジュールとの接続の記載は省略されている。

ログ保存条件生成装置１０２は、接続表１０５に基づき、機能ブロックごとにログ管理関数１１２を備えるモジュールを決定する。機能ブロック内における接続されるノードが最も多いモジュールがログ管理関数１１２を備えるモジュールとして決定され、接続されるノード数が同一であれば、インタフェースに接続されるモジュールが優先される。たとえば、機能ブロックＡでは、モジュールＡａに接続される同一ブロック内のノード数が２、モジュールＡｂおよびモジュールＡｃは１なので、モジュールＡａがログ管理関数１１２を備えるモジュールとして決定される。機能ブロックＢでは、モジュールＢｂおよびモジュールＢｃのいずれも接続されるノード数が２なので、インタフェースに接続されるモジュールＢｂがログ管理関数１１２を備えるモジュールとして決定される。

ログ保存条件生成装置１０２は、決定したログ管理関数１１２を備えるモジュールにそのモジュールが属する機能ブロックの全てのモジュールのログ取得条件を設定する。これにより、図８の例ではモジュールＡａのログ管理関数１１２は、モジュールＡａ、Ａｂ、Ａｃのログ情報を取得し、ログ保存領域１３に保存する。ログ保存領域１３に保存されるログ情報は、第１の実施の形態と同様である。

（フローチャート）
ログ保存条件生成装置１０２の生成部１０２ｂの動作を、フローチャートを用いて説明する。以下に説明する各ステップの実行主体は、ログ保存条件生成装置１０２のＣＰＵである。ログ保存条件生成装置１０２は、入力部１０２ａに性質表１０３、取得ルール１０４、および接続表１０５が入力されると動作を開始する。
図１０は、第２の実施の形態における生成部１０２ｂの動作を示すフローチャートである。

ステップＳ２０１において、全てのモジュールのログ取得条件を算出し、ステップＳ２０２に進む。具体的な算出方法は、第１の実施の形態で説明したとおりである。
ステップＳ２０２において、機能グループごとに、同一グループ内で接続数が最大のモジュールを算出し、ステップＳ２０３に進む。
ステップＳ２０３において、機能グループごとに、ステップＳ２０２において算出した同一グループ内で接続数が最大のモジュールに、ログ管理関数１１２を備えさせステップＳ２０４に進む。
ステップＳ２０４において、ステップＳ２０３においてログ管理関数１１２を備えさせたモジュールに、そのモジュールが属する機能ブロック内の全てのモジュールに対応するログ取得条件を設定し、図１０に示すフローチャートを終了する。

上述した実施の形態によれば、次の作用効果が得られる。
（１）入力部１０２ａには、ノードにより接続される複数のソフトウエアモジュール同士の接続関係が接続表１０５として入力される。生成部１０２ｂは、ソフトウエアモジュールに接続されるノードの数に基づき、ログを取得するソフトウエアモジュールを決定する。
そのため、生成部１０２ｂが同一機能グループ内で多くのノードが接続されたモジュールをログ取得関数を備えるモジュールとして決定することで、効率よくログ情報を収集することができる。

（２）入力部１０２ａには、複数のソフトウエアモジュールが機能に基づきグループ分けされた情報が接続表１０５として入力される。生成部１０２ｂは、他のグループ、すなわち他の機能ブロックに属するソフトウエアモジュールと接続されるノードの数に基づき、ログを取得するソフトウエアモジュールを決定する。
他の機能ブロックに属するモジュールと接続されるモジュールには多くの情報が集まるので、そのモジュールにおいてログ情報を取得することにより、効率よくログ情報を収集することができる。

（第２の実施の形態の変形例１）
第１の実施の形態では、当該モジュールの性質に基づきログ取得条件が決定された。しかし、隣接するモジュールの性質に基づきログ取得条件が決定されてもよい。
たとえば、取得ルール１０４が隣接するモジュールのベンダーが自社であるか否かを判断条件の１つに含んでもよい。

（第２の実施の形態の変形例２）
上記、第２の実施の形態の変形例１において、さらに、性質表１０３にモジュールの性質として、同じ機能ブロック内の他のモジュールからの要求に応じた処理内容や変数の値の送信の可否（以下、ログ情報転送の可否）、およびログ管理関数１１２の具備の可否が設定されていてもよい。
ログ情報転送が不可能なモジュールに関するログ情報は、当該モジュール自身がログ管理関数１１２を備える場合か、他のモジュールから間接的に得られる場合に得られる。たとえば、ログ情報転送が不可能なモジュールＡから、ログ情報転送が可能なモジュールＢに変数が出力された場合に、以下のように間接的に情報が得られる。すなわち、モジュールＡのログ情報として出力した変数を得ることはできないが、モジュールＢのログ情報として入力された変数を得ることにより、間接的にモジュールＡが出力した変数が間接的に得られる。

このような場合に、取得ルール１０４には、隣接するモジュールの性質が、ログ管理関数１１２を備えることが不可能であり、なおかつ、同じ機能ブロック内の他のモジュールからの要求に応じた処理内容や変数の値の送信が不可能であれば、以下の動作を行う旨を規定してもよい。すなわち、当該モジュールがその隣接するモジュールとの間で送受信する変数の値、および動作指令を取得する。
この変形例によれば、モジュールのソースコードが不明であり、ライブラリ形式など変更が不可能な形式で提供された場合に、そのモジュールに関するログ情報を取得することができる。

（第２の実施の形態の変形例３）
第２の実施の形態では、プログラム１４がＡ〜Ｇの７つの機能ブロックから構成された。しかし、プログラム１４を構成する機能ブロックの数はこれに限定されない。たとえば、プログラム１４が１つの機能ブロックのみから構成され、プログラム１４が１つのログ管理関数１１２のみを備えてもよい。

（第３の実施の形態）
図１１〜１２を参照して、本発明によるログ保存条件生成装置の第３の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、ログ取得条件がモジュールに組み込まれない点で、第１の実施の形態と異なる。

図１１は、第３の実施の形態における、ある１つのＥＣＵ１００の構成を示すブロック図である。ＥＣＵ１００のフラッシュメモリ１２には、ログ取得条件１１１が保存される。ただし、ログ取得条件１１１は、全てのモジュールに関するログ取得条件がまとめて１つのファイルに保存されてもよいし、モジュールごとに個別のファイルに保存されてもよい。
図１２は、第３の実施の形態に係るログ保存条件生成装置およびＥＣＵ１００の概念図である。ログ管理関数１１２は、フラッシュメモリ１２に保存されるログ取得条件１１１の記載に基づき動作する。すなわち、プログラム１４にはログ取得条件１１１が組み込まれていない。

そのため、ログ取得条件１１１が変更された場合でも、オブジェクトファイルであるモジュールを再構成する必要がなく、そのまま利用することができる。一方、第１の実施の形態では、ログ管理関数１１２のソースコードとログ取得条件１１１に記載された情報とが結合されてからオブジェクトファイルであるモジュールがコンパイルされる。そのため、第１の実施の形態ではログ取得条件１１１が変更されると、モジュールを再度コンパイルする必要があった。第３の実施の形態では、再度のコンパイルが不要であり、モジュールを簡便に再利用することができる。

上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。
上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１３ … ログ保存領域
１００ … ＥＣＵ
１０２ … ログ保存条件生成装置
１０２ … 生成部
１０２ａ … 入力部
１０２ｂ … 生成部
１０３ … 性質表
１０４ … 取得ルール
１０５ … 接続表
１１１ … ログ取得条件
１１２ … ログ管理関数

Claims (6)

1. 自動車用電子制御装置に含まれる複数のソフトウエアモジュールのログ情報を保存する条件を生成するログ保存条件生成装置であって、
   前記複数のソフトウエアモジュールの性質、および保存ルールが入力される入力部と、
   前記ソフトウエアモジュールの性質および前記保存ルールに基づき、各々の前記ソフトウエアモジュールに関するログ情報を取得するタイミング、および取得する情報を決定する条件生成部とを備えるログ保存条件生成装置。
2. 請求項１に記載のログ保存条件生成装置において、
   前記ソフトウエアモジュールの性質とは、
   ベンダー、品質レベル、検証観点の少なくとも１つを含み、
   前記条件生成部は、ソフトウエアモジュールの性質、および前記保存ルールに基づき、
   ベンダーが自社でない場合、品質レベルが低い場合、および検証観点が少ない場合の少なくとも１つを満たす場合に、
   ログ情報を取得する頻度を増加させる、またはログ情報として取得する情報を増加させる、ログ保存条件生成装置。
3. 請求項２に記載のログ保存条件生成装置において、
   前記品質レベルとは、ＩＥＣ規格６１５０８における安全度水準であるログ保存条件生成装置。
4. 請求項１に記載のログ保存条件生成装置において、
   前記入力部には、ノードにより接続される前記複数のソフトウエアモジュール同士の接続関係がさらに入力され、
   前記条件生成部は、前記ソフトウエアモジュールに接続されるノードの数に基づき、ログ情報を取得するソフトウエアモジュールを決定するログ保存条件生成装置。
5. 請求項４に記載のログ保存条件生成装置において、
   前記入力部には、前記複数のソフトウエアモジュールが機能に基づきグループ分けされた情報がさらに入力され、
   前記条件生成部は、他の前記グループに属するソフトウエアモジュールと接続されるノードの数に基づき、ログ情報を取得するソフトウエアモジュールを決定するログ保存条件生成装置。
6. 自動車用電子制御装置を構成する複数のソフトウエアモジュールのログ情報を保存する条件をコンピュータが生成するログ保存条件生成方法であって、
   前記複数のソフトウエアモジュールの性質、および保存ルールがコンピュータに入力されるステップと、
   入力された前記複数のソフトウエアモジュールの性質および入力された前記保存ルールに基づき、前記複数のソフトウエアモジュールに関するログ情報を取得するタイミング、および取得する情報をコンピュータが生成するステップと、を実行するログ保存条件生成方法。
   
   

Images