Linux

in "In-Vehicle Infotainment" Systems

Motivation & Goals


  • Linux IVI are essentially driven by OEMs to 
    • reduce development costs dramatically
    • speed up innovation and time to market
    • enable faster technology update
  • Linux is an open-source operating system and therefore
    • free available
    • free of license fees
  • Increase the amount of re-usable software modules
  • Derive from existing software modules and adapt it to project-specific needs
  • Inspire open-source community to develop applications based on Linux
  • Bring together automotive with consumer electronics activities

Open-source software collaboration


  • Linux IVI systems are usually developed in collaborations to bundle and align open source activities
  • Collaboration members are
    • OEMs
    • Software suppliers
    • Hardware and middleware suppliers
  • Important initiatives are
    • GENIVI
    • Automotive Grade Linux



Beyond the operating system


  • Standardization of application layer interfaces
  • Alignment of requirements
  • Provisioning of reference implementations and proof-of-concepts
  • Common solutions for cross-cutting functionality needed, e.g.:
    • Log & Trace
    • Diagnosis
    • Startup / Shutdown
  • Application and/or HMI framework required
  • Common Middleware (IPC) solution required for well-defined data exchange between applications
  • Definition of a software development process
  • Tooling support (Configuration management, SW Design Tools, Development GUIs, etc.)

Genivi software functional units

Expert Groups (1/2)

Automotive
Diagnostic Log and Trace, Software Management, Virtualization, CAN-based networking
Connectivity
Bluetooth, Media Playback, Audio Processing, DLNA, Smart Device
HMI & Application Framework
HTML5, PlugIn Architecture, Pop-Up Management, Speech Interface
Location-Based Services
Positioning, Navigation, Traffic Provider, POI Provider

Expert Groups (2/2)

Media & Graphics

Audio Manager, Layer Manager, Graphics Back End Server, Web and Radio Tuner, Graphics API
Networking
Browser, Data Transfer, Ethernet, Inter Node Communication
System Infrastructure
Lifecycle, Persistence, User Management & Personalization, IPC, Franca IDL, Common API

Intellectual Property


Licensing

  • Development department must be supported by legal department
  • The license model of used open-source software must be understood and applied correctly

Unique Selling Points
  • Differentiation of unique features is more difficult in a system with standardized interfaces
  • Look and feel might be predetermined
  • Difficult and tedious process to extend standardized interfaces for proprietary needs

Hardware & OS Support


  • Experts are needed to port Linux Kernel to underlying hardware and processor architecture
  • Often unclear who will provide driver, if not already provide by hardware supplier
  • Since Linux Kernel has no determined Driver API, driver adaptations might be necessary from release to relase
  • Powerful tools needed for monitoring CPU usage, RAM consumption, scheduling, etc.
  • Who provides non-functional software modules such as middleware or application framework?

Integration


  • Integration of complete software stack has a high complexity, due to amount of software modules and suppliers
  • Coherent process and tooling necessary to cover entire software lifecycle from requirements management to system testing
  • Formal description of interfaces required in order to
    • generate re-occuring code (such as control & data flow)
    • decouple logical interface from technical details
    • compare real-life behavior with specification
    • create a homogeneous system architecture
    • establish a common system understanding for all stakeholders (architect, requirement manager, project leader, developer)
  • Software development process must be defined with a supporting tool environment

Experiences from Genivi


  • OEM has different goals than supplier
    • OEM wants to re-use available software modules
    • Supplier wants to re-use software modules in different platform and OS environments
    • Each supplier has already APIs for the functional units, which then needs to be adapted
  • Overall software is very unhomogeneous
  • Most supplier use legacy code, that is not natively implemented for running under Linux, but also under different operating systems
  • Several frameworks and IPCs mechanism do co-exist
  • Lots of adaptor layers are implemented
  • Interface definition is very time-consuming and unefficient

Android as competitor


  • Android is based on a Linux Kernel, but also provides
    • additional libraries
    • runtime
    • application framework
    • development environment (Eclipse-based Android SDK)
  • Open-source community is used to Android App development
  • User is familiar with look & feel from Android Apps by Smartphone and Tablet
  • Android can replace Linux or co-exist
Made with Slides.com