How do we integrate FOSS into the automotive environment? Its not as cut-and-dry as one might assume, the automotive industry has entrenched processes as well as some seriously complex software designs and requirements. But it is possible and I'll point out areas where work needs to be done and where work has been done in this presentation.

1. Vroom, vroom, ctrl-x, ctrl-s
Concrete progress between the
Automotive industry and FOSS

2. 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.)

3. 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.

4. 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.

5. 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!)

6. 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

7. 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?

8. 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.)

9. 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?

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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

16. 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

17. 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.

18. 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.

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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.

26. 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?

27. 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)

28. __END__

29. 
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