Vroom, vroom, ctrl-x, ctrl-s

Concrete progress between the Automotive industry and FOSS

Jeremiah C. Foster• A bit about myself . . .

• Background in Open Source and Free Software.

• Worked for Nokia as the Maemo debmaster

• Participated in the MeeGo IVI working group

• Baseline Integration Team Lead in GENIVI

• Long time Debian user and contributor (not a DD, yet.)

Running emacs on your car

Now that Linux is mainstream, how do we ensure that our new car is running FOSS like the rest of our devices?

It turns out that the car makers would like to have an answer to that question as well and they occasionally look to FOSS for the answer.

Defining our expectations

What we're talking about is an In-Vehicle Infotainment (IVI) system that runs on a head unit, we're not talking about what powers the ECU per se.

The IVI system is not a phone on wheels. It is not enough to just take a standard system that uses a Linux kernel and stuff it into a car.

Automotive is different 1

You would think that an automotive system should be able to simply plug-in its APIs to Linux subsystems and have a working system, but this is sadly not the case. In fact, there have been years and years of software development on sophisticated realtime POSIX compliant platforms that can provide DTS and 5.1 audio, even 7.1 audio to play things like DVDs (in a car!)

Automotive is different 2

In addition, automotive has a much different set of hardware to support. Things like;

Tuners and software defined radio in a DSP on the main board

Silicon vendors that work mainly in the automotive market

Third party hardware like authentication chips that are pretty much a requirement

Automotive is different 3

Along with different silicon and hardware components, there are different network buses. CAN (Controller Area Network) is one such bus.

From wikipedia; “CAN bus is a message-based protocol designed specifically for automotive applications but now also used in other areas such as industrial automation and medical equipment”

No intrinsic security features. Hack a luxury car anyone?

Automotive is different 4

Business relationships are fundamentally different as is the business model. There are established participants who have traditional partnerships and markets that are very segmented.

A well defined hierarchy is already in place with OEMs, Tier 1s, etc. Difficult to be a start-up car company (ask Tesla.)

Automotive is different 5

• There is a fundamentally different regulatory environment surrounding a motor vehicle. Safety is obviously a prime concern.

• This safety focus has an impact all the way up the application stack, not just on the driver systems or on the safety critical systems like brakes.

• What happens if some app downloaded from the internet suddenly increases the volume on the head unit? Who is responsible?

Automotive is different 6

• If there is a great deal concern about safety, and there is, you can understand that the car makers might want to prevent a user from changing the software on their car.

• Yet people do this already since automotive electronics are throttled and if you change the firmware on your high powered car you can get significantly faster speeds which might make you significantly more dead.

• Car makers feel it is imperative, given the legal environment, to lock the firmware and even IVI software in such a manner as to make the GPL v3 a license non-grata.

Change afoot

There is a change afoot however and their are opportunities for new companies

Car makers would like to recoup some of their investment in software development. They are insisting that they actually own the software delivered and can reuse it.

To do this they’re separating software and hardware in a typical IVI unit, something that traditionally is not done. Usually you buy an IVI hardware platform and get software included.

Open Source to the rescue

Yet very often, automakers re-wrote IVI systems, sometimes from scratch each time there was a new model. There is very little software re-use.

This is something that FOSS (Free Open Source Software) can help with immediately. Code reuse is a tenet of FOSS and will allow car makers to save significant costs on software development.

Standardization

There is traditionally an understanding of the benefits of standardization, at least across car platforms; experience of common component integration. The automotive industry also has standardization bodies, like Autosar, that create a set of open standards for automotive electrical systems

The old joke still applies however; the good thing about standards is that there are so many to chose from.

Standardization continued

• Automakers have an affinity for standardization and some of them have joined with companies like Intel, ARM holdings, and others to create GENIVI

GENIVI® is a non-profit industry alliance committed to driving the broad adoption of an In-Vehicle Infotainment (IVI) open-source development platform.

The alliance aims to align requirements, deliver reference implementations, offer certification programs, and foster a vibrant open-source IVI community.

Note the “open”

• a vibrant open-source IVI community.

• This means that they understand, to a good degree, how it works. They contribute code into the open directly upstream. They take code directly from upstream and from open source.

• While the traditional automotive development model makes them cautious, they have in fact contributed quite a bit to open source.

• I’ll try to detail some of those projects and how you can get involved

What comes from GENIVI

• Fastboot, in a variety of formats, is very interesting to car makers. You have to have your rear-facing camera available very quickly and that’s likely to be displayed on the IVI system screen, not necessarily the cluster instrument panel.

• So going from a system that is powered off, to showing video in less than two seconds (or faster) is close to a requirement.

GENIVI has done a lot of work in that area, comparing various booting systems and strategies, and has worked closely with the developer of systemd to make it into an automotive grade boot system

fastboot and LUC

Of course there are other implementations of fastboot, from proprietary to robust event based boot sytems.

GENIVI has already begun developing software around systemd however in the form of software tools like Last User Context (LUC.)

LUC creates the possibility for different users to have different settings in the car, and for the car to recognize the user and change the IVI system, and potentially seating and steering wheel, accordingly.

bluez

bluez is also something the car makers are interested in because it is already implemented in the kernel

Still lots of companies that would like to sell a proprietary stack

Still lots of opportunity to contribute to bluez and test with different hardware, build out more profiles, and generally ensure bluetooth works well with IVI software and Linux in general.

connman

There is lots of debate in various GNU/Linux distributions on how to create network management software for mobile users. Network Manager has recently been unbundled as a required dependency for GNOME in Debian for example and there is a long flame^H^H^Hdiscussion on debian-devel as to what is the best tool for the job.

Connman is widely seen as being appropriate for automotive and works well with bluez (and ofono) and being an open source project there is lots of room for cooperation

ofono

ofono is a project that was founded by Intel and Nokia and is also an open source project.

It too provides some key functionality for an automobile and works hand in glove with connman and bluez

Open source

data persistency

Creating an effective way to store a user’s music playlist and pulling up that data again is a key area that does not have a specific solution yet.

There are a number of mechanisms and configurations of existing tools

Work around doing this type of operation effectively is a very interesting area for car makers and something that the open source community would likely have good input on since we have experience

kdbus

GENIVI has contributed a patch to the Linux kernel to improve the speed of DBUS. DBUS is widely used, sometimes incorrectly used as IPC. systemd uses DBUS

Meant to be a resource locater, not IPC

GENIVI patch moved DBUS into the kernel limiting the duplication of messages, no need to send to the bus, then the kernel, then the bus. Increase of 2x.

Despite some support the kernel patch has not been accepted by the network subsystems maintainer

Automotive Hardware

Automotive hardware can be difficult to find, especially development platforms. It is expensive to produce platforms that contain all the needed components and peripherals that support automotive software in an industry that does not have the same mass market scale as mobile telephony for example.

You can purchase boards from Texas Instruments, the Jammer for example. Intel also makes development hardware.

Pandboard is a good and inexpensive alternative

More Hardware

Freescale also produces a development board called the quick start board.

Currently iMX 53 but coming out with a powerful iMX 6

Toyota’s initiative to create a “reference” board is of course interesting and is meant to have a sub $500 US price point

Renasas creates automotive hardware and has existing relationships with OEMs

Which distro?

• Choice of distro is always a loaded question. People have their favorite distro and you nearly need to include your software in _every_ distro to get people to work on it.

• There is a need though for an automotive specific distro, that is plain

• Ubuntu IVI, Tizen IVI, Yocto’s meta-ivi layer, and potentially others all provide a type of “baseline” that can provide an open collaborative platform today.

What about my distro?

• It is hard to ensure that every distro is supplied with automotive software. Part of that job is up to the distro maintainers because the distros have very specific ideas about how to construct a coherent OS.

• Sometimes those dependency chains conflict with choices made in GENIVI. Think Upstart vs. systemd (or openrc for that matter.)

• What is the best way to ensure the greatest coverage?

HMI For many car makers the major differentiation will

come in the user interface and the apps that will being integrated into it

Which application framework will be used? Yes. All of them. Proprietary graphics stacks

will take advantage of proprietary proprietary drivers, but there is interest in Englightenment in Tizen and some Tier 1s contribute to GTK.

Qt IVI is also a workable solution (shameless plug)

__END__

obd (on board diagnostic)

LIN (Local interconnect network) How are those drivers in Linux?

flexray is faster and more flexible than CAN, but also more expensiveQt in IVI

Enlightenment in Tizen

Distros, AGL, Yocto, Tizen, Ubuntu IVI respin

mirrorlink and the CCC

kdbus patch, other GENIVI software