SOVD dynamic diagnosis permission control method and system based on vehicle state perception

Abstract

The application discloses a SOVD dynamic diagnosis permission control method and system based on vehicle state sensing, which comprises the following steps: continuously collecting key vehicle dynamic state parameters in real time; when a diagnosis service request is received, if identity verification fails or there is no basic permission, a request is returned; if identity verification is successful, a dynamic permission rule library is matched based on the key vehicle dynamic state parameters, a decision result is obtained, if the decision result is rejection, a request is returned, if the decision result is permission, a set of steady state parameters corresponding to the diagnosis service request is obtained based on the diagnosis service request, if any parameter in the set of steady state parameters does not reach a steady state, a rejection response is returned, and if all the parameters in the set of steady state parameters have reached a steady state, a decision result is generated. The application can realize real-time sensing of the real-time state of a vehicle, dynamically adjust the permission according to the specific scene where the vehicle is located, prevent human errors or malicious attacks, and prevent dangerous diagnosis service requests from being accidentally executed.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic diagnostics technology, specifically to a SOVD dynamic diagnostic access control method and system based on vehicle state perception. Background Technology

[0002] In the field of automotive electronic diagnostics, with the widespread adoption of the SOVD (Service-Oriented Vehicle Diagnostics) standard, application scenarios such as remote diagnostics and on-demand function activation are becoming increasingly diverse. Diagnostic clients complete vehicle inspection and maintenance by calling diagnostic services on the vehicle side. During this process, access control for diagnostic services is a core mechanism for ensuring vehicle safety.

[0003] Currently, mainstream diagnostic access control solutions typically employ a static access binding model, which makes authorization decisions based on client identity. This model suffers from the following technical problems: 1. The disconnect between access permissions and vehicle operating status poses a significant security risk. In existing technologies, regardless of whether a vehicle is traveling at 100 km / h on a highway or stationary in a repair shop, the authorized diagnostic client has the same access permissions for critical services such as "steering control" and "braking control." This static binding mechanism fails to perceive the vehicle's real-time status, leading to the possibility that, during operation, human error or malicious attacks could cause dangerous diagnostic service requests to be executed unexpectedly, potentially resulting in serious safety incidents.

[0004] 2. Lack of scenario-based access control capabilities. Existing technologies cannot dynamically adjust permissions based on the specific scenario in which the vehicle is located. For example, all write operations that may affect driving safety should be prohibited when the vehicle is in motion, while such operations that have undergone security verification should be allowed in a maintenance scenario. Existing static authorization models cannot meet this scenario-based and differentiated permission management requirement.

[0005] 3. Security protection is limited in scope, leading to concentrated risks. Existing technologies only focus on who is operating the system, neglecting the environment in which it operates. Once client credentials are leaked or misused, attackers gain complete control over all authorized services, especially when the vehicle is in motion, with potentially disastrous consequences. This single-dimensional protection system has significant security weaknesses.

[0006] 4. Rigid security policy updates and long response cycles. When security policies need to be adjusted, traditional solutions usually require modifying the core code and reflashing the ECU firmware, involving complex OTA processes and lengthy verification cycles, making it impossible to quickly respond to newly discovered security threats. Summary of the Invention

[0007] To address the problems existing in the prior art, this invention provides a SOVD dynamic diagnostic permission control method and system based on vehicle state perception. It can perceive the real-time state of the vehicle, dynamically adjust permissions according to the specific scenario in which the vehicle is located, automatically adapt different safety strategies according to different operating scenarios of the vehicle, and take key safety status such as vehicle speed and gear position as the core factors for authorization decision-making. This fundamentally eliminates the possibility of performing dangerous diagnostic operations in high-risk states such as vehicle driving, and prevents human error or malicious attacks from causing dangerous diagnostic service requests to be executed unexpectedly.

[0008] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of this application.

[0009] According to a first aspect of this application, a SOVD dynamic diagnostic access control method based on vehicle state perception is provided, comprising: Step S1: Continuously collect key vehicle dynamic status parameters in real time; Step S2: When a diagnostic service request is received, if authentication fails or basic permissions are not available, return a rejection request; if authentication succeeds, proceed to step S3. Step S3: Based on the dynamic status parameters of key vehicles, match the dynamic permission rule base to obtain the decision result. If the decision result is rejection, return the rejection request. If the decision result is permission, proceed to step S4. Step S4: Obtain a set of steady-state parameters corresponding to the diagnostic service request based on the diagnostic service request. If any parameter in the set of steady-state parameters does not meet the steady-state determination condition, return a rejection response. If all the steady-state parameters in the set have met the steady-state determination condition and the duration has reached the steady-state confirmation duration, then generate a decision result.

[0010] In some embodiments of this application, based on the foregoing scheme, the key vehicle dynamic state parameters include vehicle speed signal, gear signal, geographical location, and vehicle mode. Step S1 includes: Vehicle speed signals are acquired based on wheel speed sensors or CAN bus; Gear position signal is obtained based on the transmission controller; Geographic location is obtained based on the GNSS module; Vehicle mode is obtained based on the domain controller state machine; Determine whether the vehicle speed signal, the gear signal, the geographical location, and the vehicle mode meet their respective safety conditions. If any key vehicle dynamic state parameter does not meet the corresponding safety condition, return a rejection request.

[0011] In some embodiments of this application, based on the foregoing scheme, step S2 includes: Parse the client identity token in the diagnostic service request and verify the legality of the client identity token, including querying the static permission database to see if the client identity token has been granted the basic permissions for requesting the service.

[0012] In some embodiments of this application, based on the foregoing scheme, the method for setting the dynamic permission rule base includes: The preset rules include a rule ID, a conditional expression corresponding to the rule ID, an action, and a weight factor. The action is to deny or allow, and the weight factor includes a security veto, temporary authorization, or default permission. The weight value of each weight factor is preset.

[0013] In some embodiments of this application, based on the foregoing scheme, step S3 includes: Step S31: If the dynamic permission rule base is empty, it is determined that execution is allowed, and proceed to step S4; Step S32: If the dynamic permission rule base is not empty, sort the matched rules from high to low according to their weight values; Step S33: If the highest weight value corresponds to one rule, extract the rule with the highest weight value as the decision result, and proceed to step S34 or step S35; if the highest weight value corresponds to multiple rules, and there is a rule with the action of rejection among the multiple rules, select the rule with the action of rejection as the decision result, and proceed to step S34; if there is no rule with the action of rejection among the multiple rules, proceed to step S35. Step S34: If the action in the ruling is rejection, return a rejection response directly; Step S35: If the action is allowed in the ruling result, proceed to step S4.

[0014] In some embodiments of this application, based on the foregoing scheme, step S4 includes: When the target steady-state parameter displayed by the key vehicle dynamic status parameters reaches the preset judgment condition, the target steady-state timer corresponding to the target steady-state parameter is controlled to start timing. If the count value of the target steady-state timer reaches the steady-state confirmation duration corresponding to the target steady-state parameter, it is determined that the target steady-state parameter has entered a steady state. The target steady-state parameter is the steady-state parameter in the set of steady-state parameters. If the target steady-state parameter changes during the timing process, the target steady-state timer is controlled to be reset to zero and the timing is restarted.

[0015] In some embodiments of this application, based on the foregoing scheme, the decision result includes allowing execution and denying execution, and step S4 further includes: If the decision result is to allow execution, the diagnostic service request is forwarded to the vehicle bus; If the decision result is to refuse execution, the issuance of the diagnostic service request will be terminated immediately.

[0016] According to a second aspect of this application, a SOVD dynamic diagnostic permission control system based on vehicle state perception is provided, comprising: The data acquisition module is used to continuously collect key vehicle dynamic status parameters in real time. The first judgment module is used to return a rejection request if authentication fails or basic permissions are not available when a diagnostic service request is received; if authentication is successful, it will jump to the second judgment module. The second judgment module is used to match the dynamic permission rule base based on the key vehicle dynamic status parameters to obtain the decision result. If the decision result is rejection, it returns a rejection request; if the decision result is permission, it jumps to the third judgment module. The third judgment module is used to obtain a set of steady-state parameters corresponding to the diagnostic service request based on the diagnostic service request. If any parameter in the set of steady-state parameters does not meet the steady-state judgment condition, a rejection response is returned. If all the steady-state parameters in the set have met the steady-state judgment condition and the duration has reached the steady-state confirmation duration, a decision result is generated.

[0017] According to a third aspect of this application, a computer-readable storage medium is provided that stores a computer program thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0018] According to a fourth aspect of this application, an electronic device is provided, comprising: One or more processors; A memory for storing executable instructions of the processor, which, when executed by the one or more processors, cause the one or more processors to implement the method described above.

[0019] The beneficial effects of this application are as follows: (1) The SOVD dynamic diagnostic permission control method and system based on vehicle state perception provided in this application breaks through the limitation of traditional diagnostic permission control relying solely on client identity (static factor). It incorporates key vehicle dynamic state parameters such as vehicle speed signal, gear signal, geographical location, and vehicle mode into the key dimensions of authorization decision, fundamentally changing the dimensions of authorization decision and achieving an architectural breakthrough from identity-based static authorization to identity- and environment-based dynamic authorization.

[0020] (2) The SOVD dynamic diagnostic permission control method and system based on vehicle state perception provided in this application designs a three-layer decoupled architecture of "state perception layer - policy decision layer - execution interception layer", which realizes a clear separation of vehicle state acquisition, permission logic judgment and instruction execution. This architecture improves the modularity, testability and maintainability of the system, which is the core architectural innovation that distinguishes this invention from the prior art.

[0021] (3) The SOVD dynamic diagnostic permission control method and system based on vehicle state perception provided in this application constructs a rule-based, configurable dynamic permission verification engine, and designs the rule base as an independently updatable module. The rule base is decoupled from the core execution logic, supporting remote upgrades of security policies via OTA technology, enabling the vehicle's security protection capabilities to continuously evolve. This mechanism solves the inherent problems of rigid security policy updates and long response cycles in traditional solutions.

[0022] (4) The SOVD dynamic diagnostic permission control method and system based on vehicle state awareness provided in this application binds a weight factor to each rule in the dynamic permission rule base and establishes a strict adjudication hierarchy of "safety veto right takes precedence over temporary authorization over default permission". When the real-time vehicle state simultaneously matches multiple rules and the rule actions conflict, the rules are ranked and adjudicated according to the weight factor, and the safety veto rule unconditionally overrides the permission rule. This mechanism eliminates the uncertainty of traditional rule engines relying on sequential execution or random selection when rules conflict, ensuring the absolute priority of driving safety.

[0023] (5) The SOVD dynamic diagnostic permission control method and system based on vehicle state perception provided in this application obtains the steady-state parameters to be confirmed based on the state change anti-shaking confirmation mechanism of the steady-state timer. When the steady-state parameter meets the judgment condition, the state is not immediately accepted, but the continuous duration of the steady-state parameter is verified to have reached the preset steady-state confirmation duration. Only when the duration is greater than or equal to the steady-state confirmation duration is it determined that the steady-state parameter has entered a steady state and the permission is granted accordingly. This mechanism effectively solves the problem of erroneous opening of the permission window period caused by the instantaneous satisfaction of the threshold condition of the signal during transient conditions such as rapid deceleration and gear shifting.

[0024] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this application. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and are intended to explain the invention, but do not constitute an undue limitation thereof. In the drawings: Figure 1This is a flowchart of a SOVD dynamic diagnostic permission control method based on vehicle state perception according to the present invention. Figure 2 This is a schematic diagram of a SOVD dynamic diagnostic permission control system based on vehicle state perception according to the present invention. Figure 3 This is a schematic diagram of an electronic device according to the present invention. Detailed Implementation

[0026] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0027] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0028] According to the first aspect of this application, Figure 1 As shown, this embodiment provides a SOVD dynamic diagnostic permission control method based on vehicle state perception, including: Step S1: Continuously collect key vehicle dynamic status parameters in real time.

[0029] In some embodiments of this example, the key vehicle dynamic state parameters include vehicle speed signal, gear signal, geographical location, and vehicle mode. Step S1 includes: Vehicle speed signals are acquired based on wheel speed sensors or CAN bus; Gear position signal is obtained based on the transmission controller; Geographic location is obtained based on the GNSS module; Vehicle mode is obtained based on the domain controller state machine; Determine whether the vehicle speed signal, the gear signal, the geographical location, and the vehicle mode meet their respective safety conditions. If any key vehicle dynamic state parameter does not meet the corresponding safety condition, return a rejection request.

[0030] In one specific embodiment, Table 1 shows a table of some key vehicle dynamic state parameters. The safety conditions corresponding to the vehicle speed signal are as follows: At that time, When writing is prohibited, a rejection request is returned. The safety condition corresponding to the gear position signal is that steering control requires P gear. Geographic location restrictions are enhanced in sensitive areas; these restrictions can be set as needed, and this embodiment does not impose any limitations on them. Vehicle mode maintenance mode restrictions are relaxed; these restrictions can be set as needed, and this embodiment does not impose any limitations on them.

[0031] Table 1. Dynamic Status Parameters of Some Key Vehicles

[0032] In this embodiment, vehicle modes include transportation mode, driving mode, maintenance mode, and charging mode. In driving mode, the vehicle starts and... Safety conditions related to prohibiting chassis writing, steering control, and ECU reset can be preset. In maintenance mode, safety conditions related to allowing chassis writing, steering control (requiring secondary authentication), activating maintenance mode commands, and exiting maintenance mode commands can be preset. In charging mode, safety conditions related to connecting to and disconnecting charging stations can be preset. In transportation mode, safety conditions related to activating and exiting transportation mode can be preset. This embodiment does not limit these conditions.

[0033] Thus, this embodiment uses key safety conditions such as vehicle speed signal, gear signal, geographical location, and vehicle mode as the core factors for authorization decisions, fundamentally eliminating the possibility of performing dangerous diagnostic operations under high-risk conditions such as vehicle driving.

[0034] Step S2: When a diagnostic service request is received, if authentication fails or basic permissions are not available, return a rejection request; if authentication is successful, proceed to step S3.

[0035] In some embodiments of this example, step S2 includes: Parse the client identity token in the diagnostic service request and verify the legality of the client identity token, including querying the static permission database to see if the client identity token has been granted the basic permissions for requesting the service.

[0036] In this embodiment, a client identity token is preset in the static permission library.

[0037] Step S3: Based on the dynamic status parameters of key vehicles, match the dynamic permission rule base to obtain the decision result. If the decision result is rejection, return the rejection request. If the decision result is permission, proceed to step S4.

[0038] In some embodiments of this example, the method for setting the dynamic permission rule base includes: Preset rules, which include a rule ID, a conditional expression corresponding to the rule ID, an action, and a weight factor; The weight value of each weight factor is preset.

[0039] In some embodiments, the action is denial or permission, and the weighting factor includes security veto, temporary authorization, or default permission. Table 2 shows a portion of the rules in the dynamic permission rule base.

[0040] Table 2. Partial Rule Tables of the Dynamic Permission Rule Base

[0041] In this embodiment, each rule in the dynamic permission rule base is bound to a weight factor, and the weight factor corresponds to a weight value. The security veto right involves prohibition rules related to driving safety and cannot be overridden by any other rule; the temporary authorization involves permission rules related to specific scenarios and can be overridden by the security veto right; the default permission allows basic authorization under normal circumstances and can be overridden by the above two types of rules.

[0042] Table 3 shows the correspondence between the weight values ​​of the weight factors.

[0043] Table 3. Weight Factor Weight Value Correspondence Table

[0044] Thus, this embodiment constructs a rule-based, configurable dynamic permission verification engine, and designs the dynamic permission rule base as an independently updatable module. The dynamic permission rule base is decoupled from the core execution logic, supporting remote upgrades of security policies via OTA (Over-The-Air) technology, enabling the vehicle's security protection capabilities to continuously evolve. This mechanism solves the inherent problems of rigid security policy updates and long response cycles in traditional solutions.

[0045] In this embodiment, the dynamic permission rule base is independently configurable and supports updates without modifying the core code logic. The dynamic permission rule base can be defined by the OEM (Original Equipment Manufacturer) during the vehicle development phase and can be remotely updated via OTA throughout the vehicle's lifecycle.

[0046] Specifically, the OEM R&D center uploads the new rule package to the OTA cloud platform, the OTA cloud platform distributes the new rule package to the vehicle T-Box, the vehicle T-Box transmits the new rule package to the SOVD server, and the SOVD server updates the rules in the dynamic permission rule base based on the new rule package.

[0047] In some embodiments of this example, step S3 includes: Step S31: If the dynamic permission rule base is empty, it is determined that execution is allowed, and proceed to step S4; Step S32: If the dynamic permission rule base is not empty, sort the matched rules from high to low according to their weight values; Step S33: If the highest weight value corresponds to one rule, extract the rule with the highest weight value as the decision result, and proceed to step S34 or step S35; if the highest weight value corresponds to multiple rules, and there is a rule with the action of rejection among the multiple rules, select the rule with the action of rejection as the decision result, and proceed to step S34; if there is no rule with the action of rejection among the multiple rules, proceed to step S35. Step S34: If the action in the ruling is rejection, return a rejection response directly; Step S35: If the action is allowed in the ruling result, proceed to step S4.

[0048] Step S4: For requests with an approved decision, perform a critical security state steady-state confirmation before release. Specifically, obtain a set of steady-state parameters corresponding to the diagnostic service request based on the diagnostic service request. If any parameter in the set of steady-state parameters does not meet the steady-state determination condition, return a rejection response. If all the steady-state parameters in the set have met the steady-state determination condition and the duration has reached the steady-state confirmation duration, then generate a decision result.

[0049] In some embodiments of this example, when the target steady-state parameter displayed by the key vehicle dynamic state parameters reaches a preset judgment condition, the target steady-state timer corresponding to the target steady-state parameter is controlled to start timing. If the count value of the target steady-state timer reaches the steady-state confirmation duration corresponding to the target steady-state parameter, it is determined that the target steady-state parameter has entered a steady state. The target steady-state parameter is a steady-state parameter in the set of steady-state parameters. If the target steady-state parameter changes during the timing process, the target steady-state timer is reset to zero and restarted. If the parameter value changes during the timing process, the timer is reset to zero and restarted. When a diagnostic service request involves the following diagnostic service categories, the steady-state state of the corresponding parameters needs to be checked. The diagnostic service requests include chassis control writing, powertrain calibration, airbag ECU reset, and steering system control.

[0050] In this embodiment, as shown in Tables 4 and 5, when the diagnostic service request is chassis control write, the corresponding steady-state parameters are vehicle speed signal and gear signal. The preset judgment condition for the vehicle speed signal is that it is continuously equal to 0 km / h, and the steady-state confirmation time is a first time threshold. The preset judgment condition for the gear signal is that it is continuously in P gear, and the steady-state confirmation time is a second time threshold. When the diagnostic service request is for powertrain calibration, the corresponding steady-state parameter is the vehicle mode. The preset judgment condition for the vehicle mode is that it is continuously in maintenance mode, and the steady-state confirmation time is the third time threshold. When the diagnostic service request is to reset the airbag ECU, the corresponding steady-state parameter is the vehicle speed signal. The preset judgment condition for the vehicle speed signal is that it is continuously equal to 0km / h, and the steady-state confirmation time is the first time threshold. When the diagnostic service request is for steering system control, the corresponding steady-state parameters are vehicle speed signal and gear signal. The preset judgment condition for the vehicle speed signal is that it is continuously equal to the vehicle speed threshold, and the steady-state confirmation time is the first time threshold. The preset judgment condition for the gear signal is that it is continuously in P gear, and the steady-state confirmation time is the second time threshold.

[0051] In this embodiment, the first duration threshold, the second duration threshold, and the third duration threshold are set as needed. This embodiment does not limit this setting. In one specific embodiment, the first duration threshold is 500ms, the second duration threshold is 200ms, and the third duration threshold is 100ms.

[0052] Table 4 Diagnostic Service Requests

[0053] Table 5 Steady-state parameter table

[0054] If all the required steady-state parameters have reached a steady state, the decision is passed, and a decision result is generated, as shown in Table 6. The decision result includes allowing execution and rejecting execution. If execution is allowed, the diagnostic service request is forwarded to the vehicle bus; if execution is rejected, the diagnostic service request is immediately terminated. If any steady-state parameter has not reached a steady state, a rejection response is returned with the reason code REJECT_REASON_STATE_NOT_STEADY.

[0055] Generate a decision result. Based on the above verification results, generate the final decision ("allow execution" or "deny execution") and pass it to the execution interception layer.

[0056] In some implementations of this embodiment, the execution interception layer is responsible for executing the decision result.

[0057] Table 6 Diagnostic Service Requests

[0058] When the decision is to deny, the system returns a clear error code (VehicleStateNotSafe) to the client, along with specific rule information that was triggered (condition: vehicle_speed>5km / h). Simultaneously, this denial event is logged as a critical safety event for subsequent tracing and analysis.

[0059] According to the second aspect of this application, such as Figure 2As shown in the figure, this embodiment provides a SOVD dynamic diagnostic permission control system based on vehicle state perception, including: The data acquisition module is used to continuously collect key vehicle dynamic status parameters in real time. The first judgment module is used to return a rejection request if authentication fails or basic permissions are not available when a diagnostic service request is received; if authentication is successful, it will jump to the second judgment module. The second judgment module is used to match the dynamic permission rule base based on the key vehicle dynamic status parameters to obtain the decision result. If the decision result is rejection, it returns a rejection request; if the decision result is permission, it jumps to the third judgment module. The third judgment module is used to obtain a set of steady-state parameters corresponding to the diagnostic service request based on the diagnostic service request. If any parameter in the set of steady-state parameters does not meet the steady-state judgment condition, a rejection response is returned. If all the steady-state parameters in the set have met the steady-state judgment condition and the duration has reached the steady-state confirmation duration, a decision result is generated.

[0060] Specifically, this embodiment corresponds one-to-one with the above method embodiments. The functions of each module have been described in detail in the corresponding method embodiments, so they will not be repeated here.

[0061] According to a third aspect of this application, this embodiment provides a computer-readable storage medium having a computer program stored thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0062] The present invention can implement all or part of the processes in the above methods, or it can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or system capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0063] According to the fourth aspect of this application, such as Figure 3As shown, an electronic device is provided, comprising: One or more processors; Memory is used to store executable instructions for the processor, which, when executed by one or more processors, cause one or more processors to implement the methods described above.

[0064] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0065] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of a computer system, connecting all parts of the computer system through various interfaces and lines.

[0066] Memory can be used to store computer programs and / or modules. The processor implements various functions of the computer system by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system and at least one application program required for a function (e.g., sound playback, image playback, etc.); the data storage area can store data created based on the use of the mobile phone (e.g., audio data, video data, etc.). Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, SmartMedia Cards (SMC), Secure Digital (SD) cards, Flash Cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0067] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, servers, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and memory) containing computer-usable program code.

[0068] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), servers, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0069] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0070] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0071] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0072] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0073] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A SOVD dynamic diagnosis permission control method based on vehicle state awareness, characterized in that, include: Step S1: Continuously collect key vehicle dynamic status parameters in real time; Step S2: When a diagnostic service request is received, if authentication fails or basic permissions are not available, return a rejection request; if authentication succeeds, proceed to step S3. Step S3: Based on the dynamic status parameters of key vehicles, match the dynamic permission rule base to obtain the decision result. If the decision result is rejection, return the rejection request. If the decision result is permission, proceed to step S4. Step S4: Obtain a set of steady-state parameters corresponding to the diagnostic service request based on the diagnostic service request. If any parameter in the set of steady-state parameters does not meet the steady-state determination condition, return a rejection response. If all the steady-state parameters in the set have met the steady-state determination condition and the duration has reached the steady-state confirmation duration, then generate a decision result.

2. The method of claim 1, wherein, The key vehicle dynamic status parameters include vehicle speed signal, gear signal, geographical location, and vehicle mode. Step S1 includes: Vehicle speed signals are acquired based on wheel speed sensors or CAN bus; Gear position signal is obtained based on the transmission controller; Geographic location is obtained based on the GNSS module; Vehicle mode is obtained based on the domain controller state machine; Determine whether the vehicle speed signal, the gear signal, the geographical location, and the vehicle mode meet their respective safety conditions. If any key vehicle dynamic state parameter does not meet the corresponding safety condition, return a rejection request.

3. The method according to claim 1, characterized in that, Step S2 includes: Parse the client identity token in the diagnostic service request and verify the legality of the client identity token, including querying the static permission database to see if the client identity token has been granted the basic permissions for requesting the service.

4. The method according to claim 1, characterized in that, The method for setting up the dynamic permission rule base includes: The preset rules include a rule ID, a conditional expression corresponding to the rule ID, an action, and a weight factor. The action is to deny or allow, and the weight factor includes a security veto, temporary authorization, or default permission. The weight value of each weight factor is preset.

5. The method according to claim 4, characterized in that, Step S3 includes: Step S31: If the dynamic permission rule base is empty, it is determined that execution is allowed, and proceed to step S4; Step S32: If the dynamic permission rule base is not empty, sort the matched rules from high to low according to their weight values; Step S33: If the highest weight value corresponds to one rule, extract the rule with the highest weight value as the decision result, and proceed to step S34 or step S35; if the highest weight value corresponds to multiple rules, and there is a rule with the action of rejection among the multiple rules, select the rule with the action of rejection as the decision result, and proceed to step S34; if there is no rule with the action of rejection among the multiple rules, proceed to step S35. Step S34: If the action in the ruling is rejection, return a rejection response directly; Step S35: If the action is allowed in the ruling result, proceed to step S4.

6. The method according to claim 1, characterized in that, Step S4 includes: When the target steady-state parameter displayed by the key vehicle dynamic status parameters reaches the preset judgment condition, the target steady-state timer corresponding to the target steady-state parameter is controlled to start timing. If the count value of the target steady-state timer reaches the steady-state confirmation duration corresponding to the target steady-state parameter, it is determined that the target steady-state parameter has entered a steady state. The target steady-state parameter is the steady-state parameter in the set of steady-state parameters. If the target steady-state parameter changes during the timing process, the target steady-state timer is controlled to be reset to zero and the timing is restarted.

7. The method according to claim 1, characterized in that, The decision result includes allowing execution and rejecting execution, and step S4 further includes: If the decision result is to allow execution, the diagnostic service request is forwarded to the vehicle bus; If the decision result is to refuse execution, the issuance of the diagnostic service request will be terminated immediately.

8. A SOVD dynamic diagnostic permission control system based on vehicle state perception, characterized in that, include: The data acquisition module is used to continuously collect key vehicle dynamic status parameters in real time. The first judgment module is used to return a rejection request if authentication fails or basic permissions are not available when a diagnostic service request is received; if authentication is successful, it will jump to the second judgment module. The second judgment module is used to match the dynamic permission rule base based on the key vehicle dynamic status parameters to obtain the decision result. If the decision result is rejection, it returns a rejection request; if the decision result is permission, it jumps to the third judgment module. The third judgment module is used to obtain a set of steady-state parameters corresponding to the diagnostic service request based on the diagnostic service request. If any parameter in the set of steady-state parameters does not meet the steady-state judgment condition, a rejection response is returned. If all the steady-state parameters in the set have met the steady-state judgment condition and the duration has reached the steady-state confirmation duration, a decision result is generated.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program includes executable instructions that, when executed by a processor, implement the method of any one of claims 1-7.

10. An electronic device, characterized in that, include: One or more processors; A memory for storing executable instructions of the processor, which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-7.

Images