In regulated production environments, it is not enough for a product to have been inspected correctly. It is equally important to provide a traceable record of how the inspection result was generated.
In the pharmaceutical industry, medical technology and other sectors with demanding quality assurance and traceability requirements, relevant events, changes and results must be documented clearly. During an audit, the statement “The system performed the inspection” is usually not sufficient. It must also be possible to show under which conditions the inspection was carried out, which inspection program was used, who made changes and which data were stored or transferred.
This transforms a purely technical inspection solution into a system that not only detects defects, but also supports the required level of traceability.
Inspection Is Only One Part of the Quality Record
A machine vision system can inspect products for presence, completeness, geometry, surface defects, codes, plain text and other quality features. However, the pass/fail result represents only part of the information required in regulated environments.
Additional questions may include:
- Which product and batch were inspected?
- Which inspection program was active?
- Which program version was used?
- Which parameters and tolerances applied?
- When was the inspection performed?
- Which result was generated?
- Which measurement values or images were stored?
- Who changed settings or programs?
- When were the changes made?
- Were data transferred to other systems?
- How were defects or system messages handled?
The specific requirements depend on the application, risk assessment and internal operating procedures. The key point is that the necessary records should not be improvised afterward. They must already be considered during the design of the inspection system.
Traceability Begins with the System Architecture
Audit readiness is not created by a single software function. It results from the coordinated interaction of several system components.
These include in particular:
- machine vision and inspection software,
- user and rights management,
- recipe and program management,
- audit trail,
- result and image storage,
- timestamps and system information,
- databases and interfaces,
- connection to the machine control system or higher-level systems,
- and defined operating and change-control processes.
If these areas are planned separately, gaps can arise. An inspection program may store results but fail to document changes. A user management system may distinguish roles while critical parameters can still be modified without a traceable approval process. Or inspection data may be stored locally without being clearly assigned to a batch or serial number.
OCTUM therefore treats technical inspection and the associated data and user structure as one integrated system.
User Management Creates Clear Responsibilities
Not every user requires the same permissions. Operators, setup personnel, quality assurance, maintenance staff and administrators have different tasks and responsibilities.
A suitable user management system can therefore map different roles and permissions. It can define, for example:
- who may select inspection programs,
- who may change parameters,
- who may create or release new programs,
- who may view or export results,
- and who may edit administrative settings.
This prevents critical changes from being made unintentionally or without sufficient authorization.
At the same time, user management must fit the actual production environment. An overly complex concept can lead to shared accounts or workarounds. The objective is therefore to combine security and traceable responsibilities with practical operation.
Audit Trail: Documenting Changes Transparently
An audit trail is used to record relevant events and changes in a traceable manner. Depending on the system and application, this may include:
- user login and logout,
- changes to inspection parameters,
- adjustments to tolerances,
- creation, modification or activation of inspection programs,
- changes to user rights,
- system messages and faults,
- data exports,
- and administrative interventions.
It is not enough to store the fact that a change occurred. The change should also be assigned clearly. Relevant information typically includes the user, timestamp, affected setting and type of change.
Depending on the requirements, a reason or approval may also be required. This should be considered when defining user and change-control processes.
Recipe Management for Controlled Inspection Programs
Production lines often process different products, formats and variants. Each configuration may require different inspection programs, tolerances or image acquisition parameters.
Structured recipe management ensures that the correct inspection program is selected and used unambiguously. Relevant aspects may include:
- clear naming and identification of the recipe,
- versioning of inspection programs,
- assignment to a product or format,
- controlled release of new versions,
- traceable changes,
- automatic selection via order or machine data,
- and prevention of unintended program changes.
The mere existence of an inspection program is not enough. It must remain traceable which version was used for which production run and at what time.
Establishing Batch and Product Assignment
An inspection result becomes particularly meaningful when it can be assigned unambiguously to a product, batch or serial number.
Data from different sources can be combined for this purpose, including:
- machine or order data,
- batch number,
- product or format identifier,
- serial number or code content,
- timestamp,
- inspection program and program version,
- measurement values,
- defect class,
- pass/fail result,
- and stored inspection or defect images.
This assignment provides the basis for retrieving results later and evaluating them in the context of a specific production run.
Especially when several inspection stations are involved, it must be ensured that the respective results are assigned clearly to the same product. Reliable product tracking is therefore essential not only for rejection, but also for documentation.
Considering Data Integrity Across the Entire Data Flow
Inspection data may be generated within a system, stored locally, transferred to a database or forwarded to higher-level systems. At every stage, it must be ensured that the data remain unambiguous, complete and traceable.
The following questions must be clarified:
- Which data are generated?
- Which data must be stored?
- Where are they stored?
- How long must they remain available?
- Who may view, change or export them?
- How is data transfer monitored?
- What happens in the event of a communication failure?
- How are timestamps synchronized?
- How is unintended overwriting of results prevented?
- How can stored information be retrieved later?
The data connection should therefore not be added only after the inspection system has been completed. It is part of the overall concept and influences software architecture, storage requirements, interfaces and operating processes.
Storing Images and Measurement Values Selectively
Not every application requires all images to be stored. In other cases, documenting only a pass/fail result is not sufficient.
Depending on the inspection task, a tiered storage concept may be appropriate. Options include:
- storing all inspection results,
- storing individual measurement values,
- storing only defective products,
- storing defined samples,
- storing images in borderline cases,
- or event-based storage for specific defect classes.
Data volume, retention periods and access options must be taken into account. High-resolution image data can generate considerable volumes, especially at high production speeds.
The storage concept should therefore be derived from the actual documentation requirements. The objective is not to collect as much data as possible, but to provide the relevant information completely and in a retrievable form.
An Audit Trail Does Not Replace Clear Processes
Technical functions alone do not create robust audit readiness. Defined organizational procedures are equally important.
These include, for example:
- roles and responsibilities,
- approval of inspection programs,
- handling of parameter changes,
- response to system messages,
- data backup,
- regular review of user rights,
- user training,
- and procedures for maintenance and system changes.
If a system records changes but no one has defined which changes are permitted and how they must be reviewed, a significant gap remains.
Audit readiness is therefore always the result of suitable technology, clear processes and trained employees.
Designing Software and Machine Integration Together
The machine vision system is usually connected to other systems. These may include a PLC, line control system, databases or quality assurance systems.
Responsibilities between these systems must be defined clearly. For example, the machine vision system may generate the inspection result while the machine control system tracks and rejects the product. A higher-level system may provide batch data and archive results.
The following questions must therefore be clarified:
- Which system supplies product and batch data?
- Which system manages inspection programs?
- Where is the binding pass/fail decision generated?
- Which system is responsible for product tracking?
- Where are the results stored?
- Which feedback signals and acknowledgements are required?
- What happens in the event of communication failures?
A clear interface definition prevents inconsistent data and simplifies commissioning, maintenance and later audits.
Considering System Changes Throughout the Life Cycle
An inspection system does not remain unchanged over its entire service life. Products, requirements, operating systems, hardware components and interfaces can change.
Possible changes include:
- new product variants,
- adjusted tolerances,
- additional inspection features,
- new defect classes,
- software updates,
- replacement of cameras or computer hardware,
- changes to databases or interfaces,
- and adjustments to user roles.
Such changes must be carried out and documented in a controlled manner. Their impact on inspection performance, data integrity and existing approvals must be assessed.
A maintainable system concept therefore considers not only initial commissioning, but the entire life cycle.
Defining Audit Readiness at an Early Stage
The required functions and records cannot be defined identically for every application. Requirements depend on the product, process, risk, company specifications and regulatory environment.
The following questions should therefore be clarified at the beginning of the project:
- Which events must be logged?
- Which user roles are required?
- Which changes are critical?
- Which data must be stored?
- How are results assigned to products and batches?
- Which retention periods apply?
- Which systems must be connected?
- Which reports and analyses are required?
- How are programs released?
- Which records are expected for acceptance and operation?
The system architecture, software functions and interfaces can then be derived from these requirements.
Addressing audit readiness only shortly before acceptance creates a risk of costly rework and structural limitations.
From an Inspection Solution to an Audit-Ready System
A technical inspection solution answers the question of whether a product meets the defined quality requirements. An audit-ready system must additionally make it possible to trace how that result was generated.
This includes:
- unambiguous user identification,
- controlled permissions,
- traceable program and parameter changes,
- assignable inspection and batch data,
- documented results,
- defined data flows,
- and a robust operating and change-control concept.
OCTUM therefore does not treat these requirements as a later addition. Machine vision, software, user management, audit trail, recipe management and data integration are planned together from the beginning.
Because during an audit, the statement “The system performed the inspection” is not enough.
A better answer is: The system performed the inspection—and it can be shown how, when and under which conditions.