Vroom!

  • 382 views
Uploaded on

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 …

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.

More in: Automotive
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
382
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
3
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Vroom, vroom, ctrl-x, ctrl-sConcrete progress between theAutomotive 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 were talking about is an In-Vehicle Infotainment (IVI) system that runs on a head unit, were 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