Euro 6 vehicle electronics 04 June 2014
The arrival of Euro 6 has resulted in changes to heavy truck electronic architectures – some OEMs much more than others. Brian Tinham takes advice from Ian Judd and Stuart Bull, of Renault Trucks
Digital electronics have long since monitored, controlled and managed virtually all vehicle functions, whatever the type and marque. So it's no surprise that, with the increased sophistication of Euro 6 engines, technicians need to focus on their CANbus and LINbus knowledge. That means revisiting your DMM (digital multimeter) and oscilloscope skills and your understanding of fault signatures, not just your ability to wield the latest generation diagnostic tools.
But, ahead of that, it also means spending some time on the new trucks' wiring diagrams, and particularly understanding how the ECUs (engine control units), communications networks, power supplies, etc, hang together and 'talk' to one another. Why? Because many of these networks have changed significantly, so your approaches to fault-finding will need upgrading if you want to remain competent, cost effective and efficient.
The scale of change is partly due to the fact that most of the truck manufacturers timed their Euro 6 engine introductions to coincide with new vehicle ranges – so it's not just the engine management electronics that have changed. You should also expect to see new-generation functions and features – such as lane departure warning, autonomous emergency braking and electronic parking brakes – accommodated, with all their sensor and actuator communications.
But additionally, some OEMs have gone for a wholesale revision of their vehicles' electronics, taking advantage of modern network architectures to reduce cost and weight, while also improving the robustness and resilience of their wiring systems. That's certainly the case with Renault and Volvo trucks. On their latest vehicles, for example, the network design is now based on two main CANbus backbones that, in turn, communicate with a much greater number of ECUs and modules via so called subnets (mostly CAN, but also some LIN) specific to certain areas – such as the rear chassis, mid chassis and cab.
Not only does this architecture mean that, if there's a problem with one sector of the CANbus, it doesn't bring down other aspects of vehicle management, but also the logic of the layout helps boost failure-to-safety on critical systems, such as lighting and brakes. However, it can also assist with fault diagnostics – if you know what you're looking for.
So the first observation is that, if you or your team's CAN and LIN skills are at all shaky, now is the time to find an intermediate electronics course that's at the right level for you. Talk to your dealership for advice. No one needs to get their heads round brand new concepts – after all, we've all been familiar with multiple ECUs on trucks since well before Euro 5. But the point is that on newer trucks there are many more distributed control units, so the level of knowledge required is greater too.
This is not rocket science. The objective is ensuring proficiency in using DMMs and scopes to check that interactions between ECUs and equipment, in response to driver or system demand, are correct, in the right format and that they're not being corrupted. And, by the way, don't assume diagnostics tools can do all this for you. They should be viewed as aids for gathering evidence and suggesting tests, potential problems and solutions, but you need to be in control and taking the initiative with conventional tools. Also, basic electronic test tools are often the fastest route to problem solving.
Take the LIN (Local Interconnect Network) communications system, developed by auto makers in the early 2000s to improve the flexibility of distributed monitoring and control, without the cost of CAN. This serial network protocol is effectively a simplified version of CANbus, still running over a twisted pair but with messaging down one line, while the other provides a ground connection. LIN doesn't have the messaging sophistication of CANbus, but it's more than man enough to support remote subsystems in master-slave format.
Renault and Volvo have now joined other heavy vehicle manufactures in incorporating a lot more LIN – for example, to improve flexibility of positioning controls in the cab. With LIN-based devices, drivers have the flexibility to configure their switches (which are key coded to particular functions) in allocated groups, close to hand or above their heads, according to personal preference. For technicians then, the issue is understanding how these systems work so that, in the event of a failure, they can follow a logical sequence to quickly determine where the fault is (whether wiring- or component-related).
Since LIN-based switch blocks (managing, for example, door locks, windows, sunroof, blinds, etc) are connected in series, if there is a complete failure between one block and the next, you're likely to have a wiring fault. If just one switch appears not to be working, simply swapping it to another valid position quickly demonstrates whether it's the switch or the connector block.
If the problem is more subtle, the logical approach to fault finding is first to check for the presence of power to the switch, using a DMM. If that is positive, then view the two-way transmission of messages between the relevant ECU (master) and LIN switch (slave) in response to demand, using an oscilloscope.
It's a similar story with the truck's switched components – everything from the side lights up. However, the driver input request, which started on a LIN switch, then moves onto the main CANbus network (via one of the three chassis I/O boxes), which is responsible for the vast majority of truck equipment communications, potentially being relayed through a chain of ECUs and intelligent modules (according to the CAN master message identifier field and its slave message control data).
CANbus (Controller Area Network), which was also developed for the automotive industry, predates LIN by around 15 years and is a more sophisticated, message-based protocol. The digital data bus standard was designed to allow a network of distributed microcontrollers to communicate with each other without a host controller. The standard has been subject to ongoing revision – the latest release, in 2012, having an uprated CAN data link layer.
For modern trucks then, there are four obvious changes. First, CAN-based intelligent devices are now no longer all mounted in the cab, but ruggedised and distributed logically around the vehicle (broadly split between the front, centre and rear of the chassis). Secondly, there are many more of them (around 30), ranging from the biggest EMS (engine management system) and TECU (transmission control unit) to shared-function devices (such as the chassis I/O modules). Thirdly, most now handle multiple functions relating to where they are, not a particular equipment requirement. And fourthly, as a result, the scale of multi-core hard wiring has been significantly reduced.
Manufacturers talk of some 20kg weight saving, just in terms of copper wire. However, the fact of massively reducing the wiring loom also reduces the potential for failures. Also, for Renault and Volvo resilience is improved by the introduction of dual backbone networks, with multiple, semi-independent CANbus subnets that optimise communications between local area modules that need to exchange data frequently.
Some modules are connected to both backbones; others are not, depending on their functional requirements and criticality. EMS, TECU, VMCU (vehicle master control unit), DACU (driver assistance control unit) and CIOM (cab I/O module), for example, have access to both networks. VMCU – which handles power management and is the main port for diagnostics – is also the gateway ECU between the backbones and the chassis subnets (note: it is not, however, required for all inter-module communications). Meanwhile, EBS (electronic braking system), ACM (after-treatment control unit), APM (air production modulator) and TACHO are attached to one backbone only.
As for shared-function devices, as stated, responsibilities are dictated largely according to their location. The front chassis I/O module, for example, handles all front area lighting. However, the ACM (situated mid-chassis) looks after auxiliary controls and the retarder, if fitted, as well as its primary after-treatment tasks. Similarly, there is no longer a dedicated air suspension ECU: air bag pressure and ride height are functions carried out by the RCIOM (rear chassis I/O module), which also manages power to the rear and trailer lighting.
All this represents radical change for technicians. Taking the rear suspension example again, pressure and level information used to be hard-wired back to the cab for processing and then hard-wired again to the rear modulators. Now, all of that is handled locally by the RCIOM alongside its other functions at the vehicle rear, with messaging elsewhere only as required – and only on a single CANbus pair.
To reiterate, physical proximity is the key throughout. For instance, the APM (new to this infrastructure) is located between the FCIOM (front) and CCIOM (central) chassis I/O modules – putting it adjacent to its key partner equipment, the Knorr-Bremse EBS module. The necessarily high data rates between these two are then enabled by the local CAN subnet, used by all of the chassis I/O modules.
It sounds daunting and at first glance the top level CAN network architecture may look unnecessarily complicated. However, the fact that functional distribution maps to a clear, location-based structure means that, depending on the component or function reported faulty, following the logic may well mean that you don't even need your DMM to make a diagnosis. A visual inspection might well be enough.
A good example would be a rear light not working. Before looking at the bulb or connector, you should know that the RCIOM – which, again, manages everything at the rear of the vehicle – has two separate fuses, with the feed split to enable fail to safety. If the vehicle has lost one module feed, that will take out different opposing lights on either side of the vehicle. So, without putting test equipment anywhere near the truck, just viewing the rear lamp operation may tell you the story.
If there is no correlation, however, then working on the principle of maximum speed and minimum intervention, your examination should start with unplugging the connector. A quick look might reveal all you need to know. If not, use your multimeter on the connector (faster than removing the bulb). If that is okay and the connector is clean but there's no voltage, then you're looking for a voltage output elsewhere.
RCIOM receives messages to put power to the lights via the CANbus from the driver's LIN switch. It should do so via its dual-redundant power supplies. But, beyond the rear lights, remember that module is also responsible for air suspension, locking fifth wheel (if electronic), trailer lights (if relevant), etc. So, if there's no voltage at the light, you need to establish that: the ECU has power; it is sending voltage to those other systems; it is getting the message to deliver power; and that power is not being lost to a break in the wire.
Don't plug in the diagnostics yet (that might reveal other fault codes and potentially blind alleys), or connect the oscilloscope to view message signatures. Instead, thinking again of 'maximum speed, minimum intervention', use your DMM to check that voltage appears where it should – starting at each connector end.
If there's power at RCIOM, then you've already isolated the fault between the two connectors (CAN module and lamp). If there isn't, you need to start working back – and now it's time to use the diagnostics to avoid simply chasing the fault. First, read the fault codes – the likelihood is that your fault (among others) has already been logged. If it has, you're on the right track and the next easiest thing to do is pull up a visualisation of that module on the screen, and check for the message inputs and outputs along the logical chain of command.
Limp home modes
Making the new electronic infrastructure resilient to faults is achieved by 'limp home' modes across a range of functions. If, for example, there is a loss of communication to a whole CANbus subnet, the connected modules will continue to operate because each has its own power supplies. However, all devices will recognise that communications have ceased and revert to a fallback mode (if applicable) that is safe and offers sufficient functionality to get the vehicle back to base.
Technicians can easily recognise this condition. As well as the fault codes generated, warning lamps will illuminate on the dash, making it clear that a module(s) is in limp home mode – and therefore that the truck is likely to have experienced a communication issue.
With a lighting failure, for example, the default is 'lights on'. So, if the lights can't be switched off, then maybe there is a communications problem in the relevant chassis subnet. Equally, given that many of the modules, especially those with shared functions, continuously 'talk' on their subnet and via the gateway ECU to the rest of the network, if, say the transmission control unit falls of the network, several will flag up the communications problem.
From an electronics angle, EBS (electronic braking system) – with its wheel speed, steering angle, momentum and vehicle gyro sensors – remains much the same as before, functioning as a semi-autonomous controller. The latest system also has similar protection to its earlier counterpart, with, for example, automatic conflict resolution between sensor inputs leading to shut down of the system if sensor inputs are outside the programmed tolerance.
Note that, although APM2 and EBS are co-located, their only shared function is the exchange of air pressure information and operating state. Neither is capable of taking over from the other.
If APM2 experiences electrical failure, it reverts to pneumatic valve regulation, but this will not disable EBS. If EBS detects a serious electrical fault, it reverts to pneumatic braking distribution via conventional service brake valve and module relay valves, with no vehicle speed, load or momentum intervention.
However, electronic parking brakes are coming in – with their improved safety, and cost and weight-saving advantages – so you need to be aware of the additional function and its touch points around the network. On Renault and Volvo platforms, operation is independent, via one switch with a dedicated LIN to the APM (none of the old valves and pipework). In operation, if the engine is running, the vehicle is in gear and there is air pressure to release the springs, as the driver depresses the accelerator, the park brake releases, automatically managing roll back.
From a data perspective, the new parking brake looks at throttle position, engine revs and torque, the gearbox inclination sensor, clutch bite position and air pressure to control its release rate and timing. If the controller sees the engine has shut down, then, with ignition off, it exhausts air from the chambers, the springs come on and the park brake is automatically applied.
From a maintenance point of view, driver control is via a LIN switch (disguised as a conventional lever with a bias spring), so fault finding is as per earlier descriptions – primarily using a DMM, oscilloscope and finally diagnostic equipment, and pointing the latter to the relevant ECUs. Then at the APM end, you're back to pneumatic valves, although these are now under solenoid control.
Incidentally, for the brakes' workshop mode, with the engine on, release the park brake, hold the switch and shut down the engine.
To reverse the procedure, simply reapply the parking brake. The vehicle will recognise any failure to quit workshop mode and revert to automatic when the vehicle reaches 30kph.
Renault Trucks UK Ltd
Volvo Group UK Ltd
This material is protected by MA Business copyright
See Terms and Conditions.
One-off usage is permitted but bulk copying is not.
For multiple copies
contact the sales team.