Simulated low overhead operating system for embedded systems

Abstract

A method includes: receiving a software system to be tested including a software application; determining one or more operating system application programming interfaces called by the software system to be tested; compiling, by a processing device, a simulated operating system comprising a reduced interface layer providing services associated with the one or more operating system application programming interfaces invoked by the software system to be tested, the services comprising a virtual timer; and outputting the simulated operating system configured to execute the software system to be tested.

Description

Technical Field

[0001] This disclosure relates to testing and verifying the operation of software programs targeted at embedded systems. Background Technology

[0002] Many electronic devices incorporate integrated computer systems, often referred to as embedded systems. For example, Internet of Things (IoT) devices typically include integrated electronic microcontrollers. Additionally, modern automobiles and other types of vehicles include at least one electronic control unit (ECU) to control features such as power steering, braking, infotainment, and advanced driver assistance systems (ADAS). Advances in computing technology, such as reduced cost and power consumption, and increased computing performance and memory density, have enabled these electronic devices to offer enhanced features implemented using software running on these integrated computer systems.

[0003] The information disclosed in this background section is intended to enhance the understanding of this disclosure only, and therefore may contain information that does not constitute prior art known to those skilled in the art. Attached Figure Description

[0004] This disclosure will be more fully understood from the detailed description given below and from the accompanying drawings illustrating embodiments of this disclosure. The drawings are provided to give an understanding of embodiments of this disclosure and are not intended to limit the scope of this disclosure to these specific embodiments. Furthermore, the drawings are not necessarily drawn to scale.

[0005] Figure 1 This is a schematic diagram of a portion of a low-overhead mono-core testing system that supports a system under test, including middleware and applications, according to an embodiment of the present disclosure.

[0006] Figure 2A This is a block diagram depicting components of a single kernel according to some embodiments of the present disclosure.

[0007] Figure 2B This is a signal diagram depicting the communication between the system under test, the verification system, and the monolithic kernel according to embodiments of this disclosure.

[0008] Figure 3 This is a flowchart depicting a method for constructing a single kernel for testing a system under test, according to an embodiment of the present disclosure.

[0009] Figure 4 This is an example of a vehicle electronic control unit (ECU) development and testing platform according to an embodiment of the present disclosure, which includes using a low-overhead single core to simulate the operation of the ECU in the system under test.

[0010] Figure 5This is a flowchart depicting a method for performing testing on a software system under test according to an embodiment of the present disclosure.

[0011] Figure 6 A diagram depicting an example computer system in which embodiments of the present disclosure may operate. Detailed Implementation

[0012] This disclosure relates to a low-overhead operating system for emulation of embedded systems.

[0013] Computer systems integrated into devices (such as vehicles, home appliances, industrial tools (such as robots), and the like) are referred to as embedded systems. These embedded systems allow the devices to provide functionality implemented as software programs rather than using dedicated electronic hardware or mechanical devices. For example, in road vehicles, software running on an electronic control unit (ECU) provides electronic stability control (ESC) or dynamic stability control (DSC), which monitors for loss of steering control and automatically applies the brakes to help steer the vehicle. In more advanced vehicles, the ECU may include additional functionality associated with advanced driver assistance systems (ADAS), such as receiving sensor data (e.g., radar information) to track distances to objects around the vehicle and automatically controlling the vehicle in response to this data (e.g., acceleration, braking, and steering) (e.g., maintaining a set distance from another vehicle or braking or turning to avoid a collision). As another example, robotic systems in manufacturing environments may include embedded processors to dynamically control their operation based on the environment in which those robots operate, such as analyzing workpieces and controlling the robotic arm to perform tasks based on said analysis.

[0014] The complex functions performed by these integrated controllers can be expensive to implement using specially designed integrated circuits, but relatively economical to implement them using software programs running on digital processors, partly due to the decreasing cost and increasing computing power of these processors. As the role of software running on embedded systems (such as vehicle ECUs) increases, a growing portion of the engineering work on manufactured products is being devoted to software running on embedded processors.

[0015] For example, the term Software-Defined Vehicle (SDV) has been used to refer to much of the engineering work spent on the software components of some vehicles, such as autonomous vehicles. In the SDV approach, the functionality of many different ECUs performing specific functions for different parts of the vehicle is integrated into a smaller number of centralized ECUs. These centralized ECUs typically have more powerful processors (e.g., microprocessors) rather than embedded microcontrollers. The more powerful microprocessors also provide these centralized ECUs with sufficient headroom to run an operating system to support advanced features such as ADAS, in-vehicle entertainment, and the like. Using a standards-compliant operating system (e.g., a Portable Operating System Interface or POSIX®) allows engineers to focus their work on building differentiated features within their specialized software.

[0016] For example, a vehicle's infotainment system (e.g., for performing climate control, providing navigation, and playing audio content) can be implemented as one or more software applications running on a software platform that provides application programming interfaces (APIs) for displaying graphics on in-cabin displays, receiving user input via corresponding in-cabin controls (e.g., touchscreens), communicating with user devices (e.g., smartphones), and receiving sensor data from the vehicle. The software platform may contain an operating system, such as Linux® or Android®, running on the ECU's microprocessor. Building applications on a software platform saves engineering time because engineers can use services provided by the operating system (e.g., timers, device drivers, data storage interfaces (e.g., file systems), communication protocols (e.g., Bluetooth® and cellular protocols and the like)) and third-party application software (e.g., databases, audio and video codecs, graphical user interface libraries and the like). An example of an operating system standard is the Portable Operating System Interface (POSIX®), which enables application compatibility across different Unix-like operating systems. The POSIX® standard contains definitions of certain application programming interfaces (APIs) for functions such as threading and network communication. For example, various operating systems such as Linux®, FreeBSD®, macOS®, and similar systems exhibit varying degrees of compliance with the POSIX® standard.

[0017] Validation of software and electronic devices may involve checking whether the device responds to a specific input and produces the expected output. The product being tested may be referred to as a device under test (DUT) or a system under test (SUT). For example, when testing the operation of an ECU used to provide electronic stability control, inputs from sensors (such as accelerometer readings, steering wheel position, brake position, and the like) may be provided to the ECU, and the ECU's output will be monitored to ensure that it provides the expected output to control the wheel brakes.

[0018] While verification can be performed on existing real-world prototypes (e.g., a prototype ECU installed in a vehicle), this approach can be costly and impractical for the development process, especially when dealing with functions that don't heavily rely on the vehicle itself (e.g., audio playback) or when testing a collision avoidance system (e.g., the risk attributable to physical damage). A more economical, but sometimes less accurate, approach is to perform verification within a simulated environment executed by a simulator backend of a verification system (which may contain a computer system). Simulated environments also offer benefits such as increased control over the environment from which the SUT receives input and allow for easier verification of the SUT's state during testing (e.g., pausing the simulation to verify the values ​​of variables).

[0019] In many cases, the application software being tested or validated uses only a small subset of the functionality provided by the operating system. For example, applications conforming to the Automotive Open Systems Architecture (AUTOSAR®) adaptive standard are only allowed to call APIs that are part of the POSIX® Portable Systems Environment (PSE) 51 profile, and PSE51 does not require a file system. Furthermore, running a full production operating system (e.g., one that will be deployed in a device containing embedded systems) can impose significant overhead on the validation system. This overhead reduces the performance (e.g., speed) of the validation system, thereby increasing costs and extending turnaround time for generating feedback for engineers (e.g., generating validation test results). Additionally, some operating systems (e.g., Linux®) are licensed under terms unfavorable to organizations wishing to maintain the proprietary nature of their software products (e.g., the GNU General Public License or variants of the GNU GPL).

[0020] Therefore, aspects of embodiments of this disclosure relate to a low-overhead operating system for simulating embedded systems, which can be used to perform verification of software applications and middleware. The operating system or virtualized operating system environment according to embodiments of this disclosure is customized to provide only the functionality (e.g., APIs) used by the software application and middleware (or system under test). The operating system (or virtualized operating system) provides functionality and drivers to interact with a simulator backend, which provides environmental information (e.g., sensor inputs) and also provides a simulated environment for interaction with the system under test, including providing output from the simulator backend to the application via the operating system. Compared to running a full operating system, using a simulation backend and operating system according to embodiments of this disclosure reduces overhead and provides a high degree of control over the simulation process.

[0021] The technical advantages of this disclosure include, but are not limited to, reducing the computational overhead of verifying the software applications of the system under test. In this case, providing a dedicated emulated operating system that offers only the minimum interfaces and functional sets (e.g., file systems, Ethernet stacks, drivers, and the like) required to validate and verify software running on an operating system offers advantages in terms of operating system image footprint (e.g., memory usage) and faster boot and simulation times (reduced resource consumption compared to a full operating system). This enables better scalability and shorter feedback loops, and also incurs less overhead, for example, when the emulated operating system is stored in a version control system (e.g., Git® or Mercurial) or exchanged between different parties (e.g., vendors) as part of the software development process. This improves simulation performance, allowing more tests to run within the time budget allocated for verification, thereby producing a higher quality final product. Higher performance and lower cost verification and validation (V&V) also enable continuous integration or continuous verification and validation development processes, where software changes are tested, validated, and verified immediately during the engineering process, rather than waiting for batch testing. In addition, running software applications and middleware in a simulated environment enables a high degree of control over the environment, which allows the implementation to test the SUT's application under many different operating conditions, such as insufficient memory, data loss, hardware failure, etc.

[0022] One approach to providing a POSIX®-based emulated OS is to run a modified Linux® within a virtual machine (VM) on top of a hypervisor. Typically, a POSIX®-based OS that provides a full POSIX® interface like Linux® is unnecessary, especially in early development stages where only specific parts of the ECU software stack need to be validated and verified (e.g., perception algorithms receiving input from sensors that are part of an ADAS ECU). This approach leads to scalability issues and longer feedback loops, for example, in regression test cases where a larger number of tests must be performed. A prominent example is the validation and verification of driver assistance functions in different traffic scenarios. Furthermore, modifications to licensed (e.g., GPL-licensed) open-source POSIX®-based OSes (such as Linux®) can create derivative works that may also require open-source access, making the creation of proprietary software difficult because any source code changes may need to be made public to comply with the GPL.

[0023] Alternative methods of using unmodified POSIX®-compliant host operating systems (such as Linux®) for application / middleware validation and verification may result in reduced control over the verification environment due to a lack of determinism, a lack of virtual hardware (HW) models (such as virtual timers), a lack of test features (such as support for fault injection), and a lack of automotive standard support (such as AUTOSAR® Diagnostic Logs and Tracing (DLT)). Furthermore, differences in implementation details between different POSIX®-compliant operating systems (such as Linux® and QNX®), such as regarding non-standard functions (such as APIs) provided by one operating system and another, and regarding behaviors not defined in the POSIX® standard, can lead to different test results. Typically, different mechanisms (e.g., the Linux® command ptrace on a Linux® host OS) can be used to intercept POSIX® API calls for emulation purposes, but these mechanisms are slower and require the creation of a POSIX®-based emulation OS, for example, to maintain internal state between multiple POSIX® API function calls (see, for example, socket calls, such as the socket() function for creating a communication endpoint, the connect() function for initiating a connection on a socket, and the send() function for sending a message on a socket).

[0024] This disclosure relates to low-overhead (e.g., resource-optimized) POSIX®-based operating systems. Figure 1 This is a schematic diagram of a portion of a testing system 100 that uses a low-overhead monolithic kernel 110 running on a host operating system kernel 120 (e.g., executed by a computer system) supporting a system under test 130 including middleware 132 and application 134, according to an embodiment of this disclosure. The following sections promote the use and benefits of monolithic kernels and describe how they are integrated into the testing system.

[0025] Monolithic Approach: Both monolithic kernels and containers are technologies used for application deployment and execution (e.g., in cloud computing environments), but there are key differences regarding this work. Containers are more general-purpose and have a larger footprint than monolithic kernels. Containers do not provide their own operating system kernel (as in the case of a full virtual machine), but instead use the underlying host operating system kernel. A monolithic kernel is a computer program configured to be executed by a processing device, where the monolithic kernel program is linked with the operating system code used by the monolithic kernel. For example, a monolithic kernel is built using a compiler that identifies the operating system services used by the application and links the monolithic kernel program with the corresponding operating system services, so that applications running on the monolithic kernel can access those operating system services.

[0026] Compared to containers, a monolithic kernel is highly specialized and customized to contain only the components required for running a specific application within the kernel (e.g., only the code supporting the portions of the POSIX® API accessible by the application). In other words, the monolithic kernel 110 provides a desired API (e.g., a minimal API) or a desired POSIX® interface (e.g., a minimal POSIX® interface) or a simplified interface layer 112, customized to meet the needs of a specific software system 130 under test, comprising middleware 132 and applications 134, which will run on the monolithic kernel 110. The middleware 132 contains software instructions executed by the processing device, which provide, for example, communication and data management between the application 134 and the monolithic kernel 110. The application 134 refers to one or more applications that perform desired computer functions via the processing device. This also means that a single kernel can be built (or compiled) quickly with extremely low memory footprint, which improves the simulation performance of ECUs and other embedded systems. The low model footprint, speed, scalability, and fast turnaround time improvements are used in the development process of the system under test 130 (e.g., middleware 132 and application 134), including the verification and validation of the operation of the system under test 130. Furthermore, the single kernel, also referred to herein as the emulated operating system, is independent of the host operating system and can be customized to meet the specific requirements of the software system under test 130, for example, by customizing the single kernel to match its behavior to that of the production operating system on which the software application will run in production (e.g., regarding behavior not defined in the POSIX® standard and implementing a dedicated application programming interface).

[0027] Figure 2A This is a block diagram depicting the components of a monolithic kernel 200 according to some embodiments of the present disclosure. The monolithic kernel 200 implements only the portions of the complete application programming interface (e.g., POSIX® API) provided by the operating system required by the system under test 230, wherein the exposed implementation of the API is presented as a minimal API or simplified interface layer 202. The system under test 230 may include middleware 232 and / or applications 234 developed by the user for implementing embedded systems (e.g., ECUs of vehicles), and therefore, the portions of the complete API implemented in the monolithic kernel 200 according to embodiments of the present disclosure are customized based on the application (e.g., by performing static analysis to trace the operating system API calls made by the system under test 230 during compilation or build and building only the portions required to implement those identified OS API calls during the compilation and / or linking of the monolithic kernel).

[0028] The monolithic kernel 200 communicates with an emulator backend 250, which manages other parts of the verification of the system under test 230. For example, the emulator backend 250 may include or manage a simulation environment that provides test inputs to the system under test 230 via the monolithic kernel 200, receives outputs generated by the system under test 230, simulates the impact of outputs from the system under test 230 on a certain environment, and may present updated inputs to the system under test 230. The emulator backend 250 may contain one or more software applications running on the same computer system as the monolithic kernel 200 and the system under test 230, and / or may further contain one or more software applications running on other computer systems (e.g., communicating with the computer system running the monolithic kernel 200 and the system under test 230 via a computer network connection or other communication link). The monolithic kernel 200 and the emulator backend 250 operate within the context of a verification system 260, which, as described above, may be implemented using one or more computers, each containing processing circuitry or processing devices (e.g., a central processing unit (CPU) and a graphics processing unit (GPU)).

[0029] For example, when the ADAS system is used as the system under test 230, the simulator backend 250 can maintain or interact with a simulated three-dimensional (3-D) model of the driving environment of the simulated vehicle (e.g., using a 3-D physics engine). The inputs to the system under test 230 may include image data captured by virtual cameras of the simulated environment surrounding the simulated vehicle, and the outputs from the system under test 230 may include controls for manipulating and / or controlling the acceleration (throttle) and deceleration (brake) of the simulated vehicle. Updated input data from the simulated environment in response to these controls can then be fed back to the system under test 230.

[0030] The monolithic kernel 200 according to embodiments of this disclosure further includes a monolithic kernel component 210 specific to its use in the verification of a system under test 230 running on the monolithic kernel 200. Figure 2A In the embodiments shown, these single-kernel components 210 include drivers for interfacing with virtual hardware simulated by the emulator backend, such as a virtual timer driver 212, a virtual bus hardware driver 214, a logging and trace generator 216, and a fault injection 218, which will be described in more detail below.

[0031] Typically, test cases in a testing system should be reproducible—any given test should pass or fail when executed on a given version of the system under test, regardless of the current time of the test run and independent of the underlying host machine (e.g., in a simulated 3D environment, tests of the detection algorithm's operation under low-light conditions should always generate simulated low-light conditions, regardless of whether the current real-world time is day or night, because additional instance executions, bus and network data packets, log messages, and the like produce the same results or provide the same data, independent of the current time and the execution speed of the underlying host computer). This increases the confidence that changes made to the system under test resolve the problem, rather than finding that the problem has disappeared due to random external changes.

[0032] To achieve repeatable test execution, aspects of embodiments of this disclosure involve controlling a single kernel 200 to operate deterministically on a virtual time basis independent of real time (e.g., wall clock time), wherein the virtual time is controlled by a simulator backend that runs a simulation of an environment used to test the software system under test. This allows for greater control over the environment presented to the software system under test, as the simulator has complete control over the time observable by the software system under test, rather than being subject to a timer of a host computer system running based on real time (e.g., wall time). This virtual time may be faster or slower than real time (e.g., depending on the quality or level of detail of the simulation environment and the performance of the simulator backend, such as the capabilities of the hardware running the simulator and the efficiency of the simulation software). In some embodiments, the single-kernel time mechanism is replaced by a virtual timer driver 212 (or a front-end virtual timer) that provides an interface to the virtual time provided by a simulator backend virtual timer model 252 of the simulator backend 250. More specifically, in some embodiments, the emulator backend provides a virtual timer hardware model and a mechanism for incrementing virtual time in an event-discrete manner, so that the simulated virtual timer driver 212 in the monolithic kernel 200 accessed by the middleware 232 and the application 234 is synchronized with the virtual time in the environment simulated by the emulator backend 250.

[0033] Another example of the monolithic kernel component 210, specifically designed for use in verifying the system under test 230 according to embodiments of this disclosure, is the virtual bus hardware driver component 214. For example, to enable verification of the system under test 230 interacting with a dedicated communication bus, the virtual bus hardware driver 214 is integrated with the monolithic kernel 200 and communicates with virtual bus hardware models 254. These virtual bus hardware models are provided by the simulator backend 250, which allows the simulator backend to implement virtual bus communication (e.g., providing freedom from the bandwidth limitations of the real bus). In the case where the system under test 230 is an application for an automotive ECU, an example of an automotive bus system is Automotive Ethernet and Controller Area Network (CAN). However, embodiments of this disclosure are not limited thereto and may include other types of virtual bus hardware models for other communications, such as virtual network stacks (e.g., for cellular, Wi-Fi, Bluetooth® and other network connections using, for example, Transmission Control Protocol / Internet Protocol (TCP / IP) communication stacks or User Datagram Protocol (UDP) network functions), use case-specific proprietary network protocols, local communication bus protocols such as Universal Serial Bus (USB), Peripheral Component Interconnect Fast (PCIe) and the like.

[0034] Compared to hypervisor methods where the virtualized operating system runs on a hypervisor and containerization methods where the virtualized operating system uses an underlying host kernel, the virtual bus hardware driver 214 according to embodiments of this disclosure does not need to interact with the host operating system network stack (e.g., provided by the host kernel). Instead, socket communication is routed from the POSIX® API to a driver that directly interacts with the virtual bus hardware model 254 provided by an emulator backend 250, which uses shared memory to communicate with other components of the test system, such as simulations of other ECUs under test (not necessarily simulations of other ECUs running on the POSIX® operating system), which may be controlled by the same emulator backend 250 or other emulator backends. This contrasts with bus hardware communication exposed by a host operating system that is not controlled by the emulator backend 250 and may therefore exhibit unpredictable and uncontrolled behavior. Using the virtual bus HW driver 214, which communicates with the virtual bus HW model 254, not only improves performance but also increases control over the simulation environment (e.g., the environment exposed to the system under test 230) because it avoids interference with the host operating system (e.g., the network stack), which could affect the reproducibility of the simulation results. Furthermore, the virtual bus hardware driver 214 increases control by allowing the simulator backend 250 to intercept data transmitted from the system under test 230 to the virtual bus hardware model 254 via the virtual bus hardware driver 214 of the monolithic kernel 200. This allows the simulator backend 250 to directly interact with and respond to the data, as discussed in more detail below. This allows the simulator backend to control, to a degree, the data presented to the software under test by the virtual bus HW model 254 via the virtual bus HW driver 214, a degree that would be impossible, for example, if the software under test communicates via a non-virtualized bus driver to a communication bus exposed by the host computer system.

[0035] Figure 2B This is a signal diagram depicting the communication between the system under test, the simulator backend, and the monolithic kernel according to embodiments of the present disclosure. The communication occurs during the verification process of the system under test (e.g., testing the operation of the system under test), during the runtime of the system under test running on the monolithic kernel according to embodiments of the present disclosure. Figure 2BThe example depicts virtual Ethernet communication initiated by the software system under test 231 (including application and middleware 233) using a POSIX® API provided by a virtual bus hardware 215 of a single kernel 201, wherein the virtual bus hardware 215 may include a network stack 217 (e.g., a layer implementing a network stack such as TCP / IP) and a virtual bus hardware driver 219 (e.g., an Ethernet driver in the case of a virtual Ethernet hardware bus). In some embodiments, Figure 2A The virtual bus hardware driver 214 shown in the document contains Figure 2B The virtual bus hardware 215 is shown in the diagram. The software system under test 231 writes output to the virtual bus hardware 215 (or other operating system services) via APIs of services exposed by a streamlined application programming interface provided by the monolithic kernel 202. Instead of routing network communication via the host network stack (e.g., provided by the underlying host kernel running on top of the monolithic kernel 200), the simulator backend 251 provides a virtual bus hardware model 255 that communicates with other ECU emulators (e.g., other ECU emulators running on the same computer) using shared memory 257 by copying data to other parts of memory (e.g., as instructed by the memcpy() function), or by using the host network stack to communicate with other ECU emulators running on other computers (e.g., by copying data to memory locations that will be accessed by the host network stack). Similarly, incoming data to the software system under test is passed from the shared memory 257 of the simulator backend 251 through the virtual bus hardware model 255 and then through the virtual bus hardware 215 into the monolithic kernel 201 to be read as input to the software system under test 231.

[0036] Furthermore, this method does not require elevated privileges on the host computer system (e.g., in the host operating system) and does not require host kernel modifications to run the simulated environment of the system under test 230. Embodiments of this disclosure enable the system under test 230 to run a single kernel 200, which in turn can be executed as a user-space program on the computer system (i.e., without elevated privileges, such as administrator privileges). Specifically, since the single kernel 200 according to embodiments of this disclosure integrates the virtual bus hardware driver 214, it is not necessary to install, for example, a network splitter (e.g., to intercept network access requested by the system under test 230) by modifying the underlying host operating system kernel, which might require elevated privileges (e.g., administrator privileges). In some embodiments, a CAN library (e.g., the SocketCAN library) is integrated into the single kernel 200, enabling CAN messages to be sent to and received from the system under test 230 (application 234 and middleware 232) without requiring these protocols to be available on the host operating system. Here, the virtual bus HW model 254 of the simulator backend 250 is used to transmit and receive CAN messages sent by the simulated system under test 230 and sent to the simulated system under test. The exchange of CAN messages can be performed via shared memory (instead of via an actual or simulated CAN bus), thereby improving the simulation performance.

[0037] Some aspects of embodiments of this disclosure relate to a logging and tracing generator 216 (or a logging and tracing client). In some embodiments, this logging and tracing generator 216 can be used to support automotive-standard-based ECU software validation and verification. For example, to log and traverse ECU SW execution according to the AUTOSAR® Diagnostic Logging and Tracing (DLT) standard, some embodiments integrate a DLT daemon (shown as logging and tracing generator 216 in FIG2) into a single kernel 200 that communicates with a logging and tracing consumer 256 of an simulator backend 250, which acts as a DLT client (e.g., where the DLT daemon provides traces in DLT format). The logging and tracing generator 216 can also be used to log and traverse the execution of a system under test 230, including the execution of POSIX® API calls and / or simulating the internal state of the POSIX® OS for debugging applications 234 and middleware 232. Logging and tracing can further utilize timestamps from virtual timers, which improves log interpretability, especially when trying to reproduce errors by rerunning tests, because timestamps remain consistent across runs.

[0038] Additionally, for verification and validation purposes, it is particularly important to simulate certain dynamic error conditions or faults at the POSIX® interface level. Examples of faults include out-of-memory, connection resets (e.g., network connection resets), connection timeouts (e.g., network connection timeouts), and system restart scenarios. In many cases, verifying the system under test 230 involves verifying whether these error conditions or faults reported by the operating system to the application or middleware through the POSIX® interface layer are handled safely (e.g., an out-of-memory condition does not lead to a catastrophic failure of the ADAS system, but rather allows the ADAS system to continue operating normally or undergoes graceful degradation, protecting the safety of vehicle occupants and the surrounding environment). Therefore, some aspects of embodiments of this disclosure relate to a fault injection component 218 configured to inject faults or report synthetic faults into the system under test 230 through a simplified interface layer 202 of a single kernel 200. For example, the fault injection component 218 may cause memory allocation calls (e.g., malloc or calloc) from middleware 232 or application 234 to return an out-of-memory fault, thereby allowing engineers to test and verify the application's response to this fault. As another example, the fault injection component can cause the virtual bus hardware model 254 or the virtual bus hardware driver 214 to present a connection reset fault to the system under test 230. In some embodiments, the fault is generated or introduced via the fault generation component 258 of the simulator backend 250. More specifically, a specific test of the test suite can cause the ECU under test to enter a specific state (e.g., a state in which the ECU is providing driving guidance and ADAS while simultaneously playing music), and when the ADAS will control the vehicle to take evasive action to avoid a collision with another vehicle, the fault generation component 258 injects a fault, such as a system reset (e.g., caused by the perception system detecting an unknown object in the environment).

[0039] Figure 3 This is a flowchart depicting a method 300 for constructing a single kernel for testing a system under test, according to an embodiment of the present disclosure. Figure 6 The described processing apparatus is implemented using one or more computer systems or machines. Method 300 is provided with one or more user applications (e.g., ...). Figure 2A The application shown in the image (234) includes middleware in some cases (e.g., Figure 2AThe middleware 232 shown in the diagram represents the system under test or the software system under test. In some embodiments of this disclosure, building a monolithic kernel includes compiling the monolithic kernel (e.g., generating object code from one or more source code files) and may further include linking the monolithic kernel (e.g., linking the object code to generate an executable binary). In various embodiments of this disclosure, applications and middleware may be combined with the monolithic kernel using different methods. One method is to compile the monolithic kernel (or a portion thereof) together with the applications and middleware. Another method is to statically link the monolithic kernel (or a portion thereof) together with the applications and middleware. A third method is to compile and link the applications and middleware separately from or independently of the monolithic kernel, and then dynamically load and link the applications and middleware to the monolithic kernel at runtime.

[0040] At 310, the processing device automatically analyzes the software system under test to determine the operating system application programming interfaces (APIs) called by the software system under test. For example, in some embodiments, the processing device performs static analysis of the software system under test to identify or determine API calls. Where the software system under test is provided as source code, libraries or header files containing access to POSIX® APIs (or other operating system APIs) and / or function calls or other system calls to access those APIs are then detected, and the processing device stores a list or other set of detected API uses. (This may include cases where parts of the software system under test are implemented using a compiled programming language (e.g., C) and cases where parts of the software system under test are implemented using an interpreted programming language (e.g., Python or JavaScript). Where the software system under test is provided as compiled object code or binary code, the processing device detects system function calls from the object code to shared libraries (e.g., libraries provided by the POSIX® API) that will be accessed at runtime using dynamic linking.

[0041] At 330, the processing device automatically configures the monolithic kernel compilation to include code that supports APIs called by the software system under test (as previously determined at 310 based on the analysis of the software system under test). In some embodiments, the processing device further configures the monolithic kernel to exclude code that supports APIs not called by the software system under test. For example, a system under test that only performs local operations (e.g., a clock application) may not use network communication functions and / or file system operations, and therefore code supporting the virtual timer driver 212 can be included in the monolithic kernel, while code supporting the virtual bus hardware driver 214 and the file system can be excluded from the monolithic kernel.

[0042] In version 350, the processing unit is automatically configured with a single-core compilation to include functionality for performing verifications on the software system under test. This includes, for example, the functionality described above. Figure 2A The described log recording and tracing generator 216 and fault injection code 218.

[0043] At 370, the processing device compiles the monolithic kernel to be customized for the software system under test to generate a simulated operating system. More specifically, according to some embodiments, the monolithic kernel is customized by including code that supports APIs called by the software system under test and / or linking code while excluding code that would otherwise support APIs not called by the software system under test. The monolithic kernel is further customized to include functionality specifically designed for simulation for the purpose of verifying the software system under test, making the customized monolithic kernel a dedicated simulated operating system. In some cases, depending on the configurability of the monolithic kernel, a relatively small amount of code supporting APIs not called by the software system under test may still be included in the compiled monolithic kernel (e.g., because the granularity of the monolithic kernel's configuration may prevent specific APIs from being called by the software system under test from being supported by the monolithic kernel without also including another API not called by the software system under test).

[0044] In some embodiments, the compilation of the monolithic kernel further includes statically linking the system under test with the compiled monolithic kernel to generate a statically executable binary to be executed during the verification of the system under test. In some embodiments, the software system under test is dynamically linked with the monolithic kernel at runtime (e.g., when performing verification of the system under test).

[0045] At 390, the verification system verifies the software system under test, which includes running the software system under test on a simulated POSIX® operating system and supplying test cases to the software system under test, as will be described in more detail below.

[0046] Experiments using designs based on embodiments of this disclosure demonstrate that a single-kernel operating system image can be used to simulate a POSIX®-based OS for ECU SW stacks used in the field of autonomous driving.

[0047] Figure 4 This is an example of a vehicle ECU development and testing platform 400 according to an embodiment of the present disclosure, which includes a system under test 430 (including middleware 432 and application program 434) using a low-overhead monolithic kernel 410 to simulate the operation of a simulated electronic control unit (ECU) 402. The monolithic kernel 410 includes a virtual hardware (HW) driver 411 that interacts with a corresponding virtual hardware (hardware) 412 (e.g., virtual network hardware, virtual timers, and the like) provided by a simulator backend 414, which runs (e.g., as application software) on a host kernel 416 running on a computer system.

[0048] The analog ECU 402 communicates with the analog environment 440 via a virtual bus. Figure 4 In this example, the simulation environment includes a virtual vehicle 450 simulated based on a vehicle dynamics model 451, a sensor model 453, and an environment model 470 from a vehicle ECU development and testing platform 400. The simulation environment 440 may further include communication with other ECUs 455, which may be simulated ECUs or real ECUs (e.g., physical hardware devices to be used in production vehicles), and may also include communication with other vehicle components 457 (e.g., batteries, thermal systems, and the like, which may also be simulated in software or physical hardware devices). The models included in the virtual vehicle 450 are not limited to the categories described above and may include other vehicle-related models 459 related to testing the software system under test. The environment model 470 provides information about the simulated environment surrounding the vehicle, such as traffic, traffic signs, and road objects, and is also part of the simulation environment 440. The simulation environment 440 is not limited to the models associated with the virtual vehicle 450 and the environment 470 and may also include other models 490 that may not belong to the categories described above. The simulation environment 440 can be implemented in software running on the same host 416 as the simulator backend 414, or it can run on one or more other computer systems separate from the host, wherein the simulator backend 414 communicates with the simulation environment via, for example, a network connection. The test automation service 480 then drives the tests (e.g., test suites) of the verification process to test whether the system under test 430 operates according to specifications. Similarly, the test automation service 480 can run on the same host 416 as the simulator backend 414, or it can run on a different computer system, and communicate with both the simulator backend 414 and the simulation environment 440 to present test cases of the test suite to the software system under test 430 during the verification process.

[0049] More specifically, the test automation service 480 can present test cases to the software system under test 430 by configuring the simulation environment 440 and the simulator backend 414, so as to present inputs to the software system under test 430 and update the state of the simulation environment 440 based on the output of the software system under test.

[0050] Figure 5 This is a flowchart depicting a method 500 for performing verification of a software system under test according to an embodiment of the present disclosure. At 510, a test automation service 480 loads test cases from a test suite to be run to perform verification of the software system under test.

[0051] In 530, Test Automation Service 480 establishes a simulation environment based on test case configuration. For example, where the software system under test is an ADAS system and the test case involves testing the operation of the ADAS system under specific driving conditions, Test Automation Service 480 can configure the simulation environment to initialize a three-dimensional physical simulation of the driving conditions specified by the test case (e.g., approaching an intersection with four-way stop signs, where two other vehicles approach the same intersection from other directions).

[0052] At 550, the test automation service 480 loads the software system under test and the monolithic kernel according to embodiments of the present disclosure, for example by running a compiled binary executable containing a compiled monolithic kernel 410 and the software system under test 430.

[0053] At 570, test automation service 480 runs test cases, which may include, for example, updating the state of simulation environment 440 based on an analog clock to synchronize with or drive a virtual timer within the software system under test 430 (e.g., the virtual timer is synchronized with the analog clock of the simulation environment), so that the simulated time matches the virtual time seen by the system under test. Running test cases produces test results, such as whether the software system under test 430 passes the test case (pass result or failure result) and logs or other output about the test case execution (e.g., stack trace or core dump in the case of failure, logs, and the like). During test case execution, various inputs can be provided from simulation environment 440 to software system under test 430 via simulator backend 414. For example, sensor model 453 and environment model 470 can generate simulated radar data (corresponding to data that a real ADAS system would receive from radar sensors), which is transmitted to software system under test 430 via the virtual hardware bus model of simulator backend and supplied via the virtual hardware bus of single core 410. The software system under test 430 generates output (e.g., steering output) in the form of a message transmitted to the simulation environment via a virtual hardware bus and used to change the state of the simulation environment (e.g., generating output to a virtual vehicle, which can change its steering direction based on the output from the software system under test, wherein the three-dimensional (3-D) model of the simulation environment is updated according to the vehicle dynamics model 451 based on the vehicle's speed and the updated steering direction of the vehicle).

[0054] In some embodiments of this disclosure, test cases may further specify the injection of faults (e.g., out-of-memory errors) into the software system under test during the testing process. For example, a test case may specify that any attempt to allocate memory will cause an out-of-memory error to be generated by fault generation component 258 and injected into the system under test 230 by fault injection component 218 of monolithic kernel 200. Even in the case of injected faults, the operation of the system under test 430 will still be monitored to ensure that the system under test 430 operates as expected.

[0055] Therefore, the behavior of the system under test 430 under simulated timing conditions can be observed by the test automation system and used to verify whether the software system under test operates according to specifications. (In this example, it verifies that the ADAS system under test correctly navigates through an intersection without colliding with other vehicles, while also conforming to the expected behavior of a human driver, such as rules regarding the right-of-way when crossing an intersection and waiting for pedestrians to cross the road.)

[0056] In some experiments, using the mono-kernel method according to embodiments of this disclosure, a custom mono-kernel operating system image tailored for the applications and middleware of the system under test can be built (e.g., compiled) in less than a minute and integrated into the ECU simulation, with a memory footprint of less than 10 megabytes (MB) and a boot time in the millisecond range. For comparison, methods using different operating system images running in a hypervisor were also tested against embodiments of this disclosure. Compared to the three comparative examples, the method according to embodiments of this disclosure is approximately an order of magnitude smaller in memory footprint and approximately an order of magnitude faster in boot time. This significantly reduces simulation and infrastructure costs (e.g., storage, energy consumption, licenses) by providing engineers with the same workflows and environments they are accustomed to using through vehicle development platforms for application / middleware validation and verification, allowing for faster feedback loops and thus shorter development cycles.

[0057] Therefore, embodiments of this disclosure relate to ECU emulation using a POSIX®-based monolithic kernel, which offers significant advantages over Linux®-based methods. Using a POSIX®-based monolithic kernel according to embodiments of this disclosure is more resource-efficient (e.g., has lower overhead) than Linux®-based methods because embodiments of this disclosure implement a monolithic kernel containing only the minimum functionality required by the applications and middleware of the system under test and do not require the hypervisor to develop the ECU SW stack. In specific studies, the monolithic kernel demonstrated 40 times faster boot times and 10 times less image footprint compared to an instance Linux® operating system running in a hypervisor.

[0058] While aspects of the embodiments described herein are set in the context of the automotive industry and ECUs, this disclosure is not limited thereto and may also be applied to other embedded devices, such as in the Internet of Things (IoT) industry and other technologies that may use standardized operating systems (such as the POSIX® operating system).

[0059] According to one embodiment of this disclosure, a method includes: receiving a software system under test containing a software application; determining one or more operating system application programming interfaces (APIs) invoked by the software system under test; compiling a simulated operating system by a processing device, comprising a simplified interface layer providing services associated with the one or more operating system APIs invoked by the software system under test, the services including virtual timers; and outputting the simulated operating system configured to execute the software system under test.

[0060] The method may further include: verifying the software system under test, which includes executing the software system under test on the simulated operating system in a verification system configured to supply test cases to the software system under test and configured to drive the virtual timer, wherein one or more operating system application programming interfaces may include interaction with hardware devices, and wherein the simulated operating system may include services associated with virtual hardware devices simulating the hardware devices in the verification system.

[0061] The testing of the software system under test may include writing output from the software system under test to the virtual hardware device via the service associated with the virtual hardware device.

[0062] The testing of the software system under test may include reading input from the virtual hardware device into the software system under test via the service associated with the virtual hardware device.

[0063] The hardware device may be a network interface.

[0064] The verification of the software system under test may include: injecting an operating system fault from the verification system into the simulated operating system, and presenting the operating system fault to the software system under test via the simplified interface layer.

[0065] The operating system failure described in the method can be selected from one or more of the following: insufficient memory failure; system restart failure; and connection timeout failure.

[0066] According to one embodiment of this disclosure, a system includes: a memory storing instructions; and a processor coupled to the memory and configured to execute the instructions, which, when executed, cause the processor to: execute a simulator backend to provide a virtual hardware model of a simulated environment; and execute a software system under test on a simulated operating system kernel configured to provide operating system features to the software system under test for communication with the virtual hardware model of the simulator backend, wherein the virtual hardware model includes virtual timers.

[0067] The memory may further store instructions that, when executed by the processor, cause the processor to run test cases to verify the software system under test, including setting conditions in the simulation environment according to the test cases, wherein the processor executes the simulator backend to increment the virtual timer in synchronization with the simulation clock of the simulation environment maintained by the simulator backend, wherein the processor executes the simulator backend to provide input from the simulation environment to the software system under test via the virtual hardware model, and wherein the processor executes the simulator backend to receive output from the software system under test via the virtual hardware model and provide the output to the simulation environment.

[0068] The simulation environment may include simulated vehicles generated by a three-dimensional physics engine.

[0069] The simulator backend may include a fault generation component configured to supply operating system faults to a fault injection component of the simulated operating system kernel.

[0070] The simulator backend may include a logging and tracking component configured to log data recorded by the logging and tracking component of the simulated operating system kernel.

[0071] The processor can be configured to increment the virtual timer in sync with the simulation clock update of the simulation environment.

[0072] According to one embodiment of this disclosure, a non-transitory computer-readable medium includes stored instructions that, when executed by a processing device, cause the processing device to: receive a software system under test containing a software application; determine one or more operating system application programming interfaces (APIs) invoked by the software system under test; compile a simulated operating system including a simplified interface layer that provides services associated with the one or more operating system APIs invoked by the software system under test; and output the simulated operating system configured to execute the software system under test.

[0073] The non-transitory computer-readable medium may further include stored instructions that, when executed by the processing device, cause the processing device to: configure a simulation environment according to the test cases; execute the software system under test on the simulated operating system; supply test cases to the software system under test, including supplying input to the software system under test via the simplified interface layer of the simulated operating system based on the state of the simulation environment; monitor the output of the software system under test; and receive the output from the software system under test into the simulation environment via the simplified interface layer of the simulated operating system.

[0074] The simplified interface layer provides virtual timer services to the software system under test based on the virtual timer of the simulated operating system, and the virtual timer can increment synchronously with the simulated clock of the simulated environment.

[0075] The simulation environment may include simulated vehicles generated by a three-dimensional physics engine.

[0076] The simulated operating system may include a fault injection component, and supplying test cases to the software system under test may include injecting operating system faults into the simulated operating system, the operating system faults being presented to the software system under test via the simplified interface layer.

[0077] The operating system failure may be selected from one or more of the following: insufficient memory failure; system restart failure; and connection timeout failure.

[0078] The simulated operating system may include logging and tracking components configured to log operations performed by the software system under test.

[0079] Figure 6 The example machine of computer system 600 can execute within said computer system a set of instructions for causing said machine to perform any or more of the methodologies discussed herein. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine may operate as a server or client machine in a client-server network environment, as a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0080] A machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network device, a server, a network router, a switch, or a bridge, or any machine capable of (sequentially or otherwise) executing a set of instructions specifying actions to be taken by that machine. Furthermore, while referring to a single machine, the term "machine" should also be considered as any collection of machines that individually or jointly execute a set (or more) of instructions to perform any or more of the methodologies discussed herein.

[0081] Example computer system 600 includes a processing device 602 that communicates with each other via a bus 630, a main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (e.g., synchronous DRAM (SDRAM)), a static memory 606 (e.g., flash memory, static random access memory (SRAM) and the like), and a data storage device 618.

[0082] Processing device 602 represents one or more processors, such as microprocessors, central processing units, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or multiple processors implementing combinations of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, or the like. Processing device 602 may be configured to execute instructions 626 for performing the operations and steps described herein.

[0083] The computer system 600 may further include a network interface device 608 for communication via a network 620. The computer system 600 may also include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse), a graphics processing unit 622, a signal generation device 616 (e.g., a speaker), a graphics processing unit 622, a video processing unit 628, and an audio processing unit 632.

[0084] Data storage device 618 may include a machine-readable storage medium 624 (also referred to as a non-transitory computer-readable medium) thereon storing one or more sets of instructions 626 or software embodying any or more of the methodologies or functions described herein. Instructions 626 may also reside wholly or at least partially in main memory 604 and / or processing device 602 during their execution by computer system 600, which also constitute machine-readable storage media.

[0085] In some embodiments, instruction 626 includes instructions for implementing functions corresponding to this disclosure. Although machine-readable storage medium 624 is shown as a single medium in example embodiments, the term "machine-readable storage medium" should be considered as including a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered as including any medium capable of storing or encoding a set of instructions for machine execution and causing the machine and processing device 602 to perform any or more of the methodologies of this disclosure. Therefore, the term "machine-readable storage medium" should be considered as including, but not limited to, solid-state memory, optical media, and magnetic media.

[0086] Some parts of the foregoing detailed description have been presented based on the algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are methods used by those skilled in the art of data processing to most effectively communicate the essence of their work to others skilled in the art. An algorithm can be a sequence of operations that leads to a desired result. An operation is an operation that requires physical manipulation of physical quantities. Such quantities can take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Such signals can be referred to as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0087] However, it should be remembered that all these and similar terms should be associated with appropriate physical quantities and are merely convenient labels for application to those quantities. Unless otherwise expressly indicated as is clearly stated in this disclosure, it should be understood that throughout the description, certain terms refer to the actions and processes of a computer system or similar electronic computing device that manipulate and transform data representing physical (electronic) quantities in the registers and memories of the computer system into other data representing physical quantities similarly represented in the memory or registers or other such information storage devices of the computer system.

[0088] This disclosure also relates to apparatus for performing the operations described herein. Such apparatus may be specifically constructed for its intended purpose, or may comprise a computer selectively activated or reconfigured by a computer program stored in a computer. This computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magneto-optical disks), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards, or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0089] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various other systems may be used in accordance with the teachings and procedures herein, or it may prove convenient to construct more specialized devices to implement the methods. Furthermore, this disclosure is not described with reference to any particular programming language. It should be understood that various programming languages ​​can be used to implement the teachings of this disclosure described herein.

[0090] This disclosure can be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, said instructions being used to program a computer system (or other electronic device) to perform processes according to this disclosure. A machine-readable medium includes any means for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes machine-readable storage media such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory devices, etc.

[0091] In the foregoing disclosure, embodiments thereof have been described with reference to specific examples of embodiments thereof. It should be understood that various modifications may be made to this disclosure without departing from the broader spirit and scope of the embodiments set forth in the appended claims. Where elements are referenced in a singular form in this disclosure, more than one element may be depicted in the drawings, and similar elements are labeled with similar numbers. Therefore, this disclosure and the drawings should be viewed in an illustrative rather than restrictive sense.

Claims

1. A method comprising: Receive the software system to be tested, including the software application; Identify one or more operating system application programming interfaces (APIs) that are called by the software system under test; A simulated operating system, compiled by a processing device, includes a simplified interface layer providing services associated with one or more operating system application programming interfaces (APIs) called by the software system under test, the services including virtual timers; and The output is configured to execute the simulated operating system of the software system under test.

2. The method of claim 1, further comprising verifying the software system under test, comprising executing the software system under test on the simulated operating system in a verification system configured to supply test cases to the software system under test and configured to drive the virtual timer. The one or more operating system application programming interfaces include interaction with hardware devices, and The simulated operating system includes services associated with a virtual hardware device that simulates the hardware device in the testing system.

3. The method of claim 2, wherein testing the software system under test includes writing output from the software system under test to the virtual hardware device via the service associated with the virtual hardware device.

4. The method of claim 2, wherein testing the software system under test includes reading input from the virtual hardware device into the software system under test via the service associated with the virtual hardware device.

5. The method according to claim 2, wherein the hardware device is a network interface.

6. The method according to claim 2, wherein the testing of the software system under test comprises: Injecting the operating system fault from the testing system into the simulated operating system, and The operating system fault is presented to the software system under test via the simplified interface layer.

7. The method of claim 6, wherein the operating system failure is selected from one or more of the following: Insufficient memory fault; System restart failure; and Connection timeout error.

8. A system comprising: Memory, which stores instructions; and A processor, coupled to the memory and configured to execute the instructions, which, when executed, cause the processor to: Execute the simulator backend to provide a virtual hardware model for the simulation environment; and The software system under test is executed on a simulated operating system kernel, which is configured to provide operating system features to the software system under test for communication with the virtual hardware model at the backend of the simulator, wherein the virtual hardware model includes a virtual timer.

9. The system of claim 8, wherein the memory further stores instructions that, when executed by the processor, cause the processor to run test cases to verify the software system under test, including setting conditions in the simulation environment according to the test cases. The processor executes the simulator backend to increment the virtual timer in sync with the analog clock of the simulation environment maintained by the simulator backend. The processor executes the simulator backend to provide input from the simulation environment to the software system under test via the virtual hardware model, and The processor executes the simulator backend to receive output from the software system under test via the virtual hardware model and provides the output to the simulation environment.

10. The system of claim 9, wherein the simulation environment comprises a simulated vehicle simulated by a three-dimensional physics engine.

11. The system of claim 8, wherein the simulator backend includes a fault generation component configured to supply operating system faults to a fault injection component of the simulated operating system kernel.

12. The system of claim 8, wherein the simulator backend includes a logging and tracking component configured to log data recorded by the logging and tracking component of the simulated operating system kernel.

13. The system of claim 8, wherein the processor is configured to increment the virtual timer in sync with the analog clock update of the simulation environment.

14. A non-transitory computer-readable medium comprising stored instructions that, when executed by a processing means, cause the processing means to: Receive the software system to be tested, including the software application; Identify one or more operating system application programming interfaces (APIs) that are called by the software system under test; Compile a simulated operating system that includes a streamlined interface layer providing services associated with one or more operating system application programming interfaces called by the software system under test; and The output is configured to execute the simulated operating system of the software system under test.

15. The non-transitory computer-readable medium of claim 14, further comprising stored instructions that, when executed by the processing means, cause the processing means to: Configure the simulation environment according to the test case described; The software system under test is executed on the simulated operating system. Supplying test cases to the software system under test includes supplying input to the software system under test via the simplified interface layer of the simulated operating system based on the state of the simulated environment; Monitor the output of the software system under test; and The output from the software system under test is received into the simulation environment via the simplified interface layer of the simulated operating system.

16. The non-transitory computer-readable medium of claim 15, wherein the simplified interface layer provides virtual timer services to the software system under test based on a virtual timer of the simulated operating system, and The virtual timer increments synchronously with the analog clock of the simulation environment.

17. The non-transitory computer-readable medium of claim 15, wherein the simulation environment comprises a simulated vehicle simulated by a three-dimensional physics engine.

18. The non-transitory computer-readable medium of claim 14, wherein the simulated operating system includes a fault injection component, and The provision of test cases to the software system under test includes injecting operating system faults into the simulated operating system, and the operating system faults are presented to the software system under test through the simplified interface layer.

19. The non-transitory computer-readable medium of claim 18, wherein the operating system failure is selected from one or more of the following: Insufficient memory fault; System restart failure; and Connection timeout error.

20. The non-transitory computer-readable medium of claim 14, wherein the simulated operating system includes a logging and tracking component configured to log operations performed by the software system under test.

Images