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.
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.
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?
@ 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 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.
The first Tacoma Narrows Bridge was a Washington State suspension bridge that opened in 1940 and spanned the Tacoma Narrows strait of Puget Sound between Tacoma and the Kitsap Peninsula. It opened to traffic on July 1, 1940, and dramatically collapsed into Puget Sound on November 7, just four months after it opened.
Noting that we now live in an era of “confusion and ill-conceived stuff,” Ammunition design studio founder Robert Brunner, speaking at Gigaom Roadmap, said that by adding connectivity to everything and its mother, we aren't necessarily doing ourselves any favors, with many ‘things’ just fine in their unconnected state.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.