by Bill Cooke
|EngineLab GUI. Source: EngineLab. Click to enlarge.|
EngineLab, a new technology company focused on automotive electronics embedded system design, is planning to revolutionize the engine control business by applying advanced technologies developed for consumer electronics to a vehicle’s Electronic Control Unit (ECU).
The company is especially excited about how this development has the potential to unleash the creativity of innovators with princely visions but pauper budgets by allowing them to monitor and control an engine’s inputs and outputs in real time using a graphical user interface. The company is evaluating producing ECUs for aftermarket tuners (performance and green) as well as licensing their technology to Tier 1s and OEMs.
Our goal from the onset was to create the most generic, flexible and accurate approach to control system development. The EngineLab Machine is an application independent control system that can be applied to drive any technology that would require integration.—Jim Vito, chairman and CEO of EngineLab
Background on today’s engine development. Today’s ECUs are built around microcontrollers (MCUs) that are almost always five years out of date. OEMs source the MCU for a particular model several years prior to production, meaning the microcontroller is already a few years old at the time of the car's start of production.
Migrating to a new MCU is expensive in terms of development, testing and validation time, so OEMs tend to stretch the lifespan of their MCUs as far as possible.
By focusing on aftermarket applications for vehicles already developed and by avoiding legacy software, EngineLab hopes to have an ECU on the market with an advanced microprocessor a year before any OEM vehicles.
Legacy microprocessors become a serious issue when you examine the software development process. The process starts with a systems engineer’s view of how a vehicle should function. The operating systems of the legacy microprocessors are too basic to support any kind of advanced development tools internally so the software has to be developed with an external system called a simulation environment which is a custom combination of hardware and software.
The system engineer uses the simulation environment to create a behavioral model which is a graphical representation of how they want the engine to function. “This environment is expensive and because it is a simulation there will always be issues with accuracy when applied to the real world. Once the design has been simulated at multiple levels and deemed acceptable it must be ported to the actual ECU,” said Vito.
Ideally, porting software to different computer environments that the original design target can be automated. But in the case of automotive software, Vito has learned “only 25-35% of the code is successfully ported automatically, the rest of the code needs to be handled manually.”
There are several shortcomings with this process. The system engineer is several steps removed from the controller. The simulation environment is too expensive—hundreds of thousands of dollars—for anyone aside from automakers and major suppliers to purchase and the entire process takes time and money.
Since only bad things can happen during each step, the entire validation process needs to be repeated once the software has been ported to the microprocessor. All of these issues are barriers to creativity and risk taking and in a recent SAE article describing another path to software improvement, the authors Frank Schirrmeister and Filip Thoen estimated that “50-70% of ECU development cost is due to software.”
The process has been tolerated because the auto industry is a high volume business where a company is willing to invest more money in development for a significantly lower piece price and until recently more capable processors were too expensive for automotive use. The same economic forces that have enabled personal computers, game consoles and high end cell phones to become affordable are now being applied to automotive control electronics and affordable automotive grade microprocessors that can support advanced features are on the horizon.
Next generation engine control. “Innovators don’t want to work in simulated environments, they don’t want to learn about porting and they don’t want to debug assembler code. They want to design and build engines” said Vito. He adds, “The newest generation of microprocessors are poised to support direct model design on the microprocessor’s platform itself.”
EngineLab has developed an architecture that functions as an operating system for control application development, the EngineLab Machine™, for one of these microprocessors and the company is excited about its potential to spur creativity. “The operating system will handle the grunt work in the embedded operating system, hardware device driver development and system resource management allowing innovators to innovate,” said Vito.
The system has two high-speed USB interfaces. One is a communication interface to the Host Console for model development, data visualization, manipulation and logging. A second USB high-speed interface is for a USB Mass storage device for direct on-system logging for on the road data collection at data rates faster and cheaper than anything available in today’s ECUs.
The developer may want to use this capability to collect “interesting” variables not immediately associated with engine performance, like tank pressure for a CNG vehicle or they may want to collect traditional data over a long period of time to help detect intermittent faults. In fact, any data in the ECU—sensor data, output data, or even variables used for internal calculations—can be logged at extremely high data rates, taking full advantage of high speed USB. The “developer” doesn’t need to be part of the new vehicle development process—he or she can be an aftermarket tuner.
All of these features are controlled by a Graphical User Interface (GUI) which would allow the developer to easily add and remove features and manipulate these features without writing computer code.
The developer won’t be limited to look-up tables based on traditional relationships. While today they might be limited to a two dimensional plot of manifold pressure vs. rpm or mass air flow vs. rpm, with EngineLab one can create a two-dimensional plot with any inputs and use the output in any other computation. This unlimited flexibility frees the engineer to focus on core issues, like combustion dynamics, knock sensing, or hybrid or regenerative drive control.