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

차량용 ECU 아키텍처가 분산 아키텍처에서 중앙집중형, 도메인, Zonal 아키텍처로 움직이고 있다. OEM 마다 약간씩 다르지만 목적은 작은 수십/수백개의 ECU를 성능 좋은 수/수십개로 줄이는 것이다. 하드웨어 비용을 줄이고 소프트웨어 업데이트 등을 조금 더 자유롭고 편하게 하고자 하는 목적이다. 이렇게 함으로써 ECU 하나에 들어있는 소프트웨어의 복잡도는 늘어나고 각기 다른 기능을 위한 OS도 하나의 ECU에 여러개가 서로 고립되면서 돌아가야 한다. 이 때 하이퍼바이저 (Hypervisor)을 사용한다. 하이퍼바이저 쪽 전문가는 아니지만 최근 프로젝트를 하면서 Type1, Type2 하이퍼바이저에 대한 구분 및 장단점 그리고 전 가상화 (Full Virtualization)와 반 가상화 (Para ..

honister 3.4 버전에서 Yocto 오버라이드 문법이 변경되었다. "_"를 사용 하던 것이 ":" 로 변경되었다. 예를 들면 아래와 같다. 기존 문법 SRC_URI_qemux86 = "file://somefile" 신규 문법 SRC_URI:qemux86 = "file://somefile" 물론 기존 변수 이름에 _를 사용하여 약간 헤깔리는 경우가 있다. BBFILE_PATTERN, SRC_URI, PREFERRED_VERSION_xxx, SRCREV_xxx 등이 있다. 위의 것들은 변경 없이 기존과 같이 사용한다. 문법 변경사항을 쉽게 적용하기 위해 Yocto에서는 script를 제공하니 한꺼번에 변경하려면 아래 스크립트를 사용하면 된다. $ /scripts/contrib/convert-overr..

Yocto에서는 빌드 과정 중 각 컴포넌트의 태스크를 빌드할 때 사용한 리소스(CPU, Disk) 사용량 및 빌드 시간을 저장할 수 있다. 이는 빌드 시간을 최적화하는데 많은 도움을 준다. 빌드 통계를 활성화 하는 방법은 conf 파일 (ex, local.conf)에 다음 라인을 추가하여 빌드하면 된다. INHERIT += "buildstat" 빌드를 하면 아래 그림과 같이 build/tmp/buildstats/[timestamp] 디렉토리에 레시피 디렉토리가 있고 그 디렉토리 안에 태크스 별로 파일이 생성된다. 아래는 zip 컴포넌트의 do_compile 태스크 결과 파일이다. 이 파일들만을 가지고는 분석하기 어렵기 때문에 yocto에서는 시각화할 수 있는 python 스크립트를 제공한다. 다음 명령어..

Yocto dunfell (3.1)이 릴리스되기 전까지 Yocto는 기본적으로 6개월 주기의 릴리스 과정을 거치고 새로운 버전이 릴리스되면 이전버전의 유지보수를 멈추었다. 하지만 많은 요구사항 중에 하나는 Kernel과 같이 LTS (Long Term Support)를 해달라는 것이였고 Board 미팅에서 지원하기로 결정했다. 그 시작은 Yocto dunfell (3.1)부터였고 2년간 유지보수를 하기로 결정하였다. 하지만 2년이 지나서도 커뮤니티 및 보드 멤버 회사에서 추가적인 유지보수를 요구하였고 dunfell은 4년 동안 유지보수를 하기로 결정하였다. 그리고 그 다음 LTS 버전은 kirkstone (4.0)이고 이미 릴리스가 되어 있다. 현재 프로젝트는 dunfell을 사용하고 있고 필자의 동료가..

이전 글에서는 Delivery Team 에 대한 다양한 구성 방법에 대해서 이야기했다. 이 글에서는 실제로 회사에서 진행하려는 Subsystem Delivery 조직 구성에 대해서 조금 더 이야기해보고자 한다. 이렇게 글로 쓰면 생각이 좀 더 정리되어 조직을 구성하는데 쉬울 것 같아서 블로그를 열었다. 다음 그림은 완전히 일치하지는 않지만 곧 출시할 벤츠 E Class의 인포테인먼트 구조와 비슷하다. 용어 설명 Sub System: 각각의 Guest OS, 즉 QNX, Linux, Android, RTOS 가 각각의 Sub System 이다. System: 모든 Sub System을 통합 조직 구성 각각의 Sub System 별로 Delivery 팀을 구성할 예정이고, 전체를 통합하여 릴리스하는 Syst..

앞에서 소프트웨어 플랫폼과 Delivery 조직에 대해서 이야기했다. 이번 글에서는 Delivery 조직을 어떻게 구성을 하면 좋을 지에 대한 고민을 하면서 글을 적어본다. Delivery 조직은 최종 전달할 제품의 품질을 책임지는 조직이다. 프로세스 상 최종 Integration을 담당한다. 지금 생각하는 역할은 다음과 같다. Delivery Lead: 전체 Delivery 팀을 총괄 Project Manager: 프로젝트 일정 관리와 테스트 결과를 바탕으로 최종 Integration 결정 Release Manager: 제품 릴리스에 필요한 이미지, 문서를 관리 Defect Manager: 현재 나오는 문제에 대해서 관리 Build Engineer: 리뷰한 commit을 바탕으로 묶어서 테스트 할 수 ..

지금 EOSS (Embedded Open Source Summit) 2023 참석을 마치고 베를린으로 돌아가는 기차안에 있다. 역시나 이번에도 실망시키지 않는 유럽의 기차 ㅠㅠ. 베를린으로 가는 기차가 제대로 안와서 프라하 Local 기차를 타고 중간 어딘가에서 갈아타서 이제야 제대로 가고 있다. 덕분에 1시간정도 지연될 예정이다. EOSS에서 오랜만에 전직장 (LG전자) 분들 5명을 만났다. 그리고 현대자동차, 다른 한국회사 분들도 만났다. 프라하에 사는 친구 Martin Jansa (Yocto Maintainer/Contributor)도 LG분들과 함께 만나서 저녁식사를 같이 했다. Yocto Project Dev Day는 2019년 이후 코로나로 중단되었다가 다시 Co-Event로 들어왔다. 원래 ..

앞에 소프트웨어 플랫폼에 대해서 1부와 2부까지 글을 쓰고 다 끝난줄 알았다. 하지만 지금 다시 글을 쓰는 이유는 요즘 다시 회사 내부에서 조직에 관한 고민과 지금 프라하에서 열리고 있는 EOSS (Embedded Open Source Summit)에서 BMW 개발자들과 이야기 한 후 생각의 정리가 필요해서 블로그를 열었다. 어제도 간단히 BMW의 소프트웨어 플랫폼 node0에 대해서 글을 썼다. 이번 글을 소프트웨어 플랫폼의 제목을 달았지만 현재 프로젝트 상 조직에 대한 고민이 더 커서 이에 대해 글을 써보고자 한다. 플랫폼 조직, 제품 조직, 개발 조직 등에 대해 플랫폼과 엮어 여러가지로 고민 중에 있다. 위의 그림은 개발 조직 구조 중에 하나를 검색하다가 가지고 왔다. 현재 상황 제품: 인포테인먼트..

2022년까지는 ELCE (Embedded Linux Conference Europe)와 Open Source Summit 등을 합쳐 여러개로 진행했는데 올해에는 Embedded Open Source Summit 이라는 이름으로 프라하에서 열린다. Yocto Project Dev Day는 Co-Location 컨퍼런스로 하루 전에 열리게 된다. 다음주 월요일에 Yocto Project Dev Day부터 시작을 하여 지금 어떤 세션을 들을까 보면서 간단히 글을 적어 보려고 한다. 당연히 컨퍼런스가 끝나면 후기도 올릴 예정이다. Yocto Project Dev Day (2023년 6월 26일, 9:00 - 17:00) Link: https://events.linuxfoundation.org/embedded-..

요즘 리더십에 관련된 도서를 읽고 있고 "팀장의 탄생"은 아는 분의 추천에 의해서 읽게 되었다. 이 책은 실리콘밸리 페이스북 초창기 인턴으로 입사해 부사장까지 오른 작가가 썼고 팀장이 되어가면서 그리고 점차 올라갈 수록 어떻게 팀원을 관리하고, 본인을 관리해야하는 가에 대해서 이야기하고 있다. 관리에 대한 정의 즉, 여러 팀원이 함께 뭉쳐 그 이상의 성과를 낼 수 있도록 뒷받침해 주는 것부터 시작한다. 그리고 수습생 (필자의 회사로 말하면 Interim Engineering Lead), 개척자 (새로운 팀을 만들어 부임), 신규 부임자 (기존 조직에 신규 부임), 후계자 (기존 관리자의 자리를 대신 받음)에 따라 각각 어떻게 행동을 하면 좋은지에 대해서 이야기 한다. 작은 팀을 이끄는 방법에 대해서 이후..