Inside Look: Cummins Centinel
Managing the addition of oil to a diesel engine’s fuel-oil mix turns out to be a tricky problem. Here’s one design that worked well.
Welcome to this edition of Inside Look, a periodic column that takes an indepth look at the design of a successful, unsuccessful, or just plain interesting embedded system.
This isn't a marketing pitch. We're scrutinizing the technical aspects of the design, to find out what went right, what went wrong, and what would go differently if the designers had the opportunity to do it all over again.
This issue features a device called Centinel, an embedded system designed by Cummins Engine Company, Inc. that aims to eliminate oil changes for big diesel trucks and other diesel powered equipment. This product has been an amazing success, and chances are you've been passed on the highway by trucks with this hardware built in.
Enjoy the Inside Look.
The Cummins Centinel Advanced Oil Management System is an embedded system that extends oil change intervals on electronically-controlled diesel engines, by periodically removing a small amount of used oil from the engine’s crankcase and replacing it with fresh oil. The used oil is sent to the engine’s fuel tank, where it is blended with the fuel and burned during normal combustion.
Centinel allows diesel powered trucks, tractors, generators and other devices to spend more time at work, and less time in the shop for oil changes and other routine maintenance. And by burning the used oil as fuel, Centinel also saves money and reduces environmental damage by eliminating the need to dispose of the used oil.
This idea is not new. Mechanical systems with similar functionality have been around for years, but the today’s sophisticated engine controllers and strict EPA emissions standards make an all-mechanical solution impractical. Centinel also does a better job of maintaining engine oil quality than previous mechanical designs, because its control algorithm takes into account several factors, including the engine’s realtime workload, to determine the ideal oil burn and replacement rate.
2. The Problems
When they were getting started, Centinel’s designers already knew that they need the device needed to be as reliable as possible. An engine requires good quality oil to operate, and any system that can remove oil from the engine’s crankcase must also be able to make sure that it doesn't damage the engine in the process. This problem is actually more difficult than it sounds, because inexpensive oil level sensors that can survive inside of a diesel engine do not exist.
The product also had to be durable. On-highway diesel trucks routinely travel as many as 200,000 miles a year, in all types of climates, and industrial machinery like construction equipment often goes without maintenance for months at a time. Furthermore, all such commercial applications seek to maintain the highest productivity possible, which means they cannot stand idle while an "accessory" like Centinel is down for repairs.
Finally, the product had to be affordable. The first production Centinel units were to be offered as an aftermarket, owner-installed device, which meant that its sales price had to be considerably less than the savings it could realize by reducing a vehicle’s total cost of ownership. This made for an aggressive cost target.
3. The Solution
After considering several options, the designers settled on an electromechanical design featuring a TMS370 microcontroller, an SAE J1587 automotive datalink interface, a mechanical pump to transfer oil in and out of the engine, sensors to measure oil levels, and a tank to hold fresh oil.
During normal operation, the microcontroller reads information from the engine via the J1587 datalink, in order to determine the engine’s current workload and to detect the occurrence of various engine related system faults. From this information, an ideal oil burn rate is computed and periodic pulses are sent to the oil pump in order to transfer oil to the engine’s fuel tank.
The oil pump design combines the used and make-up oil pistons into the same mechanical package, yielding a device that reliably transfers a fixed, known quantity of used oil to the fuel tank, and replaces it with an identical quantity of fresh oil on the return stroke. The pump and related plumbing are sometimes heated and insulated, to help keep the oil flowing even in the coldest climates.
Sensors indicate when the fresh oil tank is empty, and Centinel will postpone pulses until additional oil is provided. The engine operator must still monitor the dipstick in the engine’s crankcase, and manually add oil as necessary to replace what the engine burns inherently during normal operation.
4. The Details
The Texas Instruments TMS370 microcontroller forms the basis of the design. This controller was selected for its low price, high integration, and its availability—competing chips from other vendors had lead times that were beyond the intended project completion date.
The chip chosen sports 128 bytes of onboard RAM, 8K of ROM, and a 12 MHz system clock. The Centinel circuitry adds a serial EEPROM, power conditioning and failure detection, and an SAE J1587 datalink interface (similar to an RS-485 network) to connect to the engine’s communications datalink.
To improve reliability and durability, all of Centinel’s data inputs are extensively qualified before the values are used. Clever hardware detects open and short circuits on all inputs and outputs, and careful range checking of all data prevents improper operation in the event of tampering or electrical failure.
The primary control algorithm runs on a fixed 20 msec interval, and combines engine workload, climate and other information received via the engine datalink with knowledge about the type of oil in use (as indicated by a jumper in the wiring harness) to compute the desired oil burn rate. The oil replacement rate therefore varies in real time, to maintain oil quality at a level that approximates a typical 50,000 mile oil change interval regardless of the engine’s actual duty cycle.
Once the oil burn rate is calculated, the number is passed to a second algorithm that computes the rate at which pulses must be sent to the oil transfer pump in order to actually burn and replace the requested volume of oil. The logic at this second stage is somewhat complicated, because pulses are postponed when the fresh oil tank is empty; when the operator refills the fresh oil tank, pulses are sent at an accelerated rate in order to "catch up" to the requested volume.
To minimize air pollution and other concerns, EPA guidelines limit the amount of oil that can be burned as fuel in an automotive diesel engine. To prevent Centinel from exceeding this limit, a third algorithm restricts the maximum pulse rate sent to the oil transfer pump under all circumstances, so much so that in extreme cases, the "catching up" process can take hours, or even days to complete.
5. Software Architecture
Upon startup, the software sets up the MPU’s I/O hardware, timers, serial communications port, ADC and other peripherals, then enters an endless, do-nothing loop. Interrupt service routines contain the bulk of Centinel’s code, a common approach for devices that lack an operating system.
A periodic timer interrupt initiates the control loop code, which resets a hardware watchdog timer only upon successful completion. Other interrupt service routines manage serial data reception from the J1587 datalink, time pulses to the oil transfer pump, and detect impending power failures.
One of the most difficult aspects of the development effort was managing updates of Centinel’s serial EEPROM. Data in the EEPROM could not be refreshed on every iteration of the control loop, because that would exceed the device’s write limit well before Centinel’s intended lifetime. Instead, persistent data was written to the chip only at system shutdown, during a 200 msec holdup deliberately built into Centinel’s power supply circuitry.
In the interest of reduced cost and improved reliability, the power supply holdup was critically close to the EEPROM’s update time, which meant that there was virtually no room for unexpected delays during the shutdown process. And since the EEPROM contained vital information about the state of the oil burning process, the update operation had to succeed under all real-world conditions other than device failure.
The shutdown and EEPROM updating process was the most carefully scrutinized code in the Centinel system, and numerous improvements took place during an extensive analysis and testing process to make sure things worked as they were expected to. Careful consideration was given to the logic that induced the writing process, the order in which bytes were written, and how much data was queued before writing began, both to make sure that the amount of time required was absolutely bounded, and to help assure that the system would reawaken in a safe state if an unanticipated error somehow did occur.
One unexpected surprise found during early field testing was that the excessively high powered (in some cases illegally so) CB radios favored by many truckers could induce voltage swings of nearly 30 volts peak-to-peak on the truck’s main power system. To combat this, additional code had to be added to Centinel’s already extensive set of signal analysis logic to prevent false powerfail indications from initiating an EEPROM update and system shutdown when the radio was in use.
6. The Results
Centinel is one of Cummins Engine Company’s most successful products, apart from their award-winning family of electronically controlled diesel engines. Even after more than five years of production, the Centinel system has yet to find need for improvement or revision.
The Centinel design won an OEMmie award from OEM Off-Highway Magazine (Johnson Hill Press Publications), and is highly regarded within Cummins as an example of how their continuous improvements in system engineering practices are yielding superior products. In fact, the design is so successful, it has served as a platform for several other new products, some of which will certainly be presented in future Design Views.
7. Next Time?
It doesn’t look like there is going to be a "next time" for Centinel. The design works so well as it is, there is little room for improvement.
One thing that the developers acknowledge would have helped the initial development work would have been to choose a microcontroller with more available memory. A larger device would have permitted some sloppy C coding in spots, allowing the developers to focus more attention on fine-tuning Centinel’s control algorithm and diagnostics, instead of constantly reworking code to reduce resource consumption.
The authors wish to acknowledge the efforts of Andy Pajakowski and Gary Gron, both of Cummins Engine Company, for their assistance in reviewing this article.
This article is Copyright (c) 2002 by Bill Gatliff. All rights reserved. Reproduction for personal use is encouraged as long as the document is reproduced in its entirety, including this copyright notice and author contact information. For other uses, contact the author.
10. About the Author
Bill Gatliff is a freelance embedded developer and training consultant with almost ten years of experience of using GNU and other tools for building embedded systems. His product background includes automotive, industrial, aerospace and medical instrumentation applications.
Bill specializes GNU-based embedded development, and in using and adapting GNU tools to meet the needs of difficult development problems. He welcomes the opportunity to participate in projects of all types.
Bill is a Contributing Editor for Embedded Systems Programming Magazine, a member of the Advisory Panel for the Embedded Systems Conference, maintainer of the Crossgcc FAQ, creator of the gdbstubs project, and a noted author and speaker.
Bill welcomes feedback and suggestions. Contact information is on his website, at www.billgatliff.com.