이 페이지는 기계 번역되었습니다.
번역 품질에 대한 1분 설문 조사에 참여해 주세요.
MathWorks 인사이트
저자:
"우리는 MATLAB, Simulink, System Composer 및 Embedded Coder를 활용한 모델 기반 설계를 바탕으로 워크플로를 개선하고 확장하고 있습니다." 이 워크플로는 개발을 가속화하고 직접 코드 작성에 따르는 어려움을 최소화함으로써 이미 그 가치를 입증했습니다.
자동차 산업은 차량이 기존의 기계 시스템에서 SDV(소프트웨어 정의 차량)으로 진화함에 따라 근본적인 변화를 겪고 있습니다. 이러한 변화는 소프트웨어 개발에 대한 새로운 접근 방식을 요구하며, 유연하고 확장 가능한 자동차 애플리케이션 설계를 위한 선호 패러다임으로 SOA(서비스 지향 아키텍처)가 부상하고 있습니다. ZEEKR에서는 차량용 운영 체제에서 실행되는 SOA 애플리케이션 개발을 위해 모델 기반 설계를 바탕으로 한 포괄적인 워크플로를 구축함으로써 이러한 변화를 적극적으로 수용했습니다.
모델 기반 설계를 사용한 기존의 자동차 소프트웨어 개발은 주로 AUTOSAR® Classic Platform 구현에 집중해왔으며, 이 환경에서는 SW-C(소프트웨어 컴포넌트)는 표준화된 RTE(런타임 환경) 인터페이스를 통해 상호작용합니다. 하지만 SOA는 클라이언트-서버 호출 및 메시지 기반 상호작용과 같은 새로운 통신 패턴을 도입하므로 기존 개발 방식에 상당한 조정이 필요합니다. 과제는 이러한 새로운 통신 패턴을 모델링하는 것뿐만 아니라 AUTOSAR 표준을 따르지 않는 환경에서 소프트웨어 아키텍처의 복잡성 증가를 관리하는 데에도 있습니다.
ZEEKR의 우리 그룹은 SOA 애플리케이션 개발을 위한 모델 기반 설계 워크플로를 통해 이러한 과제들을 대응해 왔습니다. 이 칼럼에서는 이 워크플로의 세 가지 핵심 영역에 대해 다룹니다.
우리의 경험은 엔지니어들이 모델 기반 설계를 활용해 기존 임베디드 시스템에서 최신 SOA 기반 소프트웨어 아키텍처로의 전환을 가속화할 수 있는 방법을 보여줍니다.
SOA는 기존 임베디드 시스템과는 근본적으로 다른 새로운 통신 패턴을 도입합니다. Classic AUTOSAR 애플리케이션은 간단한 RTE 인터페이스를 통해 통신하며, 이를 통해 소프트웨어 컴포넌트 간에 긴밀하게 연결되고 정적으로 정의된 상호작용이 가능합니다. 반면, 원격 프로시저 호출 및 메시지 기반 상호작용과 같은 SOA 통신 패턴은 더욱 유연하고 정교합니다. 또한 하드웨어와 소프트웨어의 분리는 물론 소프트웨어 계층적 설계도 가능하게 합니다. 이러한 패턴을 최대한 활용하기 위해, 우리는 Simulink에서 SOA 애플리케이션을 모델링하고, Embedded Coder®로 C++ 코드를 생성하며, 우리가 개발한 래퍼 생성기로 미들웨어 통합 코드를 생성하고, 애플리케이션 코드와 통합 코드를 배포 가능한 애플리케이션 패키지로 병합하는 모델 기반 설계에 기반한 개발 워크플로를 따릅니다. 이 자동화된 워크플로에서는 직접 C++ 코드를 작성할 필요가 없습니다. 자동으로 생성된 래퍼 코드는 Simulink 모델에서 생성한 애플리케이션 코드와 런타임 환경인 ZEEKR ARK OS를 잇는 가교 역할을 합니다.
우리 워크플로에서 일반적인 SOA 모델은 서비스 제공자와 클라이언트를 포함하며, 둘 다 Simulink에서 모델링됩니다. (그림 1) 이 구조는 SOA의 핵심 동작을 포착합니다. 즉, 서비스 호출의 분리, 명시적 메시지 교환, 그리고 통신과 연산 간의 명확한 분리를 특징으로 합니다. 이를 통해 Simulink 내에서 SOA 개념을 명확하게 표현하고 분산된 서비스 기반 환경에 배포할 수 있도록 모델을 준비할 수 있습니다.
그림 1. Simulink에서 모델링된 간단한 클라이언트 및 서버. 클라이언트는 제어 신호("Step")에 의해 주기적으로 트리거되는 Receiver 블록과 Sender 블록을 포함합니다.
우리의 배포 시나리오는 중앙 집중식 연산 환경과 분산 연산 환경 모두를 포괄합니다. (그림 2) Simulink에서 모델링된 서비스 지향 애플리케이션은 고성능 중앙 연산 장치에서 실행됩니다. 한편, Simulink에서 개발된 Classic AUTOSAR 컴포넌트는 마이크로컨트롤러에서 실행되며 차량 액추에이터와 직접 연동됩니다. 이러한 혼합 배포 방식은 도메인 컨트롤러가 고수준 처리를 관리하고 에지 노드가 하위 제어를 처리하는 중앙 집중식 도메인 아키텍처로 가는 광범위한 추세를 반영합니다. Simulink를 사용하면 통합 개발 환경을 활용해 이종 자동차 시스템의 모델링, 시뮬레이션 및 코드 생성을 수행함으로써 이러한 아키텍처의 두 가지 측면을 모두 지원할 수 있습니다.
그림 2. Simulink에서 개발된 실제 공조 애플리케이션은 중앙 처리 장치 노드에 배포된 SOA 소프트웨어와 마이크로컨트롤러에서 실행되는 AUTOSAR Classic SW-C를 결합해 액추에이터를 구동합니다.
서비스 지향 애플리케이션의 범위와 복잡성이 증가함에 따라, 그 구조를 관리하는 것이 매우 중요한 과제가 됩니다. 여러 소프트웨어 단위에 걸쳐 여러 서비스가 상호작용함에 따라 각 모델을 개별적으로 처리하는 것은 더 이상 충분하지 않습니다. 대신, 소프트웨어 컴포넌트들이 서로 어떻게 연관되는지, 즉 어떻게 그룹화되고, 어떻게 통신하며, 어디에 배포되는지를 명확하게 보여주는 아키텍처 표현이 필요합니다. AUTOSAR 작성 툴을 비롯한 시중에 나와 있는 많은 자동차 소프트웨어 아키텍처 툴은 AUTOSAR 기반 환경을 가정하고 있으며, 사용자 정의 운영 체제에 서비스 기반 통신 모델을 배포하는 유연성을 지원하지 않습니다. SOA 프레임워크와 차량용 OS의 요구사항을 충족하기 위해 우리는 자체 아키텍처 모델링 환경을 구축했습니다. SOA 모델 컴포저, 즉 SOMOC는 System Composer의 모델 기반 시스템 공학 기능과 아키텍처 설계 요소, 그리고 MATLAB®의 객체 지향 프로그래밍 기능을 기반으로 구축되었습니다. 사용 편의성을 위해 MATLAB 및 앱 디자이너로 사용자 지정 사용자 인터페이스를 제작했습니다. (그림 3)
그림 3. SOMOC 사용자 인터페이스는 아키텍처 트리 뷰(왼쪽)와 컴포넌트 컴포저 인터페이스(오른쪽)를 포함합니다.
SOMOC은 시스템 아키텍처, 프로세스, 소프트웨어 컴포넌트 및 서비스 정의라는 네 가지 주요 수준에 걸쳐 SOA를 정의하고 관리하는 구조화된 접근 방식을 지원합니다. (그림 4) 이 계층적 구성은 System Composer의 참조 컴포넌트 기능을 활용해 상위 시스템에서 개별 서비스에 이르기까지 명확한 추적성을 확립합니다.
그림 4. 아키텍처, 프로세스, SW-C 및 서비스 수준을 보여주는 SOMOC의 컴포넌트 계층 구조.
SOMOC은 서비스 식별자, 네임스페이스, 버전 정보와 같은 SOA 관련 메타데이터를 캡처하는 사용자 지정 프로필 및 스테레오타입을 통해 아키텍처 모델을 확장합니다. ZEEKR의 시스템 설계자는 SOMOC를 사용하여 시스템 설계 중에 생성된 ARXML 파일에서 가져온 기능 요구사항을 프로세스 경계, 서비스 인터페이스 및 소프트웨어 컴포넌트를 정의함으로써 배포 가능한 아키텍처로 변환합니다. 이러한 아키텍처 모델로부터 SOMOC는 일관된 인터페이스를 갖춘 셸 Simulink 모델을 자동으로 생성하여 개발자에게 내부 동작이나 논리를 구현하기 위한 신뢰할 수 있는 시작점을 제공합니다. (그림 5) 이 자동화 시스템은 아키텍처에서 구현에 이르는 워크플로를 표준화하고, 인터페이스를 동기화하며, 개발 전반에 걸쳐 팀에게 공통된 참조점을 제공합니다.
그림 5. SOMOC 프레임워크 내에서 다양한 계층이 설계 및 테스트되고 있습니다.
ZEEKR에서는 모델 수준 테스트와 코드 수준 테스트를 결합하여 서비스 지향 애플리케이션을 검증합니다. Simulink Test ™를 사용해 Simulink에서 단위 및 모델 테스트로 시작하고 테스트 하네스를 사용하여 개별 컴포넌트를 분리하고 서비스 상호 작용을 검증합니다. (그림 6) 각 모델에 대해 엔지니어는 소비자 모델의 경우 시뮬레이션된 공급자와 같은 대응 컴포넌트와의 통신을 시뮬레이션하고 예상되는 응답 및 인터페이스 동작을 검증할 수 있습니다. 이러한 초기 단계 검증은 코드가 생성되기 전에 논리 오류나 인터페이스 불일치를 식별하는 데 도움이 됩니다.
그림 6. 테스트 시퀀스 편집기에 표시된 테스트 하네스의 테스트 시퀀스입니다.
애플리케이션 코드를 생성하고 차량용 OS에 통합한 후, Visual Studio Code 내의 경량 플러그인인 SVT(서비스 검증 툴킷)를 사용해 런타임 테스트를 수행합니다. (그림 7) SVT를 사용하면 팀에서 ARXML 파일에서 서비스 인터페이스 정의를 가져온 다음 애플리케이션 수준에서 서비스 통신을 시뮬레이션하여 메서드 및 토픽 인터페이스를 모두 테스트할 수 있습니다. 이는 소비자 또는 공급자 역할을 할 수 있으며, 메서드 요청을 보내거나, 응답을 처리하거나, 토픽 데이터를 게시하거나, 메시지를 구독할 수 있습니다. SVT는 서비스 인터페이스 간에 교환되는 값을 표시하여 엔지니어가 배포된 애플리케이션이 다양한 상호 작용 시나리오에서 올바르게 작동하는지 확인할 수 있도록 지원합니다.
그림 7. Visual Studio Code의 SVT 플러그인.
차량용 배포를 위한 새로운 서비스 지향 애플리케이션을 지속적으로 개발하는 동시에 MATLAB, Simulink, System Composer 및 Embedded Coder를 활용한 모델 기반 설계 워크플로를 개선하고 확장하고 있습니다. 이 워크플로는 개발을 가속화하고 코드를 직접 작성하는 데 따르는 어려움을 최소화함으로써 이미 그 가치를 입증했습니다. 하나의 환경에서 서비스 지향형 및 AUTOSAR 기반 애플리케이션의 아키텍처 모델링, 서비스 모델링, 시뮬레이션, 코드 생성 및 테스트를 수행할 수 있는 기능을 통해, 자동차 산업 환경을 지속적으로 변화시키는 SDV 개발을 지원하는 확장 가능한 소프트웨어 기반을 구축했습니다.
2025년 기고
