Automotive VCU validation
Development of a Compact Hardware-in-the-Loop Platform
End-to-end development of a flexible and compact hardware-in-the-loop (HiL) system from requirements definition and electrical architecture through component selection, schematic and PCB design, prototyping, bring-up, and debugging.
VALIDATED DESIGN
Role
Electronics Hardware Engineer
Company
Renco GmbH — Germany
Period
March 2026 - September 2026
Problem
The company needed a faster and more automated way to validate embedded software on its VCUs. Several employees may need to test VCU software at the same time, and sharing three validation systems among four validation engineers and five software engineers creates waiting time and limits parallel development. The long-term objective is therefore to provide one validation platform per employee.
Commercial Hardware-in-the-Loop systems provide the required functionality, but purchasing several systems is not financially realistic. In addition to the hardware cost, these systems generally require dedicated software licences. The company therefore needed an internal platform that covers its three main VCUs without requiring a hardware modification when switching between test configurations.
Core requirements
- Cost-effective enough to deploy at multiple employee workstations.
- Compact, easy to transport by hand, and simple to install and operate.
- Suitable for fast and automated embedded-software validation.
- Compatible with the electrical and communication requirements of the company's three main VCUs.
- Configurable through CAN, LIN, Ethernet, or USART without manual hardware changes.
- Powered from the grid without requiring an external laboratory supply.
- Extendable so additional functions and interfaces can be added later.
Solution
I developed a compact Hardware-in-the-Loop platform designed for individual use at an engineer's workstation. It can be transported by hand, installed directly on a desk, and fully configured through software.
The system is designed to cover all the I/O and functions of the company's three VCUs, with additional capacity for external devices such as sensors and other ECUs.
The objective is to deploy identical units across the engineering team so employees can develop and validate VCU software in parallel without the delays, cost, and licensing constraints associated with multiple commercial HiL systems.
Platform capabilities
- Enough analog and digital I/O channels to fully cover the company's three VCUs.
- PWM signal generation and measurement.
- CAN, CAN FD, LIN, Ethernet, SPI, USART, and I²C interfaces.
- Compatible with both 12 V and 24 V systems.
- Software-configurable pull-up and pull-down selection.
- An extensible architecture that supports additional functions and interface boards.
Method
Step 1 — Requirements definition
I collected and structured the validation requirements for the company's three target VCUs. This included signal types, channel counts, voltage and current levels, PWM capabilities, communication interfaces, power supply requirements, physical constraints, and future extension needs.
I then created a high-level system diagram in draw.io showing the processing architecture and all required driver blocks, with the requirements for each block documented directly in the diagram.


Step 2 — Driver and microcontroller selection
I selected the main components based on the required digital and analog signal channels and their performance requirements, as well as the necessary PWM, timer and communication interfaces, processing performance, electrical specifications, availability, and cost.
A dual-STM32F407ZGT7 architecture was selected because one microcontroller did not provide enough pins, timers, and peripheral resources for the complete system. I selected the principal interface drivers, fixed the first detailed architecture, and prepared a preliminary BOM estimate to verify the cost direction.

Step 3 — Schematic design
I created the first complete schematic in Altium Designer using the selected microcontrollers, interface drivers, and communication components. Placeholder passive components were initially used around the main drivers so the circuit architecture could be defined before every value and reference was fixed.
I used hierarchical sheets, repeated functional blocks, multi-channel structures, harnesses, buses, reusable circuits, and centralized component-parameter management. I then sized and selected the remaining filters, protection devices, resistors, capacitors, connectors, and supporting components for the complete project.




Step 4 — BOM development and cost control
I developed the BOM in parallel with the schematic using Altium ActiveBOM. Each schematic update was reflected in the cost and sourcing view, allowing me to monitor supplier references, component availability, alternatives, missing parameters, individual component prices, and the resulting total hardware cost.
This continuous process reduces the risk of discovering expensive or unavailable components after the schematic is complete. The BOM remains preliminary and will be finalized after the ongoing circuit validation.

Step 5 — Prototyping and functional validation
I translated the system architecture into dedicated functional prototypes, independently designing the schematics, PCB layouts, and 3D assemblies in Altium Designer. Each prototype was produced to de-risk a representative part of the final HiL platform and to validate the design before full-system integration.
I assembled and soldered the prototype hardware myself, then used an STM32F407G-DISC1 evaluation board as the microcontroller platform for bring-up and functional testing. For every prototype function, I wrote and executed a test plan covering the intended electrical behaviour, firmware interaction, and measurable acceptance criteria.
Through this work, most of the platform’s core functions have been prototyped and fully validated, including digital and analog I/O behaviour, PWM generation and measurement, timing performance, GPIO operation, and peripheral interfaces. The remaining work focuses on integrating the validated functions into the complete HiL platform and verifying their operation together.





Results
The complete system schematic has been delivered to the company with its linked bill of materials (BOM). The design package is supported by a technical design note that documents each functional block, the key engineering decisions, and the associated technical choices.
A dedicated validation note records the prototype test plans, test evidence, results, and current validation status for the functions assessed. A separate state-of-the-art and development-planning note defines the next phase through concept sketches, reference images, milestones, and target dates.
The capability summary below provides a concise view of the platform interfaces, I/O resources, power-control functions, and planned expandability.

