A method for generating driver attendance based on vehicle T-box data and face recognition

Abstract

This invention provides a method for generating driver attendance based on vehicle T-box data and facial recognition. While the vehicle is in motion, the T-box continuously reports driving data, and Flink calculates acceleration, stop, and device offline timeout events in real time. When a valid acceleration event occurs, a facial capture command is sent to the onboard device via the gateway to obtain the image and call the facial recognition service to obtain the driver's identity. Combining the vehicle / driver attendance status in Redis and the verification results from the same organization, an automatic attendance record is generated or a shift change / return record is executed. When a stop, offline timeout event, or scheduled inspection condition occurs, the current attendance is automatically terminated and a return record is generated. This invention eliminates the need for drivers to carry attendance cards, automatically completing attendance based on real driving behavior (acceleration, stopping, offline), solving problems such as forgetting to bring or remove cards, and the inability to supervise fleets without attendance machines. It is suitable for actual operation, and the attendance data is stable and reliable.

Description

Technical Field

[0001] This invention relates to the field of fleet transportation management technology, and in particular to a method for generating driver attendance based on vehicle T-box data and facial recognition. Background Technology

[0002] With the rapid development of industries such as logistics and transportation, engineering construction, and urban delivery, fleet sizes are constantly expanding, and companies are increasingly demanding higher standards for driver attendance, working hour statistics, and transportation compliance management. Driver attendance, as a fundamental aspect of fleet human resource management, directly impacts transportation task scheduling, payroll settlement, safety responsibility tracing, and operational efficiency analysis.

[0003] Currently, common methods for driver attendance tracking include: 1) installing IC / ID card attendance machines in vehicles or depots, where drivers insert the card upon entering and remove it upon exiting; 2) using mobile apps and WeChat mini-programs for check-in and check-out; and 3) combining vehicle location tracking with geofencing to determine attendance within designated areas or time periods. However, significant shortcomings remain in actual operation. First, relying on physical attendance cards or manual operation is unreliable. For fleets with card-operated attendance machines, drivers often forget to bring their cards, use someone else's card, or leave their cards behind when getting off the vehicle, resulting in missing work records, delayed get off work records, or attendance statuses that do not end for a long time, making it impossible for the data to accurately reflect the work situation. For fleets without attendance equipment, it is difficult to effectively supervise drivers' departure and return.

[0004] Second, mobile check-in is disconnected from the actual operating status of the vehicles. Drivers can check in when not driving or miss check-out. The attendance time is not related to objective operating events such as vehicle ignition, driving, and parking. It is difficult for managers to verify the authenticity of attendance, which can easily lead to management loopholes such as "proxy check-in" and "make-up check-in".

[0005] Third, relying solely on location tracking or geofencing results in a coarse-grained manner. It is difficult to distinguish the actual driver based solely on changes in vehicle location, and it is impossible to accurately link the "person-vehicle-shift" relationship in scenarios such as shift changes, shift replacements, and multiple drivers in the same vehicle, making it difficult to assign attendance results to specific drivers.

[0006] Fourth, although in-vehicle telematics boxes (T-boxes) have been widely deployed in the commercial vehicle sector in recent years, enabling real-time collection of vehicle speed, location, ignition / shutdown, and rapid acceleration / deceleration data, and uploading them to cloud platforms; and active safety devices (such as ADAS and DSM driver status monitoring) are gradually becoming more common in commercial vehicles, possessing the ability to capture images and perform facial recognition of drivers in the cab. Some fleet management platforms have integrated vehicle network data, video surveillance, and facial recognition services, but the existing vehicle network and facial recognition capabilities have not formed a closed loop for attendance tracking. While vehicles already possess the ability to report data from T-boxes and perform active safety capture, there is a lack of a unified method for coordinating driving events such as acceleration, stopping, and offline status with capture, facial recognition, and check-in / check-out business rules. This results in the in-vehicle perception data failing to automatically transform into standardized, continuous, and auditable driver attendance records. Summary of the Invention

[0007] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method for generating driver attendance records that utilizes vehicle T-box driving data, combined with in-vehicle face capture and recognition, to automatically complete driver clocking in and clocking out without physical attendance cards.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: A method for generating driver attendance based on vehicle T-box data and facial recognition, including an in-vehicle T-box, an in-vehicle active safety capture device, and a cloud platform; Includes the following steps: S1: Calculate vehicle events and preprocess them to obtain valid acceleration events; During vehicle operation, the on-board T-box continuously collects and reports vehicle driving data. The cloud uses Flink streaming data for real-time calculation to generate acceleration events, dwell events, and device offline timeout events. S2: Effectively accelerates event-triggered face capture; S3: Acquire facial images and perform facial recognition to obtain driver identity information; S4: Generate work attendance clock-in or execute shift change and card return; Based on the identified and confirmed driver identity information, obtain the driver ID, and determine whether to generate a new check-in, execute a shift change and card refund, or ignore the event based on the driver's check-in cache and the vehicle's check-in cache. S5: Card ejection is triggered by dwell events and device offline events; S6: Scheduled task to guarantee card refund; Configure a scheduled task to perform inspections on vehicles that have not reported safety incidents for more than 2 hours and are still in the check-in state, and trigger the card removal based on the location and time of the last safety incident.

[0009] Furthermore, step S1 includes: S11: The vehicle-mounted T-box reports vehicle driving data; Driving data includes vehicle ID, terminal number, GPS time, longitude, latitude, speed, ACC status, and HDOP positioning accuracy value; The cloud forwards the reported driving data to the message queue, and the partition key uses the vehicle ID; S12: Configure Flink streaming computation; Flink is used to consume data reported by the vehicle's T-box in real time from the message queue, and abnormal driving data is filtered out; GPS timestamps are set as the time base, and allowable delays are set to handle out-of-order data caused by network latency; S13: Generate acceleration events; Consume driving data in real time and detect acceleration process: if the vehicle speed exceeds a preset speed within a preset time and remains stable after the speed has changed from a standstill / low speed, an acceleration event is generated and written to the message queue. S14: Generate a dwell event; If the vehicle's latitude and longitude change is less than a preset threshold and the duration exceeds a preset time threshold, a dwell event is generated and written to the message queue. S15: Generate device offline timeout event; When an in-vehicle safety device reports a safety event to the cloud, Flink maintains a status record of the last reporting time for the in-vehicle safety device. Whenever a safety event is received from the device, the last reporting time of the device is updated, the old timer is deleted, and a new timer is set. The trigger time of the preset timer is set. If no new data is received within the trigger time, a device offline timeout event is generated and written to the queue message. S16: Retransmission filtering obtains effective acceleration events; When consuming an acceleration event, first check the difference between the event time and the current system time. If it exceeds the preset time window, it is determined to be supplementary data transmission. The message is directly confirmed but no further processing is done. It is only logged and then discarded. Otherwise, it is a valid acceleration event.

[0010] Furthermore, the acceleration event includes a unique event number, vehicle ID, terminal number, event time, acceleration start time, speed values ​​before and after acceleration, and current latitude and longitude. Step S2 includes: consuming effective acceleration events for business services. First, determine whether the event has been consumed based on the Redis key "terminal number: event type: event time". If it has been consumed, skip this step. If no data is consumed, check the binding relationship between the terminal and the vehicle. If the vehicle does not exist, skip this step; otherwise, send a face capture command to the vehicle's active safety device. After the command is successfully sent, the vehicle's active safety device starts the camera to capture the face. The command includes the terminal number and the serial number of this command. Store the acceleration event in Redis with "Vehicle ID: Command Serial Number" as the key and set an expiration time. Wait for the vehicle's active safety capture device to send back the capture result within the expiration time. If no callback is received after the timeout, discard this acceleration event.

[0011] Furthermore, after the device callback, it consumes the capture result message, determines whether the capture result has been consumed, verifies that the vehicle still exists and the acceleration event cache has not expired, obtains the captured image, and performs face recognition. If no face is recognized, the acceleration event is discarded; if multiple face candidates are recognized, the driver and vehicle are verified one by one to see if they belong to the same organization, and cross-organization recognition results are directly discarded.

[0012] Furthermore, step S3 includes: S31: Consume the capture result message, deduplicate and verify to obtain the captured image; First, after the vehicle-mounted active safety capture device completes the capture, it uploads the image file to the cloud object storage module to obtain a unique multimedia identifier. Then, it reports a message containing information such as terminal number, instruction serial number, multimedia identifier, and capture time to the cloud and forwards it to the message queue. The capture result message is then retrieved from the message queue. Next, using "terminal number: instruction serial number: multimedia identifier" as the key, it is determined whether the capture result message has been consumed. If the key already exists, the message has been consumed and is discarded directly. If no event has been consumed, the system will query Redis for a corresponding acceleration event cache using "Vehicle ID: Command Serial Number" as the key. If the event exists, the captured image will be retrieved from the cloud object storage module based on the multimedia identifier. S32: Obtain candidate driver information through facial recognition; In response to the request, the face recognition service module is invoked to compare the face in the captured image with the pre-entered driver face database in the system and return the driver identity information of the candidate driver. If no face is recognized, the acceleration event is discarded. S33: Driver identity information is obtained through verification with the same organization; For each returned driver identity information, query the driver's affiliated organization ID, and obtain the vehicle's affiliated organization ID according to the vehicle-affiliated organization mapping table. Compare whether the driver's affiliated organization ID and the vehicle's affiliated organization ID are the same. If they are the same, the driver's identity information is adopted and the driver's identity is confirmed. If the affiliated organization IDs of all candidate drivers are different from the vehicle's affiliated organization ID, then the driver and the vehicle do not belong to the same organization, and the current acceleration event is discarded.

[0013] Furthermore, step S4 includes: S41: If the current driver is already clocking in on another vehicle, discard this acceleration event; Use the driver ID as the key to query the driver check-in cache to see if there is a record for the driver ID. Determine if there is a check-in record for that driver. If there is, discard the current acceleration event; otherwise, execute S42. S42: Determine if there are any unfinished check-in records for the vehicle; Using the vehicle ID as the key, query whether there is a check-in record for the current vehicle in the vehicle check-in cache, and determine whether there are any unfinished check-in records for the current vehicle. If there is no check-in record for the current vehicle, it is determined that the vehicle has no unfinished check-in records; otherwise, it is determined that the vehicle has unfinished check-in records. S43: If the vehicle currently has no outstanding check-in records, a new check-in will be generated; The system prioritizes querying the trajectory playback service module to obtain the ignition event as the start time for the driver's shift. If the driver has a history of card cancellation, the system uses the maximum value of the card cancellation time and the time before acceleration one hour prior as the start time for the trajectory query. Otherwise, the system uses the time before acceleration two days prior as the start time and the acceleration event time as the end time. If there is no ignition event, the system uses the acceleration event time as the clock-in time. The clock-in data is written to the database attendance table, and the driver clock-in cache and vehicle clock-in cache are updated. S44: If the vehicle has an unfinished check-in and the driver who checked in is different from the driver identified this time, the original driver's check-in will be terminated first and a refund will be generated; the stop event cache will be queried first. If a stop event exists, the stop event will be used as the basis for refund, and the start time of the stop event will be used as the refund time; otherwise, the current acceleration event will be used as the basis for refund, and the event time of the acceleration event will be used as the refund time. When a card is returned, the attendance record is updated, written to the driver's card return cache, and the card-swiping cache for the vehicle and driver is deleted; then a new card-swiping record is generated for the currently identified driver. S45: If the vehicle has an unfinished check-in and the check-in driver is the same as the driver identified this time, then discard this acceleration event; S46: Delete cache; Delete the cache of this acceleration event after processing is complete.

[0014] Furthermore, the dwell event includes the vehicle ID, dwell start time, dwell location latitude and longitude, and cumulative dwell time; the device offline timeout event includes the terminal number, vehicle ID, offline start time, and the last reported location information; In step S5, both consumption stay events and device offline timeout events are subscribed to simultaneously. The vehicle ID is used as the key to query the vehicle attendance cache in Redis. If the cache does not exist, the vehicle is not currently in attendance, and the event is discarded without any processing. Otherwise, for stay events, the stay start time in the event is used as the card return time, and for device offline timeout events, the offline start time is used as the card return time. The vehicle's currently unfinished attendance is ended, and a card return record is generated. The attendance database attendance record is updated, the driver card return cache is written, and the vehicle attendance cache and driver attendance cache are deleted.

[0015] Furthermore, the vehicle-mounted T-box and vehicle-mounted active safety capture equipment are deployed on the vehicle side and connected to the cloud through a standard data interface; The vehicle-mounted T-box is an in-vehicle terminal used to collect driving data and report it to the cloud; Vehicle-mounted active safety capture equipment includes ADAS and DSM driver status monitoring and reporting of safety events, and is capable of capturing images of the driver in the cab; Deploy Flink streaming computing module, message queue, Redis caching service module, interface gateway, cloud object storage module, face recognition service module, trajectory playback service module, attendance database and scheduled task module in the cloud; The Flink streaming computing module is used for real-time event computing of driving data; Message queues are used to accelerate the transmission of events and capture results; The gateway serves as a communication bridge between the cloud and vehicle hardware, used for issuing device commands, image recognition, and trajectory ignition query. The cloud object storage module is used to store face capture images transmitted back from the vehicle-mounted active safety capture device; The face recognition service module is used to perform face detection and recognition on face image results, compare the captured face with the driver face database pre-entered in the system, and return the identified driver identity information; The trajectory playback service module is used to retrieve the historical ignition records of a vehicle based on its vehicle ID and time range. The attendance database is used to store all complete clock-in, shift change, and clock-out records; The Redis caching service module includes a cache of vehicle terminal-vehicle mapping relationships that meet certain conditions, a driver attendance cache, a vehicle attendance cache, a card return record cache, and a mapping table of vehicles and their affiliated organizations; it is used for event deduplication, vehicle / driver attendance status caching, and acceleration event timeout control.

[0016] Furthermore, the driver's identity information includes the driver's ID, the ID of the organization to which the driver belongs, the name, and the mobile phone number; The driver check-in cache includes the driver ID, the driver's current vehicle ID, the check-in record number, and the check-in time; The vehicle attendance cache includes the vehicle ID, the ID of the driver currently driving the vehicle, the attendance record number, and the attendance time; The card return record cache includes driver ID and card return time; The vehicle terminal-vehicle mapping relationship cache includes the terminal number and vehicle ID; The mapping table between vehicles and their respective organizations includes the vehicle ID and the organization ID.

[0017] Furthermore, during the startup phase, a scheduled task is used to identify vehicles that meet the facial recognition criteria: the vehicle has been bound to active safety devices, has activated facial recognition service, and has recorded driver facial data. The mapping relationship between the eligible vehicle terminals and the vehicles is then cached in the Redis cache service module.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) Cardless automatic attendance. By linking the T-box driving data with the vehicle active safety equipment, the system automatically triggers capture and recognition during the driver's normal driving process, eliminating the need for a physical attendance card and fundamentally avoiding attendance loss or errors caused by forgetting to bring or remove the card.

[0019] (2) Multi-source event collaborative determination of get off work arrival and departure. Acceleration events combined with facial recognition are used to determine work arrival, while dwell events, equipment offline timeout events and timed inspections are used to determine work departure. Trajectory ignition events are also introduced to optimize work arrival time, so that the start and end times of attendance are consistent with the actual operating status of the vehicle, thereby improving the authenticity and explainability of attendance.

[0020] (3) Improved idempotency and anti-duplicate mechanisms. Redis is used to deduplicatize and cache vehicle events, capture results, and driver / vehicle check-in status, avoiding duplicate check-in or erroneous check-out caused by duplicate message consumption and duplicate device callbacks, thus ensuring stable and reliable attendance data.

[0021] (4) Cross-organization identification filtering and permission constraints. Face recognition supports cross-organization retrieval, but the business layer forces verification that the driver and vehicle belong to the same organization. If they do not match, the vehicle is discarded to avoid the problem of attendance mismatch caused by wrong vehicle or wrong person.

[0022] (5) Automatic handling of shift change scenarios. When the same vehicle is driven by different drivers in succession, the system automatically ends the previous driver's check-in and generates a check-in for the new driver without manual intervention, which is suitable for actual operation modes such as shift change and shift replacement in logistics fleets.

[0023] (6) Abnormal fallback closed loop. There are clear discard or skip strategies for abnormalities such as capture timeout, failure to recognize face, and driver having already clocked in on other vehicles; for vehicles that have not reported safety incidents for a long time, the timed task combined with the last location is used to force the card to be returned, so as to avoid the clocking record not ending for a long time and improve the integrity of fleet management data.

[0024] (7) Scalable and easy to maintain. Event calculation, command issuance, image recognition, trajectory query and attendance data storage are layered and decoupled, which facilitates the connection with T-boxes, active safety devices and cloud storage services from different manufacturers, and is conducive to promotion and deployment in fleet management platforms. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the steps of the method for generating driver attendance records based on vehicle T-box data and facial recognition according to the present invention. Detailed Implementation

[0026] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0027] Please refer to the reference. Figure 1 This invention provides a method for generating driver attendance records based on vehicle T-box data and facial recognition, including an in-vehicle T-box, an in-vehicle active safety capture device, and a cloud platform. The in-vehicle T-box and the in-vehicle active safety capture device are deployed in the vehicle and connected to the cloud platform via a standard data interface.

[0028] The vehicle-mounted T-box is an in-vehicle terminal used to collect driving data and report it to the cloud; Vehicle-mounted active safety capture equipment is an intelligent vehicle electronic system that can proactively identify and record driving risks, including ADAS, DSM driver status monitoring and reporting of safety events, and has the ability to capture images of the driver in the cab.

[0029] Deploy Flink streaming computing module, message queue, Redis caching service module, interface gateway, cloud object storage module, face recognition service module, trajectory playback service module, attendance database and scheduled task module in the cloud; The Flink streaming computing module is used to perform real-time computing on streaming driving data and generate vehicle events; it is used for real-time event computing of driving data.

[0030] Message queues act as asynchronous data pipelines, reliably transmitting event messages between modules; they are used to accelerate the transmission of events and capture results.

[0031] The gateway acts as a communication bridge between the cloud and the vehicle hardware, used for issuing device commands, image recognition, and trajectory ignition query. It is responsible for issuing commands to the onboard active safety capture device, receiving the face image results transmitted back by the device, and calling the external trajectory playback service module. The cloud object storage module is used to store face capture images transmitted back from the vehicle-mounted active safety capture device.

[0032] The face recognition service module is used to perform face detection and recognition on face image results. It compares the captured face with the pre-entered driver face database in the system and returns the identified driver identity information, including driver ID, driver's affiliated organization ID, name, mobile phone number, etc.

[0033] The trajectory playback service module is a historical driving data query interface, used to retrieve the historical ignition records of a vehicle based on the vehicle ID and time range.

[0034] The attendance database is used to store all complete clock-in, shift change, and clock-out records; The Redis caching service module includes caches of vehicle terminal-vehicle mapping relationships that meet certain conditions, driver attendance cache, vehicle attendance cache, card return record cache, and a mapping table between vehicles and their affiliated organizations; it is used for event deduplication, vehicle / driver attendance status caching, and acceleration event timeout control.

[0035] The driver attendance cache includes the driver ID, the driver's current vehicle ID, the attendance record number, and the attendance time. The vehicle attendance cache includes the vehicle ID, the driver ID currently driving the vehicle, the attendance record number, and the attendance time.

[0036] The card return record cache includes driver ID, card return time, etc.

[0037] The vehicle terminal-vehicle mapping relationship cache includes the terminal number and vehicle ID.

[0038] Eligible vehicles refer to vehicles that have been bound to active safety devices, have activated facial recognition services, and have had their driver's facial data recorded. During the startup phase, vehicles that meet the facial recognition criteria are identified through a scheduled task.

[0039] The mapping table between vehicles and their affiliated organizations includes vehicle ID, affiliated organization ID, etc.

[0040] Includes the following steps: S1: Calculate vehicle events and preprocess them to obtain valid acceleration events; During vehicle operation, the on-board T-box continuously collects and reports vehicle driving data. The cloud uses Flink streaming data for real-time calculation to generate acceleration events, dwell events, and device offline timeout events. Valid acceleration events are obtained by performing retransmission filtering (filtering time window is 2 minutes) and discarding out-of-order data for acceleration events.

[0041] S11: The vehicle-mounted T-box reports vehicle driving data; The vehicle-mounted T-box reads vehicle driving data via the CAN bus and reports it to the cloud at a fixed frequency of 1Hz. The cloud forwards the reported driving data to a message queue, and the partition key uses the vehicle ID to ensure sequential consumption of driving data for the same vehicle.

[0042] Driving data includes vehicle ID, terminal number, GPS time, longitude, latitude, speed, ACC status, HDOP positioning accuracy value, etc. The ACC status is the power-on status corresponding to the vehicle's one-button start position. It is used to determine whether the vehicle is powered on or off, including 0 / 1; 0 indicates that the vehicle is off and 1 indicates that the power is on.

[0043] S12: Configure Flink streaming computation; Flink is used to consume data reported by the vehicle T-box in real time from the message queue, and to filter abnormal driving data with HDOP positioning accuracy value >5, negative speed or >200km / h. In Flink jobs, event time semantics are set, that is, GPS timestamps are used instead of data arrival times as the time base, and the allowable delay is set to 60 seconds to handle out-of-order data caused by network latency.

[0044] Flink is an open-source stream processing framework that enables low-latency, high-throughput real-time computation on unbounded data streams.

[0045] S13: Generate acceleration events; Consume driving data in real time and detect acceleration: If the vehicle speed drops below 5 km / h for three consecutive data points and the ACC status is 1, the vehicle is considered stationary / low-speed. If the speed jumps to over 30 km / h (medium-high speed) within a preset short period of 5 seconds and remains stable, an acceleration event is generated and written to the message queue as a set of acceleration events.

[0046] An acceleration event includes a unique event number, vehicle ID, terminal number, event time, acceleration start time, speed values ​​before and after acceleration, and current latitude and longitude.

[0047] S14: Generate a dwell event; If the vehicle's latitude and longitude change is less than 50m and the duration exceeds a preset time threshold, a dwell event is generated and written to the dwell event set in the message queue.

[0048] A stop event includes the vehicle ID, the start time of the stop, the latitude and longitude of the stop location, and the cumulative duration of the stop.

[0049] S15: Generate device offline timeout event; Vehicle-mounted safety devices report safety events to the cloud. Flink maintains a status record of the last reporting time for each device. Whenever a safety event is received from the device, its last reporting time is updated, the old timer is deleted, and a new timer is set. The default trigger time for this timer is set to the last reporting time plus 5 minutes. If no new data is received within 5 minutes, a device offline timeout event is generated and written to the offline event set in the queue message. Device offline timeout events include terminal number, vehicle ID, offline start time, and the last reported location information.

[0050] S16: Retransmission filtering obtains effective acceleration events; When consuming an acceleration event, first check the difference between the event time and the current system time. If it exceeds 2 minutes, it is determined to be retransmission of data. The message is directly confirmed but no further processing is done. It is only recorded in the log and then discarded. If it is within 2 minutes, it is a valid acceleration event.

[0051] To avoid situations where the T-box temporarily stores data in a local cache when driving in areas with poor signal, and then retransmits it all at once after the signal is restored, causing the event time to be much earlier than the current system processing time, thus triggering incorrect attendance records.

[0052] S2: Effectively accelerates event-triggered face capture; After Flink generates an acceleration event, the business service consumes the valid acceleration event (pushed by the Kafka message queue). The business service first determines whether the event has been consumed based on the Redis key "terminal number: event type: event time". If it has been consumed, it skips the event to achieve idempotency: "write a record to the Redis cache service module with the key "terminal number: event type: event time" and try to write it using the SETNX command of the Redis cache service module. If the write is successful, the event has not been consumed; otherwise, the event has been consumed.

[0053] If the event is not consumed, query the binding relationship between the terminal and the vehicle in the Redis cache service module. If the vehicle does not exist, skip this step. For unconsumed and validly bound acceleration events, send a face capture command to the vehicle-mounted active safety device through the gateway. After the command is successfully sent, the vehicle-mounted active safety device starts the camera to capture the face. The command includes the terminal number, the serial number of this command, etc. Store the acceleration event in Redis with "Vehicle ID:Command Serial Number" as the key, set an expiration time of 5 minutes, and wait for the device to call back the capture result within the agreed time (5 minutes). If no callback is received within the time limit, discard the acceleration event and do not generate an attendance record. If the time limit is not exceeded, execute S3.

[0054] S3: Acquire facial images and perform facial recognition; After the device callback, the captured image result message is consumed. Redis is used to determine if the captured image result has already been consumed (the key includes the terminal number, serial number, and multimedia identifier) ​​to avoid duplicate recognition. After verifying that the vehicle still exists and the acceleration event cache has not timed out, the captured image is retrieved (saved via cloud object storage service), and the face recognition service module is called for face recognition. If no face is recognized, the acceleration event is discarded; if multiple face candidates are recognized (maximum 3), each face is checked to see if the driver and vehicle belong to the same organization. Cross-organization recognition results are discarded to ensure the correct attribution of attendance data.

[0055] S31: Consume the capture result message, deduplicate and verify to obtain the captured image; First, after the onboard active safety device captures an image, it uploads the image file to the cloud object storage module to obtain a unique multimedia identifier. Then, it reports a message containing information such as the terminal number, command serial number, multimedia identifier, and capture time to the cloud and forwards it to the message queue. The business service, acting as a consumer, pulls the capture result message from the message queue.

[0056] Next, a Redis SETNX write operation is performed using "terminal number: command serial number: multimedia identifier" as the key. This checks whether the capture result message has already been consumed to prevent the same image from being recognized multiple times due to network retransmissions or duplicate consumption by Kafka. If the key already exists, the message is discarded.

[0057] If the event has not been consumed, the system will query Redis for a corresponding acceleration event cache using "Vehicle ID: Command Serial Number" as the key. If the event exists, the captured image will be retrieved from the cloud object storage module based on the multimedia identifier.

[0058] S32: Obtain candidate driver information through facial recognition; In response to the request, the face recognition service module is invoked to compare the face in the captured image with the pre-entered driver face database in the system. The faces are sorted from high to low similarity and the driver identity information of up to 3 candidate drivers with the highest scores is returned. If no face is recognized, the acceleration event is discarded.

[0059] S33: Driver identity information is obtained through verification with the same organization; For each returned driver identity information, query the driver's affiliated organization ID, and obtain the vehicle's affiliated organization ID according to the vehicle-affiliated organization mapping table. Compare whether the driver's affiliated organization ID and the vehicle's affiliated organization ID are the same. If they are the same, the driver's identity information is adopted and the driver's identity is confirmed. If the affiliated organization IDs of all candidate drivers are different from the vehicle's affiliated organization ID, then the driver and the vehicle do not belong to the same organization, and the current acceleration event is discarded.

[0060] S4: Generate work attendance clock-in or execute shift change and card return; Based on the driver's identity information after identification and confirmation, information such as driver ID, name, and mobile phone number is obtained. Combined with the driver's attendance cache and vehicle attendance cache in Redis, it is determined whether to generate a new attendance, execute a shift change, or ignore the current event.

[0061] S41: If the current driver is already clocking in on another vehicle, discard this acceleration event; The system queries the driver attendance cache using the driver ID as the key to check if a record for that driver ID exists. It then determines if the driver has an ongoing attendance record. If a record exists, the current acceleration event is discarded; otherwise, step S42. This prevents duplicate attendance and avoids the same driver being recorded as driving multiple vehicles simultaneously within the same time period.

[0062] S42: Determine if there are any unfinished check-in records for the vehicle; Using the vehicle ID as the key, query the vehicle attendance cache to see if there is an attendance record for the current vehicle. Determine if there are any unfinished attendance records for the vehicle. If there are no attendance records for the current vehicle, it is determined that the vehicle has no unfinished attendance records; otherwise, it is determined that the vehicle has unfinished attendance records.

[0063] S43: If the vehicle currently has no outstanding check-in records, a new check-in will be generated; The system prioritizes querying the trajectory playback service module to obtain the ignition event as the start time for the driver's shift. If a historical card return record exists for the driver, the maximum value of the card return time and the hour preceding the acceleration time is used as the start time for the trajectory query; otherwise, the start time is two days prior to the acceleration time, and the end time is the acceleration event time. If no ignition event exists, the acceleration event time is used as the clock-in time. Clock-in data is written to the attendance table in the database, and the driver clock-in cache and vehicle clock-in cache (including record identifier and driver identifier) ​​are updated.

[0064] S44: If a vehicle has an unfinished check-in and the driver who checked in is different from the driver identified this time, then first end the original driver's check-in and generate a refund card: If a vehicle has an unfinished check-in record, compare the driver ID with the driver ID currently driving the vehicle. If they are different, the driver is different from the driver identified this time. In this case, first check the stop event cache. If a stop event exists, use the stop event as the basis for card cancellation and the start time of the stop event as the card cancellation time. Otherwise, use the current acceleration event as the basis for card cancellation and the event time of the acceleration event as the card cancellation time. When a card is returned, the attendance record is updated. The original card-return record number is retrieved from the vehicle card-return cache, and the return time is updated. The driver's card-return cache is written to Redis using the original driver ID as the key, and the vehicle and driver's card-return caches are deleted. Then, a new card-return record is generated for the currently identified driver. If they are the same, execute S45.

[0065] S45: If a vehicle has an unfinished check-in and the driver who checked in is the same as the driver identified this time, then discard this acceleration event to avoid duplicate check-ins.

[0066] S46: Delete cache; After processing, delete the cache related to this acceleration event.

[0067] S5: Card ejection is triggered by dwell events and device offline events; When Flink generates a stay event or a device offline timeout event, it consumes the corresponding vehicle event, ends the current unfinished check-in for that vehicle, generates a card return record, updates the attendance record in the attendance database, writes to the driver card return cache, and deletes the vehicle check-in cache and the driver check-in cache.

[0068] Among them, the stop event reflects that the vehicle has stopped running, and the offline timeout event reflects that the on-board safety equipment has not reported data for a long time. Both can be used as the basis for determining whether the driver has ended his shift and left the vehicle.

[0069] Simultaneously subscribe to consumption stay events and device offline timeout events. Query the vehicle attendance cache in Redis using the vehicle ID as the key. If the cache does not exist, it means the vehicle is not currently in attendance, and the system discards the event without any processing. Otherwise, for stay events, the stay start time in the event is used as the check-out time; for device offline timeout events, the offline start time is used as the check-out time. Retrieve the current check-in record number from the vehicle attendance cache, perform an attendance database update, write the check-out time, write the check-out record cache to Redis using the driver ID as the key, and then delete both the vehicle attendance cache and the driver attendance cache.

[0070] S6: Scheduled task to guarantee card refund.

[0071] A pre-set scheduled task scans for vehicles that have not reported safety events for an extended period (2 hours) and still have unfinished check-ins. The task queries the location and time of the last report from the safety equipment, forcibly terminates the current check-in, and generates a card return record to prevent check-in records from being suspended indefinitely due to equipment failure or abnormal shutdown.

[0072] Configure a scheduled task to perform inspections on vehicles that have not reported safety incidents for more than 2 hours and are still in the check-in state. Combine the last location data (latitude, longitude, and time) of the safety equipment to trigger card cancellation, as a closed-loop attendance method in abnormal scenarios.

[0073] This invention continuously reports driving data from the T-box while the vehicle is in motion, and Flink calculates acceleration, stop, and device offline timeout events in real time. When a valid acceleration event occurs, the system sends a face capture command to the on-board device via the gateway, acquires the image, and calls the face recognition service to obtain the driver's identity. Combining the vehicle / driver attendance status in Redis and the verification results from the same organization, it automatically generates a work attendance record or executes a shift change and card return. When a stop, offline timeout event, or scheduled inspection condition occurs, it automatically ends the current attendance and generates a card return record. Attendance can be automatically completed under the drive of real driving behavior (acceleration, stopping, offline) without the driver carrying an attendance card, solving problems such as forgetting to bring or remove the card, and the inability to supervise fleets without attendance machines.

[0074] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A method for generating driver attendance records based on vehicle T-box data and facial recognition, characterized in that: This includes in-vehicle T-boxes, in-vehicle active safety capture devices, and the cloud; Includes the following steps: S1: Calculate vehicle events and preprocess them to obtain valid acceleration events; During vehicle operation, the on-board T-box continuously collects and reports vehicle driving data. The cloud uses Flink streaming data for real-time calculation to generate acceleration events, dwell events, and device offline timeout events. S2: Effectively accelerates event-triggered face capture; S3: Acquire facial images and perform facial recognition to obtain driver identity information; S4: Generate work attendance clock-in or execute shift change and card return; Based on the identified and confirmed driver identity information, obtain the driver ID, and determine whether to generate a new check-in, execute a shift change and card refund, or ignore the event based on the driver's check-in cache and the vehicle's check-in cache. S5: Card ejection is triggered by dwell events and device offline events; S6: Scheduled task to guarantee card refund; Configure a scheduled task to perform inspections on vehicles that have not reported safety incidents for more than 2 hours and are still in the check-in state, and trigger the card removal based on the location and time of the last safety incident.

2. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 1, characterized in that: Step S1 includes: S11: The vehicle-mounted T-box reports vehicle driving data; Driving data includes vehicle ID, terminal number, GPS time, longitude, latitude, speed, ACC status, and HDOP positioning accuracy value; The cloud forwards the reported driving data to the message queue, and the partition key uses the vehicle ID; S12: Configure Flink streaming computation; Flink is used to consume data reported by the vehicle's T-box in real time from the message queue, and abnormal driving data is filtered out; GPS timestamps are set as the time base, and allowable delays are set to handle out-of-order data caused by network latency; S13: Generate acceleration events; Consume driving data in real time and detect acceleration process: if the vehicle speed exceeds a preset speed within a preset time and remains stable after the speed has changed from a standstill / low speed, an acceleration event is generated and written to the message queue. S14: Generate a dwell event; If the vehicle's latitude and longitude change is less than a preset threshold and the duration exceeds a preset time threshold, a dwell event is generated and written to the message queue. S15: Generate device offline timeout event; When an in-vehicle safety device reports a safety event to the cloud, Flink maintains a status record of the last reporting time for the in-vehicle safety device. Whenever a safety event is received from the device, the last reporting time of the device is updated, the old timer is deleted, and a new timer is set. The trigger time of the preset timer is set. If no new data is received within the trigger time, a device offline timeout event is generated and written to the queue message. S16: Retransmission filtering obtains effective acceleration events; When consuming an acceleration event, first check the difference between the event time and the current system time. If it exceeds the preset time window, it is determined to be supplementary data transmission. The message is directly confirmed but no further processing is done. It is only logged and then discarded. Otherwise, it is a valid acceleration event.

3. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 1, characterized in that: An acceleration event includes a unique event number, vehicle ID, terminal number, event time, acceleration start time, speed values ​​before and after acceleration, and current latitude and longitude. Step S2 includes: consuming effective acceleration events for business services. First, determine whether the event has been consumed based on the Redis key "terminal number: event type: event time". If it has been consumed, skip this step. If no data is consumed, check the binding relationship between the terminal and the vehicle. If the vehicle does not exist, skip this step; otherwise, send a face capture command to the vehicle's active safety device. After the command is successfully sent, the vehicle's active safety device starts the camera to capture the face. The command includes the terminal number and the serial number of this command. Store the acceleration event in Redis with "Vehicle ID: Command Serial Number" as the key and set an expiration time. Wait for the vehicle's active safety capture device to send back the capture result within the expiration time. If no callback is received after the timeout, discard this acceleration event.

4. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 3, characterized in that: After the device callback, consume the capture result message, determine whether the capture result has been consumed, verify that the vehicle still exists and the acceleration event cache has not expired, obtain the captured image, and perform face recognition. If no face is recognized, discard this acceleration event. If multiple face candidates are identified, each one is checked to determine whether the driver and vehicle belong to the same organization. Cross-organization identification results are discarded directly.

5. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 1, characterized in that: Step S3 includes: S31: Consume the capture result message, deduplicate and verify to obtain the captured image; First, after the vehicle-mounted active safety capture device completes the capture, it uploads the image file to the cloud object storage module to obtain a unique multimedia identifier. Then, it reports a message containing information such as terminal number, instruction serial number, multimedia identifier, and capture time to the cloud and forwards it to the message queue. The capture result message is then retrieved from the message queue. Next, using "terminal number: instruction serial number: multimedia identifier" as the key, determine whether the capture result message has been consumed. If the key already exists, the message has been consumed and is discarded directly. If no event has been consumed, the system will query Redis for a corresponding acceleration event cache using "Vehicle ID: Command Serial Number" as the key. If the event exists, the captured image will be retrieved from the cloud object storage module based on the multimedia identifier. S32: Obtain candidate driver information through facial recognition; In response to the request, the face recognition service module is invoked to compare the face in the captured image with the pre-entered driver face database in the system and return the driver identity information of the candidate driver. If no face is recognized, the acceleration event is discarded. S33: Driver identity information is obtained through verification with the same organization; For each returned driver identity information, query the driver's affiliated organization ID, and obtain the vehicle's affiliated organization ID according to the vehicle-affiliated organization mapping table. Compare whether the driver's affiliated organization ID and the vehicle's affiliated organization ID are the same. If they are the same, the driver's identity information is adopted and the driver's identity is confirmed. If the affiliated organization IDs of all candidate drivers are different from the vehicle's affiliated organization ID, then the driver and the vehicle do not belong to the same organization, and the current acceleration event is discarded.

6. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 1, characterized in that: Step S4 includes: S41: If the current driver is already clocking in on another vehicle, discard this acceleration event; Use the driver ID as the key to query the driver check-in cache to see if there is a record for the driver ID. Determine if there is a check-in record for that driver. If there is, discard the current acceleration event; otherwise, execute S42. S42: Determine if there are any unfinished check-in records for the vehicle; Using the vehicle ID as the key, query whether there is a check-in record for the current vehicle in the vehicle check-in cache, and determine whether there are any unfinished check-in records for the current vehicle. If there is no check-in record for the current vehicle, it is determined that the vehicle has no unfinished check-in records; otherwise, it is determined that the vehicle has unfinished check-in records. S43: If the vehicle currently has no outstanding check-in records, a new check-in will be generated; The system prioritizes querying the trajectory playback service module to obtain the ignition event as the start time for the driver's shift. If the driver has a history of card cancellation, the system uses the maximum value of the card cancellation time and the time before acceleration one hour prior as the start time for the trajectory query. Otherwise, the system uses the time before acceleration two days prior as the start time and the acceleration event time as the end time. If there is no ignition event, the system uses the acceleration event time as the clock-in time. The clock-in data is written to the database attendance table, and the driver clock-in cache and vehicle clock-in cache are updated. S44: If the vehicle has an unfinished check-in and the driver who checked in is different from the driver identified this time, the original driver's check-in will be terminated first and a refund will be generated; the stop event cache will be queried first. If a stop event exists, the stop event will be used as the basis for refund, and the start time of the stop event will be used as the refund time; otherwise, the current acceleration event will be used as the basis for refund, and the event time of the acceleration event will be used as the refund time. When a card is returned, the attendance record is updated, written to the driver's card return cache, and the card-swiping cache for the vehicle and driver is deleted; then a new card-swiping record is generated for the currently identified driver. S45: If the vehicle has an unfinished check-in and the check-in driver is the same as the driver identified this time, then discard this acceleration event; S46: Delete cache; Delete the cache of this acceleration event after processing is complete.

7. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 1, characterized in that: A dwell timeout event includes the vehicle ID, dwell start time, dwell location latitude and longitude, and cumulative dwell time; a device offline timeout event includes the terminal number, vehicle ID, offline start time, and the last reported location information. In step S5, both consumption stay events and device offline timeout events are subscribed to simultaneously. The vehicle ID is used as the key to query the vehicle attendance cache in Redis. If the cache does not exist, the vehicle is not currently in attendance, and the event is discarded without any processing. Otherwise, for stay events, the stay start time in the event is used as the card return time, and for device offline timeout events, the offline start time is used as the card return time. The vehicle's currently unfinished attendance is ended, and a card return record is generated. The attendance database attendance record is updated, the driver card return cache is written, and the vehicle attendance cache and driver attendance cache are deleted.

8. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 1, characterized in that: The vehicle-mounted T-box and vehicle-mounted active safety capture equipment are deployed on the vehicle and connected to the cloud through a standard data interface; The vehicle-mounted T-box is an in-vehicle terminal used to collect driving data and report it to the cloud; Vehicle-mounted active safety capture equipment includes ADAS and DSM driver status monitoring and reporting of safety events, and is capable of capturing images of the driver in the cab; Deploy Flink streaming computing module, message queue, Redis caching service module, interface gateway, cloud object storage module, face recognition service module, trajectory playback service module, attendance database and scheduled task module in the cloud; The Flink streaming computing module is used for real-time event computing of driving data; Message queues are used to accelerate the transmission of events and capture results; The gateway serves as a communication bridge between the cloud and vehicle hardware, used for issuing device commands, image recognition, and trajectory ignition query. The cloud object storage module is used to store face capture images transmitted back from the vehicle-mounted active safety capture device; The face recognition service module is used to perform face detection and recognition on face image results, compare the captured face with the driver face database pre-entered in the system, and return the identified driver identity information; The trajectory playback service module is used to retrieve the historical ignition records of a vehicle based on its vehicle ID and time range. The attendance database is used to store all complete clock-in, shift change, and clock-out records; The Redis caching service module includes a cache of vehicle terminal-vehicle mapping relationships that meet certain conditions, a driver attendance cache, a vehicle attendance cache, a card return record cache, and a mapping table of vehicles and their affiliated organizations; it is used for event deduplication, vehicle / driver attendance status caching, and acceleration event timeout control.

9. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 8, characterized in that: Driver identification information includes driver ID, driver's affiliated organization ID, name, and mobile phone number; The driver check-in cache includes the driver ID, the driver's current vehicle ID, the check-in record number, and the check-in time; The vehicle attendance cache includes the vehicle ID, the ID of the driver currently driving the vehicle, the attendance record number, and the attendance time; The card return record cache includes driver ID and card return time; The vehicle terminal-vehicle mapping relationship cache includes the terminal number and vehicle ID; The mapping table between vehicles and their respective organizations includes the vehicle ID and the organization ID.

10. The method for generating driver attendance based on vehicle T-box data and facial recognition as described in claim 8, characterized in that: During the startup phase, a scheduled task is used to identify vehicles that meet the facial recognition criteria: the vehicle has been bound to active safety devices, has activated facial recognition service, and has had driver facial data recorded. The mapping relationship between the eligible vehicle terminals and the vehicles is then cached in the Redis cache service module.

Images