Vehicle-mounted software system simulation method and device, electronic equipment and storage medium

Abstract

The application provides a vehicle-mounted software system simulation method and device, electronic equipment and a storage medium. The method comprises the following steps: identifying and obtaining a vehicle body capability; abstracting and analyzing the vehicle body capability to obtain a corresponding hardware capability; and simulating the hardware capability to obtain a simulation result. In the above technical solution, the development board is not required for related development and debugging, the use scenarios of development and debugging are increased, cross-domain function development can be realized, the universality of development functions is increased, and the user experience is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data, more particularly, to a vehicle software system simulation method, a vehicle software system simulation device, an electronic device and a storage medium. BACKGROUND

[0002] At present, when developing a car machine system, due to the involvement of some special ability control functions of the vehicle body, a series of debugging work can only be carried out after entering the real vehicle, which affects the overall efficiency of the development process. It can be understood that for mobile phone development, there is a corresponding simulator for mobile phones. However, for the car machine system, there are too many limitations and there is no good simulator.

[0003] Generally, the vehicle cabin can include two systems, an instrument control system (QNX) and an information entertainment system (Android). For the instrument control system, there is no simulator for related system simulation, so the developers of the instrument control system need to use actual development boards to complete related development and debugging work. For the Android system, due to the introduction of the Google simulator, application developers or system developers can use the simulator to perform related system simulation and debugging.

[0004] However, there is no complete system simulation scheme for the combination of the above two systems, that is, the current car machine system, to solve the needs of actual car machine development. At present, when developing and debugging the car machine system (except for Android functions), a development board is needed for related development and debugging. This greatly limits the use scenarios and makes it difficult to realize the development and debugging of cross-domain functions.

[0005] Therefore, there is an urgent need for a new technical solution to solve the above technical problems. SUMMARY

[0006] A series of simplified concepts are introduced in the summary section, which will be further described in detail in the specific embodiment section. The summary section of the present application does not mean to try to limit the key features and necessary technical features of the claimed technical solution, nor does it mean to try to determine the protection scope of the claimed technical solution.

[0007] In a first aspect, the present application provides a vehicle software system simulation method, comprising: identifying and obtaining vehicle body capabilities; abstracting and analyzing the vehicle body capabilities to obtain corresponding hardware capabilities; and simulating the hardware capabilities to obtain simulation results.

[0008] Optionally, the simulating for the hardware capability to obtain the simulation result comprises: simulating for the hardware capability to obtain hardware data; aligning the hardware data to an application layer with a corresponding capability to obtain aligned data; and determining the first simulation result based on the aligned data.

[0009] Optionally, the simulating for the hardware capability to obtain the simulation result comprises: simulating for the hardware capability to obtain hardware data; submitting the hardware data to a network end to determine a second simulation result by a network server.

[0010] Optionally, the method further comprises: merging the first simulation result and the second simulation result to determine the simulation result.

[0011] Optionally, the method further comprises: performing development debugging on the simulation result in response to a debugging instruction of a user.

[0012] Optionally, the method further comprises: displaying a user interface, the user interface comprising a development debugging area, and performing development debugging on the simulation result in response to a debugging instruction of a user comprises: issuing a debugging instruction based on the user interface to perform development debugging on the simulation result.

[0013] Optionally, the method further comprises: displaying a user interface, the user interface comprising a vehicle body follow-up effect display area for displaying a vehicle body follow-up scene to the user to determine whether the command is successfully issued.

[0014] The second aspect further proposes a vehicle-mounted software system simulation device, comprising:

[0015] a recognition module configured to recognize and obtain a vehicle body capability;

[0016] a parsing module configured to abstract and parse the vehicle body capability to obtain a corresponding hardware capability;

[0017] a simulation module configured to simulate for the hardware capability to obtain a simulation result.

[0018] The third aspect further proposes an electronic device comprising a processor and a memory, wherein the memory stores computer program instructions, and the computer program instructions are used to execute the vehicle-mounted software system simulation method as described above when executed by the processor.

[0019] The fourth aspect further proposes a storage medium, wherein the storage medium stores program instructions, and the program instructions are used to execute the vehicle-mounted software system simulation method as described above when executed.

[0020] According to the technical scheme, the vehicle body capability is firstly recognized and obtained, and the vehicle body capability can be abstracted and analyzed, and it can be determined whether the hardware capability is needed, and then the hardware capability is simulated to obtain the simulation result. Thus, the development board is not needed in the technical scheme, and the use scene of the development and debugging is increased, and the cross-domain function development is realized, the universality of the development function is increased, and the user experience is improved.

[0021] The vehicle software system simulation method, other advantages, objects and features of the present application will be embodied in part by the following description, and will be understood by those skilled in the art through the study and practice of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0022] Various other advantages and benefits will become apparent to those of ordinary skill in the art, upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of preferred embodiments, and are not meant to limit the present application. Furthermore, the same reference numerals are intended to denote the same components throughout the accompanying drawings. In the drawings:

[0023] Figure 1 a schematic flow chart of a vehicle software system simulation method according to one embodiment of the present application is shown;

[0024] Figure 2 a schematic flow chart of simulating the hardware capability to obtain the simulation result according to one embodiment of the present application is shown;

[0025] Figure 3 a schematic flow chart of simulating the hardware capability to obtain the simulation result according to another embodiment of the present application is shown;

[0026] Figure 4 a schematic diagram of a user interface according to one embodiment of the present application is shown;

[0027] Figure 5 a schematic block diagram of a vehicle software system simulation device according to one embodiment of the present application is shown; and

[0028] Figure 6 a schematic block diagram of an electronic device according to one embodiment of the present application is shown. DETAILED DESCRIPTION

[0029] According to the above technical solution, the vehicle body capabilities are first identified and obtained. These capabilities can then be abstracted and parsed to determine if hardware support is required. Finally, simulation of the hardware capabilities yields the simulation results. Therefore, this technical solution eliminates the need for a development board for development and debugging, expanding the application scenarios for development and debugging. It also enables cross-domain development, increasing the breadth of development functions and improving the user experience.

[0030] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The technical solutions of the embodiments of this application will now be clearly and completely described in conjunction with the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0031] According to a first aspect of the present invention, a method for simulating an in-vehicle software system is proposed. Figure 1 A schematic flowchart of an in-vehicle software system simulation method 100 according to an embodiment of the present invention is shown. Figure 1 As shown, method 100 may include the following steps.

[0032] Step S110: Identify and obtain vehicle body capabilities.

[0033] Optionally, any existing or future technology capable of identifying vehicle body capabilities can be used to identify and obtain these capabilities. These capabilities can be abstract or concrete, such as rearview mirrors, air suspension, vehicle speed, etc. Preferably, to facilitate subsequent data processing, the obtained vehicle body capabilities can be categorized and organized.

[0034] Step S120 involves abstracting and parsing the vehicle body capabilities to obtain the corresponding hardware capabilities.

[0035] Optionally, through the above classification and arrangement operation, the inherent hardware required by the car machine simulator can be arranged. The inherent hardware required by these systems can be identified for the ability, and it can be identified that the system side has which hardware capabilities can be abstracted and embodied. For example, wireless fidelity technology (WiFi), screen, camera, etc. Through data simulation of these capabilities, the purpose of providing related hardware capabilities to the developer for calling and debugging can be achieved.

[0036] Step S130, simulating the hardware capability to obtain a simulation result.

[0037] Optionally, any existing or future technical solution that can realize simulation emulation can be used to simulate the hardware capability to obtain a simulation result. The simulation result can include the simulation result of the terminal side and the car machine end, and can also include the behavior simulation of the network side of the vehicle body.

[0038] According to the above technical solution, the vehicle body capability is first identified and obtained, and the vehicle body capability can be abstracted, analyzed, etc. It can be determined whether the hardware capability support is required, and then the hardware capability is simulated to finally obtain the simulation result. Therefore, in the above technical solution, the development board is not required for related development and debugging, which increases the use scenario of development and debugging, and also realizes the development of cross-domain functions, increases the universality of development functions, and improves the user experience.

[0039] In one embodiment, step S130 simulating the hardware capability to obtain a simulation result can include the following steps. Specifically, Figure 2 A schematic flow chart of step S130 simulating the hardware capability to obtain a simulation result according to one embodiment of the present application is shown. As shown in Figure 2 In this embodiment, step S130 can include the following steps.

[0040] Step S131, simulating the hardware capability to obtain hardware data.

[0041] As described above, through the classification and arrangement of the vehicle body capability, the inherent hardware required by the system can be arranged. The hardware capability of these hardware is simulated to obtain the corresponding hardware data.

[0042] Step S132, aligning the hardware data to the application layer with the corresponding capability to obtain aligned data.

[0043] In combination with the hardware capability simulated above, the hardware data can be aligned to the application layer with the corresponding capability, and the simulated hardware capability can be provided by the capability of the application layer. The application layer can be a hardware abstraction layer. For the hardware abstraction layer, if the corresponding capability is to be provided, the simulated data interface needs to be connected, and thus the hardware data can be obtained when the application calls the hardware capability. The alignment processing can be implemented by any existing or future technical solution, which is not limited in the present application. It can be understood that the hardware abstraction layer data obtained by the technical solution above is the aligned data.

[0044] In step S133, the first simulation result is determined based on the aligned data.

[0045] After obtaining the hardware abstraction layer data, the data can be connected and transmitted into the system, and the corresponding simulation effect can be formed and displayed on the system, i.e., the first simulation result is determined. The first simulation result includes the running condition of the application under the Android system.

[0046] Thus, the vehicle-mounted software can be simulated and developed by the separate system simulator, i.e., the Android simulator of the prior art can be used to simulate the Android environment.

[0047] In another embodiment, the step S130 of simulating the hardware capability to obtain the simulation result can further include the following steps. Specifically, Figure 3 A schematic flowchart of the step S130 of simulating the hardware capability to obtain the simulation result according to another embodiment of the present application is shown. As shown in the figure, Figure 3 In this embodiment, the step S130 can include the following steps.

[0048] In step S134, the hardware data is obtained by simulating the hardware capability.

[0049] As described above, by classifying and arranging the vehicle body capability, the inherent hardware required by the system can be arranged, and the hardware capability of the hardware can be simulated to obtain the corresponding hardware data. However, the abstraction layer data cannot be generated for the hardware data.

[0050] In step S135, the hardware data is submitted to the network end, and the second simulation result is determined by the network server.

[0051] Then, the hardware data can be submitted to the network end, and the running simulation is performed by the network server. For example, the hardware capability can be the action of the vehicle window. Specifically, the running effect of QNX is running on the network server, which can be displayed to the developer in the form of a remote mirror. It can be understood that the content displayed to the developer is the second simulation result.

[0052] Thus, compared with the existing simulator, i.e., the terminal-side simulator, the network-side dynamic simulation is added.

[0053] It can be understood that steps S131-S133 and steps S134-S135 belong to different steps according to whether the hardware data can be simulated by hardware capability, and there is no sequence in actual execution. The specific execution result is only related to the hardware data.

[0054] Optionally, the method 100 can further include: merging the first simulation result and the second simulation result to determine the simulation result.

[0055] It can be understood that the first simulation result and the second simulation result can be directly and simply merged to determine the simulation result. Then, the simulation results in the two cases can be integrated in the form of an online simulator to be presented to the developer.

[0056] Thus, the developer can develop and debug the simulation result through a unified online simulator or interface, the method is simple and easy to implement, and is convenient for the developer to operate.

[0057] Optionally, the method 100 can further include: step S140, in response to a debugging instruction of a user, developing and debugging the simulation result. For example, the user can input the debugging instruction through a manual input or a voice input, and it can be understood that the debugging instruction can be inputted by the user according to actual conditions or requirements. The user here is the developer mentioned above. After the developer inputs the debugging instruction, the simulation result can be developed and debugged in response to the debugging instruction.

[0058] Thus, the development and debugging of the simulation result can be realized through the above-mentioned interaction mode, the user operation is simple, and the possibility of operation error is reduced.

[0059] Preferably, the method 100 can further include: displaying a user interface, and the user interface includes a development and debugging area. In this embodiment, step S140, in response to a debugging instruction of a user, developing and debugging the simulation result, can include: step S141, issuing the debugging instruction based on the user interface to develop and debug the simulation result. Figure 4 A schematic diagram of a user interface according to an embodiment of the present application is shown. As shown in the figure, Figure 4As shown, for the Android system simulation, it can align the application layer with the corresponding capability in combination with the simulated hardware capability, and finally display the first simulation result in the Android system simulation display area. For the QNX and the vehicle body, it can run through the network server and display the second simulation result in the QNX system simulation display area or the vehicle body follow-up effect display area. Finally, the developer is presented with a result drawing after execution, i.e., the drawing of the simulation result after combining the first simulation result and the second simulation result.

[0060] Optionally, the method 100 can further include displaying a user interface including a vehicle body follow-up effect display area for showing the vehicle body follow-up scene to the user to determine whether the command is successfully issued.

[0061] Referring again to Figure 4 The vehicle body follow-up scene can be shown to the user through the vehicle body follow-up effect display area. For example, an application in the QNX or the Android system has the function of opening the rearview mirror, and at this time, the developer does not know whether the command is successfully issued. Therefore, after the command is issued, it can be directly observed in the vehicle body follow-up effect display area whether the command is successfully issued, and if so, the rearview mirror of the vehicle body is unfolded. Conversely, if the command is not successfully issued, the rearview mirror of the vehicle body does not move.

[0062] Thus, the behavior simulation of the vehicle body dynamics can be realized, so that the developer can more intuitively know whether the command is successfully issued.

[0063] According to a second aspect of the present application, a vehicle software system simulation device is further provided. Figure 5 A schematic block diagram of a vehicle software system simulation device 500 according to an embodiment of the present application is shown. As shown in the figure, Figure 5 The device 500 can include an identification module 510, an analysis module 520 and a simulation module 530.

[0064] The identification module 510 is configured to identify and obtain the vehicle body capability.

[0065] The analysis module 520 is configured to abstract and analyze the vehicle body capability to obtain the corresponding hardware capability.

[0066] The simulation module 530 is configured to simulate the hardware capability to obtain the simulation result.

[0067] According to a third aspect of the present application, an electronic device is further provided. Figure 6 A schematic block diagram of an electronic device according to an embodiment of the present application is shown. As shown in the figure, Figure 6As shown, the electronic device 600 can include a processor 610 and a memory 620, wherein the memory 620 stores computer program instructions which, when executed by the processor 610, are used to perform the in-vehicle software system simulation method as described above. The processor 610 can be implemented in at least one of a hardware form of a microprocessor, a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic array (PLA). The processor 610 can also be a combination of one or several of a central processing unit (CPU), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), or other forms of processing units having data processing and / or instruction execution capabilities, and can control other components in the electronic device 600 to perform desired functions. The memory 620 can include one or more computer program products. The computer program product can include various forms of computer readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory can include, for example, a random access memory (RAM), a cache, and / or the like. The non-volatile memory can include, for example, a read-only memory (ROM), a hard disk, a flash memory, and / or the like. One or more computer program instructions can be stored on the computer readable storage medium, and the processor 610 can execute the program instructions to implement the client functions (implemented by the processor) in the embodiments of the application described below and / or other desired functions. Various application programs and various data, such as various data used and / or generated by the application programs, and the like, can also be stored in the computer readable storage medium.

[0068] According to a fourth aspect of the present application, there is also provided a storage medium on which program instructions are stored, which, when executed, are used to perform the in-vehicle software system simulation method as described above. The storage medium can include, for example, a storage component of a tablet computer, a hard disk of a computer, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a portable compact disc read-only memory (CD-ROM), a USB memory, or any combination of the above storage media. The computer readable storage medium can be any combination of one or more computer readable storage media.

[0069] The specific details and advantages of the in-vehicle software system simulation apparatus, the electronic device, and the storage medium can be understood by those of ordinary skill in the art through reading the above description of the in-vehicle software system simulation method, and will not be repeated here for brevity.

[0070] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and / or device can be implemented in other manners. For example, the division of the units is only a logical function division, and there can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different units, or the among different units, can be indirect couplings or communication connections through some interfaces, and electrical, mechanical or other forms.

[0071] The units described as separated components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purposes of the embodiments.

[0072] In addition, each functional unit in the embodiments of the present application can be integrated in a processing unit, or each unit can exist physically as a separate unit, or two or more units can be integrated in one unit. The integrated unit can be implemented in the form of hardware, or in the form of a software functional unit.

[0073] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present application essentially, or the part that contributes to the prior art, or all or a part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in the embodiments of the present application. The foregoing storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and various media that can store program codes.

[0074] The above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method of simulating an in-vehicle software system, the method comprising: The method comprises: identifying and obtaining a vehicle body capability; abstracting and analyzing the vehicle body capability to obtain a corresponding hardware capability; simulating the hardware capability to obtain a simulation result; the simulating the hardware capability to obtain a simulation result comprises: simulating the hardware capability to obtain hardware data; aligning the hardware data to an application layer with a corresponding capability to obtain aligned data; determining a first simulation result based on the aligned data.

2. The in-vehicle software system simulation method of claim 1, wherein, the simulating the hardware capability to obtain a simulation result comprises: simulating the hardware capability to obtain hardware data; submitting the hardware data to a network end to determine a second simulation result through a network server.

3. The in-vehicle software system simulation method of claim 1 or 2, wherein, The method further comprises: merging the first simulation result and the second simulation result to determine the simulation result.

4. The in-vehicle software system simulation method of claim 3, wherein, The method further comprises: in response to a user's debugging instruction, developing and debugging the simulation result.

5. The in-vehicle software system simulation method of claim 4, wherein, The method further comprises: displaying a user interface, the user interface comprising a development and debugging area, the responding to a user's debugging instruction, developing and debugging the simulation result comprises: based on the user interface, issuing the debugging instruction to develop and debug the simulation result.

6. The in-vehicle software system simulation method of any one of claims 1 to 2, wherein, The method further comprises: displaying a user interface, the user interface comprising a vehicle body follow-up effect display area for displaying a vehicle body follow-up scene to a user to determine whether a command is successfully issued.

7. An in-vehicle software system simulation apparatus characterized by comprising: The method comprises: a recognition module for identifying and obtaining a vehicle body capability; an analysis module for abstracting and analyzing the vehicle body capability to obtain a corresponding hardware capability; a simulation module for simulating the hardware capability to obtain a simulation result; the simulation module is further configured to simulate the hardware capability to obtain hardware data; aligning the hardware data to an application layer with a corresponding capability to obtain aligned data; determining a first simulation result based on the aligned data.

8. An electronic device, comprising: A storage medium having stored thereon program instructions, which, when executed, cause a processor to perform the method of simulating a vehicle software system according to any one of claims 1 to 6.

9. A storage medium having stored thereon program instructions, which, when executed, cause a processor to perform the method of simulating a vehicle software system according to any one of claims 1 to 6.

Images