Innovative Cost-Effective Embedded System to Enhance ECU Firmware Quality Through Remote Hybrid Testing in Automotive Domain

Abstract

This paper addresses the challenge of ensuring quality control for electronic control units (ECUs) in the automotive industry. Traditional hardware-in-the-loop (HIL) systems, used for software quality assurance, are costly and not always readily available, leading to potential delays in software verification and release. This paper investigates the factors causing these delays and proposes process task workflow optimization using a hybrid testing approach. This approach allows software developers to conduct early integration and system testing for embedded software, complementing the formal validation stage. To support this, the paper presents a novel piece of test equipment called TestBench, which utilizes inexpensive embedded hardware like the Arduino Mega2560, which can carry out the fundamental tasks needed to test the ECU. TestBench enables local testing, remote accessibility, and the monitoring of key parameters, including voltage current consumption, and the communication bus. It also facilitates fault injection for the evaluation of communication protocol robustness. By enabling earlier and more frequent testing, TestBench aims to enhance the quality of software developer outputs and the overall quality of ECU-embedded software. The system has the potential to significantly improve the testing process, making advanced testing capabilities more accessible and cost-effective for engineering teams and educational institutions.

1. Introduction

The automotive industry has experienced a substantial transformation in the testing of electronic control units (ECUs), particularly with the introduction of automated testing systems. Hardware-in-the-loop (HIL) simulation is a prominent approach that enables the real-time testing of ECUs by simulating their operational environments. This approach improves the overall accuracy of testing and minimizes human errors by increasing the efficacy of testing and reducing the dependence on manual processes. HIL testing is essential for the evaluation of the reliability and safety of automotive systems, as it enables the evaluation of a variety of ECU functionalities under controlled conditions [1].

The transition to automated testing systems is further bolstered by developments in software tools developed for ECU testing. The utilization of frameworks such as ECU-Test has been emphasized for its capacity to optimize testing procedures and improve the dependability of software validation in automotive contexts. These technologies are essential in handling the complex software in modern cars, where many ECUs communicate using various protocols [2].

A primary advantage of HIL modeling is its cost effectiveness. It facilitates the swift prototyping and evaluation of intricate automotive systems, which is essential due to the increasing complexity of contemporary vehicles that integrate multiple electronic components and embedded software systems [3]. The ability to recreate diverse settings and scenarios in a controlled setting substantially diminishes the time and resources needed for physical testing, consequently decreasing the overall development expenses [4]. HIL simulation enhances the building of resilient embedded software by enabling the early detection and correction of errors during the design phase. Methods like real-time fault injection might be incorporated into HIL frameworks to replicate abnormal conditions, thus guaranteeing that the software can manage unforeseen scenarios proficiently [5].

Hardware-in-the-Loop (HIL) simulation integrates real hardware components within a closed-loop virtual environment, enabling the realistic testing of control systems while reducing the development time, cost, and risk of hardware damage. It has become a standard approach in industries such as automotives, aerospace, and power electronics for the validation of embedded systems under real-time conditions [6].

The automobile sector has progressively embraced the capabilities of cost-effective testing systems employing Arduino platforms for the testing of ECUs in engineering centers. These systems provide a versatile and economical solution for diverse testing applications, covering the development, calibration, and validation of ECUs.

Arduino platforms are distinguished by their open-source architectures, which enable straightforward programming and integration with diverse sensors and components. This adaptability enables engineers to tailor testing configurations to particular specifications, rendering Arduino devices a compelling choice for the development of economical ECUs. Syaka et al. illustrated the design and functionality of an Arduino-based ECU prototype for a two-stroke spark ignition engine, highlighting its durability and versatility for experimental applications [7]. Furthermore, the cost-effective nature of Arduino systems substantially diminishes the financial obstacles for engineering institutes, facilitating more comprehensive testing and experimentation. Dewatama’s study on the efficacy of the Arduino Uno demonstrates the platform’s capacity to manage diverse jobs well, which is crucial for real-time ECU testing [8]. In addition, the research conducted by Komarizadehasl et al. on an economical system for assessing structural vibrations illustrates the cost effectiveness and precision of Arduino-based solutions, which can be modified for automotive applications [9]. This affordability is essential in a sector where testing expenses can rapidly increase, facilitating more frequent and comprehensive testing cycles.

Although primarily focused on IoT-based monitoring, a study shows that the Arduino Uno R4 provides real-time data acquisition and system interaction, which can be extended to emulate HIL principles for preliminary testing. Its ability to monitor and control physical systems in real time suggests that Arduino-based setups can serve as simplified HIL solutions for the validation of embedded systems before full-scale testing [10].

The Arduino Mega 2560 can be integrated into a real-time HIL environment as a cost-effective alternative for the implementation of intelligent control strategies. It has been highlighted that Arduino devices, combined with a host PC, enable low-cost hardware-in-the-loop testing for automotive applications, validating control algorithms under realistic conditions without expensive HIL platforms [11].

Despite the benefits, obstacles persist in the execution of Arduino-based systems for ECU testing. The amalgamation of these systems with current vehicle testing frameworks necessitates the meticulous evaluation of compatibility and performance measures. Hellhake et al.’s research on black-box integration testing underscores the necessity of stringent testing methodologies to comprehensively validate the interactions among numerous ECUs [12]. Moreover, the intricacy of present-day automotive systems, as described by Englisch et al., necessitates advanced testing environments capable of supporting the varied functionalities of ECUs [13]. Consequently, although Arduino devices provide an economical option, it is essential to ensure that these systems comply with industry standards for reliability and performance.

2. The Need for a Simple Test Device

Although HIL testing gives a necessary environment for the validation of automotive electronic control units (ECUs), the V model presents a disciplined framework for managing the whole development lifecycle and integrates HIL as the main verification and validation tool inside this process. From a management standpoint, the V model uses HIL testing to methodically lower risks and raise product quality throughout the development process. Including HIL in the V model helps project managers to ensure that testing fits the stages of development, thus producing more consistent results.

Verification and validation techniques are also of critical importance. Both verification, which assesses whether the developed product fulfills the specified requirements, and validation, which determines whether the requirements accurately and comprehensively reflect the customer’s expectations, are crucial. HIL testing, which integrates real and virtual components in a simulation, plays a crucial part in verification processes. Verification should be performed regularly, which, along with comprehensive system tests, contributes to an evolutionary development process [14].

The V cycle is the essential methodology for the development of electrical devices within the automobile sector [15].

Figure 1 depicts a streamlined representation of this cycle. The development process commences at the top right with the specifications and requirements of the new product. The diagram is segmented vertically into three tiers: the system level, module level, and component level. The product is generally categorized into mechanical, electronic (hardware), and software components at the module and component levels. After the specification and requirement definition phase, each mechanical, hardware, and software component is subjected to horizontal implementation and validation. Upon completion of the development and implementation phases, situated in the upper-right corner, the product reaches the prototype stage, primed for production. The left branch of the V model includes the research, design, and development activities of the product across several stages of its maturity. In contrast, the right branch of the letter V encompasses testing, validation, and proof-of-concept operations. Every phase on the left branch must align horizontally with the testing and validation operations on the right branch.

Rigorous testing is crucial to validate the accuracy of the simplified model’s validation. For example, the authors in [16] state that real-world experiments involving tire–road interactions are necessary to compare simulated results with actual measurements.

Automotive organizations are advised to employ the Agile methodology to enhance the development processes of embedded software in ECUs, utilizing the product life cycle (PLC) phases aligned with the V model. In Agile software development, the tasks of software engineers concerning embedded software from electronic control units are carried out in sprints. A sprint is structured with a biweekly cycle for optimization. The component-level activities in the V module, related to the development of embedded software, as described by the authors in [15], may be incorporated into a series of sprints. Typically, the tasks for the creation of the embedded software (also called firmware—FW) are delegated by the project manager, software tester, or even a software developer to another software developer.

They perform the implementations and then deliver the developed software to the software tester for an evaluation of the changes. Figure 2a presents the typical workflow of an embedded software task as specified above.

The implementation and testing of a task can occur inside a single sprint or span multiple sprints. Moreover, many tasks may be accomplished within the same sprint, contingent upon their complexity.

If the software tester engineer concludes that the firmware does not meet the specifications, they return it to the software developer for the analysis and repair of the bugs in the firmware. If the firmware is satisfactory, the implementations are integrated into the final firmware. Figure 2a depicts the flow and implementation duration at each stage of the procedure. For the software developer, usually, a new implementation typically requires an average of 1 to 2 days.

The software tester engineer checks the firmware implementations on the hardware-in-the-loop testing system.

Owing to its considerable complexity, the hardware-in-the-loop (HIL) test equipment is a costly investment, priced between EUR 100,000 and 200,000. Consequently, such equipment is limited in comparison to the variety of items developed. Typically, there is one hardware-in-the-loop (HIL) system for each product type at each original equipment manufacturer (OEM), leading to restricted availability for diverse software implementations. Each hardware-in-the-loop (HIL) system is custom-built and tailored to the hardware configuration of the ECU that it is intended to test. Another cost-determining factor is the testing environment: either in development centers (HIL) or in production for individual ECU testing on the assembly line (EOL—end of line or final test). Testing a production ECU from the central body controller (CBC) class requires a highly complex HIL system capable of managing a large number of ECU inputs and outputs. In 2010, the cost of such a system configured for an ECU with 59 inputs and 98 outputs was EUR 110,000, of which the switching component (fault insertion relay matrix) alone accounted for EUR 42,000.

A dSPACE HIL system intended for R&D applications, specifically for ECUs controlling vehicle suspensions (with significantly fewer inputs and outputs than a CBC), reached a cost of EUR 160,000 by 2025, with the switching component (fault insertion relay matrix) exceeding EUR 90,000.

Proactive preparation is essential to secure access to this costly equipment. The access duration may range from one day to several days in such instances.

If the firmware evaluated on the HIL fails to match the required criteria, the test engineer will return it to the software developer for the fixing of these issues. Repairing them requires many hours, after which the firmware is returned again to the test engineer for verification on the HIL. The attempts to implement, test, fail, and rectify are illustrated in Figure 2a as “attempts: i”, where “i” is the number of iterations required to modify the firmware until it meets the specified requirements.

The postponement in providing the firmware to the end customer is directly correlated with the number of iterations “i”. The number of iterations is directly proportional to the expertise of the firmware development engineers. The insufficient number of IT engineers in the market leads them to migrate to organizations offering superior compensation, while those who remain in the automobile sector as embedded software developers (firmware) typically lack sufficient expertise, as they are predominantly recent graduates. This is a primary reason that numerous “i” iterations (“trial and error”) are essential. Upon acquiring sufficient experience over several years, they relocate to other organizations.

The time periods depicted in Figure 2a are as follows:

• T1: The implementation/development timeframe of a task by the software developer. The duration may range from several hours to several days, dependent upon the task’s complexity.
• T2: The period during which the HIL test system is anticipated to be accessible to the tester developer engineer. The duration may range from one day to several days, contingent upon the HIL’s load. It is essential to consider that firmware development involves teams of engineers concurrently creating various software components. The output of each firmware development engineer must undergo testing on the hardware-in-the-loop (HIL) system. The access time to the HIL is contingent upon the number of firmware developers and the volume of their implementation tasks.
• T3: The time necessary for the software test engineer to evaluate the firmware. This duration typically spans several hours.
• T4: The period for fixing the firmware by the software engineer. Usually, this takes from 1 to 2 h.

It is important to note that a period for the comprehensive testing of the firmware occurs prior to its release to the final consumer. This process requires one day.

In the current era of constant change, a contributing aspect is the expenses associated with implementing improvements, resulting from the proliferation of poor-quality goods and associated complaints. The major objective of modern innovative organization to reduce the period and expenses associated with change implementation [17].

The authors of [4] performed a survey that indicated the proficiency of engineers in the development or testing of embedded software for the automobile sector. It is allocated as follows: 35.7% have 0 to 3 years of experience, 28.6% have 3 to 5 years of experience, 14.3% possess 5 to 10 years of experience, and 21.4% possess above 10 years of experience in the area.

3. Hybrid Testing

To reduce the number of “i” iterations in the firmware testing part, Figure 2b proposes a process change wherein the software developer checks the minimum functionality of the implementations locally on their workstation. In contrast to the SW tester, who performs activities on the HIL, the SW developer, responsible for implementing the firmware directly on the ECU, typically conducts work at their office, where a local bench is accessible at their desk. As a result, the firmware developer can carry out a further procedure step at his office, which is local testing. The additional testing time is indicated in Figure 2b with (T5), and it is the amount of time that the firmware developer spends testing his implementations and changes locally on the ECU. As a result, the FW/SW developer receives the number of iterations “i” from the HIL (hard-to-reach equipment).

To comprehend the distinctions between the two workflow strategies illustrated in Figure 2, it is essential to pay attention to the example provided in

Table 1. Comparison between current workflow and optimized workflow.

Task State	SW Activity [Hours]	Current Workflow [Hours]	Optimized Workflow [Hours]
SW developer (T1)	Implementation time	2 days = 16 h	2 days = 16 h
SW tester (T2 + T3)	Waiting + testing time	3 days + 2 h = 26 h	3 days + 2 h = 26 h
Attempts (i)		3	3
SW developer (T4)	Bug fix time	2 h	2 h
SW developer (T5)	Test time	-	1 h
Total hours spent formula		T1 + i × (T2 + T3) + (i − 1) × T4 (1)	T1 + i × (T4 + T5) + (T2 + T3) (2)
Total hours spent		98 h	51 h

.

The following example is taken:

• The software developer requires 2 days (T1) to implement the software, followed by 2 h (T4) to fix the error;
• Testing the implemented changes in the software on the local bench requires one hour (T5);
• The software tester requires three days (T2) to obtain the hardware-in-the-loop (HIL) and then two hours (T3) to perform software testing;
• The cumulative count of software correction efforts is three, denoted by (i).

After three cycles of firmware patching by the developer, according to the traditional procedure, the maximum time to complete the task is 98 h. When the processes are followed in the optimized or “hybrid” workflow, the time required to finalize the task after the same number of iterations is 51 h.

In order to clarify the advantages provided by the optimized procedure,

Table 2. Workflow durations from 1 to 10 different attempts.

Attempts (i)	Traditional Workflow [Hours]	Optimized Workflow [Hours]	Attempts	Traditional Workflow [Hours]	Optimized Workflow [Hours]
1	42	45	6	182	60
2	70	48	7	210	63
3	98	51	8	238	66
4	126	54	9	266	69
5	154	57	10	294	72

presents ten scenarios with attempt counts ranging from 1 to 10. The durations of the traditional and improved workflows in Table 2 were computed based on the values in Table 1.

Figure 3 shows graphically the two scenarios presented in Table 2.

Figure 4 presents an alternative graphical interpretation of Table 2.

In Figure 4 and Table 2, it can be better observed that, only for one case, when the total number of iterations is 1 (one), the duration of the traditional workflow is 3 h shorter than the duration of the optimized workflow. This assumes that the firmware deployment runs smoothly on the first try. This applies only if the firmware developer is an expert with more than 10 years of experience. As the authors of [4] pointed out, the number of experts is relatively limited in this field, at less than 21.4%. For this category of programmers (experts), the optimized workflow does not bring a significant benefit, yielding a delay of 3 h.

However, for the predominant types of programmers, this newly optimized methodology is excellent. An increased number of iterations results in enhanced time efficiency. This is most effectively observed through the examination of Figure 4.

For the current workflow, with three bug fix attempts, the total implementation and testing time is 98 h, about 12 days, or about 2 and a half weeks. For the optimized workflow, the total implementation and testing time with three bug fix attempts is about 6 days, or about a week and a day. This clearly shows the need to use the local bench at the SW developer’s office for the minimal testing of the implemented SW and bug fixes.

Due to the limited experience of some software developers, the software products that they create—although free of compilation errors and, in principle, eligible for ECU testing within an HIL environment—may fail to execute correctly on the microcontroller. In practice, execution on the ECU microcontroller can become blocked (hang) for various reasons, such as multiple task activation (MTA), the occurrence of faults within the memory protection fault class, or the improper functioning of communication over CAN or FlexRay buses.

4. TestBench

The local bench in the developer space can be relocated to a designated area equipped with a computer for remote connectivity. The proposed equipment, called “TestBench”, for the verification of firmware at a remote workbench, contains the following devices:

• ECU under test (EUT);
• Power supply that supplies the ECU with electricity;
• Debugger for debugging embedded SW running in the ECU;
• ISOK (K-line) programmer that facilitates the downloading of SW into the ECU;
• Vector VN box device (Vector Informatik GmbH, Stuttgart, Germany) that allows monitoring and injects messages into the ECU’s CAN/FR/LIN communication bus;
• Switching relay, or fault insertion relays, for the interconnection of the abovementioned elements.

The present authors propose a concept for an embedded system, referred to as TestBench, designed to enable the basic management of all equipment required for the rapid preliminary verification of the embedded software capabilities on the ECU.

The objective of this research is to identify and implement a simple and cost-effective technical solution to test the basic functionality of embedded software on the ECU. The underlying idea is to avoid occupying the HIL system with defective software that can be preliminarily verified in a straightforward manner—by checking whether the software starts on the ECU using TestBench and communicates correctly over the CAN/FlexRay bus.

Bogdan et al. [18] demonstrated that open-source hardware platforms, such as Arduino platforms, can be integrated into remote testing architectures for ECU systems, being employed to control relays that enable circuit isolation and reconnection. This solution, applied in the context of optimizing AUTOSAR communication for ADAS, provides flexibility and cost efficiency, confirming the industry trend toward using programmable microcontrollers in distributed testing procedures.

4.1. Embedded Test System Hardware

The architectural overview of the proposed embedded system for ECU testing is illustrated in Figure 5.

In simple terms, every embedded system, as depicted in the embedded test system in Figure 5 (A1), comprises the following:

• A microcontroller (MCU);
• Input circuits;
• Output circuits.

In this instance, an input signal conditioning board serves as the input element in the embedded system. This board’s function is to adjust the electrical signals’ amplitudes when they are applied to the microcontroller MCU’s analog inputs. The signals applied to the embedded system’s input must be lowered to a maximum amplitude of 5 volts, as the MCU can only handle signals with this amplitude. Resistive dividers that linearly alter the input signal’s form serve as the signal conditioning board.

Relay boards, frequently referred to as “fault insertion relays”, comprise the embedded system’s output elements. They are used to apply power signals or power supplies or disturb inputs to the ECU. The command from the MCU and, typically, the electrical energy from the voltage source (“power supply” in Figure 5 (A2)) serve as the input elements to this fault injection board.

The EUT (ECU under test) is the ECU that the embedded test system (ETS) is testing, and it can be found in Figure 5 (A3). The signal conditioning board allows the ETS to monitor the voltages at the EUT connections. The goal of this monitoring is—if possible—to measure the voltages on each electrical connection from the ECU using a device like a voltmeter.

The EUT is energized by the power supply seen in Figure 5 (A2) through the fault injection board involving relays. This board can transmit electricity from the source to the KL30, KL31, KL30_P, and KL15 power lines. The relay board can potentially short-circuit or terminate the electrical connection from the EUT.

The power supply should ideally be controlled by the MCU. The MCU must simultaneously always monitor the power supply condition. The embedded test system is handled via the control interface by a computer.

The main requirements that TestBench must meet are the following:

• Control and monitor the electrical power supply;
• Manage various power supply models;
• Closely and precisely measure the current consumption of the EUT;
• Introduce a minimum of fault injection into the EUT;
• Control the power supply of the Lauterbach debug equipment through the HW device;
• Control the K-line programming interface of the EUT via the HW device connected to its power supply;
• Monitor the communication activity on the bus of the ECU.

According to the concepts illustrated in Figure 5 and the requirements mentioned above, a block diagram of the TestBench testing system is depicted in Figure 6.

Upon analyzing Figure 6, it becomes obvious that a computer is required to oversee the operations of the test equipment. This computer does not have to be identical to the one utilized by the firmware development engineer. A computer may be specifically designated for this function.

This “TestBench” system, equipped with a dedicated computer, facilitates remote operation, enabling other members of the software development team engaged in the same project to use it for firmware testing on the identical physical ECU.

The benefits of the shared TestBench are as follows:

• It offers a designated physical location for TestBench equipment.
• The comprehensive embedded testing system may be completely managed from a computer by using the “Remote Desktop Connection” feature in the Windows operating system. This removes the need for third-party software.
• It allows remote access by other software developers, facilitating remote mobile work. This benefit was highly valued during the COVID-19 pandemic, as the software development process and its testing could continue.
• It offers equipment with significantly reduced costs (EUR 200 for TestBench hardware) compared to a hardware-in-the-loop (HIL), which contains expensive devices used to validate software developer duties at just 5–10% of its potential.

TestBench has, as its central core, the Arduino Mega 2560 board, which is equipped with the 8-bit ATmega2560 microcontroller, running at 16 MHz, from Microchip (Chandler, AZ, USA). As can be seen from the block diagram shown in Figure 6, TestBench controls four types of additional electronic boards: the shunt board, the digital-to-analog converter (DAC) board, the relay board, and the ADC board.

The block diagram in Figure 6 shows the derivations (in blue) linked to the power supply paths (marked in red) to the ECU. These blue connections serve to track the voltages at several ECU circuit locations. The ADC board receives the electrical signals, which then are applied to the signal conditioning interface.

The power supply is controlled in two ways by TestBench. The adjustment of the power supply output voltage is performed remotely through its analog input control port (“Control”) through the DAC board from TestBench. The general control of the power supply is achieved through its digital input port (“ON/OFF”), which receives a digital signal from the relay board through the “K9” switch from TestBench. The output voltage and current of the power supply are monitored on the analog output signals “Imon” and “Umon” and are applied through the ADC board in TestBench.

The power supply supplies energy to the ECU through the power lines “PS+” and “PS-”. The power line “PS-” is directly connected to the KL31 terminal on the ECU. In contrast, the “PS+” line is connected in series with a digital shunt to measure the current consumption of the ECU. This digital shunt is implemented through the shunt board. The power line “PS+” is distributed to the KL15, KL30, and KL30_P terminals through the switches K3, K1, and K2, which are implemented in the relay board. Each of these power lines from the ECU is monitored by measuring the electrical voltages through the ADC board. Moreover, the voltages on the ECU outputs are measured through the same ADC board.

To introduce faults on the controller area network (CAN) and/or FlexRay (FR) communication bus, K6, K7, and K8 (from the relay board) were inserted at the communication line between the ECU and the VN device. K performs the bus short function, K7 sets the CANL line to “PS+”, and K8 sets the CANH line to “PS-”.

K4 provides the power supply to the K-line converter. It was necessary to disconnect the power supply of this device because it can introduce errors in the measurement of the current consumption from the ECU when it is in sleep mode.

K5 guarantees the interruption of the 7.5 V power supply to the Lauterbach debugger. There are instances when the “Trace32” graphical interface from the remote computer becomes unusable due to the debugger entering an error mode, requiring a remote hardware reset. This can only be accomplished by disconnecting the power supply from the debugger for several seconds.

The DAC board, shown in Figure 6, comprises the “MCP4725 PICtail” board manufactured by Microchip [19]. The active component is the MCP4725 integrated circuit, a 12-bit digital-to-analog converter (DAC). The communication interface with TestBench uses the I2C communication bus. In TestBench, the DAC board serves the purpose of regulating the output voltage of the power supply.

The shunt board, presented in Figure 6, is implemented by the Adafruit INA260 electronic board from Adafruit, a manufacturer of electronic boards for Arduino platforms [20]. The INA260 integrated circuit, produced by Texas Instruments, Dallas, TX, USA, is a shunt capable of handling up to 15 Amperes with a 16-bit resolution, offering a shunt resolution of 1.25 mA [21]. Similar to the DAC board, the shunt board interfaces with TestBench via the same I2C communication bus. This board is installed between the power supply and the ECU to precisely measure the current consumption of the EUT. The ECU’s operational mode, either sleep or awake, is determined by the measured current.

The relay board, shown in Figure 6, comprises a board featuring eight relays, each equipped with 10-Ampere contacts, activated by a coil driven at 5 V. The board type is OKY3015 from the electronic components manufacturer Okystar [22]. The OKY3015 operates on a supply voltage of 5 V, reducing the need for an independent power source. This is powered directly from the Arduino’s supply voltage via the USB connector of the remote computer. The current limit through the relay contacts K1, K2, and K3 is sufficiently high to avoid jeopardizing the power terminals of the EUT. The maximum total current recorded at the power supply typically did not surpass 1.5 Amperes, as the EUT had no loads attached to its outputs.

The ADC board is mostly utilized to measure voltages at the EUT terminals (KL15, KL30, KL30_P, and OUT1.N), in addition to monitoring the power supply (“Imon” and “Umon”), the general power supply line “PS+”, and the supply voltage from the K-line converter.

Figure 7 presents the pin configuration of the Arduino Mega 2560 connections used by TestBench and designated for each board.

From Figure 7, it can be observed that the connectors J3 and J6, located on the left side of the figure and marked in blue, are assigned to the ADC ports. From the 16 available ADC channels, seven are used. These are linked to the signal conditioning board, and their purpose is to modify the electrical signals from excessive voltages (12–14 V) from the power supply and EUT to the ADC input ports of the ATmega2560 microcontroller, which cannot handle signals over 5 V.

The J7 connector located at the bottom serves as the interface to the Arduino’s digital ports. The digital pins marked in orange, i.e., 22 to 29, have been configured as outputs and allocated to the eight channels associated with the relay board, from K1 to K8. Pin 30 is designated for the ON/OFF control of the power supply.

Pins 20 and 21, from the J5 connector, highlighted in light green, are used for the I2C communication interface. This communication bus facilitates the control of the shunt board and DAC board.

Figure 8 shows TestBench in its prototype layout. The Arduino Mega 2560 board, DAC board, signal conditioning board, and relay board were attached to a support plate composed of epoxy glass composite material.

A plate, named the “panel interface connection”, was attached over the relay board, incorporating connectors for interfacing with the power supply, EUT, and Vector VN device. The shunt board and the connector for control and monitoring associated with the power supply were mounted to the signal conditioning board.

The interface connection panel is divided into different areas.

The yellow “EUT connection” space is assigned to the EUT connection on TestBench as follows:

• The EUT power supply is implemented through the red connectors KL30, KL30P, and KL15 and the black KL31 for the ground connection;
• The yellow connector links the K-line communication interface to the EUT.

The red zone, named “power supply input”, connects the power supply output to TestBench via the “PS+” and “PS−” connectors.

A cable connects the “EUT LIN/CAN/FR bus” communication interface to the ECU. The VN device monitors the EUT communication bus through the “Vector VN device LIN/CAN/FR BUS” connector.

The blue “Shunt−” and “Shunt+” connectors indicate that the shunt can be connected anywhere in the circuit. It is recommended to connect it in series with the power supply.

4.2. Embedded Test System Firmware

TestBench runs under a software program, as with any smart device with a microprocessor. To facilitate the fast development of the TestBench firmware via rapid prototyping, the BIOComProP_ECU (Basic Input Output Communication Protocol Platform for ECU) platform from [23] was adopted. BIOComProP_ECU is a dedicated software platform designed to enhance the rapid prototyping of electronic control units (ECUs). It offers a portable and adaptable solution that is compatible with several microcontroller families, hence considerably decreasing the development and implementation time for new ECU applications. Its capacity to diagnose system conditions in real time during various development phases improves the quality and efficiency of fast prototyping procedures for ECUs.

TestBench, with firmware tailored to the BIOComProP_ECU platform, must satisfy a set of criteria to function as a small ECU testing system.

The primary purpose of TestBench is to control switches K1 through K9. The switches link the power supply lines to the EUT, handle power supply management, insert faults into the communication bus between the EUT and VN equipment, and oversee the K-line converter. A significant function is to measure the voltages at the terminals of the EUT. In this manner, feedback is gathered during the operation of the switches.

Furthermore, TestBench must be capable of managing operations with the power supply, including its monitoring. Continuous monitoring of the power supply lines to the EUT and the electric current drained by the EUT is essential. Upon restarting the TestBench system, it is necessary to retrieve the status and operational parameters of the firmware from the EEPROM memory. The EEPROM parameterization is conducted beforehand via the communication module and is overseen by the software application (graphical interface “TestBench SW”) operating on the remote computer.

Figure 9 illustrates the internal architecture of the TestBench firmware, customized for the BIOComProP_ECU platform.

The firmware is split into five main regions, each with particular functions:

• A real-time operating system (RTOS);
• Software application modules (“SW_APP_x”): “FW_APP_iMonitor”, “FW_APP_iMonitor”, and “FW_APP_PS” provide the key features of the firmware, indicating that this is where the algorithmic components of the firmware program are executed;
• A library module “Lib” with the specific libraries “Lib_EEPROM”, “Lib_Shunt”, “Lib_ADC”, “Lib_DAC”, and “Lib_Toggle”;
• Data memory “Dat_ shared”, which facilitates information interchange between the high-level application modules (“SW_APP_x”) and the “Lib” module; the “Data_shared” module stores the project’s global variables;
• A communication module implemented in the form of the “Communication Core”.

Table 3. TestBench firmware requirements.

Nr.	Requirement Description	FW_APP_iMonitor	FW_APP_vMonitor	FW_APP_PS	Communication Core	Lib_EEPROM	Lib_Shunt	Lib_ADC	Lib_DAC	Lib_Toggle	Data Shared
1	Activation and deactivation of switches K1–K9.				x					x
2	Activation or deactivation for a defined timeframe.				x					x
3	Injection of faults into the communication bus.				x					x
4	Voltage measurement at the terminals of the equipment under test (EUT).		x		x			x			x
5	Measurement of the current consumption from the shunt.	x			x		x				x
6	Cyclic monitoring of the voltages at the EUT terminals.		x					x			x
7	Cyclic monitoring of the current consumption from the shunt.	x					x				x
8	Digital control of the power supply’s ON/OFF functionality.			x	x					x
9	Analog control of the power supply.			x	x				x
10	Digital control for the activation or deactivation of a power source for a predetermined duration and specified number of cycles.			x						x
11	Analog control including a predetermined waveform and several cycles of the power supply.			x					x
12	Monitoring the current consumption, safeguarding the power supply and the equipment under test (EUT) during a short circuit, and notifying the graphical interface.	x		x	x		x		x	x	x
13	Fast cache retrieval of voltage and current consumption data subsequent to periodic monitoring.	x	x		x						x
14	Preserving and reinstating system state parameters during shutdown and startup.	x	x	x		x					x
15	Reading and writing system parameters from/to EEPROM.				x	x
16	Reading and writing traceability data from/to EEPROM.				x	x

summarizes the basic requirements indicated above, as well as additional requirements resulting from the interaction between the firmware modules and applications, as illustrated in Figure 9.

The first two columns provide the number and description of the requirements, while the following ten columns show the selected firmware applications in brown and the firmware modules (libraries) in blue that are involved in fulfilling these requirements.

The “Data_shared” module holds together the information stored as variables exchanged across firmware applications. In the firmware architecture in Figure 9, it is marked in green.

The “Lib” package includes firmware modules that interface between the firmware applications “FW_APP_x” and “low-level” access to the microcontroller’s hardware.

The “Lib_Toggle” library provides access to the microcontroller’s digital lines. The digital lines used by TestBench are described in Section 4.1 (Figure 7) and are mapped to the J7 connector. The digital lines control the closing and opening of the switches K1–K9.

The “Lib_DAC” library is used for the analog control of the EUT’s power supply. The “Lib_DAC” firmware interface controls the digital-to-analog converter provided by the MCP4725 electronic module via the I2C communication bus. The “Lib_DAC” library can also control various electronic modules that convert data from digital to analog. The purpose of this library is to provide uniform access mechanisms for firmware applications to digital-to-analog conversion.

The “Lib_ADC” library provides access to the analog lines of the microcontroller’s analog-to-digital converter. The ADC lines are used to measure the voltages of the EUT wires. The first eight ADC lines are mapped on connector J3, while the remaining eight are mapped on connector J6.

The library “Lib_Shunt” allows firmware applications to measure current consumption using the shunt. The INA260 electronic module is used as a shunt in TestBench. This is managed by the same I2C communication module used by the DAC, i.e., MCP4725.

The “Lib_EEPROM” library controls how information is written to or read from the non-volatile EEPROM memory. The EEPROM memory can be physically included in a chip (integrated circuit), separate from the microcontroller, with communication between the two carried out via the I2C bus; incorporated into the microcontroller based on its internal structure; or emulated in the microcontroller’s FLASH memory.

The firmware application “FW_APP_iMonitor” measures the consumption current using the “Lib_Shunt” library and stores the values in global variables inside “Data_shared”. The “Communication Core” module allows to read the current value in real time using the graphical interface from a computer.

The firmware program “FW_APP_vMonitor” obtains voltages from EUT terminals using the “Lib_ADC” library and stores them in global variables in “Data_shared”. The “Communication Core” module allows the immediate voltage value to be read via the graphical interface from a computer.

The firmware program “FW_APP_PS” handles the power supply’s operating mode. It uses the “Lib_DAC” library to adjust the power supply’s output voltage and the “Lib_Toggle” library to regulate the power supply’s ON/OFF state. The firmware application also adjusts and reads the power supply parameters via the “Communication Core” module in response to the “TestBench SW” graphical interface’s requests.

The real-time operating system (RTOS) schedules and executes tasks at predefined time intervals. In essence, the RTOS manages firmware applications. Each of them contains a loop function that is called by the RTOS.

Every 10 milliseconds, the RTOS activates the task “Task_Com_UART_RX_10ms()”. This task directly calls the communication module “Communication Core” via the main reception method “Com_UART_RX_10ms()”. The purpose of this function is to continuously monitor communication with a computer via the serial port in order to supervise the embedded TestBench system.

The RTOS triggers the task “Task_App_vMonitor_02s()” every 200 milliseconds. This task calls the main function “App_Loop__iMonitor()” in the firmware application FW_APP_iMonitor. This function is responsible for periodically monitoring (every 200 milliseconds) the consumption current traveling via the INA260 shunt.

The RTOS triggers the task “Task_App_vMonitor_02s()” every 200 milliseconds. This task calls the main function “App_Loop__vMonitor()” in the firmware application FW_APP_vMonitor. The purpose of this function is to periodically monitor (every 200 milliseconds) the voltages present on the Arduino’s J5 and J6 connectors.

The RTOS triggers the task “Task_App_PS_02s()” every 200 milliseconds. This task calls the main function “App_Loop__PowerSupply()” in the firmware application FW_APP_PS. This function manages the power supply mode using the Lib_DAC and Lib_Toggle libraries.

4.3. Embedded Test System Software

The graphical interface controlling the hardware component of TestBench is depicted with minimal features in Figure 10. At the center of Figure 10 (B1), the graphical user interface (GUI) serves as a visual representation of the switches that facilitate the transmission of electrical signals to the EUT, while simultaneously monitoring the electrical voltages at the EUT’s terminals.

In the upper-left corner of the graphical interface is the “Power Supply” section, which regulates the power supply, as depicted in Figure 10 (B2). The “Set OUT Voltage” button transmits a command voltage via the DAC converter to the power supply, ensuring that the output voltage at the source terminals PS− and PS+ matches the value predetermined in the graphical interface. The “Umon” voltage and “Imon” current from the power supply behind the control connector are measured by the signal conditioning board, subsequently applied to the ADC lines, and ultimately shown in the designated “Power Supply” section of the graphical interface.

The GUI performs as an authentic human–machine interface (HMI). The switches from the TestBench block diagram are illustrated on the left side of Figure 10 (B3, C4) and at the bottom of Figure 1 (B5).

The switches K1, K3, and K2, which provide electrical power to the EUT via the power lines KL30, KL15, and KL30_P, depicted on the left side of Figure 10 (B3), are illustrated in the graphical interface as the graphic objects “Relay 1”, “Relay 3”, and “Relay 2”. Every visual object in the “Relay x” class is allocated a graphic box that displays the voltage at the switch terminals.

The K5 switch in section (d) is included inside the same graphic object class “Relay 5”, despite its function of supplying power to the Lauterbach debugger.

A distinct category is the graphic object “BUS fault”. It handles the faults introduced into the CAN/FR/LIN communication bus using switches K6, K7, and K8 in area (e). The “BUS fault” object has been altered in comparison to the “Relay x” object, eliminating the need for voltage display while potentially incorporating temporal control of the fault injection duration on the communication bus.

The design of the graphical user interface contributes to the comprehension of the management of the TestBench embedded system.

4.4. Communication Protocol

The connection between the GUI, operating on the remote computer, and the TestBench hardware (Arduino) is facilitated by the BIOComProP communication protocol, wherein the exchanged messages are structured as 8-byte request–response packets, as presented in Figure 11.

The BIOComProP communication protocol provides harmony between the graphical user interface (TestBench SW) and the physical device TestBench HW, which is built on the BIOComProP_ECU firmware platform. It has many other applications, described in [23], such as the following:

• A weather station (IoT project);
• A hydro-electric turbine linearly unfolded on the streams [24];
• A portable hydro-electric turbine with deformable paddles [25];
• A computer chair with an active principle of spine relaxation [26].

This communication protocol allows control from the PC to an embedded system through dedicated commands divided into fixed frames of 8 bytes each. The message sent from the PC (TestBench SW) to the TestBench HW is called “Request”, and it either requests information from the device or controls an actuation element. The device receives the command, processes (executes) it, and then sends a message (response) to the PC with the requested results or confirmation of the action task. The software module that is responsible for the implementation of communication in the TestBench firmware is the “Communication Core”, and it is shown in Figure 9, on the right side.

The BIOComProP communication protocol is similar to the Unified Diagnostic Services (UDS) utilized for diagnosing ECUs in the automotive industry. UDS is used to access diagnostic data from ECUs, particularly for retrieving vehicle state information. However, a paper [27] notes that UDS access is often limited due to OEM restrictions, which motivated the development of alternative methods like the BIOComProP protocol.

Table 4. Commands implemented in TestBench.

Command Description	Nr	Direction	#0	#1	#2	#3	#4	#5	#6	#7
Set relay, i.e., “Write Port X bit”	1	PC -> TestBench	x10	xB2	CH	x00	State	x00	x00	x00
	2	PC <- TestBench	x50	xB2	CH	x00	State	x00	x00	x00
Get relay state, i.e., “Read Port X bit”	3	PC -> TestBench	x11	xB2	CH	x00	x00	x00	x00	x00
	4	PC <- TestBench	x51	xB2	CH	x00	State	x00	x00	x00
Read voltage, i.e., “Read Port ADC”	5	PC -> TestBench	x11	x05	CH	x00	x00	x00	x00	x00
	6	PC <- TestBench	x51	x05	CH	Data MSB	Data LSB	x00	x00	x00
Set voltage, i.e., “Write Port DAC”	7	PC -> TestBench	x10	x08	CH	Data MSB	Data LSB	x00	x00	x00
	8	PC <- TestBench	x50	x08	CH	Data MSB	Data LSB	x00	x00	x00
Read shunt	9	PC -> TestBench	x11	x0F	CH	x00	x00	x00	x00	x00
	10	PC <- TestBench	x51	x0F	CH	Data MSB	Data LSB	x00	x00	x00
Write EEPROM	11	PC -> TestBench	x30	x02	Addr MSB	Addr LSB	Data	x00	x00	x00
	12	PC <- TestBench	x70	x02	Addr MSB	Addr LSB	Data	x00	x00	x00
Read EEPROM	13	PC -> TestBench	x31	x02	Addr MSB	Addr LSB	x00	x00	x00	x00
	14	PC <- TestBench	x71	x02	Addr MSB	Addr LSB	Data	x00	x00	x00

shows the most common commands from the BIOComProP communication protocol that are used here to control the TestBench HW. The communication protocol uses a total of seven commands, divided equally into request and response frames. Columns #0 to #7, in Table 4, represent the messages sent from the PC to TestBench and back.

The first byte of the command (#0) represents the type of request. For the response returned from TestBench to the PC, #0 always has the value + 0x40, which complies with the UDS standard.

The second byte of the command (#1) represents the function that TestBench must perform. For the writing or reading of a digital channel, #1 has the value 0xB2. For the reading of an ADC channel, #1 is assigned the value 0x05. To write an analog value in the MCP4725 DAC converter, #1 receives a value of 0x08. To read the value of the current from the INA260 shunt, #1 receives the value 0x0F. Finally, for the reading and writing of the EEPROM memory, #1 takes the value 0x02.

For example, Lines 1 and 2 in the table correspond to the command Set Relay or “Write Port X bit”, with the function of activating or deactivating relays K1–K9.

In the graphical interface (Figure 10), when relay K1 is activated, the command 0x10, 0xB2, “CH”, 0x00, “State”, 0x00, 0x00, 0x00 is sent.

“State” has the value 0x01 for relay activation; for its deactivation, it has the value 0x00.

“CH” is the number of the relay that must be activated/deactivated. In this case, for relay 1 (KL30), CH receives the value 22 + 0, where 22 represents the digital channel number (see Figure 7), and 0 represents the number of relay K1, as it is mapped to the digital port. The command for activating the K1 relay (KL30) becomes 0x10, 0xB2, 0x22, 0x00, 0x01, 0x00, 0x00, 0x00. TestBench receives the command, executes it, activates relay K1, and sends the response 0x50, 0xB2, 0x22, 0x00, 0x01, 0x00, 0x00, 0x00 back to the PC.

The access of the “Communication Core” module from the TestBench firmware to digital channels 22–30, for the actuation of relays K1–K9, is achieved through the “Lib_Toggle” library, as shown in Figure 9.

Immediately after the transmission of the request to activate relay K1, a secondary request is dispatched to measure the voltage at terminal KL30. The request to read the electrical voltage is located in Line 5 in Table 4, while the response from TestBench is in Line 6. Byte #2 (CH) corresponds to the ADC channel, whereas bytes #3 and #4 represent the values of the electrical voltage measured after the “signal conditioning board” and prior to the ADC channel input. Bytes #3 and #4 comprise a 16-bit variable, with Byte #3 representing the most significant byte (MSB) and Byte #4 representing the least significant byte (LSB). The algorithm for reading from the ADC port and converting the result into a digital voltage is implemented in the TestBench firmware via the “Lib_ADC” library.

For instance, in the same case, for KL30, to measure the voltage from the KL30 terminal, byte #2 (CH) is assigned the value 0x02, where 2 corresponds to the ADC channel A2 designated for KL30 in the “Voltage Measurements” section in Figure 7. The request transmitted from the graphical interface to TestBench is 0x11, 0x05, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00. Upon processing the request, TestBench executes the ADC measurement and transmits the response to the PC: 0x51, 0x05, 0x02, 0x04, 0xCE, 0x00, 0x00, 0x00. By isolating bytes #3 and #4, a 16-bit value of 0x04CE can be extracted, which is represented in millivolts. The decimal conversion results in 1230, which, when translated from millivolts to volts, results in a value of 12.30 V, and this is displayed in the graphical user interface.

5. Results and Discussion

The TestBench test system, along with the associated equipment and the EUT, as depicted in the block diagram in Figure 6, occupies a rather confined physical space, covering an area of less than 1 m². The TestBench test system primarily targets embedded software developers who are not involved in the implementation of sensors and actuators. It is aimed at communication stack (ComStack) engineers within the AUTomotive Open System Architecture (AUTOSAR).

Modern vehicles increasingly require advanced communication frameworks capable of managing the varied demands of different driving situations, passenger entertainment, and safety-critical systems. The AUTOSAR communication stack enables developers to effectively control data flows and ensure system reliability, promoting advancements in automotive technology and improving safety and performance measures [28].

To prove the robustness of the firmware from the ECU under test, the TestBench test system has mechanisms to introduce faults into the communication bus, and the link from the EUT to the sensors and actuators is absent. K6, K7, and K8 were designed exclusively for ComStack software developers to induce faults into the communication bus and assess the robustness of the software that implements the ComStack component.

The evaluated ECU is not “error-free”. This is advantageous since it significantly diminishes the footprint of the TestBench test system, eliminating the necessity of sensors and actuators that occupy physical space.

Figure 12 depicts a test bench built with the TestBench concept test system, intended for an ECU under test developed for embedded software within a mechatronic braking system.

The remote test bench, depicted in Figure 12, comprises a programmable power supply (in this case, analog), at least one Vector VN device for communication with the EUT, the EUT itself, the Lauterbach debugger, and the indispensable TestBench that oversees all devices.

The TestBench serves an additional advantageous purpose in the analysis of complaints received from the end customer. Problem reports are typically accompanied by log traces from the communication bus. The logs are imported into the test bench on the remote PC using the CANoe/CANalyzer software. Afterwards, the firmware version reported by the customer is loaded into the EUT, and the investigation is started. Figure 13 illustrates a screenshot obtained during the analysis phase of a problem report.

Zone C1 and zone C2 are components of the CANalyzer software, involved in displaying communication events on the bus. Zone C1 highlights the messages and signals transmitted over the FlexRay communication bus, while zone C2 provides a graphical representation of these signals. Zone C2 allows for the more detailed and enhanced observation of non-conformities. Zone C3, as depicted in Figure 13, is associated with the Trace32 software, utilized to manage the source code execution of the Lauterbach debugger. This selected window in zone C3 displays software variables, which are updated in real time in accordance with the current status of the embedded software within the EUT.

The TestBench control software can be found in zone C4. Remote monitoring indicates that the power supply delivers 12.3 V to the EUT, with current consumption of 442 mA. In this window (zone C4), a voltage measurement of 12.3V is observed at the EUT power terminal (KL30), indicating that relay 1 is active. Additionally, a voltage of the same value is present at KL15 via relay 2. The power supply for the Lauterbach debugger is provided via relay 5.

The TestBench test system aims to enable testing from a software functionality perspective rather than an electronic perspective. The accuracy of the voltage readings from terminals KL30, KL15, KL30_P, PS+, and VBAT_K-line is not critical; nevertheless, the feedback following the actuation of relays K1 through K9 is significant. This feedback is crucial for the software developer conducting remote tests on the EUT, as it informs them of the operational status of switches K1 through K9.

The essential steps in performing basic verification of the embedded software on the ECU are as follows:

• The embedded software engineer establishes a connection to the bench hosting the ECU under evaluation via remote desktop connection and launches the graphical user interface (GUI) (see Figure 10).
• The ECU is powered through the activation of relays K1, K3, and K2, while its current consumption is visually monitored for a short period to ensure proper operating conditions. Typically, the current does not exceed 500 mA.
• To download the software onto the microcontroller, relay K4 is closed to supply power to the USB–K-line interface. Using dedicated software tools, the compiled software, from the embedded software engineer, is then flashed into the ECU’s microcontroller. Initiating the download process requires the triggering of Bootloader execution on the ECU, which involves resetting the microcontroller by briefly interrupting and restoring its power supply. This is achieved by pressing the “Reset Pulse” button. Normally, the entire programming process takes only a few minutes.
• The debugger is activated by closing relay K5, after which the Trace32 graphical interface is launched and the corresponding software symbols to be monitored are loaded. Software execution on the microcontroller is started via Trace32. Sensitive variables are observed in the watch window, such as task counters and other critical parameters relevant to the new software version under verification (see Figure 13, C3). If the counters fail to increment, this indicates severe software issues (bugs), and the software must be returned to the developer for correction. This stage corresponds to T4 in Figure 2b.
• If all previous steps are successful, a RestBus simulation is executed using CANoe or CANalyzer. At this stage, the signals transmitted by the ECU are monitored (see Figure 13, C2). Any inconsistencies or missing signals require reversion to stage T4 in Figure 2b. Conversely, if all checks are satisfactory, the software is transferred to the HIL system for final testing. At this point, the likelihood of non-compliance is significantly reduced, and the number of “test fail” loops between the software developer and tester is minimized.

The primary functions that TestBench can perform are as follows:

• EUT ON/OFF by switching remote ON/OFF, fast reset, and digital auto-sequence generation for the power supply;
• Manual or automatic waveform generation by controlling the variable voltage output of the power supply;
• Control of the EUT operation mode (sleep, normal) by stimulating the ignition line (KL15) ON/OFF;
• Monitoring of the status of the EUT operation mode (sleep, normal) by measuring the EUT current consumption and EUT output voltages;
• Voltage measurements on the EUT outputs using the spare ADC channels from the Arduino board;
• Fault injection on the communication bus LIN/CAN/FlexRay (bus short), either permanent or pulse.

The decision to use Arduino is due to its capabilities for rapid prototyping and its compatibility with pre-assembled boards, enabling a plug-and-play experience. The affordability of hardware boards, along with the drivers accessible within the Arduino ecosystem, renders TestBench a versatile device, adaptable to the BIOComProP software platform.

After a period following the introduction of the TestBench testing system, it was observed, in the case of junior employees, that the time in which they developed their professional skills, analytical thinking, and technical expertise had decreased. The time required to resolve firmware implementations and then perform testing at the bench was significantly reduced, thus contributing to the accumulation of technical experience for younger colleagues. It is thus found that TestBench is not only a technical tool for the solution of problems but also contributes to learning.

6. Conclusions

The development and implementation of the TestBench system represent a significant advancement in the testing and validation of embedded software for automotive ECUs. By integrating a cost-effective, flexible, and efficient testing solution, TestBench addresses several critical challenges faced by software developers in the automotive industry.

The introduction of a hybrid testing approach, where initial testing is conducted locally before utilizing HIL systems, optimizes the workflow of development for embedded software. This approach reduces the number of iterations required to achieve functional firmware, thereby decreasing the overall development time and costs. The TestBench system significantly reduces the time required for the testing and debugging of firmware by switching from local testing at the developer’s desk to remote testing on a bench zone. This minimizes the dependency on expensive and limited HIL systems, thereby accelerating the development cycle.

The ability to control and monitor TestBench remotely enhances its flexibility for developers, allowing them to perform testing and debugging from various locations. This feature proved particularly valuable during the COVID-19 pandemic, supporting continuous development despite physical restrictions.

Utilizing affordable hardware components such as the Arduino Mega 2560 and associated boards, TestBench provides a budget-friendly alternative to traditional HIL systems.

Both systems provide ECU power supply capabilities, and both TestBench and the HIL platform can inject faults into the communication bus. Additionally, each system is equipped with the Lauterbach debugger, which is used to monitor software execution on the ECU microcontroller via the specialized Trace32 graphical interface. Furthermore, both systems include the necessary hardware components for performing RestBus simulations, utilizing the graphical interfaces of Vector CANoe/CANalyzer applications to manage communication with the ECU. Both platforms also employ the USB–K-line interface for ECU reprogramming with software versions delivered by embedded software developers. However, TestBench does not incorporate the specific modeling capabilities of an HIL system or the relay matrix required for comprehensive fault injection across all ECU inputs and outputs. This limitation is irrelevant to its intended purpose, as TestBench is not designed to replace the HIL system but rather to provide preliminary verification of software execution within the microcontroller, ensuring that it runs correctly and without deadlocks.

The TestBench system exemplifies how innovative approaches can transform traditional testing methodologies, making them more efficient, cost-effective, and accessible. By addressing the specific needs of embedded software developers in the automotive industry, TestBench not only enhances the quality of software but also contributes to the overall advancement of automotive technology.