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

한국 출장차 베를린에서 출발해 뮌헨 공항에서 대기중이다. 무려 8시간이나 ㅠㅠ 뮌헨에 사는 같이 가는 분과 일정을 맞추기 위해 어쩔 수 없다. 시간이 너무 많이 남아 노트북을 열었고 얼마전 지인과 독일 OEM 3사의 소프트웨어 회사 MBition (Mercedes-Benz Innovation Lab.), BMW Car IT, Cariad (폭스바겐 그룹)에 대해 이야기 했던 것이 생각나 정리해보려고 한다. 개인적으로 아는 정보로는 BMW Car IT -> Cariad (이전이름 Carmeq) -> MBition 순서대로 각 OEM의 소프트웨어 회사가 설립 된 것으로 알고 있다. BMW Car IT와 Carmeq는 솔직히 누가 먼저 생겼는지 모르겠지만 느낌상 그렇다. 자동차의 소프트웨어가 너무 광범위해서 ..

소프트웨어를 개발할 때 테스트는 기본적으로 같이 이루어져야 한다. 이 글에서는 차량용 소프트웨어를 개발할 때 ASPICE 프로세스를 기준으로 어느 단계에서 어떤 테스트가 이루어져야하는지를 간단히 소개하고 이를 CI와 연결하여 자동으로 테스트할 수 있는 방법에 대해서 이야기해보고자 한다. 이론은 크게 어렵지 않지만 실제 개발에 적용하기란 단계에 따라 상당히 어려울 수 있다. 이유도 가지 각색으로 정말 다양하다. 개발 리소스, CI 리소스, 하드웨어 리소스 문제, 안정성 문제, Component/SW Elements 등에 대한 정의의 문제, 의존성 문제 등등 말이다. 이 각각의 문제를 필자의 경험을 토대로 어떻게 하면 해결할 수 있을까 또는 왜 그렇게 어려운가에 대해서 하나씩 풀어보고자 한다. https:/..

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

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

소프트웨어 개발 과정중에 테스트는 구지 꺼내어 이야기할 필요도 없을 정도로 기본이고 중요하다. 그 테스트 종류는 단위 테스트, 통합 테스트, 시스템 테스트, 사용자 시나리오 테스트 등등 다양하다. 현재 2024년도 벤츠 E Class 최종 막바지 작업과 차세대 프로젝트 등 동시에 진행중에 있으며 테스트 및 통합 관련 이야기는 프로젝트 시작부터 지금까지 계속 중요한 주제 중 하나로 다루어지고 있다. 통합 이야기는 다른 글에서 이야기하고 하고 이 글에서는 테스트 이야기를 조금 더 해보기로 한다. 개발 과정중에 단위 테스트, 컴포넌트 테스트, 도메인 테스트 등 다양한 테스트를 개발자 및 개빌 팀, 도메인 팀에서 진행을 한다. 하지만 통합 직전에 하는 테스트에서 문제는 끊임없이 계속 반복이 된다. 심지어 그 도..

이전 글에서 BMW가 다른 독일 OEM에 비해 전반적인 기술을 도입하는 속도나 성숙도가 느리다고 이야기 했었다. 하지만 계속 느끼고 있었고 오늘 EOSS (Embedded Open Source Summit) 2023에서 다시 한번 확인해본 결과 그렇지 않다는 결론을 스스로 내렸다. 지속적으로 오픈소스 컨퍼런스에 활동한 내용들을 발표했고, 이제는 스폰서도 하고, 데모도 지속적으로 한다. 여기서 만난 친구들과 여러 이야기를 나누면 소프트웨어에 대한 성숙도는 다른 독일 자동차 회사보다 훨씬 더 난거 같기도 하다. Node0 - BMW 소프트웨어 플랫폼 위의 데모는 최신 건 아니지만 Cluster에서 Linux를 사용하고 많은 곳 (IVI, RSU, 뒷좌석 양쪽 컨트롤러)에서 자체 리눅스 플랫폼인 Node0를 ..

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

소프트웨어 플랫폼 1부 LG전자 편에서는 webOS가 LG전자의 개발 문화를 한층 높였다고 자평했다. 여전히 그 믿음에는 흔들리지 않는다. 물론 양산 직전에는 이전과 달라지지 않았지만 애자일한 방법도 도입이 되었고, 이전에 지속적으로 품질에 대한 성숙도도 높아졌다. 이 글에서는 MB.OS (Mercedes-Benz Operation System)에 대해서 간단히 이야기해보고 그 중에서도 Infotainment에서 생각하고 있는 소프트웨어 플랫폼에 대해서 조금 더 자세히 이야기해보고자 한다. MB.OS (Mercedes-Bnez OS) MB.OS는 크게 4개로 나누어지고 각기 다른 형태의 OS를 가질 수도 전체의 코어 플랫폼을 하나로 가지고 다른쪽에 수평전개해서 사용할 수도 있다. 하지만 여전히 논의중이고..

차량용 ECU가 다양한 형태로 통합되고 있다. Domain Architecture, Zonal Architecture 등 다양한 용어의 ECU 아키텍처가 등장하고 각 자동차 회사 (OEM)마다 각자의 설계에 맞게 진행하고 있다. 확실한건 ECU 수가 줄어들고 있고 그만큼 하나의 ECU 내에서 소프트웨어 복잡도도 증가하고 있다. 지금 여기서 이 이야기를 하려는 것은 아니고 현재 인포테인먼트를 개발하고 곧 양산을 하는데 이 중에서 리눅스 부분만 떼어서 어떤 종류의 하드웨어를 가지고 어떤 종류의 이미지를 만들어 내고 있는지를 간단하게 적으려고 한다. Mercedes에서는 인포테인먼트를 MB.OS의 큰 축 중 하나로 보고 있고 다음 개발을 연속적으로 하기 위해 Product Platform도 함께 가지고 가고 ..

자동차 인포테인먼트의 핵심 기능 중 하나는 네비게이션이다. 하지만 OEM (자동차 제조업체)에서 개발해 탑재된 네비게이션의 품질은 좋지 않은 것으로 유명하다. 특히나 한국에서는 TMAP이나 카카오, 다른 나라에서는 Google MAP을 스마트폰으로 켜서 운전 중 네비게이션으로 많이들 사용한다. 차량에서 아이폰의 CarPlay나 Android Auto를 지원하면 스마트폰에 연결해서 차량의 디스플레이로 사용하면서 말이다. 최근 많은 자동차 업체들이 한국에서 TMAP을 내장 네비게이션으로 탑재하기 시작했고 벤츠에서도 탑재를 하기로 결정했다. 독자적인 네비게이션을 탑재할 만큼 벤츠도 한국이 중요한 시장이라는 것을 인지한 것이다. 이를 위해서 오래전부터 계획을 했었고 벤츠코리아에서 많은 노력을 한 결과 결정이 되..