print

Connected Car Gets Into Gear with Linux

At the beginning of this year the open source project Automotive Grade Linux announced a Unified Code Base distribution. Caroline Hayes finds out what it will mean for the automotive industry.

Automotive Grade Linux (AGL) is an open community of developers, OS vendors, semiconductor vendors, system integrators, automotive companies and academia. All are collaborating on next-generation, in-vehicle software systems, and in particular the connected car and In-Vehicle Infotainment (IVI).

“Our membership base is not only growing rapidly, but it is also diversifying across various business interests, from semiconductors and in-vehicle software to IoT and connected cloud services,” observes Dan Cauchy, General Manager of Automotive at the Linux Foundation.

The project, founded in September 2012, is developing a common, Linux-based software stack for the connected car, within a collaborative, open environment and supporting ecosystem. Among the latest members to join are Oracle, Qualcomm Innovation Center, Texas Instruments, Continental, Toshiba Corporation, and bright box, a Vienna-based software company specializing in the connected car sector, and counting Nissan, KIA and Infiniti amongst its customers.

Figure 1: Linux-based infotainment systems have been designed into vehicles by Jaguar Land Rover, including the 2017 Jaguar XE (pictured).

Figure 1: Linux-based infotainment systems have been designed into vehicles by Jaguar Land Rover, including the 2017 Jaguar XE (pictured).

In January this year, the community announced a Unified Code Base (UCB) distribution. Integrating software components from AGL, Tizen, the ecosystem for mobile and connected devices, the GENIVI Alliance, and related open source code, into a single AGL Unified Code Base, allowing car makers to leverage a common platform from rapid innovation, says Cauchy.

Leveraging the Stack

The UCB distribution is customized to meet specific automotive requirements, and it is hoped it will be the de facto standard for the industry. Developers and vehicle manufacturers can leverage a Linux-based software stack to create in-vehicle software and to bring smartphone-like capabilities to the car.

AGL members Toyota, Fujitsu Ten, Panasonic, Pioneer and Renesas Electronics have announced that they plan to use the UCB distribution.

Initially, the distribution has been focused on IVI, but different profiles can be created from the same code base. It is expected to be used for instrument clusters, heads up displays, telematics, navigation, safety and security, as well as infotainment applications.

Showcasing some of the connected car’s options, Jaguar Land Rover uses a Linux-based information system. The 2016 XF model (Figure 1) has a reconfigurable 12.3-inch TFT instrument cluster and a 10.2-inch touch screen display on the infotainment system powered by a quad-core processor. For 2017, the XE has a 10.2-inch tablet-style touch screen InControl Touch Pro infotainment system, an Apple Watch app for remote functioning to check, for example, the fuel level, and a WiFi hotspot for up to eight devices.

Getting Past Monolithic

At TU-Automotive Detroit earlier this month, The Qt Company, an AGL member since September 2015, announced its Linux-based Automotive Suite software (Figure 2). The suite of automotive-specific components and tooling is designed to reduce development costs and shorten time-to-market.

Tero Marjamäki, Head of Automotive at The QT Company, explains that it is the first vertical offering for the automotive industry.

The same code is used in embedded Linux products again and again, he says, with APIs and capabilities being developed many times over. The company, in collaboration with open source software company Pelagicore and Qt developer KDAB, has selected automotive-specific APIs and capabilities, leaving developer resources free to develop features that differentiate the vehicle’s IVI.

One tool in the suite is the Application Manager. Marjamäki explains how it can separate APIs and capabilities, so that multiple teams can work on an application at their own speed, something which is not possible in a monolithic design. “Currently developers create an emulator and wait for the target hardware, now one click can activate deployment on target hardware,” he explains, to reduce the time-to-market. The suite also allows customers to develop their own software development kit.

Possibly the biggest trend seen by Marjamäki is that the connected car is software driven. Software allows for updates, even when the vehicle is in production and on the road. “Most software in the car is individual layers of a stack,” he explains. As complexity increases and the number of screens multiplies, the more complex requirements are balanced by the platform, “So there is no need to repeat basic software for the vehicle.” This has accelerated the development of IVI and the connected car. “We have seen more development in the automotive market in the last five years than there has been in 20 years with the mobile phone market,” he says. “[Development of] the smartphone was driven by hardware, which made way for software, and then cloud services were added. In the automotive space, these are all happening at the same time,” he says. As a result, multiple screens are used, and software navigation has to go across all of them. He believes this brings logic and harmony, as software developers only need to use one stack for a multi-screen experience. For the end-user, the different IVI systems have the same, familiar navigation, making them more intuitive and easier to use.

Figure 2: Automotive Suite v1.0 was developed by The Qt Company, with Pelagicore and KDAB, pooling automotive-specific components and tooling.

Figure 2: Automotive Suite v1.0 was developed by The Qt Company, with Pelagicore and KDAB, pooling automotive-specific components and tooling.

“More standardization, using the same stack, will accelerate development opportunities,” says Marjamäki. Systems will benefit from an ecosystem where the basis software requirements do not have to be re-engineered—they are already available. Standardizing basic functionality that doesn’t differentiate the vehicle accelerates Tier 1 and OEM development, allowing their teams to focus on differentiation, rather than low level, basic functions that are done in every program,” he concludes.


hayes_carolineCaroline Hayes has been a journalist, covering the electronics sector for over 20 years. She has worked on many titles, most recently the pan-European magazine, EPN.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis