Function Development with PREEvision

V1 | 2019-09-10

Vector Congress – 2019-10-9

Function Development with PREEvision

u Overview

Function Development Today

Function Development in the Future

Summary and Outlook

Agenda

2/34

Function Development Flow in Detail

Overview

SW ArchitectFunction Designer/System Responsible

SW Developer

E/E Architect

Communication Designer ComponentResponsible

Component Supplier Test Engineer

FunctionalArchitectureDesign

PhysicalArchitectureDesign

SW Implemen-tation

ComponentHW Design

System SWArchitecture Design

COMDesign

Componentand System Test

SoftwareComponentDesign

WH SeriesDesign

Comp. SWArchitectureDesign

HW Implemen-tation

PhysicalSystemDesign

WHArchitectureDesign

WH Architect

ComponentSpecifications:

u REQ SPEC DOCu REQIFu ARXMLu TEST SPEC DOCu …

Tasks ofFunction Designer/System Responsible

Interactions

Legend:

3/34

Functional Architecture Design and Physical System Design

Overview

Function Designer/System Responsible

Tasks of the Function Designer:

u Functional Architecture Design

u Logical function design from the sensors tothe actuators

u Behavior design of logical functioncomponents

u Functional safety concept

u Functional diagnostics concept

Tasks of the System Responsible:

u Physical System Design

u Map function components to HW components

u Define component software and componenthardware needs from system perspective

u Define communication needs

u Define wiring harness needs

u Define system variants

u Provide system test specifications

u Implementation Planning and Tracking

u Plan stepwise implementation in line withvehicle network and component releases

u Provide staged system and componentspecifications

4/34

Overview

u Function Development Today


Summary and Outlook

Agenda

5/34

Physical Architectures Today: Design Space for Function Development



Software Platform:

u AUTOSAR Classic

E/E Architecture:

u Onboard

AUTOSAR Classic

SW Architecture and Communication:

u Signal-oriented

u Service-oriented (only for Ethernet and Diagnostics)

Design Workflow AUTOSAR Classic„service oriented“

Design Workflow AUTOSAR Classic„signal oriented“

E/E Architect

6/34

Feature List, Feature Model or Feature Dependencies as Starting Point


u The Function Designer considers and extends theFeature Model of the vehiclefamily under development:

u Vehicle features - can beexperienced by the vehicleuser

u Safety features

u Technical features

u Feature Dependencies

u Most relevant are:

u Exclusive OR (Xor)

u Needs (Req)

u Optional

u Feature Chains

u Needs/needed by



Feature Model

7/34

Logical Architecture Design and Mapping of Functions to Components


AUTOSAR Classic Ports are used:

u Sender/Receiver Ports and interfaces

u Client/Server Ports and interfaces

The Function Designer defines …

u … the logical functions fromthe sensors to the actuators

u … the functional safety and functional diagnostics concept

u … the mapping of the functionsto the E/E components.



Onboard


Example:

u Distributed function

u implemented with a CAN network

u specified with Sender/Receiver Ports.

8/34

Logical Architecture Design and Mapping of Functions to Components




Component Subsystem X Subsystem Y Subsystem Z …

ECU A X X

Sensor A11

Sensor A12 X

ECU A1 X X

Actuator A11 X

Sensor A21 X

ECU A2 X

Actuator A21 X

…

u The result is the Subsystem/Component Matrix:

Component Subsystem X Subsystem Y Subsystem Z …

ECU A Function Y1 Function Z3

Sensor A11

Sensor A12 Sense Z1

ECU A1 Function X3 Function Z2

Actuator A11 Actuation X4

Sensor A21 Sense X1

ECU A2 Function X2

Actuator A21 Actuation X5

…

Note:

u Unclear Responsibilities become obvious!

9/34

Logical Architecture Design




Dedicated Modeling Concepts in the Logical Architecture:

u Different block types

> Sense, Logical Function, Actuation

> Building Block, Logical Domain

> Environment Function, …

u Type/Instance concept

u Activity Chain

> they can overlap

> often used to map Functionality to Customer Features

u Logical Function Package

u Ports and Assembly Connections

> Sender/Receiver Ports, Client/Server Ports

> Environment Ports, …

10/34

Behavior of Logical Functions




u The Function Designer defines also the behaviorof the Logical Functions.

u This is supported with UML State Diagrams.

u Data Elements of Sender Receiver interfacesassigned to Ports of the Logical Function can beused in the Transition Conditions of the State Machine.

u Also the Behavior of Software Components canbe specified with State Diagrams.

u Further UML Diagrams for behaviorspecification are on the PREEvision Roadmap!

11/34

Wiring Needs for Physical Systems




u The System Responsible has to define the needs for the Wiring Harness Design

u especially the wiring needs for sensors and actuators

u possible with the Schematics Layer

u In the Schematics Diagram the needed pins of the components and the schematic connections can be specified.

u Of course, the pins of the components need to be coordinated with the Component Responsible.

u Also variants have to be considered.

12/34

Interaction with Component Specification


Component HW Design

ComponentResponsible

u The Component Responsible defines:

u … the internal component structure

u … the headers and the pins of the component

Component Diagram:

13/34

Variants of Logical and Physical Systems




Middle Class

Compact Class

Common

Compact Class only

Middle Class only

u Design Space is always a Product Line

u Widely accepted Variant Management Approach:

u Take care only for the differences of thevariants, …

u … not for the commonalities (default)

u By defining Variation Points with

u Variation Point Sets and

u Variant Conditions

u based on System Constants and Literals

14/34

Alternative 1

Design Workflows (1/2)


u Abstract logical function design:

u Independent of implementation and highly reusable!

u … but often we see low motivation to maintain.

u Abstract functional design

u Concrete SW design

u SW to HW mapping

u Communication design


SoftwareDesign

SW to HWMapping

COMDesign

No direct contribution to the vehicle

Often done at suppliers, often only top compositions defined by OEM

Clearly the OEMs responsibility


Design Workflow AUTOSAR Classic„signal oriented“

15/34

Design Workflow (2/2)


u Concrete logical function design – including deployment aspects – drives communication

u Communication design and SW component design in parallel

u The more agile approach:

u Detailed SW design can be changed as long as network communication is not affected!

u Concrete functional design

u Function to HW mapping

u Communication design

u High level SW design

u Detailed SW design

Alternative 2


Function to HWMapping

CommunicationDesign

SoftwareDesign

Optional: for inhouse development needed, otherwise at the supplier

Mostly done for the complete vehicle by the OEM (top compositions per ECU)



Direct contribution to the vehicle, high motivation to maintain

16/34

Overview


u Function Development in the Future

Summary and Outlook

Agenda

17/34

Physical Architectures in the Future: A bigger Design Space (1/3)


3 types of ECUs:

1.Sensor and Actuator ECUs

u commodity ECUs

u Signal-oriented communication

➔ AUTOSAR Classic

2. Integration ECUs

u per domain or per zone

u Service- & signal-oriented communication

➔ AUTOSAR Classic & Adaptive

3.Vehicle Brain

u few high performance computers

u secure IT-like software acc. ISO 26262

u focus of innovation, many SW contributors

u Service-oriented communication

➔ AUTOSAR Adaptive(supported by AUTOSAR Classic for fail-operational)

18/34



E/E Architecture:

u Onboard & Offboard

u Vehicle Brain withHigh Performance Computers

u Integration ECUs

u Sensor and ActuatorECUs


E/E Architect

Software Platform:

u AUTOSAR Adaptive AUTOSAR Adaptive

SW Architecture and Communication:

u Signal-orientedu Service-oriented

AUTOSAR Classic

u AUTOSAR Classic

u Other Platforms

19/34



Many new options for Function Development

u Use and integrate Services in the Backend

u Run Algorithms with high performance needs on the High Performance Computers

u Update Functions over the air on AUTOSAR Adaptive ECUs

u Run safety relevant Functions on AUTOSAR Classic ECUs

u Provide remote Diagnostics Functions

u …

Challenge

u How to cope with the Complexity!




20/34

Functional Architecture Design for Service-oriented Architectures


Ethernet

CAN

For Service-oriented Architectures AUTOSAR Adaptive Ports are available in PREEvision 9.0:

u Service Ports and Service Interfaces

Example:

u Distributed functions realized via an Ethernet network are specified with Service Ports.




Design Workflow AUTOSAR Classic or Adaptive „service oriented“

21/34

SOA Design


Service Architect

u The Service-oriented Architecture Design – as separate design layer –considers additional design aspects:

u Different possible scenarios after service discovery

u Alternative providers

u Several consumers

u All details of the neccesary Service Interfaces have to be defined.

u Service dependencies have to bedefined.

u These are the tasks of a new role in the function development process:

u Service Architect

SOADesign

22/34

Functional Architecture Design versus SOA Design



Service ArchitectFunction Designer/System Responsible

Service Architecture Design

u Type perspective (or class view) for services and software components

u Alternative service providers and other serviceconsumers are considered

u Service layers and Service Dependencies are defined

u The SOA layer is an abstract layer connecting theAUTOSAR Classic and AUTOSAR Adaptive subsystems in the vehicle …

u … and can serve as single source for the derivationof AUTOSAR Classic and AUTOSAR Adaptive SWC types.

Functional Architecture Design

u Instance perspective (or object view) forfunctions and systems including mappingsof the functions to the HW components

u Type view for functions available, but in most cases of lower importance

u Some exceptions: Window left/right, Mirror left/right, Seat left/right, ….

u End-to-end view of functional dependencies… from the sensors to the actuators

u Communication needs for service orientedand signal oriented architectures

SOADesign

Mappings between Logical Architecture andService Architectureu Function – M – Participantu Function Type – M – Service Provider/Consumer

23/34

Component Software Architecture Design


u With AUTOSAR Adaptive the implementation changes from C to C++.

u High Performance Computers will have a more complex SW Architecture than ECUs so far.


SW Architect

u With UML Class Diagrams the internal structure of AUTOSAR Adaptive SWCs can be specified:

24/34

How will the Design Workflow look in Future?


u Currently discussions with many customers and users.

u Also concept discussions in AUTOSAR have started: „VFB++“, …

u Possible solutions:

u Logical function design – SOA design – SW design

u We have 2 possible approaches in mind:

u Pragmatic approach

u „New Thinking“


SW to HWMapping

Service Design

CommunicationDesign

CommunicationDesign

AR ClassicSW Design

AR Adaptive SW Design

25/34

Pragmatic Approach


Ethernet

CAN

u If functional domains are using one SW Platform and are clearly separated, then …

u … use AUTOSAR Classic Ports in theAUTOSAR Classic Signal-oriented areas

u … use AUTOSAR Adaptive Ports in theAUTOSAR Classic and AUTOSAR Adaptive Service-oriented areas


26/34

Pragmatic Approach


Ethernet

CAN

u If functional domains

u use different SW Platforms or

u are not separated,

then …

u … the Pragmatic Approach does not work!

?Function Designer/System Responsible

27/34

SignalSignalSignal

Data Element

New Thinking: One Step back


Application SW Component (Service Provider)

Client/Server Interface

Sender/Receiver Interface

Client/Server Interfacewith GET_ and SET_ operation

Sender/Receiver Interfacefor change notification

Sender/Receiver Interface

1: Fire & Forget Method = Method without Return

2: Property = Field = Attribute

Service Interface

Method

Fire & Forget Method 1

Property 2

Event

AUTOSAR Adaptive AUTOSAR ClassicService

Provider/Consumer Port

Abstraction

Event

Service Interface

Sender/Receiver Port

Sender/ReceiverInterface

Service Interface and Technology Mapping to AUTOSAR Classic

28/34

New Thinking


u The logical design uses onlyService Ports

u … and can be deployed to AUTOSAR Classic and AUTOSAR Adaptive ECUs. Ethernet

CAN

29/34

New Thinking


u The Logical Function Design is specified for the complete vehicle.

u The Service Map or Service Landscape is also defined for thecomplete vehicle with

u Layers, clusters and dependencies

u The Software Architectures for AUTOSAR Classic and AUTOSAR Adaptive are derived from these Layers.

Service Architect


SOADesign

Logical Function Architecture

Service oriented Architecture

AUTOSAR Classic SW Architecture

AUTOSAR Adaptive SW Architecture

SW Component BehaviorSW Class Architecture & SW Component Behavior

HW Network Architecture

30/34

Overview



u Summary and Outlook

Agenda

31/34

Function Development (1/2)

Summary and OutlookThe model-based design of

u Logical functions and

u Physical systems

enables the

Consistent derivation of

u Software needs

u Communication needs

u Component needs

u Wiring harness needs and

u System variants.

Additional specification done with

u Integrated requirements and

u Test specifications

Integrated change management

u Implementation and releaseplanning in integration steps

u Ticket and change management

u Review and voting support



System SWArchitecture Design

COMDesign

WH SeriesDesign



WHArchitectureDesign


SW Architect

SW Developer

Communication Designer

ComponentResponsible

Test Engineer

WH Architect

32/34

u Today Function Development has a clear Onboard Design Space.

u In the near future a much bigger Design Space is available – with many newoptions!

u Challenge:

u Master the complexity

u Concepts are in discussion

Function Development (2/2)

Summary and Outlook

Logical Function Architecture

Service oriented Architecture

AUTOSAR Classic SW Architecture

AUTOSAR Adaptive SW Architecture

SW Component BehaviorSW Class Architecture & SW Component Behavior

HW Network Architecture

Service Architect

SW Architect

E/E System Responsible,Function Designer

SW Developer

E/E ArchitectCommunication Designer Test Engineer

33/34

© 2019. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1 | 2019-09-10

Author:Jörg SchäuffeleVector Germany

For more information about Vectorand our products please visit

www.vector.com

http://www.vector.com/

Function Development with PREEvision

Documents