hello is category

Challenge:

Dana engaged with a large vehicle OEM to develop a custom ECU to be used on an autonomous vehicle demonstration fleet. All the OEM’s traditional suppliers refused to support the project due to the very aggressive timeframes.  The ECU played a critical role in the overall vehicle positioning system and had to meet the following requirements:

 

Solution: Custom ECU Development

With a stringent timeframe of 9-10 months and limited requirements defined at the start, Dana compressed execution and delivery of the Custom ECU by paralleling hardware and software development. This was accomplished by highly leveraging the OpenECU platform for hardware and software development to meet:

This required full ECU hardware customization, OpenECU software customization, and ECU Application Software leveraging Dana’s Model Based Controls Development expertise using Simulink.

V-Model Process

Dana utilized the V-Model process while accommodating customer defined processes to develop the Custom Embedded Controller based on the OpenECU platform.  Because requirements had not been established, Dana performed requirements solicitation for functional and safety requirements with a very large organization composed of a broad diversity of stakeholders.  Dana’s extensive experience in requirements capture and analysis was leveraged in a multiple workshops involving all customer stakeholders to ensure transfer of design intent and information. Dana developed the specification for the module based on the following:

All unique system information and interfaces were taken into consideration to ensure that the hardware, underlying platform, and application software were designed to the elicited specification.

Hardware development

Based on the hardware requirements, Dana performed the following high-level tasks:

Dana’s hardware engineering team also used key techniques for hardware development to determine validation workflow early on and reduce the number of PCB spins. These include the following:

OpenECU software

Concurrently, software engineers at Dana developed the platform software incorporating the customization needed for compatibility with:

Specific OpenECU platform software builds covering all software and firmware requirements were developed and underwent static code analysis using PC-lint to ensure compliance with MISRA standards, OEM standards, and ISO26262 guidance.

Application software

The software architecture was decomposed to work on two separate CPUs within the same module following safety analysis, DAR and ASIL decomposition.

The control engineers were able to leverage the OpenECU rapid control prototyping (RCP) platform in Simulink to develop the main application software for one of the CPUs of the custom autonomous vehicle ECU. Redundant rationality diagnostics were contained in a separate CPU using a different application written in C language.

Since this was a high-integrity ECU solution, additional verification and validation (V&V) was also performed for model-based application software through Software-in-Loop (SIL) testing using VectorCAST environment. Dana also executed black box and DV testing of the new ECU in parallel to prototype testing of A-sample ECU’s in-vehicle, enabling the OEM to conduct integration testing early in the program.

A rapid turnaround of concept design to first prototype was ensured using close partners and key suppliers. Dana ensured that the custom hardware and software designs were integrated in an efficient manner while ensuring full traceability and compliance to all applicable standards.

Results and Impact

The project resulted in a custom ECU, a high-integrity sensor module, that met customer specific requirements and automotive standards. By leveraging the OpenECU rapid control prototyping platform along with expertise in design, development and manufacturing of ECUs, Dana was able to successfully deliver the prototype module to the customer in the required highly compressed timeframe. This was accomplished while incorporating customer driven processes, standards, and adhering to the highest level of functional safety requirements, critical in applications like autonomous vehicles.

Project Features

Keywords: Autonomous Vehicles, Custom ECU, Custom Embedded Controller, Functional Safety, ISO26262, Hardware design and manufacture, Custom software development, Rapid Controls Prototyping, Demonstration Fleet, Validation Testing

Introduction

Traditionally, replacing an OEM engine ECU or Engine Control Module (ECM) has almost always been out of the question. OEMs exercise proprietary rights to the hardware and software design used for engine control. This can often cause an undesirable delay, or even lead to a complete halt on advanced engine research programs or testing of new components on a base engine. Often, automotive organizations looking to modify ECU behavior face a big setback due to lack of access to engine controls.

Dana has developed a systematic approach to replace OEM ECUs (ECM) allowing full access to software and calibration, for prototypes, advanced technology development, demonstration fleets, or low to medium volume production programs. This is established with a combination of Dana’s engineering team expertise and the OpenECU family of rapid control prototyping ECUs and software suite. OpenECU is implemented to volume production standards and offers an accessible platform for custom configuration, adaptation, and further development. The goal is to provide a baseline engine control to customers to allow them to focus on what they do best.

Dana's approach for OEM ECU replacement Figure 1: Dana’s approach for OEM ECU replacement

OEM ECU Replacement Process

1. Baseline the OEM ECU

The first step in this process is understanding the OEM ECU inputs and outputs, and mechanical configuration of the engine. Requirements capture related to characteristics of sensors and actuators is a critical step to confirm the compatibility of the engine system with the right OpenECU hardware. This is done using a customer questionnaire and preliminary review of available datasheets for different engine components. M670 is commonly used for engine control applications. M670 can also be customized to meet specific customer requirements.

In situations where data sheets for sensors are unavailable, and actuator characterization or trigger wheel patterns are not known, we use a bespoke break out box (BoB) and in-line connector setup allowing access to all the pins of the OEM ECU.

Setup for baselining the OEM ECU Figure 2: Setup for baselining the OEM ECU

This setup is then used to develop transfer functions for sensors, establish crank and cam patterns, and analyze output waveforms using dual instrumentation methods, oscilloscope measurements, etc. Important parameters are recorded to develop the baseline performance dataset. Some of the typical measurements made are:

A pin-out sheet to assign the available I/O to the relevant pins of the selected OpenECU module is drafted, which is the next step prior to model configuration and hardware-in-loop (HIL) testing.

2. Model configuration

Model-based control design (MBD) has gained significant momentum in the automotive industry to accelerate product development, while addressing the increased complexity of automotive systems, and reducing development time and costs. A rapid prototyping cycle is possible since MBD enables continuous simulation and verification of the control algorithm to allow early detection of errors, and the C-code is typically auto-generated which can then be deployed and tested on hardware.

At Dana, we have developed a model-based Generic Engine Control (GEC) strategy, which is accessible source code in the form of Simulink libraries (for both gasoline and diesel applications extendable to other fuel types such as LPG, CNG, etc.). These strategies are supported by documentation of the control architecture and software functional requirements for better understanding and knowledge transfer to the customer. The strategies can be used on OpenECU hardware to meet operating system needs. These strategies use floating point arithmetic and native Simulink blocks in the core of the application to allow for easier hardware target portability.

Within the model the crank, cam, and cylinder TDC configurations are appropriately set for the engine type. An application-defined sync logic based on crank and cam patterns is implemented to achieve engine sync. The OpenECU platform is designed in a way that allows software configurable waveforms for boosted/ non-boosted peak and hold injectors, saturating injectors and valves such as the fuel control valve, etc. that might require current controlled actuation.

The application is developed in a modular fashion and the required software modules can be integrated into the main model depending on the components involved in the application such as:

The application incorporates a balance of first-principle physics-based modeling as well as 1D and 2D look-up maps, to characterize the underlying behaviors of different engine components. Commonly used functions are maintained in libraries and re-used to accelerate development and improve overall software quality. For production intent software, Dana focuses on the development of a modular architecture, which is essential since the software will go through inevitable expansion and refinement.

The model-based design approach lends itself to easy testing of the logic using simulation to prove the concept before integrating it with the main model. Further testing such as Model-in-Loop (MIL) and Software-in-Loop (SIL) testing can also be performed depending on the rigor required for the program.

The base calibration data available either from the customer or captured during the baselining process is integrated with the software before moving to the next step.

3. Hardware-in-Loop (HIL) testing

A one-click build system results in C-code generation: an S-record (s37) or Hex-record (hex) binary file along with an A2L file are generated. The A2L file contains all the information about measurement and calibration variables available in the control software and is typically utilized with industry standard calibration tools to communicate with the ECU via CCP.

The binary file is flashed on the OpenECU hardware, and HIL testing is performed with individual engine components to test basic functionality. This form of testing is made easier using calibratable overrides throughout the model. Crank and cam signals are setup using the HIL simulator, and the ability to achieve engine synchronization is verified first. OpenECU’s rapid control prototyping toolchain allows changes to be implemented and available on-target within a few minutes. This is of advantage for cases where there is interfacing with new components that might require quick software changes. After engine sync is achieved, injector firing and the waveform is verified along with actuation of other outputs such as spark, ETC, valves, etc.

This step also serves to identify any hardware changes that might be needed. Often a sensor might not function appropriately due to a different impedance than what is expected, and in cases like these OpenECU’s capability to be customized for specific system requirements becomes highly relevant. At Dana, this is referred to as an ECU ‘Option Control’. Some common changes in an option control are changing analog input pull resistance, changing low pass filter frequency of a digital input, changing pull-up source on analog and/or digital inputs, etc. Dana is also able to add completely new functionality to an existing OpenECU module depending on the specific needs of the customers such as 6-axis IMU addition to the OpenECU M670, piezoelectric pressure sensor addition to M670, etc.

After the option control exercise is completed and the available components are tested manually on the bench, the pin-out details are fixed, and the wire harness is developed by the customer.

4. First Fire

For this phase, a team from Dana typically arrives at a customer’s facility of choice. A dynamometer is used for the initial commissioning and calibration. The ECU is installed with the wire harness. One of the first steps is to perform signal and wiring checks for all sensors and actuators. If no issues are found, various key-on plausibility checks such as coolant temperature, battery voltage, etc. are performed. Crank and cam sync are established by motoring the engine without any combustion activity. This critical step ensures that engine sync is achievable which is necessary for enabling angular outputs/ actuators during normal operation.

At this point, the sensor transfer functions are also validated, and calibrated further as necessary. On the actuator side, angular outputs such as fuel control valve are verified against baseline data. Injector waveform and firing are confirmed by monitoring injector current and fuel rail pressure. If applicable, closed loop fuel rail pressure and cam phasing control are also tuned.

Once the operation of all the components is confirmed, the baseline calibration is verified. As a result, the engine is now able to operate with a new ECU.

5. Steady state calibration development

This step is intended for progress towards better engine operation with the new ECU. Traditional calibration refinement and verification activity in collaboration with the customer’s calibration engineers is performed. Steady state calibration is confirmed for various critical sections such as fueling, spark timing, target AFR, and cam phasing.

To further match OEM steady state performance, closed loop fueling, boost pressure control, and engine idling is tuned as well. Steady state operation across the engine’s nominal speed range is established.

A considerable amount of engine calibration is required to achieve the best performance from the engine control strategies, and once the initial steady state calibration is brought up to a pre-established customer expectation, a hand-off to the customer development team is performed. A training workshop is typically conducted at the end of the project to help the customer’s engineering team better understand the capabilities of OpenECU, along with new technology evaluations and understanding any future scope. Dana engineers train customer engineers while working alongside them to ensure the transfer of knowledge for full ownership.

CONCLUSION

OEM ECU replacement can be a tedious and complicated process. It can significantly affect advanced engine research programs, and customers looking to modify ECU behavior. With the OpenECU family of rapid control prototyping ECUs, and Dana’s expertise in system development and integration, you can accomplish ECU replacement seamlessly and in a short time frame.

Dana’s staged approach has been utilized in numerous engine programs. Dana can provide hands-on support with efforts ranging from commissioning and training on the OpenECU platform, through to providing full control software, hardware, and calibration, while being cost-effective and flexible.

To find out more about how Dana can help your organization replace an OEM ECU, develop a new prototype engine controller, or take your product from prototype to production, visit openecu.com or email info@openecu.com for more details.

Written by Mike Lepkowski & Ray Hyder

Option controls – Customizing OpenECU hardware for specific system requirements

Most systems require specific interfaces between controllers and sensors or actuators. While OpenECU has been designed to support a variety of sensors and actuators it can support an even larger variety of sensors through small changes to hardware in the ECU itself. Dana calls this modification an option control which uses one of our off-the-shelf OpenECU modules.

Option controls are best for customers developing prototype and low volume production systems where an existing OpenECU product meets most system needs but details of the interface between OpenECU and sensors/actuators require hardware changes. The most common option controls are changes to analog input circuits which allow OpenECU to exactly match the sensor interface as the sensor’s manufacturer requires.

Dana will work with you to define your requirements and come up with the best modifications to suit your application.

Open ECU

Which option control is needed for your application

Dana will work with you using our “Options and Variants” document that describes the default population of each pin on the module and the range of configurability that is available with an option control. Dana engineers will assess the compatibility of the customer’s I/O requirements with the default population of OpenECU and identify any areas where the default hardware configuration isn’t quite right for the system. Once those gaps are identified, Dana creates a custom option control which will configure OpenECU to be a perfect fit for the customer’s system needs/interfaces. Some examples of common changes in option controls:

More advanced option controls

For customers with more specific needs, Dana may be able to add totally new functionality to an existing OpenECU.  Some examples of specific functions added for past option controls:

Option control example

Recently on the M560, Dana worked with a customer to define their needs.  The identified change was fairly small and made all the difference in making the M560 a perfect fit for the customer’s application.  A digital input that was ranged for battery level 0-16V needed to be used as a 0-5V input. A change to the filter frequency was also identified as necessary to be compatible with the expected frequency of the sensor. Originally, the input had scaling for battery level inputs and was filtered for low-frequency inputs (25Hz). The scaling was changed to work with 0-5V PWM input and the filter frequency modified to work with 500Hz. This option control is now purchasable by the customer as the M560-00F.

What are you working on?

If you are not able to find an off-the-self controller solution to meet all your system’s needs Dana may be able to help with an option control for OpenECU.

The difficulty with diagnostics is in the definition.

The answer is usually “yes to all the above”.

Basic Pin Diagnostics:

For most embedded control systems, the minimum price for entry is basic short circuit and open circuit diagnostics for all outputs. Inputs are more nuanced as the valid states for a typical switch input are “open circuit” and “short to battery” or “short to ground”. Fully diagnosable switch input circuits require switches which transition not between open and closed, but rather between two distinct closed states (distinct resistances to battery or ground) and are diagnosed with an analog voltage measurement. Measuring the analog voltage at the pin and comparing that to the expected voltage given the currently assumed system state is typically at the core of basic robust pin diagnostics. For more constrained systems or lower diagnostic intensity a simple digital monitor can often provide enough information, and in instances where frequency-based signals are expected, the ability to measure in the time domain may prove useful. The entire OpenECU product line has at least the basic pin diagnostics as a starting point.

Output Driver Diagnostics:

Output drivers have an idle state and an actively driven state (or potentially two actively driven states for H-Bridge outputs). The basic pin diagnostics needs to be cognizant of the possible valid pin states and the current commanded state. Do the diagnostics require detection of faults regardless of the commanded state? Do the diagnostics require detection of intermediate faults (not a short to battery/ground but an over current condition which could be caused by a short internal to an inductive load)? These diagnostics start with the pin state monitor (typically analog voltage for low speed circuits and possibly a digital input into a timer channel for frequency or PWM signals) and then diagnostic application code needs to be written to make sense of the pin state data. This diagnostic application code is usually tightly coupled to the control application, as the interpretation of the pin state data is highly dependent upon the expected state, which for outputs is determined by the control application. The output driver diagnostics provided by the OpenECU product line combined with the basic pin diagnostics enable the higher-level diagnostics to be constructed in the application.

Rationality Diagnostics:

Rationality diagnostics are not faults that drive signals out of their expected ranges, but more typically a set of input values that together do not match with a rationally expected physical system, e.g. the air/fuel ratio sensor reads lean mixture even at full fuel pulse duration and partial throttle. These diagnostic applications typically require substantial knowledge of the physics of the system under control, and usually need a large engineering effort to calibrate the thresholds between normal operation and faulted state. Quite often these applications require that data be stored from repeated operating cycles of the system.

Functional Safety Associated Diagnostics:

Functional safety associated diagnostics are more a mindset than a separate category of diagnostic type, involving diagnostics of faults/failures that do not directly cause an issue with a required function (input or output), but rather with a safety measure. If your system has functional safety associated controls, then an analysis is required where the ECU design is reviewed in light of the system safety goals, and the diagnostics must be reviewed to confirm that any fault that could violate the safety goals can be detected.

It is important to understand that even full-featured ECUs like the OpenECU M560, which have extensive diagnostic capabilities, will likely require application development to implement higher-level system diagnostic functions. Development of these system-level diagnostic functions for ECUs requires knowledge of the measurements and modes available on the ECU, in addition to the behaviors and details of the system under control. Dana’s extensive OpenECU documentation provides the necessary detail for systems engineers to develop these diagnostics.

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.