JP6228324B2 - 解析装置及び解析方法 - Google Patents

解析装置及び解析方法 Download PDF

Info

Publication number
JP6228324B2
JP6228324B2 JP2016564647A JP2016564647A JP6228324B2 JP 6228324 B2 JP6228324 B2 JP 6228324B2 JP 2016564647 A JP2016564647 A JP 2016564647A JP 2016564647 A JP2016564647 A JP 2016564647A JP 6228324 B2 JP6228324 B2 JP 6228324B2
Authority
JP
Japan
Prior art keywords
event
subsystems
target system
behavior
events
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2016564647A
Other languages
English (en)
Other versions
JPWO2016157298A1 (ja
Inventor
尚志 畑
尚志 畑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Renesas Electronics Corp
Original Assignee
Renesas Electronics Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renesas Electronics Corp filed Critical Renesas Electronics Corp
Publication of JPWO2016157298A1 publication Critical patent/JPWO2016157298A1/ja
Application granted granted Critical
Publication of JP6228324B2 publication Critical patent/JP6228324B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3447—Performance evaluation by modeling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/004—Error avoidance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Biomedical Technology (AREA)
  • Health & Medical Sciences (AREA)
  • Mathematical Physics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明は、解析装置及び解析方法に関し、特に複数のサブシステムを含んで構成されるシステムの動作解析を支援するための解析装置及び解析方法に好適に利用できるものである。
分散型組込みシステムは大規模、複雑化している。しかし、システムの評価はプロトコルアナライザの目視チェックなど人手に頼る部分が多く、サポート工数やエラー箇所の特定、性能評価などの工数が大きくなっている。
特許文献１には、イベントログの検索条件を簡易に設定することができ、イベントログを検索条件と関連付けて表示する、イベントログ解析支援装置が開示されている。複数のサーバが出力したメッセージログ（文字列）に対して正規表現でフィルタリングを行う。正規表現は複数設定可能で、フィルタリング結果は時系列にグラフィカルに表示される。
特許文献２には、複数の制御モジュールが分散して実装されるシステムにおいて、システム全体でのソフトウェアの分析を容易にする技術が開示されている。システム全体で共通の時間をカウントするタイマをそれぞれの複数の制御モジュールに導入し、複数の制御モジュールはそれぞれのタイマの時刻を用いたタイムスタンプを付加したイベントログを出力する。
特開２００５−１４１６６３号公報 特開２０１５−０３５１５８号公報
特許文献１及び２について本発明者が検討した結果、以下のような新たな課題があることがわかった。
特許文献１に開示されるイベントログ解析支援装置では、正規表現の文字列マッチングによるフィルタリングしかできない。そのため「イベントＡが発生した後にイベントＢが発生する」というようなイベントの発生順序を指定するなどの設定が難しい。その結果、イベントログの評価は、フィルタリングされた結果を人が目視確認によって行うことになる。特許文献１に開示されるイベントログ解析支援装置において、イベントログの評価を自動化するためには、期待値が必要になる。期待値とログを比較して動作状況を把握するためである。期待値との比較は検証の段階では有効だが、エラーが発生したときの原因箇所の特定のような用途に適用する事は難しい。
特許文献２に開示されるシステムでは、分散している複数の制御システムで個々に発生するイベントについても、発生した時系列（前後関係）を正確に把握することができるため、システム全体のイベントログの評価を正確に行なうことができる点で有効であるが、この場合も人が目視確認によって行うこととなる。
今後、システムが大規模化、複雑化するに伴って、人手による目視確認は、より困難となる。
このような課題を解決するための手段を以下に説明するが、その他の課題と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。
一実施の形態によれば、下記の通りである。
すなわち、ターゲットシステムの動作を解析するための解析装置であって、ターゲットシステムの動作をモデル化した挙動モデルを有し、前記ターゲットシステムを動作させた時に発生するイベントを時系列で記録したログが入力され、前記挙動モデルを静的に解析することによって求められる発生順序に従ったイベント列を、前記ログに時系列で記録された複数のイベントから探索する。
前記一実施の形態によって得られる効果を簡単に説明すれば下記のとおりである。
すなわち、ターゲットシステムが大規模化、複雑化した場合にも、解析やデバッグに要する工数を抑えることができる。
図１は、実施形態１の解析装置110を含む評価システムの構成例を示すブロック図である。 図２は、ターゲットシステムの構成例を示す説明図である。 図３は、挙動モデルの構成例を示す説明図である。 図４は、解析全体の流れを示す説明図である。 図５は、サブシステムＡ（Sys_A）から出力されるログの例を示す説明図である。 図６は、サブシステムＢ（Sys_B）から出力されるログの例を示す説明図である。 図７は、サブシステムＡとＢ（Sys_AとSys_B）から出力されるログを統合したターゲットシステム全体のシステムログの例を示す説明図である。 図８は、統合されたシステムログを模式的に示す説明図である。 図９は、挙動モデルにおける、挙動シナリオのタスクの関連付けの例を示す説明図である。 図１０は、構造モデルを記述したソースコードの例を示す説明図である。 図１１は、インターフェース宣言を記述したソースコードの例を示す説明図である。 図１２は、サブシステムＡ（Sys_A）の挙動シナリオを記述したソースコードの例を示す説明図である。 図１３は、サブシステムＢ（Sys_B）の挙動シナリオを記述したソースコードの例を示す説明図である。 図１４は、ルータ（Router）の挙動シナリオを記述したソースコードの例を示す説明図である。 図１５は、システムログを探索するフローの例を示すフローチャートである。 図１６は、システムログを探索する動作の一例を模式的に示す説明図である。 図１７は、ルータ（Router）の挙動シナリオを含む構造モデルの一例を模式的に示す説明図である。 図１８は、動作の推定を行う場合のシステムログの一例を模式的に示す説明図である。 図１９は、階層的に構成された挙動モデルの一例を模式的に示す説明図である。 図２０は、複数の制御ユニットが車載ネットワークに接続される、ターゲットシステムの一構成例を示す、模式的ブロック図である。
実施の形態について詳述する。なお、発明を実施するための形態を説明するための全図において、同一の機能を有する要素には同一の符号を付して、その繰り返しの説明を省略する。
〔実施形態１〕
本実施形態１に係る、ターゲットシステムの動作を解析するための解析装置は、ターゲットシステムの動作をモデル化した挙動モデルを有し、ターゲットシステムを動作させた時に発生するイベントを時系列で記録したログが入力され、挙動モデルを静的に解析することによって求められる発生順序に従ったイベント列を、ログに時系列で記録された複数のイベントから探索する。
本実施形態１に係る解析方法は、ターゲットシステムの動作を、電子計算機を利用して解析するための解析方法であって、電子計算機の記憶装置に格納される挙動モデルと、電子計算機によって実行されることによって解析動作を行う解析プログラムとを有する。挙動モデルは、ターゲットシステムの動作をモデル化したものである。解析プログラムによる解析動作では、挙動モデルを静的に解析することによって、期待される発生順序に従ったイベント列を抽出する。さらに、ターゲットシステムを動作させた時に発生するイベントを時系列で記録したログが入力され、このログの中に抽出されたイベント列が存在するかどうかが探索される。
ここで、ターゲットシステムとは、解析の対象であるシステムを指し、ハードウェアであってもソフトウェアであっても、ハードウェアとソフトウェアが協調して動作するシステムであってもよい。また、本願で言う「解析」とは、開発過程におけるデバッグや、不良解析などの、正常ではない動作（挙動）の原因を追究するための「解析」には限定されず、正常な動作（挙動）と一致するか否かを二者択一的に判断する「検証」を含む。
これにより、ターゲットシステムが大規模化、複雑化した場合にも、解析やデバッグに要する工数を抑えることができる。ターゲットシステムを動作させた時に発生するイベントを時系列で記録したログ（システムログ）には、実際に発生したイベントの発生順序が記録されている。しかし、この発生順序が、イベントを発生させたタスク相互間で行われた、例えばメッセージやパラメータの送受の結果等の、規定された因果関係に則ったものか、単なる偶然によるものかを区別することができる情報は含まれていない。本実施形態１の解析装置及び方法では、期待される発生順序に従ったイベント列を抽出し、システムログに記録された複数のイベントの中から合致するものを探索する。合致するイベント列が発見されれば、そのイベント列を発生させた一連のタスクが正常に実行されたことが期待されるなどの一定の解析結果を得て、残りのイベント列の解析に進むことができる。そのため、ターゲットシステムが大規模化、複雑化し、そのためにシステムログに膨大な数のイベントが記録されるような場合にも、解析やデバッグに要する工数を抑えることができる。
これは特に、ターゲットシステムが複数のサブシステムを含んで構成される場合に有効である。その場合には、挙動モデルは、複数のサブシステムそれぞれの挙動を表す複数の挙動シナリオと、複数のサブシステム相互間の接続関係を表す構成モデルとを含み、それぞれの挙動シナリオには、対応するサブシステムが実行するタスクと、そのタスクによって発生するイベントとが記述される。システムログには、ターゲットシステムを動作させたときに、複数のサブシステムから発生されるイベントと、当該イベントの発生時間をターゲットシステム全体に共通の時間によって示すタイムスタンプとが記録される。解析装置または解析方法では、挙動モデルから、所定の開始タスクを起点として順次実行される複数のタスクとそれに伴って順次発生する複数のイベントの列を抽出し、システムログに記録されたタイムスタンプに基づいて発生順序で並べられた複数のイベントと照合する。
ターゲットシステムに、サブシステムが追加されて大規模化、複雑化する場合に、追加されたサブシステムに対応する挙動シナリオを挙動モデルに追加し、追加されたサブシステムと他のサブシステムとの接続関係を構成モデルに追記することにより、サブシステムの追加に対応することができる。
以上は、以下に詳述する実施形態１〜４に限らず、種々の変更を伴う他の実施の形態にも同様に適用することができる、基本的な技術思想である。
図１は、実施形態１の解析装置110を含む評価システムの構成例を示すブロック図である。評価システムは、動的評価装置100と解析装置110で構成される。動的評価装置100では、ターゲットシステム101を動作させてシステムログ104を取得する。ターゲットシステム101は、例えば、複数のサブシステム102がネットワーク103で接続された分散型組込みシステムとして定義される。
ターゲットシステム101の一構成例として、ターゲットシステム200を図２に示す。ターゲットシステム200は、２個のサブシステムSys_A(210)とSys_B(211)とがネットワーク220によって接続された組込みシステムの総体として定義される。サブシステムはデバイス(マイコン、モータ等)、ソフトウェアなどで構成され、それぞれのサブシステムがアプリケーション(機能)を提供する。サブシステムはアプリケーションとして定義されるため、一つのハードウェアに複数のサブシステムが含まれても構わない。ターゲットシステムはサブシステムを組み合わせることで一つの統合アプリケーションを実現する。
図１についての説明に戻る。解析装置110は、挙動モデル111と解析機114によって構成される。挙動モデル111はターゲットシステム101の動作をモデリングしたデータで、サブシステム102の動作を表す挙動シナリオ112とサブシステム間の構成情報を表す構成モデル113で構成される。解析機114は、挙動モデル111とシステムログ104が入力されて解析結果115を出力する。解析装置110は、例えば、プロセッサと記憶装置を含むコンピュータ上で解析プログラムを動作させることによって実現することができる。このとき、挙動シナリオ112と構成モデル113及び挙動モデル111全体は、所定の文法に則って記述されたソースコード、またはそのソースコードを符号化したデータであり、上記コンピュータの記憶装置に記憶される。システムログ104もテキストデータなど所定の形式の電子データとして、入力される。解析機114は、解析プログラムを実行することによって、その機能が実現される。ここで説明した解析装置110の実現方法は、一例に過ぎず、その要旨を逸脱しない範囲において、種々の形態で実現することができる。
図３に、図２に例示されるターゲットシステム200に対応して構築された、挙動モデル300を例示する。挙動モデル300は、構成モデル310と挙動シナリオ320、321、322で構成される。構成モデルのインスタンス311、インスタンス312、インスタンス313はそれぞれ図２のサブシステムSys_A(210)、ネットワーク220、サブシステムSys_B(211)に対応し、各インスタンスはターゲットシステム300依存の情報を保存する。この例ではインスタンス間の接続関係やターゲットシステム内でのインスタンス名(ID)が依存情報に該当する。挙動シナリオSys_A_model(320)、Router_model(321)、Sys_B_model(322)は、サブシステムSys_A(210)、ネットワーク220、サブシステムSys_B(211)の動作をそれぞれモデリングした情報で、構成モデルの各インスタンス311、313、312にそれぞれ関連付けられる。
解析全体の流れについて説明する。図４は、解析全体の流れを示す説明図である。解析を始める（スタート400）に当たって、図３に例示したような挙動モデル111を構築する（402）。その後、またはこれと並行して、ターゲットシステム101の動的評価を行い、システムログ104を取得する（401）。予め構築されている挙動モデル111と、取得したシステムログ104とを解析機114に入力する（403）。後述のフローにしたがって、解析装置110により解析を実行する（404）。
解析装置110の動作について説明する。解析機114は挙動モデル111（例えば図３の300）の記述に従ってシステムログ104の評価を行い、ターゲットシステム101（例えば図２の200）が動的評価中にどのような動きをしたかを自動探索する。システムログ104はターゲットシステム101を動的評価する事で取得する。動的評価はシミュレーションや実機によって行う。このとき、ターゲットシステム101全体で共通の時間をタイムスタンプとして記録したシステムログを各サブシステムから取得する。例えば、上述の特許文献２に記載される技術により、所望のシステムログ104を取得することができる。
図５、図６及び図７にシステムログ104の例を示す。図２に示した例と同様に、ターゲットシステム101の一例としてのターゲットシステム200は2つのサブシステム(Sys_AとSys_B)210と211で構成されるものとし、それぞれのサブシステムが個別にログを出力する。図５と図６はサブシステム(Sys_AとSys_B)210と211がそれぞれ出力するログの例である。ログにはイベントの発生時間（Time）、イベントの識別情報(Event ID)、ユーザ定義情報(Sub-Event ID)などが記録される。動的評価装置100はイベントの発生時間を元にログの並べ替えを行い時間的に整合性のとれたシステムログ104を構築する。図7は各サブシステムから個別に出力されたログを統合したシステムログ104の例である。動的評価装置100がログを統合して解析装置110に入力しても良いし、動的評価装置100からは各サブシステムから個別に出力されたログをそのまま解析装置110に入力し、解析装置110内の中間データとして時間的に整合性のとれたシステムログ104を生成しても良い。
図８は、統合されたシステムログを模式的に示す説明図である。縦軸が時間を示し、下に行くほど時間が経過する。上述の例に倣い、ライフライン600、610がログを出力したサブシステム(Sys_AとSys_B)210と211、円形のシンボルがイベント601〜603及び611〜613の発生を表す。図５によれば、サブシステム(Sys_A)210では３つのイベントEvent1(601)、Event2.Sub_A(602)、Event2.Sub_A(603)がそれぞれTime 100、200、300に発生したことがわかる。また、図６によれば、サブシステム(Sys_B)211では３つのイベントEvent3(611)、Event4.Sub_C(612)、Event5(613)がそれぞれTime 150、250、350に発生したことがわかる。図８ではサブシステム(Sys_A)210のライフライン600に、Event1(601)、Event2.Sub_A(602)、Event2.Sub_A(603)を、それぞれ発生した時間に対応して表示する。サブシステム(Sys_B)211で発生したイベントEvent3(611)はライフライン610に所属し、Timeが150なのでTime 100のイベントEvent1(601)とTime 200のイベントEvent2.Sub_A (602)の間の時間に表示される。同様に、Time 250のイベントEvent4.Sub_C(612)もライフライン610に所属し、Time 200のイベントEvent2.Sub_A (602)とTime 300のイベントEvent2.Sub_A(603)の間の時間に表示される。さらに、Time 350のイベントEvent5(613)もライフライン610に所属し、Time 300のイベントEvent2.Sub_A(603)よりも後の時間に表示される。
上述のように、各サブシステムがログに出力するタイムスタンプは、ターゲットシステム101全体で共通の時間とされているので、異なるサブシステムで発生したイベントについても、現実に発生した前後関係が正確に把握されることとなる。ここで、「ターゲットシステム101全体で共通の時間」とは、厳密に同じ時間である必要はなく、一定の誤差を含んでいてもよい。因果関係を持つ２つのタスクで発生した２つのイベントが、現実の発生順序を反映してログに記録されればよく、例えば、各サブシステムがそれぞれタイマを備えるとき、そのタイマに許される誤差は、イベントが発生した正確な時間ではなく、その発生順序を正確に判定することができる範囲で記録されればよい。因果関係を持たない複数のタスクが概ね同時に発生した複数のイベントの発生順序については、必ずしも正確である必要はない。「共通の時間」に許容される誤差は、以上のような条件を考慮して適宜規定されれば良い。
挙動モデル111における、挙動シナリオ112のタスクの関連付けの例を、図９に示す。
挙動シナリオはサブシステムやネットワークの機能を記述したタスクの集合として定義される。これまでの説明に倣って、２つのサブシステム(Sys_AとSys_B)210と211と、ネットワーク220で構成されるターゲットシステム200を例にとって説明する。図９に例示される挙動モデル111は、構造モデル700と、サブシステム(Sys_AとSys_B)210と211にそれぞれ対応する挙動シナリオ(Sys_AとSys_B)710と730と、ネットワーク220に対応する挙動シナリオ(Router)720とを含む。挙動シナリオ710はタスク711、712、713で構成され、各タスクはそれぞれイベントEvent1、Event2、Event3を発生する。なお、イベントは「サブシステム名::イベント名」と表記する。「Sys_A::Event1」はSys_AのEvent1を意味する。同様に、ネットワーク220に対応する挙動シナリオ720はタスク721、722で構成され、各タスクはそれぞれイベントEvent4、Event5を発生し、サブシステム(Sys_B)211に対応する挙動シナリオ730はタスク731、732、733で構成され、各タスクはそれぞれイベントEvent6、Event7、Event8を発生する。
解析機114は構成モデルを読み込み、挙動シナリオのタスクを関連付ける。例ではタスク711、721、731を関連づけている。関連付けの結果は、接続740、742で示される。これはターゲットシステムのアプリケーションの機能の1つがタスク711で開始し、タスク721を経由してタスク731で終了する事を意味する。この機能が実行されると、Sys_A::Event1、Router::Event4、Sys_B::Event6が順次発生することとなる。また、タスク732、733、722、713を関連づけている。関連付けの結果は、接続743、744、741で示される。これはターゲットシステムのアプリケーションの機能の1つがタスク732で開始し、タスク722を経由してタスク713で終了する事を意味し、別の機能の1つがタスク733で開始し、同じタスク722を経由して同じくタスク713で終了する事を意味している。タスク732を開始タスクとするアプリケーション(機能)が実行されると、Sys_B::Event7、Router::Event5、Sys_A::Event3が順次発生し、タスク733を開始タスクとするアプリケーション(機能)が実行されると、Sys_B::Event8、Router::Event5、Sys_A::Event3が順次発生する。
挙動モデルを解析することによるタスクの関連付けについて、さらに詳しく説明する。図１0〜14は、挙動モデル111を構成する種々のデータの例を、ソースコードで示したものである。タスク711,721,731に渡って定義されるアプリケーションのモデルを記述したコードに着目し、他のコードは図示が省略されている。図１0に示されるコード800が構造モデル700を、図１１に示されるコード801がインターフェース宣言を、図１２に示されるコード802が挙動シナリオ710(Sys_A)を、図１３に示されるコード803が挙動シナリオ730(Sys_B)を、図１４に示されるコード804が挙動シナリオ720(Router)をそれぞれ表す。
構造モデルのコード800(図１0)ではモデルのインスタンス生成と接続関係の定義を行う。インスタンス生成は、コード800の5行目のように、subsystem文でインスタンス名(Sys_A)を定義してnew文で新たに生成するインスタンスの種類(Sys_A_model)を指定することによって行う。同様に9行目でRouterのインスタンスを、14行目でSys_Bのインスタンスを、それぞれ生成している。モデル間の接続関係は、インターフェースクラスを使用して定義する。接続740を例にとると、まず2行目でインターフェースクラスのインスタンス$if_ARを作成し、6行目と10行目のbind文でSys_AとRouterに登録する。この時、2行目のeth_ifがインターフェースクラス名、6行目のeth0と10行目のSys_A_sideがポート名を表す。同様に3行目、11行目、15行目で接続742を定義する。
インターフェースクラスはモデル間を跨ぐ動作を仲介する。図１１に示されるコード801のinterface宣言では、1行目でクラス名eth_ifのインターフェースを宣言し、2-3行目で定義するクラスがsend、rcvのタスク参照を持つことを記述している。
次に挙動シナリオの記述について説明する。挙動シナリオはタスク宣言とポート宣言で構成される。図１２に示されるSys_Aの挙動シナリオ802では、2行目がポート宣言、4-7行目がタスク宣言である。同様に、図１３に示されるSys_Bの挙動シナリオ803では、2-4行目がポート宣言、6-8行目がタスク宣言であり、図１４に示されるRouterの挙動シナリオ804では、2-4行目と6行目がポート宣言、8-11行目がタスク宣言である。
タスク宣言では解析するイベントの順番や次に実行するタスクを定義する。コード802のsend_ethを例にとると5行目の$self::Event1が解析するイベントを表す(図１２)。ここで$selfにはインスタンス名(今回の例ではSys_A)を表す予約変数とする。また6行目のload文では次に解析を行うタスクを呼び出している。
ポート宣言はモデル外部に公開するタスクを定義する。ポートは上位モデルからbind文でインターフェースのインスタンスが渡されるとインスタンスの関連付けとタスク参照への登録を行う。例えばインターフェースインスタンス$if_ARは、コード800の6行目のbind文でSys_Aのポートeth0への関連付が行われ、10行目にあるbind文でポートSys_A_sideへの関連付けとタスク参照のsendにsend_from_a_sideタスクの登録を行う(図１0)。
ポートとインターフェースを使用する事でタスクは接続相手が不定であっても、同じコードでモデル外部に定義されたタスクの呼び出しが可能になる。コード802(図１２)の6行目を例にとると、解析機114はload文でeth0.sendを読み込む。最初の要素“eth0”はポートなのでポートeth0に関連付けされたインターフェースインスタンス$if_ARを参照する。次の要素“send”の読み込みで解析機114は$if_ARのタスク参照sendに登録されたタスクを呼び出す。今回の場合はコード804(図１４)のsend_from_a_sideが登録されているため、これを呼び出す。これによりSys_A_modelのsend_ethタスクはRouter_modelのsend_from_a_sideのタスクを呼び出すことが出来た。これは接続740の処理に該当する。同様に$if_BRの接続を処理する事によって接続742も実現できる。最後にユーザが外部から開始タスク(今回の例ではSys_Aのsend_eth)を指定すればタスク711、タスク721、タスク731の順に処理が行われる。
解析機114による解析フローについて説明する。図１５は、システムログ104を解析機114が探索するフローの例を示すフローチャートである。解析機114は、挙動モデル111をデコードして次に検索すべきイベントを読み込む（ステップ901）。次に検索すべきイベントの有無を判断し（ステップ902）、検索すべきイベントがなくなった時には正常終了する（ステップ906）。検索すべきイベントがあるときは、システムログ104から検索対象のイベントを検索する（ステップ903）。このとき、検索対象のイベントが、開始タスクが発生する最初のイベントであるときは、システムログ104の先頭から検索し、前回の検索で発見されたイベントがあるときは、そのイベントの発生時間よりも後を検索する。検索対象のイベントが見つかったか否かの判定を行い(ステップ904)、見つかった時には発見されたイベント情報を解析結果115として保存し(ステップ905)、次の検索対象イベントの読み込み（ステップ901）に戻り、見つからないときには、エラーを検出して終了する（ステップ907）。イベントの検索（ステップ903）を繰り返すことでイベントログ104と挙動モデル111を比較し、イベントログ104に記録された動作にもっとも適合する振舞いを選びだすことができる。
具体例を図１６に示す。図３に例示したような挙動モデル111と、図8に例示したようなシステムログ104とを並べて示す。挙動モデル111は構造モデル1000と挙動シナリオ1010、1011で構成される。図１６の動作例では解析機114は構成モデル1000から、タスク1012を開始タスクとし、タスク1012とタスク1013を関連づけたものとする。システムログ104はライフライン1030と1040とを含み、ライフライン1030に所属するイベント1031〜1033と、ライフライン1040に所属するイベント1041〜1043が示される。挙動シナリオ1010とライフライン1030は、サブシステム(Sys_A)210に対応し、タスク1012が発生するイベントSys_A::Event1とSys_A::Event2は、ライフライン1030上のイベント1032と1033にそれぞれ対応する。挙動シナリオ1011とライフライン1040は、サブシステム(Sys_B)211に対応し、タスク1013が発生するイベントSys_B::Event3は、ライフライン1040上のイベント1043に対応する。イベント1031、1041、1042は、対応するタスクの図示が省略されている、他のイベント(Other_Event)である。
解析機114は開始タスク1012から最初の検索イベントSys_A::Event1を読み込み、システムログ104のSys_A::Event1検索1014を行う。Sys_A::Event1はサブシステム(Sys_A)210の開始タスク1012が発生する最初のイベントであるため、Sys_Aのログであるライフライン1030の先頭から、Event1を検索1034する。該当のイベント1032を発見すればイベント情報(時間やユーザ定義情報)を解析結果115として保存する。解析機114は最初の検索1014、1034が終わると、次の検索イベントSys_A::Event2を挙動シナリオ1010から読み込み、Sys_A::Event2の検索1015を行う。Sys_A::Event2検索1015は検索の開始時間を、直前の検索1014、1034で発見したSys_A::Event1(イベント1032)の時間の直後に設定して検索1035を行う。Sys_A::Event2(イベント1033)を発見すると、解析機114はさらに次の検索イベントを読み込む。次のイベントの読み込みでは、挙動タスク1012を最後まで読み込んでいるため、関連1017に従い挙動シナリオ1011からタスク1013のSys_B::Event3を読み込む。Sys_B::Event3検索1016の検索ではSys_A::Event2(イベント1033)の発生時間を始点にして、Sys_Bのログであるライフライン1040からEvent3の検索1044を行う。検索によって解析機はSys_B::Event3(イベント1043)を発見する。解析機114は挙動シナリオ1011からのタスク1013に含まれる全てのイベントの読み込みが終了し、次の関連がないため、解析結果を保存して評価を終了する。一連の解析で見つからないイベントがある場合はエラーとして解析結果115に記録する。ユーザは、解析結果115をもとにターゲットシステム101の動作状況を分析することができる。例えば、リアルタイム性能(動作時間)の評価や、発生イベントの評価(起こるべきイベントが起こらない)などである。
周期的な動作をするアプリケーションの解析を行う場合には、上述の処理を繰り返してシステムログ104全体の解析を行う。例えば、Sys_A::Event1、Sys_A::Event2、Sys_B::Event3を繰り返し発生させるアプリケーションの解析を行う場合には、Sys_A::Event1の検索1014、1034、Sys_A::Event2の検索1015、1035、Sys_B::Event3の検索1016、1044を行った後に、その後の時間から同じ検索を繰り返す。ターゲットシステム101が、一連のイベントSys_A::Event1、Sys_A::Event2、Sys_B::Event3の発生の完了を待たずに次の繰り返しを開始することを許容する構成である場合には、システムログ104における繰り返しの検索の開始時間は、末尾のイベントSys_B::Event3ではなく先頭のイベントSys_A::Event1の直後とする。
以上説明したように、ターゲットシステム101の動作を解析する、システムログ104の解析に挙動モデル111を導入した。挙動モデル111は、サブシステム102の動作を表現するモデル(挙動シナリオ112)と、ターゲットシステム111の構成を表現するモデル(構成モデル113)を組合せて記述される。挙動モデル111を導入する事で、開始タスクを指定するだけでアプリケーションの動作を自動で探索することができる。また、動作のモデル(挙動シナリオ112)と構成のモデル(構成モデル113)とを分けることにより、動作部分のモデルを再利用することができる。ターゲットシステムによって変更になる部分を構成モデル113に集めることで、挙動シナリオ112はターゲットシステム111ごとに変更する必要がない。
〔実施形態２〕
実施形態２ではシステムログ104からターゲットシステム101の動作の推定を行う例について説明する。例として3つのサブシステムが相互に通信する場合を考える。図１７には、構成モデル1100においてサブシステムのインスタンスSys_A(1101)、Sys_B(1103)、Sys_C(1104)が、ルータをモデル化したインスタンスEth_router(1102)を介して相互に通信する、ターゲットシステム101の挙動モデルが例示される。1105はルータの挙動シナリオ、1106はその挙動シナリオ1105に含まれるタスクである。
図１８に、動作の推定対象であるターゲットシステム101から取得したシステムログ104の例を示す。サブシステムSys_A、Sys_B、Sys_Cにそれぞれ対応するライフライン1200、1210、1220が示され、ライフライン1200上にイベント1201、ライフライン1220上にイベント1221が示される。これは、Sys_A(1200)がパケット送信(イベント1201)を行い、Sys_C(1220)でパケット受信(イベント1221)した場合の動作を表している。
挙動シナリオ1105に動作の推定を行う場合の例を示す。タスク1106は送信したパケットが相手側で受信できたかの解析を行う。解析機114はタスク1106の1行目を読み込み、Sys_A(1200)のパケット送信イベント(Sys_A::Send_Event)をシステムログ104から検索する。この処理は図１８の検索1202に相当し、これによりイベント1201を発見する。次に解析機114はタスク1106の2行目のif文の条件を評価しSys_B(1210)のパケット受信イベント(Sys_B::Rcv_Event)を検索する。これは検索1211に該当するが、Sys_B(1210)には受信イベントが存在しないため検索が失敗する。解析機114は2行目の条件式が失敗したため6行目のelsif文の条件式を読み込み、Sys_C(1220)の受信イベント(Sys_C::Rcv_Event)を検索する。Sys_C(1220)にはパケット受信イベントが記録されているため、解析機114は検索1222でイベント1221を発見し7行目以降のタスクを読み込む。一連の評価で解析機114はパケットの受信イベントがSys_B(1210)で検出できずSys_C(1220)で検出できたため、Sys_A(1101)から送信されたパケットを、Eth_router(1102)がSys_C(1104)にルーティングしたと判断する。これにより、解析機114はEth_router(1102)の内部状態を考慮することなく、動作の推定を行う事が出来る。
シミュレーションによる動的評価ではSys_A(1101)からSys_B(1103)もしくはSys_C(1104)にパケットを送る場合、Eth_router(1102)はパケットのIPアドレスとEth_router(1102)内部のルーティングテーブルを比較してSys_B(1103)とSys_C(1104)のどちらの転送先にパケットを送るかを決定する。一連の動作はEth_router(1102)の内部状態の設定によって変わるため、シミュレーション時の条件設定によって実機動作と乖離が発生する場合がある。一方、本実施形態２の解析では、解析機114はEth_router(1102)の内部状態を参照せず、システムログ104を使用して評価を行う。これにより実動作と乖離のない振舞いの評価を行なうことができる。この特徴を利用すれば実機がエラー動作を起こした場合に、エラー条件を抽出してシミュレーションにフィードバックする等の応用が可能になる。
〔実施形態３〕
挙動モデルを流用してさらに大きなターゲットシステムの解析を行う事も可能である。その例を図１９に示す。挙動モデル1300は部分モデルとして挙動モデル1310を内包する。これは挙動モデル1300がサブシステムのインスタンスSys_A(1311)、Sys_B(1312)、Sys_C(1313)からなるシステム(挙動モデル1310のシステム)に、さらにサブシステムのインスタンスSys_D(1301)、Sys_E(1302)を追加して構築されていることを意味する。
図１９の様な複雑なシステムではシステムをいくつかの機能にわけて、機能ごとに単体検証を行ってからシステム全体の検証を行うのが一般的である。本実施形態ではシステムの動作を挙動モデルとして電子データで管理しているため、モデルの流用が可能である。単体検証で挙動モデル1310の作成を行い、その後にシステム全体の検証で単体検証の挙動モデル1310を流用して挙動モデル1300を構築する事ができる。このように、成果物をデータとして保存できるため、設計資産の流用や展開などが容易になる。
〔実施形態４〕
ターゲットシステムを水平分業で構築することも可能である。
図２０は、複数の制御ユニットが車載ネットワークに接続される、ターゲットシステムの一構成例を示す、模式的ブロック図である。ターゲットシステム1400は、サブシステムSys_A(1410)とサブシステムSys_B(1420)とをネットワークNet_C(1430)で互いに繋いで構成される。サブシステムSys_A(1410)は下位のサブシステムSys_A-1(1411)とSys_A_2(1412)とを含み、サブシステムSys_B(1420)は下位のサブシステムSys_B-1(1421)とSys_B_2(1422)とを含み、ネットワークNet_C(1430)も下位のネットワークNet_C-1(1431)とNet_C-2(1432)とを含む。サブシステムSys_A-1(1411)、Sys_A_2(1412)、Sys_B-1(1421)、及びSys_B_2(1422)は、例えば制御ユニット(ECU: Electronic Control Unit）であり、ネットワークNet_C(1430)は、例えば車載ネットワーク(CAN: Controller Area Network）である。
水平分業の一例として、サブシステムSys_A(1410)とサブシステムSys_B(1420)と互いに異なるベンダから導入される場合について説明する。
サブシステムSys_A(1410)におけるSys_A-1(1411)とSys_A_2(1412)、及び、サブシステムSys_B(1420)におけるSys_B-1(1421)とSys_B_2(1422)は、それぞれネットワークNet_C(1430)を介して相互に通信を行う。このときサブシステムSys_A(1410)とサブシステムSys_B(1420)とは、共同でネットワークNet_C(1430)を利用するため、相互に影響を与える。そのため、ターゲットシステム1400でサブシステムSys_A(1410)とサブシステムSys_B(1420)とが正常に動作することを確認するには、サブシステムSys_A(1410)、サブシステムSys_B(1420)、及び、ネットワークNet_C(1430)がすべて揃っている状態で評価する必要がある。
従来はターゲットシステム上でサブシステムの動作を評価するには、特定のポイントに観測機器を挿入または接続して人が目視でチェックするしかなかった。観測機器の挿入は挿入点数や観測できる範囲が制限される。また、検証の判定を目視で行う事が多く、観測上の制限や工数に問題があった。
これに対して本実施形態では、サブシステムSys_A(1410)とサブシステムSys_B(1420)の挙動モデルを、それぞれのベンダからリリースしてもらい、ターゲットシステム1400の挙動モデルに導入する事で各々のサブシステム動作を自動評価する事が出来る。挙動モデルを利用する事でサブシステムの開発元でなければ難しかった評価項目もターゲットシステム上で評価可能になる。これにより、従来は難しかったターゲットシステム上で動作する複数のアプリケーションの評価ができるようになる。
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
例えば、サブシステムの数、及び、サブシステムを構成する階層の深さは任意であり、サブシステム間を接続する、ネットワークや中継ルータ、ゲートウェイ等の機能を別のサブシステムとして位置付け、挙動シナリオを定義して挙動モデルを構成しても良い。
本発明は、解析装置及び解析方法に関し、特に複数のサブシステムを含んで構成されるシステムの動作解析を支援するための解析装置及び解析方法に広く適用することができる。
１００ 動的評価装置
１０１、２００、１４００ ターゲットシステム
１０２、２１０、２１１、１４１０〜１４１２、１４２０〜１４２２、１４３０〜１４３２ サブシステム
１０３、２２０ ネットワーク
１０４ システムログ
１１０ 解析装置
１１１、３００、１３００、１３１０ 挙動モデル
１１２、３２０〜３２２、７１０、７２０、７３０、１０１０、１０１１、１１０５ 挙動シナリオ
１１３、３１０、７００、１０００、１１００ 構成モデル
３１１〜３１３、１００１、１００２、１１０１〜１１０４、１３０１、１３０２、１３１１〜１３１３ インスタンス（構成モデルにおける挙動シナリオのインスタンス）
１１４ 解析機
１１５ 解析結果
４００〜４０４ 解析の各ステップ
６００、６１０、１０３０、１０４０、１２００、１２１０、１２２０ ライフライン
６０１〜６０３、６１１〜６１３、１０３１〜１０３３、１０４１〜１０４３、１２０１、１２２１ イベント
７１１〜７１３、７２１〜７２２、７３１〜７３３、１０１２、１０１３、１１０６ タスク
７４０〜７４４、１０１７ タスク間の接続、関連
８００〜８０４ 挙動モデルを構成するソースコード
９００〜９０７ 解析機による解析フローの各ステップ
１０１４〜１０１６、１０３４、１０３５、１０４４、１２０２、１２１１、１２２２ イベント検索

Claims (17)

  1. 複数のサブシステムから成るターゲットシステムの動作を解析するための解析装置であって、挙動モデルと解析機とを有し、
    前記挙動モデルは、前記複数のサブシステムそれぞれの挙動を表す複数の挙動シナリオと、前記複数のサブシステム相互間の接続関係を表す構成モデルとを含み、
    前記挙動シナリオには、対応するサブシステムが実行するタスクと、そのタスクによって発生するイベントとが記述され、
    前記解析機には、前記ターゲットシステムを動作させたときに、前記複数のサブシステムから発生されるイベントと、当該イベントの発生時間を前記ターゲットシステム全体に共通の時間によって示すタイムスタンプとを記録したシステムログが入力され、
    前記解析機は、前記挙動モデルから、所定の開始タスクを起点として順次実行される複数のタスクとそれに伴って順次発生する複数のイベントの列を抽出し、
    前記解析機は、前記システムログに記録された前記タイムスタンプに基づいて発生順序で並べられた複数のイベントと、前記挙動モデルから抽出された前記複数のイベントの列とを照合する、
    解析装置。
  2. 請求項１において、前記解析機は、複数の開始タスクとそれぞれに対応する複数のイベントから成る複数のイベント列を抽出し、前記複数のイベント列ごとに、同じ順序で配列された複数のイベントが前記システムログに記録された複数のイベントの中に同じ順序で存在するか否かを探索する、
    解析装置。
  3. 請求項２において、前記解析機は、前記探索の結果、探索対象のイベントが発見されなかったときには、探索結果としてエラーを出力または記録する、
    解析装置。
  4. 請求項２において、前記解析機は、イベント列に含まれる最後のイベントを前記システムログの探索で発見した後、当該イベント列の開始タスクに対応する最初のイベントを、前記システムログの前記最初のイベントより後の時間に再び存在するか否かを探索し、存在するときには当該イベント列についての探索を再び行う、
    解析装置。
  5. 請求項１において、前記ターゲットシステムには、前記複数のサブシステムの少なくとも一部に複数のサブシステム相互間の通信を中継するネットワークが含まれ、前記挙動モデルには、前記ネットワークに対応する挙動シナリオが含まれ、
    前記ネットワークに対応する挙動シナリオには、送信側のサブシステム及びイベントと、受信側のサブシステム及びイベントとを関連付ける記述が含まれる、
    解析装置。
  6. 請求項５において、前記ネットワークに対応する前記挙動シナリオに、送信側の１個のイベントに対して、受信側として複数のサブシステム及びイベントが関連付けられているとき、
    前記解析機は、前記挙動モデルから、関連付けられる全てのイベントへの分岐を含むイベント列を抽出し、どの分岐が前記システムログに存在するかを探索する、
    解析装置。
  7. 請求項１において、前記ターゲットシステムは、ネットワークを介して相互接続された複数の制御モジュールを前記複数のサブシステムとして備え、前記システムログは前記ターゲットシステムの実動作によって取得される、
    解析装置。
  8. 請求項１において、前記ターゲットシステムは、ネットワークを介して相互接続された複数の制御モジュールを前記複数のサブシステムとして備え、前記システムログは前記ターゲットシステムについてのシミュレーションによって取得される、
    解析装置。
  9. 複数のサブシステムから成るターゲットシステムの動作を、電子計算機を利用して解析するための解析方法であって、前記電子計算機の記憶装置に格納される挙動モデルと、前記電子計算機によって実行されることによって解析動作を行う解析プログラムとを有し、
    前記挙動モデルは、前記複数のサブシステムそれぞれの挙動を表す複数の挙動シナリオと、前記複数のサブシステム相互間の接続関係を表す構成モデルとを含み、
    前記挙動シナリオには、対応するサブシステムが実行するタスクと、そのタスクによって発生するイベントとが記述され、
    前記解析動作には、前記ターゲットシステムを動作させたときに、前記複数のサブシステムから発生されるイベントと、当該イベントの発生時間を前記ターゲットシステム全体に共通の時間によるタイムスタンプとを記録したシステムログが入力され、
    前記解析動作は、
    前記挙動モデルから、所定の開始タスクを起点として順次実行される複数のタスクとそれに伴って順次発生する複数のイベントの列を抽出する、第１ステップと、
    前記システムログに記録された前記タイムスタンプに基づいて発生順序で並べられた複数のイベントと、前記挙動モデルから抽出された前記複数のイベントの列とを照合する、第２ステップとを含む、
    解析方法。
  10. 請求項９において、
    前記第１ステップでは、複数の開始タスクとそれぞれに対応する複数のイベントから成る複数のイベント列を抽出し、
    前記第２ステップでは、前記複数のイベント列ごとに、同じ順序で配列された複数のイベントが前記システムログに記録された複数のイベントの中に同じ順序で存在するか否かを探索する、
    解析方法。
  11. 請求項１０において、前記第２ステップでは、前記探索の結果、探索対象のイベントが発見されなかったときには、探索結果としてエラーを出力または記録する、
    解析方法。
  12. 請求項１０において、前記第２ステップでは、イベント列に含まれる最後のイベントを前記システムログの探索で発見した後、当該イベント列の開始タスクに対応する最初のイベントを、前記システムログの前記最初のイベントより後の時間に再び存在するか否かを探索し、存在するときには当該イベント列についての探索を再び行う、
    解析方法。
  13. 請求項９において、前記ターゲットシステムには、前記複数のサブシステムの少なくとも一部の複数のサブシステム相互間の通信を中継するネットワークが含まれ、前記挙動モデルには、前記ネットワークに対応する挙動シナリオが含まれ、
    前記ネットワークに対応する挙動シナリオには、送信側のサブシステム及びイベントと、受信側のサブシステム及びイベントとを関連付ける記述が含まれる、
    解析方法。
  14. 請求項１３において、前記ネットワークに対応する前記挙動シナリオに、送信側の１個のイベントに対して、受信側として複数のサブシステム及びイベントが関連付けられているとき、
    前記第１ステップでは、前記挙動モデルから、関連付けられる全てのイベントへの分岐を含むイベント列を抽出し、
    前記第２ステップでは、どの分岐が前記システムログに存在するかを探索する、
    解析方法。
  15. 請求項９において、前記ターゲットシステムは、ネットワークを介して相互接続された複数の制御モジュールを前記複数のサブシステムとして備え、前記システムログは前記ターゲットシステムの実動作によって取得される、
    解析方法。
  16. 請求項９において、前記ターゲットシステムは、ネットワークを介して相互接続された複数の制御モジュールを前記複数のサブシステムとして備え、前記システムログは前記ターゲットシステムについてのシミュレーションによって取得される、
    解析方法。
  17. ターゲットシステムの動作をモデル化した挙動モデルを有し、前記ターゲットシステムを動作させた時に発生するイベントを時系列で記録したログが入力され、前記挙動モデルを静的に解析することによって求められる発生順序に従ったイベント列を、前記ログに時系列で記録された複数のイベントから探索し、
    前記ターゲットシステムは複数のサブシステムを含み、
    前記挙動モデルは、前記複数のサブシステムそれぞれの挙動を表す複数の挙動シナリオと、前記複数のサブシステム相互間の接続関係を表す構成モデルとを含み、前記挙動シナリオには、対応するサブシステムが実行するタスクと、そのタスクによって発生するイベントとが記述され、
    前記ログには、前記ターゲットシステムを動作させたときに、前記複数のサブシステムから発生されるイベントと、当該イベントの発生時間を前記ターゲットシステム全体に共通の時間によって示すタイムスタンプとが記録され、
    前記解析装置は、前記挙動モデルから、所定の開始タスクを起点として順次実行される複数のタスクとそれに伴って順次発生する複数のイベントの列を抽出し、前記ログに記録された前記タイムスタンプに基づいて発生順序で並べられた複数のイベントと照合する、
    解析装置。
JP2016564647A 2015-03-27 2015-03-27 解析装置及び解析方法 Expired - Fee Related JP6228324B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/059630 WO2016157298A1 (ja) 2015-03-27 2015-03-27 解析装置及び解析方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2017198140A Division JP2018005950A (ja) 2017-10-12 2017-10-12 挙動モデル

Publications (2)

Publication Number Publication Date
JPWO2016157298A1 JPWO2016157298A1 (ja) 2017-04-27
JP6228324B2 true JP6228324B2 (ja) 2017-11-08

Family

ID=57003983

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016564647A Expired - Fee Related JP6228324B2 (ja) 2015-03-27 2015-03-27 解析装置及び解析方法

Country Status (3)

Country Link
US (1) US20170235658A1 (ja)
JP (1) JP6228324B2 (ja)
WO (1) WO2016157298A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3339995A1 (en) * 2016-12-21 2018-06-27 ABB Schweiz AG Determining current and future states of industrial machines by using a prediction model based on historical data

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6963997B2 (en) * 2004-02-03 2005-11-08 Hewlett-Packard Development Company, L.P. Transaction logging and intelligent error reporting in an expectation-based memory agent checker
US8635596B2 (en) * 2006-04-21 2014-01-21 Microsoft Corporation Model-based event processing
US9092561B2 (en) * 2010-10-20 2015-07-28 Microsoft Technology Licensing, Llc Model checking for distributed application validation
JP2015035158A (ja) * 2013-08-09 2015-02-19 ルネサスエレクトロニクス株式会社 データ処理システム
JP5522304B2 (ja) * 2013-09-11 2014-06-18 株式会社リコー 情報処理装置、ソフトウェア動作テストシステム、ソフトウェア動作テスト方法、ソフトウェア動作テストプログラム、及びそのプログラムを記録した記録媒体
US9552249B1 (en) * 2014-10-20 2017-01-24 Veritas Technologies Systems and methods for troubleshooting errors within computing tasks using models of log files

Also Published As

Publication number Publication date
JPWO2016157298A1 (ja) 2017-04-27
US20170235658A1 (en) 2017-08-17
WO2016157298A1 (ja) 2016-10-06

Similar Documents

Publication Publication Date Title
Muccini et al. Using software architecture for code testing
Lai A survey of communication protocol testing
US20150286555A1 (en) System and method for converting the business processes to test-centric activity diagrams
Santiago et al. An environment for automated test case generation from statechart-based and finite state machine-based behavioral models
CN106919462A (zh) 一种生成处理器故障记录的方法及装置
CN107113199B (zh) 用于分析和处理通信序列的分析装置
Said et al. Towards Interactive Mining of Understandable State Machine Models from Embedded Software.
JP6228324B2 (ja) 解析装置及び解析方法
WO2014142876A1 (en) Kernel functionality checker
KR101648307B1 (ko) 임베디드 소프트웨어 단위 테스트를 위한 로그 기반 테스팅 장치 및 그 방법
Henniger et al. Automatic generation of test purposes for testing distributed systems
Qiu et al. Decentralized diagnosis of event-driven systems for safely reacting to failures
JP2018005950A (ja) 挙動モデル
US20230306343A1 (en) Business process management system and method thereof
Ambrosio et al. A conformance testing process for space applications software services
Lima et al. An approach for automated scenario-based testing of distributed and heterogeneous systems
CN115098362A (zh) 页面测试方法、装置、电子设备以及存储介质
CN105786865B (zh) 一种检索系统故障分析方法及装置
US9141341B2 (en) Inversion of control for executable extensions in a run-time environment
CN113419738A (zh) 接口文档的生成方法、装置及接口管理设备
Ipate et al. A unified integration and component testing approach from deterministic stream X-machine specifications
JP4816169B2 (ja) グローバルプロセス生成方法、装置、システム、およびプログラム
Ambrosio et al. A methodology for designing fault injection experiments as an addition to communication systems conformance testing
Joshi et al. Automatic generation of fault trees from AADL models
Fard et al. Detection and verification of a new type of emergent behavior in multiagent systems

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20161208

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20170323

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170627

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170825

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170912

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171012

R150 Certificate of patent or registration of utility model

Ref document number: 6228324

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees