1. Introduction

AGL (Automotive Grade Linux) is an open source OS (Operating System) suitable for automotive environments, created through collaboration between various vehicle manufacturing and parts companies from Europe, Japan, Korea, and other regions. It’s rapidly developing under the guidance of the Linux Foundation with Toyota’s strong funding power.

There are many participating member companies, but Japanese companies, led by Toyota, are very actively pursuing this project. https://www.automotivelinux.org/about/members/

Toyota was actually showing rather passive activity on AGL, almost like just a financial sponsor, but starting from Q3 2020, they suddenly began pursuing it quite aggressively. As a side note, Toyota, a regular guest of Harvard Business School education and the ultimate bureaucratic organization, has recently been attempting to change to a performance-based system and trying to transform through various SW policies including AGL. (According to rumors, they were stimulated by Tesla…)

Recently, BMW and VW Group’s research centers are also actively participating, and it feels like they’re doing strategic alliances as a kind of complement set to counter Tesla…

For these reasons, I felt that having a basic study of AGL should be essential, so I decided to write this article as both a summary and reference.

Let’s get started, shall we?

2. Prelude

To understand AGL, you need to know a bit about Tizen OS. Tizen OS is a mobile environment OS started by Samsung and Intel. They ambitiously started it to prevent the monopoly of Android and iOS, but were overwhelmingly defeated by their powerful developer-friendly policies and marketing strategies, eventually disappearing into the back pages of history in the mobile market. (Samsung stopped developing Tizen phones as of 2018)

But AGL is reviving this dead OS by starting a base project with Tizen IVI as a reference.

3. The Competition

A representative competitor is the GENIVI Open Source Software Project from GENIVI Alliance. (I plan to cover this in detail in a future article)

GENIVI started at an earlier point in 2009. This project is also led by the Linux Foundation.

Participating members include BMW Group, Delphi, GM, Intel, Magneti-Marelli, PSA Peugeot Citroen, Visteon, Wind River System, etc. Not only automotive OEMs but also companies like Wind River, famous for NASA rocket OS (VxWorks), participate, making it one of the representative players in the anti-Google camp in the smart car market.

4. Goals

As I mentioned above, AGL targets the IVI (In-Vehicle Infotainment) market. This is the same for GENIVI. The common point of these two OSes is that they’re non-profit organizations. Whether due to market logic or not, their development speed was significantly slower compared to Android or iOS. However, after events like the 2020 Huawei incident where Google’s Android OS usage license itself was blocked, and with recent escalation to international disputes, the development speed of these OSes is accelerating.

Looking at the direction, it seems to prioritize following up on features currently supported in mobile.

But there’s still a very long way to go.

Let’s look at the current indicators and direction through AGL’s 2020 roadmap materials. Link

5. 2020 Roadmap (February Update)

• Yocto 2.6(thud) → 3.0(zeus) platform update
• Support for graphical API features for various platforms
• Solutions for smartphone connectivity like Android Auto, Apple CarPlay
• Roadmap for continuous updates
• Enhanced QA and testing (CI/CD) coverage
• C/C++ skeleton code and Json auto-generation API tool development
• Proposing a model for controlling vehicles through smartphones using cloud systems
• Native MQTT protocol support (communication with minimal power and data)
• Security/Application Framework
  • Adding firewall functionality related to application framework
  • Security enhancement through security manager functionality
  • Providing framework that supports plugins, security, protocols and is easy to maintain
  • Support for legacy and third-party applications like Java Client, LXC/systemd
  • Built-in functionality for connection persistence (keep alive, reconnection)
  • Javascript and python binding support
• Boot and Power related
  • Boot manager supporting boot time reduction, boot mode selection, monitoring functionality
  • RAM Sleep support & low temperature operation
• AGL minimization system functionality support for ECUs requiring minimal functionality
• Real Time API functionality support to guarantee QoS

5.1 App FW & Security EG(Expert Group)

• Establish mechanism for developers to sign and load applications

• App Launcher for web apps and code management strategy for HTML5 downloadable on the fly

• App framework API and strategy to stop non-privileged apps in background (e.g., SIGTERM)

• Provide app framework communication binder that can return from Sleep mode

• Application lifecycle manager

  • Recognize background apps from home screen (music, phone, unread messages, etc.)
  • Ability to turn off each through manager
  • Need to define and implement SM(State Management)

• Provide hardware abstraction layer (HAL) API for app registration and packaging

• Modularization of main application framework that can manage keys, maintain, and build on multi-platform basis

  • Separation of application framework and keys (code level)
  • Enable device developers to easily change keys
  • Provide library for easy key management and binding

• Web Apps/HTML5

  • Support Chromium Webview Upstream API required by WAM (Web App Manager)
  • Improve communication connection between WAM and Chromium
  • Make WAM upstream and WebOSE Chromium work independently
  • Integration of new Window Manager and WAM
  • Web apps
    • Integrate new security model
    • Enhanced application lifecycle manager
    • Provide HTML5 demo platform containerized
    • Provide demo web app library
    • Provide additional demo applications

5.2 Graphical EG

Seems to have mostly achieved roadmap by end of 2019

• Complete Window Manager and Homescreen development
  • Homescreen API/service
    • QT, HTML5 completion stage
  • Provide high-level API for Japanese and English virtual keyboard
  • Support popup functionality (virtual keyboard, warnings, etc.)
  • Support multi-display resolution related functionality
    • Portrait vs Landscape
    • Scalable display size
• Multi-page, folder, slider and other off-screen app management
• Enhanced dual screen functionality
• Hardware Plane management: rear camera, smartphone connection, etc.
• Interactive user response functionality: screen shake, beep, etc.
• Wayland/Weston Upstream support
• xdg protocol
• QT change review: HTML5, GTK+, etc.
• High Level Audio API support
• Change Bluetooth Audio to Blues/Alas
• Voice recognition and text-to-speech service
• Policy management between microphone input and media player output

5.3 Connectivity EG

• Vehicle Signal management
  • CAN message initialization based on last vehicle settings
  • Encryption of streaming and Blu-ray content
  • Enhanced CANoe ↔ AGL message translation functionality support
• Enhanced Bluetooth functionality
  • Prepare support for proprietary chip stacks based on work done by other projects supporting AGL
  • Low power functionality support
• Enhanced Wifi
  • AP mode support
• Enhanced phone functionality
• Network binding
  • Provide concurrency functionality for telematics services requiring simultaneous phone calls

5.4 V2X EG

• Waiting for Kickoff

5.5 Virtualization EG

• AGL virtualization support as Host
  • Add Open source Hypervisors functionality supporting both ARM and Intel
  • Decide which Hypervisor to select at compile time
    • Finally(?) KVM support (available on Renesas RCar-M3)
    • XEN and Jailhouse support
• AGL virtualization support as Guest
  • Officially operate as guest OS on ARM and Intel CPUs
  • XEN, KVM, Jailhouse support
  • Provide Guide Document
• AGL’s graphical virtual machine manager application
  • Create tool to control guest OS from AGL GUI
  • Provide guest OS start/stop, USB attachment functionality
• VMs/AGL profile communication
  • Define/design/develop common API for communication and interaction between different VMs and AGL

5.6 Navi EG

• AGL navigation API development completed
• Documentation completed
• Reference app provided

6. 5-Star Projects

6.1 Resource Control Project

Jira Link

AGL should provide a mechanism for allocating CPU sets to a series of tasks (kernel’s cpuset). Based on policy-based decisions, the policy manager should allocate appropriate CPU subsets to target processes or process groups using “resource control” at the kernel layer. (Generally cgroups/cpuset are used).

• Background: Hardware may have multiple CPUs and the system may run multiple tasks/APPs. The system can benefit from careful processor placement to reduce scheduling and contention (cache, etc.)

7. 4-Star Projects

7.1 Smart Device Link (SDL)

Jira Link

Port Smart Device Link to AGL.

• Background: Smart Device Link is being used by Ford in next-generation vehicles and is being marketed industry-wide in partnership with Toyota.

8. Conclusion

By summarizing the roadmap as above, we could infer the parts that have progressed so far and the future direction.

APIs for device usage like wifi, bluetooth, and audio have matured to some extent, and the navigation API, which is most important in automotive environments, seems to be in completion stage. By putting a lot of effort into supporting web apps, it seems they can guarantee cross-platform compatibility and provide flexible APIs to developers.

Additionally, they’re considering many APIs to ensure security at the framework level and make development easier for developers.

We could see that they still don’t support many features that Smart Phones support. Actually, to support features like Cloud, projects in Connectivity or V2X EG need to progress and mature quickly.

Graphical API has achieved the roadmap in many areas, but they’re also considering transition from the current QT to something else.