Automotive Open Experimental Platform Overview

1
Automotive Open Experimental Platform Overview

• Karl Hedrick
• Stavros Tripakis, Mark Wilcutts, Baris Dundar

2
Outline

• Project Goals
• Target Development Context
• Overview of Challenge Problems
• Vehicle Control
• Models Controllers
• OEP Software Hardware
• OEP Simulation Environment

• Powertrain Control
• Models Controllers
• OEP Software Hardware
• OEP Simulation Environment
• Experiments
• Releasability Restrictions
• Schedule

3
SmartVehicle OEP Overview

• Project Goals
• Support Phase I software design frameworks
  including emulation environments, and vehicle /
  engine domain-specific libraries for application
  development
• Demonstrate MoBIES products on high-impact
  physical challenge problems
• Advanced Vehicle Control Testbed multi-agent
  sensing and control
• Powertrain Control Testbed emissions, fuel
  economy, driveability improvements
• Target Development Context
• Improving Embedded System Design Process
• Evaluating Competing Approaches
• Fostering Technology Transfer

4
SmartVehicle OEP Products

• OEP Testbeds
• Powertrain and Multiple-Vehicle Domains
• Software Architectures
• Detailed Dynamical Models
• Multiple Interacting Vehicles/Warning and Control
  Laws
• Powertrain Models and Control Laws
• Benchmark Comparisons
• Other Frameworks
• State of the Art in Automotive Industry
  (Matlab/Simulink, OSEK)
• Embedded Systems Environment in Use at UC
  Berkeley
• Integration with other Phase I Frameworks
• Measures of Performance, e.g., Development Time,
  code efficiency, non-functional measures

5
SmartVehicle OEP Automotive Application Domains

• (1) Advanced Vehicle Control Testbed
  Multi-Agent Sensing, Control and Communications
• Candidate Driver-Assist Safety Applications
• Cooperative Forward Collision Warning
• Cooperative Adaptive Cruise Control

• (2) Powertrain Control Testbed Improvement in
  Control Design Process
• Candidate Powertrain Control Emissions
  Reduction / Fuel Economy / Drivability
  Applications
• Idle Speed Regulation
• Air-Fuel Ratio
• Combustion Sensing
• Transmission Shift

6
Cooperative Vehicle Control Testbed

• Advanced Vehicle Control Testbed Multi-Agent
  Sensing, Control and Communications
• Candidate Driver-Assist Safety Applications
• Forward Collision Warning
• Cooperative Adaptive Cruise Control
• Salient Components
• Two 1997 Buick LeSabres with
• Automated Steering, Throttle and Brake Control
• Sensors (radar, forward vision)
• Communications equipment (wireless LAN)
• PC
• Software
• Publish and Subscribe Software Architecture
• Device Drivers QNX

7
Advanced Vehicle Control Testbed

• SmartVehicle OEP Physical Challenge Problem 1

8
Powertrain Control Testbed

• SmartVehicle OEP Physical Challenge Problem 2

9
Powertrain Control Physical Challenge Problem

• Powertrain Control Testbed
• Candidate Emissions, Fuel Economy and Drivability
  Applications
• Idle Speed Control
• Fuel Injection Control
• In-Cylinder Sensing and Control
• Transmission Control
• Salient Components
• 1996 Ford Taurus Powertrain on Dynamometer Test
  Stand
• Engine and Transmission with Full-Authority
  Control
• Motoring Dynamometer with Vehicle Simulation for
  FTP75
• MPC555 Automotive Microcontroller
• Software Architecture Implemented in OSEKWorks
  (Wind River OSEK product)

10
Cooperative Longitudinal Control Test Vehicle
11
Vehicle Free-Body Diagram and Lumped-Inertia
Model for Longitudinal Motion
? Lumped Inertia Fa Aerodynamic Drag
Force Te Net Engine Torque Tb Brake Torque Rg
Gear Ratio Mrr Rolling Resistance Moments h
Effective Wheel Radius m Total Vehicle Curb
Weight Je Engine Inertia Jwr Rear Axle
Inertia Jwf Front Axle Inertia Ca Aerodynamic
Drag Coefficient v Vehicle Velocity a Vehicle
Acceleration
12
Simplified Engine Model

• Engine Torque Function Te Te (?e , Pe)
• Based on an experimentally determined engine map.
• ?e Engine speed determined from above state
  equation.
• Pe Intake manifold pressure. Assumed ideal gas.
• Manifold Mass Equation

• Obtained from an empirical
  map.
• MAX Full throttle flow rate
• ? Throttle angle
• TC(?) Empirical throttle characteristic
• PRI(me) Pressure influence function for
  compressible flow

13
Vehicle Model
Gear Selection
?w
Torque Converter
Engine
Gear Box
Tpump,?pump
Tshaft
Tnet,?e
?w
Tload
14
Basic Vehicle Model Equations
Intake Manifold Engine Dynamics Brake Dynamics
LeSabre Parameters
15
Vehicle Components in SHIFT/SmartAHS
VehicleDynamics
Powertrain
SIEngine
Transmission
WheelSet
Throttle
Manifold
M/C Pressure
Tractive Forces
Brake Torque
Brakes
RigidBody
Moments
16
Controlled Vehicle Model in SHIFT/SmartAHS, Teja
MoBIESVehicle
Communicated Information
Communications
ControlSystem
Previous Vehicles Info.
Sensor Measurements
SensorModels
Actuator Commands
Vehicle States
Global Frame x,v,a
VehicleDynamics
Road Info.
VREP
Body Frame x,v,a
17
Vehicle Control Schematic
Vehicle Controller
?
Pmc
vlead
v
alead
a
Platoon Lead Car
Previous Car
Our Car
18
Detailed Vehicle Control Structure
Throttle Controller
?
Upper Level Control
Switching Logic
Brake Controller
Pmc
19
Throttle and Brake Control


Throttle
Brake
desired acceleration
desired acceleration
Convert to desired torque
Convert to desired torque
Convert to desired throttle angle (engine map)
Compute brake control (two strategies)
commanded throttle angle
brake actuator command
20
Throttle and Brake Switching
Switching condition is a function of desired
acceleration and current vehicle speed ?
Independent of upper (coordination) mechanism
used.
? Throttle control
Desired torque ?
? Brake control
Desired torque ?
21
Sliding SurfaceController Equations

• Throttle and Brake Switching Criterion

• aresid Closed-throttle acceleration

• Engine Control
• Filtering desired manifold air mass
• mades Filtered signal of madesc
• ?e Filter time constant
• Sliding surface for the engine control
• Desired throttle characteristic

22
Sliding SurfaceController Equations

• Brake Control
• Tdes first converted to Pwdesc
• Filtering desired brake wheel pressure
• Pwdes Filtered signal of Pwdesc
• ?b Filter time constant
• Sliding surface for the brake control
• Desired brake control input

23
Brake Control Two Strategies


Brake 2
Brake 1
Control wheel cylinder pressure, model brake
system. Use dynamic surface control.
Control master cylinder pressure. Use
feed-forward plus proportional feedback control.
ub is the applied command input to the brake
solenoid valve, Pmcdes the desired master
cylinder pressure, Pmc the measured master
cylinder pressure, kbgt0 a feedback gain
Pwdes is the desired wheel pressure, V is the
volume of displaced brake fluid, Pw the pressure
at the wheel, Cq a flow coefficient, ?b a gain
24
Hierarchical Control Architecture

• COORDINATION LAYER
• control strategies to
• - perform coordinated longitudinal control
• - maximize safety and efficiency
• monitors the evolution of the system
• receives commands, translates them
• into specific maneuvers
• finite state machines represent
• communication protocols

• REGULATION LAYER
• feedback control laws
• throttle control
• brake actuator control
• throttle and brake switching laws
• fault detection and handling

Discrete Time

• PHYSICAL LAYER
• automated vehicles
• nonlinear ODE models (continuous)
• interfaces with the platform hardware
• actuation and sensing algorithms
• sensor data processing and monitoring

Commands
Coordination Layer
Communications
Regulation Layer
Failure/Event Management
Physical Layer
Monitors, Fault Detection
Vehicle
Continuous Time
25
Cooperative Longitudinal Control
FIRST AS LEADER
Several possibilities for string control. Use
dynamic surface control to set desired
acceleration for each vehicle ? robust and
adaptive strategies available, guaranteed
stability and robustness
1
2
3
4
5
MIDDLE AS LEADER
3
1
2
4
5
LEADERLESS
1
2
3
4
5
26
Automotive Powertrain OEP
OEP Session

• Mark Wilcutts, Baris Dundar
• OEP Session
• Wednesday November 1, 145-230pm

27
Automotive Powertrain ControlTestbed Overview

• 1996 Ford Taurus engine w/automatic transmission
• Vehicle simulation through dynamometer
• Federal drive cycle test
• Production-level controller platform

• MPC555 processor
• OSEK RTOS
• Control design challenge
• emissions
• fuel economy
• drivability

28
Automotive Powertrain ControlTestbed Arrangement

• Controlled Environment for Testing Powertrain
  Controls

29
Powertrain Models

• Engine 3 state model
• Air flow, fuel flow, crankshaft speed
• Transmission 2 state model
• Reaction carrier gear speed, input shaft speed
• Drivetrain 3 state model
• Front wheel angular velocity, vehicle speed,
  shaft torque,

30
Powertrain Models

• Engine Air Flow Dynamics
• Mass of air in manifold
• Mass flow rate into manifold is max flow rate
  multiplied by throttle and pressure ratio scaling
  factors
• Mass flow rate out of manifold is a function of
  engine displacement, intake manifold volume,
  engine speed, volumetric efficiency

31
Powertrain Models

• Engine Fueling Dyamics
• Fueling results in a combination of a lag and a
  transport delay
• Lag is a result of wall-wetting effects in the
  intake manifold
• Simplest model is a first order lag
• Time constant is a function of commanded fuel
  rate and engine speed

32
Powertrain Models

• Engine Rotational Dyamics
• Engine speed is calculated from engine torques
  and engine/torque converter inertia
• Indicated torque is scaled from a max torque (for
  a given engine speed, air mass) using air/fuel
  influence and spark influence terms
• Friction torque is experimental, accessory torque
  is a model input, load torque is input to torque
  converter impeller

33
Powertrain Models

• Transmission
• Differential equations differ depending on gear
• Dynamics for second gear
• Rd, R2 final drive, second gear reduction ratios
• Ts,Tt input shaft, output shaft torques
• wcr,wt carrier ring, output shaft speeds
• It2 second gear inertia

34
Powertrain Models

• Drivetrain
• Ts sum of right and left axle torques
• Ks sum of right and left axle stiffness
• Rd final drive ratio
• wcr, wwf carrier ring and front wheel speed
• Iwf wheel inertia
• hf static ground-to-axle height of front wheel
• Ftf/Ftr tractive/braking force of front/rear tire

35
Powertrain Control Schematic
Powertrain Controller
rotational speeds
idle air fuel spark EGR
throttle flow O2 sensors temperatures rotational
speeds crank and cam triggers
shift solenoids pressure control
Engine
Transmission
throttle position
mechanical energy
to vehicle
36
Powertrain Control Software Features

• Timed task lists
• 10-50ms fuel control, idle speed control, etc.
• 100-500ms fault detection
• Event-driven control of fuel and spark handled in
  microcontroller hardware
• Event-driven control of transmission shift
• Throttle control
• Combustion sensor signal processing

37
Powertrain Simulation Environment

• Top-level of models contains libraries
• Multiple inputs, engines, transmissions,
  drivetrains, etc.
• Modular structure
• Components can be modified

38
Powertrain Simulation Model

• Hierarchical structure in Simulink/Stateflow
• continuous ODE (mean-value) engine model - some
  component models in C-code
• engine/ transmission control algorithms in
  Simulink
• control logic (mode selection) uses Stateflow

39
Mean-value Engine Models
Intake Manifold Air Flow

• Described by differential equations
• Air Intake Dynamics
• Fueling Dynamics
• Rotational Dynamics

Engine Air Flow And Fueling
Rotational Dynamics Torque Production
40
Vehicle Control Software Architecture

• Stavros Tripakis

41
Automated Vehicle Control Hardware Architecture
Buick Le Sabre
42
Hardware Architecture Buick Le Sabre
Vehicle Sensors III
Vehicle Sensors II
Vehicle Sensors I
acceleration, gyro, engine manifold, etc
wheel speeds, etc
steering wheel buttons, magnetometers, etc
PCM/Cruise Actuators
PCTIO-10 Card
ATMIO-16 Card (A/D)
ATMIO-64 Card (A/D)
Radio (Wireless Ethernet)
Control Computer
PATH-101 (Throttle)
Throttle Actuator
HMI Computer
CAN bus
Ethernet
Steering Actuator
Brake Actuator
Radar
Laptop
43
Software Architecture process types
Device drivers
Data I/O
Database
Controllers
44
Publish / Subscribe Library

• Generic C library for inter-process communication
• Services
• generic database where client processes
  login/logout
• creating/destroying variables on-the-fly
• reading variables, updating (writing) variables
• setting triggers for variables (notify upon
  update)
• operations are atomic

45
Software Architecture Dataflow
cani
atmio16
canread
canbrake
atmioe
cansteer
pctio10
veh_iols
eng_spdl
path101
radio
hst
veh_lat
hmi
buttons
HMI computer
46
Software Architecture Timing
8,10,20ms
cani
20ms
atmio16
canread
8ms
4ms
canbrake
atmioe
cansteer
pctio10
2ms
long_output
veh_iols
eng_spdl
long_input
path101
long_track
lat_input_mag
radio
hst
200ms
hmi_display
veh_lat
hmi
30ms
buttons
HMI computer
47
Publish/Subscribe Architecture
48
Publish/Subscribe Architecture
49
Publish/Subscribe Architecture

• Generic/reconfigurable
• Number/type of components (processes) interacting
  not predefined, can change dynamically
• Number/type of variables exchanged not
  predefined, can change dynamically
• Modular
• Code generated by different tools can run on the
  same Publish/Subscribe architecture, as long as
  it respects the librarys API
• Many applications
• platoons, trucks, snow-plow, MOB.

50
Publish/Subscribe Properties

• Atomicity database finishes processing a request
  before moving to the next.
• Integrity no variable can be written in the
  middle of a read.
• Update always returns most recent value.
• No fairness guarantees for requests depends on
  scheduling policy (e.g., with priorities,
  low-priority process may starve).
• May have more than one triggers buffered.

51
Publish/Subscribe Pros and Cons

• Pros
• Asynchronous inter-process communication
  consumer does not need to know how fast/slow
  producer is.
• Multicasting (many consumers) as easy as
  unicasting producer does not need to know who or
  how many consumers there are.
• Modularity.
• Cons
• Might introduce unnecessary overhead, in some
  cases (e.g., 1 producer to 1 consumer).

52
Publish/Subscribe Semantics database
Receive command X from process P
?(X, P)
Update internal data structures w.r.t X,
P compute result R
!(R, P)
Send result R to process P
Commands login, read, set_trigger, etc
53
Publish/Subscribe Semantics database (cont.)
For each Q in TrigList(var)
?(update(var), P)
!(trig(var), Q)
!(R, P)
Send asynchronous messages to all
processes registered for triggers on var
Command update
54
Publish/Subscribe Semantics client process
Send command X to database
Receive result R
!(X, DB)
?(R)


?(msg)
msg trig(var)


If message is trigger for variable var, do
something
Wait for message
55
Modeling Simulation Environments

• SHIFT/SmartAHS
• Simulation and Visualization
• Formal model hybrid automata (dynamic creation,
  dataflow or synchronous interaction)
• Legacy of automated highways models available
• Tool available at www.path.berkeley.edu
• Models available at ftp//vehicle.me.berkeley.edu
  /pub/mobies
• Teja
• Simulation and Code generation
• Formal model hybrid automata with C code
• Simple models available

56
OEP Software(Vehicle Control)

• Publish/Subscribe architecture and components
• Centralized database for inter-process
  communication
• Device-drivers hidden by data I/O components
• Controllers interact only with database
• Documentation and source code (C, QNX) available
  now
• QNX operating system device drivers
• Teja used for benchmarking

57
TEJA

• Design/Simulation/Code generation environment
• Formal model
• Dynamic networks of hybrid automata
• Mathematically based, formal design technique
• Advantages
• Specifically developed for coordinated operation
  of multiple systems
• Object-oriented
• Dynamical reconfiguration of multiple coordinated
  systems
• Real-time performance and simulation capabilities

58
Teja Design Process
59
Teja Designer Tools
60
Software Teja

• Part of sub-contract is to
• Provide Teja high-level interface to database.
• Provide Teja high-level interface to QNX device
  drivers.
• Can use these interfaces for either
• Designing controller in Teja, generate code for
  database.
• Designing the entire application from scratch in
  Teja, generate code for device drivers.

61
Software Emulation

• Need to debug/test code before experimenting on
  the cars.
• Emulation means
• Replace hardware components by pseudo-components
  that produce/consume data.
• Possible in the publish/subscribe framework.
• Pseudo-components can be
• Reading from or writing to a file (no feedback).
• C processes emulating the hardware (feedback)
  must be fast enough to emulate the hardware in
  real-time.

62
Testing and Debugging Strategies
Teja model
other control
Models and control are just representation of
processes.
Teja model
Teja control
teja2db
ctrl2db
database
Operating System
Operating System
One tool no problem.
Different tools communication through database.
63
Mixed Software/Hardware Strategies
virtual car (model or traces)
real car
control
control
car2db
ctrl2db
car2db
ctrl2db
database
Operating System
64
Phase I - Phase IIInteraction
- Model incorporation - Model validation
Models (controllers environment), Simulators

• MODELING and MODEL VALIDATION
• Powertrain models in Simulink/Stateflow
• Vehicle models in Shift/SmartAHS and Teja
• Challenges
• Model incorporation (translate?, rewrite?)
• Model validation (interconnect simulators?)

• CODE GENERATION
• OEP Software Documentation
• O/S device drivers (powertrain, vehicle)
• Publish/Subscribe (vehicle)
• Teja (benchmarking)
• Issue for Phase I
• Tailor code generator backend for specific
• platform.

Phase I frameworks (modeling, validation)

• CODE VALIDATION
• Emulate OEP platform (HW, SW) and
• environment
• O/S and microcontroller emulator
• (powertrain)
• Traces real-time simulation (vehicle)
• Issue for Phase I
• Provide API to hook up emulators with
• generated code (not an issue for Pub/Sub)

- Code generation - Platform dependent
Code generation Backend
OEP Software
- Code Testing - Code Debugging
OEP Hardware Emulation
Generated Code Validation
- Experiments - Demonstrations
OEP Hardware facilities
Final Code
Phase I
Phase II
65
Phase I - Phase IIInteraction
Models (controllers environment), Simulators
- Model incorporation - Model validation -
Implementation constraints
Phase I frameworks (modeling, validation)
- Code generation - Platform dependent -
Guarantees
Code generation Backend
OEP Software
OEP Hardware Emulation
Generated Code Validation
- Code Testing, Debugging
- Experiments - Demonstrations
OEP Hardware facilities
Final Code
Phase I
Phase II
66
Phase I - Phase IIInteractionMODELS and MODEL
VALIDATION

• Products
• Shift/SmartAHS, Teja for vehicle control
• Matlab Simulink/Stateflow for powertrain
• Challenges
• Model incorporation (rewrite? translate?)
• Model simulation/verification
• Include timing, jitter, loss, noise into the
  models/tools?
• Include implementation platform specs/constraints
  into the models/tools?

67
Phase I - Phase IIInteraction

• SOFTWARE
• Products
• Publish/Subscribe, QNX for vehicle control
• OSEK-Works for powertrain
• Challenges
• Composing/reusing components
• Large scale code generation, rather than
  per-block
• Ensure that generated code respects properties of
  models, e.g., schedulability (hardware or
  software deadlines, CPU utilization lt 100)

68
Testing and Debugging Strategies
control
ctrl2db
database
Operating System
69
Additional Challenges

• Verification
• Schedulability checks, e.g., CPU utilization lt
  100.
• Hardware requirements, e.g., steering actuator
  output every 4 ms.
• Software deadlines, e.g., consume inputs before
  new ones arrive, or produce outputs at most X ms
  later.
• Specification
• Try other languages/tools (e.g., Esterel, Giotto,
  Lustre, Ptolemy, Teja, TTA) and evaluate
  re-design time.

70
Powertrain Control Architecture

• Baris Dundar

71
Powertrain ControlHardware Architecture
Motorola MPC555
Idle air valve EGR valve Transmission
press. Torque conv. clutch
frequency counting
PWM
Turbine speed Vehicle speed
Timer output subsystem (TPU)
Timer input subsystem (TPU)
Crank position Cam pulse
Injectors (6) Spark coils (3)
events
Analog input subsystem
events
Throttle position Throttle flow rate Oxygen
sensors (4) Intake air temp. Coolant temp. EGR
flow rate Knock sensor
PowerPC core
RAM
ROM
8-bit microcontroller (HC08)
Serial, CAN transceivers
DSP (C40)
Throttle actuator
Combustion sensor
72
MPC-555

• 32 bit PowerPC Core with FPU
• 40 MHz operation, -40ºC to 125 ºC
• 448 Kbyte Flash EEPROM Memory(256K192K)
• 26 Kbyte Fast RAM
• Dual supply (3.3V , 5V)
• Two Time Processor Units

73
MPC-555

• 18-Channel Modular I/O System
• Two Queued A/D Converter Modules
• Two CAN 2.0B Controller Modules
• Queued Serial Multi-Channel Module

74
Safety Critical Systems

• Malfunctioning in a safety critical system may
  cause serious injury or even the death of one or
  more people, significant environmental damage or
  other major accidents.
• usually have low memory and strict timing
  requirements
• must be reliable (predictability of memory
  utilization, control flow, and timing), robust,
  fault tolerant, highly available

75
Platform Operating System OSEK-complianthttp//w
ww.osek-vdx.org

• Specifically designed to meet automotive
  control needs
• stringent real-time requirements, low resource
  usage, reliability, scalability, cost sensitivity
  
• Enhances reusability of application software
• abstract, application-independent API
• UI independent of hardware and network
• Improves development time and cost
• enhanced quality and ease of integration of
  software from various vendors, or for different
  ECUs

76
Powertrain Control Platform Software

• OSEK/VDX Standard
• Defined by consortium of European automotive
  manufacturers and component suppliers.
• Defines a static operating system -- operating
  system services needed by the application are
  pre-specified
• Additional standards for Communication, Network
  Management, Configuration

77
OSEK/VDX NM

• Defines standardized features which ensure the
  functionality of inter-networking as well as the
  the safety and availability of the communications
  network of autonomous control units by
  standardized interfaces.

78
OSEK COM

• Defines a mechanism both for inter-ECU
  communication and ECU-internal communication.
• Provides a standardized software communication
  interface that lowers the level of coupling
  between the application and the particular type
  of media used
• Facilitates portability of software across
  different communication environments.

79
OSEK Implementation Language (OIL)

• Used to statically configure the application at
  compile time
• OIL defines an OSEK application as a set of OSEK
  defined system objects
• At compile/link time the application code is
  compiled/linked together with the OIL files and
  then executable is generated accordingly

80
OSEK OS Vendors

• ETAS ERCOSEK
• Motorola OSEK
• Wind River OSEKWorks
• Realogy SSX5 OSEK
• ATI Nucleus OSEK (doesnt support PowerPC)

81
WindRiverOSEKWorks

• Supports the full range of OSEK /VDX conformance
  classes (Basic and Extended, levels 1 and 2).
• Communication, Network Management, OIL
  Configurator products available
• Integrated with Tornado IDE and additional
  debugging/simulation tools
• Local support (Alameda, CA)

82
Tornado Architecture
83
Tornado for OSEKWorks
84
Tornado for OSEKWorks
85
OSEKWorksBoard Support Packages

• initialization code and device drivers for
  hardware peripherals on embedded board (CAN,
  serial I/O, timers, network devices, etc.)
• provides portability
• BSPs for MPC555 boards from ETAS, AXIOM and EST

86
Tornado for OSEKWorks

• Hardware assisted and software development tool
  integrated with Tornado for OSEKWorks IDE
• Target Hardware Control BDM/JTAG
• Statistical Performance Analysis
• Internal Register Configuration Utility
• Built-in Hardware Diagnostics
• remote operation over LAN is supported.

87
OSEKWorksVisionPROBE Hardware

• Coming soon
• OSEKWorks Simulator (like VxSim), it
• enables application development to begin before
  hardware becomes available.
• OSEK API for VxWorks, which will enable one to
  link an OSEK application with WindRiver's OSEK
  API and run on top of VxWorks.

88
MPC-555 Evaluation Boards

• ETAS ES2000, AXIOM CME555, EST SBC555
• 512k 1Mb RAM
• 512k 1Mb ROM
• I/O breakout
• Debug / Logic Analyzer ports
• RS-232 ports
• CAN ports
• Optional ethernet support
• Price range 500-2000

89
MPC-555 vs MPC-565
90
OEP Software Platform

• Software Interfaces
• OSEKWorks device drivers (BSP)
• OSEK Simulator for PC -- VxSim
• Simulink-generated code for benchmark

91
Software Development Progressionwith Mathworks
Tools
hardware-in-the-loop simulation environment
design / simulation environment
real-time simulation environment

• Stateflow Coder
• RealTime Workshop
• Real Time Windows Target

Matlab
Compiled c code Powertrain Model
Compiled c code Control Model
Compiled c code Powertrain Model
Compiled c code Control Model
Simulink/ Stateflow Control
Simulink Powertrain Model
Windows
Windows
Windows, Linux, etc.
RTWT kernel
RTWT Kernel
OSEKWorks
PC, Workstation
PC
PC with I/O board
MPC555
92
Powertrain Software Architecture
Powertrain Control Software
OSEK Code Generator (Teja, Matlab, )
Controller Code
Hardware API
OSEKWorks
Powertrain Model
BSP
MPC 555 Board
93
Powertrain Software Portability Issues

• OSEK Specification provides portability
• BSP also provides portability as it encapsulates
  all the board specific code.
• Hardware API is our interface library to the
  underlying hardware
• Controller code can be easily integrated within
  the Powertrain Control Software

94
Phase I - Phase IIInteraction
- Model incorporation - Model validation
Models (controllers environment), Simulators

• MODELING and MODEL VALIDATION
• Powertrain models in Simulink/Stateflow
• Vehicle models in Shift/SmartAHS and Teja
• Issues for Phase I
• Model incorporation (translate?, rewrite?)
• Model validation (interconnect simulators?)

• CODE GENERATION
• OEP Software Documentation
• O/S device drivers (powertrain, vehicle)
• Publish/Subscribe (vehicle)
• Teja (benchmarking)
• Issue for Phase I
• Tailor code generator backend for specific
• platform.

Phase I frameworks (modeling, validation)

• CODE VALIDATION
• Emulate OEP platform (HW, SW) and
• environment
• O/S and microcontroller emulator
• (powertrain)
• Traces real-time simulation (vehicle)
• Issue for Phase I
• Provide API to hook up emulators with
• generated code (not an issue for Pub/Sub)

- Code generation - Platform dependent
Code generation Backend
OEP Software
- Code Testing - Code Debugging
OEP Hardware Emulation
Generated Code Validation
- Experiments - Demonstrations
OEP Hardware facilities
Final Code
Phase I
Phase II
95
Experiments

• Relevant Tasks for Phase I Interaction
• Task 5.1 Define Testbed Experiments
• Commenced on 9/1/00
• Team Government, UC Berkeley, GM, Ford,
  Motorola
• Ongoing through 8/30/02
• Successive Iterations
• Task 6.1 Testbed Schedule Developed (11/16/00 -
  3/30/01)
• Controllers development begins immediately after
  Task6.1
• Task 7.1 Perform Testbed Demonstration and
  Experiments (9/3/01 - 8/29/03)

96
Experiments (Contd)

• Some Issues to Resolve
• Phase I - Phase II Collaboration
• Co-location vs. Remote Access to Platforms
• Remote Access Not Possible with Vehicles
• Need to Define Process to Implement Phase I
  Software
• Phased Development
• Can Phase I software development match this
  schedule?
• Mutual Understanding of Evaluation Criteria (Task
  7)
• Benchmark Comparisons
• Development Time

97
Experimentation Plan and Demonstrations

• Vehicle experiments conducted at PATH facilities
  in Richmond, California
• Powertrain control testbed on UC Berkeley campus
  may allow some degree of remote access -- for
  safety reasons VDL personnel must oversee
  experiments

98
Releasability Restrictions

• Proprietary Rights
• All models provided without restriction
• Benchmark (Teja, MatLab, WindRiver) Applications
  Require Licensing
• Teja 5 tools license and 6 runtime licenses
  provided
• No Exportability Restrictions Exist

99
ScheduleSubtasks Shown Require Interface to
Phase I