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

프로젝트를 하다가 QT LTS Commercial 버전과 LGPL 버전이 궁금하게 되어 몇가지 조사를 해보고 나름대로 내린 결론을 아래와 같이 적어본다. QT는 Commercial과 LGPL Dual License를 모두 지원한다. Commercial 버전과 LGPL 버전의 코드는 거의 동일하지만 commit이 정확히 일치하지는 않는다. 오픈소스의 qt 저장소 커밋을 보면 한꺼번에 Commercial 저장소 commit들을 merge한 merge commit 들이 보인다. QT Commercial 버전과 LGPL 버전 차이 저장소 위치가 다름 (Commercial 버전은 로그인 해야 접근 가능) 5.15와 같은 경우 지속적인 지원 여부 (2023년 5월 26일 이후에 오픈소스 저장소 즉 LGPL 버전은..

EKC (Europe-Korea Conference) 2023이 독일 뮌헨에서 2023년 8월 14일 부터 18일까지 개최되었다. EKC2023 - Europe-Korea Conference on Science and Technology2023 www.ekc2023.org EKC 소개 미국에는 UKC 미국에 있는 과학자들이 1년에 한번씩 모여 서로의 기술을 공유하고 네트워킹을 한다면, EKC는 유럽 전역에 있는 과학자들이 1년에 한번씩 모여 정보를 공유하며 서로의 정보를 공유한다. 유럽의 각 지역에 과학자 협회(재독과협, 재영과협, 프랑스과협 등)가 돌아가면서 EKC를 개최한다. 2022년에는 프랑스 마르세유에서, 2024년에는 영국에서 개최될 예정이다. 건축, 재료, 정보통신, 생명, 화학 등 다양한 ..

Yocto 프로젝트는 가능한 모든 컴포넌트를 직접 빌드하여 사용한다. 그렇기 때문에 빌드 시간이 오래 걸리고 이를 보완하기 위해 PREMIRROR와 Shared State Cache를 사용하여 빌드 시간을 단축한다. 하지만 여전히 의존성 등의 문제로 수정하지 않은 컴포넌트를 전체 컴파일하기도 한다. 이를 보완하기 위해 ccache를 사용할 수 있다. ccache ccache (https://ccache.dev/) 는 컴파일러 캐시이다. 이전에 컴파일 했던 캐시를 저장했다가 다시 재사용하여 컴파일 속도를 빠르게 한다. GCC, Clang 등의 컴파일러를 지원하고 윈도우, 맥, 리눅스 등의 운영체제에서 동작한다. Yocto에 ccache 적용하기 yocto에는 ccache.bbclass가 있다. 그 파일 안..

차량용 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로 들어왔다. 원래 ..