Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
V6 | 2018-02-06
PREEvision User Day 2019
Function Development with PREEvision
u Overview
Function Development Today
Function Development in the Future
Summary and Next Steps
Agenda
2/36
Top Level Automotive Design Flow
Overview
Data Management, Collaboration, Platform Management, Safety, Change Management
Requirements Engineering and Management
Test Engineering and Management
FunctionalArchitectureDesign
SOADesign
SoftwareDesign
PhysicalArchitectureEvaluation
PhysicalArchitectureDesign
PhysicalSystemDesign
COMDesign
WH SeriesDesign
WHArchitectureDesign
3/36
Top Level Automotive Design Flow
Overview
Data Management, Collaboration, Platform Management, Safety, Change Management
Requirements Engineering and Management
Test Engineering and Management
FunctionalArchitectureDesign
SOADesign
SoftwareDesign
PhysicalArchitectureEvaluation
PhysicalArchitectureDesign
PhysicalSystemDesign
COMDesign
WH SeriesDesign
WHArchitectureDesign
Tasks ofFunction Designer/System Responsible
Interactions
Legend:
4/36
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:
5/36
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
6/36
Overview
u Function Development Today
Function Development in the Future
Summary and Next Steps
Agenda
7/36
Physical Architectures Today: Design Space for Function Development
Function Development Today
PhysicalArchitectureDesign
E/E Architect
Software Platform:
u AUTOSAR Classic
E/E Architecture:
u Onboard
AUTOSAR Classic
SW Architecture:
u Signal-oriented
u Service-oriented (only forEthernet and Diagnostics)
Design Workflow AUTOSAR Classic„service oriented“
Design Workflow AUTOSAR Classic„signal oriented“
8/36
Feature List, Feature Model or Feature Dependencies as Starting Point
Function Development Today
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
FunctionalArchitectureDesign
Function Designer/System Responsible
Feature Model
9/36
Logical Architecture Design and Mapping of Functions to Components
Function Development Today
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.
FunctionalArchitectureDesign
Function Designer/System Responsible
Onboard
PhysicalSystemDesign
Example:
u Distributed function
u implemented with a CAN network
u specified with Sender/Receiver Ports.
10/36
Logical Architecture Design and Mapping of Functions to Components
Function Development Today
FunctionalArchitectureDesign
Function Designer/System Responsible
Component System X System Y System Z …
ECU A X X
Sensor A11
Senser A12 X
ECU A1 X X
Actuator A11 X
Sensor A21 X
ECU A2 X
Actuator A21 X
…
u The result is the System/Component Matrix:
Component System X System Y System Z …
ECU A Function Y1 Function Z3
Sensor A11
Senser 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!
11/36
Logical Architecture Design
Function Development Today
FunctionalArchitectureDesign
Function Designer/System Responsible
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 overlag
> 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, …
12/36
Behavior of Logical Functions
Function Development Today
FunctionalArchitectureDesign
Function Designer/System Responsible
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!
13/36
Wiring Needs for Physical Systems
Function Development Today
Function Designer/System Responsible
PhysicalSystemDesign
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.
14/36
Interaction with Component Specification
Function Development Today
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:
15/36
Variants of Logical and Physical Systems
Function Development Today
FunctionalArchitectureDesign
Function Designer/System Responsible
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
16/36
Alternative 1
Design Workflows (1/2)
Function Development Today
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
FunctionalArchitectureDesign
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
Clearly the OEMs responsibility
Design Workflow AUTOSAR Classic„signal oriented“
17/36
Design Workflow (2/2)
Function Development Today
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
FunctionalArchitectureDesign
Function to HWMapping
CommunicationDesign
SoftwareDesign
Optional: for inhouse development needed, ohterwise at the supplier
Mostly done for the complete vehicle by the OEM (top compositions per ECU)
Clearly the OEMs responsibility
Clearly the OEMs responsibility
Direct contribution to the vehicle, high motivation to maintain
18/36
Overview
Function Development Today
u Function Development in the Future
Summary and Next Steps
Agenda
19/36
Physical Architectures in the Future: A bigger Design Space (1/2)
Function Development in the Future
E/E Architecture:
u Onboardu Offboard
u High Performance Computers
PhysicalArchitectureDesign
E/E Architect
Software Platform:
u AUTOSAR Adaptive AUTOSAR Adaptive
SW Architecture:
u Signal-orientedu Service-oriented
AUTOSAR Classic
u AUTOSAR Classic
u Other Platforms
20/36
Physical Architectures in the Future: A bigger Design Space (2/2)
Function Development in the Future
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!
FunctionalArchitectureDesign
PhysicalSystemDesign
Function Designer/System Responsible
21/36
Functional Architecture Design for Service-oriented Architectures
Function Development in the Future
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.
FunctionalArchitectureDesign
PhysicalSystemDesign
Function Designer/System Responsible
Design Workflow AUTOSAR Classic or Adaptive „service oriented“
22/36
SOA Design
Function Development in the Future
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
23/36
Functional Architecture Design versus SOA Design
Function Development in the Future
FunctionalArchitectureDesign
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
24/36
Component Software Architecture Design
Function Development in the Future
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.
Comp. SWArchitectureDesign
SW Architect
u With UML Class Diagrams the internal structure of AUTOSAR Adaptive SWCs can be specified:
25/36
How will the Design Workflow look in Future?
Function Development in the 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“
FunctionalArchitectureDesign
SW to HWMapping
Service Design
CommunicationDesign
CommunicationDesign
AR ClassicSW Design
AR Adaptive SW Design
26/36
Pragmatic Approach
Function Development in the Future
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
Function Designer/System Responsible
27/36
Pragmatic Approach
Function Development in the Future
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
28/36
SignalSignalSignal
Data Element
New Thinking: One Step back
Function Development in the Future
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
29/36
New Thinking
Function Development in the Future
u The logical design uses onlyService Ports
u … and can be deployed to AUTOSAR Classic and AUTOSAR Adaptive ECUs. Ethernet
CAN
30/36
New Thinking
Function Development in the Future
u The Logical Function Design is specified for the complete vehicle.
u The Service Map or Service Landscape is defined for thecomplete vehicle, too, with
u Layers, clusters and dependencies
u The Software Architectures for AUTOSAR Classic and AUTOSAR Adaptive are derived from these Layers.
Service Architect
FunctionalArchitectureDesign
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
31/36
Overview
Function Development Today
Function Development in the Future
u Summary and Next Steps
Agenda
32/36
Function Development
Summary and Next Steps
The 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
FunctionalArchitectureDesign
PhysicalArchitectureDesign
System SWArchitecture Design
COMDesign
WH SeriesDesign
Comp. SWArchitectureDesign
PhysicalSystemDesign
WHArchitectureDesign
Function Designer/System Responsible
SW Architect
SW Developer
Communication Designer
ComponentResponsible
Test Engineer
WH Architect
33/36
u Today Function Development has a clear Onboard Design Space.
u In the near future a bigger Design Space will be available – with many newoptions!
u Challenge:
u Master the complexity
u Concepts are in discussion
Function Development
Summary and Next Steps
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
34/36
© 2019. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V6 | 2018-02-06
Author:Jörg SchäuffeleVector Germany
For more information about Vectorand our products please visit
www.vector.com