Deployment
VisionObject runs in your environment and reads your cameras alongside your recorder. This page compares the four ways to run it, says what is not offered, and describes what happens when something fails.
Deployment choices
Four ways to run it, compared on the same questions.
None is recommended over another. Which fits depends on where the cameras are, who runs the hardware and what must stay on site. So far only the workstation has been run end to end in our own testing; a server or a cloud account requires assessment first.
| Question | Workstation pilotOne workstation at your site, for a first evaluation on a few cameras. | On-premises serverA server in your control room or data room, inside your network. Requires assessment. | Your cloud accountA virtual machine in a cloud account you own and control. Requires assessment. | Recorded footage onlyNo connection to live cameras: upload exports and search them. |
|---|---|---|---|---|
| Where video is processed | On the workstation, at your site. | On your server, inside your network. | On a virtual machine in your cloud account. | On whichever machine runs the platform. |
| Bandwidth | Streams stay on the local network. | Streams stay on the local network. | Every analysed stream travels from the site to the cloud, so the site's uplink must carry them all. | None beyond the upload itself. |
| Sources it can read | Live streams the workstation can reach, and uploaded clips. | Live streams the server can reach, and uploaded clips. | Live streams that can be routed to the virtual machine securely, and uploaded clips. | Exported video files. No live streams. |
| Who provides the hardware | You, to a specification we agree. A graphics card is recommended. | You, sized with us from your camera count, resolution and modules. | You, as a cloud instance with a graphics card, sized with us. | You, to a specification we agree. |
| Resilience | One machine. If it stops, analysis stops until it restarts. | One machine. Clustering and automatic failover have not been validated. | One virtual machine. If it or the link from the site fails, analysis stops; cameras and recorders on site are unaffected. | Uploads and their results are kept on the machine; a failed analysis job can be re-run. |
| Administration | Set up with us. HTTPS is off by default. | Organisations, cameras, retention and AI services are managed in an admin console. Updates are applied in a maintenance window, and analysis pauses while it restarts. | The same admin console. HTTPS is set up at deployment and has been verified with a locally issued certificate only. | Minimal: no cameras to register and no rules to run. |
| Support boundary | We support the VisionObject software. You look after the machine, the network and the cameras. | We support the VisionObject software. You look after the server, its operating system, backups and the network. | We support the VisionObject software. You look after the cloud account, its network rules and its cost. | We support the VisionObject software. Alerts are never raised from uploaded footage. |
| Run end to end in our own testing | Yes. Every test and measurement we have recorded so far was made on one workstation. | Not yet. Requires assessment: it is installed and confirmed with you before a pilot. | Not yet. An install script for a Linux virtual machine exists; it requires assessment before a pilot. | Yes, on one workstation, with exported clips from a fixed camera. |
Workstation pilot
One workstation at your site, for a first evaluation on a few cameras.
- Where video is processed
- On the workstation, at your site.
- Bandwidth
- Streams stay on the local network.
- Sources it can read
- Live streams the workstation can reach, and uploaded clips.
- Who provides the hardware
- You, to a specification we agree. A graphics card is recommended.
- Resilience
- One machine. If it stops, analysis stops until it restarts.
- Administration
- Set up with us. HTTPS is off by default.
- Support boundary
- We support the VisionObject software. You look after the machine, the network and the cameras.
- Run end to end in our own testing
- Yes. Every test and measurement we have recorded so far was made on one workstation.
On-premises server
A server in your control room or data room, inside your network. Requires assessment.
- Where video is processed
- On your server, inside your network.
- Bandwidth
- Streams stay on the local network.
- Sources it can read
- Live streams the server can reach, and uploaded clips.
- Who provides the hardware
- You, sized with us from your camera count, resolution and modules.
- Resilience
- One machine. Clustering and automatic failover have not been validated.
- Administration
- Organisations, cameras, retention and AI services are managed in an admin console. Updates are applied in a maintenance window, and analysis pauses while it restarts.
- Support boundary
- We support the VisionObject software. You look after the server, its operating system, backups and the network.
- Run end to end in our own testing
- Not yet. Requires assessment: it is installed and confirmed with you before a pilot.
Your cloud account
A virtual machine in a cloud account you own and control. Requires assessment.
- Where video is processed
- On a virtual machine in your cloud account.
- Bandwidth
- Every analysed stream travels from the site to the cloud, so the site's uplink must carry them all.
- Sources it can read
- Live streams that can be routed to the virtual machine securely, and uploaded clips.
- Who provides the hardware
- You, as a cloud instance with a graphics card, sized with us.
- Resilience
- One virtual machine. If it or the link from the site fails, analysis stops; cameras and recorders on site are unaffected.
- Administration
- The same admin console. HTTPS is set up at deployment and has been verified with a locally issued certificate only.
- Support boundary
- We support the VisionObject software. You look after the cloud account, its network rules and its cost.
- Run end to end in our own testing
- Not yet. An install script for a Linux virtual machine exists; it requires assessment before a pilot.
Recorded footage only
No connection to live cameras: upload exports and search them.
- Where video is processed
- On whichever machine runs the platform.
- Bandwidth
- None beyond the upload itself.
- Sources it can read
- Exported video files. No live streams.
- Who provides the hardware
- You, to a specification we agree.
- Resilience
- Uploads and their results are kept on the machine; a failed analysis job can be re-run.
- Administration
- Minimal: no cameras to register and no rules to run.
- Support boundary
- We support the VisionObject software. Alerts are never raised from uploaded footage.
- Run end to end in our own testing
- Yes, on one workstation, with exported clips from a fixed camera.
Sizing
What decides the size of the machine
We size hardware with you before a pilot. These are the inputs, in rough order of effect.
- Cameras analysed at once
- Each analysed stream is decoded continuously. Processor capacity for decoding is usually the first limit, before the graphics card.
- Resolution and frame rate
- Plate reading needs a high-resolution stream. Corridors and car parks can use a lower one.
- Modules switched on
- Plate reading and appearance each add work to every sighting.
- How busy the scenes are
- A motion gate reduces analysis work in still scenes, but decoding and health checks continue.
- What must be kept
- Stills and sighting records for the retention period you choose, plus uploaded footage, plate-read history and events, which have no retention period.
Sources and network
What it needs to reach.
- A stream address for each camera that the machine can reach, with its credentials
- No inbound access to the cameras from the internet: the platform connects out to them on your network
- For operators, a browser that can reach the dashboard; HTTPS where the dashboard is reachable beyond a trusted network
- After installation, outbound internet access only if you switch on AI scene reading or the weekly brief, to the AI service and mail relay you configure
- During installation and the first start, internet access to download the software and its analysis models
- For the map, the operator's browser loads the map background from a public map service
When something fails
How it behaves, including what stops.
This is the designed behaviour. We confirm it on your deployment during a pilot, and we make no uptime promise beyond it.
A camera feed drops
The platform retries with a growing delay, shows the camera as degraded and then offline, and raises a camera-offline event. Nothing is analysed from that camera until the picture returns.
Analysis falls behind
Live viewing and analysis are separate paths. When analysis cannot keep up, the oldest waiting frames are dropped and frames that are too old are skipped rather than analysed late. Each camera shows whether it is live, behind, stalled or lost.
The analysis machine runs short of graphics memory
Optional analytics such as plate reading and appearance pause for about a minute and the system reports itself as degraded. Detection continues. An alert that depends on a paused module, such as a plate watchlist hit, is not raised while it is paused.
The AI service is unreachable
Scene readings stop, unless a second AI service you configured can take them. Readings that have waited too long are skipped, not replayed, and rules that depend on them do not fire. Detection, zone and line rules carry on.
A part of the system stops
Each part reports its health, and the deployment shows as unhealthy. VisionObject runs on one machine: if that machine stops, analysis stops until it restarts. Your cameras and recorder are unaffected.
Not offered
What we do not sell.
Said plainly, so it does not surface late in a procurement.
- Analytics inside the camera
- VisionObject does not run on cameras. It reads their streams.
- A packaged edge appliance
- There is no pre-built appliance. An on-site machine is a workstation or server you provide.
- High availability
- Running on more than one machine with automatic failover has not been validated, so we do not offer it.
- A service we host for you
- The platform runs in your environment or your own cloud account, not in ours.
Who does what
Responsibilities.
Ours
- The VisionObject software and its updates
- Sizing the machine with you
- Helping you set up the platform, HTTPS and the first organisation
- Supporting the pilot and reviewing its measures with you
Yours
- The machine or cloud account, its operating system and its network
- Cameras, recorders and their stream settings
- Backups of the database and stored stills, using the procedure we supply
- Accounts, roles and reviewing alerts
Rollout
Connect, draw, decide, review.
No changes to camera firmware and no replacement of your recorder or video management system.
- First
Connect
Register the cameras you chose for the pilot, or upload a set of exported clips. We confirm each source connects and note the ones that do not.
- Next
Draw
Draw zones and lines on each camera: entrances, perimeters, lanes and restricted rooms. A count threshold applies to a camera's whole view, so a queue area needs a camera pointed at it.
- Then
Decide
Start from a starter rule set and adjust it: which events matter on each camera, on what schedule, at what severity, and how often they may repeat.
- Ongoing
Review and tune
Your reviewers mark each alert Acknowledged or False positive. The false-alarm rate by rule and camera shows what to adjust.
See it working on footage like yours.
Tell us the workflow you care about. We will walk through it on demonstration footage, say what is available today, and plan a pilot on your own cameras.