Embedded platform designed to integrate automotive HMI key-testing systems in production environments.
This project was developed at Preh Portugal as part of my Master’s thesis.
 Real KeytestBox Image |
 3D model of the KeyTestBox enclosure |
- Preview
- Introduction
- Incremental vs Continuous Tests
- Incremental Tests
- Continuous Tests
- Problem Statement
- Solution, Main Goals and Requirements
- Hardware Overview
- Final Hardware
- Software and Tools Used
- Software Overview
- MQTT Commands Implemented
- Tests and Results
- Percepio Tracealyzer Example Snapshot
- Conclusion
- Skills Learned
- Acknowledgements
Automotive HMI, such as climate and central control panels, rely on high-quality tactile feedback. Force–displacement key tests quantify that feel essencially by measuring the relation between applied force and key travel.
Images below display the main components of a key test system
|
|
- The key is pressed by a SMAC linear motor
- Force is measured using a load cell with an amplifier
- Key travel (displacement) is obtained from the SMAC internal encoder
- The Unit Under Test (UUT) sends data via CAN/LIN during the test, such as:
- Key state (pressed / released)
- Lever position or angle (e.g. gear selector tests)
- Selected gear value
- UUT Hall sensors or internal position data
- Other diagnostic or status information
The Force–Displacement curve is the most common way to characterize how a key or button behaves when it is pressed and released. It represents the force applied to the key as a function of its travel (displacement).
Curves differ depending on the type of key being tested. During a test, the key is pressed (force increases) until it reaches a maximum point, and then released. From this curve, mechanical parameters of the key can be extracted:
| Symbol | Description |
|---|---|
| S1 | Displacement at which the key actuates (snap/collapse point). |
| F1 | Actuation force – force required to trigger the snap of the membrane or key mechanism at S1. |
| S2 | Displacement where electrical contact occurs with the PCB. |
| F2 | Contact force – minimum force required to close the electrical contact at S2. |
| F3 | Return force – force at which the electrical contact is released during the return movement. |
| F4 | Force difference between actuation and release states. |
| F5 | Maximum applied force during the test (should not exceed mechanical limits). |
| Ss | Maximum travel / end of mechanical stroke. |
One of the most important metrics derived from this curve is the Snap Ratio (SR), which indicates how strong the tactile feedback is:
- A higher Snap Ratio = stronger tactile feedback (more noticeable “click”).
- A lower Snap Ratio = softer feedback, which may feel smoother but less perceptible.
- Ideal SR values depend on the application.
The flowcharts below provide a simplified comparison between the two testing methods.
The main difference is that in Incremental Tests, the actuator stops at each step to acquire a sample, while in Continuous Tests, the actuator moves without stopping and data is sampled in real time.
 Incremental Test Flowchart |
 Continuous Test Flowchart |
- Force data is acquired by the host PC via a USB Data Acquisition (DAQ) device from National Instruments.
- Position data is acquired by RS232 from the actuator controller
- Key State or info data is acquired through a CAN/LIN-USB converter
- Low cost
- Easier to implement
- low test resolution (low sample density)
- May miss the sampling of the snap point, especially on short-travel keys
- Can fail to meet client requirements
In continuous testing, the actuator moves without stopping, and all signals are sampled in real time. This enables a smoother force–displacement curve and higher data accuracy.
- Force is measured by a load cell and continuously acquired via the DAQ system
- Position (travel) is obtained from the SMAC actuator encoder in real time
- The Unit Under Test (UUT) transmits its state (CAN/LIN), such as key/lever status or sensor values, during movement
- All data is timestamped and saved by the DAQ system for later processing
While this setup delivers high accuracy and resolution, it uses sophisticated hardware and is significantly more expensive.
- High sample density → more precise force–travel curve
- Accurate snap detection
- Faster test execution → important in industrial production environments
- Substantially higher cost due to DAQ modules and synchronization hardware.
In industrial test setups, especially for testing mechanical keys, the most common approach is the incremental test method. This approach is simple and cost-effective, and it can work well in many cases.
However, in several real-world situations, incremental testing is not sufficient or may not work at all. These limitations arise due to the way the test equipment communicates and the type of measurements required:
Many devices under test (UUTs) only report their internal state (e.g., whether a button is pressed or not) when the host explicitly requests the data using a communication protocol like CAN or LIN. This process introduces a delay between the request and the response.
If the actuator is moving during this time (as in a continuous test), by the time the host receives the data, the key is already in a different position, and the measured force has also changed. This causes a mismatch between the key state, position, and force, making the data unreliable.
Given the problem 1, a good solution would be to stop the actuator and only then request the data via CAN or LIN, then wait for the response.
However, as said before, incremental testing has limited resolution. Since the actuator only samples at discrete steps, fast or short events — such as the snap point (a sudden change in force when pressing a key) — may occur between two sample points and go undetected.
This is particularly problematic for short-travel keys, where the full keypress happens in a very small movement range. In such cases, a small number of samples is not enough to capture the key’s behavior accurately.
To solve these problems, test stations often switch to continuous testing, which are significantly more expensive
To overcome the limitations of incremental testing and avoid the high cost of commercial continuous testing systems, a new solution is required — one that enables real-time, synchronized testing without the complexity and price of traditional DAQ systems.
The KeyTestBox is proposed as a low-cost, modular, and reusable platform suitable for production testing environments.
- Real-time acquisition of:
- Force (via load cell)
- Position (via SMAC encoder)
- UUT data (via CAN or LIN protocols)
- 24 VDC power supply
- CAN interface (supports baud rate up to 1 Mbps)
- LIN interface (supports baud rate up to 19 200 bps)
- Ethernet port (10/100 Mbps)
- Two RS232 interfaces
- Minimum of five differential analog inputs (−10 V to +10 V) (Mainly to read the 2 Load Cells but some extra were added)
- Two linear encoder counters
- Microcontroller-based system
- PCB design
- Firmware developed in C
- Start and stop a test routine upon request
- Ability to export the acquired test data
- Capability to execute external commands during the test routine
- Use of the MQTT protocol for communication with the host
- STM32F767VIT6
- LAN8742A
- 2x MAX1032 (ADC)
- MCP2021 (LIN)
- MCP2551 (CAN)
- MAX232 (RS232 Converter)
- STLINK-V3 Debugger SWD
|
Real KeytestBox Image |
3D model of the KeyTestBox enclosure |
PCB Schematic done by me in KiCad PCB Layout was designed by another company
- STM32Cube IDE
- FreeRTOS
- LwIP IP Stack
- Mosquitto MQTT
- Percepio Tracealyzer
Final version used Polling (faster)
The primary test target was a gear shift lever from the UUT shown below. This lever represents one of the most challenging components to test due to several factors:
- The lever travel is approximately 12 mm, much longer than typical pushbuttons (≈ 3 mm).
- Each test cycle includes two snap events in each direction (forward and return).
- The UUT transmits a high volume of CAN data during movement, requiring reliable high-frequency acquisition and synchronization.
The figure highlights the tested lever in red and shows the complete testbench used.
Tests were conducted at various sampling frequencies. The system successfully performed synchronized data acquisition at rates up to 3000 Hz, capturing:
- Force data via load cell
- Position data from the SMAC actuator encoder
- Key state data via CAN from the UUT
This sampling rate proved sufficient for accurate detection of all snap points and detailed force-position profiles.
Increasing the frequency beyond 3000 Hz was not necessary and led to excessive data, which becomes impractical to store locally due to RAM constraints.
All the defined requirements were met. Furthermore, the tests demonstrated that the KeyTestBox platform is fully capable of performing continuous key testing with:
- High-resolution data acquisition up to 3000 Hz
- Data synchronization
- Successful operation even on demanding UUT test cases
The KeyTestBox achieved a cost reduction of approximately 91.75%, lowering the price about 12 times comparing to the other solution
One limitation was the available RAM, which is sufficient for most use cases. However, for UUTs that transmit large volumes of CAN data, it may be necessary to select only the relevant CAN/LIN UUT data to avoid memory overflow.
If full data capture is required, this limitation can easily be addressed by using a microcontroller with more RAM, for example STM32H7 family.
This project provided practical experience in the design and implementation of a cyber-physical embedded system for industrial testing applications.
- Real-Time Embedded Systems
- Cyber-Physical System Design
- Signal and Data Acquisition
- Cost–Performance Trade-Offs
- Embedded C (STM32)
- FreeRTOS task design
- Peripheral integration — SPI, UART, ADC, CAN, LIN, Encoders, Timers
- Networking with LwIP + MQTT
- PCB schematic design (KiCad)
This project was supervised by Hugo Oliveira, Software Team Leader at Preh Portugal.