A vehicle end rule engine implementation method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a vehicle-side rule engine implementation method and device, electronic equipment and storage medium. The vehicle-side rule engine implementation method comprises: synchronizing rule information configured by a cloud side, and updating local rule information based on the rule information configured by the cloud side; listening to and acquiring a vehicle state in real time based on an SOA architecture; determining whether the vehicle state meets the local rule information; if yes, a pre-defined scene state is reached, and a determination event of the rule engine is output to an external. The technical solution of the embodiments of the present application can convert a state signal of a vehicle into a scene event concerned by a user according to a demand scene concerned by the user.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicle technology, specifically to a method and device for implementing a vehicle-side rules engine, electronic equipment, and storage medium. Background Technology

[0002] As automobiles gradually evolve towards intelligence and electrification, the amount of data involved in vehicles is growing exponentially. How to process and display this data in real time, and provide users with feedback on the vehicle's status, has become an increasingly pressing issue for the industry. Vehicle data includes vehicle status information, vehicle event information, environmental information, and user status information. The acquisition, processing, identification, and transmission of this data are among the main research areas for future automotive intelligence. SOA, or Service-Oriented Architecture, is a software design philosophy and the foundation for future "software-defined vehicles." In SOA, services are the abstraction of the entire system and its most basic unit. Each domain service-oriented architecture provides a unified interface for third-party use, offering its capabilities as services.

[0003] Chinese patent document CN113886385A discloses a technology entitled "New Energy Vehicle Insurance Label Recognition Method and Device Based on Rule Engine." This rule engine takes vehicle announcement model data and power type data as input and outputs whether it is a new energy vehicle label. However, this technology has a narrow application scope; it cannot process the large number of vehicle signals from current intelligent vehicles, nor can it be applied to areas where user-related events need to be identified based on vehicle status.

[0004] Chinese patent document CN114495057A discloses a technology entitled "Data Acquisition Method, Electronic Device, and Storage Medium." This technology generates data acquisition tasks based on user-inputted data acquisition requirements, configures data acquisition rules and actions, and when a data acquisition rule belongs to a vehicle-side rule engine, sends the data acquisition task to the target terminal device. When the vehicle-side rule engine determines that the triggering conditions of the data acquisition rule are met, it executes the data acquisition action to collect the target data. This technology only proposes a logical method for data acquisition using a vehicle-side rule engine; it does not elaborate on the specific design method of the vehicle-side rule engine, nor does it elaborate on the method of acquiring or monitoring vehicle signals. It cannot set or determine rules for a predefined scenario.

[0005] The existing vehicle-side rule engine has the following problems:

[0006] First, there are few application cases and technical solutions for rule engines deployed on the vehicle side. Most rule engines are applied in other fields or industries, or deployed on non-vehicle platforms.

[0007] Second, existing patents provide little description of vehicle-side rule engines. Most of them simply use them as internal modules of specific application systems without elaborating on their specific design methods and implementation.

[0008] Third, the existing vehicle-side rule engine does not address the user's needs and scenarios by transforming the vehicle's own status signals into scenario events that the user is concerned with. Summary of the Invention

[0009] To address the aforementioned technical issues, embodiments of this application provide a method and apparatus for implementing a vehicle-side rules engine, an electronic device, and a storage medium, thereby enabling the conversion of the vehicle's own state signals into scenario events of interest to the user, tailored to specific user needs.

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

[0011] According to one aspect of the embodiments of this application, a method for implementing a vehicle-side rule engine is provided, comprising: synchronizing rule information configured in the cloud and updating local rule information based on the rule information configured in the cloud; monitoring and acquiring vehicle status in real time based on SOA architecture; determining whether the vehicle status satisfies the local rule information; if satisfied, that is, reaching a predefined scenario state, and outputting the judgment event of the rule engine to the outside.

[0012] In the technical solution provided in the embodiments of this application, synchronizing the rule information configured in the cloud and updating the local rule information based on the rule information configured in the cloud includes:

[0013] Obtain the rule information configured in the cloud;

[0014] The local rule information is updated based on the rule information configured in the cloud.

[0015] Parse the updated rule information into memory;

[0016] Based on the different triggering conditions of the updated rule information, the event signals for registering or deregistering listening, and the service status call signals for registering or deregistering.

[0017] The technical solution provided in the embodiments of this application includes real-time monitoring and acquisition of vehicle status based on SOA architecture, including:

[0018] Listen for event-type signals or poll for status-type signals;

[0019] Determine whether the event-type signal or state-type signal needs smoothing processing. If so, use methods such as calculating the average value / moving average value / multi-point sampling for processing.

[0020] Record the event-type signals or status-type signals after the cache smoothing process.

[0021] In the technical solutions provided by the embodiments of this application, listening to event-type signals includes: when the event-type signal changes, recording the signal value through a registered callback function.

[0022] In the technical solution provided by the embodiments of this application, polling status signals includes: using a thread pool to poll the status signals, wherein the thread pool has an upper limit on the number of threads; the thread pool records the thread information of the blocking signal, opens a corresponding number of new threads to obtain the status signal, and destroys the new threads after the blocking thread is released.

[0023] In the technical solution provided by the embodiments of this application, determining whether the vehicle state satisfies the local rule information, and if so, reaching a predefined scene state, and outputting the judgment event of the rule engine to the outside, includes:

[0024] When a signal changes, the relevant rules are iterated according to the signal type to determine whether the rule is satisfied. If it is satisfied, the event to which the rule belongs is queried.

[0025] Iterate through the events to be decided and determine whether there are any other rules for the events;

[0026] If so, then query the remaining rule signal values;

[0027] If all other rules match successfully, then perform event debouncing judgment;

[0028] If the event debouncing conditions are met, the event code corresponding to the rule is sent to the outside.

[0029] In the technical solution provided by the embodiments of this application, determining whether the vehicle state satisfies the local rule information, and if so, reaching a predefined scene state, and outputting the judgment event of the rule engine to the outside, further includes:

[0030] Sort the timing rules in ascending order and obtain the current system time;

[0031] Iterate through the time rules and set timers based on the time difference between the system time and the time rules;

[0032] After the timer is woken up, query the events corresponding to the time rules;

[0033] Iterate through the events to be decided and determine whether there are any other rules for the events;

[0034] Query other rule signal values;

[0035] If all other rules match successfully, then perform event debouncing judgment;

[0036] If the event debouncing conditions are met, the event code corresponding to the rule is sent to the outside.

[0037] In the technical solution provided by the embodiments of this application, the rule information includes triggering rules, arbitration conditions, and event information. The rule information includes fields such as ruleType, name, signalCode, opera, constValue, needSmooth, Arbitration, ArbitrationValue, and EventCode. Among them, six fields constitute the triggering rule. The ruleType of the triggering rule indicates the triggering rule type, name indicates the triggering rule interpretation, signalCode indicates the signal type, opera indicates the comparison type, constValue indicates the comparison value, and needSmooth indicates whether the acquired signal needs to be smoothed. The Arbitration of the arbitration condition indicates the anti-jitter type, ArbitrationValue indicates the anti-jitter value, and EventCode indicates the event information.

[0038] According to one aspect of the embodiments of this application, a vehicle-side rule engine implementation apparatus is provided, comprising:

[0039] The rule distribution module is used to synchronize the rule information configured in the cloud and update the local rule information based on the rule information configured in the cloud.

[0040] The state machine module is used to monitor and acquire vehicle status in real time based on the SOA architecture;

[0041] The event arbitration module is used to determine whether the vehicle state meets the local rule information. If it does, the predefined scene state is reached, and the judgment event of the rule engine is output to the outside.

[0042] According to one aspect of the embodiments of this application, an electronic device is provided, comprising:

[0043] One or more processors;

[0044] A storage device for storing one or more programs, which, when executed by one or more processors, enable the electronic device to implement the vehicle-side rule engine implementation method described above.

[0045] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to execute the above-described vehicle-side rule engine implementation method.

[0046] According to one aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described vehicle-side rule engine implementation method.

[0047] Among the technical solutions provided in some embodiments of this application, a method for implementing a rule engine deployed on a vehicle-side platform is proposed. This method is specifically designed to address the resource limitations of the vehicle-side platform, reducing platform resource consumption while ensuring real-time performance as much as possible. Based on a Service-Oriented Architecture (SOA), a state machine mechanism is proposed to be established on the vehicle side, enabling real-time and effective monitoring of vehicle status based on the service capabilities integrated and abstracted from the vehicle side. The proposed vehicle-side rule engine can selectively monitor and obtain vehicle status based on the rule base information provided by the cloud. The rule base is configurable in the cloud, and the vehicle-side monitoring signals can be dynamically added or removed, avoiding the performance overhead caused by full monitoring of all vehicle-side signals. The proposed vehicle-side rule engine can process time-related signals in the rule base, combining vehicle signals with time signals for monitoring and judgment. The proposed vehicle-side rule engine can collaborate with external modules, such as scene orchestration and data collection, acting as a trigger to execute corresponding functions of external modules, effectively solving the problems of vehicle status recognition and user-focused event recognition.

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

[0049] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0050] Figure 1 This is an exemplary embodiment of the present application illustrating the logic diagram of the vehicle-side rules engine;

[0051] Figure 2 This is an exemplary embodiment of the present application illustrating the overall flowchart of the vehicle-side rules engine;

[0052] Figure 3 This is a flowchart illustrating a rule distribution module as shown in an exemplary embodiment of this application;

[0053] Figure 4 This is a flowchart illustrating a state machine module in an exemplary embodiment of this application;

[0054] Figure 5This is a flowchart illustrating an exemplary embodiment of the event arbitration module of this application;

[0055] Figure 6 This is a schematic diagram illustrating the rule information structure as shown in an exemplary embodiment of this application. Detailed Implementation

[0056] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0057] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0058] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0059] First, it's important to clarify that SOA (Service-Oriented Architecture) is a methodology for designing, developing, deploying, and managing discrete models within a computing environment. SOA is not a new concept; it arose from the context of redundant and inefficient IT system development within enterprises. In the SOA model, all functionalities are defined as independent services, and all services are connected through a Service Bus (ESB) or process manager. This loosely coupled structure allows for the integration of various existing heterogeneous systems with minimal cost. However, because it requires adaptation to these heterogeneous systems (typically using an ESB to handle protocol and data format conversions between different systems), it inherently introduces more complexity.

[0060] SOA design principles include: Clear interface definition: Interfaces must meet requirements such as stability, clarity, and encapsulation. Self-containment and modularity: The functional entities implementing services are completely independent, capable of independent deployment, version control, self-management, and recovery. Coarse-grained: The number of services should not be too large, relying on message interaction rather than remote procedure calls. Loose coupling: Reducing interdependencies and influences between services; the location, implementation technology, current state, and private data of each service are invisible to service requesters. Interoperability, compatibility, and policy declaration. As an architectural design concept and philosophy, SOA requires specific technologies and methods for implementation. Currently, mainstream SOA implementation methods include: Web Services, service registries, and enterprise service buses.

[0061] Rule Engine: When developing complex business logic, the program's logic code and business logic code are often nested and intricate, resulting in high maintenance costs and poor scalability. A rule engine is a component that reduces the complexity of complex business logic components and lowers the maintenance and scalability costs of applications! Essentially, a rule engine is a reasoning engine that matches facts (input data) with rules to derive a conclusion.

[0062] Thread pools offer several advantages: reduced system resource consumption by reusing existing threads, minimizing the overhead of thread creation and destruction; improved system responsiveness, allowing tasks to be executed immediately without waiting for new threads; and easier management of thread concurrency. Unrestricted thread creation not only consumes significant system resources but can also lead to system blockages or memory shortages, reducing system stability. Thread pools effectively manage threads, providing unified allocation and optimization to improve resource utilization. Furthermore, they offer more powerful features such as timed, periodic, and controllable thread count functionality, making them easy and simple to use.

[0063] In this embodiment, the rule engine is deployed on the vehicle platform. Taking into full account the limitations of vehicle performance resources, its design concept and implementation method are described in detail. Furthermore, for the needs and scenarios that users are concerned about, the vehicle rule engine can collaborate with external third-party modules, such as vehicle scenario orchestration applications and data collection applications. When the rule engine detects that the vehicle meets a certain state preset by the user or a data collection rule, it can trigger the corresponding service orchestration scenario or data collection scenario.

[0064] The vehicle-side rule engine parses the rule information configured in the cloud on the vehicle side, listens for and obtains the vehicle status in real time based on the SOA architecture, and forms a vehicle state machine mechanism on the vehicle side to determine in real time whether the current vehicle status meets the pre-configured rule information. If it does, it means that the predefined scenario state has been reached, and the rule engine outputs the judgment event to the outside.

[0065] This embodiment mainly includes three modules: rule distribution module, state machine module, and event arbitration module.

[0066] Rule distribution module: Responsible for synchronizing rule information configured in the cloud to the vehicle. This module includes rule storage and rule update functions. Rule storage refers to storing and parsing rule information on the vehicle side. Numerous rules constitute a rule library, supporting CRUD operations. Rule updates refer to retrieving rule information from the cloud to the vehicle side, and implementing proactive or reactive updates when cloud rules change.

[0067] State Machine Module: Responsible for listening to and acquiring vehicle status signals, acting as the vehicle-side state machine to record the vehicle's status in real time. This module categorizes vehicle signals into event-type signals and status-type signals. Based on an SOA architecture, this module acquires vehicle signals through external services, processes the signals accordingly, and stores them in the state machine, serving as the basis for matching with rule information.

[0068] Event Arbitration Module: Responsible for determining whether rule information is satisfied; if so, it outputs event information. This module includes signal judgment, event decision-making, and event debouncing functions. Signal judgment refers to determining whether the corresponding signal rules match the acquired vehicle signals. Event decision-making refers to determining whether all signal rules corresponding to an event match. Event debouncing addresses the characteristics of vehicle signals—large data volume and rapid signal changes—by filtering and smoothing events triggered multiple times within a short period to prevent event storms.

[0069] A vehicle-side rule engine acquires and monitors vehicle signals and data, identifies and judges whether they match rule information in a rule base based on predefined rules, and outputs the matching information. The rule engine solves the problem of complex and cumbersome vehicle-side data making it impossible to process data concretely for specific scenarios. It can integrate and abstract information relevant to a specific scenario into a specific output, allowing for a more concrete perception of the vehicle's specific state and real-time monitoring of any abnormal vehicle conditions.

[0070] The technical solutions of this application involve technologies such as SOA, and are specifically illustrated through the following embodiments:

[0071] Figure 1 This is an exemplary embodiment of the present application illustrating the logic diagram of the vehicle-side rules engine.

[0072] Figure 2 This is an exemplary embodiment of the present application illustrating the overall flowchart of the vehicle-side rules engine.

[0073] Reference Figure 1 and Figure 2 As shown, this embodiment provides a method for implementing a vehicle-side rule engine, including: synchronizing rule information configured in the cloud and updating local rule information based on the rule information configured in the cloud; real-time monitoring and acquisition of vehicle status based on SOA architecture; determining whether the vehicle status meets the local rule information; if it does, a predefined scenario state is reached, and the judgment event of the rule engine is output to the outside. Specifically: S201, synchronizing the cloud rule information database, updating the local database, and registering / unregistering monitoring signals; S202, monitoring and acquiring vehicle signals, and smoothing the signals; S203, judging rule matching information and performing event arbitration judgment; S204, sending event codes to external modules. In this embodiment, firstly, the vehicle-side rule engine synchronizes the rule base information configured in the cloud, updating the local rule base file and the parsed rule base information in memory. Then, based on the updated rule base information, it registers or deregisters the corresponding vehicle signals being monitored. The state machine categorizes the registered signals into event signals and state signals. Event signals are obtained through external callbacks, while state signals are obtained through polling. For each obtained signal, it is determined whether smoothing is required before caching it in the state machine. When the vehicle signal in the state machine changes, the rule matching information is judged. When all triggering rules corresponding to a certain rule are successfully matched, the event is arbitrated. If the arbitration is successful, the event code is sent externally.

[0074] Figure 3 This is a flowchart illustrating a rule distribution module as shown in an exemplary embodiment of this application.

[0075] Reference Figure 3As shown, the module synchronizes the rule information configured in the cloud and updates the local rule information based on the cloud-configured rule information. This includes: obtaining the cloud-configured rule information; updating the local rule information based on the cloud-configured rule information; parsing the updated rule information into memory; and registering or deregistering listening event signals and service status call signals according to the signal types of different trigger conditions of the updated rule information. Specifically: S301, system startup; S302, cloud rule update; S303, obtaining cloud rule base information; S304, updating (adding, deleting, modifying) the local file rule base; S305, parsing the local file rule base and modifying the parsed information in memory; S306, registering / deregistering event listeners or registering / deregistering service status calls according to the signal types of different trigger conditions. This module is responsible for completing the rule storage and rule update functions. Rule storage includes rule base file storage and storage of rule base parsed into memory information, which involves adding, deleting, modifying, and querying rule bases in specific operations. Rule updates ensure consistency between the vehicle-side rule base and the cloud-based rule base. This includes two update methods: the vehicle actively requests an update to the rule base (vehicle-side proactive update) and the cloud proactively sends an updated rule base to the vehicle (vehicle-side passive update).

[0076] When the vehicle-side rule engine starts, the vehicle actively updates its local rule base; when the cloud-based rule base changes, the vehicle passively updates its local rule base. After obtaining the cloud-based rule base information, the vehicle updates its local file-based rule base information and then parses the updated rule information into memory.

[0077] The vehicle-side rule engine proposed in this embodiment is implemented based on SOA architecture. It needs to register or listen to vehicle-side signals. Therefore, when the vehicle-side rule base is updated, it is necessary to register or deregister the listened event signals and the service status call signals according to the updated rules.

[0078] Figure 4 This is a flowchart illustrating a state machine module in an exemplary embodiment of this application.

[0079] Reference Figure 4As shown, the system monitors and acquires vehicle status in real time based on an SOA architecture, including: monitoring event-type signals or polling status-type signals; determining whether the event-type signals or status-type signals require smoothing processing, and if so, processing them using methods such as calculating average values / moving average values / multi-point sampling; and recording and caching the smoothed event-type signals or status-type signals. Specifically: S401, state machine startup; S402, vehicle-side event signal monitoring; S403, vehicle-side status signal polling; S404, determining whether the signal requires smoothing processing, and if so, processing it using methods such as calculating average values / moving average values / multi-point sampling; S405, recording the vehicle-side signals into the state machine. This module, based on the configured vehicle-side rule base information, completes the signal recording and maintenance functions of the vehicle-side state machine. This module divides vehicle-side signals into event-type signals and status-type signals, and records them in real time according to the characteristics of each type of signal. Since event-type signals send event signal change information to external modules, the state machine only needs to register this type of event signal. When an event-type signal changes, the state machine can automatically record the signal value through the registered callback function.

[0080] Since state signals do not send signal change information externally, their values ​​cannot be recorded via external callbacks. The state machine handles vehicle-side state signals using a timed polling method. Considering the real-time nature and resource consumption of timed polling, a trade-off is struck between the two. In its implementation, this module uses a thread pool for polling state signals. To address resource consumption, the thread pool has a maximum number of threads. Regarding the real-time recording of signals by the state machine, considering the complexity of the vehicle-side signal hardware environment and the potential for signal acquisition blocking, which could obstruct the acquisition of other signals, the thread pool records information about blocked threads. If a blocked thread exists, a corresponding number of new threads are automatically created to acquire state signals until the blocked threads are released. Then, the corresponding number of threads acquiring state signals are destroyed. This strategy ensures that a fixed number of normal threads are always working on acquiring state signals, thus maximizing the real-time performance of state signal acquisition.

[0081] For the received event or state signals, the state machine determines whether smoothing is required based on the signal's configuration information. If smoothing is needed, the state machine uses methods such as calculating average / moving average values ​​and multi-point sampling. Smoothing is primarily considered for signals like vehicle speed, which exhibit large fluctuations, rapid changes, and poor stability. After smoothing, the event or state signals are recorded and cached in the state machine to provide data support for subsequent event arbitration.

[0082] Figure 5 This is a flowchart illustrating an exemplary embodiment of the event arbitration module of this application.

[0083] Reference Figure 5 As shown, it determines whether the vehicle state meets the local rule information. If it does, the predefined scene state is reached, and the decision event of the rule engine is output to the outside. This includes: when the signal changes, iterating through the relevant rules according to the signal type to determine whether the rule is satisfied. If satisfied, it queries the event to which the rule belongs; iterating through the events to be decided to determine whether there are other rules for the event; if so, it queries the signal values ​​of the other rules; if all other rules are successfully matched, it performs event debouncing judgment; if the event debouncing condition is met, it sends the event code corresponding to the rule to the outside. That is, the steps include: S501, the vehicle-side signal changes; S502, traverse the relevant rules according to the signal type (excluding the rule information related to time); S503, determine whether the rule is satisfied, and if satisfied, query the event to which the rule belongs; S507, traverse the events to be decided, and determine whether there are other rules for the event; S508, query the signal values ​​of other rules from the state machine; S509, if all other rules are successfully matched; S510, if all other rules are successfully matched, perform event debouncing judgment; S511, if the event debouncing condition is met, send the event code corresponding to the rule to the outside.

[0084] The process of determining whether the vehicle state meets the local rule information, and if so, reaching the predefined scenario state, and outputting the decision event of the rule engine to the outside, also includes: sorting the timed rules in ascending order and obtaining the current system time; traversing the time rules and setting a timer based on the time difference between the system time and the time rule; after the timer wakes up, querying the event corresponding to the time rule; traversing the events to be decided and determining whether there are other rules for the event; querying the signal values ​​of the other rules; if all other rules are successfully matched, performing event debouncing judgment; if the event debouncing condition is met, sending the event code corresponding to the rule to the outside. Specifically, the steps include: S504, sorting the timing rules in ascending order and obtaining the current system time; S505, iterating through the rule times and setting a timer based on the time difference between the system time and the rule time; S506, after the timer wakes up, querying the event corresponding to the time rule; S507, iterating through the events to be decided and determining if there are any other rules for the event; S508, querying the signal values ​​of the remaining rules from the state machine; S509, if all other rules match successfully; S510, if all other rules match successfully, performing event debouncing judgment; S511, if the event debouncing condition is met, sending the event code corresponding to the rule to the outside. This module completes signal judgment, event decision-making, and event debouncing functions. For signal judgment, it includes the judgment of vehicle-side event signals, status signals, and time signals. Time signals mainly specify time-related rules. Due to the special nature of time signals, rules containing time signals are processed separately.

[0085] When a vehicle-side signal changes, this module iterates through relevant rules (excluding rules related to time-related signals) based on the signal type, determines if the rule matches, and if it does, queries the event corresponding to that rule and proceeds to the event decision-making stage. For rules related to time-related signals, this module sorts the timing rules in ascending order, obtains the current system time, iterates through all time-related rules, sets a timer based on the time difference between the system time and the time-related rule, and queries the event corresponding to the time rule each time the timer wakes up, proceeding to the event decision-making stage.

[0086] For an event that has entered the event decision-making stage, check if there are any other rules to be judged. If not, directly determine that the event has successfully matched the rule information and enter the event debouncing stage. Otherwise, check the state machine to see if the other rules of the event have been matched. If the other rules have been matched successfully, enter the event debouncing stage.

[0087] The event debouncing process primarily determines whether an event to be triggered by an external module meets the arbitration conditions, i.e., the debouncing conditions in the rule information. For time-interval-based debouncing mechanisms, it can only be triggered once within a certain time period; for frequency-limit-based debouncing mechanisms, it can only be triggered once within a single execution cycle of the vehicle-side rule engine. Only when the event debouncing conditions are met is it finally determined that the event can output the event code externally, i.e., the event is triggered.

[0088] To address the aforementioned issue of vehicle-side resource constraints, since the state machine involves signal monitoring and acquisition, resource consumption is mainly concentrated in the state machine module. This invention optimizes the resource consumption of the vehicle-side platform from the following three aspects:

[0089] Firstly, regarding the optimization of the state machine module: event-type signals are triggered by changes in external signals, involving relatively low resource consumption. Resource optimization primarily focuses on the acquisition of state-type signals. Since state-type signals require active polling by the vehicle-side rule engine, a trade-off must be struck between real-time signal acquisition and resource consumption. This invention employs a thread pool to acquire state-type signals, reducing resource consumption by setting a maximum thread count. Due to the complexity of the vehicle-side hardware environment, and considering blocking during signal acquisition, the thread pool dynamically creates and closes an equal number of threads to address blocking, ensuring real-time signal acquisition.

[0090] Secondly, the rule information database is optimized: Since the amount of vehicle-side signal data is large and different users pay attention to different signals, this invention supports the dynamic addition and reduction of vehicle-side monitoring signals, so as to minimize the performance consumption of the vehicle-side while ensuring different user needs.

[0091] Thirdly, event arbitration optimization: This invention proposes to support the parsing and recognition of time-related signals. Due to the special nature of time signals, firstly, this invention will specially process the rules containing time-related signals. Other rules in the time-related signal rules will not be judged separately. Only when the time signal matches will the matching status of other vehicle signals be judged, thus reducing the number of event arbitration signals. Secondly, a timer sequential sleep and wake-up method is adopted to judge the time signal, avoiding the cumbersome processing of time signal monitoring.

[0092] Figure 6 This is a schematic diagram illustrating the rule information structure as shown in an exemplary embodiment of this application.

[0093] Reference Figure 6 As shown, the rule information includes triggering rules, arbitration conditions, and event information. The rule information includes fields such as ruleType, name, signalCode, opera, constValue, needSmooth, Arbitration, ArbitrationValue, and EventCode. Six fields constitute the triggering rule: ruleType indicates the triggering rule type, name indicates the triggering rule explanation, signalCode indicates the signal type, opera indicates the comparison type, constValue indicates the comparison value, and needSmooth indicates whether the acquired signal needs smoothing. The arbitration condition's Arbitration indicates the anti-jitter type, ArbitrationValue indicates the anti-jitter value, and EventCode indicates the event information. It should be noted that the order of the fields representing the triggering rule, the arbitration condition, and the event information can be varied and is not restricted. The rule base consists of numerous rule information entries, including triggering rules, arbitration conditions, and event information. The triggering rule indicates that the rule match is successful after the condition is met; the arbitration condition indicates whether to output the rule information of successful match to the outside; the event information indicates the event-coded information sent to the outside after the rule match is successful and the arbitration is passed.

[0094] The rule information includes the fields ruleType, name, signalCode, opera, constValue, needSmooth, Arbitration, ArbitrationValue, and EventCode. The first six fields constitute the trigger rule. A rule can contain multiple trigger rules; a match is successful only when all trigger rules are satisfied. RuleType indicates the trigger rule type, including event (event-type signal), status (status-type signal), and time (time-type signal). Event-type signals actively send notification messages when their status changes; no notification is sent if the status remains unchanged. Status-type signals do not actively send notification messages regardless of status changes and must be actively retrieved through service calls. Time-type signals refer to the current system time, supporting two time types: scheduled triggers (e.g., triggered daily at 12:00) and recurring triggers (e.g., triggered every 10 minutes). Name indicates the trigger rule's explanation, such as "vehicle speed greater than 100km / h". SignalCode indicates the signal type, identifying which service the rule engine should listen to or call. Opera indicates the comparison type, such as greater than or less than; constValue indicates the comparison value; opera and constValue are used to determine whether the vehicle-side signal meets the triggering rules. NeedSmooth indicates whether the acquired vehicle-side signal needs to be smoothed. For example, for vehicle speed signals, since vehicle speed may change rapidly, it needs to be smoothed. The smoothed value is used as the input for determining the triggering rules.

[0095] Arbitration and ArbitrationValue constitute the arbitration conditions, and they have a one-to-one correspondence with the rule information. Arbitration indicates the debouncing type, supporting time intervals and a maximum number of triggers, while ArbitrationValue represents the debouncing value. If Arbitration indicates a time interval, then ArbitrationValue indicates that the rule can only be triggered once within the corresponding time class; if Arbitration indicates a maximum number of triggers, then ArbitrationValue indicates the maximum number of triggers within the rule engine's runtime cycle.

[0096] EventCode represents event information. It is represented in the form of event encoding and is used as output information of the rule engine. When a rule is matched, the rule engine will notify the external module of the event encoding of that rule.

[0097] An embodiment of this application also provides a vehicle-side rule engine implementation device, including: a rule distribution module, used to synchronize rule information configured in the cloud, and update local rule information based on the rule information configured in the cloud;

[0098] The state machine module is used to monitor and acquire vehicle status in real time based on SOA architecture; the event arbitration module is used to determine whether the vehicle status meets the local rule information. If it does, the predefined scenario state is reached, and the judgment event of the rule engine is output to the outside.

[0099] It should be noted that the vehicle-side rule engine implementation device and the vehicle-side rule engine implementation method provided in the above embodiments belong to the same concept. The specific methods of execution of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the image processing device provided in the above embodiments can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0100] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the vehicle-side rule engine implementation method provided in the above embodiments.

[0101] The computer system of the electronic device includes a central processing unit (CPU), which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) or loaded from storage into random access memory (RAM), such as performing the methods described in the above embodiments. RAM also stores various programs and data required for system operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output interfaces are also connected to the bus. The following components are connected to the I / O interface: input sections including keyboards, mice, etc.; output sections including cathode ray tubes, liquid crystal displays, etc., and speakers, etc.; storage sections including hard disks, etc.; and communication sections including network interface cards such as LAN cards and modems, etc. The communication section performs communication processing via a network such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage section as needed.

[0102] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions defined in the system of this application.

[0103] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, flash memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. Computer programs contained on computer-readable media can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0105] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0106] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vehicle-side rule engine implementation method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0107] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0108] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle-side rule engine implementation method provided in the various embodiments described above.

[0109] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0110] It should be understood that the above content is only a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A method for implementing a vehicle-side rules engine, characterized in that, include: Synchronize the rule information configured in the cloud, and update the local rule information based on the rule information configured in the cloud; Real-time monitoring and acquisition of vehicle status based on SOA architecture; Determine whether the vehicle status meets the local rule information; If the conditions are met, the predefined scenario state is reached, and the judgment event of the rule engine is output to the outside. The process of synchronizing rule information configured in the cloud and updating local rule information based on the cloud-configured rule information includes: Obtain the rule information configured in the cloud; The local rule information is updated based on the rule information configured in the cloud. Parse the updated rule information into memory; Based on the signal types of different triggering conditions in the updated rule information, register or deregister event-type signals and status-type signals to be monitored; the signal types include event-type signals, status signals, and time-type signals. Among these, the real-time monitoring and acquisition of vehicle status based on SOA architecture includes: Listen for event-type signals or poll for status-type signals; Determine whether the event-type signal or state-type signal needs smoothing processing. If so, use methods such as calculating the average value / moving average value / multi-point sampling for processing. Record the event-type signals or status-type signals after the cache smoothing process; Specifically, it determines whether the vehicle state satisfies the local rule information. If it does, a predefined scene state has been reached, and the rule engine outputs a judgment event to the outside, including: When a signal changes, the relevant rules are traversed according to the signal type to determine whether the rules are satisfied. If they are satisfied, the event to which the rule belongs is queried. The relevant rules do not include rules related to time-type signals. Iterate through the events to be decided and determine whether there are any other rules for the events; If so, then query the remaining rule signal values; If all other rules match successfully, then perform event debouncing judgment; If the event debouncing conditions are met, send the event code corresponding to the rule to the outside. For rules involving time-related signals, sort the timing rules in ascending order and obtain the current system time; Iterate through the time rules and set timers based on the time difference between the system time and the time rules; After the timer is woken up, query the events corresponding to the time rules; Iterate through the events to be decided and determine whether there are any other rules for the events; Query other rule signal values; If all other rules match successfully, then perform event debouncing judgment; If the event debouncing conditions are met, send the event code corresponding to the rule to the outside. The monitoring of event-type signals includes: recording the signal value through a registered callback function when the event-type signal changes; Polling status signals includes: using a thread pool to poll the status signals, wherein the thread pool has an upper limit on the number of threads; the thread pool records thread information of blocked signals, and if there are blocked threads, a corresponding number of new threads are created to obtain the status signals, until the blocked threads are released, and then the new threads are destroyed.

2. The vehicle-side rule engine implementation method according to claim 1, characterized in that, The rule information includes triggering rules, arbitration conditions, and event information. The rule information includes fields such as ruleType, name, signalCode, opera, constValue, needSmooth, Arbitration, ArbitrationValue, and EventCode. The triggering rule consists of six fields: ruleType (indicating the triggering rule type), name (indicating the triggering rule explanation), signalCode (indicating the signal type), opera (indicating the comparison type), constValue (indicating the comparison value), and needSmooth (indicating whether the acquired signal needs smoothing). The arbitration condition's Arbitration indicates the stabilization type, ArbitrationValue indicates the stabilization value, and EventCode indicates the event information.

3. A vehicle-side rule engine implementation device, characterized in that, include: A rule distribution module is used to synchronize rule information configured in the cloud and update local rule information based on the rule information configured in the cloud. The process of synchronizing rule information configured in the cloud and updating local rule information based on the rule information configured in the cloud includes: acquiring the rule information configured in the cloud; updating the local rule information based on the rule information configured in the cloud; parsing the updated rule information into memory; and registering or deregistering monitored event signals and status signals according to the signal types of different trigger conditions of the updated rule information. The signal types include event signals, status signals, and time signals. A state machine module is used for real-time monitoring and acquisition of vehicle status based on an SOA architecture. This real-time monitoring and acquisition of vehicle status based on SOA includes: monitoring event-type signals or polling state-type signals; determining whether the event-type signals or state-type signals require smoothing, and if so, processing them using methods such as calculating average values / moving average values / multi-point sampling; and recording and caching the smoothed event-type signals or state-type signals. Monitoring event-type signals includes: recording the signal value through a registered callback function when the event-type signal changes; polling state-type signals includes: using a thread pool to poll the state-type signals, wherein the thread pool has a maximum number of threads; the thread pool records thread information for blocked signals, and if a blocked thread exists, a corresponding number of new threads are created to acquire the state-type signals until the blocked thread is released, at which point the new threads are destroyed. The event arbitration module is used to determine whether the vehicle state meets the local rule information. If it does, a predefined scenario state is reached, and the rule engine's decision event is output externally. Determining whether the vehicle state meets the local rule information, and if so, outputting the rule engine's decision event externally, includes: when a signal changes, traversing relevant rules according to the signal type, determining whether the rules are satisfied, and if satisfied, querying the event to which the rule belongs; the relevant rules do not include rules related to time-based signals; traversing the events to be decided, determining whether there are other rules for the event; if so, then... Query the remaining rule signal values; if all remaining rules match successfully, perform event debouncing judgment; if the event debouncing condition is met, send the event code corresponding to the rule to the outside; for rules involving time-related signals, sort the timing rules in ascending order and obtain the current system time; traverse the time rules and set a timer based on the time difference between the system time and the time rule; after the timer wakes up, query the event corresponding to the time rule; traverse the events to be decided and determine if there are any other rules for the event; query the remaining rule signal values; if all remaining rules match successfully, perform event debouncing judgment; if the event debouncing condition is met, send the event code corresponding to the rule to the outside.

4. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the vehicle-side rule engine implementation method as described in any one of claims 1 to 2.

5. A computer-readable storage medium, characterized in that, It stores computer-readable instructions, which, when executed by the computer's processor, cause the computer to perform the vehicle-side rule engine implementation method as described in any one of claims 1 to 2.

6. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the vehicle-side rule engine implementation method as described in any one of claims 1 to 2.

Images