Key points
- A station can keep the images it takes, together with the result, any code it read, the time, the line and the recipe.
- Keeping only reject images is light; keeping every image answers more questions but needs storage that is planned.
- What to keep, where and for how long are your decisions, set by your records policy, your customers and the law that applies to your product.
- An image shows what the camera saw at that point on the line. It cannot show what happened to the product afterwards.
- If people can appear in the images, treat them as personal information: aim the camera at the product and keep only what you need.
What a station can store
Every inspection starts with an image. Whether that image is thrown away after the decision or kept, and what is kept with it, is a design choice made with you. An image on its own is of little use months later; it becomes evidence when it carries the data that says what it is.
| Item | What is stored | What it answers |
|---|---|---|
| Reject images | The image of each failed unit, with the check that failed and the reason. | Why a unit was rejected; whether rejects were real defects. |
| Pass images | Images of units that passed: all of them, a sample, or the last ones before a stop. | What a good unit looked like when it left the line. |
| Codes read | The content of a barcode, 2D code or printed date and batch code read by the station. | Which batch or unit an image belongs to. |
| Time stamp | Date and time of each inspection, from a synchronised clock. | When a unit passed; matching to other records. |
| Line and station | Which line, station and camera took the image. | Where in the plant the evidence comes from. |
| Recipe and limits | The recipe in use and the version of its limits. | Which product was set, and which limits applied. |
| Counts | Inspected, passed and rejected per batch or shift, per check. | How many units were checked in the batch. |
Every unit or every batch
A unit-level archive links each image to one unit. That is possible when each unit carries a unique code that the station reads, such as a serialised 2D code, so the code becomes the name of the image. Without a unique code, images are linked to the batch and the time: you can find the images of the batch and the minutes around a given time, but not prove which image shows a particular pack.
A batch-level archive is usually enough to answer “was this batch coded and labelled correctly?”. It needs the batch number in the record, read from the pack by OCR or a code reader, or passed to the station from the PLC or MES at the batch change. See OCR/OCV inspection of date and batch codes.
Where the images are kept
- In the smart camera. HIKROBOT’s smart camera selection guide lists image saving in the camera from the SC3000X upward (HIKROBOT Smart Product Catalog 2025 Q4). Space in a camera is limited, so it suits recent images on the line, not an archive.
- On the station PC or vision controller. A multi-view station runs on a PC or controller with its own disk, which can keep reject images and results, and all images for a limited period.
- On a network folder or server. Images and result files are copied from the station to storage your IT team runs and backs up. The SC3000X product row, for example, lists FTP among its protocols (HIKROBOT SC3000X product page); on a PC station the copy is part of the station application.
- In a database, MES or quality system. Results, codes and counts go into a system you can search, with a link to each image on the server. That system is built and run by its owner, not by the vision supplier. The guide to vision data for OEE and MES covers sending results to other systems.
Most archives combine two or three of these: recent images close to the line, the long-term archive on a server. See what a station includes for who supplies the network and servers.
Storage options and what they answer
Where the images are kept decides which questions they can still answer later.
| Storage option | What it usually holds | What it answers | Limits |
|---|---|---|---|
| In the smart camera | Recent images, often rejects, for checking on the line. | What the station saw in the last hours of running. | Limited space; oldest images overwritten; lost if the camera is replaced. |
| Station PC or vision controller disk | Reject images and results; all images for a limited period. | Recent complaints; reject reviews; tuning. | One copy on one disk unless backed up; full disk must be handled. |
| Network folder or server | Images and result files copied from the station. | Complaints and recalls over the retention period. | Needs network, storage and backup from your IT team. |
| Database, MES or quality system | Results, codes, counts and a link to each image. | Searches by batch, code, time or line; reports. | Built by whoever owns that system; images usually stay on the server. |
| Exported batch record | A file per batch with counts and selected images. | Evidence for a customer or an audit. | Only what was exported; agreed format. |
How much to keep, and for how long
Storage and retention are your decisions, not settings the supplier chooses. Three questions set them:
- What must the archive answer? Reject reviews need days or weeks. Customer complaints need the period in which a complaint can still arrive. A recall needs the life of the product in the market.
- What do the rules and your customers require? For food, R638 requires processing and distribution records to be kept for at least six months after the product’s shelf life, together with a traceability system and a recall procedure (R638, regulation 10). Retailer and brand-owner contracts may ask for more.
- Which images are worth keeping? Every reject image is cheap and useful. Every pass image of every unit multiplies storage; a sample of good images per batch, or the images around each reject, often answers the same questions.
Write the decision down: what is kept, where, for how long, who may see it and who deletes it. Then size the storage for that period with your IT team. A station should keep inspecting when storage fills, so the proposal states what happens then: overwrite the oldest images, raise an alarm, or both.
How images answer complaints and recalls
When a customer reports a missing date code, a wrong label or a loose cap, the first question is whether the fault left your line or happened later. With an archive you search by the batch code and date on the returned pack, open the images of that batch and time window, and see what the station saw.
- The images show the fault. Then the question is why the station passed it, or whether it was rejected and the reject failed. Reject confirmation records answer the second part.
- The images show a correct pack. That is evidence that the fault did not leave your line at that check. It is not proof about damage in transport or storage.
- The images show a run of faults. Then the archive shows where the run starts and ends, which keeps a hold or recall to the affected batches.
In a recall, batch records decide how narrow the recall can be; the guide to product recalls in South Africa covers the rules and the causes that start on the packing line. The cost of complaints, returns and recalls is part of the cost of poor quality, and an archive is one way to shorten the investigation behind each one.
Making the archive dependable evidence
- One clock. Station clocks are synchronised with the plant, so image times match PLC, MES and dispatch records. HIKROBOT’s SCMVS client for smart cameras includes time calibration (HIKROBOT SCMVS client).
- Clear names. Each image is named or indexed by line, station, time, recipe, result and code, so it can be found without the station software.
- Read-only copies. Archived images are not edited. Access is by role, and deletion follows the written retention rule.
- Backups. The server copy is backed up like other production records. A single disk in a station is not an archive.
- Known limits. Record which faces and which checks each station covers, so nobody reads more into an image than it shows.
People in the images: privacy
A camera aimed at product on a conveyor rarely records people. Some do: a station at a hand-packing table, an operator reaching into the field of view, a wide view of a dispatch dock. South Africa’s Protection of Personal Information Act (POPIA) defines personal information as information relating to an identifiable, living, natural person, and processing includes recording and storage (POPIA, section 1). In principle, then, an archived image in which an operator can be identified falls under POPIA.
- Aim and crop. Set the field of view and the stored region to the product, so people are not recorded in the first place.
- Keep only what is needed. POPIA requires personal information to be adequate, relevant and not excessive for its purpose, and not kept longer than necessary (POPIA, sections 10 and 14). Your retention rule should cover any image that shows people.
- Secure the archive. POPIA requires reasonable measures to secure the integrity and confidentiality of personal information (POPIA, section 19): access control and backups serve that as well as traceability.
- Tell staff. Let the people who work at the station know what is recorded and why.
This is a general note, not legal advice. Your information officer decides how POPIA applies at your site; the Information Regulator oversees the Act.