An interlock is an alcohol interlock that controls vehicle starting based on the result of the driver's breath test. The AF-i1 consists of a handset the driver blows into and a control box connected to the vehicle, and it stores usage events such as vehicle ACC, engine start, test results, and tampering detection along with date and time information. Dedicated PC software is used to download and manage these records and to configure how the device operates.
When a fleet manager or installer accepts the software, it is not enough to see that the program installs and files are created. The downloaded records are only useful for actual fleet management if you can link them to the vehicle and device they came from, and to the event and time they describe. So the core of acceptance is not listing on-screen features, but confirming that you can find and store the records you need and explain them on the same basis even after the person in charge changes.
Start by aligning the information that identifies devices and vehicles
When an organization runs several vehicles, it can be hard to determine the source of a record from the vehicle number alone. If a vehicle is swapped or a device is replaced, records from different devices may end up under the same vehicle. Before acceptance, it is best to check with real data what information the management screen or downloaded files use to tell vehicles and devices apart.
The list of managed assets can then bring together vehicle identification, the identification of the installed device, and the operating department or responsible manager. Whether the software has features to enter or display these items needs to be checked in the configuration currently supplied. Just because the official product information describes log event management and download through dedicated software, you cannot assume that every screen and printout automatically shows the identifiers you need.
Look at test time and processing time separately
Interlock records can include not only test results but also several kinds of events, such as vehicle ACC, engine start, and tampering detection. Even for records from the same day, the time of the breath test, the time the vehicle status changed, and the time the records were downloaded to the PC can all differ. If you do not know what the time shown in a report means, you may misread the sequence of a trip.
Pick one test record and compare the screen with the file. Check whether the date and time are shown, what the time zone and display format are, and whether the time the file was created after download could be confused with the time the device recorded the event. Do not give an unconfirmed time field a name of your own. Leave it as an item whose meaning must be confirmed with the supplier.
| What to look at during acceptance | What to actually compare | Why it matters in operation |
|---|---|---|
| Link between vehicle and device | Vehicle and device identifiers in the test record | To pin down where a record came from |
| When an event occurred | How test, start-related event, and file creation times are shown | To interpret the sequence of a trip |
| Downloaded files | The period viewed on screen versus the period in the file | To check that no records from the needed period are missing |
| User permissions | What can be viewed, downloaded, and reconfigured | To reduce changes made outside a person's role |
Verify on-screen views and file contents with the same case
As a hypothetical example, suppose fleet manager A downloads one vehicle's interlock records for the month of March. On screen, that vehicle was selected and the period was set to March. But if the generated file contains no vehicle or device identifier and no period, a person who receives only the file will find it hard to judge what the data covers.
The observation in this situation is whether the selection conditions on screen connect to the identification and period information inside the file. If they do not, the likely interpretation is not that file creation failed, but that there is no adequate way to explain the source of the data as it is passed on and stored. As a possible action, you can compare a screen capture of the test data with the downloaded file, and set a method of writing the vehicle, device, query period, and download date in the file name or in a separate management log. The completion criterion is a state in which another person receiving the same data can explain, without further guessing, which vehicle and period the records cover.
Keep test data separate so it does not mix with actual trip records. After testing, mark which data was for verification, and set out where actual management records are stored and how they are named. This process does not mean testing every feature of the software. It is a procedure to confirm that the views and downloads needed at the site connect to each other.
Check view, download, and configuration permissions separately
The dedicated software can be used not only to manage and download log events but also to configure device operation. So before acceptance, you need to check with actual accounts and screens whether the person who views records, the person who downloads and stores files, and the person who configures device operation have the same permissions or different ones. Rather than assuming a particular permission scheme is provided, it is safer to confirm what is possible in the version currently installed.
Operating rules work better when they specify actions rather than just listing names. For example, you can set it so the fleet manager downloads monthly records and stores them in a designated folder, and so any device configuration change records the settings before and after and the reason for the change. When the person in charge changes or the management PC is replaced, hand over the location of existing records, the means of accessing the software, and the first download task the new person will perform, so record management is not interrupted.
Include correction requests and maintenance alerts in the record flow
There may be cases where a record's vehicle link or a report's display needs correcting. What value the device originally stored, whether anything was changed on the screen or in reporting data, and where the reason for a change can be recorded are separate questions to confirm. If it is not confirmed whether the method changes the raw data or adds an explanation for reporting, it is better not to just change the value and use it.
The AF-i1 is described as having maintenance and calibration alert features. The scope of acceptance can also include who checks an alert on screen when it occurs, which device in which vehicle it concerns, and in what document or management list you record whether follow-up action is complete. If the person who downloads records and the person who maintains devices are different, set the route for passing on alerts as well, to reduce situations where only one side knows and the alert goes unaddressed.
On the acceptance sheet, rather than noting only whether a feature exists, such as "log download available," record the vehicle and device used for testing, the period checked, the file storage location, the results of the permission checks, and any unconfirmed items. Recording it this way lets the next person check again under the same conditions, and lets you judge whether the software was handed over in the way actual vehicle record management requires.
