NAMUR
5.5 Production Information
So far, we have talked about the aspect of control that issues commands to various entities. All of these commands have been caused, directly or indirectly, by humans.
Humans can learn from experience, unlike today’s software systems. We need feed- back from the effects of our commands in order to learn. Information on actual performance must be collected from production activities and digested into a form that we can compare with our commands, so that we can improve them.
Then there are the customers and their government representatives, such as the FDA.
They were not there when the batch was made, and they have a strong interest in what, if anything, went wrong. Information must be collected that can satisfy their requirements.
Somewhere, there are people that need information to make decisions. The informa- tion must be collected for that purpose, along with all of the other purposes. The dead time between command and feedback must be minimized so that a busy operator can make the connection between the data and the command. Just as in PID control, excessive dead time dulls the response.
The folks from Process Design can’t seem to get enough data. Indeed, they may install additional sensors on and about a test reactor. This data will not be recorded as produc- tion information if the database has to be rebuilt in order to add it. Portable data
recording systems are readily available if the existing system cannot handle the extra load.
It is important to accurately timestamp data, preferably at the source. If something unexpected happens, the cause is probably the change that has the earliest timestamp in a chain of events or the one just before the alarm timestamp. If the event is not detected and stamped at the source then the time may be offset by communication and processing delays in intervening machines.
88.01 classifies production data as batch specific and non–batch specific (common) information. It also distinguishes between batch history and batch reports.
5.5.1 Batch-specific Information
There follows a list of examples of data that could be called batch specific:
• A copy of the final control recipe—The initial control recipe may be modified during the batch.
• Recipe formula data as actual values—This data needs to be viewed as formula data so it can be compared to the targets in the recipe.
• Recipe-specified data—Although this wasn’t mentioned under recipes, procedural elements could contain specifications for data to be collected and specify the sam- pling interval. The procedure could turn trending on and off. This does not apply to exceptions such as alarms, which are always captured.
• Summary batch data—Utilities consumption, equipment run times, parameter sta- tistics, and so on.
• Operator comments—These may be invaluable for troubleshooting. “12:30 Ham- mering sound from R322 at about the speed of the agitator.” “14:02 Strong
thunderstorm dumped cold rain on units, lightning strikes.” Generally, control rooms have shift logs so that the next shift can read about any current news or exceptions. If this data can be identified by batch and operator, it should go into batch-specific information. It may be useful to log maintenance and supervisors comments as well.
• Continuous data—Recorded just like a continuous plant. An idle unit may fill up with condensate from a leaking steam valve or worse. A spike in any reading asso- ciated with an idle unit may indicate trouble, as may a reading that stays up after it should have gone down.
• Event data—The best thing to do with event data is to record all that is available with timestamps and source identification. Event data usually includes procedural element start and end, mode and state changes, exceptions, and so on.
• Operator data—Operator data records commands given by the operator that over- ride the recipe procedure or change the control recipe, with the operator’s ID and time. Such data may also include telephone or radio conversations if they can be related to a batch. If not, the operator should log them under operator comments.
• Analysis data—No problem if process analyzers are used, otherwise the data is not real-time. Worse, someone could report the wrong sample and then ask to have the correct results recorded, or realize that one of the numbers was way off and re-ana- lyze the sample. It is best to record all of this rather than go back and change history by replacing the sample report. Include time stamps and identify the people involved.
5.5.2 Common Information
A list of examples of data that would be called common follows:
• Quality Assurance (QA) information—This includes approvals, possibly with quali- fications, of process input material lots and the process output products. The product may be blended into a lot, where the analysis is made. Also includes approvals of process conformance to documented standards.
• Utility systems information—Continuous and event data from boilers, chillers, oil or water heaters, and so on.
• Equipment history—Includes the operating time since the last overhaul, calibration records, time since last inspection, indications of deterioration, over-temperature or over-pressure events, repair history, and so on.
• Operational documentation—Summary data on percent utilization, downtime, amount of products produced, average inventory levels, utilities consumed, and so on.
• Materials information—Records of materials received and produced; high, low, and average quality measurements; records of labels on incoming and outgoing mate- rials, and so on.
5.5.3 Batch History
If the process cell is small, then the stream of batch information may be captured on paper or in flat files. At some point, it makes more sense to use a relational database or its equivalent. The database may be so expensive that it is centralized, or databases may exist for each cell and collection of common information. Whatever, something has to catch the streams of data and make them effectively immortal. In a regulated environment, what you record must be what you are willing to show outsiders.
The product of a batch process may be worthless if there is no batch history available or if what the customer wants to see is missing. It may be necessary to trace the genealogy of the batch as well as its QA tests.
Batch information must be recorded with appropriate key fields, such as the source of the data and the associated equipment identification, time stamp, and value. The information will be sorted into various views in order to make it more useful. The start and end times of a batch along with the equipment ID of the first unit make it possible to sort out everything for one batch, including batch and common data. Sorting is even easier if batch ID is included, although that is not possible for common data.
5.5.4 Batch Reports
Each report represents a different view of batch history. Once the history is captured, reports can be requested whenever recipients need them. Report formats or views may be altered to show different data without modifying the batch history records, unless the data is not in the history. Graphic data may be required. The following is a partial list of possible reports and recipients:
• Production management—Summaries of manufacturing costs, actual and prom- ised manufacturing dates, cost of inventory, equipment utilization, human resource levels, and so on.
• Product development—Detailed reports of equipment activities and analysis results, statistics for many batches, comparisons of similar data among equipment, and so forth.
• Plant operations—Reports of current operations in the plant, summaries of past production.
• Quality management—Reports of data associated with quality for specific batches or equipment, statistical charts summarizing recent and long-term production, and others.
• Authorities—Carefully compiled reports of compliance with regulatory require- ments, with nothing extraneous that might be misunderstood.
• Customers—Whatever they want that they can’t be talked out of, usually related to product quality and process uniformity. Again, nothing extraneous should be included.