I have been 'informed' by our registration body, the software we use to collect our data (direct from the equipment via interfaces) requires validation.

My confusion is how? We have the appropriate statements from the supplier etc along similar line of a C of C.

Any suggestions??

Many thanks

Sounds like the registrar doesn't have much else to do, but they want to look important. I'd say you could so some short, simple experiments similar to your real-world application, i.e. record 10 readings direct from the tool with pencil and paper as well as having the software record the same values and then compare this handwritten record to the data sent by the tool to the computer. Next, maybe do some statistical calculations on this data manually (or with a calculator) and compare the results to having the software crunch the numbers. If everything matches, I'd say it was validated.

Mike has a good reply. One thing, if the SPC software is well known and accepted in the industry, perhaps you can push back as already being validated.

Without much information from the original post, here are my views:
I agree that registrar wants to show the client management that they look into every finer details of the system.
But one cannot argue that this not a valid question under 7.6.

Let me project scenario where this question can be vital:
The Software vendor designed the software to be an off-line analysis tool.
whereas the user has connected the software to the manufacturing equipment through a commercially purchased interface to perform Real-time SPC for "Special Process".

In this case:
The Software may not support the heavy load of data flowing in from the Manufacturing equipment. (The software was never intended. If they had, they would have performed Load and Stress testing during the Test phase).
The software may loose data during rapid transfer
The software may receive corrupt data, hang up during operation,etc.
Interface testing is a Software requirement if original Software requirement called for.

Another scenario:
If you are using a reputed Mitutoyo, Trimos, Tesa, etc... tools that come with standard catalogue interface and Catalogue software, then Manufacturers Certificate of Compliance would do. The rate of measurement is also slow and you can demonstrate that the value measured is the input value for the stat functions similar to what Mike and Hershal mentioned.

Regards,
Govind.

Puzzle,



I think I may be about to go off on a different track here. If I understand your situation, you have some kind of measuring system, and you are using a software application to capture data from it. Without more information than that it is hard to cover all of the unknowns, but …



As Mike mentioned, if it is possible to make the measurements manually you can do that a number of times and compare the results to the software. There are some problems to watch for there –


The measuring instruments may not have the capability to be operated or read manually.
The system may make and record a huge number of measurements in a relatively short time.
You would have to make the comparison a sufficiently large number of times to be statistically significant. If the system makes lots of measurements, it may not be possible.
Doing all of the work manually may generate more errors than the software ever would. (People are fallible; and this is the sort of mindless drudge work that computers were invented to rescue us from.)


Hershal and Govind have a good point – if the software is generally accepted in your industry and is a commercial off-the-shelf product, then rigorous validation may not be necessary. You still have to verify that it meets your requirements, and that is a type of validation as well.



Govind also mentioned clause 7.6 – I am going to assume that he is referring to ISO 9001:2000. That section says, in the last paragraph,

When used in the monitoring and measurement of specified requirements, the ability of computer software to satisfy the intended application shall be confirmed … prior to initial use and reconfirmed as necessary.


Seeing “confirmed” in a clause that deals with control of measuring and monitoring devices immediately takes me to ISO 10012:2003, Measurement management systems – Requirements for measurement processes and measuring equipment. Clause 6.2.2 of that standard gives some guidance. Paraphrased, software (including revisions) that is part of the measurement process or which calculates results must be

Documented – What is it? What does it do? Where did it come from? How does the operator use it?
Identified – records of enough information to adequately identify the currently installed and operating version. This includes the base purchase plus all upgrades, add-ons, plug-ins, patches and so on.
Controlled – software and its operating environment should be under configuration control. How many valid licenses do we have? What changes were installed – when, why and by who?
Tested and Validated – “to the extent necessary to ensure valid measurement results”. This includes security measures such as anti-virus checks. It includes “reality checks” of the results when it is first used and before and after any system change. It also includes testing and validation of user programs, macros, scripts and so on. The goals are to see if it works without error, and to see if it achieves the desired measurement result.
Approved – who says you can use it?
Archived – repeat after me: a backup on the server, an offsite backup, a backup on another server, the original CD in a data media rated fire-resistant file, a rotating daily backup, backup copies of all upgrades and patches on a CD in that data media rated fire-resistant file, and so on. It is a given that computer drives will fail – they are mechanical things that rotate at high speed. It is also true in most cases that the data in a corporate computer is worth tens of thousands times more than the hardware itself. An observation is that in today’s environment, an “off-site backup” possibly means in a different city instead of in the bank down the street. Also, make sure you have and implement a regular backup policy.


Not all organizations need to do things the same way. For instance, if the software is part of the measurement system then the approval of the purchase can be seen as “approval” of the software.



Because of the ubiquitous nature of software, any of it that is part of a measuring system must be regularly confirmed. Note that “confirmation” as applied to a measurement system in ISO 10012 consists of formal verification that


The correct measurements are identified to be made.
The tools used for the measurements are appropriate and capable.
The people using the system are trained and proficient
Adjustment on the measuring system are protected from tampering
Measuring tools and systems are calibrated
All of the above is reviewed and repeated at planned intervals.


In many cases software is embedded in an instrument that is regularly calibrated. No special testing action is needed for that software – the calibration process itself verifies that it is operating correctly



Have you made a backup today?

Many thanks to all.

I was deliberately vague in my original post.

We essentially use the software, Mitutoyo Statpak, with their propriety interface and their measuring equipment. Verniers, micrometers and touch probes. And their data cabling :)

I was thinking of a manual calculation comparison, and as usual in these cases, a nice variety of avenues were presented as solutions.

Many thanks.

I remember that there was a handbook by Ford which had numbers to enter and the results expected.

Searching the net I found refernce to this "Ford EU 883 B "Evaluation of SPC Software" which might be the name of the book.

Any one else remember this