software architecture for an entire product line

[jcarmody]

Most of us can write a VI.

Many of us can take a measurement and analyze/present/store data.

A lot of us can write an entire application.

Some of you write incredibly complex applications that make me say "Wow."

How many of us are responsible for an entire product line?  How many are responsible for several?  I expect that some of you are.  I am.

I want to standardize how I manage configuration information and test results for all stations on a product line, and I want this system to be abstract enough that I can use it on multiple lines.  I need to be able to write tools once and apply them throughout my factory.  I need each operation to know the status of the others.  I need to support QEs in their never-ending quest for perfection.  I need to teach other engineers to use this in their lines.  I might have opportunities to share our practices with other factories.

I've been thinking that I can store configuration and test data as a serialized Object string in a text field in a database.  This lets me use one database with a few simple tables, but I can't use SQL to query serialized Object strings in any useful way.

I like the way TestStand stores results in a database (among a whole bunch of things I like about TestStand) but I'm not sure I want to put a license on all my computers, and I still can't query it for statistical data to see the "health" of my processes.

I'd like to avoid needing to run a data-mining program whenever I want to measure first-pass yield or daily production or...

How do you do it?

[Dennis_Knutson]

I was responsible for all products at a couple of companies. At both, I used TestStand and yes the licensing was an extra expense but fairly small compared to overall cost of most test stations. I did not use the standard database schemas, though. The database was highly normalized with the addition of a few extra tables such as one for product name. The first pass yield and defect paretos were obtained from the SQL Server database and presented on a dashboard on the company intranet. I wish I could give an example of the queries but they were written by the IT department, sorry.

At one place, I also included some configuration data but this was pretty basic since the products were all kind of similar with features present or not and parameters for certain features in linked tables.

[thoult]

*waves*

Process developer/designer on a couple of processes across several product lines.

We don't use TestStand for a number of reasons - we have had enough fun winning people over more and more to LV based test and assembly environments rather than some of our more...historical approaches.

All raw data is saved to TDMS and summary/calculation data saved to SQL. Almost every process will record basic fields such as Serial, Overall Pass, Test Type and Start Timestamp, as well as an indexed ID column once data is inserted into the SQL results table. FTPR and yield calculations are done by parameterised stored procedures on the server - no data miner needed to return these results. Having said that, every new product line has a data viewer application...these are pretty similar straight out of the box (a SQL query builder, a serial number tracker, FTPR/yield/pareto generators) but can have additional plugins added for raw data viewing.

Most of our processes have jig data stored in an SQL table in individual columns, rather than in XML clusters. Yes, it requires more time to set up and maintain, but it means that it doesn't require translation from XML to plain English for technical managers, auditors and the like.

I can probably fish out a stored procedure or two for FTPR and yield data, but it'll have to wait until I'm back in the office on Monday.

[Sam_Sharp]

We implemented a production line for some off-shore production - we put together the production test software for ~10 stations per line as well as storing results / serial number data.

- Database is definitely the way to go for summary/results data. The time-series/live test data is probably never going to be looked at until something fails and someone wants to know why - find a way of archiving it sensibly

- The database had tables which stored time-series configuration keys that were either global, test-specific or station specific. All of the configuration came from these tables. We also had a time-series limits table. The reason for making them time-series was so that we could see how the limits/configuration changed over time. We also stored a flattened string of the limits/configuration keys against each test so we could see the conditions each part was tested under if we needed to. I thought this was quite a neat feature!

- The stations had a way of gating the parts so that they couldn't be tested if there wasn't a result for them in the results table from the previous test

- We managed to find a way to make the system pretty flexible in terms of tests, results values, limits etc.

- Find a way of updating the software automatically/remotely - either using something like Deploy or pulling in your tests as PPLs from a network/FTP site.

- Generally for production line stuff, we quickly learnt that pictures are great, text is bad, the use of a keyboard for data entry is a big no-no (barcode scanners or RFID tags!) as it's super prone to human error from an operator

- Never forget the cost of time if a) your database server breaks and/or b) lost production if the line stops - when considering your backup strategy, it can quickly make that redundant/mirrored server seem quite cheap! Something that is often forgotten about!

For viewing the results/data - I'm getting more and more convinced myself that a web-based solution is the way to go so anyone can view the data without needing to install anything and the fact it works so well with databases and there's lots out there for graphing the data etc.

[SnowMule]

Databases, yo. 

A good DBA can architect a system that's scalable across multiple products, but still able to use the same modules to feed data in from the test systems.  We had our guys working on that project for a while, and it's been a great tool to have. 

We've got a DLL that handles all the databasey-stuff, we just feed it an array of clusters that has about 12 elements (Section, name, tolerances, comparison, measured-value, database name... whether it's an "informational" or "parametric" value... couple others).  The DLL/UDL lets us use the same code and software architecture in our test equipment, while all the database/server stuff's managed by our network development team.  There's also a switch for whether we feed the data in database-direct (stuff we use here on-site) or through Azure cloud (at CM's). 

We're fortunate to have a real good network dev and infotech team here that manages all the techy-stuff and allows us (test engineering) to focus on what we do best and not have to worry about backups, failovers, whatever.

DBA's are expensive because they're worth it.

For retrieving/analyzing that data, we have a web-app for that... our "device history record".  Can dive in and see test results for a specific product by serial number, or get trend data both by test or by test station.  We have a couple automated reports that display on a few monitors around manufacturing to see the daily history/throughput/pass-fail/etc.