Field notes5 min read
A week with the cameras: deploying vision intelligence at a port, a pipeline and a perimeter
Detection is a demo. Tracking, fusion and fewer false alarms are the work. What the first week on site looks like, and what the operators end up with on their screens.
Most vision demonstrations happen in a meeting room, with a good camera and a cooperative volunteer walking across the carpet. The job happens at four in the morning, in haze, through a fifteen-year-old camera that someone bumped in 2019 and that now points slightly at the sky. Everything below is about the second kind of room.
Day one: we sit with the operators
Before we install anything we spend a day in the control room, watching. Which screens do the operators actually look at. Which alerts do they silence within a second, and why. What they know about the site that no document says: that the fishing boats come in at dusk, that the wind sets off camera twelve, that the guard at the north gate parks in the wrong place every Thursday. This is the most valuable day of the project, and the one vendors usually skip. Everything we build afterwards is measured against what these people already know.
A port: the ship that went dark
- The situation
- A port authority has cameras along the quays, a coastal radar, and the AIS feed that ships broadcast. Three screens, three pictures, three operators. A vessel switches off its transponder a few miles out. AIS shows nothing; the radar shows a contact; the cameras show a grey shape in haze. Nobody is sure they are looking at the same thing.
- What we build
- One track per vessel. Radar returns, camera detections and AIS positions are fused, so a contact that has gone dark on AIS still carries the identity it had before it went dark, and its course and speed come from the track rather than from what it chooses to broadcast. The system flags the dark contact, estimates where it will be in twenty minutes, and turns the nearest camera to it. Berth and pilot planning read from the same picture, so an arrival that slows down moves the plan.
- What the operator sees
- One screen. Every vessel has one label, one heading, one speed. The dark contact is highlighted, with the time it went silent and the camera that has it. The operator clicks once to see the footage and once to log it. No third screen.
- What it needs from you
- Read access to the radar and AIS feeds, the camera positions and their fields of view, and two weeks of recorded traffic so the system can learn what a normal day looks like before anyone trusts an alert. A harbour master's hour, once, to tell us which vessels never need flagging.
A pipeline corridor: cameras and pressure sensors on one map
- The situation
- Hundreds of kilometres of pipeline across open ground. Cameras at valve stations, pressure and acoustic sensors along the line, both installed years ago and both watched separately. The camera alerts are mostly wind, animals and shepherds. The sensor data is logged and looked at after something has happened.
- What we build
- At the stations, vehicles and people are detected and tracked across cameras, so a truck that stops where trucks do not stop is one event rather than four camera alerts. Along the line, an acoustic and pressure model learns the pipeline's normal behaviour, station by station, and flags a departure from it days before a failure, with a location rather than a section number. Both arrive on one map in the control room.
- What changed
- The control room stops chasing camera alerts caused by weather, because the system learned in the first month what a windy night at station nine looks like. The maintenance crew drives to a kilometre marker instead of walking a section. The engineers can see, for the first time, the pressure trace and the camera at the same place and time.
- What it needs from you
- The sensor history, as far back as it goes. Access to the camera streams. A month of the system learning normal before the alerts are switched on for real, and an engineer who will tell us, honestly, which past incidents the model should have caught.
A perimeter: the drone with no transponder
- The situation
- A facility with a no-fly perimeter and a security team that has started seeing small drones. Radar returns at that size are noisy. The guards hear something before they see it, and by the time a camera finds it the drone has gone.
- What we build
- A model that finds small, fast objects against the sky, follows them, and predicts where they will cross the perimeter. It runs on the existing cameras and, where there is one, on the radar feed. A detected drone becomes a track with a predicted path; the nearest camera is turned to it; the existing alarm system is triggered through the interface the guards already use. Birds are learned as birds within the first week.
- What the guard sees
- A track on the site map, a predicted crossing point, and the camera already on it. One line of text: drone, direction, seconds to the fence. The response is theirs; the system's job is to give them the seconds.
- What it needs from you
- The camera layout, the alarm system's interface, and a few days of the sky over the site, which is how the system learns the birds, the aircraft on approach and the one guard who flies his own drone at lunch.
Why false alarms are the whole game
Operators stop trusting a system the day it cries wolf. Every alert that turns out to be wind costs a little of the trust that a real alert will need later. Most of the engineering in a deployment is therefore not detection at all; it is learning what normal looks like at that site, hour by hour, camera by camera, so that the alerts left over are the ones worth a human's time. That learning has to happen on the site's own footage. It cannot be shipped in.
The system's job is to give the guard the seconds. The response is theirs.
Where the faces go
People ask about faces early, and they should. The systems run on the operator's own servers, inside the perimeter, and can run with no outside connection at all. Faces are matched only against lists the operator holds, under the operator's own policy, and nothing is kept longer than that policy allows. Nothing is sent anywhere else. The models and the code are handed over, so the site keeps running and keeps learning without depending on anyone outside the fence.
Enquiries and interviews: info@goldenlineai.com