ECUs
(Image courtesy of Moscat Ingenieria)
Layer cake
Increased requests for orders and capabilities are driving ECU manufacturers to adopt new design, programming and testing practices, as Rory Jackson investigates
It wasn’t so long ago that suppliers of ECUs and other control electronics solutions were in something of a tight spot. Pre-COVID ramp-ups in their customers’ production targets had filled ECU makers’ books with contracts, but the sudden freezes that happened across international shipping made numerous components – particularly anything made from silicon – almost impossible to source.
Entire orders of ECUs and similarly built products were falling through owing to shortages of a single chip type or, in some cases, because distributors would stockpile and price-gouge to the point that a £10 chip could cost anywhere from £50 to £100 (as also happens when conflicts or sudden imposition of tariffs disrupt global trade).
Today, thankfully, the situation is improved, despite ongoing disruptions to international supply chains (as of writing). Additionally, ECU developers have taken great strides to bear supply chain vulnerabilities in mind when designing controllers for a new order. This means both minimising the bill of materials (BOM) and evaluating alternative or backup sources for each part throughout the design and simulation phases, even when practically locked-in with a given chip’s complementary board-mount components and development tools. Modern COTS electronics design software capable of displaying real-time availability and risk metrics for the parts filling a user’s BOM (including supply chain shocks, shipping distances and mineral rarities) have henceforth become mainstays of ECU design engineers’ best practices.
Accordingly, use of highly standardised and thus widely available drivers, MOSFETs and multi-functional integrated circuits (ICs) has proliferated in today’s ECU designs, as have partnerships with expert consultancies specialising in the customisation, procurement and delivery of BOMs that meet ECU makers’ minimum hardware requirements and fit within incipient supply-chain conditions. As a result, ECU developers are once again feeling secure in their supply and growth prospects, to the point of signing and delivering on contracts for thousands of units per year.
(Image courtesy of Power4Flight)
With these workarounds in place, and new silicon foundries and fabricators around the world due to come online and improve accessibility to ICs over the next decade, ECU developers have been able to refocus their attention on several key demand trends that are driving ECU designs to evolve in several noteworthy ways.
Data are big
Engine management systems have gradually become more sophisticated over the past several years, as customers request the ability to track more parameters and control greater numbers of actuators, injectors and other ancillaries on top of whichever basic Alpha-N, speed density or mass air flow type of management strategy is at the ECU’s core.
The need for software to drive these functions is in turn impacting the hardware designs necessary to accommodate them by enabling more tracking and processing of sensor data. This includes a growing proportion of cases where users want to track and record health or performance data parameters for use in predictive maintenance or safety analyses, without necessarily using such data in any real-time engine management capacity.
This means that ECUs must be designed for a higher number of inputs for sensors, and outputs also (as and when the number of control functions increases). The rise of direct injection solutions for enabling heavy fuel operations, for instance, can mean designing ECUs with additional I/Os for controlling the solenoids in air-assisted injection rails.
It can also require ECU hardware that can operate more than one type of injector inside a given engine. For example, a multi-fuel engine might integrate conventional saturated injectors for gasoline operations, as well as low-impedance injectors for when a UAV is flown using heavy fuel.
It follows that greater quantities of flash memory are being placed atop ECU boards to store additional subroutines, such as peak-and-hold injector control or other functionalities relating to new components.
New functionalities then require new tables, to keep sensors and actuators calibrated, furthering the need for board-mount memory both internal and external to the ECU’s central microcontroller, especially given that UAVs are flying ever-longer missions. Even small OEMs less than a few years old are signing series production contracts for UAVs with endurance of 12-24 hours, whose ECUs must track and store as many as 50 different engine parameters (at frequencies from 1 to 10 Hz or more) from take-off to landing, to be downloaded and analysed post-mission.
On top of this, is the need for long-term storage of certain metrics; for instance, a significant number of UAV manufacturers and operators want to keep track of the highest temperature (by CHT, EGT or other sensors) that each of their engines has ever experienced, potentially as a useful predictor of the engine’s remaining lifespan or time until the next overhaul. Similarly, useful long-term maintenance data include running totals of the hours operated, crank rotations and engine start-ups (the last one arguably being the most important, given that an engine is typically most damaged upon start-up owing to lack of lubrication).
(Image courtesy of Orbital UAV)
The total number of UAV companies using such data is low but rising, and by tracking such data and making them available, ECU makers are keeping ahead of the curve and ensuring customers stay on board as they gain aptitude and take active interest in better caring for their engines over the years. Having masses of data for analysis is also useful for development because they can reveal connection or integration mistakes on either the supplier’s or the customer’s part and, hence, point the way to the ideal workaround. Even something as deeply set as a current mismatch between board electronics can be unveiled and fixed through tracking and cross-referencing of different ECU data points. Therefore, those companies engaging with data will retain a wide range of quality advantages in the long run.
Communication breakdown
While high-end ECUs optimised to communicate using PWM and serial buses such as RS-232 are still available, developers are increasingly catering for requests centred around the CAN bus, a trend driven primarily by the rising usage of autopilots and servos designed for CANs over the past few years.
Specifically, DroneCAN has become a hard requirement for many, with a growing count of avionics manufacturers treating it as a de facto standard, which in turn motivates more requests for DroneCAN compatibility in ECUs. Such requests are not minor things, however, because DroneCAN comes with certain difficulties that can take significant programming savvy – and much more than basic DroneCAN support – to overcome.
In a complex UAV integrating many DroneCAN devices, one might find, for instance, faults or failures occurring as reactions to messages entering the CAN bus from the ECU, simply because DroneCAN re-uses certain message types differently depending on the application-specific context (a difficult idiosyncrasy to find outside of suffering a fault or digging into DroneCAN’s source code or interface control document).
A handful of other issues can be caused by DroneCAN’s general lack of interoperability. Typically, DroneCAN tends to interact only with itself owing to the way in which it occupies the entire address space on the bus, meaning that placing a DroneCAN device on the network locks-in almost everything to DroneCAN.
This is driving some ECU makers to program for compatibility with DroneCAN as well as other protocols still used across the UAV space – including PiccoloCAN and a variety of company-specific CAN variations – and across flight controllers, motor-generator controllers and servos. By reading and emulating DroneCAN, ECUs can facilitate continued autonomous engine management and throttle control by the autopilot after a UAV manufacturer switches over to a DroneCAN-based flight computer and engine servo.
Enabling such capabilities is not easy, and is often the reason that communications end up forming the bulk of ECU software development time (that, plus the perennial fact that there are always new devices carrying new protocols that vehicle integrators want to plug into the network, mandating new comms code). Arguably, the best guarantor of portability from one CAN standard to the next is using a general-purpose comms library, based on C-code and functionally indifferent to the byte order or bandwidth of the machine with which it’s interacting.
Developing highly interoperable ECUs will benefit when using a descriptive language to generate code covering the three fundamental bodies of code associated with communications. These are ‘receive/decode’ functions, for taking bits from a wire and turning them into data in the memory, ‘send’ functions for turning data in the memory into bits on a wire, and ‘documentation’ for explaining to others how the former two work, so that they can write compatible code from their end for communicating with the ECU.
Failing to keep these three consistent with each other is generally when bugs arise. Hence, having a single automated tool to help develop them with similar logic helps greatly – one example being the open-source tool and project ProtoGen, which is used by a multitude of ECU and avionics programmers across UAV systems, as well as ProtoBuffs by Google and the well-known MAVLink library.
(Image courtesy of Performance Electronics)
Beyond these, it is increasingly commonplace for ECU developers to program communications protocols around specific capability requests – including particular control or response subroutines from ECUs to ancillaries – such is the bespoke nature of the uncrewed vehicle industry. This might also be facilitated by having the ECU operate on RS-232 as long as readings from engine sensors and the autopilot are within normal bounds, but then switching over to the CAN as soon as (for example) a CHT sensor or the flight controller flags up something of concern.
Consequently, the CAN might be reserved for moments where tighter control loops, response times, and clear prioritisation and integrity of real-time data tracking become imperative to ensure successful execution of emergency functions such as cutting off engine power for flight termination procedures or requesting escape velocities (be it in a direct mode such as setting the throttle to wide open or a governor mode such as targeting a particular air speed).
Triple-H
As indicated, much of the r&d in new ECU designs nowadays revolves around programming customer-, market- or application-specific requests to be layered atop the core engine management software, and considerations taken at both high- and low-level development for major trends in UAV powertrains such as hybridisation and heavy fuels.
Making an ECU for a highly electrified powertrain does not inherently necessitate much additional functionality beyond standard algorithms and tables because, in many instances, UAV manufacturers are happy to handle the hybridisation aspect. That is, their autopilots will issue throttle commands to the ECU, and externally govern the electric power management and distribution as a function of the throttle.
However, extensive potential synergies for hybridisation could be achieved in a number of ways not yet being widely picked up. For instance, tightly integrating an ECU with a hybrid system can help enable much leaner and thus more fuel-efficient operations. Running an engine extremely lean reduces combustion stability and risks sudden losses of power, but if the ECU is finely sensing for changes in torque via the current readings of the motor-generator, and intermittently allows the current to reverse direction, to ‘motor the generator’ when shaft torque momentarily drops, then propeller torque and hence propulsion will remain stable throughout flight, even amid combustion being lean to the point of significant instability.
Additionally, because integrating the ECU with one’s hybrid componentry allows direct measurement of electric power output (unlike propeller output, which is essentially immeasurable in real time), close feedback-based control over the engine is made possible, such that the ECU may be programmed to chase the optimal fuel-air point in terms of stable and efficient conversion of chemical energy into current.
Meanwhile, the need for optimised control of heavy fuel engines continues to drive similarly useful functionalities such that ECUs can be prepared for the task of handling more cumbersome kerosenes. Aside from core functionalities such as the aforementioned direct injection control, a growing number of UAV companies today are, bizarrely, trying to convert COTS two-stroke gasoline engines into multi-fuel engines without any modifications to the base engine metal; effectively using only ECU-centric calibrations and control without optimising for injector position or angle, fluid dynamics, passive thermal management and so on.
Doing this with even a minor degree of success requires an ECU with extremely accurate timing of control processes, access to a wide array of sensors and a microcontroller with higher than typical capacity owing to the greater number of data feeds and tasks to be managed in real time. Much of this comes down to the highly chaotic nature of trying to optimise kerosene combustion quality via crankcase injection and porting, because each injection needs to be started and stopped with very sharp precision.
Even in an engine designed from a blank sheet for heavy fuels, integrating more sensors than used in a typical spark-ignited gasoline engine is very useful for safe autonomous operation, because it could mean intelligent control loops such as reading EGT and lambda sensors to quickly identify when the fuel-air mix is running too rich, or even puddling inside the cylinder, to enable timely and novel control responses such as skipping injections until exhaust readings return to normal.
Irrespective of whether an engine is COTS, customised, multi-fuel or kerosene-only, heavy fuel is difficult to handle because it requires very tight mixture control, together with the ability to deal with cylinder imbalances and other problems. On top of robust programming and mapping, integrating key ECU functionalities – such as deactivating cylinders where fuel optimisation or temperature control is needed – and highly sophisticated transient fuelling algorithms can be crucially helpful for a heavy fuel engine. The latter are particularly useful, because in comparison with gasoline, heavy fuels often have a much longer transient period between when they enter the engine as liquid and exist in the injectors as combustible vapour; hence, transient fuelling modelling helps maintain optimal conditions and fuel usage.
Further ahead, the UAV engine space is on the cusp of a number of potentially revolutionary new direct injection technologies, several of which are expected to utilise multiple injectors per cylinder. Redesigning an ECU to control large numbers of fuel injectors – potentially including both direct and non-direct injectors in a single engine (as well as adding oil injectors as and when the use of direct injection makes the use of pre-mix impossible) – stands to make ECU design and programming increasingly complex, and make leveraging dedicated ECU manufacturers even more important than ever.
In addition to hybridisation and heavy fuels, there is growing interest in hydrogen power, via both combustion engines and fuel cells, given that several UAVs and other autonomous vehicles are successfully operating on hydrogen.
(Image courtesy of Power4Flight)
The drive for optimisation means that ECU developers are increasingly engaged in projects to create both ECUs calibrated for the nuances of hydrogen combustion, and fuel cell control units (FCCUs) calibrated for the electrochemical reactions of proton exchange membrane fuel cells.
The former represents a broad category of potential projects, given that hydrogen combustion is being explored in turboprops, two-strokes, Wankels and more. Detection of leaks, through integrating and monitoring H2 gas sensors, can be a core functionality given the potential for issues in effectively sealing engines for the universe’s smallest atom.
As for the latter, some UAV ECU manufacturers are actively working on, or set to engage in, an FCCU version of their more conventional ECU products. Creating an FCCU requires no major changes at the hardware level – a few small modifications of the board’s analogue sensor complement might be all that is needed – but the control software stack might have to be entirely different from the modules applied in engine management.
Much of that comes down to a few key management challenges. For instance, an air (or oxygen) pump and a water pump must be controlled and closely balanced to control the environmental conditions within the fuel cell. If the fuel cell is a closed-cathode configuration (using separate air streams for cooling and air intake), then thermal management must also be finely tackled, possibly whilst also controlling a separate compressor to deliver air at a stoichiometric ratio for reaction with the hydrogen. And downstream, the current output from each membrane electrode assembly must be managed effectively to turn the multiple low-voltage, high-current feeds into a single high-voltage, low-current supply (for the sake of efficiency).
(Image courtesy of Performance Electronics)
In some cases, FCCU development from the ground up might initially seem daunting to conventional ECU makers because the number of specs to monitor and standards to follow can be far higher than are tracked in engines. In other cases, the desired fuel cell controller might be less complex than managing engines of similar power output. Either way, the result might be a software stack that is fairly analogous to that used in engine management and fundamentally relying on just a few maps, despite the application revolving around very different physics.
Ruggedisation
As UAVs carry out more missions and take on harsher environments, keeping electronics such as ECUs protected against hazards from outside or inside the aircraft becomes increasingly paramount. However, material and part selections for enclosures must be restrained because they almost always have a large impact on the price of the final product (not to mention adding considerable weight). A run-of-the-mill box made from two machine-cut aluminium halves and a couple of screws, for instance, can easily represent half the total production cost of an ECU.
To get around this and offer a more price-competitive product, some ECU makers are leveraging standardised automotive enclosures, with even hard plastic boxes of this type being rated to withstand the mechanical and thermal harshness found under the hoods of road vehicles.
It is also important to remember that designing board-mount components to endure such conditions (through effective soldering, coatings, potting and so forth) can go a long way in reducing system dependency on a housing to do all the work of handling vibration, shock and heat. Operating the electronics on standard rate tables and viewing them through thermal cameras can enable analyses of how heat will distribute and how cracks will form under many hours of environmental harshness without external packaging.
Naturally, sealing against ingress of dust and liquids takes different measures to mechanical and thermal robustness. IP67 protection can be achieved through use of conventional gaskets as well as by carefully designed, injection-moulded plastic enclosures, among other approaches. However, potting is falling out of favour owing to the high expense of the required materials, the application machinery being high-maintenance, and QC of the potting process and liquid dispensation being challenging.
(Image courtesy of Moscat Ingeniería)
Additionally, ECU developers are engaging more with facilities capable of testing for EMI and EMC, given the proliferation of electronics throughout the insides of vehicles nowadays (not least the rising count of engine sensors, actuators and redundant electronics that are key to safety certifications), but extensive EMI shielding at the housing level makes it more challenging to achieve wireless data transfer from the ECU to either GCS operators or cloud-based data servers. Hence, EMI is increasingly likely to be handled on a case-by-case basis and not addressed with a one-size-fits all mitigation strategy, and the use of aluminium enclosures might be reduced in favour of plastics and nylons as connectivity becomes prioritised over sweeping countermeasures against EMI.
Production
Companies designing and engineering ECUs for UAV engines tend to focus their resources on effective design, engineering and the final aspects of assembly (such as software flashing and end-of-line validation testing). It follows that they typically entrust the actual manufacturing to specialist subcontractors who can mass-produce electronics cost-effectively.
That, combined with demand growth driving some ECU companies to deliver thousands of units per year (compared with hundreds just a few years ago), judicious selection of component suppliers and manufacturing subcontractors has become vital for balanced increases of both inputs and outputs. In some cases, multiple stages of tests might be performed throughout the build of each unit to help ensure the kinds of low failure rates expected of certifiable avionics.
Even with close assurances of a manufacturer’s consistent quality, ECU developers often create their own test benches, software tools and regimens for assessing the quality of near-finished units arriving through their doors. These are then – at least in high-end ECU companies – used to end-of-line-test 100% of units, both to validate the airworthiness of each ECU and to help maximise the throughput of testing batches (given that testing 500 ECUs per month could suffocate the resources of an otherwise small and agile ECU engineering team).
In some cases, that means an ECU can be plugged-in, programmed and tested for full and correct software functionality within 30 seconds, particularly with apt use of automation (including semi-automated tasks with a human watching and triggering each phase to ensure that they are carried out and recorded correctly) to minimise human error and repetitive strain.
Devices like coordinate measuring machines, 3D laser scanners and vision-based scanners can also check for misalignments or material swells among board-soldered components, and they are increasingly being used to such effect in ECUs (just as the first small aviation engine companies to switch from model aircraft applications to professional UAV applications were the first to adopt CMMs to validate cylinders, heads and crankcase parts arriving in-house).
Amid all these tests is an increasing drive for traceability, likely to result in customers being presented with the testing results as documentation for each unit delivered as a standard offering (as some battery cell manufacturers in the EV space do nowadays). To that end, some ECU developers are carefully automating the timestamping of every end-of-line test and of every firmware download, together with the recording of all data on the cloud for easy access, printing and analysis as needed.
Future
Just as automation is becoming vital for QC and testing of ECUs, so too are ECU software developers looking into how generative AI might assist code generation in certain areas. Given the need for guaranteed safety in certifiable avionics, low-level code in the ECU’s embedded software or firmware might not be entrusted to generative AI so widely, but non-safety-critical items such as user-side GUIs, calibration tools or ledgers for analysing engine and flight data could be rapidly developed through code generation systems without significant downsides.
However, in pursuit of shortened development times, ECU makers are expected to increasingly standardise modules for use across specific powertrain and vehicle types, encompassing both electronics modules for hardware and software modules for core engine management strategies, together with customer-specific engine or analytics demands. Use of tried, tested and constantly reviewed standard modules will enable rapid deployment of newly customised ECU designs with a strong guarantee regarding the absence of bugs, with some projections estimating that smart standardisation practices could shrink development times on new ECU prototypes from six months down to below two months.
If true, then the subsequent trend will likely be further expansion of testing facilities and increased numbers of staff among ECU makers, not only to handle the increased throughput of new product batches in need of validation, but also to ensure everything is being done supplier-side to ensure that all units are meeting the increasingly (and justifiably) stringent safety and performance standards of the professional UAV world.
Acknowledgements
The author would like to thank Sergio Moscat of Moscat Ingeniería, Bill Vaglienti of Power4Flight, and Brian Lewis of Performance Electronics for their help in researching this article.
Some examples of ECU manufacturers and suppliers
AUSTRALIA
| Currawong Engineering | +61 3 6229 1973 | www.currawongeng.com |
| Haltech | +61 2 9729 0999 | www.haltech.com |
| Orbital Corporation | +61 8 9441 2311 | www.orbitaluav.com |
AUSTRIA
| Bosch General Aviation Technology | +43 1 79722 4300 | www.bosch-aviation.com |
GERMANY
| Sky Power | +49 617 594 9005 | www.skypower.online |
ITALY
| Zanzottera Technologies | +39 0344 326 86 | www.zanzotteraengines.com |
SPAIN
| Moscat Ingeniería | +34 91 491 0236 | www.moscatingenieria.com |
TAIWAN
| Hioki | +886 2 2775 1210 | www.hioki.com |
UK
| Advanced Innovative Engineering | +44 1543 420700 | www.aieuk.com |
| Corintech | +44 1425 655655 | www.corintech.com |
| Cosworth | +44 1604 598300 | www.cosworth.com |
| GEMS Performance Electronics | +44 1784 470525 | www.gems.co.uk |
| Ilmor Engineering | +44 1604 799100 | www.ilmor.co.uk |
| OMEX Technology | +44 1242 260656 | www.omextechnology.com |
| Rotron Power | +44 1747 440 510 | www.rotronpower.com |
| UAV Engines | +44 1543 481819 | www.uavenginesltd.co.uk |
| UAVE | +44 1545 561111 | www.uave.co.uk |
USA
| Cobra Aero | +1 517 437 9100 | www.cobra-aero.com |
| Ecotrons | +1 562 758 3039 | www.ecotrons.com |
| EFI Technology | +1 480 341 5655 | www.efitechnology.com |
| HFE International | +1 520 578 0818 | www.hfeinternational.com |
| Northwest UAV | +1 503 434 6845 | www.nwuav.com |
| OpenECU | +1 734 656 0140 | www.openecu.com |
| Performance Electronics | +1 513 777 5233 | www.pe-ltd.com |
| Power4Flight | +1 541 308 0650 | www.power4flight.com |
UPCOMING EVENTS
