Newsletters

  • Contact sales

IAV Develops Mass-Production Gaseous-Fuel ECUs Using Model-Based Design

By Ralph Meyer, IAV Group

Extreme fluctuations in gasoline and diesel prices have spurred a demand for powertrain systems that can be converted to use alternative gaseous fuels, such as liquefied petroleum gas (LPG) and compressed natural gas (CNG). Although LPG and CNG are fossil fuels, they are less harmful to the environment than conventional fuels and, in many markets, less expensive.

IAV’s experts have performed more than 6,000 CNG and LPG conversions, making the company Germany’s top aftermarket modifier for these fuels.

IAV recently developed an engine control unit (ECU) that enables virtually any gasoline powertrain to be quickly and inexpensively converted to a bivalent gasoline and gaseous-fuel system without changing the gasoline master controller (Figure 1). Acting as a slave controller, the new ECU can be used with OEM-specific components, such as gas injectors, sensors, and actuators.

iav_main_w.jpg

 

Dashboard instrumentation in a gaseous-fuel vehicle. The signals for actuating the gasoline injectors are first fed to the control unit for the gaseous-fuel drive. A high-precision analysis unit processes the signals and computes the optimum gaseous-fuel injection times. © IAV

iav_fig1_w.gif

 

Figure 1. Diagram of a gaseous-fuel control unit working with a standard gasoline control unit. © IAV. Click on image to see enlarged view.

Engineered at IAV, the ECU will be manufactured and distributed by an IAV partner. Together, we are targeting production in the hundreds of thousands, and will deploy the ECU not only in the U.S. and Europe but also in emerging markets.

A key goal in the design process was to keep down costs and meet tight production deadlines. At the same time, we wanted to maintain design flexibility so that we would be able to make changes once the part is in the field.

Based on IAV’s experience with similar projects in the past, it would typically have required at least three years to develop the ECU for mass production. By using Model-Based Design, we achieved this goal in just 18 months.

Requirements Specification and Handoff

We began by developing and thoroughly reviewing system requirements and their associated test cases. Individual system requirements were then transferred to the project’s five principal work groups: algorithm development, software, testing, electronic hardware, and housing. The development team comprised 50 individuals, about half of whom worked on the controller design and implementation.

Algorithm Development and Production Code Generation

Algorithm developers modeled and simulated ECU components and subsystems in Simulink® and Stateflow®. They used a library of Simulink blocks selected specifically for use with our target processor, a 32-bit Infineon® TriCore® microcontroller with a floating-point unit.

The software group managed the interface between the algorithms and the hardware, and was also responsible for production code generation. All the ECU’s control software was generated using Real-Time Workshop Embedded Coder™. We compiled the generated C code to produce a Flash file for the TriCore processor. Because the code was automatically generated, we were confident that the Flash file would behave in the same way as the Simulink model.

The entire process, from model to production-ready Flash file, was automated. On our team, the build manager was responsible for “Ctrl-B” (the shortcut for invoking Real-Time Workshop®): He made sure that the engineer could press Ctrl-B from within Simulink, go for coffee, and return to find Flash files ready for mass production.

In-Vehicle Testing

We had no access to the master ECU before in-vehicle testing. As a result, we were unable to perform hardware-in-the-loop tests, and could test only 20% of our algorithms before our ECU was used in actual road tests. The remaining 80% of the code had to be tested in the car. Without Model-Based Design, we would have been unable to accommodate this approach because there would have been no time to correct problems found so late in the development process. Model-Based Design not only enabled us to begin in-vehicle testing earlier, it also shortened the test, update, and retest cycle: Working on a laptop in the vehicle, we could make changes to the Simulink model, re-generate the code, and produce a new prototype in as little as 20 minutes.

When in-vehicle testing revealed that incorrect assumptions had been made in defining a specific requirement, we had to change both the requirement and its test case. After the Simulink model was updated to fulfill the new requirements, the entire process of generating code and testing the Flash file was repeated, and the system was documented, approved, and ready for manufacturing within three days.

Documentation and Calibration

Throughout development, our Simulink models served as an executable specification of our design that we could share with IAV engineers in the U.K., the U.S., and Japan. While sharing models is an effective way to communicate between teams within IAV, we could not share internal models with individuals outside the company. For that, we needed clear documentation.

Working with MathWorks consultants, we created an automated documentation system (ADoS) based on Simulink Report Generator™. ADoS produced reports from our models that documented requirements and design specifications. Whenever the team reached a design milestone, we generated a PDF report that contained approximately 1,000 pages of documentation on the ECU, including signal flows, function descriptions, and component characterizations. Calibration engineers used this documentation to understand the behavior of the ECU and to facilitate the in-vehicle calibration of the ECU for use in a particular vehicle. For this purpose, the system provided an interface to common automotive calibration tools such as INCA from ETAS GmbH.

Moving to Production

The new gaseous-fuel slave controller has passed all OEM quality certification requirements, including rigorous verification procedures, such as confirming that the ECU operates correctly at temperatures from -40 to 105 degrees Celsius and checking long-term durability. IAV is ISO 9000 certified, and IAV’s processes are designed to meet Automotive Spice levels. Even with all the activities that needed to be added to the workflow to meet these standards, we completed development of the ECU on schedule—and in about half the industry-average time. The first run of production controllers has been manufactured (Figure 2), and is about to go into full-scale production.

iav_fig2_w.gif

 

Figure 2. The slave ECU in its housing. © IAV

Model-Based Design is the basis for future development efforts at IAV. With the MathWorks tool chain that we have in place, we are adept at building flexible solutions that can be adapted to diverse markets and needs. We are currently working on a high-end version of the ECU that will provide additional functionality, and a low-end, low-cost version with limited functionality suitable for emerging markets.

About IAV

Headquartered in Berlin, Germany, and employing more than 3000 staff across the globe, IAV is one of the leading providers of engineering services to the automotive industry. Our core competencies include powertrain, electronics, and vehicle development. As a result, we can provide our clients with production-ready solutions for the entire vehicle on a one-stop-shop basis. IAV engages in its own primary research, performs its own advanced development activities, and works on an interdisciplinary basis. Our clients include all major automobile manufacturers and component suppliers.

Published 2009 - 91783v00

Receive the latest MATLAB and Simulink technical articles.

Related Resources

Latest Blogs