hello is category

Written by Gordan Jurasek, Director of Hardware Advanced Solutions, Dana

Evaluating the suitability of an OpenECU Electronic Control Unit (ECU) for use in your system as an embedded controller is best done in layers with the obvious and superficial screens done first to narrow the candidate pool to a limited quantity followed by the fine detailed requirements test on the narrower candidate pool.  Many times, an off-the-shelf module will meet the requirements but for cases where customization is needed, OpenECU is designed to accommodate a wide range of options.  The topics in this OpenECU evaluation series are:

 

How to Determine Which OpenECU is Suitable for My System: I/O

The first step in determining which OpenECU Electronic Control Unit (ECU) is most suitable is a simple matching of I/O capabilities to needs.

The tools I use daily to evaluate our ECUs for customer applications are the Pinout Templates for our line of OpenECUs.  You can have a look at them on the Dana Downloads Page.

M250 Pin out

The information needed to properly evaluate a match between an application and an OpenECU is the following from the perspective of each ECU pin:

Analog sensor inputs:

Digital switch inputs:

Frequency/duty cycle inputs:

Specialty inputs:

Outputs:

Sensor supply and 5V reference:

Serial bus communication:

What are the power modes of the ECU:

Written by Gordan Jurasek, Director of Hardware Advanced Solutions, Dana

As much as I would like (as an electrical engineer) to assume away any constraints presented by the physical world, there is no avoiding reality. Complicating matters is that some of the environmental conditions vary substantially with the operating modes. The operating modes, usage profile and conditions during each operating mode of the mounting location for the ECU must be collected. These consist of:

The demands of the mounting location can then be compared to the capabilities of the candidate ECUs.

All of this can be quite a daunting task and may not be generally available at the start of a new program.  Luckily for automotive applications there is a simple shorthand of a) in-cab, b) on-chassis (sprung), c) on-chassis (un-sprung), d) under-hood 105°C, and e) under-hood 125°C which have reasonably well accepted limits published in SAE and ISO standards and can be used for an early selection criterion and revisited when further application specific data is available as the program advances.

Note that operating modes are with respect to the overall system and not specifically the ECU.  So, for a controller in an Electric Vehicle the modes might be Off, Charging and Run.  For a pickup truck the Run mode might be further decomposed into Idle, Stop/Start traffic, Highway and Trailer Tow. The engine controller function might be nearly identical for Highway operation and Idle operation, but the air flow and thermal load is likely quite different.  It is these differences which need to be captured to make a full mapping of the usage profiles and the mechanical and environmental interfaces.

A good example of a 105°C on-chassis rated ECU is the Dana M220 OpenECU.

Open ECU M220

Production Variants – Customizing OpenECU hardware for specific system requirements or cost optimization
Dana offers a wide variety of off the shelf modules that can fulfill the requirements of a broad range of applications.  In some cases, there is a need to modify the off-the-shelf ECU to optimally work with specific sensors or actuators.  In other cases, only a portion of the I/O is utilized to meet the requirements.  In both cases, Dana offers the ability to customize existing off-the shelf ECUs to provide the most cost-effective solutions for production applications.   We refer to these customized ECUs as production “variants”.

What is a production variant?

A production variant of an OpenECU module is very similar to an option control, except the circuit population changes are done at the factory during production. See the Part I of this Blog, “Option Controls” for information on how Pi develops option controls. As a short summary, Dana can provide development units with circuit changes implemented in our engineering lab to meet the needs of a customer’s system. A production variant is designed to be used as a production ECU, instead of just a development unit. The production aspect can allow for cost savings and would be PPAP capable.

How is a production variant developed?

There are two main avenues for how a variant OpenECU can be developed. The first, which is the usual case, is that they start out as an option control. When a customer has been using option control units finds that there will be a need for many more modified versions of the ECUs (possibly because they are going into production), Dana will work with them to create a variant. At that point, the development work for the customer’s system integration is done and the ECU modification needs to be released to our factory to produce the units directly. After that, ordering new ECUs with the modification can be streamlined.

The second avenue is directly developing a production variant. Dana will work with the customer to specify the variant directly when needs for low to mid volumes are apparent. Specific requirements and needs will be discussed and Dana will work with the customer to come up with the best solution for their system. After specification, Dana will create engineering samples to be tested on system to avoid “gotcha’s” (surprise changes based on unknown system elements) before releasing the variant to be produced in volume at the factory.

Production variant vs. Option control

Production variants are normally created when volumes above 50 are needed. Option controls are usually only development units from 1 to 50 pieces.

Production variants are made directly at the factory, instead of being modified at Dana. Since production variants are built at the factory they usually can be lower cost than modified off-the-shelf ECUs. Cost savings are from reduction in hand modification after the SMT process and potentially from removing compements not needed from the off-the-shelf version. Also, production variants can go through the PPAP process, while option controls cannot.

Variants will have some associated NRE for development, testing, and releasing of the variant part build documentation, but the costs are offset by lower per-unit cost vs. option controls, especially for low to mid volumes.

How it has been done before:

See case-study “Providing a new production EV supervisory controller with a customized M560”

An engine misfire can be defined as a combustion event where the air fuel mixture within a cylinder fails to ignite properly. The most common causes of misfire are:

Misfire has a number of undesirable effects, including

Misfire and OBD-II

OBD-II regulations mandate the detection of misfire on all passenger vehicles. In most applications, the Engine Control Module keeps a count of the number of misfire events that occur over a moving window of engine revolutions. If the misfire count exceeds a threshold, a diagnostic trouble code is set.

Misfire Detection Using OpenECU

There are several ways to detect misfire. In this post, we will discuss misfire detection using the crankshaft position sensor. During a normal combustion event, the piston speed is lowest at top dead center on the compression stroke, and is the highest with the piston moving downwards during the power stroke. The average engine speed for a single engine revolution would lie in between the lowest and the highest instantaneous values. The difference between the lowest and highest engine speeds is significant enough that any deviation from the values expected during normal combustion can be used to detect a misfire event. If misfire occurs, the crank speed during the power stroke will be significantly lower as there is no downward force being applied on the piston head from combustion of the air fuel mixture. Figure 1 shows how the variation of instantaneous engine speed with crank angle for normal combustion and misfire conditions.

Figure 1 - Engine Speed vs Crank Angle

Figure 1 – Instantaneous engine speeds vs crank angle for normal combustion and misfire

 

The OpenECU Simulink blockset provides an easy way to calculate the engine speed during specific portions of the engine cycle using the crankshaft position sensor.  In the example shown in Figure 2, each instance of the Engine Speed block is used to calculate the average engine speed over a different portion of the engine cycle. The first block gives the average engine speed over 720 degrees of crank rotation. The second block calculates the “post-TDC” or highest crank speed and the third calculates the “pre-TDC” or slowest crank speed during the engine cycle. The tooth range is calibratable, which means that it can be easily adjusted in real-time to account for varying operating conditions, such as a change in the spark timing, which can affect the location of the fastest crank speed relative to the TDC of the cylinder.

The tooth ranges can be specified relative to the TDC of each cylinder, or relative to the missing tooth region of the crankshaft position sensor pickup wheel. Each cylinder will have its own pair of blocks to detect the maximum and minimum crank speeds. The speeds calculated by the OpenECU blocks can then be compared and a misfire event can be detected if the separation between the two indicates that the crankshaft did not accelerate during the power stroke.

Figure 2 - Misfire Simulink Model

Figure 2 – Example implementation of TDC relative engine speed measurement with OpenECU

 

The figure below shows the pre and post TDC engine speeds when misfire events are induced on a single cylinder engine using an ignition cut. The reduced difference between the pre and post TDC engine speeds clearly shows the misfire events.

Figure 3 - Actual Misfire Data

Figure 3 – Pre and Post TDC engine speeds during normal combustion and misfire

This article provides an overview of the hardware and software architecture of a sinusoidal field oriented controller for a brushless DC motor (BLDC).  Brushless DC motors are becoming much more common in automotive applications due to their improvements in performance, efficiency, and reliability over brushed motors.

A brushless motor has to be commutated electronically, meaning that power must be applied to each of the 3 phase windings at just the right time as the rotor spins.  This requires an inverter which is capable of controlling the voltage at each motor phase.  The inverter is driven by 6 PWM outputs from the microcontroller, controlling whether each motor phase is connected to power or ground.  In order to determine the correct PWM states, the controller needs to know the rotor position (angle).  This can either be measured with a sensor, or it can be estimated from current and/or voltage feedback from the inverter.  For field oriented control, current feedback is required regardless of whether there is a rotor position sensor.

The diagram below shows the major components of the BLDC control system.

BLDC architecture

The inverter controls each motor phase voltage with a pair of FET’s which can apply either power or ground.  The PWM outputs from the microcontroller are paired together such that one controls the high side FET and the other controls the low side FET.  The PWM pairs are operated together in a complementary switching scheme, where they are never both on at the same time.  The phase current can be measured through a shunt resistor on the ground side of the inverter circuit.  In this setup, current flows through the shunt resistor when the low-side FET is turned on.  The diagram below shows an example circuit for 1 leg of the inverter.  This circuit is repeated for the other 2 motor phases.

BLDC_inverter

There are many micro-controllers designed specifically for motor control which may have some or all of the following features:

The PWM outputs can be paired together to do complementary switching.  Since each motor phase is connected to 2 FET’s, they must be controlled as a pair.  Both FET’s must never be on at the same time; when one is on, the other must be off.

The PWM pairs have a configurable deadband between the complementary switch states. The deadband is a time delay between turning one FET off and turning the other on.  This prevents current shoot-through on the FET’s by preventing any overlap where both FET’s could be on simultaneously.

The PWM clocks can be synchronized with each other and center-aligned.  For a FOC system, the phase current is typically required on at least 2 of the 3 motor phases, and is measured through a shunt resistor on the ground side of the inverter circuit.  Since current only flows through the shunt resistor when the low-side FET is on, the PWM’s need to be aligned so that all of the current measurements can be sampled at the same time.

The ADC conversions can be triggered by the PWM clock.  This allows the feedback signals to be sampled exactly when current is flowing through the shunt resistors.

The diagram below shows an example of the complementary, center-aligned PWM signals which would drive the inverter.

BLDC pwm

The control algorithm transforms the motor phase currents to the reference frame of the rotor.  This transformation allows the sinusoidal phase currents to be controlled as DC quantities.  The two axes in this coordinate system are the direct axis, which is aligned with the rotor and the quadrature axis, which is perpendicular to the rotor.  The current vector of each axis is controlled independently, which allows the angle between the resultant vector and the rotor to also be controlled.  The q-axis controls the motor torque, the d-axis controls the motor flux linkage.  Maximum torque occurs when the resultant current vector is aligned with the quadrature axis (ie. Id = 0).

Since this whole control scheme is based on the rotor frame of reference, the rotor position estimator is the key component and it must be accurate.  One method of estimating the position is to use a back-emf observer.  As the motor speed increases, it creates a back-emf which produces a current that opposes that driven by the inverter.  A simple model of the motor can be implemented based on this equation.

BLDC_model

 

In the next part in the series we will more closely investigate how to estimate the rotor position with this equation.

 

CANopen is a CAN-based communication protocol. It comprises higher-layer protocols and profile specifications to exchange data between multiple devices on a network. Today it is used in various applications, such as medical equipment, off-road vehicles, maritime electronics, railway applications, and building automation.

OpenECU provides a reference design containing six blocks to implement a CANopen communication network. These blocks are used to configure the CAN bus, monitor CAN bus status, transmit, and receive CAN messages. The CANopen reference design is built upon the OpenECU Simulink blockset.

Communication

CANopen devices use several types of messages for communication, such as, PDO, NMT, SYNC and EMCY messages. Despite the differences at the application level, the standard CAN message format is always the fundamental structure for exchanging information. This enables OpenECU to use its existing CAN blocks to act as a master CANopen device and communicate with CANopen slave devices.

CAN communication between CANopen deivices

Typical CANopen System

The reference design model is used as an example to show how OpenECU can be used to realize communication and control of CANopen devices. This model has been validated in a motor control system which has a CANopen compliant inverter controller. OpenECU serves as the master controller and sends commands via CAN to the inverter, which acts as a CANopen slave, and provides feedback to the master. This configuration may be found in a hybrid or electric vehicle utilizing an inverter that uses the CANopen protocol.

CanOpen compliant motor control system

Example 1: PDO

Process data objects (PDOs) are used in CANopen for broadcasting high-priority control and status information.  For example, the master OpenECU controller uses PDOs to send motor speed mode commands to the slave the motor controller.  The slave motor controller in turn uses PDOs to feedback the actual motor status. A PDO consists of a single CAN frame and provides up to 8 byte of application data. The PDO objects need to belong to the CANopen object dictionary and both devices must have the same configuration.

CANopen PDO protocol

The reference design model sends and receives process data using OpenECU CAN blocks. Note that OpenECU CAN blocks use the Motorola byte order and byte reversal block may need to be applied.

OpenECU PDO process data transmit

Example 2: NMT

All CANopen devices must support the CANopen network management (NMT) state machine. The NMT state machine controls the communication behavior of a CANopen device. The CANopen NMT state machine consists of an Initialization state, a Pre-operational state, an Operational state, and a Stopped state. The NMT protocol is transmitted by the active NMT master in a CANopen network. The reception of the NMT protocol forces the CANopen device to transition to the commanded NMT state. The NMT protocol uses a single CAN frame with a data length of 2 bytes. It uses the CAN-Identifier 0x00, which is the highest priority CAN-ID in a CAN-based system. In the CANopen compliant motor control system, OpenECU as a master device manages network states through a state machine built in the reference model. The NMT command specifier is sent to the slave motor controller through the OpenECU CAN transmit block.

CANopen NMT protocol

Similar to the PDO protocol, an OpenECU CAN transmit block can be used to implement the NMT protocol as well. Instead of putting process data on CAN message, the command specifier and Node-ID need to be specified as the CAN message data.

OpenECU NMT transmit

In the reference design model, a masked NMT block is provided from the CANopen library. It gives the interface to enable message transmission, change modes, specify the node ID of the slave device being commanded, and set the node ID, and the rate at which to transmit the message.

Library block NMT

CAN DBC Support

OpenECU also provides CAN blocks that can use a .dbc file to specify the message ID’s and content instead of explicitly defining the message structure of each PDO message. The principle is the same, but these blocks provide access to the information using the textual names assigned in the database, making the model easier to create and maintain.

PDO transmit by OpenECU CANdb block

CANopen Communication State Management

In addition to the CAN blocks used to transmit or receive messages from CANopen slave devices, a communications state manager is required by the CANopen protocol. The reference design model provides a state machine that determines the NMT state which is required by all CANopen devices.

NMT state diagram of a CANopen deivice

As shown in the figure below the Stateflow chart on the left controls network states according to the requirements of the CiA 301.  While the the right side is implementing NMT protocol to transmit NMT data to slave device (Node-ID = 1) with OpenECU CAN block. Another example is application software calculates the target speed velocity and send to slave devices by PDO protocol.

Network management by application level software

Summary

OpenECU Simulink CAN blockset can implement several CANopen communication protocols without much effort. Pi provides a validated reference design model to demonstrate the methods. More complicated functions, e.g. network management, devices control and diagnostics, etc. can be implemented at application software level using Simulink blocks.

For more information on the CANopen standard please go to http://www.can-cia.org/can-knowledge/canopen/canopen/

By using digital communication, many sources of inaccuracies are eliminated as compared with traditional analog sensors, such as wiring resistance, circuit component tolerances, and A/D conversion gain and non-linearity errors.  Furthermore, more data can be placed on a single wire thus co-located such as manifold air flow and ambient air temperature sensors can use a single wire, thus saving on wiring harness costs.

One method of communication that is gaining popularity within engine sensors is SENT, also known as SAE J2716.  SENT stands for Single Edge Nibble Transmission protocol.  SENT uses the time between consecutive falling edges of a digital signal to encode a single nibble (4 bits) of data, where the longest time between falling edges represents binary 1111 (hex 0xF), and the shortest time between falling edges represents zero.

By encoding the nibbles using time, this allows for a high rate of data transmission at a lower cost than traditional serial communication.

 

Decoding a SENT signal

SENT messages typically have six data nibbles, allowing 24-bits of information to be transmitted per message.  It is common to have two 12-bit signals encoded in each message.  For example, an atmospheric temperature and pressure sensor may send the temperature in the first 3 nibbles, and the pressure in the second three nibbles.  The 24-bit message will then need to be split apart into the two signals using bitwise arithmetic.

In addition to the 6 data nibbles, messages contain a synchronization pulse, one nibble for status and communication information, and one nibble for CRC error detection.  The synchronization pulse is used by the receiver to calculate the exact bit-timing of the sender, thus making the system tolerant to small clock frequency differences between the sender and receiver.

 

SENT communication with OpenECU

To show how SENT sensors are handled with OpenECU, we will use a throttle position sensor from a modern production engine.  Our sensor uses all 24 data bits of the SENT message to encode the throttle position, and communicates with a nominal communication tick duration of 3.4 microseconds.  A typical message waveform from our throttle position sensor is shown in the following oscilloscope capture:

SENT communication scope trace

The OpenECU Blockset for M670 contains a SENT input block which handles all of the decoding of the SENT messages, including CRC checking and synchronization.  In our example, we extract the 24-bits of signal information, and convert the signal to a 0.0 – 1.0 number to represent throttle fraction:

SENT Simulink model using OpenECU

After building the model for the M670 and flashing the generated software onto an M670 ECU, the throttle position sensor could be easily viewed using a standard calibration tool.  A signal trace showing the throttle position using OpenECU Calibrator can be seen below:

SENT signal monitored in Pi Snoop scope

Further information on SENT, can be obtained through SAE in the J2716 standard document.  A brief overview can be found on Wikipedia.

PumpDiagram

The fuel rail pressure in a GDI engine is provided by a cam-driven variable stroke high pressure fuel pump. In typical designs, the volume of fuel pumped is controlled by a Flow Control Valve (FCV) located on the inlet of the pump. The valve is electronically controlled by the engine control unit to regulate fuel rail pressure. The operation of the FCV is unique because its control must be synchronous with the crankshaft position.  Typical GDI fuel pumps have three lobes per camshaft revolution that stroke the pump.  Fuel pressure is regulated by controlling the FCV during the stroke of the pump to regulate how much of the stroke is allowed to draw fuel into the pumping chamber.

Fuel enters the pumping chamber during the downward motion of the plunger through the open FCV.  The FCV opens during this time due to the valve being held open by the spring and the suction of the piston.  This results in a lower pressure in the pumping chamber as compared to the fuel inlet, and fuel flows into the chamber.

If the FCV solenoid remains de-energized during the upward stroke of the cam and plunger, the valve stays open due to the spring force, preventing the pump from developing pressure.  The GDI fuel pump thus delivers no fuel to the fuel rail.

If the FCV solenoid is energized during the upward stroke, the FCV closes and the low pressure inlet is sealed off from the pumping chamber.  This allows high pressure to be developed in the chamber.  Once enough pressure has been developed, the outlet check valve opens and pressurized fuel is delivered to the fuel rail.

The quantity of fuel delivered by the GDI fuel pump can be adjusted by controlling the exact moment in the upward plunger stroke that the FCV solenoid is energized. The earlier the valve closes, the higher the quantity of fuel delivered to the fuel rail.

TimingDiagramMIN

Fig 1: Zero Fuel Pressure

TimingDiagramMID

Fig 2: Mid-range Fuel Pressure

TimingDiagramMAX

 

Fig 3: Maximum Fuel Pressure

Typically, a relief path using a pressure relief valve is also present to prevent over-pressurization of the fuel rail. This relief path is not normally used for fuel pressure control. The relief pressure setting is set higher than the maximum pressure expected during normal engine operation.  Operating the relief valve in this manner results in higher engine efficiency through reduced fuel pump drive losses. For example, during a deceleration fuel cut, no fuel will flow out of the fuel rail because the injectors are disabled. In such a case, the FCV solenoid can be left de-energized and the rail pressure will remain at its previous set point without the fuel pump adding any additional fuel, thus saving pumping work.

GDI Fuel Pump Control Algorithm

To create a closed loop pressure control algorithm using an angularly driven GDI fuel pump we start with developing a traditional feedforward and feedback control loop.  Determination of the fuel rail pressure target is not covered here, but traditionally it is based upon engine speed and torque demand.

Dana uses model based controls implemented using the Simulink development environment and the OpenECU blockset to create all the control commands necessary for use with a GDI pump. The control algorithm implements the fuel rail pressure target, and performs closed loop control of the fuel pressure.

GDI fuel pump control feedforward

Fig 4: Feedforward & Feedback Control

If the actual fuel rail pressure is below the target, then the control effort is translated into a start of current angle for the FCV solenoid. This angle is specified relative to the TDC position of the fuel pump plunger. The higher the effort required, the earlier will be the ‘on-angle’ of the FCV solenoid. This transformation from effort to angular control is fully calibratable and can be characterized for different fuel pumps.

GDI fuel pump angular control

Fig 5: FCV Angular control

The duration for which the FCV is to be energized is also calculated based on engine speed and the target effort. The duration is not a critical parameter in GDI pump control. The FCV solenoid must be energized long enough so that enough pressure is developed in the pumping chamber to prevent the FCV from opening till the plunger begins its downward stroke.  By relying on the pressure in the pumping chamber to keep the FCV closed the on-time of the FCV circuit can be reduced which reduces current draw from the ECU and limits the heating of the ECU.

The ‘on-angle’ and duration are the used to calculate the ‘off-angle’ for the FCV solenoid, and these are fed to the OpenECU Simulink block.  The OpenECU driver software will schedule the angular tasks such that the FCV is energized and de-energized at the desired crankshaft positions.

GDI fuel pump pressure performance

UofMNewsletter