소프트웨어 정의 차량을 위해 전통적인 자동차 애플리케이션을 SOA로 이전하기

SDV(소프트웨어 정의 차량)의 특징은 AI, 자율성, 연결성 및 전동화라고 요약할 수 있습니다. 최근 자동차 업계는 SDV에 대한 최신 애플리케이션 설계에 있어 '서비스 기반' 접근법을 도입하기 시작했습니다. SOA(서비스 지향 아키텍처)로 불리는 이 접근법은 높은 재사용성, 손쉬운 업데이트, 하드웨어와의 느슨한 결합을 특징으로 하는 소프트웨어 애플리케이션 개발에 대한 새로운 패러다임을 제시합니다. SOA는 런타임 중에 동적으로 발견, 게시, 구독, 재구성될 수 있는 서비스의 모음이 애플리케이션을 구성한다는 원칙에 입각해 정립되었습니다. SOA의 개념은 AUTOSAR(AUTomotive Open System ARchitecture)를 비롯한 여러 산업 표준에 광범위하게 통합되어 있습니다.

SOA 프레임워크 내에서 서비스는 자립적이고, 모듈화되어 있으며 느슨하게 결합되므로 태생적으로 비모놀리식적인 복잡하고 분산된 애플리케이션을 구축할 수 있습니다. SOA 기반 애플리케이션은 하향식 또는 상향식 접근법을 사용하여 개발할 수 있습니다. 표준 SOA 소프트웨어 스택에서 애플리케이션 소프트웨어는 서비스, 플랫폼 서비스, 미들웨어로 구성되며, 이들은 모두 고성능 하드웨어 또는 가상 머신에서 실행됩니다.

레거시 애플리케이션에서 SOA로 이전 시 마주하는 난제

레거시 애플리케이션에서 SOA로 이전하는 것은 레거시 애플리케이션의 몇 가지 속성으로 인해 까다로울 수 있습니다. 이러한 속성은 다음과 같습니다.

• 모놀리식 설계: 레거시 애플리케이션은 컴포넌트들이 밀접하게 결합되었으며 상호 연결된 모놀리식 설계(그림 1)를 취하는 경우가 많습니다. 이로 인해 기능이 서로 얽혀 있고 모듈화되지 않아 애플리케이션을 별도의 서비스로 나누기가 어렵습니다.

• 실행 순서: 통상적으로 레거시 애플리케이션은 컴포넌트에 대해 미리 정의된 실행 순서가 있습니다. 이러한 순차적 실행 특성으로 인해 애플리케이션을 런타임에 동적 발견 및 재구성이 가능한 독립적인 서비스로 변환하는 것이 까다로울 수 있습니다.
• 신호 및 시간 기반 통신: 레거시 애플리케이션은 컴포넌트 간 신호 기반 통신 또는 시간 기반 통신에 의존하는 경우가 많습니다. SOA에서 통신은 일반적으로 서비스 인터페이스와 메시지 교환을 기반으로 합니다. 레거시 애플리케이션에서 서비스 지향 접근법으로 통신 메커니즘을 조정하기 위해서는 신중한 고려가 필요하며 통신 프로토콜을 다시 설계해야 할 수도 있습니다.

이러한 난제를 극복하려면 레거시 애플리케이션의 아키텍처를 포괄적으로 분석하고 컴포넌트 간의 서비스 경계와 종속성을 면밀히 파악해야 하는 경우가 많습니다. SOA 프레임워크 내에서 서비스로 캡슐화할 수 있는 더욱 모듈화되고 느슨하게 결합된 단위로 애플리케이션을 리팩터링해야 할 수도 있습니다.

레거시 애플리케이션 구성을 서비스로 변환하는 것은 복잡한 작업입니다. 예를 들어, 고속도로 차선 추종 애플리케이션과 같이 이전에 설계된 모놀리식 애플리케이션 구성은 단일 서비스로 변환하거나 카메라 서비스, 비전 서비스, 레이다, 차선 안내 서비스 등 여러 서비스로 분해할 수 있습니다.

모델 기반 설계 외에 시스템 전문 지식을 갖추고 있다면 모놀리식 애플리케이션 설계로부터 기타 논리적 컴포넌트와는 구별되는 하나의 논리 컴포넌트를 캡슐화하고 추상화하는 서비스 기능으로 분해할 수 있습니다. 이를 통해 신호와 서비스 간 인터페이스의 마이그레이션을 수행하고 올바른 실행 순서를 결정할 수 있습니다. 이 기술 칼럼에서는 새로운 서비스를 모델링하거나 기존 애플리케이션 구성을 SDV를 위한 AUTOSAR Adaptive 개념에 기반한 서비스로 변환하는 모델 기반 설계 워크플로에 대해 다룰 것입니다.

기존 애플리케이션 소프트웨어 구성을 서비스 단위로 분해하기

기존 애플리케이션 소프트웨어 구성을 SOA 애플리케이션을 위한 서비스로 분해하려면 모놀리식 아키텍처를 더 작고 모듈화된 컴포넌트로 분해해야 합니다(그림 2). 이를 통해 SDV의 맥락에서 유연성, 확장성, 적응성을 향상할 수 있습니다.

기존 애플리케이션 소프트웨어 구성을 SOA 애플리케이션을 위한 서비스로 분해하는 과정은 다음 네 단계를 수반합니다.

• 서비스 파악 및 분석: SOA를 구성하는 서비스, 컴포넌트, 기능, 실행 순서, 종속성을 파악하는 단계입니다. 이는 엔지니어에게 가장 어려운 단계입니다. 이 단계를 완료하면 엔지니어는 기존 모놀리식 애플리케이션을 더 작은 컴포넌트로 분해하기 위해 서비스를 분석해야 합니다(그림 3).

• 서비스 및 인터페이스 정의: 서비스를 파악한 후에는 서비스 간 인터페이스를 정의하는 것이 중요합니다. 이 단계에는 서비스 간 통신에 사용되는 프로토콜 및 데이터 형식의 지정과 서비스 간 상호 작용의 조건 및 상태를 지정하는 서비스 계약의 정의를 수반합니다.
• 서비스 계약 정의: 이 단계에서는 서비스 간 상호 작용에 대한 조건 및 상태를 지정합니다. 이러한 개념은 서비스의 버전 관리를 지정하는 AUTOSAR의 22-11 스키마에 도입되었으며, 이를 통해 기존 클라이언트를 중단시키지 않고도 서비스의 새로운 버전을 출시할 수 있습니다.
• 서비스 구현 및 배포: 서비스를 구현하고 이를 인터페이스 설명을 비롯한 이 서비스만의 아티팩트와 함께 독립 실행형 애플리케이션으로 배포하는 단계입니다.

모델 기반 설계를 사용한 서비스로의 마이그레이션

모델 기반 설계는 비 AUTOSAR 및 AUTOSAR Classic 프레임워크를 위한 애플리케이션의 개발에 사용되어 왔습니다. 또한, AUTOSAR Adaptive 및 일반 SOA 프레임워크를 위한 SOA 기반 애플리케이션의 개발에도 사용될 수 있습니다. SDV 애플리케이션의 경우, 업계에서는 일반적으로 일반 SOA 또는 AUTOSAR Adaptive 플랫폼에 기반한 형태를 활용해 왔습니다. 모델 기반 설계는 SOA, AUTOSAR Classic, AUTOSAR Adaptive 등 모든 유형의 플랫폼에서 전체 개발 공정을 효과적으로 처리할 수 있는 통합 개발 플랫폼을 제공함으로써 전반적인 일관성과 효율성을 보장하여 가치가 더 커졌습니다.

모델 기반 설계를 사용하여 모놀리식 애플리케이션 컴포넌트를 서비스로 분해하는 단계는 다음과 같습니다.

• 서비스 파악 및 분석: 다양한 컴포넌트, 해당 기능, 실행 순서, 컴포넌트 간 종속성을 이해하는 단계입니다. 모놀리식 애플리케이션에서 모든 컴포넌트는 단일 실행 파일로 함께 배포됩니다(그림 4). 그러나 서비스 단위로 분해하면 각 개별 서비스가 독립적으로 배포됩니다.

예를 들어, 그림 4에서는 Simulink^®에서 개발된 고속도로 차선 추종 애플리케이션을 볼 수 있는데, 이는 모놀리식 애플리케이션 컴포지션으로 배포됩니다. Simulink를 사용하여 이러한 모놀리식 컴포넌트를 서비스로 분해(그림 5)하려면 단일 책임 원칙 및 의존성 역전 원칙이 사용됩니다. 이러한 원칙을 활용하여 고속도로 차선 추종 모델은 레이다, 비전, 차선 등의 여러 서비스로 분해됩니다. 이러한 서비스는 책임이 잘 정의되어 있고 종속성이 느슨하게 결합되어 있으므로, 한 서비스에 대한 변경이 다른 서비스에 미치는 영향이 최소화되고 이를 격리하는 것이 가능합니다.

그림 5. 모델 기반 설계로 모놀리식 레거시 애플리케이션을 서비스 단위로 분해. (왼쪽) 모놀리식 애플리케이션은 SOA 기반 서비스로 분해되고 이를 클라이언트-서버 포트에 연결됩니다. (오른쪽)

• 서비스 및 인터페이스 정의: 인터페이스를 사용하여 정의된 서비스는 해당 서비스를 통해 다른 서비스와 상호 작용하는 통신 채널의 역할을 수행하는 서비스 경계의 일부입니다. 또한, 서비스 경계는 재사용, 유지관리, 버전 컨트롤, 가시성, 오케스트레이션 및 기타 이점을 달성하기 위한 기능의 캡슐화도 수행합니다. System Composer™를 사용하면 데이터 일관성을 위한 관련 서비스 컴포넌트의 포트를 구성하여 이런 서비스가 스테레오타입과 함께 서로 상호 작용하는 방식을 나타낼 수 있습니다. 이를 통해 서비스 간의 종속성과 상호 작용을 시각적으로 표현할 수 있습니다(그림 6).

그림 6. Simulink에서 서비스 컴포넌트의 서비스 인터페이스 및 포트 구성.

• 서비스 계약 정의: 서비스의 입력, 출력, 동작을 정의하여 서비스의 명확한 경계를 설정하는 것이 좋습니다. 이를 통해 서비스는 아키텍처의 다른 부분과 밀접하게 결합되지 않은 상태에서 독립적으로 개발, 테스트, 배포될 수 있습니다. 서비스 계약을 정의함으로써 서비스의 기능과 한계를 이해하고 더 쉽게 통합할 수 있습니다(그림 7). 또한, 서비스 계약을 사용하면 기존 클라이언트를 중단하지 않고도 서비스의 새 버전을 릴리스할 수도 있습니다.

그림 7. 각 서비스는 입력, 출력 및 이에 대한 애플리케이션 로직으로 모델링됩니다. 이러한 모델은 서비스 간의 상호 작용을 시뮬레이션하고 관찰합니다.

• 구현 및 배포: 모델 기반 설계에서 클라이언트-서버 인터페이스를 사용하여 SOA 소프트웨어 아키텍처 모델을 작성할 수 있습니다. 그림 8은 Simulink에서 서비스로 구현된 LaneGuidanceApp, DetectionApp, 레이다, 비전 알고리즘을 보여줍니다.

또한, Embedded Coder^®를 사용하여 일반 SOA 애플리케이션에 대한 C++ 코드를 생성할 수도 있습니다.

AUTOSAR Adaptive 애플리케이션에 대한 서비스 구성

이러한 서비스는 Simulink 모델링 구문을 사용하여 AUTOSAR Adaptive에 맞춰 매끄럽게 구성할 수 있습니다. 그림 9와 같이 우리는 System Composer 내의 직관적인 AUTOSAR 편집기를 사용하여 AUTOSAR Adaptive 서비스로 작동하도록 모든 서비스를 통합했습니다. 그런 다음 각 포트와 인터페이스에 필요한 매핑을 설정하여 해당 AUTOSAR Adaptive 속성과 일치시켰습니다.

그림 9. AUTOSAR Adaptive 애플리케이션을 위한 C++ 코드의 설계, 개발 및 생성. (왼쪽)
Simulink에서 AUTOSAR Adaptive 애플리케이션에 대한 C++ 코드를 생성하는 방법을 보여주는 비디오. (오른쪽)

예를 들어, 모델의 루트 레벨에서 Simulink Function 블록을 사용하여 Adaptive 메서드 (3:50) 서비스 인터페이스를 생성하는 Simulink 모델에 연결된 레이다 서비스를 살펴보겠습니다. 여기에서는 AUTOSAR 서비스 인터페이스의 메서드가 인터페이스를 제공하는 서버로 모델링된 소프트웨어 컴포넌트와 인터페이스가 필요한 클라이언트로 모델링된 다른 소프트웨어 컴포넌트 간의 상호 작용을 정의합니다.

Simulink에서 클라이언트-서버 통신은 동기식 또는 비동기식 호출 동작으로 모델링할 수 있습니다. 동기식 클라이언트 모델은 차단된 클라이언트 실행을 생성하는데, 이는 클라이언트는 서버에 요청을 전송하고 응답을 대기하는 것입니다. 비동기식 클라이언트 모델은 클라이언트가 전송하는 요청으로 구성된 비차단 실행을 생성하며, 요청이 전송된 후에도 현재 실행을 계속하고 서버로부터 응답이 수신되면 이를 처리합니다.

레이다 서비스는 클라이언트-서버 통신을 사용하는 서버입니다. 그림 9에서 코드 매핑 UI는 Simulink Function 블록 및 Function Element 포트(radarCtrl.Adjust, radarCtrl.Calibrate 및 이에 대응하는 Adaptive 포트)의 매핑을 보여줍니다.

또한, 'Methods' 서비스 인터페이스에 대한 AUTOSAR 사전에서 AUTOSAR 속성을 보고 편집할 수 있습니다. (그림 10)

LaneGuidanceApp 서비스는 클라이언트로 작동하며 비동기식 호출을 통해 클라이언트-서버 통신을 활용합니다(그림 11). 이 예에서의 클라이언트는 비동기식 통신을 사용하며 요청을 서버로 전송한 후에도 계속 실행할 수 있도록 비차단 실행의 이점을 활용합니다. 클라이언트는 Simulink 모델 내에서 Function-Call Subsystem 블록과 Message Triggered Subsystem 블록을 활용하여 비동기적으로 함수 호출을 실행합니다. 코드 매핑 UI는 Simulink 함수 호출자와 해당 AUTOSAR Adaptive 포트의 매핑을 보여줍니다.

마찬가지로, 기타 모든 SOA 서비스는 Simulink에서 AUTOSAR Adaptive 개념에 따라 구성됩니다.

검증 및 시뮬레이션 이후, 각 AUTOSAR Adaptive 서비스는 C++ 코드 및 Machine, Execution, ServiceInstanceManifest 파일이 포함된 AUTOSAR 인터페이스 설명 등의 자체 아티팩트가 포함된 독립 실행형 애플리케이션으로 배포할 수 있습니다. 마지막으로, 워크플로에서 추가적인 통합을 위해 Embedded Coder를 사용하여 AUTOSAR Adaptive C++ 코드와 이에 대응하는 소프트웨어 설명 및 매니페스트 파일이 생성합니다. (그림 12)

결론 및 향후 작업

모델 기반 설계는 시스템 개발에 대한 구조화된 접근법을 제공하여 애플리케이션의 아키텍처, 컴포넌트 및 상호 작용을 나타내는 모델을 생성할 수 있습니다. 이 기술 칼럼에서는 모델 기반 설계를 통해 고속도로 차선 추종 참조 예제 모델을 사용하여 기존 모놀리식 애플리케이션을 서비스로 분해한 후 이를 AUTOSAR Adaptive 애플리케이션으로 구성하는 방법을 다뤘습니다. 이러한 모듈식 서비스는 엔지니어가 워크플로에서의 추가적인 통합을 위해 매니페스트 파일과 함께 C++ 코드를 작성, 시뮬레이션, 생성할 수 있도록 하는 청사진의 일부가 될 수 있습니다.