In the rapidly evolving automotive industry, the hybrid car represents a pivotal advancement toward sustainable mobility, combining internal combustion engines with electric propulsion systems to enhance fuel efficiency and reduce emissions. As a designer and researcher in vehicle engineering, I have focused on addressing the complexities inherent in hybrid car instrumentation, which must integrate and display data from multiple power sources and subsystems. Traditional wiring harnesses in hybrid cars often lead to cumbersome layouts, increased weight, and susceptibility to electromagnetic interference, thereby compromising reliability and real-time performance. To overcome these challenges, I embarked on designing an instrument cluster system leveraging Controller Area Network (CAN) bus technology, which offers a streamlined, efficient, and robust communication framework. This paper details my comprehensive approach—from conceptualization to validation—in developing a CAN-based instrument cluster tailored for hybrid cars, emphasizing hardware and software innovations that ensure cost-effectiveness, real-time data transmission, and modular flexibility. The integration of CAN bus not only simplifies wiring but also fosters a scalable architecture for future hybrid car enhancements, aligning with the industry’s push toward smarter and more connected vehicles.
The instrument cluster in a hybrid car serves as the primary interface for drivers, conveying critical vehicle parameters such as speed, engine RPM, battery state-of-charge (SOC), fuel level, and various warning indicators. In my design, I prioritized a user-centric display that consolidates information from diverse sensors and control units, ensuring clarity and immediacy. The hybrid car, with its dual powertrain, generates data types including analog signals (e.g., temperature and voltage), pulse signals (e.g., wheel speed), and digital switch signals (e.g., light status), all of which must be processed and displayed seamlessly. By adopting CAN bus technology, I aimed to create a system that reduces wiring complexity by up to 70% compared to conventional point-to-point connections, thereby lowering manufacturing costs and enhancing durability. The CAN bus operates at speeds up to 1 Mbps, facilitating rapid data exchange among electronic control units (ECUs) in the hybrid car, which is essential for real-time monitoring and diagnostics. My design philosophy centered on modularity, allowing for easy updates and customization to accommodate different hybrid car models, from mild hybrids to plug-in variants. Throughout this project, I iteratively refined the system to meet stringent automotive standards, such as EMI resistance and temperature tolerance, ensuring reliability across diverse driving conditions.
To structure the instrument cluster, I first defined the functional requirements and display content based on extensive analysis of hybrid car operations. The table below summarizes the key information categories and their respective data types, which guided the overall architecture:
| Category | Displayed Information | Data Signal Type |
|---|---|---|
| Instrument Indicators | Engine RPM, Fuel Gauge, Vehicle Speed, Coolant Temperature | Pulse and Analog Signals |
| LCD Display | Door Status, Time, Total Mileage, Cabin Temperature | Digital and Analog Signals |
| Status LEDs | Fog Lights, Seatbelt, Turn Signals, High/Low Beams | Switch Signals |
| Buzzer Alarms | Door Ajar, Overheating, Low Fuel, Button Feedback | Digital Signals |
| Powertrain Data | Battery SOC (State-of-Charge) | Analog Signals |
These data types necessitated distinct processing modules: analog signals required Analog-to-Digital (A/D) conversion, pulse signals utilized Pulse-Width Modulation (PWM) techniques, and switch signals were managed via General-Purpose Input/Output (GPIO) interfaces. For the hybrid car, I emphasized the battery SOC display as a critical element, given its role in optimizing energy management between the engine and electric motor. The SOC is derived from voltage and current sensors, processed through an A/D converter, and displayed on a dedicated gauge. To ensure accuracy, I implemented a filtering algorithm that averages multiple samples, reducing noise from the hybrid car’s high-voltage system. The overall functional modules of the instrument cluster are outlined below, highlighting their interdependencies:
| Module Name | Function |
|---|---|
| Power Supply Regulation | Stabilizes input voltage (12V to 5V/3.3V) for electronic components |
| A/D Conversion | Converts analog signals (e.g., temperature) to digital values |
| PWM Processing | Filters and counts pulse signals for speed and RPM calculation |
| CAN Communication | Handles data frames and remote frames via CAN bus |
| Switch Signal Control | Drives LEDs for indicators based on digital inputs |
| Servo Control | Precisely positions gauge needles via PWM outputs |
| LCD Display Control | Renders graphics and text on a TFT screen |
| Buzzer Alarm | Generates audible alerts for abnormal conditions |
| Data Storage | Stores mileage and settings in non-volatile memory |
The physical design of the instrument cluster involved creating four analog gauges for speed, RPM, coolant temperature, and battery SOC, complemented by a central LCD for supplementary data. I calibrated each gauge to map sensor ranges to angular displacements of servo motors, ensuring linear and intuitive readings. For instance, the speedometer in the hybrid car covers 0–160 km/h, corresponding to 0–160 degrees of rotation, while the battery SOC gauge spans 0–100% over 0–120 degrees. These relationships are expressed mathematically to facilitate software implementation. The angular position $\theta$ for a given value $x$ can be derived using linear interpolation:
$$ \theta = \theta_{\text{min}} + \frac{(x – x_{\text{min}}) \cdot (\theta_{\text{max}} – \theta_{\text{min}})}{x_{\text{max}} – x_{\text{min}}} $$
where $x_{\text{min}}$ and $x_{\text{max}}$ are the minimum and maximum display values, and $\theta_{\text{min}}$ and $\theta_{\text{max}}$ are the corresponding angles. For the hybrid car’s speedometer, with $x_{\text{min}} = 0 \text{ km/h}$, $x_{\text{max}} = 160 \text{ km/h}$, $\theta_{\text{min}} = 0^\circ$, and $\theta_{\text{max}} = 160^\circ$, the angle for a speed $v$ is:
$$ \theta_v = \frac{v \cdot 160^\circ}{160 \text{ km/h}} = v^\circ \quad \text{(for linear scaling)} $$
Similarly, the battery SOC gauge uses a non-linear scale to emphasize low-charge states, crucial for hybrid car energy management. I defined the SOC mapping as:
$$ \theta_{\text{SOC}} = 120^\circ \cdot \left(1 – e^{-k \cdot \text{SOC}}\right) $$
where $k$ is a constant adjusted for driver visibility. This design ensures that the hybrid car’s vital parameters are displayed with high precision, enhancing situational awareness.
Moving to hardware implementation, I selected components based on performance, cost, and compatibility with the hybrid car’s harsh operating environment. The microcontroller serves as the brain of the system, and after evaluating several options, I chose the STM32F103R6T6 chip for its Cortex-M3 core, 72 MHz clock speed, and integrated peripherals. Its resources, listed below, supported the multifaceted requirements of the hybrid car instrument cluster:
| Resource | Quantity | Application in Hybrid Car |
|---|---|---|
| 12-bit A/D Converter | 2 | Sampling temperature and voltage signals |
| Fast I/O Ports | 51 | Driving LEDs and reading switches |
| CAN 2.0B Controller | 1 | Managing CAN bus communication |
| 16-bit Timers | 3 | Generating PWM for servos and counting pulses |
| SPI Interface | 2 | Connecting to LCD and memory chips |
| USB Interface | 1 | For diagnostics and firmware updates |
The CAN bus node, central to the hybrid car’s network, comprises a controller (bxCAN embedded in the STM32) and a transceiver. I selected the TJA1050 transceiver for its high-speed capability (up to 1 Mbps) and robustness against electromagnetic interference, common in hybrid cars due to high-current traction systems. The TJA1050 features a silent mode for bus monitoring and a high-speed mode for active communication, controlled via its S pin. In my design, I configured it for high-speed operation to ensure real-time data flow. The CAN node’s data flow follows a standardized sequence: sensors generate signals, which are processed by the microcontroller and packaged into CAN frames; the bxCAN controller handles arbitration and error checking, while the TJA1050 drives the physical bus lines (CAN_H and CAN_L). This setup minimizes latency, critical for the hybrid car’s dynamic powertrain adjustments.
Circuit design focused on stability and noise immunity. The power supply circuit converts the hybrid car’s 12V battery voltage to 5V and 3.3V using LM2575 and SP1117 regulators, respectively. I incorporated filtering capacitors (e.g., 100 µF and 10 µF) and a resettable fuse for overcurrent protection, as shown in the 5V regulation stage:
$$ V_{\text{out}} = 5\text{V} \quad \text{with} \quad C_{\text{in}} = 100\mu\text{F}, \quad C_{\text{out}} = 10\mu\text{F}, \quad R_{\text{limit}} = 1\Omega $$
The 3.3V stage further stabilizes voltage for the microcontroller, using a similar topology with additional decoupling capacitors near the STM32. For signal acquisition, I designed separate circuits for analog and pulse inputs. Pulse signals from wheel speed sensors are conditioned through an RC low-pass filter to suppress high-frequency noise, with a cutoff frequency $f_c$ set at 10 kHz:
$$ f_c = \frac{1}{2\pi R C} $$
where $R = 10\text{k}\Omega$ and $C = 1\text{nF}$. The filtered signal is then fed to a timer input for edge counting. Analog signals, such as coolant temperature, pass through a voltage divider and another RC filter before A/D conversion, with the output voltage $V_{\text{out}}$ given by:
$$ V_{\text{out}} = V_{\text{in}} \cdot \frac{R_2}{R_1 + R_2} $$
where $R_1 = 10\text{k}\Omega$ and $R_2 = 2.2\text{k}\Omega$ for a 0–5V range. The CAN interface circuit includes a 120Ω termination resistor between CAN_H and CAN_L to match impedance and prevent signal reflections, essential for the hybrid car’s extended wiring. I laid out the PCB with a four-layer stackup (signal, ground, power, signal) to minimize crosstalk and allocated separate regions for analog and digital components, reducing interference. The final PCB measured 150 mm × 100 mm, hosting all components in a compact form factor suitable for dashboard integration in a hybrid car.
Software development was conducted in the IAR 6.3 environment using C language, emphasizing modularity and real-time responsiveness. The overall structure comprises a main program and several submodules, as illustrated in the flow diagram. Main program initializes peripherals—including clocks, GPIOs, timers, A/D converters, and the bxCAN controller—and enters an infinite loop that polls for events and updates displays. Interrupt service routines (ISRs) handle time-critical tasks, such as pulse counting and CAN frame reception, ensuring the hybrid car’s data is processed with minimal delay. The initialization sequence sets the bxCAN to configuration mode, where bit timing parameters are defined based on the hybrid car’s network speed of 500 kbps. The nominal bit time $t_{\text{bit}}$ is calculated as:
$$ t_{\text{bit}} = \frac{1}{500 \text{ kbps}} = 2 \mu\text{s} $$
with synchronization and propagation segments adjusted for stable communication. After initialization, the bxCAN enters normal mode, enabling message transmission and reception.
Data acquisition modules process sensor inputs differently. For pulse-based signals like vehicle speed, I employed a frequency method, where a timer captures rising edges over a fixed interval $T = 0.2\text{s}$. The speed $v$ in km/h is computed from the pulse count $N$, gear ratio $I_0$, and wheel diameter $D$:
$$ v = \left( \frac{N}{T} \cdot \frac{1}{I_0} \right) \pi D \times 3.6 $$
For a hybrid car with $D = 0.65\text{m}$ and $I_0 = 4.5$, this yields accurate speed updates every 200 ms. Analog signals are sampled at 1 Hz, and I implemented a moving average filter to smooth fluctuations, discarding outliers. The average value $\bar{x}$ over $m$ samples is:
$$ \bar{x} = \frac{1}{m} \sum_{i=1}^{m} x_i $$
with $m = 10$ for parameters like battery SOC. The CAN communication module handles message packaging and parsing. Each CAN frame includes an 11-bit identifier (e.g., 0x100 for door status) and up to 8 data bytes. The bxCAN controller uses three transmit mailboxes and two receive FIFOs to manage traffic, with interrupts triggered on successful transmission or reception. In the hybrid car, I defined a custom protocol for key parameters, as shown below:
| Parameter | CAN ID | Data Byte | Value Range |
|---|---|---|---|
| Door Status | 0x100 | Byte 1 | 0x00 (closed), 0x01 (open) |
| Cabin Temperature | 0x100 | Byte 3 | 0x00–0xFF (–40°C to +100°C) |
| Vehicle Speed | 0x100 | Byte 6 | 0x00–0xFF (0–255 km/h) |
| Battery SOC | 0x200 | Byte 2 | 0x00–0x64 (0–100%) |
The transmission subroutine checks for empty mailboxes, loads data, and sets the transmit request flag. Reception uses filter banks to accept only relevant frames, reducing CPU load. For instance, the hybrid car’s battery SOC messages are filtered by ID 0x200, ensuring efficient processing.
To validate the system, I constructed a test bench emulating a hybrid car’s network. A USB-CAN adapter served as a node simulator, connected to the instrument cluster via a CAN bus cable. Using configuration software, I generated frames corresponding to various driving scenarios—e.g., accelerating to 80 km/h, toggling doors, and varying battery SOC from 50% to 20%. The instrument cluster successfully displayed all parameters on the LCD and gauges, with response times under 50 ms, meeting real-time requirements for a hybrid car. I also conducted stress tests by injecting noise into the bus, observing that the TJA1050’s differential signaling maintained integrity, with no false readings. The validation confirmed that the CAN-based design reduces wiring complexity, as the hybrid car’s dozens of sensors connect through a single twisted-pair cable instead of individual wires. Moreover, the modular software allowed easy addition of new features, such as a tire pressure monitoring system, by simply extending the CAN protocol and adding a display subroutine.
In conclusion, this project demonstrates the efficacy of CAN bus technology for hybrid car instrument clusters. My design achieves a balance of cost, performance, and reliability, with the hybrid car benefiting from simplified wiring, enhanced real-time communication, and robust anti-interference capabilities. The hardware selection, particularly the STM32 microcontroller and TJA1050 transceiver, provides a scalable platform adaptable to various hybrid car architectures, from series to parallel hybrids. Software modularity facilitates future upgrades, such as integrating advanced driver-assistance system (ADAS) alerts via CAN messages. As hybrid cars evolve toward greater electrification and connectivity, this CAN-based instrument cluster offers a foundation for smarter dashboards that can display energy flow, efficiency metrics, and diagnostic data. I envision further research into wireless CAN extensions and AI-driven predictive displays, pushing the boundaries of hybrid car instrumentation. Ultimately, this work underscores the transformative potential of CAN bus in automotive electronics, paving the way for safer, more efficient, and user-friendly hybrid cars.