Logging is used to store the data from the controller and the APC framework itself. The logs allows controllers to produce an audit trail of the data from each of the control jobs within a controller. This audit trail can contain any data available to the control job (i.e. incoming data, parameters, state, calculated outputs, etc.). The columns are defined as part of the controller and are not hard-coded into the product.
By default, system logs exist to gain insight into the following:
- System level logging (when the server started, version running, etc.)
- Control job logging showing detailed block-to-block information as the control job is running.
- Notification logging of what and who email notifications where made to.
- Alarm logging of when the alarm was created, who acknowledged and cleared the alarm.
- Many system log tables contain a base set of columns that can be added to with customer site specific context (i.e. LOT, PART, TECHNOLOGY, etc.) allowing for filtering by the user to get the data they need.
Controller defined logging can be use to perform the following:
- Logging of metrology data. Both the raw samples and the summary statistics.
- Logging of the data actually used on the process tool. This may differ from the recommended recipe settings if a user modifies the process run manually on the the tool.
- Logging of recommendations for recipe settings and supporting data (i.e. reference lots, parameters used, etc.)
- Structure of the context and data is fully configurable as part of the development of the controller. While one site may use LOT and another LOTID, it can be configured into the controller what context or data name to use. Only limitation is the column names and type supported by the underlying database.