WIND RIVER®

HELIX COCKPIT

SYSTEM ARCHITECTURE

1.0

Copyright Notice

Copyright © 2017 Wind River Systems, Inc.

All rights reserved. No part of this publication may be reproduced or transmitted in any form orby any means without the prior written permission of Wind River Systems, Inc.

Wind River, Simics, Tornado, and VxWorks are registered trademarks of Wind River Systems,Inc. Helix, Pulsar, Rocket, Titanium Cloud, Titanium Server, and the Wind River logo aretrademarks of Wind River Systems, Inc. Any third-party trademarks referenced are the propertyof their respective owners. For further information regarding Wind River trademarks, please see:

www.windriver.com/company/terms/trademark.html

This product may include software licensed to Wind River by third parties. Relevant notices (ifany) are provided for your product on the Wind River download and installation portal, WindShare:

http://windshare.windriver.com

Wind River may refer to third-party documentation by listing publications or providing links tothird-party websites for informational purposes. Wind River accepts no responsibility for theinformation provided in such third-party documentation.

Corporate Headquarters

Wind River500 Wind River WayAlameda, CA 94501-1153U.S.A.Toll free (U.S.A.): +1-800-545-WINDTelephone: +1-510-748-4100Facsimile: +1-510-749-2010

For additional contact information, see the Wind River website:

www.windriver.com

For information on how to contact Customer Support, see:

www.windriver.com/support

Helix Cockpit

System Architecture, 1.0

11 January 2017

Contents

1 System Architecture ............................................................................................... 1Helix Cockpit System Architecture Overview ..................................................................... 1

Wind River Linux ................................................................................................................ 2

Helix Cockpit ...................................................................................................................... 3

Connectivity Framework ..................................................................................................... 3

IVI Stack ............................................................................................................................. 5

meta-ivi (GENIVI) ............................................................................................................... 5

Board Support Packages and Hardware-Specific Functionality ......................................... 6

Security .............................................................................................................................. 8

2 Connectivity Framework ......................................................................................... 11Connectivity Framework Overview ..................................................................................... 11

In-Vehicle Network Overview ............................................................................................. 12

Automotive Broker .............................................................................................................. 13

Messaging Pattern ............................................................................................................. 14

Message Payload ............................................................................................................... 15

Quality of Service ............................................................................................................... 15

Fault Tolerance .................................................................................................................. 15

Last Known Good State ..................................................................................................... 16

Security .............................................................................................................................. 16

Helix Device Cloud Overview ............................................................................................. 17

iii

Wind River Helix CockpitSystem Architecture, 1.0

iv

1System Architecture

Helix Cockpit System Architecture Overview 1

Wind River Linux 2

Helix Cockpit 3

Connectivity Framework 3

IVI Stack 5

meta-ivi (GENIVI) 5

Board Support Packages and Hardware-Specific Functionality 6

Security 8

Helix Cockpit System Architecture Overview

Wind River Helix Cockpit is a software platform adapted for in-vehicle infotainment (IVI),vehicle telematics, digital instrument cluster systems, and the Internet of things (IoT) on selectedreference targets.

The Helix Cockpit platform is aligned with GENIVI specifications and includes Wind River IPand third-party software components. The platform is based on the Yocto Project open sourcedevelopment infrastructure that provides templates, tools, and methods to create custom systemsand software development kits (SDKs) for embedded products.

Using Wind River Linux as the base system, Helix Cockpit adds the following functionality:

• board support packages (BSPs) and hardware-specific functionality

• an in-vehicle infotainment (IVI) stack aligned with GENIVI specifications

• connectivity framework

• security features

The Helix Cockpit software is installed as an additional profile to Wind River Linux.

1

Helix Cockpit is structured as follows:

Wind River Linux

Wind River Linux is a software development environment used to create optimized Linuxdistributions for embedded devices.

Wind River Linux is based on the Yocto Project implementation of the OpenEmbedded Core (OE-Core) metadata project and the Linux long term support initiative (LTSI) kernel. The YoctoProject uses build recipes and configuration files to define the core platform project image andthe applications and functionality it provides.

Wind River Linux builds on this core functionality and adds Wind River-specific extensions,tools, and services to facilitate the rapid development of embedded Linux platforms. Thisincludes support for Yocto Project build commands to help reduce your development time.

Wind River Linux provides development environments for a number of host platforms andsupports a large and ever-growing set of targets.

The build system consists of a complete development environment that includes acomprehensive set of standard Linux run-time components, both as binary and source packages.It also includes cross-development tools that enable the configuration and build of customizedrun-time systems and applications for commercial-off-the-shelf (COTS) hardware.

For information on the Yocto IVI project, see the Yocto Website (IVI page) .

For information on the Linux LTSI kernel, see the Linux LTSI Website.

For more information about Wind River Linux, see the Wind River Linux documentationavailable from the Wind River Knowledge Library.

Wind River Helix CockpitSystem Architecture, 1.0

2

Helix Cockpit

The Helix Cockpit base system uses Wind River Linux as the underlying build and target filesystem. The Helix Cockpit image is based on the poky-ivi-systemd specific distribution data setsas required by the in-vehicle infotainment (IVI) stack.

The Helix Cockpit layer structure is as follows:

For a list of Helix Cockpit layers, see the Wind River Helix Cockpit Platform Developer's Guide.

Connectivity Framework

The Helix Cockpit Connectivity Framework enables development of an end-to-end connectivitysolution from sensors to the cloud with dedicated owned automotive protocols, a vehicle-to-cloud connection, and vehicle services to backend servers.

Helix Cockpit provides secure embedded and cloud-based development environments with thefollowing connectivity framework to enable in-vehicle connectivity, Internet connectivity,multimedia streaming, and vehicle status reporting:

1 System ArchitectureHelix Cockpit

3

Consumer electronic device (CED) link

Connects phones, media players, and tablets to the IVI system.

Extra-vehicle link

Connects the vehicle to the cloud and the Internet.

In-vehicle link

Connects electronic control units (ECUs) such as engine, transmission, brake, and speedcontrol modules to the IVI system.

User interface (UI) link

Connects Helix Cockpit components to various UI frameworks such as HTML5, Qt, andAndroid.

The link interfaces are as follows:

For more information on Connectivity Framework, see Connectivity Framework Overview onpage 11.

Wind River Helix CockpitSystem Architecture, 1.0

4

IVI Stack

The IVI stack contains components from the GENIVI stack and additional components fordevelopment purposes such as Qt5 for human machine interface (HMI) development.

meta-ivi (GENIVI)

The GENIVI architecture essentially defines an in-vehicle infotainment (IVI) system.

The specification is component-based and consists of a mixture of components defined byrequirements (Placeholder components), behavior or application programming interface (Abstractcomponents), and by an existing code base (Specific components).

The Placeholder and Abstract component types may have a proof-of-concept or a referenceimplementation code base associated with them but their usage is not mandated and theimplementations can be either open source or proprietary. The Specific type components, whichare OSS components, must use the code as specified. The following diagram shows the overalldesign with component groups that are present in the GENIVI specifications. Wind River HelixCockpit is currently aligned with the GENIVI 10.0 specification.

The Yocto layer for IVI (meta-ivi) contains the GENIVI components that have associated open-source software (OSS) code. As of the GENIVI 10.0 release, the components are as follows:

1 System ArchitectureIVI Stack

5

For more information on GENIVI, access the GENIVI Website and the GENIVI Wiki.

Board Support Packages and Hardware-Specific Functionality

The board support packages (BSPs) and hardware-specific functionality consist of hardware-dependent packages and drivers to support development.

The packages and drivers support the following functionality:

• target boot

• accelerated graphics

Wind River Helix CockpitSystem Architecture, 1.0

6

• accelerated multimedia codecs

• platform-dependent plugins for in-vehicle infotainment (IVI) functions, custom compositors,and so on

Intel Software Layers

The Intel software layers, apart from providing hardware dependent patches, also add softwarelayers and enhancements unique to the Intel architecture. The Intel software layers include thefollowing:

• automotive boot loader with secure boot

• Wayland compositor optimized for the Intel platform and customized for automotiverequirements

• audio management

• audio video bridging (AVB)

The Intel software layers are as follows:

For a list of Helix Cockpit layers, see the Wind River Helix Cockpit Platform Developer's Guide.

1 System ArchitectureBoard Support Packages and Hardware-Specific Functionality

7

Security

Helix Cockpit security is a set of platform components, tools, and documents to develop, test, andenhance the security of in-vehicle infotainment (IVI) platforms.

Helix Cockpit is based on Wind River Linux and relies on the Wind River Linux Security Profile(SCP).

Helix Cockpit includes the following security features:

• security-enhanced Linux (SELinux) as the role-based access control (RBAC) mechanism

• polyinstantiation to protect against several types of security attacks

• default multi-level security (MLS) policies

• open security content automation protocol (OpenSCAP) tool

• additional policy tools

The security component layer structure is as follows:

The overall security strategy is shown in the following diagram.

Wind River Helix CockpitSystem Architecture, 1.0

8

The processes are isolated with standard features of the Linux kernel (using containers) and withminimal system resources required for the functionality visible to these processes.

The containers and the underlying system are secured by the MLS policies. This concept providesnecessary building blocks for designing and enhancing the security hardened system whilegiving maximal flexibility to the system architect and designer. The networking interfaces can beprotected with standard Linux firewall functions.

1 System ArchitectureSecurity

9

Wind River Helix CockpitSystem Architecture, 1.0

10

2Connectivity Framework

Connectivity Framework Overview 11

In-Vehicle Network Overview 12

Automotive Broker 13

Messaging Pattern 14

Message Payload 15

Quality of Service 15

Fault Tolerance 15

Last Known Good State 16

Security 16

Helix Device Cloud Overview 17

Connectivity Framework Overview

Helix Cockpit offers a service oriented architecture (SOA) that abstracts the underlyingcomplexity of the multiple and evolving automotive and Internet of things (IoT) protocols andtechnologies.

The Helix Cockpit SOA facilitates the cooperation of services across vehicle electronic controlunits (ECUs) and reduces inter-component dependencies in the system. The result is amanageable, loosely coupled software platform that enables software reuse, improves softwaremanagement, and eases deployment across architectures.

The SOA architecture extends beyond the vehicle by providing the basic software elements thatestablish a secure and managed communication channel to cloud infrastructures. The HelixCockpit SOA is implemented through the Connectivity Framework. This framework leverages aset of IoT technologies that Wind River adapted for automotive use cases.

The basic Connectivity Framework architecture is as follows:

11

Within a vehicle, the automotive broker manages communications between services running ondifferent ECUs within the system. Each service is abstracted through an applicationprogramming interface (API), and each inter-ECU exchange is authenticated and encrypted.

The automotive broker, through a vehicle abstraction API, is able to filter out the data andcommands to be exposed to the outside world. The communication channel to the cloudinfrastructure is managed through the automotive Helix Device Cloud (HDC) agent and backendservices to provide device and data management.

Each vehicle is individually connected to the backend through a peer-to-peer, secure andencrypted communication channel. On the backend side, the software as a service (SaaS)framework of HDC allows the original equipment manufacturers (OEMs) to implement theirspecific services. OEMs have full access and control over the data and commands.

In-Vehicle Network Overview

The Helix Cockpit in-vehicle network interconnects sensors, actuators, user interfaces, and smartdevices to provide a networking infrastructure to acquire data, enable device control, provide

Wind River Helix CockpitSystem Architecture, 1.0

12

vehicle status, and communicate with off-premise data servers over the Helix Cockpit extra-vehicle network.

Automotive Broker

The Helix Cockpit Automotive Broker is based on the OASIS Standard Message QueuingTelemetry Transport MQTT v3.1.1 specification.

The Wind River implementation of MQTT offers additional features and optimizations for theautomotive use cases. The implementation provides compatibility with automotive-specificcommunication buses such as the controller area network (CAN) bus, or links to inter-processcommunication (IPC) mechanisms within the in-vehicle infotainment (IVI) system such as dBus,through proprietary protocol adapters.

The following figure shows an example implementation of a vehicle electronic architecturecontaining three ECUs:

• a vehicle controller

• a gateway

• an IVI unit

The vehicle controller is connected over a CAN bus interface to the gateway, while the IVI unituses Ethernet to connect to the same gateway.

For information on the MQTT specification, see the OASIS Website.

2 Connectivity FrameworkAutomotive Broker

13

Messaging Pattern

Communication between services across the Connectivity Framework architecture follows apublish-subscribe messaging pattern.

Once registered and authenticated to the automotive broker, services can publish messages to thecommunication bus, or subscribe to messages sent by other services.

The automotive broker ensures the interconnection between services and is responsible fordistributing messages to interested and authorized clients based on message topics. Topics areorganized as a tree, and a service can subscribe to any node in the tree, allowing it to receive anymessage of subtopics from the specific node. To achieve this, two wildcards are defined:

• the # character allows a client to subscribe to a complete sub-tree

• the + character can be used as a wildcard for a specific node in a tree hierarchy

The following example shows a topic organization for a media player service. A client, such as amedia player application, can subscribe to the /IVI/Media/CurrentlyPlaying/# topic. Theapplication will receive messages published to one of the sub-elements of the /IVI/Media/CurrentlyPlaying/ tree.

Topic Scheme:[ECU]/[SERVICE]/[ENDPOINT]/../[TYPE]/IVI/ Media/ CurrentlyPlaying/ Artist/string/ Album/string/ Song/string/ Cover/png/ Elapsed/int Duration/int PlayingState/ Status/int Request/int

While the topic organization can be customized, the actual structure is used to assign specificread/write rights to each service. The topic often reflects the electronic architecture across thesystem and the security isolation of the different elements of the software architecture.

When a broker is acting as a bridge and hence acting as a client for other brokers, the broker canupdate message topics published upstream with a predefined prefix. Topics such as:

[ECU]/[SERVICE]/[ENDPOINT]/../[TYPE]

translate to:

[CAR_VIN]/[ECU]/[SERVICE]/[ENDPOINT]/../[TYPE]

Wind River Helix CockpitSystem Architecture, 1.0

14

Message Payload

The message payload represents the actual data content of a message. The Helix CockpitConnectivity Framework is entirely data-agnostic. It is able to transport data in any form such asbinary, text, encrypted, and json. However, for controller area network (CAN) and dBus bridges,the data payload is encoded as json.

Quality of Service

A quality of service (QoS) level is associated with each message in the system, and fullyimplements the Message Queue Telemetry Transport (MQTT) protocol specification.

There are three levels of QoS:

QoS 0 (At Most Once)

Used at most once, this message is delivered according to the best effort of the underlyingoperating system. Message loss can occur.

QoS 1 (At Least Once)

Used at least once, this message is guaranteed to be delivered, but duplicate delivery of themessage is possible.

QoS 2 (Exactly Once)

Used exactly once, this message is guaranteed to be delivered only once.

The level of QoS is chosen for each message delivery, allowing the system designer to adjust atradeoff between QoS levels and system performance.

Fault Tolerance

The Helix Cockpit Connectivity Framework uses the last will and testament (LWT) feature of theMessage Queuing Telemetry Transport (MQTT) protocol to ensure the system will be able todetect and manage potential failures of service.

The LWT feature of MQTT is used to notify clients of the broker about an ungracefuldisconnection of another client. Through this feature, the client can instruct the broker to publishon its behalf a message on an arbitrary topic whenever the broker detects an abnormaldisconnection. When this happens, all clients subscribed to this topic will receive the messageand may decide to take counter-measures.

2 Connectivity FrameworkMessage Payload

15

Last Known Good State

The Connectivity Framework uses the Retained feature of the Message Queuing TelemetryTransport (MQTT) protocol to prevent delays in communicating topic values to clients.

Because of the asynchronous nature of the Helix Cockpit Connectivity Framework, you canencounter situations where clients subscribed to a given topic might have to wait to get an actualvalue on the topic.

This situation might happen, for example, when a client subscribes to a topic just after a value hasbeen sent to the topic. In this case, the client is not made aware of the topic value until thepublisher sends a new value to the same topic. To ensure that each client, upon subscription to atopic, immediately receives the latest known good value for the topic, the ConnectivityFramework uses the Retained feature of the MQTT protocol.

Each message sent to the broker contains a Retained flag in its header. When the Retained flag isset, the value of the message is kept in persistent memory and the broker relays the message toany new client that subscribes to the topic. The broker is effectively maintaining a last knowngood state for the topic.

Security

The Helix Connectivity Framework provides a communication backbone for services locatedacross different electronic control units (ECUs) of the vehicle. However, some sensitive servicesmust be protected against unauthorized access from other services.

Through the Connectivity Framework, each service must identify itself to the broker, and aspecific set of permissions can be set for each topic and for each user. As a designer, you canrestrict the usage of a specific topic to a specific list of users, in both directions (publish /subscribe).

In addition to this restriction, the actual message payloads can be individually encrypted, thusminimizing the risk of man-in-the-middle attacks. When using encrypted messages, only theauthorized publisher and subscriber of the message can interpret the message content. Thebroker itself cannot observe or decrypt the payload, and the encryption process is totallytransparent to the broker.

When setting up the chain of trust for the encryption and decryption of messages, a systemdesigner must ensure that the actual key used for the process is stored in secure elements on boththe publisher and subscriber sides. When a broker is acting as a bridge and hence acting as aclient for other brokers, the broker can select which message topics can be exchanged with theupstream broker.

Wind River Helix CockpitSystem Architecture, 1.0

16

Helix Device Cloud Overview

With the proliferation of connected devices in the Internet of things (IoT), Wind River HelixDevice Cloud (HDC) provides the ability to deploy, monitor, manage, service, update, anddecommission IoT devices.

As an IoT device management platform, HDC connects machines and devices, manages andcollects machine-generated data, and enables you to quickly and securely improve operationalefficiencies.

With HDC, you can easily build device management capabilities into IoT solutions to overcomechallenges associated with device lifecycle management and reduce the complexities of buildingand providing large-scale device deployments.

HDC enables you to do the following:

• easily collect, manage, and integrate data from disparate devices, machines, and systems

• protect data in transit with a secure, scalable, and customizable on-demand infrastructure

• remotely configure, monitor, and update connected machines from a single managementconsole

• streamline the management of a multitude of IoT devices when provisioning, configuring,and monitoring services

While HDC is optional for Helix Cockpit, Helix Cockpit is pre-integrated with a HDC agent.

For more information on HDC, see the HDC documentation available from the Wind RiverKnowledge Library.

2 Connectivity FrameworkHelix Device Cloud Overview

17

Wind River Helix CockpitSystem Architecture, 1.0

18