KR20230160003A - 소프트웨어 수행 순서 오류 검출 모니터링 방법 - Google Patents

소프트웨어 수행 순서 오류 검출 모니터링 방법 Download PDF

Info

Publication number
KR20230160003A
KR20230160003A KR1020220059504A KR20220059504A KR20230160003A KR 20230160003 A KR20230160003 A KR 20230160003A KR 1020220059504 A KR1020220059504 A KR 1020220059504A KR 20220059504 A KR20220059504 A KR 20220059504A KR 20230160003 A KR20230160003 A KR 20230160003A
Authority
KR
South Korea
Prior art keywords
software
task
lastvisit
state
fault
Prior art date
Application number
KR1020220059504A
Other languages
English (en)
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 KR1020220059504A priority Critical patent/KR20230160003A/ko
Publication of KR20230160003A publication Critical patent/KR20230160003A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Retry When Errors Occur (AREA)

Abstract

본 발명은 소프트웨어가 초기화되고 런타임에 진입하는 단계; 상기 런타임 진입후 태스크 내의 첫번째 CP에 진입하는 단계; 상기 태스크 내의 첫번째 CP에 진입하면, 상기 소프트웨어의 상태가 에러 상태가 아닌 지가 판단되는 단계; 상기 소프트웨어의 상태가 에러 상태가 아니라면, 상기 태스크 내의 첫번째 CP이고 Lastvisit가 0인 지가 판단되는 단계; 상기 태스크 내의 첫번째 CP가 아니고 Lastvisit가 0이 아니라면, 상기 태스크 내의 첫번째 CP인데 Lastvisit가 0이 아닌 지가 판단되는 단계; 상기 태스크 내의 첫번째 CP도 아니고 Lastvisit가 0이라면, 상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일한 지가 판단되는 단계; 상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하지 않다면, 상기 소프트웨어가 끝인 지가 판단되는 단계; 상기 소프트웨어가 끝이라면, Fault 플래그가 세트되는 단계: 및 상기 Fault 플래그가 세트되면 상기 태스크 내의 최종 CP인지 가 판단되는 단계를 포함하는 소프트웨어 수행 순서 오류 검출 모니터링 방법에 관한 것이다.

Description

소프트웨어 수행 순서 오류 검출 모니터링 방법{METHOD FOR MONITORING OF SOFTWARE EXECUTION SEQUENCE ERROR DETECTION}
본 발명은 소프트웨어 수행 순서 오류 검출 모니터링 방법에 관한 것으로, 보다 상세하게는 표준 소프트웨어(software, SW) 플랫폼을 사용하지 않는 소프트웨어에서 다수의 태스크(Task)를 설계할 시에, 태스크가 순서대로 수행되지 않는 경우엔 잘못된 출력값이 송출되는 오류가 있으므로, 각 단위 태스크에서 현재와 이전 소프트웨어의 수행 순서를 체크함으로써 설계자가 의도한 순서대로 소프트웨어가 수행되도록 다수의 태스크의 수행 순서를 모니터링하기 위한 소프트웨어 수행 순서 오류 검출 모니터링 방법에 관한 것이다.
일반적으로, 실시간 임베디드 시스템은 종종 열악하고 급변하는 환경 속에서 중단없이 오랜 시간 지속적으로 동작하도록 요구되며 높은 안정성과 시간 제약 조건을 만족하여야 한다. 특히 안전중요(safety critical) 시스템의 경우 시스템 오작동 시 그 피해가 막대하므로 신뢰성이 매우 강조된다.
SEU(Single Event Upsets)나 전자파 간섭(EMI) 등의 환경적 요인으로 발생할 수 있는 일시적 결함(transient faults)은 임베디드 시스템 하드웨어에서 가장 발생 빈도가 높은 유형의 결함이며, 하드웨어가 물리적으로 손상되는 것이 아니므로 원천적으로 회피하거나 수리할 수 없다. 일시적 결함은 일시적 오류를 유발하며 반도체 소자의 집적도의 증가에 따른 정보의 표현에 사용되는 전하의 양의 감소, 사용 전압 감소, 동작 속도 증대 등에 따라 일시적 결함에 의한 일시적 오류의 발생 빈도도 지속적으로 증가할 것으로 예상된다.
일시적 결함의 영향을 극복하기 위한 결함허용 기법으로 체크포인팅 기법이 종종 적용되는데, 체크포인팅 기법은 임베디드 시스템에서 실행되는 태스크의 상태를 안정성이 높은 저장 장치에 주기적으로 저장하는 것을 의미한다. 태스크의 상태는 주요 변수의 값, 주요 레지스터의 값, 스택 영역에 저장된 정보 등으로 정의될 수 있다. 저장된 태스크의 상태를 체크포인트(Check Point, 이하, "CP"라 총칭함)라고 하며, 일시적 오류가 감지되었을 때, 최근에 생성된 CP를 이용하여 태스크를 오류 발생 이전, CP를 저장하기 직전의 상태로 되돌리는 것을 롤백 복구(rollback recovery)라 한다.
체크포인팅에 관한 이전 연구는 데이터베이스 시스템이나 범용 컴퓨터 시스템에서의 가용성 최대화, 시스템 성능 예측, 체크포인팅 부담 최소화 등이 주제였으며, 실시간 시스템에 대해서는 태스크 평균 실행 시간 최소화, 복구 동작의 수행 횟수가 제한된 상황에서 태스크의 실행 성공 확률 최대화, 체크포인팅 수행에 따른 태스크의 응답 시간 분석, 결함 허용 시스템의 에너지 소모 최소화 등에 관한 연구가 수행되었다.
그러나, 이러한 연구는 표준 소프트웨어 플랫폼(예를 들어, AUTOSAR 표준 소프트웨어 플랫폼)을 사용하는 소프트웨어의 경우에 해당하며, 표준 소프트웨어 플랫폼을 사용하지 않는 소프트웨어의 경우에는 적용이 어렵다는 문제가 있다.
따라서 본 발명의 목적은 상기와 같은 문제를 해결하기 위해 안출된 것으로, 각 단위 태스크에서 현재와 이전 소프트웨어의 수행 순서를 체크함으로서 설계자가 의도한 순서대로 소프트웨어가 수행되도록 다수의 태스크의 수행 순서를 모니터링하기 위한 소프트웨어 수행 순서 오류 검출 모니터링 방법을 제공하고자 하는 것이다.
본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법은 소프트웨어가 초기화되고 런타임에 진입하는 단계; 상기 런타임 진입후 태스크 내의 첫번째 CP에 진입하는 단계; 상기 태스크 내의 첫번째 CP에 진입하면, 상기 소프트웨어의 상태가 에러 상태가 아닌 지가 판단되는 단계; 상기 소프트웨어의 상태가 에러 상태가 아니라면, 상기 태스크 내의 첫번째 CP이고 Lastvisit가 0인 지가 판단되는 단계; 상기 태스크 내의 첫번째 CP가 아니고 Lastvisit가 0이 아니라면, 상기 태스크 내의 첫번째 CP인데 Lastvisit가 0이 아닌 지가 판단되는 단계; 상기 태스크 내의 첫번째 CP도 아니고 Lastvisit가 0이라면, 상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일한 지가 판단되는 단계; 상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하지 않다면, 상기 소프트웨어가 끝인 지가 판단되는 단계; 상기 소프트웨어가 끝이라면, Fault 플래그가 세트되는 단계: 및 상기 Fault 플래그가 세트되면 상기 태스크 내의 최종 CP인지 가 판단되는 단계를 포함하는 것을 특징으로 한다.
상술한 바와 같이, 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법은 표준 소프트웨어 플랫폼을 사용하지 않는 소프트웨어에서도 다수의 태스크의 수행 순서 오류를 검출할 수 있다는 이점이 있다.
또한, 표준 소프트웨어 플랫폼을 사용하지 않기에 CP 정의에 대한 제약사항이 적다는 이점이 있다.
또한, 한개의 CP를 여러 소프트웨어에 사용할 수 있으므로 리소스 소모량이 표준 소프트웨어 플랫폼보다 적다는 이점이 있다.
도 1은 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링을 구현하기 위한 컴퓨팅 장치를 도시한 도시도이다.
도 2는 도 1의 ADS에서 수행되는 태스크를 도시한 도시도이다.
도 3은 체크포인팅 기법이 적용되는 실시간 태스크의 예를 설명하기 위한 도시도.
도 4는 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법을 설명하기 위한 흐름도이다.
도 5는 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법에서 초기화 이후 반복되면서 소프트웨어가 수행되는 예를 설명하기 위한 도시도이다.
이하, 도면을 참조한 실시 예들의 상세한 설명을 통하여 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법을 보다 상세히 기술하기로 한다. 본 발명을 설명함에 있어서 관련된 공지기술 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략될 것이다. 그리고, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 클라이언트나 운용자, 사용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
도면 전체에 걸쳐 같은 참조번호는 같은 구성 요소를 가리킨다.
도 1은 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링을 구현하기 위한 컴퓨팅 장치를 도시한 도시도이며, 도 2는 도 1의 ADS에서 수행되는 태스크를 도시한 도시도이며, 도 3은 체크포인팅 기법이 적용되는 실시간 태스크의 예를 설명하기 위한 도시도이며, 도 4는 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법을 설명하기 위한 흐름도이며, 도 5는 도 5는 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법에서 초기화 이후 반복되면서 소프트웨어가 수행되는 예를 설명하기 위한 도시도이다.
이제, 도 1 및 도 2를 참조하여, 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링을 구현하기 위한 컴퓨팅 장치를 살펴보고자 한다.
설명에 앞서, 일시적 결함에 따른 오류는 평균값 를 갖는 푸아송(poisson) 분포에 따라 발생한다고 가정한다. 이는 일시적 결함 및 오류를 다루는 분야에서 대부분 사용되는 가정이다, 그리고 의 실제값은 매우 작으므로 실시간 태스크(이하 후술함)의 1회 수행 당 발생하는 일시적 오류의 평균 발생 횟수는 1보다 매우 작다고 가정한다.
도 1 및 도 2에 도시된 바와 같이, 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링을 구현하기 위한 컴퓨팅 장치(100)는 다수의 센서(domain)로 구성된 센서부(110), DCU(Domain Control Unit, 130), ADS(Anomaly Detection System, 150), 메모리(170)을 포함한다.
여기서, 센서부(130)는 다수의 센서(111, 112, ... , 11n)를 포함하며, 차량(도시되지 않음)의 각 부분에서 발생한 데이터를 감지하며, 감지된 데이터를 DCU(130)로 전달한다.
또한, DCU(130)는 센서부(130)로부터 전달받은 데이터를 통합하여 신호처리 및 제어함으로써, 차량의 실시간 운영체제(Real Time Operation System, RTOS)를 파악하는 역할을 한다. 또한, DCU(130)는 센서부(130)로부터 전달받은 데이터를 통합하여 신호처리 및 제어하여 신호처리 및 제어된 데이터를 ADS(150)에 전달한다.
또한, ADS(150)는 ADS(150)로부터 전달받은 데이터에 기초하여 다수의 태스크(151, 152, 153, ... , 15n, 도 2 참조)의 수행 순서 오류를 검출한다.
또한, 메모리(170)는 다수의 태스크(151, 152, 153, ... , 15n)의 주요 변수의 값, 주요 레지스터의 값, 스택 영역에 저장된 정보 등을 저장한다.
이제, 도 3을 참조하여, 체크포인팅 기법이 적용되는 실시간 태스크의 예를 살펴보고자 한다.
여기서, ADS(150)에서 다스의 태스크(151, 152, 153, ... , 15n) 수행 중 발생 가능한 수행 패턴은 주기적 실시간 태스크의 매 수행마다 일정 횟수의 체크포인팅 작업이 동일 간격으로 수행되는 체크포인팅 기법이 적용되는 상황을 고려한다.
도 3에 도시된 바와 같이, 체크포인팅 기법이 적용되는 실시간 태스크의 예로서 실시간 태스크의 1회 수행에 4회의 체크포인팅 작업이 수행되는 예가 도시된다.
도 3에서 두번째 체크포인팅 작업 완료 후 오류가 발생했고 세번째 체크포인팅 작업 수행 지점에 오류가 검출되어 체크포인팅 작업 대신에 두번째 체크포인팅이 완료된 시점으로 시스템의 상태가 복구되고 세번째와 마지막 네번째 체크포인팅이 수행되어 태스크의 수행이 완료되는 상황을 보여준다.
전술한 바와 같은 일시적 결함에 따른 오류는 평균값 λ를 갖는 푸아송(poisson) 분포에 따라 발생한다고 가정하는데, 오류의 극복을 위해서는 오류의 검출이 우선되어야 한다. 일시적 오류는 체크포인팅 생성 전에 수행되는 오류 검출 기법에 의해 검출되는데, 오류 검출 기법으로는 알고리즘 기반 결함 허용 기법, 소프트웨어로 구현된 오류 검출 및 정정 코드, 수락 시험, 외부 검사, WDT(Watchdog timer), 이중화 구조 시스템읠 주기적 출력 비교 등이 예시가 될 수 있다. 이러한 오류 검출 기법은 시스템의 특성이나 요구 사항 등에 따라 다양한 방법으로 다양한 레벨로 구현될 수 있으며, 완벽한 오류 검출을 보장하는 기법은 없다.
한편, 이러한 체크포인팅 작업 중에도 발생할 수 있는 일시적 오류에 대항하기 위해서는 두 개의 CP 저장공간을 구비하고 이들을 교대로 사용해야 한다, 체크포인팅 작업이 일시적 오류에 의해 정상적으로 수행되지 못했다면 최근의 무결점 상태가 저장되어 있는 다른 CP를 이용하여 롤백 복구를 수행해야 한다.
이제, 도 4를 참조하여, 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법을 살펴보고자 한다.
설명에 앞서, 도 4에서 행해지는 모든 소프트웨어 수행 순서 오류 검출은 ADS(150)에 의해 진행되며, 설명의 편의성을 위해 다수의 태스크(151, 152, 153, ... , 15n) 중 어느 하나의 태스크에서 수행되는 소프트웨어 수행 순서 오류 검출에 대해서만 설명하고자 한다.
도 4에 도시된 바와 같이, 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법은 먼저, 소프트웨어가 시작되면 S401 단계에서 소프트웨어가 초기화되고 런타임에 진입하고 S403 단계로 진행한다.
이후, S403 단계에서 소프트웨어가 초기화되고 런타임에 진입하면, 런타임 진입후 태스크 내의 첫번째 CP에 진입하고 S405 단계로 진행한다.
그 후, S405 단계에서 태스크 내의 첫번째 CP에 진입하면, 소프트웨어 상태가 에러 상태가 아닌 지가 판단된다. 여기서 소프트웨어 상태가 에러 상태이면 CP를 이탈한 것으로 판단하여 소프트웨어 수행 순서 오류 검출 모니터링을 중단하며, 소프트웨어 상태가 에러 상태가 아니면 S407 단계로 진행한다.
이후, S407 단계에서 소프트웨어 상태가 에러 상태가 아니면. 태스크 내의 첫번째 CP이고 Lastvisit가 0(초기값)인 지가 판단된다. 여기서, 태스크 내의 첫번째 CP이고 Lastvisit가 0이면 S409 단계로 진행하며, 태스크 내의 첫번째 CP가 아니고 Lastvisit가 0이 아니면 S411 단계로 진행한다.
그 후, S409 단계에서 태스크 내의 첫번째 CP이고 Lastvisit가 0이면, 전역변수인 Lastvisit CP에 현재 CPID를 저장하고 Fault가 없다고 판단하여 소프트웨어 수행 순서 오류 검출 모니터링을 중단한다.
이후, S411 단계에서 태스크 내의 첫번째 CP가 아니고 Lastvisit가 0이 아니면, 태스크 내의 첫번째 CP인데 Lastvisit가 0이 아닌 지가 판단된다. 여기서, 태스크 내의 첫번째 CP도 아니고 Lastvisit가 0이라면 S413 단계로 진행한다.
이후, S413 단계에서 태스크 내의 첫번째 CP도 아니고 Lastvisit가 0이라면, 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일한 지가 판단된다. 여기서, 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하지 않으면 S415 단계로 진행한다.
그 후, S415 단계에서 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하지 않으면, 소프트웨어가 끝인 지가 판단된다. 여기서, 소프트웨어가 끝이 아니라면 S413 단계로 리턴되며, 소프트웨어가 끝이라면 S417 단계로 진행한다.
이후, S417 단계에서 소프트웨어가 끝이라면, Fault 플래그가 세트되고 S419 단계로 진행한다.
그 후, S419 단계에서 Fault 플래그가 세트되면, 태스크 내의 최종 CP인지 가 판단된다. 여기서, 태스크 내의 최종 CP이면 S421 단계로 진행되어 전역변수인 Lastvisit CP가 클리어(clear)되고 S425 단계로 진행하며, 태스크 내의 최종 CP가 아니면 S423 단계로 진행한다.
이후, S423 단계에서 태스크 내의 최종 CP가 아니면, 전역변수인 Lastvisit CP에 현재 CPID가 저장된다.
그 후, S425 단계에서 전역변수인 Lastvisit CP가 클리어되고, 전역변수인 Lastvisit CP에 현재 CPID가 저장되면, Fault 카운트가 증가하고, CP 상태가 상태 Fault가 되며, 현재 CP가 에러 CP에 저장되며, 소프트웨어 상태가 상태 Fault가 되어 S427 단계로 진행한다.
그 후, S427 단계에서 Fault 카운트가 증가하고, CP 상태가 상태 Fault가 되며, 현재 CP가 에러 CP에 저장되며, 소프트웨어 상태가 상태 Fault가 되면, Fault 카운트가 10 이상인 지가 판단된다. 여기서, Fault 카운트가 10 이상이 아니라면 소프트웨어 상태가 에러 상태이면 CP를 이탈한 것으로 판단하여 소프트웨어 수행 순서 오류 검출 모니터링을 중단하며, Fault 카운트가 10 이상이면 S429 단계로 진행한다.
이후, S429단계에서 Fault 카운트가 10 이상이면, 에러 플래그가 세트되고, CP 상태가 상태 에러가 되며, Fault 카운트가 클리어되며, 소프트웨어 상태가 에러 상태가 된다.
한편, S411 단계에서 태스크 내의 첫번째 CP인데 Lastvisit도 0이 아니면 단계 S417로 진행한다.
또한, S413 단계에서 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하다면 S431 단계로 진행한다.
이후, S431 단계에서 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하면, 태스크 내의 최종 CP인지 가 판단된다. 여기서, 태스크 내의 최종 CP이면 S433 단계로 진행되어 전역변수인 Lastvisit CP에 현재 CPID가 저장되며, 태스크 내의 최종 CP가 아니라면 S435 단계로 진행되어 전역변수인 Lastvisit CP가 클리어된다.
그 후, S437 단계에서 전역변수인 Lastvisit CP에 현재 CPID가 저장되고 전역변수인 Lastvisit CP가 클리어되면, CP 상태가 상태 OK가 되고, Fault가 없다고 판단하여 소프트웨어 수행 순서 오류 검출 모니터링을 중단한다.
또 한편, S405 단계에선 소프트웨어 상태가 에러 상태면 더이상 수행되지 않는다.
또한, S407 단계에선 이전 소프트웨어 수행 순서 오류 검출 모니터링에서 소프트웨어가 최종 CP까지 수행되어 클리어된다.
또한, S431 단계에선 Fault와 관계없이 최종 CP면 클리어된다.
이제, 도 5를 참조하여 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법에서 초기화 이후 반복되면서 소프트웨어가 수행되는 예를 살펴보고자 한다.
도 5에 도시된 바와 같이, 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법에서 초기화 이후 반복되면서 소프트웨어가 수행되는 예는 10ms 사이클이 반복되면서 소프트웨어가 수행된다.
예를 들어, 태스크 #1은 통신 소프트웨어를 수행하고 CP #1을 추가하며, 태스크 #2는 센서 입력 처리를 소프트웨어를 수행하고 CP #2를 추가하며, 태스크 #3는 센서 입력 모니터링 소프트웨어를 수행하며, 태스크 #4는 입력 신호 프로세싱 소프트웨어를 실행하며, 태스크 #4는 출력 소프트웨어를 수행하고 CP #3을 추가하는 방식이다.
전술한 바와 같은 본 발명에 따른 소프트웨어 수행 순서 오류 검출 모니터링 방법은 표준 소프트웨어 플랫폼을 사용하지 않는 소프트웨어에서도 다수의 태스크의 수행 순서 오류를 검출할 수 있다. 또한, 표준 소프트웨어 플랫폼을 사용하지 않기에 CP 정의에 대한 제약사항이 적다. 또한, 한개의 CP를 여러 소프트웨어에 사용할 수 있으므로 리소스 소모량이 표준 소프트웨어 플랫폼보다 적다.
이상과 같이 본 발명은 양호한 실시 예에 근거하여 설명하였지만, 이러한 실시 예는 본 발명을 제한하려는 것이 아니라 예시하려는 것이므로, 본 발명이 속하는 기술분야의 숙련자라면 본 발명의 기술사상을 벗어남이 없이 위 실시 예에 대한 다양한 변화나 변경 또는 조절이 가능할 것이다. 그러므로, 본 발명의 보호 범위는 본 발명의 기술적 사상의 요지에 속하는 변화 예나 변경 예 또는 조절 예를 모두 포함하는 것으로 해석되어야 할 것이다.
110: 센서부 130: DCU
150: ADS 170: 메모리

Claims (11)

  1. 소프트웨어가 초기화되고 런타임에 진입하는 단계;
    상기 런타임 진입후 태스크 내의 첫번째 CP에 진입하는 단계;
    상기 태스크 내의 첫번째 CP에 진입하면, 상기 소프트웨어의 상태가 에러 상태가 아닌 지가 판단되는 단계;
    상기 소프트웨어의 상태가 에러 상태가 아니라면, 상기 태스크 내의 첫번째 CP이고 Lastvisit가 0인 지가 판단되는 단계;
    상기 태스크 내의 첫번째 CP가 아니고 Lastvisit가 0이 아니라면, 상기 태스크 내의 첫번째 CP인데 Lastvisit가 0이 아닌 지가 판단되는 단계;
    상기 태스크 내의 첫번째 CP도 아니고 Lastvisit가 0이라면, 상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일한 지가 판단되는 단계;
    상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하지 않다면, 상기 소프트웨어가 끝인 지가 판단되는 단계;
    상기 소프트웨어가 끝이라면, Fault 플래그가 세트되는 단계: 및
    상기 Fault 플래그가 세트되면 상기 태스크 내의 최종 CP인지 가 판단되는 단계를 포함하는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  2. 청구항 1에 있어서,
    상기 태스크 내의 최종 CP이면 Lastvisit CP가 클리어되고, 상기 태스크 내의 최종 CP가 아니면 Lastvisit CP에 현재 CPID가 저장되는 단계;
    상기 Lastvisit CP가 클리어되고, 상기 Lastvisit CP에 현재 CPID가 저장되면, Fault 카운트가 증가되고, CP 상태가 상태 Fault가 되며, 현재 CP가 에러 CP에 저장되며, 소프트웨어 상태가 상태 Fault가 되는 단계;
    상기 Fault 카운트가 증가되고, CP 상태가 상태 Fault가 되며, 현재 CP가 에러 CP에 저장되며, 소프트웨어 상태가 상태 Fault가 되면, 상기 Fault 카운트가 10 이상인 지가 판단되는 단계; 및
    상기 Fault 카운트가 10 이상이면, 에러 플래그가 세트되고, CP 상태가 상태 에러가 되며, Fault 카운트가 클리어되며, 소프트웨어 상태가 에러 상태가 되는 단계;를 더 포함하는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  3. 청구항 1에 있어서,
    상기 소프트웨어의 상태가 에러 상태가 아닌 지가 판단되는 단계에서,
    상기 소프트웨어의 상태가 에러 상태이면 CP를 이탈한 것으로 판단하여 소프트웨어 수행 순서 오류 검출 모니터링을 중단하는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  4. 청구항 1에 있어서,
    상기 태스크 내의 첫번째 CP이고 Lastvisit가 0인 지가 판단되는 단계에서,
    상기 태스크 내의 첫번째 CP이고 Lastvisit가 0이라면, 상기 전역변수인 Lastvisit CP에 현재 CPID를 저장하고 Fault가 없다고 판단하여 소프트웨어 수행 순서 오류 검출 모니터링을 중단하는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  5. 청구항 1에 있어서,
    상기 태스크 내의 첫번째 CP인데 Lastvisit가 0이 아닌 지가 판단되는 단계에서,
    상기 태스크 내의 첫번째 CP인데 Lastvisit가 0이 아니라면, Fault 플래그가 세트되는 단계로 진행하는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  6. 청구항 1에 있어서,
    상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일한 지가 판단되는 단계에서,
    상기 태스크 내의 현재 CP와 소프트웨어 CPID 및 전역변수인 Lastvisit CP와 이전 CP가 동일하다면, 상기 태스크 내의 최종 CP인지 가 판단되는 단계를 더 포함하는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  7. 청구항 1에 있어서,
    상기 태스크 내의 최종 CP인지 가 판단되는 단계에서,
    상기 태스크 내의 최종 CP이면 전역변수인 Lastvisit CP에 현재 CPID가 저장되며, 상기 태스크 내의 최종 CP가 아니면 전역변수인 Lastvisit CP가 클리어되는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  8. 청구항 7에 있어서,
    상기 전역변수인 Lastvisit CP에 현재 CPID가 저장되고 상기 전역변수인 Lastvisit CP가 클리어되면, CP 상태가 상태 OK가 되고, Fault가 없다고 판단하여 소프트웨어 수행 순서 오류 검출 모니터링을 중단하는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  9. 청구항 1에 있어서,
    상기 태스크 내의 첫번째 CP이고 Lastvisit가 0인 지가 판단되는 단계에서,
    이전 소프트웨어 수행 순서 오류 검출 모니터링에서 소프트웨어가 최종 CP까지 수행되어 클리어되는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  10. 청구항 7에 있어서,
    상기 태스크 내의 최종 CP인지 가 판단되는 단계에서,
    Fault와 관계없이 최종 CP면 클리어되는 소프트웨어 수행 순서 오류 검출 모니터링 방법.
  11. 청구항 1에 있어서,
    상기 소프트웨어는 상기 초기화 이후 10ms 사이클이 반복되면서 수행되는 소프트웨어 수행 순서 오류 검출 모니터링 방법.


KR1020220059504A 2022-05-16 2022-05-16 소프트웨어 수행 순서 오류 검출 모니터링 방법 KR20230160003A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020220059504A KR20230160003A (ko) 2022-05-16 2022-05-16 소프트웨어 수행 순서 오류 검출 모니터링 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020220059504A KR20230160003A (ko) 2022-05-16 2022-05-16 소프트웨어 수행 순서 오류 검출 모니터링 방법

Publications (1)

Publication Number Publication Date
KR20230160003A true KR20230160003A (ko) 2023-11-23

Family

ID=88974583

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020220059504A KR20230160003A (ko) 2022-05-16 2022-05-16 소프트웨어 수행 순서 오류 검출 모니터링 방법

Country Status (1)

Country Link
KR (1) KR20230160003A (ko)

Similar Documents

Publication Publication Date Title
US7991961B1 (en) Low-overhead run-time memory leak detection and recovery
US20120221884A1 (en) Error management across hardware and software layers
KR101331935B1 (ko) 추적점 기반의 고장 진단/복구 시스템 및 그 방법
KR101944873B1 (ko) 지능형 단말기의 하드웨어가 비정상적으로 작동하는지 여부를 검사하는 방법 및 지능형 단말기
CN112015599B (zh) 错误恢复的方法和装置
US9158606B2 (en) Failure repetition avoidance in data processing
US20140032962A1 (en) System and Methods for Self-Healing From Operating System Faults in Kernel/Supervisory Mode
EP0532334A2 (en) Error recovery in an information processing system
US20030084376A1 (en) Software crash event analysis method and system
CN100538644C (zh) 执行计算机程序的方法、计算设备
CN102640119A (zh) 用于运行计算单元的方法
CN101334744A (zh) 一种检测多处理器***故障的方法、***和装置
JP5056396B2 (ja) ソフトウェア動作監視装置、プログラム
CN110673975B (zh) 一种星载计算机软件的安全内核结构及安全运行方法
KR20230160003A (ko) 소프트웨어 수행 순서 오류 검출 모니터링 방법
Mouallem et al. A fault-tolerance architecture for kepler-based distributed scientific workflows
CN100511165C (zh) 执行计算机程序的方法、操作***以及计算设备
KR102438148B1 (ko) 임베디드 컴퓨팅 모듈의 이상을 감지하는 이상 감지 장치, 시스템 및 방법
US6209019B1 (en) Data processing system, computer network, and data processing method
US20230385156A1 (en) Distributed fault-tolerance via disaggregated memory boards
KR102300712B1 (ko) 스택 결함 원인을 진단하는 방법 및 장치
CN117234787B (zh) ***级芯片运行状态监控方法及***
Kelly A Framework for Fault Tolerant Design Using Abstract Data Types
Ryu Reliability analysis for static checkpointing in embedded real-time systems
Ahmad et al. Using ML in designing self-healing OS