KR20210065301A

KR20210065301A - Autosar 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치

Info

Publication number: KR20210065301A
Application number: KR1020190153876A
Authority: KR
Inventors: 서용진
Original assignee: 주식회사 알티스트
Priority date: 2019-11-27
Filing date: 2019-11-27
Publication date: 2021-06-04
Also published as: WO2021107183A1

Abstract

AUTOSAR 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치를 개시한다. 개시되는 일 실시예에 따른 AUTOSAR 기반의 소프트웨어 설계 방법은, 하나 이상의 프로세서들, 및 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치에서 수행되는 방법으로서, AUTOSAR(AUTomotive Open System Architecture) 메뉴얼을 기반으로 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계, 설계되는 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계, 및 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링 설계 단계를 포함한다.

Description

AUTOSAR 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치{METHOD FOR DESIGNING SOFTWARE OF BASED AUTOSAR AND APPARATUS FOR EXECUTING THE METHOD}

본 발명의 실시예는 개방형 자동차 표준 소프트웨어 아키텍쳐 기술과 관련된다.

개방형 자동차 표준 소프트웨어 아키텍쳐(AUTomotive Open System Architecture : AUTOSAR) 기반의 소프트웨어는 차량 내 전자/전기 장치에 탑재되어 동작하는 소프트웨어로, 자동차 기능 안전성 국제 표준(ISO 26262)을 준수하여 개발되어야 한다. 자동차 기능 안전성 국제 표준은 차량 내 안전 관련 전자/전기 장치에 적용되는 표준으로, 전자/전기 장치에 탑재되는 소프트웨어도 그 적용 대상에 포함된다. 자동차 기능 안전성 국제 표준에서 제시하는 기능 안전성을 위한 행위 중에서 가장 중요한 것은 안전 요구사항을 도출하는 것에 있다.

안전 요구사항은 OEM(Original Equipment Manufacturing) 업체로부터 생성되어 전달되는 것이 일반적이지만, 그 적용 대상과 요구 사항이 정해지지 않은 상태로 개발되는 소프트웨어는 안전 요구사항이 존재하지 않는 상황에서 개발이 진행되기도 한다. 자동차 기능 안전성 국제 표준에서는 이와 같은 요소를 SEooC(Safety Element out of Context)로 규정하며, 가정된 안전 요구사항을 정의하여 개발할 것을 권고한다.

그러나 존재하지 않은 안전 요구사항을 새로 정의하는 것은 매우 어려운 작업이다. 개발 소프트웨어만을 대상으로 안전 요구사항을 도출하는 것이 아니라 외부로부터 전파될 수 있는 고장과 외부로 전파될 수 있는 고장을 함께 고려하여야 한다. 또한, 안전 요구사항의 변경도 고려하여야 한다. 실제 소프트웨어의 탑재 과정에서 새로운 안전 요구사항이 도출될 수 있기 때문에, 새로운 안전 요구사항을 쉽게 반영할 수 있도록 통일되고 통용된 방법을 통해 안전 요구사항을 정의 및 관리할 수 있어야 한다.

본 발명은 안전 요구사항을 반영하고 식별할 수 있는 AUTOSAR 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치를 제공하는 것을 목적으로 한다.

한편, 본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명의 일 실시예에 따른 AUTOSAR 기반의 소프트웨어 설계 방법은, 하나 이상의 프로세서들, 및 상기 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치에서 수행되는 방법으로서, AUTOSAR(AUTomotive Open System Architecture) 메뉴얼을 기반으로 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계; 상기 설계되는 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계; 및 상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링 설계 단계를 포함한다.

상기 소프트웨어 설계 단계는, 상기 AUTOSAR 매뉴얼을 기반으로 사용자의 입력에 따라 상기 소프트웨어의 기능 실현을 위해 필요한 인터페이스를 각각 정의하는 단계; 및 상기 소프트웨어의 기능 실현을 위해 필요한 컴포넌트들을 정의하는 단계를 포함하고, 상기 인터페이스를 각각 정의하는 단계는, 상기 컴포넌트 간 통신 과정에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함할 수 있다.

상기 컴포넌트들을 정의하는 단계는, 각 컴포넌트들에 대해 다른 컴포넌트와의 통신을 위한 제공 포트 및 요구 포트를 정의하는 단계를 포함하고, 상기 인터페이스를 각각 정의하는 단계는, 상기 제공 포트 및 상기 요구 포트에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함할 수 있다.

상기 결함 분석 단계는, 상기 소프트웨어로부터 발생 가능한 결함의 원인 및 그로 인한 영향 간에 원인 및 영향 관계를 도출하는 단계를 포함할 수 있다.

상기 원인 및 영향 관계를 도출하는 단계는, 상기 컴포넌트의 요구 포트의 결함을 원인으로 설정하고, 상기 컴포넌트의 제공 포트의 결함을 영향으로 설정하여 상기 소프트웨어에 포함된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계를 도출할 수 있다.

상기 결함 분석 단계는, 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도 중 하나 이상에 대해 레벨을 부여하는 단계; 및 상기 부여된 레벨에 따라 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함 발생 시 조치 방법을 정의하는 단계를 더 포함할 수 있다.

상기 레벨을 부여하는 단계는, 기 설정된 각 컴포넌트의 중요도 및 각 컴포넌트에서 인터랙션이 발생되는 횟수를 기반으로 상기 원인 및 영향 관계에 대해 레벨을 부여할 수 있다.

상기 결함 분석 단계는, 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계들 중 상기 레벨이 기 설정된 기준 레벨 미만인 것은 삭제하는 단계를 더 포함할 수 있다.

상기 안전 모니터링 설계 단계는, 상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계와 상기 조치 방법을 기반으로 상기 소프트웨어 동작시 발생하는 결함을 모니터링하기 위한 감시 컴포넌트를 생성하는 단계를 포함할 수 있다.

상기 감시 컴포넌트는, 상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계로부터 상기 소프트웨어 내의 데이터 제어 흐름을 도출할 수 있도록 마련될 수 있다.

상기 안전 모니터링 설계 단계는, 상기 감시 컴포넌트에서 결함 감지 시 결함 보고를 위한 결함 보고 인터페이스를 구성하는 단계를 더 포함할 수 있다.

본 발명의 일 실시예에 따른 컴퓨팅 장치는, 하나 이상의 프로세서들; 메모리; 및 하나 이상의 프로그램들을 포함하고, 상기 하나 이상의 프로그램들은 상기 메모리에 저장되고, 상기 하나 이상의 프로세서들에 의해 실행되도록 구성되고, AUTOSAR(AUTomotive Open System Architecture) 기반의 소프트웨어 설계를 위한 컴퓨팅 장치로서, 상기 하나 이상의 프로그램들은, AUTOSAR 메뉴얼을 기반으로 소프트웨어의 구조를 정의하기 위한 명령; 상기 소프트웨어로부터 발생 가능한 결함을 분석하기 위한 명령; 및 상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링을 설계하기 위한 명령을 포함한다.

본 발명의 실시예에 따르면, AUTOSAR의 개발 방법론에 따라 소프트웨어의 개발을 수행하더라도 가정된 안전 요구사항을 용이하게 도출할 수 있게 된다. 이를 통해 개발되는 소프트웨어의 안전성을 향상시켜 상품 가치를 보장할 수 있도록 하며, 자동차 주행 중 발생 가능한 재산 및 인명 피해를 예방할 수 있게 된다.

또한, 소프트웨어로부터 발생 가능한 결함을 개발자가 미리 인지하도록 함으로써 방어적 프로그래밍(Defensive Programming)이 가능하도록 하며 검증 케이스를 쉽게 식별할 수 있도록 도와 줄 수 있다. 그로 인해, 개발되는 소프트웨어의 신뢰성을 보장할 수 있게 된다.

한편, 본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

도 1은 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경을 예시하여 설명하기 위한 블록도이고,
도 2는 본 발명의 일 실시예에 따른 AUTOSAR(AUTomotive Open System Architecture) 기반 소프트웨어의 설계 방법을 설명하기 위한 흐름도이고,
도 3은 본 발명의 일 실시예에서 소프트웨어 설계 단계를 설명하기 위한 흐름도이고,
도 4는 본 발명의 일 실시예에서 결함 분석 단계를 설명하기 위한 흐름도이고,
도 5는 본 발명의 일 실시예에서 소프트웨어의 컴포넌트에서 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보를 도출하는 상태를 설명하기 위한 도면이고,
도 6은 본 발명의 일 실시예에서 안전 모니터링 설계 단계를 설명하기 위한 흐름도이다.

이하, 본 발명의 실시 예를 첨부된 도면들을 참조하여 더욱 상세하게 설명한다. 본 발명의 실시 예는 여러 가지 형태로 변형할 수 있으며, 본 발명의 범위가 아래의 실시 예들로 한정되는 것으로 해석되어서는 안 된다. 본 실시 예는 당업계에서 평균적인 지식을 가진 자에게 본 발명을 더욱 완전하게 설명하기 위해 제공되는 것이다. 따라서 도면에서의 요소의 형상은 보다 명확한 설명을 강조하기 위해 과장되었다.

본 발명이 해결하고자 하는 과제의 해결 방안을 명확하게 하기 위한 발명의 구성을 본 발명의 바람직한 실시 예에 근거하여 첨부 도면을 참조하여 상세히 설명하되, 도면의 구성요소들에 참조번호를 부여함에 있어서 동일 구성요소에 대해서는 비록 다른 도면상에 있더라도 동일 참조번호를 부여하였으며 당해 도면에 대한 설명 시 필요한 경우 다른 도면의 구성요소를 인용할 수 있음을 미리 밝혀둔다.

도 1은 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경(10)을 예시하여 설명하기 위한 블록도이다. 도시된 실시예에서, 각 컴포넌트들은 이하에 기술된 것 이외에 상이한 기능 및 능력을 가질 수 있고, 이하에 기술된 것 이외에도 추가적인 컴포넌트를 포함할 수 있다.

도시된 컴퓨팅 환경(10)은 컴퓨팅 장치(12)를 포함한다. 일 실시예에서, 컴퓨팅 장치(12)는 본 발명의 실시예에 따른 AUTOSAR(AUTomotive Open System Architecture) 기반 소프트웨어의 설계 방법을 위한 장치일 수 있다. 여기서, 컴퓨팅 장치(12)는 소프트웨어 개발자가 소프트웨어 설계 시 이를 보조하기 위한 도구(Tool)를 포함할 수 있다.

컴퓨팅 장치(12)는 적어도 하나의 프로세서(14), 컴퓨터 판독 가능 저장 매체(16) 및 통신 버스(18)를 포함한다. 프로세서(14)는 컴퓨팅 장치(12)로 하여금 앞서 언급된 예시적인 실시예에 따라 동작하도록 할 수 있다. 예컨대, 프로세서(14)는 컴퓨터 판독 가능 저장 매체(16)에 저장된 하나 이상의 프로그램들을 실행할 수 있다. 상기 하나 이상의 프로그램들은 하나 이상의 컴퓨터 실행 가능 명령어를 포함할 수 있으며, 상기 컴퓨터 실행 가능 명령어는 프로세서(14)에 의해 실행되는 경우 컴퓨팅 장치(12)로 하여금 예시적인 실시예에 따른 동작들을 수행하도록 구성될 수 있다.

컴퓨터 판독 가능 저장 매체(16)는 컴퓨터 실행 가능 명령어 내지 프로그램 코드, 프로그램 데이터 및/또는 다른 적합한 형태의 정보를 저장하도록 구성된다. 컴퓨터 판독 가능 저장 매체(16)에 저장된 프로그램(20)은 프로세서(14)에 의해 실행 가능한 명령어의 집합을 포함한다. 일 실시예에서, 컴퓨터 판독 가능 저장 매체(16)는 메모리(랜덤 액세스 메모리와 같은 휘발성 메모리, 비휘발성 메모리, 또는 이들의 적절한 조합), 하나 이상의 자기 디스크 저장 디바이스들, 광학 디스크 저장 디바이스들, 플래시 메모리 디바이스들, 그 밖에 컴퓨팅 장치(12)에 의해 액세스되고 원하는 정보를 저장할 수 있는 다른 형태의 저장 매체, 또는 이들의 적합한 조합일 수 있다.

통신 버스(18)는 프로세서(14), 컴퓨터 판독 가능 저장 매체(16)를 포함하여 컴퓨팅 장치(12)의 다른 다양한 컴포넌트들을 상호 연결한다.

컴퓨팅 장치(12)는 또한 하나 이상의 입출력 장치(24)를 위한 인터페이스를 제공하는 하나 이상의 입출력 인터페이스(22) 및 하나 이상의 네트워크 통신 인터페이스(26)를 포함할 수 있다. 입출력 인터페이스(22) 및 네트워크 통신 인터페이스(26)는 통신 버스(18)에 연결된다. 입출력 장치(24)는 입출력 인터페이스(22)를 통해 컴퓨팅 장치(12)의 다른 컴포넌트들에 연결될 수 있다. 예시적인 입출력 장치(24)는 포인팅 장치(마우스 또는 트랙패드 등), 키보드, 터치 입력 장치(터치패드 또는 터치스크린 등), 음성 또는 소리 입력 장치, 다양한 종류의 센서 장치 및/또는 촬영 장치와 같은 입력 장치, 및/또는 디스플레이 장치, 프린터, 스피커 및/또는 네트워크 카드와 같은 출력 장치를 포함할 수 있다. 예시적인 입출력 장치(24)는 컴퓨팅 장치(12)를 구성하는 일 컴포넌트로서 컴퓨팅 장치(12)의 내부에 포함될 수도 있고, 컴퓨팅 장치(12)와는 구별되는 별개의 장치로 컴퓨팅 장치(12)와 연결될 수도 있다.

도 2는 본 발명의 일 실시예에 따른 AUTOSAR(AUTomotive Open System Architecture) 기반 소프트웨어의 설계 방법(200)을 설명하기 위한 흐름도이다. 상기 방법(200)은 AUTOSAR 기반 소프트웨어 설계 시 안전 요구 사항을 식별하기 위한 방법을 포함할 수 있다.

상기 방법(200)은 하나 이상의 프로세서들, 및 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치(12)에서 수행될 수 있다. 이를 위하여, 상기 방법(200)은 하나 이상의 컴퓨터 실행 가능 명령어를 포함하는 프로그램 내지 소프트웨어의 형태로 구현되어 상기 메모리상에 저장될 수 있다.

또한, 도시된 흐름도에서는 상기 방법을 복수 개의 단계로 나누어 기재하였으나, 적어도 일부의 단계들은 순서를 바꾸어 수행되거나, 다른 단계와 결합되어 함께 수행되거나, 생략되거나, 세부 단계들로 나뉘어 수행되거나, 또는 도시되지 않은 하나 이상의 단계가 부가되어 수행될 수 있다.

도 2를 참조하면, AUTOSAR 기반 소프트웨어의 안전 요구 사항을 반영한 설계 방법(200)은 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계(202), 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계(204), 소프트웨어의 동작 중 발생된 결함을 감지하고 감지된 결함을 보고하기 위한 방법을 정의하는 안전 모니터링 설계 단계(206), 및 안전 요구사항에 변경이 발생하는 경우 변경된 사항을 반영하기 위한 안전 요구사항 정제 단계(208)를 포함할 수 있다. 이하, 각 단계에 대해 상세히 살펴보기로 한다.

도 3은 본 발명의 일 실시예에서 소프트웨어 설계 단계(202)를 설명하기 위한 흐름도이다.

단계 302에서, 컴퓨팅 장치(12)는 AUTOSAR의 매뉴얼(예를 들어, 개발 방법론 등)을 기반으로 사용자(예를 들어, 소프트웨어 개발자 등)의 입력에 따라 설계하고자 하는 소프트웨어의 기능 실현을 위해 필요한 인터페이스를 각각 정의할 수 있다. 여기서, 인터페이스는 소프트웨어의 단위 요소인 컴포넌트 사이의 통신 방법을 명시한 요소이다.

컴퓨팅 장치(12)는 컴포넌트 간 통신 과정에서 발생될 수 있는 결함에 대해 명시하도록 인터페이스를 구성할 수 있다. 예시적인 실시예에서, 컴퓨팅 장치(12)는 컴포넌트 간 통신 과정에서 시간 초과(Time out), 요청 과다로 인한 처리 불능(Busy), 잘못된 요청, 접근 거부(Access Denied), 및 소프트웨어의 기능 등으로 인해 발생 가능한 결함을 정의할 수 있다.

이때, 컴퓨팅 장치(12)는 인터페이스에 각 결함에 대한 에러 코드가 삽입되도록 할 수 있다. 즉, 컴포넌트 간 통신 과정에서 시간 초과(Time out), 요청 과다로 인한 처리 불능(Busy), 잘못된 요청, 접근 거부(Access Denied) 등과 같은 결함이 발생한 경우, 해당 결함에 대한 에러 메시지를 상대 컴포넌트로 보내기 위해, 인터페이스에 각 결함에 대한 에러 코드를 삽입할 수 있다.

단계 304에서, 컴퓨팅 장치(12)는 AUTOSAR의 매뉴얼을 기반으로 사용자의 입력에 따라 설계하고자 하는 소프트웨어의 기능 실현을 위해 필요한 컴포넌트들을 정의할 수 있다. 컴퓨팅 장치(12)는 소프트웨어 기능에 따라 하나 이상의 컴포넌트를 정의할 수 있다.

컴퓨팅 장치(12)는 각 컴포넌트에 대해 다른 컴포넌트와의 통신을 위한 포트(Port)를 정의할 수 있다. 즉, 컴포넌트와 컴포넌트 간 인터랙션은 인터페이스를 통해 표현되는데, 이때 인터페이스와 컴포넌트를 연결하는 매핑 요소가 포트이다. 포트를 통해 어떤 데이터(예를 들어, EVENT, FIELD, METHOD 등)가 이동되는지에 대해서는 인터페이스에 정의될 수 있다.

여기서, 포트는 인터페이스를 통해 그 기능이 결정되며, 통신 방향에 따라 제공 포트(Provided Port)와 요구 포트(Required Port)로 구분될 수 있다. 제공 포트(Provided Port)는 서비스를 제공하는 포트이고, 요구 포트(Required Port)는 서비스를 사용하는 포트일 수 있다.

한편, 단계 302에서 정의된 결함에는 제공 포트의 결함 및 요구 포트의 결함을 포함할 수 있다. 제공 포트의 결함은 외부 요소로 전파될 수 있는 결함을 의미하고, 요구 포트의 결함은 내부 요소로 전파될 수 있는 결함을 의미할 수 있다.

즉, 시간 초과(Time out), 요청 과다로 인한 처리 불능(Busy), 잘못된 요청, 접근 거부(Access Denied) 등과 같은 결함은 서비스를 제공하는 제공 포트에서 발생할 수 있으며, 제공 포트에서 발생된 결함에 대한 에러 코드는 제공 포트로부터 서비스를 요구한 해당 요구 포트로 전달될 수 있다. 그리고, 요구 포트에 전달된 에러 코드로부터 발생된 결함은 요구 포트에 연결된 컴포넌트로 전파될 수 있다.

단계 306에서, 컴퓨팅 장치(12)는 설계하고자 하는 소프트웨어의 기능에 따라 컴포넌트(상위 컴포넌트)를 하나 이상의 하위 구조의 컴포넌트(하위 컴포넌트)로 분할 할 수 있다. 여기서, 컴퓨팅 장치(12)는 하위 컴포넌트가 상위 컴포넌트의 포트를 통해 외부 요소로 입력과 출력을 처리하도록 구성할 수 있다.

도 4는 본 발명의 일 실시예에서 결함 분석 단계(204)를 설명하기 위한 흐름도이다.

단계 402에서, 컴퓨팅 장치(12)는 소프트웨어 설계 내용을 기반으로 소프트웨어로부터 발생 가능한 결함의 원인 및 그로 인한 영향 간에 원인 및 영향 관계 정보를 도출할 수 있다. 컴퓨팅 장치(12)는 원인 및 영향 관계 정보를 도출하기 위해, 컴포넌트의 요구 포트의 결함을 원인으로 설정하고, 컴포넌트의 제공 포트의 결함을 영향으로 설정할 수 있다. 컴퓨팅 장치(12)는 소프트웨어 설계 시 포함된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보를 도출할 수 있다.

도 5는 본 발명의 일 실시예에서 소프트웨어의 컴포넌트에서 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보를 도출하는 상태를 설명하기 위한 도면이다.

도 5를 참조하면, 컴포넌트(S10)는 두 개의 요구 포트(S11, S12)와 한 개의 제공 포트(S13)로 구성될 수 있다(도 5의 (a)). 컴포넌트(S10)은 소프트웨어의 구성에 따라 다양한 분할 구조를 가질 수 있다. 예시적인 실시예에서, 컴포넌트(S10)는 제1 하위 컴포넌트(S21), 제2 하위 컴포넌트(S22), 및 제3 하위 컴포넌트(S23)로 분할 될 수 있다(도 5의 (b)).

여기서, 제1 하위 컴포넌트(S21)는 하나의 요구 포트(S21a)와 하나의 제공 포트(S21b)로 구성될 수 있다. 이때, 요구 포트(S21a)는 컴포넌트(S10)의 요구 포트(S11)와 동일한 구성을 가질 수 있다. 제2 하위 컴포넌트(S22)는 하나의 요구 포트(S22a)와 하나의 제공 포트(S22b)로 구성될 수 있다. 이때, 요구 포트(S22a)는 컴포넌트(S10)의 요구 포트(S11)와 동일한 구성을 가질 수 있다.

제3 하위 컴포넌트(S23)는 하나의 요구 포트(S23a)와 하나의 제공 포트(S23b)로 구성될 수 있다. 이때, 제공 포트(S23b)는 컴포넌트(S10)의 제공 포트(S13)와 동일한 구성을 가질 수 있다. 또한, 제1 하위 컴포넌트(S21)의 제공 포트(S21b) 및 제2 하위 컴포넌트(S22)의 제공 포트(S22b)는 제3 하위 컴포넌트(S23)의 요구 포트(S23a)와 동일한 구성을 가질 수 있다.

도 5의 (a)에서 컴포넌트(S10)는 요구 포트(S11)과 요구 포트(S12)를 통해 전파된 결함이 원인이 되어서 발생된 결함을 제공 포트(S13)를 통해 다른 컴포넌트에 전파하게 된다. 즉, 요구 포트(S11)과 요구 포트(S12)의 결함이 복합적으로 작용하여 컴포넌트(S10)의 결함을 발생시킬 수 있게 된다.

도 5의 (b)에서도 동일한 방식으로 원인 및 영향 관계를 가지게 된다. 다만, 요구 포트(S11)을 통해 전달된 결함은 제1 하위 컴포넌트(S21)에 의해 축소 또는 확장되고, 요구 포트(S12)를 통해 전달된 결함은 제2 하위 컴포넌트(S21)에 의해 축소 또는 확장될 수 있다. 즉, 요구 포트(S11)와 요구 포트(S12)의 결함이 간접적으로 작용하여 컴포넌트(10)의 결함을 발생시킬 수 있게 된다. 이에 따라, 도 5의 (a)의 컴포넌트 구조에 비해 더 상세한 원인 및 영향 관계 분석이 가능하게 된다.

한편, 예시적인 다른 실시예에서, 컴포넌트(S10)는 제1 하위 컴포넌트(S31) 및 제2 하위 컴포넌트(S32)로 분할 될 수 있다(도 5의 (c)).

여기서, 제1 하위 컴포넌트(S31)는 하나의 요구 포트(S31a)와 하나의 제공 포트(S31b)로 구성될 수 있다. 이때, 요구 포트(S31a)는 컴포넌트(S10)의 요구 포트(S11)와 동일한 구성을 가질 수 있다.

제2 하위 컴포넌트(S32)는 하나의 요구 포트(S32a)와 하나의 제공 포트(S32b)로 구성될 수 있다. 이때, 요구 포트(S32a)는 컴포넌트(S10)의 요구 포트(S12)와 동일한 구성을 가질 수 있다. 그리고, 제공 포트(S32b)는 컴포넌트(S10)의 제공 포트(S13)와 동일한 구성을 가질 수 있다. 또한, 제1 하위 컴포넌트(S31)의 제공 포트(S31b)는 제2 하위 컴포넌트(S32)의 요구 포트(S32a)와 동일한 구성을 가지므로, 제공 포트(S31b)는 요구 포트(S12)와 동일한 구성을 가지게 된다.

도 5의 (c)에서 컴포넌트(S10)는 요구 포트(S11)의 간접적 작용과 요구 포트(S12)의 직접적 작용으로 인해 결함이 발생할 수 있다. 이러한 구성으로 인해, 요구 포트(S11)의 결함은 요구 포트(S12)에 비해 상대적으로 적은 영향을 미치게 된다.

다시 도 4를 참조하면, 단계 404에서, 컴퓨팅 장치(12)는 도출된 원인 및 영향 관계에 대해 추가 정보를 작성하여 원인 및 영향 관계를 상세화 할 수 있다. 구체적으로, 컴퓨팅 장치(12)는 도출된 각 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨을 부여할 수 있다.

예시적인 실시예에서, 컴퓨팅 장치(12)는 기 설정된 각 컴포넌트의 중요도 및 각 컴포넌트에서 인터랙션이 발생되는 횟수를 기반으로 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨을 부여할 수 있다.

단계 406에서, 컴퓨팅 장치(12)는 도출된 각 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨에 따라 결함 발생 시 조치 방법을 정의할 수 있다. 예시적인 실시예에서, 조치 방법으로는 결함 보고, 소프트웨어 재실행, 소프트웨어가 탑재된 장치 재실행, 소프트웨어 및 소프트웨어가 탑재된 장치의 상태 변경 등이 포함될 수 있다.

표 1은 본 발명의 실시예에서 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨을 부여하고 조치 방법을 정의한 상태를 나타낸 표이다.

원인	영향	발생 가능성	심각도	조치 방법
F11×F21	F31	N/A	N/A	N/A
F11×F22	F31	L	H	재실행
F11×F21	F32	M	L	보고
F11×F22	F32	N/A	N/A	N/A

표 1을 참조하면, 도 5의 (a)에서 컴포넌트(S10)가 결함 F11이 발생 가능한 요구 포트(S11)와 결함 F21 및 F22가 발생 가능한 요구 포트(S 12)를 포함할 수 있다. 또한, 컴포넌트(S10)는 결함 F31 및 F32를 발생시킬 수 있으며, 결함 F31 및 F32를 제공 포트(S13)을 통해 다른 컴포넌트로 전파 할 수 있다고 가정한다.

그러면, 컴포넌트(S10)에 대해 표 1과 같은 요구 포트와 제공 포트 간 원인 및 영향 관계를 도출할 수 있다. 여기서, 원인 및 영향 관계는 모든 요구 포트와 제공 포트로부터 발생 가능한 결함의 조합으로 구성될 수 있다. 표 1에서는 결함의 발생 가능성 및 심각도를 없음(N/A), 낮음(L), 중간(M), 및 높음(H)의 레벨로 표현하였으나, 이는 하나의 실시예일 뿐이며, 이에 한정되는 것은 아니다.

표 1에서, 요구 포트와 제공 포트 간 원인 및 영향 관계들 중 F11×F21 → F31와 F11×F22 → F32에 대해 결함의 발생 가능성이 없음(N/A)으로 표현된 것은 모든 포트는 동시에 하나의 결함만을 발생시킬 수 있으므로, F11×F21 → F31와 F11×F22 → F32은 컴포넌트 구조 상 발생할 수 없기 때문이다.

한편, 컴퓨팅 장치(12)는 도출된 각 원인 및 영향 관계들 중 결함의 발생 가능성 및 심각성 정도의 레벨이 기 설정된 기준 레벨 미만인 것은 삭제할 수 있다.

도 6은 본 발명의 일 실시예에서 안전 모니터링 설계 단계(206)를 설명하기 위한 흐름도이다.

단계 602에서, 컴퓨팅 장치(10)는 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보와 그 조치 방법을 기반으로 소프트웨어 동작시 발생하는 결함을 모니터링하기 위한 감시 컴포넌트를 생성할 수 있다.

여기서, 감시 컴포넌트는 소프트웨어 내의 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계로부터 데이터의 제어 흐름(Control Flow)을 도출할 수 있도록 마련될 수 있다. 감시 컴포넌트는 제어 흐름 내에서 각 노드(예를 들어, 컴포넌트 또는 컴포넌트 내의 포트 등)를 식별하기 위해 소프트웨어의 소스코드에 프로브를 삽입하도록 마련될 수 있다. 감시 컴포넌트는 삽입된 프로브를 통해 데이터가 소프트웨어 내에서 어떤 노드들을 거치는지 확인할 수 있게 된다. 컴퓨팅 장치(10)는 감시 컴포넌트 생성 시 프로브 삽입 정보 및 프로브 식별 정보를 감시 컴포넌트에 포함시킬 수 있다.

감시 컴포넌트는 소프트웨어의 동작 시 데이터의 제어 흐름이 기 설정된 제어 흐름을 벗어나는지 감시하도록 마련될 수 있다. 예시적인 실시예에서, 감시 컴포넌트는 소프트웨어의 동작 시 데이터의 노드들 간의 경로가 기 설정된 경로와 다른 경우 및 노드와 노드 간 소요 시간이 기 설정된 소요 시간을 초과하는 경우 등을 감시하여 결함 여부를 모니터링하도록 마련될 수 있다.

단계 604에서, 컴퓨팅 장치(10)는 감시 컴포넌트에서 결함 여부를 검출하는 경우, 결함 보고를 위한 결함 보고 인터페이스를 구성할 수 있다. 예를 들어, 표 1에서 요구 포트(S11)과 요구 포트(S12)로부터 F11과 F21의 발생 여부를 확인한 경우 결함 F32가 발생했음을 알리도록 하고, 요구 포트(S11)과 제공 포트(S13)으로부터 F11과 F22의 발생 여부를 확인한 경우 결함 F31이 발생했음을 알리도록 결함 보고 인터페이스를 구성할 수 있다. 이때, 결함 보고 인터페이스는 결함이 발생되는 컴포넌트에 할당될 수 있으며, 결함 식별을 위한 식별자도 함께 배정될 수 있다.

한편, 다시 도 2를 참조하면, 안전 요구사항 정제 단계(208)는 컴포넌트로부터 발생 가능한 결함 정보가 변경되는 경우 수행될 수 있다. 안전 요구사항 정제 단계(208)는 변경된 결함에 한하여 소프트웨어 설계 단계(202), 결함 분석 단계(204), 및 안전 모니터링 설계 단계(206)를 재수행하도록 구성될 수 있다.

개시되는 실시예에 의하면, AUTOSAR의 개발 방법론에 따라 소프트웨어의 개발을 수행하더라도 가정된 안전 요구사항을 용이하게 도출할 수 있게 된다. 이를 통해 개발되는 소프트웨어의 안전성을 향상시켜 상품 가치를 보장할 수 있도록 하며, 자동차 주행 중 발생 가능한 재산 및 인명 피해를 예방할 수 있게 된다.

이상의 상세한 설명은 본 발명을 예시하는 것이다. 또한 전술한 내용은 본 발명의 바람직한 실시 형태를 나타내어 설명하는 것이며, 본 발명은 다양한 다른 조합, 변경 및 환경에서 사용할 수 있다. 즉 본 명세서에 개시된 발명의 개념의 범위, 저술한 개시 내용과 균등한 범위 및/또는 당업계의 기술 또는 지식의 범위내에서 변경 또는 수정이 가능하다. 저술한 실시예는 본 발명의 기술적 사상을 구현하기 위한 최선의 상태를 설명하는 것이며, 본 발명의 구체적인 적용 분야 및 용도에서 요구되는 다양한 변경도 가능하다. 따라서 이상의 발명의 상세한 설명은 개시된 실시 상태로 본 발명을 제한하려는 의도가 아니다. 또한 첨부된 청구범위는 다른 실시 상태도 포함하는 것으로 해석되어야 한다.

10 : 컴퓨팅 환경
12 : 컴퓨팅 장치
14 : 프로세서
16 : 컴퓨터 판독 가능 저장 매체
18 : 통신 버스
20 : 프로그램
22 : 입출력 인터페이스
24 : 입출력 장치
26 : 네트워크 통신 인터페이스

Claims

하나 이상의 프로세서들, 및
상기 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치에서 수행되는 방법으로서,
AUTOSAR(AUTomotive Open System Architecture) 메뉴얼을 기반으로 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계;
상기 설계되는 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계; 및
상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링 설계 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 1에 있어서,
상기 소프트웨어 설계 단계는,
상기 AUTOSAR 매뉴얼을 기반으로 사용자의 입력에 따라 상기 소프트웨어의 기능 실현을 위해 필요한 인터페이스를 각각 정의하는 단계; 및
상기 소프트웨어의 기능 실현을 위해 필요한 컴포넌트들을 정의하는 단계를 포함하고,
상기 인터페이스를 각각 정의하는 단계는, 상기 컴포넌트 간 통신 과정에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 2에 있어서,
상기 컴포넌트들을 정의하는 단계는, 각 컴포넌트들에 대해 다른 컴포넌트와의 통신을 위한 제공 포트 및 요구 포트를 정의하는 단계를 포함하고,
상기 인터페이스를 각각 정의하는 단계는, 상기 제공 포트 및 상기 요구 포트에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 3에 있어서,
상기 결함 분석 단계는,
상기 소프트웨어로부터 발생 가능한 결함의 원인 및 그로 인한 영향 간에 원인 및 영향 관계를 도출하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 4에 있어서,
상기 원인 및 영향 관계를 도출하는 단계는,
상기 컴포넌트의 요구 포트의 결함을 원인으로 설정하고, 상기 컴포넌트의 제공 포트의 결함을 영향으로 설정하여 상기 소프트웨어에 포함된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계를 도출하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 5에 있어서,
상기 결함 분석 단계는,
상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도 중 하나 이상에 대해 레벨을 부여하는 단계; 및
상기 부여된 레벨에 따라 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함 발생 시 조치 방법을 정의하는 단계를 더 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 6에 있어서,
상기 레벨을 부여하는 단계는,
기 설정된 각 컴포넌트의 중요도 및 각 컴포넌트에서 인터랙션이 발생되는 횟수를 기반으로 상기 원인 및 영향 관계에 대해 레벨을 부여하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 6에 있어서,
상기 결함 분석 단계는,
상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계들 중 상기 레벨이 기 설정된 기준 레벨 미만인 것은 삭제하는 단계를 더 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 6에 있어서,
상기 안전 모니터링 설계 단계는,
상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계와 상기 조치 방법을 기반으로 상기 소프트웨어 동작시 발생하는 결함을 모니터링하기 위한 감시 컴포넌트를 생성하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 9에 있어서,
상기 감시 컴포넌트는,
상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계로부터 상기 소프트웨어 내의 데이터 제어 흐름을 도출할 수 있도록 마련되는, AUTOSAR 기반의 소프트웨어 설계 방법.
청구항 9에 있어서,
상기 안전 모니터링 설계 단계는,
상기 감시 컴포넌트에서 결함 감지 시 결함 보고를 위한 결함 보고 인터페이스를 구성하는 단계를 더 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
하나 이상의 프로세서들;
메모리; 및
하나 이상의 프로그램들을 포함하고,
상기 하나 이상의 프로그램들은 상기 메모리에 저장되고, 상기 하나 이상의 프로세서들에 의해 실행되도록 구성되고, AUTOSAR(AUTomotive Open System Architecture) 기반의 소프트웨어 설계를 위한 컴퓨팅 장치로서,
상기 하나 이상의 프로그램들은,
AUTOSAR 메뉴얼을 기반으로 소프트웨어의 구조를 정의하기 위한 명령;
상기 소프트웨어로부터 발생 가능한 결함을 분석하기 위한 명령; 및
상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링을 설계하기 위한 명령을 포함하는, 컴퓨팅 장치.