In the last few years, a seismic shift has taken place in the automotive infotainment industry, going from proprietary solutions to open source platforms and collaboration. In this talk, we discuss some of the key challenges and their technical solutions, but also what lays ahead – how can we learn from automotive and bring open source collaboration to other industries. This talk will take you from electrical engineering to stunning user interfaces packaged in one of the most expensive consumer electronics devices on the market – cars.

1. Tech Day by Init // Stockholm 2017-11-30
Open Source on Wheels
Luxoft Digital Cockpit

2. Introduction
 Johan Thelin, System Architect at Luxoft
 Qt Champion, Foundations of Qt Development, QmlBook, Pelagicore, Nokia Qt Development
Frameworks
 Embedded Linux for 10+ years, LinuxJournal, Datormagazin, LinuxMagazine.de
qmlbook.org

3. • 200+ visitors
• 15+ speakers
• All about free and open source
• Hosted in Gothenburg
• April 23 – Save the Date!
foss-north 2018

4. In-Vehicle Infotainment

5. Automotive Challenges
 Length of projects
 Size of projects
 Complex supplier relationships
 Purchasing processes
 …
 Sudden loss of power
 Boot time requirements
 Aborted shutdown
requirements
 FLASH wear
 Latency requirements
 Expected life of product

6. Legal Challenges
 There is a difference between building a
screen into a car and bringing a screen into
the car
 Safety requirements
 Driver disruptions
 Driver workload management
 Driven by liability and legal requirements

7. Start-up Timing
START

8. Start-up – Example Figures
 Boot splash
 Available on networks
 Rear view camera
 Basic contents (radio tuner, media, phone)
 Complex contents (navigation, web, 3rd party apps)
~100ms ~ 1000ms ~ 2000ms ~ 4000ms ~ 10000ms

9. Start-up – Aborted Shutdown
START
STOPSTART

10. Start-up – Sudden Loss of Power
START

11. FLASH…
 Vehicles are meant to run for at least 15
years…
 Part prices push FLASH sizes down
 Meaning that wear increases
 Complicated by software updates and
reliability (never brick a car)
 This is a real challenge!

12. Multiple Parallel Interaction
Interfaces
 Knobs and buttons
 Touch
 Speech
 Rear-seat controls
 Paired devices
 …

13. Latency Requirements
 Timescale: 60 fps means around 16ms per frame
 Latency requirements are in the region of 100ms for good UX
 Handling events over shared busses, e.g. LIN, CAN, FlexRay
 Ensuring performance in the device
 Some events might need to be signaled further, e.g. shared with
an instrument cluster or heads-up display

14. Functional Safety
 ASIL, ISO26262
 Software development process requirements
 You might kill someone!
 Do not confuse, disturb or present the wrong information
 Autonomous vehicles takes this even further – handing over the car
to the driver in time is critical

15. Open Source Stacks
 There are two major open source efforts in the IVI space
 GENIVI
 AGL (Automotive Grade Linux)
 GENIVI defines a standard automotive platform
 Identifying existing components
 Developing components to fill the gaps
 Comes from Autosar – changing to code first now
 AGL does the same thing but within Linux Foundation
 Both project build demonstrator/development platforms

16. Qt Automotive Suite + PELUX
 Preintegrated Linux reference platform
 GENIVI + selected open source stacks +
QtAuto
 Prebuilt for selected targets with public CI
pelux.io
 Unified UX across all screens in the vehicle
 Framework to enable apps
 Supports 2D, 3D, Wayland, multi-touch,
gestures...
qt.io

17. A Word on Licenses
 We’re targetting a device with wheels
 The device is a part of a complex vehicle
network where failures can lead to fatal
injuries
 The industry is extremely cautions when it
comes of (L)GPLv3
 Signed target images
 You cannot reflash your car

18. Architecture Trends
Monolith
Skin
Service
Skin
Platform
Service Service

19. Architecture – Next Step?
Service
App
Platform
Service Service
Service
Skin
Platform
Service Service
App
System
UI

20. Architecture Trends
 Move to a smaller “main” project
 More contents packaged in a reusable
way
 Easier to add “real” contents during
the 15 years in the field (20 years
counting the development project!)
Service
App
Platform
Service Service
App
System
UI

21. Supplier Structure
OEM
T2 T2
T3T3
T4
T3
T1

22. Supplier Structure
OEM
T2 T2
T3T3
T4
T3
T1
Requirements
Liabilities
Processes
PriceStructure

23. Requirements – Too Many and Too Few
 Often focused on “micro controller level”
 Hardware integration
 Really detailed timing
 Continues at high level higher in the stack
 “The CD player shall retry reading 3 times upon encountering errors”
 With gaps
 “HTML5 Compliant Web Browser”
 This makes adoption of open source really hard because
changing requirements requires a commercial discussion

24. Open Source This?
OEM
T2 T2
T3T3
T4
T3
T1

25. Open Source This?
OEM
T2 T2
T3T3
T4
T3
T1

26. GENIVI
 Consortium of OEMS and Tns
 Pushing open source top down
 Jointly building the platform from
the bottom
OEM
T2 T2
T1
Service
App
Platform
Service Service
App
System
UI

27. Learnings
 Solve common problems and share it through open source
 Identify common ground, e.g. the common base platform
 Discuss common problems openly, e.g. what components are missing
 Reserve space for differentiation
 Focus on components rather than everything
 Define a common architecture, e.g. Works with Xyz

28. Learnings
 Understand how licenses work and what is compatible with your
industry
 Try to avoid requirements used to exclude existing components
 This is just a form of not-invented-here
 Code first

29. I’d like to Extrapolate
 Automotive accepts Linux now
 It is not being used higher up in the stack, e.g. for functions
 What is holding is back?
 Media – codec licensing
 Bluetooth – interoperability testing
 SIL – process related, incompatible with community driven projects
 These are not engineering problems – they can be challenged!

30. Thank you for your attention!
jthelin@luxoft.com
We are looking for talent!