M560

OVERVIEW

Introducing M560

The OpenECU M560 Electronic Control Unit is designed with functional safety process for Vehicle Control Unit (VCU) and Vehicle Charge Control Unit (VCCU) to support the most demanding Electric Vehicle (EV) / Hybrid Electric Vehicle (HEV) supervisory control applications. Since most supervisory controls demand the highest level of functional safety, the M560 was developed as a Safety Element out of Context (SEooC) following ISO 26262.

Pi Innovo OpenECU M560

M560 ECU is supported by a high performance SPC5746 primary microprocessor and a powerful 32-bit SPC560P34 secondary microprocessor providing sophisticated, high-bandwidth rationality checking and system safety monitoring of full-authority vehicle control applications.

The M560 is designed to support EV / HEV supervisory control applications, the integrated charging circuitry eliminates the need for a separate charger interface module.

Due to its high quantity of customizable I/O, advanced microprocessor, safety oriented architecture and user friendly OpenECU Simulink application interface, the M560 is a great rapid control prototyping platform for a broad range of applications. Pi Innovo also offers control algorithm for Electric Vehicle Model in MATLAB and Combined Charging System (CCS) suitable to support most EV / HEV / NEV architectures and following SAE J1772 and DIN 70121 standards. With the M560 or M580 Supervisory Control and Combined Charging System (CCS) control algorithms customers get an integrated module with Vehicle Control Unit (VCU) and Charge Management Unit (CMU) in one module i.e. two ECUs in a single controller.

Pi Innovo’s systems, controls and software engineers are available to support application implementations from prototype to production.

M560 is for 12v systems. Our M580 is specially tailored for 24v systems.

High Performance

  • Powerful NXP SPC5746 microprocessor and 4x CAN 2.0 channels
  • Multiple H-bridges, low side drives and high side outputs
  • Comprehensive fault diagnosis supporting functional safety as well as OBD requirements
  • High level diagnostics fault reporting resident in platform software

Versatile

  • Designed to meet ISO26262 ASIL D functional safety requirements
  • 112 pins of flexible I/O
  • Integrated charging interface circuitry
  • Truly open application independent Simulink® development environment

Capabilities

  • Designed for complex hybrid and EV applications
  • High-quality rugged hardware designed for Chassis or Passenger Compartment
  • Supports common calibration tools such as ATI Vision, ETAS INCA, and Vector CANape via CCP as well as Pi Innovo calibration tool PiSnoop
  • Same proven hardware used for development can be used for volume production
  • Supported platform software: OpenECU-FS

Hardware Specifications

Microprocessor
Primary Processor SPC5746
Clock Rate 160MHz
Code Space Up to 3MB
RAM Space Up to 256kB
Calibration Space Up to 256kB
Secondary Processor SPC560P34
Clock Rate 64MHz
Total Flash Space Up to 192kB
Total RAM Space Up to 12kB
Inputs
Digital Inputs 9x switched, 3x PWM
Analog Inputs 28
Internal Features
Partial Networking Partial Networking
Wake on CAN (2 channels) Wake on CAN (2 channels)
Wake on digital/PWM input Wake on digital/PWM input
Pilot, Proximity and CC2 pins Pilot, Proximity and CC2 pins
Application
Location Chassis/Passenger Compartment
Supply Voltage 8 – 18V
I/O Summary
Sensor Supplies 2x 5V @200mA
Input Pins 40
Output Pins 42
Communication 4x CAN 2.0 (primary processor), 1x CAN (secondary processor)
Outputs
H-Bridges 1x 10A, 2x 5A, 1x 3.2A
Low Current Low Side Drives 12x 100mA, 3x 400mA, 14x 700mA, 2x 1A
High Current Low Side Drives 4x 2.2A, 1x 3.2A
High Side Logic Outputs 2x 1mA
High Side Outputs 4x 700mA
Physical
Dimensions 225x205x45mm (WxDxH)
Material Aluminum
Weight 1.1kg
Connectors Molex 112pin (1x48, 2x32)
Vibration ISO 16750 chassis mount
Environmental Protection IP69K Sealed/Gore Vent

APPLICATIONS

M560 Applications Include:

VCU + VCCU (Integrated)The M560 provides capability for both VCU and VCCU application i.e. supervisory control and charge management in a single ECU.

Application Description
Vehicle Control Unit Vehicle Control Unit (VCU) provides torque coordination, charge control, power management, thermal management, vehicle speed limiting and more for Electric Vehicle (EV) or Hybrid Electric Vehicle (HEV) architectures.
Vehicle Charge Control Unit A Vehicle Charge Control Unit (VCCU) or Vehicle Communication and Charging Control (VCCC) is an ECU which manages the charging of Electric Vehicle or Hybrid Electric Vehicles. With Powerline Communication (PLC) the M560 provides charging circuitry for charging applications following SAE J1772, DIN 70121 standards.

BLOCK DIAGRAM

For complete M560 Pinout download, click here.
This is a default configuration, optional configuration available, please contact us.
For a full list of downloads click here.

 

CASE STUDIES

Production fault diagnostics in an M560 used as a hybrid electric vehicle powertrain control module.

M560A customer using Pi Innovo’s OpenECU platform software and M560 ECU as the hybrid control unit (HCU) for their specialty application, also wanted Pi to develop the supervisory control strategy including comprehensive diagnostics using the J1939 protocol. Pi was responsible for implementing algorithms for system fault detection and maintaining and storing the DTC life-cycle including relevant diagnostic information such as freeze-frames. Fault and diagnostic information reporting to authorized service tools was also implemented in response to diagnostic messages (DMs) as per the J1939-73 standard. All the above needed to be developed inside a Matlab/Simulink environment in compliance with customer's software implementation guidelines.Pi worked with the customer to determine all the top-level system requirements, including safety goals and functional safely requirements (FSRs). Based on FSRs and technical safety requirements (TSRs), a list of critical system faults that needed to be diagnosed for functional safety and reliable system operation of the HCU was created. For each fault, conditions were identified for detecting, setting and clearing DTCs along with the type of data to be acquired when the fault was set (freeze frame). Remedial action was determined for each fault and implemented.

Some examples of the type of faults diagnosed include:

  • Out-Of-Range check, Out-Of-Bound check, Slew-Rate check for analog inputs
  • Open and short circuit detection on M560 output pins
  • Diagnostics for CAN communication faults like communication errors between other ECUs on the CAN buses
  • Redundancy checks of safety critical signals
  • Rationality checks for redundant signals

The OpenECU platform provides an extended diagnostics library in a Simulink environment based on J1939 and ISO-15765 standards. The library blocks significantly reduce the development time for implementing the J1939 diagnostics interface in the hybrid vehicle control model. By using the extended diagnostics library, the application developer can focus on implementing the fault detection algorithms without having to worry about the DTC lifecycle maintenance, diagnostic information storage and fault reporting, all of which is entirely handled automatically by the OpenECU platform.

Providing a new production EV supervisory controller with a customized M560

M560

Challenge

For a customer doing small production runs across several years, a fully populated off the shelf OpenECU wasn’t the most cost effective or efficient solution. Pi Innovo helped the customer pare down the unused I/O and configure the sensor interfaces to match the customer’s requirements.

Solution

The customer implemented their on-vehicle control algorithm using Pi Innovo’s OpenECU M560 as the electronic control unit. While developing on test vehicles with the standard off the shelf M560, the customer worked in parallel with Pi Innovo to reduce the production piece price of the module by removing the unneeded circuitry and a variety of unused output drivers resulting in the M561. The M561 was also optimized for the customer’s sensors by modifying pull resistances. Additionally, Pi Innovo’s engineers supported the customer with app development, DV testing, and tailored production documentation.

Results and Impact

This project resulted in a new ECU, with complete PPAP, for the customer. The M561 controllers are produced on the same production line as the M560 and have customized end of line test and a customer-specific label for the module. The piece price for each unit was brought down by approximately 15%.

Interface EVSE with Combined Charging System (CCS) using OpenECU M560 or M580

A Review of Some Charging Standards

Electric vehicles (EVs), such as battery electric vehicles or plug-in hybrid electric vehicles, are expected to take over a major part of the transportation sector. As a result, the demand for Electric Vehicle Supply Equipment (EVSE), also known as Charging Stations, is growing. An EVSE should be able to handle the charging process for different types of EVs. In addition, different EVs might have different charging requirements, in terms of charging power, charging time, AC/DC charging, etc. Therefore, several standards have been created to regulate the EV-EVSE interface and the charging process requirements.

DIN 70121 is one of the first standards that was developed to regulate the EV-EVSE interface.  However, it lacked some features such as Transport Layer Security. Later, other standards, such as ISO 15118 and SAE standards were developed based on DIN 70121 to regulate secure charging requirements in an EV-EVSE interface. Whereas SAE standards are more favorable in North America, ISO 15118 is the preferred standard in Europe. Both SAE J2847-2 and ISO 15118-2 have adopted the Power-Line Communication (PLC) physical layer for communications between EV and EVSE, however, there are some differences in the datalink layers of these two protocols.

EVSEs are capable of both DC and AC charging, as shown in Figure 1. In AC charging, the EV must be equipped with an onboard rectifier. The communication between EV and EVSE in AC charging is through a PWM signal over the Control Pilot signal. DC charging, however, has some benefits over AC charging. In DC charging, the onboard rectifier is no longer needed. In addition, much more electric power can be transferred in one DC charging session which reduces the charging session time in comparison with AC charging. However, due to the complexity of a DC charging session and billing requirements, a more advanced communication protocol than PWM communication is needed.

The following figure represents the physical interface between the EV and EVSE, based on J1772.

Figure 1  Combined Charging System (CCS) with OpenECU M560 or M580

A standard handshaking protocol is required by the Pilot and Proximity signals in the EV-EVSE interface. In addition, digital communication may take place between the EV and EVSE to initiate or terminate the electric energy transfer to the EV. This communication happens over the Control Pilot signal using the PLC protocol outlined in HomePlug Green PHY specifications. Although PLC for AC charging is optional, it is required for DC charging. SAE and ISO 15118 have both adopted the HomePlug Green PHY specification for PLC and have developed several standards to manage the digital communication in an EV-EVSE interface. Pi Innovo’s OpenECU M560 and M580 controllers support these standards and are compatible with HomePlug Green PHY specifications. To achieve this goal, the M560 and M580 are equipped with the Qualcomm Powerline Communication (PLC) chipset to support digital communication between the EV and EVSE over the Control Pilot signal. Furthermore, a library of supported Simulink blocks based on SAE J2847-2 and ISO 15118-2 are offered in the OpenECU development toolchain to manage the PLC communication in Simulink environment.

OpenECU M560 and M580 are ECUs designed for complex hybrid and EV applications, such as supervisory controller or battery management system. In AC charging, typically the onboard charger controller handles the EVSE interface. However, for DC charging, no onboard charger (rectifier) is required to be installed in the vehicle. Hence, the task of handling the EVSE interface and managing the charging session is assigned to another ECU in the vehicle, such as the supervisory controller. M560 and M580 are designed to be compatible with DC charging requirements in accordance with SAE and ISO 15118 standards.

Figure 2  M560/M580 interface to EVSE

According to HomePlug Green PHY PEV-EVS, once an EV is connected to the EVSE, an association protocol assigns that EVSE to the EV. This procedure is handled via SLAC Association on Pilot signal as described in Green PHY PEV-EVS and SAE J2931-4 (or ISO 15118). For SAE J2931-4, OpenECU M560/M580 handles the SLAC protocol in its platform (base) software. However, for ISO 15118, the SLAC protocol needs to be implemented in application software, as needed for the protocol, using the Simulink blocks provided by the OpenECU platform software.

Currently in North America, SAE J1772 defines the most common protocol for establishing communication and configuring charging session parameters for the EV-EVSE interface, but in Europe ISO 15118 is the dominant standard. In both standards, once an EVSE is associated with the EV with SLAC protocol, several sequential stages must take place over PLC communication for configuring the charging parameters, and managing the energy flow to the EV:

  • Initialization of the charging session
  • Isolation monitoring and pre-charge
  • Energy transfer
  • Shutdown and disconnect
OpenECU M560 and M580 Support for Interfacing With EVSE

M560 and M580 are designed to handle AC or DC charging sessions. The hardware provides the electrical and communications interfaces, and the OpenECU platform software provides the hooks into those hardware elements to implement whichever charging protocol the application software requires. The OpenECU platform offers the two Simulink blocks depicted in Figure 3 to access the physical and data-link layers of the PLC protocol as needed, for either SAE 1772 or ISO 15118-3. These two Simulink blocks are for handling the data exchange between the OpenECU M560/M580 (EV side) and an off-board DC charger (EVSE side). The application software can be customized as needed for implementing either one of SAE J2847-2 or ISO 15118-2 protocols for handling a charge session, based on Simulink blocks in Figure 3.

Figure 3: Two Simulink blocks are provided for M560/M580 to handle a full DC charging session. The block ‘pv2g_Connection’ establishes the EV-EVSE communication link via SLAC protocol. The block ‘pv2g_Message’ is configurable and updates its ports based on selected message to be sent or received to/from the EVSE.

At the beginning of a DC charging session, an EVSE must be associated with the EV that is connected to it. Only then, a local communication network can be established between the EV and the EVSE. The association of EVSE and EV is handled by Signal Level Attenuation Characterization (SLAC) protocol. The OpenECU platform software offers a Simulink block that handles the entire SLAC protocol based on SAE J2931/4, as shown in Figure 4. The Simulink application software needs to trigger (initiate) this block once the Pilot signal is detected on the M560/M580 dedicated pin for the Pilot wire. In the future, Pi Innovo plans to provide Simulink blocks so that the SLAC protocol can be customized as needed by the Application software. After establishing the communication link with the EVSE, the block outputs may be used to notify the application control software. As was mentioned previously, please note that the SLAC protocol for ISO 15118-2 needs to be implemented in application control software using OpenECU dedicated Simulink blocks.

Figure 4: Simulink block that handles the SLAC protocol and sets up the communication link with the DC charger between EV and EVSE. The entire SLAC protocol is handled by the OpenECU platform software.

Once an EV-EVSE association and communication link is successfully established, the DC charging session begins where a continuous data exchange is required between the EV and the EVSE over the PLC interface. A normal DC charging session requires several sequential stages to be completed (For instance, see SAE-J1772 F.1.8 and F.1.9 for Normal Startup and Shutdown Sequences). The OpenECU platform provides a configurable Simulink block to handle these stages at the application layer of PLC communications, as outlined in SAE J2847-2 or ISO 15118-2. For example, Figure 5 represents two different configurations of this block for transmitting two messages during initialization stage.

Figure 5: Configurable Simulink blocks (based on SAE J2847-2) supported by OpenECU platform to manage message transmit/receive over the PLC communication in an EV-EVSE interface. The block inputs and outputs are configured automatically based on the standard for the selected message. The same blocks can be used for implementing ISO 15118 protocol.

The Simulink block in Figure 5 is fully compatible with SAE J2847-2 and ISO 15118-2 and facilitates the message transmit/receive over the PLC interface. This Simulink block can be used to implement the required stages of SAE J1772 or ISO 15118-2 in the Simulink environment for the M560/M580. If needed, Pi Innovo can provide support for implementing all of the SAE J1772 or ISO 15118-2 stages in Simulink.

Using VX1000 for fast M560 Data Measurement

Data measurement and calibration is a critical aspect of any ECU application development. All of Pi Innovo's ECUs support the industry standard CAN Calibration Protocol (CCP). CCP is a software-based solution that utilizes one of the ECU's CAN buses to interface with external calibration tools.

Using CCP, a calibration tool accomplishes basic calibration activities:

  • request calibration changes during run time
  • read application data during run time
  • reprogram application or calibration memory

The OpenECU M560 is designed to facilitate development for a wide range of hybrid and electronic vehicle supervisory control applications. In some cases, to meet the needs of the application during development, more bandwidth and flexibility is needed than CCP provides. The M560 accommodates this by providing integration with the add-on Vector VX1000 system. The VX1000 system provides significant improvements with a minimal effect on the form factor of the M560 ECU.

Free the CAN bus:

The VX1000 system communicates directly with the Vector CANape service tool using XCP over a dedicated physical connection from the JTAG interface on the M560. It supports calibration*, data measurement, and reprogramming without utilizing the CAN bus. This can be useful in applications that have high CAN utilization and cannot spare bus capacity for calibration and measurement activities.

Capture more data:

The VX1000 system has more throughput, typically 8x more, than CCP. It can capture data at a much higher rate and can reprogram the application or calibration much more quickly.

* will be available in a future release

The Vector Vx1000 is described in more detail here

DOWNLOADS

IMAGES

MODULE
COMPARISON

Compare ALL OpenECU Modules

Primary Processor SPC5534 MPC5534 MPC5534 MPC5534 MPC5674F MPC5746B SPC5746 SPC5746
Primary Clock Rate 80MHz 80MHz 80MHz 80MHz 264MHz 160MHz 160MHz 160MHz
Primary Code Space 512KB 768KB 768KB 512KB 3MB 2302KB 3MB 3MB
Primary RAM Space 64KB 832KB 832KB 64KB 128kB 384KB 256KB 256KB
Primary Calibration Space 256KB 236KB 256KB 256KB 128kB 128KB 256KB 256KB
Secondary Processor SPC560P34 SPC560P34 SPC560P34
Secondary Clock Rate 64MHz 64MHz 64MHz
Secondary Flash Space 192KB 192KB 192KB
Secondary Calibration Space 20KB
Secondary RAM Space 12KB 12KB
Operating Voltage 9V to 32V 7V to 32 V 7V to 32 V 12V or 24V 8V to 18V 8V to 18V 8V to 18V
Sensor Supply 1x 5V @250mA 1 x 5V / 250mA 1 x 5V / 250mA 2x 5V@250mA 4x 250mA @ 5V none 2x 5V @200mA 2x 5V @200mA
Standby Current 0.25mA @12V 0.25mA @ 12V
Actuator Supplies 1x 20A 2x 10A @ Vbatt
High Speed CAN 2.0 2x 2x 2x 2x 4x 1x 4x 4x
Inputs (Analog or Digital) 10x 9x 16x 18x (Digital: 6x; Analog: 12x) 40x (Digital: 5x switched, 3x Frequency, PWM; Analog: 32) 4x 40x (Digital: 9x switched, 3x PWM; Analog: 28) 44x (Digital: 9x switched, 3x PWM; Analog: 32)
Reprogramming Enable (FEPS) 1x @ -18V 1x @ -18V 1x @ -18V 1x @ -18V 1x @ -18V 4x
Differential VRS 1x (2 pins)
Single Ended VRS 2x
Frequency 1x
Cam Shaft 2x ±157V 4x Hall only
Crank Shaft 1x ±157V 1x Hall (VR option)
RTD Sensor 7x 4x
Knock Sensor Knock Sensor
Lamda Sensor (UEGO) 2x
Lamda Sensor (HEGO) 4x (only 2x available when using 2x UEGO)
Ignition Sense 1x 1x
Low Current Low Side Drives Up to 1x 20mA & 2x 100mA & 6x 500mA 12x 100mA, 3x 400mA, 14x 700mA, 2x 1A 11x 100mA, 4x 400mA, 14x 700mA, 2x 1A
Medium Current Low Side Drives Up to 4x 2A
High Current Low Side Drives 4x 2.2A, 1x 3.2A 4x 2.2A, 1x 3.2A
0-5 V Analog Output Up to 2x 10mA
PWM Low Side 2x 100mA 2x 100mA, 2x 250mA & 6x 2A
H-Bridge 1x 5A 2x 8A 1x 5A full-bridge & 2x 10A full-bridge or 4x 10A half-bridge 2x 50A peak or 10A 1x 10A, 2x 5A, 1x 3.2A 1x 10A, 2x 5A, 1x 3.2A
High Side Switch 1x 15A 1x Hall (VR option)
Low Side Injector 1x 15A or 5A 3x 5A peak/ 2A hold 8x software-programmable waveform peak-and-hold: nominal 25A peak, 15A hold
Current Monitors 2x
Voltage Monitors 2x
High Side Logic Outputs 2x 1mA 2x 1mA
High Side Outputs 4x 700mA 4x 700mA
Low Side General Purpose, PWM (SM, VM, CTM) 1x 10A, 1x 2A, 1x 500mA 9x 0.2/0.5A lamp & relay, with monitoring of state, voltage, and fault status
Low-side General Purpose, Spark (SM) 1x 8A 8x (Smart Coil only) with monitoring of state; on-off mode for non-spark uses
High-side Injector sources 2x Injector High-Side outputs with programmable boost voltage phase, 25A peak
Low side GP (General Purpose) (VM, CTM) 1x 8A, 2x 6A peak / 4A hold, with voltage and current-tripped monitoring
High-side GP (General Purpose) (CM) 2x 8A up to 85°C, intended for source to low-side outputs, with current monitoring
Constant-Current (with inductive actuator) 8x 2A
Vibration ISO 16750-3 6g random RMS 6g random RMS Ford IIIB - Severe ISO 16750-3 IEC 60068-2-64 ISO 16750 chassis mount ISO 16750 chassis mount
Environmental Protection IP67 - Sealed IP67 IP69K IP67 Sealed/Gore vent IP69K IP69K & IPx8 Sealed/Gore vent IP69K Sealed/Gore Vent IP69K Sealed/Gore Vent
ESD ±8kV - SAE J1113-13
Conducted and Radiated Emissions CISPR25 Class 2
Conducted Transients ISO 7637-2
Bulk Current Injection Immunity ISO 11452-4
Material Plastic (PPA GF33) Aluminum Aluminum Aluminum Aluminum Aluminum Aluminum Aluminum
Dimension in mm (W x H x D) 138 x 130 x 42 155 x 115 x 46 155 x 115 x 39 228 x 158 x 50 266 x 299 x 56.5 207 x 104 x 45 225 x 205 x 45 225 x 205 x 45
Weight 520g 520g 1.02 kg 2.5 kg 540g 1.1 kg 1.1 kg
Connectors 2 x 20 pin (Molex MX-150) 46 pin 46 pin 46 pin Molex CMC 154-pin, 3-pocket 1x 23 TE (AMSEAL) Molex 112pin (1x 48, 2x 32) Molex 112pin (1x 48, 2x 32)
Location Chassis mount Chassis mount Chassis mount Engine Compartment/ Chassis Engine Compartment / Chassis Passenger Compartment Chassis/Passenger Compartment Chassis/Passenger Compartment
Operating Temperature ISO 16750-4 (-40°C to 85°C) -40°C to 85°C -40°C to 85°C -40°C to 85°C -40°C to 85°C -40°C to 85°C -40°C to 85°C -40°C to 85°C