As you say it’s not ideal, but we are in the real world and once there are controls in place of who can do the editing and a record that they did it and what they did, then all should be OK. Any successful company places trust in the right employees to make things work when the unexpected happens which could potentially affect things downstream as you say.

John

Thanks for your comments. We have strict format controls and if a format or a field is updated, a parser change is required. The integrity of the database is at stake otherwise. We also don’t allow our customers update parsers.

We actually do allow editing data under the following conditons:
1. The data is in your own personal database (engineer’s databases are separate from production in our FloorVision databases), so you are not affecting what others see when reviewing production data
2. You can never copy data from your personal FloorVision database into the production database.

As to Don’s point about the gray area, yes, that’s true. We typically get data from the automated testers and these datalogs are automatically routed to our servers a few times a day. For testers which generate text files, it is of course open for people to edit this in some cases, we would just warn our customers if that’s a possibility and that the integrity of the database is sacrosanct. We have yet to have seen this as a real on-going issue with any customer. It’s rare from our experience.

If however a particular data format is awkward, we always process anyway all data to an intermediate format, then into the database. This helps with data integrity too and speed of developing parsers.

Another issue: if data looks wrong to an engineer in our FloorVision database, users can mark it as such and it’s automatically excluded from analysis for everyone. The data is wrong because for example the lot may have been misprocessed, eg reporting a zero yield because of mis-testing or an invalid lotid recorded with only a couple of units tested. Being able to exclude such data greatly improves the analysis, especially of trends over many months of data say.

Editing the production test results in this environment would be an offense that the employee would be reprimanded or maybe even fired over.

Another scenario is simply training. If a particular text format is required then workers need to be trained to use that format. Even this is not a guarantee.

There is however the third option, which is a post process of the text data log by software to enforce the required format. In the case where it is not possible to modify the software/firmware producing the original data for the log, then post processing might be the most reliable second option.

Unfortunately the test numbers generated are not unique in some circumstances and our software has to deal with that, and does so quite successfully where it is possible to do it. However, customers who have this problem seem to always attempt to rectify it when the dangers of doing this are made clear to them.

We also encounter repeated records for the same die. This is very common especially in wafer sort. We include tools to analyse the succes rate of re-probe in this case. We also see this sometimes in final test.

The original data is always sacrosanct and that data is kept. If data is to be edited, it should be the data in what we call the user’s personal database (as opposed to the production database) and it’s data in the database which is edited, not the original data. The user can always re-process the original data and the original data is there for auditing purposes, separate from the relational analysis database.

Also if you modify an stdf file you should update the log record to reflect that act. Failing to do so is not ethical.