CN116684250A - Abnormal flow alarming method, device, vehicle and readable storage medium - Google Patents

Abnormal flow alarming method, device, vehicle and readable storage medium Download PDF

Info

Publication number
CN116684250A
CN116684250A CN202310816803.3A CN202310816803A CN116684250A CN 116684250 A CN116684250 A CN 116684250A CN 202310816803 A CN202310816803 A CN 202310816803A CN 116684250 A CN116684250 A CN 116684250A
Authority
CN
China
Prior art keywords
vehicle
data packet
application
alarm
analyzed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310816803.3A
Other languages
Chinese (zh)
Inventor
苏牧辰
袁振东
张志羽
关江辉
陆刚
朱志博
康操
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Avatr Technology Chongqing Co Ltd
Original Assignee
Avatr Technology Chongqing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Avatr Technology Chongqing Co Ltd filed Critical Avatr Technology Chongqing Co Ltd
Priority to CN202310816803.3A priority Critical patent/CN116684250A/en
Publication of CN116684250A publication Critical patent/CN116684250A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Environmental & Geological Engineering (AREA)
  • Traffic Control Systems (AREA)

Abstract

The application is applicable to the technical field of traffic analysis of vehicles, and provides an abnormal traffic alarming method, an abnormal traffic alarming device, a vehicle and a readable storage medium, wherein the abnormal traffic alarming method comprises the following steps: acquiring a data packet of an application to be analyzed; acquiring running parameters of the vehicle; determining an alarm threshold corresponding to the application to be analyzed according to the identification of the application to be analyzed and the driving parameter; and selecting whether to alarm according to the data packet and the alarm threshold value. By the method, the alarm accuracy can be improved.

Description

Abnormal flow alarming method, device, vehicle and readable storage medium
Technical Field
The application belongs to the technical field of traffic analysis of vehicles, and particularly relates to an abnormal traffic alarming method and device, a vehicle and a readable storage medium.
Background
With the intelligent development of automobiles (such as electric automobiles), intelligent automobiles bear more and more man-machine interaction functions. For example, the intelligent cockpit on a vehicle provides not only the basic functions of the driving process for the user, but also a series of entertainment application functions for the user on the primary and secondary driving.
In the intelligent cabin scene, a user can use a main control screen or a remote screen to perform related functions such as movie watching, music listening, photo browsing and the like, but huge mobile network traffic usage and related cost are generated when the functions are used.
In practice, there may be situations where the user pays for mobile network traffic that is not used by himself, thereby giving the user a poor experience.
Disclosure of Invention
The embodiment of the application provides an abnormal flow alarming method, an abnormal flow alarming device, a vehicle and a readable storage medium, which can solve the problem that the existing method is difficult to timely alarm abnormal flow.
In a first aspect, an embodiment of the present application provides an abnormal flow alert method, applied to a vehicle, including:
acquiring a data packet of an application to be analyzed;
acquiring running parameters of the vehicle;
determining an alarm threshold corresponding to the application to be analyzed according to the identification of the application to be analyzed and the driving parameter;
and selecting whether to alarm according to the data packet and the alarm threshold value.
In a second aspect, an embodiment of the present application provides an abnormal flow warning device, applied to a vehicle, including:
the data packet acquisition module is used for acquiring a data packet of the application to be analyzed;
the driving parameter acquisition module is used for acquiring the driving parameters of the vehicle;
the alarm threshold determining module is used for determining an alarm threshold corresponding to the application to be analyzed according to the identification of the application to be analyzed and the driving parameter;
And the alarm selection module is used for selecting whether to alarm according to the data packet and the alarm threshold value.
In a third aspect, an embodiment of the present application provides a vehicle comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to the first aspect when executing the computer program.
In a fourth aspect, embodiments of the present application provide a readable storage medium storing a computer program which, when executed by a processor, implements a method according to the first aspect.
In a fifth aspect, embodiments of the present application provide a computer program product for, when run on a vehicle, causing the vehicle to perform the method of the first aspect described above.
Compared with the prior art, the embodiment of the application has the beneficial effects that:
in the embodiment of the application, the alarm threshold value of the application to be analyzed is determined according to the identification of the application to be analyzed and the running parameter, and whether the application to be analyzed alarms or not is selected according to the alarm threshold value and the acquired data packet of the application to be analyzed. Because the types or the use time durations of the vehicle-mounted applications used by the user under different driving parameters are generally different in the process of driving the vehicle or taking the vehicle, for example, the user usually does not operate the vehicle-mounted applications frequently in the process of driving the vehicle, but is likely to operate the vehicle-mounted applications frequently when the vehicle is powered on but does not drive, the accuracy of the acquired alarm threshold can be ensured when the alarm threshold is acquired according to the mode, so that the accuracy of whether the alarm is selected according to the alarm threshold is improved, the timeliness of finding abnormal traffic by the user is further improved, the possibility that the user needs to pay for the abnormal traffic is reduced, and the good experience of the user is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments or the prior art will be briefly described below.
FIG. 1 is a flow chart of an abnormal flow alert method according to an embodiment of the present application;
FIG. 2 is a schematic diagram of an abnormal flow alarm device according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a vehicle according to an embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It should also be understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
Furthermore, the terms "first," "second," "third," and the like in the description of the present specification and in the appended claims, are used for distinguishing between descriptions and not necessarily for indicating or implying a relative importance.
Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise.
Embodiment one:
some of the network traffic generated by the intelligent vehicle is generated by actual use of the intelligent vehicle, and some of the network traffic generated by the intelligent vehicle is not generated by actual use of the intelligent vehicle, but is not "abnormal traffic".
However, the concept of "abnormal traffic" is quite ambiguous, because each user has inconsistent habits of using vehicle applications (i.e., applications corresponding to in-vehicle infotainment products installed in automobiles), and thus it is difficult for information security operators to accurately determine whether abnormal traffic exists in network traffic based on only network traffic used by one user.
In order to improve the accuracy of judging abnormal flow on a vehicle machine, the embodiment of the application provides an abnormal flow alarming method. In the method, an alarm threshold value is determined according to an application identifier and a running parameter of a vehicle, and whether the network flow corresponding to a data packet of the application is abnormal flow is judged by comparing the alarm threshold value with the network flow corresponding to the data packet.
The abnormal flow warning method is described below with reference to the accompanying drawings.
Fig. 1 shows a flow chart of an abnormal flow alarm method according to an embodiment of the present application, where the abnormal flow alarm method is applied to a vehicle, and is described in detail as follows:
s11, acquiring a data packet of the application to be analyzed.
The application to be analyzed refers to an application installed on a vehicle and requiring abnormal flow analysis. Since an application (e.g., application a) may only have abnormal traffic when it is interacting with other devices (or applications B), an application requiring abnormal traffic analysis is herein an application that is interacting with other devices (or applications).
Specifically, the acquired data packet is typically a data packet of a period of time during which the application to be analyzed is used, for example, a data packet of the application to be analyzed during a power-on driving time of the vehicle is acquired. When the number of the applications to be analyzed is multiple, data packets of the applications to be analyzed are respectively acquired. For example, assuming that the application to be analyzed has an application a and an application C, the data packet of the application a is acquired, and the data packet of the application C is acquired, that is, the acquired data packet of the application a and the acquired data packet of the application C are independent from each other.
It should be noted that the data packet includes a data packet received by the application to be analyzed, and also includes a data packet sent by the application to be analyzed.
S12, acquiring the running parameters of the vehicle.
The running parameter of the vehicle is a parameter that can reflect the running state of the vehicle. For example, whether or not the vehicle is running, whether or not there is a parameter corresponding to a running state such as power-on, etc. are reflected.
Specifically, the corresponding parameters may be acquired from sensors or electronic control units (Electronic Control Unit, ECU) of the vehicle according to the travel parameters to be acquired.
S13, determining an alarm threshold corresponding to the application to be analyzed according to the identification of the application to be analyzed and the running parameter.
The identification of the application to be analyzed can uniquely identify the application to be analyzed. The identification of the application to be analyzed may be a name or a serial number, etc.
Specifically, the warning threshold value corresponding to the vehicle under different applications and different driving parameters is predetermined. That is, in the embodiment of the present application, the alarm thresholds corresponding to the same application under different driving parameters are also likely to be different, and the alarm thresholds corresponding to the same application under different vehicles (or different users) are also likely to be different.
In some embodiments, to be able to obtain a more accurate warning threshold, the network traffic used by the user under different applications and different driving parameters is calculated after the vehicle is delivered to the user for a preset period of time (for example, one month), and the warning threshold corresponding to the different applications under different driving parameters is determined according to the calculated network traffic.
Because the vehicle is delivered to the user, the user needs a period of time to be familiar with each application on the vehicle, and therefore, the network traffic of the vehicle is collected after the vehicle is delivered to the user for a preset period of time, the calculated network traffic can be ensured to be more fit with the actual use condition of the user, namely, the accuracy of the calculated network traffic can be ensured, and the accuracy of a warning threshold value determined later can be improved.
In some embodiments, in order to obtain a more accurate alarm threshold, after the vehicle is delivered to the user, the running time of the power-on of the user is counted, after the running time is greater than a preset running time threshold, the network traffic used by the user under different applications and different running parameters is calculated, and the alarm threshold corresponding to the different applications under the different running parameters is determined according to the calculated network traffic.
Considering that after some users take the vehicle, the driving duration of the power-on driving may not be long, and when the driving duration of the power-on driving is not long, it is generally indicated that the user does not effectively utilize the vehicle application, at this time, the obtained network traffic also cannot accurately reflect the use condition of the user on the vehicle application when driving the vehicle, so after the driving duration of the user is greater than the preset driving duration threshold (the driving duration threshold may be set to 72 hours, of course, may be set to other values, and is not limited any more here), the network traffic of the user under different applications and different driving parameters is counted, so that the accuracy of the counting result can be improved, and the accuracy of the alarm threshold obtained according to the counting result is further improved.
In some embodiments, the alarm threshold corresponding to the same application under the same driving parameter may be equal to k×habit value, where K is a value greater than 0 and less than 2, and habit value of the same application under the same driving parameter=sum of the magnitudes of the network traffic corresponding to each time the application is used under the driving parameter for the last month/power-on driving time.
Since the usage habit of the user is not changed greatly, the alarm threshold is determined according to K and habit values which are larger than 0 and smaller than 2, and the accuracy of the obtained alarm threshold can be ensured.
In some embodiments, the number of alert thresholds (or alert types) corresponding to the same application under the same driving parameters may be 1 or greater than 1. For example, assuming that the number of alarm thresholds is 2 and the corresponding alarm types are gray alarm and yellow alarm, the alarm threshold corresponding to the gray alarm may be set to be equal to 30% of the habit value (i.e., K is 30%), and the alarm threshold corresponding to the yellow alarm may be set to be equal to 130% of the habit value (i.e., K is 130%) of the current driving duration.
S14, selecting whether to alarm according to the data packet and the alarm threshold value.
Specifically, when the network traffic corresponding to the data packet is greater than the alarm threshold, an alarm is selected. For example, when the network traffic of the application acquired in the current power-on driving time length is greater than the alarm threshold corresponding to the gray alarm, the gray alarm is generated, otherwise, the gray alarm is not generated. Similarly, if the network flow of the application acquired in the current power-on driving time is greater than the alarm threshold corresponding to the yellow alarm, the yellow alarm is generated, otherwise, the yellow alarm is not generated.
It should be noted that the warning herein includes warning to a user (e.g., driver, passenger, etc. in a vehicle), and may also include warning to an information security operator, etc. For example, after an alarm is selected, the user is alerted, after the user confirms that reporting is required, the information security operator is alerted again, and so on.
Further, when there are multiple alarm types, association relations of different alarm types may be set, for example, when there are a gray alarm, a yellow alarm and a red alarm, and the alarm level of the gray alarm is the lowest, and when the alarm level of the red alarm is the highest, after the gray alarm is generated, if it is determined that the user selects to report, the gray alarm is further classified into the yellow alarm, and after the number of times of accumulating the generated yellow alarm by using the ip address as the destination ip address is greater than a preset threshold number of times of steps (for example, set as 5 times), a red alarm is generated. Because the association relation of different alarm types is set, the subsequent timely generation of the corresponding type of alarm is facilitated, and information security operators can screen the alarm types on the cloud platform to check the logs (the logs can comprise source ip addresses, destination ip addresses, flow sizes, log time, reporting time and the like) corresponding to the alarms obtained by screening so as to accurately analyze the alarms obtained by screening.
In the embodiment of the application, the alarm threshold value of the application to be analyzed is determined according to the identification of the application to be analyzed and the running parameter, and whether the application to be analyzed alarms or not is selected according to the alarm threshold value and the acquired data packet of the application to be analyzed. Because the types or the use time durations of the vehicle-mounted applications used by the user under different driving parameters are generally different in the process of driving the vehicle or taking the vehicle, for example, the user usually does not operate the vehicle-mounted applications frequently in the process of driving the vehicle, but is likely to operate the vehicle-mounted applications frequently when the vehicle is powered on but does not drive, the accuracy of the acquired alarm threshold can be ensured when the alarm threshold is acquired according to the mode, so that the accuracy of whether the alarm is selected according to the alarm threshold is improved, the timeliness of finding abnormal traffic by the user is further improved, the possibility that the user needs to pay for the abnormal traffic is reduced, and the good experience of the user is improved.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.
Embodiment two:
in some embodiments, the step S11 includes:
monitoring at least one interface in the vehicle: and the controller area network (Controller Area Network, CAN) bus interface, the network connection interface and the Bluetooth interface, and acquiring the data packet under the condition that the monitored interface has the data packet of the application to be analyzed.
In the embodiment of the application, considering that the data of the vehicle-mounted terminal is mostly transmitted through a CAN bus, network connection and/or Bluetooth and the like, the data packet of the application to be analyzed CAN be obtained by monitoring the CAN bus interface, the network connection and/or the Bluetooth interface (for example, if the data of the vehicle-mounted terminal is transmitted through the CAN bus, the CAN bus interface is monitored, and if the data of the vehicle-mounted terminal is transmitted through the Bluetooth, the Bluetooth interface is monitored). Specifically, the information such as the sender and the receiver of the data packet can be identified by identifying the identifier of the data packet, and whether a data packet is the data packet of the application to be analyzed can be judged according to the sender and the receiver.
The corresponding interfaces are monitored by combining the transmission mode of the data of the vehicle-mounted terminal, so that the data packet of the application to be analyzed can be timely obtained.
Embodiment III:
in some embodiments, before S12, the abnormal flow alert method provided by the embodiment of the present application further includes:
and detecting whether the data packet of the application to be analyzed is called by a target application, wherein the number of the data packet called by the target application is related to the running parameter.
Correspondingly, the step S12 includes:
and acquiring the running parameters of the vehicle according to the detection result.
The target application is a preset application, and the target application is also an application of the vehicle machine side.
In the embodiment of the application, whether the target application is started is detected, after the target application is started is judged, whether the target application needs to call the data packet of the application to be analyzed is judged, if so, the running parameters corresponding to the data packet of the application to be analyzed is acquired, and if not, the running parameters corresponding to the data packet of the application to be analyzed is acquired. For example, assume that the target application is a real-time road condition or navigation function type application, and the application to be analyzed is a global positioning system (Global Positioning System, GPS) positioning module. Because the GPS positioning module mainly relies on satellite signals to acquire longitude and latitude coordinates of the vehicle when measuring the position of the vehicle, and is irrelevant to the speed of the vehicle, the number of GPS data packets (namely GPS flow packets) cannot be directly influenced by the speed of the vehicle. However, if the application of the real-time road condition or navigation function type is started, the system needs to calculate the optimal route and running time according to the vehicle speed and the road condition information, i.e. in this case, the vehicle speed and the running distance can influence the processing amount of the GPS data and the transmission amount of the data packets, so as to have a certain influence on the size of the traffic packets. That is, when the application of the real-time road condition or the navigation function type is not started, the driving parameters such as the vehicle speed and the driving distance do not need to be acquired, otherwise, the driving parameters such as the vehicle speed and the driving distance need to be acquired.
In the embodiment of the application, because the number of the data packets called by the target application is related to the running parameters, the running parameters of the vehicle are acquired according to the detection result of whether the data packets of the application to be analyzed are called by the target application, and the accuracy of the acquired running parameters can be ensured.
Embodiment four:
in some embodiments, the driving parameters of embodiments of the present application include at least one of: vehicle speed, power-on information, driving duration and driving distance.
The vehicle speed refers to the speed of the vehicle, and if the acquired data packet is a data packet to be analyzed and applied in a period of time, the vehicle speed may be the average speed of the vehicle corresponding to the period of time. It is noted that the vehicle speed here may be equal to 0.
The power-on information refers to information of whether a battery of the vehicle is in a power supply state or not. When the engine of the vehicle stops working (i.e. the vehicle speed=0), but the battery of the vehicle is still supplying power, the vehicle is indicated to be in a running state of stopping but not powering down.
The driving time length refers to the driving time length corresponding to the time when the vehicle starts the application to be analyzed in the current power-on process.
The driving distance refers to the driving distance corresponding to the process of starting the application to be analyzed in the current power-on process of the vehicle.
Considering that the network traffic used by the user in different driving states of the vehicle is generally different, for example, the GPS data stream may be relatively stable (typically between 1 and 5 data packets per second) during long-distance driving (such as driving for longer than 1 hour) of the vehicle, if the GPS signal quality is better, the data stream may be more stable, so the GPS data stream in the long-distance driving state may set a higher alarm threshold when the alarm threshold is determined only according to the driving time, for example:
assuming that a vehicle travels for 1 hour long, GPS transmits 5 (MAX) packets per second, each packet being 100 bytes (about 0.1 KB), the GPS traffic consumption within 1 hour is about: 1 second 60 minutes 60 seconds 5 0.1KB=1800 KB, namely when the power-on electricity indicates that the battery is powered on, the vehicle speed is greater than 0 and the driving time is greater than or equal to 1 hour, the alarm threshold corresponding to the GPS positioning module can be set to 1800KB.
Of course, instead of determining the warning threshold value based on the running time alone, the warning threshold value may be determined based on the running time and the vehicle speed. For example:
assuming that the GPS transmits 1 packet per second at low speeds (e.g., 40km/h and below), the GPS traffic consumption within 1 hour is approximately: 1 second 60 minutes 60 seconds 1 0.1KB=360 KB, namely when the power-on electricity indicates that the battery is powered on, the driving time is longer than or equal to 1 hour, and the vehicle speed is less than or equal to 40km/h, the warning threshold corresponding to the GPS positioning module can be set to be 360KB.
The above list is a setting scenario of an alarm threshold when there is a vehicle speed (i.e. a scenario where the vehicle speed is >0 and the power-on information indicates that the vehicle is in a power-on state), in an actual situation, there is also a scenario where parking is stopped but power is not down (i.e. the battery is still supplying power), in which scenario (i.e. a scenario where the vehicle speed is equal to 0 and the power-on information indicates that the vehicle is in a power-on state), the user is likely to use the internet entertainment platform, and thus network traffic is generated. For example, after the in-vehicle entertainment system is connected to the mobile device through the vehicle-mounted bluetooth, the user can continue to use the entertainment platforms to listen to music, watch video or play games after parking, or use the mobile office device of the vehicle to make a call, send mail or use the vehicle-mounted WiFi to perform office work while parking, etc.
Assuming that the definition of the video is 720P, the video size per minute is 10MB, and the video is viewed for 1 hour using the in-vehicle networking device, the network traffic consumption within 1 hour is: 10 MB/min 60 min/hr 1 hr=600 MB, i.e. the alarm threshold corresponding to the application of the video class can be set to 600MB.
While in a park and power down scenario (i.e., a scenario where the vehicle speed is equal to 0 and power up indicates that the vehicle is in a power down state), the data flow may be almost zero. Even the application in the cabin cannot be used after the vehicle owner parks and powers down under the condition, for example, the common functional air conditioner cannot be used, and the video entertainment application cannot be used, so that the alarm threshold value corresponding to the scene can be set to be 0 or a very low flow value (for example, 100 KB/h).
According to the above description, when the driving parameters include the vehicle speed and the power-on information, three different driving states of the vehicle can be determined according to the vehicle speed and the power-on information, and the warning threshold corresponding to the driving state in which the vehicle is stopped but not powered down is the highest, and the warning threshold corresponding to the driving state in which the vehicle is powered down is the lowest, namely: assuming that the vehicle speed is greater than 0 and the warning threshold corresponding to the power-on state indicating vehicle is a first warning threshold, the vehicle speed is equal to 0 and the warning threshold corresponding to the power-on state indicating vehicle is a second warning threshold, the vehicle speed is equal to 0 and the warning threshold corresponding to the power-on state indicating vehicle is a third warning threshold, and setting the second warning threshold > the first warning threshold > the third warning threshold.
Fifth embodiment:
in some embodiments, after S14, the abnormal flow alert method provided by the embodiment of the present application further includes:
and displaying alarm information and processing button icons on the man-machine interaction interface of the vehicle under the condition of alarm selection, wherein after the processing button icons are clicked, the data packets of the current alarm are processed according to the processing modes corresponding to the clicked processing button icons.
The alarm information comprises an identification of an application with abnormal traffic and used traffic. For example, the alert message may be "the system monitors that the current XX application flow exceeds YY, which is a specific flow value, and may generate more flow charges, please confirm whether to stop using the XX application. Because the alarm information comprises the application identifier and the value of the used network traffic, visual information is provided for the user, so that the accuracy of judging whether the current used network traffic is abnormal or not by the user is improved.
Wherein the number of processing button icons is the same as the number of selectable processing modes. For example, assume that there are 3 alternative treatments: the user can choose to ignore the alarm information of the time, can choose to terminate the application currently used and report the related information, and the number of the displayed processing button icons is 3 when the number of the preset days is a fixed value or a plurality of selectable values. Suppose that the 3 process button icons are: the application is ignored, terminated and reported this time, and no prompt is given within 7 days.
When the man-machine interaction interface of the vehicle displays the alarm information and the processing button icon, if the user clicks the processing button icon of 'neglect this time', neglect this time, namely, the alarm information of this time is not reported. Further, in order to reduce the interference to the user, the alarm information is not generated for the application corresponding to the alarm information in the default day, that is, even if the network traffic generated by the application corresponding to the alarm information in the current day still exceeds the corresponding alarm threshold, the alarm information and the processing button icon are not displayed on the man-machine interaction interface. It should be noted that, if the alarm types are multiple and the association relations of different alarm types are set, after the user clicks the processing button icon of "ignore" this time, other types of alarms will not be generated according to the set association relations. For example, if the type of the generated alarm is gray alarm and the number of generated gray alarms is equal to 3, a yellow alarm will be generated once, and after the user clicks the processing button icon of "ignore this time", the generated gray alarm will be ignored, i.e. the number of generated gray alarms will not be accumulated.
If the user clicks the process button icon of 'terminate application and report', the currently used application is terminated, and the generated alarm information and the log corresponding to the alarm information are reported to a cloud platform (Vehicle Security Operations Center, V-SOC) of a vehicle safety operation center, so that information safety operators can conduct abnormal flow investigation on the alarm information. In some embodiments, if the alarm types are multiple (for example, the gray alarm level is lower than the yellow alarm level), after the user clicks the process button icon of "terminate application and report", the alarm information generated this time is marked, for example, the alarm is marked as a yellow alarm, and then reported. When the user judges that the current network flow is abnormal flow, the probability that the network flow is abnormal flow is high, so that the corresponding alarm information is marked as a higher-level alarm type, the information security operator can analyze the alarm information more quickly, and the probability that the user pays for the abnormal flow is reduced.
In the embodiment of the application, considering that the development period of the intelligent vehicle is not long, the data with enough magnitude currently does not support the abnormal flow accurate alarm with low false alarm rate, so the false alarm rate of the alarm information can be reduced through the monitoring feedback with higher real-time performance (namely, the alarm information and the processing button icon are displayed on the man-machine display interface). In addition, because the processing button icons displayed on the man-machine display interface are usually large button controls, and compared with sliding operation, clicking on the large button controls is simple interactive operation, the manner of displaying the processing button icons on the man-machine display interface is convenient for the user in the vehicle to perform quick and accurate operation, and the safety of the driver and the passengers is improved.
Example six:
in some embodiments, after S11, the abnormal flow alert method provided by the embodiment of the present application further includes:
a1, identifying whether the data packet is an abnormal data packet.
The abnormal data packet includes a data packet whose data packet itself is abnormal, for example, a data packet corresponding to an identifier that is illegal or counterfeit (for example, the identifier indicates that the address of the corresponding data packet is a suspicious address), a data packet whose data segment length does not meet the specification, and the like. For example, the cyclic redundancy check (Cyclic Redundancy Check, CRC) code of the received data packet is compared with the actual check result, and if the two are not matched, it indicates that the data packet may have been tampered with or transmitted with errors, i.e., the probability that the data packet is an abnormal data packet is high.
In the embodiment of the application, whether the data packet is an abnormal data packet can be judged by identifying the identifier and/or the length of the data segment of the data packet. Of course, it is also possible to judge whether or not a packet is an abnormal packet by identifying the transmission speed between adjacent packets, or the like.
A2, selecting an alarm when the data packet is identified as the abnormal data packet.
In the embodiment of the application, when the data packets are abnormal data packets, the network traffic corresponding to the data packets is indicated to be abnormal traffic, so that the timeliness of the alarm can be ensured by selecting the alarm.
In some embodiments, when the number of data packets is greater than 1, the abnormal data packet further includes data packets that are transmitted excessively frequently, where A1 includes:
a11, determining transmission intervals of two data packets in each data packet group, wherein each data packet group comprises two adjacent data packets.
A12, identifying whether the data packet is an abnormal data packet according to the determined transmission intervals.
Specifically, it is assumed that the transmitted data packet has: packet 1, packet 2, packet 3 and packet 4, packet 1 and packet 2 form a packet group (assumed to be packet group 1), packet 2 and packet 3 form a packet group (assumed to be packet group 2), and packet 3 and packet 4 form a packet group (assumed to be packet group 3). And calculating transmission intervals of corresponding data packets according to transmission start time of two data packets in each data packet group, and judging the data packets as data packets which are transmitted excessively frequently if the obtained transmission intervals are smaller than a preset transmission interval threshold value or judging the data packets as abnormal data packets if most transmission intervals (such as more than 60% transmission intervals) in all the transmission intervals are smaller than the preset transmission interval threshold value.
Embodiment seven:
corresponding to the abnormal flow warning method described in the above method embodiments, fig. 2 shows a block diagram of the abnormal flow warning device provided in the embodiment of the present application, and for convenience of explanation, only the portion related to the embodiment of the present application is shown.
The abnormal flow warning device 2, which is applied to a vehicle, includes: a data packet acquisition module 21, a driving parameter acquisition module 22, an alarm threshold determination module 23 and an alarm selection module 24. Wherein:
the data packet obtaining module 21 is configured to obtain a data packet of an application to be analyzed.
The driving parameter obtaining module 22 is configured to obtain the driving parameters of the vehicle.
The alarm threshold determining module 23 is configured to determine an alarm threshold corresponding to the application to be analyzed according to the identifier of the application to be analyzed and the driving parameter.
The alarm selecting module 24 is configured to select whether to alarm according to the data packet and the alarm threshold.
In the embodiment of the application, the alarm threshold value of the application to be analyzed is determined according to the identification of the application to be analyzed and the running parameter, and whether the application to be analyzed alarms or not is selected according to the alarm threshold value and the acquired data packet of the application to be analyzed. Because the types or the use time durations of the vehicle-mounted applications used by the user under different driving parameters are generally different in the process of driving the vehicle or taking the vehicle, for example, the user usually does not operate the vehicle-mounted applications frequently in the process of driving the vehicle, but is likely to operate the vehicle-mounted applications frequently when the vehicle is powered on but does not drive, the accuracy of the acquired alarm threshold can be ensured when the alarm threshold is acquired according to the mode, so that the accuracy of whether the alarm is selected according to the alarm threshold is improved, the timeliness of finding abnormal traffic by the user is further improved, the possibility that the user needs to pay for the abnormal traffic is reduced, and the good experience of the user is improved.
In some embodiments, the packet acquisition module 21 is specifically configured to:
monitoring at least one interface in the vehicle: the method comprises the steps of (1) acquiring a data packet of the application to be analyzed under the condition that the monitored interface is provided with the data packet of the application to be analyzed.
In some embodiments, the abnormal flow warning device 2 provided in the embodiments of the present application further includes:
and the called application judging module is used for detecting whether the data packet of the application to be analyzed is called by a target application or not before the running parameters of the vehicle are acquired, and the number of the data packets called by the target application is related to the running parameters.
Correspondingly, the driving parameter obtaining module 22 is specifically configured to:
and acquiring the running parameters of the vehicle according to the detection result.
In some embodiments, the above-described travel parameters include at least one of: vehicle speed, power-on information, driving duration and driving distance.
In some embodiments, the driving parameter includes the vehicle speed and the power-on information, the vehicle speed is greater than 0, the alarm threshold corresponding to the power-on information indicating that the vehicle is in the power-on state is a first alarm threshold, the alarm threshold corresponding to the power-on information indicating that the vehicle is in the power-on state is a second alarm threshold, the vehicle speed is equal to 0, and the alarm threshold corresponding to the power-on information indicating that the vehicle is in the power-on state is a third alarm threshold.
Setting the second alarm threshold value > the first alarm threshold value > the third alarm threshold value.
In some embodiments, the abnormal flow warning device 2 provided in the embodiments of the present application further includes:
and the alarm information display module is used for displaying alarm information and processing button icons on a man-machine interaction interface of the vehicle under the condition of selecting the alarm after the alarm is selected according to the data packet and the alarm threshold, wherein the processing button icons are clicked and then the data packet of the alarm is processed according to the processing mode corresponding to the clicked processing button icon.
In some embodiments, the abnormal flow warning device 2 provided in the embodiments of the present application further includes:
and the abnormal data packet identification module is used for identifying whether the data packet is an abnormal data packet or not after the data packet of the application to be analyzed is acquired.
And the alarm module is used for selecting an alarm under the condition that the data packet is identified as the abnormal data packet.
In some embodiments, the number of the data packets is greater than 1, and the abnormal data packet identification module includes:
and a transmission interval determining unit, configured to determine a transmission interval of two data packets in each data packet group, where each data packet group includes two adjacent data packets.
And the abnormal data packet identification unit is used for identifying whether the data packet is an abnormal data packet according to the determined transmission intervals.
It should be noted that, because the content of information interaction and execution process between the above devices/units is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and will not be described herein.
Example eight:
fig. 3 is a schematic structural diagram of a vehicle according to an embodiment of the application. As shown in fig. 3, the vehicle 3 of this embodiment includes: at least one processor 30 (only one processor is shown in fig. 3), a memory 31 and a computer program 32 stored in the memory 31 and executable on the at least one processor 30, the processor 30 implementing the steps in any of the various method embodiments described above when executing the computer program 32.
The vehicle 3 may include, but is not limited to, a processor 30, a memory 31. It will be appreciated by those skilled in the art that fig. 3 is merely an example of the vehicle 3 and is not intended to limit the vehicle 3, and may include more or fewer components than shown, or may combine certain components, or may include different components, such as input-output devices, network access devices, etc.
The processor 30 may be a central processing unit (Central Processing Unit, CPU), the processor 30 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field-programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 31 may in some embodiments be an internal storage unit of the vehicle 3, such as a hard disk or a memory of the vehicle 3. The memory 31 may in other embodiments also be an external storage device of the vehicle 3, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the vehicle 3. Further, the memory 31 may also include both an internal storage unit and an external storage device of the vehicle 3. The memory 31 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs etc., such as program codes of the computer program etc. The memory 31 may also be used for temporarily storing data that has been output or is to be output.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, the specific names of the functional units and modules are only for distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.
The embodiments of the present application also provide a readable storage medium storing a computer program, where the steps in the above method embodiments are implemented when the computer program is executed by a processor.
Embodiments of the present application provide a computer program product which, when run on a vehicle, causes the vehicle to perform the steps of the method embodiments described above.
The integrated units described above, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, where the computer program, when executed by a processor, may implement the steps of each of the method embodiments described above. The computer program comprises computer program code, and the computer program code can be in a source code form, an object code form, an executable file or some intermediate form and the like. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a photographing device/terminal apparatus, recording medium, computer Memory, read-Only Memory (ROM), random access Memory (RAM, random Access Memory), electrical carrier signals, telecommunications signals, and software distribution media. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other manners. For example, the apparatus/network device embodiments described above are merely illustrative, e.g., the division of modules or elements described above is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims (11)

1. An abnormal flow warning method, characterized by being applied to a vehicle, comprising:
acquiring a data packet of an application to be analyzed;
acquiring running parameters of the vehicle;
determining an alarm threshold corresponding to the application to be analyzed according to the identification of the application to be analyzed and the driving parameter;
And selecting whether to alarm according to the data packet and the alarm threshold value.
2. The abnormal traffic alert method according to claim 1, wherein the acquiring the data packet of the application to be analyzed comprises:
monitoring at least one interface in the vehicle: the method comprises the steps of (1) acquiring a data packet of the application to be analyzed under the condition that the monitored interface comprises the data packet of the application to be analyzed.
3. The abnormal flow warning method according to claim 1, characterized by further comprising, before the acquisition of the running parameter of the vehicle:
detecting whether the data packet of the application to be analyzed is called by a target application, wherein the number of the data packet called by the target application is related to the running parameter;
the acquiring the driving parameters of the vehicle includes:
and acquiring the running parameters of the vehicle according to the detection result.
4. The abnormal flow alert method of claim 1 wherein the travel parameters include at least one of: vehicle speed, power-on information, driving duration and driving distance.
5. The abnormal flow warning method according to claim 4, wherein the running parameter includes the vehicle speed and the power-on information, the vehicle speed is greater than 0 and the warning threshold corresponding to the power-on information indicating that the vehicle is in the power-on state is a first warning threshold, the vehicle speed is equal to 0 and the warning threshold corresponding to the power-on information indicating that the vehicle is in the power-on state is a second warning threshold, and the vehicle speed is equal to 0 and the warning threshold corresponding to the power-on information indicating that the vehicle is in the power-off state is a third warning threshold;
Setting the second alarm threshold > the first alarm threshold > the third alarm threshold.
6. The abnormal traffic warning method according to any one of claims 1 to 5, characterized by, after said selecting whether to warn according to said data packet and said warning threshold value, further comprising:
and under the condition of selecting the alarm, displaying alarm information and processing button icons on a human-computer interaction interface of the vehicle, wherein after the processing button icons are clicked, the data packets of the alarm are processed according to the processing modes corresponding to the clicked processing button icons.
7. The abnormal traffic warning method according to any one of claims 1 to 5, characterized by further comprising, after said acquiring the data packet of the application to be analyzed:
identifying whether the data packet is an abnormal data packet;
and selecting an alarm under the condition that the data packet is identified as the abnormal data packet.
8. The abnormal traffic warning method according to claim 7 wherein the number of packets is greater than 1, and wherein the identifying whether the packet is an abnormal packet comprises:
determining transmission intervals of two data packets in each data packet group, wherein each data packet group comprises two adjacent data packets;
And identifying whether the data packet is an abnormal data packet according to the determined transmission intervals.
9. An abnormal flow warning device, characterized by being applied to a vehicle, comprising:
the data packet acquisition module is used for acquiring a data packet of the application to be analyzed;
the driving parameter acquisition module is used for acquiring the driving parameters of the vehicle;
the alarm threshold determining module is used for determining an alarm threshold corresponding to the application to be analyzed according to the identification of the application to be analyzed and the driving parameter;
and the alarm selection module is used for selecting whether to alarm according to the data packet and the alarm threshold value.
10. A vehicle comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 8 when the computer program is executed.
11. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1 to 8.
CN202310816803.3A 2023-07-04 2023-07-04 Abnormal flow alarming method, device, vehicle and readable storage medium Pending CN116684250A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310816803.3A CN116684250A (en) 2023-07-04 2023-07-04 Abnormal flow alarming method, device, vehicle and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310816803.3A CN116684250A (en) 2023-07-04 2023-07-04 Abnormal flow alarming method, device, vehicle and readable storage medium

Publications (1)

Publication Number Publication Date
CN116684250A true CN116684250A (en) 2023-09-01

Family

ID=87781070

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310816803.3A Pending CN116684250A (en) 2023-07-04 2023-07-04 Abnormal flow alarming method, device, vehicle and readable storage medium

Country Status (1)

Country Link
CN (1) CN116684250A (en)

Similar Documents

Publication Publication Date Title
US9888080B2 (en) Detection of mobile phone usage
EP2503516A2 (en) Idle detection for improving fuel consumption efficiency in a vehicle
JPH10507287A (en) Method and apparatus for detecting a fault condition in a vehicle data recording device
CN111369798A (en) Vehicle violation monitoring method, vehicle machine and vehicle
JP6258375B2 (en) Vehicle monitoring system, electronic device and vehicle monitoring method
CN104184801A (en) Integrated intelligent driving service system
CN110956715A (en) Driving recording method, driving recording system, cloud server and vehicle
CN112947137A (en) Hydrogen energy automobile control method, hydrogen energy automobile and Internet of things system
KR20160062259A (en) Method, system and computer readable medium for managing abnormal state of vehicle
CN112017459A (en) Vehicle, vehicle equipment and driving assistance method for signal lamp recognition thereof
CN111695956A (en) Intelligent service management method and system for automobile leasing platform and electronic equipment
EP4221158A1 (en) Method and system for controlling a non-interfering mode in a telematics device
CN116684250A (en) Abnormal flow alarming method, device, vehicle and readable storage medium
CN115534867A (en) Vehicle anti-theft method, device, vehicle and storage medium
CN111885492A (en) Automatic vehicle positioning method and electronic equipment
CN110316201B (en) Method, device and system for identifying sharp turn
CN115348149A (en) Equipment monitoring method and device in Internet of vehicles and terminal equipment
CN115909708A (en) Shared vehicle over-stop management method, system and device
CN212243228U (en) Vehicle-mounted T-BOX monitoring system and vehicle
CN114089119A (en) High-voltage loop fault positioning method and device, electric vehicle and storage medium
CN110320545B (en) Method, device and system for identifying sudden speed change
CN111741042A (en) Oil consumption, driving track and safe driving integrated remote monitoring system
CN113879313A (en) Driver fatigue detection method and device
CN112383706B (en) Collision photographing method, device and equipment based on automobile data recorder and storage medium
US20240096146A1 (en) Systems and methods for configuring a non-interfering mode in a telematics device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination