An interlock is an alcohol interlock that controls whether a vehicle can start based on the result of the driver's breath test. Drivers subject to installation, or fleet managers, may assume they can start driving as soon as the device is connected to the vehicle, but completing installation is not the same as being ready to operate. Acceptance testing is the process of confirming, on the actual vehicle, that the device's basic functions, record management, and user support channels all connect.
The AF-i1 consists of a handset that measures breath and a control box that processes vehicle signals. The product guidance explains that it is designed so the vehicle will not start if the test result exceeds the set threshold. So at acceptance, rather than stopping at receiving the components, it is better to check separately whether the test result and start control are linked on that vehicle and whether you are ready to manage the data generated afterward.
Check that the vehicle and device are matched correctly
First, compare the vehicle information in the installation documents with the actual vehicle, and record the device identification as well. Whether all the components to be delivered, such as the handset, control box, mount, and connecting wiring, are present is also something to check. This makes it clear which device is installed in which vehicle when you later download records or request inspections.
The AF-i1 guidance states that it stores events such as vehicle ACC, engine start, test results, and tamper-related events with date and time information. Checking the time information shown on the device or in the management software during acceptance reduces confusion when you later compare vehicle operating data with device records. This is not a separate procedure to verify time accuracy; it is a check of whether records can be identified.
Check basic functions in a parked vehicle
Run the function demonstration in a safely parked vehicle, within the scope agreed with the installer. Confirm the basic flow in which the user performs a breath test with the handset and the vehicle's start control follows from the result. The purpose of this item is to see whether start control based on the test result is actually connected on the installed vehicle.
Screen messages and operating sequences must be confirmed on the actual device, since they depend on model settings and the installation. The person accepting the device should check whether they can tell what to do next from the information on the device and the user guide, and ask the installer to explain any indication they do not understand. A single successful start does not mean that all conditions of use and error situations have been confirmed.
Do not stage tests; look at how records are managed
The AF-i1 guidance describes functions that detect and store events related to whether a person is providing breath directly, whether the vehicle is driven without an approved test, and whether the device is removed from the vehicle. However, acceptance testing must not deliberately create situations such as disconnecting the device or driving without approval. Rather than reproducing dangerous or inappropriate actions, it is appropriate to decide who will check the records and request support when such events occur.
If records are managed and downloaded with dedicated software, check right after the demonstration whether you can find the data for that vehicle, device, and time. Record the fact that the demonstration was performed and the fact that the records were looked up separately. That way, if data is missing later, you can tell whether it is a problem with the test function or with the record lookup procedure.
| What to look at during acceptance | Check on site | Criterion for completion |
|---|---|---|
| Vehicle-device connection | Compare vehicle information and device identification with the installation documents | The installed vehicle and device can be identified in the documents |
| Test result and start control | Run a demonstration within the agreed scope with the vehicle parked | A record shows that basic operation according to the test result was confirmed |
| Record lookup | Look up the data from the demonstration time in the software | A way to separate test data from other operating data is set |
| Later inspection and support | Assign who handles the user guide, contacts, and checking reminders | It is clear whom to contact when a problem occurs and who is responsible for inspections |
When records do not appear, break down the possible causes
As a hypothetical example, consider a logistics fleet manager and driver who completed a demonstration right after installation but could not immediately find that demonstration record in the software. The observed fact here is that "the record could not be found," and it is not grounds for immediately concluding the device is faulty. A possible action is to recheck the vehicle information, device identification, and demonstration time, and then ask the installer to confirm the lookup method or settings.
This item can be considered complete if you can identify the demonstration data for that time and keep it separate from other operating data as data generated by the acceptance test. Conversely, if the data still does not appear or the vehicle information is linked differently, leave it as an unconfirmed item and set what the installer will check and a date for rechecking. You can also suggest recording the test date and purpose together so that test records are not mistaken for events that occurred during actual operation.
Hand over with user and manager roles separated
The user must be able to find the user guide inside the actual vehicle when a test does not proceed as expected. They also need to know which contact to ask for support, without operating the device on their own or changing the installation. At the acceptance stage, actually finding and understanding these response paths is more necessary than tests that deliberately trigger errors.
The fleet manager takes on the additional roles of checking records and managing the inspection schedule. The AF-i1 guidance mentions inspection and calibration reminders, and the official product page gives a calibration interval of every 12 months. Rather than writing down only the next inspection date, assigning who will check the reminders and who will book or request inspections keeps tasks from being missed even when the person delivering the vehicle, the driver, and the manager are different people.
Record unconfirmed items with a follow-up schedule
Acceptance testing is not a declaration that every possible situation has been reproduced at once. It is a procedure for recording whether the basic functions, record management, and user support needed to start actual operation are in place. For anything not confirmed on site, it is better to record the reason it was not confirmed, who will confirm it, and the date for rechecking, and manage it as an item to be completed.
Installation completed, user briefing completed, record lookup confirmed, and inspection schedule registered are separate items. Registration or administrative procedures that may be required separately from installation acceptance are also not confirmed by a function demonstration. In acceptance testing, it is appropriate to clearly record the device's operation on the vehicle and operating readiness, and to confirm separately, within the scope of drunk-driving laws, whether any legal requirements apply.
