Altarum presentation

Altarum PresentationAltarum PresentationPaul M. Bombach Paul M. Bombach

20-May-200420-May-2004

20-May-2004 Paul M. Bombach 2

AgendaAgenda

Academic BackgroundEmployment HistoryRecent Projects


Academic BackgroundAcademic Background

Bachelors of Science in Aerospace Engineering from the University of Michigan, Ann Arbor; 12/90

Masters of Science in Aerospace Engineering from the University of Michigan, Ann Arbor; 12/98


Employment HistoryEmployment History

Airflow Sciences Corporation - Livonia MI

Horiba Instruments - Ann Arbor, MIFord Motor Company - Dearborn, MI.


VPACSVPACSVirtual Powertrain and Control

SystemAutomotive simulation designed to

validate and calibrate a vehicle’s control strategy (PCM)

There are two modes of running. A software-in-the loop mode (SIL), and a hardware-in-the-loop mode (HIL)


Software-in-the-Loop (SIL)Software-in-the-Loop (SIL)

VPACS-SIL

Powertrain Models

ReplacementHigh LevelDrivers

CommonBlocks

Software PCM


SIL BenefitsSIL Benefits

Numerous tests can be run faster than real-time

A strategy developer can step through their code in a debugger

Can record data as a function of time for any variable in the strategy


SIL DisadvantagesSIL DisadvantagesHigh and low level drivers are not

testedRequires our section to port each

strategy to the SILNot really suitable to the test, fix,

repeat loop of software developmentRequires engine calibration file to be

converted


Hardware-in-the-Loop (HIL)Hardware-in-the-Loop (HIL)

High Speed I/O

SharedMemory

Hardware PCM

A/D - D/AFunction Calls



HIL TimingHIL Timing

0 21 3 4 5 76 8 9

PowertrainModels

HighSpeed I/O

Time (ms)


HIL AdvantagesHIL Advantages

Allows full testing of high level and low level drivers

Uses the native calibrationNew strategies are relatively easily

tested


HIL Disadvantages - UserHIL Disadvantages - User

Tests must run in realtimeThe strategy developer can not

debug their application. They are limited in the variables that

can be recorded.


HIL Disadvantages - DeveloperHIL Disadvantages - Developer

Frequently, can not use a symbolic debugger

Printf style debuggingFrame overruns


Current I/O ArchitectureCurrent I/O Architecture

VPACS-SIL

Powertrain Models


CommonBlocks

Software PCM

High Speed I/O

SharedMemory

Hardware PCM




New I/O ArchitectureNew I/O Architecture

SharedMemory

Vehicle Simulation Powertrain Control Module


SIL Specific ArchitectureSIL Specific Architecture

SharedMemory




HIL Specific ArchitectureHIL Specific Architecture

SharedMemory


I/O Process

Hardware PCM



Speed SensorSpeed Sensor


Governing EquationGoverning Equation

dtd

tii 1


Speed Sensor RotationSpeed Sensor Rotation i

i+1


Every ms

Speed sensors > 0

Get Speed

Predict CrankPosition

Calculate Edge Times

Sort Edge Times

Write to I/O Board

False

True


Time ProblemTime Problem

0 21 3 4 5 76 8 9

PowertrainModels

HighSpeed I/O

Time (ms)


SIL ProcessSIL Process

No automatic build process, so developers manually compiled source modules

Releases were done live so developers were offline for hours

No dependency tracking


SIL ProcessSIL ProcessInstituted a make based build system

– This eliminated manual compilation– Ensured all dependencies were satisfied

Segregated the release process– Isolated the release from all other

developers– Allowed development to continue

during the release


HIL ProcessHIL Process

Four stations with four different source codes

Four stations with separate passwords and user directories

Model code was not under source code control


HIL ProcessHIL Process

Instituted source code controlCommonized the code across four

workstationsInstalled NIS database for shared

user authenticationInstalled a file server to serve

common home directories


Code StructureCode Structure Multiple architecture specific code was

kept in one library Special scripts had to be run to select the

proper code It was difficult to determine what needed to

be ported in moving to a new architecture Some code was maintained in parallel.

When changes were made, they didn’t always get updated in both places


Code Structure ImprovementsCode Structure Improvements

Separated all architecture specific code into separate libraries

Put them under individual source code control

This had multiple benefits– For code that was parallel it was obvious

where updates had to be made– Decreased porting time because it was clear

what code needed to be ported.


ConclusionConclusion

Altarum presentation

Documents

Transcript of Altarum presentation