차량용 소프트웨어 개발 환경 2부

이 글에서는 차량용 IVI 소프트웨어 개발 환경에 대해서 이야기하고자 한다. 

 

ELCE 2019에 필자가 제출했고 리젝되었던 제목과 초록은 아래와 같다.

 

Software development process with CI/CD in embedded linux using Yocto Project

 

Yocto Project uses lots of embedded linux products such as consumer electronics, automotive industries, and others. The software development process is different depended on company. According to the process, speed and product quality is decided.

 

I have experienced for consumer electronic, automotive industry, and opensources. In this presentation, I introduce development process in different area with CI/CD.

 

I briefly introduce Yocto Project first and then explain each different development processes with pros and cons in opensource (Yocto, AGL, GENIVI) and embedded linux product (Consumer electronic and automotive Industry) using Yocto Project. After that, I introduce infrastructure for source code management (Gerri, GitHub, gitlab) and CI/CD tool (Jenkins) and how to connect and use between those infrastructures. Finally I compare the development processes.

 

In summary, I introduce and compare software development process with CI/CD opensources and products using yocto project.

 

개요

소프트웨어 개발 프로세스, 개발 환경이라고 하면 포함하는 범위가 상당히 넓다. 시작점을 요구사항 수집부터 관리 그리고 최종 릴리스까지 모든 개발자가 이 내용을 알면 좋지만 이 글에서는 실제 개발자 입장에서 소프트웨어 코드 구현을 해서 리뷰를 받고 공식적인 빌드에 반영이 되는 과정까지만 간단히 소개해 보고자 한다.

 

다른 임베디드 제품과 차량용 임베디드 소프트웨어라고 크게 다르진 않을 것으로 본다. 하지만 1부에서도 설명했듯이 차량용 임베디드 소프트웨어는 여러개의 SoC가 서로 맞물려 돌아가기 때문에 다른 OS의 구현 사항도 고려를 해야한다.

개발 환경

개발 Issue/Bug 관리, 개발 코드 형상관리, CI/CD 도구, Test Automation 등을 관리하는 도구를 간단히 소개하고 시작한다.

Issue/Bug/wiki tracker

제품으로는 Atlassian의 Jira와 Confluence 가 가장 많이 사용되고 있는 것으로 보이고 Perforce의 솔루션이나 작은 프로젝트에서는 오픈 소스로 github, gitlab에 있는 Issue/wiki 또는 오픈소스 bugtracker 등이 있다. 참고로 Atlassian 은 오픈소스 프로젝트에 한해 무료로 Cloud Jira를 제공하기도 한다.

Source Code Management

SVN이나 perforce와 같은 관리도구를 사용하는 곳도 많지만 Git이 대세로 보인다. Gerrit, Github, Gitlab 등을 많이 사용하고 Atlassian 의 Jira등의 도구와 연동성이 좋아서 bitbucket을 사용하는 곳도 있다.

Build

개발 효율성에 가장 중요한 것중 하나이지만, 대부분 SoC Vendor 에서 주는 그대로 사용하는 경우가 상당히 많다. 대부분의 이유는 전문가가 없어서, 원하는대로 수정하려면 시간과 노력이 많이 들고 side effect가 생길 경우가 두려워서, 그리고 다음 릴리스를 받아 쉽게 적용하기 위해 대부분 SoC Vendor과 같은 환경을 유지하고자 한다. 하지만 요구하는 환경을 명확히 하고 이를 요청하는 경우도 있다.

 

임베디드 리눅스의 경우 대부분 Yocto를 사용하지만 QNX나 다른 OS들은 각기 다른 빌드 시스템(Make, CMake 등등)을 사용한다.

CI/CD

Jenkins가 가장 많이 사용되고 go.cd 및 gitlab과 github에서 제공하는 도구를 사용하기도 한다. 필자도 Jenkins 와 go.cd 밖에 사용한 경험이 없지만 정말 유용한 도구이고, 최종 결과물을 저장하는 파일 서버에는 artifactory 를 사용하기도 한다.

Test Automation

주로 자체 개발 플랫폼 기반에 테스트 스크립트를 많이 사용하지만 오픈 소스를 가져다 사용하는 경우도 많다. Test Framework를 만들고 이를 기반으로 하나씩 TC를 자동화해야 한다. 하지만 차량용 전체 개발 환경을 꾸미는 것은 정말 복잡하고, 장비가 많이 필요해 실제 HW를 가지고 여러대로 Test Farm을 구성하기란 정말 어렵다. 개발자를 위한 개발 Test Bench도 Full로 구성하기 어렵기 때문이다.

개발 프로세스

위의 Source Code Management 도구 및 리뷰하는 방법, 빌드를 구성하는 시스템, CI/CD까지를 하나의 개발 프로세스로 묶어서 각각의 회사에서 서로 다른 방법을 사용하고 있다. 특히 차량용 System Integrator를 하는 곳은 여러 다른 업체들(SoC, 3rd party등)과 일을 하기 때문에 각각의 업체의 룰에 따르기도 하고, Integration 하는 업체의 방법을 가이드해 진행하기도 한다.

 

필자가 생각하는 가장 이상적인 방법론은 하나의 공간에서 모든 소스를 함께 오픈해놓고 개발하는 것이지만 정치적 이슈 및 지적재산권등에 따라 어려운 것이 현실이다.

 

위에서 언급한 모든것을 가지고 CI/CD를 구성한다. 다양한 방법이 있고 개발,릴리스등 정말 생각할게 많고 복잡하다. 특히나 자동차 소프트웨어 개발(여기서는 Incrument Cluster 와 Infortainment 부분에 한정해서 설명한다.)에서는 더더욱이 그렇다.

 

다음 차량용 소프트웨어 개발 환경 3부에서는 이 개발 프로세스부터 CI/CD까지 내용을 이야기할 예정이다.

Reference

• https://www.bmw-carit.com/downloads/presentations/2018_Bulwahn_BMWs-Journey-With-the-Open-Source-Ecosystem.pdf
• https://at.projects.genivi.org/wiki/download/attachments/16027368/GENIVI_AMM_2018_Achim_Demelt.pdf?version=1&modificationDate=1524099162000&api=v2
• https://elinux.org/images/d/d4/Goulart.pdf