KR102158687B1 - FBF(Function Block Feature)를 이용하여 AUTOSAR의 VFB를 설계하는 방법 및 장치 - Google Patents

Abstract

AUTOSAR(AUTomotive Open System ARchitecture)의 VFB(Virtual Function Bus)를 설계하는 방법에 있어서, 차량의 동작과 관련된 기능에 대한 기능 요구사항을 식별하는 단계; 상기 기능 요구사항과 상기 차량의 하드웨어에 기초하여, 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 구성된 시스템 모델을 생성하는 단계; 상기 기능 요구사항 및 상기 시스템 모델에 기초하여, 상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 기능 블록 피처(FBF: Function Block Feature, 이하 FBF)를 결정하는 단계; 및 상기 시스템 모델에 포함된 각 카테고리 별 상기 결정된 FBF에 기초하여 AUTOSAR의 VFB를 설계하는 단계를 포함하는, 방법이 개시된다.

Description

FBF(Function Block Feature)를 이용하여 AUTOSAR의 VFB를 설계하는 방법 및 장치 {Method and apparatus for designing VFB of AUTOSAR using a FBF (Function Block Feature)}

본 개시의 다양한 실시예들은 AUTOSAR(AUTomotive Open System ARchitecture)의 VFB(Virtual Function Bus)를 설계하는 방법 및 장치에 관한 것이다.

현재 자동차는 기능의 복잡도가 높아지며 하나의 ECU(Electronic Control Unit)가 아닌 수십 개의 ECU가 상호 통신을 통해 복합적인 기능을 수행하고 있다. 복수의 ECU의 상호 통신으로 인해 시스템 복잡성이 증가됨에 따라 ECU 소프트웨어의 상호 호환성 및 재사용성에 대한 문제가 거론되기 시작하면서, AUTOSAR(AUTomotive Open System Architecture, 오토사)라는 개방형 자동차 소프트웨어 아키텍처 표준이 개발되었다.

AUTOSAR는 세계의 자동차 업체가 공통으로 사용할 수 있는 개방형 표준 시스템 아키텍처이다. AUTOSAR는 소프트웨어 구조를 계층적 구조로 나누고 인터페이스를 표준화 함으로써 소프트웨어의 이식성 및 재사용성을 향상하였다.

AUTOSAR에서 VFB(Virtual Functional Bus)는 AUTOSAR 소프트웨어 컴포넌트 간 연결을 추상화 함으로써 컴포넌트들을 간의 상호작용이 원활하도록 컴포넌트들을 연결하는 역할을 한다.

하지만 AUTOSAR에는 VFB의 설계 방법 및 요소에 대한 설명, 그리고 내부 동작(Internal Behavior) 설계 방법 및 요소에 대한 설명은 있으나, 기능 요구사항에 따라 VFB를 설계하는 방법에 대한 설명은 명시되어 있지 않다. 따라서 VFB 설계 시 설계의 완성도는 설계자의 지식과 경험에 의존하고 있다. 또한 기능 요구사항을 기초로 VFB를 설계하기까지의 설계 과정에 대한 명확한 설계 근거가 마련되어 있지 않아, 추적성을 관리하기 위해서는 별도의 전용 개발 도구를 사용해야 하는 문제가 있다.

따라서, 명확한 설계 근거에 따라 AUTOSAR의 VFB를 설계하고, 추적성을 향상하기 위한 방법이 요구된다.

본 개시의 다양한 실시예들은 기능 요구사항과 차량의 하드웨어에 기초하여 시스템 모델 및 기능 블록 피처(FBF, Function Block Feature. 이하 FBF)를 결정하고, 결정된 FBF를 이용하여 AUTOSAR의 VFB를 설계하는 방법 및 장치를 제공하는 것을 목적으로 한다.

일 실시예에 따른 AUTOSAR의 VFB를 설계하는 방법은, 차량의 동작과 관련된 기능에 대한 기능 요구사항을 식별하는 단계; 상기 기능 요구사항과 상기 차량의 하드웨어에 기초하여, 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 구성된 시스템 모델을 생성하는 단계; 상기 기능 요구사항 및 상기 시스템 모델에 기초하여, 상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 기능 블록 피처(FBF: Function Block Feature, 이하 FBF)를 결정하는 단계; 및 상기 시스템 모델에 포함된 각 카테고리 별 상기 결정된 FBF에 기초하여 AUTOSAR의 VFB를 설계하는 단계를 포함한다.

일 실시예에 따르면, 상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정하는 단계는, 상기 차량의 컨트롤러 내부의 소프트웨어 모듈 중 출력 요소를 가지는 개체 또는 상기 차량의 센서 중 적어도 하나를 소스 개체로 분류하고, 상기 컨트롤러 내부의 소프트웨어 모듈 중 입력 요소를 가지는 개체 또는 상기 차량의 작동기 중 적어도 하나를 결과 개체로 분류하고, 상기 기능 요구사항에 기초하여 상기 소스 개체 및 상기 결과 개체 간의 연결 관계를 액션으로 결정하고, 상기 소스 개체, 상기 결과 개체, 및 상기 액션의 매핑을 상기 FBF로 결정하는 단계를 포함할 수 있다.

일 실시예에 따르면, 상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정하는 단계는, 상기 각 카테고리 별로 상기 적어도 하나의 FBF를 매핑하여 FBF 워크시트(Worksheet)를 생성하는 단계를 포함하고, 상기 AUTOSAR의 VFB를 설계하는 단계는, 상기 FBF 워크시트에 기초하여 상기 VFB에서 센서 컴포넌트, 어플리케이션 컴포넌트, 및 작동기 컴포넌트를 결정하고, 상기 컴포넌트들의 연결관계를 결정하는 단계를 포함할 수 있다.

일 실시예에 따르면, 상기 AUTOSAR의 VFB를 설계하는 단계는, AUTOSAR의 센서-작동기 패턴에 기초하여, 상기 컴포넌트들의 연결에 이용되는 인터페이스를 결정하는 단계를 더 포함할 수 있다.

일 실시예에 따른 AUTOSAR의 VFB를 설계하는 장치는, 차량의 동작과 관련된 기능에 대한 기능 요구사항을 식별하는 기능 요구사항 식별부; 상기 기능 요구사항과 상기 차량의 하드웨어에 기초하여, 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 구성된 시스템 모델을 생성하는 시스템 모델 생성부; 상기 기능 요구사항 및 상기 시스템 모델에 기초하여, 상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 기능 블록 피처(FBF: Function Block Feature, 이하 FBF)를 결정하는 FBF 분석부; 및 상기 시스템 모델에 포함된 각 카테고리 별 상기 결정된 FBF에 기초하여 AUTOSAR의 VFB를 설계하는 설계부를 포함한다.

본 개시의 다양한 실시예에 따른 AUTOSR의 VFB 설계 방법에 따르면, 기능 요구사항을 기초로 시스템 모델 및 FBF를 결정하고, 결정된 FBF에 따라 VFB를 설계함으로써, 일관적이고 정형적인 VFB 설계 근거를 제공할 수 있고, 기능 요구사항과 설계의 불일치를 해소할 수 있다.

또한, FBF 결정 시 각 피처에 대한 피처 식별자(Feature ID)를 설정함으로써, 정형화된 설계 절차 및 피처 식별자를 기초로 VFB 컴포넌트에 대한 기능 요구사항 등의 추적을 용이하게 할 수 있다.

도 1은 FDD (Feature Driven Development) 프로세스를 나타내는 도면이다.
도 2는 AUTOSAR의 센서-작동기 패턴을 나타내는 도면이다.
도 3은 일 실시예에 따라 AUTOSAR의 VFB를 설계하는 방법을 설명하기 위한 흐름도이다.
도 4는 일 실시예에 따라 기능 요구사항에 기초하여 FBF (Function Block Feature)를 결정하는 방법을 설명하기 위한 흐름도이다.
도 5는 일 실시예에 따른 VFB 설계 방법의 시스템 모델을 설명하기 위한 도면이다.
도 6은 기능 요구사항과 AUTOSAR의 센서-작동기 패턴과의 측정값 수준 연관관계를 나타내는 도면이다.
도 7은 AUTOSAR의 센서-작동기 패턴에서의 AUTOSAR 소프트웨어 컴포넌트의 분류를 나타내는 도면이다.
도 8은 일 실시예에 따른 VFB 설계 방법에 따라 설계된 VFB의 일 예를 설명하기 위한 도면이다.
도 9는 일 실시예에 따른 VFB 설계 장치의 구성을 도시한 블록도이다.

본 개시의 실시예들에서 사용되는 용어는 개시된 실시예들에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 부분에서 상세히 그 의미를 기재할 것이다. 따라서, 개시된 실시예들에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 개시된 실시예들 전반에 걸친 내용을 토대로 정의되어야 한다.

본 개시의 실시예들은 다양한 변경을 가할 수 있고 여러 가지 형태를 가질 수 있는바, 일부 실시예들을 도면에 예시하고 상세하게 설명하고자 한다. 그러나, 이는 본 개시의 실시예들을 특정한 개시형태에 대해 한정하려는 것이 아니며, 본 개시의 실시예들의 사상 및 기술범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 본 명세서에서 사용한 용어들은 단지 실시예들의 설명을 위해 사용된 것으로, 개시된 실시예들을 한정하려는 의도가 아니다.

본 개시의 실시예들에 사용되는 용어들은 다르게 정의되지 않는 한, 개시된 실시예들이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미가 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 개시된 실시예들에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않아야 한다.

이하에서는 도면들을 참조하여 본 개시의 실시예들을 상세히 설명하도록 한다.

도 1은 FDD (Feature Driven Development) 프로세스를 나타내는 도면이다.

도 1에서는 본 개시의 다양한 실시예에 따른 AUTOSAR의 VFB 설계 방법을 설명하기 위해, 먼저 피처(Feature), 기능 블록 피처(FBF: Function Block Feature. 이하 FBF), 및 FDD (Feature Driven Development) 프로세스에 대해 설명한다.

피처는 피처 엔지니어링(Feature Engineering)에서 유래된 것으로, 성능(Performance), 이식성(Portability), 기능성(Functionality)과 같은 소프트웨어 특성 및/또는 요구사항 문서화에 의해 명시되거나 암시된 소프트웨어 특성을 의미한다. 피처는 소프트웨어와 관련된 개발 프로세스 중 도메인 분석 기법에서 주로 사용되었다.

FDD(Feature Driven Development)는 반복적이고 점증적인 방식으로 S/W를 개발하는 애자일 S/W 개발 프로세스이다. 도 1을 참조하면, FDD 프로세스에서는 다섯 단계를 통해 요구사항을 피처 단위로 분리하여 개발을 진행한다. 첫 번째로 도메인 모델을 정의한다. 두 번째로 도메인 모델에 포함된 적어도 하나의 기능적인 요소 중 하나의 기능 요소에서 <Action>, <Result>, <Object>로 정의된 피처 리스트를 도출한다. 세 번째로 피처를 이용한 기능 요소의 개발 계획을 수립하고, 네 번째로 피처의 기능에 대한 세부 시퀀스 다이어그램을 정의하는 등 피처를 이용하여 기능 요소를 설계한다. 최종적으로 디자인된 피처의 명세를 통해 빌드를 진행하여 기능 설계를 완료하고, 이를 도메인 모델에 포함된 다른 기능 요소에 대해 반복적으로 수행한다.

기능 블록(Function Block)은 제어시스템 표준인 IEC 61131-3에서 도입되어 PLC에서 제어구성을 위해 사용하는 언어 중 하나이다. 기능 블록은 입력 변수와 출력 변수를 가지고 있는 함수이며, 전술한 함수를 기본 블록 세트라 부른다. 기본 블록 세트는 입력 변수, 출력 변수 그리고 수행하는 기능으로 이루어져 있다. 입력 및 출력 변수는 연결선에 의하여 블록과 블록 간 연결될 수 있다. 연결선은 데이터를 일 방향으로만 전송할 수 있다. 연결선은 총 3가지의 연결, 즉 입력 변수와 블록의 입력, 블록의 출력과 출력 변수, 및 블록의 출력과 다른 블록의 입력의 연결을 지원한다.

본 개시의 다양한 실시예에 따른 VFB 설계 방법은, 기능 블록(Function Block)을 피처(Feature)로 구성한 기능 블록 피처(FBF)를 이용하여 VFB를 설계한다. 또한 FBF를 결정하는 방법에는, 기능 요소에서 <Action>, <Result>, <Object>로 정의된 피처 리스트를 도출하여 개발을 진행하는 FDD의 프로세스의 일부를 변형하여 반영하였다. FBF를 이용한 VFB 설계 방법의 자세한 내용은 도 3에서 설명하도록 한다.

먼저, 이하에서는 도 2를 참조하여 VFB 설계의 바탕이 되는 AUTOSAR 의 소프트웨어 구조를 설명하도록 한다.

도 2는 AUTOSAR의 센서-작동기 패턴을 나타내는 도면이다.

AUTOSAR의 소프트웨어 구조는 센서(Sensor)나 작동기(Actuator)와 같이 하드웨어에 바로 접근하는 MCAL, 및 ECU Abstraction과, 센서 및 작동기를 통해 하드웨어와 연결되어 하드웨어 종속성을 가지지 않게 되는 어플리케이션 소프트웨어(Application Software) 계층으로 나누어져 있다. 그리고 각 계층을 구성하는 요소들은 소프트웨어 컴포넌트(Software Component)로 캡슐화 되어 있다.

AUTOSAR는 전술한 소프트웨어 구조를 위해 소프트웨어의 디자인 패턴 중 도 2에 도시된 센서-작동기 패턴(Sensor Actuator Pattern)을 따른다. 센서-작동기 패턴은 디바이스 추상화(Device Abstraction)라고도 한다.

센서-작동기 패턴은 전반적인 AUTOSAR의 아키텍처와 관련하여 ECU에 연결된 하드웨어 센서와 작동기의 연결된 동작에 대하여 표현한다. 또한 센서-작동기 패턴은 특정 ECU에 연결된 센서 및 작동기와 응용 소프트웨어의 독립성을 보장하고, 서로 다른 종류의 센서와 작동기 사이에서의 재사용 가능한 소프트웨어 컴포넌트 설계를 가능하게 하는 구조를 나타낸다.

이하에서는 본 개시의 다양한 실시예에 따라 FBF를 이용하여 VFB를 설계하는 구체적인 방법을 설명한다.

도 3은 일 실시예에 따라 AUTOSAR의 VFB를 설계하는 방법을 설명하기 위한 흐름도이다.

단계 310에서, 차량의 동작과 관련된 기능에 대한 기능 요구사항을 식별한다.

AUTOSAR의 VFB를 FBF로 설계하기 위해서는 우선 기능 요구사항을 식별하여 시스템에서 수행해야 하는 기능을 파악해야 한다.

차량의 동작과 관련된 기능에 대한 기능 요구사항은, 예를 들어 차량 전조등 점등, 차량 계기판 LED 점등, 차량 브레이크 동작 등 차량의 동작과, 그 동작이 수행되기 위한 세부 절차를 의미한다. 다음 표 1은 차량의 기능 요구사항의 일 예이다.

[표 1]

예를 들어, '차량 전조등 점등' 및 '운전자가 차량 전조등 점등 스위치를 작동하면 차량 전조등이 켜진다.'는 내용을 기능 요구사항으로 식별할 수 있다.

또한, 복수의 기능 요구사항에 대한 설계를 일관적으로 진행하고, 추적성을 향상하기 위해, [표 1]에 기재된 바와 같이 각각의 기능 요구사항에 대해 기능 요구사항 식별자(Function Requirement ID)를 설정할 수 있다. 예를 들어, 차량 전조등 점등과 관련된 기능 요구사항의 식별자는 FR-001(Function Requirement-001)로 설정할 수 있다.

단계 320에서, 기능 요구사항과 차량의 하드웨어에 기초하여, 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 구성된 시스템 모델을 생성한다.

센서, 컨트롤러, 및 작동기 카테고리로 구성된 시스템 모델을 생성함으로써, 시스템 구성요소와 시스템의 기능, 및 기능의 흐름을 명확히 파악하여 VFB의 설계를 용이하게 진행할 수 있다.

도 5를 참조하면, 단계 310의 [표 1]에 기재된 기능 요구사항에 대한 시스템 모델이 도시되어 있다. 도 5에 도시된 시스템 모델의 센서 카테고리(510)에는 차량 전조등 스위치, 차량 브레이크 페달이 포함되어 있고, 컨트롤러 카테고리(520)는 ECU가 포함되어 있고, 작동기 카테고리(530)에는 차량의 하드웨어로 차량 전조등, 차량 계기판 LED, 및 차량 브레이크가 포함되어 있다.

다시 도 3을 참조하면, 단계 330에서, 기능 요구사항 및 시스템 모델에 기초하여, 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정한다.

FBF 모델은 소스 개체(Source Object), 결과 개체(Result Object), 및 액션(Action)으로 구성 되어있다. 소스 개체는 다른 개체에 영향을 주는 개체의 저장소 및/또는 장치를 추상화한 객체이다. 결과 개체는 다른 개체로부터 영향을 받는 개체의 저장소 및/또는 장치를 추상화한 객체이다.

예를 들어, 하드웨어 센서는 주변 환경을 감지한 정보를 소프트웨어에 데이터로 전달하므로, 하드웨어 센서는 소프트웨어에 영향을 주는 소스 개체이고, 하드웨어 센서로부터 영향을 받는 소프트웨어는 결과 개체이다. 마찬가지로, 한 소프트웨어가 다른 소프트웨어에 영향을 주는 경우, 영향을 주는 소프트웨어는 소스 개체이고 영향을 받는 소프트웨어는 결과 개체가 된다.

액션은 소스 개체가 결과 개체에 영향을 주는 방식을 표현한다. 액션은 측정값 수준에서는 읽기(Read), 전송(Transfer), 처리(Process), 및 쓰기(Write)로 총 4가지로 구성될 수 있다. 액션의 4가지 항목은 아래의 표 2와 같다.

[표 2]

한편, 측정값 수준이란 사용자의 관점에서 시스템 모델을 통해 센서, 컨트롤러 및 작동기를 바라본 개념이다.

센서를 동작하면 소정의 데이터가 센서의 저장공간에 사람이 인지할 수 있는 값(Value)으로 저장되고, 저장된 값은 소정의 인터페이스를 통해 컨트롤러(ECU)에 전달된다. 컨트롤러는 센서로부터 받은 데이터를 처리(Process)하여 명령을 만들고, 명령을 값으로 저장하여 소정의 인터페이스를 통해 작동기로 전송한다. 전송된 명령은 작동기의 저장공간에 값으로 저장되며, 저장된 값을 참조하여 작동기가 동작한다.

전술한 바와 같이 센서의 측정값이 단계적으로 처리됨으로써 작동기가 동작하는 과정을 사용자의 관점에서 바라본 개념을 측정값 수준이라 한다.

측정값 수준으로 각 카테고리 별 FBF를 결정하기 위해서, 먼저 차량의 하드웨어 센서 개체, 컨트롤러 내부 소프트웨어 모듈 개체, 및 하드웨어 작동기 개체로 이루어진 개체 군에서, 기능 요구사항에 따라 시스템 모델의 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리 각각에 포함되어야 하는 개체들을 식별한다.

도 6을 참조하면, 기능 요구사항과 AUTOSAR의 센서-작동기 패턴과의 측정값 수준 연관관계가 도시되어 있다. 도 6에 도시된 바와 같이, 시스템 모델의 센서 카테고리(510)에 포함되어야 하는 개체들(610), 컨트롤러 카테고리(520)에 포함되어야 하는 개체들(620), 및 작동기 카테고리(530)에 포함되어야 하는 개체들(630)을 기능 요구사항에 따라 식별할 수 있다.

다시 도 3을 참조하면, 단계 330에서, 시스템 모델의 각 카테고리에 포함된 개체에 대해, 기능 요구사항을 기초로 서로 영향을 주고 받는 개체를 식별한다.

이어서, 기능 요구사항을 기초로 서로 영향을 주고 받는 개체 사이의 액션을 식별한다.

마지막으로, 시스템 모델의 각 카테고리에 대해서, 제2 개체에게 영향을 주는 제1 개체, 제1 개체에게 영향을 받는 제2 개체, 및 제1 개체와 제2 개체 사이의 액션을 매핑하여 하나의 FBF로 결정한다. 각 카테고리에 포함된 모든 액션들 및 개체들에 대해 전술한 바와 같이 서로 연관된 액션 및 개체들을 하나의 FBF로 결정하여, FBF 리스트를 생성한다.

도 4를 참조하면, 일 실시예에 따라 기능 요구사항에 기초하여 FBF를 결정하는 방법에 대한 흐름도가 도시되어 있다. 도 4의 단계 410 내지 단계 440은 도 3의 단계 330의 세부 단계에 해당할 수 있다.

도 4의 단계 410에서, 차량의 컨트롤러 내부의 소프트웨어 모듈 중 출력 요소를 가지는 개체 또는 차량의 센서 중 적어도 하나를 소스 개체(Source Object)로 분류한다.

소스 개체는 다른 개체로 영향을 주는 개체이므로, 주로 하드웨어 센서나 컨트롤러 내부 소프트웨어 모듈 중 출력 요소를 가지고 있는 개체들을 소스 개체로 분류할 수 있다.

단계 420에서, 컨트롤러 내부의 소프트웨어 모듈 중 입력 요소를 가지는 개체 또는 차량의 작동기 중 적어도 하나를 결과 개체(Result Object)로 분류한다.

결과 개체는 다른 개체로부터 영향을 받는 개체이므로, 주로 하드웨어 작동기나 컨트롤러 내부 소프트웨어 모듈 중 입력 요소를 가지고 있는 개체들을 결과 개체로 분류할 수 있다.

단계 430에서, 기능 요구사항에 기초하여 소스 개체 및 결과 개체 간의 연결 관계를 액션(Action)으로 결정한다.

즉, 결정된 소스 개체들과 결과 개체들 중, 기능요구사항과 시스템 모델 기반으로 소스 개체와 결과 개체 사이의 관계를 분석한 뒤, 서로 영향을 주고 받는 소스 개체와 결과 개체를 매핑한다. 이어서, 매핑된 소스 개체와 결과 개체 사이의 기능 요구사항에 따른 관계에 따라, 두 개체 사이의 액션을 4가지의 액션 타입 중에서 결정한다.

단계 440에서, 소스 개체, 결과 개체, 및 액션의 매핑을 FBF로 결정한다.

즉, 서로 영향을 주고 받는 하나의 소스 개체와 하나의 결과 개체, 및 두 두 개체 사이의 액션을 하나의 FBF로 매핑한다.

다시 도 3을 참조하면, 단계 330에서, 예를 들어 하나의 FBF에 매핑된 액션, 소스 개체 및 결과 개체는 다음의 [표 3]과 같이 나타낼 수 있다.

[표 3]

또한, 하나의 기능 요구사항의 시스템 모델의 각 카테고리에 포함된 FBF들을 종합하여 FBF 워크시트(Worksheet)를 생성할 수 있다. 예를 들어, [표 1]의 '차량 전조등 점등' 기능 요구사항에 대한 측정값 수준 FBF 워크시트는 다음 [표 4]와 같이 구성할 수 있다.

[표 4]

[표 4]에 기재된 바와 같이, 각각의 FBF에 대해서 피처 ID (Feature ID)를 설정하고, 설계된 VFB 컴포넌트에 대해 VFB 컴포넌트와 관련된 카테고리, 영향을 주고 받는 개체 및 액션 등의 추적을 용이하게 할 수 있다.

또한, 시스템 모델의 카테고리는 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 분류하였으나, [표 4]에 기재된 바와 같이 FBF는 센싱(Sensing), 제어(Control), 및 작동(Actuation)의 카테고리로 분류할 수 있다. FBF를 센싱, 제어, 및 작동 카테고리로 분류하는 이유는 FBF 각각에 매핑된 소스 개체 또는 결과 개체가 하드웨어 센서 또는 하드웨어 작동기뿐만 아니라 소프트웨어 컴포넌트일 수 있기 때문이다.

[표 4]에서 Light_Switch는 차량 전조등 스위치의 추상화 객체이고, SW_Light_Ctl은 ECU 내부에서 데이터를 처리하는 소프트웨어의 추상화 객체이다. Light_Act는 차량 전조등의 추상화 객체이며 LightSwitch_Val, LightAct_Val 은 도 5에 도시된 시스템 모델에서 차량 전조등 스위치와 ECU, 및 ECU와 차량 전조등 간의 전송되는 데이터를 추상화한 객체이다. 전송되는 데이터 추상화 객체는 서로 다른 두 객체를 연결하는 인터페이스를 통하여 전송된다.

또한, 복수의 기능 요구사항에 대한 VFB 설계를 위해, 각각의 기능 요구사항에 대한 FBF 워크시트를 생성할 수 있다. 예를 들어, [표 1]의 '차량 계기판 LED 점등' 기능 요구사항에 대한 측정값 수준 FBF 워크시트는 다음 [표 5]와 같이 구성할 수 있다.

[표 5]

또한, [표 1]의 '차량 브레이크 동작' 기능 요구사항에 대한 측정값 수준 FBF 워크시트는 다음 [표 6]과 같이 구성할 수 있다.

[표 6]

단계 340에서, 시스템 모델에 포함된 각 카테고리 별 결정된 FBF에 기초하여 AUTOSAR의 VFB를 설계한다.

단계 310 내지 단계 330을 통해 결정된, 기능 요구사항에 대한 시스템 모델의 센서, 컨트롤러, 및 작동기 카테고리 각각에 포함된 FBF를 통해, 시스템 모델에 포함된 각각의 개체들에 관한 연결관계가 명확히 식별된다. 따라서, AUTOSAR의 센서-작동기 패턴에서의 AUTOSAR 소프트웨어 컴포넌트의 분류, 및 단계 330에서 결정된 각 카테고리 별 FBF를 이용하여, AUTOSAR의 VFB 컴포넌트들 및 VFB 컴포넌트들 사이의 연결관계를 설정함으로써 VFB를 설계한다.

도 7을 참조하면, AUTOSAR의 센서-작동기 패턴에서의 AUTOSAR 소프트웨어 컴포넌트의 분류가 도시되어 있다. VFB 설계는 어플리케이션 컴포넌트(Application Component) 및 센서 컴포넌트(Sensor Component) 및 그 연결관계를 설계하는 것을 포함한다. MCAL은 사용되는 보드의 공급 회사에서 제공하며, VFB 설계 단계에서는 포함되지 않는다.

또한, ECU Abstraction 컴포넌트는　하드웨어와 밀접하게 연관되어 있어서, AUTOSAR 소프트웨어의 각 컴포넌트가 하드웨어에 접근할 수 있도록 하기 위해서는 VFB 설계 시 하나 이상의 ECU Abstraction 컴포넌트를 포함해야 한다.

본 개시에서는 설명의 편의상 ECU Abstraction 컴포넌트 하나를 포함하여 VFB를 설계하는 것을 일 예를 들어 설명한다. 그러나 VFB 설계 시 복수의 ECU Abstraction 컴포넌트를 포함할 수도 있는 것은 물론이다.일 실시예에 따르면, AUTOSAR의 센서-작동기 패턴에 기초하여, 컴포넌트들의 연결에 이용되는 인터페이스를 결정할 수 있다. 예를 들어, AUTOSAR 인터페이스에 관하여, ECU Abstraction과 센서/작동기 컴포넌트 사이의 연결관계는 Client-Server Interface를 사용하고, 센서/작동기 및 어플리케이션 컴포넌트 사이의 연결관계는 Sender-Receiver Interface를 사용하도록 결정할 수 있다.

다시 도 3를 참조하면, 단계 340에서는 또한, 기능 요구사항 및 카테고리 별 FBF를 종합하여 생성된 적어도 하나의 FBF 워크시트에 기초하여, VFB에서 센서 컴포넌트, 어플리케이션 컴포넌트, 및 작동기 컴포넌트를 결정하고, 각 컴포넌트들의 연결관계를 결정함으로써 VFB를 설계할 수도 있다.

도 8을 참조하면, 도 3을 참조하여 설명한 VFB 설계 방법에 따라 설계된 VFB의 일 예가 도시되어 있다. 도 8은 VFB단계까지의 설계에 대해 TopLevelComposition을 작성한 것이다.

도 8을 참조하면, 하나의 ECU Abstraction(CPT_ECU_ABS)으로부터, 차량 전조등 스위치 상태 및 차량 브레이크 페달 상태를 각 센서 컴포넌트가 Client-Server Interface를 이용하여 수신하며, 각 센서 컴포넌트는 수신한 데이터를 어플리케이션 컴포넌트인 Brake_Ctl 및 Light_Ctl로 Sender-Receiver Interface를 이용하여 전송한다.

Brake_Ctl은 차량 브레이크 동작 명령을 생성하여 차량 브레이크를 작동시켜야 하기 때문에, Sender-Receiver Interface를 이용하여 작동기 컴포넌트인 Brake_Act에 명령을 전달한다. 마찬가지로 Light_Ctl은 차량 전조등 및 차량 계기판 LED에 대한 동작 명령을 생성하여 각 작동기를 작동시키야 하기 때문에, Sender-Receiver Interface를 이용하여 작동기 컴포넌트인 Car_Light_Act 및 InstPanel_Act에 명령을 전달한다.

3개의 작동기 컴포넌트인 Brake_Act, Car_Light_Act, 및 InstPanel_Act는, 실제 하드웨어 작동기가 동작할 수 있도록 ECU Abstraction에 데이터를 전달하여야 하므로, Client-Server Interface를 사용하여 명령 데이터를 ECU Abstraction에 전달한다.

도 3을 참조하여 설명한 AUTOSAR의 VFB 설계 방법에 따르면, 기능 요구사항을 기초로 시스템 모델 및 FBF를 결정하고, 결정된 FBF에 따라 VFB를 설계함으로써, 일관적이고 정형적인 VFB 설계 근거를 제공할 수 있고, 기능 요구사항과 설계의 불일치를 해소할 수 있다. 예를 들어, FBF 설계 시 하나의 FBF의 결과 개체가 다음 단계 FBF의 소스 개체가 되어 각각의 FBF가 연결되도록 설계함으로써, VFB 설계 시에도 각 단계를 이전 단계를 기반으로 설계할 수 있다.

또한, FBF 결정 시 기능 요구사항에 대한 식별자 및 각 피처에 대한 식별자(피처 ID)를 설정함으로써, 정형화된 설계 절차 및 식별자를 기초로 VFB 컴포넌트에 대한 기능 요구사항 등의 추적을 용이하게 할 수 있다. 예를 들어, 도 8의 Car_Light_Act Component는 FBF 중[표 4]의 FBF-004 및 FBF-005와 관련이 있으며, 따라서 기능 요구사항 FR-001과 관련이 있음을 알 수 있다.

도 9는 일 실시예에 따른 VFB 설계 장치의 구성을 도시한 블록도이다.

도 9을 참고하면, VFB 설계 장치(900)는 프로세서(910)를 포함하고, 추가적으로 메모리(920)를 포함할 수도 있다. 프로세서(910)는 기능 요구사항 식별부(912), 시스템 모델 생성부(914), FBF 분석부(916), 및 VFB 설계부(918)를 포함한다.

도 9에 도시된 VFB 설계 장치(900)에는 본 실시예와 관련된 구성요소들만이 도시되어 있다. 따라서, 도 9에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 VFB 설계 장치(900)에 더 포함될 수 있음을 본 실시예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.

프로세서(910)는 VFB 설계 장치(900)의 전반적인 기능 및 동작을 제어하는 하드웨어로서, 메모리(920)에 저장된 다양한 명령어들, 애플리케이션들 등을 실행하여 본 개시의 다양한 실시예에 따른 VFB 설계 방법을 수행할 수 있다. 프로세서(910)는 VFB 설계 장치(900) 내에 구비된 CPU(central processing unit), GPU(graphics processing unit), AP(application processor) 등으로 구현될 수 있으나, 이에 제한되지 않는다.

메모리(920)는 VFB 설계 장치(900) 내에서 처리되는 각종 데이터들을 저장하는 하드웨어로서, VFB 설계 장치(900)에서 VFB 설계를 위해 처리된 데이터들 및 처리될 데이터들을 저장할 수 있다. 메모리(920)는 DRAM(dynamic random access memory), SRAM(static random access memory) 등과 같은 RAM(random access memory), ROM(read-only memory), EEPROM(electrically erasable programmable read-only memory), CD-ROM, 블루레이 또는 다른 광학 디스크 스토리지, HDD(hard disk drive), SSD(solid state drive), 또는 플래시 메모리를 포함할 수 있다.

기능 요구사항 식별부(912)는, 차량의 동작과 관련된 기능에 대한 기능 요구사항을 식별한다.

시스템 모델 생성부(914)는, 기능 요구사항과 차량의 하드웨어에 기초하여, 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 구성된 시스템 모델을 생성한다.

FBF 분석부(916)는, 기능 요구사항 및 시스템 모델에 기초하여, 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정한다.

VFB 설계부(918)는, 시스템 모델에 포함된 각 카테고리 별 결정된 FBF에 기초하여 AUTOSAR의 VFB를 설계한다.

일부 실시예에 따르면, 프로세서(910)는 차량의 컨트롤러 내부의 소프트웨어 모듈 중 출력 요소를 가지는 개체 또는 차량의 센서 중 적어도 하나를 소스 개체로 분류하고, 컨트롤러 내부의 소프트웨어 모듈 중 입력 요소를 가지는 개체 또는 차량의 작동기 중 적어도 하나를 결과 개체로 분류하고, 기능 요구사항에 기초하여 소스 개체 및 결과 개체 간의 연결 관계를 액션으로 결정하고, 소스 개체, 결과 개체, 및 액션의 매핑을 FBF로 결정함으로써, 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정할 수 있다.

일부 실시예에 따르면, 프로세서(910)는 각 카테고리 별로 적어도 하나의 FBF를 매핑하여 FBF 워크시트(Worksheet)를 생성하고, FBF 워크시트에 기초하여 VFB에서 센서 컴포넌트, 어플리케이션 컴포넌트, 및 작동기 컴포넌트를 결정하고, 컴포넌트들의 연결관계를 결정함으로써 AUTOSAR의 VFB를 설계할 수 있다.

일부 실시예에 따르면, 프로세서(910)는 AUTOSAR의 센서-작동기 패턴에 기초하여 컴포넌트들의 연결에 이용되는 인터페이스를 결정함으로써 AUTOSAR의 VFB를 설계할 수 있다.

개시된 실시예에 따른 장치의 동작방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 전술한 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 전술한 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 전술한 컴퓨터 판독 가능 매체는 컴퓨터 프로그램 제품에 포함될 수 있다.

컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.

개시된 실시예는 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다.　 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어 또는/및 소프트웨어 구성들로 구현될 수 있다.　 예를 들어, 개시된 실시예는 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직(logic), 룩업 테이블(look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다.　 개시된 실시예의 구성 요소들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 개시된 실시예는 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바(Java), 어셈블러(assembler) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다.　 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다.　 또한, 개시된 실시예는 전자적인 환경 설정, 신호 처리, 및/또는 데이터 처리 등을 위하여 종래 기술을 채용할 수 있다.

한편, 개시된 실시예와 관련된 기술 분야에서 통상의 지식을 가진 자는 상기된 기재의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 방법들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

Claims (5)

1. AUTOSAR(AUTomotive Open System ARchitecture)의 VFB(Virtual Function Bus)를 설계하는 장치에 의해 수행되는, AUTOSAR의 VFB를 설계하는 방법에 있어서,
   상기 장치에 포함된 기능 요구사항 식별부를 제어하여, 차량의 동작과 관련된 기능에 대한 기능 요구사항을 식별하는 단계;
   상기 장치에 포함된 기능 시스템 모델 생성부를 제어하여, 상기 기능 요구사항과 상기 차량의 하드웨어에 기초하여, 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 구성된 시스템 모델을 생성하는 단계;
   상기 장치에 포함된 기능 블록 피처(FBF: Function Block Feature, 이하 FBF) 분석부를 제어하여, 상기 기능 요구사항 및 상기 시스템 모델에 기초하여, 상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정하는 단계; 및
   상기 장치에 포함된 설계부를 제어하여, 상기 시스템 모델에 포함된 각 카테고리 별 상기 결정된 FBF에 기초하여 AUTOSAR의 VFB를 설계하는 단계를 포함하고,
   상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정하는 단계는,
   상기 차량의 컨트롤러 내부의 소프트웨어 모듈 중 출력 요소를 가지는 개체 또는 상기 차량의 센서 중 적어도 하나를 소스 개체로 분류하고,
   상기 컨트롤러 내부의 소프트웨어 모듈 중 입력 요소를 가지는 개체 또는 상기 차량의 작동기 중 적어도 하나를 결과 개체로 분류하고,
   상기 기능 요구사항에 기초하여 상기 소스 개체 및 상기 결과 개체 간의 연결 관계를 액션으로 결정하고,
   상기 소스 개체, 상기 결과 개체, 및 상기 액션의 매핑을 상기 FBF로 결정하는 단계를 포함하는, 방법.
2. 삭제
3. 제1항에 있어서,
   상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 FBF를 결정하는 단계는,
   상기 각 카테고리 별로 상기 적어도 하나의 FBF를 매핑하여 FBF 워크시트(Worksheet)를 생성하는 단계를 포함하고,
   상기 AUTOSAR의 VFB를 설계하는 단계는,
   상기 FBF 워크시트에 기초하여 상기 VFB에서 센서 컴포넌트, 어플리케이션 컴포넌트, 및 작동기 컴포넌트를 결정하고, 상기 컴포넌트들의 연결관계를 결정하는 단계를 포함하는, 방법.
4. 제3항에 있어서,
   상기 AUTOSAR의 VFB를 설계하는 단계는,
   AUTOSAR의 센서-작동기 패턴에 기초하여, 상기 컴포넌트들의 연결에 이용되는 인터페이스를 결정하는 단계를 더 포함하는, 방법.
5. AUTOSAR(AUTomotive Open System ARchitecture)의 VFB(Virtual Function Bus)를 설계하는 장치에 있어서,
   차량의 동작과 관련된 기능에 대한 기능 요구사항을 식별하는 기능 요구사항 식별부;
   상기 기능 요구사항과 상기 차량의 하드웨어에 기초하여, 센서 카테고리, 컨트롤러 카테고리, 및 작동기 카테고리로 구성된 시스템 모델을 생성하는 시스템 모델 생성부;
   상기 기능 요구사항 및 상기 시스템 모델에 기초하여, 상기 시스템 모델에 포함된 각 카테고리에 포함되는 적어도 하나의 기능 블록 피처(FBF: Function Block Feature, 이하 FBF)를 결정하는 FBF 분석부; 및
   상기 시스템 모델에 포함된 각 카테고리 별 상기 결정된 FBF에 기초하여 AUTOSAR의 VFB를 설계하는 설계부를 포함하고,
   상기 FBF 분석부는,
   상기 차량의 컨트롤러 내부의 소프트웨어 모듈 중 출력 요소를 가지는 개체 또는 상기 차량의 센서 중 적어도 하나를 소스 개체로 분류하고,
   상기 컨트롤러 내부의 소프트웨어 모듈 중 입력 요소를 가지는 개체 또는 상기 차량의 작동기 중 적어도 하나를 결과 개체로 분류하고,
   상기 기능 요구사항에 기초하여 상기 소스 개체 및 상기 결과 개체 간의 연결 관계를 액션으로 결정하고,
   상기 소스 개체, 상기 결과 개체, 및 상기 액션의 매핑을 상기 FBF로 결정하는, 장치.

Images