Security data permission control method and electronic device

Abstract

The safety data authority control method and the electronic equipment provided by the application relate to the Internet of Vehicles monitoring technical field. The method is executed by a cloud platform, and comprises the following steps: obtaining a stage switching trigger event from a vehicle terminal or a mobile terminal, the stage switching trigger event being an event generated based on a judgment on a travel process state; in response to the stage switching trigger event, updating a current stage of a monitoring scene of the present trip to link a key conversion node from driving to walking and avoid a monitoring vacuum problem that is prone to occurring in a scene switching process; and based on the updated current stage of the monitoring scene, controlling a viewing authority of a family terminal on safety data. Thus, the application can meet the actual needs of the family terminal to view the travel safety status in stages, thereby solving the technical problem that the safety data sharing mode generated by the two types of systems in the prior art is fixed and the viewing authority of the family terminal on the safety data cannot be dynamically adjusted according to different stages of the travel process.

Description

Technical Field

[0001] This application relates to the field of vehicle network monitoring technology, and more specifically, to a secure data access control method and electronic device. Background Technology

[0002] With the popularization of intelligent vehicles and mobile terminals, users' travel has formed a closed loop scenario from driving to parking, walking and then arriving at the destination. The demand for travel safety monitoring has also extended from a single driving scenario to continuous monitoring throughout the entire process.

[0003] To address the need for travel safety monitoring, existing technologies mainly fall into two categories: one is in-vehicle safety monitoring systems, which use DMS (Driver Monitoring System) and ADAS (Advanced Driver Assistance Systems) to monitor and warn about safety during driving. The other is mobile terminal pedestrian safety systems, which use positioning, motion sensors, and SOS (Save Our Souls) functionality to track location and provide emergency protection in pedestrian scenarios.

[0004] However, both types of systems operate independently, and the security data they generate is typically only available to the traveler or the backend server. While family members have a need to understand the traveler's safety status, existing solutions can only provide a fixed, indiscriminate data sharing method, and cannot dynamically adjust the family members' viewing permissions for security data according to different stages of the travel process. Summary of the Invention

[0005] The security data access control method and electronic device provided in this application can meet the actual needs of family members to view the travel safety status in stages. This solves the technical problem in the prior art where the security data sharing method generated by the two types of systems is fixed and cannot dynamically adjust the family members' access to security data according to different stages of the travel process.

[0006] Firstly, a method for controlling access to security data is provided, executed by a cloud platform. This method includes: acquiring a stage switching trigger event from the vehicle-mounted terminal or a mobile terminal, wherein the stage switching trigger event is an event generated based on the judgment of the travel process status; in response to the stage switching trigger event, updating the current stage of the monitoring scenario for this trip; and controlling the viewing permissions of family members on the security data based on the updated current stage of the monitoring scenario; wherein the security data is data related to travel safety reported by the vehicle-mounted terminal and / or the mobile terminal.

[0007] The above technical solution breaks down the barriers between traditional vehicle-mounted safety monitoring systems and mobile terminal pedestrian safety systems, which are isolated and can only operate independently in a single scenario, by acquiring stage switching trigger events generated from the vehicle-mounted terminal or mobile terminal based on the judgment of the travel progress status. In response to the stage switching trigger event, the current stage of the monitoring scenario for this trip is updated to bridge the critical transition from driving to walking, avoiding monitoring gaps that may occur during scenario switching. Simultaneously, based on the updated current stage of the monitoring scenario, the access permissions of family members to view safety data are controlled. This safety data is travel safety-related data reported by the vehicle-mounted terminal and / or mobile terminal, enabling dynamic adjustment of data sharing rules according to different stages of the travel process. This breaks away from the original fixed and indiscriminate data sharing mode, adapting to the actual needs of family members to view travel safety status in stages. This solves the technical problem in existing technologies where the safety data sharing methods generated by the two systems are fixed, making it impossible to dynamically adjust the access permissions of family members to view safety data according to different stages of the travel process.

[0008] Secondly, a security data access control device is provided, executed by a cloud platform. The device includes: an acquisition module for acquiring a stage switching trigger event from the vehicle-mounted terminal or a mobile terminal, wherein the stage switching trigger event is an event generated based on the judgment of the travel process status; an update module for updating the current stage of the monitoring scenario for this trip in response to the stage switching trigger event; and a control module for controlling the viewing permissions of the family member's terminal on the security data based on the updated current stage of the monitoring scenario; the security data is travel safety-related data reported by the vehicle-mounted terminal and / or the mobile terminal.

[0009] Thirdly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the methods of the first aspect or any possible implementation thereof.

[0010] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of this application more easily understood, specific embodiments of this application are given below. Attached Figure Description

[0011] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1This is a schematic diagram of a secure data access control system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3 A flowchart illustrating a secure data access control method provided in this application embodiment. Figure 1 ; Figure 4 This is a schematic diagram of a secure data access control device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0013] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0014] With the widespread adoption of intelligent vehicles and mobile terminals, user travel forms a complete closed loop of driving, parking, and walking to the destination, making continuous safety monitoring throughout the entire process a core requirement. Existing travel safety monitoring technologies mainly fall into two categories: in-vehicle systems and mobile terminal systems. In-vehicle systems use DMS and ADAS to monitor and warn about driving scenarios, while mobile terminal systems utilize positioning, sensors, and SOS functions for pedestrian protection. However, both operate independently in single scenarios, with data isolated from each other. Safety data generated by these two systems is typically only accessible to the traveler or the backend server. While family members have a need to understand the traveler's safety status, existing solutions only provide fixed, indiscriminate data sharing methods and cannot dynamically adjust family members' access permissions to safety data based on different stages of the journey. Therefore, this application proposes a collaborative management solution for the entire driving-walking travel monitoring chain, aiming to achieve seamless data exchange between the vehicle and the terminal, collaborative management of the entire process status, and dynamically adapt family members' access permissions to safety data based on different stages of the journey, thus addressing the shortcomings of existing technologies.

[0015] The following detailed description, in conjunction with the accompanying drawings, of the secure data access control method and electronic device of this application through multiple embodiments, will be provided respectively.

[0016] Figure 1 This is a schematic diagram of a secure data access control system provided in an embodiment of this application. For example... Figure 1 As shown, the secure data access control system 100 includes at least: a cloud platform 110, a vehicle terminal 120, a mobile terminal 130, and a family member terminal 140.

[0017] Among them, the cloud platform 110 is connected to the vehicle terminal 120, the mobile terminal 130 and the family terminal 140 respectively; The cloud platform 110 includes at least the following: a state chain management unit 111, a permission management unit 112, a data archiving unit 113, and an anomaly warning unit 114. The state chain management unit 111 is responsible for generating and updating the security state chain sequence; the permission management unit 112 is responsible for dynamically allocating viewing permissions for family members; the data archiving unit 113 is responsible for end-to-end secure data encryption and storage; and the anomaly warning unit 114 is responsible for full-scenario anomaly detection and tiered warning functions.

[0018] Among them, the state chain management unit 111, as the control unit of the cloud platform 110, establishes a connection with the permission management unit 112 through the internal communication link of the server. It can issue stage permission switching instructions to the permission management unit 112 in real time, driving the permission management unit 112 to complete the opening and revocation of viewing permissions for the driving segment, walking segment, and destination segment on the family terminal. The state chain management unit 111 is connected to the data archiving unit 113, which can synchronize the generated and updated full-time-series security state chain data to the data archiving unit 113, which will then perform encrypted archiving and permanent storage operations. The state chain management unit 111 is connected to the anomaly warning unit 114, which can push the security monitoring data uploaded by the vehicle terminal and mobile terminal to the anomaly warning unit 114 in real time, providing basic data support for the anomaly judgment of the anomaly warning unit 114, and receiving the anomaly judgment results fed back by the anomaly warning unit 114, realizing the linkage and coordination between state chain management and anomaly warning.

[0019] The vehicle terminal 120 includes at least: a driver monitoring unit 121, a vehicle-to-vehicle coordination control unit 122, and a CAN signal acquisition unit 123. The vehicle terminal 120 is an in-vehicle intelligent terminal installed in a smart car; the driver monitoring unit 121 monitors driving behavior for safety based on the DMS (Driver Monitoring System); the CAN signal acquisition unit 123 acquires physical signals of vehicle operation through the vehicle's CAN bus; and the vehicle-to-vehicle coordination control unit 122 serves as the control core of the vehicle terminal 120, coordinating the processing of driver monitoring data and CAN signals, as well as the generation and uploading of stage switching commands.

[0020] The driving monitoring unit 121 is connected to the vehicle-machine collaborative control unit 122 via the vehicle internal data interface, transmitting DMS driving monitoring data and ADAS (Advanced Driver Assistance Systems) warning data to the vehicle-machine collaborative control unit 122 for integration and processing in real time. The CAN signal acquisition unit 123 is connected to the vehicle-machine collaborative control unit 122 via the vehicle CAN bus interface, continuously collecting parking condition signals such as vehicle engine shutdown, handbrake engagement, and door closure, and uploading them to the vehicle-machine collaborative control unit 122. The vehicle-machine collaborative control unit 122 establishes a remote communication connection with the state chain management unit 111 of the cloud platform 110 via the 4G / 5G vehicle network communication protocol, and can upload driving segment safety data, parking switching instructions, and stage switching requests to the state chain management unit 111, realizing instruction and data interaction between the vehicle terminal and the cloud platform.

[0021] The mobile terminal 130 includes at least: a mobile command receiving unit 131, a geofence determination unit 132, and a motion monitoring unit 133. The mobile terminal 130 is a portable smart device such as a smartphone carried by the user; the mobile command receiving unit 131 is responsible for receiving stage switching commands issued by the cloud platform; the geofence determination unit 132 determines the walking termination condition based on the preset destination geofence; and the motion monitoring unit 133 collects walking safety data based on positioning sensors and motion sensors.

[0022] The mobile command receiving unit 131 is connected to the mobile monitoring unit 133 via the internal data bus of the mobile terminal. After receiving the parking switch command from the cloud platform 110, it immediately sends a command to the mobile monitoring unit 133 to start the walking monitoring mode. The geofence determination unit 132 is connected to the mobile monitoring unit 133, obtains the location data collected by the mobile monitoring unit 133 in real time, performs the determination operation of whether the user has entered the destination geofence, and feeds back the determination result to the mobile monitoring unit 133. The mobile command receiving unit 131 communicates with the state chain management unit 111 of the cloud platform 110 via the 4G / 5G mobile communication protocol to receive the stage synchronization command issued by the state chain management unit 111. The mobile monitoring unit 133 is also connected to the state chain management unit 111 to upload walking safety data such as walking location, movement status, and dwell time to the state chain management unit 111 in real time, and sends a destination segment monitoring termination request to the state chain management unit 111.

[0023] The family member terminal 140 includes at least: a family member view unit 141 and an anomaly receiving unit 142. The family member terminal 140 is a smartphone terminal used by the guardian's family member; the family member view unit 141 is used to display the user's current travel stage and safety status according to permissions; the anomaly receiving unit 142 is used to receive anomaly warning information pushed by the cloud platform, enabling the family member to visually monitor the user's travel safety and receive anomaly alarms.

[0024] Among them, the family view unit 141 establishes a data connection with the permission management unit 112 of the cloud platform 110 through the mobile communication network. The permission management unit 112 dynamically grants or revokes the safety data viewing permissions for the driving and walking segments to the family view unit 141 according to the instructions of the state chain management unit 111. The family view unit 141 only displays the safety status information within the current permission range. The anomaly receiving unit 142 establishes an early warning push connection with the anomaly warning unit 114 of the cloud platform 110. When the anomaly warning unit 114 determines anomalies such as driving danger, nighttime stay, stay in remote areas, or standing still for too long, it immediately pushes graded early warning information to the anomaly receiving unit 142 through this connection to realize real-time anomaly alarms on the family end.

[0025] The security data access control system provided in this application can be composed of at least a cloud platform, a vehicle-mounted system, a mobile terminal, and a family member's terminal. The state chain management unit of the cloud platform establishes communication connections with the vehicle-mounted collaborative control unit on the vehicle-mounted system, the mobile command receiving unit on the mobile terminal, and the family member's view unit on the family member's terminal. This state chain management unit can receive the first-stage switching request generated by the vehicle-mounted collaborative control unit based on vehicle status data collected by the CAN signal acquisition unit, and simultaneously receive the second-stage switching request and pedestrian safety data reported by the mobile terminal. It can also issue monitoring control commands to the mobile command receiving unit and synchronize the current stage of the security state chain and the security data view to the family member's view unit, thereby achieving seamless switching and real-time state synchronization across all travel stages (driving, parking, walking, and destination), ensuring uninterrupted security monitoring throughout the entire process. This state chain management unit also communicates with the access control unit and data archiving unit within the cloud platform, and can dynamically update the data viewing permissions of the family member's view unit based on the current stage of the security state chain, thereby controlling monitoring permissions. At the end of the monitoring process, the data archiving unit encrypts and archives the complete safety status chain, achieving time-series traceable management of the safety status throughout the entire process. The cloud platform's anomaly warning unit maintains communication with the status chain management unit and the family member's anomaly receiving unit. It can intelligently determine anomalies based on the driving and walking safety data synchronized by the status chain management unit and send tiered warning information to the anomaly receiving unit, effectively improving the timeliness and accuracy of cross-scenario anomaly warnings. The vehicle-mounted collaborative control unit communicates with the driving monitoring unit and the CAN signal acquisition unit, respectively. It can make collaborative decisions based on the vehicle operation data collected by the driving monitoring unit and the vehicle status signals obtained by the CAN signal acquisition unit, providing stable and reliable data support for automatic switching of travel stages. The mobile terminal's motion monitoring unit communicates with the geofence determination unit, which in turn communicates with the motion command receiving unit. It can automatically determine the destination based on positioning and motion status monitoring, ensuring intelligent start and stop of walking monitoring and further enhancing the seamless convenience of the entire process of safety monitoring.

[0026] Optionally, Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 2 As shown, the electronic device 200 may include a processor 210 and a memory 220.

[0027] The memory 220 stores machine-executable instructions that can be executed by the processor 210. When the electronic device 200 is running, these machine-readable instructions are executed. The processor 210 and the memory 220 communicate via a bus. The processor 210 can execute these machine-executable instructions to implement a secure data access control method.

[0028] The memory 220, processor 210, and bus components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected via one or more communication buses or signal lines. The memory 220 includes at least one software functional module, which is stored or embedded in the operating system (OS) of the electronic device in the form of software or firmware. This software functional module includes at least one executable module. The processor 210 executes the executable modules stored in the memory 220, such as the software functional modules and computer programs included in the secure data access control method.

[0029] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0030] The electronic device 200 can be selected according to actual needs; for example, it can be a controller or computer device on a cloud platform. Furthermore, the electronic device 200 has software or a secure data access control system capable of executing secure data access control methods, which can be used to execute such methods.

[0031] The secure data access control method provided in this application adopts an end-to-cloud collaborative architecture. Peripheral terminal devices (vehicle-mounted devices, mobile terminals) are used to perform local data perception on the terminal side, travel process status judgment, generation of stage switching trigger events, and event uploading operations. The electronic device 200 (such as a cloud platform device), as the execution subject of this application, has a built-in state chain management unit used to remotely listen to, receive, and acquire stage switching trigger events from the peripheral terminal devices, and perform subsequent state chain updates, access control, anomaly warnings, and other full-process collaborative management operations based on these trigger events. The peripheral terminal devices and the electronic device 200 have an upstream-downstream end-to-cloud collaborative execution relationship, respectively undertaking different technical functions such as terminal-side event generation and reporting, cloud-side event acquisition, and global control. This application uses the cloud platform as the execution subject. The secure data access control method provided in this application embodiment will be explained below. Figure 3A flowchart illustrating a secure data access control method provided in this application embodiment. Figure 1 .like Figure 3 As shown, the method may include: S310. Obtain the stage switching trigger event from the vehicle terminal or mobile terminal.

[0032] Among them, the stage switching trigger event is an event generated based on the judgment of the travel process status (such as the time sequence status of driving segment, parking segment, walking segment, and destination segment), and includes at least: the trigger command for switching from driving segment to parking segment, the trigger command for switching from walking segment to destination segment, and the safety monitoring data reported by the mobile terminal after the walking monitoring is enabled.

[0033] In one possible implementation, to sense the phase changes in the user's travel process, as well as the current phase update of the monitoring scenario, the switching of monitoring permissions, and the start and stop of corresponding phase safety monitoring, triggering basis is provided. This enables seamless connection and imperceptible collaboration of the entire safety monitoring chain, from driving to parking, walking, and destination. Therefore, the state chain management unit can monitor and receive command messages uploaded by the vehicle terminal 120 or mobile terminal 130 in real time through 4G / 5G vehicle networking and mobile communication networks. These command messages serve as the transmission carrier for the aforementioned phase switching trigger events and corresponding safety monitoring data. Specifically, the command message for switching from driving to parking is generated by the CAN bus signals collected by the CAN signal acquisition unit on the vehicle terminal, indicating that the vehicle is off, the handbrake is engaged, and the doors are closed. After the vehicle-to-vehicle cooperative control unit determines that the preset parking conditions are met, it encapsulates the switching control command and vehicle status data into a command message and uploads it to the cloud platform. The instruction message for switching from the walking segment to the destination segment is determined by the mobile terminal's geofence determination unit based on location data, which confirms that the user has entered the destination geofence, or by the user initiating a manual confirmation command. The motion monitoring unit encapsulates the termination control command and location data into an instruction message and uploads it to the cloud platform. The cloud platform then receives the stage switching trigger event from the vehicle's infotainment system or the mobile terminal.

[0034] S320, In response to the phase switching trigger event, update the current phase of the monitoring scenario for this trip.

[0035] In one possible implementation, since the stage switching trigger event is not randomly generated, but rather generated and uploaded by the vehicle-mounted device or mobile terminal based on its own collected hardware perception data and pre-defined travel process judgment rules, it occurs only after a stage transition occurs in the actual travel process and the stage switching conditions are met. The stage switching trigger event itself carries a clear stage switching type and travel status identifier. At the same time, the system pre-sets fixed time-series monitoring scenarios for driving, parking, walking, and destination segments. The cloud-based state chain management unit only needs to parse and identify the switching type corresponding to the trigger event to match the next legitimate monitoring scenario stage. It has the judgment basis and rule support for changing the current monitoring stage. Therefore, the cloud platform only needs to respond to the compliant and valid stage switching trigger event to automatically and accurately complete the update and switching of the current stage of the current travel monitoring scenario based on the real travel process information carried by the event.

[0036] Based on this, after acquiring the stage switching trigger event uploaded by the vehicle-mounted terminal or mobile terminal, the state chain management unit unpacks and parses the command message according to the preset message parsing rules. First, it extracts the event source identifier and event type identifier from the message header to distinguish whether the trigger event originates from the vehicle-mounted terminal or the mobile terminal. Then, it extracts core data from the message payload, which includes at least: stage switching command, vehicle status data, location data, and safety monitoring data. Subsequently, it performs legality and integrity checks on the extracted core data, eliminating invalid or abnormal messages. After the checks pass, it identifies the specific type of stage switching based on the event type identifier. That is, if the parsed command message originates from the vehicle-mounted terminal and contains vehicle status data such as vehicle engine off, handbrake engaged, and doors closed, it is identified as a trigger event for switching from the driving segment to the parking segment. If the parsed message originates from the mobile terminal and contains destination geofence matching results or user manual confirmation commands, it is identified as a trigger event for switching from the walking segment to the destination segment.

[0037] Then, using the phase transition trigger event as the sole trigger for phase updates, the monitoring scenario phase update process is immediately initiated. This involves modifying the current monitoring scenario phase identifier based on the pre-defined four-segment sequential travel process rules (driving, parking, walking, and destination segments) and the parsed phase transition trigger event type. When a trigger event indicating a transition from driving to parking is parsed, the current monitoring scenario phase is updated from driving to parking; similarly, when a trigger event indicating a transition from walking to destination is parsed, the current monitoring scenario phase is updated from walking to destination. Simultaneously, the updated current monitoring scenario phase information is temporarily stored locally and synchronized. This provides a phase baseline for subsequent access control, data archiving, and anomaly alerts.

[0038] S330. Based on the current stage of the updated monitoring scenario, control the family member's access permissions to view security data.

[0039] The safety data refers to business data directly related to the user's travel safety status reported by the vehicle-mounted system and / or mobile terminals. The data sources for this business data include at least the vehicle-mounted system and mobile terminals. That is, the business data can be reported separately by the vehicle-mounted system or the mobile terminal, or simultaneously by both. Specifically, the safety data reported by the vehicle-mounted system includes: driver status monitoring data collected by the driving monitoring unit, advanced driver assistance system warning data, and vehicle operating status data collected by the CAN signal acquisition unit; the safety data reported by the mobile terminal includes: location data, motion sensor data, environmental monitoring data, geofencing determination results data, and emergency distress alarm data collected by the motion monitoring unit. All of the above data is packaged and uploaded to the cloud platform as a data source accessible to family members within their authorized scope.

[0040] Among them, the current stage of the updated monitoring scenario is determined by the state chain management unit based solely on the latest updated and calibrated monitoring scenario stage identifier for this trip. It abandons the traditional fixed monitoring mode and clarifies the user's current real travel monitoring scenario according to the four-stage time-sequential travel process rules of driving, parking, walking, and destination.

[0041] In one possible implementation, since the monitoring tasks, function start / stop rules, and data collection strategies differ for each monitoring scenario—driving, parking, walking, and destination—updating solely on the cloud platform for the current monitoring stage cannot automatically adjust data access permissions for family members. The cloud platform must issue dedicated monitoring control instructions based on the latest monitoring stage to dynamically manage the scope and access permissions of family members' viewing of safety data. This safety data includes driver status data and vehicle operation status data reported by the vehicle's infotainment system, as well as location data, motion sensor data, and environmental monitoring data reported by mobile terminals, all related to travel safety. This approach can match the monitoring needs and privacy control requirements of different travel stages, avoiding unreasonable permission issues arising from a fixed, indiscriminate data sharing model, and ensuring travel data security and access compliance. Based on this, the state chain management unit pre-stores a standardized permission control instruction policy library corresponding to each monitoring scenario stage. Different travel monitoring stages are matched with dedicated control logic for family members' data viewing, permission activation, permission revocation, and data anonymization. After determining the updated current monitoring scenario stage, the corresponding permission control instructions are automatically retrieved. Specifically, if the current monitoring scenario is in the driving, parking, or walking phase of the journey, the state chain management unit generates corresponding instructions to grant family members normal viewing permissions for the corresponding stage of safety data. If the current monitoring scenario changes from the walking phase to the destination phase, the state chain management unit generates a permission revocation instruction to close the family members' viewing permissions for the current journey's safety data. It can also anonymize historical travel data. Simultaneously, the state chain management unit encapsulates the generated permission control instructions into standard instruction messages according to a preset mobile communication protocol and sends them in real-time to the corresponding family member's device via a dedicated communication link between the cloud platform and the mobile terminal. Upon receiving the instruction message, the family member's device parses it and executes the corresponding permission change operation. This achieves dynamic adaptation and orderly switching of data viewing permissions under different travel scenarios, without any manual intervention. This solves the technical problem of existing solutions using a fixed, indiscriminate data sharing method and being unable to dynamically adjust family members' viewing permissions according to the travel progress, ensuring the rationality, security, and adaptability of data sharing throughout the user's entire travel process.

[0042] For example, the state chain management unit synchronously sends the latest real-time monitoring scenario information to the permission management unit. The permission management unit then retrieves the internally stored phased permission control policies, generates corresponding permission control instructions based on the current phase, and sends them to the family view unit on the family's end via the network communication link. This restricts the scope of safe data that the family can browse and view from the background permission level, achieving the goal of dynamically controlling the family's viewing permissions according to the travel phase, and avoiding information leakage and ineffective monitoring problems caused by arbitrary or permanent opening of permissions.

[0043] The security data access control method provided in this application breaks down the barriers between traditional vehicle-mounted safety monitoring systems and mobile terminal pedestrian safety systems, which are isolated and can only operate independently in a single scenario, by acquiring stage switching trigger events generated from the vehicle-mounted terminal or mobile terminal based on the judgment of the travel process status. In response to the stage switching trigger event, it updates the current stage of the monitoring scenario for this trip to connect the critical transition node from driving to walking, avoiding the monitoring vacuum problem that easily occurs during scenario switching. Simultaneously, based on the updated current stage of the monitoring scenario, it controls the family member's access to security data, which is travel safety-related data reported by the vehicle-mounted terminal and / or mobile terminal. This allows for dynamic adjustment of data sharing rules according to different stages of the travel process, moving away from the original fixed and indiscriminate data sharing mode, and adapting to the actual needs of family members to view travel safety status in stages. This solves the technical problem in existing technologies where the security data sharing methods generated by the two systems are fixed, and the access permissions of family members to view security data cannot be dynamically adjusted according to different stages of the travel process.

[0044] Optionally, the above method for controlling family members' access to security data includes: If the current stage is the driving segment, grant family members access to view driving segment safety data.

[0045] In one possible implementation, when the current monitoring scenario for this trip is identified as the driving segment, a preset driving segment-specific permission policy is invoked to clarify the business objective: granting only the family member's access to view the corresponding driving segment security data on the vehicle's infotainment system. After determining the business objective, the permission management unit, based on the internal permission protocol, encapsulates the driving segment, access permissions, and data scope (vehicle infotainment system driving data) into a standardized permission granting instruction message according to the fields, format, and encryption method specified in the protocol, and performs a self-check for the legality of the permission granting instruction message. Once the permission granting instruction is encapsulated, it is sent to the family member's device according to the communication link and transmission sequence agreed upon in the internal permission protocol. The family member's view unit also follows this internal permission protocol, decoding, verifying, and parsing the received permission granting instruction message to identify the corresponding business requirements. Subsequently, the family member's view unit matches the corresponding local permission rules and finally loads and displays the specified range of security data according to the requirements of the driving segment permission policy. The permission granting instruction explicitly limits the scope of data access to driving segment safety data collected, aggregated, and uploaded by the vehicle's infotainment system. This driving segment safety data includes at least driving scenario monitoring content such as driver behavior data, vehicle dynamic data, and vehicle status data, thus avoiding the overgeneralization of the permission scope.

[0046] If the current phase is a walking section, grant family members access to view the walking section's safety data.

[0047] In one possible implementation, when the current monitoring scenario is determined to be a walking segment, a permission switching action is first executed. The previously granted permission to view driving segment safety data is proactively revoked, cutting off the family member's access to historical driving segment data and preventing unauthorized access across different segments. Based on this, the permission management unit generates a new permission opening instruction according to the walking segment permission rules. This new instruction limits access to walking segment safety data collected and reported by the mobile terminal, including location data, movement status data, and other walking scenario monitoring information. After this new instruction is transmitted to the family member's terminal via the communication link, the family member's view unit synchronously responds to the permission change, closing the original driving segment data loading and display channel, switching the data retrieval source to the walking monitoring data uploaded by the mobile terminal, and updating the content in the interface so that the family member's terminal only displays safety information corresponding to walking trips. Therefore, this application can achieve seamless linkage switching between travel stages and data permissions, ensuring that the scope of permission access always matches the current monitoring scenario.

[0048] If the current stage is updated to the destination segment, all viewing permissions will be disabled for family members.

[0049] In one possible implementation, when the current stage of the monitoring scenario updates to the destination segment, it signifies the end of the user's entire trip. This update information is immediately synchronized to the permission management unit, serving as the trigger for permission revoke. Upon recognizing the current stage as the destination segment, the permission management unit executes a pre-defined full permission revoke strategy, uniformly generating a permission closure command. This command does not distinguish between the travel stages to which the data belongs, thus revoking the family member's viewing permissions for all safety data related to this trip. Subsequently, the permission management unit sends the permission closure command to the family member's device via the communication link. Upon receiving the permission closure command, the family member's view unit immediately stops loading, parsing, and displaying all safety data for this trip, simultaneously locking all data access channels and clearing the original content displayed on the interface. Ultimately, this prevents the family member from viewing safety data for any stage of the trip. Therefore, full permission closure can be completed upon arrival at the destination, forming a closed loop of dynamic permission control and maximizing the protection of the user's travel data privacy after the entire monitoring process concludes.

[0050] It should be noted that the policy for controlling the family member's access to security data is implemented by the cloud platform's permission management unit according to the current stage of the monitoring scenario synchronized by the state chain management unit, and is linked and adapted in real time with the family member's view unit on the family member's end.

[0051] In one possible implementation method The security data access control method provided in this application grants family members access to view safety data for the driving segment if the current monitoring stage is driving; access to view safety data for the walking segment if the current monitoring stage is walking; and automatic closure of all data viewing permissions for family members if the current monitoring stage changes to the destination segment. Thus, this application, through a hierarchical access control method that is linked in real-time with the travel monitoring scenario, enables family members' viewing permissions to adaptively adjust with the travel progress. This ensures that family members can view safety monitoring data in accordance with regulations at the corresponding stage for effective monitoring, while also allowing for timely revoke of permissions upon arrival at the destination to prevent excessive leakage of privacy data. Furthermore, it adapts to seamless switching logic across the entire process, further improving the end-to-end cloud collaborative monitoring system and avoiding the problems of poor monitoring adaptability and lack of privacy control caused by the isolation of traditional systems and rigid, fixed permissions.

[0052] Optionally, the method described above includes obtaining the stage switching trigger event from the vehicle-mounted system or mobile terminal, including: Get the first-stage switching request generated by the vehicle terminal when it detects that the vehicle status meets the preset parking conditions.

[0053] The first-stage switching request is used to request an update to the current stage of the monitoring scenario.

[0054] The preset parking conditions are based on a joint determination of multiple signals from the vehicle's powertrain, parking brake status, and door status. These preset parking conditions are determined collaboratively by the vehicle's CAN signal acquisition unit and the vehicle-to-everything (V2X) control unit. This preset parking condition is not determined by a single signal, but rather employs a multi-dimensional signal joint verification mechanism. The CAN signal acquisition unit simultaneously acquires signals from the vehicle's powertrain, parking brake status, and door status. The vehicle's powertrain signal indicates whether the vehicle is off; the parking brake status signal indicates whether the handbrake is engaged and the vehicle is parked securely; and the door status signal indicates whether the vehicle doors are fully closed and locked. The V2X control unit performs a joint logical determination on these three signals. Only when the vehicle's powertrain, parking brake status, and door status all simultaneously meet the preset threshold requirements can the overall preset parking condition be considered met. This avoids invalid request generation due to misjudgment of a single signal, ensuring the accuracy and reliability of the first-stage switching request generation. The preset threshold can be selected according to actual conditions.

[0055] In one possible implementation, the vehicle-mounted terminal 120 collects various vehicle operating status signals in real time according to the CAN signal acquisition unit 123, and the vehicle-mounted cooperative control unit 122 performs real-time logical judgment on the collected vehicle status. When the vehicle status is determined to meet the preset parking conditions, the vehicle-mounted cooperative control unit 122 automatically generates a first-stage switching request. This request is encapsulated into a standard message according to a preset communication protocol and uploaded to the cloud platform through the vehicle network communication link. The status chain management unit 111 monitors the communication link data in real time and completes the reception and acquisition of the first-stage switching request. The core function of the first-stage switching request is to initiate a scenario change application to the cloud, requesting the cloud to switch and update the stage of the user's current travel monitoring scenario, providing a proactive request basis for subsequent monitoring scenario stage adjustments.

[0056] And / or acquire safety data reported by the mobile terminal after pedestrian monitoring is enabled.

[0057] Among them, security data is used to trigger the update of the current stage of the monitored scenario to the walking stage.

[0058] In one possible implementation, once the travel process reaches the parking completion state, the cloud platform or local device triggers the mobile terminal to activate the pedestrian monitoring mode. The mobile terminal's motion monitoring unit activates its built-in positioning and motion sensors to collect data in real time, forming safety data corresponding to the pedestrian scenario. The mobile terminal encapsulates the collected safety data according to a preset communication protocol and actively reports it to the cloud platform. The state chain management unit receives and acquires this safety data in real time. This safety data serves as the trigger source for stage switching. Upon receiving valid and compliant safety data, the cloud platform can directly trigger logical actions to automatically update and switch the current stage of the user's monitoring scenario to the walking segment, achieving an automatic transition from the parking scenario to the pedestrian monitoring scenario.

[0059] And / or acquire the second-stage handover request generated by the mobile terminal when it detects arrival at the destination segment.

[0060] The second-stage switching request is used to request that the current stage of the monitoring scenario be updated to the destination stage.

[0061] The phase switching trigger event serves as the unified trigger carrier for the cloud platform to perform phase updates of the monitoring scenario. It comprises at least three components: a first-phase switching request from the vehicle-mounted system, security data from the mobile terminal, and a second-phase switching request from the mobile terminal. Specifically, the first-phase switching request from the vehicle-mounted system refers to the trigger command for switching from the driving segment to the parking segment; the security data from the mobile terminal refers to the security monitoring data reported by the mobile terminal after pedestrian monitoring is activated; and the second-phase switching request from the mobile terminal refers to the trigger command for switching from the walking segment to the destination segment.

[0062] In one possible implementation, the mobile terminal's geofence determination unit continuously matches and compares real-time location data with a pre-defined destination geofence range to detect whether the user has arrived at the destination coverage area. When it is determined that the user's location has entered the destination geofence and the destination segment has been detected, the mobility monitoring unit generates a second-stage switching request, encapsulates it into a communication message, and uploads it to the cloud platform. The state chain management unit listens for and receives the second-stage switching request. The purpose of this second-stage switching request is to initiate a scenario termination change request to the cloud platform, that is, to request that the current pedestrian monitoring scenario stage be updated to the destination segment, marking the end and termination of this pedestrian monitoring process.

[0063] The security data access control method provided in this application acquires a first-stage switching request generated by the vehicle terminal when it detects that the vehicle status meets preset parking conditions. This request is used to update the current stage of the monitoring scenario. The preset parking conditions are determined jointly by multiple signals, including the vehicle's power system, parking brake status, and door status, which improves the accuracy and reliability of parking status recognition. The method also acquires security data reported by the mobile terminal after it starts pedestrian monitoring. Based on this security data, the current stage of the monitoring scenario can be updated to the pedestrian segment, enabling automatic switching to the pedestrian monitoring scenario. Simultaneously, the method acquires a second-stage switching request generated by the mobile terminal when it detects that it has reached the destination segment. This request is used to update the current stage of the monitoring scenario to the destination segment. Correspondingly, the stage switching trigger event at least includes the first-stage switching request from the vehicle terminal, the security data from the mobile terminal, and the second-stage switching request from the mobile terminal. Therefore, this application, by being compatible with multiple terminals and multiple types of trigger sources, covers all travel process nodes from driving to parking, parking to walking, and walking to destination, and constructs a multi-dimensional, full-process event triggering mechanism. This effectively solves the shortcomings of traditional solutions that only operate independently in a single scenario and have a single triggering method, and provides reliable triggering support for automatic and seamless switching of monitoring scenarios and eliminating monitoring vacuums during transition phases.

[0064] Optionally, the above method further includes: The timer starts when the vehicle status is detected to meet the preset parking conditions.

[0065] The preset parking condition is that the engine is off, the handbrake is engaged and locked, and the doors are fully closed, all three conditions must be met simultaneously.

[0066] In one possible implementation, the CAN signal acquisition unit connects to the vehicle's CAN bus in real time, continuously polling and acquiring key vehicle status signals such as engine off status, handbrake engaged status, and door closed status. It then transmits the collected raw CAN status data from multiple channels to the vehicle-to-everything (V2X) control unit in real time. The V2X control unit has pre-configured standardized parking determination rules. Only when the engine is off, the handbrake is engaged and locked, and the doors are fully closed simultaneously is the preset parking condition initially determined to be met. If any one of these conditions is not met, the determination process is terminated. When the vehicle's instantaneous status simultaneously meets multiple requirements, the V2X control unit immediately activates its internal timing module and begins timing, thus avoiding false triggering issues caused by status fluctuations such as temporary engine shutdown, brief handbrake engagement, or momentary door opening and closing.

[0067] If the timeout is greater than or equal to the preset duration and the vehicle status continues to meet the preset parking conditions, then the vehicle status is determined to meet the preset parking conditions.

[0068] The preset duration can be selected according to the actual situation.

[0069] In one possible implementation, throughout the entire timer cycle of the preset duration, the vehicle-to-machine (V2M) control unit continuously collects vehicle status data at high frequency via the CAN signal acquisition unit, performing real-time verification of all parking conditions. If any change occurs during the timer, such as engine restart, handbrake release, or door opening, the timer immediately stops and the judgment logic is reset, denying the preset parking conditions. Only when the timer duration is greater than or equal to the system's preset duration, and all vehicle statuses remain stable and consistently meet the preset parking conditions without any abnormal fluctuations throughout the timer interval, can the V2M control unit finally confirm that the vehicle stably meets the preset parking conditions. This provides accurate and reliable judgment data for subsequently generating the stage transition trigger event from the driving segment to the parking segment and uploading it to the cloud platform.

[0070] The secure data access control method provided in this application, upon real-time acquisition of the vehicle's CAN bus status signal at the vehicle's infotainment system and detection that the vehicle initially meets the preset parking conditions, immediately activates a built-in timing mechanism for delay buffering to avoid misjudgments caused by instantaneous fluctuations in the vehicle's status or temporary operational jitter. Throughout the entire timer cycle, which lasts for the preset duration, the vehicle's status is continuously monitored and verified. If, upon the expiration of the timer, the vehicle consistently maintains and continues to meet the preset parking conditions, then the vehicle is ultimately confirmed to have stably met the parking conditions. Therefore, this application effectively filters instantaneous signal interference and temporary state changes through instantaneous initial judgment and delayed steady-state verification, improving the accuracy and reliability of parking condition determination. This provides a reliable pre-judgment basis for subsequently generating stage switching trigger events and achieving smooth switching of monitoring scenarios.

[0071] Optionally, in the above method, in response to the phase switching trigger event, the current phase of the monitoring scenario for this trip is updated, including: If the stage switching trigger event is the first stage switching request on the vehicle's infotainment system, then the current stage of the monitoring scenario for this trip will be updated to the parking segment.

[0072] In one possible implementation, after acquiring and parsing the command and data messages uploaded by the vehicle terminal and mobile terminal, the state chain management unit classifies and identifies them according to the message identifier type and matches the corresponding monitoring scenario stage update logic: if the received stage switching trigger event is identified as a first stage switching request uploaded by the vehicle terminal, which is a driving segment to parking segment switching request generated by the vehicle terminal through the CAN signal acquisition unit to collect the vehicle status in real time and by the vehicle-to-vehicle cooperative control unit after a preset parking condition delay steady-state verification, the state chain management unit immediately updates the current stage of the monitoring scenario corresponding to this trip to the parking segment after identifying the request type, thus completing the automatic switching from the driving monitoring scenario to the parking monitoring scenario.

[0073] If the phase switching trigger event is security data from a mobile terminal, then the current phase of the monitoring scenario for this trip will be updated to the walking phase.

[0074] In one possible implementation, if the received stage switching trigger event is identified as security data uploaded by the mobile terminal after parsing, this type of security data is generated and uploaded by the mobile terminal's mobile monitoring unit based on the user's location and motion status information collected by the positioning module and motion sensor. It is used to indicate that the user has left the vehicle and entered a walking travel state. Based on the event type characteristics of this type of security data, the state chain management unit automatically updates the current stage of the monitoring scenario of this trip to the walking segment, realizing a smooth transition from the parking monitoring scenario to the walking monitoring scenario.

[0075] If the phase switching trigger event is a second phase switching request from the mobile terminal, then the current phase of the monitoring scenario for this trip will be updated to the destination phase.

[0076] In one possible implementation, if the received stage switching trigger event is identified as a second-stage switching request uploaded by the mobile terminal, this second-stage switching request is determined by the mobile terminal's geofence determination unit based on location data to match the destination geofence, or it is generated and uploaded by the mobile monitoring unit after the user actively initiates a manual confirmation command. This indicates that the user has arrived at the travel destination. After the state chain management unit identifies the second-stage switching request, it updates the current stage of the monitoring scenario for this trip to the destination segment, marking the end of the monitoring of the entire trip. Thus, by identifying, classifying, matching, and updating the corresponding stage values ​​of stage switching trigger events from different sources and of different types, the monitoring scenario can be automatically adapted based on the actual travel status feedback from the vehicle terminal and the mobile terminal. This enables orderly transitions and divisions of monitoring scenarios for driving, parking, walking, and destination segments, avoiding scenario update errors, switching delays, and monitoring gaps during transition periods.

[0077] The security data access control method provided in this application updates the current stage of the current travel monitoring scenario to the parking segment when the stage switching trigger event is a first stage switching request reported by the vehicle terminal; when the stage switching trigger event is security data uploaded by the mobile terminal, it automatically updates the current stage of the current travel monitoring scenario to the walking segment; when the stage switching trigger event is a second stage switching request initiated by the mobile terminal, it synchronously updates the current stage of the current travel monitoring scenario to the destination segment. By classifying, identifying, and matching stage switching trigger events of different sources and types, the corresponding monitoring scenario stages can be automatically divided and switched according to the actual travel status of the vehicle terminal and the mobile terminal. This avoids the defects of traditional single-scenario independent operation mode, which cannot link across terminals and is prone to monitoring vacuum due to scene switching lag. It realizes the orderly switching, alignment, and seamless connection of each monitoring stage of the entire travel process from driving, parking, walking to the destination, and avoids the problems of stage confusion and monitoring omission.

[0078] Optionally, the above method further includes: Based on the current stage of the updated monitoring scenario, corresponding monitoring and control commands are sent to the vehicle-mounted terminal or mobile terminal.

[0079] In one possible implementation, after completing the entire process of updating the current stage of the current travel monitoring scenario, temporarily storing local data, and marking the stage synchronization, the state chain management unit retrieves the latest monitoring scenario stage identifier that has been calibrated and has no data delay. It discards the old stage data before the update and uses the effective travel stage after real-time synchronization as the sole criterion for generating subsequent instructions, thus avoiding errors in instruction issuance due to stage data lag. Secondly, the state chain management unit has a pre-built standardized mapping strategy library that corresponds one-to-one between monitoring scenario stages and monitoring control instructions. It binds exclusive start-stop monitoring control instructions to different travel stage switching conditions. If the current monitoring scenario is updated from the driving segment to the parking segment, it matches the vehicle driving monitoring shutdown instruction issued to the vehicle terminal. If the current monitoring scenario is updated from the walking segment to the destination segment, it matches the pedestrian safety monitoring shutdown instruction issued to the mobile terminal. At the same time, it distinguishes the target terminal for instruction issuance and distinguishes between the two types of receiving entities: the vehicle terminal and the mobile terminal. Subsequently, the state chain management unit encapsulates the matched monitoring and control commands into standard communication messages with device ID, command code, and effective timestamp according to the preset communication protocol in the cloud. It prioritizes the downlink transmission of monitoring and control commands through the 4G / 5G public network link. If the location is in a weak network area such as an underground parking garage, it automatically switches to the Bluetooth backup communication link between the vehicle terminal and the mobile terminal to resend the monitoring and control commands, ensuring uninterrupted transmission of monitoring and control commands. After receiving the monitoring and control command message, the corresponding terminal completes message parsing and legality verification, and then executes the monitoring function start / stop operation corresponding to the monitoring and control command. This enables the linkage and synchronous switching between the monitoring scenario stage and the terminal monitoring function, ensuring seamless connection of monitoring functions during the transition of the travel stage, eliminating monitoring blind spots, and avoiding the waste of terminal power consumption caused by the ineffective idle operation of the monitoring function.

[0080] The secure data access control method provided in this application, based on the current stage of the updated monitoring scenario, retrieves the preset monitoring control strategy corresponding to the current travel stage on the cloud platform, and issues specific monitoring control instructions adapted to the current travel conditions to the vehicle-mounted terminal or mobile terminal. According to the stage-linked instruction issuance mechanism, the monitoring function can adaptively start, stop, and switch along with the travel process. This not only avoids data redundancy and additional power consumption of the terminal caused by the synchronous operation of the monitoring functions on the vehicle-mounted terminal and mobile terminal, but also connects the switching nodes of the travel stages, eliminating the monitoring vacuum problem during the switching process of driving, parking, and walking, and preventing monitoring failure caused by premature shutdown or delayed start of the monitoring function. No manual intervention is required to start or stop the terminal monitoring module throughout the process, realizing automatic linkage and seamless switching of the monitoring services on the vehicle-mounted terminal and mobile terminal, ensuring uninterrupted and accurate safety monitoring throughout the entire travel process.

[0081] Optionally, in the above method, based on the current stage of the updated monitoring scenario, corresponding monitoring and control instructions are sent to the vehicle-mounted terminal or mobile terminal, including: If the current stage of the updated monitoring scenario is a parking section, a monitoring control command is sent to the mobile terminal associated with the vehicle terminal to trigger the mobile terminal to start pedestrian monitoring.

[0082] In one possible implementation, when the current stage of the updated monitoring scenario is a parking segment, the state chain management unit recognizes that the current travel process has transitioned from a driving scenario to a parking transition scenario. Based on the preset scenario matching control logic, it sends the corresponding monitoring control command to the mobile terminal pre-bound and associated with the vehicle-mounted terminal. The monitoring control command is encapsulated by a preset communication protocol and transmitted to the mobile terminal through a preset network link. After the mobile terminal receives and parses the monitoring control command through its own mobile command receiving unit, it triggers the mobile monitoring unit and the geofence determination unit to simultaneously start their working mode, officially starting the walking monitoring process. It begins to continuously collect user location data and movement status data, and performs real-time determination of the destination geofence, realizing a seamless handover from vehicle driving monitoring to mobile walking monitoring, filling the monitoring gap in the critical stage of transitioning from driving to walking.

[0083] If the current stage of the updated monitoring scenario is the destination segment, a monitoring control command will be sent to the vehicle terminal and / or mobile terminal to disable the safety monitoring function of the vehicle terminal and / or mobile terminal.

[0084] In one possible implementation, when the current stage of the updated monitoring scenario is the destination segment, it means that the user has completed the entire trip and arrived at the target area. The state chain management unit selectively sends shutdown monitoring control commands to the vehicle terminal and / or mobile terminal according to the preset end control rules. After receiving the corresponding command, the vehicle terminal controls the driving monitoring unit and CAN signal acquisition unit to stop the safety monitoring of vehicle status and driver status. After receiving the corresponding shutdown monitoring control command, the mobile terminal forwards it to the mobile monitoring unit through the mobile command receiving unit to shut down the pedestrian safety monitoring functions such as positioning acquisition, motion monitoring and geofence determination, and orderly terminate the entire trip monitoring task. This avoids the terminal from meaninglessly collecting data and the background from consuming resources through invalid calculations, and at the same time completes the closed loop of this trip monitoring process.

[0085] The security data access control method provided in this application, if the current stage of the updated monitoring scenario is a parking segment, the cloud platform proactively sends corresponding monitoring control commands to the mobile terminal associated with the vehicle-mounted terminal, promptly triggering the mobile terminal to start the walking monitoring mode, realizing seamless monitoring from the vehicle driving scenario to the user's walking scenario, and eliminating the monitoring vacuum during the transition from driving to walking; if the current stage of the updated monitoring scenario is the destination segment, the method sends corresponding monitoring control commands to the vehicle-mounted terminal and / or the mobile terminal, shutting down the security monitoring functions of the vehicle-mounted terminal and / or the mobile terminal, avoiding the continuous occupation of ineffective monitoring resources, and orderly terminating the monitoring tasks of each terminal after the entire trip, realizing the linkage and coordinated start and stop between the vehicle-mounted safety monitoring system and the mobile terminal walking safety system, effectively solving the problem of monitoring link breakage caused by the independent operation of the two types of systems and the inability to switch between scenarios.

[0086] Optionally, triggering the mobile terminal to enable pedestrian monitoring in the above method includes: The monitoring and control command is configured to trigger the mobile terminal to perform the following operations: Upon receiving a monitoring and control command, the system activates the motion status monitoring function and identifies whether the user is in walking mode based on the monitored data. Once the user is identified as being in walking mode, the system activates the location function to monitor walking safety.

[0087] In one possible implementation, after receiving a monitoring and control command from the cloud platform via its own mobile command receiving unit, the mobile terminal immediately responds to the monitoring and control command scheduling and actively activates the terminal's built-in motion state monitoring function. This motion state monitoring function, based on the mobile monitoring unit's access to the terminal's built-in inertial sensors such as accelerometers and gyroscopes, continuously collects multi-dimensional raw motion monitoring data, including human posture, gait frequency, and motion acceleration. The mobile monitoring unit filters, reduces noise, and extracts features from the collected sensor data. By comparing and analyzing the monitored motion data through a preset motion behavior discrimination logic, it identifies whether the user is currently in a walking mode, effectively avoiding static, sedentary, or other movement patterns. This addresses the issue of misidentification caused by non-walking conditions such as vehicle bumps. Once the motion monitoring unit confirms that the user is stably in walking mode, it will automatically trigger the generation of a positioning activation signal, linking the activation of the mobile terminal's positioning function. Through satellite positioning modules such as Beidou and GPS, it will continuously acquire the user's real-time location information, officially commencing uninterrupted walking safety monitoring. This provides continuous and reliable positioning data source support for subsequent geofencing determination, abnormal behavior warnings, and travel stage switching judgments. It enables the mobile terminal monitoring function to be automatically activated and stopped as needed according to the travel stage, without manual intervention. At the same time, it reduces the power consumption caused by ineffective sensor collection and positioning standby of the mobile terminal, ensuring a smooth and seamless transition of monitoring from driving to walking.

[0088] The secure data access control method provided in this application configures the monitoring and control command to trigger the mobile terminal to perform corresponding linkage operations. After receiving the monitoring and control command from the cloud platform, the mobile terminal automatically activates its own motion state monitoring function, collects motion monitoring data based on the built-in sensor module, and identifies whether the user is in walking mode. It can distinguish between different behavioral states such as the user being stationary, riding in a vehicle, or walking, avoiding invalid and false monitoring. After confirming that the user is in walking mode, it simultaneously starts the high-precision positioning function to carry out continuous walking safety monitoring, realizing the on-demand automatic start and stop and the orderly activation of the monitoring function in walking scenarios without manual operation. It can adapt to the monitoring needs after the transition of travel stages, save mobile terminal power consumption and system resources, and fill the monitoring gap in the critical stage of driving to walking.

[0089] Optionally, the second-stage handover request in the above method is generated by the mobile terminal when any of the following conditions are met: The mobile terminal detects that the user has entered the preset geofence area, or the mobile terminal receives an arrival confirmation command manually initiated by the user.

[0090] In one possible implementation, since the second-stage switching request is autonomously generated by the mobile terminal and used to represent the stage switching request from the walking segment to the destination segment, this second-stage switching request is limited to being generated by the mobile terminal when either of two triggering conditions is met. First, the mobile terminal collects its own location coordinate data in real time using its built-in positioning module. A geofencing determination unit compares the real-time location coordinates with a pre-configured and stored preset geofencing range for the destination, continuously verifying whether the user's real-time location falls within the preset geofencing range. When it detects that the user's real-time location has entered from outside the geofencing and is stably within the preset geofencing range, it immediately determines that the automatic triggering condition is met and triggers the generation of the second-stage switching request. Second, the mobile terminal reserves a human-computer interaction entry point, allowing the user to manually confirm their arrival at the destination. When the mobile terminal receives an arrival confirmation command manually initiated by the user through interface buttons, touch operations, or voice commands, it directly determines that the manual triggering condition is met, generating the second-stage switching request without relying on geofencing location verification. Therefore, by setting either automatic geofence detection or manual user confirmation as the triggering condition, the system can achieve fully automated and seamless destination arrival determination based on positioning and geofence technology, adapting to travel monitoring scenarios without human intervention. It also retains the fallback triggering method of manual user confirmation, effectively avoiding misjudgments or omissions caused by location drift and geofence matching errors. This improves the flexibility, reliability, and adaptability of the second-stage switching request generation. The generated second-stage switching request will be encapsulated and uploaded to the cloud platform's state chain management unit according to a preset communication protocol, providing a valid triggering basis for subsequent travel monitoring scenario stage updates and the issuance of monitoring and control commands.

[0091] The secure data access control method provided in this application automatically generates a second-stage switching request when the mobile terminal meets any triggering condition. The specific triggering method includes two parallel selectable logics: First, the mobile terminal performs real-time geofence determination based on location data; once it detects that the user has entered the preset destination geofence area, it can automatically generate a second-stage switching request. Second, it supports a manual intervention triggering mode; when the mobile terminal receives a user-initiated arrival confirmation command, it can also generate a second-stage switching request. Therefore, this application, by setting up a dual-redundancy mechanism of automatic geofence triggering and user manual confirmation triggering, can achieve intelligent automatic determination of the walking destination based on location recognition without additional user operation. Furthermore, in scenarios with weak geolocation signals or deviations in geofence determination, it can assist in triggering with user manual confirmation, avoiding the false triggering and missed triggering problems that are prone to occur with a single determination method, and ensuring the reliability and adaptability of the generation of the stage switching request from the walking segment to the destination segment.

[0092] Optionally, the above method further includes: If the current stage of the monitoring scenario is the driving segment, and the safety data reported by the vehicle terminal indicates that the vehicle is in motion, and the deviation between the location data reported by the mobile terminal and the vehicle's location data continues to be greater than a preset distance threshold, then the preset abnormal triggering condition is determined to be met.

[0093] The preset distance threshold can be selected according to the actual situation.

[0094] In one possible implementation, the state chain management unit first identifies the current stage of the monitored scenario as the driving segment, using this as a preliminary benchmark for anomaly detection. Subsequently, the cloud platform continuously receives safety monitoring data uploaded from the vehicle's infotainment system. This vehicle-side safety data is generated by the CAN signal acquisition unit, which collects CAN bus signals such as vehicle speed and gear status, and then encapsulates them before uploading them through the vehicle-to-everything (V2X) control unit. The cloud platform analyzes the data to determine if the vehicle is in a driving state in real time. Simultaneously, the cloud platform receives real-time positioning data uploaded from the mobile terminal, compares the vehicle's own positioning data with the mobile terminal's positioning data using coordinate differences, continuously calculates the spatial position deviation between the two, and employs a continuous judgment mechanism to avoid misjudgments caused by instantaneous positioning drift. This continuous judgment mechanism means that the cloud platform does not determine an anomaly based on a single instantaneous deviation exceeding a certain threshold. Instead, when a single positioning deviation is detected to be greater than a preset distance threshold, a continuous state timing and steady-state verification process is immediately initiated. Within a preset continuous verification duration, the positioning deviations at both ends are compared frame-by-frame without interruption. If the positioning deviation falls back to within the preset distance threshold at any point during the verification process, the timer is immediately reset and the judgment state is reset, indicating a positioning jitter error. If the deviation remains above the limit throughout the entire process without instantaneous recovery, and the state remains stable without fluctuations, and the preset continuous verification time is completed, the cloud platform will ultimately confirm that the positioning deviation continues to exceed the limit. This will then determine that the current scenario meets the preset abnormal triggering conditions, in order to identify real risks such as people leaving the vehicle or abnormal separation of the mobile phone from the vehicle during vehicle operation, and to avoid false triggering problems caused by instantaneous drift of the positioning signal and network fluctuations.

[0095] If the current stage of the monitored scenario is a walking segment, and the safety data reported by the mobile terminal indicates that the movement state is stationary and the duration of the stationary state is greater than the first preset duration threshold, and the current location of the mobile terminal is outside the preset safety geofence, then the preset abnormal triggering conditions are determined to be met.

[0096] Both the first preset duration threshold and the preset security geofence can be selected according to the actual situation.

[0097] In one possible implementation, if the current stage of the monitoring scenario is a walking segment, the cloud platform continuously receives safety monitoring data uploaded by the mobile terminal. This safety monitoring data is collected by the mobile terminal's built-in motion sensor, collecting information such as posture and acceleration. After being analyzed by the motion monitoring unit, the user's current movement state is identified as stationary. The cloud platform simultaneously times and counts the stationary state, continuously monitoring the duration of stationary stay. Simultaneously, it combines the location determination results output by the geofence determination unit to verify whether the mobile terminal's current coordinates are outside the pre-defined safe geofence area. When all three conditions are met simultaneously—the user's movement state is continuously stationary, the stationary duration exceeds the first preset time threshold set by the system, and the location is not within the safe geofence—the cloud platform can comprehensively determine that the preset abnormal triggering conditions are met. This effectively identifies dangerous situations such as prolonged lingering or unexpected stops during walking, achieving automatic identification of walking-related abnormalities.

[0098] If the current stage of the monitoring scenario is a walking segment, and the location data reported by the mobile terminal indicates that the mobile terminal's moving speed is greater than the preset speed threshold, or it has entered the area covered by the preset risk location database, then the preset abnormal triggering condition is determined to be met.

[0099] The preset speed threshold can be selected according to the actual situation.

[0100] In one possible implementation, assuming the monitored scenario is a walking segment, the cloud platform receives real-time time-series positioning data uploaded by the mobile terminal according to a fixed positioning sampling period. This positioning data includes the latitude and longitude coordinates of multiple consecutive time-adjacent points and their corresponding high-precision timestamps. The cloud platform calculates the user's real-time movement speed using a continuous multi-point positioning coordinate time difference calculation method. Specifically, the cloud platform extracts two sets of adjacent valid positioning point data, obtains the latitude and longitude coordinates and collection timestamps of the corresponding points, calculates the actual walking distance between the two adjacent positioning points using a spherical distance conversion algorithm, calculates the walking time using the time difference between the two sets of timestamps, and calculates the movement speed of a single sampling interval using the following formula (1).

[0101] Movement speed = Distance traveled ÷ Time interval Formula (1) Meanwhile, the cloud platform performs smoothing and filtering on multiple sets of continuously sampled movement speed data to filter out interference from single-point positioning drift and instantaneous speed jumps caused by signal fluctuations, outputting a stable real-time user movement speed. The cloud platform dynamically compares the final calculated real-time movement speed with the system's preset speed threshold, and simultaneously retrieves a preset risk location database stored locally on the cloud platform to perform real-time matching and retrieval of the mobile terminal's current location with the coordinate range of various high-risk areas and remote areas within the preset risk location database. As long as the mobile terminal's real-time movement speed exceeds the preset speed threshold, or the location falls within any area covered by the risk location database, the preset abnormal trigger condition is met, thus identifying abnormal behaviors such as speeding, entering dangerous areas, or entering unfamiliar high-risk areas during walking, achieving multi-dimensional screening of risks in walking scenarios.

[0102] If the duration of the heartbeat communication interruption between the mobile terminal and the cloud platform exceeds the second preset duration threshold, then the preset abnormal triggering condition is determined to be met.

[0103] The second preset duration threshold can be selected according to the actual situation.

[0104] In one possible implementation, a normalized heartbeat communication mechanism is established between the cloud platform and the mobile terminal. The mobile terminal sends heartbeat messages to the cloud platform at fixed intervals to maintain the online status of the link. The cloud platform continuously monitors the timing of the heartbeat message reception. If it does not receive the heartbeat data packet from the mobile terminal on time, it immediately starts an interruption timer and continuously counts the duration of communication disconnection. When the cumulative duration of communication interruption exceeds the second preset duration threshold of the system, it can directly determine that the preset abnormal triggering condition is met without other auxiliary conditions, so as to identify the working conditions such as mobile terminal shutdown, signal loss, and abnormal offline device in a timely manner, thus supplementing the abnormal judgment capability of the communication link abnormal dimension.

[0105] The security data access control method provided in this application sets different preset abnormal trigger conditions for different monitoring scenarios, enabling scenario-based and multi-dimensional abnormal identification. When the current monitoring scenario is the driving segment, if the security data reported by the vehicle terminal indicates that the vehicle is in motion, and the positional deviation between the location data reported by the mobile terminal and the vehicle location data continuously exceeds a preset distance threshold, it can be determined that the preset abnormal trigger condition is met, so as to promptly identify abnormal situations such as users leaving the vehicle without permission or separation between people and vehicles. When the current stage of the monitoring scenario is a walking segment, if the safety data reported by the mobile terminal shows that the user's movement status remains stationary for a duration exceeding a first preset time threshold, and the current location is outside the preset safety geofence, then the preset abnormal triggering conditions can be determined to be met, in order to identify abnormal situations such as the user lingering in unfamiliar and remote areas for an extended period of time. Similarly, in the walking segment monitoring scenario, if the location data reported by the mobile terminal detects that the mobile terminal's walking speed exceeds a preset speed threshold, or if the location point enters a dangerous area covered by a preset risk location database, then the preset abnormal triggering conditions can also be determined to be met, in order to quickly identify safety hazards such as abnormally rapid movement or accidental entry into risk areas. In addition, if the heartbeat communication interruption between the mobile terminal and the cloud platform lasts for a duration exceeding a second preset time threshold, then the preset abnormal triggering conditions can also be determined to be met, in order to promptly detect communication anomalies such as mobile terminal offline or signal loss. Therefore, this application uses a multi-scenario, multi-dimensional, and multi-rule parallel anomaly judgment logic to cover various safety risk scenarios such as separation of people and vehicles, staying in the wild, speeding and abnormal movement, entering risky areas by mistake, and communication loss, thereby improving the accuracy and completeness of travel anomaly identification and avoiding omissions and misjudgments caused by a single judgment rule.

[0106] To further explain the secure data access control method provided in this application, this application also provides an embodiment, which is as follows: Example 1: The travel monitoring and collaborative management system in this example mainly consists of a vehicle-mounted terminal, a mobile terminal, a cloud platform, and a family member terminal. The vehicle-mounted terminal is equipped with an intelligent vehicle system that supports DMS, ADAS functions, and CAN signal acquisition. The mobile terminal is a smartphone equipped with a positioning sensor and an acceleration sensor. The cloud platform deploys a state chain management server and a permission management server. The family member terminal is a smartphone owned by a family member. Data interaction between the devices is achieved through multi-dimensional communication methods. The vehicle-mounted terminal and the cloud platform use 4G / 5G combined with vehicle-to-everything (V2X) communication. The mobile terminal and the cloud platform transmit data via 4G / 5G. At the same time, the vehicle-mounted terminal and the mobile terminal establish a short-range connection via Bluetooth to facilitate the efficient transmission of switching commands.

[0107] Example 2: This example is adaptable to various travel scenarios, such as commuting after work and traveling to unfamiliar destinations. The following example illustrates a user's nighttime commute by car and then walking into their residential area: At 18:30, after the user starts the vehicle, the vehicle's DMS and ADAS units automatically start and run. The CAN signal acquisition unit collects vehicle data such as speed, throttle, and brakes in real time. The cloud platform continuously receives various driving data uploaded from the vehicle, generates an initial travel monitoring scenario, and marks the current travel stage as the driving segment. Simultaneously, the corresponding driving segment viewing permission is granted to family members. At 19:10, after the vehicle arrives at the parking lot outside the residential area, the user turns off the engine, engages the handbrake, and closes the doors. The vehicle's CAN signal acquisition unit detects that the vehicle status meets the preset parking conditions and automatically generates a stage switching command to switch from the driving segment to the parking segment. This command is then uploaded to the cloud platform via the vehicle network. After receiving and parsing the command, the cloud platform updates the current stage of the monitoring scenario to the parking segment and simultaneously sends a scene switching command to the user's mobile terminal via the 4G / 5G network. The mobile terminal automatically activates the walking safety mode, enabling location monitoring and accelerometer monitoring. During the user's walk, the mobile terminal's motion monitoring unit continuously collects real-time location data. At 19:15 on the same day, after detecting that the user has entered the preset geofence area of ​​the community, it sends a monitoring termination request to the cloud platform. After responding to the request, the cloud platform updates the current stage of the monitoring scenario for this trip to the destination segment, disables the full-link safety monitoring function, simultaneously revokes all viewing permissions on the family member's end, and encrypts and archives the complete travel monitoring data, including data from the driving segment, parking segment, and walking segment, to the platform's data archiving unit. At the same time, this embodiment has comprehensive abnormal monitoring capabilities. If the user remains stationary in a remote section of the road for more than a preset 2-minute threshold during the walk, the mobile terminal's motion monitoring unit can autonomously determine the travel abnormality, immediately trigger a local alarm, and simultaneously upload the abnormal information to the cloud platform. The cloud platform then pushes abnormal warning information, including the user's location and risk level, to the family member's end, realizing safety monitoring and abnormal control throughout the entire travel process.

[0108] Example 3: At the stage judgment and switching logic level, this example meticulously divides the judgment rules for the four major travel monitoring stages. Specifically, the driving stage abandons the single vehicle power-on judgment method and adopts a multi-dimensional signal cross-verification mechanism. It sets an engine speed greater than 0 RPM and a vehicle speed greater than 5 km / h for 10 seconds as a valid driving start condition, effectively filtering out non-driving scenarios such as the vehicle being powered on and stationary, or resting inside the vehicle. Simultaneously, the driving stage safety monitoring data is structured and uploaded to the cloud platform. This driving stage safety monitoring data includes at least: driver behavior data collected by the DMS, such as continuous eye-closing duration, yawning frequency, head deviation angle, mobile phone holding, and smoking; dynamic vehicle data from the ADAS and vehicle CAN outputs, such as lane departure warning, forward collision warning, rapid acceleration, sudden braking, and sharp turns; and basic vehicle status data such as vehicle speed, throttle opening, braking status, and turn signal signals. For parking sections, this embodiment adopts a multi-condition and logic combination judgment mechanism, which requires that the conditions of vehicle engine off or power system off, electronic parking brake engaged or P gear parking, and driver's door switching from open to closed be met simultaneously. It is also equipped with a 5-10 second delay confirmation to prevent false judgment. Parking is only determined to be effective when all parking conditions are continuously met within the time period, avoiding the problem of false switching in scenarios such as temporarily turning off the engine while waiting at a red light. At the same time, the Bluetooth signal strength attenuation detection of the vehicle system and mobile terminal is added as an auxiliary judgment basis to identify the user's real departure behavior. In determining the walking segment and destination segment, this embodiment adopts a low-power progressive monitoring strategy. After receiving the parking segment monitoring scene switching command from the cloud, the mobile terminal first wakes up low-power motion sensors such as accelerometers and gyroscopes to identify the user's walking movement mode. After confirming the walking status, the GPS / BeiDou high-precision positioning module is activated, effectively reducing terminal power consumption. The destination segment is determined by intelligent geofence to achieve scene switching. The system not only supports fixed safety fences with a default radius of 30m for homes, companies, etc., which can be customized and adjusted, but also allows setting temporary safety fences corresponding to the navigation destination through in-vehicle voice and mobile APP. When the mobile terminal detects that the user has entered any valid fence range and the movement state has remained still for more than 1 minute, it can determine that the destination monitoring stage has been entered.

[0109] Example 4: In terms of data and access control in the monitoring scenario, this example constructs a time-series, structured travel monitoring data system. It records the entire process of monitoring information using structured data sequences with unique travel identifiers. Each data record includes at least the following core fields: timestamp, travel stage, data source, event type, and detailed event data. It is also equipped with a dynamic access control mechanism to bind independent access tokens to each monitoring stage node. The cloud platform access control server can synchronously adjust the access permissions of the family member's terminal as the monitoring scenario stage is updated, so as to achieve a hierarchical privacy control effect where the family member's terminal can only view the current and subsequent monitoring data, and the historical data is automatically encrypted, de-identified, and hidden.

[0110] Example 5: Regarding the anomaly warning mechanism, this example establishes a multi-level, multi-scenario systematic anomaly judgment and multi-terminal collaborative response system, enriching the anomaly dimensions of various travel scenarios. The driving segment adds a new anomaly of human-vehicle trajectory deviation, which can identify risks such as significant deviations between the mobile terminal trajectory and the vehicle trajectory while the vehicle is in motion, and lost mobile phones. The walking segment covers multiple anomaly scenarios such as prolonged stillness in unsafe areas, abnormally high movement speed, entering high-risk POI areas, and terminal heartbeat disconnection, and adapts to day and night differentiated stillness timeout thresholds, with a default of 2 minutes during the day and 1 minute at night to meet different safety monitoring needs at different times. Simultaneously, a three-level warning mechanism is established: Level 1 low-risk warnings only retain cloud logs and are silently recorded without disturbing the user, for subsequent behavior analysis; Level 2 medium-risk warnings simultaneously push reminders to the user's terminal and family's terminal, reserving the user's ability to independently resolve the anomaly; Level 3 high-risk warnings trigger full-dimensional strong intervention, providing emergency reminders through a full-screen pop-up and continuous ringing on the family's terminal, while the cloud automatically collects auxiliary information such as user terminal recordings and environmental images, packaging them into a rescue information package to comprehensively ensure user travel safety. Furthermore, this embodiment establishes redundant communication links, using 4G / 5G as the primary communication channel and Bluetooth short-range communication between the vehicle-mounted system and the mobile terminal as a backup channel in signal blind spots such as underground parking garages. This temporarily caches switching commands and vehicle data, which are then synchronously uploaded to the cloud after network recovery, preventing missed recordings during monitoring scenario switching. Simultaneously, an intelligent degradation strategy is configured on the device side. In offline states, the mobile terminal can perform basic anomaly detection and local alarms based on local sensors. After network recovery, all monitoring data is synchronized. When the vehicle-mounted system detects life-threatening driving anomalies such as severe collisions, it can independently trigger the vehicle emergency call function, enabling independent emergency response without relying on the cloud-based warning link. For special scenarios involving separation of people and vehicles, the system adds a parking-stay sub-state. When the vehicle meets preset parking conditions but a living being remains inside, the pedestrian monitoring scenario switch is not triggered. Instead, the system continuously monitors the temperature and humidity inside the vehicle and sends a stay-at-home reminder to family members. Only after confirming that all occupants have left the vehicle does the normal pedestrian safety monitoring begin, covering various complex travel conditions.

[0111] Based on the same inventive concept, this application also provides a secure data access control device. Since the principle of the device in this application is similar to the secure data access control method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0112] Figure 4 This is a schematic diagram of a secure data access control device provided in an embodiment of this application. Figure 4 As shown, the secure data access control device 400, executed by a cloud platform, may include: The acquisition module 401 is used to acquire stage switching trigger events from the vehicle terminal or mobile terminal. The stage switching trigger events are generated based on the judgment of the travel process status. Update module 402 is used to update the current stage of the monitoring scenario for this trip in response to the stage switching trigger event; The control module 403 is used to control the family member's access rights to view safety data based on the current stage of the updated monitoring scenario; the safety data is data related to travel safety reported by the vehicle terminal and / or mobile terminal.

[0113] In one optional implementation, the control module 403 is specifically configured to: grant family members access to view driving safety data if the current stage is the driving stage; grant family members access to view walking safety data if the current stage is the walking stage; and deactivate all viewing access for family members if the current stage is updated to the destination stage.

[0114] In one optional implementation, the acquisition module 401 is specifically configured to: acquire a first-stage switching request generated by the vehicle terminal when it detects that the vehicle status meets preset parking conditions, the first-stage switching request being used to request an update of the current stage of the monitoring scenario; the preset parking conditions are conditions jointly determined based on multiple signals from the vehicle power system, parking brake status, and door status; and / or acquire safety data reported by the mobile terminal after pedestrian monitoring is enabled, the safety data being used to trigger an update of the current stage of the monitoring scenario to the walking segment; and / or acquire a second-stage switching request generated by the mobile terminal when it detects that it has reached the destination segment, the second-stage switching request being used to request an update of the current stage of the monitoring scenario to the destination segment; wherein, the stage switching triggering event includes at least: the first-stage switching request from the vehicle terminal, the safety data from the mobile terminal, and the second-stage switching request from the mobile terminal.

[0115] In one optional implementation, the security data access control device 400 is further configured to: start a timer when it is detected that the vehicle status meets the preset parking conditions; if the timer is greater than or equal to the preset duration and the vehicle status continues to meet the preset parking conditions, then determine that the vehicle status meets the preset parking conditions.

[0116] In one optional implementation, the update module 402 is specifically configured to: if the stage switching trigger event is a first stage switching request from the vehicle terminal, update the current stage of the monitoring scenario for this trip to the parking segment; if the stage switching trigger event is security data from the mobile terminal, update the current stage of the monitoring scenario for this trip to the walking segment; if the stage switching trigger event is a second stage switching request from the mobile terminal, update the current stage of the monitoring scenario for this trip to the destination segment.

[0117] In one optional implementation, the security data access control device 400 is further configured to: issue corresponding monitoring and control instructions to the vehicle terminal or mobile terminal based on the current stage of the updated monitoring scenario.

[0118] In one optional implementation, the security data access control device 400 is specifically used to: if the current stage of the updated monitoring scenario is a parking segment, send a monitoring control command to the mobile terminal associated with the vehicle terminal to trigger the mobile terminal to enable pedestrian monitoring; if the current stage of the updated monitoring scenario is a destination segment, send a monitoring control command to the vehicle terminal and / or the mobile terminal to disable the security monitoring function of the vehicle terminal and / or the mobile terminal.

[0119] In one optional implementation, the security data access control device 400 is specifically configured to: trigger the mobile terminal to perform the following operations upon receiving the monitoring control instruction: upon receiving the monitoring control instruction, activate the motion status monitoring function and identify whether the user is in walking motion mode based on the monitored data; upon identifying that the user is in walking motion mode, activate the positioning function to perform walking safety monitoring.

[0120] In one optional implementation, the acquisition module 401 is used to acquire the second-stage switching request generated by the mobile terminal when any of the following conditions are met: the mobile terminal detects that the user has entered the preset geofence range, or the mobile terminal receives an arrival confirmation instruction manually initiated by the user.

[0121] In an optional implementation, the security data access control device 400 is further configured to: determine that a preset abnormality triggering condition is met if the current stage of the monitored scenario is the driving stage, the security data reported by the vehicle terminal indicates that the vehicle is in a driving state, and the deviation between the positioning data reported by the mobile terminal and the vehicle's positioning data is continuously greater than a preset distance threshold; determine that a preset abnormality triggering condition is met if the current stage of the monitored scenario is the walking stage, the security data reported by the mobile terminal indicates that the movement state is stationary, and the duration of the stationary state is greater than a first preset duration threshold, and the current location of the mobile terminal is outside a preset security geofence; determine that a preset abnormality triggering condition is met if the current stage of the monitored scenario is the walking stage, the positioning data reported by the mobile terminal indicates that the mobile terminal's moving speed is greater than a preset speed threshold, or that it has entered an area covered by a preset risk location database; and determine that a preset abnormality triggering condition is met if the duration of the heartbeat communication interruption between the mobile terminal and the cloud platform is greater than a second preset duration threshold.

[0122] It should be noted that for details not disclosed in the security data access control device of this application embodiment, please refer to the details disclosed in the security data access control method of this application embodiment, which will not be repeated here.

[0123] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0124] Optionally, embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is run by a processor, the processor executes the steps of the security data access control method described in the above embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0125] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and other division methods may exist in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The integrated units described above can be implemented in hardware or in the form of hardware plus software functional units.

[0126] Optionally, this embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a secure data access control method provided in the above embodiment.

[0127] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0128] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0129] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and other division methods may exist in actual implementation. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0130] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A secure data access control method, characterized in that, Performed by a cloud platform, including: Acquire a stage switching trigger event from the vehicle terminal or mobile terminal, wherein the stage switching trigger event is an event generated based on the judgment of the travel process status; In response to the stage switching trigger event, update the current stage of the monitoring scenario for this trip; Based on the current stage of the updated monitoring scenario, control the family member's access permissions to view safety data; the safety data is data related to travel safety reported by the vehicle-mounted system and / or the mobile terminal.

2. The method according to claim 1, characterized in that, The control over family members' access to security data includes: If the current stage is the driving segment, grant the family member access to view the driving segment safety data. If the current stage is a walking segment, grant the family member access to view the walking segment safety data. If the current stage is updated to the destination segment, all viewing permissions are disabled for the family member's device.

3. The method according to claim 1, characterized in that, The acquisition of stage switching trigger events from the vehicle-mounted system or mobile terminal includes: The system obtains a first-stage switching request generated by the vehicle terminal when it detects that the vehicle status meets the preset parking conditions. The first-stage switching request is used to request an update of the current stage of the monitoring scenario. The preset parking conditions are conditions jointly determined based on multiple signals from the vehicle power system, parking brake status, and door status. And / or acquire safety data reported by the mobile terminal after pedestrian monitoring is enabled, the safety data being used to trigger the update of the current stage of the monitoring scenario to a pedestrian segment; And / or obtain a second stage switching request generated by the mobile terminal when it detects arrival at the destination segment, the second stage switching request being used to request that the current stage of the monitoring scenario be updated to the destination segment; The phase switching trigger event includes at least: the first phase switching request from the vehicle-mounted terminal, the security data from the mobile terminal, and the second phase switching request from the mobile terminal.

4. The method according to claim 3, characterized in that, The method further includes: When the vehicle status is detected to meet the preset parking conditions, a timer is started. If the timeout is greater than or equal to the preset duration, and the vehicle status continuously meets the preset parking conditions, then it is determined that the vehicle status meets the preset parking conditions.

5. The method according to claim 3, characterized in that, The response to the phase switching trigger event, updating the current phase of the monitoring scenario for this trip, includes: If the stage switching trigger event is the first stage switching request on the vehicle terminal, then the current stage of the monitoring scenario for this trip will be updated to the parking segment. If the stage switching trigger event is the security data of the mobile terminal, then the current stage of the monitoring scenario for this trip will be updated to the walking stage. If the stage switching trigger event is the second stage switching request of the mobile terminal, then the current stage of the monitoring scenario for this trip will be updated to the destination segment.

6. The method according to claim 1, characterized in that, The method further includes: Based on the current stage of the updated monitoring scenario, corresponding monitoring and control commands are sent to the vehicle-mounted system or the mobile terminal.

7. The method according to claim 6, characterized in that, Based on the current stage of the updated monitoring scenario, the corresponding monitoring control command is sent to the vehicle-mounted device or the mobile terminal, including: If the current stage of the updated monitoring scenario is a parking section, then the monitoring control command is sent to the mobile terminal associated with the vehicle terminal to trigger the mobile terminal to start pedestrian monitoring. If the current stage of the updated monitoring scenario is the destination segment, then the monitoring control command is sent to the vehicle terminal and / or the mobile terminal to disable the security monitoring function of the vehicle terminal and / or the mobile terminal.

8. The method according to claim 7, characterized in that, The triggering of the mobile terminal to enable pedestrian monitoring includes: The monitoring and control command is configured to trigger the mobile terminal to perform the following operations: Upon receiving the monitoring and control command, the motion status monitoring function is activated, and the user is identified as being in walking mode based on the monitored data. After recognizing that the user is in walking mode, the location function is activated to monitor walking safety.

9. The method according to claim 1, characterized in that, The method further includes: If the current stage of the monitoring scenario is the driving segment, the safety data reported by the vehicle terminal indicates that the vehicle is in a driving state, and the deviation between the positioning data reported by the mobile terminal and the positioning data of the vehicle is continuously greater than a preset distance threshold, then it is determined that the preset abnormal triggering condition is met. If the current stage of the monitoring scenario is a walking segment, the safety data reported by the mobile terminal indicates that the movement state is stationary, and the duration of the stationary state is greater than a first preset duration threshold, and the current location of the mobile terminal is outside a preset safety geofence, then the preset abnormal triggering condition is determined to be met. If the current stage of the monitoring scenario is a walking segment, and the location data reported by the mobile terminal indicates that the mobile terminal's moving speed is greater than a preset speed threshold, or it has entered an area covered by a preset risk location database, then the preset abnormal triggering condition is determined to be met. If the duration of the heartbeat communication interruption between the mobile terminal and the cloud platform exceeds the second preset duration threshold, then the preset abnormal triggering condition is determined to be met.

10. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform the method as described in any one of claims 1 to 9.

Images