Growing number of ecus forces new approach to cars electrical architecture

Perhaps the biggest challenge facing designers is the number of electronic control units (ecus): in some top of the line models, there are more than 100 such devices. Convenience and comfort is bringing with it complexity as large amounts of data move around the vehicle's various communications networks. So how can automotive systems designers make things simpler while still enabling more 'bells and whistles' to be included in future vehicles? Nick Jones is manager, advanced engineering, with BWI Group – a leading supplier of systems to automotive manufacturers. "There are already too many ecus," he said, "and oems – the manufacturers – are looking at ways to deal with the situation." One of the ways in which this might happen is a more enthusiastic commitment to the features available in Autosar – the AUTomotive Open System ARchitecture. "This has been around for some years," Jones commented, "but the number of oems using it is still relatively small. We are expected to be Autosar compliant, but are rarely asked to implement all of what the standard is capable." However – at least in Jones' opinion – things are changing. "There is growing insistence that suppliers comply with the latest standards: it now looks as if oems want to use this capability." More creative use of the features in Autosar, for example, may enable designers to overcome what seems to be a tyranny of ecus. Jones gave an example: "Autosar allows designers to take particular functions and to embed them in controllers not originally designed for that function." But he cautioned that such an approach has wider implications: "This would have to go hand in hand with other changes in order to be effective." How would such an approach work? "It's all down to the way in which systems are architected," he said. "Say, for example, we have a chassis controller that handles a variable damping system. That controller also has the 'smarts' and computing power to run a set of electric door mirrors. Instead of having an ecu for the mirrors, we could embed the software into the chassis controller and feed it the relevant data. It would compute what needs to be done and issue the appropriate commands. "That's fine," he continued, "but you need to configure the mirrors to be self controlling, with a degree of intelligence built in. There may be more cost in the mirror assembly, but the overall cost would be less than with a mirror ecu." This approach allows oems to take advantage of ecus with spare computing power. "Autosar lets you take a particular piece of software and 'drop' it into another Autosar compliant ecu. It's potentially powerful, but it would need other architectural changes." And it's here that the changes to which Jones alluded are needed. "It can be a gradual rework, but there has to be a management decision that is the approach to be adopted." Alongside the growing number of ecus, there is an increasing amount of data flowing around the various communications networks. "Distributed systems, where intelligence is embedded in actuators, mean you no longer have to transmit so much data across heavily loaded CAN buses because the actuator can perform closed loop control locally. "All that is being sent back from the smart actuator is diagnostic data, for instance." He believes this approach is not necessarily more sophisticated. "It does need a more powerful controller," he admitted, "but when there are four or five subsystems, a lot of the same things are being computed. This eliminates redundant computing. The amount of additional processing power required is less than you might think." The growing number of ecus is bringing with it ever larger volumes of data. "It's swamping the network," Jones believes. "There are too many ecus trying to pull too much data from actuators and sensors. One solution is systems that don't require so much data to be transmitted. Another is to move to protocols such as FlexRay. This is powerful and handles a staggering amount of data, but it requires a major commitment within the development phase. It's not simple to implement and requires a high investment, but once in place, it's robust and reliable." Jones pointed to the recently developed CAN FD protocol as an alternative. CAN has been limited to 1Mbit/s, but CAN FD – flexible data rate – improves the performance in two ways: it supports data rates in excess of 1Mbit/s; and it supports payloads with more than 8byte per frame. It achieves this through the use of a new format in which faster bit rates and different data length coding can be selected inside the frame. "CAN FD is exciting," Jones enthused. "It allows some ecus to run in 'supercharger' mode, while others on the same network can run more slowly. This ability to mix high and low speed data is powerful and doesn't drive you towards deterministic systems such as FlexRay. It also provides for an evolutionary, rather than revolutionary, approach – and oems and tier 1s prefer evolution." CAN FD can also be applied in specific modes, including software download during end of line programming. Controllers that do not support CAN FD can be kept in standby mode. "Say the customer wants a variable damper system; if you set up the original design correctly, options can be switched on and off, but you have to remember there's a large number of ecus programmed at end of line. If you don't want to carry self detecting software within the central domain ecu, you can effectively download a controller for optional systems on individual vehicles at the end of the line." But there is a wider impact. "There's a certain 'point and step' needed," Jones said. "Decisions often have to be made five years in advance because of the changes in the vehicle's electrical architecture." This appears to be in line with current design trends. "The drive for increased reliability in electrical systems means more oems are trying to freeze requirements and software much earlier in the design cycle. While the advantage of a software based approach was that things could change right up to the point of manufacture, the number of bugs you build in is unacceptable. There has to be a long settling time, with debug and test phases. People are now realising that late software changes carry large risk." Despite the moves to industry standards, Jones said oems remain uncooperative when it comes to standardisation of systems. "But that's changing; and there's growing interest in ISO26262; a powerful standard which has been developed collaboratively." He said there is now more standardisation on how protocols are interpreted and implemented. "That's incredibly helpful to tier 1 suppliers," he concluded. "The more standardisation means the more efficient the development process will become."