OpenECU is a development platform that supports Dana’s family of customizable off-the-shelf rapid prototyping ECUs suitable for use in vehicle prototypes, fleet trials, or volume production. The platform can be used to develop a range of applications including communications gateways, engine control, motor control, and Electric Vehicle (EV) or Hybrid Electric Vehicle (HEV) supervisory control.

OpenECU allows customers to develop control applications with production level Electronic Control Unit (ECU) targets using either Simulink® or C.

For higher-volume production, our off-the-shelf ECU’s may be cost-optimized, or we can develop custom controllers leveraging the OpenECU software platform. Dana also provides engineering services supported by a strong team of Systems, Controls, Software and Hardware engineers. Contact Dana to discuss specific requirements.

Application Development: Developer API

OpenECU products allow customers to develop their own software applications and retain Intellectual Property (IP).

The OpenECU platform software provides two distinct Application Programming Interfaces (APIs) for application development. For controls systems that use Model-Based development, OpenECU comes with the Simulink-API. This allows developers to use the Mathworks Simulink tool suite to implement their software. For customers who choose to develop their software in C, OpenECU provides a C-API. Both interfaces, C and Simulink, allow companies and their engineers to develop and retain their own designs and IP.

OpenECU Platform Software Architecture

Bootloader

The bootloader is the entry point when the Electronic Control Unit (ECU) powers up. It verifies the application and calibration images, and if valid, starts running the application. If an error is detected in the application or calibration image, or if a reprogramming request has been received, the bootloader goes into reprogramming mode where it aways reprogramming commands.

Vehicle ECU Reprogramming

OpenECU supports reprogramming over CAN via CCP and UDS protocols, allowing users to reflash a new application to the ECU with 3rd party engineering or service tools.

Real-time Operating System

OpenECU contains a real-time operating system (RTOS) for automotive embedded software supporting Dana controllers with microprocessor configurations. The OpenECU RTOS can support application tasks as fast as 1ms. Interfaces are provided to the application developer to monitor task timing and missed or over-run tasks. Applications can create tasks at different rates allowing optimization of CPU usage and resource utilization. The scheduler uses rate-monotonic task prioritization, where application tasks with the fastest periodic rate are given the highest priority.

Platform Library

OpenECU platform software provides an abstraction layer between the application and the underlying hardware. The application programming interface is consistent across all ECU’s in the OpenECU family of products so that applications may be easily ported and reused on any target ECU. Services available in the OpenECU Platform Libraries include CAN and LIN communications, UDS and J1939 diagnostics, time-based I/O, event-based angular I/O, non-volatile data storage and many more. Refer to OpenECU Technical Specification for more details.

The OpenECU library functions support a wide range of automotive ECU applications including gateway, motor control, Hybrid Control Unit (HCU), Vehicle Control Unit (VCU), or supervisory control. OpenECU provides a Simulink API to support model-based application development and a C-API to support applications written in C.

Development environment

The OpenECU platform provides a common development environment that can be used across all ECUs in the OpenECU product line. For model-based development, OpenECU integrates closely with Matlab Simulink. OpenECU library blocks are available from the Simulink library browser and OpenECU build options are added to the Simulink model configuration menu. Application developers can create a Simulink model, compile it, and generate the files necessary for flashing and testing an ECU, all with a single button click within Simulink. On some ECU’s, a free GCC compiler is provided for use in experimental or prototype development. For production applications, OpenECU supports 3rd party commercially available compilers such as Wind River’s Diab C compiler.

Automotive ECU Messaging and Communication

Automotive ECU Messaging and Communication

OpenECU provides the ability for application developers to define CAN messages in their application by either importing Vector database (DBC) files or constructing the message packets within the model. The platform also supports various industry standard protocols for diagnostic communications including ISO 11898 (CAN), ISO 14229 (UDS), SAE J1979 (OBD II), ISO 15765-2 (ISO-TP) and SAE J1939.

OpenECU supports CAN Calibration Protocol (CCP) allowing interaction with reprogramming and calibration tools. CCP is primarily a client/server-based protocol where a client, a calibration tool requests the server, the target ECU to perform a task or provide status information. During the application build process, OpenECU generates an ASAP2 (A2L) file which contains the memory addresses of variables and calibrations defined by the application. The A2L file can be used with automotive calibration tools like OpenECU Calibrator, ATI Vision, or Vector CANape for reprogramming, data acquisition, and runtime calibration.

Memory Management

OpenECU platform software performs management of non-volatile, adaptive and calibration memory. It handles storage of data parameters across power cycles and provide utility functions for adaptive data and maps for Non-volatile and adaptive memory. OpenECU platform software handles calibration memory, whether provided by dedicated on-board memory or attachable emulators.

OpenECU Software Architecture vs AUTOSAR BSW

OpenECU platform software provides many of the same capabilities as an AUTOSAR Basic Software (BSW) layer. Both architectures contain modular software components, many of which do similar things. However, they are designed with different goals and there are a few key differences that make OpenECU more suitable for use in general purpose off-the-shelf controllers.
In an AUTOSAR architecture every software component is configured for each ECU or end application. ECU’s that use AUTOSAR are typically single-purpose controllers designed for a specific type of application (for example an anti-lock brake controller). In the AUTOSAR workflow, all the BSW components are configured with knowledge of the Application Software’s (ASW) interface requirements. If the application’s interface requirements change, components of the BSW may need to be re-configured.

OpenECU is architected such that the platform software components can support all functions and hardware variants available on each target ECU. The ASW enables and configures the platform features it requires. This architecture design supports a broad range of applications and does not need to be changed for each customer or application. The boundary between the Application Software (ASW) and the platform SW is designed to give the application developer flexibility in how they use the inputs and outputs.

One example of OpenECU’s flexibility is in CAN message definitions. In OpenECU, the application defines all CAN messages and signals, the platform is completely agnostic of the configuration. With AUTOSAR, CAN messages and signals are configured in the BSW, and communicated to the Application via the RTE. The BSW must be configured for each application’s message set. Similarly, an OpenECU digital output may be capable of being used as an H-bridge driver, PWM output, or a discrete digital output. The application software can decide which mode to use without requiring any changes to the platform software.

Both OpenECU and AUTOSAR aim to provide portability. OpenECU does this by providing a consistent set of APIs across all our controller products. In many cases, applications may be easily ported from one OpenECU controller to another by simply re-mapping the IO channel selections in the Simulink API blocks. Applications developed with OpenECU may also be ported to other platforms like AUTOSAR by designing the application with OpenECU APIs separated from the control logic.