Control freak

If there is one area of engineering that has simply exploded over the past 30 years or so it is that of control. Where once we had mechanical or electrical devices to manage what few systems were around, these days almost all mechanical systems are controlled by some measure of electronics and computing such that a whole new subject has evolved - that of mechatronics.

In the case of a modern race engine, we are all too familiar with the idea of electronics together with a little help from computing to deliver a superior, more fuel-efficient system with greater levels of reliability. But in many of the aftermarket so-called engine management systems found in motorsports, the degree of this control is somewhat limited.

Promoted because of their user friendliness, these aftermarket systems expose the calibrator to a number of look-up tables and software-toggled settings, which enable the inexperienced to trim the device to the demands of the engine. The look-up tables will invariably consist of fuel maps, ignition timing maps, lambda target maps and temperature correction features that allow the user to fine-tune it the engine to the limits of the system. The inputs and outputs of these will invariably be linked to individual ECU pins, which may or may not be programmable to perform other functions.

Whichever way you look at it, these devices are designed to work in a certain way, and the firmware inside the ECU with its various control algorithms will be fixed and unalterable. The firmware might contain a number of tables or parameters that may be modified to take things such as turbochargers, even multiple injectors per cylinder, but the way in which these work will be more or less fixed according to the installed firmware.

This may be totally acceptable to the amateur, whose primary target might just be to get the engine running in the first place, but to the professional, the control offered by these systems may be somewhat lacking.

At the other end of the spectrum, to introduce a new or revised control algorithm will invariably involve much simulation and testing with third-party software tools. At the prototyping stage, third-party hardware platforms may need to be used with custom software, allowing the simulation to be linked to the real world.

This process will require compilers, assemblers, linkers and, no doubt, even more software. And by this time the team will have expanded to include control engineers, firmware engineers and hardware engineers with enough knowledge and experience across a number of skill sets to deliver a quality product.

Needless to say, ECU development at this level can be very expensive, even assuming the appropriate software licence can be obtained. Is it no wonder therefore that with some vehicle manufacturers, the powertrain electronic management department can often dwarf the engine and transmission mechanical departments combined.

The ideal approach, and one that is now offered by EngineLab in the US, is to enable the engineer to focus totally on the algorithm development and carry out all the work within the production hardware platform. In tightly coupling the firmware to the Host Console application on the host PC, unnecessary complexity can be avoided and once the prototyping is complete, the job is finished.

Referred to as the EngineLab Machine, the architecture is built on a real-time operating system and presents a simple application development interface to the control system designer. Not requiring any further compilers, assemblers or firmware development, the control algorithms are developed directly onto the production-based hardware. Indeed, the equipment as purchased doesn't contain any fixed-function behaviour model, the entire control system being downloaded to the system via the host PC.

Described more as a general control system than a fixed-function engine controller but at aftermarket-type costs, this could begin a trend for future high-level engine control systems.

Written by John Coxon