Infotainment 개발 과정에서 Software Integration Process

아래 글들을 읽어보면 Mercedes-Benz에서 첫 Infotainment In-house Software를 곧 양산한다는 것을 알 수 있을 것이다. 이 글에서는 2-3년동안 필자의 회사에서 어떻게 integration Process가 바뀌었는지 그리고 필자가 알고 있는 프로세스들에 대해서 소개하고자 한다.

CI/CD를 가장한 지속적인 통합

 

CI/CD의 원칙은 완벽하게 자동화된 테스트와 신뢰성 있는 테스트 결과에 기반을 한다. 임베디드 특히 소프트웨어의 복잡도가 엄청 높은 차량용 임베디드 소프트웨어 개발에서 이를 잘 도입하기란 필자의 경험상 어려운 것 같다. 필자의 회사에서도 초기 1-2년정도 이것을 하려고 프로세스만 따랐고 결국은 잘 안되서 Staging이라는 프로세스를 도입했다.

 

임베디드 특히나 복잡한 차량용 임베디드에서는 여러가지 이유로 자동화 테스트를 완벽하게 구현하기 어렵다. 그 이유는 첫번째로 부족한 하드웨어 샘플 수이다. A,B,C,D 샘플로 계속 업데이트 되는데다가 각 샘플의 수량도 자동화하기에는 개발자의 수에 비해 턱없이 부족하다. 자동화 뿐만이겠는가 실제 개발자들에게 할당되는 샘플 개수도 넉넉치 않다. 이전 회사에서 임베디드 TV 개발을 할 때는 1인당 한개 이상의 개발 보드가 주어졌지만 차량용 임베디드는 그렇게 여유가 있지 않다. 다음으로는 샘플 하나에 보드만 3개, 그리고 어떤 보드에는 여러개의 OS가 올라간다. 또한 다른 ECU와의 의존성등이 있어서 자동화 테스트를 구현하기도 어렵다. 또한 Mock이 필요한 경우도 많다.

 

자동화 테스트도 어렵지만 실제 개발팀에서도 위와 같은 이유로 제대로된 하드웨어 테스트를 하기가 어렵다. 최대한 팀당 여러개의 샘플을 제공하려고도 하고 그날 안정된 버전의 이미지를 제공하려 해도 하드웨어 문제, 소프트웨어 문제 등으로 제대로 테스트하지 못하는 경우가 다반사였다.

 

지금은 원격에서 테스트할 수 있는 환경, 개발팀에 할당된 테스트 벤치, 쉽게 플래싱할 수 있는 이미지를 제공하여 상황이 많이 좋아졌지만 여전히 복잡도 때문에 테스트가 힘든 상황이긴 하다. 지속적으로 안정적인 자동화 테스트를 만들고도 있다.

Staging 후 통합

위의 그림과 완전히 일치하지는 않지만 약간 비슷하여 가지고 와봤다.

 

작년 말부터 수정사항을 최종 통합하기 전에 모아서 여러 가지 테스트를 진행한다. 개발팀들은 당연히 자기들의 수정사항을 직접 테스트 벤치에서 실행하여 그 결과를 첨부하기도 하지만 최종 통합이전에 통합 대상 수정사항을 모아서 테스트 팀에서 차량에 이미지를 플래싱한다. 그리고 일부 테스트 케이스는 직접 테스트를 하여 결과를 내고 일부는 개발팀을 원격으로라도 초대하여 직접 테스트를 할 수 있도록 제공한다.

 

그리고 통합 전 테스트 결과를 기반으로 PM이 수정사항이 들어갈지 말지에 대한 결정을 하고 최종 Integrator가 통합을 한다. 아주 간단히만 설명을 했는데 개발팀 입장에서는 여러 복잡한 과정들이 들어가 있다.

 

Yocto 기반 리눅스를 개발 및 통합 프로세스만 설명하는 것도 쉽게 할 수 없을 정도이니.. 참 어렵다. 여러가지 이유가 있긴 하다. Security 관련된 MAC 기반 제어 Configuration 리뷰, sysemd service 리뷰, 테스트 결과 리뷰, Yocto 레시피 리뷰 등 개발팀이 Yocto recipe 수정사항을 보내면 경우에 따라서 4개 이상의 팀의 리뷰를 받아야 한다. 필자의 회사는 gitlab을 사용하는데 label로 이런 리뷰 및 현재 Integration status를 관리한다.

What's next?

Staging을 Domain 별로 만들어 통합하려는 시도를 할까 하고 있다. ASPICE에 보면 components, SW Elements 개념이 있고 이를 내부적으로 정리하여 SW Elements 별로 Integrator와 Tester를 둘까도 생각중이다.

ASPICE V MODEL

 

여기에는 우선 아키텍처 적으로 플랫폼 정의, Components 정의, SW Elements의 정의를 한 후 도메인 팀 조직 개편, Integrator, Tester 등등 많은 이슈를 풀어내야 한다. 그리고 이게 지금보다 더 좋을지도 봐야할 것 같다.

 

지금보다 앞으로는 Variant가 훨씬 더 많아질텐데 이런 고려도 해야하고.. 참 할 것도, 갈길도 멀다. 어려운 문제를 다같이 하나씩 풀어나는데 참 재밌고 어렵고 기대된다.