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.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
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.