People counting camera support: what to verify

A people-counting installation can produce images while still failing to deliver usable entry, exit or occupancy data. For buyers and automation teams, the purchasing question is therefore broader than camera selection: who will configure, integrate and maintain the complete application? Use this checklist to assign support responsibilities, define the data interface and agree on acceptance tests before committing to hardware or an analytics subscription.

1. Separate camera support from counting application support

Start with the required output, not the camera specification. Decide whether you need directional entry and exit totals, estimated occupancy, periodic reports or events delivered to another system. Each output creates different integration and support obligations.

A camera may supply images or depth data without providing tracking, direction detection, reporting or application support. Likewise, an analytics package may accept only particular devices, firmware releases and mounting arrangements.

The camera acquisition software compatibility guide explains the acquisition layer. Successful acquisition is necessary, but it does not demonstrate that a complete counting application is supported.

Before requesting a proposal, check that it identifies:

• [ ] The camera and the approved firmware release, so hardware compatibility is traceable.
• [ ] The analytics software, deployment location and legitimate licensing requirements, so the processing responsibility is clear.
• [ ] The counting outputs and receiving application, so integration includes more than a demonstration display.
• [ ] The commissioning and acceptance work, so installation does not end when images appear.
• [ ] The primary support contact and escalation process, so faults do not circulate between separate providers.

Ask for these items in the proposal rather than relying on a verbal description of a complete package.

2. Assign an owner to each support boundary

One contact can coordinate several technical teams, but coordination must be explicit. Ask who owns diagnosis when the camera streams correctly but the reported count is wrong.

Use a responsibility table like this during the purchasing review:

• [ ] Name a primary case owner who remains responsible until the fault is classified.
• [ ] Define remote-access arrangements, authorization and diagnostic data handling before commissioning.
• [ ] Distinguish initial tuning from later changes to the doorway, layout or reporting requirements.
• [ ] Ask which changes require paid engineering rather than routine support.

A useful support commitment identifies deliverables and boundaries. A general promise of technical assistance does not establish responsibility for your analytics or business-system integration.

3. Verify the camera's role before selecting hardware

Compare 3D sensors and smart cameras and vision sensors only after identifying the analytics requirements. Depth sensing and on-device inspection describe technical capabilities, not an approved people-counting package.

The MV-DT01WMU is listed as a ToF sensing camera. Its catalog classification alone does not establish directional counting, an analytics interface or support for your intended installation.

The MV-SC3050XC-16M-ATN-H is listed as a color vision sensor. That description does not establish a people-counting algorithm or compatibility with a particular analytics service.

These are hardware examples to discuss during qualification, not confirmed people-counting recommendations. Use the camera finder to compare catalog attributes, then obtain written confirmation of application compatibility before ordering.

For each proposed device, check:

• [ ] The analytics provider explicitly supports the exact model and firmware combination.
• [ ] The installation geometry is within the application's documented operating conditions.
• [ ] Any required image or depth stream is available through the supported interface.
• [ ] Processing location, licensing and network requirements are documented.
• [ ] Replacement hardware can receive the approved configuration through a supported procedure.

For depth-based installations, the 3D camera positioning guide helps frame the mounting discussion. Do not assume a different mounting height or viewing angle can be corrected entirely through software.

4. Define counting events and integration behavior

Specify what constitutes a count. Crossing a doorway boundary is different from appearing in a detection region. Someone who approaches, pauses and turns back should be handled according to an agreed rule, not an undocumented default.

• [ ] Define the entry and exit directions using a marked installation drawing.
• [ ] Specify whether the interface provides individual events, cumulative totals, interval totals or estimated occupancy.
• [ ] Request sample payloads with field names, timestamps, units and reset behavior.
• [ ] Identify documented delivery guarantees, retry behavior and duplicate-handling responsibilities.
• [ ] Test how the receiving system distinguishes an unavailable measurement from a genuine zero.

For an event-based interface, ask whether a stable event identifier is available. If delivery can repeat, the receiving application needs a supported way to avoid counting the same event twice. Do not assume every protocol provides that behavior automatically.

Also define who maintains the connector when either application changes. A working demonstration against a temporary endpoint does not prove that your production reporting system is supported.

5. Agree on numerical acceptance criteria

Validate entry and exit counts separately. Net occupancy alone can conceal errors because missed entries and missed exits can cancel each other.

Use a defined observation period and independently recorded reference counts. One simple acceptance measure is directional count error:

The percentage calculation requires a nonzero reference count. For empty scenes, record false counts directly rather than dividing by zero.

For example, suppose an observed trial contains 120 entries and 80 exits. The system reports 116 entries and 82 exits:

• Entry error: 100 × |116 - 120| / 120 = 3.3%.
• Exit error: 100 × |82 - 80| / 80 = 2.5%.
• True net change: 120 - 80 = 40 people.
• Reported net change: 116 - 82 = 34 people.

Starting from an empty space, the occupancy estimate is therefore low by 6 people. These are illustrative calculations, not promised performance or recommended acceptance limits.

• [ ] Agree on separate limits for entry error, exit error and occupancy drift.
• [ ] Test quiet periods, busy periods, side-by-side passage, pauses and turnbacks.
• [ ] Include representative carrying items and partial occlusions where relevant.
• [ ] Preserve the reference method, configuration and test conditions with the results.

Aggregate totals can still hide missed people offset by false detections. Where practical, review event-level matches as well. Choose test duration and sample size around the operating conditions you need to demonstrate; a short demonstration is not a universal accuracy guarantee.

6. Check updates, recovery and ongoing operation

Ask who approves firmware and analytics updates, who performs them and who validates the resulting counts. A security update and an application upgrade may have different owners, but both need a supported deployment process.

• [ ] Obtain software and firmware only through the manufacturer or its authorized distribution channels.
• [ ] Record the approved camera, firmware, analytics and interface versions together.
• [ ] Export configurations through documented tools and record legitimate license-recovery requirements.
• [ ] Confirm the vendor-supported recovery procedure before updating; do not assume every release permits rollback.
• [ ] Repeat acquisition, integration and counting checks after maintenance.

The camera firmware mismatch guide covers version-related detection faults. The machine vision software upgrade validation checklist provides a broader framework for controlled changes.

Include a restart and network-interruption test in commissioning. Check whether totals persist, reset or require reconciliation, and verify that the receiving application recognizes any data gap. Record the observed behavior instead of assuming counters survive every interruption.

7. Know when a camera purchase is the wrong next step

Buying hardware first is usually premature when nobody has accepted responsibility for analytics compatibility or count validation. Resolve those gaps before comparing additional camera specifications.

• [ ] If you need only periodic traffic totals, confirm whether continuous occupancy tracking adds unnecessary complexity.
• [ ] If people can enter through unmonitored routes, address coverage before relying on occupancy estimates.
• [ ] If scene conditions fall outside the analytics provider's documented limits, request a representative trial or another approach.
• [ ] If identifiable imagery is unnecessary, ask whether the required output can be produced without retaining it.
• [ ] If the output will affect machine safety or emergency functions, obtain a compliant safety design rather than treating ordinary counting analytics as a safety function.

Privacy, retention and access requirements should be part of the application specification. Ask what leaves the device, where it is processed and who can retrieve recordings or diagnostic captures. Keep retention limited to the agreed operational need and applicable requirements.

8. Complete the pre-purchase handover checklist

Before approving the purchase, assemble a compact handover package:

• [ ] Supported configuration: exact hardware, approved software versions, licenses and installation conditions.
• [ ] Responsibility matrix: setup, tuning, integration, updates and escalation owners.
• [ ] Interface contract: message examples, counter meanings, resets and interruption behavior.
• [ ] Acceptance plan: reference method, representative scenarios and agreed error limits.
• [ ] Recovery record: configuration backups and documented restoration procedures.
• [ ] Operational instructions: routine checks, fault reporting and change-control requirements.

Do not accept an image preview as evidence that the counting application is complete. Acceptance should demonstrate that representative passages produce the agreed events and that those events reach the intended destination correctly.

For a hardware compatibility review, send the required outputs, installation geometry and proposed analytics package through application support. With those responsibilities established, use the camera configurator to organize the hardware selection without confusing component support with ownership of the complete counting system.