addressing complexity in connected & autonomous...

25.04.2018

Addressing Complexity in Connected & Autonomous Vehicles (and in fact everything else…)

2 Addressing complexity in connected and autonomous vehicles

Contents

1 Context and Background

2 The Architecture

3 SOA & SOA++

4 SOA Connectivity Models

5 Summary

1. Context and Background

4 Context

The Context

Assured

Safety

Availability

Usability Civics

User

Awareness

In an increasingly connected and value adding environment

Functional Trend

Increased assistance Autonomy

5 Expectations

Expectations

Expectations

Assured Safety

Availability

Usability

User Awareness

Civics

Components

User Monitoring

Algorithm Mgmt

Failure Control

Lifecycle Mgmt

Connectivity

System/policy Update

System Monitoring

Energy Mgmt

Environment Monitoring

Orchestration

Diagnostics

Personalisation Inherent Complexity

How to structure?

6 Volume of software

And then there is the volume of software

Hubble Telescope

2M LOC

Mars Curiosity Lander

5M LOC

Android Phone

12M LOC

F-35 Fighter

25M LOC

Luxury Car

100M LOC

Where is this

figure going?

2. The Architecture

8 Hardware architecture

Moving the HW Architecture

Ad Hoc

Now Tomorrow

Benefits:

• Reduced cabling

• Reduced number of ECUs

• Induced reduced weight

• Reduced complexity

• More CPU capacity

Centralised Computing &

Zonal I/O

9 Management of software

The trick is in the Software Management

Compute Node Compute Node

Hypervisor Hypervisor

VM

Linux

VM

RTOS VM

Linux

VM

Android

What is the paradigm for software development and integration which

supports the economics of development and the need for vehicle level

integration against the inherent complexity?

High Bandwidth Networking

Service Oriented Architecture (SOA)

3. SOA & SOA++

11

So what is Service Oriented Architecture?

SOA is defined as a design pattern in which application components provide

services to other components via a communications protocol.

• It is a software design and software architecture.

• Service-orientation: Distinct pieces of software providing functionality as

services to other pieces of software.

• It is independent of any vendor, product or technology.

• Set of rules, guidelines, process and supporting artefacts.

SOA

12

SOA – 2 Perspectives

SOA perspectives

Compute Node Compute Node

Hypervisor Hypervisor

Domain

Virtual

ECU E.G.

ADAS

Domain

Virtual

ECU E.G.

Cluster

Non-

domain

Specific

Collection

of

Services

Non-

domain

Specific

Collection

of

Services

Full SOA Domain Centric

In practice full

SOA allows Domain

Centric instantiations

as a System Engineering

Choice

Partioning at Service level

offers advantages for

Safety, Security perf

tuning and increased

reuse

The transition to SOA can

be done incrementally.

13

Leading Questions beyond SOA

Questions beyond SOA

How does the system boot respecting

schedules?

How does my feature

leverage other features with common

semantics?

How does the system update without

‘Bricking’?

How do I maintain the safety case?

How do I tune performance? How do I access sensor data?

I need to signal an error – who to?

I want to create a system variant?

How do I use a new feature supplier

in an existing system?

How do I read my current

configuration?

How do I do system wide

error management? How do I pick and choose features at system build time?

Can I use connectivity simply?

14

The Paradigm Requirements: SOA++

SOA++ concepts

• Lego-based feature model

• Model based system engineering/Modelling collateral creation

• Bondage style development at syntax & semantics (API, and assumptions)

for ‘citizenship’ considerations

• COTS interactions with suppliers and ecosystem

• Increased certification against standards but also against platform definition

• Extended inventory management

• Security from specification to delivery

• Integration focussed system construction

• System ‘scripting’ support

• SW separated from HW procurement and integration

15

Concrete Architecture: SOA + System Aspects

Concrete SOA

Cross Domain Feature Platform

• Configuration

• Resource Map

• Standard Lifecycle

• End-to-end Security

• Performance tuning

• Diagnostics

• Standard Error

• Data Plane

• Feature Interaction Plane

• Arbitration

• Testability

• Deep reach connectivity

• Modular Safety Cases

• Declarative Policy

• COTS-style Integration

• Tooling

• Variant support

• SOTA/FOTA

P

R

O

C

E

S

S

T

O

O

L

I

N

G

CoherenSE®

16

Managing this complexity using CoherenSE®

CoherenSE® has been designed and developed specifically to address the

challenges of intelligent vehicles and machines complexities.

It is a software middleware layer and toolchain which sits between the operating

system and application layers in the software stack.

It brings SOA principles to the embedded world and consists of the following:

• A run-time library

• A Toolchain

• Documentation and training material

• A development process

It has been co-developed with Jaguar Land Rover.

CoherenSE

4. SOA Connectivity Models

18

SOA Connectivity Models

Connectivity models

Standard Connected Service Model

Unified Topology Model

Inter-topology Gateway Model

CoherenSE® Extend

3 models of wide distribution

allowing system engineers

options for trade-offs:

security, dynamicity,

performance, criticality, reuse

and control

5. Summary

20

Summary

• Inherent complexity of the systems and use cases

• Reorientation of HW to centralised processing and I/O concentration

• Continuing use of heterogeneous OS, with hypervisors

• Service orientation but with some discussion on the paradigm – virtual

ECU/Domains (reflecting supply chain?) or service level granularity of partitioning

across domains?

• SOA is part of the solution, in practice further architecture standards are required

to cover system lifecycle, safety case, security, robustness and data plane are

required

• Connectivity not tied to a unique model; more flexibility for system architecture

Summary