Indycar Telemetry Data Acquisition Interface Danny Ho 97 140232 March 25, 2002 University of Waterloo Systems Design SD 542.

Indycar TelemetryData Acquisition Interface

Danny Ho97 140232

March 25, 2002

University of WaterlooSystems Design

SD 542

Presentation Summary

• Introduction to Telemetry• Functional Decomposition• Initial Design• 1st Prototype• User Feedback & Limitations• 2nd Prototype• Industry Comparison• Conclusions

Objective of Telemetry

• Ensure driver safety• Monitor vehicle performance• Use data history to adapt car to track

1st place finish !

The Flow of Data

Pit laneOnboard sensors Radio transmitters

Functional Decomposition

Functional Purpose Transport driver around a race track

Abstract Function Conservation of Mass and Energy

Generalized Function Engine provides torque, wheels turn, vehicle is driven forward, steering wheels steer the car

Physical Function Engine, chassis, steering wheel, pedals, tires, transmitter antenna, etc…

Physical Form(location of sensors)

Inside tire rim, engine hardpoints, onboard computer socket location, etc…

Initial Design

Focus of 1st Interface

• Functional Visual Basic for Application implementation

• Simulate alarm conditions• Provide real-time monitoring scenario

1st Prototype

User Feedback & Limitations

• Alarm salience was adequate• Visual representation did not conform

well to mental model• Graphical forms lacked frame of

reference (scale)• Certain graphical elements were hard to

notice

Final Prototype

Final Prototype

Final Prototype

Industry Comparison

EFI Technologies

PI Research

Conclusions

• Proposed system:– offers richer, more iconic representation of data– Provides better cognitive association– Improves upon salience and mental model

• Industry systems:– more data intense– data display in the strictest sense– targeted towards expert engineers (experienced!)

Q & A

• How critical is alarming?– Shouldn’t experts know what to look at?

• Analogical or Iconic?

• Is industry software too bland?