Ahh, Bob, seems we disagree on this one.. Point 1 Both the software I install, and our biggest competitor are installed by chaps with many, many years of practical experience. In my case 26 years, and I'm sure my competitor is just as much... Point 2 As a Lab Assessor myself, I take issue also wit that point also. We ( the group of us to chat you know... ), require users of software to show that the results are as expected. What we don't ask for is a line by line validation of the code. With 100+ installations of our SW, each one validated to the extreme by very very picky clients ( and trust me, they find errors!! ) means the code is much more reliable than any assessor could ever hope to check during an assessment, or any individual could achieve. Why make a lab pay for this pointless act. What we check is that they know how to use it. Now, if I were assessing a lab with non-COTS software, I would expect to see evidence of every aspect of the program. Point 3 As I've stressed, the standards are so poorly written that there are interpretations of how the test should be run. A good software package has the flexibility to enable a user to have it do what THEY want, so they can stand behind their approach. Goes back to point 2, the lab has ultimate responsibility, BUT the software does what it's supposed to which is what the lab want. Point 4 Instrument drivers are key: but all COTS SW drivers are different, and are certainly not interchangeable. And I beg to differ that drivers are written with Rented equipment: you should talk to our insurers that pay out for equipment damaged in transit! Further, in the case of my software, the drivers are tied to the model and SERIAL number of the instrument. So unless it is a deliberate action, instruments can't be swapped out. On top of this, with a team of 6 people world wide ( collectively 100 years of instrument control ), with experience on almost every instrument made, we know a few tricks.... An internal test lab ( with few exceptions ) just cannot call on that wealth of knowledge. Point 5 Good software should work with ANY instrument. After all, if it's written for dedicated equipment that suffers prolonged damage, the lab would be off line until the WHOLE process is done again..... What a serious financial and chronological hit to a laboratory! Point 6 While experience is beneficial, after all I boast about it above, past experience IS NO indicator of future performance. After all, we all ( well, most of us ) rush out and upgrade to the newest version of windows or Office when it comes out, because the new features are typically over come the resentment we hold cos' the darn software crashed on us many times. Point 7 Having written my own EMC test software 20 years ago, and having COTS now, it's a no brainer. As a lab manager, I'd rather my EMC techs and engineers be working in their field rather than trying to be programmers... Yes, I'm biased, but I'm also battered and bruised from MANY MANY years of testing. Right, back to the possible reasons that Manual and Automated testing may differ. Cheers, Derek Walton L F Research ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. Website: http://www.ieee-pses.org/
To post a message to the list, send your e-mail to [email protected] Instructions: 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: Scott Douglas [email protected] Mike Cantwell [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
