Method and device for analyzing dormancy abnormity of automobile network and computer equipment

Abstract

The invention relates to the technical field of automobile networks, and discloses an automobile network dormancy abnormity analysis method and device and computer equipment, and the analysis method comprises the steps: obtaining first log data recorded by a domain controller in an automobile network abnormal state, the first log data is used for storing working information of a software layer in the automobile network anomaly time domain controller; acquiring second log data recorded by the domain controller in an automobile network recovery state, wherein the second log data is used for storing working information of a software layer in the automobile network recovery time domain controller; and based on the first log data and the second log data, carrying out positioning analysis on the abnormal trigger source of the automobile network. According to the invention, the problem that the automobile network dormancy abnormity is difficult to accurately position in the related technology is solved, and the positioning accuracy of the automobile network dormancy abnormity is improved.

Description

Technical Field

[0001] The present invention relates to the field of automobile technology, and in particular to a method, device and computer equipment for analyzing automobile network dormancy anomalies. Background Art

[0002] Related technologies for locating abnormalities during vehicle network hibernation rely primarily on static current or wakeup times. However, these indicators can be affected by environmental factors (such as temperature and humidity) or non-controller factors (such as sensor noise), leading to misjudgments. Positioning accuracy is insufficient for abnormal wakeups in complex networks (e.g., with multiple network segments and multiple controllers).

[0003] In summary, in the related art, it is difficult to accurately locate an anomaly that occurs during vehicle network dormancy. Summary of the Invention

[0004] In view of this, the present invention provides a method for analyzing automobile network anomalies to solve the problem in the related art that automobile network sleep anomalies are difficult to accurately locate.

[0005] In a first aspect, the present invention provides a method for analyzing sleep anomalies in an automobile network. The automobile network includes a communication network consisting of network ports, network protocols, gateways, or switches of a domain controller and a central domain controller. The analysis method is applied to the central domain controller and includes:

[0006] Acquire first log data recorded by the domain controller when the vehicle network is abnormal, where the first log data is used to store working information of a software layer in the domain controller when the vehicle network is abnormal;

[0007] obtaining second log data recorded by the domain controller in a vehicle network recovery state, the second log data being used to store working information of a software layer in the domain controller when the vehicle network is recovered;

[0008] Based on the first log data and the second log data, a trigger source of the automobile network anomaly is located and analyzed.

[0009] The present invention records the log data of the application layer in the software layer of the domain controller when an automobile network anomaly occurs; when the automobile network recovers, it records the log data of the application layer in the software layer of the domain controller calling the bottom layer output, providing a sufficient data analysis source for automobile network anomalies. By analyzing the above log data, the positioning accuracy of the trigger source of the automobile network dormancy anomaly is improved.

[0010] In an optional embodiment, the software layer includes an application layer, and obtaining first log data recorded by the domain controller in an abnormal state of the automobile network includes:

[0011] Detect network request anomalies of the domain controller, locate the local abnormal network through network grouping, and control the domain controller to record multiple first log data output by different applications in the application layer.

[0012] This embodiment provides log data output by multiple applications at the application layer during network anomalies for locating automobile network anomalies, which helps to finely analyze the operating status of different applications in the domain controller and detect the trigger source of the network anomaly.

[0013] In an optional embodiment, the software layer includes a bottom layer, and obtaining second log data recorded by the domain controller in a vehicle network recovery state includes:

[0014] Detect network request recovery of the domain controller, control the domain controller to record function log data output by the application layer, control the domain controller to record service log data output by the bottom layer, and control the domain controller to record call log data output by the application layer calling the bottom layer;

[0015] Receive function log data, service log data, and call log data;

[0016] The function log data, service log data, and call log data are combined into the second log data.

[0017] Compared to related technologies that only record application-layer log data, this implementation not only records the functional log data output by the domain controller's software layer, but also the service log data output by the underlying software layer. Furthermore, it also records the call log data generated by the application layer calling the underlying layer. This increased log data diversity provides a comprehensive data source for locating vehicle network sleep anomalies.

[0018] In an optional implementation, the control domain controller records a plurality of first log data output by different applications of the application layer, including:

[0019] Controlling the domain controller to run the application layer, and outputting a first exception log of a first application of the application layer in a runtime environment and storing the first exception log in a log storage unit of the domain controller;

[0020] The control domain controller runs the application layer, and outputs a second exception log of the second application of the application layer in the runtime environment and stores it in the log storage unit, wherein the first application is different from the second application, and the first log data includes the first exception log and the second exception log.

[0021] In this embodiment, when the vehicle network is in an abnormal state, different applications in the application layer record their own output abnormal log data, providing more detailed log data as an analysis basis for abnormal network analysis.

[0022] In an optional embodiment, after the control domain controller runs the application layer and outputs the second exception log of the second application of the application layer in the runtime environment and stores it in the log storage unit, the method further includes:

[0023] storing the first exception log and the second exception log in the first memory;

[0024] If the capacity of the first exception log and the second exception log is greater than or equal to the rated capacity of the first memory, the first exception log is saved to the first memory and the second exception log is saved to the second memory, wherein the priority of the first exception log is higher than that of the second exception log, and / or the reading and writing speed of the first memory is higher than that of the second memory.

[0025] Through this implementation, compared to only storing abnormal data in the first memory (such as running memory), data that has been stored for a longer time is transferred to the second memory (such as a hard disk, a CD, a USB flash drive, etc.) for storage, thereby reducing the power consumption of the domain controller; high-priority log data is stored in the first memory, making it convenient for the domain controller to use the log data at any time, thereby improving the flexibility of the domain controller.

[0026] In an optional embodiment, detecting a network request anomaly of a domain controller, locating a local abnormal network through network grouping, and recording a plurality of first log data output by different applications at the application layer include:

[0027] In response to an abnormality in an input / output operation of the application layer, controlling the domain controller to record read / write abnormality log data according to the domain name and / or network number, wherein the domain name and network number represent a node position of the domain controller in the vehicle network;

[0028] Detect network request anomalies of the domain controller, determine a local abnormal network through network grouping, and control the domain controller to record abnormal logs output by the first application and the second application, where the network nodes of the first application and the second application are in the local abnormal network.

[0029] Through this implementation, when input and output anomalies or network anomalies occur at the application layer, network grouping is used to narrow the scope of positioning, determine the local abnormal network, and record the abnormal log data output by different applications in the local abnormal network, providing more detailed log data for automobile network dormancy anomaly analysis, which helps to improve the accuracy of anomaly positioning.

[0030] In an optional embodiment, locating and analyzing the trigger source of the vehicle network anomaly based on the first log data and the second log data includes:

[0031] Taking the standard reference time when the vehicle leaves the factory as the starting point of the target timeline, sorting the log contents of the first log data and the second log data according to the target timeline to obtain a log sorting result, wherein the log contents of the first log data and the second log data both include the abnormal frequency of each log;

[0032] Based on the abnormal frequency, the target domain controller or target application of the network request abnormality is determined as the trigger source.

[0033] In this implementation, log data is sorted chronologically, resulting in unified log data for easier management and analysis. Furthermore, by using the number of anomalies recorded in the log data—the anomaly frequency—the domain controller or application corresponding to the log with the highest anomaly frequency can be identified as the triggering source of the anomaly, accurately locating the network anomaly.

[0034] In an optional embodiment, after locating and analyzing the trigger source of the vehicle network anomaly based on the first log data and the second log data, the method further includes:

[0035] In response to an upload instruction for target log data, the target log data is sent to a cloud server, where the target log data is obtained from log data corresponding to devices and / or modules of the car specified by the user based on the log sorting result.

[0036] In this embodiment, for the recorded log data, the user can choose to synchronize the log data of the device or module to be analyzed to the remote server, thereby achieving flexible use of the log data.

[0037] In an optional embodiment, after locating and analyzing the trigger source of the vehicle network anomaly based on the first log data and the second log data, the method further includes:

[0038] Statistics trigger source;

[0039] Based on the trigger source, the abnormal status of the vehicle is synchronized to the cloud for visualization and analysis of the vehicle's fault.

[0040] In this embodiment, after the trigger source of the network anomaly is determined, the number of records of the trigger source is counted and analyzed, providing a detailed data source for improving the stability of the vehicle's domain controller, which helps maintenance personnel quickly determine the vehicle's fault information.

[0041] In a second aspect, the present invention provides a device for analyzing abnormalities in automobile network dormancy, the device comprising:

[0042] a first log acquisition module, configured to acquire first log data recorded by the domain controller when the vehicle network is in an abnormal state, the first log data being used to store working information of a software layer in the domain controller;

[0043] a second log acquisition module, configured to acquire second log data recorded by the domain controller in the recovery state of the automotive network, the second log data being used to store working information of a software layer in the domain controller;

[0044] an analysis module, configured to perform positioning analysis on a trigger source of the automotive network anomaly based on the first log data and the second log data.

[0045] In a third aspect, the present application provides a computer device, comprising a memory and a processor, which are communicatively connected with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the automotive network hibernation anomaly analysis method according to the first aspect or any one of the corresponding embodiments thereof.

[0046] In a fourth aspect, the present application provides a computer readable storage medium, which stores computer instructions, and the computer instructions are used to make a computer execute the automotive network hibernation anomaly analysis method according to the first aspect or any one of the corresponding embodiments thereof.

[0047] In a fifth aspect, the present application provides a computer program product, which comprises computer instructions, and the computer instructions are used to make a computer execute the automotive network hibernation anomaly analysis method according to the first aspect or any one of the corresponding embodiments thereof. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the drawings needed in the specific embodiments or the prior art description will be briefly introduced as follows. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0049] Figure 1 is a flowchart of the automotive network hibernation anomaly analysis method according to an embodiment of the present application;

[0050] Figure 2 is a flowchart of another automotive network hibernation anomaly analysis method according to an embodiment of the present application;

[0051] Figure 3 is a flowchart of still another automotive network hibernation anomaly analysis method according to an embodiment of the present application;

[0052] Figure 4 is a flowchart of an automotive network hibernation anomaly analysis method using application layer output log data according to an embodiment of the present application;

[0053] Figure 51 is a flow chart of another method for analyzing automobile network dormancy anomalies by utilizing application layer output log data according to an embodiment of the present invention;

[0054] Figure 6 1 is a flow chart of another method for analyzing automobile network dormancy anomalies by utilizing application layer output log data according to an embodiment of the present invention;

[0055] Figure 7 is a flow chart of a method for analyzing automobile network sleep anomalies based on an abnormal trigger source according to an embodiment of the present invention;

[0056] Figure 8 is a flow chart of a method for synchronizing automobile network dormancy abnormality log data with the cloud according to an embodiment of the present invention;

[0057] Figure 9 is a flow chart of a method for analyzing automobile faults using automobile network sleep anomaly log data according to an embodiment of the present invention;

[0058] Figure 10 A schematic diagram of a user uploading a log of a specified device or module according to an embodiment of the present invention;

[0059] Figure 11 is a schematic diagram of analyzing fault causes according to log files in different states according to an embodiment of the present invention;

[0060] Figure 12 is a schematic diagram of log data output by each layer in a domain controller according to an embodiment of the present invention;

[0061] Figure 13 This is a structural block diagram of a device for analyzing abnormal vehicle network sleep according to an embodiment of the present invention;

[0062] Figure 14 Schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0063] 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.

[0064] According to the technical solution provided by the present invention, the method for analyzing automobile network dormancy anomalies can be applied to the following scenarios or fields:

[0065] In the field of automobile manufacturing and testing, it can be applied in the vehicle production process to verify and debug the network hibernation function of the domain controller. Specifically, by recording application layer logs in abnormal state (such as input / output operation abnormality, local network packet logs) and underlying service logs in recovery state, the network abnormality caused by software configuration errors or hardware compatibility problems in the manufacturing process can be quickly located.

[0066] In the field of vehicle after-sales maintenance and fault diagnosis, it can be used for precise diagnosis of problems such as abnormal battery consumption and frequent network wake-up when the vehicle is hibernating. Specifically, maintenance personnel can directly locate the trigger source (such as abnormal wake-up request of a certain sensor or failure of an application layer function module) by analyzing the first log data (including abnormal state logs) and the second log data (including recovery state logs) recorded by the domain controller, combined with cloud visualization tools.

[0067] In the field of intelligent networked vehicles and Internet of Vehicles, it can be used for remote monitoring of vehicle network health status to prevent functional failure caused by network abnormalities. Specifically, by synchronizing log data (such as user-specified module logs) in the cloud, real-time analysis of hibernation abnormal patterns of multiple vehicles can be performed to discover potential design flaws or environmental interference (such as local network abnormalities caused by electromagnetic interference in a specific area).

[0068] In the field of automatic driving system development and optimization, it can be used to debug the hibernation logic of complex multi-network segment communication in the development of automatic driving domain controllers. Specifically, by recording application layer call logs, the interaction abnormalities between automatic driving function modules (such as perception and decision-making) and underlying services (such as sensor drivers) can be analyzed, and the hibernation strategy can be optimized to avoid false wake-up.

[0069] In the field of new energy vehicle battery management systems, it can be used to solve the problem of unexpected battery consumption caused by network abnormalities in new energy vehicles. Specifically, by prioritizing log storage (such as storing high-priority abnormal logs in the first memory), the hibernation failure caused by software logic errors or communication timeouts in the battery management domain controller can be quickly located.

[0070] In the field of fleet management and shared travel, it can be used to monitor the hibernation state of vehicles in large-scale fleets to reduce operation and maintenance costs. Specifically, by using trigger source data (such as frequent abnormal wake-up of a certain application module in a certain vehicle model) collected in the cloud, batch software updates or replacement of faulty hardware modules can be pushed.

[0071] In the automotive electronic system upgrade, that is, in the Over-The-Air (OTA) scenario, it can be used to verify the stability of the vehicle network after the OTA upgrade. Specifically, by comparing the log sorting results before and after the upgrade (based on the factory timeline), it is analyzed whether the new version of the software introduces dormant anomalies (such as a significant increase in the frequency of anomalies in a certain application module). The technical solution of the present invention supports multi-level logging, covering the application layer, the bottom layer and the call relationship log, and is suitable for fields that require refined analysis of software interactions (such as autonomous driving and vehicle networking). It also implements dynamic storage optimization, and adapts to scenarios with high real-time requirements (such as fast fault reproduction in manufacturing testing) through a priority-based storage strategy (first memory and second memory). It also supports cloud-based collaborative analysis, remote diagnosis and big data analysis, which meets the needs of intelligent connected vehicles and fleet management.

[0072] In summary, this technical solution can be widely used in the design, production, operation and maintenance, and intelligent scenarios related to network dormancy throughout the entire life cycle of a vehicle, and is particularly valuable in the fields of new energy vehicles and intelligent driving with complex electronic architectures.

[0073] In related technologies, in-vehicle network communications typically rely on Ethernet, Controller Area Network (CAN), Local Interconnect Network (LIN), Flexray (a communication protocol for automotive electronic systems), and other networks for mutual communication, and rely on certain network management protocols to connect together, or some physical switches or hard-wired connections to achieve the sleep and wake-up of each Electronic Control Unit (ECU). When a vehicle experiences a network sleep anomaly, in order to not interrupt the fault phenomenon and reduce damage to the vehicle, the fault data is usually recorded in one or more of the following ways:

[0074] 1. Monitor network status: When the vehicle power is off or the network is in dormant state, detect network management messages and record the number of network wake-up times by comparing them with the threshold value.

[0075] 2. Collect static current: Obtain the static current data of the vehicle battery within a certain period, and calculate its average value and fluctuation range. When it exceeds the set threshold, the possible trigger source is stored in the controller.

[0076] 3. Determine abnormal wakeup: If the static current exceeds the preset threshold, or the network message transmission frequency is abnormal, it is determined to be an abnormal wakeup event.

[0077] 4. Locate the abnormal controller: Determine the controller that is abnormally awakened based on the source address or fault code in the network message.

[0078] 5. Record and store logs: record the time, controller information, fault code and other data of abnormal wake-up events into the diagnostic number, and upload the diagnostic information to the background server through the gateway controller.

[0079] Related technologies that primarily rely on quiescent current or wake-up times as a basis for judgment can be affected by environmental factors (such as temperature and humidity) or non-controller factors (such as sensor noise), leading to misjudgments. Positioning accuracy may be insufficient for abnormal wake-ups in complex networks (such as those with multiple network segments and multiple controllers). Furthermore, related technologies primarily target specific controllers or network segments, lacking comprehensive information about the entire vehicle's network or controller core. The limited fields used for recorded information are insufficient to support the diversity of issues that may arise, and fail to address the entire vehicle's perspective.

[0080] Therefore, in related technologies, the difficulty in accurately locating automotive network sleep anomalies is a problem that needs to be solved urgently.

[0081] According to an embodiment of the present invention, an embodiment of a method for analyzing automotive network sleep anomalies is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0082] In this embodiment, a method for analyzing automotive network sleep anomalies is provided. The automotive network includes a communication network consisting of network ports, network protocols, gateways, or switches between domain controllers and central domain controllers. The analysis method can be run on the central controller unit (CCU) and central computing platform (CCP) of the vehicle. Figure 1 FIG. 1 is a flow chart of a method for analyzing abnormal vehicle network sleep according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0083] Step S101 : obtaining first log data recorded by a domain controller when a vehicle network is in an abnormal state. The first log data is used to store working information of a software layer in the domain controller when the vehicle network is in an abnormal state.

[0084] In this embodiment, the domain controller (Zone Controller Unit, ZCU) refers to a new core control unit in the automotive electronic and electrical architecture, mainly used to integrate and manage the computing and control tasks of multiple functional modules in the vehicle, such as the cockpit domain, power domain, chassis domain, etc. The central domain controller refers to the domain controller in the automotive electronic and electrical architecture that is responsible for centrally integrating and managing the computing and control tasks of multiple functional domains (such as autonomous driving, smart cockpit, and power system). The central computing platform refers to the core hardware and software integration platform in the intelligent automotive electronic and electrical architecture, running in the central domain controller, responsible for the centralized processing and coordinated control of cross-domain functions of the entire vehicle. The first log data refers to the log recorded by the domain controller when the vehicle network is in an abnormal state, which is used to store the working information of the software layer in the domain controller. The vehicle network refers to the communication network for data communication and coordinated control between the domain controllers inside the vehicle, including the communication network between the domain controllers and the central domain controller. The software layer of the domain controller refers to the layered design of the software architecture within the domain controller. For example, in the Automotive Open System Architecture (AUTOSAR), its software layer is divided into a three-level architecture, from the top to the bottom: application layer, runtime environment layer, and basic software layer. The application layer is composed of multiple software components (SWCs) and interacts with the lower layers through standardized interfaces; the runtime environment (RTE) layer is the middleware between the application layer and the basic software layer, providing tasks such as communication, data mapping, and task scheduling, supporting multi-core distributed processing, and can generate code through configuration tools to simplify cross-domain communication; the basic software (BSW) layer provides general functions such as diagnosis, communication, and network management.

[0085] When the automobile network is in an abnormal state, the central domain controller controls the domain controller to record first log data. Optionally, the first log data is log information output by the software layer of the domain controller; wherein the automobile network abnormal state at least includes the automobile network dormant abnormal state.

[0086] Step S102 : obtaining second log data recorded by the domain controller when the vehicle network is restored. The second log data is used to store working information of the software layer in the domain controller when the vehicle network is restored.

[0087] Similar to the first log data, the second log data refers to the operational information output by the software layer in the domain controller when the vehicle network recovers. When the vehicle network recovers from an abnormal state to a normal state, the central domain controller controls the domain controller to record the second log data.

[0088] Step S103 : locating and analyzing the triggering source of the vehicle network anomaly based on the first log data and the second log data.

[0089] The trigger source refers to the source of the fault that causes the vehicle network anomaly, including domain controller hardware or software. Optionally, the vehicle network anomaly may be an abnormal wakeup from a dormant state. For example, after a vehicle enters dormant state, the entire vehicle is in low-power operation, and an abnormal wakeup due to a domain controller anomaly may occur. By recording the first log data of the vehicle network in the abnormal state and the second log data in the recovery state, the trigger source of the vehicle network anomaly can be analyzed and located.

[0090] In this embodiment, a method for analyzing abnormal sleep in a car network is provided, which can be used in the central domain controller mentioned above. Figure 2 FIG. 1 is a flow chart of a method for analyzing abnormal vehicle network sleep according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0091] Step S201 : obtaining first log data recorded by a domain controller when the automobile network is in an abnormal state, where the first log data is used to store working information of a software layer in the domain controller.

[0092] Specifically, the above step S201 includes:

[0093] Step S2011 , detecting abnormal network requests of the domain controller, locating the local abnormal network through network grouping, and controlling the domain controller to record a plurality of first log data output by different applications of the application layer.

[0094] In this embodiment, the software layer includes an application layer. The central domain controller detects an abnormality in the network request of the domain controller, indicating that an abnormality has occurred in the automobile network. The local abnormal network is located by means of network grouping, and the domain controller is controlled to record multiple first log data output by different applications in the application layer. For example, when an abnormality occurs in the automobile network, the domain controller prints logs for multiple applications running in the application layer to retain the data source of the network failure. Among them, the abnormality of the network request of the domain controller can be detected by setting the communication status field in the communication message between the central domain controller and the domain controller. Optionally, the network grouping performs local network management tasks from the bus signal level through the partial network cluster (PNC) strategy, and realizes a more refined network relationship through group control. Among them, PNC belongs to the COM layer of AUTOSAR, which groups and controls network communications, and finds a path to minimize controller wake-up while meeting the function implementation requirements.

[0095] Step S202 : obtaining second log data recorded by the domain controller when the vehicle network is in recovery state, where the second log data is used to store working information of the software layer in the domain controller.

[0096] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0097] Step S203 : locating and analyzing the triggering source of the vehicle network anomaly based on the first log data and the second log data.

[0098] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0099] In this embodiment, the logs of the vehicle network abnormality process are output to the application layer, and are further refined to different applications in the application layer, with logs printed for each application, providing more comprehensive data for analyzing the triggering source of the network abnormality.

[0100] In this embodiment, a method for analyzing abnormal sleep in an automobile network is provided, which can be used in the above-mentioned central domain controller, and the software layer includes the bottom layer. Figure 3 FIG. 1 is a flow chart of a method for analyzing abnormal vehicle network sleep according to an embodiment of the present invention. Figure 3 As shown, the process includes the following steps:

[0101] Step S301 : obtaining first log data recorded by a domain controller when the automobile network is in an abnormal state, where the first log data is used to store working information of a software layer in the domain controller.

[0102] Specifically, the above step S301 includes:

[0103] Step S3011 , detecting abnormal network requests of the domain controller, locating the local abnormal network through network grouping, and controlling the domain controller to record a plurality of first log data output by different applications of the application layer.

[0104] For details, please see Figure 2 Step S2011 of the illustrated embodiment will not be described in detail here.

[0105] Step S302 : obtaining second log data recorded by the domain controller when the vehicle network is in recovery state, where the second log data is used to store working information of the software layer in the domain controller.

[0106] Specifically, the above step S302 includes the following steps:

[0107] Step S3021, detecting the network request recovery of the domain controller, controlling the domain controller to record the function log data output by the application layer, controlling the domain controller to record the service log data output by the bottom layer, and controlling the domain controller to record the call log data output by the application layer calling the bottom layer.

[0108] In this embodiment, functional log data refers to log data output by the application layer of the domain controller software layer. Service log data refers to log data output by the bottom layer of the domain controller software layer. Call log data refers to log data output by the bottom layer application programming interface (API) when the application layer software calls the bottom layer API during operation. When the central domain controller detects that the network request of the domain controller has been restored, the control domain controller records the functional log data output by the application layer, the control domain controller records the service log data output by the bottom layer, and the control domain controller records the call log data output by the application layer calling the bottom layer.

[0109] In an example of this embodiment, the Diagnostic Log and Trace (DLT) module of the application layer prints the log data (functional log data) output by each application of the application layer, and also outputs the log (service log data) output by the underlying layer of the domain controller software layer through the underlying DLT module, as well as the log data (call log data) output by the underlying API when the multiple applications call the underlying API.

[0110] The recovery of the network request of the domain controller can be detected by obtaining the information from the communication status field in the communication message between the central domain controller and the domain controller.

[0111] Step S3022: Receive function log data, service log data, and call log data.

[0112] After the control domain controller records the function log data, service log data, and call log data, the central domain controller sends the function log data, service log data, and call log data to the central domain controller, which then receives the function log data, service log data, and call log data.

[0113] Step S3023: Merge the function log data, service log data, and call log data into second log data.

[0114] After the central domain controller obtains the function log data, service log data, and call log data, in order to facilitate overall analysis from the vehicle level, the function log data, service log data, and call log data are merged into the second log data.

[0115] Step S303 : locating and analyzing the triggering source of the vehicle network anomaly based on the first log data and the second log data.

[0116] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0117] In this embodiment, during the automobile network recovery process, the log data of the software layer and bottom layer inside the domain controller and the output of the software layer calling the bottom layer are recorded, providing diverse log data for the trigger source analysis of automobile network anomalies, which helps to improve the positioning accuracy of the trigger source.

[0118] In this embodiment, a method for analyzing abnormal sleep in a car network is provided, which can be used in the central domain controller mentioned above. Figure 4 FIG. 1 is a flow chart of a method for analyzing abnormal vehicle network sleep according to an embodiment of the present invention. Figure 4 As shown, the process includes the following steps:

[0119] Step S401 : obtaining first log data recorded by a domain controller when the automobile network is in an abnormal state, where the first log data is used to store working information of a software layer in the domain controller.

[0120] Specifically, the above step S401 includes:

[0121] Step S4011: Detect network request anomalies of the domain controller and locate the local abnormal network through network grouping.

[0122] For details, please see Figure 2 Step S2011 of the illustrated embodiment will not be described in detail here.

[0123] Step S4012: The control domain controller records a plurality of first log data output by different applications of the application layer.

[0124] Specifically, the above step S4012 includes:

[0125] Step a1: Control the domain controller to run the application layer, and output a first exception log of a first application in the application layer in a runtime environment and store the first exception log in a log storage unit of the domain controller;

[0126] In this embodiment, the first application refers to an application in the application layer of the domain controller that implements a specific function, typically corresponding to a C language file. The first exception log refers to the log printed by the first application when a vehicle network anomaly occurs. The log storage unit refers to the software or hardware unit in the domain controller used to store log data. When the central domain controller detects a vehicle network anomaly, it controls the domain controller to run the first application in the application layer, execute the first application in the RTE, and print the first exception log. The first exception log is stored in the domain controller's log storage unit.

[0127] Step a2: Control the domain controller to run the application layer, and output a second exception log of the second application of the application layer in the runtime environment and store it in the log storage unit, wherein the first application is different from the second application, and the first log data includes the first exception log and the second exception log.

[0128] In this embodiment, similar to the first application, the second application refers to an application in the domain controller's application layer that implements a specific function. The second exception log refers to the log printed by the second application when a vehicle network anomaly occurs. Similar to step a1 above, when the central domain controller detects a vehicle network anomaly, it controls the domain controller to run the second application in the application layer, execute the second application in the RTE, and print a second exception log. The second exception log is stored in the domain controller's log storage unit.

[0129] Step S402 : obtaining second log data recorded by the domain controller when the vehicle network is in recovery state, where the second log data is used to store working information of the software layer in the domain controller.

[0130] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0131] Step S403 : locating and analyzing the triggering source of the vehicle network anomaly based on the first log data and the second log data.

[0132] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0133] This implementation records the log data output by different applications running in the application layer of the domain controller when a vehicle network anomaly occurs. This refines the granularity of vehicle network anomaly analysis and improves the accuracy of fault source location.

[0134] In this embodiment, a method for analyzing abnormal sleep in a car network is provided, which can be used in the central domain controller mentioned above. Figure 5 FIG. 1 is a flow chart of a method for analyzing abnormal vehicle network sleep according to an embodiment of the present invention. Figure 5 As shown, the process includes the following steps:

[0135] Step S501 : obtaining first log data recorded by a domain controller when the automobile network is in an abnormal state, where the first log data is used to store working information of a software layer in the domain controller.

[0136] Specifically, the above step S501 includes:

[0137] Step S5011: Detect network request anomalies of the domain controller and locate the local abnormal network through network grouping.

[0138] For details, please see Figure 2 Step S2011 of the illustrated embodiment will not be described in detail here.

[0139] Step S5012: The control domain controller records a plurality of first log data output by different applications of the application layer.

[0140] Specifically, the above step S5012 includes:

[0141] Step b1: Control the domain controller to run the application layer, and output a first exception log of a first application in the application layer in a runtime environment and store the first exception log in a log storage unit of the domain controller;

[0142] For details, please see Figure 4 Step a1 of the illustrated embodiment will not be described in detail here.

[0143] Step b2: Control the domain controller to run the application layer, and output a second exception log of the second application of the application layer in the runtime environment and store it in the log storage unit, wherein the first application is different from the second application, and / or the first log data includes the first exception log and the second exception log.

[0144] For details, please see Figure 4 Step a1 of the illustrated embodiment will not be described in detail here.

[0145] Step b3, storing the first abnormality log and the second abnormality log in the first memory;

[0146] In this embodiment, the first memory refers to a storage unit in the domain controller for storing the first exception log and the second exception log. Preferably, the first memory is a random access memory (RAM). The first exception log and the second exception log recorded by the domain controller are preferentially stored in the RAM of the domain controller.

[0147] Step b4: If the capacity of the first exception log and the second exception log is greater than or equal to the rated capacity of the first memory, the first exception log is saved to the first memory and the second exception log is saved to the second memory, wherein the priority of the first exception log is higher than that of the second exception log, and the read and write speed of the first memory is higher than that of the second memory.

[0148] In this embodiment, the second memory refers to a storage unit in the domain controller for storing the second exception log. Preferably, the second memory is a read-only memory (ROM). If the total capacity of the first exception log and the second exception log is greater than or equal to the rated capacity of the first memory, it means that the exception log of the domain controller is difficult to continue to be stored in the first memory, then the first exception log is saved in the first memory, and the second exception log is saved in the second memory. Among them, for storage priority, the storage priority of the first exception log is higher than that of the second exception log, that is, for the remaining storage space of the RAM, the first exception log is stored first. After ensuring that the first exception log is stored in the RAM, if the RAM still has storage space remaining, the second exception log can be stored therein. Otherwise, only the first exception log with a higher priority is saved in the RAM, and the second exception log with a lower priority is saved in the ROM. This makes it easy to resend the first exception log after the automobile network communication is restored, and to synchronize key exception log data to the central domain controller in a timely manner, so as to improve the efficiency of network anomaly positioning.

[0149] Step S502 : obtaining second log data recorded by the domain controller when the vehicle network is in recovery state, where the second log data is used to store working information of the software layer in the domain controller.

[0150] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0151] Step S503 : locating and analyzing the triggering source of the vehicle network anomaly based on the first log data and the second log data.

[0152] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0153] In this embodiment, after obtaining the exception logs output by different applications at the application layer, the order of storage of the exception logs is divided according to the priority of the exception logs. The high-priority exception log data is stored in a memory with a higher read / write speed, facilitating flexible data access and timely synchronization during network recovery. The exception log data that exceeds the capacity of the memory with a higher read / write speed is stored on a storage medium such as a hard disk, USB flash drive, or optical disk, ensuring the integrity of the exception log data.

[0154] In this embodiment, a method for analyzing abnormal sleep in a car network is provided, which can be used in the central domain controller mentioned above. Figure 6 FIG. 1 is a flow chart of a method for analyzing abnormal vehicle network sleep according to an embodiment of the present invention. Figure 6 As shown, the process includes the following steps:

[0155] Step S601: obtaining first log data recorded by a domain controller when the automobile network is in an abnormal state. The first log data is used to store working information of a software layer in the domain controller when the automobile network is abnormal.

[0156] Specifically, the above step S601 includes:

[0157] Step S6011: Detect network request anomalies of the domain controller, locate the local abnormal network through network grouping, and control the domain controller to record multiple first log data output by different applications in the application layer.

[0158] Specifically, the above step S6011 includes:

[0159] In step c1, in response to an exception in the input / output operation of the application layer, the domain controller is controlled to record read / write exception log data according to the domain name and / or network number, where the domain name and network number represent the node position of the domain controller in the automobile network.

[0160] In this embodiment, the domain name refers to the name of the domain controller, and the network number refers to the address of the domain controller in the vehicle network. Both the domain name and the network number represent the node location of the domain controller in the vehicle network. For example, CS01 can be used to represent the chassis domain, and CC01 can be used to represent the body domain. When an exception occurs in an input / output operation at the application layer, the domain controller is controlled to record read and write exception log data based on the domain name and / or network number given by the local abnormal network determined by the network grouping. Exceptions caused by input / output operations within the application layer are logged.

[0161] Step c2: Detect network request anomalies of the domain controller, determine a local abnormal network through network grouping, and control the domain controller to record abnormal logs output by the first application and the second application. The network nodes of the first application and the second application are in the local abnormal network.

[0162] In this embodiment, when the central domain controller detects an abnormal network request of the domain controller, it determines the local abnormal network through a network grouping method, preferably through a PNC policy, and controls the domain controller to record the abnormal logs output by the first application and the second application in the local abnormal network.

[0163] Step S602 : obtaining second log data recorded by the domain controller when the vehicle network is restored. The second log data is used to store working information of the software layer in the domain controller when the vehicle network is restored.

[0164] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0165] Step S603 : Based on the first log data and the second log data, a trigger source of the vehicle network anomaly is located and analyzed.

[0166] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0167] In this implementation, network request anomalies occurring in the domain controller are divided into anomalies caused by internal input / output errors and anomalies caused by the controller hardware or software. In the latter case, the local abnormal network is located through network grouping, and the domain controller is controlled to record multiple first log data output by different applications at the application layer, providing more granular log data for locating network anomalies. This improves the accuracy of anomaly location.

[0168] In this embodiment, a method for analyzing abnormal sleep in a car network is provided, which can be used in the central domain controller mentioned above. Figure 7 FIG. 1 is a flow chart of a method for analyzing automobile network sleep anomalies based on an abnormal trigger source according to an embodiment of the present invention. Figure 7 As shown, the process includes the following steps:

[0169] Step S701: obtaining first log data recorded by a domain controller when the automobile network is in an abnormal state. The first log data is used to store working information of a software layer in the domain controller when the automobile network is abnormal.

[0170] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0171] Step S702 : obtaining second log data recorded by the domain controller when the vehicle network is restored. The second log data is used to store working information of the software layer in the domain controller when the vehicle network is restored.

[0172] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0173] Step S703 : Based on the first log data and the second log data, a trigger source of the vehicle network anomaly is located and analyzed.

[0174] Specifically, the above step S703 includes the following steps:

[0175] In step S7031, the standard reference time when the car leaves the factory is used as the starting point of the target timeline, and the log contents of the first log data and the second log data are sorted according to the target timeline to obtain a log sorting result. The log contents of the first log data and the second log data both include the abnormal frequency of each log.

[0176] In this embodiment, the target timeline refers to the timeline extending backward from the standard reference time when the vehicle leaves the factory. That is, the timeline for abnormality statistics begins with the time the vehicle rolls off the production line. The abnormality frequency refers to the number of hardware or software anomalies within the same domain controller. The abnormality frequency for each log entry is included in both the first and second log data. Recording begins at the time the vehicle leaves the factory, and the log contents in the first and second log data are sorted in chronological order along the target timeline to produce uniformly time-sorted log data.

[0177] Step S7032: Based on the abnormal frequency, determine the target domain controller or target application with the network request abnormality as a trigger source.

[0178] In this embodiment, based on the frequency of exceptions, the target domain controller or target application with the network request exception can be used as the trigger source. Optionally, the exception frequencies can be sorted from highest to lowest, and the domain controller or application with the most frequent log records can be used as the target domain controller or target application for the network exception trigger source. Alternatively, a comprehensive analysis can be conducted on multiple logs with abnormal frequency records exceeding a preset threshold, combined with the topology of the current domain controller's communication network, to analyze the core trigger source causing the network exception.

[0179] In this embodiment, by analyzing the log entries in the first log data and the second log data, the trigger source causing the vehicle network anomaly is located, thereby achieving accurate troubleshooting of network faults and improving the efficiency of fault location.

[0180] In this embodiment, a method for analyzing abnormal sleep in a car network is provided, which can be used in the central domain controller mentioned above. Figure 8 is a flow chart of a method for synchronizing abnormal log data of a vehicle network dormancy to the cloud according to an embodiment of the present invention. Figure 8 As shown, the process includes the following steps:

[0181] Step S801: Acquire first log data recorded by a domain controller when the automobile network is in an abnormal state. The first log data is used to store working information of a software layer in the domain controller when the automobile network is abnormal.

[0182] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0183] Step S802 : obtaining second log data recorded by the domain controller when the vehicle network is restored. The second log data is used to store working information of the software layer in the domain controller when the vehicle network is restored.

[0184] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0185] Step S803 : Based on the first log data and the second log data, a trigger source of the vehicle network anomaly is located and analyzed.

[0186] For details, please see Figure 7 Step S703 of the illustrated embodiment will not be described in detail here.

[0187] Step S804 , in response to an instruction to upload target log data, the target log data is sent to a cloud server, where the target log data is obtained from log data corresponding to the device and / or module of the car specified by the user based on the log sorting result.

[0188] In this embodiment, the target log data refers to the log data recorded by the domain controller associated with the device and / or module of the vehicle specified by the user, based on the log sorting results. After the user specifies the target log data to be uploaded, the target log data can be uploaded to the cloud server. This provides a more comprehensive dataset for further analysis of abnormal faults based on this log data, or for analyzing the cause of faults from the perspective of the entire vehicle.

[0189] This embodiment provides a method for analyzing abnormal sleep in a car network, which can be used in the central domain controller mentioned above. Figure 9 FIG. 1 is a flow chart of a method for analyzing automobile faults using automobile network sleep abnormality log data according to an embodiment of the present invention. Figure 9 As shown, the process includes the following steps:

[0190] Step S901 : obtaining first log data recorded by a domain controller when the automobile network is in an abnormal state. The first log data is used to store working information of a software layer in the domain controller when the automobile network is in an abnormal state.

[0191] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0192] Step S902 : obtaining second log data recorded by the domain controller when the vehicle network is restored. The second log data is used to store working information of the software layer in the domain controller when the vehicle network is restored.

[0193] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0194] Step S903 : Based on the first log data and the second log data, a trigger source of the vehicle network anomaly is located and analyzed.

[0195] For details, please see Figure 7 Step S703 of the illustrated embodiment will not be described in detail here.

[0196] Step S904: Count trigger sources.

[0197] In this embodiment, after the trigger source of the vehicle network anomaly is located, statistics are collected on the trigger source.

[0198] In step S905, based on the trigger source, the abnormal state of the vehicle is synchronized to the cloud for visualization and the failure of the vehicle is analyzed.

[0199] In this embodiment, based on the counted trigger sources, the vehicle's abnormal status can be synchronized to the cloud for visualization, showing the module or device related to the domain controller where the vehicle has failed. Furthermore, a comprehensive analysis of the vehicle's failure can be performed by combining multiple trigger sources, providing a visual reference for troubleshooting and repair.

[0200] This embodiment provides a method for analyzing abnormal sleep in a car network, which can be used in the central domain controller mentioned above. Figure 10 This is a schematic diagram of a user uploading a log of a specified device or module according to an embodiment of the present invention. Figure 10 As shown, the vehicle type is determined to be Model 1 using the vehicle identification number (VIN) VIN123456. In Model 1, the user decides to select the log data recorded by the Bluetooth and map modules in the cockpit domain controller (CDC) type device. The user selects the target time period from XX / XX to Y / Y / Y as the target time period to extract the log data within this time period. After the user confirms, the log can be uploaded to the cloud. This enables targeted analysis of the log data of the target module, saving the time spent searching each module and improving the efficiency of abnormality detection.

[0201] This embodiment provides a method for analyzing abnormal sleep in a car network, which can be used in the central domain controller mentioned above. Figure 11 FIG. 1 is a schematic diagram of analyzing fault causes according to log files in different states according to an embodiment of the present invention. Figure 11As shown, the log file for device a records a higher number of faults, while the log file for device b records a lower number. This suggests that the anomaly is more likely to have originated in the domain controller for device a. By combining the number of faults recorded in the log files of both devices a and b during a specific time period, we can analyze the domain controllers associated with both devices, providing data reference for accurately locating the source of the fault.

[0202] This embodiment provides a method for analyzing abnormal sleep in a car network, which can be used in the central domain controller mentioned above. Figure 12 FIG. 1 is a schematic diagram of log data output by each layer in a domain controller according to an embodiment of the present invention. Figure 12 As shown, when the car network connection is normal, the first application and the second application of the SWC application layer output their respective recorded log data through the client / server (Client / Server, C / S) function call method. When the car network is abnormal, the first application and the second application of the application layer both use the application layer DLT log module in the runtime environment through the sender / receiver (Sender / Receiver, S / R) message transmission method to output their respective log data. After the car network connection is restored, the application layer DLT log module resends the stored DLT logs output by the first application and the second application to the underlying DLT log module through a function call. For example, when the vehicle is in a dormant state, each domain controller is running in a low-power state, and each domain controller is in a dormant state. Excluding the wake-up action set by humans or programs, a controller or multiple domain controllers of the vehicle are automatically awakened. In this case, when the car network connection is normal, the first application and the second application of the application layer output the log data of each application in the underlying DLT log module through the C / S method. When the vehicle network goes into hibernation abnormally, the first and second applications in the application layer both output their respective log data to the application layer's DLT log module in the runtime environment via an S / R method. After the vehicle network resumes connection from hibernation, the application layer's DLT log module resends the stored DLT logs output by the first and second applications to the underlying DLT log module via a C / S method. This implementation records the logs output by the domain controller's application layer, the logs output by the underlying layer, and the logs associated between the application layer and the underlying layer, providing diverse log data for analyzing vehicle network hibernation abnormalities and improving the accuracy of locating vehicle network hibernation abnormalities.

[0203] This embodiment also provides a device for analyzing automotive network sleep anomalies. This device is used to implement the above-mentioned embodiments and preferred implementations, and details already described will not be repeated. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0204] This embodiment provides a device for analyzing abnormalities in automobile network sleep. Figure 13 Shown, including:

[0205] A first log acquisition module 1301 is configured to acquire first log data recorded by the domain controller when the vehicle network is abnormal. The first log data is used to store working information of the software layer in the domain controller when the vehicle network is abnormal.

[0206] A second log acquisition module 1302 is configured to acquire second log data recorded by the domain controller when the vehicle network is restored. The second log data is used to store working information of the software layer in the domain controller when the vehicle network is restored.

[0207] The analysis module 1303 is configured to perform location analysis on a trigger source of the vehicle network anomaly based on the first log data and the second log data.

[0208] In some optional implementations, the software layer includes an application layer, and the first log acquisition module 1301 includes:

[0209] The log output unit is used to detect network request anomalies of the domain controller, locate local abnormal networks through network grouping, and control the domain controller to record multiple first log data output by different applications in the application layer.

[0210] In some optional implementations, the software layer includes a bottom layer, and the second log acquisition module 1302 includes:

[0211] A log output unit is used to detect the network request recovery of the domain controller, control the domain controller to record the function log data output by the application layer, control the domain controller to record the service log data output by the bottom layer, and control the domain controller to record the call log data of the application layer calling the bottom layer output;

[0212] A receiving unit, configured to receive function log data, service log data, and call log data;

[0213] The log merging unit is used to merge the function log data, the service log data, and the call log data into the second log data.

[0214] In some optional implementations, the log output unit includes:

[0215] A first log output subunit is configured to control the domain controller to run the application layer, and output a first exception log of the first application of the application layer in the runtime environment and store the first exception log in the log storage unit of the domain controller;

[0216] The second log output subunit is used to control the domain controller to run the application layer, and output the second exception log of the second application of the application layer in the runtime environment and store it in the log storage unit, wherein the first application is different from the second application, and the first log data includes the first exception log and the second exception log.

[0217] In some optional implementations, the second log output subunit further includes:

[0218] A first log storage subunit is configured to store the first exception log and the second exception log in a first memory;

[0219] The second log saving subunit is used to save the first exception log to the first memory and save the second exception log to the second memory if the capacity of the first exception log and the second exception log is greater than or equal to the rated capacity of the first memory, wherein the priority of the first exception log is higher than that of the second exception log, and / or the reading and writing speed of the first memory is higher than that of the second memory.

[0220] In some optional implementations, the log output unit includes:

[0221] a first logging subunit, configured to control a domain controller to record read / write exception log data in response to an exception in an input / output operation of the application layer, according to a domain name and / or a network number, wherein the domain name and the network number represent a node position of the domain controller in the vehicle network;

[0222] An abnormal network determination unit, used to detect abnormal network requests from the domain controller and determine the local abnormal network through network grouping;

[0223] The second log recording subunit is used to control the domain controller to record the abnormal logs output by the first application and the second application, and the network nodes of the first application and the second application are in the local abnormal network.

[0224] In some optional implementations, the analysis module 1303 includes:

[0225] a sorting unit, configured to use a standard reference time when the vehicle leaves the factory as a starting point of a target timeline, and sort the log contents of the first log data and the second log data according to the target timeline to obtain a log sorting result, wherein the log contents of the first log data and the second log data both include an abnormality frequency of each log;

[0226] The determination unit is used to determine the target domain controller or target application of the network request abnormality as a trigger source based on the abnormal frequency.

[0227] In some optional implementations, the determining unit further includes:

[0228] The log uploading subunit is used to send the target log data to the cloud server in response to an upload instruction for the target log data. The target log data is obtained from the log data corresponding to the device and / or module of the car specified by the user based on the log sorting result.

[0229] In some optional implementations, the analysis module 1303 further includes:

[0230] Statistics unit, used to count trigger sources;

[0231] The fault analysis unit is used to synchronize the abnormal status of the vehicle to the cloud for visualization based on the trigger source and analyze the vehicle's faults.

[0232] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0233] The vehicle network sleep anomaly analysis device 13 in this embodiment is presented in the form of a functional unit, where the unit refers to an application specific integrated circuit (ASIC) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0234] The embodiment of the present invention also provides a computer device having the above Figure 13 The device 13 is shown for analyzing abnormalities in automobile network sleep.

[0235] See also Figure 14 , Figure 14 is a structural diagram of a computer device provided by an optional embodiment of the present invention, such as Figure 14As shown, the computer device includes: one or more processors 10, memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in the memory or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Equally, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 14 A processor 10 is taken as an example.

[0236] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0237] The memory 20 stores instructions that can be executed by at least one processor 10, so as to enable at least one processor 10 to execute the method shown in the above embodiment.

[0238] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0239] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0240] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0241] The embodiment of the present invention also provides a computer-readable storage medium. The above-mentioned method according to the embodiment of the present invention can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0242] A portion of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium that can be accessed by the computer.

[0243] 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 method for analyzing abnormalities in automobile network dormancy, characterized in that: The vehicle network includes a communication network consisting of network ports, network protocols, gateways, or switches between a domain controller and a central domain controller. The analysis method is applied to the central domain controller, and the method includes: Acquire first log data recorded by a domain controller in an abnormal state of a vehicle network, wherein the first log data is used to store working information of a software layer in the domain controller when the vehicle network is abnormal; acquiring second log data recorded by the domain controller in a state where the vehicle network is restored, wherein the second log data is used to store working information of the software layer in the domain controller when the vehicle network is restored; Based on the first log data and the second log data, a trigger source of the automobile network anomaly is located and analyzed.

2. The method according to claim 1, characterized in that The software layer includes an application layer, and obtaining first log data recorded by the domain controller in an abnormal state of the automobile network includes: Detect network request anomalies of the domain controller, locate local abnormal networks through network grouping, and control the domain controller to record multiple first log data output by different applications of the application layer.

3. The method according to claim 2, characterized in that The software layer includes a bottom layer, and obtaining the second log data recorded by the domain controller in the automobile network recovery state includes: Detecting network request recovery of the domain controller, controlling the domain controller to record function log data output by the application layer, controlling the domain controller to record service log data output by the bottom layer, and controlling the domain controller to record call log data of the application layer calling the bottom layer output; receiving the function log data, the service log data, and the call log data; The function log data, the service log data, and the call log data are merged into the second log data.

4. The method according to claim 2, characterized in that The controlling the domain controller to record the plurality of first log data output by different applications of the application layer includes: Controlling the domain controller to run the application layer, and outputting a first exception log for a first application of the application layer in a runtime environment and storing the first exception log in a log storage unit of the domain controller; Control the domain controller to run the application layer, and output a second exception log for the second application of the application layer in the runtime environment and store it in the log storage unit, wherein the first application is different from the second application, and the first log data includes the first exception log and the second exception log.

5. The method according to claim 4, characterized in that After controlling the domain controller to run the application layer and causing the second application of the application layer to output a second exception log in the runtime environment and store the second exception log in the log storage unit, the method further includes: storing the first exception log and the second exception log in a first memory; If the capacity of the first exception log and the second exception log is greater than or equal to the rated capacity of the first memory, the first exception log is saved to the first memory and the second exception log is saved to the second memory, wherein the priority of the first exception log is higher than that of the second exception log, and / or the reading and writing speed of the first memory is higher than that of the second memory.

6. The method according to claim 2, characterized in that The detecting of abnormal network requests of the domain controller, locating the local abnormal network through network grouping, and recording a plurality of first log data output by different applications of the application layer include: In response to an abnormality in an input / output operation of the application layer, controlling the domain controller to record read / write abnormality log data according to a domain name and / or a network number, wherein the domain name and the network number represent a node position of the domain controller in the automobile network; Detect network request anomalies of the domain controller, determine the local abnormal network through network grouping, and control the domain controller to record abnormal logs output by the first application and the second application, where the network nodes of the first application and the second application are in the local abnormal network.

7. The method according to claim 1, characterized in that The performing location analysis on the triggering source of the vehicle network anomaly based on the first log data and the second log data includes: Taking the standard reference time when the vehicle leaves the factory as the starting point of a target timeline, sorting the log contents of the first log data and the second log data according to the target timeline to obtain a log sorting result, wherein the log contents of the first log data and the second log data both include the abnormal frequency of each log; Based on the abnormal frequency, a target domain controller or a target application of the network request abnormality is determined as the trigger source.

8. The method according to claim 7, characterized in that After locating and analyzing the trigger source of the vehicle network anomaly based on the first log data and the second log data, the method further includes: In response to an upload instruction for target log data, the target log data is sent to a cloud server. The target log data is obtained from log data corresponding to the device and / or module of the car specified by the user based on the log sorting result.

9. The method according to claim 4, characterized in that After locating and analyzing the trigger source of the vehicle network anomaly based on the first log data and the second log data, the method further includes: Counting the trigger sources; Based on the trigger source, the abnormal state of the car is synchronized to the cloud for visualization, and the fault of the car is analyzed.

10. An analysis device for abnormal vehicle network dormancy, characterized in that: The vehicle network includes a communication network consisting of network ports, network protocols, gateways, or switches between a domain controller and a central domain controller. The analysis device may be applied to the central domain controller, and the device includes: a first log acquisition module, configured to acquire first log data recorded by a domain controller when an automobile network is in an abnormal state, the automobile network comprising a communication network between the domain controller and a central domain controller, the first log data being used to store working information of a software layer in the domain controller; a second log acquisition module, configured to acquire second log data recorded by the domain controller in a state where the vehicle network is restored, wherein the second log data is used to store working information of the software layer in the domain controller; An analysis module is used to locate and analyze a trigger source of the automobile network anomaly based on the first log data and the second log data.

11. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for analyzing automobile network sleep anomalies according to any one of claims 1 to 9 by executing the computer instructions.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method for analyzing automobile network dormancy anomalies according to any one of claims 1 to 9.

13. A computer program product, characterized in that The method comprises computer instructions for causing a computer to execute the method for analyzing automobile network sleep anomaly according to any one of claims 1 to 9.

Images