SOA Migration of Legacy Applications for SDV
소프트웨어 정의 자동차 위한 기존 애플리케이션의 SOA 마이그레이션
2024년 01월호 지면기사  / 글 | 슈웨타 바드라바시 파틸(Shwetha Bhadravathi Patil) 시니어 프로덕트 매니저 / 누쿨 세갈(Nukul Sehgal) 시니어 애플리케이션 엔지니어, 매스웍스



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

글 | 슈웨타 바드라바시 파틸(Shwetha Bhadravathi Patil) 시니어 프로덕트 매니저
      누쿨 세갈(Nukul Sehgal) 시니어 애플리케이션 엔지니어, 매스웍스







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

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



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

레거시 애플리케이션에서 SOA로 이전하는 것은 다음과 같은 레거시 애플리케이션의 속성들로 인해 까다로울 수 있다. 

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



컴포넌트가 밀접히 결합된 모놀리식 설계



- 실행 순서: 통상적으로 레거시 애플리케이션은 컴포넌트에 대해 미리 정의된 실행 순서를 갖는다. 순차적 실행 특성으로 인해 애플리케이션을 런타임에 동적으로 발견하고, 재구성이 가능한 독립적인 서비스로 변환하는 것이 까다로울 수 있다. 

- 신호 및 시간 기반 통신: 레거시 애플리케이션은 컴포넌트 간 신호 기반 통신 또는 시간 기반 통신에 의존하는 경우가 많다. SOA에서 통신은 일반적으로 서비스 인터페이스와 메시지 교환을 기반으로 한다. 레거시 애플리케이션에서 서비스 지향 접근법으로 통신 메커니즘을 조정하기 위해서는 신중한 고려가 필요하며 통신 프로토콜을 다시 설계해야 할 수 있다. 

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

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

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



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

기존 애플리케이션 소프트웨어 컴포지션을 SOA 애플리케이션을 위한 서비스로 분해하려면 일체형 아키텍처를 더 작고 모듈화된 컴포넌트로 분해해야 한다. 이를 통해 SDV의 맥락에서 유연성, 확장성, 적응성을 향상할 수 있다. 
기존 애플리케이션 소프트웨어 컴포지션을 SOA 애플리케이션을 위한 서비스로 분해하는 과정은 다음의 네 단계를 거친다. 


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


- 서비스 파악 및 분석: SOA를 구성하는 서비스, 컴포넌트, 기능, 실행 순서, 종속성을 파악하는 단계로, 엔지니어에게 가장 어려운 단계이다. 이 단계를 완료하면 엔지니어는 기존의 일체형 애플리케이션을 더 작은 컴포넌트로 분해하기 위해 서비스를 분석해야 한다. 






소프트웨어 컴포넌트를 서비스로 분해



- 서비스 및 인터페이스 정의: 서비스를 파악한 후에는 서비스 간 인터페이스를 정의하는 것이 중요하다. 이 단계에는 서비스 간 통신에 사용되는 프로토콜 및 데이터 형식을 지정하고 서비스 간 상호 작용의 조건 및 상태를 지정하는 서비스 계약의 정의를 수반한다.

- 서비스 계약 정의: 이 단계에서는 서비스 간 상호 작용에 대한 조건 및 상태를 지정한다. 이러한 개념은 서비스의 버전 관리를 지정하는 AUTOSAR의 22-11 스키마에 도입되었으며, 이를 통해 기존 클라이언트를 중단시키지 않고도 서비스의 새로운 버전을 출시할 수 있다.

- 서비스 구현 및 배포: 서비스를 구현하고 이를 인터페이스 설명을 포함한 자체 아티팩트가 있는 독립 실행형 애플리케이션으로 배포하는 단계이다.



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

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

모델 기반 설계를 통해 일체형 애플리케이션 컴포넌트를 서비스로 분해하는 단계는 다음과 같다.

- 서비스 파악 및 분석: 다양한 컴포넌트, 해당 기능, 실행 순서, 컴포넌트 간 종속성을 이해하는 단계이다. 일체형 애플리케이션에서 모든 컴포넌트는 단일 실행 파일로 함께 배포되지만, 서비스 단위로 분해하면 각 개별 서비스는 독립적으로 배포된다.



모든 시뮬링크(Simulink) 모델은 단일 실행 파일로 배포된다.


 
예를 들어, 위 그림의 시뮬링크에서 개발된 고속도로 차선 추종 애플리케이션은 일체형 애플리케이션 컴포지션으로 배포된다. 시뮬링크를 활용해 일체형 컴포넌트를 서비스로 분해하기 위해서는 단일 책임 원칙 및 의존성 역전 원칙이 적용된다. 이러한 원칙을 통해 고속도로 차선 추종 모델은 레이다, 비전, 차선 등의 여러 서비스로 분해된다. 해당 서비스는 책임이 잘 정의되어 있고 종속성이 느슨하게 결합되어 있으므로 한 서비스를 변경 시 다른 서비스에 미치는 영향이 최소화되며 이를 격리하는 것이 가능하다.


모델 기반 설계로 모놀리식 레거시 애플리케이션을 서비스 단위로 분해
 


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




시뮬링크에서 서비스 컴포넌트의 서비스 인터페이스 및 포트 구성 



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

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


시뮬링크에서 SOA 서비스에 대한 알고리즘 구현   


 
또한, Embedded Coder를 사용해 일반 SOA 애플리케이션에 대한 C++ 코드를 생성할 수 있다.



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

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


 
AUTOSAR Adaptive 애플리케이션을 위한 C++ 코드의 설계, 개발 및 생성 



예를 들어, 모델의 루트 레벨에서 시뮬링크 함수(Simulink Function) 블록을 사용하여 어댑티브 메서드 서비스 인터페이스를 생성하는 시뮬링크 모델에 연결된 레이다 서비스에서 AUTOSAR 서비스 인터페이스의 메서드는 인터페이스를 제공하는 서버로 모델링된 소프트웨어 컴포넌트와 인터페이스를 필요로 하는 클라이언트로 모델링된 다른 소프트웨어 컴포넌트 간의 상호 작용을 정의한다.

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

레이다 서비스는 클라이언트-서버 통신을 사용하는 서버이다. 위 그림의 코드 매핑 UI는 시뮬링크 함수 블록 과 함수 요소(Function Element) 포트인 radarCtrl.Adjust 및 radarCtrl.Calibrate를 각각의 어댑티브 포트에 매핑한 것을 보여준다. 

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



속성을 보고 편집할 수 있는 AUTOSAR 사전



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



 LaneGuidanceApp 서비스의 AUTOSAR 속성에 매핑된 시뮬링크 모델 



마찬가지로, 기타 모든 SOA 서비스는 시뮬링크에서 AUTOSAR Adaptive 개념에 따라 구성된다. 
검증 및 시뮬레이션 이후, 각 AUTOSAR Adaptive 서비스는 C++ 코드 및 머신, 실행, ServiceInstanceManifest 파일, AUTOSAR 인터페이스 설명 등이 포함된 자체 아티팩트를 사용해 독립 실행형 애플리케이션으로 배포 가능하다. 마지막으로, 워크플로에서 추가적인 통합을 위해 Embedded Coder를 사용해 AUTOSAR 어댑티브 C++ 코드와 이에 대응하는 소프트웨어 설명 및 매니페스트 파일을 생성할 수 있다. 


 
AUTOSAR Adaptive 애플리케이션에 대한 C++ 코드 인터페이스 파일 생성



결론 및 향후 작업     

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



AEM_Automotive Electronics Magazine


<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>

PDF 원문보기

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)

  • 100자평 쓰기
  • 로그인


  • 세미나/교육/전시

TOP