Posts AGL(Automotive Grade Linux)에 대하여
Post
Cancel

AGL(Automotive Grade Linux)에 대하여

1. 들어가며

AGL(Automitive Grade Linux)는 유럽, 일본, 한국 등 다양한 차량제조 및 부품회사들이 협력하여 만들고 있는 차량환경에 적합한 Opensource OS(Operating System)입니다.. Toyota의 막강한 Funding 력으로 Linux Foundation의 지휘를 받으며 빠르게 발전하고 있습니다.

참여하고 있는 멤버 회사들은 매우 많지만 그 중 Toyota를 필두로 하여 일본계 회사들이 매우 적극적으로 달려들고 있습니다. https://www.automotivelinux.org/about/members/

Desktop View

Toyota는 사실상 그저 물주에 가까울 정도로 AGL에 대해 소극적인 활동을 보여줬었는데, 2020년 3Q를 시작으로 갑자기 무서울정도로 달려들고 있는 것 같아 보입니다.. 여담이지만 Havard Bussiness School 교육의 단골 손님이자 관료제 끝판왕 Toyota 가 최근 성과제로 변경을 시도하기도하고, AGL을 포함한 다양한 SW 정책과 같이 변모를 시도한다고 합니다. (카더라 통신에 의하면 Tesla에게 자극 받아서 그렇다는 소문이..)

최근엔 BMW 와 VW 그룹의 리서치 센터도 활발하게 참여하는 등 Tesla를 대항하기 위한 일종의 여집합처럼 합종연횡 을 한다는 느낌으로 Co-work 중인 것으로 파악됩니다..

필자는 이런 이유로 AGL에 대한 스터디가 기본은 되어 있어야 할 것 같아서 정리 겸 이 글을 기고하기로 결심했습니다..

그럼 시작 해보도록 할까요

2. 서막

AGL을 이해하기 위해서는 Tizen OS 에 대해 조금 알아야 합니다. Tizen OS 는 삼성과 인텔이 시작한 모바일 환경의 OS입니다. Android와 iOS의 독점을 막기 위해 야심차게 시작했지만 막강한 개발자 친화적 정책과 마케팅 전략등에 압도적으로 밀려 결국은 모바일 시장에서는 역사의 뒤안길로 사라졌죠. (2018년을 마지막으로 삼성에서 타이젠폰 개발을 중단)

그런데 AGL에서 Tizen IVI를 레퍼런스로 기반 프로젝트를 시작하여 이 다 죽은 OS를 살려내고 있습니다.

3. 대항마

Desktop View

대표적 대항마로는 GENIVI Alliance의 GENEVI Open Source Software Project가 있습니다. (추후 다른 글에서 자세히 다룰 예정)

GENEVI는 더 빠른 시점인 2009년에 시작 했는데요. 이 프로젝트 역시 Linux Foundation를 필두로 나아가고 있습니다.

참여 멤버로는 BMW Group, Delphi, GM, Intel, Magneti-Marelli, PSA Peugeot Citroen, Visteon, Wind River System 등이 있고, 차량 OEM 뿐아니라 NASA 로켓의 OS(VxWorks)로 유명한 Wind River 같은 회사들도 참여하여 스마트카 시장에서 반 구글진영의 대표적 주자 중 하나입니다.

4. 목표

위에서 필자가 언급했듯이 AGL은 IVI(In-Vehicle Informaintment) 시장을 목표로 삼고 있습니다. 이는 GENEVI도 마찬가지 인데요. 이 두 OS의 공통점은 비영리단체라는 점입니다. 시장 논리 때문인지는 몰라도 사실 발전 속도가 Android나 iOS에 비해 현저하게 느렸습니다만, 2020년 화웨이 사태와 같이 Google의 Android OS 사용 License 자체를 막는 사건들을 지나 국가간의 분쟁사태까지 번지고 있는 최근에는 OS의 발전속도에 박차가 가해지고 있습니다.

방향성을 보면 현재 모바일에서 지원되는 기능들을 팔로우업하는 것 우선으로 보입니다.

하지만 여전히 갈길은 매우 멀다고 볼 수 있습니다.

2020년 AGL의 로드맵 자료를 통하여 비춰볼 수 있는 현재 지표와 그 방향성에 대해 살펴보겠습니다. 링크

5. 2020년 로드맵 (2월 업데이트)

  • Yocto 2.6(thud) -> 3.0(zeus) 플랫폼으로 업데이트
  • 다양한 플랫폼을위한 Graphical API 기능 지원
  • Android auto, Apple Carplay와 같은 스마트폰과의 연계를 위한 솔루션 마련
  • 지속적 업데이트를 위한 로드맵 마련
  • QA 및 테스트 (CI/CD) 커버리지 강화
  • C/C++ Skeleton 코드 및 Json 자동생성 API 툴 개발
  • 클라우드시스템을 이용하여 스마트폰을 통해 차량을 제어할 수 있는 모델을 제안
  • 네이티브 기능으로서 MQTT 프로토콜 지원(최소한의 전력과 데이터로 통신)
  • 보안/어플리케이션 프레임워크
    • 어플리케이션 프레임워크와 관련한 방화벽 기능 추가
    • 보안 관리자 기능을 통한 보안강화
    • 플러그인, 보안, 프로토콜등을 지원하고 유지보수하기 쉽도록 프레임워크를 제공
    • Java Client, LXC/systemd 와 같은 레거시 및 써드파티 어플리케이션 지원
    • 연결 지속을 위한 기능 내장(keep alive, reconnection)
    • Javascript 및 python binding 지원
  • 부팅 및 파워 관련
    • 부팅시간 감소, 부트 모드 선택, 모니터링 기능을 하는 부트 매니저 지원
    • RAM Sleep 지원 & 저온 동작
  • 최소기능을 요하는 ECU지원 등을 위한 AGL 최소화 시스템 기능 지원
  • QoS를 보장하기위한 Real Time API 기능 지원

5.1 App FW & Security EG(Expert Group)

  • 개발자가 어플리케이션에 서명하고 로드 할 수 있는 매커니즘을 마련
  • 웹 앱용 App Launcher 및 HTML5로 즉석에서 다운로드 할 수있는 코드 관리 전략
  • 현재 백그라운드에있는 비 권한 앱을 중지하기위한 앱 프레임 워크 API 및 전략 (예 : SIGTERM)
  • Sleep mode로 부터 돌아올 수 있는 App 프레임워크 통신 바인더를 제공
  • 어플리케이션 라이프사이클 관리자
    • 홈 화면에서 백그라운드 앱을 인지(음악, 전화, 읽지않은 메시지 등)
    • 매니저를 통한 각각을 끌 수 있음
    • SM(State Management) 정의 및 구현 필요
  • 앱 등록 및 패키징을 위한 하드웨어 추상화(HAL) API 제공
  • 멀티플랫폼 기반으로 키관리, 유지보수, 빌드 할 수 있는 메인 어플리케이션 프레임워크의 모듈화
    • 어플리케이션 프레임워크와 키들의 분리(코드 레벨)
    • 디바이스 개발자가 키의 변경을 쉽게 할 수 있도록 함
    • 키 관리와 바인딩을 쉽게 할 수 있도록 라이브러리 제공
  • Web Apps/HTML5
    • WAM(웹앱 관리자)에서 요구하는 Chromium Webview Upstream API 지원
    • WAM 와 Chromium과의 통신 연계 향상
    • WAM upstream 과 WebOSE Chromium를 독립적으로 동작하도록 함
    • 새로운 Window Manager와 WAM의 통합
    • 웹앱
      • 새로운 보안모델 통합
      • 향상된 어플리케이션 라이프사이클 관리자
      • HTML5 데모 플랫폼 컨테이너화하여 제공
      • 데모 웹앱 라이브러리 제공
      • 추가 데모 어플리케이션들 제공

5.2 Graphical EG

2019년을 끝으로 얼추 로드맵 달성한 것으로 보임

  • Window Manager와 Homescreen 개발 마무리
    • Homescreen API/서비스
      • QT, HTML5 마무리 단계
    • 가상 키보드를 위한 일어와 영어의 High-level API 제공
    • 팝업 기능 지원 (가상키보드, 경고 등)
    • 멀티디스플레이 해상도 관련 기능 지원
      • Portrait vs Landscape
      • Scalable display size
  • 멀티 페이지, 폴더, 슬라이더 등 스크린에서 벚어나는 앱 관리
  • 향상된 이중 스크린 기능
  • 하드웨어 Plane 관리 : 후방카메라, 스마트폰 연결 등
  • 대화식 사용자 응답 기능 : 스크린 떨림, 비프음 등
  • Wayland/Weston Upstream 지원
  • xdg 프로토콜
  • QT 변경 검토 : HTML5, GTK+ 등..
  • High Level Audio API 지원
  • Bluetooth Audio 를 Blues/Alas 로 변경
  • 음성 인식 및 문자->음성 서비스
  • 마이크 입력 과 미디어 플레이어 출력간의 정책 관리

5.3 Connectivity EG

  • 차량 Signal 관리
    • 마지막 차량 설정 기반 CAN 메세지 초기화
    • 스트리밍과 블루레이 컨텐츠의 암호화
    • 향상된 CANoe <-> AGL 간의 메시지 번역기능 지원
  • 향상된 블루투스 기능
    • AGL를 지원하는 다른프로젝트에서 수행한 작업을 기반으로 독접 칩 스택에 대한 지원 준비
    • 저전력 기능 지원
  • 향상된 Wifi
    • AP모드 지원
  • 향상된 전화기능
  • 네트워크 바인딩
    • 동시에 전화가 필요한 텔레메틱스 서비스를 위한 동시성 기능제공

5.4 V2X EG

  • Kickoff 대기중

5.5 Virtualiation EG

  • Host로서 AGL의 가상화 지원
    • ARM과 Intel 동시에 지원하는 Opensource Hypervisors 기능 추가
    • Compile 타임에 어떠한 Hypervisor를 선택할 것인지 결정할 수 있음
      • 드디어(?) KVM 지원(Renesas RCar-M3 에서 이용가능)
      • XEN과 Jailhouse 지원
  • Guest로서 AGL의 가상화 지원
    • 공식적으로 ARM과 Intel CPU 에서 게스트 OS로 동작
    • XEN, KVM, Jailhouse 지원
    • Guide Document 제공
  • AGL의 그래픽 가상머신 관리자 어플리케이션
    • AGL GUI에서 게스트 OS를 컨트롤 하기 위한 툴 생성
    • 게스트 OS의 시작과 종료, USB 부착 기능 제공
  • VMs/AGL 프로파일 통신
    • 서로다른 VM들과 AGL간의 통신 및 상호작용을 위한 공통 API 정의/디자인/개발

5.6 Navi EG

  • AGL 네비게이션 API 개발 완료
  • Documentation 완료
  • Reference 앱 제공

6. 5-Star Projects

6.1 Resource Control Project

Jira Link

AGL은 일련의 작업 (커널의 cpuset)에 CPU 집합을 할당하는 메커니즘을 제공해야합니다. 정책 기반 결정에 따라 정책 관리자는 커널 계층의 “자원 제어”를 사용하여 대상 프로세스 또는 프로세스 그룹에 적절한 CPU 하위 집합을 할당해야합니다. (일반적으로 cgroups / cpuset이 사용됩니다).

  • 배경: 하드웨어에는 여러 CPU가있을 수 있으며 시스템은 여러 작업 / APP을 실행할 수 있습니다. 시스템은 일정 및 경합 (캐시 등)을 줄이기 위해 신중한 프로세서 배치의 이점을 얻을 수 있습니다

7. 4-Star Projects

Jira Link

AGL에 스마트 장치 링크를 포트합니다.

  • 배경: Smart Device Link는 Ford가 차세대 차량에 사용하고 있으며 Toyota와 제휴하여 업계 전반에 걸쳐 마케팅되고 있습니다.

8. 마무리하며

위와 같이 로드맵을 요약하며 현재까지 진행된 부분과 앞으로의 방향에 대해 미뤄 짐작해볼 수 있었습니다.

와이파이, 블루투스, 오디오 같은 디바이스 사용을 위한 API는 어느정도 성숙했고, 차량환경에서 제일 중요한 네비게이션 API는 완성에 단계로 보입니다. 웹앱을 지원하기위해서 많은 노력을 쏟아 이를 통해 크로스플랫폼의 호환성을 보장하며 개발자에게 유연한 API를 제공할 수 있을 것으로 보입니다.

추가적으로 프레임워크 레벨에서 보안을 보장하고 개발자가 개발을 쉽게 할 수 있도록 많은 API들을 고려중입니다.

아직 Smart Phone에서 지원하는 기능들을 많이 지원하지 못하는 것을 볼 수 있었는데요. 실제로 Cloud와 같은 기능을 지원하기 위해서는 Connectivity나 V2X EG의 프로젝트들이 빠른시일내에 진행되고 성숙해야 할 것으로 보입니다.

Graphical API는 많은 부분에서도 로드맵을 달성하였으나 현재 QT에서 다른것으로의 이전도 고려중인 것으로 사료되고 있습니다.

This post is licensed under CC BY 4.0 by the author.