New platform integrates dual charging protocols and full supervisory control to simplify EV system architecture

LAS VEGAS–(BUSINESS WIRE)–ACT EXPO 2026—New Eagle™, a leader in embedded control systems for intelligent vehicles and machines, today announced the launch of the OpenECU™ NX3, a next-generation control platform designed to simplify electrified vehicle architectures by consolidating charging and supervisory control into a single ECU.

Leveraging expanded hardware, software, and engineering capabilities from the recent acquisition of Pi Innovo, the NX3 extends New Eagle’s unified Raptor® and OpenECU platform, enabling new levels of system integration, scalability, and development efficiency across electrified vehicle programs.

The NX3 is the industry’s first single-controller solution combining Megawatt Charging System (MCS) and Combined Charging System (CCS) protocols with full vehicle supervisory control, eliminating the need for multiple controllers and significantly reducing system complexity, wiring overhead, and failure points.

“The OpenECU NX3 is designed to simplify vehicle control systems architecture,” said Kevin Alley, chief commercial officer at New Eagle. “We’re eliminating multi-controller complexity and delivering a single, production-ready platform that accelerates deployment of next-generation EV systems.”

As commercial EV platforms scale, traditional multi-box architectures are driving unnecessary cost, wiring complexity, and integration risk. The NX3 addresses these limitations by enabling OEMs to consolidate key vehicle functions into one production-ready controller.

Built on the OpenECU platform and integrated with New Eagle’s Raptor toolchain, the NX3 enables seamless development from model-based design through production deployment.

Key capabilities include:

• Dual-Inlet Charging Control: MCS and CCS support from a single ECU, eliminating redundant controllers
• Full Vehicle Supervisory Control: Integrated management of powertrain, charging, and auxiliary systems
• Production-Ready Safety & Security: Designed to meet ASIL-D functional safety and ISO 21434 cybersecurity requirements
• Flexible Development Environment: Support for model-based development and C-code workflows

The NX3 is part of a broader portfolio expansion enabled by New Eagle’s acquisition of Pi Innovo, strengthening the company’s capabilities across hardware, software, and engineering services.

Together, New Eagle and OpenECU deliver a unified platform that supports a wide range of applications—from early development through production—across electrified, hybrid, and clean fuel vehicle programs.

In addition to the NX3, New Eagle is introducing new charge control and driveline solutions, including the Charge Control Unit (CCU) and DLC-12, expanding its portfolio of scalable, production-ready controllers for electrified vehicle systems.

The NX3 and broader OpenECU platform will be showcased at ACT Expo 2026 at the New Eagle booth (#3205).

The OpenECU NX3 is available now. Please contact sales@neweagle.net for more information.

About New Eagle

New Eagle is a leader in embedded control systems for intelligent vehicles and machines, providing a unified platform of hardware, software, and engineering solutions that simplify development and accelerate time to production. Powered by the Raptor® toolchain and expanded OpenECU™ portfolio—strengthened through the acquisition of Pi Innovo—New Eagle enables OEMs and Tier 1 suppliers to build scalable, production-ready systems across electrified, hybrid, and autonomous applications. Learn more at www.neweagle.net.

Expanded New Eagle and OpenECU portfolio highlights scalable hardware, software, and partner ecosystem for next-generation commercial vehicles

ANN ARBOR, Mich.–(BUSINESS WIRE)–New Eagle™, a leader in embedded control systems for intelligent vehicles and machines, today announced it will showcase its most comprehensive platform to date at ACT Expo 2026, May 4 – 6 at the Las Vegas Convention Center (Booth #3205).
At its first major industry event following the acquisition of Pi Innovo, New Eagle will present a unified portfolio spanning Raptor® software, OpenECU™ hardware, and integrated engineering solutions, demonstrating how OEMs can accelerate development across electrified, hybrid, and internal combustion vehicle programs.

As commercial vehicle systems scale in complexity, fragmented architectures and disconnected toolchains are becoming a primary bottleneck to development speed, integration, and deployment. New Eagle addresses this challenge by delivering a complete, production-ready platform that unifies control software, embedded hardware, and real-world deployment expertise.

At ACT Expo, New Eagle will showcase more than 30 production-ready products and integrated systems spanning its combined Raptor and OpenECU portfolio, including:

• Core Control Platforms: Raptor and OpenECU development environments enabling model-based design, rapid prototyping, and production deployment
• Production ECUs and Displays: Broad lineup of controllers and operator interfaces supporting electrification, driveline control, alternative fuels, and vehicle systems
• Connected & Intelligent Systems: John Deere VPU2 platform integrating ADAS, real-time processing, and edge compute capabilities
• Integrated Vehicle Systems: End-to-end demonstrations combining controllers, software, and partner technologies in real-world applications

In addition, New Eagle will highlight its expanding ecosystem through collaborations with John Deere, Bosch, ETAS, Veethree, and Helix, demonstrating how integrated partner solutions accelerate system development and deployment.

“ACT Expo marks a major milestone for New Eagle as we bring together our expanded portfolio into a single, unified platform,” said Kevin Alley, chief commercial officer at New Eagle. “By combining Raptor and OpenECU, we’re expanding what customers can build and how quickly they can bring it to market, across development, integration, and production.”

The showcase will focus on real-world applications across commercial vehicles, off-highway systems, electrified platforms, and alternative fuels, reinforcing New Eagle’s role as a scaled, end-to-end provider of embedded control solutions.

New Eagle will also host a joint networking event with ETAS during the show, providing customers and partners an opportunity to engage directly with engineering teams and explore collaboration opportunities.

About New Eagle

New Eagle is a leader in embedded control systems for intelligent vehicles and machines, providing a unified platform of hardware, software, and engineering solutions that simplify development and accelerate time to production. Powered by the Raptor® toolchain and expanded OpenECU™ portfolio—strengthened through the acquisition of Pi Innovo—New Eagle enables OEMs and Tier 1 suppliers to build scalable, production-ready systems across electrified, hybrid, and autonomous applications. Learn more at www.neweagle.net.

We are pleased to announce a new release of the OpenECU Functional Safety Developer Software. OpenECU FuSa was developed according to ISO 26262 for use on the M560 and M580 targets. For detailed information on functional safety, request the M560 Family Functional Safety Manual.

Users of M560 and M580 ECUs are encouraged to upgrade to this version as soon as possible to take advantage of the new features and fixes therein. Release 3.5.0 includes new features, fixes and improvements, some of which are briefly described below.

Click here to download

Please note that existing customers will need to contact support for an updated license. If you do not have an existing support contract, please contact Dana Novi Technology Center for a quote.

New Support & Features

New features introduced by this version, or significant changes to existing features.

Third party tool support

OpenECU builds on, and utilizes, various tools from third parties, including C compilers, calibration tools and operating systems. See the third-party tool requirements section of the full User Guider documentation for a complete list of required and options software, and the versions supported.

• Added support for MATLAB R2025a for M5XX targets, removed support for R2015b, R2018b, R2020a, R2021b, and R2023a

Communications

• Added support for diagnostic response override to the Simulink API
• Updated CAN messaging and CAN database file (CANdB) handling in both Sim-API and C-API

Fixes and Improvements

• User documentation improvements

Learn more on more fixes and improvements in the release note.

We are pleased to announce a new release of the OpenECU Functional Safety Developer Software. OpenECU FuSa was developed according to ISO 26262 for use on the M560 and M580 targets. For detailed information on functional safety, request the M560 Family Functional Safety Manual.

Users of M560 and M580 ECUs are encouraged to upgrade to this version as soon as possible to take advantage of the new features and fixes therein. Release 3.4.0 includes new features, fixes and improvements, some of which are briefly described below.

Click here to download

Please note that existing customers will need to contact support for an updated license. If you do not have an existing support contract, please contact Dana Novi Technology Center for a quote.

New Support & Features

New features introduced by this version, or significant changes to existing features.

Third party tool support

OpenECU builds on, and utilizes, various tools from third parties, including C compilers, calibration tools and operating systems. See the third party tool requirements section for a complete list of required and options software, and the versions supported.

• Added support for MATLAB R2024a
• Added support for Simulink ASAP2 generator (R2021b and greater)
• Added support for Wind River Diab C Compiler v5.9.8.4 (5.9.6.7 being deprecated by Wind River)

Communications

• Updated CAN gateway functionality – message forwarding to more than one destination CAN bus
• Support for new infotypes under UDS $09 (0x1A, 0x1B, 0x1C)
• Added support for 666.67 kbps and 800 kbps CAN baud rates

Fixes and Improvements

• Code generation improvements

Learn more on more fixes and improvements in the release note.

Today’s vehicles rely heavily on complex electrical systems to provide advanced features.  Although these systems provide many convenience and safety enhancements, they introduce new failure modes which must be addressed by appropriate diagnostics and diagnostic architecture.

The use of electronic parking brakes (EPB) over manual lever-actuated parking brakes imposes new requirements for advanced diagnostics to ensure proper brake operation and the functional safety of the vehicle.  The development of an EPB controller by Dana provides insight into several often-underappreciated aspects of diagnostic architectures.

Diagnostics Overview:

The role of diagnostics in any control system is to detect anomalous or undesired operation of a component or components in that system.  Diagnostics have an immediate impact on both system availability (ability of a user to perform some task) and functional safety (the absence of unreasonable risk due to hazards caused by malfunction behavior[i]).  A diagnostic that detects a fault when one is not present (a false positive) can cause a driver to be unable to perform some task. This may be a nuisance, such as not being able to select a desired channel on the radio, or something more severe rendering the vehicle inoperable.  A diagnostic that fails to detect a fault may also result in a hazardous situation.  For EPB systems, the most severe fault is a sudden application of braking force when driving at high speed. Failure to detect such a fault has a high probability of resulting in a high-severity, low-controllability situation.

A park brake is often the only retention mechanism for electric powertrains due to the lack of driveline resistance to freewheeling. As such, the combination of the need for availability and functional safety requires balance in the system design and approach to diagnostics.  Immobilizing a vehicle is a safe condition in response to faults, but has a dramatic adverse impact on vehicle availability.

 Example topology:

For high availability and high functional safety, EPB systems typically employ redundant processing components, which work in concert, providing braking when needed and preventing unintended braking.  Figure 1 shows the example control topology used discussed in this paper.

This topology provides detection of and protection against:

1. Unintended actuation

The secondary microcontroller can open the low-side path independently of the micro, preventing inadvertent control from the primary.  Current-monitoring on both legs can detect shorts to supply, or ground outside the controller.

2. Actuation in wrong direction

Both microcontrollers measure voltage on both terminals of the caliper, providing independent, redundant measurement of direction.

This topology provides detection against

3. Failure to actuate

Redundant voltage and current measurements can detect failure to actuate due to incorrect command, and due to some failures of gates and external components. Load-off shorts and open can be detected by measuring terminal voltages with zero, or only one high- or low-side, gate active.

Approach to diagnostics

The fault management strategy is as important as the technical details of fault detection and mitigation.  A fault management strategy consists of several main concepts:

1. The fault life cycle. When to set faults, when to clear faults, and how to report faults.
2. Awareness of diagnostic capabilities of hardware components and the relationship to safety analyses.
3. Coordination of fault detection, and response among distributed processing components.

 Life cycle

The diagnostic life cycle in this paper is defined as the cycle of detecting a fault condition, confirming the fault, then acknowledging a return to the absence of the fault condition.

While the criteria for determining the presence of a fault condition is normally well understood (e.g. detecting current when none is expected, which indicates unintended actuation), the conditions for returning to a fault-absent state are less clear.

The available choices for returning to fault-free behavior fall into one of several broad categories:

• Simple debounce
• Drive-cycle debounce
• Condition-based debounce
• Manual/service recovery

The type-of-fault recovery mechanism must be informed by the functional safety analyses for the system.

Some examples from an EPB system are tabulated below.

Fault	Fault Recovery Method	Rationale
Wrong command to motor	Manual/service recovery	A wrong command to the motors indicates a fault within the microcontrollers or drive circuitry which can only be rectified by controller replacement.
Overtemperature and/or transient Current Trips	Simple or condition-based (time) debounce	Temperature and current faults can be due to transient environmental conditions, meaning a retry or delay-and-retry scheme is appropriate.
Open / Short circuit detection	Manual/service recovery	Open and short circuits indicate either a failure of drive circuitry or a failure in external components, such as harnesses, which warrant inspection and/or repair.

Consideration of hardware capabilities

Hardware capabilities of a control module are intrinsic to the diagnostics available on a module.  The specific use cases for which a controller is designed, drive the part selection, which has a specific impact on the diagnostics.

EPB controller output drivers are a hardware component of particular interest.  Modern output driver chips often have built-in capabilities for detecting, and automatically protecting against, temperature and current excursions. Some chips also include built-in facilities for open- and short-circuit detection with the load commanded on or off.  While this can be convenient, it is important to ensure the method of reporting those internal driver states, to the application, is well understood.  Some chips, for example, may report a single status bit to the application rather than individual status bits.

EXAMPLE: An H-bridge chip, providing a single bit, indicates a fault but does not disambiguate between overcurrent, over-temperature, or open-/short-circuit.  The application software must use multiple sources of information to determine the fault, and then associate an appropriate fault action.  In Figure 1 – Example EPB Topology, the independent current measurements outside of the driver chips allowed disambiguation between excessive current, and driver overtempt faults.

Coordination of fault detection and response

The most challenging aspect of managing faults is related to safety mechanisms on the EPB topology.  In a topology, as in Figure 1, there are two independent computation units, each capable of independently disabling the outputs. Care must be taken to handle how an intervention by one computation unit is interpreted by the other computation unit.

In a naïve implementation, the primary microcontroller is likely to detect an open-circuit fault if the secondary microcontroller disables the caliper motor.  To avoid nuisance faults, the secondary micro must be able to communicate to the primary that it is actively intervening.  This may require high-frequency communication, since the fault handling time intervals are short for EPB.

Fault reporting

Once the application has detected a fault, the final aspect of fault management is the reporting concept.  There are two scopes of fault reporting: indications to the vehicle operator, and fault reporting for diagnostics and service.

A driver needs to know if a feature is available or not, ideally before needing that feature.  A diagnostic that detects potential latent failures should be indicated to the driver as soon as the failure is identified.  Generally, drivers only need to know that something will likely not work as expected. The cause is not relevant information to the driver.  Additional diagnostic indication should direct the vehicle operator to a course of action, rather than only indicating a fault.

For service tools, much more detailed information is necessary, often including best estimate of root cause to direct repair activities.  An internal EPB controller fault should be distinguished from a caliper fault, for example, with a specific fault identifier.

Concluding remarks

A technical consideration alone, of how to detect and address faults in modern vehicle systems, is not sufficient. It requires a holistic approach. The fault detection and management architecture must satisfy the requirements for functional safety, while maintaining reasonable vehicle availability.  The fault indication strategy must be able to provide guidance to the vehicle operator, without being distracting or providing non-actionable information.

[i] ISO 26262-1:2018 Clause 3.67

With complex vehicle architectures designed into modern vehicles for ADAS, EV systems, gateways etc., a simple ignition key driven ECU wake up architecture is no longer adequate. New strategies that require ECUs to be woken up by CAN traffic, or on a specific CAN message, are becoming a requirement. For example, EV architectures require a periodic wake-up of the ECU to perform some scheduling and background tasks, even when the vehicle is not in use. This requires a real-time clock wake up functionality in ECUs.

The M560 and M580 families of Functional Safety (ISO 26262) Vehicle Control Units (VCU) take modern vehicle architectures into consideration. They have the following wake sources:

• Wake on RTC clock
• Ignition (Pin XD1)
• Fuel Door Button (Pin ZA2)
• Control Pilot (Pin XF1)
• Wake on CAN bus A Message(s) (Traffic present or Specific Message IDs) (Pins YE4 & YF4)
• Wake on CAN bus B Messages (Traffic present) (Pins YJ4 & YK4)

The Wake_M560_M580_Sleep example Simulink model demonstrates the M560 and M580 ECU’s flexibility to either bring the ECU to a sleep state, or wake it from a sleep state.  The Simulink model follows a top down/left right flow, allowing the user to easily follow the logic.  Within the Simulink model, the user will be able to identify the following key characteristics of the M560 or M580:

• Selecting the type of Real Time Workshop (RTW) build,
• Configuring CAN/CCP settings,
• Enabling the secondary microcontroller and
• Details about configuring the six wake-sources for the M560 or M580

An easy to use, and easy to build, example Simulink model supporting OpenECU M560 and M580 families of rapid control prototyping embedded controllers is available for download here. It is intended to introduce users to the ease and simplicity of creating, and building, applications using OpenECU.

Use cases for testing the wake sources

1. Download the Example model: https://support.openecu.com/
2. Download the User Guide for Simulink API
3. Read the comments in the model to take next steps

A snippet of the instructions for the example model with various wake sources is provided below:

1. RTC (Real Time Clock)
   1. The steps of operation to test this feature are as follows:
      1. Set slpc_mins_RTCData to a value that you want to wake the M5xx up after it has been asleep (units are in Minutes)
      2. Verify that slp_b_WakeSourceOff is not true
         1. To verify which source is holding slp_b_WakeSourceOff False look at the following variables:
            1. slp_b_XD1Ign (ignition input)
            2. slp_b_ZA2FuelDoorButton (fuel door button input)
            3. slp_b_XF1ControlPilot (control pilot input)
            4. slp_b_canAwaketrg (CAN A wakeup flag)
            5. slp_b_canBwaketrg (CAN B wakeup flag)
      3. Whichever input is true, disconnect that input and verify that slp_b_WakeSourceOff goes true
      4. Observe that in the time set on slpc_mins_RTCData that the M5xx wakes up and then goes back to sleep
2. Ignition Input
   1. The steps of operation to test this feature are as follows:
      1. Set slpc_mins_RTCData to 999 (we do not want to wake the M5xx up after it has been asleep
      2. Verify that slp_b_WakeSourceOff is not true
         1. To verify which source is holding slp_b_WakeSourceOff False look at the following variables:
            1. slp_b_XD1Ign (ignition input)
            2. slp_b_ZA2FuelDoorButton (fuel door button input)
            3. slp_b_XF1ControlPilot (control pilot input)
            4. slp_b_canAwaketrg (CAN A wakeup flag)
            5. slp_b_canBwaketrg (CAN B wakeup flag)
      3. Whichever input is true, disconnect that input and verify that slp_b_WakeSourceOff goes true
      4. Set pin xD1 true and verify that the variable slp_b_WakeSourceOff goes true and that the M5xx wakes up
      5. The M5xx will stay awake based on the value set on the calibration variable slpc_s_PsuHoldOffDelay.
3. Fuel Door Button Input
   1. The steps of operation to test this feature are as follows:
      1. Set slpc_mins_RTCData to 999 (we do not want to wake the M5xx up after it has been asleep
      2. Verify that slp_b_WakeSourceOff is not true
         1. To verify which source is holding slp_b_WakeSourceOff False look at the following variables:
            1. slp_b_XD1Ign (ignition input)
            2. slp_b_ZA2FuelDoorButton (fuel door button input)
            3. slp_b_XF1ControlPilot (control pilot input)
            4. slp_b_canAwaketrg (CAN A wakeup flag)
            5. slp_b_canBwaketrg (CAN B wakeup flag)
      3. Whichever input is true, disconnect that input and verify that slp_b_WakeSourceOff goes true
      4. Set pin ZA2 true and verify that the variable slp_b_WakeSourceOff goes true and that the M5xx wakes up
      5. The M5xx will stay awake based on the value set on the calibration variable slpc_s_PsuHoldOffDelay.
4. Control Pilot Input
   1. The steps of operation to test this feature are as follows:
      1. Set slpc_mins_RTCData to 999 (we do not want to wake the M5xx up after it has been asleep
      2. Verify that slp_b_WakeSourceOff is not true
         1. To verify which source is holding slp_b_WakeSourceOff False look at the following variables:
            1. slp_b_XD1Ign (ignition input)
            2. slp_b_ZA2FuelDoorButton (fuel door button input)
            3. slp_b_XF1ControlPilot (control pilot input)
            4. slp_b_canAwaketrg (CAN A wakeup flag)
            5. slp_b_canBwaketrg (CAN B wakeup flag)
      3. Whichever input is true, disconnect that input and verify that slp_b_WakeSourceOff goes true
      4. Set pin XF1 true and verify that the variable slp_b_WakeSourceOff goes true and that the M5xx wakes up
      5. The M5xx will stay awake based on the value set on the calibration variable slpc_s_PsuHoldOffDelay.
5. Can_A Input
   1. The steps of operation to test this feature are as follows:
      1. Set slpc_mins_RTCData to 999 (we do not want to wake the M5xx up after it has been asleep
      2. Verify that slp_b_WakeSourceOff is not true
         1. To verify which source is holding slp_b_WakeSourceOff False look at the following variables:
            1. slp_b_XD1Ign (ignition input)
            2. slp_b_ZA2FuelDoorButton (fuel door button input)
            3. slp_b_XF1ControlPilot (control pilot input)
            4. slp_b_canAwaketrg (CAN A wakeup flag)
            5. slp_b_canBwaketrg (CAN B wakeup flag)
      3. Whichever input is true, disconnect that input and verify that slp_b_WakeSourceOff goes true
      4. Transmit CAN Message 512 on CAN Channel A and verify that the variable slp_b_WakeSourceOff goes true and that the M5xx wakes up
      5. The M5xx will stay awake based on the value set on the calibration variable slpc_s_PsuHoldOffDelay.
6. Can_B Input
   1. The steps of operation to test this feature are as follows:
      1. Set slpc_mins_RTCData to 999 (we do not want to wake the M5xx up after it has been asleep
      2. Verify that slp_b_WakeSourceOff is not true
         1. To verify which source is holding slp_b_WakeSourceOff False look at the following variables:
            1. slp_b_XD1Ign (ignition input)
            2. slp_b_ZA2FuelDoorButton (fuel door button input)
            3. slp_b_XF1ControlPilot (control pilot input)
            4. slp_b_canAwaketrg (CAN A wakeup flag)
            5. slp_b_canBwaketrg (CAN B wakeup flag)
      3. Whichever input is true, disconnect that input and verify that slp_b_WakeSourceOff goes true
      4. Transmit a CAN Message on CAN Channel B and verify that the variable slp_b_WakeSourceOff goes true and that the M5xx wakes up
      5. The M5xx will stay awake based on the value set on the calibration variable slpc_s_PsuHoldOffDelay.

      This article addresses the applicability of CE and E-marks to automotive electronics, when looking to sell automotive electronics systems into Europe, and how Dana OpenECU products can support customer’s regulatory challenges.

      What is CE marking and how does it apply to automotive electronics?

      According to https://ec.europa.eu/growth/single-market/ce-marking/ the CE marking indicates a product has “been assessed to meet high safety, health, and environmental protection requirements.”  These requirements cover a range of products & potential sources of pollution.

      Automotive electronics largely fall into categorical exemptions from CE marking. For example, most automotive electronics do not have operating input or output voltages above 50Vac, or 75Vdc, and therefore are not in scope for the Low Voltage Directive 2014/35/EU.  CE marking also includes an EMC directive, 2014/30/EU, which includes a categorical exemption for vehicles/automotive electronics on the basis that there is a more specific directive for the automotive industry.

      What is E-marking and how does it apply do automotive electronics?

      According to https://www.unece.org/trans/main/wp29/wp29regs0-20.html E-marking is a regulatory process for vehicles, and electronic sub-assemblies, which certifies the product demonstrates a bare minimum of EMC immunity for safety functions, and has EMC emissions below a statutory maximum.  Tests on electronic sub-assemblies also check for immunity against transient disturbances common in automotive electrical systems.  The level of formality associated with E-marking is significant.  Testing related to E-marking must be witnessed by a regulatory body, at a certified lab, to a pre-approved test plan.  That testing rigor differs from CE mark requirements, which often simply require a self-certification.

      E-marking is the automotive industry specific EMC process which supplants the CE EMC directive according to 2014/30/EU Article 2(3).  It is required for all vehicles sold in Europe.

      There are two paths available to achieving E-mark, at the discretion of the manufacturer:

      1. E-marking can be achieved by testing the vehicle as a whole
      2. E-marking can be achieved by testing each electrical sub-assembly (ESA) and integrating them within their installation guidelines

      Both paths require a test plan approved, and testing observed by a notified body.  The test plan must identify:

      • the immunity related functions (of the ESA or vehicle) related to:
        • control of the vehicle
        • signaling other road users
        • vehicle occupant and road user protection
      • the mission profile, and load simulators, which are expected to produce the max EMC emissions

      E-mark testing is similar to typical OEM-specified EMC testing, althoughgenerally, the limits of the tests are less stringent than common OEM specifications:

      • Radiated emissions (CISPR 12 & 25)
      • Radiated immunity (ISO 11451 & ISO 11452)
      • Power line transient immunity & emissions (ISO 7637)

      How Dana can help customers achieve E-marking and regulatory compliance

      Dana helps customers plan for, and execute, E-mark testing on custom controller products and systems containing an OpenECU controller, based on the knowledge gained from pre-compliance testing.  All OpenECU products have undergone pre-compliance testing, covering the same test types required for E-marking.  The remining system information needed to develop a test plan are:

      • The immunity related functions
        • Dana can use its safety expertise and Functional Safety Certified Automotive Engineers to define those functions for a customer’s system
      • The loads and mission profiles that produce maximum emissions
        • Dana can use its 30+ years of automotive electronics design expertise to assist customers in defining these profiles

      Dana has experience integrating its OpenECU controllers into systems that have achieved regulatory compliance, and can offer flexible support models to assist customers at every stage, from development and validation, through volume production.

      Formula SAE Team from the University of Michigan:
      Michigan Electric Racing (MER) uses Dana’s M220 and M110 OpenECU controllers for Formula SAE Electric Vehicle.

      About Formula SAE:
      “SAE International’s Collegiate Design Series (CDS) competitions take students beyond textbook theory by enabling them to design, build, and test the performance of a real vehicle and then compete with other students from around the globe in exciting and intense competitions.”- SAE.

      More can be found here: https://www.sae.org/attend/student-events

      Michigan Electric Racing designs and builds an all-electric formula style race car every year. MER vehicles include many cutting-edge features:

      • Independent, Dual Rear Wheel Drive
      • Custom Battery Pack, designed from the cell up
      • Custom Distributed Battery Management System
      • Custom Motor Controllers
      • Independent Torque Vectoring and Traction Control
      • Live Data of three interoperable vehicle CAN Buses
      • Full Aerodynamics Package, including front/rear wings, Undertrays, Diffuser, Side Wings, and Complete Body Work
      • Rear Wheel Bump Steering
      • Custom, In-House Manufactured Gearboxes, Spindles/Uprights, and other Suspension Components
      • Advanced Driver Interface Controls and Feedback

      Learn More about the team here