Resource optimization-oriented vehicle end safety monitoring dynamic scheduling system
By optimizing vehicle-side safety monitoring through a dynamic scheduling system, the problem of high resource consumption has been solved, resource utilization has been improved, redundant data has been reduced, and communication bandwidth and storage costs have been saved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-30
- Publication Date
- 2026-03-13
AI Technical Summary
Existing vehicle-side safety monitoring systems consume a lot of resources and have high hardware costs. Most existing solutions use simple loops or fixed priority scheduling, resulting in low utilization of CPU and memory resources.
A vehicle-side safety monitoring dynamic scheduling system oriented towards resource optimization is adopted. Through the collaborative work of the input signal preprocessing module, dynamic time scheduling module, safety monitoring rule logic core module, and output and event trigger management module, the system dynamically schedules rule enable signals, executes safety monitoring rules only when necessary, and outputs structured data packets.
Resource optimization was achieved, redundant data uploads were reduced, communication bandwidth and cloud storage resources were saved, and the system's resource utilization and real-time performance were improved.
Smart Images
Figure CN121650673A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle-side safety monitoring technology, and in particular to a dynamic scheduling system for vehicle-side safety monitoring oriented towards resource optimization. Background Technology
[0002] With the development of intelligent driving functions, the number and complexity of vehicle-side safety monitoring rules have surged. The main problems with existing technical solutions in implementing these rules are: high resource consumption and high hardware costs. Existing solutions mostly use simple loops or fixed priority scheduling, and all rules run at high frequencies without distinction, resulting in low utilization of CPU and memory resources. In order to meet performance requirements, it is often necessary to choose hardware platforms with higher costs and higher computing power. Summary of the Invention
[0003] To address the aforementioned issues, this application provides a vehicle-side safety monitoring dynamic scheduling system oriented towards resource optimization, which can dynamically schedule rule enable signals, thereby saving CPU and memory resources.
[0004] According to one aspect of the embodiments of this application, a vehicle-side safety monitoring dynamic scheduling system oriented towards resource optimization is proposed, the system comprising: An input signal preprocessing module is used to receive raw message data from the vehicle bus and convert the raw message data into preprocessed data. A dynamic time scheduling module is used to dynamically schedule multiple rule enable signals based on the preprocessed data and the internal trigger state of the dynamic time scheduling module. A security monitoring rule logic core module, which includes multiple rule sub-modules, wherein the rule sub-modules are used to perform operations corresponding to the rule enable signal and output rule status signals; The output and event triggering management module is used to output structured data packets according to the rule status signal and send the structured data packets to the acquisition component at the vehicle end; When the rule submodule receives the rule enable signal, the rule submodule is activated to perform the operation corresponding to the rule enable signal.
[0005] In the above scheme, the input signal preprocessing module includes a CAN unpacking module and a unit conversion module; the CAN unpacking module is used to receive raw message data from the vehicle bus and parse it to obtain parsed data, and the unit conversion module is used to convert the unit of the parsed data into a preset standard unit.
[0006] In the above scheme, the input signal preprocessing module further includes a signal limiting check module and a filtering module. The signal limiting check module is used to verify the validity of the parsed data, and the filtering module is used to filter the valid parsed data to obtain the preprocessed data.
[0007] In the above scheme, the dynamic time scheduling module includes a time-triggered state and an event-triggered state. In the time-triggered state, the dynamic time scheduling module periodically enables high-priority rules according to a preset timing logic to generate rule enable signals for high-priority rules. In the event-triggered state, low-priority rules are activated to generate rule enable signals for low-priority rules.
[0008] In the above scheme, each rule submodule has an enable terminal, and the enable terminal of each rule submodule is connected to the dynamic time scheduling module.
[0009] In the above scheme, the dynamic time scheduling module is connected to the input signal preprocessing module.
[0010] In the above scheme, each rule submodule corresponds to a single security monitoring rule. The security monitoring rule is encapsulated in the system of the rule submodule, and the system of the rule submodule is used to implement the algorithm processing corresponding to the security monitoring rule.
[0011] In the above scheme, the output and event triggering management module includes a detection module, which is used to monitor the rule status signals output by each rule sub-module.
[0012] In the above scheme, the output and event triggering management module further includes a data packaging module, which is used to receive the rule status signal sent by the detection module and output the structured data packet according to the rule status signal.
[0013] In the above scheme, the rule submodule is in a dormant state when it is not activated, and the rule submodule does not perform any operation in the dormant state.
[0014] The beneficial effects of this application are as follows: This application utilizes the collaboration between four modules—an input signal preprocessing module, a dynamic time scheduling module, a security monitoring rule logic core module, and an output and event triggering management module—to dynamically schedule multiple rule enable signals. This allows the rule sub-modules to execute operations corresponding to the rule enable signals and output rule status signals. Clearly dividing the system into four independent yet collaborative modules—input preprocessing, dynamic scheduling, rule core, and output management—enables resource optimization and efficient development. Furthermore, this application's mechanism of outputting structured data packets based on the rule status signals, rather than the traditional periodic output, significantly reduces the uploading of redundant data, thereby saving communication bandwidth and cloud storage resources. Attached Figure Description
[0015] Figure 1 This is an architecture diagram of a vehicle-side safety monitoring and dynamic scheduling system for resource optimization provided in an embodiment of this application; Figure 2 This is a logical diagram of a vehicle-side safety monitoring and dynamic scheduling system for resource optimization provided in an embodiment of this application. Detailed Implementation
[0016] To enable those skilled in the art to better understand the solutions of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0017] It should be noted that while some processes described in the specification, claims, and accompanying drawings include multiple steps appearing in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not themselves represent any execution order. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. "Multiple" in this document refers to at least two.
[0018] It is worth noting that in the specific embodiments of this application, raw message data and other related data are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the target object is required, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, when an embodiment of this application needs to obtain raw message data and other related data, separate permission or consent from the target object can be obtained through pop-up windows or redirection to a confirmation page. After obtaining separate permission or consent from the target object, the necessary raw message data and other related data for enabling the embodiment of this application to operate normally can then be obtained.
[0019] The following provides a detailed description of the specific implementation methods of the embodiments of this application: Please see Figure 1 , Figure 1 This is an architecture diagram of a resource-optimized vehicle-side safety monitoring dynamic scheduling system provided in this application embodiment. The resource-optimized vehicle-side safety monitoring dynamic scheduling system provided in this application embodiment includes: An input signal preprocessing module is used to receive raw message data from the vehicle bus and convert the raw message data into preprocessed data. A dynamic time scheduling module is used to dynamically schedule multiple rule enable signals based on the preprocessed data and the internal trigger state of the dynamic time scheduling module. A security monitoring rule logic core module, which includes multiple rule sub-modules, wherein the rule sub-modules are used to perform operations corresponding to the rule enable signal and output rule status signals; The output and event triggering management module is used to output structured data packets according to the rule status signal and send the structured data packets to the acquisition component at the vehicle end; When the rule submodule receives the rule enable signal, the rule submodule is activated to perform the operation corresponding to the rule enable signal.
[0020] Specifically, this application utilizes the collaboration between four modules—an input signal preprocessing module, a dynamic time scheduling module, a security monitoring rule logic core module, and an output and event triggering management module—to dynamically schedule multiple rule enable signals. This allows the rule sub-modules to execute operations corresponding to the rule enable signals and output rule status signals. Clearly dividing the system into four independent yet collaborative modules—input preprocessing, dynamic scheduling, rule core, and output management—achieves resource optimization and efficient development. This application's mechanism of outputting structured data packets based on the rule status signals, rather than traditional periodic output, significantly reduces the uploading of redundant data, thereby saving communication bandwidth and cloud storage resources.
[0021] In some embodiments, the input signal preprocessing module includes a CAN unpacking module and a unit conversion module. The CAN unpacking module receives raw message data from the vehicle bus and parses it to obtain parsed data. The unit conversion module converts the units of the parsed data into preset standard units. The input signal preprocessing module also includes a signal limiting check module and a filtering module. The signal limiting check module verifies the validity of the parsed data, and the filtering module filters the valid parsed data to obtain the preprocessed data.
[0022] Here, as Figure 2 As shown, the input signal preprocessing module consists of multiple parallel Simulink functional blocks, including a CAN unpacking module, a unit conversion module (Gain / Product), a signal amplitude limiting check module (Interval Test), and a first-order low-pass filter module (Transfer Fcn). All input signals flow through the above processing chain sequentially. The CAN unpacking module receives the raw CAN messages from the vehicle bus and parses them into specific physical signal values (such as vehicle speed and acceleration). The unit conversion module converts the parsed signal values into international standard units (such as converting km / h to m / s), providing a unified data benchmark for subsequent rule calculations. The signal amplitude limiting check module verifies the validity of the signal; if the signal value exceeds a preset reasonable physical range (such as vehicle speed less than 0 or greater than 300 km / h), the signal is marked as invalid. The filtering module suppresses high-frequency noise in the signal, ensuring smooth and reliable input rule signals. Through the above processing, this module provides the system with clean, reliable, and uniformly formatted input data. This method directly avoids rule mis-triggers caused by signal anomalies and noise, improving the accuracy and robustness of the entire monitoring system.
[0023] In some embodiments, the dynamic time scheduling module internally includes a time-triggered state and an event-triggered state. In the time-triggered state, the dynamic time scheduling module periodically enables high-priority rules according to a preset timing logic to generate rule enable signals for high-priority rules. In the event-triggered state, low-priority rules are activated to generate rule enable signals for low-priority rules. Each rule submodule has an enable terminal, and the enable terminal of each rule submodule is connected to the dynamic time scheduling module.
[0024] Here, the dynamic time scheduling module (implemented by Stateflow) is a Stateflow state machine graph. Its inputs include the system clock signal, preprocessed external signals, and rule state feedback signals from the SMT module (rule submodule). Its outputs are multiple rule enable signals, each connected to a corresponding sub-rule in the SMT module. Hybrid scheduling strategy: The state machine (dynamic time scheduling module) contains multiple parallel states, such as time-triggered and event-triggered states. In time-triggered states, sequential logic periodically enables high-priority rules (such as ASIL-D level rules). In event-triggered states, transition conditions are used to event-driven activate low-priority rules. Priority management: The state machine can implement priority preemption logic. For example, when the condition of a high-priority rule is met, the Stateflow graph can interrupt the current execution flow and immediately transition to the state processing that high-priority task. This Stateflow scheduler, by implementing hybrid scheduling and priority management, directly achieves the technical effect of on-demand allocation of CPU computing resources, ensuring that critical rules are always executed in a timely manner, thereby greatly optimizing resource utilization and guaranteeing the real-time performance and determinism of the system.
[0025] Safety Monitoring Rule (SMT) Logic Core Module: This module consists of multiple rule sub-modules operating in parallel. Each rule sub-module represents an independent monitoring rule (e.g., SM001, where SM001 represents a specific safety monitoring rule). The enable port of each cabinet sub-module is connected to the output of the dynamic time scheduling module. Its input comes from the input signal preprocessing module, and its output is sent to the output and event trigger management module. Modular Encapsulation: Each safety monitoring rule is encapsulated in an independent system, internally implementing specific monitoring algorithms (such as calculating MTTC and comparing with safety boundaries). The rule sub-module only performs calculations within the current simulation step when its enable port is activated by the scheduling module; otherwise, it remains dormant, consuming no computing resources. This modular, enable-controlled architecture allows each safety monitoring rule to be developed, tested, and updated independently, directly resulting in a significant improvement in development and maintenance efficiency.
[0026] Output and Event Trigger Management Module: This module mainly consists of a rising edge detection module, a data packaging module, and an output port. Its input comes from the rule status signals of the SMT module. Rising Edge Detection: Continuously monitors the status output of each rule. Subsequent actions are triggered only when the status changes from 0 to 1 (i.e., a violation occurs). Data Packaging: Triggered upon event, it packages key information such as the rule ID, current timestamp, and rule return value into a structured data packet. Output: The data packet is sent to the downstream big data acquisition component through the output port. This event-triggered output mechanism ensures that data is uploaded only at the moment of the most effective violation. This technical feature directly results in a significant reduction in redundant data uploads, thereby saving communication bandwidth and cloud storage resources (corresponding beneficial effect: saving communication resources).
[0027] One specific embodiment of this application can be implemented in a Matlab / Simulink R2023b environment for deploying safety monitoring rules on a Common Controller for Intelligent Driving (CSC). The implementation process is as follows: Model building: Create a model in Simulink such as... Figure 2 The top-level model shown contains four modules. The dynamic time scheduling module uses Stateflow to create a state machine. This state machine contains two main parallel states: HighPriorityState: In this state, the after(10ms, tick) timing logic is used to periodically output the enable signal of high-priority rules (such as rule SM021 related to forward collision warning) every 10ms. LowPriorityState: In this state, the [change(signal)] condition detection is used to output the enable signal of low-priority rules (such as rules used for diagnosis) only when the change value of certain low-frequency signals exceeds the threshold.
[0028] The SMT rule core module implements the logic of the SM001 rule (calculating the MTTC and comparing it with the safety boundary) in a Simulink atomic subsystem. The enable port of this subsystem is connected to the SM001_Enable output signal of the aforementioned scheduling module. Parameter configuration and interface definition: In the Simulink data dictionary, explicitly define the names, data types (e.g., uint8, single), physical units, and ranges of all input and output signals. Configure the parameters of the scheduling module, such as the execution cycle (10ms) of high-priority rules and the trigger threshold of low-priority rules.
[0029] Create a Simulink Bus object for the data packets packaged in the output module, and explicitly define its structure, which includes elements such as Rule_ID (uint16), Timestamp (uint32), and Return_Value (single).
[0030] Simulation Testing and Code Generation: Simulink Test was used to write test cases, injecting simulated vehicle bus signals to perform Software-in-the-Loop (SIL) testing on the model, verifying the correctness of the scheduling strategy and the accuracy of the rule logic. After passing the tests, Embedded Coder was used, configuring code generation options for the target hardware to generate efficient and readable C code with a single click. In the generated code, the Stateflow scheduler was converted into efficient switch-case statements, and each rule submodule was generated modularly. In summary, this application, through the detailed technical solutions of the above four modules and their collaborative working relationship, fully achieves the purpose of the invention and directly produces the aforementioned beneficial effects.
[0031] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.
[0032] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0033] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.
[0034] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, 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 in actual implementation, there may be other division methods. 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 coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.
[0035] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.
[0036] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0037] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0038] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.
[0039] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
[0040] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.
Claims
1. A vehicle-side safety monitoring and dynamic scheduling system for resource optimization, characterized in that, The system includes: An input signal preprocessing module is used to receive raw message data from the vehicle bus and convert the raw message data into preprocessed data. A dynamic time scheduling module is used to dynamically schedule multiple rule enable signals based on the preprocessed data and the internal trigger state of the dynamic time scheduling module. A security monitoring rule logic core module, which includes multiple rule sub-modules, wherein the rule sub-modules are used to perform operations corresponding to the rule enable signal and output rule status signals; The output and event triggering management module is used to output structured data packets according to the rule status signal and send the structured data packets to the acquisition component at the vehicle end; When the rule submodule receives the rule enable signal, the rule submodule is activated to perform the operation corresponding to the rule enable signal.
2. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 1, characterized in that, The input signal preprocessing module includes a CAN unpacking module and a unit conversion module; the CAN unpacking module is used to receive raw message data from the vehicle bus and parse it to obtain parsed data, and the unit conversion module is used to convert the units of the parsed data into preset standard units.
3. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 2, characterized in that, The input signal preprocessing module further includes a signal limiting check module and a filtering module. The signal limiting check module is used to verify the validity of the parsed data, and the filtering module is used to filter the valid parsed data to obtain the preprocessed data.
4. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 1, characterized in that, The dynamic time scheduling module includes a time-triggered state and an event-triggered state. In the time-triggered state, the dynamic time scheduling module periodically enables high-priority rules according to a preset timing logic to generate rule enable signals for high-priority rules. In the event-triggered state, it activates low-priority rules to generate rule enable signals for low-priority rules.
5. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 1, characterized in that, Each rule submodule has an enable terminal, and the enable terminal of each rule submodule is connected to the dynamic time scheduling module.
6. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 5, characterized in that, The dynamic time scheduling module is connected to the input signal preprocessing module.
7. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 5, characterized in that, Each rule submodule corresponds to a single security monitoring rule, which is encapsulated within the system of the rule submodule. The system of the rule submodule is used to implement the algorithm processing corresponding to the security monitoring rule.
8. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 1, characterized in that, The output and event triggering management module includes a detection module, which is used to monitor the rule status signals output by each rule submodule.
9. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 8, characterized in that, The output and event triggering management module also includes a data packaging module, which is used to receive the rule status signal sent by the detection module and output the structured data packet according to the rule status signal.
10. The vehicle-side safety monitoring and dynamic scheduling system for resource optimization according to claim 1, characterized in that, The rule submodule is in a dormant state when it is not activated, and does not perform any operations in the dormant state.