Virtual verification system and method for verifying functions of vehicle-mounted controller

Abstract

The invention belongs to the technical field of vehicle engineering, and particularly discloses a virtual verification system, which comprises vehicle virtualization software which comprises a plurality of virtual units, is used for simulating other entity vehicle-mounted modules except a vehicle-mounted controller, and comprises communication protocols for simulating other entity vehicle-mounted modules; the controller virtualization software is used for simulating software and hardware functions in a vehicle-mounted controller and comprises a test connection unit which serves as a test interface to communicate with an upper computer, receive simulation data for testing and send test result data; and the virtual microcontroller abstraction layer unit is used for simulating the IO behavior of the vehicle-mounted controller so as to communicate with the vehicle virtualization software through a communication protocol. The method has the advantage that the operation logic of the vehicle-mounted controller can be verified under the condition of being completely separated from a vehicle entity.

Description

Technical Field

[0001] The present invention relates to the field of vehicle engineering technology, and in particular to a virtual verification system, a method for verifying the function of an on-board controller, a computer device, and a storage medium. Background Art

[0002] Smart vehicles are the general trend of vehicle development. They need to undergo a lot of testing and verification work before mass production and delivery to ensure the safety and stability of smart driving vehicles. At present, the testing and verification methods include software in the loop SIL (Software in the Loop) testing, hardware in the loop HIL (Hardware in the Loop) testing, real vehicle in the loop VIL (Vehicle in the Loop) testing, real vehicle field testing and public road testing according to different R&D stages.

[0003] Among them, hardware-in-the-loop HIL testing is a special test for on-board controllers. In HIL testing, only the controller under test is real hardware, which also includes the software running in the hardware. With the advent of the era of intelligent vehicle software, the functions and performance of automotive software, especially on-board controllers, are becoming more and more complex. Faced with increasingly high requirements for software integration and verification, the current hardware-in-the-loop HIL testing method seems to be somewhat inadequate. Because testing always requires the participation of hardware, but the manufacturing cycle and manufacturing cost of hardware are in conflict with the rapid iteration of software. For the entire software integration and verification, the time is relatively long, and the hardware involved is more extensive, and the problem is not easy to locate. For integration engineers, it takes a lot of energy to complete the related work.

[0004] In addition, for vehicle controller development, due to the existence of a highly coupled system between software and hardware, it is difficult to conduct a relatively complete and detailed verification of the software itself. Therefore, many software problems are exposed at the end of development or even after installation, resulting in high maintenance and upgrade costs. For many extreme working conditions, it is difficult to simulate in hardware scenarios or it requires high costs to simulate, so such test cases are often ignored.

[0005] In view of the above problems, it is urgent to propose a software testing method that is less dependent on controller hardware. Summary of the invention

[0006] In order to solve the above problems, shorten the software verification cycle, and realize complete software integration without relying on any hardware carrier, the software integration and compilation can be completed in the early stage of software development, and the software can be fully verified at a low cost. The present invention proposes a virtual verification system, which communicates with a host computer in a pure software environment and receives test instructions from the host computer, including:

[0007] Vehicle virtualization software, including a plurality of virtual units for simulating other physical vehicle modules other than the vehicle controller, including simulating communication protocols of the other physical vehicle modules;

[0008] Controller virtualization software that simulates the software and hardware functions in an in-vehicle controller, including:

[0009] The test connection unit communicates with the host computer as a test interface, receives simulation data for testing and sends test result data;

[0010] The virtual microcontroller abstraction layer unit is used to simulate the IO behavior of the vehicle controller, so as to communicate with the vehicle virtualization software through a communication protocol.

[0011] In the above system, the host computer injects the simulation data for the test into the controller virtualization software or obtains the test result data by sharing memory with the controller virtualization software or by using a network protocol.

[0012] In the above-mentioned system, in the shared memory mode, the host computer or the controller virtualization software needs to verify whether the memory area to be read or written is being read or written before reading or writing the shared memory. When the memory area is not being read or written, the host computer or the controller virtualization software starts reading or writing.

[0013] In the above system, the host computer or the controller virtualization software updates the read / write flag to "reading / writing" when reading / writing the memory.

[0014] In the above system, when reading and writing the shared memory, the operation is performed with the actual data object type.

[0015] The present application also discloses a method for verifying the function of a vehicle-mounted controller, comprising the following steps:

[0016] Write stub functions based on the above virtual verification system;

[0017] Compiling the stub function together with the virtual verification system to generate an executable file executable by a computer device;

[0018] The executable file of the virtual verification system is run in at least one computer device, and verification is performed according to the data input by the host computer.

[0019] In the above method, the stub function is included in the virtual microcontroller abstraction layer unit to simulate the IO behavior of the vehicle controller.

[0020] In the above method, the stub function is included in the virtual microcontroller abstraction layer unit to simulate the IO behavior of the vehicle controller.

[0021] The present application also discloses a computer device, comprising:

[0022] at least one memory for storing computer instructions;

[0023] At least one processor implements the above method when the at least one processor executes the computer instructions.

[0024] The present application also discloses a computer-readable storage medium, in which at least one computer instruction is stored. The at least one instruction is loaded and executed by a processor to implement the above method.

[0025] Compared with the prior art, the present invention uses software that can run on mainstream operating system platforms such as Windows / Linux to simulate physical entities (such as functional units such as on-board controllers and battery managers) and software running in physical entities (also called firmware), so that the operating logic of the on-board controller can be verified completely without being separated from the vehicle entity, so that virtual calibration, single-step debugging and other tasks can be performed at an early stage, and imperfections can be corrected as early as possible.

[0026] Furthermore, since all functional units of the vehicle are simulated by software, the model of the controlled object can be changed arbitrarily, and the verification environment can be switched arbitrarily according to project requirements with high efficiency. Compared with traditional hardware-in-the-loop HIL testing, it can greatly save the capital investment in test hardware, and at the same time reduce the related hardware construction and debugging personnel, saving the cost and R&D cycle of project development.

[0027] In addition, for the testing process, the test cases of the virtualized verification system can be 100% reused without having to be adjusted according to hardware conditions. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is the architecture diagram of the AUTOSAR system;

[0029] Figure 2 It is a module diagram of the virtual verification system in this application;

[0030] Figure 3 is a software architecture diagram of the controller virtualization software in this application;

[0031] Figure 4a It is a schematic diagram of the application layer development and introduction of the controller virtualization software in this application;

[0032] Figure 4bIt shows the Rte and Os configuration diagram of the controller virtualization software 22 in this application;

[0033] Figure 5 is a flow chart of the method for verifying the function of the vehicle controller in this application;

[0034] Figure 6 It shows the connection relationship between the virtual modules during the test;

[0035] Figure 7 The display interface of the host computer is shown;

[0036] Figure 8 It is a schematic diagram of the hardware structure in this application. DETAILED DESCRIPTION

[0037] The following specific embodiments illustrate the implementation of the present invention, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. Although the description of the present invention will be introduced in conjunction with the preferred embodiment, this does not mean that the features of this invention are limited to this implementation. On the contrary, the purpose of introducing the invention in conjunction with the implementation is to cover other options or modifications that may extend based on the claims of the present invention. In order to provide a deep understanding of the present invention, the following description will include many specific details. The present invention can also be implemented without using these details. In addition, in order to avoid confusion or blurring the focus of the present invention, some specific details will be omitted in the description. It should be noted that the embodiments of the present invention and the features in the embodiments can be combined with each other without conflict.

[0038] It should be noted that in this specification, similar numbers and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings and is assumed to be the same definition.

[0039] It should also be stated that the methods and processes in the present invention are numbered for ease of reference, rather than to limit the order of precedence. If there is an order between the steps, the text description shall prevail.

[0040] In order to make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0041] Figure 1This is the architecture diagram of the AUTOSAR system. AUTOSAR (AUTomotive Open System ARchitecture) is a relatively common standardized software framework and open E / E system architecture in the automotive industry. It is developed and established to adapt to current smart vehicles. Compared with traditional software architecture, AUTOSAR, which is developed specifically for the smart vehicle industry, embeds a standard middle layer between the upper-level application software and the underlying hardware platform, realizing the decoupling of software and hardware. There are unified standards between the layers (software interface, file exchange format, methodology) to facilitate different manufacturers to develop their own software (firmware). Figure 1 As shown in Figure 1, the hardware foundation of the AUTOSAR system is the microcontroller, and its system software can be divided into three levels: application software layer (ASW Layer), runtime environment (RTE) and basic software layer (BSW Layer). Among them, the application software layer is composed of software components (SWC), each SWC can be understood as a .c file, and the entire application software layer can be regarded as a folder, containing multiple such SWC components. The runtime environment provides the operating environment for SWC, manages and schedules many SWCs, and manages the communication between ECUs and within ECUs. In other words, RTE is used to virtualize the functional bus, and RTE is embedded between ASW and BSW. Application software and basic software communicate or access hardware resources through RTE, and communication between application software can also be carried out through TRE. BSW provides necessary and general software support for ASW, including service layer, ECU abstraction layer and microcontroller abstraction layer. The communication between applications and between applications and BSW is completed through RTE to exchange data, thus achieving complete independence between applications and hardware.

[0042] In order to solve the problem that in the existing development cycle, the software (or firmware, referring to the software running in the microcontroller) of the vehicle controller is often developed first, while there is no supporting other automotive functional hardware at this time, and even the hardware of the vehicle controller itself has not been produced, thereby delaying the debugging progress of the vehicle controller software and being unfavorable for the modification and improvement of the software, this application proposes to develop a completely virtual (i.e., software-based) vehicle controller verification system based on the AUTOSAR system architecture.

[0043] Figure 2 The module diagram of the virtual verification system in the present application is shown. As shown in the figure, the virtual verification system 20 simulates all the components / functions of the entire vehicle with software that can run on a general operating system such as Windows / Linux. That is, the virtual verification system 20 provides a virtual car that can be used as a verification platform. When it is necessary to verify whether the logic of any electronic controller (Electronic Control Unit, ECU) in the car is reasonable and whether it can adapt to other functional components in the car (such as various sensors), the ECU can be used as the object to be tested, and other virtual functional units in the virtual verification system 20 can be used as controlled objects (objects that provide feedback data) for virtual verification. Data can be exchanged between the host computer 10 and the virtual verification system 20, and the host computer 10 can issue test instructions to the virtual verification system 20 in the form of data / data packets, and the test instructions can include data that limits the working conditions. For example, the host computer 10 sends the data "50 meters away from the front vehicle, current vehicle speed 100 km / h, front vehicle speed 80 km / h" to the virtual verification system 20, and the host computer 10 expects to receive the result that the virtual verification system 20 (i.e., ECU) issues a deceleration command and also detects the vehicle speed decreases. If the virtual verification system 20 (i.e., ECU) does not feedback this result, the verification fails and the ECU software needs to be modified.

[0044] Specifically, the virtual verification system 20 includes a controller virtualization software 22. The vehicle virtualization software 21 includes multiple virtual units for simulating other physical vehicle modules other than the vehicle controller under test, including simulating the communication protocol of the other physical vehicle modules. The other physical vehicle modules may include a vehicle speed measurement module, a distance measurement module, and other vehicle controllers. The controller virtualization software 22 is used to simulate the software and hardware functions in the vehicle controller under test, including simulating IO behavior, so that the controller virtualization software 22 can communicate with the vehicle virtualization software 21 to realize the interaction of the controller virtualization software 22 issuing instructions and the vehicle virtualization software 21 feeding back the execution results.

[0045] Those skilled in the art should know that the host computer 10 and the virtual verification system 20 are both software, which can be run on the same computer device or on two computer devices respectively. When the host computer 10 and the virtual verification system 20 are respectively run on two computer devices, the two computer devices can exchange data through a universal serial interface (such as RS-483), or through a network transmission protocol (such as TCP / IP). When the host computer 10 and the virtual verification system 20 are run on the same computer device, data can be exchanged by sharing memory. Furthermore, the host computer 10 can share memory with the controller virtualization software 22, and both realize data exchange by reading the same memory. For example, it is assumed that the data of the distance from the preceding vehicle is saved in the first register, the data of the speed of the vehicle is saved in the second register, and the data of the speed of the preceding vehicle is saved in the third register. When the host computer 10 needs to verify the rear-end collision avoidance function of the vehicle, the host computer 10 writes data to the first register, the second register and the third register respectively. After the controller virtualization software 22 reads the above data, it makes corresponding operation instructions according to the data and monitors the subsequent speed, vehicle distance and other data, and writes the updated data to the first register, the second register and the third register, thereby realizing the effect that the host computer sends the verification instruction and the controller virtualization software 22 controls the vehicle to react.

[0046] Further, in order to avoid read-write conflicts, the host computer 10 or the controller virtualization software 22 needs to verify whether the memory area (register) to be read and written is being read and written before reading and writing the shared memory. When the memory area is not being read and written, the host computer 10 or the controller virtualization software 22 starts reading and writing. Correspondingly, when reading and writing the memory, the host computer 10 or the controller virtualization software 22 updates the read-write flag to being read and written. For example, a structure with a marked status flag can be set for each shared memory, and whether to operate is determined by judging the status flag. Specifically, it can be compared with queuing and calling numbers. The role of the status flag in the structure is equivalent to the call number plate. The status flag can be used to record the order in which each thread requests to read and write. When the shared memory can allow the next thread to read and write the memory in order, the status flag is updated. Then the corresponding thread finds that its own status flag has changed, and it can start reading and writing the shared memory. When the response status flag of the thread indicates that the memory cannot be read and written, the thread can perform other tasks without having to wait (give up other tasks) for the status flag to be updated. Such memory read and write rules are conducive to each thread to make full use of time and improve the efficiency of program operation.

[0047] Based on the memory sharing mechanism, the host computer 10 and the controller virtualization software 22 can operate with the actual data object type without the need to adopt a fixed width method. The actual data object type can be a custom data structure. For example, a structure can be uniformly defined for shared data, and the variable types in the structure can be defined separately, such as float, uint, boolean, etc., or a mixture of multiple types. Therefore, there is no need to define the length of the structure. At the same time, the entire structure is operated during operation. As long as the structure of the structure is known in advance, the data can be correctly parsed and used.

[0048] Virtual verification is separated from physical hardware, but is connected to virtual hardware, so that verification failure caused by hardware problems can be eliminated. In other words, virtual verification can verify whether the control logic of ECU (including software and hardware) is correct with less interference. In the development cycle of intelligent vehicles, the research and development of the software part is advanced. Compared with the hardware equipment that needs to be designed before manufacturing, the development of software is relatively fast. When the first version of the software is released, the various hardware equipment of the vehicle, including the hardware of the ECU, is often not manufactured, which makes it impossible to implement hardware in the loop HIL (Hardware in the Loop) testing. The virtual verification system 20 proposed in this application comprehensively virtualizes the functions of the entire vehicle and can achieve the effect of HIL in a virtual environment. In addition, the virtual model of the controlled object can be changed arbitrarily, and the verification environment can be switched arbitrarily according to project requirements, which has high flexibility and high verification efficiency.

[0049] Figure 3 2 is a software architecture diagram of the controller virtualization software 22 in this application. Figure 1 As shown in the AUTOSAR system architecture, this application also virtualizes the controller (including software and hardware) into a three-layer architecture.

[0050] Corresponding to the application software layer, the controller virtualization software 22 includes an application software component (Application Software Component, Asw Swc) and a test connection unit (Test Swc). Asw Swc can usually integrate the application software of the physical controller (ECU) into the controller virtualization software 22 by importing. Test Swc acts as a test interface, which can communicate with the host computer 10, receive simulation data for testing, and send test result data. As mentioned above, Test Swc and the host computer 10 can communicate (exchange data) through a bus protocol or a network protocol, or exchange data through a shared memory.

[0051] Corresponding to the runtime environment, the RTE of the physical controller (ECU) can be integrated into the controller virtualization software 22 by importing.

[0052] Corresponding to the basic software layer, the controller virtualization software 22 includes a basic software component (Basic SoftWareComponent, Bsw Swc), an operating system (Operation System, OS) and a virtual microcontroller abstract layer unit (vMcal). Bsw Swc can integrate the Bsw layer of the physical controller (ECU) into the controller virtualization software 22 by importing. OS is an interface between the computer device running the virtual verification system 20. By adding configuration to the compilation tool (such as AAT tool), a software implementation body and interface file referring to the Autosar standard can be generated. vMcal is used to simulate the IO behavior of the vehicle controller, so as to communicate with the vehicle virtualization software through a communication protocol (such as CAN).

[0053] In some embodiments, each Swc software code can be automatically encapsulated and generated based on Autosar standard configuration information and tools, and a virtual operating system can be automatically configured to achieve correct and reliable calling of application software. Asw Swc can refer to Autosar standard generation and export, and Rte and Os also refer to Autosar standard generation software implementation and interface files. Bsw uses standard Bsw software library files provided by a third party. In this software architecture, according to the virtualization test requirements, vMcal and Test Swc are custom generated to build a test pile environment. vMcal simulates the IO behavior of the chip and the communication protocol of the peripheral chip (such as voltage sampling chip, temperature sampling chip, communication chip, etc.). Test Swc builds an interface with the test host computer, which can realize the sending of test simulation conditions and the uploading of test results.

[0054] In the above embodiment, the controller virtualization software 22 needs to virtualize (softwareize) the hardware of the physical controller, and then compile the virtualized hardware code and the software code of the physical controller together to obtain a virtualized controller. In order to be as close as possible to the actual operating state of the controller, the software architecture of the controller virtualization software 22 is developed with reference to the AUTOSAR system architecture, which is conducive to better simulation of the actual controller behavior.

[0055] Since AUTOSAR adopts a top-down methodology, model development is adopted from architecture design, interface description, software development, and functional component integration. Therefore, a code generation tool can be used to generate executable code after importing SWC description files, ECU description files, system constraint files, etc. into the tool. In the development process of the controller virtualization software 22, the Swc component of the application software layer can be automatically generated by extracting the Swc configuration file information and source code generated by the MBD tool. The code of the Rte layer can use the AAT tool to complete the Rte automatic configuration, thereby generating the Rte code. In addition, in order to realize the connection between the controller virtualization software 22 and the operating platform of the computer device (usually the Windows system), the necessary library files can be imported, the Api interface declaration file can be automatically created, and the necessary auxiliary files required for integration can be generated. Finally, the compilation file is written, the GCC compiler is called, all software files are compiled / linked, and the software library / executable file of the specified format is generated.

[0056] Furthermore, in order to realize the virtual verification system 20, it is also necessary to obtain the external input and output interface of the software, automatically call the MBD tool to generate the controlled object model (i.e., multiple virtual units in the vehicle virtualization software 21), and then develop a simulation platform, import the execution file and the model object file, and run the entire virtual verification system 20. The test conditions are injected between the virtual verification system 20 and the host computer 10 through the shared memory / TCP protocol, and the output of the virtual verification system 20 is obtained and compared to determine whether the virtual verification system 20 is running normally.

[0057] Figure 4a The schematic diagram of the application layer development and import of the controller virtualization software 22 in this application is shown. AUTOSAR is a layered software architecture, and the software requirements are implemented through the static configuration of each layer during design. Specifically, Simulink modules can be used to develop Swc, and a three-layer Atomic Subsystem architecture is used for development. The three-layer architecture is a relationship in which each layer is progressive and contains a layer. The bottom layer defines the data structure and the most "atomic" simple operations, such as Figure 4a In the example, the bottom-level module diagram illustrates a multiplication operation. The middle-level module diagram defines a function function() based on a predetermined trigger condition (e.g., time trigger). When the trigger condition is met, the multiplication operation shown in the bottom-level diagram is executed. In some other embodiments, the middle-level module diagram may include multiple bottom-level module diagrams with different functions to implement slightly more complex functions. Similarly, the top-level module may include one (e.g., Figure 4a As shown) or multiple middle-layer modules to achieve more complex functions. Figure 4aThe top-level module shown is a simple reference to a middle-level module and is only used to show the hierarchical relationship. The code inside each layer of the module can be automatically generated by the Simulink module based on the definition and configuration of each layer of the module.

[0058] 4b shows a schematic diagram of the Rte and Os configuration of the controller virtualization software 22 in the present application. The required software configuration files and source codes can be imported into the AAT tool, and the Rte and Os source codes can be configured and generated through the configuration function of the AAT tool.

[0059] The present application also discloses a method for verifying the function of the vehicle controller. Figure 5 : is a flow chart of a method for verifying the function of a vehicle controller in this application. Specifically, the method comprises the following steps:

[0060] S1, write a stub function based on the above-mentioned virtual verification system, wherein the stub function is included in the virtual microcontroller abstraction layer unit to simulate the IO behavior of the vehicle controller, or the stub function is included in the virtual microcontroller abstraction layer unit to simulate the IO behavior of the vehicle controller.

[0061] S2, compiles the pile function together with the virtual verification system to generate an executable file executable by a computer device. Specifically, during compilation, the source files generated by all ASW layers are uniformly compiled, and also the configuration information (xml file) generated by the ASW layer is imported into the Autosar tool to generate the necessary bottom module source code such as Rte and Os, compiled together with the source file of the ASW layer, and then linked into the target file, and the target file is a DLL file.

[0062] S3, running the executable file of the virtual verification system in at least one computer device, and verifying according to the data input by the host computer. Specifically, a variety of test cases can be written to input the executable file to verify the function or performance of the controller virtualization software 22. In some embodiments, test cases can usually be written according to existing Excel templates. Test cases can provide limiting conditions and expectations such as preconditions, test steps and expected results for each functional test.

[0063] Then the test cases are loaded into the Server (i.e. the host computer) one by one, and the Server executes the corresponding tests one by one according to the test steps of the use cases. Figure 6The connection relationship between each virtual module during the test is shown. The host computer 61 runs the simulation monitoring program loaded with the test case, communicates with the executable file 611 executable by the computer device through the shared memory (in some embodiments, it can also be through the TCP / IP protocol, but the real-time performance is poor), exchanges the data required by the test case, and the controller virtualization software 22 communicates with the host computer 61 through the communication interface, accepts the instructions and data given by the test case, and then gives corresponding feedback. If necessary, the controller virtualization software 22 also communicates with other vehicle-mounted modules through the communication network on the vehicle (such as CAN bus), thereby obtaining corresponding data from other vehicle-mounted modules, and then feeding back to the host computer 61.

[0064] In some embodiments, the host computer 61 can also use some development platforms to display the test interface. In one embodiment, the CANoe (CAN open environment) bus development environment is selected as the host computer display interface. Figure 7 The display interface is shown.

[0065] The embodiments provided by the present invention may be run in an electronic device 100. Specifically, the electronic device 100 may be a computer device or a server used to run the virtual verification system described in the present application. Figure 6 A basic hardware structure diagram of the electronic device 100 is given.

[0066] like Figure 6 As shown, the electronic device 100 at least includes a main processor 101 and a storage medium 103. According to different actual use requirements, the electronic device 100 may also include a coprocessor 102, an I / O unit 104, a network communication unit 105, and some other expansion units 106. The selectivity of the coprocessor 102, the I / O unit 104, the network communication unit 105, and other expansion units 106 is shown in the figure by dotted lines.

[0067] The main processor 101 and / or the coprocessor 102 are used to execute computer instructions stored in the storage medium 103 to implement the method proposed in the present invention. The main processor 101 is the control center of the electronic device 100, which is usually a general-purpose processor (for example, Intel's CPU series), which can achieve logical processing and arithmetic calculations in a relatively balanced manner. The main processor 101 uses various interfaces to connect various parts of the entire electronic device 100, and realizes various functions of the electronic device 100 by running or executing software programs stored in the storage medium 103, and calling data stored in the storage medium 103, thereby managing the electronic device 100 as a whole.

[0068] The coprocessor 102 is usually a dedicated processor (e.g., a user-programmable embedded microprocessor) used to implement a single function. For example, the coprocessor 102 may be a graphics processor (GPU) dedicated to processing graphics and images. The main processor 101 does not directly process information about graphics and images at this time, but provides data from other units to the coprocessor 102 or sends management instructions to the coprocessor 102 to instruct the coprocessor 102 to obtain data from other units, and after the coprocessor 102 processes the data, the main processor 101 receives the processing result from the coprocessor 102 so that other decisions can be made based on the processing result. For different professional fields, the coprocessor 102 can also be a signal processor, a network communication processor, a complex computing processor, etc. Usually, the hardware implementation basis of the coprocessor 102 is a digital signal processing (DSP) chip, or a complex programmable logic device (CPLD), a field programmable gate array (FPGA), and other application-specific integrated circuits (ASIC, Application Specific Integrated Circuit).

[0069] The storage medium 103 may include an internal memory and an external memory, or may also include a volatile memory and a non-volatile memory, or may also include a magnetic storage device, a solid-state memory, a flash memory, a floppy disk, and a hard disk. The storage medium 103 may be used to store an operating system (e.g., it may be executed by the main processor 101) and data generated during the operation of the operating system, a software program of an application software and data generated during the operation of the application software, and a software program of a dedicated module (e.g., it may be executed by a certain coprocessor 102) and data generated during the operation of the program. For example, in one embodiment of the present invention, the main processor 101 executes various functional applications and data processing by running a monitoring program stored in the storage medium 103. In some embodiments, the storage medium 103 may also be a remote memory (relative to a memory in the usual sense) remotely arranged relative to the main processor 101, and these remote memories may be connected to the main processor 101 or a certain coprocessor 102 via a network connection (e.g., via a network communication device 105). 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.

[0070] The I / O (Input / Output) unit 104 includes an information input device and an information output device, which enables a user to interact with the electronic device 100. The input device can be used to receive input digital or character information, and specifically can include: a keyboard, a mouse, a joystick, a touch input device or a trackball, etc. The output device can be used to output / display a processing result processed by the electronic device 100, and the processing result can be made based on the information input by the input device. Specifically, the output device can include: a liquid crystal display (Liquid Crystal Display, LCD), an organic light-emitting diode (Organic Light-Emitting Diode, OLED), etc.

[0071] The network communication unit 105 realizes communication between the electronic device 100 and various remote devices through the connection of the wired / wireless network, so that the electronic device 100 can also exchange data with the remote device (for example, the remote storage described above). Alternatively, the electronic device 100 can also realize connection with the server through the network communication unit 105, so that the electronic device 100 can interact with the server as part of a large system.

[0072] Other expansion units 106 include a variety of peripheral components and interfaces thereof, so that the electronic device 100 can interact with a variety of devices. For example, through a Bluetooth interface, it can be connected to a Bluetooth headset, so that the audio played by the electronic device 100 can be received by the Bluetooth headset. For another example, through a bus interface (such as an RS-485 bus), the electronic device 100 can be connected to some sensors to obtain some monitoring data to assist the electronic device 100 in implementing specific functions. In various embodiments, other expansion interfaces 106 can exist alone or be integrated with other components of the electronic device 100. At the same time, other expansion interfaces 106 are optional, and their optional nature is represented in the figure by dotted lines.

[0073] The present invention also provides a vehicle-mounted controller, comprising:

[0074] at least one memory for storing computer instructions;

[0075] At least one processor implements the above method when the at least one processor executes the computer instructions.

[0076] The present invention also provides a computer-readable storage medium, wherein at least one computer instruction is stored in the computer-readable storage medium, and the at least one instruction is loaded and executed by a processor to implement the above method.

[0077] The present invention also provides a computer program product, which includes computer instructions. When the computer instructions are executed, the above method is implemented.

[0078] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0079] Similarly, it should be understood that in order to streamline the present invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting the intention that the claimed invention requires more features than those expressly recited in each claim. Rather, as reflected in the claims, inventive aspects lie in less than all of the features of the individual embodiments previously disclosed. Therefore, the claims that follow the detailed description are hereby expressly incorporated into the detailed description, with each claim itself serving as a separate embodiment of the present invention.

[0080] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and in addition they may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive, all features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed in this manner may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0081] In addition, those skilled in the art will appreciate that, although some embodiments described herein include certain features included in other embodiments but not other features, the combination of features of different embodiments is meant to be within the scope of the present invention and form different embodiments. For example, in the claims, any one of the claimed embodiments may be used in any combination.

Claims

1. A virtual verification system, characterized in that: Communicate with the host computer in a pure software environment and receive test instructions from the host computer, including: Vehicle virtualization software, including a plurality of virtual units for simulating other physical vehicle modules other than the vehicle controller, including simulating communication protocols of the other physical vehicle modules; Controller virtualization software that simulates the software and hardware functions in an in-vehicle controller, including: The test connection unit communicates with the host computer as a test interface, receives simulation data for testing and sends test result data; The virtual microcontroller abstraction layer unit is used to simulate the IO behavior of the vehicle controller, so as to communicate with the vehicle virtualization software through a communication protocol.

2. The system according to claim 1, characterized in that The host computer injects the simulation data for the test into the controller virtualization software or obtains the test result data by sharing memory with the controller virtualization software or by using a network protocol.

3. The system according to claim 2, characterized in that In the shared memory mode, the host computer or the controller virtualization software needs to verify whether the memory area to be read or written is being read or written before reading or writing the shared memory. When the memory area is not being read or written, the host computer or the controller virtualization software starts reading or writing.

4. The system according to claim 3, characterized in that When reading and writing the memory, the host computer or the controller virtualization software updates the read-write flag to read and write.

5. The system according to claim 1, wherein: When reading and writing the shared memory, operations are performed with the actual data object type.

6. A method for verifying the function of an on-board controller, characterized in that: The steps include: Write a stub function based on the virtual verification system as described in any one of claims 1-5; Compiling the stub function together with the virtual verification system to generate an executable file executable by a computer device; The executable file of the virtual verification system is run in at least one computer device, and verification is performed according to the data input by the host computer.

7. The method according to claim 7, characterized in that The stub function is included in the virtual microcontroller abstraction layer unit to simulate the IO behavior of the vehicle controller.

8. The method according to claim 7, characterized in that The stub function is included in the virtual microcontroller abstraction layer unit to simulate the IO behavior of the vehicle controller.

9. A computer device, characterized in that: include: at least one memory for storing computer instructions; At least one processor, when the at least one processor executes the computer instructions, the scheduled charging is implemented in the circuit according to any one of claims 1-9.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer instruction, and the at least one instruction is loaded and executed by a processor to implement scheduled charging in the circuit as described in any one of claims 1-9.

Images