A vehicle networking business detection system

Abstract

The present invention relates to the field of vehicle networking technology, and discloses a vehicle networking business detection system. The present invention sends the data request package of the target business detection task to the terminal nodes deployed in different areas through the task scheduling node. The terminal node requests the vehicle networking cloud to call multiple interfaces of the target data corresponding to the target business based on the relevant configuration information of the parsed data request package, and waits for the vehicle networking cloud to return the response result of the target data corresponding to the target business. After the terminal node forwards the response result of the target data corresponding to the target business to the task scheduling node, the data monitoring module generates a monitoring report and performs an alarm action for the abnormal response result. Therefore, the present invention does not need to test the vehicle networking cloud monitoring on a large number of actual vehicles, thereby reducing the monitoring cost. At the same time, since the present invention does not require relevant personnel to participate in the test during the monitoring process, it not only reduces the monitoring cost but also improves the monitoring accuracy.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle networking, and in particular to a vehicle networking service detection system. Background Art

[0002] In recent years, with the advancement of intelligent vehicles, the demand for connected vehicle (IoV) services from automakers has been growing rapidly. The interactions between vehicles, applications (APPs), and the IoV cloud have also become increasingly complex and diverse. Therefore, monitoring the operational status of IoV services to ensure their stability has become a key concern.

[0003] In the actual monitoring test of the Internet of Vehicles, monitoring whether the Internet of Vehicles cloud can return data to the vehicle normally is an essential part of the Internet of Vehicles operation and maintenance.

[0004] In related technologies, actual vehicles are required to request data from the IoV cloud. Based on the data returned by the vehicle to the IoV cloud, it is determined whether the IoV cloud can normally return data to the vehicle, that is, whether the IoV cloud service is normal. To ensure a certain degree of credibility in the test results, a large number of tests are required. Therefore, a large number of actual vehicles and different types of actual vehicles need to participate in the tests. In addition, relevant personnel are required to participate in the tests, resulting in high costs for monitoring whether the IoV cloud can return data to the vehicle in the IoV. Summary of the Invention

[0005] In view of this, the present invention provides an Internet of Vehicles service detection system to solve the problem of high cost in monitoring whether an Internet of Vehicles cloud can return data to a vehicle in the Internet of Vehicles.

[0006] In a first aspect, the present invention provides a vehicle network service detection system, the system including: a data detection module, a data monitoring module, and a data configuration module, wherein the data detection module includes: a task scheduling node and terminal nodes distributed in multiple different areas.

[0007] The task scheduling node generates a target detection task based on the basic vehicle information of at least one vehicle to be detected that is controlled by the terminal node in at least one area, and generates a data request packet for accessing the target service from the Internet of Vehicles cloud based on the hardware configuration information of the vehicle to be detected associated with the target detection task configured by the data configuration module, and sends the data request packet of the target service to the terminal node.

[0008] The terminal node parses the hardware configuration information of the vehicle to be detected associated with the target detection task from the data request packet of the target business, and based on the hardware configuration information of the vehicle to be detected associated with the target detection task, requests the Internet of Vehicles cloud to call multiple interfaces of the target data corresponding to the target business. The Internet of Vehicles cloud returns the target data corresponding to the target business to the terminal node, and the terminal node then loads the target data corresponding to the target business into the data response packet and forwards the data response packet to the task scheduling node.

[0009] The task scheduling node parses the data response packet to obtain the response result of the target data corresponding to the target business.

[0010] The data monitoring module generates a monitoring report based on the response results of the target data corresponding to the target business, performs alarm actions for abnormal response results, and sends the monitoring report to the target user.

[0011] The vehicle network service detection system in the embodiment of the present disclosure sends a data request packet of the target service of the vehicle to be detected associated with the target detection task to the terminal nodes deployed in different areas through the task scheduling node. The terminal node parses the hardware configuration information of the vehicle to be detected associated with the target detection task from the data request packet of the target service, and requests the vehicle network cloud to call multiple interfaces of the target data corresponding to the target service. The vehicle network cloud returns the response result of the target data corresponding to the target service. After the terminal node forwards the response result of the target data corresponding to the target service to the task scheduling node, it generates a monitoring report through the data monitoring module and performs an alarm action for the abnormal response result. Therefore, the embodiment of the present disclosure does not need to test the vehicle network cloud monitoring on a large number of actual vehicles, thereby reducing the monitoring cost. At the same time, since the embodiment of the present disclosure does not require relevant personnel to participate in the test during the monitoring process, it not only reduces the monitoring cost but also improves the monitoring accuracy.

[0012] In some optional implementations, the basic vehicle information includes: vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information.

[0013] The task scheduling node includes: a task generation unit, which is used to generate a target detection task with a specified detection time and detection period based on the above-mentioned at least one vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected controlled by a terminal node in at least one area.

[0014] During the task detection process, the disclosed embodiment sends a data request package for the target detection task by the task scheduling node to the terminal nodes in different cities, and the terminal nodes initiate a request to the Internet of Vehicles cloud service, simulating real vehicles using the Internet of Vehicles cloud service in different cities. The task scheduling node replaces batches of vehicles to initiate target detection tasks to the Internet of Vehicles cloud, thereby reducing the Internet of Vehicles cloud's dependence on batches of real vehicles and thus reducing monitoring costs. At the same time, since the disclosed embodiment does not require relevant personnel to participate in the test during the monitoring process, it not only reduces monitoring costs but also improves monitoring accuracy.

[0015] In some optional embodiments, the Internet of Vehicles business detection system includes: a vehicle data management module for managing vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected that is controlled by a terminal node in at least one area; vehicle attribute information includes: vehicle model, series, color, size, and the area to which the vehicle belongs; vehicle identification information includes: vehicle identification number, manufacturer, factory, model, and year; vehicle hardware information includes: hardware information including vehicle serial number and integrated circuit card identification number.

[0016] The disclosed embodiment manages the vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected that is controlled by a terminal node in at least one area through a vehicle data management module, thereby enabling monitoring of different types of vehicles to determine whether the Internet of Vehicles cloud can return data to the vehicle normally, thereby enhancing the breadth and flexibility of vehicle monitoring.

[0017] In some optional embodiments, the hardware configuration information of the vehicle to be detected associated with the target detection task includes: interface attribute information corresponding to the target service, basic vehicle information of the vehicle to be detected associated with the target detection task, and basic user information of the vehicle to be detected associated with the target detection task. The interface attribute information corresponding to the target service includes an interface data list of multiple interfaces, interface dependencies, and interface data sources. The vehicle network service detection system further includes:

[0018] The data access module is used to access the vehicle terminal to send a task request to the Internet of Vehicles cloud, and obtain the interface data list, interface dependency, and interface data source of multiple interfaces corresponding to the task request.

[0019] In the disclosed embodiment, a data access module is used to access the interface data list, interface dependency, and interface data source of multiple interfaces corresponding to the task request sent by the vehicle terminal to the Internet of Vehicles cloud, thereby ensuring that when the terminal node initiates a request to access the target service to the Internet of Vehicles cloud, multiple interfaces of the target service are called.

[0020] In some optional embodiments, the data configuration module is used to configure the hardware configuration information of the vehicle to be detected based on the interface attribute information corresponding to the target business, the vehicle basic information of the vehicle to be detected associated with the target detection task, and the user basic information of the vehicle to be detected associated with the target detection task.

[0021] The disclosed embodiment configures the basic vehicle information associated with the target detection task, the interface attribute information corresponding to the target business of the vehicle to be detected, and the basic user information of the vehicle to be detected associated with the target detection task through a data configuration module. This information can be regarded as the virtual vehicle data of the vehicle to be detected, ensuring that the cloud side of the Internet of Vehicles can subsequently accurately call the terminal node to initiate access to multiple interfaces corresponding to the target business.

[0022] In some optional implementations, the system further includes: a first database for reading or storing hardware configuration information of a vehicle to be detected associated with a target detection task.

[0023] The embodiment of the present disclosure reads or stores the hardware configuration information of the vehicle to be detected associated with the target detection task through the first database, so that the task scheduling node obtains vehicle-related data information to form the target detection task, thereby preventing the hardware configuration information of the vehicle to be detected from being lost.

[0024] In some optional implementations, the response result of the target data corresponding to the target service includes: normal response information or abnormal response information, and the response time of each interface; the data monitoring module includes:

[0025] A report generation unit is used to generate monitoring detection data according to normal response information or abnormal response information and the response time of each interface through task alarm rules to obtain a monitoring report;

[0026] The report sending unit is used to send the monitoring report to the target user in a preset manner.

[0027] The disclosed embodiment uses a data monitoring module to monitor the response results of the terminal node initiating a request for target data corresponding to the target business, and generates monitoring detection data according to the task alarm rules, thereby actively discovering service problems in the Internet of Vehicles cloud, reducing the fault perception time, solving faults before customer complaints, and thus improving the stability of the Internet of Vehicles cloud service.

[0028] In some optional embodiments, the data monitoring module also includes: an alarm execution unit, which is used to execute alarm actions based on the monitoring detection data and task alarm rules. The monitoring detection data is based on normal response information or abnormal response information and the response time of each interface. The task alarm rules are generated based on static thresholds or dynamic thresholds. The dynamic threshold is predicted using a pre-trained neural network model.

[0029] The embodiment of the present disclosure executes an alarm action through an alarm execution unit to prevent abnormal failures from causing irreparable losses to the Internet of Vehicles.

[0030] In some optional implementations, the second database is used to read or store the response result of the target data corresponding to the target business.

[0031] The embodiment of the present disclosure stores the response results of the target data corresponding to the target business in the second database, so that the data monitoring module can obtain the corresponding results and related data to generate an alarm to prevent the data loss of the response results.

[0032] In some optional implementations, the basic user information includes: user name, password, email address, and mobile phone number. The system also includes: a user data management module for managing the basic user information and maintaining user lists and user permissions.

[0033] The embodiment of the present disclosure uses a user data management module to manage data information of different users, which is conducive to managing the Internet of Vehicles for different users. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0035] Figure 1 This is a structural block diagram of a vehicle networking service detection system according to an embodiment of the present invention;

[0036] Figure 2 is a structural block diagram of another vehicle networking service detection system according to an embodiment of the present invention;

[0037] Figure 3 This is a structural block diagram of another vehicle networking service detection system according to an embodiment of the present invention;

[0038] Figure 4 4 is a structural block diagram of another vehicle network service detection system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0039] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present invention.

[0040] In recent years, with the advancement of intelligent vehicles, the demand for connected vehicle (IoV) services from automakers has been increasing. The interactions between vehicles, applications (APPs), and the IoV cloud have become increasingly complex and diverse. Therefore, monitoring the operational status of IoV services to ensure their stability has become a key concern. In actual IoV operations, relying on logs and monitoring metrics from IoV cloud microservices often fails to directly resolve various issues and customer complaints on IoV cloud platforms. Instead, real-vehicle testing is required to further analyze the service failures based on the test results. For example, testers can navigate through various functional modules in a real vehicle and then, based on the actual interaction results and vehicle-side logs, locate the fault. This strong reliance on real vehicles can slow down fault location and introduce unmanageable costs.

[0041] That is, in related technologies, actual vehicles are required to request data from the IoV cloud. Whether the vehicle receives the data returned by the IoV cloud determines whether the IoV cloud can normally return data to the vehicle. To ensure the credibility of the test results, a large number of tests are required. Therefore, a large number of actual vehicles and different types of actual vehicles are required to participate in the tests. Furthermore, relevant personnel are required to participate in the tests, resulting in high costs for monitoring whether the IoV cloud can return data to the vehicle in the IoV.

[0042] Therefore, the embodiment of the present disclosure provides a vehicle network business detection system, which mainly uses a data detection module, a data monitoring module, and a data configuration module to form a design architecture for detecting the stability of vehicle network cloud business, simulates the interaction process between the vehicle side and the vehicle network cloud, and gets rid of the dependence on real vehicle auxiliary testing and vehicle-side log collection, thereby reducing the detection cost of vehicle network data.

[0043] In this embodiment, a vehicle network service detection system is provided. Figure 1As shown, the system includes: a data detection module 11, a data monitoring module 12, and a data configuration module 13, wherein the data detection module 11 includes: a task scheduling node 111 and terminal nodes 112 distributed in multiple different areas, and the terminal node 112 is communicatively connected to the Internet of Vehicles cloud 14, wherein the Internet of Vehicles cloud 14 serves as the object to be measured.

[0044] Specifically, multiple different regions may include but are not limited to multiple different cities, multiple different provinces and regions, multiple different counties and regions, multiple different villages, etc. The terminal node may be a server deployed in each region, and the task scheduling node may be a server that distributes scheduling tasks to terminal nodes in multiple different regions.

[0045] like Figure 2 The figure shows the overall architecture of the vehicle networking service detection system in the embodiment of the present disclosure. Figure 2 In the figure, it can be seen that the task scheduling node 111 in the data detection module 11 sends detection tasks to the terminal nodes 112 in different cities, and the terminal nodes 112 in different cities initiate detection requests to the Internet of Vehicles cloud 14 based on the detection tasks sent by the task scheduling node 111. Figure 2 There are also a data monitoring module 12 and a data configuration module 13.

[0046] The disclosed embodiment simulates the specific interaction process between the vehicle side and the Internet of Vehicles cloud through the design architecture of the data detection module, data monitoring module, and data configuration module. Please refer to the following content for details.

[0047] The task scheduling node generates a target detection task based on the basic vehicle information of at least one vehicle to be detected that is controlled by the terminal node in at least one area, and generates a data request packet for accessing the target service from the Internet of Vehicles cloud based on the hardware configuration information of the vehicle to be detected associated with the target detection task configured by the data configuration module, and sends the data request packet of the target service to the terminal node.

[0048] In a specific example, basic vehicle information includes vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information. Vehicle attribute information includes vehicle model, series, color, size, and region; vehicle identification information includes vehicle identification number, manufacturer, plant, model, and year; and vehicle hardware information includes hardware information including the vehicle serial number and integrated circuit card identification number.

[0049] For example, the terminal nodes in multiple different areas are: terminal node A in city 1, terminal node B in city 2, terminal node C in city 3, terminal node D in city 4, and terminal node E in city 5. On this basis, the task scheduling node M generates a target detection task based on the basic vehicle information of the above example of at least one vehicle to be detected controlled by the terminal nodes in any one or more of the above five cities.

[0050] Since traditional methods are basically aimed at specific regional network failure scenarios or failure scenarios of a specific model or series of vehicles, they cannot solve the problem of whether the Internet of Vehicles cloud can return data normally to the vehicles when monitoring real vehicles in non-fault areas or non-corresponding models and series.

[0051] The embodiment of the present disclosure deploys terminal nodes in different areas to realize data service monitoring of the interaction between vehicles in different areas and the Internet of Vehicles cloud. By generating target detection tasks through the task scheduling node based on the basic vehicle information of at least one vehicle to be detected controlled by the terminal nodes in at least one area, it is possible to realize data service monitoring of the interaction between batch vehicles of different specific areas and different types and the Internet of Vehicles cloud.

[0052] Table 1 below is a detailed diagram of the task scheduling node sending detection tasks to terminal nodes in different cities.

[0053] Table 1

[0054]

[0055] In another specific example, Figure 3 As shown, the task scheduling node 111 includes: a task generating unit 1111, which is used to generate a target detection task with a specified detection time and detection period based on at least one vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected controlled by a terminal node in at least one area. Figure 3 In the system, there is also a data detection module 11, a data monitoring module 12, a data configuration module 13 and an IoV cloud 14. The data detection module 11 includes a task scheduling node 111 and terminal nodes 112 distributed in multiple different areas. This has been explained above and will not be repeated here.

[0056] For example, when the task scheduling node M performs task detection, the task generation unit controls the vehicle attribute information of at least one vehicle to be detected, including the model, series, color, size, and area to which the vehicle belongs, according to any one city (city 1 or city 2 or city 3 or city 4 or city 5) or multiple cities (city 1, city 2, city 3, city 4, city 5) in Table 1 above, and generates a target detection task with a specified detection time and detection period. For example, in Table 1 above, the target detection task can be generated based on the vehicle attribute information of the model, series, color, size, and area to which the vehicle belongs of vehicles 41, 42, 43, and 44 controlled by the terminal node C in city 3, and a target detection task with a specified detection time and detection period. For example, in Table 1 above, the target detection task can also be generated based on the vehicle attribute information of the model, series, color, size, and area to which the vehicle belongs of vehicles 41, 42, 43, and 44 controlled by the terminal node C in city 3, and vehicles 51, 52, and 53 controlled by the terminal node E in city 5, and a target detection task with a specified detection time and detection period.

[0057] To generate a target detection task with a specified detection time and period, for example, when performing target business detection, you need to select the detection period and detection time for the target detection task. For example, you can select immediate detection or scheduled detection to initiate a periodic target detection task. Periodic target detection tasks include: issuing a battery check command to the vehicle being detected every minute, issuing a command to turn on the air conditioner at 6:00 PM every day, and so on.

[0058] The disclosed embodiment performs function-level stress testing on the IoV cloud service, i.e., initiating access requests for target services to the IoV cloud through terminal nodes, simulating batches of real vehicles to initiate large-scale function detection to the IoV cloud, thereby achieving the effect of simulating peak traffic or hot events, improving the capacity management capabilities of the IoV cloud service, and at the same time reducing costs and dependence on real vehicle testing. There is no need to purchase real vehicles, and the vehicle scale can grow arbitrarily.

[0059] Furthermore, the above-mentioned data configuration module is used to configure the hardware configuration information of the vehicle to be detected associated with some target detection tasks. The above-mentioned vehicle basic information can be regarded as the virtual vehicle data of the vehicle to be detected. These virtual vehicle data can be managed by the vehicle data management module, and the virtual vehicle data can be added or modified in the vehicle data management module.

[0060] The target services mentioned above include, but are not limited to, vehicle-mounted data usage inquiries, music playback, and remote vehicle control commands. For example, the task scheduling node M in the above example generates a data request packet for accessing the target service (music playback) from the IoV cloud based on the hardware configuration information of vehicles 41, 42, 43, and 44 in city 3 associated with the target detection task, as configured by the data configuration module.

[0061] In a specific example, the hardware configuration information of the vehicle to be detected associated with the target detection task includes: interface attribute information corresponding to the target business, vehicle basic information of the vehicle to be detected associated with the target detection task, and user basic information of the vehicle to be detected associated with the target detection task. The interface attribute information corresponding to the target business includes interface data lists of multiple interfaces, interface dependencies, and interface data sources.

[0062] The terminal node in the above-mentioned process parses the hardware configuration information of the vehicle to be detected associated with the target detection task from the data request packet of the target business, and based on the hardware configuration information of the vehicle to be detected associated with the target detection task, requests the Internet of Vehicles cloud to call multiple interfaces of the target data corresponding to the target business. The Internet of Vehicles cloud returns the target data corresponding to the target business to the terminal node, and the terminal node then loads the target data corresponding to the target business into the data response packet and forwards the data response packet to the task scheduling node.

[0063] Traditionally, the stability of cloud services is determined by probing a single interface on the IoV cloud. However, vehicle service flows are composed of a series of interfaces organized in a logical sequence, each providing smooth service functionality through interdependent relationships. In the actual interaction between the vehicle and the IoV cloud, assuming the vehicle sends a request to the IoV cloud through a single, unified interface and then verifies the return value, the correctness of the vehicle service functionality cannot be accurately inferred. Therefore, the disclosed embodiments employ service services with multiple interfaces.

[0064] In a specific example, the interface attribute information corresponding to the target service includes an interface data list of multiple interfaces, interface dependencies, and interface data sources, thereby improving the continuity, completeness, and accuracy of the target data corresponding to the target service responded by the Internet of Vehicles cloud when the terminal node requests to access the target service from the Internet of Vehicles cloud.

[0065] Specifically, the target data is specific data corresponding to the target service. For example, if the target service is playing music, the target data is specific music content corresponding to the played music.

[0066] The task scheduling node in the above example parses the data response packet to extract the target data response result corresponding to the target business. The data monitoring module generates a monitoring report based on the target data response result corresponding to the target business, performs an alarm action for abnormal response results, and sends the monitoring report to the target user.

[0067] In a specific example, the response result includes: normal response information or abnormal response information, and the response time of each interface. The monitoring report includes: monitoring detection data and task alarm rules.

[0068] The data detection module in the disclosed embodiment is divided into a task scheduling node and a terminal node. The task scheduling node is responsible for combining target detection tasks, sending them to the terminal node, and receiving the detection results of the terminal node. The terminal node can be deployed in the computer room of different cities or different operators, and is responsible for simulating the vehicle to be tested to initiate a service request to the Internet of Vehicles cloud. The task scheduling node generates a data request packet for accessing the target service from the Internet of Vehicles cloud based on the hardware configuration information of the vehicle to be detected associated with the target detection task configured by the data configuration module. The terminal node parses the data request packet sent by the task scheduling node and initiates a task interface request to the Internet of Vehicles cloud. The Internet of Vehicles cloud responds to the task interface request, thereby simulating the data interaction between the real vehicle and the Internet of Vehicles cloud, and achieving the purpose of verifying and testing whether the Internet of Vehicles platform and the Internet of Vehicles cloud service are normal.

[0069] In summary, the Internet of Vehicles service detection system in the embodiment of the present disclosure uses terminal nodes deployed in different areas to send an interface call request for a data request packet of a target service of a vehicle to be detected, which is associated with a target detection task generated by a task scheduling node, to the Internet of Vehicles cloud, and waits for the Internet of Vehicles cloud to return a response result of target data corresponding to the target service generated by multiple interfaces according to the interface request. After the terminal node forwards the response result of the target data corresponding to the target service to the task scheduling node, it generates a monitoring report through the data monitoring module and performs an alarm action for abnormal response results. Therefore, the embodiment of the present disclosure does not need to test the Internet of Vehicles cloud monitoring on a large number of actual vehicles, thereby reducing monitoring costs. At the same time, since the embodiment of the present disclosure does not require relevant personnel to participate in the test during the monitoring process, it not only reduces monitoring costs but also improves monitoring accuracy.

[0070] In this embodiment, a specific vehicle network service detection system is also provided. Figure 4As shown, it includes: data detection module 11, data monitoring module 12, data configuration module 13, wherein the data detection module 11 includes: task scheduling node 111 and terminal nodes 112 distributed in multiple different areas. Among them, the data monitoring module 12 includes: report generation unit 121, report sending unit 122 and alarm execution unit 123. The terminal node 112 is connected to the Internet of Vehicles cloud 14 for communication, wherein the Internet of Vehicles cloud 14 is the object to be measured. On this basis, Figure 4 In the embodiment of the present disclosure, the vehicle network service detection system further includes: a vehicle data management module 15, a data access module 16, a first database 17, a second database 18, and a user data management module 19.

[0071] exist Figure 4 In the example, the first database 17 is used to read or store the hardware configuration information of the target vehicle associated with the target detection task. Furthermore, the first database 17 stores basic vehicle information such as vehicle attributes, vehicle identification, vehicle function, and vehicle hardware information, as well as basic user information such as username, password, email address, and mobile phone number, and static data in the monitoring report. The second database 18 is used to read or store the response results of the target data corresponding to the target business. Furthermore, the second database 18 stores the time series data in the monitoring report.

[0072] Among them, Figure 4 The vehicle data management module 15 is used to manage the vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected that is controlled by a terminal node in at least one area; the vehicle attribute information includes: vehicle model, series, color, size, and the area to which the vehicle belongs; the vehicle identification information includes: vehicle identification number, manufacturer, factory, model, and year; the vehicle hardware information includes: hardware information including the vehicle serial number and integrated circuit card identification number.

[0073] Specifically, the vehicle data management module is used to manage a list of vehicle series for at least one vehicle to be detected, controlled by a terminal node within at least one region. For example, it manages a list of vehicle series for at least one vehicle to be detected, controlled by a terminal node within any one or more cities, as shown in Table 1 above. This list of vehicle series can be manually imported by the target user or synchronized from the IoV cloud service. A series refers to a series of related models under a particular brand, typically sharing common design elements, technical platforms, or market positioning. Examples include the BMW X-Series and Mercedes-Benz C-Class. A model refers to a specific product line or model under a particular brand. Each model typically has specific design styles, dimensions, and technical features, and is categorized into different versions or configurations, such as luxury, sport, and comfort. In the disclosed embodiments, the detection target is the target service of the IoV cloud service. Due to differences in hardware configuration between vehicle series and models, the functionality of the same service may vary across different vehicle series and models. Therefore, it is necessary to define the vehicle series and models that can be observed in the IoV service detection system. Furthermore, when a new model is launched, the corresponding model year must be added to the vehicle data management module.

[0074] The vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected that is controlled by a terminal node in at least one of the aforementioned areas may be regarded as virtual vehicle data of the vehicle to be detected.

[0075] The vehicle identification number (VIN) in the vehicle identification information mentioned above is a 17-character unique identifier used to identify each specific vehicle. Vehicle identification information also includes the manufacturer, make, model, and year. This information is a crucial parameter for providing various services in the IoV cloud. Therefore, when a terminal node simulates a target vehicle and exchanges data with the IoV cloud, it requires the vehicle data management module to provide the target vehicle's data. For example, it requires the target vehicle's model VIN code, and uses a flag to identify this VIN code as the simulated target vehicle. When adding virtual vehicle data for the target vehicle to the vehicle data management module in the disclosed embodiment, the VIN code parsing rules for the vehicle model management are invoked to generate the corresponding VIN code. This disclosed embodiment maps information such as model and year to the fixed bits of the VIN code, generating a virtual vehicle identification placeholder in the non-fixed bits. Therefore, the vehicle data management module has the ability to parse VIN codes.

[0076] The vehicle function information mentioned above may specifically include but is not limited to the detailed management of vehicle model functions. For example, the remote vehicle control function has the ability to open the trunk in some models, but not in some models. When adding a new vehicle model in the embodiment of the present disclosure, it is necessary to synchronize the function details of the actual vehicle model online. In addition, the functions of different models vary depending on the year, and it is necessary to distinguish the functions of the models synchronized by year. The embodiment of the present disclosure supports synchronizing the function list of the actual vehicle model from the Internet of Vehicles cloud service, or manually importing the vehicle model functions.

[0077] The vehicle serial number in the vehicle hardware information is called the SN number. The integrated circuit card identification number in the vehicle hardware information is called the ICCID number. For example, the embodiment of the present disclosure can generate hardware information corresponding to the vehicle model based on the mapping relationship between the SN number and the ICCID number.

[0078] Since the traditional method is based on the failure scenario of a specific model or series, it cannot solve the problem of whether the Internet of Vehicles cloud can return data normally to the vehicle when monitoring a real vehicle of a non-corresponding model or series. That is, this method has some limitations.

[0079] The disclosed embodiment manages the vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected that is controlled by a terminal node in at least one area through a vehicle data management module, thereby enabling monitoring of different types of vehicles to determine whether the Internet of Vehicles cloud can return data to the vehicle normally, thereby enhancing the breadth and flexibility of vehicle monitoring.

[0080] The hardware configuration information of the vehicle to be detected associated with the target detection task includes: the interface attribute information corresponding to the target business, and the interface attribute information corresponding to the target business includes the interface data list of multiple interfaces, interface dependency, and interface data source. Because in the traditional way, the stability of the cloud service is generally judged by detecting a single interface of the Internet of Vehicles cloud. However, the vehicle business service process is composed of a series of multiple interfaces organized in a logical order, and multiple interfaces provide smooth business function services through the dependency relationship between the front and the back. In the actual interaction process between the vehicle side and the Internet of Vehicles cloud, assuming that the vehicle side sends a request to the Internet of Vehicles cloud through a unified single interface and then verifies the return value, it cannot be well inferred that the correctness of the vehicle business function service. Therefore, business services with multiple interfaces are adopted in the embodiment of the present disclosure.

[0081] The hardware configuration information of the vehicle to be detected associated with the target detection task includes: interface attribute information corresponding to the target service.

[0082] In a specific example, the interface attribute information corresponding to the target service includes the interface data list, interface dependency, and interface data source of multiple interfaces, thereby improving the continuity, integrity, and accuracy of the target data corresponding to the target service in the Internet of Vehicles cloud when the terminal node requests the Internet of Vehicles cloud to access the target service.

[0083] The data access module is used to access the vehicle terminal to send a task request to the Internet of Vehicles cloud, and obtain the interface data list, interface dependency, and interface data source of multiple interfaces corresponding to the task request.

[0084] Specifically, the target business in the embodiments of the present disclosure is some business functions that can be provided by the Internet of Vehicles cloud, which refers to the atomic capabilities of the Internet of Vehicles business services, such as vehicle-machine traffic usage query, music playback, remote vehicle control commands, etc. Among them, a business function usually initiates target business requests for multiple interfaces to the Internet of Vehicles cloud service, and there are logical dependencies between the interfaces.

[0085] It should be noted that, as mentioned above, the detection of the Internet of Vehicles cloud service function in the embodiment of the present disclosure is a combination of a series of interfaces, not a single interface. Therefore, it is necessary to ensure the accuracy of the interface logic and the sequential dependency relationship involved in the entered functions. Inaccurate interface entry will not achieve the purpose of Internet of Vehicles business detection. Generally, the vehicle-side request sends an interface request to the Internet of Vehicles cloud through the vehicle-side SDK. By obtaining the SDK log when a certain business function is used from the Internet of Vehicles cloud, the interface logic and sequential dependency relationship involved in the function can be obtained, that is, the interface data list of the business function can be obtained.

[0086] Therefore, in the embodiment of the present disclosure, access is made through the data access module. When the vehicle-side requests a task from the Internet of Vehicles cloud, the vehicle-side and the Internet of Vehicles cloud interact to perform specific tasks, and the interface data list, interface dependency, and interface data source of the corresponding multiple interfaces are obtained, thereby ensuring that when the terminal node initiates a request to access the target business to the Internet of Vehicles cloud, the Internet of Vehicles cloud can accurately call multiple interfaces of the target business.

[0087] exist Figure 4 In the data configuration module 13, the data configuration module is used to configure the hardware configuration information of the vehicle to be detected according to the interface attribute information corresponding to the target service, the vehicle basic information of the vehicle to be detected associated with the target detection task, and the user basic information of the vehicle to be detected associated with the target detection task.

[0088] Specifically, as explained above, the basic vehicle information of the vehicle to be detected includes: vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information. Vehicle attribute information includes: vehicle model, series, color, size, and region; vehicle identification information includes: vehicle identification number, manufacturer, plant, model, and year; vehicle hardware information includes: hardware information such as the vehicle serial number and integrated circuit card identification number. As explained above, the interface attribute information corresponding to the target service of the vehicle to be detected includes: interface data lists, interface dependencies, and interface data sources for multiple interfaces.

[0089] The above-mentioned basic vehicle information of the vehicle to be detected, the interface attribute information corresponding to the target service of the vehicle to be detected, and the basic user information of the vehicle to be detected associated with the target detection task can be regarded as virtual vehicle data of the vehicle to be detected.

[0090] When detecting target data corresponding to target services in the cloud of the Internet of Vehicles, the disclosed embodiment can perform addition, deletion, modification, and query operations on the virtual vehicle data used through the vehicle data management module, and batch operations can be performed. In the above-mentioned vehicle data management module, the basic vehicle information of the added vehicles to be detected can be configured in the data configuration module. In the data configuration module, the interface attribute information corresponding to the target service of the vehicle to be detected, the basic vehicle information of the vehicle to be detected associated with the target detection task (vehicle attribute information, vehicle identification information, vehicle function information, vehicle hardware information), and the basic user information of the vehicle to be detected associated with the target detection task (user name, password, email address, mobile phone number) are configured. The above-mentioned basic vehicle information can be retrieved from the vehicle data management module through the data configuration module, and the above-mentioned basic user information can be retrieved from the user data management module. For example, the data configuration module retrieves the VIN code, ICCID number, and SN number information from the vehicle data management module. After the data configuration module completes the configuration of the virtual vehicle data, the hardware configuration information of the vehicle to be detected is stored in the first database after configuration is completed for use in subsequent business function detection.

[0091] The response results of the target data corresponding to the target business mentioned above include: normal response information or abnormal response information, and the response time of each interface; Figure 4In the data monitoring module 12, it includes: a report generating unit 121, which is used to generate monitoring detection data according to normal response information or abnormal response information, the response time of each interface, and the task alarm rule to obtain a monitoring report; a report sending unit 122, which is used to send the monitoring report to the target user in a preset manner; an alarm execution unit 123, which is used to execute an alarm action according to the monitoring detection data and the task alarm rule, the monitoring detection data is generated according to the normal response information or abnormal response information, and the response time of each interface, the task alarm rule is generated according to the static threshold or the dynamic threshold, and the dynamic threshold is predicted using a pre-trained neural network model.

[0092] Specifically, a normal response message means that the terminal node accessed the target data corresponding to the target service from the IoV cloud, and the IoV cloud was able to successfully return the data. An abnormal response message means that the terminal node accessed the target service data corresponding to the target service from the IoV cloud, but the IoV cloud failed to return the data. For example, if the terminal node requested access to the IoV cloud's music playback service function, but the IoV cloud encountered an exception when calling multiple APIs for the music playback function, the IoV cloud would feedback an abnormal response message.

[0093] In the embodiment of the present disclosure, when an abnormal fault occurs, the terminal node returns the return value of the Internet of Vehicles cloud to the terminal node, thereby locating the vehicle-side fault or the Internet of Vehicles cloud fault. Based on the different cities and operators to which the terminal node belongs, it is determined whether it is a regional network problem.

[0094] In the data monitoring module of the disclosed embodiments, continuous monitoring and alarming can be performed on the response results of target data corresponding to target services stored in a time series in the second database. Based on normal or abnormal response information, as well as the response time of each interface, a detection task monitoring curve (monitoring detection data) is plotted, providing monitoring and detection capabilities. Task alarm rules are divided into static thresholds and dynamic thresholds. In the disclosed embodiments, the corresponding alarm rule is selected based on different usage scenarios. Static thresholds are a traditional alarm method. Users must pre-set specific values ​​as alarm conditions. Once the actual monitored value exceeds or falls below the preset value, an alarm is triggered. Dynamic thresholds are an alarm mechanism based on machine learning algorithms. They can automatically identify and adapt to historical data patterns (such as periodicity, trends, and fluctuations) of monitoring indicators, dynamically calculating upper and lower alarm boundaries for each instance. There are many methods for implementing dynamic thresholds, including but not limited to support vector machines (SVMs), random forests, and long short-term memory networks (LSTMs). These models can learn abnormal patterns from large amounts of historical data and automatically adjust thresholds to adapt to different situations. The present invention uses an autoregressive integrated moving average (ARIMA) model. The ARIMA model is a time series forecasting model that captures both cyclical and trend components in historical data. It can be used to predict future values ​​and set dynamic thresholds based on the forecast results.

[0095] As a specific example, for example, the terminal node requests to access the music playing service function of the Internet of Vehicles cloud, but when the Internet of Vehicles cloud calls multiple interfaces for playing music, if the response time of any interface for playing music exceeds the preset threshold, the report generation unit generates monitoring detection data, obtains a monitoring report, and then sends the monitoring report to the target user through the report sending unit in a preset manner, and finally uses the alarm execution unit to execute the alarm action.

[0096] Specifically, the report sending unit is used to send monitoring reports to the target user via a preset method, including but not limited to email, text message, phone call, and chat tools. For example, an alarm email can be sent to a specified email address. SMS can send an alarm message to a specified mobile phone number. Phone calls can dial a specified phone number and automatically play the alarm message. Chat tools can send alarm messages through tools such as WeChat for Business, DingTalk, and Slack.

[0097] In addition, the monitoring report of the data monitoring module records detailed information of each alarm, including time, indicators, thresholds, notification methods, etc. It also provides statistical information such as the number of alarms, alarm types, and alarm frequencies.

[0098] The disclosed embodiment uses a data monitoring module to monitor time series data such as response information of target data corresponding to a request for a target business initiated by a terminal node. If the alarm threshold is reached, it indicates that the Internet of Vehicles cloud service is abnormal, thereby proactively discovering Internet of Vehicles cloud service problems, reducing the fault perception time, resolving faults before customer complaints, and improving the stability of the Internet of Vehicles cloud service.

[0099] exist Figure 4 The user data management module 19 is used to manage basic user information and maintain user lists and user permissions. Basic user information includes: user name, password, email address, and mobile phone number. The user list includes user permissions.

[0100] Therefore, the embodiment of the present disclosure forms a vehicle network business detection system through a data detection module, a data monitoring module, a data configuration module, a vehicle data management module, a data access module, a first database, a second database, and a user data management module. Since there is no need to test the vehicle network cloud monitoring on a large number of actual vehicles, the monitoring cost is reduced. At the same time, since the embodiment of the present disclosure does not require relevant personnel to participate in the testing during the monitoring process, it not only reduces the monitoring cost but also improves the monitoring accuracy.

[0101] The vehicle networking service detection system in the embodiment of the present disclosure is as follows: Figure 4 As shown, the task detection process specifically includes the following steps:

[0102] In the first step, the task scheduling node 111 generates a target detection task with a specified detection time and detection period based on the basic vehicle information of at least one vehicle to be detected, which is controlled by the terminal node 112 in at least one area. For example, the task scheduling node 111 sends the target detection task to the terminal node. If the target detection task is an immediate detection task, a detection request is immediately initiated. If the target detection task is a scheduled task or a periodic task, the terminal node sets the detection time according to a preset time or preset period, and when the detection time arrives, the terminal node 112 executes the corresponding task. The basic vehicle information is information obtained by the task scheduling node 111 from the first database 17. The basic vehicle information includes vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information. Vehicle attribute information includes vehicle model, series, color, size, and region. Vehicle identification information includes vehicle identification number, manufacturer, plant, model, and year. Vehicle hardware information includes hardware information including vehicle serial number and integrated circuit card identification number.

[0103] In the second step, task scheduling node 111 generates a data request packet for accessing the target service from IoV cloud 14 based on the hardware configuration information of the target detection task associated with the task configured by data configuration module 13, and sends the data request packet for the target service to terminal node 112. Data configuration module 13 obtains the interface data list, interface dependencies, and interface data source information corresponding to the target service from data access module 16. It then configures the hardware configuration information of the target vehicle based on the interface attribute information corresponding to the target service, the basic vehicle information of the target detection task associated with the target detection task, and the basic user information of the target detection task associated with the target vehicle.

[0104] In the third step, the terminal node 112 parses the hardware configuration information of the vehicle to be detected associated with the target detection task from the data request packet of the target business, and based on the hardware configuration information of the vehicle to be detected associated with the target detection task, requests the Internet of Vehicles cloud 14 to call multiple interfaces of the target data corresponding to the target business, that is, the terminal node 112 requests the Internet of Vehicles cloud 14 to provide the vehicle information and function information required for the target business service and bring it into the multiple interfaces of the target business.

[0105] In the fourth step, the Internet of Vehicles cloud 14 returns the target data corresponding to the target business to the terminal node.

[0106] In the fifth step, the terminal node 112 loads the target data corresponding to the target service into a data response packet, and forwards the data response packet to the task scheduling node.

[0107] In the sixth step, the task scheduling node 111 parses the data response packet to extract the target data response corresponding to the target business. Specifically, the terminal node 112 returns the response result from the IoV cloud to the task scheduling node 111, which then stores the execution result, the return values ​​of each interface, and the response time in a second database 18 (a time series database (TSDB)) for persistence.

[0108] In the seventh step, the data monitoring module 12 generates a monitoring report based on the response result of the target data corresponding to the target business, performs an alarm action for the abnormal response result, and sends the monitoring report to the target user.

[0109] The embodiment of the present disclosure uses the above-mentioned Internet of Vehicles business detection system. During the execution of task detection, the task scheduling node sends the target detection task to the terminal nodes in different cities, and the terminal nodes initiate requests to the Internet of Vehicles cloud service. This simulates real vehicles using Internet of Vehicles cloud services in different cities. After the request is completed, the terminal node uploads the return value, response time and other information to the task scheduling node for storage. The data monitoring module monitors time series data such as request status and response information. If the alarm threshold is reached, it indicates that the Internet of Vehicles cloud service is abnormal. Therefore, the embodiment of the present disclosure uses the task scheduling node instead of the Internet of Vehicles cloud to initiate target detection tasks to batches of vehicles, thereby reducing the Internet of Vehicles cloud's dependence on batches of real vehicles, thereby reducing monitoring costs. At the same time, since the embodiment of the present disclosure does not require relevant personnel to participate in the test during the monitoring process, it not only reduces monitoring costs but also improves monitoring accuracy.

[0110] Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention. Such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A vehicle networking service detection system, characterized in that: The system includes: a data detection module, a data monitoring module, and a data configuration module, wherein the data detection module includes: a task scheduling node and terminal nodes distributed in multiple different areas; The task scheduling node generates a target detection task based on basic vehicle information of at least one vehicle to be detected that is controlled by a terminal node in at least one area, generates a data request packet for accessing a target service from the Internet of Vehicles cloud based on hardware configuration information of the vehicle to be detected associated with the target detection task configured by the data configuration module, and sends the data request packet for the target service to the terminal node; The terminal node parses the hardware configuration information of the vehicle to be detected associated with the target detection task from the data request packet of the target service, and requests the Internet of Vehicles cloud to call multiple interfaces of the target data corresponding to the target service based on the hardware configuration information of the vehicle to be detected associated with the target detection task. The Internet of Vehicles cloud returns the target data corresponding to the target service to the terminal node, and the terminal node loads the target data corresponding to the target service into a data response packet and forwards the data response packet to the task scheduling node; the hardware configuration information of the vehicle to be detected associated with the target detection task includes: interface attribute information corresponding to the target service, and the interface attribute information corresponding to the target service includes an interface data list, interface dependency, and interface data source of the multiple interfaces; The task scheduling node parses the data response packet to obtain a response result of the target data corresponding to the target service; The data monitoring module generates a monitoring report based on the response result of the target data corresponding to the target business, performs an alarm action for abnormal response results, and sends the monitoring report to the target user.

2. The vehicle networking service detection system according to claim 1, characterized in that: The basic vehicle information includes: vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information; The task scheduling node includes: a task generation unit, which is used to generate a target detection task with a specified detection time and detection period based on at least one of the above-mentioned vehicle attribute information, vehicle identification information, vehicle function information, and vehicle hardware information of at least one vehicle to be detected controlled by a terminal node in at least one area.

3. The vehicle networking service detection system according to claim 2, characterized in that: Also includes: a vehicle data management module, configured to manage the vehicle attribute information, the vehicle identification information, the vehicle function information, and the vehicle hardware information of at least one vehicle to be detected and controlled by a terminal node within the at least one area; The vehicle attribute information includes: vehicle model, series, color, size, and the region to which the vehicle belongs; the vehicle identification information includes: vehicle identification number, manufacturer, factory, model, and year; the vehicle hardware information includes: hardware information including vehicle serial number and integrated circuit card identification number.

4. The vehicle networking service detection system according to claim 1, characterized in that: The hardware configuration information of the vehicle to be detected associated with the target detection task also includes: basic vehicle information of the vehicle to be detected associated with the target detection task, basic user information of the vehicle to be detected associated with the target detection task, and the Internet of Vehicles service detection system also includes: The data access module is used to obtain the interface data list, interface dependency, and interface data source of the multiple interfaces corresponding to the task request when the vehicle terminal sends a task request to the Internet of Vehicles cloud.

5. The vehicle networking service detection system according to claim 4, characterized in that: A data configuration module is used to configure the hardware configuration information of the vehicle to be detected according to the interface attribute information corresponding to the target service, the basic vehicle information of the vehicle to be detected associated with the target detection task, and the basic user information of the vehicle to be detected associated with the target detection task.

6. The vehicle networking service detection system according to claim 1, 4 or 5, characterized in that: Also includes: The first database is used to read or store hardware configuration information of the vehicle to be detected associated with the target detection task.

7. The vehicle networking service detection system according to claim 1, characterized in that: The response result of the target data corresponding to the target business includes: normal response information or abnormal response information, and the response time of each interface; the data monitoring module includes: A report generating unit, configured to generate monitoring detection data according to the normal response information or the abnormal response information and the response time of each interface through a task alarm rule to obtain a monitoring report; The report sending unit is used to send the monitoring report to the target user in a preset manner.

8. The vehicle networking service detection system according to claim 7, characterized in that: The data monitoring module also includes: an alarm execution unit, which is used to execute the alarm action based on the monitoring detection data and the task alarm rules. The monitoring detection data is generated based on the normal response information or the abnormal response information and the response time of each interface. The task alarm rules are generated based on the static threshold or the dynamic threshold. The dynamic threshold is predicted using a pre-trained neural network model.

9. The vehicle networking service detection system according to claim 1, 7 or 8, characterized in that: The second database is used to read or store the response result of the target data corresponding to the target business.

10. The vehicle networking service detection system according to claim 4, characterized in that: The basic user information includes: user name, password, email address, and mobile phone number. The system also includes: a user data management module for managing basic user information and maintaining user lists and user permissions.

Images