Patent Description:
At the outset of new embedded system designs, little is known of the eventual target hardware design or the embedded software that will run on that target hardware. Typically, as the hardware design matures, software development progresses in parallel, undergoing numerous iterations of development and testing. The development and testing are generally carried out on hardware other than the eventual target hardware, for example, within an integrated development environment (IDE) on a personal computer (PC) running a commercial operating system (OS). Consequently, there may be "gaps" in the fidelity of at least some testing that can be carried out while the hardware design is incomplete. There may also be gaps in fidelity due to techniques such as application software re-hosts that enable re-hosted application software to run on a PC, but not other elements of the target hardware software stack, such as a real-time OS. Those gaps may result in delays in full-fidelity testing of target software and target hardware, which may result in late detection of problems, which may result in further iterations of development and testing when nearing completion of the embedded system development.

<CIT>, according to its abstract, presents techniques for testing a physical hardware system by executing hardware system application software on a corresponding emulated proxy physical hardware system in a proxy virtual machine. The techniques include: obtaining a proxy physical hardware system that matches aspects of the physical hardware system; constructing, in a virtualization system, the proxy virtual machine; emulating, using the virtualization system, hardware components of the proxy physical hardware system in the proxy virtual machine; executing a hardware abstraction software layer in the proxy virtual machine; executing, by the hardware abstraction software layer of the virtualization system, the hardware system application software in the proxy virtual machine on the proxy physical hardware system using a memory map at least one adapter; and testing, using the virtualization system, the physical hardware system by the executing the hardware system application software in the proxy virtual machine on the proxy physical hardware system.

One aspect is directed to a host computer according to claim <NUM>. A further aspect is directed to a method according to claim <NUM>.

Various refinements exist of the features noted in relation to the above-mentioned aspects. Further features may also be incorporated in the above-mentioned aspects as well. These refinements and additional features may exist individually or in any combination. For instance, various features discussed below in relation to any of the illustrated examples may be incorporated into any of the above-described aspects, alone or in any combination.

Corresponding reference characters indicate corresponding parts throughout the several views of the drawings. Although specific features of various examples may be shown in some drawings and not in others, this is for convenience only. Any feature of any drawing may be referenced and/or claimed in combination with any feature of any other drawing.

Examples herein provide at least some testing that can occur earlier in the development cycle through use of virtualized hardware within a virtual machine (VM). Virtualization refers to the imitation, or emulation, of a given unit of hardware by a software program, such as a VM, executing on a local, or host, computer via a hypervisor. Virtualization enables testing of target software without modification through software re-hosts or the need for a complete target hardware test bench, which can be costly and in high demand for large or complex system development. Virtualizing target hardware, such as, for example, a single board computer (SBC) or a communication bus controller, generally requires detailed knowledge of the specific target hardware and firmware to build a VM that will imitate, or emulate, the target hardware with comparable functionality to the genuine target hardware. Target hardware, as used herein, refers to a unit of actual hardware for an embedded system or data processing system that is virtualized by the VM.

Examples herein provide a VM that closely matches the target hardware available to carry out early development and testing of either target hardware or target software. Consequently, virtualization is leveraged while the hardware design is under development.

For the purpose of this disclosure, the terms "virtualization" and "emulation" are used interchangeably to refer to a VM where any aspect of target hardware is being emulated, although the host computer may incorporate one or more other aspect of target hardware.

The host computer disclosed provides a proxy VM for developing and testing target software, or target code, for an incomplete hardware design for an embedded system. More specifically, the proxy VM includes only core aspects of a hardware design that are known at early stages of design.

For example, the processor type and OS are typically determined in early stages of design, i.e., in an incomplete hardware design. Other aspects, such as firmware for field programmable gate array (FPGAs) and application specific integrated circuits (ASICs), or designs for input/output (I/O) devices, generally are not determined until much later in the hardware design process, which could be months or years after the core aspects of the hardware design are determined. Accordingly, many aspects of the target hardware for the embedded system may change over the course of development, including requirements, designs, interfaces, and input and output data definitions.

The proxy VM, which includes at least an emulation of the target processor and the target OS, enables early development and testing of application software using an IDE, compiler, and other development tools for the target OS, or another off-the-shelf OS that is the same or very similar to the target OS. For the purpose of this disclosure, the term "development tool" refers to any software module, program, library, or other application that can be used in the development, testing, or execution of software under development, or in the development or testing of target hardware. For example, the OS for the proxy VM utilizes the same or very similar stack as the target OS. In alternative examples, the OS need not be similar to the target OS, although the similar OS is advantageous for the efficiencies gained, for example, in developing and testing for a single set of development tools for the target OS. In other alternative examples, the proxy VM may omit the target OS to operate with "bare metal. " In such an example, development and testing may still be carried out using an IDE, compiler, debugger, or other development tools for the bare metal implementation. Early application software often includes atomic-level functionality, application programming interfaces (APIs), and device drivers (once target I/O devices are designed). These early software components are amenable to "white box" testing and typically need not interface directly with hardware aspects of the embedded system. Moreover, early iterations of target hardware and device drivers may be emulated to test and evaluate hardware design options. Such early leveraging of virtualization eliminates re-work and re-hosting effort later in development that often results from differences in the OS and IDE that run on a typical developers' PC. The differences between the development, or "re-hosted," environment and the target environment are often resolved later in development when a complete hardware design is available.

<FIG> is a block diagram of example target hardware for an embedded system <NUM>. Embedded system <NUM> may be an avionics system, for example, a flight management computer (FMC) or a flight control computer (FCC). Although the disclosed systems and methods are sometimes described in terms of avionics, the systems and methods may also be applied in any other computing system that could benefit from reduced development cycles, for example, for land, marine, or space vehicles.

<FIG> illustrates and example complete design of embedded system <NUM>. Embedded system <NUM> includes a processor <NUM> directly coupled to a memory cache <NUM>, such as a level <NUM> or level <NUM> cache. Embedded system <NUM> also includes a host bridge <NUM> coupled directly to processor <NUM> via, for example, a front side bus. Host bridge <NUM> controls communication with processor <NUM> over, for example, a memory bus <NUM>, such as an X-bus, and an I/O, or peripheral, bus <NUM>, such as a peripheral component interconnect (PCI) bus, PCI express, PCI-X, integrated drive electronics (IDE) bus, serial advanced technologies attachment (SATA) bus, or any other suitable communication media for connecting I/O devices <NUM> to processor <NUM>. Host bridge <NUM> may be implemented on a processing chip, such as an ASIC or FPGA, and may include additional functionality, such as, for example, an interrupt controller. I/O devices <NUM> may include, for example, sensors, communication interfaces, peripheral interfaces, or other peripheral hardware devices, which may be implemented on PCI mezzanine cards (PMCs) <NUM>. Embedded system <NUM> includes an additional bus bridge including a Versa Module Eurocard (VME) bus controller <NUM>. Embedded system <NUM> includes at least two communication interfaces for transmitting and receiving over a communication bus: an Ethernet controller <NUM> and a serial controller <NUM>. In certain examples, I/O devices may include peripheral interfaces such as audio or video interconnects.

Memory bus <NUM> connects various memory devices to processor <NUM> through host bridge <NUM>. Memory devices may include, for example random access memory (RAM) such as synchronous dynamic RAM (SDRAM) <NUM> that is generally only available to processor <NUM>. Embedded system <NUM> includes a direct memory access (DMA) buffer <NUM> on memory bus <NUM> between host bridge <NUM> and additional memory devices that may be accessed by other devices in addition to processor <NUM>. For example, embedded system <NUM> includes memory <NUM> for large storage, non-volatile RAM (NVRAM) <NUM>, and a serial bus controller <NUM> coupled to a highspeed bus <NUM>, such as a PCI-X bus. DMA buffer <NUM> enables access to memory <NUM> and NVRAM <NUM> without consuming processing cycles of processor <NUM>.

Memory <NUM> provides storage for, for example, an OS <NUM> and a board support package (BSP) <NUM> for embedded system <NUM>. Memory <NUM> may also store other application software and data for embedded system <NUM>. NVRAM <NUM> is generally a significantly smaller volume of memory reserved for low-level configuration data, such as a basic input output system (BIOS) <NUM>, or "bootloader.

<FIG> is a block diagram of an incomplete hardware design for target hardware for embedded system <NUM>. In early stages of development, when the hardware design is "incomplete," only core aspects of the hardware design are known, such as processor <NUM> and OS <NUM>. An incomplete design may include various aspects that are specified in requirements, but designs or hardware device selections for those aspects are uncertain and may change. Conversely, a complete hardware design would include all hardware device selections and all hardware design aspects complete. As the hardware design progresses, the still incomplete hardware design may evolve to include certain I/O devices <NUM>, such as a communication interface <NUM>. Communication interface <NUM> may include, for example, an ARINC <NUM> or a MIL-STD-<NUM> PCI mezzanine card. Communication interface <NUM> may also be an Ethernet controller that is the same or similar to Ethernet controller <NUM>. In some examples, communication interface <NUM> may include a selected Ethernet controller that is not similar to the eventual target Ethernet controller <NUM>, which is acceptable so long as it sufficiently supports standard Ethernet protocols. The incomplete hardware design otherwise generally lacks any I/O devices, fully implemented memory or peripheral buses, or fully implemented firmware for ASICs or FPGAs.

<FIG> is a block diagram of an example high-fidelity software test architecture <NUM> for a desktop test environment. Architecture <NUM> is generally embodied on a desktop computer, e.g., a PC, or "host computer," rather than a hardware test bench that includes genuine target hardware. Architecture <NUM> may also be implemented on a cloud computing platform that utilizes PC virtual machines or servers. In certain examples, architecture <NUM> may be implemented on a mobile computing device, such as a tablet computer or smart phone. Architecture <NUM> includes a proxy VM <NUM> that emulates core aspects of the otherwise incomplete hardware design for embedded system <NUM> shown in <FIG>. Proxy VM <NUM> executes, or runs, on top of an OS <NUM> and a hardware abstraction layer for the host computer. For the purpose of this disclosure, a hardware abstraction layer generally refers to APIs <NUM> that include, for example, interfaces for interacting with OS <NUM>, such as inter-process communication mechanisms (e.g., shared memory or sockets). In certain examples, APIs <NUM> may also include a hypervisor for orchestrating operation of proxy VM <NUM>. The host computer generally includes a host central processing unit (CPU) <NUM> and various host I/O devices <NUM>. Host I/O devices <NUM> may include, for example, a graphics interface including a graphics processing unit (GPU), audio peripheral devices, a network interface controller (NIC), a keyboard and mouse, or other peripheral devices. In certain examples, architecture <NUM> may include target hardware in host I/O devices <NUM>. Architecture <NUM> includes device drivers <NUM> that interface among host I/O devices <NUM>, OS <NUM>, APIs <NUM>, and any application software that is executed that interacts with host I/O devices <NUM>. For example, proxy VM <NUM> interacts with host I/O devices <NUM> through APIs <NUM>, OS <NUM>, and device drivers <NUM>.

Proxy VM <NUM> generally includes a virtual processor <NUM> that emulates processor <NUM> of embedded system <NUM> when processor <NUM> does not match the processor for the host computer. Alternatively, proxy VM <NUM> may omit virtual processor <NUM> if target processor <NUM> matches that of the host computer. Proxy VM <NUM> also includes an OS <NUM> and a BSP <NUM> corresponding to the combination of emulated hardware and OS <NUM>. OS <NUM> and BSP <NUM> are stored in one or more sections of emulated memory connected to virtual processor <NUM> via a virtual memory bus. Such a virtual memory bus, in certain examples, is a conceptual memory bus, or memory construct, implemented in the virtualization layer to enable construction of a memory map and to enable the transfer of data between the VM and host hardware. OS <NUM> is the same or very similar to OS <NUM> for embedded system <NUM>. BSP <NUM> includes configuration information for virtual processor <NUM> to run OS <NUM>, including, for example, memory mappings and interrupt mappings. Notably, at early stages of development for embedded system <NUM>, when the hardware design is incomplete, proxy VM <NUM> generally does not include complete emulated I/O devices <NUM> for target hardware I/O devices <NUM> in embedded system <NUM>, or a complete emulated peripheral bus. Consequently, target code generally lacks corresponding device drivers <NUM> for emulated I/O devices <NUM> or an emulated peripheral bus, although later iterations of proxy VM <NUM> may ultimately incorporate those virtualized components as their designs mature.

Architecture <NUM> includes target code <NUM> that is often developed within an IDE <NUM> that operates with OS <NUM>. Again, in early stages of development, target code <NUM> typically includes application software for only atomic functionality. As development progresses, target code <NUM> may grow to include hardware abstraction layers, or APIs <NUM>, and device drivers <NUM> once target I/O devices are designed and emulated I/O devices <NUM> are available. Target code <NUM> can generally be developed and tested with IDE <NUM>, or other test environment mechanisms, with basic test data <NUM>. Test data <NUM> generally is stored in host memory, but could also be stored with target code <NUM> on proxy VM <NUM> for the purpose of "white box testing.

The low level functionality in target code <NUM> does not interact with emulated I/O devices <NUM>, and at least not directly. Rather, target code <NUM> would interact with emulated I/O devices <NUM> through APIs <NUM>. As both the hardware design and the embedded software evolve, target code <NUM> can exercise APIs <NUM> and eventually device drivers <NUM> and emulated I/O devices <NUM>.

Emulated I/O devices <NUM> may include virtual hardware that is distinct from target hardware of embedded system <NUM> or will not exist in the completed target hardware. For example, the proxy VM <NUM> may include an emulated Ethernet controller for communicating during testing and development until the design of the target hardware for embedded system reaches a point where the target hardware for such communication matures. For example, for avionics systems that often utilize standardized communication buses, such as an ARINC <NUM> or MIL-STD-<NUM> bus, an emulated Ethernet controller enables communication until target hardware PCI mezzanine cards are designed or selected for the ARINC <NUM> or MIL-STD-<NUM> bus. Likewise, proxy VM <NUM> may omit the emulated Ethernet controller or other emulated I/O devices <NUM> in later stages of the design of embedded system <NUM>. Proxy VM <NUM> may, in certain examples, include another virtual peripheral bus to connect, or couple, proxy VM <NUM> to host hardware, such as a physical host I/O device. This enables the VM to communicate with devices outside of the physical host over a virtual peripheral bus connected to a physical peripheral bus in the virtualization layer.

Target code <NUM> can be developed and tested within proxy VM <NUM>. Virtual processor <NUM> executes OS <NUM>. The host OS <NUM> may also execute IDE <NUM> or other target code development tool within OS <NUM>. Virtual processor <NUM> reads-in target code <NUM> and test data <NUM>, particularly test input data, through an emulated I/O device <NUM>, such as a virtual communication interface, e.g., an emulated Ethernet controller. In certain examples, if I/O device <NUM> is unavailable in proxy VM <NUM>, because, for example, it is too early in development of embedded system <NUM>, then target code <NUM> and test data <NUM> can be loaded directly into emulated memory in proxy VM <NUM>, and will be available when target code <NUM> boots up on proxy VM <NUM>. Virtual processor <NUM> then executes target code <NUM> to operate on the test input data, and writes-out test output data over the virtual communication interface in response to execution of target code <NUM>. In examples where the communication interface is not available in proxy VM <NUM>, test output data can be written to emulated memory in proxy VM <NUM> for post-processing for verification and validation.

As the hardware design progresses further and certain additional target hardware becomes available, such target hardware may be incorporated into host I/O devices <NUM> within the host computer. Accordingly, corresponding APIs <NUM> and device drivers <NUM> for that target hardware are incorporated into proxy VM <NUM>, and target code <NUM> can interact through those components that are mapped to corresponding APIs <NUM> and device drivers <NUM> for the target hardware in the host computer.

<FIG> is a block diagram of an example host computer <NUM> for emulating target hardware of embedded system <NUM> shown in <FIG>. Host computer <NUM> can include, for example, a desktop PC, server PC, a cloud computing platform (e.g., a VM), a mobile computing device (e.g., tablet computer or smartphone), training system, or other suitable computing system. Host computer <NUM> includes host CPU <NUM> coupled to RAM <NUM> and host memory <NUM> via a physical bus <NUM> that includes one or more memory bus, communication bus, or peripheral bus. Host memory <NUM> is a computer-readable memory that includes a section storing proxy VM <NUM>, a section storing OS <NUM>, a section storing APIs <NUM>, a section storing device drivers <NUM>, and a section storing target code <NUM>. In alternative examples, one or more section of host memory <NUM> may be omitted and the data stored remotely. For example, in certain examples, target code <NUM> may be stored remotely on a server or mass-storage device, and made available over a network to host CPU <NUM> and proxy VM <NUM>.

Host computer <NUM> also includes host I/O devices <NUM>, which may include, for example, a communication interface such as an Ethernet controller <NUM>, or a peripheral interface for communicating with a host peripheral device <NUM> over a peripheral link <NUM>. Host I/O devices <NUM> may include, for example, a GPU for operating a display peripheral over a display link.

Host computer <NUM>, in certain examples, may include target I/O devices <NUM> once the design or selection of such devices is completed, or near completed, for the target hardware of embedded system <NUM>. For example, in one example, host computer <NUM> and, more specifically, target I/O devices <NUM> may include an ARINC <NUM> or MIL-STD-<NUM> PCI mezzanine card that is the same as the target hardware device for embedded system <NUM>, or substantially similar to the target hardware. Likewise, host computer <NUM>, in such examples, includes devices drivers <NUM> corresponding to those target I/O devices <NUM>. Host computer <NUM> may include a mapping, in a virtualization layer (e.g., within APIs or a hypervisor), of an emulated target I/O device <NUM> to a physical target I/O device <NUM> residing in host computer <NUM>.

<FIG> is a flow diagram of an example method <NUM> of testing target code for target hardware having an incomplete design, such as the target hardware for embedded system <NUM> shown in <FIG>. Method <NUM> may be embodied, for example, in host computer <NUM> shown in <FIG>. Host computer <NUM> executes <NUM> proxy VM <NUM> to emulate the target hardware. As shown in <FIG>, proxy VM <NUM> includes virtual processor <NUM>, emulated memory, and I/O devices <NUM> often including, in certain examples, a virtual communication interface, such as a virtual Ethernet controller. Host computer <NUM> executes <NUM>, within proxy VM <NUM>, OS <NUM> stored in the emulated memory. Host computer <NUM> and, more specifically, proxy VM <NUM>, reads-in <NUM> target code <NUM> and test input data <NUM> over the virtual communication interface. Target code <NUM> is then executed <NUM> within proxy VM <NUM> and operates on test input data <NUM>. Test output data is then written-out <NUM> over the virtual communication interface in response to execution <NUM> of target code <NUM>.

Proxy VM <NUM> may also include a BIOS, or bootloader, coupled to virtual processor <NUM>. The bootloader loads OS <NUM> and BSP <NUM> from a portion of the emulated memory at startup of proxy VM <NUM>. Host computer <NUM> may also include one or more development tools, such as IDE <NUM>, that executes within host OS <NUM>. In certain examples, OS <NUM> is omitted and BSP <NUM> and target code <NUM> execute on emulated bare metal. Likewise, on such examples, one or more development tools, such as IDE <NUM>, execute without OS <NUM>.

In embodiments, execution <NUM> of target code <NUM> includes executing, within proxy VM <NUM>, at least one functional application that interacts with at least one peripheral hardware abstraction layer, such as API <NUM>, and does not interact directly with the corresponding peripheral hardware, such as I/O device <NUM>, which is omitted from an incomplete hardware design for target hardware of embedded system <NUM>. For the purpose of this disclosure, the term "functional application" refers to any portion of program code that does not interact directly with a peripheral hardware device. Peripheral hardware generally includes any unit of hardware that communicates with processor <NUM> over a data bus (e.g., a memory bus, communication bus, or peripheral bus) as opposed to being integrated with processor <NUM> or communicating with processor <NUM> via the front-side bus. For example, referring to embedded system <NUM> shown in <FIG>, peripheral hardware devices communicate with processor <NUM> via memory bus <NUM> and peripheral bus <NUM>, and through host bridge <NUM>. Additional non-target code may also be executed within proxy VM <NUM> to test proxy VM <NUM> itself.

An example technical effect of the methods, systems, and apparatus described herein includes at least one of: (a) providing a proxy VM for target hardware of an embedded system early in development of the embedded system and generally before the target hardware is complete; (b) enabling a development and test environment within the proxy VM that operates within the same or very similar OS and BSP, and executing on an emulated processor that is the same as the target hardware; (c) enabling earlier testing and development of target hardware and target code without re-hosting and without complete virtualization of the target hardware; (d) reducing defects late in development of embedded systems by utilizing high-fidelity early-development testing on the proxy VM; and (e) enabling a user trainer (e.g., a maintenance or operator training system) utilizing a proxy VM that operates within a same, or very similar, OS and BSP, and executing on an emulated processor that is the same as the target hardware.

Some examples involve the use of one or more electronic processing or computing devices. As used herein, the terms "processor" and "computer" and related terms, e.g., "processing device", "computing device", and "controller" are not limited to just those integrated circuits referred to in the art as a computer, but broadly refers to a processor, a processing device, a controller, a general purpose central processing unit (CPU), a graphics processing unit (GPU), a microcontroller, a microcomputer, a programmable logic controller (PLC), a reduced instruction set computer (RISC) processor, a field programmable gate array (FPGA), a digital signal processing (DSP) device, an application specific integrated circuit (ASIC), and other programmable circuits or processing devices capable of executing the functions described herein, and these terms are used interchangeably herein. These processing devices are generally "configured" to execute functions by programming or being programmed, or by the provisioning of instructions for execution. The above examples are not intended to limit in any way the definition or meaning of the terms processor, processing device, and related terms.

In the examples described herein, memory may include, but is not limited to, a non-transitory computer-readable medium, such as flash memory, a random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and non-volatile RAM (NVRAM). As used herein, the term "non-transitory computer-readable media" is intended to be representative of any tangible, computer-readable media, including, without limitation, non-transitory computer storage devices, including, without limitation, volatile and non-volatile media, and removable and non-removable media such as a firmware, physical and virtual storage, CD-ROMs, DVDs, and any other digital source such as a network or the Internet, as well as yet to be developed digital means, with the sole exception being a transitory, propagating signal. Alternatively, a floppy disk, a compact disc - read only memory (CD-ROM), a magnetooptical disk (MOD), a digital versatile disc (DVD), or any other computer-based device implemented in any method or technology for short-term and long-term storage of information, such as, computer-readable instructions, data structures, program modules and sub-modules, or other data may also be used. Therefore, the methods described herein may be encoded as executable instructions, e.g., "software" and "firmware," embodied in a non-transitory computer-readable medium. Further, as used herein, the terms "software" and "firmware" are interchangeable, and include any computer program stored in memory for execution by personal computers, workstations, clients and servers. Such instructions, when executed by a processor, cause the processor to perform at least a portion of the methods described herein.

Also, in the examples described herein, additional input channels may be, but are not limited to, computer peripherals associated with an operator interface such as a mouse and a keyboard. Alternatively, other computer peripherals may also be used that may include, for example, butnotbe limited to, a scanner. Furthermore, in some examples, additional output channels may include, but not be limited to, an operator interface monitor.

The systems and methods described herein are not limited to the specific examples described herein, but rather, components of the systems and/or steps of the methods may be utilized independently and separately from other components and/or steps described herein.

Although specific features of various examples of the disclosure may be shown in some drawings and not in others, this is for convenience only. In accordance with the principles of the disclosure, any feature of a drawing may be referenced and/or claimed in combination with any feature of any other drawing.

As used herein, an element or step recited in the singular and proceeded with the word "a" or "an" should be understood as not excluding plural elements or steps unless such exclusion is explicitly recited. Furthermore, references to "one example" of the present invention or the "exemplary example" are not intended to be interpreted as excluding the existence of additional examples that also incorporate the recited features.

Claim 1:
A host computer (<NUM>) comprising:
a memory (<NUM>) configured to store a proxy virtual machine, VM, (<NUM>) for emulating target hardware (<NUM>), the target hardware (<NUM>) having an incomplete design wherein a processor and operating system of the target hardware (<NUM>) are known but firmware and an input/output device are unknown, the proxy VM including:
an emulated Ethernet controller;
a virtual processor (<NUM>) for emulating a target processor (<NUM>); and
emulated memory in communication with the virtual processor via a virtual memory bus, the emulated memory including at least one portion storing target code (<NUM>) which is software to run on the emulated target hardware (<NUM>) ; and
a host central processing unit, CPU, (<NUM>) configured to execute the proxy VM to emulate the target hardware,
the proxy VM, upon execution by the host CPU, configured to:
execute, by the virtual processor, the target code (<NUM>),
read-in input data (<NUM>),
operate (<NUM>) on the input data (<NUM>) using the executed target code (<NUM>) to generate output data, and
write (<NUM>) the output data over the virtual memory bus in response to execution of the target code (<NUM>), and
update the proxy VM to omit the emulated Ethernet controller and to include a target hardware I/O device; wherein
the target code (<NUM>) is configured to interact with an emulated input/output device in the emulated target hardware (<NUM>) through an application programming interface, API (<NUM>), comprises at least one functional application that interacts with at least one peripheral hardware abstraction layer, and does not interact with peripheral hardware (<NUM>,<NUM>,<NUM>,<NUM>) omitted from the incomplete design.