Technology focus - Engine Control Unit (ECU) - Torque based architecture explained

In older generation engine management systems, different internal control subsystems had conflicting demands on the overall control system, with no real co-ordination. This meant that there was an interdependence between these systems, which was difficult to handle during calibration and did not provide the optimum with respect to an overall engine control concept. The answer was a 'torque' based architecture in the ECU - that is, to focus on the driver demand for torque, rather than respond to the throttle pedal postion.

Fig 1 - Conflicting torque demands in an Engine control unit

The block diagram above shows the conflicting requirements - the answer was a torque based control architecture – an overall torque demand manager (TDM) co-ordinates all the overall torque and efficiency input values. Internal inputs are typically defined by the engine operating mode and protection limits, external inputs are driver demand, cruise control and vehicle dynamic control values (ABS, Stability control etc.). The TDM process the inputs, taking into account drivability optimisation factors (thus allowing ‘tuning’ of the vehicle behaviour with respect to vehicle type and driver expectation). The final output from the TDM is a required torque value, this is realised by the controller output stages and connected actuators which are available to influence the engine torque output – typically throttle angle, ignition timing (SI engine), injection parameters (SI and CI engine) and turbocharger control.

Fig 2 - Overview of the TDM function (Torque Demand Manager)

But how is engine torque measured? well it isn’t! it is derived from an internal model that takes into account cylinder air charge, lambda and ignition timing (SI engine). Combustion generates a cylinder based ‘internal’ torque, from this gas exchange and friction losses are estimated and subtracted, and this gives a final engine output torque. Clutch torque can then be derived by subtracting engine ancillary torque absorbers, for example, Electrical and HVAC loads.

Fig 3 - Virtual torque sensor function which forms the basis of a torque based ECU structure

Read More

Technology focus - Vehicle network and communication bus technology

Vehicle networks have become common place in modern automotive electrical and electronic systems. As the cost of electronic systems has reduced, this technology has become the most efficient way of handing the large amount of data required and shared by modern vehicle control systems. The introduction of automotive compatible serial data networks has expanded the capabilities for intelligent data transfer and sharing of information and is a logical development for modern vehicles.

Fig 1 - Relative comparison of BUS performance level

Bus systems for different applications require different data transmission rate capability (also known as bandwidth). It is very common to see a several networks on the same vehicle running at different speeds appropriate for the application. There are a number of typical groups implemented with different performance requirements: 

• Entertainment/Multimedia – Mobile communications, radio, navigation 
• Body and Convenience – Lighting, HVAC, Door locks, mirrors etc. 
• Powertrain – Powertrain control, Vehicle Dynamic control, Driver Safety systems 

Current Technology

The most widely adopted vehicle network technology was developed by Bosch and is known as CAN (Controller Area Network). This technology has established itself as the standard for vehicle manufacturers. It should be noted though that there are a number of other network technologies available and under development:

CAN

The basic principle of the CAN bus is that individual modules (ECU’s) are connected in parallel to the bus system. Each point of connection to the bus is known as a node and all the connected nodes have equal priority. This means that all messages on the bus are available to all the ECU’s at the same time. This is known as a multi-master system. The advantage of this method is that failure of one node does not impair bus-system access for the other connected nodes and this increases the overall reliability of the system. In addition, the system is designed with a high degree of inbuilt safety with respect to error checking and handling of transmitted data.

The basic principle is that each control unit is connected to the bus, in parallel, by transceiver modules. The transceiver is a transmitter and receiver amplifier. It converts serial data into electrical signals on the bus (and vice versa). Generally the signal is transmitted over a differential line as this provides superior electrical interference rejection. The information is transmitted as electronic messages and each control unit can send and receive them via the transceiver. A typical message would be a physical value, for example, engine speed. This is converted into a binary number and them transmitted electrically as a serial bit stream on the CAN data bus as 1’s and 0’s. All the other control units on the bus receive this data and can convert the bit stream back into a message ready for processing by the ECU.

Between the transceiver and ECU, the CAN module controls the data transfer process for the CAN messages to and from the ECU. It is divided into 2 sections – send and receive. The CAN module transmits data to the ECU via mailboxes (i.e. memory locations) which have read/write access to and from the ECU processor.The CAN data bus can be in one of 2 states representing 1 or 0. The transceiver is connected to the bus line via an open collector. This results in two possible states on the bus line:

• Transistor ‘open circuit’ - high state via resistor, bus level high (logic 1) 
• Transistor ‘closed circuit’ – low state, resistor shorted, bus level low (logic 0). 

These are known as recessive and dominant states. If we look at 3 transceivers connected on a bus line. It will be clear that if any switch is closed, the bus line becomes 0 state, if all switches are open, bus line become 1 status. Also, if the bus is in state 1 any node can overwrite this state to 0. This shows how the multi-master or broadcast system works but there are some considerations with this method: 

What if two control units send at the same time? 

Fault handling? 

In order to understand more clearly we will look at the send and receive process in more detail:

Example: Data Transmission

In this example we will look at the transmission of throttle position data to an ABS ECU. 

1. First the Engine ECU gets the throttle position value, this value is stored in the ECU microprocessor memory ready for transmission 
2. This data is then passed to the transmit mailbox of the CAN module, a electronic ‘flag’ is then raised to indicate that data is ready for transmission 
3. The data is then converted into a message in the correct format for transmission according to the CAN protocol. The main components of this protocol included in the message are: 

• Identifier – States what the message data is 
• Message content – Actual data value 
• Checksum – method or error protection 
• Acknowledge – Message acknowledgement 

In addition: 

• Other – start and end of frame messages, control message (size of data field) 
• CAN module checks that the bus is active and if necessary waits until it is free. When the bus is free, the data is transmitted by the transceiver. 

Fig 2 - CAN data transmission concept

Example: Data Receive

All nodes on the CAN bus receive the transmitted data at their transceivers. First the data is checked for errors and usability. This helps to detect local faults but still allows high data throughput on the bus. Using the checksum part of the protocol (CRC- Cyclic Redundancy Check) transmission faults can be detected. If no errors are found an acknowledgment is sent to the transmitter confirming reception of the data intact. The message is then processed in the CAN module and a decision is made as to whether that message is relevant to that control unit (or node). If so, the message is placed in the receive mailbox, otherwise it is discarded. When the receive flag is raised, the ECU microprocessor knows new information has arrived. This data is then copied into the input memory of the microprocessor ready for use. Data exchange is repeated cyclically according to the cycle time setting.

Error Handling

If several control units transmit data at once there would be collision on the bus. This is avoided by using bus arbitration with the following strategy. Every node starts its transmission by sending an identifier and all the nodes monitor the bus traffic. The identifier sets the priority of the message and the message with the highest priority is assigned first access to the bus without delay. Transceivers respond to failure to gain bus access by automatically switching into receive mode; they then repeat the transmission attempt as soon as the bus is free again.

The CAN protocol has an extensive error management system capable of detecting transmission errors with a high degree of certainty. Any node detecting an error can inform the other nodes via transmission of an error frame and the message can then be rejected by all nodes. Following this, an automatic re-transmission is executed and these are monitored. If these become frequent, a control unit can be automatically switched off to prevent bus traffic being impaired.

LIN

This is an acronym for Local Interconnect Network which is a technology that has been proposed and developed by a consortium of manufacturers including Audi, Daimler-Chrysler, Volkswagen and Volvo. It is a low-cost alternative to CAN where high bandwidth is not required (for example, comfort and convenience functions like window lift, central locking). The main difference between LIN and CAN is that bus access in a LIN network is controlled by a master node so that no arbitration or data collision management in the slave nodes is required. Note that LIN is implemented as a sub-bus and as such fully integrates with a vehicle CAN network. LIN is a complimentary bus system and is not designed as a replacement for CAN. It’s main application is where the throughput capability and versatility of CAN is not required.

Fig 3 - Typical applications for LIN bus

LIN bus is generally implemented as a single-wire serial communications protocol using simple UART hardware (which is available on most microcontrollers as standard). A particular feature is the self-synchronization in the slave nodes without crystal or ceramic oscillators. These two factors together significantly reduce the cost of the electronic hardware needed for interfacing to the bus.

The specification of the line driver and receiver follows the ISO 9141 single-wire standard (with some enhancements). The maximum transmission speed is limited to 20 kbit/s due to the requirements for electromagnetic compatibility (EMC) and clock synchronization. A node in a LIN network does not make use of any information about the system configuration, except for identification of the master node. Nodes can be added to the LIN network without requiring hardware or software changes in other slave nodes. The size of a LIN network is typically under 12 nodes (though not restricted to this), resulting from the fact that only 64 identifiers are available and also the relatively low transmission speed.

New Developments

Due to the rapid developments in automotive technology, faster, near real-time performance capability for data transmission networks will be essential (for example, drive or brake-by-wire systems). New bus systems are being developed and proposed for these applications. The leading technology is Flexray which has already been implemented in production (to an extent, on the suspension control of the BMW X5). This technology has been developed by a consortium including Volkswagen, BMW, Daimler-Chrysler, General Motors and Bosch

FLEXRAY

FlexRay has been designed to support the high-bandwidth needs of current and future in-car control applications. At the core of the system is the communications protocol. The protocol provides flexibility and performance and has the following features: 

• Time- and event-triggered communication schemes 
• High error detection and error diagnosis capability 
• Sophisticated power down and wake up mechanisms 
• Flexible extendibility and full scalability to enable upgrades 
• Collision-free bus access 
• Guaranteed message latency 
• Message oriented addressing via identifiers 
• Scalable system fault-tolerance via the support of either single or dual channels 

A hardware layer incorporating an independent bus monitoring feature provides further support for error management. The FlexRay system is targeted to support data rates of up to 10Mbit/sec with a gross of up to 20Mbit/sec possible. The system consists of a bus network and processors (ECU, electronic control units) similar to the CAN bus system. Each ECU has an independent clock. And these are frequently resynchronised to guarantee high performance. The Flexray network provides scalable fault-tolerance by allowing single or dual-channel communication. For security-critical applications, the devices connected to the bus may use both channels for transferring data. However, it is also possible to connect only one channel when redundancy is not needed, or to increase the bandwidth by using both channels for transferring non-redundant data.

Within the hardware layer, the Flexray protocol provides fast error detection and signalling, as well as error management via an independent Bus Guardian. The main benefits of:

• Provides up to 10Mbit/sec data rate on 2 channels, or a gross data rate up to 20Mbit/sec 
• Significantly increases Frame Length (compared to CAN – 8 Bytes per frame) 
• Synchronous and asynchronous data transfer possible 
• Guaranteed frame latency during synchronous transfer (deterministic performance) 
• Provides prioritization of messages during asynchronous transfer 
• Provides fault-tolerant clock synchronization via a global time base 
• Error detection and signalling capability 
• Enables error containment on the physical layer through the use of an independent bus guardian mechanism 
• Provides scalable fault-tolerance through single or dual channel communication 

Flexray has been specifically developed to support future requirements in the Industry and will become commonplace in the high-performance control systems mentioned above. In addition, it has the performance to support active and passive safety systems, collision avoidance and driver assistance systems.

CAN FD (CAN WITH FLEXIBLE DATA RATE)

The wide acceptance of vehicle serial communication buses like CAN, to more and more applications has led to requirements that the bandwidth for this serial communication needs to be increased. There are 2 factors that limit the effective data-rate in CAN networks, first the minimum bit length required for the CAN bus arbitration method and second, the relation between the numbers of data bits and other frame bits in a CAN message.

There is now an evolution of CAN to cope with this higher demand called "CAN with Flexible Data-Rate" or CAN FD. It is based on the CAN protocol as specified in ISO 11898-1. It still uses the CAN bus arbitration method, but it increases the bit-rate by switching to a shorter bit time after the end of the arbitration process, then returning to the longer bit time at the CRC delimiter (but before the receivers send their acknowledge bits). The effective data-rate is also increased by allowing longer data fields. CAN normally uses four bits as Data Length Code (DLC) resulting in 16 different codes, but generally, only the first nine values are used, codes [0 - 8] standing for a data field length of [0 - 8] bytes. In CAN, the codes [9 - 15] are defined to signify eight data bytes. In CAN FD, the codes are used to signify longer data fields.

So, there are two main differences between the CAN FD frame format and the CAN frame format, first the option to use frames with more than 8 data bytes and second the option to switch to a different bit rate after the arbitration is decided. Note that CAN systems can migrate gradually to CAN FD systems. All nodes in the network must have a CAN FD protocol controller for CAN FD communication, but all CAN FD protocol controllers are also able to take part in standard CAN communication. In the introductory phase, CAN FD communication may be limited to specific use cases or applications, e.g. software-download, while the other nodes that do not support CAN FD are kept in standby. If the CAN FD communication is limited to data fields with a length of up to eight data bytes, it is not necessary to change the application program apart from the initial configuration of the controller.

Read More