Challenges to Embedded Controller Software and Hardware Development
The Problem:
You have to develop the software for a new embedded controller. The schedule is short. The budget is limited. And you absolutely
have to deliver on time and within budget. What do you do?
The Typical Approach:
You quickly pull together some development equipment: The control module (if it exists), an emulator, the development software, test equipment, and
some hardware that will hopefully simulate the system that your module will control. Nothing fancy, just some switches, potentiometers, resistor and
LEDs, along with a signal generator (or a few), and a 'scope. If you're really fortunate, either you or someone else has the time to build a nice switch/load box that you can hook your module up to.
|
What's wrong with this picture??
A typical development bench setup
(is this like yours?) |
Features of a typical manual software test/validation bench setup:
- Uses switches and potentiometers to simulate digital and analog sensors. Sometimes real
sensors are used.
- Emulated or real loads used.
- Signal generators used to emulate waveform generating sensors or sources.
- Meters, oscilloscopes, or other pieces of test equipment used as part of the setup.
- For multi controller systems, computer(s) may be used to emulate the other modules in the system. Sometimes the real modules are used.
|
Problems with the manual approach to software bench and validation testing
When the development schedule and budget are tight, you might think that a manual test setup is the quick and easy way to address your development and validation testing needs, but there are several problems with this approach:
- Manual test benches are labor intensive to build and use
- It's difficult or impossible to perform complex test sequences by hand on a manual test bench.
- Many test sequences involve signal change timing relationships that are too fast to be done by hand.
- It is extremely time consuming to perform recursive testing.
- It is easy to make a mistake during a test sequence, requiring that the testing be repeated.
- Test results must be manually documented.
OK, I'm convinced. Show me the solution