독일 자동차 소프트웨어 개발자

이틀간의 UI 통합 관련 워크샾을 마치고 돌아왔다. 워크샾 기간 동안 그리고 저녁식사를 같이 하면서 많은 이야기를 나누었다. UI 개발자가 몇백명이고 독립된 CI/CD 팀과 내부 인프라 등을 모두 가지고 있었다. 물론 테스트를 위한 전용 차량 및 테스트 벤치, 통합팀 등 전체 개발에 필요한 모든 조직을 내부에 가지고 있었다. 그럼에도 불구하고 UI 도메인 테스트가 끝나고 통합 직전 Pre Integration 테스트를 할 때 가끔 문제가 발생한다. UI 뿐만이 아니라 덩치가 큰 Speech, SoC, Camera, Media, Vehicle 도메인은 자체 통합팀 및 테스터를 보유하고 있다. 그리고 Pre Integration 팀에서도 통합 직전 테스트시 문제가 발생할 때 왜 나는지 개선을 위해 5 why..

회사에서 SCRUM 형태로 팀을 운영을 하고 있다. 일반적으로 하나의 SCRUM 팀에 1명의 Product Owner (PO)가 있고 Scrum Master (SM)은 여러 팀이 공유를 한다. DR (Development Representative)도 각 SCRUM 팀마다 한명이 있다. People 관리를 하는 Engineering Lead (EL)도 여러개의 스크럼을 가지고 있고 Architect는 System Architect (SA) 팀이 따로 있고, 여러개의 SCRUM 팀이 묶인 Domain 개념이 있는데 이 Domain에 속한 Architect 즉, Domain Architect (DA)도 있다. 간단하게 그림으로 표현하면 위와 비슷한 구조이다. 가끔 역할이 애매할 때가 있어 이번 기회에 개인적..

The Direct Rendering Manager (DRM) is a device-independent kernel-level device driver that provides support for the Direct Rendering Infrastructure. Direct Rendering Infrastructure (DRI) is an interface and a free software implementation inside the kernel used by the X Window System/Wayland to securely allow user applications to access the video hardware without requiring data to be passed throu..

Platform 및 플랫폼 개발을 하면서 오픈소스 처럼 개발 하기는 정말 어렵다. 여기서 오픈소스 처럼 개발 한다는 의미는 Yocto master branch를 계속 쫓아가면서 production branch (필자의 회사는 dunfell branch)를 유지하는 것이다. 즉 2개의 branch를 운영하고 개발자는 코드를 제출할 때는 master와 dunfell 모두 올려야하고 테스트도 물론 모두 함께 해야한다는 것을 의미한다. 필자의 회사에서는 Yocto 로 개발하는 Infotainment 플랫폼 및 제품에서 이를 시도하고 있다. 개발자들은 잘 지켜가고 있지만 현재 리소스 부족으로 테스트는 자동화만 돌리고 일부 매뉴얼 테스트는 대응하기 어렵지만, 필요할 때마다 요청해서 돌리고 있는 상황이다. 이 모델의..

Yocto 프로젝트에서 의존성 관리하는 방법과 의존성을 쉽게 추출하여 볼 수 있는 도구가 있어 간단히 소개하고자 한다. 의존성 (Dependency) 관리 의존성에는 크게 런타임 의존성과 빌드타임 의존성이 있다. 말 그대로 런타임 의존성은 실제 시스템 동작시 필요한 의존성이다. 예를 들면 시스템에서 실행 중 A라는애플리케이션에서 버튼을 눌러 특정 동작을 하라고 명령을 내리면 IPC를 통해 다른 프로세스로 실행중인 B라는서비스의 API를 실행할 A 애플리케이션은 B 서비스에 런타임 의존성을 가진다고 할 수 있다. 빌드 타임 의존성은 빌드 과정중에 필요한 의존성으로 빌드할 때 필요한 라이브러리가 그 하나의 예가 될 수 있다. Yocto에서는 각 레시피에서 DEPENDS와 RDEPENDS 변수를 통해 빌드타임..

회사에서 개발자 대상으로 Yocto Training 자료 정리하는 중에 도움이 될 만한 자료가 있어 공유하고자 한다. 첫번째 두 세션은 Yocto 프로젝트에 대한 개념을 소개하고 나머지 두 세션은 layer, image, application 생성에 대한 실습을 하면서 필요한 yocto 개념을 설명한다. Yocto는 임베디드 개발에서 프로그래밍을 하는 것에 대한 기본 지식을 가지고 이해해야 해서 약간의 사전 지식이 필요하다. Yocto 프로젝트에 대한 짧은 소개 - 개념 잡기 (5분) Getting started with Yocto (1:03:26) Embedded Linux 에 대한 간단한 정의부터 시작해서 1시간 동안 Yocto Project에 대해 소개한다. 아래 총 4개의 세션으로 나누어져 있는 ..

Yocto 기반으로 임베디드 리눅스를 개발할때 일반적으로 많이 사용하는 개발 환경을 소개하고자 한다. 다들 알고 글을 읽고 있겠지만 간단히 Yocto에 대해서 다시 소개하자면 하드웨어 아키텍처와 무관하게 커스텀 임베디드 리눅스를 만들기 위한 빌드 프레임워크이다. 자세한 내용은 https://www.yoctoproject.org/ 를 방문해서 문서와 함께 살펴보면 된다. Yocto 기반으로 개발을 해본 분들은 알고 있겠지만 일단 Yocto 자체를 배우는 것에 대한 시간이 소요된다. 오죽하면 "욕나오고 토나온다고 해서" 욕토라고 하겠는가? :) 물론 Yocto 원어는 10의 -24승, 아주 작은 단위를 말한다. 이유야 어찌되었건 그만큼 Yocto 환경에서 개발하는데 어렵다는 의미이다. 그럼 왜그렇게 다들 어..

지금 Mercedes-Benz 본사가 있는 Sindelfingen에 이틀 동한 UI 통합 관련 워크샾을 하러 가는 길이다. 새벽같이 일어나 공항에서 대기하는 도중 간단히 정리도 할 겸 블로그를 열었다. 차량용 인포테인먼트 소프트웨어 통합은 정말로 복잡하고 어렵다. 앞의 글에서 테스트에 대해서 이야기 했다시피 여러가지 장벽이 많다. 통합과정 중 테스트는 가장 중요한 핵심 요소 중에 하나이다. 테스트 부분은 빙산의 일각일 뿐이다. 회사 전체의 화두 중 하나도 소프트웨어 통합이다. 통합 관련 VSM (Value Stream Mapping) 워크샾도 여러번 진행을 하면서 전체 개발 과정을 펼쳐놓고 어느 부분이 bottleneck이고 어떻게 하면 조금 더 효율적으로 해결할 수 있는 지 등등을 이야기 했다. 여러번..

어제 회사 Summer Party에서 동료와 승진 과정 및 조건에 대한 주제가 나와서 간단히 글을 적어보고자 한다. 지금 기준인 지금 필자가 있는 회사기준이고 모든 독일회사가 동일하지는 않다. 그리고 Staff, Principal 엔지니어에게 요구되는 덕목(?)도 요즘에 많은 고민을 하고 있고 관련된 서적도 읽고 있어서 그 책을 다 읽고 이와 비슷한 이야기를 다시 적고자 한다. 위의 그림은 일반적인 커리어 패스에 대해서 개발 패스와 매니저 패스로 나눠서 체계를 잘 적어놓았고 필자의 회사와 완벽하게 포지션 명까지는 일치하지 않지만 대략 비슷하다. 대부분 경력 10-15년차정도 되는 개발자들은 위의 그림 기준으로 시니어 소프트웨어 엔지니어가 된다. 필자의 회사에서도 시니어 소프트웨어 엔지니어는 엔니지어링 매..

Yocto 프로젝트에서는 CI와 연동하여 QEMU에서 자동화 테스트를 할 수 있는 image test framework인 oeqa를 제공을 한다. 이 테스트는 ssh를 통해 타깃 시스템에서 실행이 되고 테스트 스크립트를 파이썬으로 작성이 된다. 이 테스트의 구현 사항은 testimage.bbclass에 구현이 되어 있다. 위의 그림은 Yocto QEMU 이미지 빌드후 QEMU를 실행하는 과정이다. Yocto 자동화 테스트를 하려면 테스트 환경 설정 및 테스트 케이스를 파이썬 스크립트로 작성해야 한다. 테스트 케이스 구현 테스트 케이스는 일반적으로 /lib/oeqa/runtime/cases 에 위치를 한다. Poky의 테스트 케이스를 참고하려면 다음 링크를 가서 하나씩 살펴보면 된다. 아래 예제는 conn..