KR101440299B1 - 자가 치유 시스템 및 그 방법 - Google Patents
자가 치유 시스템 및 그 방법 Download PDFInfo
- Publication number
- KR101440299B1 KR101440299B1 KR1020100113888A KR20100113888A KR101440299B1 KR 101440299 B1 KR101440299 B1 KR 101440299B1 KR 1020100113888 A KR1020100113888 A KR 1020100113888A KR 20100113888 A KR20100113888 A KR 20100113888A KR 101440299 B1 KR101440299 B1 KR 101440299B1
- Authority
- KR
- South Korea
- Prior art keywords
- healing
- self
- software
- performance evaluation
- unit
- Prior art date
Links
Images
Classifications
-
- 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/0706—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 the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—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 the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
-
- 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/0793—Remedial or corrective actions
Abstract
본 발명은 크리티칼 시스템의 자가 치유를 위한 시스템 및 방법에 관한 것이다. 본 발명은 대상 크리티칼 시스템의 현재 상황을 모니터링하고, 모니터링 결과를 분석하여 시스템 오류 여부를 판별하며, 시스템 오류가 있을 경우 자가 치유가 가능한지 여부에 따라 현 상태에서 자가 치유를 수행할 것인지 최소한의 기본 서비스만 제공 가능한 안전 소프트웨어를 구동시킬 것인지를 판단하고, 시스템 오류를 치유시킨 뒤 자가 치유 성능을 평가한다. 본 발명에 따르면, 계속적으로 소프트웨어 서비스를 제공할 수 있으며, 자가 치유 성능 평가를 통해 자가 치유 시스템의 신뢰성을 더욱 향상시킬 수가 있다.
Description
본 발명은 자가 치유(self-healing)를 위한 시스템 및 방법에 관한 것이다. 보다 상세하게는, 크리티칼 시스템(critical system)의 자가 치유를 위한 시스템 및 방법에 관한 것이다.
최근 폭넓게 사용되고 있는 일반적인 임베디드 시스템은 사용자나 외부의 입력에 대하여 정해진 특정한 응답 또는 처리를 하도록 설계된다. 그러나, 대부분의 임베디드 시스템이 사용되는 환경에서는 미리 정의된 형태의 입력 뿐만 아니라 다양한 형태의 입력이 존재한다. 심지어는 발생되지 않아야 하는 형태의 입력이 발생하기도 한다. 이러한 비정상적인 입력은 컴퓨터 시스템을 오류 상태로 만들어 정상적인 동작이 불가능하게 한다. 특히 사람의 생명을 좌우하는 세이프티 크리티칼 시스템(safety critical system), 우주선이나 미사일 유도와 같은 군사용에 사용되어 시스템의 오류 발생시 막대한 손실이 발생하는 미션 크리티칼 시스템(mission critical system), 주식이나 증권 등 돈과 관련된 비즈니스 크리티칼 시스템(business critical system)에도 임베디드 시스템이 사용됨에 따라 외부의 불확실한 입력에 의해 시스템이 서비스를 제공하지 못한다거나 부정확한 결과를 만들어 내는 것은 큰 문제가 된다. 따라서, 현재 이러한 오류가 발생된 시스템이 스스로 오류를 치유하여 정상적으로 동작할 수 있게 하는 자가 치유 기술이 개발되고 있다.
그러나, 종래의 자가 치유 시스템은 각각의 시스템마다 개별적으로 자신의 판단에 따라 정해진대로 동작되도록 구성되어 있어, 불확실성이 지배하는 현실 세계에서는 운영 환경에 대한 전체적인 상태를 판단할 수 없다는 문제점을 가지고 있다. 또한, 종래의 자가 치유 시스템은 자가 치유를 수행한 이후의 결과에 대한 평가를 수행하지 않기 때문에 자가 치유 시스템이 발생한 오류에 따라 적절하게 자가 치유를 수행했는지 여부를 알 수 없다는 문제점을 가지고 있다.
본 발명은 상기한 문제점을 해결하기 위해 안출된 것으로서, 수많은 시스템에서 다양한 종류의 응용프로그램이 동작하는 실제 환경에서 크리티칼 시스템의 오류를 스스로 치유하고, 발생된 오류에 대응하여 자가 치유 기능이 동작했을 경우 자가 치유 성능을 평가하여 다음번 치유에 활용하는 자가 치유 시스템 및 그 방법을 제공함을 목적으로 한다.
본 발명은 상기한 목적을 달성하기 위해 안출된 것으로서, 시스템의 환경이나 시스템을 구성하는 컴포넌트들에 대한 모니터링 결과를 분석하여 시스템 오류 발생 여부를 판별하는 시스템 오류 판별부; 시스템 오류가 발생되면 시스템 오류에 대한 자가 치유 가능 여부에 따라 대응 방안을 선택하는 대응 방안 선택부; 선택된 대응 방안을 반영하여 시스템에서 소프트웨어 서비스를 계속적으로 제공하는 소프트웨어 서비스 제공부; 및 선택된 대응 방안이 시스템 오류 자가 치유이면 치유 결과를 기초로 치유 성능을 평가하는 치유 성능 평가부를 포함하는 것을 특징으로 하는 자가 치유 시스템을 제공한다.
바람직하게는, 상기 대응 방안 선택부는 대응 방안으로 오류 발생된 소프트웨어를 자가 치유시킬 것인지 또는 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시킬 것인지를 선택하거나, 상기 소프트웨어 서비스 제공부는, 선택된 대응 방안이 시스템 오류 자가 치유이면, 오류 발생된 소프트웨어를 자가 치유시키는 자가 치유부; 및 선택된 대응 방안이 시스템 오류 자가 치유가 아니면, 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시키는 안전 소프트웨어 실행부를 포함한다. 더욱 바람직하게는, 상기 자가 치유부는, 오류 발생된 소프트웨어 내부의 치유 코드를 제어하여 소프트웨어 내부적으로 치유를 수행하는 내부 치유부; 또는 오류 발생된 소프트웨어 외부에서 해당 소프트웨어의 내용을 추가/수정/삭제하여 치유를 수행하는 외부 치유부를 포함한다. 또는, 상기 소프트웨어 서비스 제공부는, 컴포넌트마다 설정된 액츄에이터를 관리하며, 상기 액츄에이터를 이용하여 소프트웨어 실행을 요청하는 컴포넌트와 실행 요청된 소프트웨어를 연결시키는 서비스 실행부; 및 선택된 대응 방안에 따라 상기 자가 치유부 또는 상기 안전 소프트웨어 실행부를 제어하며, 시스템의 환경을 고려하여 동일한 서비스와 연관된 소프트웨어들을 동시 실행시키는 서비스 운영 제어부를 더욱 포함한다.
바람직하게는, 상기 자가 치유 시스템은 적어도 하나의 크리티칼 시스템(critical system)의 환경이나 적어도 하나의 크리티칼 시스템을 구성하는 컴포넌트들에 대해 모니터링을 수행하는 모니터링부를 더욱 포함한다. 더욱 바람직하게는, 상기 자가 치유 시스템은 컴포넌트를 구성하는 클래스에 대한 정보, 컴포넌트의 상태 정보, 및 컴포넌트들 간 관계 정보 중 적어도 하나의 정보를 정의하는 정의부를 더욱 포함한다. 더욱더 바람직하게는, 상기 모니터링부는 정의된 정보를 기초로 모니터링을 수행하며, 상기 치유 성능 평가부는 정의된 정보에 의한 신뢰성(reliability)과 시스템 성능(performability) 중 적어도 하나를 포함하는 시스템 특성을 상기 치유 성능으로 평가한다.
바람직하게는, 상기 치유 성능 평가부는, 모니터링 방법의 기초가 되는 모니터링 정책, 치유 성능 평가의 기초가 되는 성능 평가 정책, 및 소프트웨어의 자가 치유와 관련된 자가 치유 정책을 저장하는 정책 데이터베이스; 모니터링 대상이 되는 모델들로부터 성능 평가를 위한 모델을 분리하여 분석하며, 분석 결과를 기초로 성능 평가 정책을 결정하는 성능 평가 모델 분석부; 및 결정된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 평가하는 치유 성능 평가 엔진을 포함한다. 더욱 바람직하게는, 상기 치유 성능 평가 엔진은, 자가 치유 뒤 시스템의 환경과 관련한 정보를 수집하는 정보 수집부; 수집된 정보를 기초로 상기 성능 평가 모델 분석부에 의해 성능 평가 정책이 결정되면, 결정된 성능 평가 정책을 적재시키는 정책 적재부; 및 적재된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 정량적으로 평가하는 성능 평가부를 포함하거나, 상기 성능 평가 모델 분석부는, 상기 정보 수집부에 의해 수집된 정보와 상기 정책 데이터베이스에 저장된 정책을 기초로 자가 치유 성능 평가를 위한 성능 평가 모델을 분석하며, 성능 평가 모델의 자가 치유 전 상태와 성능 평가 모델의 자가 치유 뒤 상태를 비교하여 자가 치유 성능에 대한 분석 정보를 생성하는 분석 정보 생성부; 및 생성된 분석 정보를 기초로 성능 평가 정책을 결정하는 정책 결정부를 포함한다.
바람직하게는, 상기 자가 치유 시스템은 평가된 치유 성능을 기초로 자가 치유된 소프트웨어에 대한 자가 치유 결과를 학습하는 것으로서, 자가 치유 이전보다 자가 치유 뒤 시스템 성능이 떨어지면 기계 학습 알고리즘을 기초로 상기 학습을 수행하는 치유 결과 학습부를 더욱 포함한다. 더욱 바람직하게는, 상기 치유 결과 학습부는 수행된 학습에 따라 미리 저장된 모니터링 정책도 변경한다.
또한, 본 발명은 시스템의 환경이나 시스템을 구성하는 컴포넌트들에 대한 모니터링 결과를 분석하여 시스템 오류 발생 여부를 판별하는 시스템 오류 판별 단계; 시스템 오류가 발생되면 시스템 오류에 대한 자가 치유 가능 여부에 따라 대응 방안을 선택하는 대응 방안 선택 단계; 선택된 대응 방안을 반영하여 시스템에서 소프트웨어 서비스를 계속적으로 제공하는 소프트웨어 서비스 제공 단계; 및 선택된 대응 방안이 시스템 오류 자가 치유이면 치유 결과를 기초로 치유 성능을 평가하는 치유 성능 평가 단계를 포함하는 것을 특징으로 하는 자가 치유 방법을 제공한다.
바람직하게는, 상기 대응 방안 선택 단계는 대응 방안으로 오류 발생된 소프트웨어를 자가 치유시킬 것인지 또는 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시킬 것인지를 선택하거나, 상기 소프트웨어 서비스 제공 단계는, 선택된 대응 방안이 시스템 오류 자가 치유이면, 오류 발생된 소프트웨어를 자가 치유시키는 자가 치유 단계; 및 선택된 대응 방안이 시스템 오류 자가 치유가 아니면, 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시키는 안전 소프트웨어 실행 단계 중 어느 한 단계를 포함한다. 더욱 바람직하게는, 상기 자가 치유 단계는, 오류 발생된 소프트웨어 내부의 치유 코드를 제어하여 소프트웨어 내부적으로 치유를 수행하는 내부 치유 단계; 또는 오류 발생된 소프트웨어 외부에서 해당 소프트웨어의 내용을 추가/수정/삭제하여 치유를 수행하는 외부 치유 단계를 포함한다. 또는, 상기 소프트웨어 서비스 제공 단계는, 컴포넌트마다 설정된 액츄에이터를 관리하며, 상기 액츄에이터를 이용하여 소프트웨어 실행을 요청하는 컴포넌트와 실행 요청된 소프트웨어를 연결시키는 서비스 실행 단계; 및 선택된 대응 방안에 따라 상기 자가 치유 단계 또는 상기 안전 소프트웨어 실행 단계가 수행되도록 제어하며, 시스템의 환경을 고려하여 동일한 서비스와 연관된 소프트웨어들을 동시 실행시키는 서비스 운영 제어 단계를 더욱 포함한다.
바람직하게는, 상기 자가 치유 방법은 적어도 하나의 크리티칼 시스템(critical system)의 환경이나 적어도 하나의 크리티칼 시스템을 구성하는 컴포넌트들에 대해 모니터링을 수행하는 모니터링 단계를 더욱 포함한다. 더욱 바람직하게는, 상기 자가 치유 방법은 컴포넌트를 구성하는 클래스에 대한 정보, 컴포넌트의 상태 정보, 및 컴포넌트들 간 관계 정보 중 적어도 하나의 정보를 정의하는 정의 단계를 더욱 포함한다. 더욱더 바람직하게는, 상기 모니터링 단계는 정의된 정보를 기초로 모니터링을 수행하며, 상기 치유 성능 평가 단계는 정의된 정보에 의한 신뢰성(reliability)과 시스템 성능(performability) 중 적어도 하나를 포함하는 시스템 특성을 상기 치유 성능으로 평가한다.
바람직하게는, 상기 치유 성능 평가 단계는, 모니터링 방법의 기초가 되는 모니터링 정책, 치유 성능 평가의 기초가 되는 성능 평가 정책, 및 소프트웨어의 자가 치유와 관련된 자가 치유 정책을 미리 저장하는 정책 데이터베이스 구축 단계; 모니터링 대상이 되는 모델들로부터 성능 평가를 위한 모델을 분리하여 분석하며, 분석 결과를 기초로 성능 평가 정책을 결정하는 성능 평가 모델 분석 단계; 및 결정된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 평가하는 치유 성능 평가 엔진 구동 단계를 포함한다. 더욱 바람직하게는, 상기 치유 성능 평가 엔진 구동 단계는, 자가 치유 뒤 시스템의 환경과 관련한 정보를 수집하는 정보 수집 단계; 수집된 정보를 기초로 성능 평가 정책이 결정되면, 결정된 성능 평가 정책을 적재시키는 정책 적재 단계; 및 적재된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 정량적으로 평가하는 성능 평가 단계를 포함하거나, 상기 성능 평가 모델 분석 단계는, 상기 정보 수집 단계에서 수집된 정보와 미리 저장된 정책을 기초로 자가 치유 성능 평가를 위한 성능 평가 모델을 분석하며, 성능 평가 모델의 자가 치유 전 상태와 성능 평가 모델의 자가 치유 뒤 상태를 비교하여 자가 치유 성능에 대한 분석 정보를 생성하는 분석 정보 생성 단계; 및 생성된 분석 정보를 기초로 성능 평가 정책을 결정하는 정책 결정 단계를 포함한다.
바람직하게는, 상기 자가 치유 방법은 평가된 치유 성능을 기초로 자가 치유된 소프트웨어에 대한 자가 치유 결과를 학습하는 것으로서, 자가 치유 이전보다 자가 치유 뒤 시스템 성능이 떨어지면 기계 학습 알고리즘을 기초로 상기 학습을 수행하는 치유 결과 학습 단계를 더욱 포함한다. 더욱 바람직하게는, 상기 치유 결과 학습 단계는 수행된 학습에 따라 미리 저장된 모니터링 정책도 변경한다.
본 발명은 수많은 시스템에서 다양한 종류의 응용프로그램이 동작하는 실제 환경에서 크리티칼 시스템의 오류를 스스로 치유하고, 발생된 오류에 대응하여 자가 치유 기능이 동작했을 경우 자가 치유 성능을 평가하여 다음번 치유에 활용함으로써 다음과 같은 효과를 얻을 수 있다. 첫째, 크리티칼 시스템의 안전한 자가 치유를 위한 시스템을 개발할 때 운영 환경을 모니터링하고 그에 따라 안전 소프트웨어를 실행할 지 자가 치유를 수행할 지를 결정하여 상황에 따른 서비스를 제공할 수 있다. 다양한 응용프로그램이 존재하는 현실 세계에서는 응용프로그램마다 각각의 특성에 맞는 자가 치유 방법을 설계하고 개발해야 한다. 그러나, 수많은 응용프로그램별로 별도의 자가 치유 기능을 만드는 것은 거의 불가능하다. 본 발명에서는 응용프로그램별로 그에 맞는 자가 치유 기능을 용이하게 추가할 수 있으며, 자가 치유가 용이하지 않은 경우에는 100% 신뢰할 수 있는 미리 개발된 안전 소프트웨어를 실행하여, 어떠한 경우에도 서비스의 중단 없이 최소한의 기본 서비스를 제공할 수 있다. 둘째, 자가 치유 기능이 수행된 이후 자가 치유 성능을 평가하여 자가 치유 시스템의 신뢰성을 기존보다 더욱 높일 수 있다.
도 1은 본 발명의 바람직한 실시예에 따른 자가 치유 시스템을 개략적으로 도시한 블록도이다.
도 2는 자가 치유 시스템의 내부 구성을 세부적으로 도시한 블록도이다.
도 3은 크리티칼 시스템의 안전한 자가 치유를 위한 시스템의 구조도이다.
도 4는 상황 모니터의 구성도이다.
도 5는 자가 치유 성능 평가기의 구성도이다.
도 6은 서비스 운영 관리기의 구성도이다.
도 7은 본 발명의 바람직한 실시예에 따른 자가 치유 방법을 도시한 순서도이다.
도 8은 자가 치유 관리 방법을 수행하는 일실시예 흐름도이다.
도 2는 자가 치유 시스템의 내부 구성을 세부적으로 도시한 블록도이다.
도 3은 크리티칼 시스템의 안전한 자가 치유를 위한 시스템의 구조도이다.
도 4는 상황 모니터의 구성도이다.
도 5는 자가 치유 성능 평가기의 구성도이다.
도 6은 서비스 운영 관리기의 구성도이다.
도 7은 본 발명의 바람직한 실시예에 따른 자가 치유 방법을 도시한 순서도이다.
도 8은 자가 치유 관리 방법을 수행하는 일실시예 흐름도이다.
이하, 본 발명의 바람직한 실시예를 첨부된 도면들을 참조하여 상세히 설명한다. 우선 각 도면의 구성요소들에 참조 부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다. 또한, 이하에서 본 발명의 바람직한 실시예를 설명할 것이나, 본 발명의 기술적 사상은 이에 한정하거나 제한되지 않고 당업자에 의해 변형되어 다양하게 실시될 수 있음은 물론이다.
도 1은 본 발명의 바람직한 실시예에 따른 자가 치유 시스템을 개략적으로 도시한 블록도이다. 도 2는 자가 치유 시스템의 내부 구성을 세부적으로 도시한 블록도이다. 이하 설명은 도 1과 도 2를 참조한다.
도 1에 따르면, 자가 치유 시스템(100)은 시스템 오류 판별부(110), 대응 방안 선택부(120), 소프트웨어 서비스 제공부(130), 치유 성능 평가부(140) 및 주제어부(150)를 포함한다.
본 실시예에서 자가 치유 시스템(100)은 크리티칼 시스템(critical system)의 안전한 자가 치유를 위한 시스템이다. 자가 치유 시스템(100)은 크리티칼 시스템 상에서 발생하는 오류를 스스로 치유하는 안전한 자가 치유를 위한 시스템으로서, 크리티칼 시스템이 동작하는 운영 환경에 대해 모니터링하고, 그 결과를 바탕으로 크리티칼 시스템의 서비스를 재구성하기 위해 자가 치유를 수행하며, 자가 치유가 발생된 경우에는 자가 치유 수행 결과를 평가하는 방법을 통해 치유 정책을 업데이트하는 시스템이다.
시스템 오류 판별부(110)는 시스템의 환경이나 시스템을 구성하는 컴포넌트들에 대한 모니터링 결과를 분석하여 시스템 오류 발생 여부를 판별하는 기능을 수행한다.
대응 방안 선택부(120)는 시스템 오류가 발생되면 시스템 오류에 대한 자가 치유 가능 여부에 따라 대응 방안을 선택하는 기능을 수행한다. 대응 방안 선택부(120)는 대응 방안으로 오류 발생된 소프트웨어를 자가 치유시킬 것인지 또는 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시킬 것인지를 선택한다. 본 실시예에서 대응 방안 선택부(120)는 미리 개발된 것으로서 신뢰도가 100%인 소프트웨어를 안전 소프트웨어로 선택할 수 있다. 안전 소프트웨어는 해당 소프트웨어 서비스가 계속적으로 제공될 수 있게 서비스의 중단 없이 최소한의 기본 서비스를 제공하기 위한 것이다. 신뢰도는 통상의 소프트웨어 신뢰도 평가를 통해 얻을 수 있다. 한편, 대응 방안 선택부(120)는 유관 소프트웨어들 중에서 신뢰도가 가장 높은 소프트웨어를 안전 소프트웨어로 선택하는 것도 가능하다.
소프트웨어 서비스 제공부(130)는 선택된 대응 방안을 반영하여 시스템에서 소프트웨어 서비스를 계속적으로 제공하는 기능을 수행한다.
소프트웨어 서비스 제공부(130)는 도 2의 (a)에 도시된 바와 같이 자가 치유부(131)와 안전 소프트웨어 실행부(134)를 포함한다. 자가 치유부(131)는 선택된 대응 방안이 시스템 오류 자가 치유이면, 오류 발생된 소프트웨어를 자가 치유시키는 기능을 수행한다. 자가 치유부(131)는 내부 치유부(132) 또는 외부 치유부(133)를 포함할 수 있다. 내부 치유부(132)는 오류 발생된 소프트웨어 내부의 치유 코드를 제어하여 소프트웨어 내부적으로 치유를 수행한다. 반면, 외부 치유부(133)는 오류 발생된 소프트웨어 외부에서 해당 소프트웨어의 내용을 추가/수정/삭제하여 치유를 수행한다. 안전 소프트웨어 실행부(134)는 선택된 대응 방안이 시스템 오류 자가 치유가 아니면, 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시키는 기능을 수행한다.
한편, 소프트웨어 서비스 제공부(130)는 서비스 실행부(135)와 서비스 운영 제어부(136)를 더욱 포함할 수 있다. 서비스 실행부(135)는 컴포넌트마다 설정된 액츄에이터를 관리하며, 액츄에이터를 이용하여 소프트웨어 실행을 요청하는 컴포넌트와 실행 요청된 소프트웨어를 연결시키는 기능을 수행한다. 서비스 운영 제어부(136)는 선택된 대응 방안에 따라 자가 치유부(131) 또는 안전 소프트웨어 실행부(134)를 제어하는 기능을 수행한다. 서비스 운영 제어부(136)는 시스템의 환경을 고려하여 동일한 서비스와 연관된 소프트웨어들을 동시 실행시키는 기능도 수행할 수 있다.
치유 성능 평가부(140)는 선택된 대응 방안이 시스템 오류 자가 치유이면 치유 결과를 기초로 치유 성능을 평가하는 기능을 수행한다.
치유 성능 평가부(140)는 도 2의 (b)에 도시된 바와 같이 정책 데이터베이스(141), 성능 평가 모델 분석부(142), 및 치유 성능 평가 엔진(145)을 포함할 수 있다. 정책 데이터베이스(141)는 모니터링 방법의 기초가 되는 모니터링 정책, 치유 성능 평가의 기초가 되는 성능 평가 정책, 및 소프트웨어의 자가 치유와 관련된 자가 치유 정책을 저장한다. 성능 평가 모델 분석부(142)는 모니터링 대상이 되는 모델들로부터 성능 평가를 위한 모델을 분리하여 분석하며, 분석 결과를 기초로 성능 평가 정책을 결정하는 기능을 수행한다. 성능 평가 모델 분석부(142)는 정책 데이터베이스(141)와 연동되는 것으로서, 성능 평가 정책을 결정할 때에 정책 데이터베이스(141)에 저장되어 있는 성능 평가 정책을 활용한다. 성능 평가 모델 분석부(142)는 분석 정보 생성부(143)와 정책 결정부(144)를 포함할 수 있다. 분석 정보 생성부(143)는 정보 수집부(146)에 의해 수집된 정보와 정책 데이터베이스(141)에 저장된 정책을 기초로 자가 치유 성능 평가를 위한 성능 평가 모델을 분석하며, 성능 평가 모델의 자가 치유 전 상태와 성능 평가 모델의 자가 치유 뒤 상태를 비교하여 자가 치유 성능에 대한 분석 정보를 생성하는 기능을 수행한다. 정책 결정부(144)는 생성된 분석 정보를 기초로 성능 평가 정책을 결정하는 기능을 수행한다. 치유 성능 평가 엔진(145)은 결정된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 평가하는 기능을 수행한다. 치유 성능 평가 엔진(145)은 정보 수집부(146), 정책 적재부(147) 및 성능 평가부(148)를 포함할 수 있다. 정보 수집부(146)는 자가 치유 뒤 시스템의 환경과 관련한 정보를 수집하는 기능을 수행한다. 정보 수집부(146)가 수집하는 시스템 환경과 관련한 정보로는 시스템 외부 환경에 대한 정보, 자원 상태에 대한 정보, 로그 정보, 이벤트 신호, 자가 치유 정보 등이 있다. 정보 수집부(146)는 자가 치유된 소프트웨어, 상호작용하는 시스템 정보 등도 함께 수집할 수 있다. 정책 적재부(147)는 수집된 정보를 기초로 성능 평가 모델 분석부(142)에 의해 성능 평가 정책이 결정되면, 결정된 성능 평가 정책을 적재시키는 기능을 수행한다. 성능 평가부(148)는 적재된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 정량적으로 평가하는 기능을 수행한다.
주제어부(150)는 자가 치유 시스템(100)을 구성하는 각 부의 전체 작동을 제어하는 기능을 수행한다.
자가 치유 시스템(100)은 모니터링부(160)를 더욱 포함할 수 있다. 모니터링부(160)는 적어도 하나의 크리티칼 시스템(critical system)의 환경이나 적어도 하나의 크리티칼 시스템을 구성하는 컴포넌트들에 대해 모니터링을 수행하는 기능을 수행한다. 모니터링부(160)는 크리티칼 시스템 환경에서 컴포넌트들이 서로 다른 응용프로그램을 구동시킬 때에 모니터링을 수행할 수 있다.
자가 치유 시스템(100)은 정의부(170)를 더욱 포함할 수 있다. 정의부(170)는 컴포넌트를 구성하는 클래스에 대한 정보, 컴포넌트의 상태 정보, 및 컴포넌트들 간 관계 정보 중 적어도 하나의 정보를 정의하는 기능을 수행한다. 정의부(170)는 컴포넌트의 상태 정보로 상태 집합과 상태 전이를 포함한다. 상태 집합은 상태 이름, 상태로의 진입 전이, 상태에서의 탈출 전이 등으로 구성될 수 있으며, 상태 전이는 전이 이름, 전이의 시작 상태, 전이의 목적 상태 등으로 구성될 수 있다. 이때, 모니터링부(160)는 정의부(170)에 의해 정의된 정보를 기초로 모니터링을 수행할 수 있다. 또한, 치유 성능 평가부(140)는 정의부(170)에 의해 정의된 정보에 의한 신뢰성(reliability)과 시스템 성능(performability) 중 적어도 하나를 포함하는 시스템 특성을 치유 성능으로 평가할 수 있다.
자가 치유 시스템(100)은 치유 결과 학습부(180)를 더욱 포함할 수 있다. 치유 결과 학습부(180)는 평가된 치유 성능을 기초로 자가 치유된 소프트웨어에 대한 자가 치유 결과를 학습하는 것이다. 이러한 치유 결과 학습부(180)는 자가 치유 이전보다 자가 치유 뒤 시스템 성능이 떨어지면 기계 학습 알고리즘을 기초로 학습을 수행할 수 있다. 치유 결과 학습부(180)는 수행된 학습에 따라 미리 저장된 모니터링 정책도 변경할 수 있다.
한편, 치유 결과 학습부(180)는 평가된 치유 성능을 기초로 해당 소프트웨어에 대한 자가 치유 방법을 갱신하는 것도 가능하다. 이때, 치유 결과 학습부(180)는 평가된 치유 성능을 기초로 소프트웨어에 대한 현재 자가 치유 방법이 이전 자가 치유 방법보다 치유율이 더 우수하다면 해당 소프트웨어에 대한 자가 치유 방법을 이전 자가 치유 방법에서 현재 자가 치유 방법으로 변경한다. 반면, 이전 자가 치유 방법이 현재 자가 치유 방법보다 치유율이 더 우수하다면, 치유 결과 학습부(180)는 해당 소프트웨어에 대한 자가 치유 방법으로 이전 자가 치유 방법을 유지한다.
다음으로, 자가 치유 시스템(100)에 대한 일실시예를 설명한다. 본 실시예에 따른 자가 치유 시스템(100)은 크리티칼 시스템의 안전한 자가 치유를 위한 시스템으로서, 최근 임베디드 시스템이 수많은 분야에서 사용되기 시작함에 따라 시스템의 오류를 스스로 모니터링하고, 발생된 오류에 대응하여 자가 치유 기능을 동작시켜 서비스의 중단 없이 동작하는 시스템을 치유하기 위한 것이다. 오늘날 세이프티 크리티칼 시스템(safety critical system), 미션 크리티칼 시스템(mission critical system), 비즈니스 크리티칼 시스템(business critical system) 등 각종 크리티칼 시스템에 임베디드 시스템이 사용됨에 따라 시스템의 신뢰도에 대한 요구가 점점 더 증가하고 있다. 본 실시예에 따른 자가 치유 시스템(100)은 이러한 점을 고려하여 크리티칼 시스템이 운영 환경에서 동작하고 있는 것을 감시하는 상황 모니터, 최소한의 기능만을 가지고 100% 신뢰할 수 있는 안전 소프트웨어를 관리하는 안전 소프트웨어 운영기, 상황별 자가 치유 정책을 이용하여 모니터링 결과에 바탕한 자가 치유를 수행하는 자가치유 관리기, 자가 치유 성능을 평가하는 자가 치유 성능 평가기, 치유된 시스템의 서비스를 관리하는 서비스 운영 관리기, 안전 소프트웨어 저장소, 및 상황별 자가 치유 시스템 DB 등을 포함한다.
이하에서는 크리티칼 시스템의 안전한 자가 치유를 위한 시스템을 자가 치유 관리 시스템으로 명명한다. 자가 치유 관리 시스템이 구현될 수 있는 실제 운영 환경에는 다수의 시스템이 존재하며, 각 시스템 상에서는 다수의 응용프로그램(application program)이 포함될 수 있다. 일반적인 임베디드 시스템의 실제 운영 환경과 관련돼서 다른 공지 기술들 및 구성요소들에 대한 설명은 생략되며, 본 실시예가 속하는 기술 분야에서 통상의 지식을 가진 자라면 이하에서 설명하는 시스템과 관련하여 실제 운영 환경에서 구현될 수 있는 다양한 방식들이 존재한다는 것을 명확히 이해할 수 있을 것이다.
도 3은 자가 치유 관리 시스템의 구조(architecture)를 나타내고 있다. 자가 치유 관리 시스템(300)은 상황 모니터(310), 안전 소프트웨어 운영기(320), 자가 치유 관리기(330), 자가 치유 성능 평가기(340), 서비스 운영 관리기(350), 안전 소프트웨어 저장소(321) 및 상황별 자가 치유 시스템 DB(331)를 포함할 수 있다.
상황 모니터(310)는 도 1의 모니터링부(160)에 대응하는 구성으로서, 크리티칼 시스템(360)의 운영 환경 및 시스템(370)을 구성하고 있는 컴포넌트들을 모니터링한다. 상황 모니터(310)는 실제 운영 환경에서 응용프로그램의 동작 상태, 발생할 수 있는 오류 상태, 비정상적인 상태 등을 주로 모니터링한다.
도 4는 상황 모니터(310)의 내부 구성을 세부적으로 나타낸 것이다. 상황 모니터(310)는 다양한 센서를 포함하고 있는 센서 제어기(311)를 통해 필요한 정보를 획득한다. 이후 상황 판단기(312)를 통해 획득된 센싱 정보를 바탕으로 크리티칼 시스템이 오류 상태에 빠졌는지를 판단하며, 이를 해결하기 위해 자가 치유를 수행할 것인지 안전 소프트웨어를 운영할 것인지를 판단한다. 상황 모니터(310)에서 컴포넌트 단위의 모니터링을 제공하기 위해서는 컴포넌트를 구성하고 있는 클래스에 대한 정보 즉, 속성이나 함수 등이 필요하다. 따라서, 시스템을 구성하고 있는 컴포넌트들에 대한 정보를 정의함으로써 소스 코드 수준의 모니터링을 가능하게 하는 시스템 지식을 요구한다. 또한, 컴포넌트를 구성하고 있는 클래스들과 상태 정보를 정의함으로써 정확한 의도의 컴포넌트의 상태 및 실제 구현된 클래스에 대한 정보를 제공한다. 특히, 시스템을 구성하고 있는 컴포넌트들의 구성 및 이름에 대한 정보, 컴포넌트 간의 관계에 대한 정보 등을 포함함으로써 특정 컴포넌트에 문제 발생시 전체 시스템에 미치는 영향에 대한 정보를 제공한다. 각 컴포넌트는 컴포넌트를 구성하는 클래스들의 정보와 컴포넌트의 상태 정보로 구성된다. 클래스 정보는 클래스 집합과 클래스 간의 관계 집합으로 구성된다. 클래스는 클래스 이름, 속성 집합, 행동 집합 등으로 구성된다. 클래스의 이름, 속성, 함수 등의 이름은 구현된 코드를 분석하여 모니터링 대상을 식별할 때 요구되며, 클래스의 생성 및 속성의 변경, 함수의 수행과 같은 세부적인 수준의 모니터링을 가능하게 한다. 이러한 정보는 상황 모니터의 모니터링 정책 DB(313)에 저장된다.
안전 소프트웨어 운영기(320)는 크리티칼 시스템(360)의 각각의 소프트웨어에서 제공해야 하는 최소한의 서비스를 100% 안정적인 상태로 동작할 수 있는 소프트웨어를 가지고 있는 안전 소프트웨어 저장소(321)와 연동하여 필요한 안전 소프트웨어의 수행/관리/중지 등의 기능을 수행한다. 안전 소프트웨어 운영기(320)는 도 2 (a)의 안전 소프트웨어 실행부(134)에 대응하는 구성이다.
자가 치유 관리기(330)는 상황별 자가 치유 시스템 DB(331)를 이용하여 소프트웨어의 자가 치유를 수행한다. 자가 치유는 소프트웨어 내부의 치유 코드를 자가치유 관리기(330)가 제어하여 소프트웨어 내부적으로 치유를 수행하는 내부 치유(internal healing), 자가 치유 관리기(330)가 소프트웨어의 외부에서 소프트웨어를 변경/제어/수정하여 치유를 수행하는 외부 치유(external healing) 등으로 구분된다. 자가 치유 관리기(330)는 도 2 (a)의 자가 치유부(131)에 대응하는 구성으로, 내부 치유는 내부 치유부(132)가 수행할 수 있으며, 외부 치유는 외부 치유부(133)가 수행할 수 있다.
자가 치유를 위한 상태 정보는 상태 집합과 상태 전이로 구성된다. 상태 집합을 구성하는 상태 S는 상태 이름, 상태로의 진입 전이, 상태에서의 탈출 전이 등으로 구성된다. 상태 전이 집합을 구성하는 상태 전이 T는 전이 이름, 전이의 시작 상태, 전이의 목적 상태 등으로 구성된다. 이러한 상태 정보는 시스템 이상이 발생했을 때 특정 컴포넌트의 상태에 대한 정보를 제공한다. 시스템에 대한 컴포넌트의 모니터링을 수행하고 그 결과를 바탕으로 자가 치유를 수행하여 시스템의 신뢰성(reliability), 시스템 성능(performability) 등과 같은 시스템 특성을 평가할 수 있다. 이러한 정보는 상황별 자가 치유 시스템 DB(331)에 포함되어 있다.
자가 치유 성능 평가기(340)는 자가 치유 관리기(330)를 통해 상황별 자가 치유 시스템 DB(331)를 이용하여 상황별 치유 모델을 분석하고 자가 치유 성능을 평가한다. 자가 치유 성능 평가기(340)는 도 1의 치유 성능 평가부(140)에 대응하는 구성으로서, 그 일실시예에 따른 구성은 도 5에 도시된 바와 같다. 도 5를 참조하면, 자가 치유 성능 평가기(340)는 성능 평가 모델 분석기(341), 자가 치유 성능 평가 엔진(342), 성능 평가 정책 지식베이스(343) 등을 포함한다. 성능 평가 모델 분석기(341)는 도 2 (b)의 성능 평가 모델 분석부(142)에 대응하는 구성으로서, 모니터링 정보 모델에서 성능 평가 정보 모델을 분리하여 분석한다. 자가 치유 성능 평가 엔진(342)은 도 2 (b)의 치유 성능 평가 엔진(145)에 대응하는 구성으로, 성능 평가 모델 분석기(341)에서 결정한 성능 평가 모듈을 장착하여 성능 평가를 수행한다. 성능 평가 정책 지식베이스(343)는 도 2 (b)의 정책 데이터베이스(141)에 대응하는 구성으로, 자가 치유 시스템에 따라 변경될 수 있는 모니터링 정책, 성능 평가 정책 및 여러가지 오류 상황에 따라 달리 대응하는 자가 치유 시스템의 데이터 등의 정보가 저장될 수 있다.
서비스 운영 관리기(350)는 크리티칼 시스템(360)에서 동작하는 소프트웨어를 관리하고 외부 환경에 영향을 줄 수 있는 액츄에이터를 관리한다. 서비스 운영 관리기(350)는 도 6에 도시된 바와 같이 서비스 운영 제어기(351)와 서비스 실행기(352)로 구성된다. 서비스 운영 제어기(351)는 도 2 (a)의 서비스 운영 제어부(136)에 대응하는 구성으로, 안전 소프트웨어 운영기(320)와 자가 치유 관리기(330)에서 제공하는 정보를 바탕으로 안전 소프트웨어를 운영할 지 아니면 이에 해당하는 응용 소프트웨어를 운영할 지를 판단하여 적절한 소프트웨어를 운영한다. 각 소프트웨어는 동일한 서비스에 연관되어 있기 때문에 동시에 안전 소프트웨어와 응용 소프트웨어 중 하나의 소프트웨어만이 수행되며, 상황별로 여러 개의 안전 소프트웨어 또는 응용 소프트웨어가 동시에 수행될 수 있다. 서비스 실행기(352)는 도 2 (a)의 서비스 실행부(135)에 대응하는 구성으로서, 서비스 운영 제어기(351)에서 수행되는 소프트웨어와 크리티칼 시스템 외부를 연결하는 역할을 한다. 서비스 실행기(352)는 크리티칼 시스템별로 설치되어 있는 액츄에이터를 관리하며, 소프트웨어의 명령을 받아 실제 운영 환경에 작용하기 위해 액츄에이터를 구동한다.
다음으로, 자가 치유 시스템(100)의 자가 치유 방법에 대해서 설명한다. 도 7은 본 발명의 바람직한 실시예에 따른 자가 치유 방법을 도시한 순서도이다. 이하 설명은 도 7을 참조한다.
먼저, 시스템 오류 판별부(110)가 시스템의 환경이나 시스템을 구성하는 컴포넌트들에 대한 모니터링 결과를 분석하여 시스템 오류 발생 여부를 판별한다(시스템 오류 판별 단계, S700).
시스템 오류가 발생되면, 대응 방안 선택부(120)가 시스템 오류에 대한 자가 치유 가능 여부에 따라 대응 방안을 선택한다(대응 방안 선택 단계, S710). 대응 방안 선택 단계(S710)는 대응 방안으로 오류 발생된 소프트웨어를 자가 치유시킬 것인지 또는 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시킬 것인지를 선택할 수 있다.
이후, 소프트웨어 서비스 제공부(130)가 선택된 대응 방안을 반영하여 시스템에서 소프트웨어 서비스를 계속적으로 제공한다(소프트웨어 서비스 제공 단계, S720). 소프트웨어 서비스 제공 단계(S720)는 자가 치유 단계(S721)와 안전 소프트웨어 실행 단계(S722) 중 어느 한 단계를 포함할 수 있다. 자가 치유 단계(S721)는 선택된 대응 방안이 시스템 오류 자가 치유일 때 오류 발생된 소프트웨어를 자가 치유시키는 단계이다. 자가 치유 단계(S721)는 내부 치유 단계 또는 외부 치유 단계를 포함할 수 있다. 내부 치유 단계는 오류 발생된 소프트웨어 내부의 치유 코드를 제어하여 소프트웨어 내부적으로 치유를 수행하는 단계이다. 외부 치유 단계는 오류 발생된 소프트웨어 외부에서 해당 소프트웨어의 내용을 추가/수정/삭제하여 치유를 수행하는 단계이다. 안전 소프트웨어 실행 단계(S722)는 선택된 대응 방안이 시스템 오류 자가 치유가 아닐 때 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시키는 단계이다.
소프트웨어 서비스 제공 단계(S720)는 서비스 실행 단계와 서비스 운영 제어 단계를 더욱 포함할 수 있다. 서비스 실행 단계는 컴포넌트마다 설정된 액츄에이터를 관리하며, 액츄에이터를 이용하여 소프트웨어 실행을 요청하는 컴포넌트와 실행 요청된 소프트웨어를 연결시키는 단계이다. 서비스 실행 단계는 자가 치유 단계나 안전 소프트웨어 실행 단계 이전에 수행될 수 있다. 서비스 운영 제어 단계는 선택된 대응 방안에 따라 자가 치유 단계 또는 안전 소프트웨어 실행 단계가 수행되도록 제어한다. 서비스 운영 제어 단계는 시스템의 환경을 고려하여 동일한 서비스와 연관된 소프트웨어들을 동시 실행시키는 것도 가능하다. 서비스 운영 제어 단계는 자가 치유 단계나 안전 소프트웨어 실행 단계와 동시에 수행될 수 있다.
선택된 대응 방안이 시스템 오류 자가 치유이면, 치유 성능 평가부(140)가 치유 결과를 기초로 치유 성능을 평가한다(치유 성능 평가 단계, S730). 치유 성능 평가 단계(S730)는 정책 데이터베이스 구축 단계, 성능 평가 모델 분석 단계, 치유 성능 평가 엔진 구동 단계 등을 포함할 수 있다. 정책 데이터베이스 구축 단계는 모니터링 방법의 기초가 되는 모니터링 정책, 치유 성능 평가의 기초가 되는 성능 평가 정책, 및 소프트웨어의 자가 치유와 관련된 자가 치유 정책을 미리 저장하는 단계이다. 성능 평가 모델 분석 단계는 모니터링 대상이 되는 모델들로부터 성능 평가를 위한 모델을 분리하여 분석하며, 분석 결과를 기초로 성능 평가 정책을 결정하는 단계이다. 성능 평가 모델 분석 단계는 분석 정보 생성 단계와 정책 결정 단계를 포함할 수 있다. 분석 정보 생성 단계는 정보 수집부에 의해 수집된 정보와 정책 데이터베이스에 저장된 정책을 기초로 자가 치유 성능 평가를 위한 성능 평가 모델을 분석하며, 성능 평가 모델의 자가 치유 전 상태와 성능 평가 모델의 자가 치유 뒤 상태를 비교하여 자가 치유 성능에 대한 분석 정보를 생성하는 단계이다. 정책 결정 단계는 생성된 분석 정보를 기초로 성능 평가 정책을 결정하는 단계이다. 치유 성능 평가 엔진 구동 단계는 결정된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 평가하는 단계이다. 치유 성능 평가 엔진 구동 단계는 정보 수집 단계, 정책 적재 단계 및 성능 평가 단계를 포함할 수 있다. 정보 수집 단계는 자가 치유 뒤 시스템의 환경과 관련한 정보를 수집하는 단계이다. 정책 적재 단계는 수집된 정보를 기초로 성능 평가 모델 분석부에 의해 성능 평가 정책이 결정되면, 결정된 성능 평가 정책을 적재시키는 단계이다. 성능 평가 단계는 적재된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 정량적으로 평가하는 단계이다.
본 실시예에 따른 자가 치유 방법은 모니터링 단계, 정의 단계 및 치유 결과 학습 단계 중에서 적어도 하나의 단계를 더욱 포함할 수 있다.
모니터링 단계는 적어도 하나의 크리티칼 시스템(critical system)의 환경이나 적어도 하나의 크리티칼 시스템을 구성하는 컴포넌트들에 대해 모니터링을 수행하는 단계이다. 모니터링 단계는 시스템 오류 판별 단계(S700) 이전에 수행될 수 있다.
정의 단계는 컴포넌트를 구성하는 클래스에 대한 정보, 컴포넌트의 상태 정보, 및 컴포넌트들 간 관계 정보 중 적어도 하나의 정보를 정의하는 단계이다. 정의 단계는 모니터링 단계 이전에 수행될 수 있다. 이 경우, 모니터링 단계는 정의된 정보를 기초로 모니터링을 수행하며, 치유 성능 평가 단계는 정의된 정보에 의한 신뢰성(reliability)과 시스템 성능(performability) 중 적어도 하나를 포함하는 시스템 특성을 치유 성능으로 평가한다.
치유 결과 학습 단계는 평가된 치유 성능을 기초로 자가 치유된 소프트웨어에 대한 자가 치유 결과를 학습하는 단계이다. 치유 결과 학습 단계는 자가 치유 이전보다 자가 치유 뒤 시스템 성능이 떨어지면 기계 학습 알고리즘을 기초로 학습을 수행한다. 치유 결과 학습 단계는 치유 성능 평가 단계(S730) 이후에 수행될 수 있다. 치유 결과 학습 단계는 수행된 학습에 따라 미리 저장된 모니터링 정책도 변경할 수 있다.
다음으로, 자가 치유 방법의 일실시예에 대해서 설명한다. 본 실시예에 따른 크리티칼 시스템의 안전한 자가 치유를 위한 방법은 크리티칼 시스템의 운영 환경을 모니터링하는 단계, 모니터링 결과를 분석하여 오류가 발생했는지를 판단하는 단계, 치유가 필요한지 또는 안전 소프트웨어의 동작이 필요한지를 결정하는 단계, 안전 소프트웨어를 동작시키고 서비스를 제공하는 단계, 자가 치유를 수행하고 서비스를 제공하는 단계, 및 자가 치유 결과를 평가하여 치유 정책을 변경하는 단계를 포함한다.
도 8은 자가 치유 관리 방법에 대한 일실시예 흐름도이다. 이하 설명은 도 8을 참조한다.
제1 단계에서는 운영 환경 모니터링 단계에 의해 크리티칼 시스템이 운영되는 환경이 모니터링된다(S800). 운영 환경에는 시스템이 동작하는 외부 실제 환경 뿐만 아니라 하드웨어적인 운영 환경이나 소프트웨어적인 운영 환경도 포함된다. 일실시예로써, 사용자는 그래픽 사용자 인터페이스를 통해 자가 치유 시스템이 모니터링하고자 하는 운영 환경을 모델링할 수 있다.
제2 단계에서 상황 모니터는 모니터링한 결과를 바탕으로 현재 크리티칼 시스템이 오류 상태에 빠졌는지를 판단한다(S805). 만일 크리티칼 시스템이 오류 상태에 빠졌으면, 상황 모니터는 다음 단계로 자가 치유가 필요한 상황인지, 안전 소프트웨어가 실행되어야 하는 상황인지를 결정한다(S810). 안전 소프트웨어는 각 소프트웨어에서 제공해야 하는 최소한의 서비스를 100% 안정적인 상태로 동작할 수 있는 소프트웨어이며, 소프트웨어 정형 검증 및 다양한 테스트 기법을 통과한 소프트웨어로 개발자에 의해 미리 제작된다.
제3 단계는 안전 소프트웨어가 실행되는 단계이다(S815). 안전 소프트웨어가 실행되어야 하는 경우, 안전 소프트웨어 운영기를 통해 기존에 동작하고 있는 실행하고자 하는 안전 소프트웨어에 해당하는 응용 소프트웨어를 정지시키고, 안전 소프트웨어로 변경한 후 실행하여 서비스를 제공한다(S820).
제4 단계는 제3 단계와 반대의 경우로서 자가 치유가 필요한 경우이다. 이때에는 자가 치유 관리기를 통해 자가 치유를 수행한다(S825). 이 단계에서는 소프트웨어 내부의 치유 코드를 자가 치유 관리기가 제어하여 소프트웨어 내부적으로 치유를 수행하는 내부 치유(internal healing)와 자가 치유 관리기가 소프트웨어의 외부에서 소프트웨어를 변경/제어/수정하여 치유를 수행하는 외부 치유(external healing)로 구분하여 치유를 수행한다. 자가 치유 관리기에 의해 치유된 소프트웨어는 서비스 운영 관리기에 적재된 후 실행되어 크리티칼 시스템의 운영에 영향을 미친다(S830).
제5 단계는 자가 치유 결과를 평가하는 단계이다. 자가 치유 기능이 수행된 뒤, 자가 치유 성능 평가기는 상황 모니터를 통해 자가 치유가 반영된 후의 실제 운영 환경의 다양한 정보를 수집한다(S835). 이때에 수집되는 정보로는 외부 환경, 자원상태, 로그 정보, 이벤트 신호, 자가 치유 정보 등이 있다. 수집되는 정보에는 실제 운영 환경에서 자가 치유를 수행한 응용프로그램과 상호작용하는 시스템의 정보 등도 있다. 수집된 정보에 근거하여 상황별 자가 치유 시스템 DB 및 성능 평가 지식베이스를 이용하여 자가 치유 성능 평가를 위한 성능 평가 모델을 분석하며, 성능 평가 모델의 자가 치유가 발생하기 이전과 이후의 상태를 비교하여 자가 치유 성능을 분석할 수 있는 정보를 생성한다. 이후 분석 정보를 통해 결정된 자가 치유 성능 평가 모듈이 자가 치유 성능 평가 엔진에 적재된다. 자가 치유 성능은 적재된 성능 평가 모듈을 근거로 하여 정량적인 평가가 수행될 수 있다(S840). 이 단계에서 수행된 자가 치유 성능 평가는 사용자에게 보고될 수 있다.
제6 단계는 자가 치유 결과를 학습하는 단계이다. 제5 단계에서 정량적으로 평가된 결과를 바탕으로 치유 이전보다 치유 후 시스템의 성능이 떨어지는 경우에 한해(S845) 기계 학습 알고리즘을 바탕으로 치유 정책을 학습하며(S850), 그 결과는 다음번 치유에 사용하기 위해 지식베이스에 반영된다(S855).
이상 설명한 자가 치유 관리 방법은 자가 치유가 적용될 시스템의 특성이나 정보에 따라 자가 치유 시스템이 적절하고 용이하게 적용될 수 있으며, 자가 치유 수행 결과가 자동으로 보고될 수 있도록 한다.
이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위 내에서 다양한 수정, 변경 및 치환이 가능할 것이다. 따라서, 본 발명에 개시된 실시예 및 첨부된 도면들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예 및 첨부된 도면에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구 범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리 범위에 포함되는 것으로 해석되어야 할 것이다.
본 실시예는 CPS(Cyber Physical Systems)에 적용될 수 있다. 특히 본 실시예는 자율 제어 소프트웨어를 위한 CPS에 적용될 수 있다.
100 : 자가 치유 시스템 110 : 시스템 오류 판별부
120 : 대응 방안 선택부 130 : 소프트웨어 서비스 제공부
131 : 자가 치유부 132 : 내부 치유부
133 : 외부 치유부 134 : 안전 소프트웨어 실행부
135 : 서비스 실행부 136 : 서비스 운영 제어부
140 : 치유 성능 평가부 141 : 정책 데이터베이스
142 : 성능 평가 모델 분석부 143 : 분석 정보 생성부
144 : 정책 결정부 145 : 치유 성능 평가 엔진
146 : 정보 수집부 147 : 정책 적재부
148 : 성능 평가부 150 : 주제어부
160 : 모니터링부 170 : 정의부
180 : 치유 결과 학습부
120 : 대응 방안 선택부 130 : 소프트웨어 서비스 제공부
131 : 자가 치유부 132 : 내부 치유부
133 : 외부 치유부 134 : 안전 소프트웨어 실행부
135 : 서비스 실행부 136 : 서비스 운영 제어부
140 : 치유 성능 평가부 141 : 정책 데이터베이스
142 : 성능 평가 모델 분석부 143 : 분석 정보 생성부
144 : 정책 결정부 145 : 치유 성능 평가 엔진
146 : 정보 수집부 147 : 정책 적재부
148 : 성능 평가부 150 : 주제어부
160 : 모니터링부 170 : 정의부
180 : 치유 결과 학습부
Claims (20)
- 복수의 응용프로그램이 동작하는 크리티칼 시스템에 적용되는 자가 치유 시스템에 있어서,
시스템의 환경이나 시스템을 구성하는 컴포넌트들에 대한 모니터링 결과를 분석하여 시스템 오류 발생 여부를 판별하는 시스템 오류 판별부;
시스템 오류가 발생되면 시스템 오류에 대한 자가 치유 가능 여부에 따라 대응 방안을 선택하는 대응 방안 선택부;
선택된 대응 방안을 반영하여 시스템에서 소프트웨어 서비스를 계속적으로 제공하는 소프트웨어 서비스 제공부; 및
선택된 대응 방안이 시스템 오류 자가 치유이면 치유 결과를 기초로 치유 성능을 평가하는 치유 성능 평가부를 포함하고,
상기 대응 방안 선택부는 대응 방안으로 오류 발생된 소프트웨어를 자가 치유시킬 것인지 또는 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시킬 것인지를 선택하는 것을 특징으로 하는 자가 치유 시스템. - 제 1 항에 있어서,
상기 소프트웨어 서비스 제공부는,
선택된 대응 방안이 시스템 오류 자가 치유이면, 오류 발생된 소프트웨어를 자가 치유시키는 자가 치유부; 및
선택된 대응 방안이 시스템 오류 자가 치유가 아니면, 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시키는 안전 소프트웨어 실행부
를 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 2 항에 있어서,
상기 자가 치유부는,
오류 발생된 소프트웨어 내부의 치유 코드를 제어하여 소프트웨어 내부적으로 치유를 수행하는 내부 치유부; 또는
오류 발생된 소프트웨어 외부에서 해당 소프트웨어의 내용을 추가/수정/삭제하여 치유를 수행하는 외부 치유부
를 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 2 항에 있어서,
상기 소프트웨어 서비스 제공부는,
컴포넌트마다 설정된 액츄에이터를 관리하며, 상기 액츄에이터를 이용하여 소프트웨어 실행을 요청하는 컴포넌트와 실행 요청된 소프트웨어를 연결시키는 서비스 실행부; 및
선택된 대응 방안에 따라 상기 자가 치유부 또는 상기 안전 소프트웨어 실행부를 제어하며, 시스템의 환경을 고려하여 동일한 서비스와 연관된 소프트웨어들을 동시 실행시키는 서비스 운영 제어부
를 더욱 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 1 항에 있어서,
적어도 하나의 크리티칼 시스템(critical system)의 환경이나 적어도 하나의 크리티칼 시스템을 구성하는 컴포넌트들에 대해 모니터링을 수행하는 모니터링부
를 더욱 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 5 항에 있어서,
컴포넌트를 구성하는 클래스에 대한 정보, 컴포넌트의 상태 정보, 및 컴포넌트들 간 관계 정보 중 적어도 하나의 정보를 정의하는 정의부
를 더욱 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 6 항에 있어서,
상기 모니터링부는 정의된 정보를 기초로 모니터링을 수행하며,
상기 치유 성능 평가부는 정의된 정보에 의한 신뢰성(reliability)과 시스템 성능(performability) 중 적어도 하나를 포함하는 시스템 특성을 상기 치유 성능으로 평가하는 것을 특징으로 하는 자가 치유 시스템. - 제 1 항에 있어서,
상기 치유 성능 평가부는,
모니터링 방법의 기초가 되는 모니터링 정책, 치유 성능 평가의 기초가 되는 성능 평가 정책, 및 소프트웨어의 자가 치유와 관련된 자가 치유 정책을 저장하는 정책 데이터베이스;
모니터링 대상이 되는 모델들로부터 성능 평가를 위한 모델을 분리하여 분석하며, 분석 결과를 기초로 성능 평가 정책을 결정하는 성능 평가 모델 분석부; 및
결정된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 평가하는 치유 성능 평가 엔진
을 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 8 항에 있어서,
상기 치유 성능 평가 엔진은,
자가 치유 뒤 시스템의 환경과 관련한 정보를 수집하는 정보 수집부;
수집된 정보를 기초로 상기 성능 평가 모델 분석부에 의해 성능 평가 정책이 결정되면, 결정된 성능 평가 정책을 적재시키는 정책 적재부; 및
적재된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 정량적으로 평가하는 성능 평가부
를 포함하거나,
상기 성능 평가 모델 분석부는,
상기 정보 수집부에 의해 수집된 정보와 상기 정책 데이터베이스에 저장된 정책을 기초로 자가 치유 성능 평가를 위한 성능 평가 모델을 분석하며, 성능 평가 모델의 자가 치유 전 상태와 성능 평가 모델의 자가 치유 뒤 상태를 비교하여 자가 치유 성능에 대한 분석 정보를 생성하는 분석 정보 생성부; 및
생성된 분석 정보를 기초로 성능 평가 정책을 결정하는 정책 결정부
를 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 1 항에 있어서,
평가된 치유 성능을 기초로 자가 치유된 소프트웨어에 대한 자가 치유 결과를 학습하는 것으로서, 자가 치유 이전보다 자가 치유 뒤 시스템 성능이 떨어지면 기계 학습 알고리즘을 기초로 상기 학습을 수행하는 치유 결과 학습부
를 더욱 포함하는 것을 특징으로 하는 자가 치유 시스템. - 제 10 항에 있어서,
상기 치유 결과 학습부는 수행된 학습에 따라 미리 저장된 모니터링 정책도 변경하는 것을 특징으로 하는 자가 치유 시스템. - 복수의 응용프로그램이 동작하는 크리티칼 시스템에 적용되는 자가 치유 시스템의 자가 치유 방법에 있어서,
시스템 오류 판별부가 시스템의 환경이나 시스템을 구성하는 컴포넌트들에 대한 모니터링 결과를 분석하여 시스템 오류 발생 여부를 판별하는 시스템 오류 판별 단계;
대응 방안 선택부가 시스템 오류가 발생되면 시스템 오류에 대한 자가 치유 가능 여부에 따라 대응 방안을 선택하는 대응 방안 선택 단계;
소프트웨어 서비스 제공부가 선택된 대응 방안을 반영하여 시스템에서 소프트웨어 서비스를 계속적으로 제공하는 소프트웨어 서비스 제공 단계; 및
치유 성능 평가부가 선택된 대응 방안이 시스템 오류 자가 치유이면 치유 결과를 기초로 치유 성능을 평가하는 치유 성능 평가 단계를 포함하고,
상기 대응 방안 선택 단계는 대응 방안으로 오류 발생된 소프트웨어를 자가 치유시킬 것인지 또는 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시킬 것인지를 선택하는 것을 특징으로 하는 자가 치유 방법. - 제 12 항에 있어서,
상기 소프트웨어 서비스 제공 단계는,
선택된 대응 방안이 시스템 오류 자가 치유이면, 오류 발생된 소프트웨어를 자가 치유시키는 자가 치유 단계; 및
선택된 대응 방안이 시스템 오류 자가 치유가 아니면, 오류 발생된 소프트웨어와 관련된 안전 소프트웨어를 실행시키는 안전 소프트웨어 실행 단계
중 어느 한 단계를 포함하는 것을 특징으로 하는 자가 치유 방법. - 제 13 항에 있어서,
상기 자가 치유 단계는,
오류 발생된 소프트웨어 내부의 치유 코드를 제어하여 소프트웨어 내부적으로 치유를 수행하는 내부 치유 단계; 또는
오류 발생된 소프트웨어 외부에서 해당 소프트웨어의 내용을 추가/수정/삭제하여 치유를 수행하는 외부 치유 단계
를 포함하는 것을 특징으로 하는 자가 치유 방법. - 제 13 항에 있어서,
상기 소프트웨어 서비스 제공 단계는,
컴포넌트마다 설정된 액츄에이터를 관리하며, 상기 액츄에이터를 이용하여 소프트웨어 실행을 요청하는 컴포넌트와 실행 요청된 소프트웨어를 연결시키는 서비스 실행 단계; 및
선택된 대응 방안에 따라 상기 자가 치유 단계 또는 상기 안전 소프트웨어 실행 단계가 수행되도록 제어하며, 시스템의 환경을 고려하여 동일한 서비스와 연관된 소프트웨어들을 동시 실행시키는 서비스 운영 제어 단계
를 더욱 포함하는 것을 특징으로 하는 자가 치유 방법. - 제 12 항에 있어서,
적어도 하나의 크리티칼 시스템(critical system)의 환경이나 적어도 하나의 크리티칼 시스템을 구성하는 컴포넌트들에 대해 모니터링을 수행하는 모니터링 단계
를 더욱 포함하는 것을 특징으로 하는 자가 치유 방법. - 제 16 항에 있어서,
컴포넌트를 구성하는 클래스에 대한 정보, 컴포넌트의 상태 정보, 및 컴포넌트들 간 관계 정보 중 적어도 하나의 정보를 정의하는 정의 단계
를 더욱 포함하는 것을 특징으로 하는 자가 치유 방법. - 제 12 항에 있어서,
상기 치유 성능 평가 단계는,
모니터링 방법의 기초가 되는 모니터링 정책, 치유 성능 평가의 기초가 되는 성능 평가 정책, 및 소프트웨어의 자가 치유와 관련된 자가 치유 정책을 미리 저장하는 정책 데이터베이스 구축 단계;
모니터링 대상이 되는 모델들로부터 성능 평가를 위한 모델을 분리하여 분석하며, 분석 결과를 기초로 성능 평가 정책을 결정하는 성능 평가 모델 분석 단계; 및
결정된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 평가하는 치유 성능 평가 엔진 구동 단계
를 포함하는 것을 특징으로 하는 자가 치유 방법. - 제 18 항에 있어서,
상기 치유 성능 평가 엔진 구동 단계는,
자가 치유 뒤 시스템의 환경과 관련한 정보를 수집하는 정보 수집 단계;
수집된 정보를 기초로 성능 평가 정책이 결정되면, 결정된 성능 평가 정책을 적재시키는 정책 적재 단계; 및
적재된 성능 평가 정책을 기초로 자가 치유에 대한 성능을 정량적으로 평가하는 성능 평가 단계
를 포함하거나,
상기 성능 평가 모델 분석 단계는,
상기 정보 수집 단계에서 수집된 정보와 미리 저장된 정책을 기초로 자가 치유 성능 평가를 위한 성능 평가 모델을 분석하며, 성능 평가 모델의 자가 치유 전 상태와 성능 평가 모델의 자가 치유 뒤 상태를 비교하여 자가 치유 성능에 대한 분석 정보를 생성하는 분석 정보 생성 단계; 및
생성된 분석 정보를 기초로 성능 평가 정책을 결정하는 정책 결정 단계
를 포함하는 것을 특징으로 하는 자가 치유 방법. - 제 12 항에 있어서,
평가된 치유 성능을 기초로 자가 치유된 소프트웨어에 대한 자가 치유 결과를 학습하는 것으로서, 자가 치유 이전보다 자가 치유 뒤 시스템 성능이 떨어지면 기계 학습 알고리즘을 기초로 상기 학습을 수행하는 치유 결과 학습 단계
를 더욱 포함하는 것을 특징으로 하는 자가 치유 방법.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020100113888A KR101440299B1 (ko) | 2010-11-16 | 2010-11-16 | 자가 치유 시스템 및 그 방법 |
| US13/214,640 US9372742B2 (en) | 2010-11-16 | 2011-08-22 | System and method for self-healing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020100113888A KR101440299B1 (ko) | 2010-11-16 | 2010-11-16 | 자가 치유 시스템 및 그 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20120052635A KR20120052635A (ko) | 2012-05-24 |
| KR101440299B1 true KR101440299B1 (ko) | 2014-09-17 |
Family
ID=46048931
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020100113888A KR101440299B1 (ko) | 2010-11-16 | 2010-11-16 | 자가 치유 시스템 및 그 방법 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US9372742B2 (ko) |
| KR (1) | KR101440299B1 (ko) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102387137B1 (ko) * | 2020-12-23 | 2022-04-15 | 재단법인대구경북과학기술원 | 전자식 변속 제어기의 고장 검출 시스템 |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8769346B2 (en) * | 2007-11-21 | 2014-07-01 | Ca, Inc. | Method and apparatus for adaptive declarative monitoring |
| IN2015DE01177A (ko) * | 2015-04-28 | 2015-06-26 | Hcl Technologies Ltd | |
| WO2017178068A1 (en) * | 2016-04-15 | 2017-10-19 | Nokia Solutions And Networks Oy | Mechanism for modyfying security setting of a network service including virtual network parts |
| US20180176089A1 (en) * | 2016-12-16 | 2018-06-21 | Sap Se | Integration scenario domain-specific and leveled resource elasticity and management |
| US11645181B2 (en) | 2021-07-21 | 2023-05-09 | Dell Products L.P. | Automated issue direction and remediation across multiple user systems using healing-as-a-service techniques |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20080086296A (ko) * | 2007-03-22 | 2008-09-25 | 성균관대학교산학협력단 | 멀티 에이전트 기반의 자가 치유 시스템 및 그 방법 |
| US20090217235A1 (en) | 2008-02-27 | 2009-08-27 | Sap Ag | Apparatus and Method of Generating Self-Debugging Computer Software |
| KR20110067418A (ko) * | 2009-12-14 | 2011-06-22 | 한국전자통신연구원 | 자가치유 시스템의 모니터링 및 치유성능 평가를 위한 시스템 및 방법 |
Family Cites Families (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR200227881Y1 (ko) * | 2000-09-29 | 2001-06-15 | 주식회사이오니아테크놀로지 | 치과치료용 영상저장장치 |
| US20020169738A1 (en) * | 2001-05-10 | 2002-11-14 | Giel Peter Van | Method and system for auditing an enterprise configuration |
| US7275179B1 (en) * | 2003-04-24 | 2007-09-25 | Network Appliance, Inc. | System and method for reducing unrecoverable media errors in a disk subsystem |
| US7373553B2 (en) * | 2003-05-21 | 2008-05-13 | Hewlett-Packard Development Company, L.P. | Computer support network with customer portal to monitor incident-handling status by vendor's computer service system |
| US20050198279A1 (en) * | 2003-05-21 | 2005-09-08 | Flocken Philip A. | Using trend data to address computer faults |
| US7260743B2 (en) * | 2004-01-13 | 2007-08-21 | International Business Machines Corporation | System and method for achieving autonomic computing self-healing, utilizing meta level reflection and reasoning |
| US7490268B2 (en) * | 2004-06-01 | 2009-02-10 | The Trustees Of Columbia University In The City Of New York | Methods and systems for repairing applications |
| US8271838B2 (en) * | 2004-11-16 | 2012-09-18 | Siemens Corporation | System and method for detecting security intrusions and soft faults using performance signatures |
| US7627538B2 (en) * | 2004-12-07 | 2009-12-01 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Swarm autonomic agents with self-destruct capability |
| US7688712B2 (en) * | 2005-10-04 | 2010-03-30 | Invensys Systems, Inc. | Selecting one of multiple redundant network access points on a node within an industrial process control network |
| WO2007050667A2 (en) * | 2005-10-25 | 2007-05-03 | The Trustees Of Columbia University In The City Of New York | Methods, media and systems for detecting anomalous program executions |
| US20110010518A1 (en) * | 2005-12-19 | 2011-01-13 | Srinivas Kavuri | Systems and Methods for Migrating Components in a Hierarchical Storage Network |
| US7962798B2 (en) * | 2006-04-17 | 2011-06-14 | The Trustees Of Columbia University In The City Of New York | Methods, systems and media for software self-healing |
| WO2007149725A2 (en) * | 2006-06-09 | 2007-12-27 | The Arizona Board Of Regents, On Behalf Of The University Of Arizona | Method and system for autonomous control and protection of computer systems |
| US7430692B2 (en) * | 2006-06-16 | 2008-09-30 | Siemens Medical Solutions Usa, Inc. | Processor operational status management system |
| US7757120B2 (en) * | 2006-06-23 | 2010-07-13 | International Business Machines Corporation | Ignoring redundant symptoms in modular self-healing systems |
| US8135994B2 (en) * | 2006-10-30 | 2012-03-13 | The Trustees Of Columbia University In The City Of New York | Methods, media, and systems for detecting an anomalous sequence of function calls |
| US7661032B2 (en) * | 2007-01-06 | 2010-02-09 | International Business Machines Corporation | Adjusting sliding window parameters in intelligent event archiving and failure analysis |
| WO2008092162A2 (en) * | 2007-01-26 | 2008-07-31 | The Trustees Of Columbia University In The City Of New York | Systems, methods, and media for recovering an application from a fault or attack |
| US8072999B1 (en) * | 2007-05-08 | 2011-12-06 | Motion Engineering Inc. | Method and system for removing and returning nodes in a synchronous network |
| US8352393B2 (en) * | 2007-08-03 | 2013-01-08 | Alcatel Lucent | Method and system for evaluating tests used in operating system fingerprinting |
| US8041996B2 (en) * | 2008-01-11 | 2011-10-18 | Alcatel Lucent | Method and apparatus for time-based event correlation |
| US8255902B1 (en) * | 2008-03-17 | 2012-08-28 | Symantec Corporation | Systems and methods for determining and quantifying the impact of an application on the health of a system |
| US8271949B2 (en) * | 2008-07-31 | 2012-09-18 | International Business Machines Corporation | Self-healing factory processes in a software factory |
| EP2357562A4 (en) * | 2008-11-27 | 2014-03-05 | Ibm | SYSTEM FOR ASSESSING ACTIONS IN RESPECT OF EVENTS DETECTED, METHOD FOR ASSISTING THE EXECUTION OF ACTIONS IN REACTION TO DETECTED EVENTS, AID DEVICE AND COMPUTER PROGRAM |
| US20100149984A1 (en) * | 2008-12-13 | 2010-06-17 | Salil Kapoor | Self Dimensioning and optimization of telecom Network - SDAOTN |
| US7941700B2 (en) * | 2009-03-02 | 2011-05-10 | Microsoft Corporation | Operating system-based application recovery |
| US8775886B2 (en) * | 2009-03-31 | 2014-07-08 | Toyota Jidosha Kabushiki Kaisha | Architecture for a self-healing computer system |
| US8924266B2 (en) * | 2009-04-30 | 2014-12-30 | Bank Of America Corporation | Self-service device inventory information control |
| US10242329B2 (en) * | 2009-07-02 | 2019-03-26 | Hewlett Packard Enterprise Development Lp | Method and apparatus for supporting a computer-based product |
| WO2011002463A1 (en) * | 2009-07-02 | 2011-01-06 | Hewlett-Packard Development Company, L.P. | Automating diagnoses of computer related incidents |
| US8863094B2 (en) * | 2010-05-18 | 2014-10-14 | International Business Machines Corporation | Framework for a software error inject tool |
| US8645772B2 (en) * | 2010-08-25 | 2014-02-04 | Itron, Inc. | System and method for managing uncertain events for communication devices |
-
2010
- 2010-11-16 KR KR1020100113888A patent/KR101440299B1/ko active IP Right Grant
-
2011
- 2011-08-22 US US13/214,640 patent/US9372742B2/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20080086296A (ko) * | 2007-03-22 | 2008-09-25 | 성균관대학교산학협력단 | 멀티 에이전트 기반의 자가 치유 시스템 및 그 방법 |
| US20090217235A1 (en) | 2008-02-27 | 2009-08-27 | Sap Ag | Apparatus and Method of Generating Self-Debugging Computer Software |
| KR20110067418A (ko) * | 2009-12-14 | 2011-06-22 | 한국전자통신연구원 | 자가치유 시스템의 모니터링 및 치유성능 평가를 위한 시스템 및 방법 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102387137B1 (ko) * | 2020-12-23 | 2022-04-15 | 재단법인대구경북과학기술원 | 전자식 변속 제어기의 고장 검출 시스템 |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20120052635A (ko) | 2012-05-24 |
| US9372742B2 (en) | 2016-06-21 |
| US20120124410A1 (en) | 2012-05-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10901727B2 (en) | Monitoring code sensitivity to cause software build breaks during software project development | |
| KR101440299B1 (ko) | 자가 치유 시스템 및 그 방법 | |
| US7349826B2 (en) | Causal ladder mechanism for proactive problem determination, avoidance and recovery | |
| Klein et al. | Attribute-based architecture styles | |
| US8621278B2 (en) | System and method for automated solution of functionality problems in computer systems | |
| US7890315B2 (en) | Performance engineering and the application life cycle | |
| Lou et al. | Software analytics for incident management of online services: An experience report | |
| US20060112061A1 (en) | Rule based engines for diagnosing grid-based computing systems | |
| CN105683919A (zh) | 用于安全关键软件应用的多核处理器故障检测 | |
| JP2008009842A (ja) | コンピュータシステムの制御方法及びコンピュータシステム | |
| US20080234999A1 (en) | Implementing performance-dependent transfer or execution decisions from service emulation indications | |
| US20130297972A1 (en) | Dependability maintenance system, change accommodation cycle execution device, failure response cycle execution device, method for controlling dependability maintenance system, control program, and computer-readable storage medium storing the control program | |
| Schmerl et al. | Challenges in composing and decomposing assurances for self-adaptive systems | |
| US20080235001A1 (en) | Implementing emulation decisions in response to software evaluations or the like | |
| US8417996B2 (en) | Facade for business risk minimization in change administration via risk estimation and mistake identification by ticket analysis | |
| US20160246691A1 (en) | Acquiring diagnostic data selectively | |
| US9632857B2 (en) | Intelligent dump suppression | |
| KR101008959B1 (ko) | 로봇 소프트웨어 컴포넌트의 계층별 테스트방법 | |
| US9558019B2 (en) | Coordinating instances of a thread or other service in emulation | |
| US20080235000A1 (en) | Implementing security control practice omission decisions from service emulation indications | |
| KR20110067418A (ko) | 자가치유 시스템의 모니터링 및 치유성능 평가를 위한 시스템 및 방법 | |
| Rajput et al. | Exploration in adaptiveness to achieve automated fault recovery in self-healing software systems: a review | |
| CN115756394A (zh) | 借助失效数据的嵌入式软件需求安全性验证方法 | |
| WO2020109252A1 (en) | Test system and method for data analytics | |
| EP3671588A1 (en) | Dependability priority number |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| FPAY | Annual fee payment |
Payment date: 20170828 Year of fee payment: 4 |
|
| FPAY | Annual fee payment |
Payment date: 20190826 Year of fee payment: 6 |