Safety management and control system and method for self-driving / operation dual-mode intelligent connected automobile

Abstract

The invention provides a safety management and control system and method integrating a vehicle-mounted terminal, an operation server and a user terminal. The vehicle-mounted terminal comprises a mode control module, a safety monitoring module and a positioning communication module and is responsible for mode switching, state acquisition and communication; the operation server comprises a geofence management unit, an identity verification database and an abnormal intervention instruction generation unit, and is used for realizing region delimitation, identity verification and intervention decision making; and the user terminal supports mode setting, identity verification and state viewing. Safe mode switching is achieved through identity verification and permission isolation, the operation range is limited through double geofences, parameters such as electric quantity and tire pressure are collected in real time, and grading intervention is triggered. According to the method, the blank of self-driving / operation dual-mode switching authority control is filled, and safety guarantee is provided for fusion of private cars and shared travel.

Description

Technical Field

[0001] This invention relates to the field of intelligent connected vehicle technology, and in particular to an intelligent connected vehicle safety management system and method that supports dynamic switching between autonomous driving and operational scenarios. It is applicable to safety protection, operational scope restriction and real-time risk monitoring when private cars and shared mobility scenarios are integrated, and provides technical support for the future "one car, two uses" model. Background Technology

[0002] Existing intelligent connected vehicles all operate in a single mode (private cars only support self-driving, and commercial vehicles only support dedicated operation). When expanding to the scenario of "dynamic access of private cars to shared operation," the following mechanisms are missing:

[0003] 1) Lack of cross-scenario switching permission mechanism: The existing system does not have permission control logic for switching between 'private use - shared operation' scenarios. If private cars are connected to the operation, unauthorized users (such as passengers) may switch the vehicle status without authorization, which may cause security risks.

[0004] 2) Risk of uncontrolled operation area boundaries: Existing dedicated operating vehicles rely on manual demarcation of operating areas, lacking an automated geofencing control mechanism for autonomous driving. If private cars are dynamically integrated into the shared operation (autonomous driving mode), the system may not have pre-set precise boundaries or real-time location monitoring may lag, causing vehicles to exceed the safe area set by the owner (such as remote areas outside the city) or the operating area stipulated by the platform (such as restricted areas prohibited by policy). This could lead to risks such as failure to return on time (affecting the availability of subsequent operating periods), entry into areas with complex road conditions (such as mountainous areas or closed roads), or illegal operation.

[0005] 3) Lagging vehicle status monitoring: Traditional systems only support alarms after a fault occurs, and cannot collect key parameters (such as battery level and tire pressure) in real time and actively intervene, which makes it difficult to meet the safety requirements of shared operation scenarios.

[0006] Therefore, given the current state of dual-mode switching technology, there is an urgent need to build a safety management and control system that supports dynamic scene switching in order to fill the technological gap in the integration of private cars and shared mobility. Summary of the Invention

[0007] In response to the current lack of dual-mode switching intelligent connected vehicles, and the problems of insufficient access control, uncontrolled operating areas, and lagging status monitoring when single-mode vehicles are integrated and expanded into "autonomous driving-operation" scenarios, this invention provides a safety management system and method for autonomous / operation dual-mode intelligent connected vehicles, enabling access control, precise area restriction, and proactive intervention for anomalies in future dual-mode scenarios.

[0008] Specifically, this invention aims to solve the following core technical problems:

[0009] 1) Security issues related to cross-scenario switching permissions: How to achieve permission isolation for switching between 'self-driving scenarios' and 'operational scenarios' through identity verification mechanisms (such as facial recognition and key verification) to prevent unauthorized users (such as passengers) from switching vehicle status without authorization; 2) Dynamic control of operational area boundaries: How to use geofencing technology to delineate precise operational area boundaries (supporting dual restrictions of owner-defined safe areas and platform compliant areas), monitor vehicle location in real time, and trigger boundary crossing warnings and restrictions (such as stopping order acceptance and forcing navigation back) to prevent vehicles from exceeding the set range; 3) Real-time monitoring and abnormal intervention of vehicle status: How to collect key vehicle parameters in real time through sensors and automatically trigger graded intervention strategies based on preset thresholds, such as low battery navigation charging and speed limits due to abnormal tire pressure, to eliminate safety risks at the nascent stage.

[0010] In order to overcome the shortcomings of the existing technology, the present invention proposes the following technical solution:

[0011] According to one aspect of the present invention, a safety management system and method for a dual-mode intelligent connected vehicle (autonomous driving / operational driving) is provided, comprising an in-vehicle terminal, an operation server, and a user terminal (owner's APP). The in-vehicle terminal is installed in the vehicle and includes a mode control module, a safety monitoring module, and a positioning and communication module; the operation server includes a geofence management unit, an authentication database, and an anomaly intervention command generation unit; the user terminal (owner's APP) includes a mode setting module, an authentication module, and a vehicle status viewing module.

[0012] Given that current vehicles cannot switch modes, the issue of access control needs to be addressed when private cars are integrated into the operational system. This invention addresses this through the following solution: The vehicle owner initiates an "operation mode activation" request via the mode setting module on the user terminal (owner's app) or the in-vehicle terminal, setting the permitted operating hours and cities / regions. Simultaneously, when switching from operational mode to autonomous driving mode, the system verifies the vehicle owner's identity through an identity verification module. If verification is successful, the mode control module executes the switch; otherwise, the request is rejected and the terminal is locked for 30 minutes to prevent unauthorized users from switching modes. As a further improvement, the identity verification supports "two-factor authentication" (e.g., facial recognition + app key), suitable for high-security scenarios (e.g., nighttime operation mode switching), providing dual protection for the secure switching of dual-mode vehicles in the future.

[0013] Since the current vehicles operate in a single mode (private cars with no operational needs, operational vehicles operating in fixed areas), future dual-mode vehicles will require an additional area control mechanism. This invention achieves this through the following solution: The geofence management unit of the operation server delineates the boundaries of the operational area based on an electronic map, supporting polygonal / circular fences with an accuracy of up to 10 meters, and sends the fence data, including boundary coordinates and road attributes, to the vehicle terminal; the positioning and communication module of the vehicle terminal collects vehicle location information in real time (GPS / BeiDou positioning, sampling frequency 1 time / second) and compares it with the fence data; if the vehicle exceeds the operational area, the system triggers a three-level response:

[0014] Level 1 warning: The vehicle terminal will display a voice prompt saying "You have exceeded the operating area and will soon terminate your order."

[0015] Level 2 restriction: The operations server stops assigning new orders to this vehicle;

[0016] Level 3 intervention: If the boundary crossing continues for 5 minutes, the vehicle terminal will automatically plan the optimal route back within the fence and push the boundary crossing message and navigation route to the vehicle owner through the user terminal (vehicle owner APP).

[0017] Currently, single-mode vehicles only need to meet the monitoring requirements for private use or dedicated operation. Future dual-mode vehicles need to meet the safety standards of both. This invention achieves this through the following solution: The vehicle terminal's safety monitoring module communicates with the vehicle's ECU via a CAN bus, collecting key parameters in real time: battery level (sampling frequency 1 time / minute), tire pressure (1 time / 30 seconds), fault codes (real-time trigger), and vehicle speed (1 time / second), and encrypting and uploading them to the operation server. The operation server's abnormal intervention command generation unit presets safety thresholds for each parameter and triggers corresponding intervention strategies after comparing the real-time data.

[0018] If the battery level is less than 10% (default threshold, which can be customized by the owner through the APP), the system will automatically navigate to the nearest charging station and simultaneously notify the owner that "battery level is low, remaining range is 15 kilometers" (to ensure vehicle availability during operating hours and avoid affecting the owner's subsequent use).

[0019] If the tire pressure is less than 90% of the standard value, the speed limit will be triggered (≤30km / h), and a voice prompt will continuously say "Tire pressure is abnormal, it is recommended to stop and check immediately" (while ensuring passenger safety and vehicle operating efficiency).

[0020] If a high-risk fault code is detected (such as engine misfire or brake system malfunction), the hazard lights will automatically activate, the vehicle will decelerate to a safe stop at the roadside, and an alarm will be simultaneously sent to the operating platform and the vehicle owner (achieving dual safety response from both the operator and the vehicle owner). As a further improvement of this invention, the safety monitoring module allows the vehicle owner to manually set personalized thresholds (such as adjusting the battery warning threshold to 15%) via a user terminal (vehicle owner APP), balancing the owner's personal usage preferences with operational safety requirements in future dual-mode scenarios.

[0021] Given the current lack of intelligent connected vehicles with dual-mode switching capabilities, this invention, through forward-looking design, provides core technical support for future "self-driving-operation" dual-mode scenarios. Its beneficial effects are as follows: Filling the security gap in dual-mode switching: Through an "identity verification + permission isolation" mechanism, the mode-switching permission in future dual-mode scenarios is strictly limited to the vehicle owner, preventing unauthorized operations (such as passengers unilaterally terminating operations), thus solving the technical gap in permission control when expanding from a single mode to a dual mode; Achieving precise and controllable operating range: Based on geofencing technology, the operating area boundaries are delineated (supporting owner-defined safe zones + platform-compliant zones), preventing future dual-mode vehicles from being unable to operate due to a lack of system boundaries. By controlling entry into dangerous areas (such as remote areas outside the city or areas with policy restrictions), the risk of violations and the probability of accidents can be reduced; a proactive safety intervention system can be built: real-time monitoring of vehicle status and triggering graded interventions (such as navigation charging before low battery, speed limit due to abnormal tire pressure), breaking through the passive response limitations of the current single-mode vehicle "fault alarm", and meeting the high requirements for operational safety in future dual-mode scenarios (such as ensuring that the vehicle is fault-free during operating hours); and enhancing the owner's control and sense of security: through the APP, the owner can view the vehicle mode, location and status data in real time, so that the owner can still fully control the vehicle's dynamics in future dual-mode scenarios (such as when the vehicle is in operating hours), and enhance their trust in shared operations.

[0022] In summary, this invention addresses the current lack of dual-mode switching technology by constructing a complete safety management and control scheme, providing key technical support for the upgrade of intelligent connected vehicles from a single mode to a "one vehicle, two uses" dual-mode system. Attached Figure Description

[0023] To better understand the various aspects of the present invention, reference can be made to the preferred embodiments shown in the accompanying drawings, wherein the same reference numerals in the drawings denote the same steps or components.

[0024] Figure 1 Security management system architecture diagram;

[0025] In the attached diagram: 1-Vehicle terminal, 11-Mode control module, 12-Security monitoring module, 13-Location and communication module; 2-Operation server, 21-Geofence management unit, 22-Authentication database, 23-Abnormal intervention command generation unit; 3-User terminal, 31-Mode setting module, 32-Authentication module, 33-Status viewing module

[0026] Figure 2 : Flowchart of safety control for mode switching;

[0027] In the attached diagram: 1 - Vehicle owner initiates mode switch request; 2 - System receives request; 3 - Identity verification; 4 - Permission determination; 5 - Switch request rejected; 6 - Mode switch executed; 7 - Status synchronization; 8 - Mode switch completed; 9 - Process ends.

[0028] Figure 3 Vehicle status monitoring and anomaly intervention flowchart.

[0029] In the attached diagram: 1-Status acquisition, 2-Encrypted data upload, 3-Anomaly detection, 4-Anomaly detection result, 5-Status synchronization to database cluster, 6-Intervention command generation, 7-Return to status acquisition, 8-Intervention command issuance, 9-Execution of intervention, 10-Intervention status synchronization, 11-Determining whether intervention is complete, 12-End of process. Detailed Implementation

[0030] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0031] A typical future application scenario might be: After commuting on a weekday, the car owner initiates an "operation mode activation" request via the user terminal app, setting the operating hours to "October 15, 2025, 9:00-18:00" and the operating area to "Xuhui District, Shanghai". The system triggers facial recognition verification: the car owner captures a facial image through the app's camera, uploads it to the operation server, and compares it with facial templates in the identity verification database (matching accuracy ≥ 95%). After successful verification, the vehicle terminal's mode control module switches to operation mode and synchronizes the status to the user terminal. After the server pushes nearby orders, the vehicle automatically starts and navigates to the passenger's location, completes facial verification through the vehicle's camera, and automatically deposits the fare into the car owner's account after the trip (after deducting the platform's commission). If the car owner needs to use the car temporarily, they can remotely switch back to self-driving mode, and the system immediately terminates the current operation task.

[0032] The invention will now be described in detail with reference to some embodiments illustrated in the accompanying drawings. To provide a more thorough understanding of the invention, numerous specific details are set forth in the following description. However, it will be apparent to those skilled in the art that the invention may be practiced even without some or all of these specific details. In other instances, well-known processing steps and / or structures have not been specifically described in order to avoid unnecessary ambiguity in the invention. Furthermore, although the invention has been described in conjunction with specific embodiments, it should be understood that this description is not intended to limit the invention to the described embodiments. Rather, the description is intended to cover substitutions, modifications, and equivalents that may be included within the spirit and scope of the invention as defined by the appended claims.

[0033] refer to Figure 1 , Figure 1 This is a safety management system architecture diagram for a dual-mode intelligent connected vehicle (autonomous driving / operational use). Given that there are currently no intelligent connected vehicles supporting dual-mode switching, this architecture provides core technical support for future "one vehicle, two uses" scenarios. Those skilled in the art should understand that implementing this invention does not require all of these components, and that changes can be made to the type and arrangement of these components without departing from the spirit and scope of this invention.

[0034] like Figure 1 As shown, this invention provides a security management system architecture, which includes three core units: 1-vehicle terminal, 2-operation server, and 3-user terminal. Each unit achieves data interaction and collaborative management through network communication. The 1-vehicle terminal is installed inside the vehicle and serves as the core of the system's vehicle-mounted execution and data acquisition, including 11-mode control module, 12-security monitoring module, and 13-positioning and communication module. The 2-operation server is deployed in a cloud data center and serves as the system's decision-making and data management hub, including 21-geofencing management unit, 22-authentication database, and 23-abnormal intervention command generation unit. The 3-user terminal is a mobile application (APP) used by the vehicle owner, serving as the human-computer interaction interface, including 31-mode setting module, 32-authentication module, and 33-status viewing module.

[0035] The 1-vehicle terminal is the physical interface between the system and the vehicle, integrating hardware execution and data acquisition functions to realize vehicle status monitoring, mode switching control, and remote communication. The specific sub-module functions are as follows:

[0036] 11-Mode Control Module: The core execution module designed for future dual-mode scenarios, responsible for receiving and executing mode switching commands, such as switching from autonomous driving mode to operational mode. It achieves mode switching by adjusting vehicle control logic, such as activating / disabling autonomous driving permissions and restricting manual driving operations. Simultaneously, it feeds back the switching results to the 13-Positioning and Communication Module to ensure synchronization with the operational server and user terminal status.

[0037] 12-Safety Monitoring Module: Collects core vehicle operating data in real time via CAN bus, such as battery level, vehicle speed, tire pressure, braking system status, and autonomous driving module operating conditions. The data sampling frequency is 1 time / second, and the accuracy reaches the industry's first-class standard, such as vehicle speed error ≤0.5km / h. It provides raw data support for the 23-Abnormal Intervention Command Generation Unit and is the "perception layer" for abnormal judgment.

[0038] 13-Positioning and Communication Module: Integrates GPS / BeiDou positioning chip and 4G / 5G communication module. On the one hand, it obtains the vehicle's latitude and longitude coordinates in real time with a position error of ≤5 meters and uploads them to the 2-Operation Server. On the other hand, it serves as a data transmission hub to realize bidirectional communication between the vehicle terminal and the operation server (such as uploading status data and receiving intervention commands), and the user terminal (such as receiving mode switching requests). The AES-256 encryption protocol is used to ensure transmission security.

[0039] The 2-operation server is the "brain" of the system, responsible for data storage, logical decision-making, and instruction generation, supporting full-process security control. Specific sub-module functions are as follows:

[0040] 21-Geofence Management Unit: Stores and manages the geographic boundary data of vehicle operation (such as city-level / regional-level fence coordinate sets). By comparing it with the real-time location uploaded by 13-Positioning and Communication Module, it determines whether the vehicle has crossed the boundary (the boundary crossing determination accuracy is 10 meters). The result is fed back to 23-Abnormal Intervention Command Generation Unit to trigger graded intervention (such as early warning prompts and order restrictions).

[0041] 22-Identity Verification Database: Stores the identity information of the vehicle registration owner (such as facial feature value, fingerprint template, APP dynamic key) and permission records (such as whether it is the registrant and whether there are any violations). In the mode switching process, it receives the verification information uploaded by the 32-Identity Verification Module and compares it (matching degree threshold ≥95%), and returns the permission judgment result (pass / fail) to the 11-Mode Control Module.

[0042] 23-Abnormal Intervention Command Generation Unit: The core of the system's abnormal decision-making, it calls the status data uploaded by the 12-Safety Monitoring Module and the boundary data of the 21-Geofence Management Unit, performs multi-dimensional abnormal judgment through a preset threshold library (such as battery level ≥10%, tire pressure ≥2.0 bar), generates corresponding intervention commands (such as "navigate to charging station" or "emergency stop"), and sends them to the vehicle terminal for execution through the 13-Positioning and Communication Module.

[0043] The 3-user terminal provides a human-machine interface for vehicle owners, supporting mode control, identity verification, and status monitoring. Specific sub-module functions are as follows:

[0044] 31-Mode Setting Module: The entry point for vehicle owners to initiate mode switching requests. It supports manual selection of "Automotive Mode / Operational Mode" and transmits the request to the 11-Mode Control Module via the network. At the same time, it displays the switching progress (such as "Verifying" or "Switching in progress") and is the starting point of the mode switching process.

[0045] 32-Identity Verification Module: Integrates multi-factor authentication functions (such as facial recognition, fingerprint collection, and APP dynamic key generation). When switching modes, it collects the vehicle owner's identity information and encrypts and uploads it to the 22-Identity Verification Database for comparison. The verification result is fed back to the vehicle owner's interface in real time (such as "Verification passed" or "Verification failed, please try again") to ensure the authenticity of the identity.

[0046] 33-Status Viewing Module: Displays the vehicle's current status in real time, including mode status (autonomous driving / operation), operating data (battery level, vehicle speed, location), abnormal alerts (such as "low tire pressure"), and intervention progress (such as "planned to a charging station 3 kilometers away"). Data synchronization delay is ≤3 seconds, enabling vehicle owners to visualize and monitor the vehicle's status throughout the entire process.

[0047] The module interaction relationship includes the linkage between the vehicle terminal, the operation server and the user terminal.

[0048] The linkage between the vehicle terminal and the operation server includes data uploading, namely, the status data collected by the 12-safety monitoring module is encrypted and uploaded to the 23-abnormal intervention command generation unit via the 13-positioning and communication module, and the location data uploaded by the 13-positioning and communication module is synchronized to the 21-geofence management unit; it also includes command issuance, namely, the intervention command generated by the 23-abnormal intervention command generation unit and the permission judgment result of the 22-authentication database are issued to the 11-mode control module for execution via the 13-positioning and communication module.

[0049] The interaction between the user terminal and the vehicle terminal includes request initiation, i.e., the mode switching request initiated by the 31-mode setting module is directly transmitted to the 11-mode control module to trigger the switching process; it also includes status feedback, i.e. the switching result of the 11-mode control module and the abnormal status of the 12-safety monitoring module are synchronized to the 33-status viewing module for display via the 13-positioning and communication module.

[0050] The interaction between the user terminal and the operation server includes identity verification, where the identity information collected by the 32-identity verification module is uploaded to the 22-identity verification database for comparison, and the verification result is returned to the user terminal in real time; it also includes fence synchronization, where the latest boundary data of the 21-geofence management unit is periodically synchronized to the 33-status viewing module, allowing vehicle owners to view the permitted operating range of their vehicles.

[0051] Through the above three-layer architecture design of "vehicle terminal execution - operation server decision-making - user terminal interaction", the system realizes closed-loop management of the entire process of vehicle status monitoring, mode switching control, and anomaly intervention, providing technical support for the safety and controllability of future self-driving / operational scenarios.

[0052] refer to Figure 2 , Figure 2 This is the mode switching safety control process for autonomous / operation dual-mode intelligent connected vehicles. The process includes: 1. The owner initiates a mode switching request; 2. The system receives the request; 3. Identity verification; 4. Permission determination; 5. Rejection of the switching request; 6. Mode switching is executed; 7. Status synchronization; 8. Mode switching is completed; 9. Process ends.

[0053] The first step, "Vehicle Owner Initiating Mode Switching Request," refers to the vehicle owner actively initiating a mode switching command through the mode setting module of the user terminal or the mode control module of the vehicle terminal, such as switching from autonomous driving mode to operational mode or vice versa, marking the start of the process. The second step, "System Receiving Request," refers to the vehicle terminal communication module or the operational server receiving the request and automatically invoking the security verification mechanism, triggering the linkage between the user terminal authentication module and the operational server authentication database. The third step, "Authentication," refers to the user terminal authentication module collecting the vehicle owner's identity information (such as facial recognition, APP dynamic key, or fingerprint) and uploading it to the operational server authentication database for comparison (matching degree threshold ≥ 95%) to complete the identity authenticity verification. The fourth step, "Permission Determination," refers to the operational server, based on the authentication result, calling the permission management unit to verify whether the vehicle owner is the vehicle registrant, whether there are any unprocessed violation records, and other permission information to confirm the legality of the switch. The fifth step, "Rejecting Switching Request," refers to the situation where authentication fails or permission determination is not met. Upon successful verification, the system sends a verification failure reminder to the vehicle owner via the user terminal APP push module and triggers the vehicle terminal locking module to lock the terminal for 30 minutes (lock duration is configurable) to prevent unauthorized operations. The sixth step, mode switching execution, refers to the vehicle terminal mode control module performing the underlying mode switch after the permission check is passed. This includes activating / disabling the autonomous driving module's permissions and adjusting vehicle control logic, such as disabling the driver's manual driving permissions in operation mode. The seventh step, status synchronization, refers to the vehicle's current mode status being synchronized to the operation server database cluster storage via the vehicle terminal positioning and communication module after mode switching execution, and then pushed to the user terminal status viewing module for real-time display, achieving consistency between the "terminal-server-user" three-way status. The eighth step, mode switching completion, refers to the system entering a new mode standby state after status synchronization is complete, such as entering order-accepting standby in operation mode and restoring the driver's manual control in autonomous driving mode. The ninth step, process end, refers to the endpoint of the entire mode switching process (including successful switching or rejection of switching).

[0054] like Figure 3As shown, the present invention provides a vehicle status monitoring and anomaly intervention process for a dual-mode intelligent connected vehicle (autonomous driving / operation). The process includes: 1. Status acquisition; 2. Data encryption and uploading; 3. Anomaly determination; 4. Anomaly determination result; 5. Status synchronization to database cluster; 6. Intervention command generation; 7. Return to status acquisition; 8. Intervention command issuance; 9. Execution of intervention; 10. Intervention status synchronization; 11. Determining whether the intervention is completed; 12. Process end. The first step, status acquisition, refers to the vehicle terminal safety monitoring module collecting core vehicle operating data in real time via the CAN bus (such as battery level / SOC, vehicle speed, latitude and longitude coordinates, tire pressure, braking system status, and autonomous driving module operating status). The sampling frequency is 1 time / second, and the data accuracy meets industry-leading standards (e.g., speed error ≤ 0.5 km / h, position coordinate error ≤ 5 meters), providing raw data support for anomaly detection. The second step, encrypted data upload, refers to the vehicle terminal positioning and communication module uploading the collected status data to the operation server via 4G / 5G network. Data transmission is performed using the AES-256 encryption protocol, and a timestamp and unique device identifier (UUID) are added to prevent data tampering or forgery. The third step, anomaly detection, refers to the operation server's anomaly intervention command generation unit calling a preset threshold library (stored in a database cluster) to perform multi-dimensional real-time comparison of the uploaded data. The comparison dimensions include numerical thresholds (e.g., battery level ≥ 10%, tire pressure ≥ 2.0 bar). The system employs several mechanisms: 1) logical rules (e.g., driving within a geofence, matching autonomous driving permissions with the current mode), and 2) trend analysis (e.g., battery level dropping ≥5% within 10 minutes). The fourth, anomaly determination result, refers to the system outputting a binary judgment conclusion based on the comparison results: no anomaly (all parameters are within safe thresholds and conform to logical rules) or anomaly (at least one parameter exceeds the standard, such as speeding > 120km / h, crossing geofence boundaries, or abnormal braking pressure), providing a decision-making basis for subsequent process branches. The fifth, status synchronization to the database cluster, refers to the operation server marking the current vehicle status as "normal monitoring" when the anomaly determination result is no anomaly, writing it to the database cluster in real time (storage latency ≤ 1 second), and simultaneously pushing it to the user terminal status viewing module for display. The sixth, intervention instruction generation, refers to the operation server's anomaly intervention instruction generation unit automatically matching a preset strategy library based on the anomaly type to generate a graded intervention instruction: minor anomaly (e.g., tire pressure 2.0-2).2. A "warning prompt" command is generated for moderate anomalies (e.g., battery level 5%-10%), and a "navigate to charging station" command is generated for severe anomalies (e.g., braking system failure), and an "emergency stop + rescue dispatch" command is generated. The 7th step, returning to status acquisition, refers to the system returning to the status acquisition stage through closed-loop control in the absence of anomalies, continuing the "acquisition-upload-judgment" cycle to achieve 24 / 7 uninterrupted monitoring. The 8th step, issuing intervention commands, refers to the operation server sending the generated intervention commands (including target parameters such as charging station latitude and longitude, speed limit 60km / h, and warning level) to the vehicle terminal via TCP / IP protocol. The command transmission timeout is set to 5 seconds, and automatic retransmission (up to 3 times) occurs if the timeout is exceeded. The 9th step, executing intervention, refers to the corresponding module executing operations after the vehicle terminal receives the command: the autonomous driving module responds to the path planning command, the mode control module executes speed limit or permission adjustment, and the safety monitoring module triggers audible and visual alarms (buzzer + red warning light on the dashboard). The execution result is then displayed. The system updates the status of the intervention to the operation server in real time. Step 10, "intervention status synchronization," refers to the system updating the status through a three-level synchronization mechanism after the intervention is executed: the vehicle terminal stores the execution log locally (including start time and completion progress), the operation server database cluster marks the status as "intervention in progress," and the user terminal APP pushes intervention details (such as "battery is too low, planned to go to a charging station 3 kilometers away, expected to arrive in 10 minutes"). The synchronization delay is ≤3 seconds. Step 11, "judging whether the intervention is completed," refers to the operation server determining whether the intervention is over based on the execution results fed back by the vehicle terminal (such as the vehicle arriving at the charging station, the vehicle speed dropping to within the speed limit, and the fault code being cleared). The judgment logic adopts a dual standard of "result meeting the standard + continuous stability for 30 seconds." When Step 11, "judging whether the intervention is completed," determines that the intervention is not completed (such as after step 9, the vehicle does not drive as instructed, abnormal parameters do not recover to the safety threshold, such as the battery level continuously being below 5%, failing to return to the geofence after crossing the boundary, or the fault code not being cleared), the system re-executes Step 9 to perform the intervention. The term "12 process completion" refers to the process reaching its end point when intervention is completed (state returns to normal) or the monitoring loop terminates without abnormalities (e.g., the vehicle is turned off), and the operations server writes the final state into the database for archiving.

[0055] It is understood that each block and combination of blocks in the flowchart can be implemented using analog or digital hardware and computer program instructions. These flowcharts can be provided to a processor of a general-purpose computer, special-purpose computer, ASIC, or other programmable data processing device, such that instructions executed by the processor of the computer or other programmable data processing device can implement the specific function / action shown in the block diagram. Various aspects or features will be represented by systems, which may include multiple devices, components, modules, etc. It is understood that individual systems may include additional devices, components, modules, etc., and / or may not include all the devices, components, modules, etc., illustrated in the relevant figures, and combinations thereof are also possible.

[0056] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is altered and sub-operations described as part of a larger operation are executed independently.

[0057] Example 1: Operational Scope Control

[0058] When a vehicle travels to Huangpu District in Shanghai (beyond the preset Xuhui District area) in operating mode, the positioning module uploads its location coordinates in real time (121.48°E, 31.23°N). After comparison by the geofence management unit, it determines that the vehicle has crossed the boundary and immediately executes a three-level response: a voice warning within 10 seconds, cessation of accepting new orders within 30 seconds, and automatic planning of a route back to Xuhui District after 2 minutes (prioritizing Yan'an Elevated Road), and pushes a boundary crossing message to the vehicle owner in the APP.

[0059] Example 2: Low Battery Anomaly Intervention

[0060] The safety monitoring module detected that the vehicle's battery level had dropped to 8% (the owner-defined threshold is 10%), and immediately uploaded the data to the operation server. The abnormal intervention command generation unit triggered the "low battery intervention" strategy: the vehicle terminal automatically called the navigation module and planned to the "Shanghai South Railway Station charging station" 3 kilometers away. At the same time, a push notification was sent to the owner through the APP: "Battery level is too low. We have planned to the nearest charging station for you. Remaining range is 15 kilometers."

[0061] This invention achieves dynamic switching safety management between autonomous driving and operational scenarios, dynamic limitation of operational scope, and real-time monitoring of vehicle status through modular design. In view of the current lack of dual-mode switching intelligent connected vehicles, it provides key technical support for the future "one vehicle, two uses" mode. It can be widely used in private car sharing operation platforms and car companies' own mobility services, significantly improving the operational safety of intelligent connected vehicles.

[0062] Although various concepts have been described in detail, those skilled in the art will understand that various modifications and substitutions to those concepts are possible within the spirit of the overall teachings of this invention.

[0063] Furthermore, although the invention has been described in the context of functional modules and illustrated by block diagrams, it should be understood that, unless otherwise stated, one or more of the described functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the system disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

Claims

1. A safety management and control system for a dual-mode intelligent connected vehicle (autonomous driving / operation), characterized in that, include: The vehicle-mounted terminal, installed inside the vehicle, includes a mode control module, a safety monitoring module, and a positioning and communication module, and is used to perform mode switching, status acquisition, and data communication. The operation server, deployed in the cloud, includes a geofence management unit, an authentication database, and an anomaly intervention command generation unit, used for data storage, decision-making, and command generation; the user terminal is a vehicle owner mobile application, including a mode setting module, an authentication module, and a status viewing module, used for initiating requests, authentication, and status monitoring; the three components interact via network communication, wherein: after receiving a switching request, the mode control module verifies permissions in collaboration with the authentication module and the authentication database, and then executes the self-driving / operation mode switch; The geofencing management unit delineates the boundaries of the operating area, determines boundary violations and triggers tiered interventions based on real-time location data uploaded by the positioning and communication module, and the safety monitoring module collects key vehicle parameters. The abnormal intervention command generation unit generates intervention commands based on preset thresholds and issues them for execution.

2. The system according to claim 1, characterized in that, When the mode control module performs mode switching, it activates / disables autonomous driving permissions, restricts / enables manual driving operations, and synchronizes the status to the operation server and user terminal through the positioning and communication module. The identity verification adopts "two-factor authentication" (such as face recognition + APP key), with a matching threshold of ≥95%. If the verification fails, the terminal is locked for 30 minutes.

3. The system according to claim 1, characterized in that, The safety monitoring module collects parameters in real time via the CAN bus, including: battery level (once per minute), tire pressure (once every 30 seconds), fault codes (triggered in real time), and vehicle speed (once per second). The sampling accuracy meets the requirement that the vehicle speed error is ≤0.5km / h. The abnormal intervention command generation unit has preset thresholds: when the battery level is <10% (customizable), it navigates to the charging station; when the tire pressure is <90% of the standard value, the speed is limited to ≤30km / h and a prompt is given; and high-risk fault codes trigger "emergency stop + rescue dispatch".

4. The system according to claim 1, characterized in that, The positioning and communication module integrates a GPS / BeiDou positioning chip and a 4G / 5G communication module: the positioning accuracy error is ≤5 meters, and AES-256 encrypted transmission is used; the geofence management unit supports dual area restrictions of vehicle owner customization and platform compliance (accuracy of 10 meters), and cross-boundary triggers a three-level response: voice warning, stop accepting orders, and automatically plan a return route after 5 minutes.

5. The system according to claim 1, characterized in that, The status viewing module displays in real time: current mode (autonomous driving / operational), operating data (battery level, vehicle speed, location), abnormal alerts and intervention progress, with a data synchronization delay of ≤3 seconds; Geofencing boundary data is periodically synchronized to user terminals so that vehicle owners can view the permitted operating range.

6. A safety management and control method for a dual-mode intelligent connected vehicle (autonomous driving / operation), characterized in that, The process includes the following steps: (1) The vehicle owner initiates a mode switching request through the user terminal. The system calls the identity verification module to collect information and uploads it to the identity verification database for comparison (matching degree ≥ 95%). (2) After verification, the vehicle terminal mode control module performs the switch and synchronizes the status to the operation server and user terminal. (3) During operation, the safety monitoring module collects vehicle parameters and uploads them. The abnormal intervention instruction generation unit generates intervention instructions based on the preset threshold. (4) The geofence management unit determines the boundary crossing through real-time location and triggers an early warning, stops accepting orders, or automatically navigates back. (5) After the order is completed or the mode is switched, the system terminates the intervention and updates the status to "standby".

Images