KR102643598B1 - 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치 - Google Patents

패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치 Download PDF

Info

Publication number
KR102643598B1
KR102643598B1 KR1020200183097A KR20200183097A KR102643598B1 KR 102643598 B1 KR102643598 B1 KR 102643598B1 KR 1020200183097 A KR1020200183097 A KR 1020200183097A KR 20200183097 A KR20200183097 A KR 20200183097A KR 102643598 B1 KR102643598 B1 KR 102643598B1
Authority
KR
South Korea
Prior art keywords
pattern
sos
interaction
lcs
failure
Prior art date
Application number
KR1020200183097A
Other languages
English (en)
Other versions
KR20220091897A (ko
Inventor
배두환
현상원
Original Assignee
한국과학기술원
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 한국과학기술원 filed Critical 한국과학기술원
Priority to KR1020200183097A priority Critical patent/KR102643598B1/ko
Priority to JP2021164887A priority patent/JP7299640B2/ja
Publication of KR20220091897A publication Critical patent/KR20220091897A/ko
Application granted granted Critical
Publication of KR102643598B1 publication Critical patent/KR102643598B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/26—Visual data mining; Browsing structured data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/213—Feature extraction, e.g. by transforming the feature space; Summarisation; Mappings, e.g. subspace methods
    • G06F18/2132—Feature extraction, e.g. by transforming the feature space; Summarisation; Mappings, e.g. subspace methods based on discrimination criteria, e.g. discriminant analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Geometry (AREA)
  • Computer Hardware Design (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치가 제시된다. 일 실시예에 따른 컴퓨터 장치를 통해 구현되는 패턴 기반 SoS(System-of-Systems) 내 실패 유발 상호작용 분석 방법은, 시스템의 실행 로그에 존재하는 데이터로부터 SoS 실행 중 실행되는 구성 시스템(Constituent System, CS)과 상호작용을 식별하여, SoS에 대한 상호작용 모델을 생성하는 단계; 및 생성된 상기 상호작용 모델에서 LCS(Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 이용하여 실패를 유발하는 의심스러운 상호작용 패턴을 추출하는 단계를 포함하여 이루어질 수 있다.

Description

패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치{METHOD AND APPARATUS FOR ANALYZING PATTERN-BASED INTERACTION FAILURES IN SYSTEMS-OF-SYSTEMS}
아래의 실시예들은 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치에 관한 관한 것이다.
최근, 플래투닝(platooning, 군집운행) 시스템 복합시스템은 연비와 교통 혼잡에 긍정적인 영향을 미치면서 다양한 환경 및 사업상의 편익으로 이어져 연구에 큰 관심을 받고 있다. 여기서, 시스템 복합시스템은 시스템 오브 시스템즈(System-of-Systems, 이하 SoS)를 의미한다. SoS는 단일 CS로는 달성할 수 없는 공통 목표를 달성하기 위해 독립 구성 시스템(CS)으로 구성된 복잡하고 이질적인 시스템이다. 플래투닝 SoS는 차량을 근접하게 하나의 유닛으로 그룹화하여 동작하며, Leave 및 Merge와 같은 운영 프로토콜을 사용하여 관리하여 SoS 레벨 목표를 달성한다. SoS의 특성 중 하나는 대부분의 SoS 레벨 조작은 CS들 간의 복잡한 상호작용을 수반한다는 것이다. 이러한 특성 때문에 상호작용의 특정 실패 순서에 의해 야기되는 상호작용 실패라고 불리는 특정 유형의 실패가 존재한다.
다이믈러(메르세데스-벤츠 트럭), 볼보, 현대 등 많은 글로벌 기업이 실제 도로에서 플래투닝을 동작하는 데 성공했지만, 가능한 모든 상호작용에 관해서도 이처럼 고도로 복잡한 소프트웨어의 무장애 기능을 보장하기는 어렵다.
도 1은 일반적인 플래투닝 SoS에서의 상호작용 실패의 예시를 나타내는 도면이다.
도 1을 참조하면, 플래투닝 SoS에서 동시에 Leave 및 Merge 요청에 의해 유발되는 상호작용 실패의 예시를 나타내며, 플래툰-1(110)에는 리더 v1(111), v2(112) 및 v3(113)이 포함되고, 플래툰-2(120)에는 리더 v5(121) 및 v6(122)가 포함된다. 여기서, 플래툰-1(110)의 리더 v1(111)은 플래툰을 떠나려 하지만 플래툰-2(120)의 리더 v5(121)는 v1(111)의 Leave 조작이 완료되기 전에 v1(111)로 Merge 요청을 전송한다. 이러한 상황은 Merge 동작의 정상적인 실행을 억제하고 진행 중인 Leave 동작의 실행 시간에 부정적인 영향을 미친다. SoS가 상호작용 실패 없이 동작하기 위해서는 근본적 실패를 유발하는 상호작용을 사전에 체계적으로 파악하고 분석하는 것이 중요하다.
최근의 연구에서는 대규모 시스템에서 가장 의심스러운 실패(failure) 구성요소를 분리하기 위해 스펙트럼 기반 실패 위치 측정(Spectrum-based Fault Localization, SBFL)을 적용했다. Shin(비특허문헌 1)은 재난대응 SoS에 SBFL 기법을 적용하여 그 안에 주입된 실패를 식별하였다. 또한, Arrieta는 SBFL 기술을 적용하여 소프트웨어 제품군에서 가장 의심스러운 기능을 위치 측정했다. 그러나 기존 기법은 의심스러운 상호작용 시퀀스를 식별하는 데 있어 특정 한계로 인해 어려움을 겪는다. 첫째, 이 기법은 근본 원인을 분석하기 위해 상세한 상호작용 데이터를 직접 활용하지 않는다. 대신, 참여자 CS와 같은 시스템으로부터 고도의 정보만을 추출하고, CS 간의 연결의 존재만을 추출한다. 둘째로, 상호작용 시퀀스의 조합의 무한한 수 때문에 SBFL을 적용하여 실패 상호작용 시퀀스(faulty interaction sequence)를 추출하는 것은 불가능하다.
다른 기존 연구들은 SoS의 근본 원인을 진단하기 위해 머신러닝 기법을 적용하는 데 초점을 맞추었다. Kleyko(비특허문헌 2)는 원전의 매트릭스 기반 추상화 모델을 구축하고, 실패 지식 기반에 기초한 패턴을 효율적으로 일치시키기 위한 초차원 벡터 기반 진단 접근법을 제안했다. Cai는 반복적이고 작은 구성요소로 구성된 시스템에 적합한 빠른 Object-Oriented Bayesian Network(OOBN) 모델을 제안했다. 그들은 해저 생산 시스템을 위한 OOBN 기반의 실패 진단 모델을 개발했다. 이러한 기법에 공통되는 일차적인 제한은 각 시스템의 "알려진 실패(known faults)"만을 고려한다는 것이다. SoS에서 각 CS는 운영 및 관리 독립성 때문에 블랙박스 시스템으로 간주된다. 그러나 기존 기법은 SoS의 제한된 지식과 높은 복잡성에 의해 야기될 수 있는 "알 수 없는 실패(unknown faults)"이라고 불리는 잠재적 위험을 설명하지 않는다.
Y.-J. Shin, S. Hyun, Y.-M. Baek, and D.-H. Bae, "Spectrum-based fault localization on a collaboration graph of a system-of-systems," in 2019 14th Annual Conference System of Systems Engineering (SoSE)(SoSE2019), Anchorage, USA, 2019. D. Kleyko, E. Osipov, N. Papakonstantinou, and V. Vyatkin, "Hyperdimensional computing in industrial systems: the use-case of distributed fault isolation in a power plant," IEEE Access, vol. 6, pp. 30766-30777, 2018. S. Hyun, J. Song, S. Shin, and D.-H. Bae, "Statistical verification framework for platooning system of systems with uncertainty," in 2019 26th Asia-Pacific Software Engineering Conference (APSEC), pp. 212- 219, IEEE, 2019.
실시예들은 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치에 관하여 기술하며, 보다 구체적으로 효과적으로 SoS 상에 존재하는 상호작용 버그를 유추할 수 있는 실패 유발 상호작용 위치 추정 기술을 제공한다.
실시예들은 시스템 실행 로그로부터 상호작용 모델을 생성하고, 상호작용 모델 내에서의 공통 시퀀스를 추출하는 방식으로 상호작용 버그를 유추하는 과정에 필요한 정보들을 시스템 매니저에게 제공하는 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치를 제공하는데 있다.
일 실시예에 따른 컴퓨터 장치를 통해 구현되는 패턴 기반 SoS(System-of-Systems) 내 실패 유발 상호작용 분석 방법은, 시스템의 실행 로그에 존재하는 데이터로부터 SoS 실행 중 실행되는 구성 시스템(Constituent System, CS)과 상호작용을 식별하여, SoS에 대한 상호작용 모델을 생성하는 단계; 및 생성된 상기 상호작용 모델에서 LCS(Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 이용하여 실패를 유발하는 의심스러운 상호작용 패턴을 추출하는 단계를 포함하여 이루어질 수 있다.
추출된 상기 의심스러운 상호작용 패턴을 분석하는 단계를 더 포함할 수 있다.
상기 SoS에 대한 상호작용 모델을 생성하는 단계는, 상기 실행 로그와 목표 속성 검사의 통과 또는 실패 결과라는 두 가지 입력을 사용하여 상기 SoS에 대한 상호작용 모델을 생성할 수 있다.
상기 SoS에 대한 상호작용 모델을 생성하는 단계는, 상기 실행 로그에 존재하는 데이터로부터 단일 SoS 실행 중 실행되는 구성 시스템(CS)과 상호작용 메시지 시퀀스를 식별하는 단계를 포함할 수 있다.
상기 SoS에 대한 상호작용 모델을 생성하는 단계는, 외부 모듈을 통해 기록된 각 상기 실행 로그의 목표 속성 검사 결과인 통과 또는 실패 태그를 각 상기 상호작용 모델에 첨부하는 단계를 포함할 수 있다.
상기 SoS에 대한 상호작용 모델을 생성하는 단계는, 식별된 구성 시스템(CS)의 집합, 식별된 상호작용 메시지 시퀀스, 및 각 상기 실행 로그의 목표 속성 검사의 통과 여부를 표시하는 통과 또는 실패 태그를 통합하여 각 상기 상호작용 모델을 생성할 수 있다.
상기 의심스러운 상호작용 패턴을 추출하는 단계는, 생성된 상기 상호작용 모델에서 DP-LCS(Dynamic Programming for Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 실행하여, 각 카테고리에 공통되는 패턴을 포함하는 LCS 패턴과 분류된 상호작용 모델을 출력할 수 있다.
상기 의심스러운 상호작용 패턴을 추출하는 단계는, 의심스러운 LCS 지식부로부터 추출된 LCS 패턴과 상기 상호작용 모델을 비교하는 단계; 상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하지 않는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부에 새로운 LCS 패턴으로 추가하는 단계; 및 상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부의 동일한 카테고리에 할당하는 단계를 포함할 수 있다.
상기 의심스러운 상호작용 패턴을 분석하는 단계는, SoS 엔지니어는 추출된 상기 의심스러운 상호작용 패턴을 분석함에 따라 분류된 LCS 패턴과 상호작용 모델을 분석하여 실패의 근본 원인과 발생 상황에 대한 정보를 획득할 수 있다.
시나리오 생성 모듈을 이용하여 플래투닝 SoS의 랜덤 시나리오를 생성하는 단계; 및 시뮬레이션 모듈을 이용하여 생성된 상기 랜덤 시나리오에 대한 실행 로그를 생성하는 단계를 더 포함할 수 있다.
다른 실시예에 따른 패턴 기반 SoS(System-of-Systems) 내 실패 유발 상호작용 분석 장치는, 시스템의 실행 로그에 존재하는 데이터로부터 SoS 실행 중 실행되는 구성 시스템(Constituent System, CS)과 상호작용을 식별하여, SoS에 대한 상호작용 모델을 생성하는 상호작용 모델 생성부; 및 생성된 상기 상호작용 모델에서 LCS(Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 이용하여 실패를 유발하는 의심스러운 상호작용 패턴을 추출하는 패턴 마이닝부를 포함하여 이루어질 수 있다.
추출된 상기 의심스러운 상호작용 패턴을 분석하는 패턴 분석부를 더 포함할 수 있다.
상기 상호작용 모델 생성부는, 상기 실행 로그와 목표 속성 검사의 통과 또는 실패 결과라는 두 가지 입력을 사용하여 상기 SoS에 대한 상호작용 모델을 생성할 수 있다.
상기 상호작용 모델 생성부는, 상기 실행 로그에 존재하는 데이터로부터 단일 SoS 실행 중 실행되는 구성 시스템(CS)과 상호작용 메시지 시퀀스를 식별할 수 있다.
상기 상호작용 모델 생성부는, 외부 모듈을 통해 기록된 각 상기 실행 로그의 목표 속성 검사 결과인 통과 또는 실패 태그를 각 상기 상호작용 모델에 첨부할 수 있다.
상기 상호작용 모델 생성부는, 식별된 구성 시스템(CS)의 집합, 식별된 상호작용 메시지 시퀀스, 및 각 상기 실행 로그의 목표 속성 검사의 통과 여부를 표시하는 통과 또는 실패 태그를 통합하여 각 상기 상호작용 모델을 생성할 수 있다.
상기 패턴 마이닝부는, 생성된 상기 상호작용 모델에서 DP-LCS(Dynamic Programming for Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 실행하여, 각 카테고리에 공통되는 패턴을 포함하는 LCS 패턴과 분류된 상호작용 모델을 출력할 수 있다.
상기 패턴 마이닝부는, 의심스러운 LCS 지식부로부터 추출된 LCS 패턴과 상기 상호작용 모델을 비교하고, 상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하지 않는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부에 새로운 LCS 패턴으로 추가하며, 상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부의 동일한 카테고리에 할당할 수 있다.
상기 패턴 분석부는, SoS 엔지니어는 추출된 상기 의심스러운 상호작용 패턴을 분석함에 따라 분류된 LCS 패턴과 상호작용 모델을 분석하여 실패의 근본 원인과 발생 상황에 대한 정보를 획득할 수 있다.
플래투닝 SoS의 랜덤 시나리오를 생성하는 시나리오 생성 모듈; 및 생성된 상기 랜덤 시나리오에 대한 실행 로그를 생성하는 시뮬레이션 모듈을 더 포함할 수 있다.
실시예들에 따르면 효과적으로 SoS 상에 존재하는 상호작용 버그를 유추할 수 있는 실패 유발 상호작용 위치 추정 기술을 제공하는 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치를 제공할 수 있다.
실시예들에 따르면 시스템 실행 로그로부터 상호작용 모델을 생성하고, 상호작용 모델 내에서의 공통 시퀀스를 추출하는 방식으로 상호작용 버그를 유추하는 과정에 필요한 정보들을 시스템 매니저에게 제공하는 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치를 제공할 수 있다.
도 1은 일반적인 플래투닝 SoS에서의 상호작용 실패의 예시를 나타내는 도면이다.
도 2는 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치를 설명하기 위한 도면이다.
도 3은 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법을 나타내는 흐름도이다.
도 4a는 일 실시예에 따른 실행 로그 생성을 설명하는 도면이다.
도 4b는 일 실시예에 따른 상호작용 모델의 구조를 설명하는 도면이다.
도 4c는 일 실시예에 따른 알고리즘 출력의 예시를 설명하는 도면이다.
도 5는 일 실시예에 따른 상호작용 시퀀스의 대표적인 LCS 패턴 추출을 나타내는 도면이다.
도 6a 내지 도 6c는 일 실시예에 따른 카테고리 1 패턴의 실행 흐름 예시를 나타낸다.
도 7a 내지 도 7e는 일 실시예에 따른 카테고리 2 패턴의 실행 흐름 예시를 나타낸다.
도 8a 내지 도 8d는 일 실시예에 따른 카테고리 3 패턴의 실행 흐름 예시를 나타낸다.
이하, 첨부된 도면을 참조하여 실시예들을 설명한다. 그러나, 기술되는 실시예들은 여러 가지 다른 형태로 변형될 수 있으며, 본 발명의 범위가 이하 설명되는 실시예들에 의하여 한정되는 것은 아니다. 또한, 여러 실시예들은 당해 기술분야에서 평균적인 지식을 가진 자에게 본 발명을 더욱 완전하게 설명하기 위해서 제공되는 것이다. 도면에서 요소들의 형상 및 크기 등은 보다 명확한 설명을 위해 과장될 수 있다.
대규모 시스템 복합시스템인 시스템 오브 시스템즈(SoS)는 이종의 시스템들이 서로 협업하여 단일 시스템으로는 해결할 수 없는 목표들을 달성 가능하게 하는 시스템이다. SoS의 대표적은 예시로는 스마트 홈, 스마트 플랜트, 지능형 교통 시스템이 있으며, 이런 대규모 시스템들은 구성 시스템(Constituent System, CS)들 간의 긴밀한 상호작용을 통해 특정 동작(operation)을 수행하여 목표를 달성할 수 있다. 예를 들어, 지능형 교통 시스템의 한 종류인 군집 주행 시스템(Platooning System)에서는 Leave, Merge, Split과 같은 동작들을 수행하는데 평균적으로 20번 정도의 메시지를 상호 교환한다.
SoS의 이 같은 상호작용 기반 성질은 이전에는 자주 발견되지 않았던 상호작용 버그에 의한 시스템 실패를 유발할 수 있다. 하지만, 이러한 상호작용 버그를 해결하는데 필요한 정보들을 효율적으로 추출하고, 제공하기에 적합한 기술은 존재하지 않는다. 또한, 시스템 실패로부터 상호작용 버그를 유추하기까지 높은 수준의 시스템 자체에 대한 배경지식을 필요로 한다. 본 실시예에서는 효과적으로 SoS 상에 존재하는 상호작용 버그를 유추할 수 있는 “실패 유발 상호작용 위치 추정 기술”을 제시한다. 본 실시예들은 시스템 실행 로그로부터 상호작용 모델을 생성하고, 실패 상호작용 모델 내에서의 공통 시퀀스를 추출하는 방식으로 상호작용 버그를 유추하는 과정에 필요한 정보들을 시스템 매니저에게 제공한다. 이 기술을 위해 종래에 AI 분야의 자연어 처리에서 자주 사용되는 Longest Common Subsequence(LCS) 알고리즘을 확장하여 제안하였으며, 시스템 자체에 어떠한 전처리 과정 없이 시스템 로그만을 입력으로 활용하였다.
해당 기술을 군집 주행 시스템에 적용해본 결과, 동작 성공률(Operation Success Rate) 평가 기준에 미달하는 7가지 유형의 상호작용 실패 시나리오를 발견하였으며, 해당 상호작용 버그에 대한 실패 환경(Context), 증상(Symptom) 등을 시스템 로그상에서 직접적으로 추출할 수 있었다. 이러한 결과는 해당 군집 주행 시스템 커뮤니티에서 이전에 보고된 적 없는 실패 유형으로써, 특정 시스템이 아닌 일반적인 군집 주행 시스템 관련 실패 유형으로 사용될 수 있다.
아래에서 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치에 대해 보다 상세히 설명한다.
소프트웨어 구성 요소 간의 상호작용은 시스템 복합시스템(SoS)와 같은 복잡한 시스템의 목표 달성에 중요한 역할을 한다. 플래투닝(platooning, 군집운행) SoS는 연비를 높이기 위해 차량을 그룹으로 묶고 운행 프로토콜을 이용해 근접 주행이 가능해 교통 혼잡을 완화한다. 플래투닝 SoS에서, Leave나 Merge와 같은 전형적인 조작 실행은 평균 20개의 미세 조작으로 이루어진다. 이러한 하위조작의 과잉으로 인해 특정 운전 시퀀스의 상호작용 실패는 SoS 실행에서 발생할 수 있다. 또한, 이러한 실패의 근본 원인을 분석하는 것은 구성 상호작용의 밀도 때문에 시간이 많이 소요된다. 기존 기법에는 두 가지 한계가 있다. 첫째, 근본 원인 분석 기법의 대다수는 상호작용 데이터를 직접 활용하지 않기 때문에 실패(결함 있는) 상호작용 시퀀스를 분리할 수 없다. 둘째, 대부분의 실패 진단 기법은 제한된 지식으로 인해 SoS에서 고려해야 하는 "알 수 없는 실패"을 검토하지 않는다.
SoS에서 상호작용 오류를 효과적으로 분석하기 위해 패턴 기반 실패 상호작용 분석 기법을 제안한다. 이를 위해 먼저 SoS에 대해 상호작용 모델을 정의하고, 의심스러운 상호작용 패턴 마이닝 알고리즘을 제안한다. 플래투닝 시뮬레이터를 사용한 사례 연구 중 제안된 기법은 로그에서 상호작용 데이터를 자동으로 추출하고 실패 상호작용 패턴을 추출하여 보고되지 않은 7가지 새로운 상호작용 실패 시나리오를 식별할 수 있다. 본 실시예들에 따른 결론은 플래투닝 SoS를 위한 일반적인 실패 지식 기반을 풍부하게 할 수 있다.
앞에서 언급한 기존 접근법의 한계를 극복하기 위해 실패한 실행의 로그에서 가장 의심스러운 상호작용 패턴을 발굴하는 패턴 기반 실패 유도 상호작용 분석 기법을 제안한다. 본 발명의 주요 기여는 다음과 같다.
- 각 SoS 실행 로그의 상호작용 특성과 동작 시퀀스를 추상화하는 SoS에 대한 상호작용 모델을 제안한다.
- 실시예들은 Longest Common Subsequence(LCS) 알고리즘을 확장하여 실패 상호작용 패턴을 자동으로 마이닝하는 접근방식을 정의한다.
- SoS 플래투닝에서 상세한 상호작용 실패 시나리오를 찾아내고 테스트 벤치마크 및 일반 플래투닝 시스템을 위한 실패 지식으로 사용될 수 있다.
상호작용 모델과 패턴 마이닝 알고리즘을 적용하여 StarPlateS를 이용한 플래투닝 SoS에 대한 사례 연구를 실시한다(비특허문헌 3). 사례 연구에서는 검출된 실패를 3개 등급으로 분류하고 플래투닝 SoS에 대한 기존 지식 없이 7개의 세부적인 상호작용 실패 시나리오를 개발한다. 이는 플래투닝 SoS에 관한 상호작용 실패 시나리오를 제공하는 첫 연구이다.
StarPlateS: 플래투닝 SoS를 위한 통계적 검증 프레임워크
플래투닝 SoS는 매우 복잡한 시스템으로, 신뢰할 수 있는 운영을 보장하기 위해 가능한 한 많은 환경에서 기능할 수 있어야 한다. 가능한 모든 실제 시나리오에서 플래투닝 SoS를 테스트하는 것이 어렵기 때문에 시뮬레이터가 필요하다. 최근 여러 연구에서는 플래투닝 SoS(비특허문헌 3)의 시뮬레이션과 검증을 연구하였다. 다양한 동작 중 플래투닝 차량 간의 상호작용을 중점적으로 하기 위해 플래투닝 동작 및 현실적인 시나리오 생성에 초점을 맞춘 StarPlateS(비특허문헌 3)를 이러한 목적으로 사용했다.
StarPlateS는 VENTOS 확장 프레임워크로, 현실적인 시나리오를 처리할 수 있는 내외부의 불확실한 요소를 고려한다. StarPlateS에서 도로와 차량의 구현은 SUMO 시뮬레이터를 기반으로 하며 차량 간 통신은 OMNET++ 시뮬레이터를 기반으로 한다. 시뮬레이터의 통합으로 StarplateS는 랜덤 플래투닝 구성과 시나리오를 생성하고, 시나리오에 대한 실행 로그를 생성하고, 로그를 사용하여 플래투닝 목표를 검증한다. 이런 맥락에서 플래투닝 구성은 플래툰 생성 특성을 나타내고, 시나리오는 플래투닝 SoS Merge, Split, Leave의 기본 동작(operation) 순서를 나타낸다. Merge 동작 중에는 두 개의 뚜렷한 플래툰이 한 개의 플래툰으로 합쳐지는 반면, Split 동작은 정확히 정반대의 역할을 한다. Leave 동작은 멤버가 플래툰을 떠나고 싶을 때 실행된다.
본 실시예에서는 사례 연구에서 시나리오 생성과 시뮬레이션 모듈 2개를 StarplateS에서 사용했다. 시나리오 생성 모듈은 랜덤 플래툰 구성과 시나리오를 생성한 다음, 시뮬레이션 모듈은 VENTOS 시뮬레이터를 실행하여 시나리오에 대한 실행 로그를 생성한다.
스펙트럼 기반 실패 위치 측정(Spectrum-Based Fault Localization, SBF) 기법
실패 로그에 존재하는 데이터를 기반으로 실패를 유발하는 상호작용을 식별하기 위해 패턴 마이닝 기반 실패 위치 측정 기법을 제안한다. 실패 위치 측정 기법은 프로그래머가 주의를 기울일 만한 프로그램 내의 의심스러운 위치를 정확히 찾아낸다. 오류가 있는 것으로 보이는 프로그램 위치를 의심스러운 위치라고 한다. 불합격 사례를 포함한 모든 시험 사례에 대응하여 프로그램 내 의심스러운 위치의 목록이 작성된다.
SBFL 기술은 각 테스트 사례에 해당하는 코드 카테고리(category)를 활용하여 의심스러운 위치를 결정한다. 프로그램 스펙트럼이라고도 하는 코드 카테고리는 특정 입력에 관한 프로그램의 실행 추적이다. 의심스러운 위치를 파악하기 위한 SBFL 기법의 기본 개념은 실패한 경우 프로그램 위치가 많이 실행될수록 의심스러운 것으로 간주된다는 것이다.
크고 복잡한 SoS의 경우, 실패의 식별과 보정은 노력 집약적인 동작이다. 실패 위치 측정 기법은 엔지니어가 실패의 근본 원인과 발생 상황을 분석하는 데 도움이 되기 때문에, SBFL 기법은 재해 대응 SoS 및 소프트웨어 제품군과 같은 대규모 복합시스템의 실패 위치를 측정하기 위해 사용되어 왔다. 그러나, 본 실시예에서는 특히 플래투닝 SoS에서의 상호작용 실패를 다룬다. 실패 로그에서 실패 상호작용을 효과적으로 추출하기 위해 SoS 및 Longest Common Subsequence(LCS) 기반 패턴 마이닝 알고리즘에 대한 상호작용 모델을 제안한다.
아래에서는 본 실시예에 따른 실패 유발 상호작용 패턴 마이닝에 대해 설명한다.
전체 프로세스
도 2는 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치를 설명하기 위한 도면이다.
도 2를 참조하면, SoS 실행 로그에 존재하는 상호작용 데이터를 처리하고 실패를 유발하는 상호작용 패턴을 추출하기 위한 패턴 기반 분석 기법을 제안한다. 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치는 상호작용 모델 생성부(210) 및 패턴 마이닝부(220)을 포함하여 이루어질 수 있다. 실시예에 따라 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치는 패턴 분석부(230)를 더 포함하여 이루어질 수 있다. 또한, 플래투닝 SoS의 랜덤 시나리오를 생성하는 시나리오 생성 모듈, 및 생성된 랜덤 시나리오에 대한 실행 로그를 생성하는 시뮬레이션 모듈을 더 포함할 수 있다.
여기에서는 실행 로그와 목표 속성 검사의 통과 또는 실패 결과라는 두 가지 입력을 사용한다. 상호작용 모델 생성부(210)는 로그에 존재하는 데이터에 기초하여, 먼저 단일 SoS 실행 중에 실행되는 CS와 이들의 상호작용을 식별할 수 있다. 상호작용은 통신 네트워크에 포착된 통신 추적(예: 메시지)의 시퀀스를 말한다. 그런 다음, 상호작용 모델 생성부(210)는 각 로그의 목표 속성 검사 결과를 각 상호작용 모델(IM)에 첨부할 수 있다. 각 상호작용 모델은 식별된 CS 집합, 메시지 시퀀스, 통과/실패 태그를 통합하여 생성된다. 다양한 도메인에 대한 확장성 때문에 외부 목표 검증 모듈의 존재를 가정한다. 예를 들어, 나중에 제시된 사례 연구에서는 SIMVA-SoS를 사용하여 각 실행 로그를 검사했다.
패턴 마이닝부(220)는 생성된 모델에서 의심스러운 메시지 시퀀스의 패턴을 추출할 수 있다. SoS는 규모가 크고 복잡하기 때문에 SoS에 단일 버그가 존재한다고 가정하는 것이 부적절하기 때문에, SoS는 다중 실패로 인해 어려움을 겪고 각각의 실패한 상호작용 모델(IM)에는 하나 이상의 실패 패턴이 포함될 수 있다고 가정한다. 패턴 마이닝부(220)는 실패한 IM의 각 쌍 사이에 LCS가 존재하는지 검색하고 그러한 쌍을 동일한 카테고리에 할당할 수 있다. 이 과정을 통해 각 카테고리는 결국 관련성이 높은 실패한 IM에 의해 채워지게 되는데, 이는 유사한 근본 원인에 의해 유도된 것으로 기대할 수 있다. 각 카테고리에 해당하는 추출된 LCS 패턴은 해당 카테고리에 속하는 모든 IM에 공통적으로 관찰되는 특정 메시지 반복이며, 관련 실패의 근본 원인과 발생 상황을 분석하는 데 사용할 수 있다.
또한, 패턴 분석부(230)는 SoS 엔지니어는 출력 패턴을 상세하게 분석함으로써 분류된 LCS 패턴과 IM을 분석함으로써 실패의 근본 원인과 발생 상황에 대한 이해를 얻을 수 있다.
도 3은 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법을 나타내는 흐름도이다.
도 3을 참조하면, 일 실시예에 따른 컴퓨터 장치를 통해 구현되는 패턴 기반 SoS(System-of-Systems) 내 실패 유발 상호작용 분석 방법은, 시스템의 실행 로그에 존재하는 데이터로부터 SoS 실행 중 실행되는 구성 시스템(Constituent System, CS)과 상호작용을 식별하여, SoS에 대한 상호작용 모델을 생성하는 단계(310), 및 생성된 상호작용 모델에서 LCS(Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 이용하여 실패를 유발하는 의심스러운 상호작용 패턴을 추출하는 단계(320)를 포함하여 이루어질 수 있다.
또한, 추출된 의심스러운 상호작용 패턴을 분석하는 단계(330)를 더 포함할 수 있다.
아래에서 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법의 각 단계를 보다 상세히 설명한다.
일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법은 도 2에서 설명한 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치를 예를 들어 설명할 수 있다.
단계(310)에서, 상호작용 모델 생성부(210)는 시스템의 실행 로그에 존재하는 데이터로부터 SoS 실행 중 실행되는 구성 시스템(CS)과 상호작용을 식별하여, SoS에 대한 상호작용 모델을 생성할 수 있다. 상호작용 모델 생성부(210)는 실행 로그와 목표 속성 검사의 통과 또는 실패 결과라는 두 가지 입력을 사용하여 SoS에 대한 상호작용 모델을 생성할 수 있다.
먼저, 상호작용 모델 생성부(210)는 실행 로그에 존재하는 데이터로부터 단일 SoS 실행 중 실행되는 구성 시스템(CS)과 상호작용 메시지 시퀀스를 식별할 수 있다. 이후, 상호작용 모델 생성부(210)는 외부 모듈을 통해 기록된 각 실행 로그의 목표 속성 검사 결과인 통과 또는 실패 태그를 각 상호작용 모델에 첨부할 수 있다. 상호작용 모델 생성부(210)는 식별된 구성 시스템(CS)의 집합, 식별된 상호작용 메시지 시퀀스, 및 각 실행 로그의 목표 속성 검사의 통과 여부를 표시하는 통과 또는 실패 태그를 통합하여 각 상호작용 모델을 생성할 수 있다.
단계(320)에서, 패턴 마이닝부(220)는 생성된 상호작용 모델에서 LCS(Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 이용하여 실패를 유발하는 의심스러운 상호작용 패턴을 추출할 수 있다. 보다 구체적으로, 패턴 마이닝부(220)는 생성된 상호작용 모델에서 DP-LCS(Dynamic Programming for Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 실행하여, 각 카테고리에 공통되는 패턴을 포함하는 LCS 패턴과 분류된 상호작용 모델을 출력할 수 있다.
패턴 마이닝부(220)는 의심스러운 LCS 지식부(240)로부터 추출된 LCS 패턴과 상호작용 모델을 비교하고, 추출된 LCS 패턴과 상호작용 모델 사이에 LCS가 존재하지 않는 경우, 상호작용 모델을 의심스러운 LCS 지식부(240)에 새로운 LCS 패턴으로 추가하며, 추출된 LCS 패턴과 상호작용 모델 사이에 LCS가 존재하는 경우, 상호작용 모델을 의심스러운 LCS 지식부(240)의 동일한 카테고리에 할당할 수 있다.
단계(330)에서, 패턴 분석부(230)는 추출된 의심스러운 상호작용 패턴을 분석할 수 있다. 패턴 분석부(230)는 SoS 엔지니어는 추출된 의심스러운 상호작용 패턴을 분석함에 따라 분류된 LCS 패턴과 상호작용 모델을 분석하여 실패의 근본 원인과 발생 상황에 대한 정보를 획득할 수 있다.
한편, 일 실시예에 따른 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법은 시나리오 생성 모듈을 이용하여 플래투닝 SoS의 랜덤 시나리오를 생성한 후, 시뮬레이션 모듈을 이용하여 생성된 랜덤 시나리오에 대한 실행 로그를 생성할 수 있다.
상호작용 모델 생성
시스템 추상화 모델은 시스템 모델의 추상화된 정보에 의해서만 실패의 근본 원인을 분리할 수 있기 때문에 복잡한 시스템의 실패 분석에서 중요한 역할을 한다. 예를 들어, 기존 연구는 시스템 실행에 대한 높은 수준의 정보를 활용했다(비특허문헌 1 및 2). 참여 CS와 그들 사이의 커뮤니케이션을 추상화했다. 그러나 기존 추상화 모델은 상호작용의 내부 시퀀스와 실행 컨텍스트를 포함하지 않으므로 기존 모델은 상호작용-실패 분석에 적합하지 않다. 실패 분석에서 발생 상황 및 실행 흐름과 같은 충분한 상호작용 기능을 활용하기 위해 상호작용 모델(IM)을 정의하고 실행 로그에서 자동화된 IM 생성 모듈을 구축한다. IM은 다음과 같이 정의된다.
[식 1]
로그 Li에서 생성된 IM의 일 예인 IMi는 CSi, Mi, tagi의 세 가지 요소로 구성된다. 여기서, CSi는 로그 Li의 실행 중에 SoS에 참여하는 csj 인스턴스 집합이다. csj의 참여는 일반적인 SoS 수준 목표 달성을 위한 특정 기능을 수행하는 것으로 구성된다. 예를 들어 플래투닝 SoS에서는 플래투닝 동작을 수행할 수 있는 차량을 참여 CS로 표시했다.
또한, Mi는 Li의 실행 중에 전달되는 Li 길이와 함께 순서가 정해진 메시지 순서를 나타낸다. 즉, Mi는 Li에서 실행되는 시퀀스 도표의 형식적인 표현이다. Mi의 각 메시지 msgk는 SoS 상호작용 기능의 벡터를 나타낸다. SoS에서 상호작용 특성을 추출하기 위해, 자율 차량, 통신 시스템, 웹 서비스 등 다양한 영역에서 상호작용과 통신의 특성을 식별하는 기존 연구를 참조할 수 있다.
표 1은 메시지 기반 상호작용과 그 유형을 나타내기 위해 사용되는 특성을 나타낸다.
[표 1]
표 1을 참조하면, 지속성(Continuity) 특성(feature)은 송신자가 단일 메시지(임시 통신, TC) 또는 메시지 스트림(연속 통신, CC)을 보낼지 여부를 결정한다. 동기화(Synchronization)는 전달된 메시지가 동기식(Sync)인지 비동기식(Async)인지 여부를 결정한다. 지속성과 동기화 특성은 CS들 사이의 동시성 속성을 함께 포착한다. 시작 엔티티(Initiating Entity) 및 수신 엔티티(Receiving Entity)은 각각 모든 메시지의 발신자와 수신자를 가리킨다. 콘텐츠(Content) 특성은 메시지의 내용을 설명하고, IM에 메시지의 송신 및 수신 시간을 기록하기 위해 시작 시간(Start Time), 종료 시간(End Time), 그리고 딜레이(Delay)를 사용한다. 콘텐츠 특성의 예시 값에는 LEAVE_REQ, LEAVE_ACCEPT와 같이 플래투닝 동작 프로토콜에 정의된 17개의 마이크로 명령이 포함된다. 콘텐츠 특성은 CS 간의 인터페이스 충돌 및 목표 충돌과 같은 특정 유형의 충돌을 평가하는 데 사용할 수 있다. 시작 엔티티 및 수신 엔티티와 콘텐츠 특성은 시작 엔티티 및 수신 엔티티와의 관계를 분석하여 시스템 운영 중 직간접적인 리소스 충돌을 평가하는 데 사용할 수 있다.
상호작용 모델의 마지막 구성요소는 tagi이다. 각 실행 로그는 SoS의 특정 목표를 충족하는지 여부에 의해 평가될 수 있다. i번째 실행 로그에 해당하는 목표 만족도 결과, 통과 또는 실패는 tagi에 할당된다.
앞에서 언급한 IM 생성 모듈을 구현했는데, 이 모듈은 Li의 참여 CS와 상호작용 특성을 자동으로 식별한다. 식별 후, 모듈은 각 IMi에 tagi를 부착한다. 외부 모듈은 Li가 특정 목표를 통과하는지 여부를 기록한다. 그런 다음, 통과 또는 실패 결과는 IMi의 tagi에 저장된다.
DP-LCS 기반 패턴 마이닝 알고리즘
다음 단계에는 DP-LCS(Dynamic Programming for Longest Common Subsequence) 알고리즘에 기초한 의심스러운 상호작용 시퀀스(suspicious interaction sequence)의 마이닝 프로세스가 포함된다.
표 2는 의심스러운 상호작용 패턴 마이닝 알고리즘을 나타낸다.
[표 2]
표 2를 참조하면, 알고리즘 1은 실패를 유발하는 상호작용을 분리하고 분류하는 DP-LCS 기반 마이닝 알고리즘을 나타낸다. 여기서, 각 IM의 단일 실행 내에서 SoS에 여러 개의 실패와 여러 개의 실패 상호작용 패턴이 존재한다고 가정한다. 실시예들은 (1) 기존 카테고리에 주어진 IM을 추가하고, (2) IM으로 새로운 카테고리를 만드는 다음과 같은 분기를 기반으로 알고리즘을 구성한다. 5~7행은 IM-추가 사례를 설명한다. 알고리즘은 IM과 기존 LCS 패턴 사이에 LCS가 존재할 때 기존 카테고리에 IM을 추가하기로 결정한다. 5행은 의사결정 과정을 그린다. 공통적인 상호작용이 존재하는 경우, 주어진 IM은 카테고리에 할당되고, 갱신된 카테고리의 상호작용 패턴은 주어진 IM을 포함하여 새롭게 추출된다. 각 IM은 전술한 조건을 만족하는 복수의 부속 패턴을 가진 경우 여러 카테고리에 할당될 수 있다. 8~9행은 IM과 지식기반 내의 기존 패턴들 사이에 LCS가 존재하지 않는 경우에 대한 카테고리 생성 과정을 보여준다. 이 경우 IM은 새로운 카테고리에 추가되고 메시지 순서 M은 먼저 해당 카테고리의 새로운 패턴으로 할당된다.
LCS 생성 알고리즘은 알고리즘 2에 자세히 설명되어 있다.
표 3은 LCS 생성 알고리즘을 나타낸다.
[표 3]
표 3을 참조하면, O(Sizep * Sizek)의 실현 가능한 성능을 보여주기 때문에 동적 프로그래밍(DP) 솔루션을 사용하여 LCS를 생성한다. LCS 생성 알고리즘은 6행에서 17행까지와 같이 두 개의 IM을 비교하여 LCS 테이블을 생성하는 것으로 시작한다. 18~24행은 표에서 공통적으로 관찰되는 메시지의 시퀀스를 추출하는 과정을 보여준다. 알고리즘의 기본 흐름은 문자열의 기존 DP-LCS 알고리즘과 유사하다. 기존 알고리즘은 문자열의 모든 문자를 비교하여 LCS를 생성한다. 문자열 기반 비교 메트릭을 IM의 메시지 비교 메트릭으로 확장한다. 28~33행에서 정의한 바와 같이, 지속성, 동기화, 송신자 및 수신자, 그리고 두 메시지의 콘텐츠 특성이 동일한 값을 공유하는 경우, 두 메시지는 동일한 것으로 간주된다. 동일한 메시지가 시뮬레이션 중에 서로 다른 시간에 전달될 수 있기 때문에 비교를 위해 시간 관련 특성을 사용하지 않는다. Sender/Receiver 비교의 경우에도 동일한 문제가 존재한다. 이를 해결하기 위해 차량 ID와 같은 구체적인 CS 인스턴스가 아닌 Follower, Leader 등 추상적인 CS 클래스에 의한 Sender/Receiver를 비교한다. 추상 클래스는 SoS의 역할 유형에 의해 정의될 수 있다. 제안된 알고리즘의 구현은 저장소에 포함될 수 있다.
즉, 제안된 알고리즘은 각 카테고리에 공통되는 패턴을 포함하는 일련의 LCS 패턴과 분류된 IM을 반환한다. 실패의 컨텍스트와 관련된 의심스러운 패턴은 SoS 엔지니어들이 카테고리의 실패를 분석하고 발생 상황과 근본 원인을 이해하는 데 도움이 된다.
적용 사례에 기초한 심층 분석
도 4a 내지 도 4c는 일 실시예에 따른 프로세스, 상호작용 모델 구조 및 알고리즘 출력의 예시를 보여준다. 보다 구체적으로, 도 4a는 일 실시예에 따른 실행 로그 생성을 설명하는 도면이고, 도 4b는 일 실시예에 따른 상호작용 모델의 구조를 설명하는 도면이고, 도 4c는 일 실시예에 따른 알고리즘 출력의 예시를 설명하는 도면이다.
도 4a에 도시된 바와 같이, SoS의 로그를 감안할 때 제안된 기법은 우선 i번째 실행과 관련된 시스템 흔적을 포함하는 각 로그(Li)에 해당하는 상호작용 모델(IMi)을 자동으로 생성한다. 상호작용 모델(IMi)의 구조는 도 4b에 도시된 바와 같이 나타낼 수 있으며, 이 예시에서 IM0에는 4개의 메시지(M0), 4개의 참여 CS(CS0), 그리고 통과 태그(tag0)의 순서가 포함되어 있다. M0의 각 메시지는 [표 1]에 설명되어 있는 특정한 특성들로 구성된 벡터다. 이 예시는 msg0이 다음과 같은 값으로 구성됨을 보여준다. TC, Sync, 송신자 A 및 수신자 B, SPLIT_REQ 콘텐츠 및 시간 값2019/12/24:000000000, 2019/12/24:000159000, 159000. 이는 msg0이 159,000 ms의 지연으로 시간적, 동기화 메시지로 A에서 B로 SPLIT_REQ를 전달하기 위해 전송된다는 것을 나타낸다.
생성된 상호작용 모델을 사용하여 이 기술은 DP-LCS 기반의 의심스러운 상호작용 패턴 마이닝 알고리즘을 실행한다. 도 4c에 도시된 바와 같이, 이 알고리즘의 출력은 모든 의심스러운 LCS 패턴, 분류된 IM 및 감지 카운트와 같이 후속 분석을 위한 추가 정보로 구성된 지식 테이블이다. 이 예시에서는 두 가지 LCS 패턴이 나열된다. 첫 번째 메시지인 LCS0은 세 개의 메시지로 구성되며, 이 패턴은 35개의 IMs―IM1, IM9, ... , IMn-1에서 관찰된다. 두 번째 의심스러운 패턴인 LCS1은 4개의 메시지의 시퀀스로, 13개의 다른 IM에서 검출된다.
이 기법의 마지막 단계에는 SoS 엔지니어의 결과 분석이 포함된다. 도 4c에 도시된 바와 같은 출력 표의 각 행에는 분류된 IM과 해당 LCS 패턴이 포함되어 있어 SoS에서 상호작용 실패를 일으킬 수 있다. 즉, 각 행은 독립적인 카테고리를 나타내며 카테고리 IM은 특정 상호작용 실패를 야기하는 차별적 상호작용을 포함한다. SoS 엔지니어는 출력을 활용하여 검출된 상호작용 오류를 매우 상세하게 분석할 수 있다.
아래에서는 본 발명의 실시예에 따른 사례 연구를 설명한다.
본 사례 연구의 목표는 플래투닝 시뮬레이션 및 검증 프레임워크인 StarPlateS(비특허문헌 3)를 사용하여 제안된 기법의 효과를 입증하고 플래투닝 SoS에서 알려지지 않은 실패 상호작용을 분석하는 것이다. 이 기법을 평가하기 위해 다음과 같은 연구 질문을 사용한다.
1) RQ1. 제안된 기법은 컨텍스트와 상호작용을 충분히 이해하는 등 의심스러운 패턴을 효과적으로 추출하고 있는가?
2) RQ2. SoS 엔지니어는 마이닝 결과를 활용하여 플래투닝 SoS의 실패 시나리오를 분석할 수 있는가?
RQ1은 DP-LCS 기반 패턴 마이닝 결과의 높은 수준의 분석을 목표로 한다. 이 질문에 답하기 위해 추출된 상호작용 패턴의 상세한 컨텍스트와 실행 흐름을 분석했다. RQ2는 카테고리를 세부 시나리오 사례로 세분화하여 기법의 실용성을 판단하기 위한 것이다. 실무적으로 고도의 분석 결과를 바탕으로 각 IM에 대한 수동 조사를 실시하였고, 플래투닝 SoS에서 7가지 상호작용 실패 시나리오를 확인하였다.
이 사례 연구에서는 시나리오 생성 모듈과 시뮬레이션 모듈이라는 두 개의 StarPlateS 모듈을 사용했다. 이 모듈을 이용하여 플래투닝 SoS의 랜덤 시나리오를 생성하고 그에 상응하는 실행 로그를 생성했다. 제안된 기법은 또한 각 로그에 대한 목표 속성 검사 결과를 요구한다. SIMVA-SoS에 있는 검증 모듈을 수정하여 독립적인 목표 검증 모듈을 구축하였다. 플래투닝 시스템의 정확한 동작 수행 평가에서 가장 관련성이 높은 것으로 StarPlateS에서 다음 식과 같은 기준을 선택했다.
[식 2]
이 기준은 시뮬레이션에서 성공적으로 실행되는 요청된 동작 수를 결정한다. 예를 들어 플래툰 안(in) 또는 사이(between)로 10번의 동작(operation)을 요청하고, 요청된 10번의 동작 중 9번의 동작이 성공적으로 수행된다면, 시뮬레이션의 op 성공률은 90%가 된다.
사례 연구를 위한 플래투닝 시나리오의 자세한 설정은 다음과 같이 설명된다. 생성된 총 시나리오 수는 600개의 시나리오이고, 단일 시뮬레이션의 지속시간(duration)은 100초이며, 생성된 플래툰 수는 24개의 플래툰이고, 플래툰 규모는 2~6개의 차량이다. 그리고 환경 객체는 5초마다 1대씩 HDV(Human-Driven Vehicle, 사람 구동 차량)을 생성한다.
총 600개의 시나리오를 100초 동안 무작위로 생성하여 단일 시뮬레이션에 사용하였다. 모든 시뮬레이션에서 생성된 플래툰의 수는 2개에서 4개까지 무작위로 결정되었고, 크기는 2개에서 6 차량까지 무작위로 할당되었다. 또한 플래툰과 연결되지 않고 차선과 속도를 임의로 변경하는 HDV용 생성기를 정의했다. 생성기는 5초마다 HDV를 시뮬레이션에 추가했다. 그런 다음, 로그에 기반한 600개의 IM을 생성하고 제안된 알고리즘을 통해 의심스러운 상호작용 패턴을 추출했다. 아래에서는 마이닝과 분석 결과를 상세히 설명한다.
RQ1에 적절하게 답하기 위해, 먼저 op 성공률 기준의 관점에서 600개의 시뮬레이션 시나리오에 해당하는 마이닝 결과를 분석하였다. 성공률 임계값을 80%로 설정하고 실패한 시나리오 258개에서 LCS를 추출했다. 마이닝 결과는 op 성공률 관련 실패에 세 가지 패턴 카테고리가 존재함을 보여준다. (1) 실패 카테고리의 근본 원인과, (2) 실패한 실행의 컨텍스트를 파악하기 위해 패턴을 매우 상세하게 조사했다.
도 5는 일 실시예에 따른 상호작용 시퀀스의 대표적인 LCS 패턴 추출을 나타내는 도면이다.
도 5를 참조하면, 각 카테고리에 해당하는 의심스러운 상호작용의 시퀀스 패턴을 나타낸다. 녹색 영역은 실패 시나리오의 이해를 돕는 실행 컨텍스트를 나타내며, 빨간색 영역은 실패 뒤에 숨은 근본 원인에 대한 단서를 제공한다.
세 가지 LCS 패턴 모두 병합 동작을 포함하는 것으로 관찰된다. 각 패턴은 카테고리 1의 5에서 7행까지, 카테고리 2의 9와 12에서 14행까지, 카테고리 3의 10과 12에서 14행에서와 같이 동일한 차량으로부터 최소 3개의 Merge 요청을 가진다. op 성공률은 요청된 모든 동작 중 실행된 동작의 비율을 나타내기 때문에, 지속적으로 요청된 동작은 수신자에서 다른 동작의 적절한 수행과 반응 시간에 부정적인 영향을 미친다. Split 동작은 LCS 패턴에도 공통적이다. 카테고리 1에서 첫 번째 보고된 메시지는 v1에서 v2로 Split 요청이다. 카테고리 2와 3에서는 두 번째 메시지가 관찰되어 Split 동작을 요청한다. 이 두 가지 공통점을 바탕으로 운영 프로토콜이 대상 플래투닝 SoS의 특정 문제로 인해 어려움을 겪었으며, 이러한 문제들은 Split 및 Merge 동작과 높은 상관관계가 있다고 결론지었다.
카테고리 1의 의심스러운 상호작용 패턴은, 도 5에 도시된 바와 같이, 7개의 순차 메시지로 구성된다. 처음 두 메시지는 Split과 Merge의 동시 요청을 기록한다. 1행은 리더 차량 v1이 후속 차량 v2에 Split 요청을 전송했음을 나타낸다. 2행은 후방 플래툰인 v5가 전방 플래툰에게 Merge를 요청함을 나타낸다.
도 6a 내지 도 6c는 일 실시예에 따른 카테고리 1 패턴의 실행 흐름 예시를 나타낸다.
도 6a 내지 도 6c를 참조하면, 카테고리 1과 관련된 실패 패턴을 보여준다. 이 시나리오의 문제는, 도 6a에 도시된 바와 같이, Split 동작 요청으로 v5(621) 앞의 전방 플래툰(610)이 v1(611)에서 v2(612)로 변경되었다는 점이다. 이 경우, 도 6b에 도시된 바와 같이, 후방 전면 리더인 v5(621)가 계속 Merge를 v1(611)에 요청해도 실행되지 않는다. 또한, 도 6c에 도시된 바와 같이, Split 동작 후에도 후방 전면 리더인 v5(621)가 계속 Merge를 v1(611)에 요청해도 실행되지 않는다. 따라서 관측된 실패 중 하나가 프로토콜의 운전요청 논리와 관련되며, 이 실패는 Split과 Merge의 동시 요청에 의해 촉발된다고 결론지을 수 있다.
도 7a 내지 도 7e는 일 실시예에 따른 카테고리 2 패턴의 실행 흐름 예시를 나타낸다.
도 7a 내지 도 7e를 참조하면, 카테고리 2와 관련된 실패 패턴을 보여준다. 카테고리 2 패턴에서는, 같은 차선에서 두 개의 플래툰, 즉 리더 v1(711)이 있는 전방 플래툰 1(710)과 리더 v5(721)가 있는 후방 플래툰 2(720)가 있다. 이 경우 v5(721)는 연속적인 Merge 요청을 전송했다.
도 7a에 도시된 바와 같이, 이 패턴에서, 전방 플래툰(710)의 팔로워 중 하나인 v2(712)가 도 5의 1~3행에 나타낸 것과 같이 Leave 동작을 요청한다. 도 7b에 도시된 바와 같이, FollowerLeave 동작은 대상 플래투닝 운영 프로토콜의 세 단계로 구성된다. 즉, Split, Leave 및 Merge이다. 먼저, 도 7c에 도시된 바와 같이, v2(712)가 Leave를 요청했기 때문에 v3(713)와 v4(714)는 4~8행에서 새 플래툰으로 나뉘었다. 그런 다음, 후방 플래툰(720)이 갑자기 Merge 요청을 분단된 플래툰에 전송했다. 그러나 나뉘어진 플래툰은 v2(712)가 떠난 후 원래의 리더 v1(711)과 함께 재병합할 필요가 있었다. 여기서 문제는, 도 7d에 도시된 바와 같이, 후방 플래툰(720)인 v5(721)가 MERGE_REQ가 포함된 메시지를 중간 플래툰인 v3(713)에게 계속 전달했다는 점이다. v5(721)의 지속적인 Merge 요청이 최적 크기 구성이 되는 이유를 파악할 수 있다. 도 7e에 도시된 바와 같이, 후방 플래툰(720) 크기가 최적 사이즈보다 작고 후방 플래툰(720) 크기와 중간 플래툰 크기의 합이 최적 크기와 우연히 같을 경우, 후방 플래툰(720)은 Merge 요청을 중간 플래툰에게 지속적으로 전달하는 것이 관찰된다.
도 8a 내지 도 8d는 일 실시예에 따른 카테고리 3 패턴의 실행 흐름 예시를 나타낸다.
도 8a 내지 도 8d를 참조하면, 카테고리 3과 관련된 실패 패턴을 보여준다. 카테고리 3에서는, v1(811)부터 v4(814)까지의 차량이 단일 플래툰(810)을 구성했다. 팔로워 중 하나인 v3(813)는 이 요청을 v1(811)과 v2(812)로 전송했다.
도 8a 및 도 8b에 도시된 바와 같이, 최종 LCS 패턴은 Leave 동작으로 시작하는 것으로 관찰된다. 도 5의 카테고리 3에 있는 1부터 5행까지는 v2(812)가 Leave를 요청했고, 도 8c 및 도 8d에 도시된 바와 같이, 후방 차량인 v3(813)와 v4(814)가 중간 플래툰로 나뉘어 Leave 동작을 수행했음을 보여준다. 이 패턴의 차별적 특성은 중간 플래툰인 v3(813)가 떠나는 차량 v2(812)에 Merge 요청을 전송했다는 것이다. 당초 v1(811)이 원래의 플래툰과 함께 재병합할 수 있도록 요청을 보낼 것으로 예상됐다. 그러나 v3(813)는 리더 v1(811)과 떠나는 차량 v2(812)에 모두 메시지를 보낸다. 이 경우를 설명하기 위해 최적 크기 설정이 다른 시뮬레이션에서 유사한 사례를 재현했다. 중복된 병합 요청은 최적 크기 또는 Leader/FollowerLeave 설정과 관계없이 외부 차량에 전송된 것으로 확인되었다. 이 실패 사례는 3대 이상의 차량으로 구성된 플래툰에서 FollowerLeave 동작이 수행될 때 자주 관찰된다.
RQ2에 답하기 위해 각 카테고리 내 IM을 추가로 분석하여 기존 카테고리에서 7가지 실패 시나리오를 세분화하였다. 전제 조건, 실행 흐름, 예시, 추출된 패턴 등 7가지 시나리오의 상세한 실패 보고서가 개발되었다. 이 분석은 제한된 지식을 가진 SoS 엔지니어가 제안된 접근방법에 의해 제공되는 데이터를 만족스럽게 활용할 수 있음을 보여준다.
표 4는 분석의 세부사항을 제시한다.
[표 4]
예를 들어, 표 4에서 세 가지 다른 사례(동시 Split & Merge, OptSizeChange &Merge, LeaderLeave & Merge)가 카테고리 1 실패를 야기할 수 있다. 카테고리 1에 속하는 IM에서 이러한 구체적인 시나리오 사례를 관찰했다. 마찬가지로, 각 카테고리 2와 3에서 두 가지 유형의 상호작용 실패 시나리오인 LeaderLeave 및 FollowerLeave를 식별했다. 여기서 7가지 실패 시나리오를 상세히 기록하고, 이 연구에서 고려한 플래투닝 SoS에 대한 실패 보고서로 정리했다. 전술한 실패 시나리오는 이전에 VENTOS 또는 기타 관련 플래투닝 시뮬레이터 저장소에 대해 보고된 적이 없다. 보고된 실패 시나리오는 테스트 벤치마크로 사용되며 일반 플래투닝 시스템을 위한 실패 지식 데이터베이스를 강화시킬 것으로 예상한다. 자세한 실패 보고서는 저장소에 포함될 수 있다.
다양한 시스템 도메인에 대한 철저한 조사에 기초하여 상호작용 특성을 정의했음에도 불구하고, 본 연구에서 고려된 특성들이 SoS에서 가능한 모든 유형의 실패를 분석하기에 충분하다고 결론짓기는 어렵다. 특정한 예외적인 실패 사례는 외부의 근본 원인에 의해 유도된다. 예를 들어 플래투닝 SoS 시뮬레이션에서 인간 구동 차량(HDV) 부분에서 다중 충돌 관련 실패가 관찰된다. 그러나 VENTOS는 사례연구에 사용된 플래투닝 시뮬레이터는 플래투닝 동작의 내부 마이크로 명령만 기록하고 센서 레벨 정보는 기록하지 않기 때문에 충돌 배후에서 외부 원인을 식별하기에 충분한 정보를 제공할 수 없다. 향후 동작에서는 외부 요인에 의한 실패도 감안하여 상호작용 모델과 시뮬레이터를 일반화하고자 한다.
대규모 시스템, 특히 플래투닝 SoS에서의 상호작용 실패를 보고한 최초의 연구이다. 그 결과, 검토 중인 플래투닝 SoS에 대해 적절한 테스트 벤치마크를 획득할 수 없어, 실행 로그, 오라클 및 실패 시나리오 및 해당 원인에 대한 데이터를 제공할 수 없었다. 따라서 본 사례 연구에서는 상호작용 실패에 대한 출력 및 생성된 실패 지식을 수동으로 조사했다. 본 연구에서 얻은 실패 지식은 향후 연구에서 플래투닝 SoS를 위한 벤치마크나 일반적인 실패 지식으로 활용될 것으로 기대한다.
경험적 가치가 80%인 op 성공률 속성도 활용했다. 플래투닝 시스템을 시뮬레이션하고 검증한 연구를 조사했지만, 대부분은 모의실험이 끝날 때까지 플래툰을 유지보수하거나, 또는 단일 운전실행의 검증 등 플래툰에 대한 기본적인 테스팅 기준을 사용했다. 그 대신 ISO26262와 같은 국제 표준에 근거하여 플래투닝 SoS에 대한 설득력 있는 속성을 생성하려고 시도했다. 그러나 최근 일부 연구에서는 ISO26262와 같은 기존 표준이 자율주행에 초점을 맞추고 있어 플래투닝 SoS의 요건을 완전히 충족시킬 수 없다고 보고하고 있다. 본 실시예에 따른 연구에서는 클라우드 시스템의 테스팅에서 사용된 성공 요청률(PSR)을 바탕으로 운영 성공률을 벤치마킹하여 소대 시스템의 시뮬레이션 로그에 적용하도록 수정하였다.
이상과 같이, 해당 기술의 대상인 대규모 복잡 시스템, SoS는 4차 산업혁명 이후 국제 표준등록 및 다양한 예시로써 차세대 시스템 유형으로 주목 받고 있다. 대표적인 예시로는 스마트 홈, 스마트 시티, 스마트 플랜트, 지능형 교통 시스템, 그리고 재난 대응 시스템 등이 있다. 해당 기술은 일반적인 SoS를 대상으로 만들었으며, 시스템으로부터 필요한 주요한 입력 값이 시스템 실행 기록이라는 점에서 적용-응용분야가 광범위하다고 볼 수 있다.
스마트 홈, 지능형 교통 시스템 등과 같은 대규모 복잡 시스템이 차세대 시스템 유형으로 자리잡아가고 있는 가운데, 대규모 복잡 시스템 내에서 다양한 이종(Heterogeneous) 시스템들간 발생할 수 있는 상호작용 버그를 디자인 수준에서 미리 대응하는 것은 현실적으로 불가능하다. 또한, 대규모 복잡 시스템이 실패했을 경우 발생될 수 있는 피해 영향은 사용자에게 단순 불편함을 줄 수 있는 수준에서부터, 인명에 큰 영향을 끼칠 수 있는 경우도 존재한다. 따라서 대규모 복잡 시스템에 존재하는 상호작용 버그를 시스템 출시 이전에 효율적, 효과적으로 해결하는 기술은 반드시 필요하다.
대규모 복잡 시스템은 단일 시스템이 달성할 수 없었던 목표들을 달성 가능하게 하는 시스템으로 다양한 분야에서 활용될 수 있다. 이러한 시스템들을 생성하는 데에는 많은 노력이 필요하지만, 시스템 내에 존재하는 오류를 해결하는 데에도 방대한 비용이 필요하다. 해당 기술은 대규모 복잡 시스템 내에서 예측하지 못한 상호작용 버그를 해결하는데 필요한 인적, 시간적 자원을 감소시킬 수 있다.
이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 컨트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 컨트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.
실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.
이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.
그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (20)

  1. 컴퓨터 장치를 통해 구현되는 패턴 기반 SoS(System-of-Systems) 내 실패 유발 상호작용 분석 방법에 있어서,
    시스템의 실행 로그에 존재하는 데이터로부터 SoS 실행 중 실행되는 구성 시스템(Constituent System, CS)과 상호작용을 식별하여, SoS에 대한 상호작용 모델을 생성하는 단계; 및
    생성된 상기 상호작용 모델에서 LCS(Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 이용하여 실패를 유발하는 의심스러운 상호작용 패턴을 추출하는 단계
    를 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  2. 제1항에 있어서,
    추출된 상기 의심스러운 상호작용 패턴을 분석하는 단계
    를 더 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  3. 제1항에 있어서,
    상기 SoS에 대한 상호작용 모델을 생성하는 단계는,
    상기 실행 로그와 목표 속성 검사의 통과 또는 실패 결과라는 두 가지 입력을 사용하여 상기 SoS에 대한 상호작용 모델을 생성하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  4. 제1항에 있어서,
    상기 SoS에 대한 상호작용 모델을 생성하는 단계는,
    상기 실행 로그에 존재하는 데이터로부터 단일 SoS 실행 중 실행되는 구성 시스템(CS)과 상호작용 메시지 시퀀스를 식별하는 단계
    를 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  5. 제1항에 있어서,
    상기 SoS에 대한 상호작용 모델을 생성하는 단계는,
    외부 모듈을 통해 기록된 각 상기 실행 로그의 목표 속성 검사 결과인 통과 또는 실패 태그를 각 상기 상호작용 모델에 첨부하는 단계
    를 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  6. 제1항에 있어서,
    상기 SoS에 대한 상호작용 모델을 생성하는 단계는,
    식별된 구성 시스템(CS)의 집합, 식별된 상호작용 메시지 시퀀스, 및 각 상기 실행 로그의 목표 속성 검사의 통과 여부를 표시하는 통과 또는 실패 태그를 통합하여 각 상기 상호작용 모델을 생성하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  7. 제1항에 있어서,
    상기 의심스러운 상호작용 패턴을 추출하는 단계는,
    생성된 상기 상호작용 모델에서 DP-LCS(Dynamic Programming for Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 실행하여, 각 카테고리에 공통되는 패턴을 포함하는 LCS 패턴과 분류된 상호작용 모델을 출력하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  8. 제1항에 있어서,
    상기 의심스러운 상호작용 패턴을 추출하는 단계는,
    의심스러운 LCS 지식부로부터 추출된 LCS 패턴과 상기 상호작용 모델을 비교하는 단계;
    상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하지 않는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부에 새로운 LCS 패턴으로 추가하는 단계; 및
    상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부의 동일한 카테고리에 할당하는 단계
    를 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  9. 제2항에 있어서,
    상기 의심스러운 상호작용 패턴을 분석하는 단계는,
    SoS 엔지니어는 추출된 상기 의심스러운 상호작용 패턴을 분석함에 따라 분류된 LCS 패턴과 상호작용 모델을 분석하여 실패의 근본 원인과 발생 상황에 대한 정보를 획득하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  10. 제1항에 있어서,
    시나리오 생성 모듈을 이용하여 플래투닝 SoS의 랜덤 시나리오를 생성하는 단계; 및
    시뮬레이션 모듈을 이용하여 생성된 상기 랜덤 시나리오에 대한 실행 로그를 생성하는 단계
    를 더 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법.
  11. 패턴 기반 SoS(System-of-Systems) 내 실패 유발 상호작용 분석 장치에 있어서,
    시스템의 실행 로그에 존재하는 데이터로부터 SoS 실행 중 실행되는 구성 시스템(Constituent System, CS)과 상호작용을 식별하여, SoS에 대한 상호작용 모델을 생성하는 상호작용 모델 생성부; 및
    생성된 상기 상호작용 모델에서 LCS(Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 이용하여 실패를 유발하는 의심스러운 상호작용 패턴을 추출하는 패턴 마이닝부
    를 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  12. 제11항에 있어서,
    추출된 상기 의심스러운 상호작용 패턴을 분석하는 패턴 분석부
    를 더 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  13. 제11항에 있어서,
    상기 상호작용 모델 생성부는,
    상기 실행 로그와 목표 속성 검사의 통과 또는 실패 결과라는 두 가지 입력을 사용하여 상기 SoS에 대한 상호작용 모델을 생성하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  14. 제11항에 있어서,
    상기 상호작용 모델 생성부는,
    상기 실행 로그에 존재하는 데이터로부터 단일 SoS 실행 중 실행되는 구성 시스템(CS)과 상호작용 메시지 시퀀스를 식별하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  15. 제11항에 있어서,
    상기 상호작용 모델 생성부는,
    외부 모듈을 통해 기록된 각 상기 실행 로그의 목표 속성 검사 결과인 통과 또는 실패 태그를 각 상기 상호작용 모델에 첨부하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  16. 제11항에 있어서,
    상기 상호작용 모델 생성부는,
    식별된 구성 시스템(CS)의 집합, 식별된 상호작용 메시지 시퀀스, 및 각 상기 실행 로그의 목표 속성 검사의 통과 여부를 표시하는 통과 또는 실패 태그를 통합하여 각 상기 상호작용 모델을 생성하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  17. 제11항에 있어서,
    상기 패턴 마이닝부는,
    생성된 상기 상호작용 모델에서 DP-LCS(Dynamic Programming for Longest Common Subsequence) 기반 의심스러운 상호작용 패턴 마이닝 알고리즘을 실행하여, 각 카테고리에 공통되는 패턴을 포함하는 LCS 패턴과 분류된 상호작용 모델을 출력하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  18. 제11항에 있어서,
    상기 패턴 마이닝부는,
    의심스러운 LCS 지식부로부터 추출된 LCS 패턴과 상기 상호작용 모델을 비교하고, 상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하지 않는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부에 새로운 LCS 패턴으로 추가하며, 상기 추출된 LCS 패턴과 상기 상호작용 모델 사이에 LCS가 존재하는 경우, 상기 상호작용 모델을 상기 의심스러운 LCS 지식부의 동일한 카테고리에 할당하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  19. 제12항에 있어서,
    상기 패턴 분석부는,
    SoS 엔지니어는 추출된 상기 의심스러운 상호작용 패턴을 분석함에 따라 분류된 LCS 패턴과 상호작용 모델을 분석하여 실패의 근본 원인과 발생 상황에 대한 정보를 획득하는 것
    을 특징으로 하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
  20. 제11항에 있어서,
    플래투닝 SoS의 랜덤 시나리오를 생성하는 시나리오 생성 모듈; 및
    생성된 상기 랜덤 시나리오에 대한 실행 로그를 생성하는 시뮬레이션 모듈
    을 더 포함하는, 패턴 기반 SoS 내 실패 유발 상호작용 분석 장치.
KR1020200183097A 2020-12-24 2020-12-24 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치 KR102643598B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020200183097A KR102643598B1 (ko) 2020-12-24 2020-12-24 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치
JP2021164887A JP7299640B2 (ja) 2020-12-24 2021-10-06 パターンベースＳｏＳ内の失敗誘発相互作用を分析する方法および装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020200183097A KR102643598B1 (ko) 2020-12-24 2020-12-24 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치

Publications (2)

Publication Number Publication Date
KR20220091897A KR20220091897A (ko) 2022-07-01
KR102643598B1 true KR102643598B1 (ko) 2024-03-06

Family

ID=82270940

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020200183097A KR102643598B1 (ko) 2020-12-24 2020-12-24 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치

Country Status (2)

Country Link
JP (1) JP7299640B2 (ko)
KR (1) KR102643598B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102523671B1 (ko) * 2022-11-07 2023-04-20 메타빌드 주식회사 자율 주행 시스템의 로그 기반 이상 탐지 시스템 및 방법

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104461842A (zh) * 2013-09-23 2015-03-25 伊姆西公司 基于日志相似性来处理故障的方法和装置
US20200145299A1 (en) 2018-11-06 2020-05-07 Telefonaktiebolaget Lm Ericsson (Publ) System and method for providing intelligent diagnostic support for cloud-based infrastructure

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3447595B1 (en) 2017-08-23 2022-10-05 ABB Schweiz AG Method for monitoring an industrial plant and industrial control system
CN111930903A (zh) 2020-06-30 2020-11-13 山东师范大学 基于深度日志序列分析的系统异常检测方法及系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104461842A (zh) * 2013-09-23 2015-03-25 伊姆西公司 基于日志相似性来处理故障的方法和装置
US20200145299A1 (en) 2018-11-06 2020-05-07 Telefonaktiebolaget Lm Ericsson (Publ) System and method for providing intelligent diagnostic support for cloud-based infrastructure

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"SIMVA-SoS: Simulation-based Verification and Analysis for System-of-Systems", 2020 IEEE 15th International Conference of System of Systems Engineering(pp. 575-580), 2020.07.01.
"Statistical Verification Framework for Platooning System of Systems with Uncertainty", 2019 26th Asia-Pacific Software Engineering Conference(pp. 212-219), 2020.01.02.*

Also Published As

Publication number Publication date
JP7299640B2 (ja) 2023-06-28
JP2022101455A (ja) 2022-07-06
KR20220091897A (ko) 2022-07-01

Similar Documents

Publication Publication Date Title
US11755919B2 (en) Analytics for an automated application testing platform
CN110262972B (zh) 一种面向微服务应用的失效测试工具及方法
AU2015201161B2 (en) Event correlation
US9672137B1 (en) Shadow test replay service
US8352907B2 (en) Software application recreation
Aarts et al. Improving active Mealy machine learning for protocol conformance testing
Kumar et al. Inferring class level specifications for distributed systems
CN111831574B (zh) 回归测试规划方法、装置、计算机系统和介质
CN105279196A (zh) 测试脚本的生成方法和装置
CN113590454A (zh) 测试方法、装置、计算机设备和存储介质
KR102643598B1 (ko) 패턴 기반 SoS 내 실패 유발 상호작용 분석 방법 및 장치
Selay et al. Adaptive random testing for image comparison in regression web testing
Hyun et al. Pattern-based analysis of interaction failures in systems-of-systems: A case study on platooning
Hassine et al. A framework for the recovery and visualization of system availability scenarios from execution traces
CN110069400A (zh) 漏洞测试报告生成方法、装置、计算机设备和存储介质
Salva et al. Automated test case generation for service composition from event logs
Keren et al. Model-based diagnosis with multi-label classification
CN108984397B (zh) 黑盒故障注入方法和系统及介质设备
CN113032270B (zh) 一种基于流量对比的白盒仿真测试方法及系统
Andonov et al. logs2graphs: Data-driven graph representation and visualization of log data
Kustarev et al. Functional monitoring of SoC with dynamic actualization of behavioral model
CN114218056B (zh) 交易系统的性能测试方法、装置、计算机设备及存储介质
Bozzano et al. Formal Specification and Synthesis of FDI through an Example
Shin et al. Spectrum-based fault localization on a collaboration graph of a system-of-systems
Hosseini et al. A survey on efficient diagnosability tests for automata and bounded Petri nets

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right