A monitoring method and an analysis method, device, equipment and medium for a request scenario

Abstract

The application relates to a monitoring method, an analysis method, a device, equipment and a medium for a request scenario, the monitoring method comprising the following steps: acquiring actual characteristic values of respective request signals of N request scenarios, wherein the request signals comprise valid request signals and invalid request signals; obtaining a monitoring value according to the actual characteristic values, wherein the monitoring value is the sum of the actual characteristic values; and outputting a monitoring message comprising the monitoring value, so as to determine a valid request scenario based on the monitoring value in the output monitoring message. The monitoring method can improve the problem of high CAN network load caused by multiple request signals in the prior art.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, analysis method, apparatus, device, and medium for monitoring a request scenario. Background Technology

[0002] New energy vehicles integrate technologies such as computers, modern sensing, information fusion, communication, artificial intelligence, and automatic control. They are typical high-tech complexes that employ flexible and versatile multi-scenario control strategies. For example, doors can be opened in multiple ways, vehicles can perform power-on processes in various scenarios, and range extenders can be requested to start in different scenarios. All of these are designed to improve the user's driving experience.

[0003] In existing technologies, it is not possible to directly observe the source of the request scenario for starting a certain system. For example, it is difficult to directly observe which startup scenario triggered the start of the range extender. In this case, it is necessary to analyze the request signal messages corresponding to each scenario reported by the vehicle. However, the number of request signals increases with the continuous enrichment of vehicle usage scenarios, which increases the load on the CAN (Controller Area Network). Summary of the Invention

[0004] Based on this, a monitoring method, analysis method, device, equipment, and medium for request scenarios are provided to improve the problem of high CAN network load caused by numerous request signals in the prior art.

[0005] On the one hand, a monitoring method for request scenarios is provided, including:

[0006] Obtain the actual feature values ​​of the request signals corresponding to each of the N request scenarios, wherein the request signals include valid request signals and invalid request signals;

[0007] Based on the actual feature values, a monitoring value is obtained, wherein the monitoring value is the sum of the actual feature values;

[0008] The output includes a monitoring message containing the monitoring value, so as to determine the valid request scenario based on the monitoring value in the output monitoring message;

[0009] The actual feature value is configured according to the feature value corresponding to the signal state of the request signal. The feature value corresponding to the signal state includes a first feature value when the signal is valid and a second feature value when the signal is invalid. The second feature value of the request signal when it is invalid is zero. Furthermore, the sum of the first feature values ​​corresponding to different combinations of request scenarios is not the same.

[0010] In one embodiment, each of the request scenarios corresponds to a sequence value K arranged in an ordered manner;

[0011] The sums of the first eigenvalues ​​of the different combinations are not the same, including:

[0012] The first feature value of the request signal in the Kth request scenario is the m-th power of the base A, where m is positively correlated with the sequence value K, and the base A is a positive number that is not one.

[0013] In one embodiment, the first characteristic value of the request signal in the Kth request scenario is a power of m of the base A, including:

[0014] The first feature value of the request signal in the Kth request scenario is the power of 2 to the power of K-1, and N is less than or equal to the scenario preset value;

[0015] The output includes a message containing the monitored values, including:

[0016] The monitoring values ​​are transmitted in binary data frames.

[0017] In one embodiment, before obtaining the actual feature values ​​of the request signals corresponding to the N request scenarios, the method further includes:

[0018] All the request scenarios are divided into multiple groups, each group including at least N request scenarios, so as to determine the corresponding valid request scenarios in each group based on the monitoring values ​​of each group.

[0019] In one embodiment, before obtaining the actual feature values ​​of the request signals corresponding to the N request scenarios, the process includes:

[0020] Determine the signal state of the request signal, where the signal state includes valid or invalid;

[0021] When the signal status is valid, the actual characteristic value of the configuration request signal is the first characteristic value; otherwise, it is the second characteristic value.

[0022] In one embodiment, the request scenario includes the start-up scenario of the vehicle's range extender, and the request signal includes the start-up request signal of the vehicle's range extender.

[0023] Before obtaining the actual feature values ​​of the request signals corresponding to N request scenarios, the following steps are included:

[0024] Obtain vehicle status parameters, and determine whether the start conditions corresponding to the start scenario are met based on the vehicle status parameters. If so, configure the start request signal corresponding to the start scenario to be valid.

[0025] On the other hand, a method for analyzing request scenarios is provided, including:

[0026] Acquire monitoring messages, which include monitoring values. The monitoring values ​​are the sum of actual feature values. The actual feature values ​​are the actual feature values ​​of the request signals corresponding to each of the N request scenarios. The request signals include valid request signals and invalid request signals. The actual feature values ​​are configured according to the feature values ​​corresponding to the signal states of the request signals. The feature values ​​corresponding to the signal states include a first feature value when the signal is valid and a second feature value when the signal is invalid. The second feature value of the request signal when it is invalid is zero, and the sum of the first feature values ​​is different for different combinations.

[0027] Based on the monitoring values ​​in the monitoring message, a valid request scenario is determined.

[0028] On another front, a monitoring device for request scenarios is provided, the device comprising:

[0029] The feature value acquisition module is used to acquire the actual feature values ​​of the request signals corresponding to each of the N request scenarios. The request signals include valid request signals and invalid request signals. The actual feature values ​​are configured according to the feature values ​​corresponding to the signal states of the request signals. The feature values ​​corresponding to the signal states include a first feature value when the signal is valid and a second feature value when the signal is invalid. The second feature value of the request signal when it is invalid is zero. The sum of the first feature values ​​is different for different combinations.

[0030] The monitoring value calculation module is used to obtain the monitoring value based on the actual feature value, wherein the monitoring value is the sum of the actual feature values;

[0031] An output module is used to output a message including the monitoring value, so as to determine the valid request scenario based on the monitoring value in the output message.

[0032] A computer device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method.

[0033] A computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method.

[0034] The monitoring method, apparatus, device, and medium for the above-mentioned request scenarios obtain a monitoring value by acquiring the feature value of the request signal corresponding to each request scenario, summing the feature values, and configuring the feature value of invalid request signals to zero. Since the sum of the feature values ​​of different combinations of the request signals is different, a monitoring value corresponds to only one set of valid request signals, and the corresponding valid request scenario can be determined based on a monitoring value. Since only a message including the monitoring value needs to be sent out, the network load is greatly reduced. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating a monitoring method for a request scenario in one embodiment;

[0036] Figure 2 This is a diagram illustrating the existing message reporting methods and the message reporting method of this application;

[0037] Figure 3 This is a flowchart illustrating the analysis method for a request scenario in another embodiment;

[0038] Figure 4 This is a structural block diagram of a monitoring device for a request scenario in one embodiment;

[0039] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0041] New energy vehicles are accelerating their development towards intelligence and integration. To meet specific user needs, new energy vehicles are further developing towards scenario-based applications, that is, achieving automatic vehicle control through scenario matching.

[0042] In scenario-based control strategies, when one or more scenarios are met, the corresponding system of the vehicle begins to execute the corresponding function. However, for analysis and testing personnel, determining which scenario triggered the system is a challenge.

[0043] Taking range-extended electric vehicles as an example, their range extenders have multiple start-up scenarios. When the vehicle status meets the start-up conditions of a certain preset scenario for the range extender to start, the start-up scenario is established, and the corresponding start-up signal engon = true is output. Otherwise, engon = false is output. Since there are different start-up scenarios, there are multiple start-up signals engon1, engon2, engon3...engonN. These start-up signals are all transmitted through the CAN network, and each start-up signal is reported using a separate message.

[0044] As the scenarios are developed, the number of request signals will increase as the vehicle usage scenarios become more diverse. Simply increasing the number of request signals will increase the load on the CAN bus.

[0045] The monitoring method for request scenarios provided in this application can be applied to the CAN network system of a vehicle to reduce the load on the CAN network.

[0046] like Figure 1 As shown, the monitoring method for request scenarios provided in this application includes the following steps:

[0047] Step 101: Obtain the actual feature value of the request signal corresponding to each request scenario.

[0048] It is understandable that for a specific system, there may be one or more scenarios where the system is expected to start, and there may also be scenarios where the system is expected to shut down. Taking the range extender as an example, when a user is using the vehicle, there may be start requests when the power is insufficient, start requests when the SOC (State of Charge) is insufficient, start requests when charging while parked, etc. Each request scenario corresponds to a start request signal. The vehicle system obtains the vehicle status parameters and determines whether the start conditions corresponding to the start scenario are met based on the vehicle status parameters. When the conditions of a start scenario are met, the start request signal corresponding to that start scenario is configured as true, that is, it is valid; the start request signal corresponding to other start scenarios where the conditions are not met is false, that is, it is invalid. Generally, true = 1, false = 0.

[0049] For example, the range extender start request when power is insufficient can be divided into start requests for insufficient drive power and insufficient battery discharge power when the battery is in a static state.

[0050] Insufficient drive power start-up request: This is used in scenarios where the user needs to accelerate at high throttle and urgently requires a larger power output or a larger drive power output.

[0051] The required vehicle status parameters include:

[0052] Accelerator pedal opening: Accpedel;

[0053] The requested power Pd of the driver;

[0054] The discharge power Pb of the power battery;

[0055] Vehicle speed V;

[0056] The threshold power P1 for starting the range extender is a V-P1 curve related to vehicle speed V, and the threshold is different for different vehicle speeds.

[0057] The compensation power threshold P2 of the range extender (calibrable).

[0058] When the vehicle controller calculates and identifies that the vehicle meets the following conditions:

[0059] Accpedel≥95; Pb≤P1; Pd≥Pb+P2.

[0060] If the vehicle's drive power is insufficient, a start request signal is sent, and engon1 = 1.

[0061] The range extender start request when the battery discharge power is insufficient in static conditions is used in the following scenarios: The power battery is sensitive to the ambient temperature. At extremely high or low temperatures, or at low SOC, the battery discharge power Pb is extremely low, which cannot meet the requirements of thermal management and drive, and may even be insufficient to start the range extender. Therefore, it is necessary to start the range extender to generate electricity and ensure the power needs of the whole vehicle.

[0062] The required vehicle status parameters include:

[0063] The discharge power Pb of the power battery;

[0064] High-voltage accessory power consumption Pascy;

[0065] The vehicle's driving mode and the range extender's start safety threshold P3 (a calibrable value; the value of P3 varies depending on the driving mode).

[0066] Powertrain readiness status and time (PtReady, T).

[0067] When the VCU (Vehicle Control Unit) calculates and identifies that the vehicle meets the following conditions:

[0068] PtReady=1; T≥3s; Pb-Pascy≤P3.

[0069] If the power battery discharge power is insufficient, a start request signal is sent, and engon2 = 1.

[0070] Based on actual needs, the two scenarios mentioned above can also be unified into a range extender startup scenario with insufficient power, using the same signal.

[0071] The range extender also has a SOC threshold activation request. In different driving modes, such as fuel priority and pure electric priority, the user's expected battery discharge capacity varies. The activation threshold for the range extender in fuel priority mode is SOC1, and in pure electric priority mode it is SOC2. In pure electric priority mode, the range extender activates when SOC ≤ SOC2; in fuel priority mode, it activates when SOC ≤ SOC1. Typically, SOC2 < SOC1. Using different activation request signals in different driving modes facilitates data analysis by testing personnel in real-world scenarios.

[0072] In addition, the range extender also has a launch mode start request. Launch mode requires reaching the limit of 0-100 km / h in time, and the power battery and range extender need to provide sufficient power to the motor to avoid the power reduction caused by the range extender start delay. At this time, the range extender starts, warms up in advance and enters the power generation state. When there is a power demand, the range extender can enter the power generation state at any time. That is, when it receives the launch mode flag signal, the start conditions are met and a start request signal is issued.

[0073] For example, in V2V (Vehicle-to-Vehicle) mode, when a vehicle provides power to another new energy vehicle, the range extender is used to discharge to the external vehicle first. At this time, the VCU determines that the V2V gun has been successfully connected and sends a message to indicate whether to enable the V2V function. After the user selects and confirms, the V2V trigger request signal becomes true, controlling the range extender to start. In V2L (Vehicle-to-Load) mode, the user can choose to discharge to the external vehicle using either the battery or the range extender. When the user connects the V2L gun and selects to discharge to the external vehicle using the range extender, the V2L start range extender flag becomes true, controlling the start of the range extender.

[0074] At the same time, there may be multiple valid start request signals, and any valid start request signal can trigger the range extender to start.

[0075] For ease of understanding, unless otherwise specified, the following request scenarios refer to the range extender's start-up request scenarios; and the request signals refer to the range extender's start-up request signals.

[0076] In this embodiment, the acquired request signals include engon1, engon2, engon3...engonN. These request signals include both valid and invalid request signals.

[0077] The characteristic values ​​of a request signal are illustrated by an example. The same request signal has a predefined characteristic value when it is valid (first characteristic value) and a characteristic value when it is invalid (second characteristic value), as shown in Table 1. During the monitoring process, the actual characteristic value of the request signal is configured according to the actual valid or invalid state of the signal.

[0078] Table 1:

[0079] 1 engon1 T1’ T1 2 engon2 T2’ T2 3 engon3 T3’ T3 … … … … N EngonN TN' TN

[0080] In actual implementation, when invalid, the characteristic values ​​of the request signal can all be zero, that is, T1' to TN' are all 0; when valid, there is a one-to-one correspondence between the characteristic values ​​of the request signal and the request signal itself, so the actual characteristic value of the request signal is set to the characteristic value when valid, as shown in Table 2.

[0081] Table 2:

[0082] engon1 efficient T1 engon2 efficient T2 engon3 invalid T3’＝0 … … … engonN invalid TN' = 0

[0083] In the monitoring method for request scenarios provided in this application, the sum of the first feature values ​​corresponding to different combinations of request scenarios are not the same.

[0084] Define the sum of the actual eigenvalues ​​of all request signals as ∑T. Since the eigenvalue of an invalid request signal is zero, the sum of the actual eigenvalues ​​∑T is equal to the sum of the first eigenvalues ​​of the valid request signals.

[0085] Therefore, the aforementioned special constraint ensures that for any ∑T, only one set of corresponding valid request signals can be found.

[0086] The sum of the first eigenvalues ​​of different combinations is different, which means that, when predefined, the sum of any combination of T1 to TN does not repeat.

[0087] For example, for the four known request scenarios corresponding to request signals engon1 to engon4, their characteristic values ​​when they are valid can be predefined: T1 = 32, T2 = 16, T3 = 8, T4 = 4. Depending on the actual vehicle usage scenario, one or more request signals may be valid, as shown in Table 4.

[0088] Table 4:

[0089]

[0090] In Table 4, the sum of the actual eigenvalues ​​∑T is unique when any combination of request signals is valid.

[0091] Step 102: Obtain monitoring values ​​based on the actual feature values, wherein the monitoring values ​​are the sum of the actual feature values.

[0092] The monitoring system sums the actual characteristic values ​​of each request signal to obtain the monitoring value J = ∑T.

[0093] Step 103: Output a message including the monitored value.

[0094] In the vehicle system, a CAN network is used to connect the controllers of each node to achieve time-sharing. In existing documentation, such as... Figure 2 As shown in Figure a, after the vehicle system receives the request signals for each request scenario, it will send each request signal to the CAN network in the form of a separate message. Controllers that need it, such as IVI (In-Vehicle Infotainment), can receive it. As the number of request scenarios increases, a new request signal needs to be created for each request scenario, which increases the load on the CAN network.

[0095] The monitoring method for request scenarios provided in this application, such as Figure 2 b) Even with a large number of request signals, only messages containing monitoring values ​​are output. Based on the monitoring values ​​in the output messages, and utilizing the unique correspondence between the sum of actual characteristic values ​​∑T and valid request signals, analysts or other controllers in the vehicle can deduce the valid request signals and the corresponding valid request scenarios. This achieves the monitoring of multiple request scenarios using a single monitoring value, significantly reducing the number of messages and the load on the CAN network.

[0096] In one embodiment, each request scenario corresponds to a sequentially arranged sequence of values. Generally, the request scenarios are sorted according to 1, 2, 3, 4, 5, 6...N (N is a preset number of scenarios), and their corresponding request signals are engon1, engon2, engon3, ..., engonN. The feature value of each request signal when it is valid is defined numerically according to a predefined rule. In this embodiment, the feature value of each request signal when it is valid is determined sequentially in exponential form. The first feature value of the request signal of the Kth request scenario is configured as the m-th power of the base A, i.e., T. k =A m The base A is the same positive number.

[0097] Where m is linearly correlated with the sequence value K, m = f(k), and in this embodiment, m is positively correlated with the sequence value K.

[0098] It is understandable that the second characteristic value when the request signal is invalid can be regarded as the exponent of the base A being zero. Therefore, in actual implementation, the base A can be configured according to the signal state of the request signal. When the request signal is valid, the base A is positive; when invalid, the base A is zero. The actual characteristic value of the request signal in the Kth request scenario is (true or false) A. f(k) .

[0099] Using the above method, the first characteristic value of a larger number of request signals can be quickly predefined.

[0100] It is also understandable that the N request signals use the same base A, which is not equal to 1.

[0101] In actual implementation, the configuration of feature values ​​can be achieved by the configuration module in the monitoring system. For predefined feature values, the configuration module can directly call the feature value data when judging the request signal. If valid, the actual feature value of the request signal is configured as the first feature value; otherwise, it is configured as the second feature value.

[0102] Alternatively, the configuration module can determine the appropriate option based on the sequence value of the request signal and the signal state, according to (true or false) A. f(k) Perform real-time calculation of actual feature values.

[0103] Using the above configuration method, it is only necessary to obtain the status of each request signal from the vehicle and make a judgment, which requires minimal modification to the original vehicle system.

[0104] In one embodiment of the above embodiments, the first feature value of the request signal of the Kth request scenario is configured as a power of 2 raised to the power of K-1, as exemplarily shown in Table 5.

[0105] Table 5:

[0106]

[0107] For the feature value calculation method shown in Table 5, analysts or some controllers in the vehicle can use the lookup table shown in Table 6 to find the request source.

[0108] Table 6:

[0109]

[0110] Meanwhile, as can be seen from Table 5, for cases where there are 5 or fewer request signals, the maximum monitoring value Jmax obtained by summing is 31. When the monitoring value J is transmitted in binary data frames, it is converted to binary, which is 2^5-1. In CAN communication, only five bits of data frames are needed to complete the transmission of feature value signals, thus reducing the amount of data occupied.

[0111] When there are many request signals, the summation of the monitoring value J is large, which makes it difficult for analysts to quickly find the corresponding valid request scenarios. In this case, the number of request scenarios corresponding to a single monitoring value can be reduced by grouping. Specifically, all the request scenarios can be divided into multiple groups, each group including at least N request scenarios, so as to determine the corresponding valid request scenarios in each group based on the monitoring value of each group.

[0112] For example, a typical range-extended electric vehicle has 10-15 start requests for its range extender. These are set up as three groups of five start requests each. Each group outputs a monitoring value J1, J2, or J3. The maximum value of each monitoring value is Jmax = 31. By using these three monitoring values, the source of the start signal can be monitored and quickly located.

[0113] This application also provides a method for analyzing request scenarios, such as... Figure 3 As shown, it includes the following steps:

[0114] Step 301: Obtain monitoring messages, the monitoring messages include monitoring values, the monitoring values ​​are the sum of actual feature values, the actual feature values ​​are the actual feature values ​​of the request signals corresponding to each of the N request scenarios, wherein the request signals include valid request signals and invalid request signals; the actual feature values ​​are configured according to the feature values ​​corresponding to the signal states of the request signals, the feature values ​​corresponding to the signal states include a first feature value when valid and a second feature value when invalid, the second feature value of the request signal when invalid is zero, and the sum of the first feature values ​​is different for different combinations;

[0115] Step 302: Determine the valid request scenario based on the monitoring value in the monitoring message.

[0116] In some embodiments, the first feature value of the request signal is configured in an exponential form. Specifically, each request scenario corresponds to a sequentially arranged sequence value K. The first feature value of the request signal of the Kth request scenario is configured as the m-th power of the base A, where m is positively correlated with the sequence value K, and the base A is the same positive number.

[0117] Generally, the first characteristic value of the corresponding request signal is configured according to 2 raised to the power of K or K-1.

[0118] For specific limitations on the analysis methods for request scenarios, please refer to the limitations on the monitoring methods for request scenarios mentioned above, which will not be repeated here.

[0119] The above-mentioned method for analyzing request scenarios only requires monitoring messages containing monitoring values ​​to determine valid request scenarios, reducing the amount of uploaded messages and alleviating network load pressure.

[0120] It should be understood that, although Figure 1 , Figure 3 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 , Figure 3 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0121] In one embodiment, such as Figure 4As shown, a monitoring device for a request scenario is provided, including: a feature value acquisition module 401, a monitoring value calculation module 402, and an output module 403, wherein:

[0122] The feature value acquisition module 401 is used to acquire the actual feature values ​​of the request signals corresponding to each of the N request scenarios. The request signals include valid request signals and invalid request signals. The actual feature values ​​are configured according to the feature values ​​corresponding to the signal state of the request signal. The feature values ​​corresponding to the signal state include a first feature value when the signal is valid and a second feature value when the signal is invalid. The second feature value of the request signal when it is invalid is zero. The sum of the first feature values ​​of different combinations is different.

[0123] The monitoring value calculation module 402 is used to obtain a monitoring value based on the actual feature value, wherein the monitoring value is the sum of the actual feature values;

[0124] The output module 403 is used to output a message including the monitoring value, so as to determine the valid request scenario based on the monitoring value in the output message.

[0125] The monitoring device for the aforementioned request scenarios obtains the feature values ​​of the request signals corresponding to each request scenario, sums the feature values ​​to obtain the monitoring value, and configures the feature value of invalid request signals to be zero. Since the sum of the feature values ​​of different combinations of the request signals is different, a monitoring value corresponds to only one set of valid request signals, and the corresponding valid request scenario can be determined based on a monitoring value. Since only a message including the monitoring value needs to be sent out, the network load is greatly reduced.

[0126] In one embodiment, the system further includes a feature value configuration module, which is used to determine the signal state of the request signal, the signal state including valid or invalid; when the signal state is valid, the system configures the actual feature value of the request signal as the first feature value, otherwise it configures it as the second feature value.

[0127] In one embodiment, the first feature value of the request signal of the Kth request scenario is configured as a power of m of the base A, where m is positively correlated with the sequence value K, and the base A is the same positive number.

[0128] In one implementation, the first feature value of the request signal in the Kth request scenario is configured as a power of 2 to the power of K-1, and N is less than or equal to 5; the output includes a message containing the monitoring value, comprising: transmitting the monitoring value as a binary data frame.

[0129] In one embodiment, all the request scenarios are divided into multiple groups, each group including at least N request scenarios, so as to determine the corresponding valid request scenarios in each group based on the monitoring values ​​of each group.

[0130] Specific limitations regarding the monitoring device for the request scenario can be found in the limitations of the monitoring method for the request scenario described above, and will not be repeated here. Each module in the aforementioned monitoring device for the request scenario can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0131] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for monitoring a requested scenario. The display screen can be an LCD screen or an e-ink display screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0132] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0133] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0134] Obtain the actual feature values ​​of the request signals corresponding to each of the N request scenarios, wherein the request signals include valid request signals and invalid request signals;

[0135] Based on the actual feature values, a monitoring value is obtained, wherein the monitoring value is the sum of the actual feature values;

[0136] The output includes a monitoring message containing the monitoring value, so as to determine the valid request scenario based on the monitoring value in the output monitoring message;

[0137] The actual feature value is configured according to the feature value corresponding to the signal state of the request signal. The feature value corresponding to the signal state includes a first feature value when the signal is valid and a second feature value when the signal is invalid. The second feature value of the request signal when it is invalid is zero. The sum of the first feature values ​​is different for different combinations.

[0138] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0139] The first feature value of the request signal in the Kth request scenario is configured as the m-th power of the base A, where m is positively correlated with the sequence value K, and the base A is the same positive number.

[0140] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0141] The first feature value of the request signal in the Kth request scenario is a power of 2 raised to the power of K-1, and N is less than or equal to 5;

[0142] The output includes a message containing the monitored values, including:

[0143] The monitoring values ​​are transmitted in binary data frames.

[0144] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0145] All the request scenarios are divided into multiple groups, each group including at least N request scenarios, so as to determine the corresponding valid request scenarios in each group based on the monitoring values ​​of each group.

[0146] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0147] Obtain the actual feature values ​​of the request signals corresponding to each of the N request scenarios, wherein the request signals include valid request signals and invalid request signals;

[0148] Based on the actual feature values, a monitoring value is obtained, wherein the monitoring value is the sum of the actual feature values;

[0149] The output includes a monitoring message containing the monitoring value, so as to determine the valid request scenario based on the monitoring value in the output monitoring message;

[0150] The actual feature value is configured according to the feature value corresponding to the signal state of the request signal. The feature value corresponding to the signal state includes a first feature value when the signal is valid and a second feature value when the signal is invalid. The second feature value of the request signal when it is invalid is zero. The sum of the first feature values ​​is different for different combinations.

[0151] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0152] The first feature value of the request signal in the Kth request scenario is the m-th power of the base A, where m is positively correlated with the sequence value K, and the base A is the same positive number.

[0153] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0154] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0155] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for monitoring request scenarios, characterized in that, include: Obtain the actual feature values ​​of the request signals corresponding to each of the N request scenarios, wherein the request signals include valid request signals and invalid request signals; wherein... When the execution conditions of the request scenario are met, the request signal corresponding to the request scenario is characterized as a valid request signal; when the execution conditions of the request scenario are not met, the request signal corresponding to the request scenario is characterized as an invalid request signal. The actual feature value is configured according to the feature value corresponding to the signal state of the request signal. The feature value corresponding to the signal state includes a first feature value when the signal is valid and a second feature value when the signal is invalid. When the request signal is characterized as a valid request signal, the feature value corresponding to the signal state of the request signal is the first feature value when it is valid; when the request signal is characterized as an invalid request signal, the feature value corresponding to the signal state of the request signal is the second feature value when it is invalid. Each of the aforementioned request scenarios corresponds to a sequentially arranged sequence value K. The first characteristic value when the request signal of the Kth request scenario is valid is the m-th power of the base A, where m is positively correlated with the sequence value K, and the base A is a positive number that is not one. The second characteristic value when the request signal is invalid is zero. Furthermore, the sum of the first characteristic values ​​corresponding to different combinations of request scenarios is not the same. Based on the actual feature values, a monitoring value is obtained, wherein the monitoring value is the sum of the actual feature values; The output includes a monitoring message containing the monitoring value, so as to determine the valid request scenario based on the monitoring value in the output monitoring message; wherein the valid request scenario is the request scenario corresponding to the valid request signal.

2. The monitoring method for request scenarios according to claim 1, characterized in that, The first feature value of the request signal in the Kth request scenario is a power of m of the base A, including: The first feature value of the request signal in the Kth request scenario is the power of 2 to the power of K-1, and N is less than or equal to the scenario preset value; The output includes a message containing the monitored values, including: The monitoring values ​​are transmitted in binary data frames.

3. The monitoring method for request scenarios according to claim 1, characterized in that, Before obtaining the actual feature values ​​of the request signals corresponding to N request scenarios, the process also includes: All the request scenarios are divided into multiple groups, each group including at least N request scenarios, so as to determine the corresponding valid request scenarios in each group based on the monitoring values ​​of each group.

4. The monitoring method for request scenarios according to claim 1, characterized in that, The request scenario includes the start-up scenario of the vehicle's range extender, and the request signal includes the start-up request signal of the vehicle's range extender; Before obtaining the actual feature values ​​of the request signals corresponding to N request scenarios, the following steps are included: Obtain vehicle status parameters, and determine whether the start conditions corresponding to the start scenario are met based on the vehicle status parameters. If so, configure the start request signal corresponding to the start scenario to be valid.

5. A method for analyzing request scenarios, characterized in that, include: Acquire monitoring messages, the monitoring messages include monitoring values, the monitoring values ​​are the sum of actual feature values, the actual feature values ​​are the actual feature values ​​of the request signals corresponding to each of the N request scenarios, wherein the request signals include valid request signals and invalid request signals; When the activation conditions of the request scenario are met, the request signal corresponding to the request scenario is characterized as a valid request signal; when the activation conditions of the request scenario are not met, the request signal corresponding to the request scenario is characterized as an invalid request signal. The actual feature value is configured according to the feature value corresponding to the signal state of the request signal. The feature value corresponding to the signal state includes a first feature value when the signal is valid and a second feature value when the signal is invalid. When the request signal is characterized as a valid request signal, the feature value corresponding to the signal state of the request signal is the first feature value when it is valid; when the request signal is characterized as an invalid request signal, the feature value corresponding to the signal state of the request signal is the second feature value when it is invalid. Each of the aforementioned request scenarios corresponds to a sequentially arranged sequence value K. The first characteristic value when the request signal of the Kth request scenario is valid is the m-th power of the base A, where m is positively correlated with the sequence value K, and the base A is a positive number that is not one. The second characteristic value when the request signal is invalid is zero. Furthermore, the sum of the first characteristic values ​​corresponding to different combinations of request scenarios is not the same. Based on the monitoring value in the monitoring message, a valid request scenario is determined; wherein, the valid request scenario is the request scenario corresponding to the valid request signal.

6. A monitoring device for a request scenario, characterized in that, The device includes: The feature value acquisition module is used to acquire the actual feature values ​​of the request signals corresponding to each of the N request scenarios, wherein the request signals include valid request signals and invalid request signals; wherein... When the activation conditions of the request scenario are met, the request signal corresponding to the request scenario is characterized as a valid request signal; when the activation conditions of the request scenario are not met, the request signal corresponding to the request scenario is characterized as an invalid request signal. The actual feature value is configured according to the feature value corresponding to the signal state of the request signal. The feature value corresponding to the signal state includes a first feature value when the signal is valid and a second feature value when the signal is invalid. When the request signal is characterized as a valid request signal, the feature value corresponding to the signal state of the request signal is the first feature value when it is valid; when the request signal is characterized as an invalid request signal, the feature value corresponding to the signal state of the request signal is the second feature value when it is invalid. Each of the aforementioned request scenarios corresponds to a sequentially arranged sequence value K. The first characteristic value when the request signal of the Kth request scenario is valid is the m-th power of the base A, where m is positively correlated with the sequence value K, and the base A is a positive number that is not one. The second characteristic value when the request signal is invalid is zero. Furthermore, the sum of the first characteristic values ​​corresponding to different combinations of request scenarios is not the same. The monitoring value calculation module is used to obtain the monitoring value based on the actual feature value, wherein the monitoring value is the sum of the actual feature values; An output module is configured to output a message including the monitoring value, so as to determine the valid request scenario based on the monitoring value in the output message; wherein the valid request scenario is the request scenario corresponding to the valid request signal.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images