DMS Pilot Test and Acceptance Checklist for Commercial Fleets

1. Freeze the scope, configuration and reference conditions

Keep one versioned configuration record for the pilot. Include hardware revision, firmware, camera position, enabled event categories, thresholds or settings exposed by the supplier, operational enable conditions and connected accessories. Record any platform, network or license dependency separately.

Agree what counts as an eligible test. Some functions depend on vehicle state or other enable conditions. A parked demonstration may not exercise a function that requires an operating-speed condition. Use the supplier's supported demonstration or simulation method; do not bypass vehicle controls or assume a generic action tests every device.

• Installation checks: secure mounting, view, wiring, power and the documented setup procedure.
• Controlled functional checks: supported demonstrations or simulations in an appropriate controlled setting.
• Normal-operation observation: routine driving with no deliberately induced unsafe behavior, plus authorized event review.
• Workflow checks: alert output, event identity, retrieval, permissions and follow-up.

Do not ask drivers to become fatigued or perform distracting actions on public roads. Observe ordinary operation without inducing hazards; any staged scenario should follow an approved, supervised test plan appropriate to the vehicle and supplier's method. Stop a test that creates an unsafe condition.

See DMS functions and limits for the distinction between a supported alert and a conclusion about the driver. A staged action is not proof of a real fatigue state.

2. Check installation and fit before changing detection settings

Inspect the intended camera position using the selected model's installation instructions. Record mounting location, alignment, the normal driver position and any obstruction. There is no universal camera distance or angle in this worksheet; the applicable limits come from the actual device documentation.

• Check the view at normal seat and steering-wheel adjustments used by the fleet.
• Check whether visors, handles, equipment or clothing obstruct the relevant view.
• Confirm mounting security, cable routing, supply behavior and the supplier's calibration or setup procedure.
• Record the device response when the view is unavailable or the camera is obstructed, if that status is supported.
• After a mounting change, record a new configuration version and repeat the affected checks.

Use a representative mix of driver positions and cab layouts. Keep driver identifiers pseudonymous in a shared test sheet and restrict any installation photos that identify people. The DMS vehicle-fit and installation guide explains why the same mounting arrangement may not transfer across vehicles.

3. Build a matrix for lighting, eyewear and normal variation

Choose conditions that occur in the fleet and identify combinations that need separate checks. Testing each item once does not cover every combination. Mark untested or unsupported conditions explicitly rather than calling the whole vehicle type validated.

Protective equipment or eyewear can create conditions outside a model's supported scope. Record that limitation and the operational decision it requires; do not promise that every camera can detect every event through every lens or face covering.

4. Test the alert and the downstream workflow separately

For each eligible functional check, record the reference scenario, event time and expected output agreed with the supplier. Then record what the device actually produced. Distinguish a local warning from the later arrival of an uploaded event.

• In-cab output: confirm the enabled audible, visual or other supported warning, its location and whether users understand its meaning.
• Event record: check vehicle and device identity, event category, timestamps and any supported clip association.
• Retrieval: test the intended authorized route for accessing an event or clip; recording locally does not guarantee remote retrieval.
• Connectivity: where supported, verify offline behavior, delayed upload and recovery after the connection returns.
• Permissions: test reviewer access and export rules with the intended user role.
• Recovery: perform supported power-cycle or restart checks in a safe parked setting and record the result.

Use separate timing fields for the local output and platform arrival. State the clock source and measurement method. An upload delay should not be mislabeled as the device's detection delay.

Run one available event through the driver-event review and coaching workflow: retrieve evidence, record driver context, assign an action and check closure. This tests whether the fleet can use the record, not just generate it.

5. Evaluate false alerts and missed events with the right evidence

Review generated alerts against the agreed event definition and available contextual evidence. Classify each as supported by the reference, not supported, or unassessable. Keep uncertain cases visible instead of silently counting them as correct or incorrect.

A missed event requires an independent reference. Inspecting only device-generated clips can identify problems with recorded alerts, but it cannot establish how many relevant events the device failed to record. Use an authorized reference method, reviewed observation or supplier-approved test scenario with its own time record. State what the reference can establish and any limitation.

Agree the matching rules before counting: event category, timestamp tolerance, repeats and exclusions. Report the raw numerator and denominator alongside any percentage. Small samples and uneven condition coverage do not justify a universal accuracy claim. If the denominator is zero or the reference is unavailable, report the measure as not assessed.

The fatigue and distraction deployment guide provides the operating context for alert response. A pilot can expose limitations and support a configuration decision; it is not proof of medical diagnosis or guaranteed crash prevention.

6. Keep a test record that another reviewer can repeat

Give each test a case ID and link it to the exact configuration version. Keep the original result after a change; record the repeat as a new run. Store authorized evidence in the agreed repository and reference it rather than placing unrestricted clips in a shared spreadsheet.

Document driver feedback about alert clarity, nuisance burden and the review process. Separate feedback from measured detection results, and separate a supplier demonstration from independent fleet observation.

7. Decide whether to accept, adjust or repeat the pilot

Review the evidence against the criteria agreed before the pilot. Do not change a threshold afterward simply to make a result pass. If the use case or configuration changes, record the revised requirement and the new tests it needs.

• Accept the tested scope: the required checks have sufficient evidence and the agreed criteria are met.
• Accept with a documented limit: the decision owner agrees an explicit operating restriction or unresolved item with an owner and follow-up.
• Adjust and repeat: mounting, configuration, training or integration needs a change followed by affected tests.
• Do not accept: a required function remains unsupported, unusable or lacks adequate evidence for the intended operation.

Record the decision jointly with the people responsible for installation, operations, safety review and integration as applicable. Define which firmware, cab or workflow changes trigger a repeat check during rollout. A result for one cab and configuration should not be silently extended to all vehicles.

Connect the pilot decision to the driver-management workflow: who responds to an alert, who reviews the record and how the fleet acts on the result.

Common questions

Can a short demonstration establish an overall accuracy percentage?

No. Report the actual cases and conditions tested, the reference method and the sample size. Do not generalize beyond that evidence.

How do we check missed events?

Use eligible independently referenced events and pre-agreed matching rules. Device-triggered clips alone cannot reveal unrecorded events.

Does every vehicle need the same camera position?

Use the selected model's instructions and validate the cab and driver-position range. Record differences and repeat affected tests.

Should a firmware change restart the whole pilot?

Determine the affected functions with the supplier, retain the previous version's results and repeat the relevant checks. A major scope change may require a broader pilot.