A cockpit software monitoring method, device, equipment and storage medium

Abstract

The application provides a cockpit software monitoring method, device, equipment and storage medium, the method comprises the following steps: obtaining real-time state data of a target vehicle through a controller area network or an Ethernet, then converting the real-time state data to obtain conversion data, and providing the conversion data to an application layer through an interface; receiving and responding to an operation instruction input by a target object in the application layer, and calling the conversion data to generate log information; when the target vehicle is in a starting state, analyzing the log information, and monitoring cockpit software in the target vehicle based on the analysis result. The application can record the time spent by each link in the cockpit software, analyze the time to determine whether the cockpit software is running normally, and provide maintenance or repair reference to relevant personnel through analysis of abnormal information in the case of abnormal running, thereby helping to improve the stability and safety of the entire cockpit software.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, specifically to a cockpit software monitoring method, device, equipment, and storage medium. Background Technology

[0002] With the continuous development of intelligent cockpit technology and the increasing functional requirements of vehicle users, the entire cockpit system has become increasingly complex. A cockpit system is not a single application or service, but rather a collaborative effort of multiple applications or services, integrating their functions to ensure the normal operation of the entire system. The safety and stability of the cockpit system are paramount considerations. Therefore, during the operation of the cockpit software, there are very high requirements for monitoring the overall operational status of the software, proactively identifying potential faults, and resolving problems after they occur. However, current cockpit monitoring technologies require numerous monitoring devices, significantly increasing monitoring costs. Furthermore, the diagnostic functions primarily rely on data from the instrument panel, which is relatively limited. It also fails to cover the entire cockpit system's functionality, resulting in incomplete diagnostics. Moreover, existing methods for cockpit software monitoring are mainly used in development testing and are almost useless in real-vehicle testing, unable to test all aspects of the cockpit system's functionality, thus lacking comprehensiveness. Summary of the Invention

[0003] In view of the shortcomings of the prior art described above, this application provides a cockpit software monitoring method, apparatus, device and storage medium to solve the above technical problems.

[0004] This application provides a cockpit software monitoring method, including the following steps:

[0005] Real-time status data of the target vehicle is obtained through the controller area network or Ethernet.

[0006] The real-time status data is transformed to obtain transformed data, and the transformed data is provided to the application layer through an interface.

[0007] The system receives and responds to operation instructions input by the target object at the application layer, and uses the transformed data to generate log information; wherein, the target object includes: the person driving the vehicle and the person riding in the vehicle;

[0008] When the target vehicle is in the startup state, the log information is parsed, and the cockpit software in the target vehicle is monitored based on the parsing results.

[0009] In one embodiment of this application, the process of parsing the log information and monitoring the cockpit software in the target vehicle based on the parsing results includes:

[0010] The log information is parsed, and the parsing result is used to determine whether a first log exists in the log information; wherein, the first log is used to record cockpit software functions that take longer than a preset time.

[0011] If a first log exists, a notification message indicating the existence of the first log is issued, the location of the first log is located, and the cockpit software is monitored based on the location of the first log.

[0012] If the first log does not exist, then based on the parsing result of the log information, it is determined whether a second log exists in the log information; wherein, the second log is used to record abnormal operation of the cockpit software;

[0013] If a second log exists, a notification message indicating the existence of the second log is issued, the location of the second log is located, and the cockpit software is monitored based on the location of the second log.

[0014] If a second log does not exist, the parsing result of the log information will be displayed.

[0015] In one embodiment of this application, after generating log information by calling the conversion data, the method further includes: storing the log information in a preset database, and setting a log information storage switch; wherein, the log information storage switch includes: enabling log information storage during the cockpit software development stage, enabling log information storage during the bench testing stage of the target vehicle, enabling log information storage during the actual testing stage of the target vehicle, and disabling log information storage when the target vehicle reaches preset production conditions.

[0016] In one embodiment of this application, the preset database includes at least one of the following: a local database established in advance or in real time, or a cloud database established in advance or in real time.

[0017] In one embodiment of this application, when using the preset database, the method further includes: setting a data cleanup mechanism in the preset database; wherein the data cleanup mechanism includes at least one of the following: performing data cleanup when files in the preset database reach a preset size, performing data cleanup when the date of data information in the preset database exceeds a preset duration, and performing data cleanup after data information in the preset database is marked as abnormal data.

[0018] In one embodiment of this application, the target vehicle includes: a new energy vehicle and a fuel vehicle.

[0019] This application also provides a cockpit software monitoring device, the device comprising:

[0020] The data acquisition module is used to acquire real-time status data of the target vehicle via the controller area network or Ethernet.

[0021] The data conversion module is used to convert the real-time status data to obtain converted data, and provide the converted data to the application layer through an interface;

[0022] The log generation module is used to receive and respond to the operation instructions input by the target object at the application layer, and to call the transformed data to generate log information; wherein, the target object includes: the person driving the vehicle and the person riding in the vehicle;

[0023] The monitoring module is used to parse the log information when the target vehicle is in the startup state, and to monitor the cockpit software in the target vehicle based on the parsing results.

[0024] In one embodiment of this application, the process by which the monitoring module parses the log information when the target vehicle is in a startup state, and monitors the cockpit software in the target vehicle based on the parsing results, includes:

[0025] The log information is parsed, and the parsing result is used to determine whether a first log exists in the log information; wherein, the first log is used to record cockpit software functions that take longer than a preset time.

[0026] If a first log exists, a notification message indicating the existence of the first log is issued, the location of the first log is located, and the cockpit software is monitored based on the location of the first log.

[0027] If the first log does not exist, then based on the parsing result of the log information, it is determined whether a second log exists in the log information; wherein, the second log is used to record abnormal operation of the cockpit software;

[0028] If a second log exists, a notification message indicating the existence of the second log is issued, the location of the second log is located, and the cockpit software is monitored based on the location of the second log.

[0029] If a second log does not exist, the parsing result of the log information will be displayed.

[0030] This application also provides a cockpit software monitoring device, the device comprising:

[0031] One or more processors;

[0032] A storage device for storing one or more programs that, when executed by one or more processors, cause the device to implement the cockpit software monitoring method as described above.

[0033] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer's processor, causes the computer to perform the cockpit software monitoring method as described in any of the above-described methods.

[0034] As described above, this application provides a cockpit software monitoring method, apparatus, device, and storage medium, which has the following beneficial effects: First, this application acquires real-time status data of the target vehicle via a controller area network or Ethernet. Then, it converts the real-time status data to obtain converted data and provides the converted data to the application layer through an interface. Next, it receives and responds to operation commands input by the target object at the application layer and calls the converted data to generate log information. The target object includes: the person driving the vehicle and the person riding in the vehicle. When the target vehicle is in a startup state, the log information is parsed, and the cockpit software in the target vehicle is monitored based on the parsing results. Therefore, this application provides a scheme for monitoring the operating status of cockpit software, including saving detailed log information of program operation and recording the time spent on each stage of the cockpit software operation. Time analysis is used to determine whether the cockpit software is operating normally. In case of abnormal operation, analysis of the abnormal information can provide maintenance or repair references for relevant personnel, helping to improve the stability and security of the entire cockpit software.

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

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

[0037] Figure 1 This is a schematic diagram illustrating an exemplary system architecture that applies the technical solutions in one or more embodiments of this application;

[0038] Figure 2 This is a flowchart illustrating a cockpit software monitoring method provided in one embodiment of this application.

[0039] Figure 3 This is a schematic diagram of the system architecture of cockpit software provided in one embodiment of this application;

[0040] Figure 4 A diagram illustrating the operating mechanism of a database provided in one embodiment of this application;

[0041] Figure 5 A schematic diagram of the hardware structure of a cockpit software monitoring device provided in one embodiment of this application;

[0042] Figure 6 A schematic diagram of the hardware structure of a cockpit software monitoring device provided in another embodiment of this application;

[0043] Figure 7 This is a schematic diagram of the hardware structure of a cockpit software monitoring device suitable for implementing one or more embodiments of this application. Detailed Implementation

[0044] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0045] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0046] In this application, "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0047] The term "multiple" in this application refers to two or more.

[0048] In the description of this application, the terms "first," "second," etc., are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance or order.

[0049] Additionally, in the embodiments of this application, the term "exemplary" is used to indicate that it is an example, illustration, or description. Any embodiment or implementation described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or implementations. Rather, the use of the term "exemplary" is intended to present the concept in a specific manner.

[0050] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0051] Figure 1 A schematic diagram of an exemplary system architecture that can apply the technical solutions of one or more embodiments of this application is shown. Figure 1 As shown, the system architecture 100 may include terminal device 110, network 120, and server 130. Terminal device 110 may include various electronic devices such as smartphones, tablets, laptops, and desktop computers. Server 130 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal device 110 and server 130, such as a wired communication link or a wireless communication link.

[0052] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of terminal devices, networks, and servers. For example, server 130 can be a server group composed of multiple server devices. In addition, the technical solutions provided in this application embodiment can be applied to terminal device 110, or to server 130, or can be implemented jointly by terminal device 110 and server 130. This application does not impose any special limitations on this.

[0053] In one embodiment of this application, the terminal device 110 or server 130 can acquire real-time status data of the target vehicle via a controller area network or Ethernet, then convert the real-time status data to obtain converted data, and provide the converted data to the application layer through an interface; then it receives and responds to the operation instructions input by the target object in the application layer, and calls the converted data to generate log information; wherein, the target object includes: the person driving the vehicle and the person riding in the vehicle; when the target vehicle is in the start state, the log information is parsed, and the cockpit software in the target vehicle is monitored based on the parsing result. Using the terminal device 110 or server 130 to execute the cockpit software monitoring method can provide a solution for monitoring the operating status of cockpit software, including saving detailed log information of program operation and recording the time spent on the operation of each link in the cockpit software. Time analysis is used to determine whether the cockpit software is operating normally. In the case of abnormal operation, the analysis of abnormal information can provide relevant personnel with maintenance or repair references, helping to improve the stability and security of the entire cockpit software.

[0054] The above sections introduced an exemplary system architecture that applies the technical solution of this application. Next, we will continue to introduce the cockpit software monitoring method of this application.

[0055] Figure 2 A schematic flowchart of a cockpit software monitoring method according to an embodiment of this application is shown. Specifically, in an exemplary embodiment, as follows... Figure 2 As shown, this embodiment provides a cockpit software monitoring method, which includes the following steps:

[0056] S210, real-time status data of the target vehicle is obtained through the controller domain network or Ethernet; as an example, the target vehicle in this embodiment includes, but is not limited to, new energy vehicles, fuel vehicles, etc.

[0057] S220, the real-time status data is transformed to obtain transformed data, and the transformed data is provided to the application layer through an interface;

[0058] S230, receive and respond to the operation instructions input by the target object at the application layer, and call the conversion data to generate log information; wherein, the target object includes: the person driving the vehicle and the person riding in the vehicle;

[0059] S240, when the target vehicle is in the startup state, the log information is parsed, and the cockpit software in the target vehicle is monitored based on the parsing results.

[0060] Therefore, this embodiment provides a scheme for monitoring the operating status of cockpit software, including saving detailed log information of program operation and recording the time spent on each part of the cockpit software operation. Time analysis is used to determine whether the cockpit software is operating normally. In case of abnormal operation, analysis of the abnormal information can provide relevant personnel with maintenance or repair references, helping to improve the stability and security of the entire cockpit software. In this embodiment, the architecture of the cockpit software is as follows: Figure 3 As shown. In Figure 3 In this system, the cockpit software adopts a layered architecture. At the bottom is the system's underlying layer, which primarily acquires real-time vehicle status data via CAN signals or Ethernet, including instrument panel data such as mileage, speed, fuel consumption, and battery level. It also includes in-vehicle information such as air conditioning settings, temperature, and seat adjustment status. The middle layer is the business component service layer, which acts as the link between the entire system. It primarily acquires data from the underlying layer through specified protocols and transforms the data. Simultaneously, it provides the transformed data to the application layer HMI through external interfaces. At the top is the application layer HMI, which consists of various application software that drivers and passengers can operate via the in-vehicle display. Through interface calls, it retrieves data from the business service layer for display and performs various control operations through the application layer HMI. Then, through the business component services, the data is distributed back to the underlying layer, thereby achieving control of the vehicle's infotainment system. Furthermore, during development, the cockpit software needs to record each key step and important process using a log-based approach. The logs include specified tags, process functions, exception information, and time information, and are saved to a designated database. The log saving function could be toggled, for example, only turned on during development, bench testing, and vehicle testing, and then turned off after mass production.

[0061] According to the above description, in an exemplary embodiment, the process of parsing the log information and monitoring the cockpit software in the target vehicle based on the parsing result includes: parsing the log information and determining whether a first log exists in the log information based on the parsing result; wherein the first log is used to record cockpit software functions that take longer than a preset time; if the first log exists, a prompt message indicating the existence of the first log is issued, the location of the first log is located, and the cockpit software is monitored based on the location of the first log; if the first log does not exist, determining whether a second log exists in the log information based on the parsing result; wherein the second log is used to record cockpit software malfunctions; if the second log exists, a prompt message indicating the existence of the second log is issued, the location of the second log is located, and the cockpit software is monitored based on the location of the second log; if the second log does not exist, the parsing result of the log information is displayed. Therefore, in this embodiment, as soon as the vehicle's infotainment system starts, the current program directly initiates the monitoring function. This primarily involves reading and analyzing the log information stored in the cockpit software from a designated database. If the analysis reveals that certain functions are taking too long or contain abnormal information, the analysis results are displayed and prompts are provided via voice or other means. For projects with UI display functions, the log information and abnormal information during project operation can be visualized, and the location of the log information can be pinpointed, thereby quickly guiding developers or personnel to perform corresponding checks.

[0062] In an exemplary embodiment, after generating log information by calling the converted data, this embodiment may further include: storing the log information in a preset database, and setting a log information storage switch; wherein, the log information storage switch includes: enabling log information storage during the cockpit software development stage, enabling log information storage during the bench testing stage of the target vehicle, enabling log information storage during the actual testing stage of the target vehicle, and disabling log information storage when the target vehicle reaches preset production conditions. The preset database includes at least one of the following: a local database established in advance or in real time, and a cloud database established in advance or in real time. As an example, this embodiment may further include: setting a data cleanup mechanism in the preset database; wherein, the data cleanup mechanism includes at least one of the following: performing data cleanup when files in the preset database reach a preset size, performing data cleanup when the date of data information in the preset database exceeds a preset duration, and performing data cleanup after data information in the preset database is marked as abnormal data. As an example, in this embodiment, the operating mechanism of the preset database is as follows: Figure 4 As shown. In Figure 4In this system, the database is directly placed within the monitoring software project. The monitoring software provides functions for saving, viewing, and modifying log data. All modules of the cockpit software can perform log information saving and modification operations through the interfaces provided by the monitoring software. The tables in the database need to be indexed according to actual needs, as the monitoring software queries log information in real time, and indexes improve efficiency for multiple and large-scale queries. Simultaneously, the database needs a data cleanup mechanism. For example, when the database file reaches a certain size, the data date exceeds a specified time, or the abnormal information has been analyzed and resolved, the corresponding information needs to be cleared to reduce the database's excessive consumption of vehicle system resources and ensure the stability of the entire cockpit software.

[0063] In summary, this application provides a cockpit software monitoring method. First, it acquires real-time status data of a target vehicle via a controller area network (CAN) or Ethernet. Then, it transforms the real-time status data to obtain transformed data, which is provided to the application layer through an interface. Next, it receives and responds to operation commands input by the target object at the application layer and uses the transformed data to generate log information. The target object includes: the person driving the vehicle and the passengers in the vehicle. When the target vehicle is in a startup state, the log information is parsed, and the cockpit software in the target vehicle is monitored based on the parsing results. Therefore, this method provides a solution for monitoring the operating status of cockpit software, including saving detailed log information of program operation and recording the time spent on each stage of the cockpit software operation. Time analysis is used to determine whether the cockpit software is operating normally. In case of abnormal operation, analysis of the abnormal information can provide maintenance or repair references for relevant personnel, helping to improve the stability and security of the entire cockpit software.

[0064] like Figure 5 As shown, this application also provides a cockpit software monitoring device, the device comprising:

[0065] The data acquisition module 510 is used to acquire real-time status data of the target vehicle through the controller domain network or Ethernet; as an example, the target vehicle in this embodiment includes, but is not limited to, new energy vehicles, fuel vehicles, etc.

[0066] Data conversion module 520 is used to convert the real-time status data to obtain converted data, and provide the converted data to the application layer through an interface;

[0067] The log generation module 530 is used to receive and respond to the operation instructions input by the target object at the application layer, and call the transformed data to generate log information; wherein, the target object includes: the person driving the vehicle and the person riding in the vehicle;

[0068] The monitoring module 540 is used to parse the log information when the target vehicle is in the startup state, and to monitor the cockpit software in the target vehicle based on the parsing results.

[0069] Therefore, this embodiment provides a scheme for monitoring the operating status of cockpit software, including saving detailed log information of program operation and recording the time spent on each part of the cockpit software operation. Time analysis is used to determine whether the cockpit software is operating normally. In case of abnormal operation, analysis of the abnormal information can provide relevant personnel with maintenance or repair references, helping to improve the stability and security of the entire cockpit software. In this embodiment, the architecture of the cockpit software is as follows: Figure 3 As shown. In Figure 3 In this system, the cockpit software adopts a layered architecture. At the bottom is the system's underlying layer, which primarily acquires real-time vehicle status data via CAN signals or Ethernet, including instrument panel data such as mileage, speed, fuel consumption, and battery level. It also includes in-vehicle information such as air conditioning settings, temperature, and seat adjustment status. The middle layer is the business component service layer, which acts as the link between the entire system. It primarily acquires data from the underlying layer through specified protocols and transforms the data. Simultaneously, it provides the transformed data to the application layer HMI through external interfaces. At the top is the application layer HMI, which consists of various application software that drivers and passengers can operate via the in-vehicle display. Through interface calls, it retrieves data from the business service layer for display and performs various control operations through the application layer HMI. Then, through the business component services, the data is distributed back to the underlying layer, thereby achieving control of the vehicle's infotainment system. Furthermore, during development, the cockpit software needs to record each key step and important process using a log-based approach. The logs include specified tags, process functions, exception information, and time information, and are saved to a designated database. The log saving function could be toggled, for example, only turned on during development, bench testing, and vehicle testing, and then turned off after mass production.

[0070] According to the above description, in an exemplary embodiment, the process by which the monitoring module parses the log information and monitors the cockpit software in the target vehicle based on the parsing result when the target vehicle is in the startup state includes: parsing the log information and determining whether a first log exists in the log information based on the parsing result; wherein the first log is used to record cockpit software functions that take longer than a preset time; if the first log exists, a prompt message indicating the existence of the first log is issued, the location of the first log is located, and the cockpit software is monitored based on the location of the first log; if the first log does not exist, determining whether a second log exists in the log information based on the parsing result; wherein the second log is used to record cockpit software malfunctions; if the second log exists, a prompt message indicating the existence of the second log is issued, the location of the second log is located, and the cockpit software is monitored based on the location of the second log; if the second log does not exist, the parsing result of the log information is displayed. Therefore, in this embodiment, as soon as the vehicle's infotainment system starts, the current program directly initiates the monitoring function. This primarily involves reading and analyzing the log information stored in the cockpit software from a designated database. If the analysis reveals that certain functions are taking too long or contain abnormal information, the analysis results are displayed and prompts are provided via voice or other means. For projects with UI display functions, the log information and abnormal information during project operation can be visualized, and the location of the log information can be pinpointed, thereby quickly guiding developers or personnel to perform corresponding checks.

[0071] In an exemplary embodiment, after generating log information by calling the converted data, this embodiment may further include: storing the log information in a preset database, and setting a log information storage switch; wherein, the log information storage switch includes: enabling log information storage during the cockpit software development stage, enabling log information storage during the bench testing stage of the target vehicle, enabling log information storage during the actual testing stage of the target vehicle, and disabling log information storage when the target vehicle reaches preset production conditions. The preset database includes at least one of the following: a local database established in advance or in real time, and a cloud database established in advance or in real time. As an example, this embodiment may further include: setting a data cleanup mechanism in the preset database; wherein, the data cleanup mechanism includes at least one of the following: performing data cleanup when files in the preset database reach a preset size, performing data cleanup when the date of data information in the preset database exceeds a preset duration, and performing data cleanup after data information in the preset database is marked as abnormal data. As an example, in this embodiment, the operating mechanism of the preset database is as follows: Figure 4 As shown. In Figure 4In this system, the database is directly placed within the monitoring software project. The monitoring software provides functions for saving, viewing, and modifying log data. All modules of the cockpit software can perform log information saving and modification operations through the interfaces provided by the monitoring software. The tables in the database need to be indexed according to actual needs, as the monitoring software queries log information in real time, and indexes improve efficiency for multiple and large-scale queries. Simultaneously, the database needs a data cleanup mechanism. For example, when the database file reaches a certain size, the data date exceeds a specified time, or the abnormal information has been analyzed and resolved, the corresponding information needs to be cleared to reduce the database's excessive consumption of vehicle system resources and ensure the stability of the entire cockpit software.

[0072] like Figure 6 As shown, this application also provides an example embodiment, which provides a cockpit software monitoring device, including: a cockpit software system, a real-time diagnostic system, and a database.

[0073] The cockpit software system adopts a layered architecture. At the bottom is the system's underlying layer, which primarily acquires real-time vehicle status data via CAN signals or Ethernet, including instrument panel data such as mileage, speed, fuel consumption, and battery level. It also includes in-vehicle information such as air conditioning settings, temperature, and seat adjustment status. The middle layer is the business component service layer, which acts as the link between the entire system. It primarily acquires data from the underlying layer through specified protocols and transforms the data. Simultaneously, it provides the transformed data to the application layer HMI through external interfaces. At the top is the application layer HMI, which consists of various application software that drivers and passengers can operate via the in-vehicle display. Through interface calls, it retrieves data from the business service layer for display and performs various control operations through the application layer HMI. Then, through the business component services, the data is distributed back to the underlying layer, thereby achieving control of the vehicle's infotainment system. Furthermore, during development, the cockpit software system needs to record each key step and important process using a log-based approach. The logs include specified tags, process functions, exception information, and time information, and are saved to a designated database. The log saving function could be toggled, for example, only turned on during development, bench testing, and vehicle testing, and then turned off after mass production.

[0074] The real-time diagnostic system starts monitoring as soon as the vehicle's infotainment system is powered on. It primarily reads and analyzes log information stored in the cockpit software system from a designated database. If the analysis reveals that certain functions take a long time or contain abnormal information, the results are displayed and prompts are provided via voice or other means. The system also features a UI display that visualizes log and abnormal information during operation and can locate the log information, thus quickly guiding developers or personnel to perform corresponding checks.

[0075] A database is used to store log information. This database is directly placed within the monitoring software project. The monitoring system provides functions for saving, viewing, and modifying log data. Various modules of the cockpit software system can perform log information saving and modification operations through the interfaces provided by the monitoring system. Tables in the database need to be indexed according to actual needs, as the monitoring system queries log information in real time; indexes improve efficiency for multiple and large-scale queries. Simultaneously, a data cleanup mechanism needs to be implemented in the database. For example, when the database file reaches a certain size, the data date exceeds a specified time, or the abnormal information has been analyzed and resolved, the corresponding information needs to be cleared to reduce the database's excessive consumption of vehicle system resources and ensure the stability of the entire system. Because monitoring the cockpit software system requires saving log information during system operation, especially log information from critical steps, the data volume in the entire cockpit system is particularly large, so a separate database is needed for data storage. Data in the database needs to be cleaned up after analysis, or after a specified time, when the data becomes outdated in terms of timeliness and functionality. Otherwise, the large data volume will cause the entire system to lag, having a counterproductive effect.

[0076] In summary, this application provides a cockpit software monitoring device. First, it acquires real-time status data of a target vehicle via a controller area network (CAN) or Ethernet. Then, it converts the real-time status data to obtain converted data, which is provided to the application layer through an interface. Next, it receives and responds to operation commands input by the target object at the application layer and uses the converted data to generate log information. The target object includes: the person driving the vehicle and the passengers in the vehicle. When the target vehicle is in a startup state, the log information is parsed, and the cockpit software in the target vehicle is monitored based on the parsing results. Therefore, this device provides a solution for monitoring the operating status of cockpit software, including saving detailed log information of program operation and recording the time spent on each stage of the cockpit software operation. Time analysis is used to determine whether the cockpit software is operating normally. In case of abnormal operation, analysis of the abnormal information can provide maintenance or repair references for relevant personnel, helping to improve the stability and security of the entire cockpit software.

[0077] It should be noted that the cockpit software monitoring device and the cockpit software monitoring method provided in the above embodiments belong to the same concept. The specific operation methods of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the cockpit software monitoring device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0078] Embodiments of this application also provide a cockpit software monitoring device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the cockpit software monitoring device implements the cockpit software monitoring method provided in the above embodiments.

[0079] Figure 7 A schematic diagram of a computer device suitable for implementing the cockpit software monitoring equipment of the embodiments of this application is shown. It should be noted that... Figure 7 The computer system 1000 of the cockpit software monitoring device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0080] like Figure 7 As shown, the computer system 1000 includes a Central Processing Unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1002 or programs loaded from storage portion 1008 into Random Access Memory (RAM) 1003, such as performing the methods described in the above embodiments. The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An Input / Output (I / O) interface 1005 is also connected to the bus 1004.

[0081] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. Removable media 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1010 as needed so that computer programs read from them can be installed into storage section 1008 as needed.

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

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

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

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

[0086] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the cockpit software monitoring method as described above. This computer-readable storage medium may be included in the cockpit software monitoring device described in the above embodiments, or it may exist independently and not incorporated into the cockpit software monitoring device.

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

[0088] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A cockpit software monitoring method, characterized in that, The method includes the following steps: Real-time status data of the target vehicle is obtained through the controller area network or Ethernet. The real-time status data is transformed to obtain transformed data, and the transformed data is provided to the application layer through an interface. The system receives and responds to operation instructions input by the target object at the application layer, and uses the transformed data to generate log information; wherein, the target object includes: the person driving the vehicle and the person riding in the vehicle; When the target vehicle is in the start-up state, the log information is parsed, and the cockpit software in the target vehicle is monitored based on the parsing results; The process of parsing the log information and monitoring the cockpit software in the target vehicle based on the parsing results includes: The log information is parsed, and the parsing result is used to determine whether a first log exists in the log information; wherein, the first log is used to record cockpit software functions that take longer than a preset time. If a first log exists, a notification message indicating the existence of the first log is issued, the location of the first log is located, and the cockpit software is monitored based on the location of the first log. If the first log does not exist, then based on the parsing result of the log information, it is determined whether a second log exists in the log information; wherein, the second log is used to record abnormal operation of the cockpit software; If a second log exists, a notification message indicating the existence of the second log is issued, the location of the second log is located, and the cockpit software is monitored based on the location of the second log. If a second log does not exist, the parsing result of the log information will be displayed.

2. The cockpit software monitoring method according to claim 1, characterized in that, After generating log information by calling the converted data, the method further includes: storing the log information in a preset database, and setting a log information storage switch; wherein, the log information storage switch includes: enabling log information storage during the cockpit software development stage, enabling log information storage during the bench testing stage of the target vehicle, enabling log information storage during the actual testing stage of the target vehicle, and disabling log information storage when the target vehicle reaches preset production conditions.

3. The cockpit software monitoring method according to claim 2, characterized in that, The preset database includes at least one of the following: a local database established in advance or in real time, or a cloud database established in advance or in real time.

4. The cockpit software monitoring method according to claim 2 or 3, characterized in that, The method further includes: setting a data cleanup mechanism in the preset database; wherein the data cleanup mechanism includes at least one of the following: performing data cleanup when the files in the preset database reach a preset size, performing data cleanup when the date of the data information in the preset database exceeds a preset duration, and performing data cleanup after the data information in the preset database is marked as abnormal data.

5. The cockpit software monitoring method according to claim 1, characterized in that, The target vehicles include: new energy vehicles and fuel vehicles.

6. A cockpit software monitoring device, characterized in that, The device includes: The data acquisition module is used to acquire real-time status data of the target vehicle via the controller area network or Ethernet. The data conversion module is used to convert the real-time status data to obtain converted data, and provide the converted data to the application layer through an interface; The log generation module is used to receive and respond to the operation instructions input by the target object at the application layer, and to call the transformed data to generate log information; wherein, the target object includes: the person driving the vehicle and the person riding in the vehicle; A monitoring module is used to parse the log information when the target vehicle is in the startup state, and monitor the cockpit software in the target vehicle based on the parsing results; the process of the monitoring module parsing the log information and monitoring the cockpit software in the target vehicle based on the parsing results when the target vehicle is in the startup state includes: The log information is parsed, and the parsing result is used to determine whether a first log exists in the log information; wherein, the first log is used to record cockpit software functions that take longer than a preset time. If a first log exists, a notification message indicating the existence of the first log is issued, the location of the first log is located, and the cockpit software is monitored based on the location of the first log. If the first log does not exist, then based on the parsing result of the log information, it is determined whether a second log exists in the log information; wherein, the second log is used to record abnormal operation of the cockpit software; If a second log exists, a notification message indicating the existence of the second log is issued, the location of the second log is located, and the cockpit software is monitored based on the location of the second log. If a second log does not exist, the parsing result of the log information will be displayed.

7. A cockpit software monitoring device, characterized in that, The device includes: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the device to implement the cockpit software monitoring method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the computer's processor, causes the computer to perform the cockpit software monitoring method as described in any one of claims 1 to 5.

Images