I originally thought the same thing as Battar. In stuff I used to work on, test routines were never kept in the main operational software. They changed the timing, for one. But that was in the old days when cycles weren't "free." I can see if you architected generalized tools, as you say, Chris, then adapted them for different applications right at the outset, the could "live" in the real code because they'd go thru the complete test and dev cycle like everything else.
@ Battar: Additional code certainly does increase the software V&V burden, but if architected properly they can actually make the SW team's work easier. In every instance where I've requested operational additions I architect them to be generalized tools that everyone can use for test and debug. Once implemented, I then work with the SW team to work these features into their V&V test plans and procedures. In the end, the additions have actually reduced the overall SW test load and have repeatedly streamlined the whole development process.
I can never get the software crew to add test routines to the "operational" software. They insist that this would require retesting the entire software, and they are right. Their policy is to program the test routines, run the tests, then re-program with the operational file. What iif a bug caused a jump to a non-existant address, wihch in you setup would suddenly exist?
You alreayd corrected the typo in the article (burning room? Where are those smoke detectors when you need them - or was this a device to identify firemen while they enter a building ;-)
I presume that the relay was the first installment of the test and not used as soon as the solution was found in adding test routines in the unit's own software that would automatically scan every minute, so they only had to place the cups with simulated retina, throw the hidden switch and there was no need to have something interact with the device to initiate the test.
I recall our automated test of mobility-enabled DECT base stations and terminals. Two base stations were installed at two sides of a room, toy train tracks were laid out between them, the train cars were stuffed with handsets that had a special version of their normal software, the added User Interface routines generated (and tallied) outgoing calls with random timing. After a night of testing you could read the tallies and compare with statistics from the Base Station to see how many calls were missed or dropped, while the terminals roamed between the base stations.
So how did you attach the relay to the fixtures holding the scanners, so that it could physically execute the key press? And did you have to build those fixtures; I'm assuming not, since you were using the burn-in room anyway, prior to your time-saving auto-keypress solution.
As energy efficiency becomes more and more a concern for makers of electronics devices, researchers are coming up with new ways to harvest energy from sound vibration, footsteps, and even electromagnetic fields in the air.
The government wants to study your brain, and DARPA wants to use similar information to give robots true autonomy beyond any artificial intelligence developed to date. Sound like science fiction? It's not.
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is