Transcript DAC Presentation 34_1

Computer-aided Architecture Design
and Optimized Implementation of
Distributed Automotive EE Systems
Ajay Kumar, Antal Rajnak
Automotive Programs
System Level Engineering Division
June 06, 2007
DAC 07, Paper 31.4
Presentation Outline
 Problem statement
 Basic AUTOSAR concepts
 Proposed Tool Flow
 Experience thus far
 Suggested improvements / future work
 Summary
Current Design Environment
 Manual process with inadequate tool support
 Insufficient data to support early decision making,
leading to early binding and late verification.
 ECU-focused rather than system-level
 Validation on physical prototypes
 Distributed, multi-company, modular supply chain
 Few if any widely-accepted standards
 The resulting architectures are seldom optimal in
terms of:




Performance
Flexibility / Scalability
Reliability
Life-cycle Cost
Industry trends
 Increasing use of model-based function development
 20-25%
of all EE functions covered today
Used for:
 Functional verification
 Executable specification OEM -> Tier1
 Major standardization effort - AUTOSAR
2.1 of specs released – matured
 Use gaining momentum in Europe
 US and Japan watching closely
 Version
 Step towards development and validation in a virtual
environment, using Systems Engineering principles
Basic AUTOSAR concepts
AUTomotive Open System ARchitecture
 Layered software architecture, with clearly defined
interfaces
 Applications implemented as atomic or composed
Software Components (SWC)
 Virtual Function Bus (VFB) – abstraction of all
interconnected SWCs, communicating exclusively
through ports independent of underlying hardware
 Run Time Environment (RTE) – implementation of
the VFB on a particular ECU
 Basic Software (BSW) – implementation of the
AUTOSAR infrastructure (nearly 40 different modules)
AUTOSAR ECU sw structure
source: www.autosar.org
Basic AUTOSAR concepts (Cont.)
 AUTOSAR systems are described by a set of XML
based Description Files
 Derived
from a defined UML metamodel
 What’s described: ECUs, SWCs, their mapping to
ECUs, ECU interconnections etc.
 What’s missing: Methodology to create these
description files
The Implementation Abyss
 Model based function design – a widely accepted,
and used technique
 AUTOSAR – brings new level of abstraction to
function implementers
But…
 The task to translate a model based design into a
robust, and efficient system, in a highly distributed
environment remains a challenge.
How to bridge the implementation abyss?
Proposed SLD methodology
 Architecture Design
 Topology
definition
 SWC to ECU Vehicle function creation
 mapping
 VFB-level simulation
 Bus scheduling
 Initial ECU Scheduling
 Metrics generation

ECU configuration
 Runnables
to task mapping
 OS task scheduling
 Configuration of remaining BSW modules
Proposed System Level Tool Chain
Implemented as a set of well connected point-tools.
 Vehicle System Architect – for the OEMs



Function Editor
Topology Editor
Function Mapper



VFB-level Simulator
Network Cluster Builder
ECU Scheduler


Harness Design Tool (Capital Harness®)
Metrics Generator
 Vehicle System Builder – for the Tier 1s
Proposed Tool Flow
Vehicle
Topology
Editor
Network
Cluster
Builder &
ECU
scheduler
Optimized
&
Vehicle
Features
Vehicle
Function
Editor
Metrics
Generator
Vehicle
Function
Mapper
Vehicle
Architecture
Description
VFB level
simulator
Wiring
Harness
Design Tool
Tool Implementation Challenges
 Support for concept evaluation for EE-systems in
early phases of the design process, when the
available level of detail is minimal
 Connectivity to legacy OEM environments
 Scalable tool functionality, depending on OEM
preferences
 Manual
/ Interactive use mode
 Analysis
 Synthesis – requirements based design
Vehicle Function Editor
 Users create atomic or composed SWCs
representing vehicle functions
 Method:
 Manual
graphical entry
 Import from function modeling tools
(e.g. Matlab/Simulink)
 “Envelope” of function is adequate
 Interface consistency is checked
Vehicle Topology Editor
 Instantiation of basic elements of the physical
architecture (ECU-s, sensors, actuators, buses etc.)
 Allows creation of “soft” (only partially defined)
components in the early phases of design.
 Import:
 Individual
components
 Pre-existing message matrix
 Pre-existing topology
 Graphically arrange components to form desired
physical architecture.
Topology editing & Function mapping
Mapped System Architecture
Logical Architecture
Functions
and SWCs
•Connect functions
Simulink
•Add new functions
Network Generation
•Map functions
Topology Import /
Creation
Cabling
Physical Architecture
•Extend network
•Add new ECUs
Vehicle Function Mapper
Function:
 Mapping of vehicle functions to logical ECUs
 Check of resource demand vs. availability
 Soft ECUs allocated to real ECUs from library
 Split of end to end timing requirements btw ECUs and buses
 Automatic gateway configuration
Output:
 System Configuration Description file
 ECU extract of SCD
 Export to Harness design tool
VFB-level Simulation
 VFB-level view: network of SWCs connected through
ports
 This network can be simulated
 Appropriately
compiled SWCs with behavior required
 Verify desired functionality across single, as well as
multiple ECUs
Network Scheduling – the Cluster Builder
Basic Functionality:
 Produces schedule tables
 Creation/modification of frames (PDU-s) and related
parameters (ID, period time, x-fer mode etc.)
 Interactive signal packing and editing of schedule
tables
 Cluster schedulability analysis
Expanded functionality:
 Automatic frame compilers (AFC-s) for
CAN/LIN/FlexRay
 Fully automatic scheduling and frame packing
ECU Scheduler
 Runnables to tasks mapping
 Manual configuration and schedulability analysis
based on available timing information
 Configuration of OS and BSW schedulers
Tightly coupled to network scheduling.
Unified Timing Model
LEVEL 1: VEHICLE FUNCTION LEVEL (AUTOSAR VFB VIEW)
Terminator
SENSOR SWC
APPLICATION
SWC
Terminator
ACTUATOR
SWC
MAX. AGE
LEVEL 2: VEHICLE ARCHITECTURE LEVEL
SENSOR
B
S
W
SENSOR SWC
PUBLISHER
LATENCY
B
S
W
B
U
S
BUS PROP.
DELAY
BSW
GATEWAY
GW
DELAY
B
U
S
B
S
W
APPLICATION
SWC
BUS PROP.
DELAY
SWC PROP.
DELAY
B
S
W
B
U
S
B
S
W
BUS PROP.
DELAY
ACTUATOR
SWC
SUBSCRIBER
LATENCY
B
S
W
ACTUATOR
Metrics generation
 Compares and ranks a set of alternative architectural
solutions in relative terms
 Component cost is only one aspect - scalability,
flexibility and extensibility will heavily influence the
results.
 Scenario based sensitivity analysis is essential to
identify decision points
 Simplified analysis running in the background
provides ”live” feedback to user
Vehicle System Builder
Function:
 Create/edit all AUTOSAR-related
configuration files
 Intelligently merge partial configuration files
from multiple sources
 Generate a downloadable binary image of the
complete software (Apps+BSW+Config) for the
selected ECU.
Vehicle System Builder
SWC
Descript.
File
System
File
Vehicle
System
Architect
RTE
ECU
Extract
of
System
File
Partial ECU
Config.
File
•SWC creation
Vehicle
System
Builder
Generator
RTE
Glue
Code
Complete
ECU
Config.
File
Compiler/
Linker
BSW
Config.
Generator
•Topology definition
•SWC to ECU mapping
•Bus scheduling
•Initial ECU Scheduling
•Runnables to task mapping
•OS task scheduling
•Config of remaining BSW
modules
Application
Software
ECU
Binary
Image
BSW
BSW
Config.
Library
Data
Correctness by Design
Vision:
 Requirements based Systems Engineering
Process
 Holistic, top-down approach, supported by
well connected high-level tools.
 Development and validation in a virtual
environment
Values:
 Reduced
cost
 Shortened lead-times
 Improved Reliability & Quality
Experience thus far
 Tool-set for requirements based synthesis of
complex CAN and LIN networks and gateways
successfully deployed and used in production
since 1998 (Volcano Network Architect tool).
 Users are enthusiastic!
But...
 Timing analysis is not widely used in current
automotive design flows.
Suggested improvements / future work
 Enhanced AUTOSAR Timing Model – to cover
important concepts, i.e. jitter, phasing, or
precedence required to deal with complex systems
 Coordinated AUTOSAR Metamodel extensions
 Evaluation metrics refinement
 Define
objective metrics and evaluation
algorithms to judge:


Scalability
Flexibility
Summary
 Bridging the implementation abyss between model
based function design and creation of efficient
AUTOSAR implementations calls for new methods,
and advanced tool support.
 Challenges:
 Usability
in early project phases, when only limited
amount of data is available
 Need to support a flexible set of usage models:
(interactive, analytic or full synthesis)
 The required technology is readily available
 The AUTOSAR Timing model needs major re-work
Q&A...
Thank you!