AUTOSAR-Compatible Level-4 Virtual ECU for the Verification of the Target Binary for Cloud-Native Development

Abstract

The rapid evolution of automotive software necessitates efficient and accurate development and verification processes. This study proposes a virtual electronic control unit (vECU) that allows for precise software testing without the need for hardware, thereby reducing developmental costs and enabling cloud-native development. The software was configured and built on a Hyundai Autoever AUTomotive Open System Architecture (AUTOSAR) classic platform, Mobilgene, and Renode was used for high-fidelity emulations. Custom peripherals in C# were implemented for the FlexTimer, system clock generator, and analog-to-digital converter to ensure the proper functionality of the vECU. Renode’s GNU debugger server function facilitates detailed software debugging in a cloud environment, further accelerating the developmental cycle. Additionally, automated testing was implemented using a vECU tester to enable the verification of the vECU. Performance evaluations demonstrated that the vECU’s execution order and timing of tasks and runnable entities closely matched those of the actual ECU. The vECU tester also enabled fast and accurate verification. These findings confirm the potential of the AUTOSAR-compatible Level-4 vECU to replace hardware in development processes. Future efforts will focus on extending capabilities to emulate a broader range of hardware components and complex system integration scenarios, supporting more diverse research and development efforts.

1. Introduction

The modern automotive industry is experiencing a period of technological transformation, with a rapid increase in the role and importance of software within vehicles [1]. Unlike the past, where automobiles primarily relied on mechanical functions, today’s vehicles depend heavily on software-based features. As the complexity of software increases, simulation plays a crucial role in substantially enhancing the efficiency and accuracy of the development and verification processes [2].

Figure 1 shows the structure of the V-model development process. In vehicular development, the V-model is extensively used to systematically manage the processes of system design, development, and testing [3]. This model includes all the processes from the analysis of requirements to the system, architecture, and module designs on the descending path (shown on the left side of Figure 1). The ascending path on the right side of the figure includes the module, integration, and system tests and the verification of meeting end-user requirements. This structure enables the clear definition and systematic integration and verification of requirements during the complex system development process, greatly enhancing overall development efficiency and productivity.

As the complexity of in-vehicle software increases, especially in software-defined vehicles (SDV), the software requirements and design defined on the left side of the V-model must be quickly and accurately verified during the verification stages (shown on the right side of the model). In actual automotive development, software development is initiated before the hardware is determined, and the developed software must be verified on real hardware. Bottlenecks can occur during this process, which may affect the overall vehicle development project timeline. Therefore, developing and testing software using a virtual electronic control unit (vECU) [4] is a key element that can improve the productivity of the entire vehicle development by enabling high-level software verification from the early stages without delays in hardware preparation.

Figure 1b shows a V-model which includes a vECU. This improved model allows developers to verify quickly software requirements from the early stages of development. Typically, the verification stage on the ascending path on the right progresses in the order of software-in-the-loop (SiL) [5] and hardware-in-the-loop (HiL) [6], but if the hardware is not ready, verification can be delayed until after the SiL stage. By using a vECU in vHiL (virtual HiL) [7], early verification of the software is enabled, allowing issues to be identified early and ensuring the stability and reliability of the software before the hardware is ready.

Moreover, the recent adoption of cloud-native development methods makes the use of vECUs even more essential. Cloud-native development refers to the design, development, deployment, and operation of applications in a cloud environment. In automotive software development, the introduction of cloud-native development methods offers several benefits. First, developers can collaborate in real time on the cloud, using vECUs to simultaneously test and verify software. This enables rapid feedback cycles without the delays associated with the preparation hardware, significantly accelerating software development. Second, it ensures that all developers work in the same environment, reducing issues caused by differences in development environments and allowing for consistent debugging and testing. Third, it facilitates data collection and analysis. As the software runs on a vECU, the logs and data generated during this process can be stored and analyzed in the cloud.

This cloud-native approach plays a crucial role in developing complex and highly reliable automotive software, especially for SDVs. By combining vECUs with cloud-native development methods, developers can create more reliable and efficient software, thereby enhancing the productivity and quality of the entire vehicle development project.

Understanding the AUTomotive Open System Architecture (AUTOSAR) [8] is essential before delving into the stages of a vECU. AUTOSAR is an open system architecture that promotes standardization in the global automotive industry to enhance the reusability, scalability, and interoperability of in-vehicle software. This promotes the SDV approach and plays an important role in the development and integration of in-vehicle software. The AUTOSAR architecture can be divided into three main components: the application software (ASW), the run-time environment (RTE), and the basic software (BSW). The ASW consists of software modules that implement specific vehicle functions, while the BSW provides system services, network management, and other hardware abstraction functions, including the operating system. The RTE mediates communication between the ASW and BSW and is generated based on the configurations of the ASW and BSW. This structure provides a crucial foundation for the development and testing of vECUs and serves as the background for various corporate attempts to develop and supply vECUs.

vECUs are classified into different levels based on the scope of testing [9].

Table 1. Level of virtual ECU (vECU).

Level	Application Software	Run-Time Environment	Basic Software
Level 0	Model	-	-
Level 1	Production Code	Simulated Code	-
Level 2	Production Code	Production Code	Simulated Code
Level 3	Production Code	Production Code	Production Code without HW dependency
Level 4	Binary Code	Binary Code	Binary Code

lists the differences among vECU levels. Level 0 is used for simple control algorithm testing with the control model itself or the C code generated from the model. Level 1 involves the production code of the ASW, including the simulated RTE, and tests the interactions and functionalities in the ASW. Level 2 includes production code of the ASW and the RTE, along with the simulated BSW to test interactions and perform bus monitoring and diagnostic tests for a broad range of ASW. Level 3 involves the integration and validation of the entire system, including the production ASW, RTE, and BSW, excluding hardware-dependent parts. It is tested in a Linux or X86 PC environment. Level 4 tests the binary code for the actual target ECU. Unlike Level 3, it uses a vECU that simulates hardware to test the binary code. Various stages of vECU solutions used in the automotive industry provide significant value; additionally, the higher the level of the vECU, the greater the utility in software and hardware integration and validation.

This study proposes a Level-4 vECU that not only runs AUTOSAR-based software but also adjusts the simulation time to operate as a prototype ECU and quickly execute test cases. The increasing complexity of automotive software demands more accurate and efficient development and verification processes. By matching the simulation clock with the wall clock, we can create a realistic prototype of the actual ECU, while accelerating the simulation clock allows for the faster execution of test cases.

To achieve this, we configured the basic ASW and BSW settings in a Hyundai Autoever AUTOSAR classic platform (CP), Mobilgene classic for R4.0.3 [10], and generated the RTE. Based on these settings, we generated the source code for the entire system, built it, and created the executable file. As this executable file is built based on NXP S32K148 hardware [11], we used the Renode 1.15.0 emulator [12] to create the NXP S32K148 vECU. We included the minimal necessary components for the operation, such as the central processing unit (CPU) and memory, and we created the peripherals required to run the AUTOSAR OS. Our performance evaluation demonstrated that the timing accuracy and execution order of the vECU closely matched those of actual ECU, with minimal error rates.

The remainder of this paper is organized as follows. Section 2 provides the background and related work in this field. Section 3 explains the design of the software architecture that will run on the vECU. Section 4 details the hardware architecture. Section 5 presents the experimental results by comparing the proposed approach with actual hardware boards. Section 6 discusses the potential improvements and future directions for vECU. Finally, Section 7 discusses the conclusions and future research directions.

2. Background

2.1. AUTOSAR

AUTOSAR was established in 2003 with the participation of major automotive manufacturers and technology companies, including Bayerische Motoren Werke (BMW), Bosch, and Continental; the first release was announced in 2006. AUTOSAR provides standardized interfaces and a software architecture that ensure software complexity management and system interoperability. This standard is extensively used in the global automotive industry and plays an essential role in integrating modern automotive technologies. As of the latest release, R23-11, AUTOSAR continues to evolve to meet the latest industry requirements.

AUTOSAR is divided into the CP and the adaptive platform (AP). CP is centered around a real-time operating system (RTOS) and supports traditional automotive controller applications. In contrast, AP is Linux-based and developed to support advanced applications with higher data processing requirements, such as autonomous driving. This study focuses solely on the CP, as it deals with a Level-4 vECU that supports the CP of AUTOSAR.

Figure 2 shows the structure of the AUTOSAR CP. This structure is mainly composed of the ASW, RTE, and BSW. The ASW consists of software components (SWCs) that implement specific vehicular functions, such as engine management, vehicular information systems, and vehiclular control. The BSW comprises the basic software components running on the ECU. Functionally, the BSW is divided into system services, memory services, communication services, input/output (I/O), and complex device drivers (CDDs). Each of these components is responsible for operating system functions, memory management, communication support, and I/O management, with CDD allowing users to implement non-standard functionalities. The BSW can be abstracted into the microcontroller abstraction layer (MCAL), the ECU abstraction layer, and the service layer. The MCAL handles direct hardware control and includes various hardware drivers such as analog-to-digital converters (ADCs), the controller area network (CAN), and pulse width modulation (PWM). The ECU abstraction layer hides hardware details and provides a consistent interface to the upper layers. The service layer, the highest layer, offers system and operating system services and is responsible for network and memory management. This focus on the early-stage validation of hardware-dependent code positions our Level-4 vECU as an important tool for more complex system development, where higher-level vECUs are essential for verifying hardware-specific functionalities.

This layered architecture reduces software dependency on specific hardware configurations, allowing new hardware to be implemented by replacing the MCAL without extensive modification to the existing software code. This greatly enhances software reusability and improves the efficiency of the vehiclular development process.

2.2. Virtual ECU Tools

There are several commercial tools available in the market that support the creation of vECUs. ETAS’s VECU-BUILDER [13] supports the creation of vECUs and generates Level-1, Level-2, and Level-3 vECUs in the form of functional mock-up units (FMUs). ETAS also offers the COSYM [14], which integrates environmental data with vECUs and supports model-in-the-loop (MiL) and SiL testing through the ETAS MODEL-SIMULATOR. dSPACE’s SystemDesk [15], like VECU-BUILDER, generates Level-1, Level-2, and Level-3 vECUs in FMU form and integrates and simulates these vECUs through the use of VEOS [16]. Vector’s vVIRTUALtarget [17] supports the development and testing of Level-3 vECUs and integrates with other vector tools such as CANoe [18] and vTESTstudio [19]. Commercial tools typically support up to Level-3 vECUs. This is because meeting the requirements of Level-4 vECUs is challenging. ECUs include various hardware components, and modeling all these elements is extremely complex and requires significant time and effort. Therefore, from the perspective of commercial tools, the Level-3 approach is cost-effective and practically feasible.

However, our proposed Level-4 vECU addresses some of the limitations seen in commercial tools. While commercial tools like VECU-BUILDER and SystemDesk are efficient for MiL and SiL testing, our solution is designed to support hardware-dependent testing. Unlike most commercial tools that focus on model-based abstractions, our vECU can execute the actual target binary generated from a commercial AUTOSAR authoring tool. This enables the testing and validation of hardware-dependent code, including the MCAL and real-world applications at an early development stage. In addition, our Level-4 vECU provides precise timing accuracy through the synchronization of the simulation clock, which is vital for systems that require detailed timing analysis. Many commercial tools operate at higher levels of abstraction, which can limit their ability to test hardware-dependent timing behaviors with the same level of precision.

2.3. Related Works

2.3.1. Using Level-3 Virtual ECU

Level-3 vECUs are supported by various commercial tools. A considerable amount of related research exists on this topic. Bidkar et al. [20] presented a methodology to develop and test vehicular diagnostic software in a vECU environment using the unified diagnostic services (UDS) protocol. This study used vVIRTUALtarget to create a Level-3 vECU, providing an environment for testing diagnostic software without physical hardware. Yadav et al. [21] developed a virtual test environment for vehicle-level simulations and proposed a methodology for testing and verifying AUTOSAR-based ECUs. This study utilized the SystemDesk and VEOS toolchain. Urbina et al. [22] developed an AUTOSAR-based simulation environment for multicore processors using SystemC and VEOS. This research work proposed a methodology to simulate vECU operations using SystemDesk and TargetLink tools and introduced a communication interface for synchronization and data exchange between VEOS and SystemC simulation systems, supporting accurate time-triggered message-based communication. Franco et al. [23] presented a workflow and toolchain for developing and verifying vehicle software in vECUs based on the AUTOSAR standard. This study described a methodology for generating and managing vECUs using dSPACE’s SystemDesk, VEOS, TargetLink, and MathWorks’ MATLAB, Simulink, and Stateflow. Ankitha et al. [24] developed a vECU compliant with the AUTOSAR standard using the dSPACE toolchain and described the memory addresses and data structures of vECU variables through memory description files. This research work assessed various techniques to prevent random-access memory damage using ControlDesk, XILAPIMAPort, Pymem, and GDB and analyzed their limitations.

2.3.2. Using Level-4 Virtual ECU

Most studies dealing with Level-4 vECUs have utilized quick emulator (QEMU) [25]. Yang et al. [26] used QEMU to virtualize the STM32F407ZGT6 and proposed a methodology to reduce simulation timing errors of the vECU by reflecting the actual ECU’s operation time. Yang et al. [27] proposed a method to simulate the input and output of AUTOSAR-based software in a QEMU vECU. This study explained how to simulate the digital I/O modules by modifying or reading the register values of the vECU using specific software programs.

3. AUTOSAR Software Architecture

We designed the software according to the AUTOSAR standard. To ensure that multiple SWCs operate identically in both the Renode vECU and the actual hardware, we designed the SWCs as shown in Figure 3. First, SWC1 operates every 10 ms to read the value of switch1 and sends the read value to SWC2. SWC2 turns on LED1 if the data received from SWC1 indicate that the switch is on. SWC3 operates every 10 ms, incrementing its counter, and triggers SWC4 when the counter reaches a value of five. SWC5 operates every 50 ms to toggle LED2. Additionally, SWC6 reads data from the ADC and sends the value to SWC7. SWC7 has four LEDs and controls their state based on the analog-to-digital converter (ADC) data values.

3.1. Designing ASW with the AUTOSAR Authoring Tool

Once the structure of the SWC was designed, we proceeded to create the SWCs. The tool used to generate the target executable file according to the AUTOSAR standard is called the AUTOSAR authoring tool. We also used the Mobilgene. To create an SWC, a design blueprint of the components comprising the SWC is required. The AUTOSAR standard refers to these design diagrams as types. When SWCs exchange data, the data must be defined. We defined these data as Boolean and integer data. After we defined the data type, we defined the port types. The AUTOSAR standard refers to port types as interfaces. Interfaces include sender–receiver interfaces used for data exchange, client–server interfaces used for service requests, and trigger interfaces for activating connected SWCs. We defined the If_Switch and If_ADC sender–receiver interfaces to transmit Boolean switch and integer ADC data. The previously defined Boolean and integer data were brought in as data prototypes within the interface. Once the interface design was complete, we created the SWC type for SWC1. Within the SWC1 type, we added the provided and received ports using the interfaces. The former provides data or services, while the latter receives data or services. We created a provided port with the If_Switch interface and a received port with the If_DigDir interface from the BSW’s input/output hardware abstraction (IoHwAb) module. SWC2, which receives data from SWC1, was created with a received port using the If_Switch interface and an additional received port using the If_DigDir interface to request services for LED1. SWC3 was created with a provided port using the If_Trigger interface. In addition, SWC4, triggered by SWC3, was created with a received port using the If_Trigger interface. SWC5 was created with a received port using the If_DigDir interface to request LED2 services. SWC6, which reads data from the ADC, was created with a provided port using the If_ADC interface and a received port using the If_AnaInDir interface from the IoHwAb module. SWC7, which receives data from SWC6, was created with a received port using the If_ADC interface and an additional received port using the If_DigDir interface to control the state of four LEDs (LED3 to LED6) based on the ADC data values.

Following the creation of the ports, we created runnable entities (REs). An RE is an execution unit of an SWC requiring event and point settings. Events are conditions that trigger RE execution. Event types include timing events (TEs) that execute REs at defined intervals, data received events (DREs) that trigger REs upon receiving specific data from other SWCs, and operation-invoked events that execute REs when an operation is requested. Points define how the SWC exchanges data and requests and provides services. A data send point (DSP) is an interface point for the software component to send data externally. A data received point (DRP) is a point for receiving data from external sources. DRPs include data received points by value for return-based data receipt and data received points by argument (DRPBA) for pointer variable-based data receipt. A server call point (SCP) allows a client SWC to invoke operations of a server SWC, requesting services from the server. In the RE1 of SWC1, we added a 10 ms TE, an SCP for requesting switch data, and a DSP for sending switch data. In the RE2 of SWC2, we set the following: a DRE triggered by data received from SWC1, a DRPBA to receive data, and an SCP to request LED1 services. For the RE3 of SWC3, we added a 10 ms TE and a triggering point for other SWCs. The RE4 of SWC4, triggered by SWC3, was set with a trigger occurred event (TOE) to execute upon SWC3’s call. The RE5 of SWC5 was set with a 50 ms TE and an SCP to request LED2 services. For the RE6 of SWC6, we designed it with a 10 ms TE, an SCP for requesting ADC data, and a DSP for sending ADC data. Lastly, the RE7 of SWC7 was configured with a DRE triggered by data received from SWC6, a DRPBA to receive the ADC data, and an SCP to control the state of four LEDs.

After completing the design of all the SWCs, we grouped SWCs that required connections into the composition software component (CSWC). A CSWC can contain multiple atomic SWCs, enhancing modularity and manageability in system design. We grouped SWC1 and SWC2 into CSWC1, SWC3 and SWC4 into CSWC2, and SWC6 and SWC7 into CSWC3

3.2. ECU Data Extraction and System Configuration

Once the SWC design is complete, it needs to be mapped to the root composition. The root composition is the top-level composition that constitutes the ECU system. After mapping it to the root composition, we extracted the ECU information. The result of the ECU information extraction updates the EcuExtract.arxml. This file is then used as the input to generate the RTE configuration file, RTE.arxml. Because the RTE adjusts internal interfaces according to data exchange and service request information among SWCs, the RTE configuration must be regenerated once the SWC design is complete.

After generating the RTE, we proceeded with the configuration of the necessary modules within the BSW. As we were using switches, LEDs, and ADC, we configured the IoHwAb module. The MCAL attached to the hardware is typically provided by the board manufacturer and does not usually need modification. However, the I/O requires adjustments to the pin options such as mode and direction in the MCAL’s port module. According to the board specifications, we set Pin 8 of Port C to the GPIO input, Pins 12–17 of Port E to LED1–LED6, and Pin 0 of Port A to ADC. We then created a switch, LEDs, and an ADC in IoHwAb, added references to the pins, and connected the pins with IoHwAb. After this configuration, we regenerated the IoHwAb module to create the ports. Once the ports were created, we connected the client–server received ports generated in SWC1, SWC2, SWC4, SWC6, and SWC7 to the provided ports for the switch, LEDs, and ADC in IoHwAb

To ensure that the RE operates correctly, the OS module configuration must precede the configuration of the RE. The AUTOSAR OS, based on the OSEK RTOS, manages the system through task scheduling. For OS scheduling, the OS must be able to measure time, which is achieved using the OS counter. We created an OS counter and set the seconds per tick in the OS counter to determine how often the OS counter should increment. In this system, we set it to 1.25 ms. Subsequently, we configured OS alarms. Alarms are used to activate tasks at specific intervals or trigger events at certain times to induce system responses. We created alarms to activate tasks every 10 ms and 50 ms, setting the counter reference to the previously created OS counter. We then created four tasks. OsTask_ASW_10ms executes a timing event every 10 ms. OsTask_ASW_TOE executes the TOE. OsTask_ASW_50ms executes a timing event every 50 ms. OsTask_ASW_DRE executes the DRE. Task priorities were set in the order of OsTask_ASW_10ms, OsTask_ASW_TOE, OsTask_ASW_50ms, and OsTask_ASW_DRE. Full pre-emption was enabled so that a higher-priority task interrupts a lower-priority task when it becomes ready.

After creating tasks and alarms, we added the objects to the OS application. The OS application contains information about alarms, tasks, counters, ISRs, and others. Each core independently manages an OS application, which provides time predictability and resource management benefits. After setting up the OS, we used the event-to-task mapping function to map the events of REs created in each SWC to tasks. After completing all these processes, we generated the source code from the ARXML, built it, and created the target binary.

4. Proposed Virtual ECU

4.1. Configuration of Hardware

To execute the target binary, we developed a vECU using the Renode emulator. Renode defines the configuration of the board in a renode platform (REPL) file. Components such as the CPU, memory, and peripherals defined in the REPL are instantiated with specific types and mapped to the system bus (Sysbus) with address spaces and necessary parameters.

Figure 4 shows the block diagram of the S32K148 vECU components. Modules are connected to the Sysbus, and each hardware component is assigned a memory-mapped I/O address. We set the CPU to the ARM Cortex-M series and specifically designated it as the Cortex-M4, identical to the actual hardware CPU. The nested vectored interrupt controller (NVIC), a component of the Cortex-M series, manages interrupt handling within the microcontroller, enabling efficient interrupt prioritization and processing. We set the input clock to 80 MHz according to the system clock configuration.

Subsequently, we defined the memory according to the memory specifications of the S32K148 hardware. The program memory starts at address 0 or 0x0, has a size of 2 MB, and contains the program code to be executed by the system. Static random-access memory (SRAM) was defined as upper and lower SRAM. The upper SRAM is a relatively small SRAM area with a size of 124 KB, used for storing small datasets or critical system components requiring high-speed access. In contrast, the lower SRAM represents a larger SRAM area with a size of 64 MB, used for data-intensive tasks.

The FlexTimer (FTM) is a timer module used as an input to the OS counter, where the OS counter tick increases when an interrupt occurs. The system clock generator (SCG) manages the overall system clock. This clock generator integrates various clock sources and provides the necessary clocks for different parts of the system. The ADC module receives analog data or sampled data through its channels and stores the converted digital data or sampled data in the result register. The port module is directly connected to sensors or actuators, allowing the CPU to read sensor data or control actuators through the Sysbus. The GPIO module is connected to all port modules, and when an interrupt occurs from the input of a port, it sends an interrupt request to the NVIC module.

4.2. Implementation of Hardware Using C# Scripts

Renode supports various microcontroller architectures such as ARM, AVR, and RISC-V, and provides basic modules that can simulate related CPUs, memory, and peripherals. These modules are already verified components that effectively emulate the operation of actual hardware. This allows developers to build systems quickly using existing, verified configurations without having to design complex hardware setups from scratch.

Another significant advantage of Renode is the ability to create custom peripherals using the C# programming language. This is particularly useful when the components provided by Renode are insufficient or when specific functionalities are required. C# is object-oriented and offers extensive libraries and APIs, enabling developers to write code easily and integrate it for new peripherals or specialized behaviors.

In this study, we created custom peripherals for the FTM, SCG, and ADC. The FTM provides multifunctional timer capabilities in the actual hardware. This module is mainly used for motor control, time measurement, and PWM output generation. Figure 5 illustrates the FTM module we implemented. Given that our focus was on the time measurement functionality of the FTM, other unrelated features were not included. First, we created a timer object for comparisons which takes the clock source, frequency, compared value, prescale, and continuous mode as input parameters to set up the basic timer. Subsequently, we created an event handler. The comparing timer instance triggers an internal event when it reaches the set compared value, calling the event handler in response. The event handler sets the overflow flag variable to true and calls the interrupt update function. The interrupt update function performs an AND operation on the interrupt enable variable and the overflow flag variable to set the interrupt based on the result. This sets the interrupt when the timer interrupt condition is met and clears it otherwise.

Subsequently, we defined the registers required for configuring the FTM. When defining registers in Renode, field definition methods and callback functions are used to emulate hardware behavior effectively. The field definition methods specify individual bits or bit groups within a register, allowing the definition of single flags, value fields, tagged flags, reserved bits, and others. These methods establish the structure of the registers. Callback functions are APIs that execute specific actions when register values are changed or accessed. The status and control (SC) register is a key register that controls the basic operation of the FTM. The prescale factor selection (PS) bits in SC set the prescale value of the timer. When the value changes, the changeCallback function sets this value in the comparing timer object’s prescale value. The prescale value is calculated as the power of two of the prescale value and divides the input frequency by this value. The clock source selection (CLKS) field allows the selection of the input clock source for the FTM from multiple clock sources. As our system assumes a single simulation clock source, this value is used as the enable field. The changeCallback function sets the timer instance’s enable field to false if the value changes to zero and to true otherwise. The timer overflow interrupt enable (TOIE) field controls the activation of the timer overflow interrupt. When this field value changes, the changeCallback function updates the interrupt enable value accordingly. The timer overflow flag (TOF) is set to true when a timer overflow occurs and to false otherwise. The writeCallback function sets the overflow flag variable based on the value of this field. This field is cleared to false after the timer overflow occurrence ends, and the interrupt update function is applied to clear the interrupt. The CNT register contains the FTM counter value. This register uses only 16 bits, counting from 0 to 65,535 and overflowing back to 0 when its value exceeds 65,535. The writeCallback function initializes the timer object’s counter when a value is written to this register, and the valueProviderCallback function reads the timer object’s counter value when the field is read. The MOD register holds the modulo value of the FTM counter. When the FTM counter reaches the modulo value, the TOF is set at the subsequent clock cycle.

After implementing the FTM, we implemented the SCG. The SCG sets and manages clocks and distributes clock sources. Therefore, in the current vECU which uses a single simulation clock, not all functions need to be implemented. However, if problems arise during execution, these parts must be implemented to ensure the vECU operates correctly. In our system, the AUTOSAR SW driver initialization process checks if the input clock is correctly set before starting the initialization. Our system’s MCAL sets the system clock to the phase locked loop (PLL) clock. Hence, the system PLL valid (SPLLVLD) field in the system PLL control status (SPLLCSR) register must be set for initialization. If this field is zero, the system will execute a checking loop infinitely during initialization. The SPLLVLD field is set when the system PLL clock is enabled and valid. This setting is determined by the operation of the PLL clock in actual hardware. As we do not directly implement the PLL in the Renode environment using a simulation clock, we set the initial value of SPLLVLD to one and confirmed that the system initialization avoided the infinite loop related to the PLL clock. With this hardware configuration, we confirmed that the target software developed in AUTOSAR operates correctly.

Additionally, we implemented the ADC module to handle automated testing input in the vECU. We defined the timer and registers necessary to configure the ADC, including control, status, and result registers. The SC register includes fields such as the ADC channel (ADCH), which selects the input channel, and the conversion complete (COCO) field, which indicates the end of a conversion. The ADC operates by writing the channel to the ADCH field. The ADC conversion process works as follows: when the user inputs sample data or analog values, the sample data or converted digital values from analog values are stored in the channel buffer. When the set timer interrupt occurs, it indicates that the conversion is complete, and the system reads the data stored in the designated channel.

4.3. Debugging Environment for Cloud-Native Development

To utilize the developed vECU in a cloud-native development environment, we leveraged GDB. Renode supports a GDB server’s functionality to facilitate debugging within the emulator. First, it can start a GDB server for a specific core. The command sysbus.cpu0 StartGdbServer PortNumber initiates a GDB server for a specific core at the specified port. This command starts a GDB server for the CPU connected to the sysbus on port PortNumber. This allows developers to investigate issues occurring on a specific core in detail. Second, it can start a GDB server for the entire machine, allowing a comprehensive analysis of the system’s overall operation. The command machine StartGdbServer PortNumber starts a GDB server for the entire machine on the specified port. This enables developers to quickly identify and resolve system-wide issues.

Once the vECU is set up as a server, it can be accessed through a GDB client. There are two ways to connect from the GDB client. One is to connect from a local host server using the command target remote localhost:PortNumber. The other way is to connect from the user’s local machine using the command target remote IpAddress:PortNumber. Each method has its advantages and disadvantages. The former method benefits from minimal network latency as the debugging session occurs on the host server, but it can increase the server load if many developers are connected simultaneously. The latter method separates resources, allowing the server to focus on running the vECU and the GDB server, but it may introduce network latency.

Based on these two methods, we performed a comparative analysis in a vECU environment in Section 5.1. First, under the assumption that multiple developers use the system, we executed a vECU with up to 50 GDB servers running in the background. Then, we connected the GDB client to the local host. The GDB client set a breakpoint at RE1 via a GDB script, and each time the breakpoint was hit, it automatically proceeded using the continue command. We used pidstat to analyze CPU usage, and found that the CPU usage accounted for by the vECU was approximately 94.7%, while the GDB client accounted for about 3.91% of the CPU usage. Next, when the GDB client connected remotely via an IP address from the local machine, the vECU’s resource usage increased to approximately 98.4%, indicating more resources being consumed for the vECU’s operation. We also compared communication performance by measuring the round-trip time (RTT) of communication data between the vECU and the debugger using Wireshark under identical conditions. RTT refers to the time it takes for a data packet to travel from the sender to the receiver and for the acknowledgment to return to the sender in network communication. We measured RTT for 100 packets and calculated the average. When the debugger was run on the server and connected to the vECU local host, the RTT was 0.01 ms, whereas when the debugger was run locally and connected to the vECU via a remote server IP address, the RTT was 0.49 ms, making the former method approximately 50 times faster. However, this difference in speed was imperceptible to users during actual development. Therefore, depending on the available resources of the server or cloud environment, users can configure their debugging environment accordingly. If resources are limited, using a debugger connected locally may offer better performance.

4.4. Automated Testing of the Virtual ECU

Using a vECU not only allows the verification of software as a substitute for the actual ECU but also facilitates the establishment of an automated testing environment to quickly verify outputs for specific inputs. Our proposed vECU also provides such automated testing capabilities. To achieve this, we utilized the Robot Framework [28]. This is an open source framework for software development and test automation, which helps in easily making and executing various test cases using a keyword-driven testing language.

Renode has an embedded Robot Framework server, and when executing robot scripts with the test-dedicated program, it creates a vECU instancs in the background and runs the Robot Framework test engine, connecting it to the vECU instance. Subsequently, the test cases in the robot script are executed sequentially. To perform connected Renode commands in a robot script, the Execute Command keyword is used. This allows the execution of Renode commands in the format Execute Command Renode_Command. A robot script is divided into parts that define keywords and parts that define test cases. Keywords define specific actions like C language functions. By defining actions with specific keyword names in this section, these actions can be initiated in other sections. Test cases determine whether specific variables satisfy certain values, indicating test success or failure.

5. Performance Evaluation

In this section, we evaluated the performance of the proposed AUTOSAR-compatible vECU by comparing it with actual hardware and conducting automated testing to validate the efficiency and accuracy of the vECU. The evaluation metrics focused on the time of the wall clock, the execution order of tasks and REs, and the similarities of execution times. Specifically, we measured the execution times of each task and RE relative to the real hardware to quantitatively analyze how accurately the vECU emulates the real hardware. This comprehensive evaluation assesses the accuracy and efficiency of Renode emulation.

5.1. Evaluation Environments

To evaluate the performance of the Level-4 vECU implemented in Renode, we conducted several experiments comparing the vECU with a actual ECU. Figure 6 shows our experimental setup. The actual ECU used was an evaluation board based on the NXP S32K148. We loaded the target software onto this board and used the Trace32 PowerDebug debugger [29] developed by Lauterbach GmbH for debugging. The vECU experiments were conducted on a server equipped with an AMD EPYC 9354 32-core processor. The system had a total of 256 GB of DDR5 RAM and used an 894 GB NVMe solid-state drive as the main storage. The operating system was Ubuntu 22.04.

First, we connected the Trace32 PowerDebug and the S32K148 evaluation board via JTAG, and then loaded the target binary file developed through Mobilgene onto the board. Afterward, we set breakpoints on tasks or REs and measured the execution time of the actual ECU using the benchmark counter, a tool provided by PowerDebug. This tool measures the number of CPU clock cycles consumed while executing a specific code section or instruction. By multiplying the measured clock cycles by the clock period, which is the inverse of the clock frequency, we calculated the wall-clock time interval between tasks or RE executions. Next, we created a new machine through the Renode platform description file for the vECU, loaded the target binary file, and ran the vECU. After setting up the GDB server port number on the vECU and executing it, we launched arm-none-eabi-gdb, a GDB specialized for ARM Cortex-M series, and connected it to the vECU’s GDB server via local host. Similarly, we set breakpoints on tasks or REs and measured the time interval between executions by invoking the Renode command CurrentTime. Since CurrentTime calculates time using the vECU’s internal clock source and clock frequency, the measured time represents the simulation time.

We used the four tasks and five REs configured in Section 3 for the experiments. The details of these tasks and REs are as follows:

• T1: 10 ms periodic task (OsTask_ASW_10ms).
• T2: 50 ms periodic task (OsTask_ASW_50ms).
• T3: Data received event task (OsTask_ASW_DRE).
• T4: Trigger occurred event task (OsTask_ASW_TOE).
• RE1: RE that reads the switch and sends the data through DSP every 10 ms.
• RE2: RE that toggles LED1 based on the received switch data.
• RE3: RE that increments a counter and triggers another entity every 10 ms.
• RE4: RE that executes when triggered by another entity.
• RE5: RE that toggles LED2 every 50 ms.
• RE6: RE that reads the analog or sampled input and send the data through DSP every 10 ms.
• RE7: RE that sets LED3–LED6 based on the received ADC data.

5.2. Wall Clock

Measuring wall clock time is crucial to evaluate the performance of the vECU, as it indicates the actual time expended for the simulation. The wall clock time varies based on the performance of the hardware running the simulator. We use wall clock measurements to evaluate and analyze the execution speed of the Level-4 vECU based on Renode.

Renode logs include actual timestamps. We executed T1 100 times and extracted the logs containing the current time to calculate the time differences between consecutive calls of T1. The average time difference between task calls was approximately 11.4 ms, and the time differences consistently ranged between 10 ms and 12 ms.

5.3. Execution Order Accuracy

We assessed the execution accuracy of the vECU by comparing the execution order of tasks and REs with those on the actual ECU. This evaluation verifies the reliability and predictability of the vECU, determining whether it can replace actual hardware during development and testing.

Figure 7a,b show the task execution comparison between the actual ECU and the vECU. Tasks activated by alarms are first initiated based on the SetRelAlarm function configuration. SetRelAlarm sets the AlarmID, Increment, and Cycle parameters, such that the alarm expires after Increment ticks and continues to expire at Cycle intervals. In our system, Increment was set to one, causing T1 and T2 to be initiated after a one tick increase in the OS counter. Subsequently, the T1 task and the T3 task, triggered by a DRE caused by the DSP of the RE1 mapped to T1, are initiated sequentially. When 50 ms has elapsed, all tasks are in the ready state simultaneously, and tasks are initiated in order of priority: T1, T4, T2, and T3. This task initiation sequence was identical for both the actual ECU and the vECU. Figure 7c,d show the RE execution comparison between the actual ECU and the vECU. RE1, RE3, and RE6, which are mapped to the same task event, are initiated in sequence, with RE1 executed first followed by RE3 and RE6. When the REs are all in the ready state at 50 ms, they are executed in the order of task priority, namely RE1, RE3, RE6, RE4, RE5, RE2, and RE7. This sequence was also identical for both the actual ECU and the vECU.

5.4. Execution Time Accuracy

Subsequently, we evaluated the accuracy of the vECU’s simulation clock. The simulation clock represents the virtual time within the simulation. This metric examines how closely the simulation clock of tasks and REs in the vECU matches the execution times on the actual ECU. The consistency of execution times is crucial for assessing the real-time performance of the system, verifying the temporal reliability of the vECU, and determining whether it meets the performance requirements in an actual operational environment. The execution time is measured for each task and RE, respectively. The metrics include the average time required to execute the tasks and REs 100 times, the standard deviation values indicating the variability, and the error rate between the actual ECU and the vECU, calculated using Equation (1).

$$\mathrm{Error}\mathrm{Rate}(\%)=\left({\displaystyle \frac{\left|\mathrm{Actual}\mathrm{ECU}\mathrm{Time}-\mathrm{Virtual}\mathrm{ECU}\mathrm{Time}\right|}{\mathrm{Actual}\mathrm{ECU}\mathrm{Time}}}\right)\times 100$$

(1)

The results in

Table 2. Results of task execution time measurement in the actual ECU and vECU.

Task	Actual ECU Time Average (ms)	Actual ECU Time Std Dev (ms)	vECU Time Average (ms)	vECU Time Std Dev (ms)	Average Time Error Rate (%)
T1	9.9978	0.0454	9.9966	0.0014	0.011
T2	49.9902	0.0065	49.9830	0.0084	0.014
T3	9.9985	0.0154	9.9966	0.0097	0.019
T4	49.9896	0.0078	49.9832	0.0081	0.013

and

Table 3. Results of runnable entity execution time measurement in the actual ECU and vECU.

Runnable Entity	Actual ECU Time Average (ms)	Actual ECU Time Std Dev (ms)	vECU Time Average (ms)	vECU Time Std Dev (ms)	Average Time Error Rate (%)
RE1	9.9979	0.0036	9.9967	0.0014	0.013
RE2	9.9986	0.0254	9.9967	0.0121	0.019
RE3	9.9978	0.0035	9.9967	0.0014	0.012
RE4	49.9896	0.0066	49.9828	0.0081	0.013
RE5	49.9897	0.0072	49.9833	0.0084	0.013
RE6	9.9982	0.0083	9.9967	0.0025	0.014
RE7	9.9980	0.0137	9.9968	0.0097	0.012

indicate minimal discrepancies between the actual ECU and the vECU, demonstrating that the vECU can reliably replicate the timing behavior of the actual ECU. The standard deviation values show that the execution times in the vECU are as stable and reliable as those in the actual ECU. Specifically, the standard deviation for T1, T3, RE1, and RE3 in the vECU were lower than those of the actual ECU, indicating more consistent performance. The low error rates of 0.011%, 0.014%, 0.019%, and 0.013% for T1, T2, T3, and T4, respectively, and 0.013%, 0.019%, 0.012%, 0.013%, 0.013%, 0.0014%, and 0.012% for RE1, RE2, RE3, RE4, RE5, RE6, and RE7, respectively, also confirm the high fidelity of the vECU’s simulation clock.

5.5. Automated Testing

5.5.1. Experimental Setup

To evaluate how fast and accurately the proposed vECU performs automated testing, we utilized RE6 and RE7. RE6 processes input data through ADC, creating input cases equivalent to the ADC resolution. RE7 receives ADC data from RE6 and indicates the data range through LED3–6. In other words, with a 12-bit resolution, 4096 input cases can be created, forming 16 sections of size 256. For example, when an ADC input of 256 is received, it falls into the second section, causing LED3–6 to output off, off, on, and off, respectively. We created a test case script that compares the expected output with the actual output when an ADC input is received.

Figure 8 shows the vECU automated testing flow. First, the test case generator (TCGEN) creates the test case scripts. TCGEN automatically generates and stores robot script test cases for each ADC input value, ranging from 0 to 4096. Next, the yaml generator (YAMGEN) lists the test cases for the entire test. YAMGEN randomly selects a specified number of test cases. The vECU tester provides the ability to execute multiple test cases sequentially or in parallel when running the yaml file. At the execution stage, entering an integer with the –jobs option creates that number of processes to handle test cases in parallel. At this point, the test cases can be grouped, with sequential execution within the group and parallel execution between groups. If there are dependencies between test cases, grouping ensures the execution order within the group. Otherwise, it enhances performance by not creating groups and using parallel execution. The Robot Framework creates and initializes the vECU in the background according to the test case script. Next, the Robot Framework initializes the GPIO and inputs the specified ADC sample into the vECU’s ADC. Then, it calculates the expected LED output for the input ADC data and waits until the ADC read is complete. Once the ADC read is complete, it reads the status of LED3–6 and compares it with the expected output. After the test is complete, the results are centrally collected and reflected in the final report.

5.5.2. Experimental Results

We first evaluated the parallel processing performance of the vECU tester. In the experiment, we randomly selected 1024 test cases out of 4096 and measured the execution time and number of false positives when performing automated tests with different numbers of jobs. The results were averaged by running each job 10 times.

Figure 9 shows the experimental results. When the number of jobs was set to 1, the execution was the slowest, with an average time of 2168.23 s. The execution time proportionally decreased as the number of jobs increased. This is because the CPU utilization reached its maximum with that number of parallel processes. We confirmed that at 32 jobs, all 64 CPUs of the experimental server were fully occupied. We confirmed that from 32 jobs onwards, up to 64 CPUs were utilized, and as the number of jobs increased, the duration for which all 64 CPUs were fully occupied became longer. Additionally, false positives began to occur from 40 jobs onwards (0.4 false positives on average) and increased with an increasing number of jobs, reaching 3.8 false positives with 64 jobs. This issue arose because the more parallel processes there were, the slower each test case was processed. The execution speed of the Robot Framework was much slower compared to the vECU, leading to false positives due to delayed reading of the changed LED output.

Next, we measured the execution time, number of false positives, and the number of timeouts as the number of test cases increased, using 32 jobs, which provided the best performance in our testing environment. Although the test case processing was fastest with 40 jobs, false positives occurred, so we set the number of jobs to 32 for the experiment to avoid false positives. Figure 10 shows the test results. The execution time increased proportionally as the number of test cases increased. For instance, with 128 test cases, the average time was 24.82 s, while with 8192 test cases, the average time increased to 1131.80 s. No false positives occurred during these tests. This confirmed that optimal test case processing is possible without errors when using the maximum CPU utilization with 32 jobs.

6. Future Work

After developing and verifying a single vECU, we began to explore the scalability of the vECU. The application of the vECU extends across a wide range from development to testing. Therefore, the vECU must be capable of large-scale simulation. Simulators typically operate based on software and can simulate large parts of a system with relatively fewer resources. Additionally, they are time-modeled, making synchronization between models easier. In contrast, emulators operate more like actual hardware, requiring more computing resources and offering higher time resolution, making them closer to real hardware. However, they are less favorable for simulation scalability compared to simulators because synchronization between models becomes more challenging. As shown in Table 1, as the level of a vECU increases, it begins to adopt more characteristics of an emulator. This indicates that a Level-4 vECU is closer to an emulator, which makes improving simulation scalability more difficult.

We aim to improve the scalability of the Level-4 virtual ECU through two approaches. First, we will focus on synchronizing time between vECUs using the functional mock-up interface (FMI). FMI is a standard interface used in model-based development that allows co-simulation between various simulation tools. It operates by advancing connected models by a predetermined time step, gathering results, and feeding those results as inputs at the start of the next time step. We plan to use this interface to synchronize the timing during communication between vECUs and will explore methods to minimize the overhead that arises during synchronization. Secondly, we will address the issue of resource shortages in large-scale simulations by researching cloud-native simulation. By utilizing cloud orchestrators to allocate resources based on the load of the vECU, we expect to improve the scalability of the vECU.

7. Conclusions

In this paper, we implemented a Level-4 vECU using the Renode emulator and successfully verified that AUTOSAR-based software runs correctly on this platform. We designed and implemented the SWCs according to the AUTOSAR standard. The SWCs, as shown in Figure 3, were designed to operate in both the poposed vECU and the actual hardware, ensuring consistent behavior across both environments. Additionally, we developed custom peripherals using Renode’s C# scripting capabilities to create hardware modules that accurately emulate actual hardware. By implementing the FTM and SCG modules, we ensured proper functionality of the AUTOSAR OS, enhancing the practicality of the AUTOSAR-based vECU. We evaluated the performance of the vECU by comparing it with actual hardware, focusing on the execution order and execution time of tasks and REs. The data showed a close match between the execution order and timing of tasks and REs in the vECU and the actual ECU, with minimal error rates, as presented in Table 2 and Table 3. The results shown in Figure 7 further demonstrate the accuracy of the vECU’s execution order. This level of precision validates the reliability of the vECU for software testing. Furthermore, the vECU tester enabled efficient and accurate automated testing, confirming the potential of the Level-4 vECU to replace actual hardware during both the development and testing phases. The close alignment between the vECU’s performance and actual ECU measurements shows that this tool can significantly contribute to reducing development costs and time while ensuring software stability and reliability.

In conclusion, the Level-4 vECU that utilizes Renode is a powerful tool that enables precise automotive software testing and verification without the need for actual hardware. By leveraging this vECU, developers can accelerate their development processes and reduce the overall costs associated with hardware-based testing. Future work will focus on adding more hardware components, such as communication interfaces like CAN and LIN, and expanding Renode’s capabilities to emulate complex system integration scenarios with greater precision. These improvements will enhance the scalability of the vECU, allowing it to support more diverse and large-scale research and development efforts in the automotive industry.