▶ コリア アドバンスド インスティチュート オブ サイエンス アンド テクノロジィの特許一覧
特許7299640パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-06-20
(45)【発行日】2023-06-28
(54)【発明の名称】パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置
(51)【国際特許分類】
G06F 11/07 20060101AFI20230621BHJP
G06F 11/34 20060101ALI20230621BHJP
【ＦＩ】
G06F11/07 190
G06F11/34 147
【請求項の数】
20
(21)【出願番号】P 2021164887
(22)【出願日】2021-10-06
(65)【公開番号】P2022101455
(43)【公開日】2022-07-06
【審査請求日】2021-10-06
(31)【優先権主張番号】10-2020-0183097
(32)【優先日】2020-12-24
(33)【優先権主張国・地域又は機関】KR
【新規性喪失の例外の表示】特許法第３０条第２項適用 ▲１▼発行日 ２０２０年１２月１日 ▲２▼刊行物 ２０２０ ２７ｔｈ Ａｓｉａ－Ｐａｃｉｆｉｃ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｆｅｒｅｎｃｅ （ＡＰＳＥＣ）， ２０２０， Ｖｏｌ．１， ｐ．３２６－３３５， ＩＥＥＥ ▲１▼開催日 ２０２０年１２月３日 ▲２▼集会名 ２０２０ ２７ｔｈ Ａｓｉａ－Ｐａｃｉｆｉｃ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｆｅｒｅｎｃｅ （ＡＰＳＥＣ）
(73)【特許権者】
【識別番号】514260642
【氏名又は名称】コリア アドバンスド インスティチュート オブ サイエンス アンド テクノロジィ
(74)【代理人】
【識別番号】110000408
【氏名又は名称】弁理士法人高橋・林アンドパートナーズ
(72)【発明者】
【氏名】ぺ，ドゥファン
(72)【発明者】
【氏名】ヒョン，サンウォン
【審査官】木村 雅也
(56)【参考文献】
【文献】国際公開第２０１９／０３８２８３（ＷＯ，Ａ１）
【文献】中国特許出願公開第１１１９３０９０３（ＣＮ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １１／０７
Ｇ０６Ｆ １１／３４
(57)【特許請求の範囲】
【請求項1】
コンピュータ装置で実現されるパターンベースＳｏＳ（Ｓｙｓｔｅｍ－ｏｆ－Ｓｙｓｔｅｍｓ）内の失敗誘発相互作用を分析する方法であって、システムの実行ログに存在するデータからＳｏＳの実行中に実行される構成システム（Ｃｏｎｓｔｉｔｕｅｎｔ Ｓｙｓｔｅｍ：ＣＳ）間の相互作用を識別して、ＳｏＳに対する前記識別された相互作用のモデルを生成する段階、および
生成された前記相互作用のモデルでＬＣＳ（Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを利用して、失敗を誘発する疑わしい相互作用パターンを抽出する段階
を含む、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項2】
抽出された前記疑わしい相互作用パターンを分析する段階をさらに含む、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項3】
前記相互作用のモデルを生成する段階は、前記実行ログと目標属性検査の通過または失敗結果という２つの入力を用いて前記相互作用のモデルを生成すること
を特徴とする、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項4】
前記相互作用のモデルを生成する段階は、前記実行ログに存在するデータから、単一ＳｏＳの実行中に実行される構成システム（ＣＳ）と相互作用メッセージシーケンスを識別する段階
を含む、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項5】
前記相互作用のモデルを生成する段階は、外部モジュールによって記録された各前記実行ログの目標属性検査結果である通過または失敗タグを各前記相互作用のモデルに添付する段階
を含む、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項6】
前記相互作用のモデルを生成する段階は、識別された構成システム（ＣＳ）の集合、識別された相互作用メッセージシーケンス、および各前記実行ログの目標属性検査の通過状況を表示する通過または失敗タグを統合して各前記相互作用のモデルを生成すること
を特徴とする、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項7】
前記疑わしい相互作用パターンを抽出する段階は、生成された前記相互作用のモデルでＤＰ－ＬＣＳ（Ｄｙｎａｍｉｃ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを実行して、各カテゴリに共通するパターンを含むＬＣＳパターンと分類された相互作用のモデルを出力すること
を特徴とする、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項8】
前記疑わしい相互作用パターンを抽出する段階は、疑わしいＬＣＳ知識部から抽出されたＬＣＳパターンと前記相互作用のモデルとを比較する段階、
前記抽出されたＬＣＳパターンと前記相互作用のモデルとの間にＬＣＳが存在しない場合には、前記相互作用のモデルを前記疑わしいＬＣＳ知識部に新たなＬＣＳパターンとして追加する段階、および
前記抽出されたＬＣＳパターンと前記相互作用のモデルとの間にＬＣＳが存在する場合には、前記相互作用のモデルを前記疑わしいＬＣＳ知識部の同じカテゴリに割り当てる段階
を含む、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項9】
前記疑わしい相互作用パターンを分析する段階は、ＳｏＳエンジニアは、抽出された前記疑わしい相互作用パターンを分析することによって分類されたＬＣＳパターンと前記相互作用のモデルを分析し、失敗の根本原因と発生状況に関する情報を取得すること
を特徴とする、請求項２に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項10】
シナリオ生成モジュールを利用してプラトーニングＳｏＳのランダムシナリオを生成する段階、およびシミュレーションモジュールを利用して生成された前記ランダムシナリオに対する実行ログを生成する段階
をさらに含む、請求項１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法。
【請求項11】
パターンベースＳｏＳ（Ｓｙｓｔｅｍ－ｏｆ－Ｓｙｓｔｅｍｓ）内の失敗誘発相互作用分析装置であって、システムの実行ログに存在するデータからＳｏＳの実行中に実行される構成システム（ＣｏｎｓｔｉｔｕｅｎｔＳｙｓｔｅｍ：ＣＳ）間の相互作用を識別して、ＳｏＳに対する前記識別された相互作用のモデルを生成する相互作用モデル生成部、および
生成された前記相互作用のモデルでＬＣＳ（Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを利用して、失敗を誘発する疑わしい相互作用パターンを抽出するパターンマイニング部
を含む、パターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項12】
抽出された前記疑わしい相互作用パターンを分析するパターン分析部をさらに含む、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項13】
前記相互作用モデル生成部は、前記実行ログと目標属性検査の通過または失敗結果という２つの入力を用いて前記相互作用のモデルを生成すること
を特徴とする、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項14】
前記相互作用モデル生成部は、前記実行ログに存在するデータから、単一ＳｏＳの実行中に実行される構成システム（ＣＳ）と相互作用メッセージシーケンスを識別すること
を特徴とする、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項15】
前記相互作用モデル生成部は、外部モジュールによって記録された各前記実行ログの目標属性検査結果である通過または失敗タグを各前記相互作用のモデルに添付すること
を特徴とする、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項16】
前記相互作用モデル生成部は、識別された構成システム（ＣＳ）の集合、識別された相互作用メッセージシーケンス、および各前記実行ログの目標属性検査の通過状況を表示する通過または失敗タグを統合して各前記相互作用のモデルを生成すること
を特徴とする、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項17】
前記パターンマイニング部は、生成された前記相互作用のモデルでＤＰ－ＬＣＳ（Ｄｙｎａｍｉｃ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを実行して、各カテゴリに共通するパターンを含むＬＣＳパターンと分類された相互作用のモデルを出力すること
を特徴とする、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項18】
前記パターンマイニング部は、疑わしいＬＣＳ知識部から抽出されたＬＣＳパターンと前記相互作用のモデルとを比較し、前記抽出されたＬＣＳパターンと前記相互作用のモデルとの間にＬＣＳが存在しない場合には、前記相互作用のモデルを前記疑わしいＬＣＳ知識部に新たなＬＣＳパターンとして追加し、前記抽出されたＬＣＳパターンと前記相互作用のモデルとの間にＬＣＳが存在する場合には、前記相互作用のモデルを前記疑わしいＬＣＳ知識部の同じカテゴリに割り当てること
を特徴とする、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項19】
前記パターン分析部は、抽出された前記疑わしい相互作用パターンを分析することによって分類されたＬＣＳパターンと前記相互作用のモデルを分析し、失敗の根本原因と発生状況に関する情報を取得すること
を特徴とする、請求項１２に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【請求項20】
プラトーニングＳｏＳのランダムシナリオを生成するシナリオ生成モジュール、および生成された前記ランダムシナリオに対する実行ログを生成するシミュレーションモジュール
をさらに含む、請求項１１に記載のパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置。
【発明の詳細な説明】
【技術分野】
【0001】
以下の実施形態は、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置に関する。
【背景技術】
【0002】
近年、プラトーニング（ｐｌａｔｏｏｎｉｎｇ、除隊走行）システム複合システムは、燃費と交通渋滞に肯定的な影響を及ぼしながら多様な環境および事業上の利便に繋がることから、これに関する研究に高い関心が寄せられている。このとき、システム複合システムとは、システム・オブ・システムズ（Ｓｙｓｔｅｍ－ｏｆ－Ｓｙｓｔｅｍｓ、以下「ＳｏＳ」とする）を意味する。ＳｏＳは、単一の構成システム（Ｃｏｎｓｔｉｔｕｅｎｔ Ｓｙｓｔｅｍ：ＣＳ）では果たすことのできない共通目標を果たすために独立構成システム（ＣＳ）で構成された複雑かつ異質的なシステムである。プラトーニングＳｏＳは、複数の車両が接近しながら１つのユニットとしてグループ化して動作し、ＬｅａｖｅやＭｅｒｇｅのようなオペレーティングプロトコルによって管理されてＳｏＳレベルの目標を達成する。ＳｏＳの特性の１つとして、ＳｏＳレベル操作のほとんどがＣＳ間の複雑な相互作用を伴うということが挙げられる。このような特性のため、相互作用の特定の失敗順によって引き起こる、相互作用失敗と呼ばれる特定の類型の失敗が存在する。
【0003】
ダイムラー（メルセデスベンツトラック）、ボルボ、ヒュンダイなどのような多くの国際企業が実際の道路でのプラトーニング動作を成功させたが、すべての可能な相互作用に関しても、このように高度で複雑なソフトウェアの無障害機能を保障することは容易でない。
【0004】
図１は、一般的なプラトーニングＳｏＳでの相互作用の失敗例を示した図である。
【0005】
図１は、プラトーニングＳｏＳでＬｅａｖｅとＭｅｒｇｅの要請が同時に誘発したときの相互作用の失敗例を示している。プラトーン１（１１０）にはリーダーｖ１（１１１）、ｖ２（１１２）、ｖ３（１１３）が含まれ、プラトーン２（１２０）にはリーダーｖ５（１２１）、ｖ６（１２２）が含まれる。ここで、プラトーン１（１１０）のリーダーｖ１（１１１）がプラトーンから離れようとしているのに、プラトーン２（１２０）のリーダーｖ５（１２１）がｖ１（１１１）のＬｅａｖｅ操作が完了する前にｖ１（１１１）にＭｅｒｇｅの要請を送る場合が考えられる。このような状況は、Ｍｅｒｇｅ動作の正常な実行を抑制し、進行中のＬｅａｖｅ動作の実行時間に否定的な影響を及ぼす。ＳｏＳが相互作用を失敗せずに動作を進めるためには、根本的な失敗を誘発する相互作用を事前に体系的に把握して分析することが重要となる。
【0006】
近年の研究では、大規模システムから最も疑わしい失敗（ｆａｉｌｕｒｅ）の構成要素を分離するためにＳＢＦＬ（Ｓｐｅｃｔｒｕｍ－ｂａｓｅｄ Ｆａｕｌｔ Ｌｏｃａｌｉｚａｔｉｏｎ）を適用した。Ｓｈｉｎ（非特許文献１）は、災難対応ＳｏＳにＳＢＦＬ技法を適用することにより、その内部に注入された失敗を識別した。また、Ａｒｒｉｅｔａは、ＳＢＦＬ技術を適用することにより、ソフトウェア製品群から最も疑わしい機能の位置を測定した。しかし、従来の技法は、疑わしい相互作用シーケンスを識別するにあたり、次のような限界によって困難を感じている。第一に、この技法は、根本原因を分析するために詳細な相互作用データを直接活用しない。この代わりに、参加者ＣＳのようなシステムから高度の情報だけを抽出し、ＣＳ間の連結の存在だけを抽出する。第二に、相互作用シーケンスの組み合わせは無限数であるため、ＢＦＬを適用して失敗相互作用シーケンス（ｆａｕｌｔｙ ｉｎｔｅｒａｃｔｉｏｎ ｓｅｑｕｅｎｃｅ）を抽出することは不可能である。
【0007】
他の従来の研究では、ＳｏＳの根本原因を診断するために機械学習技法を適用することに焦点を合わせた。Ｋｌｅｙｋｏ（非特許文献２）は、原典のマトリックスに基づく抽象画モデルを構築し、失敗知識に基づいたパターンを効率的に一致させるための秒次元ベクトル診断接近法を提案した。Ｃａｉは、反復的かつ小さい構成要素で構成されたシステムに適した、迅速なＯｂｊｅｃｔ－Ｏｒｉｅｎｔｅｄ Ｂａｙｅｓｉａｎ Ｎｅｔｗｏｒｋ（ＯＯＢＮ）モデルを提案した。これらは、海底生産システムのためのＯＯＢＮに基づく失敗診断モデルを開発した。このような技法が共通してもつ一次的な限界は、各システムの「周知の失敗（ｋｎｏｗｎ ｆａｕｌｔｓ）」だけを考慮するという点にある。ＳｏＳにおいて各ＣＳは、オペレーティングおよび管理の独立性のためブラックボックスシステムとして見なされる。しかし、従来の技法は、ＳｏＳの制限的な知識と高い複雑性によって発生する「未周知の失敗（ｕｎｋｎｏｗｎ ｆａｕｌｔｓ）」と呼ばれる潜在的な危険に関しては説明することができずにいる。
【先行技術文献】
【非特許文献】
【0008】
【文献】Ｙ．－Ｊ．Ｓｈｉｎ，Ｓ．Ｈｙｕｎ，Ｙ．－Ｍ．Ｂａｅｋ，ａｎｄ Ｄ．－Ｈ．Ｂａｅ，“Ｓｐｅｃｔｒｕｍ－ｂａｓｅｄ ｆａｕｌｔ ｌｏｃａｌｉｚａｔｉｏｎ ｏｎ ａ ｃｏｌｌａｂｏｒａｔｉｏｎ ｇｒａｐｈ ｏｆ ａ ｓｙｓｔｅｍ－ｏｆ－ｓｙｓｔｅｍｓ，”ｉｎ ２０１９ １４ｔｈ Ａｎｎｕａｌ Ｃｏｎｆｅｒｅｎｃｅ Ｓｙｓｔｅｍ ｏｆ Ｓｙｓｔｅｍｓ Ｅｎｇｉｎｅｅｒｉｎｇ（ＳｏＳＥ）（ＳｏＳＥ２０１９），Ａｎｃｈｏｒａｇｅ，ＵＳＡ，２０１９．
【文献】Ｄ．Ｋｌｅｙｋｏ，Ｅ．Ｏｓｉｐｏｖ，Ｎ．Ｐａｐａｋｏｎｓｔａｎｔｉｎｏｕ，ａｎｄ Ｖ．Ｖｙａｔｋｉｎ，“Ｈｙｐｅｒｄｉｍｅｎｓｉｏｎａｌ ｃｏｍｐｕｔｉｎｇ ｉｎ ｉｎｄｕｓｔｒｉａｌ ｓｙｓｔｅｍｓ：ｔｈｅ ｕｓｅ－ｃａｓｅ ｏｆ ｄｉｓｔｒｉｂｕｔｅｄ ｆａｕｌｔ ｉｓｏｌａｔｉｏｎ ｉｎ ａ ｐｏｗｅｒ ｐｌａｎｔ，”ＩＥＥＥ Ａｃｃｅｓｓ，ｖｏｌ．６，ｐｐ．３０７６６－３０７７７，２０１８．
【文献】Ｓ．Ｈｙｕｎ，Ｊ．Ｓｏｎｇ，Ｓ．Ｓｈｉｎ，ａｎｄ Ｄ．－Ｈ．Ｂａｅ，“Ｓｔａｔｉｓｔｉｃａｌ ｖｅｒｉｆｉｃａｔｉｏｎ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｐｌａｔｏｏｎｉｎｇ ｓｙｓｔｅｍ ｏｆ ｓｙｓｔｅｍｓ ｗｉｔｈ ｕｎｃｅｒｔａｉｎｔｙ，”ｉｎ ２０１９ ２６ｔｈ Ａｓｉａ－Ｐａｃｉｆｉｃ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｆｅｒｅｎｃｅ（ＡＰＳＥＣ），ｐｐ．２１２－２１９，ＩＥＥＥ，２０１９．
【発明の概要】
【発明が解決しようとする課題】
【0009】
実施形態は、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置に関し、より具体的には、ＳｏＳ上に存在する相互作用バグを効果的に類推することができる、失敗誘発相互作用位置の推定技術を提供する。
【0010】
実施形態は、システム実行ログから相互作用モデルを生成して相互作用モデル内の共通シーケンスを抽出する方式により、相互作用バグを類推する過程に必要な情報をシステムマネージャに提供する、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置を提供する。
【課題を解決するための手段】
【0011】
一実施形態に係るコンピュータ装置が実現するパターンベースＳｏＳ（Ｓｙｓｔｅｍ－ｏｆ－Ｓｙｓｔｅｍｓ）内の失敗誘発相互作用を分析する方法は、システムの実行ログに存在するデータからＳｏＳの実行中に実行される構成システム（Ｃｏｎｓｔｉｔｕｅｎｔ Ｓｙｓｔｅｍ：ＣＳ）間の相互作用を識別して、ＳｏＳに対する相互作用モデルを生成する段階、および生成された前記相互作用モデルでＬＣＳ（Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを利用して、失敗を誘発する疑わしい相互作用パターンを抽出する段階を含んでよい。
【0012】
抽出された前記疑わしい相互作用パターンを分析する段階をさらに含んでよい。
【0013】
前記ＳｏＳに対する相互作用モデルを生成する段階は、前記実行ログと目標属性検査の通過または失敗結果という２つの入力を用いて前記ＳｏＳに対する相互作用モデルを生成してよい。
【0014】
前記ＳｏＳに対する相互作用モデルを生成する段階は、前記実行ログに存在するデータから、単一ＳｏＳの実行中に実行される構成システム（ＣＳ）と相互作用メッセージシーケンスを識別する段階を含んでよい。
【0015】
前記ＳｏＳに対する相互作用モデルを生成する段階は、外部モジュールによって記録された各前記実行ログの目標属性検査結果である通過または失敗タグを各前記相互作用モデルに添付する段階を含んでよい。
【0016】
前記ＳｏＳに対する相互作用モデルを生成する段階は、識別された構成システム（ＣＳ）の集合、識別された相互作用メッセージシーケンス、および各前記実行ログの目標属性検査の通過状況を表示する通過または失敗タグを統合して各前記相互作用モデルを生成してよい。
【0017】
前記疑わしい相互作用パターンを抽出する段階は、生成された前記相互作用モデルでＤＰ－ＬＣＳ（Ｄｙｎａｍｉｃ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを実行して、各カテゴリに共通するパターンを含むＬＣＳパターンと分類された相互作用モデルを出力してよい。
【0018】
前記疑わしい相互作用パターンを抽出する段階は、疑わしいＬＣＳ知識部から抽出されたＬＣＳパターンと前記相互作用モデルとを比較する段階、前記抽出されたＬＣＳパターンと前記相互作用モデルとの間にＬＣＳが存在しない場合には、前記相互作用モデルを前記疑わしいＬＣＳ知識部に新たなＬＣＳパターンとして追加する段階、および前記抽出されたＬＣＳパターンと前記相互作用モデルとの間にＬＣＳが存在する場合には、前記相互作用モデルを前記疑わしいＬＣＳ知識部の同じカテゴリに割り当てる段階を含んでよい。
【0019】
前記疑わしい相互作用パターンを分析する段階は、抽出された前記疑わしい相互作用パターンを分析することによって分類されたＬＣＳパターンと相互作用モデルを分析して、失敗の根本原因と発生状況に関する情報を取得してよい。
【0020】
シナリオ生成モジュールを利用してプラトーニングＳｏＳのランダムシナリオを生成する段階、およびシミュレーションモジュールを利用して生成された前記ランダムシナリオに対する実行ログを生成する段階をさらに含んでよい。
【0021】
他の実施形態に係るパターンベースＳｏＳ（Ｓｙｓｔｅｍ－ｏｆ－Ｓｙｓｔｅｍｓ）内の失敗誘発相互作用を分析する装置は、システムの実行ログに存在するデータからＳｏＳの実行中に実行される構成システム（Ｃｏｎｓｔｉｔｕｅｎｔ Ｓｙｓｔｅｍ：ＣＳ）間の相互作用を識別して、ＳｏＳに対する相互作用モデルを生成する相互作用モデル生成部、および生成された前記相互作用モデルからＬＣＳ（Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを利用して、失敗を誘発する疑わしい相互作用パターンを抽出するパターンマイニング部を含んでよい。
【0022】
抽出された前記疑わしい相互作用パターンを分析するパターン分析部をさらに含んでよい。
【0023】
前記相互作用モデル生成部は、前記実行ログと目標属性検査の通過または失敗結果という２つの入力を用いて前記ＳｏＳに対する相互作用モデルを生成してよい。
【0024】
前記相互作用モデル生成部は、前記実行ログに存在するデータから、単一ＳｏＳの実行中に実行される構成システム（ＣＳ）と相互作用メッセージシーケンスを識別してよい。
【0025】
前記相互作用モデル生成部は、外部モジュールによって記録された各前記実行ログの目標属性検査結果である通過または失敗タグを各前記相互作用モデルに添付してよい。
【0026】
前記相互作用モデル生成部は、識別された構成システム（ＣＳ）の集合、識別された相互作用メッセージシーケンス、および各前記実行ログの目標属性検査の通過状況を表示する通過または失敗タグを統合して各前記相互作用モデルを生成してよい。
【0027】
前記パターンマイニング部は、生成された前記相互作用モデルでＤＰ－ＬＣＳ（Ｄｙｎａｍｉｃ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを実行して、各カテゴリに共通するパターンを含むＬＣＳパターンと分類された相互作用モデルを出力してよい。
【0028】
前記パターンマイニング部は、疑わしいＬＣＳ知識部から抽出されたＬＣＳパターンと前記相互作用モデルとを比較し、前記抽出されたＬＣＳパターンと前記相互作用モデルとの間にＬＣＳが存在しない場合には、前記相互作用モデルを前記疑わしいＬＣＳ知識部に新しいＬＣＳパターンとして追加し、前記抽出されたＬＣＳパターンと前記相互作用モデルとの間にＬＣＳが存在する場合には、前記相互作用モデルを前記疑わしいＬＣＳ知識部の同じカテゴリに割り当ててよい。
【0029】
前記パターン分析部は、抽出された前記疑わしい相互作用パターンを分析することによって分類されたＬＣＳパターンと相互作用モデルを分析して、失敗の根本原因と発生状況に関する情報を取得してよい。
【0030】
プラトーニングＳｏＳのランダムシナリオを生成するシナリオ生成モジュール、および生成された前記ランダムシナリオに対する実行ログを生成するシミュレーションモジュールをさらに含んでよい。
【発明の効果】
【0031】
実施形態によると、ＳｏＳ上に存在する相互作用バグを効果的に類推することができる失敗誘発相互作用位置の推定技術を提供する、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置を提供することができる。
【0032】
実施形態によると、システム実行ログから相互作用モデルを生成して相互作用モデル内から共通シーケンスを抽出する方式により、相互作用バグを類推する過程に必要な情報をシステムマネージャに提供する、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置を提供することができる。
【図面の簡単な説明】
【0033】
【図1】一般的なプラトーニングＳｏＳの相互作用の失敗例を示した図である。
【図2】一実施形態における、パターンベースＳｏＳ内の失敗誘発相互作用を分析する装置を説明するための図である。
【図3】一実施形態における、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法を示したフローチャートである。
【図4a】一実施形態における、実行ログ生成を説明するための図である。
【図4b】一実施形態における、相互作用モデルの構造を説明するための図である。
【図4c】一実施形態における、アルゴリズムの出力の例を説明するための図である。
【図5】一実施形態における、相互作用シーケンスの代表的なＬＣＳパターンの抽出を示した図である。
【図6a】一実施形態における、カテゴリ１パターンの実行の流れを示した例示図である。
【図6b】一実施形態における、カテゴリ１パターンの実行の流れを示した例示図である。
【図6c】一実施形態における、カテゴリ１パターンの実行の流れを示した例示図である。
【図7a】一実施形態における、カテゴリ２パターンの実行の流れを示した例示図である。
【図7b】一実施形態における、カテゴリ２パターンの実行の流れを示した例示図である。
【図7c】一実施形態における、カテゴリ２パターンの実行の流れを示した例示図である。
【図7d】一実施形態における、カテゴリ２パターンの実行の流れを示した例示図である。
【図7e】一実施形態における、カテゴリ２パターンの実行の流れを示した例示図である。
【図8a】一実施形態における、カテゴリ３パターンの実行の流れを示した例示図である。
【図8b】一実施形態における、カテゴリ３パターンの実行の流れを示した例示図である。
【図8c】一実施形態における、カテゴリ３パターンの実行の流れを示した例示図である。
【図8d】一実施形態における、カテゴリ３パターンの実行の流れを示した例示図である。
【発明を実施するための形態】
【0034】
以下、添付の図面を参照しながら、実施形態について詳しく説明する。記載された実施形態は異なる多様な形態に変形されてよく、本発明の範囲が後述する実施形態によって限定されてはならない。また、多様な実施形態は、当技術分野において通常の知識を有する者に本発明をより完全に説明するために提供されるものである。図面において要素の形状および大きさなどは、より明確な説明のために誇張して示されることがある。
【0035】
大規模システム複合システムであるシステムオブシステムズ（ＳｏＳ）とは、異種のシステムが互いに協業することにより、単一システムでは解決することのできなかった目標を達成できるようにするシステムである。ＳｏＳの代表的は例としては、スマートホーム、スマートプラント、知能型交通システムなどが挙げられるが、このような大規模システムは、構成システム（Ｃｏｎｓｔｉｔｕｅｎｔ Ｓｙｓｔｅｍ：ＣＳ）間の緊密な相互作用によって特定の動作（ｏｐｅｒａｔｉｏｎ）を実行して目標を達成する。例えば、知能型交通システムの一種である隊列走行システム（Ｐｌａｔｏｏｎｉｎｇ Ｓｙｓｔｅｍ）では、Ｌｅａｖｅ、Ｍｅｒｇｅ、Ｓｐｌｉｔなどの動作を実行するために平均で２０回ほどメッセージの交換をする。
【0036】
ＳｏＳのこのような相互作用による性質は、以前にはあまり発見されることのなかった相互作用バグによるシステム失敗を誘発することがある。しかしながら、このような相互作用バグを解決するために、必要な情報を効率的に抽出して提供するのに適した技術は存在しない。さらに、システム失敗から相互作用バグを類推するまでには、高水準のシステム自体に関する背景知識を必要とする。本実施形態では、ＳｏＳ上に存在する相互作用バグを効果的に類推することのできる「失敗誘発相互作用位置推定技術」を提示する。本実施形態は、システム実行ログから相互作用モデルを生成し、失敗相互作用モデル内から共通シーケンスを抽出する方式により、相互作用バグを類推する過程に必要な情報をシステムマネージャに提供する。この技術のために、従来のＡＩ分野の自然語処理において常用されているＬｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ（ＬＣＳ）アルゴリズムを確張して提案し、システム自体ではいかなる前処理過程も必要とせず、システムログだけを入力として活用する。
【0037】
該当の技術を隊列走行システムに適用した結果、オペレーション成功率（Ｏｐｅｒａｔｉｏｎ ＳｕｃｃｅｓｓＲａｔｅ）の評価基準に達しない７つの相互作用失敗シナリオの発見に成功し、該当の相互作用バグに対する失敗環境（Ｃｏｎｔｅｘｔ）や症状（Ｓｙｍｐｔｏｍ）などをシステムログ上から直接抽出することができた。このような結果は、隊列走行システムコミュニティでは今まで報告されたことのない失敗類型であり、特定のシステムではない、一般的な隊列走行システムと関連する失敗類型としての利用が可能となる。
【0038】
以下では、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置についてより詳しく説明する。
【0039】
ソフトウェア構成要素間の相互作用は、システム複合システム（ＳｏＳ）のような複雑なシステムが目標を達成するにおいて重要な役割を担う。プラトーニング（ｐｌａｔｏｏｎｉｎｇ、隊列走行）ＳｏＳは、燃費を高めるために車両をグループとして束ね、運行プロトコルを利用して接近走行を可能にし、交通渋滞を緩和する。プラトーニングＳｏＳにおけるＬｅａｖｅやＭｅｒｇｅのような典型的な動作の実行は、平均で２０件ほどの細かな操作からなる。このような下位操作の過剰による特定の運転シーケンスの相互作用失敗は、ＳｏＳの実行時に発生することがある。また、このような失敗の根本原因の分析は、構成の相互作用の密度が高いことから多くの時間が必要となる。従来の技法には２つの限界点がある。第一に、根本原因分析技法のほとんどは相互作用データを直接活用しないため、失敗（欠陥のある）相互作用シーケンスを分離することができない。第二に、失敗診断技法のほとんどは制限的な知識によるものであり、ＳｏＳで考慮すべき「未周知の失敗」は検討しない。
【0040】
ＳｏＳで相互作用間失敗を効果的に分析するために、パターンベースの失敗相互作用分析技法を提案する。このために、先ず、ＳｏＳに対して相互作用モデルを定義し、疑わしい相互作用パターンマイニングアルゴリズムを提案する。プラトーニングシミューレータを用いた事例研究中に提案された技法は、ログから相互作用データを自動で抽出して失敗相互作用パターンを抽出することにより、報告されたことのない７つの新たな相互作用失敗シナリオを識別することができる。本実施形態から得られる結論は、プラトーニングＳｏＳのための一般的な失敗知識を豊富にできるという点にある。
【0041】
上述した従来の接近法の限界を克服するために、失敗した実行のログから最も疑わしい相互作用パターンを発掘する、パターンベースの失敗誘導相互作用分析技法を提案する。本発明の主な寄与は、次のとおりとなる。
【0042】
－各ＳｏＳ実行ログの相互作用特性と動作シーケンスを抽象化する、ＳｏＳに対する相互作用モデルを提案する。
－実施形態は、Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ（ＬＣＳ）アルゴリズムを確張して失敗相互作用パターンを自動的にマイニングする処理方式を定義する。
－ＳｏＳプラトーニングから詳細な相互作用失敗シナリオを見つけ出し、テストベンチマークおよび一般プラトーニングシステムのための失敗知識として利用する。
－実施形態は、Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ（ＬＣＳ）アルゴリズムを確張して失敗相互作用パターンを自動的にマイニングする処理方式を定義する。
－ＳｏＳプラトーニングから詳細な相互作用失敗シナリオを見つけ出し、テストベンチマークおよび一般プラトーニングシステムのための失敗知識として利用する。
【0043】
相互作用モデルとパターンマイニングアルゴリズムを適用して、ＳｔａｒＰｌａｔｅＳを利用したプラトーニングＳｏＳに対する事例研究を実施する（非特許文献３）。事例研究では、検出された失敗を３つの等級に分類し、プラトーニングＳｏＳに対する既存の知識なく、７つの詳細的な相互作用失敗シナリオを開発する。これは、プラトーニングＳｏＳに関する相互作用失敗シナリオを提供する初めての研究である。
【0044】
Ｓｔａｒ ＰｌａｔｅＳ：プラトーニングＳｏＳのための統計的検証フレームワーク
プラトーニングＳｏＳは極めて複雑なシステムであるため、信頼性のあるオペレーティングを保障するために可能な限り多くの環境で機能する必要がある。すべての可能な実際のシナリオでプラトーニングＳｏＳをテストすることには困難があるため、シミューレータが必要である。近年の多くの研究では、プラトーニングＳｏＳ（非特許文献３）のシミュレーションと検証を研究してきた。多様な動作のうちでもプラトーニング車両間の相互作用に重点を置くために、プラトーニング動作および現実的なシナリオ生成に焦点を当てたＳｔａｒＰｌａｔｅＳ（非特許文献３）をこのような目的として利用した。
プラトーニングＳｏＳは極めて複雑なシステムであるため、信頼性のあるオペレーティングを保障するために可能な限り多くの環境で機能する必要がある。すべての可能な実際のシナリオでプラトーニングＳｏＳをテストすることには困難があるため、シミューレータが必要である。近年の多くの研究では、プラトーニングＳｏＳ（非特許文献３）のシミュレーションと検証を研究してきた。多様な動作のうちでもプラトーニング車両間の相互作用に重点を置くために、プラトーニング動作および現実的なシナリオ生成に焦点を当てたＳｔａｒＰｌａｔｅＳ（非特許文献３）をこのような目的として利用した。
【0045】
ＳｔａｒＰｌａｔｅＳはＶＥＮＴＯＳ拡張フレームワークであって、現実的なシナリオを処理することのできる内外部の確実でない要素を考慮する。ＳｔａｒＰｌａｔｅＳにおいて、道路と車両の実現はＳＵＭＯシミューレータを基盤とし、車両間の通信はＯＭＮＥＴ＋＋シミューレータを基盤とする。シミューレータの統合により、ＳｔａｒｐｌａｔｅＳは、ランダムプラトーニング構成とシナリオを生成し、シナリオに対する実行ログを生成し、ログを用いてプラトーニング目標を検証する。このような脈絡において、プラトーニング構成はプラトーン生成の特性を示し、シナリオはプラトーニングＳｏＳ Ｍｅｒｇｅ、Ｓｐｌｉｔ、Ｌｅａｖｅの基本動作（ｏｐｅｒａｔｉｏｎ）順を示す。Ｍｅｒｇｅ動作の中には２つの明確なプラトーンが１つのプラトーンとして合わさる反面、Ｓｐｌｉｔ動作は正確に正反対の役割をする。Ｌｅａｖｅ動作は、メンバーがプラトーンから離れたいときに実行される。
【0046】
本実施形態では、事例研究において、シナリオの生成とシミュレーションモジュール２つをＳｔａｒｐｌａｔｅＳで使用した。シナリオ生成モジュールがランダムプラトーン構成とシナリオを生成した後、シミュレーションモジュールがＶＥＮＴＯＳシミューレータを実行し、シナリオに対する実行ログを生成する。
【0047】
スペクトラムに基づく失敗位置の測定（Ｓｐｅｃｔｒｕｍ－Ｂａｓｅｄ Ｆａｕｌｔ Ｌｏｃａｌｉｚａｔｉｏｎ：ＳＢＦ）技法
失敗ログに存在するデータに基づいて失敗を誘発する相互作用を識別するために、パターンマイニングによる失敗位置測定技法を提案する。失敗位置測定技法は、プログラマーが注意するくらいのプログラム内の疑わしい位置を正確に見つけ出す。失敗したように見えるプログラム位置のことを、疑わしい位置とする。不合格な事例を含んだすべての試験事例に対応してプログラム内の疑わしい位置のリストが作成される。
失敗ログに存在するデータに基づいて失敗を誘発する相互作用を識別するために、パターンマイニングによる失敗位置測定技法を提案する。失敗位置測定技法は、プログラマーが注意するくらいのプログラム内の疑わしい位置を正確に見つけ出す。失敗したように見えるプログラム位置のことを、疑わしい位置とする。不合格な事例を含んだすべての試験事例に対応してプログラム内の疑わしい位置のリストが作成される。
【0048】
ＳＢＦＬ技術は、各テスト事例に該当するコードカテゴリ（ｃａｔｅｇｏｒｙ）を活用して疑わしい位置を決める。プログラムスペクトラムとも呼ばれるコードカテゴリは、特定の入力に関するプログラムの実行追跡である。疑わしい位置を把握するためのＳＢＦＬ技法の基本概念は、失敗が起こった場合にプログラム位置が多く実行されるほど疑わしいものと見なされるという点にある。
【0049】
大きくて複雑なＳｏＳの場合、失敗の識別と補正は、集約的な努力の動作となる。失敗位置測定技法は、エンジニアが失敗の根本原因と発生状況を分析するために役立つため、災害対応ＳｏＳおよびソフトウェア製品群のような大規模複合システムの失敗位置を測定するために利用されてきた。しかし、本実施形態では、特に、プラトーニングＳｏＳの相互作用失敗を取り扱うことから、失敗ログから失敗相互作用を効果的に抽出するために、ＳｏＳおよびＬｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ（ＬＣＳ）ベースのパターンマイニングアルゴリズムに対する相互作用モデルを提案する。
【0050】
以下では、本実施形態に係る失敗誘発相互作用パターンマイニングについて説明する。
【0051】
全体プロセス
図２は、一実施形態における、パターンベースのＳｏＳ内の失敗誘発相互作用を分析する装置を説明するための図である。
図２は、一実施形態における、パターンベースのＳｏＳ内の失敗誘発相互作用を分析する装置を説明するための図である。
【0052】
図２を参照すると、ＳｏＳ実行ログに存在する相互作用データを処理して失敗を誘発する相互作用パターンを抽出するためのパターンベースの分析技法を提案する。一実施形態に係るパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置は、相互作用モデル生成部２１０およびパターンマイニング部２２０を含んでよい。実施形態によって、パターンベースＳｏＳ内の失敗誘発相互作用を分析する装置は、パターン分析部２３０をさらに含んでよい。また、プラトーニングＳｏＳのランダムシナリオを生成するシナリオ生成モジュール、および生成されたランダムシナリオに対する実行ログを生成するシミュレーションモジュールをさらに含んでよい。
【0053】
ここでは、実行ログと目標属性検査の通過または失敗結果という２つの入力を用いる。相互作用モデル生成部２１０は、ログに存在するデータに基づき、先ず、単一ＳｏＳの実行中に実行されるＣＳとこれらの相互作用を識別してよい。相互作用とは、通信ネットワークにキャッチされた通信追跡（例：メッセージ）のシーケンスを意味する。この後、相互作用モデル生成部２１０は、各ログの目標属性検査結果を各相互作用モデル（ＩＭ）に添付してよい。各相互作用モデルは、識別されたＣＳ集合、メッセージシーケンス、通過／失敗タグを統合して生成される。多様なドメインに対する拡張性のため外部目標検証モジュールの存在を仮定する。例えば、以降に提示された事例研究では、ＳＩＭＶＡ－ＳｏＳを用いて各実行ログを検査した。
【0054】
パターンマイニング部２２０は、生成されたモデルから疑わしいメッセージシーケンスのパターンを抽出してよい。ＳｏＳは規模が大きくて複雑であるため、ＳｏＳに単一バグが存在すると仮定することは不適切であることから、ＳｏＳは多重失敗によって困難を経験し、それぞれの失敗した相互作用モデル（ＩＭ）には１つ以上の失敗パターンが含まれると仮定する。パターンマイニング部２２０は、失敗したＩＭの各ペアの間にＬＣＳが存在するかを検索し、このようなペアを同じカテゴリに割り当ててよい。このような過程により、各カテゴリは、最終的には高い関連性をもつ、失敗したＩＭによって満たされるようになるが、これは類似の根本原因によって誘導されたものとして期待することができる。各カテゴリに該当する抽出されたＬＣＳパターンは、該当のカテゴリに属するすべてのＩＭに共通して観察される特定のメッセージの繰り返しであり、関連失敗の根本原因と発生状況を分析するために用いることができる。
【0055】
また、パターン分析部２３０は、ＳｏＳエンジニアが出力パターンを詳細に分析し、分類されたＬＣＳパターンとＩＭを分析することにより、失敗の根本原因と発生状況に対する理解を得ることができる。
【0056】
図３は、一実施形態における、パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法を示したフローチャートである。
【0057】
図３を参照すると、一実施形態に係るコンピュータ装置で実現されるパターンベースＳｏＳ（Ｓｙｓｔｅｍ－ｏｆ－Ｓｙｓｔｅｍｓ）内の失敗誘発相互作用を分析する方法は、システムの実行ログに存在するデータからＳｏＳ実行中に実行される構成システム（Ｃｏｎｓｔｉｔｕｅｎｔ Ｓｙｓｔｅｍ：ＣＳ）と相互作用を識別し、ＳｏＳに対する相互作用モデルを生成する段階Ｓ３１０、および生成された相互作用モデルとしてＬＣＳ（Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）基盤の疑わしい相互作用パターンマイニングアルゴリズムを利用して失敗を誘発する疑わしい相互作用パターンを抽出する段階Ｓ３２０を含んでよい。
【0058】
また、抽出された疑わしい相互作用パターンを分析する段階Ｓ３３０をさらに含んでよい。
【0059】
以下では、一実施形態に係るパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法の各段階について詳しく説明する。
【0060】
一実施形態に係るパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法は、例えば、図２で説明した一実施形態に係るパターンベースＳｏＳ内の失敗誘発相互作用を分析する装置によって行われてよい。
【0061】
段階Ｓ３１０で、相互作用モデル生成部２１０は、システムの実行ログに存在するデータからＳｏＳの実行中に実行される構成システム（ＣＳ）と相互作用を識別して、ＳｏＳに対する相互作用モデルを生成してよい。相互作用モデル生成部２１０は、実行ログと目標属性検査の通過または失敗結果という２つの入力を用いてＳｏＳに対する相互作用モデルを生成してよい。
【0062】
先ず、相互作用モデル生成部２１０は、実行ログに存在するデータから単一ＳｏＳの実行中に実行される構成システム（ＣＳ）と相互作用メッセージシーケンスを識別してよい。この後、相互作用モデル生成部２１０は、外部モジュールによって記録された各実行ログの目標属性検査結果である通過または失敗タグを各相互作用モデルに添付してよい。相互作用モデル生成部２１０は、識別された構成システム（ＣＳ）の集合、識別された相互作用メッセージシーケンス、および各実行ログの目標属性検査の通過状況を表示する通過または失敗タグを統合して各相互作用モデルを生成してよい。
【0063】
段階Ｓ３２０で、パターンマイニング部２２０は、生成された相互作用モデルからＬＣＳ（Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを利用して、失敗を誘発する疑わしい相互作用パターンを抽出してよい。より詳しく説明すると、パターンマイニング部２２０は、生成された相互作用モデルでＤＰ－ＬＣＳ（Ｄｙｎａｍｉｃ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）ベースの疑わしい相互作用パターンマイニングアルゴリズムを実行して、各カテゴリに共通するパターンを含むＬＣＳパターンと分類された相互作用モデルを出力してよい。
【0064】
パターンマイニング部２２０は、疑わしいＬＣＳ知識部２４０から抽出されたＬＣＳパターンと相互作用モデルとを比較し、抽出されたＬＣＳパターンと相互作用モデルとの間にＬＣＳが存在しない場合には、相互作用モデルを疑わしいＬＣＳ知識部２４０に新たなＬＣＳパターンとして追加し、抽出されたＬＣＳパターンと相互作用モデルとの間にＬＣＳが存在する場合には、相互作用モデルを疑わしいＬＣＳ知識部２４０の同じカテゴリに割り当ててよい。
【0065】
段階Ｓ３３０で、パターン分析部２３０は、抽出された疑わしい相互作用パターンを分析してよい。パターン分析部２３０は、抽出された疑わしい相互作用パターンを分析することによって分類されたＬＣＳパターンと相互作用モデルを分析し、失敗の根本原因と発生状況に関する情報を取得してよい。
【0066】
一方、一実施形態に係るパターンベースＳｏＳ内の失敗誘発相互作用を分析する方法は、シナリオ生成モジュールを利用してプラトーニングＳｏＳのランダムシナリオを生成した後、シミュレーションモジュールを利用して生成されたランダムシナリオに対する実行ログを生成してよい。
【0067】
相互作用モデルの生成
システム抽象画モデルは、システムモデルの抽象化された情報だけによって失敗の根本原因を分離することができるため、複雑なシステムの失敗分析において重要な役割を担う。例えば、従来の研究では、システム実行に対する高水準の情報を活用していた（非特許文献１および２）。参加ＣＳとこれらのコミュニケーションを抽象化していた。しかし、従来の抽象画モデルは、相互作用の内部シーケンスと実行コンテキストを含まないため、従来のモデルは相互作用－失敗分析には適合しない。失敗分析で発生状況および実行の流れのような十分な相互作用機能を活用するために相互作用モデル（ＩＭ）を定義し、実行ログで自動化されたＩＭ生成モジュールを構築する。ＩＭは、次のように定義される。
・・・（１）
システム抽象画モデルは、システムモデルの抽象化された情報だけによって失敗の根本原因を分離することができるため、複雑なシステムの失敗分析において重要な役割を担う。例えば、従来の研究では、システム実行に対する高水準の情報を活用していた（非特許文献１および２）。参加ＣＳとこれらのコミュニケーションを抽象化していた。しかし、従来の抽象画モデルは、相互作用の内部シーケンスと実行コンテキストを含まないため、従来のモデルは相互作用－失敗分析には適合しない。失敗分析で発生状況および実行の流れのような十分な相互作用機能を活用するために相互作用モデル（ＩＭ）を定義し、実行ログで自動化されたＩＭ生成モジュールを構築する。ＩＭは、次のように定義される。
【数1】
【0068】
ログＬｉで生成されたＩＭの一例であるＩＭｉは、ＣＳｉ、Ｍｉ、ｔａｇｉという３つの要素で構成される。ここで、ＣＳｉは、ログＬｉの実行中にＳｏＳに参加するｃｓｊインスタンス集合である。ｃｓｊの参加は、一般的なＳｏＳ水準目標を達成するための特定の機能を実行することで構成される。例えば、プラトーニングＳｏＳでは、プラトーニング動作を実行する車両を参加ＣＳとして表示した。
【0069】
また、Ｍｉは、Ｌｉの実行中に伝達されるＬｉの長さとともに、順序が定められたメッセージ順序を示す。すなわち、Ｍｉは、Ｌｉで実行されるシーケンス図表の形式的な表現である。Ｍｉの各メッセージｍｓｇｋは、ＳｏＳ相互作用機能のベクトルを支援する。ＳｏＳから相互作用特性を抽出するために、自律車両、通信システム、ウェブサービスなどのような多様な領域で相互作用と通信の特性を識別した従来の研究を参照することができる。
【0070】
表１は、メッセージベースの相互作用とその類型を示すために用いられる特性を示している。
（表１）
（表１）
【表1】
【0071】
表１を参照すると、持続性（Ｃｏｎｔｉｎｕｉｔｙ）特性（ｆｅａｔｕｒｅ）は、送信者が単一メッセージ（一時通信、ＴＣ）またはメッセージストリーム（連続通信、ＣＣ）を送るか否かを決める。同期化（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）は、伝達されたメッセージが同期式（Ｓｙｎｃ）であるか非同期式（Ａｓｙｎｃ）であるかを決める。持続性と同期化特性は、ＣＳ間の同時性属性をともにキャッチする。開始エンティティ（Ｉｎｉｔｉａｔｉｎｇ Ｅｎｔｉｔｙ）および受信エンティティ（Ｒｅｃｅｉｖｉｎｇ Ｅｎｔｉｔｙ）はそれぞれ、すべてのメッセージの発信者と受信者を示す。コンテンツ（Ｃｏｎｔｅｎｔ）特性は、メッセージの内容を説明し、ＩＭにメッセージの送信および受信時間を記録するために開始時間（Ｓｔａｒｔ Ｔｉｍｅ）、終了時間（Ｅｎｄ Ｔｉｍｅ）、およびディレイ（Ｄｅｌａｙ）を用いる。コンテンツ特性の例示的な値には、ＬＥＡＶＥ＿ＲＥＱ、ＬＥＡＶＥ＿ＡＣＣＥＰＴのようにプラトーニング動作プロトコルに定義された１７個のマイクロ命令が含まれる。コンテンツ特性は、ＣＳ間のインタフェース衝突および目標衝突のような特定の類型の衝突を評価するために用いられてよい。開始エンティティおよび受信エンティティとコンテンツ特性は、開始エンティティと受信エンティティとの関係を分析し、システムオペレーティング中に直接／間接的なリソースの衝突を評価するために使用されてよい
【0072】
相互作用モデルの最後の構成要素はｔａｇｉである。各実行ログは、ＳｏＳの特定の目標を満たしているかによって評価されてよい。ｉ番目の実行ログに該当する目標満足度結果、通過、または失敗は、ｔａｇｉに割り当てられる。
【0073】
上述したＩＭ生成モジュールを実現したが、このモジュールは、Ｌｉの参加ＣＳと相互作用特性を自動的に識別する。識別後、モジュールは、各ＩＭｉにｔａｇｉを付着する。外部モジュールは、Ｌｉが特定の目標を通過するかを記録する。この後、通過または失敗結果は、ＩＭｉのｔａｇｉに格納される。
【0074】
ＤＰ－ＬＣＳベースのパターンマイニングアルゴリズム
次の段階には、ＤＰ－ＬＣＳ（Ｄｙｎａｍｉｃ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）アルゴリズムによる疑わしい相互作用シーケンス（ｓｕｓｐｉｃｉｏｕｓ ｉｎｔｅｒａｃｔｉｏｎ ｓｅｑｕｅｎｃｅ）のマイニングプロセスが含まれる。
次の段階には、ＤＰ－ＬＣＳ（Ｄｙｎａｍｉｃ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｌｏｎｇｅｓｔ Ｃｏｍｍｏｎ Ｓｕｂｓｅｑｕｅｎｃｅ）アルゴリズムによる疑わしい相互作用シーケンス（ｓｕｓｐｉｃｉｏｕｓ ｉｎｔｅｒａｃｔｉｏｎ ｓｅｑｕｅｎｃｅ）のマイニングプロセスが含まれる。
【0075】
表２は、疑わしい相互作用パターンマイニングアルゴリズムを示している。
（表２）
（表２）
【表2】
【0076】
表２を参照すると、アルゴリズム１は、失敗を誘発する相互作用を分離して分類するＤＰ－ＬＣＳベースのマイニングアルゴリズムを示している。ここで、各ＩＭの単一実行内において、ＳｏＳに複数の失敗と複数の失敗相互作用パターンが存在すると仮定する。実施形態は、（１）従来のカテゴリに与えられたＩＭを追加し、（２）ＩＭで新たなカテゴリを生成する次のような分岐に基づいてアルゴリズムを構成する。５～７行はＩＭ－追加の事例を説明している。アルゴリズムは、ＩＭと従来のＬＣＳパターンとの間にＬＣＳが存在するときには、従来のカテゴリにＩＭを追加するものと決める。５行は意思決定過程を示している。共通する相互作用が存在する場合、与えられたＩＭはカテゴリに割り当てられ、更新されたカテゴリの相互作用パターンは与えられたＩＭを含んで新たに抽出される。各ＩＭは、上述したような条件を満たす複数の付属パターンをもつ場合、多数のカテゴリに割り当てられてよい。８～９行は、ＩＭと知識ベース内の従来のパターンとの間にＬＣＳが存在しない場合に対するカテゴリの生成過程を示している。この場合、ＩＭは新たなカテゴリに追加され、メッセージ順序Ｍは、先ずは該当のカテゴリの新たなパターンに割り当てられる。
【0077】
ＬＣＳ生成アルゴリズムは、アルゴリズム２に詳しく説明されている。
【0078】
表３は、ＬＣＳ生成アルゴリズムを示している。
（表３）
（表３）
【表3】
【0079】
表３を参照すると、Ｏ（Ｓｉｚｅｐ＊Ｓｉｚｅｋ）の実現可能な性能を示すために、動的プログラミング（ＤＰ）ソリューションを用いてＬＣＳを生成する。ＬＣＳ生成アルゴリズムは、６～１７行までのように、２つのＩＭを比較してＬＣＳテーブルを生成することから始まる。１８～２４行は、表で共通して観察されるメッセージのシーケンスを抽出する過程を示している。アルゴリズムの基本的な流れは、文字列の従来のＤＰ－ＬＣＳアルゴリズムと類似する。従来のアルゴリズムは、文字列のすべての文字を比較してＬＣＳを生成する。文字列に基づく比較マトリックをＩＭのメッセージ比較マトリックに確張する。２８～３３行で定義するように、持続性、同期化、発信者および受信者、さらに２つのメッセージのコンテンツ特性が同一値を共有する場合、２つのメッセージは同じものと見なされる。同じメッセージがシミュレーション中に互いに異なる時間に伝達されることがあるため、比較のために時間関連の特性は使用しない。Ｓｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒ比較の場合にも同じような問題が存在する。これを解決するために、車両ＩＤのような具体的なＣＳインスタンスではない、ＦｏｌｌｏｗｅｒやＬｅａｄｅｒなどのような抽象的なＣＳクラスによるＳｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒを比較する。抽象クラスは、ＳｏＳの役割の類型によって定義されてよい。提案されたアルゴリズムの実現は格納場所に含まれてよい。
【0080】
すなわち、提案されたアルゴリズムは、各カテゴリに共通するパターンを含む一連のＬＣＳパターンと分類されたＩＭを返還する。失敗のコンテキストと関連する疑わしいパターンは、ＳｏＳエンジニアがカテゴリの失敗を分析して発生状況と根本原因を理解するのに役立つ。
【0081】
適用事例に基づく深層分析
図４ａ～ｃは、一実施形態における、プロセス、相互作用モデル構造、およびアルゴリズム出力を説明するための例示図である。より詳しく説明すると、図４ａは一実施形態に係る実行ログの生成を説明するための図であり、図４ｂは一実施形態に係る相互作用モデルの構造を説明するための図であり、図４ｃは一実施形態に係るアルゴリズムの出力の一例を説明するための図である。
図４ａ～ｃは、一実施形態における、プロセス、相互作用モデル構造、およびアルゴリズム出力を説明するための例示図である。より詳しく説明すると、図４ａは一実施形態に係る実行ログの生成を説明するための図であり、図４ｂは一実施形態に係る相互作用モデルの構造を説明するための図であり、図４ｃは一実施形態に係るアルゴリズムの出力の一例を説明するための図である。
【0082】
図４ａに示すように、ＳｏＳのログを勘案するときに提案された技法は、先ず、ｉ番目の実行と関連するシステムの痕跡を含む各ログＬｉに該当する相互作用モデルＩＭｉを自動で生成する。相互作用モデルＩＭｉの構造は図４ｂに示すとおりであり、この例において、ＩＭ０には４つのメッセージＭ０、４つの参加ＣＳ（ＣＳ０）、および通過タグｔａｇ０の順序が含まれている。Ｍ０の各メッセージは、表１に説明されている特定の特性で構成されたベクトルである。この例では、ｍｓｇ０が次のような値で構成されることを示している。ＴＣ、Ｓｙｎｃ、送信者Ａおよび受信者Ｂ、ＳＰＬＩＴ＿ＲＥＱコンテンツ、および時間値２０１９／１２／２４：０００００００００、２０１９／１２／２４：０００１５９０００、１５９０００。これは、ｍｓｇ０が１５９，０００ｍｓの遅延により、時間的、同期化メッセージとしてＡからＢにＳＰＬＩＴ＿ＲＥＱを伝達するために送信されるということを支援する。
【0083】
生成された相互作用モデルを使用することで、この技術はＤＰ－ＬＣＳベースの疑わしい相互作用パターンマイニングアルゴリズムを実行する。図４ｃに示すように、このアルゴリズムの出力は、すべての疑わしいＬＣＳパターン、分類されたＩＭ、および感知カウントのように後続分析のための追加情報によって構成された知識テーブルである。この例では２つのＬＣＳパターンが並べられる。１つ目のメッセージであるＬＣＳ０は３つのメッセージで構成され、このパターンは３５個のＩＭｓ－ＩＭ１、ＩＭ９、・・・、ＩＭｎ－１で観察される。２つ目の疑わしいパターンであるＬＣＳ１は、４つのメッセージのシーケンスとして、１３個の異なるＩＭから検出される。
【0084】
この技法の最後の段階には、ＳｏＳエンジニアの結果分析が含まれる。図４ｃに示すような出力表の各行には、分類されたＩＭと該当のＬＣＳパターンが含まれており、ＳｏＳで相互作用失敗を引き起こすことがある。すなわち、各行は独立的なカテゴリを示し、カテゴリＩＭは特定の相互作用失敗を引き起こす差別的な相互作用を含む。ＳｏＳエンジニアが出力を活用することにより、検出された相互作用失敗を極めて詳細に分析することができる。
【0085】
以下では、本発明の実施形態に係る事例研究について説明する。
【0086】
本件の事例研究の目標は、プラトーニングシミュレーションおよび検証フレームワークであるＳｔａｒＰｌａｔｅＳ（非特許文献３）を用いて提案された技法の効果を立証して、プラトーニングＳｏＳで未周知の失敗相互作用を分析することにある。この技法を評価するために、次のような研究質問を使用する。
【0087】
１）ＲＱ１．提案された技法は、コンテキストと相互作用を十分に理解するなど、疑わしいパターンを効果的に抽出しているか？
２）ＲＱ２．ＳｏＳエンジニアは、マイニング結果を活用してプラトーニングＳｏＳの失敗シナリオを分析することができるか？
２）ＲＱ２．ＳｏＳエンジニアは、マイニング結果を活用してプラトーニングＳｏＳの失敗シナリオを分析することができるか？
【0088】
ＲＱ１は、ＤＰ－ＬＣＳベースのパターンマイニング結果の高水準の分析を目標とする。この質問に答えるために、抽出された相互作用パターンの詳細なコンテキストと実行の流れを分析した。ＲＱ２は、カテゴリを詳細なシナリオ事例に細分化して技法の実用性を判断するためのものである。実務的に高度な分析結果に基づいて各ＩＭに対する調査を手動で実施し、プラトーニングＳｏＳから７つの相互作用失敗シナリオを確認した。
【0089】
この事例研究では、シナリオ生成モジュールとシミュレーションモジュールという２つのＳｔａｒＰｌａｔｅＳモジュールを使用した。このモジュールを利用してプラトーニングＳｏＳのランダムシナリオを生成し、これに相応する実行ログを生成した。提案された技法も、各ログに対する目標属性検査結果を要求する。ＳＩＭＶＡ－ＳｏＳにある検証モジュールを修正して独立的な目標検証モジュールを構築した。プラトーニングシステムの正確な動作実行評価において最も関連性が高いものとして、ＳｔａｒＰｌａｔｅＳで次の式のような基準を選択した。
・・・（２）
【数2】
【0090】
この基準は、シミュレーションで成功的に実行される、要請された動作回数を決める。例えば、プラトーン内（ｉｎ）または中間（ｂｅｔｗｅｅｎ）で１０回の動作（ｏｐｅｒａｔｉｏｎ）を要請し、１０回のうち９回の動作が成功的に実行されれば、シミュレーションのｏｐ成功率は９０％となる。
【0091】
事例研究のためのプラトーニングシナリオの詳しい設定について次のように説明する。生成されたシナリオの総数は６００個であり、単一シミュレーションの持続時間（ｄｕｒａｔｉｏｎ）は１００秒であり、生成されたプラトーンの数は２４であり、プラトーン規模は２～６台の車両である。また、環境客体は、５秒ごとに１台ずつＨＤＶ（Ｈｕｍａｎ－Ｄｒｉｖｅｎ Ｖｅｈｉｃｌｅ、人間運転車両）を生成する。
【0092】
合計６００個のシナリオを１００秒間にランダムで生成して単一シミュレーションに使用した。すべてのシミュレーションで生成されたプラトーンの数は２～４個までランダムに決められ、大きさは２～６台までランダムに割り当てられた。また、プラトーンには連結しない、車線と速度を任意に変更するＨＤＶ用生成器を定義した。生成器は５秒ごとにＨＤＶをシミュレーションに追加した。この後、ログに基づく６００個のＩＭを生成し、提案されたアルゴリズムを利用して疑わしい相互作用パターンを抽出した。以下では、マイニングと分析結果について詳しく説明する。
【0093】
ＲＱ１に適切に答えるために、先ず、ｏｐ成功率を基準とした観点において、６００個のシミュレーションシナリオに該当するマイニング結果を分析した。成功率の閾値は８０％に設定し、失敗したシナリオ２５８個からＬＣＳを抽出した。マイニング結果は、ｏｐ成功率と関連する失敗に３つのパターンカテゴリが存在することを示した。（１）失敗カテゴリの根本原因と（２）失敗した実行のコンテキストを把握するためにパターンを極めて詳しく調査した。
【0094】
図５は、一実施形態における、相互作用シーケンスの代表的なＬＣＳパターンの抽出を示した図である。
【0095】
図５には、各カテゴリに該当する疑わしい相互作用のシーケンスパターンが示されている。緑色の領域には失敗シナリオの理解を助けるために実行コンテキストを示し、赤色領域では失敗後の隠れた根本原因に対する手がかりを提供する。
【0096】
３つのＬＣＳパターンすべてで併合動作を含むことが観察された。各パターンは、カテゴリ１の５～７行まで、カテゴリ２の９と１２～１４行まで、カテゴリ３の１０と１２～１４行までのように、同じ車両から最小３つのＭｅｒｇｅ要請を有する。ｏｐ成功率は、要請されたすべての動作中に実行された動作の割合を示すため、持続して要請された動作は、受信者に他の動作の適切な実行と反応時間に否定的な影響を及ぼす。Ｓｐｌｉｔ動作はＬＣＳパターンにも共通的である。カテゴリ１で最初に報告されたメッセージは、ｖ１からｖ２へのＳｐｌｉｔ要請である。カテゴリ２と３では２つ目のメッセージが観察され、Ｓｐｌｉｔ動作を要請する。この２つの共通点に基づき、オペレーティングプロトコルが対象プラトーニングＳｏＳの特定の問題によって困難を経験していたし、このような問題はＳｐｌｉｔおよびＭｅｒｇｅ動作と高い相関関係があると結論付けられた。
【0097】
カテゴリ１の疑わしい相互作用パターンは、図５に示すように、７つの順次メッセージで構成される。最初の２つのメッセージにはＳｐｌｉｔとＭｅｒｇｅの同時要請が記録された。１行目は、リーダー車両ｖ１が後続車両ｖ２にＳｐｌｉｔ要請を送信したことを示し、２行目は、後方プラトーンであるｖ５が前方プラトーンにＭｅｒｇｅを要請したことを示す。
【0098】
図６ａ～６ｃは、一実施形態における、カテゴリ１パターンの実行の流れを示した例示図である。
【0099】
図６ａ～ｃには、カテゴリ１と関連する失敗パターンが示されている。このシナリオの問題は、図６ａに示すように、Ｓｐｌｉｔ動作要請としてｖ５（６２１）の前方プラトーン６１０がｖ１（６１１）からｖ２（６１２）に変更したという点である。この場合、図６ｂに示すように、後方の全面リーダーであるｖ５（６２１）がＭｅｒｇｅをｖ１（６１１）に要請し続けても実行がなされない。また、図６ｃに示すように、Ｓｐｌｉｔ動作後にも後方全面リーダーであるｖ５（６２１）がｖ１（６１１）にＭｅｒｇｅを要請し続けても実行がなされない。したがって、観測された失敗のうちの１つがプロトコルの運転要請論理に関連付けられるようになり、この失敗はＳｐｌｉｔとＭｅｒｇｅの同時要請によって触発したものであるという結論を導き出すことができる。
【0100】
図７ａ～ｅは、一実施形態における、カテゴリ２パターンの実行の流れを示した例示図である。
【0101】
図７ａ～ｅには、カテゴリ２と関連する失敗パターンが示されている。カテゴリ２のパターンでは、同じ車線に２つのプラトーン、すなわち、リーダーｖ１（７１１）が位置する前方プラトーン１（７１０）とリーダーｖ５（７２１）が位置する後方プラトーン２（７２０）が存在する。この場合、ｖ５（７２１）は、ｖ３（７１３）にＭｅｒｇｅ要請を送信し続けた。
【0102】
図７ａに示すようなパターンにおいて、前方プラトーン７１０のフォロワーの１つであるｖ２（７１２）が、図５の１～３行に示すようにＬｅａｖｅ動作を要請する。図７ｂに示すように、ＦｏｌｌｏｗｅｒＬｅａｖｅ動作は、対象プラトーニングオペレーティングプロトコルの３つの段階で構成される。すなわち、Ｓｐｌｉｔ、Ｌｅａｖｅ、およびＭｅｒｇｅである。先ず、図７ｂに示すように、ｖ２（７１２）がＬｅａｖｅを要請したため、ｖ３（７１３）とｖ４（７１４）は４～８行で新たなプラトーンとして分断された。この後、急に、後方プラトーン７２０が分断されたプラトーンにＭｅｒｇｅ要請を送信した。しかし、分断されたプラトーンは、ｖ２（７１２）が離れた後、本来のリーダーｖ１（７１１）と再併合しなければならなかった。ここで問題となるのは、図７ｄに示すように、後方プラトーン７２０であるｖ５（７２１）が、ＭＥＲＧＥ＿ＲＥＱが含まれたメッセージを、中間プラトーンであるｖ３（７１３）に伝達し続けたという点にある。ｖ５（７２１）の持続的なＭｅｒｇｅ要請が、最適な大きさで構成されることが理由となることを把握することができる。図７ｅに示すように、後方プラトーン７２０の大きさが最適なサイズよりも小さく、後方プラトーン７２０の大きさと中間プラトーンの大きさを合わせたものが最適な大きさと偶然に同じである場合、後方プラトーン７２０はＭｅｒｇｅ要請を中間プラトーンに継続して伝達することが観察される。
【0103】
図８ａ～ｄは、一実施形態における、カテゴリ３パターンの実行の流れを示した例示図である。
【0104】
図８ａ～ｄには、カテゴリ３と関連する失敗パターンが示されている。カテゴリ３では、ｖ１（８１１）～ｖ４（８１４）までの車両が単一プラトーン８１０を構成している。フォロワーの１つであるｖ３（８１３）がｖ１（８１１）とｖ２（８１２）に要請を送信した。
【0105】
図８ａおよび図８ｂに示すように、最終ＬＣＳパターンはＬｅａｖｅ動作から始まることが観察される。図５のカテゴリ３にある１～５行までは、ｖ２（８１２）がＬｅａｖｅを要請し、図８ｃおよび図８ｄに示すように、後方車両であるｖ３（８１３）とｖ４（８１４）が中間プラトーンとして分断されてＬｅａｖｅ動作を実行したことを示している。図示されていないが, このパターンの差別的な特性は、中間プラトーンであるｖ３（８１３）が、離れた車両ｖ２（８１２）にＭｅｒｇｅ要請を送信したという点にある。当初は、ｖ１（８１１）が、本来のプラトーンに再併合できるように要請を送信することが予想された。しかし、ｖ３（８１３）は、リーダーｖ１（８１１）と離れた車両ｖ２（８１２）の両方にメッセージを送信した。この場合を説明するために、最適な大きさ設定が異なるシミュレーションで類似の事例を再現した。重複する併合要請は、最適な大きさまたはＬｅａｄｅｒ／ＦｏｌｌｏｗｅｒＬｅａｖｅ設定とは関係なく、外部車両に送信されたことが確認された。この失敗事例は、３台以上の車両で構成されたプラトーンでＦｏｌｌｏｗｅｒＬｅａｖｅ動作が実行されるときによく観察される。
【0106】
ＲＱ２に答えるために各カテゴリ内のＩＭを追加で分析し、従来のカテゴリで７つの失敗シナリオを細分化した。前提条件、実行の流れ、例示、抽出されたパターンなどのような７つのシナリオの詳細な失敗報告書が開発された。この分析は、制限的な知識を有するＳｏＳエンジニアが、提案された接近方法によって提供されるデータを満足に活用できることを示している。
【0107】
表４では、分析の詳細事項を提示する。
（表４）
（表４）
【表4】
【0108】
例えば、表４に示す３つの異なる事例（同時Ｓｐｌｉｔ＆Ｍｅｒｇｅ、ＯｐｔＳｉｚｅＣｈａｎｇｅ＆Ｍｅｒｇｅ、ＬｅａｄｅｒＬｅａｖｅ＆Ｍｅｒｇｅ）が、カテゴリ１の失敗を引き起こすことがある。カテゴリ１に属するＩＭで、このような具体的なシナリオの事例を観察した。同じように、カテゴリ２と３で、２つの類型の相互作用失敗シナリオであるＬｅａｄｅｒＬｅａｖｅおよびＦｏｌｌｏｗｅｒＬｅａｖｅを識別した。ここで、７つの失敗シナリオを詳細に記録し、この研究で考慮したプラトーニングＳｏＳに対する失敗報告書に整理した。上述した失敗シナリオは、以前にはＶＥＮＴＯＳまたはその他の関連プラトーニングシミューレータの格納場所に対して報告されたことがない。報告された失敗シナリオはテストベンチマークとして利用され、一般のプラトーニングシステムのための失敗知識データベースを強化させることが予想される。詳しい失敗報告書は格納場所に含まれてよい。
【0109】
多様なシステムドメインに対する徹底した調査に基づいて相互作用の特性を定義したにもかかわらず、本研究で考慮された特性がＳｏＳで可能なすべての類型の失敗を分析するのに十分であるとは結論を付け難い。特定の例外的な失敗事例は、外部の根本原因によって誘導される。例えば、プラトーニングＳｏＳシミュレーションにおいて、人間運転車両（ＨＤＶ）部分で多重衝突関連の失敗が観察される。しかし、ＶＥＮＴＯＳは、事例研究に用いられたプラトーニングシミューレータはプラトーニング動作の内部マイクロ命令だけを記録してセンサレベル情報は記録しないため、衝突の背景で外部原因を識別するのに十分な情報を提供することができない。今後の動作では外部要因による失敗も勘案し、相互作用モデルとシミューレータを一般化することを心がける。
【0110】
大規模システム、特に、プラトーニングＳｏＳにおける相互作用の失敗を報告した最初の研究となった。その結果、検討中のプラトーニングＳｏＳに対して適切なテストベンチマークを得ることができず、実行ログ、オラクルおよび失敗シナリオ、および該当の原因に対するデータを提供することができなかった。したがって、今回の事例研究では、相互作用の失敗に対する出力および生成された失敗知識を手動で調査した。今回の研究で得られた失敗知識は、今後の研究において、プラトーニングＳｏＳのためのベンチマークや一般的な失敗知識として活用されることを期待する。
【0111】
経験的価値が８０％であるｏｐ成功率属性も活用した。プラトーニングシステムをシミュレーションして検証した研究を調査したが、そのほとんどが、模擬実験が終わるまでプラトーンをメンテナンスするとか単一運転実行の検証などのように、プラトーンに対する基本的なテスティング基準を使用した。その代わりに、ＩＳＯ２６２６２のような国際標準に基づいてプラトーニングＳｏＳに対する説得力のある属性を生成することを試みた。しかし、近年の一部の研究では、ＩＳＯ２６２６２のような従来の標準は自律走行に焦点を合わせており、プラトーニングＳｏＳの要件を完全に満たしていないと報告されている。本実施形態に係る研究では、クラウドシステムのテスティングで用いられた成功要請率（ＰＳＲ）に基づいてオペレーティング成功率をベンチマーキングすることにより、小隊システムのシミュレーションログに適用できるように修正した。
【0112】
このように、該当の技術の対象である大規模複合システム「ＳｏＳ」は、４次産業革命後の国際標準登録および多様な例示であり、次世代システム類型として注目されている。代表的な例としては、スマートホーム、スマートシティー、スマートプラント、知能型交通システム、災難対応システムなどが挙げられる。この技術は一般的なＳｏＳを対象にして生成され、システムで必要な主な入力値がシステム実行記録であるという点において適用－応用分野が広範囲であると見なすことができる。
【0113】
スマートホームや知能型交通システムなどのような大規模複合システムが次世代システムの類型として位置づけられている中、大規模複合システム内において多様な異種（Ｈｅｔｅｒｏｇｅｎｅｏｕｓ）システム間に発生し得る相互作用バグをデザイン水準で事前に対応することは、現実的には不可能である。さらに、大規模複合システムが失敗を起こした場合に発生し得る被害影響は、利用者が感じる単なる不便さから、人命に大きな影響を与えるケースまで存在する。したがって、大規模複合システムに存在する相互作用バグを効率的かつ効果的に解決する技術は、システムが販売されて利用される前に必ず必要となる。
【0114】
大規模複合システムは、単一システムが達成することが不可能だった目標を達成可能にするシステムであり、多様な分野で活用可能である。このようなシステムを生成するためには多くの努力が必要となるが、システム内に存在する失敗を解決することにも膨大な費用がかかる。この技術は、大規模複合システム内で予測外に起こる相互作用バグを解決するのに必要となる、人的または時間的資源を節減することができる。
【0115】
上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。
【0116】
ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。
【0117】
実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。前記コンピュータ読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであっても、コンピュータソフトウェアの当業者に公知な使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピディスク、磁気テープのような磁気媒体、ＣＤ－ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を記録して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。
【0118】
以上のように、実施形態を、限定された実施形態および図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。
【0119】
したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【図1】
【図2】
【図3】
【図4a】
【図4b】
【図4c】
【図5】
【図6a】
【図6b】
【図6c】
【図7a】
【図7b】
【図7c】
【図7d】
【図7e】
【図8a】
【図8b】
【図8c】
【図8d】
