MBD Battery Fan Controller

Created by Luke Cross, Modified on Mon, 17 Oct, 2022 at 12:52 PM by Luke Cross

This case study shows how Embed delivered an ECU development project using their model-based design process and the Embed off-the-shelf components and technology in record time.

The technologies used were:-

  • Model-based development
  • Embed UDS Blockset
  • Freescale Star12 Simulink target package
  • Freescale Star12 hardware component board design

Our customer’s electric vehicle needed a fan to cool the traction battery. However, the fan proved noisy in the vehicle cabin and some intelligence was needed to run the fan at varying speeds to disguise fan noise whenever possible.

With the vehicle project nearing completion and Start-Of-Production (SOP) only a matter of 3 months away, the decision was taken to introduce a new controller to manage the fan speed based on vehicle and battery status over CAN. This enables the fan to be off at low vehicle speeds and low battery temperatures so as to remove the cabin noise whilst also ensuring that the fan is on when needed.

ECU Hardware

To make matters more complicated, the only space available for the fan controller was an internal connector board that could be replaced with the intelligent fan controller. This severely restricted the size of the hardware.

Embed MBD Battery Fan Controller

The ECU hardware development was based on a Freescale Star12 microprocessor using previously developed power supply stages, CAN transceiver stages and IO ports. This modular approach to hardware design sped up development and, by using the simulation capabilities within OrCAD, Embed had the hardware design complete in 3 weeks.

Software Driver Development

Since the Freescale Star12 is well known to Embed we had a micro-controller software abstraction layer available. This needed to be wrapped with an ECU abstraction layer so that the processor IO could be mapped to the board. This then needed to be wrapped with a board-level Simulink Blockset to enable the whole system to be controlled from Simulink.

Once this was complete the first thing dropped into the model was the UDS IO Control for all the IO pins so that diagnostics services could be used to read and write the IO. Using Vector’s CANape tool, Embed had proved the drivers and board from the pin all the way through to the Simulink blocks within a week of getting the board back from the CEM.

Software Functionality Development

The functional software was fully developed in Simulink, where all the features were created as library components and tested offline. This enabled the feature to be proved against the requirements. When the board and Simulink board blocksets were available, the feature libraries were dropped into the board model. The resulting model was then compiled and downloaded to the target. We had the system running within 6 weeks of the project start!

System Qualification testing was done with the Embed UDS blockset again to control the IO of the functional libraries on the target board. This enabled the same tests that were run on the PC to be run using UDS over CAN. This proved the complete functionality of the target against the initial requirements.

This was not the end of the story though, the UDS blockset was again employed to create End-Of-Line tests so that the 1000s of fan controllers could be tested automatically using diagnostic scripts running in Vector’s CANdito tool. The part and serial numbers were also written to NVRAM as part of the process.

All in all a successful project was completed in record time to a fantastic level of quality using the Embed Model-Based Development Process and tools.

 

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article