hello is category

Summary

OpenECU®, Dana’s product line of off-the-shelf rapid control prototyping ECUs support integration with TargetLink. Users can import TargetLink subsystems into OpenECU Simulink models. Developers and test engineers can evaluate, and test algorithms developed with TargetLink on OpenECU hardware for fleet trials.

OpenECU Block

OpenECU integration has been simplified with the development of TargetLink Integration block available in OpenECU Developer Simulink-API.

The OpenECU TargetLink Subsystem block allows for easy import of production code from a subsystem developed in TargetLink.

The TargetLink model name, subsystem name, and input/output ports are specified in the block interface. One button causes the block to configure itself to have the specified interface. Another button launches the TargetLink code generator to generate production code for the TargetLink subsystem, imports the production code into the model at the block location, and imports the TargetLink data dictionary entries into the Simulink data dictionary.

Block Parameters

TargetLink Model

Press the “Browse…” button to browse for the model file. When the browse button is used, you will be prompted to select which subsystem from the TargetLink model file that you wish to import. All mask parameters will be automatically populated from the selected TargetLink subsystem.

TargetLink Subsystem Name

Enter the name of the TargetLink subsystem in the TargetLink model that you wish to import.

Input Port Names

Enter the names of the input ports for the block interface, separated by commas.

Output port names

The names of the output ports for the block interface, separated by commas.

Update Block Interface

Clicking this button will update the interface of this block. Input ports will be created according to the “Input port names” parameter, and output ports will be created according to the “Output port names” parameter. Note that clicking this button will disconnect the block from the rest of the model as the block is re-drawn.

Start Import

Clicking this button will import TargetLink production code into the model at the current block location.

The TargetLink code generator is launched to produce production code from the TargetLink subsystem. All data entries in the TargetLink data dictionary associated with the selected TargetLink model will be imported into the Simulink data dictionary.

TargetLink Versions Supported

Currently, TargetLink version 4.4 (2018-B) has been tested and is supported. Newer TargetLink versions are expected to be compatible but have not been fully tested.

Refer to OpenECU Sim-API User Guide for more details or contact Dana at support@openecu.com or bd@OpenECU.com

Dana is proud to publish this whitepaper on Model-Based Design and OpenECU written by Arnav Gupta, System Engineer at Dana. Below is the summary of the whitepaper.

This whitepaper discusses the challenges faced by engineers while developing embedded control systems and focuses on software specific considerations within the model-based design (MBD) paradigm. It also sheds light on hardware considerations and highlights how an electronic control unit (ECU) development platform such as OpenECU®, can provide the complete solution for embedded controls development.

Today’s vehicles contain a complex technical infrastructure of various integrated systems. They have evolved from an aggregate of systems of mechanical components to systems with embedded electronic controls. Because of this evolution, embedded control systems are an integral part of vehicles today and even components such as traditional hand brakes are evolving into electronic parking brakes (EPB). While the traditional handbrake is simple and functional, an EPB enables additional functions such as automatic hill-hold and automatic brake-hold at stoplights. Additionally, it also frees up the space in the center console area contributing to interior aesthetics and enhances vehicle security, as the brakes can be locked when the vehicle is turned off and only unlocked with an authorized electronic key. With the traditional handbrake, information on failures is not available to the user, but electronic systems enable this – increasing both active and passive safety.

Download here for entire Dana Whitepaper


The M220-XAU is a unique variation of the M220 controller, specifically designed to be the master controller in applications using the S090 as a slave power driver box. This variation of the M220 provides inputs and outputs unique to motor control to seamlessly interact with the features of the S090 which include control of both a brushed and brushless DC motor.

The S090 is a versatile solenoid and motor drive slave power driver box optimized to support engineering development programs for the electrification of vehicular systems. It is designed for any system that uses PWM controlled actuators (valves, solenoids) and/or DC motors (brushed, brushless). It is an ideal solution for the most demanding actuators, capable of producing a total of 40A across its outputs.

The combination of the M220-XAU with the S090 makes motor control simple by taking advantage of the M220’s existing VR sensor inputs and modified digital inputs, improved for high-frequency measurement.  Software applications for using the M220-XAU as a master controller are streamlined with the availability of PWM outputs with synchronous sampling from the S090, providing feedback for measuring average motor line voltage, and decoders for measuring quadrature and 3-phase hall effect sensors.

Software Features include:

PWM outputs with synchronous analog inputs allow analog input signals (feedback from the S090’s motor drivers) to be read synchronously with the output waveform of the PWM control outputs of the M220. This analog input can be used for reading the average voltage for one of the 3-phase BLDC control lines.

The quadrature decode and frequency input provide a count of edges on the quadrature encoder since the last software iteration. This can be used to determine the encoder position or velocity.

This feature also provides the channel frequency for both the primary and secondary encoder sensors.

The hall decode input measurement decodes the signals from a 3-phase hall input, such as from a BLDC motor. This is compatible with 60° and 120° spacing configurations. This allows for accurate and consistent tracking of the motor angle in addition to speed, direction, and number of revolutions. This is often used to track the actuator position where the stop-to-stop motion requires several rotations of the motor.

Use Case

A Dana customer used the S090 for a high torque BLDC application for cold engine testing. The BLDC outputs of the S090 were used to drive an electric cam phaser. The master controller reads the speed of the internal combustion engine and subsequently commands the S090 to set the BLDC motor to the desired cam phaser position.

Proposed Pinout

The schematic below shows an example pinout of the M220-XAU paired with the S090.

Motor Drive Control Box

Overview

Hexagon Studio was founded in 2005 with a vision to provide design and engineering services implementing turnkey solutions primarily in the automotive sector. The Hexagon Studio facility has been registered as an “R&D Center” by Ministry of Industry and Technology (Turkey) since 2011.  A primary focus is electric vehicle integration and control software applications.

Dana’s OpenECU platform has been used in a range of EV/HEV projects and is currently in use by Hexagon Studio in several capacities. Erinc Topdemir – Technical Lead Engineer, R&D Center, Hexagon Studio shared reasons why they like using OpenECU:

Vehicle Projects using OpenECU

Hexagon Studio’s Product Development System was used as a basis for systems engineering and requirement management in the following projects:

Wheelchair accessible taxi

The M250 OpenECU was used in a plug-in-hybrid taxi vehicle project as a vehicle controller. Dana supplied an EV & HEV control strategy including sample application and a generic requirement list for this program. By leveraging the Dana vehicle control strategies, Hexagon Studio was able to quickly develop a prototype vehicle.  Torque, energy and thermal management strategies were added to provide control for features such as charging, discharging and regenerative braking.

EV Low-floor minibus

Hexagon Studio has used both the M670 OpenECU, and the M560 OpenECU  for a low-floor minibus. The minibus is used as a public transport vehicle with an integrated wheelchair ramp for both the North American and the European markets. With the know-how and experience gained from previous projects, Hexagon Studio developed their own control algorithms based on customer requirements. The range extender control algorithm was developed to meet emissions requirements and has separate charge/range sustaining modes. The project evolved into a full EV by request of the customer in later stages.

Plug-in Hybrid Electric Vehicle (PHEV) Work Truck

The M670 OpenECU was used as the vehicle controller for the PHEV work truck.  The PHEV with a 2-cylinder range extender was specifically designed to meet stringent work truck requirements to serve as a last mile package delivery vehicle for the North American market. This vehicle has both 2WD and 4WD options, and two body lengths. Hexagon Studio delivered multiple prototypes to the customer for durability testing and real-life delivery operations. This program also evolved into a pure EV and is now being prepared for production launch.

EV Three-wheeler cargo and passenger vehicle

The M110 OpenECU is used for the three-wheeler vehicle controller design. The 48V design includes special component selection and control. This vehicle is targeting last mile urban delivery applications where zero emissions and quiet operating performance are needed.  Hexagon Studio leveraged EV control strategies developed on other programs to implement an optimized subset of strategies appropriate for this 3-wheel application.

35-foot EV Bus

M580 OpenECU is used in this full EV bus development. This project is based on a 650V architecture to enable the usage of readily available HV (High Voltage) components. Dana OpenECU modules are used for both VCU (Vehicle Control Unit) and as a gateway unit for combining components and supervising their controllers.

For all these projects, Hexagon Studio was responsible for implementing algorithms for vehicle traction, thermal management, charging control, energy management and component controls including traction inverters, DC/DC converters, and HV batteries. Electric vehicle Control Strategies were developed in Matlab/Simulink and validated with PIL (Processor-in-the-Loop) and HIL (Hardware-in-the-Loop) tests before starting the final validation on the prototype vehicles.

Some special features were designed and implemented for differing customer expectations and vehicle usage scenarios. The following solutions are offered depending on the customer’s requirements.

Solution

All of the Dana modules mentioned above have been used in testing vehicle control applications with a HIL device. Hexagon Studio is also capable of designing and incorporating into the HIL any kind of vehicle dynamic and all the main vehicle components. Performance and energy management calculations, functional tests, reliability checks and even design validation and durability tests are done with the help of these configurations. HIL testing at Hexagon Studios can use any of the Dana products covering all application types, vehicle types, and component functions.

Regardless of the hardware and project, fault diagnostics are also developed with OpenECU libraries. UDS, ISO-TP and ISO diagnostic algorithms are developed and integrated into the main control algorithm.

Introduction

With the increase in vehicle electrification and autonomy, electronic control units are now subject to rigorous functional safety standards such as ISO 26262.  Functional safety is defined by ISO 26262 as “the absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical and electronic systems[1].”

Malfunctions are broadly grouped into two categories: random faults and systematic faults.

The architecture of an electronic control unit establishes the likelihood for and ease of management of these two types of faults. Modern electronic control units can take advantage of several microcontroller architectures with different approaches to managing random and systematic faults. The main goals of any microcontroller architecture with respect to functional safety are:

  1. Manage random hardware failure in the microcontrollers
  2. Manage systematic failure in the hardware design
  3. Assist in managing systematic failure in the associated software

 

ECU Functional Safety Architectures

The two dominant controller architectures for electronic control units are:

  1. Multiple microcontrollers in separate packages
  2. A single microcontroller package

 

Multiple Microcontrollers in Separate Packages

Multiple-package architecture with diverse redundancy architecture utilizes two separate, physical microcontrollers working in concert to provide functionality and functional safety. The separate packages allow the selection of two different microcontrollers to provide diverse redundancy through different design and manufacturing.

This architecture can also support fail-operational behavior since a failure of one package may not prevent the other package from providing some degraded function. Since the microcontrollers are separate they can be powered by two independent power supplies to provide additional redundancy. The tradeoff is higher electronics complexity, typically larger footprint, and typically higher unit cost.

A Single Microcontroller Package

The single-package architecture is made possible by recent automotive microcontrollers that provide features such as lockstep cores (two redundant CPUs running the same code at the same clock rate with one delayed some clock phases with their results compared for consistency) and multiple cores (often with diverse design) in the same package.

This provides protection for many random hardware failure modes in a smaller hardware footprint which often has part cost benefits over multiple-package designs. Single-package architectures also generally require an external watchdog; increasingly these are being included in “smart” power supplies so there is no additional part count. However, the single package carries higher risk of dependent failures within the single package and is more limited in fail-operational use cases.

Comparison

The following section compares these two architectures in more detail

Robustness to Random Hardware Failures

Both diverse redundancy and modern lockstep-core + multiple core microcontrollers provide excellent protection against random hardware failures, both transient and permanent. Lockstep cores provide this checking with very little software overhead, while the diverse redundancy approach requires application software and communications protocols which can be a significant development effort.

Robustness to Systematic and Dependent Failures

Dependent failures are any failures that are not statistically independent. These are typically systematic faults even though they may have a probabilistic occurrence.

Hardware

Diverse redundancy is still the standard for minimizing dependent failures; two microcontrollers in separate packages with different design and manufacturers have very few opportunities for dependent failure. Independent packages are also less susceptible to the increasing threat of cybersecurity side-channel vulnerabilities such as timing-based attacks or privilege escalation.

Single-package architectures have greater opportunity for dependent failures due to manufacturing, common design of duplicated sub-components (for example, if lockstep cores are identical), and physical proximity.

Software

Lockstep cores cannot protect against systematic software fault concerns since the same software is run on both cores; Put another way: lockstep cores only cover hardware failure modes. This means that the processes for developing software on a lockstep core must still be performed to the highest applicable ASIL.

Most microcontrollers targeted for functional safety applications include additional CPU cores which are not lock-stepped in the same package to provide co-processing / checker capability. These cores are often of a different implementation architecture from the lockstep core, but care must be taken to ensure that there are no common sources of failure such as a common compiler.
For both single- and multi-package architectures that use co-processors or checker cores, the development of the software for each core should be performed by separate teams. Independent implementation, verification, and development tools such as compilers minimize the possibility for systematic errors.

Coexistence of Elements and ASIL Decomposition

Microcontrollers for both multiple- and single-package architectures are available with hardware-based memory protection units which can support partitioning of software.

A single-package design relying on memory protection hardware features requires the portions of software responsible for managing that memory protection to be developed to the highest ASIL.

Dual microcontroller designs, however, allow full decomposition of all software. For instance, it is possible to decompose all software two-micro system to ASIL B(D)+B(D), including for the operating system, because the two microcontrollers can provide redundant, independent coverage of the system safety functions.

Confidence in the use of software tools

Although the compilers for both microcontrollers in a separate-package architecture must be subject to software tool evaluation, the use of different compilers eliminates a source of systematic error since different compilers for different microarchitectures will not be subject to the same failure modes.
Since the software running on each core can be developed to a decomposed ASIL, savings can be realized in the tool qualification efforts to that decomposed ASIL.

Summary

Both the diverse-redundant multiple-package design and the single-package multiple-core designs can satisfy the functional safety demands of modern control units.

Multiple-Package Architecture Single-Package Architecture
Dependent Failure Robustness Higher Lower
Part Cost / Footprint Larger Smaller
Safety Analysis Effort Lower Higher
Software Implementation Effort Higher Lower
Tool qualification efforts Lower per tool, but more tools Higher per tool, fewer tools

The OpenECU M560 and M580 vehicle controllers from Dana incorporate the Multiple-Package, diverse redundancy architecture, making them a compelling choice for low to medium volume projects with aggressive development schedules.

[1] ISO 26262-1:2018 Clause 3.67

[2] Adapted from ISO 26262-1:2018 Clause 3.118

[3] Adapted from ISO 26262-1:2018 Clause 3.165

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.