addressing complexity in connected & autonomous...
TRANSCRIPT
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