http://www.ieee-pses.org/symposium http://www.emc2004.org/
From: Brian O'Connell [mailto:[email protected]] Sent: Tuesday, August 17, 2004 1:00 PM To: [email protected]; [email protected] Subject: RE: Which Operating System - 2000 vs XP to use? Good People I got wayyyyy too much OS theory in school (was a CS major). SNIP My final word on this subject (honest...). If your lab is accredited to IEC 17025, and the auditor requires software verification, validation, and traceability for instrument control and/or numerics; then you must have access to, or knowledge of, system internals. The most simple solution, for people whose job/hobby is not systems administration, is to control the instruments using command-line Linux (or DOS if you do not need USB or other modern I/O) on a dedicated box, and export the data to an appropriate machine loaded with your number cruncher/graphing apps, typically an XP box. Stand-alone numerics is easilly tested using "black-box" and associated regression tests. Important note: the (US) FDA will always require full validaton. luck, Brian Brian: Could you please explain (in beginner's terms) what are the concerns regarding "validation" of the software used in a data acquisition system or an OS. About a decade ago, I had gotten just a hint of exposure to software control at General Dynamics. At that time, my area of GD typically used HP "desktop controllers" like the HP-9836, running HP Unix or Pascal or Basic. We used data acquisition applications that were either self-authored or purchased >from HP. GD's QA people had required that all software be registered with them, and that working copies be periodically audited for changes by performance of a digital checksum on the file. The HP software was proprietary, and we couldn't see anything about how the internals worked. The QA control was only concerned with "creeping code shift"; that is, undocumented changes made on the working copy of the code. As far as I know, they never tried investigate any deeper. I validated the operation of the HP data acquisition code by using the technique, now described in MIL-STD-461E, of injecting known signal levels into the probe end of the coax cable and seeing if the acquisition system would output the correct frequency and amplitude data. (I did the same for the self-authored code, but this was very redundant, since that code had been very rigorously verified as module by module went together.) Regardless, with a few hours time, I could feel very certain that the code was yielding correct results. But your comments about "validation" give me a chill suspicion that I was blissfully ignorant of something important, something I still don't see in hindsight! Do current auditing standards require far more samples to justify confidence? How many samples would you need? So what is involved with proving confidence in an OS? I know that HP simply stated that their (acquisition) code was proprietary, and that we would just have to trust them that everything was as it should be. And nobody ever thought to question their OS. But what would you have to do to validate an OS? Are you saying that confidence requires knowing that an OS yields the same result for 10^9 square-root operations? Or is 10^15 needed? Does every algorithm need to be examined and proved? Why would using a CLI be any more trustworthy than using a GUI? Using these standards, could we even prove confidence in a hand-held calculator? What about the firmware in a printer? How confident are we that it will always print "47 dBuV" every time we send that data to it? How far does traceability need to go? Do you need to document the origin and chemical composition of the graphite in a pencil, or do you just accept that the pencil is whatever it is, so long as it makes marks you can read? As you can see, I'm groping at the concepts and definitions. Regards, Ed Ed Price [email protected] WB6WSN NARTE Certified EMC Engineer & Technician Electromagnetic Compatibility Lab Cubic Defense Applications San Diego, CA USA 858-505-2780 (Voice) 858-505-1583 (Fax) Military & Avionics EMC Is Our Specialty This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. IEEE PSES Main Website: http://www.ieee-pses.org/ To post a message send your e-mail to [email protected] Instructions for use of the list server: http://listserv.ieee.org/listserv/request/user-guide.html List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Ron Pickard: [email protected] Dave Heald: [email protected] For policy questions, send mail to: Richard Nute: [email protected] Jim Bacher: [email protected] All emc-pstc postings are archived and searchable on the web at: http://www.ieeecommunities.org/emc-pstc
