What features make calibration software better?

[johnnyviri]

I've worked as a calibration technician for almost 15 years and am currently working towards a BS in IT. The shop I work at currently uses a combination of access databases and some pretty old custom software for their instrument tracking and data entry. I intend to create new custom calibration software as a school project that could end up actually being useful.

So, community, what are all the good and bad aspects of the various pieces of software you've used in calibration labs? In an ideal world, what design choices would you make?

Also, What's the current deal with Mudcats?

[Hawaii596]

I will refrain from naming the particular software packages for fear of raising contentious conversations.  I will cal "A" (our old database) and "B" (our new database).

One of the problems with A was that it didn't keep good history.  In many cases, when you changed things, they were gone, and no trace of the old data.  In B, most of the time when you change anything, the history is recorded, providing good document traceability.

Also, A had the problem that you had to perform multiple  functions on multiple tabs, and you could easily forget to do one, and gum things up.  B allows you to set up process flows so that you click a receive event, which receives the item into the lab, then it automatically goes to WIP status.  You click on an event to do the calibration (and can even imbed the calibration procedure PDF and data points and uncertainties into the event on B).  When you complete it, the database automatically generates the certificate and sticker. 

Those are a couple of examples of parts of the process flows.  Very high configurability and creating detailed, custom process flows.

Just a few thoughts.

[johnnyviri]

Thanks for the feedback. Yeah, preventing accidental data loss is a high priority.

My current, theoretical plan is to have each copy of the program maintain its own embedded database (Java, Derby) that will keep a time stamped change log of all changes to the database and then synchronize/share itself with other copies of the program. Basically, a peer-to-peer shared database setup where every peer has a copy. The disadvantages of this over a centralized server-client approach is that it doesn't scale as easily, managing the synchronization may be difficult, and it can lead to duplicated information in some situations. The advantages are great data redundancy and the ability for a single peer to temporarily operate while disconnected from the network.

For this to work without users just overwriting each other's data, a unique identifier for each peer would need to be part of the primary key for every entry made by that peer. Now, what makes a unique "peer"? I'm leaning towards a peer referring to a single installation of the program that would need to be setup during installation and it's uniqueness enforced somehow. The other way to go would be to consider each user to be a logical "peer".

[RFCAL]

Good Luck to you!!

[CalLabSolutions]

johnnyviri,
There is a design patterns for what you are trying to do with the database.  Only the patterns allow you to replicate data without overwriting other's records.

MUDCATS.. They closed the nuclear reactor, which closed the calibration lab, which killed MUDCATS.

You should talk a look at www.Metrology.NET.  What I am building there is a System of Systems solution for Metrology.  The goal is to make a metrology solutions that is database and language agnostic as well as platform independent.  Meaning you can run it on anything and store the data anywhere..

We are currently building version 1.0 of the product.  We did a presentation at Keysight's Metrology Forum held a UME (Turkey's NMI).  http://www.keysight.com/main/editorial.jspx?cc=US&lc=eng&ckey=2614573&id=2614573

Let me know if you have any questions.