Instrumentation processing method, program execution method and related apparatus

Abstract

An instrumentation processing method, a program execution method and a related apparatus, which are applied to the technical field of simulation tests. The instrumentation processing method supports obtaining an instrumented program file on the basis of a DSL code file and a program file of a target program and by means of a target instrumentation mode among a plurality of instrumentation modes. A DSL can achieve lower syntax noise and is convenient to use; configuring a plurality of instrumentation modes enables users to select instrumentation tools as required, and enables adaptation to a plurality of instrumentation scenarios, improving the system optimization efficiency. The program execution method uses a plurality of simulated computing units to execute tasks obtained from program modeling, and performs serial processing on events by means of a global queue, so as to ensure clock synchronization, implementing collaborative simulation among a plurality of computing units and a plurality of OSs, thus satisfying system optimization requirements of embedded systems and improving the system optimization efficiency.

Description

Method for inserting a stub, method for running a program and related devices

[0001] The present application claims priority to the Chinese patent application No. 202410809002.9, filed on June 20, 2024, and entitled "Method for inserting a stub, method for running a program and related devices", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the technical fields of computer technology and simulation testing, and in particular, to a method for inserting a stub, a method for running a program and related devices. BACKGROUND

[0003] With the development of information technology and the continuous improvement of chip manufacturing process, embedded systems have been widely developed and applied, and more and more functional and complex devices are configured with embedded systems, such as devices in the fields of automobiles, industrial automation, military and aerospace, etc. The devices with complex software functions have strict requirements on the real-time performance and reliability of embedded systems, which makes the performance and safety of embedded systems a difficult problem that must be solved by system engineers.

[0004] Taking the field of automobiles as an example, with the continuous improvement of the capability of software defined vehicles (SDV), software will be deeply involved in the definition, development, verification, sales, service, etc. of automobiles. A large amount of software, including system software and application software, is applied to the fields of autonomous driving technology, vehicle networking technology, vehicle electronic architecture, data security, entertainment system, software upgrade, cloud service, etc., which realizes the continuous optimization of experience, process and value creation of automobiles. However, the requirements for embedded systems in vehicles are also increasing, for example, an intelligent driving system is a system with high software and hardware complexity. As users have higher and higher requirements on driving experience and riding comfort, the requirements on real-time performance, determinacy and safety of the intelligent driving system are also correspondingly improved, and the indicators of end-to-end latency and resource occupancy are particularly demanding. Therefore, the intelligent driving system is in a high-speed development scenario of continuous optimization and continuous iteration. Of course, not only the intelligent driving system, but also other embedded systems have optimization needs.

[0005] For optimization of embedded systems, currently, the embedded system is mainly manually optimized by expert experience, but the manual optimization method becomes inefficient and high in labor cost, and is difficult to adapt to the rapid iteration and commercial needs of the system. For example, with the rapid evolution and iteration of intelligent driving business and the growth of parameter space, the efficiency of the manual optimization method will become slower and slower. For another example, after improving a certain function of the system in a manual optimization manner, the developer needs to modify the code of the business application for adaptation, which increases the development difficulty of the business application, makes the development cost of the application high, and affects the application prospect of the system.

[0006] Based on the above background, how to meet the system optimization needs of the embedded system and improve the efficiency of system optimization is a hot issue that the person skilled in the art is studying. SUMMARY

[0007] The application provides a stubbing processing method, a program running method and related devices, which realize decoupling of business logic and system optimization logic, greatly reduce the complexity and cost of system optimization, and are beneficial to improving the determinacy, stability and security of the system.

[0008] In a first aspect, the application provides a stubbing processing method, which includes: obtaining a domain-specific language (DSL) code file, obtaining a program file of a target program, and obtaining a stubbed program file based on the DSL code file and the program file of the target program through a target stubbing manner. The DSL is a programming language for stubbing a field, which can be predefined. The DSL code file is written based on the DSL, and is used to indicate a stubbing point and an operation performed at the stubbing point. The stubbed program file is used to implement the business logic of the target program and the operation performed at the stubbing point.

[0009] The method can be applied to a stubbing processing system, and the stubbing processing system supports multiple stubbing manners. The target stubbing manner is any one of the multiple stubbing manners. Optionally, the stubbing processing system can be deployed in a device with computing capability, such as a chip, a host, a server, or a computing instance. For ease of description, some embodiments take the stubbing processing system or a stubbing processing device as an exemplary execution subject.

[0010] In the present application, the instrumentation processing system can obtain a DSL code file written in DSL, which is a computer language suitable for the field of instrumentation, can achieve smaller syntax noise, is easy to use, and can improve the ease of use and flexibility of the instrumentation processing system. During the upgrading and maintenance process, the DSL language of the special instrumentation can be easily used and maintained by the developer, reducing the cost of upgrading and maintenance. On the other hand, the instrumentation processing device can support multiple instrumentation methods, so that the developer can choose the instrumentation tool according to the needs, so that the present application can be applied to various instrumentation scenarios and has strong practicality.

[0011] In a possible implementation of the first aspect, the multiple instrumentation methods include compiler instrumentation, and in the case of the target instrumentation method being compiler instrumentation, the program file of the target program is the source code of the target program.

[0012] In another possible implementation of the first aspect, the multiple instrumentation methods include binary instrumentation, and in the case of the target instrumentation method being binary instrumentation, the program file of the target program is a compiled binary file corresponding to the target program.

[0013] In another possible implementation of the first aspect, the DSL supports one or more of the following instrumentation point granularities: module, function, instruction, and address aligned with a specified boundary. The DSL supports one or more of the following operations: variable acquisition, function, programming language syntax, and output, wherein the output methods include standard output stream, system log output, specified log file output, and memory writing.

[0014] In another possible implementation of the first aspect, the operations supported at the instrumentation points are implemented by calling a pre-configured instrumentation function library. The instrumentation function library includes a plurality of pre-defined function components, and the plurality of function components include one or more of the following function components: time delay analysis and statistics, hardware information analysis and statistics, memory information analysis and statistics, sandbox interface, parameter expansion interface, and string processing. In this way, the developer can select the function components in the instrumentation function library according to the needs, and the instrumentation function library covers the classic instrumentation operations in the system testing process, which can greatly reduce the development cost of the developer and is conducive to the rapid verification and iteration of the software.

[0015] In another possible implementation of the first aspect, the operations performed at the instrumentation points include collecting time delay information of the target communication link. The instrumentation processing method further includes: running the instrumented program file, and outputting the time delay information of the target communication link. Through the instrumentation processing method provided by the present application, the monitoring of the specific Topic communication delay can be realized.

[0016] In a further possible implementation form of the first aspect, the instrumentation points include a first instrumentation point and a second instrumentation point, and the operations performed at the instrumentation points include entering a sandbox at the first instrumentation point and configuring a performance tag, and exiting the sandbox at the second instrumentation point, the performance tag being related to available resources of a thread corresponding to the target program. The method further includes running the instrumented program file, performing resource allocation based on the performance tag of the thread corresponding to the target program when the first instrumentation point is reached, forming a sandbox and executing the thread of the service program in the sandbox, and exiting the sandbox when the second instrumentation point is reached. By means of the performance sandbox, the process can run in a resource-matched and relatively isolated environment, which can improve the running efficiency of the program and guarantee the security of the operating system.

[0017] In a further possible implementation form of the first aspect, the target service program includes a call to a first function, and the instrumentation point is a position at which the first function is called, and the operations performed at the instrumentation point include replacing the call to the first function with a call to a second function. In the above implementation form, the instrumentation processing system has a program analysis capability, and can replace the function call of the program file of the target program, so as to decouple the service logic and the optimization logic, and improve the security of the operating system.

[0018] In a second aspect, the present application provides a program running method, which includes modeling a target program to obtain a task model, and creating a plurality of tasks based on the task model of the target program. A plurality of events are obtained by executing the plurality of tasks by a plurality of computing units, and the plurality of events are added to a global queue so as to be executed in a serial logic. The events in the global queue are distributed to the plurality of computing units, and the clocks of the plurality of computing units are synchronized.

[0019] The method can be used in a software running system, which includes a plurality of simulated computing units, each of which corresponds to one or more kernels. In other words, in the present application, the software running system can simulate a plurality of computing units, create a plurality of tasks based on the task model of the target program, and place the events generated by the plurality of computing units when executing the tasks in a global queue, and then execute the events from the global queue on the corresponding computing units. In this way, the global queue can be used to realize the cooperative simulation of the plurality of simulated computing units. Since the plurality of computing units correspond to different kernels, the operating system (OS) running on the plurality of computing units is a hybrid OS. Therefore, the present application can realize the cooperative simulation of the hybrid OS.

[0020] In a possible implementation of the second aspect, the plurality of computing units are heterogeneous computing units. Heterogeneous here means that the computing units are different in hardware. Exemplarily, the plurality of computing units include a central processing unit (CPU), a micro processor unit (MPU), a microcontroller unit (MCU), an artificial intelligence cube (AIC) operator node, an artificial intelligence vector (AIV) operator node, a digital video pre-processing (DVPP) module, and the like. Of course, the computing units can include a special computing unit, an acceleration computing unit, which can also be referred to as an accelerator, and is mainly used to implement artificial intelligence (AI) related computing. The acceleration computing unit is, for example, the aforementioned AIC, AIV, and the like.

[0021] Optionally, the software running system can also simulate other hardware, such as input / output (I / O, or IO), memory, and the like.

[0022] In another possible implementation of the second aspect, the plurality of tasks include a first task, and the plurality of computing units include a first computing unit and an acceleration computing unit, and the acceleration computing unit is used to execute a specified task. The plurality of events obtained by executing the tasks by the plurality of computing units include: executing the first task by the first computing unit. The program running method further includes: adding a second task generated by the first computing unit in the process of executing the first task to an acceleration running queue. The acceleration running queue (or running queue) is used to arrange tasks (the second task belongs to the specified task) to be executed by the acceleration computing unit.

[0023] In the above embodiment, the first computing unit can generate a task, i.e., a second task, that needs to be executed by the acceleration computing unit in the process of executing the first task. In order to simulate the running process of a system with an acceleration computing unit, the second task is arranged in a queue and then dispatched to the acceleration computing unit for execution. In this way, the simulation of the system with the acceleration computing unit can be realized, the cooperation between the accelerator and other processors can be simulated, and the verification of the operating system with the accelerator and the program running in the operating system with the accelerator can be facilitated.

[0024] In another possible implementation of the second aspect, the program running method further includes: creating a first event, and the first event is used to query the execution of the second task asynchronously.

[0025] In the above embodiment, if the first computing unit generates the second task and the second task is added to the acceleration running queue, the software running system can create a first time to monitor the execution of the second task, so that the whole cycle management of the task scheduled to the acceleration processing unit can be realized, the system stability is improved, and the cooperation between the multiple computing units is also realized.

[0026] In another possible implementation of the second aspect, the program running method further includes: executing the second task by the acceleration computing unit, and after the execution of the second task is completed, creating a second event and adding the second event to the global queue to notify the first computing unit to process the second event.

[0027] In the above embodiment, after the execution of the second task by the acceleration computing unit is completed, the second event can be generated to notify the first unit to process the second time. In this way, the cooperation simulation between the multiple computing units can be realized.

[0028] In another possible implementation of the second aspect, the program running method further includes: obtaining a memory bandwidth flow condition of the software running system when the target task is scheduled to be executed, and generating a time delay of the target task based on the memory bandwidth flow condition of the software running system. In the above embodiment, the multiple tasks include the target task, and the software running system can monitor the memory bandwidth flow condition of the system when the target task is executed. Based on the memory bandwidth flow condition, the memory access time delay of the target task can be simulated. The time delay of the target task can reflect the running efficiency of the operating system or the target application, so as to facilitate the developers to design and test the hardware and software.

[0029] Optionally, the target task is a preselected task, or the target task is a task of the first type, or the target task is a task processed by the acceleration computing unit.

[0030] In another possible implementation of the second aspect, at least two computing units of the multiple computing units are used to jointly deploy a computing model, and each computing unit of the at least two computing units is used to deploy a part of the computing model. The program running method further includes: collecting state data of the at least two computing units when the tasks are executed, and obtaining a performance evaluation index of the computing model according to the state data.

[0031] Exemplarily, the state data includes one or more of the following data: inference time of the model part deployed by each computing unit of the at least two computing units, overall execution time of the computing model, and resource occupancy rate of the at least two computing units. The performance evaluation index includes one or more of the following data: end-to-end time delay, average response time of the computing model, maximum response time of the computing model, and resource occupancy rate of the at least two computing units.

[0032] Thus, by simulating the software running system, how the sub-graphs of the large model are split and deployed on the multi-DIE chip can be guided and verified, and by reasonably defining constraint conditions such as computing power, memory capacity, bandwidth, and in combination with the definition of key indicators such as end-to-end latency, average / maximum response time, CPU / AI core occupancy, and the like, an optimal deployment scheme can be solved.

[0033] In a third aspect, the present application provides a stub processing apparatus, which comprises units or modules for implementing the method described in the first aspect or any possible implementation manner of the first aspect. Illustratively, the stub processing apparatus comprises an acquisition module and a processing module, wherein the acquisition module is configured to implement one or more operations of acquisition, reception, generation, and the like. The processing module is configured to implement one or more operations of processing, determining, calculating, and the like.

[0034] In a fourth aspect, the present application provides a program running apparatus, which comprises units or modules for implementing the method described in the second aspect or any possible implementation manner of the second aspect. Illustratively, the stub processing apparatus comprises a plurality of simulated computing units, a modeling module, and a processing module. The modeling module is configured to model the target program and create tasks, and the processing module is configured to implement operations of task scheduling, event scheduling, and the like.

[0035] In a fifth aspect, the present application provides a stub processing system, which comprises a stub front end and a stub back end. The stub front end is configured to acquire a DSL code file, and the stub back end is configured to obtain a stubbed program file based on the DSL code file and a program file of the acquired target program. The stub processing system is configured to implement the method described in the first aspect or any possible implementation manner of the first aspect.

[0036] In a sixth aspect, the present application provides a software running system, which comprises a modeling module, an operating system layer, and a hardware layer. The hardware layer comprises a plurality of simulated computing units, and the operating system layer comprises a plurality of operating systems. The plurality of computing units correspond to the plurality of operating systems. The modeling module is configured to model a target program and create a plurality of tasks based on a model of the target program. The operating system is configured to execute the plurality of tasks through the plurality of computing units. The software running system is configured to implement the method described in the second aspect or any possible implementation manner of the second aspect.

[0037] In a seventh aspect, the present application provides an operating system simulation system, which comprises the stub processing system described in the fifth aspect and the software running system described in the sixth aspect.

[0038] Optionally, the operating system simulation system can be deployed in a device with computing capability, such as a chip, a host, a server, or a computing instance. Further, the operating system simulation system can be integrally deployed in one device or distributively deployed in multiple devices.

[0039] In an eighth aspect, the present application provides a computing device, comprising a processor and a memory, the memory being configured to store computer instructions, and the processor being configured to invoke the computer instructions to implement the method described in the first aspect or any possible implementation of the first aspect, or to implement the method described in the second aspect or any possible implementation of the second aspect.

[0040] In a ninth aspect, the present application provides a readable storage medium, the readable storage medium being configured to store a computer program, and when the computer program is executed by a processor, the communication device comprising the processor implements the method described in the first aspect or any possible implementation of the first aspect, or implements the method described in the second aspect or any possible implementation of the second aspect.

[0041] In a tenth aspect, the present application provides a computer program product, and when the computer program product is executed by a processor, the communication device comprising the processor implements the method described in the first aspect or any possible implementation of the first aspect, or implements the method described in the second aspect or any possible implementation of the second aspect.

[0042] The beneficial effects of the third aspect to the tenth aspect of the present application can refer to the beneficial effects of the first aspect or the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0043] The drawings needed to be used in the following embodiment description will be briefly introduced.

[0044] FIG. 1 is an architecture schematic diagram of a patching system provided by an embodiment of the present application;

[0045] FIG. 2 is a functional block diagram of a patching system provided by an embodiment of the present application;

[0046] FIG. 3 is a schematic diagram of a compiler patching manner provided by an embodiment of the present application;

[0047] FIG. 4 is a schematic diagram of a binary patching manner provided by an embodiment of the present application;

[0048] FIG. 5A is a schematic diagram of a patching operation provided by an embodiment of the present application;

[0049] FIG. 5B is a schematic diagram of a DSL code file provided by an embodiment of the present application;

[0050] FIG. 6 is a schematic diagram of another patching operation provided by an embodiment of the present application;

[0051] FIG. 7 is a schematic diagram of another patching operation provided by an embodiment of the present application;

[0052] FIG. 8 is a flowchart of a method for inserting a stub according to an embodiment of the present application;

[0053] FIG. 9 is a schematic diagram of an architecture of a software running system according to an embodiment of the present application;

[0054] FIG. 10 is a schematic diagram of an architecture of a software running system simulating an operating system running environment according to an embodiment of the present application;

[0055] FIG. 11 is a schematic diagram of a running process of a global queue according to an embodiment of the present application;

[0056] FIG. 12 is a schematic diagram of a simulation process of a software running system including multiple accelerators according to an embodiment of the present application;

[0057] FIG. 13 is a flowchart of a method for running a program according to an embodiment of the present application;

[0058] FIG. 14 is a schematic diagram of an architecture of a simulation test system of a hybrid OS according to an embodiment of the present application;

[0059] FIG. 15 is a schematic diagram of a running scenario of a simulation test system according to an embodiment of the present application;

[0060] FIG. 16 is a schematic diagram of a structure of a stub inserting device according to an embodiment of the present application;

[0061] FIG. 17 is a schematic diagram of a structure of a program running device according to an embodiment of the present application;

[0062] FIG. 18 is a schematic diagram of a structure of another computing device according to an embodiment of the present application. DETAILED DESCRIPTION

[0063] Some concepts involved in the present application will be introduced first.

[0064] 1. Stub, a stub refers to an operation of inserting a piece of code into another piece of code or replacing another piece of code by a certain strategy. Stubs are widely used in the field of software testing. A probe (which is essentially a piece of code for collecting information, and can be an assignment statement or a function call for collecting coverage information) is inserted into a program through a stub to collect characteristic data of the program running. The control flow and data flow information of the program can be obtained by analyzing the data, and the testing purpose is achieved.

[0065] 2. DSL, DSL is a computer programming language for a certain field with limited expressiveness. For example, the DSL in the present text can be a programming language for the field of stubs, which mainly supports two key aspects of semantics in the stub process: stub points and stub operations.

[0066] 3. Sandbox is a mechanism for running programs securely, allowing programs to run in an environment that is restricted by the operating system. Because the running environment is restricted, intruders who break into the program cannot access the facilities provided by the operating system without restriction, and even if hackers gain control of the program, the damage caused in the sandbox is limited. That is, attackers have to break through the sandbox restrictions to gain full control of the operating system. Many platform as a service (PaaS) systems provide real-time running environments, and the core of the real-time running environment is a sandbox application. In some solutions, multiple sandboxes can be built on top of the operating system, and the resources allocated to the multiple sandboxes can be different.

[0067] 4. Processor simulation simulates the running state of the processor in a software simulation manner, and realizes analysis and evaluation of performance, power consumption, etc. of the processor. Processor simulation is realized by a simulator, the simulator runs on a host computer, can simulate the architecture and running process of the target processor, and thus facilitates research and analysis of the target host. Using the simulator can effectively reduce the hardware cost, can flexibly configure the software and hardware, and facilitates computer researchers to design and test the hardware and software. The software to be tested can run on the host computer without dependence on hardware resources, and fully utilizes the host computer resources for effective and comprehensive testing, and the simulation environment can provide convenient conditions for debugging and running of the software and fault positioning.

[0068] 5. Computational graph, a computational graph is a data structure used to represent a computation process. A computational graph is a graph consisting of nodes and edges, where nodes represent computational units (such as matrix multiplication, addition, etc.), and edges represent data flow (i.e., the passing of data between computational units). In deep learning, computational graphs are used to represent the computation process of neural networks, which can help us better understand and debug the networks. Computational graphs are used in deep learning frameworks such as TensorFlow and PyTorch, and can be used to build, train, and evaluate neural networks. The advantage of using computational graphs is that they can dynamically build and modify the computation process at runtime, and can take advantage of hardware acceleration (such as GPUs) to improve computation efficiency. In summary, computational graphs are a data structure used to represent computation processes, and are widely used in deep learning to help us better understand and debug networks.

[0069] The above introduction to the terms can be applied to the embodiments below.

[0070] With the development of computer hardware and software technology, and the complexity of the function of computer equipment is constantly improving, people have higher and higher requirements for embedded systems. How to meet the system optimization needs of embedded systems and improve the efficiency of system optimization is a hot issue that the technical personnel in the field are studying.

[0071] In the optimization process of embedded systems, there are mainly two problems, one is the decoupling of the business logic and the system optimization logic of the embedded system, and the other is the simulation of the embedded system.

[0072] First, the decoupling of the business logic and the system optimization logic of the embedded system will be introduced. In the process of system optimization, the software, including application software and system software, needs to be instrumented to improve the efficiency of software running and design optimization.

[0073] First, the architecture and business scenarios of the instrumented processing system to which the embodiments of the present application can be applied will be introduced. It should be noted that the system architecture and business scenarios described in the present application are to more clearly illustrate the technical solutions of the present application, and do not constitute a limitation on the technical solutions provided by the present application. It should be understood that as the system architecture evolves and new business scenarios appear, the technical solutions provided by the present application are also applicable to similar technical problems.

[0074] Please refer to FIG. 1, which is an architecture diagram of an instrumented processing system according to an embodiment of the present application. The instrumented processing system 10 includes a DSL front end 101 and an instrumented back end 102. Wherein:

[0075] The DSL front end 101 is used to obtain a DSL code file, which is a file written in DSL. In the present application, the DSL code file is used to indicate an instrumented point and an operation performed at the instrumented point. Wherein, DSL is a computer design language used in the field of instrumentation, which will be described in detail below. Optionally, the DSL front end 101 also includes a DSL parser, which is used to parse the DSL code file. Of course, alternatively, the DSL parser can also be set in the instrumented back end 102, and the present application is also applicable to the case where the DSL parser is set in the instrumented back end 102.

[0076] The instrumented back end 102 is used to process the DSL code file and the program file of the target program to realize instrumentation. In the present application, the instrumented back end 102 supports multiple instrumentation tools, such as a compilation phase instrumentation tool and a binary instrumentation tool.

[0077] Further, the instrumentation backend can also include other instrumentation tools not shown in FIG. 1, such as Berkeley packet filter (BPF) compiler collection (BCC), uprobe, etc., to further expand the applicable scenarios of the framework.

[0078] Referring to FIG. 2, FIG. 2 is a functional block diagram of an instrumentation processing system according to an embodiment of the present disclosure. The functional block diagram shows the functions of the instrumentation processing system 10 in the form of modules and components. The instrumentation processing system 10 can include the following modules: a DSL parser, a compilation stage tool, a binary tool, an analysis tool, etc. The DSL parser module can include one or more of the following components: a lexer, a parser, a semantic analyzer, a DSL verifier, etc. The lexer is used for lexical analysis, the parser is used for syntax analysis in combination with context, the semantic analyzer is used for semantic analysis, and the verifier is used for verifying the analyzed semantics. The compilation stage tool module can include components for compilation, and can serve as a compilation stage instrumentation tool. For example, the compilation stage tool module can include an LLVM Pass component. LLVM originally refers to a low level virtual machine, but has evolved into a framework for building compilers. Pass is a structured technique for compiler development, which is used to complete the conversion, analysis or optimization of the compilation object (such as IR), etc. The binary tool module is used to implement binary rewriting, and can serve as a binary instrumentation tool. For example, the binary tool module can include a binary rewriter.

[0079] It should be understood that the front end and the back end here are used to distinguish different functional modules. Generally, the front end refers to the module that interacts, and the interaction here can include data input, output, editing and feedback, etc., and the back end is also called the server, which is used to implement data processing, business logic and security. In some solutions, the DSL front end 101 and the instrumentation back end 102 can be integrated in the same device (including physical devices and / or virtual devices), or can be integrated in different devices.

[0080] As an example of using the instrumentation processing system, a user can provide a DSL code file to the instrumentation processing back-end through the DSL front-end, the DSL code file being used to indicate the instrumentation points and the operations performed at the instrumentation points. Accordingly, the DSL back-end can obtain the DSL code file and the program file of the target program, and generate an instrumented program file based on the DSL code file and the program file of the target program through any supported instrumentation manner (for ease of distinction, referred to as a target instrumentation manner), the instrumented program file being used to implement the business logic of the target program and the operations performed at the instrumentation points.

[0081] In the instrumentation processing system provided in the present application, the instrumentation front-end supports defining the instrumentation code in a pre-defined DSL language, and the DSL is a computer language used in the field of instrumentation, which can achieve less syntax noise, is easy to use, and can improve the ease of use and flexibility of the instrumentation processing system. In the process of upgrading and maintenance, the DSL language used for special instrumentation can be easily used and maintained by developers, and the cost of upgrading and maintenance is reduced. In the instrumentation back-end, multiple instrumentation tools are integrated, so that developers can select the instrumentation tools according to the requirements, and the instrumentation processing system of the present application can be applied to various instrumentation scenarios, and the practicability of the instrumentation processing system is improved.

[0082] In some possible embodiments, the instrumentation processing system 10 can be deployed in a device with computing capability, such as a chip, a host, a server, or a computing instance, etc. The computing instance is, for example, a container, or a virtual machine, etc.

[0083] In some possible embodiments, the instrumentation back-end 102 further includes an instrumentation function library. The instrumentation function library includes one or more pre-defined components, which are used to implement some instrumentation operations. For example, the components in the instrumentation function library can pre-define one or more functions, and the call of the function can be defined in the DSL code file, and the call of the function in the instrumentation operation is implemented. For another example, the instrumentation operation can replace the call of a function of the target program with a function in the instrumentation function library. Of course, before the function is called or replaced, the parameters for the function call of the function library are prepared, which is not expanded here. Alternatively, the components in the instrumentation function library can be pre-configured or default set in the system, or imported by the user, or written by the user.

[0084] Exemplarily, the components of the instrumentation function library can include one or more of the following functional components: time delay analysis and statistics, hardware information analysis and statistics, memory information analysis and statistics, sandbox interface, parameter expansion interface, and string processing.

[0085] For example, in combination with FIG. 2, the analysis tool class module can be regarded as a library of instrumentation functions, which includes one or more of the following components: a variables logger, a latency monitor, a memory monitor, a memory monitor, a nice configer, etc.

[0086] As mentioned above, the DSL is a computer design language for the field of instrumentation, which covers two key aspects of semantics of the instrumentation process: instrumentation points and instrumentation operations. The DSL is described as follows.

[0087] In some possible implementation manners, in terms of the instrumentation points, in order to support arbitrary point instrumentation, the DSL supports various instrumentation granularities. For example, the instrumentation granularities include one or more of the following: a module, a function, an instruction, or an arbitrary address aligned with an instruction boundary, etc. For example, the instrumentation points can be an entry or an exit of a module, or a function name, a function call entry, a function call exit, a relative line number in a function, or a type of an instruction.

[0088] In some possible implementation manners, in terms of the instrumentation operations, the DSL can provide programming capabilities and runtime information, that is, a user can perform programming operations through the DSL language. For example, the DSL supports one or more of the following operations: variable acquisition, functions, programming language syntax, and output, where the output modes include a standard output stream, a system log output, a specified log file output, and writing into memory.

[0089] The variable acquisition can include at least one of the following three aspects. One is that the DSL supports acquisition of built-in variables at runtime, such as a function name, a called function name, a function argument, a return value, a register content, a process identifier (PID), a user identifier (UID), etc. The DSL supports user-defined local variables and global variables used in the instrumentation operations. The DSL supports user acquisition of information such as local variables, global variables, and structure members in target code. Two is that the DSL supports user-defined local variables and global variables used in the instrumentation operations. Three is that the DSL supports user acquisition of information such as local variables, global variables, and structure members in target code.

[0090] The DSL provides a lot of basic function interfaces and encapsulated function interfaces, and further supports user-defined functions. Exemplarily, the basic function interfaces include string processing, log output, etc., and the encapsulated function interfaces are mainly used to obtain and count some runtime information (such as the analysis tool class shown in FIG. 2), such as runtime delay, real-time memory, hardware information, control flow information, etc. The user-defined function refers to that the user can encapsulate some frequently used instrumentation operations into a function, and call the function at multiple instrumentation points, thereby increasing the reusability of the code in the DSL.

[0091] The DSL supports logical judgment, loop, array, structure, operation and comparison between basic types, and other programming language syntaxes.

[0092] In order to adapt to different use scenarios, the DSL also provides multiple output modes, such as standard output stream, system log output, specified log file output, and writing into memory. Among them, the standard output stream refers to the output stream realized by calling a pre-defined standard output object, which is similar to the System.out defined in Java. It is an instance of the java.io.PrintStream class and serves as the standard output stream of Java. This output stream is used to print text information to the console or terminal window.

[0093] As a possible application example, in a non-performance sensitive scenario, the output modes can include output to the standard output stream, output to the system log (syslog), or output to a specified log file, etc. In a performance sensitive scenario, the user can call a specific output interface to directly write the data (such as runtime data) to be output into memory after compression, and then periodically copy and save the content in the memory. Further, after the running ends, the user can use an offline data parser to analyze the data. The offline data parser will analyze and count the runtime compressed data in combination with the target instrumentation point and the corresponding operation information in the DSL. For example, in the system shown in FIG. 14, the modeling and analysis module can analyze the output data.

[0094] The foregoing describes the general running process of the instrumentation processing system. The following exemplarily introduces the implementation process of two kinds of instrumentation modes.

[0095] Please refer to FIG. 3, which is a schematic diagram of a compiler instrumentation method provided by an embodiment of the present application. The compiler is equipped with a compilation phase instrumentation tool, which can be regarded as an instrumentation back end (or part of the instrumentation back end). The input of the compiler includes a DSL code file and a program file of a target program. Of course, for the compiler instrumentation method, the program of the target program is the source code of the target program (also referred to as business source code). The compiler compiles the source code of the target program and the DSL file, and outputs an instrumented program file. Exemplarily, the instrumented program file includes a binary file and / or a library file.

[0096] Please refer to FIG. 4, which is a schematic diagram of a binary instrumentation method provided by an embodiment of the present application. The instrumentation back end includes a binary instrumentation tool. The input of the binary instrumentation tool is a compiled binary program and a DSL code file, i.e., a program file formed after the source code of the target program is compiled. The binary instrumentation tool rewrites the binary program based on the DSL code file, and outputs an instrumented program file. Exemplarily, the instrumented program file includes a binary file and / or a library file.

[0097] The instrumentation methods shown in FIG. 3 and FIG. 4 are only examples. In a specific implementation, the instrumentation processing system can include more instrumentation methods. It should be understood that, regardless of the instrumentation method selected, the instrumented program file can run in a test environment, a simulation environment, or a real use environment.

[0098] As mentioned above, the DSL supports defining multiple instrumentation operations. A user can define an instrumentation point and an operation performed at the instrumentation point by writing a DSL code file. The instrumented program file can perform the corresponding operation at the instrumentation point at runtime. The operation performed at the instrumentation point includes one or more of the following: obtaining runtime data and / or instructions, performing dynamic security reinforcement or resource management on an application, and the like.

[0099] To facilitate understanding, three implementation examples of the instrumentation operations are introduced below.

[0100] As an implementation example, the instrumented program file can obtain runtime data at runtime. For example, in a vehicle communication scenario, a data distribution service (DDS) is a widely used distributed real-time communication middleware protocol, which adopts a publish and subscribe architecture and can meet various distributed real-time communication application requirements. In DDS communication, a data publisher (Publisher) and a subscriber (Subscriber) establish contact through a Topic. Between components of a vehicle system and within a component, there can be a large number of DDS communication links, and when analyzing communication performance, it is often necessary to monitor the communication delay of a certain key communication link. Since differentiating different communication links can only be filtered through a Topic, it is required that a delay analysis tool must have fine-grained analysis capability.

[0101] Referring to FIG. 5A, which is a schematic diagram of an instrumented operation provided in an embodiment of the present application, in the present application, the DSL language can support variable acquisition and can instruct to monitor the delay of a specific communication link. As shown in the DSL code file in FIG. 5A, the delay of TOPIC1 can be monitored, that is, the start time is recorded when the publisher writes data to TOPIC1, and the end time of the delay is recorded when the subscriber reads data from TOPIC1, thereby monitoring the delay of TOPIC1. When the DSL code file and the program file of the target program are input into the instrumented back end, the instrumented program file can be obtained. When the instrumented program file is run, when the publisher, such as publisher 1, publisher 2, etc., writes data to TOPIC1, the start time of the delay can be recorded, and correspondingly, when subscriber 1, subscriber 3 reads the content from TOPIC1, the end time of the delay is recorded. For other Topics, such as TOPIC2, the instrumented program will not record the delay information thereof.

[0102] Further, the instrumented operation can further include outputting the delay information of the link satisfying the filtering condition, where the filtering condition is the information instructing TOPIC1, that is, the delay information of TOPIC1 can be outputted after being recorded. As can be seen, with the fine-grained analysis and secondary development capability provided by the instrumented processing system, the monitoring of the communication delay of a specific Topic can be achieved while decoupling the measurement logic and the business logic without recompiling the business code.

[0103] Referring to FIG. 5B, FIG. 5B is a schematic diagram of a DSL code file, which can include code segment 1, code segment 2 and code segment 3. Code segment 1 is used to define a latency pair ID, which can be a global variable. The latency pair ID is used to identify a pair of time points (i.e. start time point and end time point), for example, 0x01. Code segment 2 is used to implement the following function: when a publisher is detected to write in a qualified TOPIC (e.g. TOPIC1), record the latency start time (associated with the latency pair ID). Code segment 3 is used to implement the following function: when a subscriber is detected to read in a qualified TOPIC (usually consistent with the condition in the aforementioned code segment 2, for example, also TOPIC1), record the latency end time (associated with the latency pair ID). As can be seen, the present application supports defining global variables to distinguish different monitoring data, and supports monitoring latency of a specific communication link.

[0104] As yet another implementation example, the instrumentation operation includes entering / leaving a sandbox. In some scenarios, the operating system supports resource allocation based on performance tags, which can be associated with bandwidth, priority, etc., to form a sandbox (i.e. performance sandbox), such that a process with high priority and high bandwidth requirement can enter a sandbox with more abundant resources. Of course, the operating system can also support behaviors such as generation, use, transmission and integration of performance tags. Optionally, the instrumentation operation also includes configuring performance tags, so that a process can enter a sandbox with resources matching the resources required by the process.

[0105] Referring to FIG. 6, FIG. 6 is a schematic diagram of another example of the instrumentation operation. As shown in FIG. 6, in the test phase, the system optimization engineer confirms the key business that needs to be configured with the performance sandbox, confirms the instrumentation points and the instrumentation operation, and writes the corresponding DSL code file. The instrumentation points indicated in the DSL code file can include a first instrumentation point and a second instrumentation point, and the instrumentation operation can include entering the sandbox at the first instrumentation point and configuring the performance tag and exiting the sandbox at the second instrumentation point. The instrumentation back end receives the DSL code file and the program file of the target program, and implements the instrumentation. After the instrumentation, the application program can run in the running environment, and when the business thread is executed, the sandbox is entered at the first instrumentation point and exited at the second instrumentation point. The operating system can perform sandbox resource matching for the business thread according to the performance tag configured for the business thread at the first instrumentation point, so that the business thread can obtain the corresponding hardware resources. Exemplarily, the hardware layer can include a digital video pre-processing (DVPP) module, a system direct memory access (SDMA), an artificial intelligence cube (AIC) operator node (indicated as AIC in the figure), or an artificial intelligence vector (AIV) operator node (indicated as AIV in the figure), etc.

[0106] As another example of implementation, the instrumentation operation includes replacement of instructions. Exemplarily, the target business program includes a call to a first function, the instrumentation point is the position of calling the first interface, and the operation performed at the instrumentation point includes replacing the call to the first function with a call to a second function.

[0107] An application scenario is introduced below. Most operating systems have memory vulnerabilities, and use-after-free (UAF) is a typical memory vulnerability. UAF vulnerability is usually caused by improper memory allocation and release when a program uses dynamically allocated memory, resulting in misuse or reuse of memory. By using type-isolated heap memory management, UAF vulnerability can be effectively prevented. The main principle is to implement a type-based memory allocation framework in the kernel mode and provide a customized interface to the user mode. Users can call the customized interface to allocate different types of objects to different heap memories, thereby preventing cross-type occupation of heap blocks. In combination with FIG. 7, the original memory allocation interface prototype is void*malloc(size), the function name is malloc, and the input parameter is size, that is, the size information of the memory to be allocated. At this time, the object corresponding to the function call is not type-distinguished, which is easy to cause UAF vulnerability. The customized memory allocation interface prototype is approximately void*tmalloc(size, some_type_info), the function name is tmalloc, and when using the interface, in addition to size, additional type information (i.e., some_type_info) needs to be provided. The additional type information can be used to determine what type of instance object the newly allocated memory will be used for. The object corresponding to the call based on tmalloc is allocated memory, which can prevent cross-memory occupation of heap blocks and can prevent UAF vulnerability.

[0108] In combination with FIG. 7, by using the instrumentation system of the present application, when preventing UAF problems, the developer can write a DSL code file, the instrumentation points specified in the DSL code file can be all calls to the malloc function, and it is confirmed that the instrumentation operation is to replace the malloc function with the tmalloc function. After the instrumentation backend reads the DSL code file, it can perform program analysis to obtain type information of memory allocation (this step can be implemented by a pre-designed program). The instrumentation backend replaces the call to malloc with the call to tmalloc, and the type information of memory allocation is used as the input parameter some_type_info of the tmalloc interface. It can be seen that the instrumentation system of the present application also has program analysis capability, can replace the function call of the program file of the target program, realizes the decoupling of business logic and optimization logic, and improves the security of the operating system.

[0109] The above introduces several application examples of the instrumentation processing system. In specific implementation, the instrumentation processing system can also be applied in more scenarios and can implement more instrumentation operations. For example, the DSL code file is used to obtain data, indicators, etc. of a runtime operating system or application, or to dynamically secure, manage resources, etc. of the application.

[0110] The above describes the instrumentation processing system, and the following describes an instrumentation processing method provided by the present application.

[0111] Referring to FIG. 8, FIG. 8 is a flow diagram of an instrumentation processing method according to an embodiment of the present application. Optionally, the method can be applied to an instrumentation processing system, a simulation test system, etc., such as the above-described instrumentation processing system and the simulation system shown in FIG. 14. It should be understood that the terms, logics and operations described in FIG. 8 can refer to the above description of the functions of the instrumentation processing system.

[0112] The instrumentation processing method shown in FIG. 8 can include one or more of steps S801 to S803. It should be understood that, for the convenience of description, the steps S801 to S803 are described in this order, and it is not intended to limit the execution of the steps in the above order. The embodiments of the present application do not limit the order of execution, the time of execution, the number of execution, etc. of the one or more steps. The steps S801 to S803 are as follows:

[0113] Step S801: The instrumentation processing device acquires a DSL code file.

[0114] The instrumentation processing device is a device with computing capability, which can be used to implement the instrumentation backend 102 shown in FIG. 1. It should be understood that the execution subject here is only an example, and in actual implementation, the device executing the method can also not be called an instrumentation processing device, for example, other devices with computing capability, such as an instrumentation processing system, a computing device, a simulation platform, etc., can also execute the method.

[0115] DSL is a computer language designed for the field of instrumentation. In the present application, based on DSL, two key aspects of semantics of the instrumentation process can be defined: instrumentation points and instrumentation operations. Exemplarily, DSL supports one or more of the following instrumentation point granularities: modules, functions, instructions, addresses aligned with specified boundaries. DSL supports one or more of the following instrumentation operations: variable acquisition, functions, programming language syntax, output. The output modes include standard output stream, system log output, specified log file output and writing to memory. For details, refer to the foregoing description.

[0116] The DSL code file is a file written using DSL. It should be understood that the writing here can be written (or input) by a developer, or can be written by a computer program. The following describes several ways in which the instrumentation processing device acquires the DSL code file:

[0117] In the first obtaining manner, the instrumentation processing apparatus obtains the input DSL code file. Illustratively, a front end of the instrumentation processing system can provide a user interface, and a developer can input DSL code on the user interface to form a DSL code file. After the developer finishes writing on the user interface, the developer can submit the DSL code file, so that the instrumentation processing apparatus can obtain the DSL code file. Illustratively, the instrumentation processing apparatus can obtain the DSL code file by reading a file. For example, the developer or another service program can copy, import or configure the DSL code file to a designated file location, and the instrumentation processing apparatus can obtain the DSL code file by reading the file in the designated file location.

[0118] In the second obtaining manner, the instrumentation processing apparatus generates the DSL code file based on requirement information. The requirement information includes description information of the instrumentation point and description information of the instrumentation operation, and the instrumentation processing apparatus can generate the DSL code file in a computer language according to the requirement information. For example, the requirement information can be natural language description of the instrumentation point and the instrumentation operation.

[0119] Of course, the above obtaining manners are only examples. In specific implementations, there can be other manners for the instrumentation processing apparatus to obtain the DSL code file, for example, in a communication manner.

[0120] In step S802, the instrumentation processing apparatus obtains a program file of a target program.

[0121] The target program is a program to be instrumented. Illustratively, the target program can belong to a service application (i.e., an application program for completing a service function).

[0122] Optionally, the program file of the target program can be one or more of a source code, a library file, a binary program, etc.

[0123] In step S803, the instrumentation processing apparatus obtains an instrumented program file based on the DSL code file and the program file of the target program by a target instrumentation manner.

[0124] In this application, the instrumentation processing apparatus supports multiple instrumentation manners, and the target instrumentation manner is any one of the multiple instrumentation manners. That is, the instrumentation processing apparatus performs an instrumentation operation on the program file of the target program based on the DSL code file based on one of the multiple instrumentation manners, to obtain the instrumented program file. In this way, the developer or the instrumentation processing system can select an instrumentation tool according to a requirement, and this application is applicable to multiple instrumentation scenarios and has strong practicability.

[0125] In some possible implementations, the instrumentation manners supported by the instrumentation processing apparatus include one or more of the following manners: binary instrumentation, compilation phase instrumentation, BCC, or uprobe, etc.

[0126] Exemplarily, the target instrumentation manner is compiler instrumentation. In combination with FIG. 3, the instrumentation processing apparatus comprises a compiler, and the compiler is equipped with a compilation phase instrumentation tool. The input of the compiler comprises a DSL code file and a program file of a target program. The compiler can generate an instrumented program file according to the DSL code file and the program file of the target program. Further, the program file of the target program input into the compiler is source code of the target program (also referred to as business source code), and the program file output by the compiler can be a library file or a binary program.

[0127] Exemplarily, the target instrumentation manner is binary instrumentation. In combination with FIG. 4, the instrumentation processing apparatus comprises a binary instrumentation tool. The input of the binary instrumentation tool is a compiled binary program (regarded as a program file of a target program) and a DSL code file. The instrumentation processing apparatus rewrites the binary program based on the DSL code file, and outputs an instrumented program file. The instrumented program file can comprise a binary file and / or a library file.

[0128] In some possible implementation manners, the instrumented program file is used to implement business logic of the target program and is used to implement operations performed at the instrumentation points. Exemplarily, after the instrumented program file is run in a running environment, the instrumented program file can execute the business logic of the target program and perform corresponding operations at the instrumentation points. For related descriptions, refer to the foregoing implementation examples of the instrumentation operations.

[0129] In the embodiment shown in FIG. 8, the instrumentation processing apparatus can obtain a DSL code file written in a DSL. The language used by the DSL code file is a computer language suitable for the field of instrumentation, can achieve smaller syntax noise, is convenient to use, and can improve the ease of use and flexibility of the instrumentation processing system. In the process of upgrading and maintenance, the DSL language for special instrumentation can be easily used and maintained by developers, and the cost of upgrading and maintenance is reduced. Moreover, the instrumentation processing apparatus can support multiple instrumentation manners, so that developers can select instrumentation tools according to requirements, and the instrumentation processing system provided in the present application can be applied to multiple instrumentation scenarios and has strong practicability.

[0130] As a possible implementation, in a system optimization scenario, by using the instrumentation processing method provided in the present application, system optimization logic can be embedded into a program file of business logic in the form of a DSL code file, the business logic and the system optimization logic are decoupled, the complexity and cost of system optimization are greatly reduced, and the determinacy, stability and security of the system are improved.

[0131] The program file, such as the program file of the aforementioned target program, the program file after being instrumented, etc., can run in a software running system. If the program file is source code, the source code can run in the software running system after being compiled. The software running system herein can be an actual use environment or a simulation environment.

[0132] In the development process of an operating system and an application program, and in the design of a chip, in order to reduce cost and shorten the development cycle, a simulator is usually used for testing. The simulator runs on a host computer and can simulate the architecture and running process of a real processor system from the aspects of hardware and / or software, thereby facilitating the research and analysis of the object under test. The use of the simulator can effectively reduce hardware cost, flexibly configure software and hardware, and facilitate the design and testing of hardware and software by developers.

[0133] However, with the continuous development of the Internet of Things and artificial intelligence technology, in order to meet the needs of developers for high performance and high real-time performance of embedded systems, a multi-core system is often used. The multi-core system includes multiple processor cores, and communication and cooperation between the multiple cores are required when running software. With the increasing use of multi-core systems, in the development process of an operating system and an application program, and in the design of a chip, the architecture and running of the multi-core system need to be simulated, and the establishment of a simulation environment of a hybrid OS can provide convenient conditions for the debugging and running of software and fault positioning.

[0134] Therefore, the present application further provides a software running system which can be used as a simulator of multiple operating systems and simulate the architecture and running of a multi-core system. Please refer to FIG. 9, which is a schematic diagram of the architecture of a software running system according to an embodiment of the present application. The software running system 20 includes a modeling module 201, an operating system (or operating system layer) 202, and a hardware layer 203. In which:

[0135] The modeling module 201 is configured to model a target program to obtain a task module of the target program, and create multiple tasks based on the task module of the target program. As shown in FIG. 9, the program file of the target program is provided to the modeling module 201, and the modeling module 201 can model the target program based on the program file of the target program and create multiple tasks. The multiple tasks can include periodic tasks and / or event tasks, etc. The periodic tasks are tasks that need to be executed multiple times according to a certain period, and the event tasks are tasks triggered by events and triggered when certain conditions are met.

[0136] The hardware layer 203 is a hardware resource layer simulated by the software running system 20, and includes one or more of a computing unit, a storage unit, a control unit, and the like. For example, the hardware layer 203 can include one or more of a CPU, an MPU, an MCU, an AIC, an AIV, a DDR controller (DDRC), and the like. Taking the computing unit as an example, the computing unit of the hardware layer is a simulated virtual hardware with computing capability, and each computing unit includes one or more cores. For example, the hardware layer 203 includes multiple computing units, such as a computing unit 1, a computing unit 2, a computing unit 3, and the like as shown in FIG. 9.

[0137] The operating system 202 is used to process the plurality of tasks modeled, and is an operating system running on the simulated hardware layer 203. In some schemes, the operating system 202 can be referred to as a discrete event simulation for operating system (DES4OS) module, or simply as a DES4OS. As a possible implementation, the operating system 202 can simulate the running of multiple OSs. As shown in FIG. 9, the operating system 202 includes an operating system 1 and an operating system 2, and of course, the present application is also applicable to the case where the operating system 202 includes more or fewer OSs. For example, the operating system 202 can simulate the running of an automotive operating system (AOS) and a vehicle operating system (VOS). The AOS supports vehicle-level safety, has a rich AI native development library, and can improve the efficiency of modeling simulation, verification, and intelligent driving development. The VOS can be deployed on multiple cores while ensuring that applications are unaware of the multiple cores, and also supports digital twinning and on the air (OTA) technology.

[0138] In an embodiment of the present application, the software running system 20 can reuse the process management, task scheduling, time subsystem, and interrupt mechanism of the kernel, and add timer events, peripheral events, system scheduling events, and the like as standard events to a global queue. In the operating system 202, the global queue is processed by a thread, and new events generated in the processing process are also added to the global queue. For a computing unit including multiple cores, the events of the multiple cores are processed according to the serial logic of the global queue, so that the clock synchronization of the entire system is achieved.

[0139] In some possible implementation manners, the software running system 20 can be deployed in a device with computing capability, such as a chip, a host, a server, or a computing instance. Further, the modules of the software running system 20 can be deployed in the same device or can be distributed and deployed in different devices.

[0140] Optionally, the software running system further includes a VOS time analysis (VTA) that can perform visual analysis and optimization based on the output of the simulation of the operating system (i.e., the operating system 202). It should be understood that the VTA can be replaced by other visual analysis modules to analyze and optimize the output of other operating systems.

[0141] Further, the software running system can implement the cooperative simulation of complex software in the vehicle operating system and implement the abstraction of the vehicle operating system. The software system can also simulate the multi-core operating system based on heterogeneous hardware. That is, the multiple computing units in the hardware layer can be heterogeneous. Here, the heterogeneity refers to the difference between the computing units in the hardware, for example, the heterogeneity between the MPU and the MCU.

[0142] Referring to FIG. 10, FIG. 10 shows a software running system for simulating the running environment of the vehicle operating system. The operating system 202 is used to implement the simulation of the AOS and the VOS. The operating system 202 supports a scheduling table (also referred to as a static scheduling table) that is used to record objects to be scheduled and is generally applied in a real-time operating system. The scheduling table can include tasks, trigger events, execution time, and the like. The operating system supports multiple scheduling technologies, such as a completely fair scheduler (CFS), a round-robin (RR), a time partition (TP), a time trigger (TT), and the like, as shown in FIG. 10.

[0143] As can be seen from FIG. 10, the software running system 20 can realize the cooperative simulation of the hybrid OS, and the AOS and the VOS can be simulated to cooperatively run in the operating system 202. As can be seen from FIG. 11, which is a schematic diagram of a running process of a global queue according to an embodiment of the present application, the DES 4 OS (regarded as the operating system 202) abstracts the key events of the AOS and the VOS, such as the scheduling tick interrupt, the timer, and the key system call, and realizes the serial processing of the abstracted events through the global event queue, so as to simulate the parallel processing of the hybrid OS and the multi-core. For example, the AOS can be deployed on the MPU, and the VOS can be deployed on the MCU. The AOS deployed on the MPU realizes the support of multiple scheduling strategies through scheduling logic multiplexing, while ensuring that the scheduling logic is completely consistent with the actual kernel, so as to realize the simulation of the task timing level. The VOS deployed on the MCU also supports the multiplexing of the static scheduling logic and supports multiple static scheduling strategies. Further, when multiple OSs are included in the system, the multiple OSs have a unified clock time, that is, the same clock time is used to realize synchronization. As can be seen, the MPU and the MCU can both generate new events, and through the global queue and the unified clock, the cooperative simulation of the hybrid OS on the heterogeneous and multi-core complex system is realized.

[0144] As shown in FIG. 11, the AOS can be deployed on the MPU, and the VOS can be deployed on the MCU, and the hardware of the MPU and the MCU is heterogeneous. When the MPU and the MCU execute tasks, events such as the high-precision clock scheduling event (Hrtick event), the SC event, and the interrupt request (IRQ) event (IRQ event) can be generated. These events are placed in the global queue and are serially processed, so as to realize the cooperative simulation of the hybrid OS on the heterogeneous and multi-core complex system.

[0145] In some possible implementation manners, the hardware layer of the software running system 20 can simulate (that is, simulate) multiple heterogeneous hardware. For example, the computing unit of the software running system can include an AI accelerator (or an acceleration computing unit). Further, the hardware layer simulated by the software running system 20 can include multiple accelerators, which can be homogeneous or can include heterogeneous accelerators.

[0146] As shown in FIG. 12, which is a schematic diagram of a simulation process of a software running system including multiple accelerators according to an embodiment of the present application, in the simulation framework of the hybrid OS, the hardware layer can include an AI core including multiple DIE. The software running system maintains two queues, a global event queue and a running queue of the AI core. The global event queue is used to store events generated in the task execution process, and the running queue is used to store tasks to be processed by the AI core.

[0147] In combination with FIG. 12, some tasks of the CPU core (or MPU, MCU) can generate and issue AI core tasks, and the CPU core can generate an SQ event, which can submit the task to the running queue of the AI core (operation ① in FIG. 12). Alternatively, in some schemes, the CUP core can submit a query event to a global queue, which is used to query the execution status of the task submitted to the running queue of the AI core (for example, the queuing status, whether it is scheduled to the AI core for execution, the information of the AI core to which it is scheduled, etc.).

[0148] The running queue of the AI core supports multiple scheduling strategies. When the AI core is idle, the scheduler can take a task that meets the scheduling condition from the running queue and schedule it to the AI core for execution (operation ② in FIG. 12). In some schemes, a plurality of AI cores (taking AI core AIC as an example) can form a group, and a plurality of groups form a DIE. The group is the smallest scheduling unit, and the AI core is the smallest computing unit. In this scheme, each group maintains a queue, and when the group is idle, it takes a task from the corresponding running queue and completes the task by the AI cores in the group. When the task is executed and completed, a CQ event is generated, which is used to notify the corresponding CPU core to process the event (operation ③ in FIG. 12). Subsequently, the CPU scheduling processing flow is entered (operation (④) in FIG. 12), for example, an IRQ event can be generated.

[0149] In some possible embodiments, the software running system 20 also supports monitoring indicators or data during program running.

[0150] As a possible implementation, the software running system 20 also supports simulation of memory bandwidth. In this case, the software running system 20 can monitor the traffic of the memory bandwidth when the task is scheduled for execution, so as to calculate the latency information of the task. Exemplarily, when the target task is scheduled for execution, the software running system 20 obtains the memory bandwidth traffic. Based on the memory bandwidth traffic, the memory access latency of each memory-intensive task can be simulated, so as to further determine the total execution time of the task. The target task can be predefined or pre-defined. For example, the target task is a pre-selected task, or the target task is a task of the first type (such as a memory access intensive task), or the target task is a task processed by the acceleration computing unit (AI core).

[0151] As a possible implementation, the software running system 20 supports model splitting for deployment on multiple computing units. For example, the computation graph of a model can be split into multiple subgraphs, which can be deployed on different computing units (including accelerated computing units). The software running system 20 can monitor state data when the computing units perform tasks, and obtain performance evaluation indicators of the model according to the state data. For example, the software running system 20 supports simulation of key indicators of a large model split deployment, such as inference time of a part of a submodel of the model, overall execution time of the model, and heterogeneous core resource occupancy, etc. In this way, through simulation of the software running system, it can be guided to verify how the subgraphs of the large model are split and deployed on a multi-DIE chip, and by reasonably defining constraints such as computing power, memory capacity, bandwidth, etc., combined with the definition of key indicators such as end-to-end latency, average / maximum response time, CPU / AI core occupancy, etc., an optimal deployment scheme can be obtained.

[0152] Through the software running system 20 of the present application, the running architecture and running process of a heterogeneous, multi-core system can be simulated, which facilitates testing of software running and also helps to optimize the operating system. Further, the software running system 20 can also obtain state data in the software running process, and based on the state data, the operating system can be optimized, which greatly improves the development and debugging efficiency.

[0153] In some scenarios, the foregoing software running system 20 can realize reuse of the kernel scheduling module and the measurement mechanism, implement the corresponding scheduling logic in the user mode, and abstract the heterogeneous hardware, so that the overall simulation system can be efficiently executed in the user mode, and the simulation efficiency and simulation efficiency are greatly improved. For example, a newly developed scheduling algorithm can be tested in the simulation system, and the function of the scheduling algorithm and the benefit to the key indicators of the overall system can be verified, and the verified scheduling algorithm can be reused in the actual kernel, which greatly improves the development and debugging efficiency.

[0154] The software running system 20 is introduced above, and the program running method provided by the embodiments of the present application is introduced below.

[0155] Please refer to FIG. 13, which is a flowchart of a program running method provided by an embodiment of the present application. Optionally, the method can be applied to a software running system, such as the systems shown in FIGS. 9 to 12. The program running method shown in FIG. 13 can include one or more steps in steps S1301 to S1305. It should be understood that, for the convenience of description, the steps S1301 to S1305 are described in this order, and it is not intended to limit the execution in the above order. The embodiments of the present application do not limit the order of execution, the time of execution, the number of execution, etc. of the one or more steps. Steps S1301 to S1305 are as follows:

[0156] Step S1301: The software running system models the target program to obtain a task model.

[0157] As shown in FIG. 9, the software running system includes a modeling module, which can receive a program file of the target program and analyze to obtain a task model of the target program.

[0158] Step S1302: The software running system creates a plurality of tasks based on the task model of the target program.

[0159] The plurality of tasks can include one or more of a periodic task, an event task, etc.

[0160] Step S1303: The software running system executes the plurality of tasks through a plurality of computing units to obtain a plurality of events.

[0161] The software running system can simulate a plurality of computing units, such as one or more of a CPU, an MPU, an MCU, an AIC, an AIV, etc.

[0162] Optionally, the plurality of computing units can include general computing units, such as a CPU, an MPU, an MCU, etc., and can also include accelerated computing units, such as an AIC, an AIV, etc.

[0163] When executing a task, a computing unit can trigger a plurality of events. For example, a CPU can trigger a high-precision clock invocation event, an SC event, an IRQ event, etc.

[0164] Step S1304: The software running system adds the plurality of events to a global queue to enable the plurality of events to be executed in a serial logic.

[0165] Please refer to FIGS. 11 and 12, the events generated during software running can be added to the global queue, and the plurality of computing units are scheduled through the global queue to realize the cooperation between the plurality of computing units.

[0166] The time in the global queue can be scheduled to the corresponding computing unit for execution in a serial logic.

[0167] Step S1305: The software running system distributes the events in the global queue to the plurality of computing units based on the serial logic.

[0168] The clock synchronization between the plurality of computing units can refer to the description in the foregoing system part.

[0169] In some possible embodiments, the software running system is capable of simulating the interaction between multiple computing units. For example, the multiple tasks include a first task, and the multiple computing units include a first computing unit and an acceleration computing unit. The acceleration computing unit is configured to perform a pre-designated task, such as an AI acceleration task. Specifically, the software running system performs the first task by using the first computing unit. During the execution of the first task, a second task can be generated, and the second task needs to be scheduled to the acceleration computing unit for execution. The software running system can add the second task generated by the first computing unit during the execution of the first task to an acceleration running queue, and the acceleration running queue is configured to arrange the tasks to be executed by the second acceleration computing unit, and the second task belongs to the designated task. Further, the software running system can create a first event, and the first event is configured to query the execution of the second task asynchronously.

[0170] Further, the acceleration computing unit executes the second task, and after the execution of the second task is completed, the software running system creates a second event and adds the second event to a global queue, to notify the first computing unit to process the second event. In this way, the simulation of the cooperation between the acceleration computing unit and the general computing unit can be realized.

[0171] In some possible embodiments, when a target task is scheduled to be executed, the software running system obtains a memory bandwidth traffic condition, and the target task belongs to the multiple tasks. Based on the memory bandwidth traffic condition of the software running system, a time delay of the target task is generated. Optionally, the target task is a pre-selected task, or the target task is a first type of task, or the target task is a task processed by the acceleration computing unit.

[0172] In some possible embodiments, at least two computing units of the multiple computing units are configured to jointly deploy a computing model, and each computing unit of the at least two computing units is configured to deploy one part of the computing model. For example, the computing graph of the computing model can be split into multiple sub-graphs, and each computing unit is configured to deploy one or more sub-graphs. Further, the software running system is capable of collecting state data of the at least two computing units during the execution of the tasks, and based on the state data, a performance evaluation index of the computing model is obtained.

[0173] Further, the state data includes one or more of the following data: an inference time of the model part deployed by each computing unit of the at least two computing units, an overall execution time of the computing model, and a resource occupancy rate of the at least two computing units. The performance evaluation index includes one or more of the following data: an end-to-end time delay, an average response time of the computing model, a maximum response time of the computing model, or a resource occupancy rate of the at least two computing units.

[0174] In the embodiment shown in FIG. 13, the software running system can implement multiplexing of the kernel scheduling module and the monitoring mechanism, implement corresponding scheduling logic in the user state, and abstract heterogeneous hardware, so that the overall simulation system can be efficiently executed in the user state, and the simulation efficiency and the simulation efficiency are greatly improved.

[0175] In some possible implementation manners, the instrumentation processing system 10 shown in FIG. 1 and the software running system 20 shown in FIG. 9 can be integrated in the same system. Referring to FIG. 14, FIG. 14 is a schematic architecture diagram of a hybrid OS simulation test system provided in an embodiment of the present application, the hybrid OS simulation test system including a development state design tool and a running state.

[0176] The development state design tool includes an instrumentation framework, a modeling and analysis module, and a simulation system. The instrumentation tool can be regarded as the instrumentation processing system 10, including a DSL front end and an instrumentation back end. The instrumentation framework can be used to implement the method described in the embodiment shown in FIG. 8.

[0177] The modeling and analysis module is configured to provide a modeling and analysis tool, and predefine the architecture of the simulation system or model a business application. Optionally, the modeling and analysis module can also be configured to perform visualization and latency analysis, for example, obtain state data of a computing unit when performing a task, and analyze to obtain latency information of the task execution and / or latency information of a communication link. Optionally, the modeling and analysis module further includes a standard profile and standard indicator module, which is configured to monitor the execution process of a task, and collect part of key performance indicators, for example, the aforementioned end-to-end latency, average response time of a computing model, maximum response time of a computing model, or resource occupancy of at least two computing units.

[0178] The development state design tool can also implement simulation of an operating system, for example, can simulate multiple heterogeneous hardware, for example, CPU, AIC, IO, memory, and the like. In other words, the simulation test system can implement simulation of a hybrid OS, and support simulation of multiple heterogeneous hardware. For related description, refer to the foregoing description of the software running system 20.

[0179] Optionally, the development state design tool includes an AI system tuning unit, which can use AI technology to optimize the system. Optionally, the development state design tool further includes a log store, which is configured to provide a storage space to store files generated in the development state or the running state.

[0180] The running state is used for running software. In the simulation test system shown in FIG. 14, the running state supports a decoupling module based on DSL patching, a patching framework, and implementation of decoupling of business logic and maintenance and testing mechanisms in runtime. Since the patching framework of the present application supports binary patching, users can modify binary programs to achieve efficient system performance optimization in runtime through the patching framework.

[0181] In some possible implementation manners, the operating system simulation system shown in FIG. 14 can be deployed in a device with computing capability, such as a chip, a host, a server, or a computing instance. Further, the operating system simulation system can be integrally deployed in one device or distributively deployed in multiple devices.

[0182] As a possible example, refer to FIG. 15, which is a running scenario diagram of a simulation test system according to an embodiment of the present application. As shown in FIG. 15(a), the patching framework provides patching processing based on a DSL code file, and multiple patching manners can be selected in the patching processing, which is helpful for rapid verification and iteration of software. Further, some system maintenance logic, system testing logic, and system optimization logic can be embodied in the DSL code file, and developers of the application program do not need to be aware, thereby achieving decoupling of the maintenance and testing mechanisms and the business logic. As shown in FIG. 15(c), the patching framework simultaneously serves as a basis for decoupling of business logic and optimization logic in runtime, and based on the DSL code file, the running process of the application program and / or the system can be analyzed, which is helpful for achieving decoupling of algorithm development and system design for X (DFX) logic in each or a certain link of the product life cycle.

[0183] As shown in FIG. 15(b), the patched program can be input to a modeling module to obtain multiple tasks to be executed. Further, the simulation test system includes simulation of multiple heterogeneous hardware and simulation of multiple OS, and can simulate running frameworks and running processes of multiple OS, synchronous simulation of multiple heterogeneous hardware, and collaborative heterogeneous multi-OS mixed simulation, thereby supporting rapid verification and iteration of software (including operating systems and application programs).

[0184] In summary, through the patching processing system, the software running system, and the simulation test system provided in the present application, the system optimization requirements of an embedded system can be met, and the efficiency of system optimization can be improved.

[0185] The above describes the method of the embodiments of the present application in detail, and the device of the embodiments of the present application is provided below.

[0186] It should be understood that the division of units in the apparatus provided in the embodiments of the present application is only a logical functional division, and all or part of the units can be integrated into a physical entity or physically separated when actually implemented. In addition, the units in the apparatus can be implemented in the form of processor calling software. For example, the apparatus includes a processor, the processor is connected with a memory, the memory stores instructions, and the processor calls the instructions stored in the memory to implement any one of the above methods or to realize the functions of each unit of the apparatus, wherein the processor is a general processor such as a central processing unit (CPU) or a microprocessor, and the memory is an internal memory of the apparatus or an external memory of the apparatus.

[0187] Alternatively, the units in the apparatus can be implemented in the form of hardware circuit, and the functions of part or all of the units can be realized by the design of the hardware circuit, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), and the functions of part or all of the units are realized by the design of the logical relationship of elements in the circuit. For another example, in another implementation, the hardware circuit is a programmable logic device (PLD), and the functions of part or all of the units are realized by configuring the connection relationship between the logic gate circuits through a configuration file, for example, a field programmable gate array (FPGA) which can include a large number of logic gate circuits.

[0188] In the embodiments of the present application, each unit in the apparatus can be one or more processors (or processing circuits) configured to implement the above methods, such as a CPU, a graphics processing unit (GPU), a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), an MPU, a digital signal processor (DSP), an ASIC, an FPGA, or a combination of at least two of these processor forms.

[0189] In addition, all or part of each unit in the above apparatus can be integrated together or can be independently implemented. In one implementation, the units are integrated together to be implemented in the form of a system on a chip (SOC, or system-level chip). The SOC can include at least one processor for implementing the functions of any of the above methods or implementing the functions of each unit of the apparatus. The at least one processor can be of different types, such as including a CPU and an FPGA, or including a CPU and an artificial intelligence processor, or including a CPU and a GPU, and the like. The following lists several possible apparatuses.

[0190] Referring to FIG. 16, FIG. 16 is a structural schematic diagram of a plug-in processing apparatus provided in an embodiment of the present application. Optionally, the plug-in processing apparatus 160 can be a stand-alone device, such as a host, a server, and the like. Alternatively, the plug-in processing apparatus 160 can also be one device in a stand-alone device (such as a node), such as a chip or an integrated circuit, and the like. The plug-in processing apparatus 160 is configured to implement the plug-in processing method and / or the program running method described above, such as the plug-in processing method shown in FIG. 8, or such as the program running method shown in FIG. 13.

[0191] Exemplarily, the plug-in processing apparatus 160 includes an acquisition module 1601 and a processing module 1602, wherein the acquisition module 1601 is configured to implement one or more operations of acquisition, reception, generation, and the like. The processing module 1602 is configured to implement one or more operations of processing, determination, calculation, and the like.

[0192] It should be understood that the naming of the division of the modules here is only illustrative. For example, the acquisition module 1601 can also be referred to as a front end of plug-in, and the processing module 1602 can also be referred to as a back end of plug-in.

[0193] In one possible implementation, the acquisition module 1601 is configured to acquire a DSL code file and acquire a program file of a target program. The processing module 1602 is configured to obtain a plugged program file based on the DSL code file and the program file of the target program through a target plug-in manner.

[0194] In another possible implementation, the plurality of plug-in manners includes compiler plug-in. In a case where the target plug-in manner is the compiler plug-in, the program file of the target program is source code of the target program.

[0195] In another possible implementation, the plurality of plug-in manners includes binary plug-in. In a case where the target plug-in manner is the binary plug-in, the program file of the target program is a compiled binary file corresponding to the target program.

[0196] In yet another possible implementation, the DSL supports one or more of the following instrumentation point granularities: module, function, instruction, and address aligned to a specified boundary. The DSL supports one or more of the following operations: variable acquisition, function, programming language syntax, and output, where the output includes standard output stream, output to a system log, output to a specified log file, and writing to memory.

[0197] In yet another possible implementation, the operations supported at the instrumentation points are implemented by invoking a pre-configured instrumentation function library. The instrumentation function library includes a plurality of pre-defined function components, which include one or more of the following function components: latency analysis and statistics, hardware information analysis and statistics, memory information analysis and statistics, sandbox interface, parameter expansion interface, and string processing.

[0198] In yet another possible implementation, the operations performed at the instrumentation points include collecting latency information of the target communication link. The processing module 1602 is further configured to execute the instrumented program file, and output the latency information of the target communication link.

[0199] In yet another possible implementation, the instrumentation points include a first instrumentation point and a second instrumentation point, and the operations performed at the instrumentation points include entering a sandbox at the first instrumentation point and configuring a performance tag, and exiting the sandbox at the second instrumentation point, where the performance tag is related to available resources of a thread corresponding to the target program. The processing module 1602 is further configured to execute the instrumented program file, allocate resources based on the performance tag of the thread corresponding to the target program when the first instrumentation point is reached, form a sandbox and execute the thread of the service program in the sandbox, and exit the sandbox when the second instrumentation point is reached.

[0200] In yet another possible implementation, the target service program includes a call to a first function, and the instrumentation point is a location of the call to the first function, and the operations performed at the instrumentation point include replacing the call to the first function with a call to a second function.

[0201] Referring to FIG. 17, FIG. 17 is a structural schematic diagram of a program running apparatus according to an embodiment of the present application. Optionally, the program running apparatus 170 can be a standalone device, such as a node, etc. Alternatively, the program running apparatus 170 can also be a component, such as a chip or an integrated circuit, etc., in a standalone device (such as a node). The program running apparatus 170 is configured to implement the foregoing instrumentation processing method and / or program running method, such as the instrumentation processing method shown in FIG. 8, or the program running method shown in FIG. 13.

[0202] Exemplarily, the program running apparatus 170 comprises a plurality of simulated computing units, a modeling module 1701 and a processing module 1702. The modeling module 1701 is configured to model and task creation, and the processing module 1702 is configured to implementation, task scheduling, event scheduling and the like. It should be understood that the division of the modules herein is only exemplary, and in some schemes, some modules can be further divided into more modules, and some modules can also be combined. The naming of the modules herein is also only exemplary.

[0203] In one possible implementation, the modeling module 1701 is configured to model the target program to obtain a task model, and create a plurality of tasks based on the task model of the target program. The processing module 1702 is configured to execute the plurality of tasks by the plurality of computing units to obtain a plurality of events, and add the plurality of events to a global queue so that the plurality of events are executed in a serial logic. The processing module 1702 is further configured to distribute events in the global queue to the plurality of computing units, and synchronize clocks among the plurality of computing units.

[0204] In another possible implementation, the plurality of computing units are heterogeneous computing units. Here, the heterogeneity refers to the difference in hardware of the computing units. Exemplarily, the plurality of computing units comprise a CPU, an MPU, an MCU, an AIC, an AIV, a DVPP module and the like.

[0205] Optionally, the program running apparatus 170 can also simulate other hardware, such as input / output (I / O, or IO), memory and the like.

[0206] In another possible implementation, the plurality of tasks comprise a first task, and the plurality of computing units comprise a first computing unit and an acceleration computing unit. The acceleration computing unit is configured to execute a specified task. The execution of the task by the plurality of computing units to obtain the plurality of events comprises execution of the first task by the first computing unit. The processing module 1702 is further configured to add a second task generated by the first computing unit in the process of executing the first task to an acceleration running queue. The acceleration running queue (or running queue) is configured to arrange tasks (the second task belongs to the specified task) to be executed by the acceleration computing unit.

[0207] In another possible implementation, the processing module 1702 is further configured to create a first event, and the first event is configured to query the execution of the second task asynchronously.

[0208] In another possible implementation, the processing module 1702 is further configured to execute the second task by the acceleration computing unit, and after the execution of the second task is completed, create a second event and add it to the global queue to notify the first computing unit to process the second event.

[0209] In yet another possible implementation, the processing module 1702 is further configured to: obtain a memory bandwidth traffic condition of the software running system when the target task is scheduled to be executed, and generate the latency of the target task based on the memory bandwidth traffic condition of the software running system. Optionally, the target task is a pre-selected task, or the target task is a task of the first type, or the target task is a task processed by the acceleration computing unit.

[0210] In yet another possible implementation, at least two computing units in the plurality of computing units are configured to jointly deploy the computing model, each of the at least two computing units being configured to deploy one part of the computing model. The processing module 1702 is further configured to: collect state data of the at least two computing units when the task is executed, and obtain the performance evaluation index of the computing model according to the state data.

[0211] Referring to FIG. 18, FIG. 18 is a structural schematic diagram of yet another computing device according to an embodiment of the present application. The computing device 180 can be a standalone device, for example, a node, or a component included in a standalone device, for example, a chip, a software module, or an integrated circuit, etc. The computing device 180 can include at least one processor 1801 and a memory 1803. Optionally, a communication interface 1802 can also be included. Further optionally, a connection line 1804 can also be included, wherein the processor 1801, the communication interface 1802, and / or the memory 1803 are connected by the connection line 1804, and / or communicate with each other through the connection line 1804 to transfer control signals and / or data signals.

[0212] wherein:

[0213] The processor 1801 is a module that performs arithmetic operations and / or logical operations, and can specifically include one or more of the following modules: a filter, a modem, a power amplifier, a low noise amplifier (LNA), a baseband processor, a radio frequency processor, a radio frequency circuit, a central processing unit (CPU), an application processor (AP), a microcontroller unit (MCU), an electronic control unit (ECU), a graphics processing unit (GPU), a microprocessor unit (MPU), an application specific integrated Circuit (ASIC), an image signal processor (ISP), a digital signal processor (DSP), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), or a co-processor, etc.

[0214] The communication interface 1802 can be configured to provide information input or output for at least one processor, or to receive externally transmitted signals and / or transmit signals to the outside. For example, the communication interface 1802 can include an interface circuit. For example, the communication interface 1802 can include a wired link interface such as an Ethernet cable, and can also be a wireless link (Wi-Fi, Bluetooth, universal wireless transmission, vehicle-mounted short-range communication technology, and other short-range wireless communication technologies) interface. Optionally, the communication interface 1802 can also include a radio frequency transmitter, an antenna, etc. In the case where the communication interface 1802 includes an antenna, the number of antennas can be one or more.

[0215] As one possible design, if the computing device 180 is a standalone device, the communication interface 1802 can include a receiver and a transmitter. The receiver and the transmitter can be the same component or different components. When the receiver and the transmitter are the same component, the component can be referred to as a transceiver.

[0216] As yet another possible design, if the computing device 180 is a chip or a circuit, the communication interface 1802 can include an input interface and an output interface, which can be the same interface, or can be different interfaces.

[0217] Optionally, the functions of the communication interface 1802 can be implemented by a transceiver circuit or a dedicated chip of transceiver.

[0218] The memory 1803 is configured to provide a storage space in which data such as an operating system and a computer program can be stored. The memory 1803 can be one or a combination of a random access memory (RAM), a read-only memory (ROM), an erasable programmable read only memory (EPROM), or a compact disc read-only memory (CD-ROM).

[0219] It should be noted that the functions and actions of the modules or units in the computing device 180 listed above are only exemplary.

[0220] The functional units in the computing device 180 can be configured to implement the foregoing method of inserting a stub and / or the method of running a program, such as the method of inserting a stub shown in FIG. 8, or the method of running a program shown in FIG. 13.

[0221] Optionally, the processor 1801 can be a processor specially configured to execute the foregoing method (for ease of distinction, referred to as a special-purpose processor), or can be a processor that executes the foregoing method by invoking a computer program (for ease of distinction, referred to as a special-purpose processor). Optionally, the at least one processor can include both a special-purpose processor and a general-purpose processor.

[0222] Optionally, in the case where the computing device 180 includes at least one memory 1803, if the processor 1801 implements the foregoing method of inserting a stub and / or the method of running a program by invoking a computer program, the computer program can be stored in the memory 1803.

[0223] The chip includes a logic circuit and a communication interface. The communication interface is configured to receive a signal or send a signal. The logic circuit is configured to receive a signal or send a signal through the communication interface. The chip is configured to implement the foregoing method of inserting a stub and / or the method of running a program, such as the method of inserting a stub shown in FIG. 8, or the method of running a program shown in FIG. 13.

[0224] The embodiments of the present application further provide a computer readable storage medium, which stores instructions. When the instructions are executed on at least one processor (or a communication device), the foregoing inserting processing method and / or program running method, for example, the inserting processing method shown in FIG. 8, or the program running method shown in FIG. 13, are implemented.

[0225] The embodiments of the present application further provide a computer program product, which comprises computer instructions. The computer instructions are used to implement the foregoing inserting processing method and / or program running method, for example, the inserting processing method shown in FIG. 8, or the program running method shown in FIG. 13.

[0226] The embodiments of the present application further provide a terminal, which comprises the foregoing inserting processing device 160 and / or computing device 180.

[0227] As a possible implementation, the terminal comprises a terminal node. Further, the terminal further comprises a first management node and / or a second management node. Further, the terminal further comprises a control node.

[0228] Exemplarily, the terminal can comprise a vehicle, a robot, a drone, a ship, a ship, and the like intelligent terminal or a vehicle. Among them, the vehicle is a vehicle in a broad sense, which can be a vehicle (such as a commercial vehicle, a passenger vehicle, a motorcycle, a flying vehicle, a train, etc.), an industrial vehicle (such as a forklift, a trailer, a tractor, etc.), an engineering vehicle (such as an excavator, a bulldozer, a crane, etc.), an agricultural device (such as a mower, a harvester, etc.), and the like. For example, the robot can be an automated guided vehicle (AGV), a walkable conversational robot, a service robot, and the like.

[0229] It should be noted that in the embodiments of the present application, the words such as "exemplarily" or "for example" are used to represent an example, illustration or description. Any embodiment or design scheme described as "exemplarily" or "for example" in the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as "exemplarily" or "for example" are intended to present the relevant concept in a specific manner.

[0230] In the embodiments of the present application, the names of information and devices are exemplarily named for the convenience of understanding the contents of the present application. In the specific implementation, the names thereof can be designed in other manners. In addition, the names of the same thing can also be designed differently in different scenarios (for example, different communication layers).

[0231] The "at least one" mentioned in the embodiments of the present application refers to one or more, and "multiple" refers to two or more. "At least one of the following" or the like refers to any combination of these items, including any combination of single or multiple items.

[0232] For example, at least one of a, b, or c can represent: a, b, c, (a and b), (a and c), (b and c), or (a and b and c), where a, b, and c can be single or multiple. "And / or" describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent three cases of A alone, A and B together, and B alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it.

[0233] In addition, unless otherwise stated, the ordinal numbers "first", "second", etc. used in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the order, time sequence, priority or importance of the multiple objects. For example, the first task and the second task are only used to facilitate the description of the tasks in different embodiments, and do not mean that their execution operations, importance, structures, etc. are different.

[0234] In the above embodiments, according to the context, the term "when" can be interpreted as meaning "if", "after" or "in response to determining" or "in response to detecting". The above is only an optional embodiment of the present application and does not limit the present application. Any modification, equivalent replacement, improvement, etc. within the concept and principle of the present application should be included in the protection scope of the present application.

[0235] A person of ordinary skill in the art can understand that all or part of the steps of the above-mentioned embodiments can be completed by hardware, or by a program instructing relevant hardware, and the program can be stored in a computer readable storage medium. The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

Claims

1. A method of stubbing, characterized by, The method is applied to a stubbing system, the stubbing system supports multiple stubbing modes, and the method comprises: obtaining a domain-specific language (DSL) code file, the DSL code file is based on a DSL writing, the DSL code file is used to indicate a stubbing point and an operation performed at the stubbing point, and the DSL is a pre-defined programming language; obtaining a program file of a target program; obtaining a stubbed program file based on the DSL code file and the program file of the target program through a target stubbing mode, the stubbed program file is used to implement a business logic of the target program and is used to implement the operation performed at the stubbing point, and the target stubbing mode is any one of the multiple stubbing modes.

2. The method of claim 1, wherein, The multiple stubbing modes comprise compiler stubbing, in a case where the target stubbing mode is compiler stubbing, the program file of the target program is source code of the target program.

3. The method according to claim 1 or 2, characterized in that, The multiple stubbing modes comprise binary stubbing, in a case where the target stubbing mode is binary stubbing, the program file of the target program is a compiled binary file corresponding to the target program.

4. The method according to any one of claims 1 to 3, characterized in that, The DSL supports one or more of the following stubbing point granularities: a module, a function, an instruction, and an address aligned with a specified boundary, and supports one or more of the following operations: variable acquisition, a function, a programming language syntax, and output, wherein the output modes comprise a standard output stream, a system log output, a specified log file output, and writing into a memory.

5. The method according to any one of claims 1 to 4, characterized in that, The operation supported at the stubbing point is implemented by calling a pre-configured stubbing function library, the stubbing function library comprises a plurality of pre-defined function components, and the plurality of function components comprise one or more of the following function components: delay analysis and statistics, hardware information analysis and statistics, memory information analysis and statistics, a sandbox interface, a parameter expansion interface, and string processing.

6. The method according to any one of claims 1 to 5, characterized in that, The operation performed at the stubbing point comprises collecting delay information of a target communication link, and the method further comprises: running the stubbed program file; outputting the delay information of the target communication link.

7. The method according to any one of claims 1 to 5, characterized in that, The stubbing point comprises a first stubbing point and a second stubbing point, and the operation performed at the stubbing point comprises entering a sandbox at the first stubbing point and configuring a performance tag and exiting the sandbox at the second stubbing point, and the performance tag is related to available resources of a thread corresponding to the target program; The method further comprises: running the stubbed program file, when the first stubbing point is reached, performing resource allocation based on the performance tag of the thread corresponding to the target program, forming a sandbox, and executing the thread of the business program in the sandbox, and when the second stubbing point is reached, exiting the sandbox.

8. The method of any one of claims 1-5, wherein: the target business program comprises a call to a first function, the stubbing point is a position of calling the first function, the operation performed at the stubbing point comprises replacing the call to the first function with a call to a second function.

9. The method according to any one of claims 1 to 8, characterized in that, The method further comprises: modeling the target program to obtain running state data of the target program.

10. A program execution method characterized by comprising: The method is applied to a software running system, the software running system comprising a plurality of computing units in simulation, each computing unit corresponding to one or more cores, and the method comprising: modeling a target program to obtain a task model; creating a plurality of tasks based on the task model of the target program; executing the plurality of tasks by the plurality of computing units to obtain a plurality of events; adding the plurality of events to a global queue to enable the plurality of events to be executed in serial logic; distributing events in the global queue to the plurality of computing units, the plurality of computing units being clock-synchronized.

11. The method of claim 10, wherein, The plurality of computing units are heterogeneous computing units.

12. The method of claim 11, wherein, The plurality of computing units comprise one or more of the following computing units: a central processing unit (CPU), a microprocessor (MPU), a microcontroller (MCU), an artificial intelligence matrix (AIC) operator node, and an artificial intelligence vector (AIV) operator node.

13. The method according to any one of claims 10-12, characterized in that, The plurality of tasks comprises a first task, and the plurality of computing units comprises a first computing unit and an acceleration computing unit, the acceleration computing unit being configured to execute a specified task; the executing the plurality of tasks by the plurality of computing units to obtain a plurality of events comprises: executing the first task by the first computing unit; The method further comprises: adding a second task generated by the first computing unit in the process of executing the first task to an acceleration running queue, the acceleration running queue being configured to arrange tasks to be executed by the acceleration computing unit, the second task belonging to the specified task; creating a first event, the first event being configured to asynchronously query the execution of the second task.

14. The method of claim 13, wherein, The method further comprises: executing the second task by the acceleration computing unit; after the execution of the second task is completed, creating a second event and adding the second event to the global queue; informing the first computing unit to process the second event.

15. The method according to any one of claims 10 to 14, characterized in that, The method further comprises: when a target task is scheduled to be executed, obtaining a memory bandwidth flow condition of the software running system, the target task belonging to the plurality of tasks; generating a time delay of the target task based on the memory bandwidth flow condition of the software running system.

16. The method of claim 15, wherein, The target task is a preselected task, or the target task is a first type of task, or the target task is a task processed by an acceleration computing unit.

17. The method according to any one of claims 10-16, characterized in that, At least two computing units of the plurality of computing units are configured to jointly deploy a computing model, each computing unit of the at least two computing units being configured to deploy a part of the computing model, and the method further comprises: collecting state data of the at least two computing units when executing tasks; obtaining a performance evaluation index of the computing model according to the state data.

18. The method of claim 17, wherein, The state data comprises one or more of the following data: inference time of a model part deployed by each computing unit of the at least two computing units, overall execution time of the computing model, and resource occupancy rate of the at least two computing units; The performance evaluation index comprises one or more of the following data: end-to-end time delay, average response time of the computing model, maximum response time of the computing model, and resource occupancy rate of the at least two computing units.

19. A stub handling apparatus, characterized by The instrumentation processing apparatus comprises an obtaining module and an instrumentation module, and is configured to implement the method of any one of claims 1-9.

20. A program execution device characterized by comprising: The program running apparatus comprises a plurality of simulated computing units, a modeling module and a processing module, and is configured to implement the method of any one of claims 10-18.

21. An inlining system, characterized by The instrumentation processing system comprises an instrumentation front end and an instrumentation back end, wherein: The instrumentation front end is configured to obtain a DSL code file, The instrumentation back end is configured to obtain an instrumented program file based on the DSL code file and the obtained program file of the target program; The instrumentation processing system is configured to implement the method of any one of claims 1-9.

22. A software execution system, characterized by The software running system comprises a modeling module, an operating system layer and a hardware layer, The hardware layer comprises a plurality of simulated computing units, and the operating system layer comprises a plurality of operating systems, the plurality of computing units corresponding to the plurality of operating systems, The modeling module is configured to model a target program and create a plurality of tasks based on the model of the target program, and the operating system is configured to execute the plurality of tasks through the plurality of computing units; The software running system is configured to implement the method of any one of claims 10-18.

23. An operating system emulation system, characterized by The operating system simulation system comprises the instrumentation processing system of claim 21 and the software running system of claim 22.

24. A computing device comprising a processor and a memory, the memory being configured to store computer instructions, and the processor being configured to invoke the computer instructions to implement the method of any one of claims 1-9.

25. A computing device comprising a processor and a memory, the memory being configured to store computer instructions, and the processor being configured to invoke the computer instructions to implement the method of any one of claims 10-18.

26. A computer program product, characterised in that, The computer program product comprises computer instructions configured to implement the method of any one of claims 1-18 when executed by a computing device.

27. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions configured to implement the method of any one of claims 1-18 when executed by a computing device.

Images