Hardware in The Loop Simulation For Hybrid Electric Vehicles dSPACE - SAE - 0901 0198

09AE-0198
HARDWARE-IN-THE-LOOP SIMULATION FOR HYBRID ELECTRIC VEHICLES AN OVERVIEW, LESSONS LEARNT AND SOLUTIONS IMPLEMENTED
Amanjot Dhaliwal, Shreyas C. Nagaraj, Syed Ali
dSPACE Inc, USA
Copyright 2009 SAE International
ABSTRACT
Rising fuel prices over the past few years have triggered an increase in the worldwide demand for hybrid vehicles. These vehicles are considerably more fuel efficient than their conventional counterparts and yet offer similar if not improved performance. ECUs or Electronic Control Units that control the energy flow through a hybrid powertrain have played a major role in the success of this technology. Due to the complexity of these systems, ECUs need to go through extensive testing before getting installed in a prototype vehicle for on-road testing. Hardware-in-the-Loop (HIL) simulation is a testing process that has proven to be an industry standard for ECU testing and validation. This paper briefly reviews the state-of-the-art technology in HEVs, outlines a HIL simulator for hybrid vehicle ECUs and discusses the type of components required for testing the various aspects of a Hybrid controller. The lessons learnt, real world challenges faced during ECU testing and proven solutions to such problems are also discussed.
on their configuration: series, parallel, series-parallel and complex hybrid [4-6]. An addition to the hybrid vehicle family is the plug-in hybrid electric vehicle (PHEV) in which an electric power source can be used to charge the batteries making them less dependent on fuel as the only source of energy [7,8]. Due to the fact that a HEV could have two or more propulsion sources, the control becomes complex. Hybrid controller testing and validation is one of the key tasks in developing a HEV. ECU testing can start from early stages of the control software development. HIL systems help benefit from the fact that ECUs are available much sooner than the vehicle hardware prototype. ECU unit tests and function tests can be performed on a single ECU using open-loop models and interaction between other ECUs can be simulated by generating CAN messages from the HIL system, this is also known as Rest bus simulation. Combining other powertrain controllers such as engine, transmission with the hybrid controller allows the user to test distributed functions, observe bus behavior and network management. Simulation of various powertrain components such as engine, transmission, electric motor requires high-speed processing capabilities on the HIL system. In most cases this may require multiple processors to simulate the complete powertrain of a HEV. Due to the complexity of hybrid vehicles various fault conditions and exception handlings have to be done within the control software to ensure proper handling of failures. This paper also discusses the critical features needed for hybrid controller testing from HIL point of view and solutions that were implemented by dSPACE engineers.
INTRODUCTION
The driving force in HEV development is improvement in fuel economy and emissions. Both of these are very pressing criteria. The growing demands for hybrid vehicles impose shorter design and development time, and overall time to market. HIL simulation has been proven to reduce the gap between system modeling and implementation of prototype hardware [2, 3]. HEVs are a complex combination of an electric motor and an internal combustion engine for extended range and reduction in pollution. HEVs are categorized based
The Engineering Meetings Board has approved this paper for publication. It has successfully completed SAEs peer review process under the supervision of the session organizer. This process requires a minimum of three (3) reviews by industry experts. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. ISSN 0148-7191 Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE. The author is solely responsible for the content of the paper. SAE Customer Service: Tel: 877-606-7323 (inside USA and Canada) Tel: 724-776-4970 (outside USA) Fax: 724-776-0790 Email: CustomerService@sae.org SAE Web Address: http://www.sae.org Printed in USA
SAE Paper number 0901-0198 2010 SAE International. This paper is posted on this website with permission from SAE International. As a user of this website, you are permitted to view this paper on-line, and print one copy of this paper at no cost for your use only. This paper may not be copied, distributed or forwarded to others for any use without permission from SAE.
FEATURES OF TYPICAL HYBRID HIL SYSTEMS

ELECTRIC MACHINE SIMULATION - An electric machine can be simulated at three different interface levels, depending on how end users describe their System Under Test (SUT). Different interface levels between the ECU and HIL systems can be established as follows [1]: Signal Interface level Electrical Interface level Mechanical Interface level This paper will mainly focus on the Signal Interface level with brief description of HIL configurations needed to support the Electrical and Mechanical Interface levels. Figure 1 below shows a block diagram of a typical Electric machine simulation using a HIL simulator. A typical real-time simulation model of an electric machine consists of the following subsystems: Electrical system Mechanical system Inverter I/O interface For a stable HIL simulation with an ECU, both the electrical and the mechanical systems must be able to function in a close-loop fashion [1]. The green blocks represent dynamic plant model for the electric machine and the Inverter model (in most cases the Inverter model is a static model), the blue blocks represent Real Time interface (RTI) that basically contain the drivers for the dSPACE I/O cards. The magenta blocks represent the dSPACE I/O cards. The solid black lines represent the external wiring harness from the dSPACE simulator to the controller. SIMULINK MODEL RTI
Inverter Model Electric Machine
The motor controller typically has a dedicated processor for motor control. The output of the ECU will be low power Pulse Width Modulated (PWM) pulses that will operate the power stages or Inverter. At the signal interface level such as the one shown above there will not be any high voltages involved so the power stages will be simulated by a Simulink model. However it is required to accurately capture the PWM pulses by the HIL simulator and the resulting frequencies and most importantly the three phase duty cycles will be fed to the inverter model. The solution for this from dSPACE is the DS5202 FPGA based PWM capture solution. Measurement of frequency, duty cycles and latch times of up to four electric machines can be done at a resolution of 25ns. It is also possible to generate interrupts which are synchronized with the incoming PWM. The board also supports three different capture settings the selection of which depends on the requirements. This mechanism will be discussed in more detail in a later section. The outputs of the motor model are the current and speed signals and must be fed back to the controller. The current feedback is accomplished by a high speed Digital to Analog (DAC) output board. Typical voltages of this board could be 0-10V or +/-5V. For accurate and reliable performance over all operating ranges, the settling time of each DAC channel must be as small as possible. Speed sensor feedback is accomplished by a digital encoder or a resolver. Typically for automotive applications a resolver is used because it is more robust and durable than a digital encoder. The DS5202 Position Sensor Simulation (PSS) is used as the output card on the HIL simulator. The position sensor simulation is based on the principle of Angular Processing Unit (APU). It consists of two independent position accumulators which enables simulation of two independent mechanical shafts. HARDWARE OVERVIEW - The following section describes some of the other components of the dSPACE simulator some of which are optional. The power supply performs the function of a battery in a car and is used as the power source for all ECUs and the loads. The Load and Failure insertion unit is used to insert failures on ECU signals. Examples of faults could be short to battery, short to ground, open circuit or short between two ECU pins. The load wiring board is another optional component that allows the user to connect simulated loads but does not have any failure simulation capability.
RTI
PWM CAPTURE
DAC
SPEED SENS.
CONTROLLER (ECU) Figure 1 shows the required HIL components for electric motor simulation
f( ) functio n
3 Phase Current
Speed [RPM] Rate Transition Torque [Nm]

3 Phase Voltage
DS2102 RTI
1
From Engine
DS5202 RTI
2
In1 Out1 Position
To Rate Transition1Engine
Battery [V] INVERTER
From Battery Model
INDUCTION MOTOR
Figure 4 Usage of Rate Transition Blocks between fast and slow subsystems Task Priority Assigning Task Priority is an important issue when dealing with models that run at different rates. The blocks with the fastest times must be assigned the highest priority. The Task Priority setup is done in the Task Configuration menu in the Simulink model configuration parameters. Figure 2 Internal components of the HIL Simulator
Model Preparation - In an electric machine simulation the current control loop / Simulink subsystem runs at a faster rate than the rest of the model. Typically this loop is computed at or above the carrier frequency of the PWM gate drive signals from the ECU. Figure 3 below shows the Electric Machine subsystem driven by a Hardware Interupt block of the DS5202. The subsystem runs at a faster rate as compared to the rest of the model.
DS5202 PWM Interrupt Block DS5202_PWM_HW_Interrupt
Figure 5 Task Configuration setup dialog

Speed[RPM] ELECTRIC MACHINE Battery[V] Position[rad] Torque[Nm]
HIL SYSTEM FOR MULTIPLE ELECTRIC MACHINE SIMULATION Strong Hybrid vehicles generally have more than one electric motor coupled to a vehicle powertrain. The electric machines generally function as a motor or generator depending on the operating conditions and the Battery State of Charge (SOC). Strong HEVs with an automatic transmission also need an additional motor to operate the oil pump when the ICE is shut off. The transmission oil pump is used to maintain the minimum Line pressure of the hydraulic fluid in the transmission to maintain a particular gear. In addition to this automotive OEMs are focusing on switching to electric steering systems as opposed to the most commonly used hydraulic systems which are powered by the ICE. The electric steering system is operated by an electric motor and is proven to increase fuel economy and reduce
Electric Machine
Figure 3 Motor Model Subsystem triggered by a DS5202 Interrupt Since the motor and inverter subsystem runs at a faster rate than the rest of the model, it a Simulink requirement to add rate transition blocks for all connections between the fast and slow tasks.
emissions. There could be an additional motor required to operate the Air conditioning compressor during an ICE shut off. The HIL system must be able to satisfy all of the above requirements for a successful integration of a HEV. While it is possible to simulate more than one electric machine on one processor board (i.e. DS1006 or DS1005), it is recommended to run the current loop as fast as possible for accurate simulation. Each electric machine has a dedicated processor board and associated I/O cards (e.g. DAC boards, PWM Capture, Resolver Simulation Board). With more than one processor board it becomes a necessity for interprocessor communication. The processor boards are interconnected by a fiber optic communication cable. A DS911 piggy back module is mounted on the processor board that houses the communication ports for interprocessor communication.
Connection to Host PC: Processor boards can be connected in a convenient way to the host PC using the DS830 multilink panel as shown in the figure below
Figure 8 Processor board connection to the host PC using the DS830 multilink panel Multiprocessor Model Preparation: A multiprocessor setup requires additional Simulink blocks that need to be added to the model. Two important blocks are added to the Simulink model 1. Multiprocessor setup block 2. Inter-processor connection block (IPC) An IPC block is added for communication between two processor boards as shown in the figure below and can be individually configured to suit user requirements. A multiprocessor setup block resides in every model. This block provides individual build capability for each processor board and additional code generation options. It is also possible to generate interupts from one processor to the other. Sometimes it may happen that a particular processor board might have significantly higher computation to be perfomed than another processor board. In this case it is also possible to distribute some of the tasks that are computationally intensive to another processor board via. the IPC blocks.
Figure 6 DS911 Gigalink Module for Multiprocessor communication The DS911 has 4 independent optical high speed communication ports for connection to other processor boards with a net transfer rate of 1.25Gbits/sec. Up to 5 processor boards can be interconnected as shown in the figure below
Figure 9 Sample multiprocessor model with IPC blocks and multiprocessor configuration Figure 7 Gigalink cable connection between individual processor boards
SIMULATION OF COUPLED ICE AND ELECTRIC COMPONENTS - A HEV powertrain is divided into following 3 main components: Internal Combustion Engine Transmission Electric Drive / Generator Unit Each of the 3 components listed above has a dedicated processor board, and in some cases, a dedicated simulator rack / chassis. ENGINE SIMULATION - Engine simulation technology has been available for quite some time, and is a fairly mature area. For this reason, it is not discussed in detail in this paper. In addition to the standard IO and processing features, an engine HIL simulator must support certain engine specific simulation requirements: Crank/Cam sensor simulation Crank based event capture (injection, ignition etc.) Knock Sensor Simulation With automotive OEMs constantly working towards improving fuel economy, there has been an increasing trend in switching to Direct Injection (DI) engines. DI engines develop more power than their port fuel injected (PFI) counterparts while at the same time improve fuel economy. In DI engines the current profiles of Fuel injectors are closely monitored by the Engine ECU. For this reason it is necessary to use real injectors connected to the HIL simulator. The HIL simulator must also have the capability for high speed capture of the current profile. A DS665 current measurement board is used to measure the current profile of the injector, the captured profile is fed to a Injector channel for crank angle based capture of the current profile. Another new technology that is increasingly being used in engine applications is smart sensors. Smart sensors use a new protocol for information transfer and is known as SENT protocol which is used to transmit high resolution sensor data to the ECU. SENT (Single Edge Nibble Transmission) is a unidirectional signal transmitted as a series of pulses with data measured as falling to falling edge times. SENT is mainly used for sensors that require high resolution data such as Throttle Position Sensor (TPS), Manifold Air Pressure Sensor (MAP), Mass Air Flow Sensor (MAF). The Engine HIL Simulator must be capable of transmitting SENT data as well as receive and decode it. TRANSMISSION SIMULATION: Fuel Economy increases with the number of gear ratios in a transmission. This is because greater the available gear ratios the more closely the operation of the engine is to the highest efficiency. Automatic transmission simulation also requires the use of real loads such as solenoids that operate the different clutches to engage a particular gear. All automatic transmissions also have wheel speed sensors such as Transmission Input Speed Sensor
(TISS), Transmission Output Speed Sensor (TOSS). These sensors are Hall Effect based sensors that sink current pulses to the ECU. The HIL simulator must have the capability to source sink such current pulses. A DS207 current sink source module coupled to a conventional waveform generation channel is used as a signal conditioning module to simulate wheel speed sensor signals. CAN COMMUNICATION: The HIL simulator must facilitate CAN communication between the Engine, Transmission and Hybrid ECU. Apart from the external connection the HIL simulator should be capable of transmitting and receiving CAN messages to simulate messages from ECUs that are not present, this is also known as Rest Bus Simulation. During fault simulation comprehensive testing is done on the CAN bus. For example, disconnecting one of the powertrain ECUs from the rest of the CAN bus and observing the response of the system. The HIL simulator should have the capability of disconnecting one or more ECUs from the rest of the CAN bus and also other faults such as short CAN bus to ground, etc. CURRENT SENSOR CONNECTIONS TO HYBRID ECU One of the critical connections to a Hybrid ECU in the signal interface level simulation is the current sensor connections. The Hybrid ECU has two or more current transducers that monitor the current of the 3 phase power lines to the electric machine. The output from these current transducers is typically 0-10v or +/-5V proportional to the actual current which could range from a few amperes to hundreds of amps. The outputs from the DAC channels of the simulator are connected directly to the output of the current transducers thereby bypassing the current transducers.
Current Sensor A
High Current Phase A
To Simulator DAC Channel
Current Sensor B
HYBRID ECU
Current Sensor C
High Current Phase B
To Simulator DAC Channel To Simulator DAC Channel
High Current Phase C
Figure 10 Current sensor connections between Hybrid ECU and HIL FAULT SIMULATION - Like most ECUs, diagnostics are a very important part of an electric drive controller. Prototype systems can be very expensive and easily damaged if the ECU sends the wrong actuation signal. A HIL system needs to be able to generate all possible fault conditions and check to make sure the ECU diagnostics are working correctly and taking the required risk mitigation steps. In addition to the standard electrical
circuit failures of different sensor and actuator lines, HIL systems need to be able to simulate complex failure conditions also. Failure mode testing is a two fold process. First, the HIL needs to generate a fault. This can be triggered by a user, an automation script, or the detection of a faulty signal from the ECU. Faulty signals from ECUs that might need to be detected by the HIL can be: Dead time violations- An interrupt is triggered if the dead time between the high and low legs of an inverter falls below a specified level. PWM period violations- An interrupt is triggered if the PWM period falls below a specified level.
MEAN DUTY CYCLE MEASUREMENT - Mean value models of electric machines rely on the mean duty cycles of the three-phase PWM pulses as their primary input. These mean duty cycle values are normally calculated on the real-time processor using the total on time for the gates, and the model step size. This method works well in theory, but the total on time is calculated for the duration of the register latch time, which is almost the same as the model step size, but varies slightly from one execution step to another. This causes small distortions in the measured duty cycle value. For a more accurate measurement of the duty cycle, the DS5202 PWM solution now provides a latch time measurement. Calculating the mean duty cycle value from the actual register latch time ensures accuracy and a distortion-free measurement. The latch time can be used in the electric machine models for more than just duty cycle measurement. For instance, it allows users to develop better integrators in the model. Instead of assuming a constant time step in the discrete integrators, the latch time provides a more accurate time-base for calculating the output. ROTOR POSITION/VELOCITY FEEDBACK - The electric machine model is usually divided into two partsthe electrical and the mechanical. The electrical part captures the input voltage and armature current dynamics in the machine and calculates the torque generated. The mechanical part factors in the physical makeup of the motor and any connected loads. This subsystem inputs the torque and calculates the RPM of the machine. During offline simulation, this RPM can be integrated to calculate the motor position; This gets fed back to the electrical subsystem for d/q conversions. For HIL simulation, this step gets a little tricky. Now, the rotor speed and position have to be fed back to the ECU by simulating a position sensor, typically an encoder or a resolver. During initial trials, we used FPGA based hardware to simulate encoders on the rotor shaft. This worked fine for a few seconds, but soon the ECU diagnostics were triggered. The problem here ties back to the position calculation mechanism on ECU versus the HIL. ECU calculates a rotor position based on the encoder lines, but the model does this by integrating the RPM on the real-time processor. Because these two rotor position values are calculated asynchronously, the position read by the ECU soon starts to drift from what the real-time processor is calculating. The solution to this lies in using one integrator to calculate the rotor position and communicate it to both the ECU and real-time processor. To accomplish this, the Position Sensor Simulation (PSS) hardware writes the position counter value to a register that can be read by the real-time processor. Now, instead of integrating the RPM to find the position, the position value is directly read from the PSS hardware. This ensures that both the
Once the fault is detected, the HIL needs to trigger specific diagnostics that would normally be sent out by an inverter. These diagnostics can be as simple as a digital high or low signal or watchdogs synchronized with the PWM signal. Depending on the nature of the diagnostic signal, appropriate signal conditioning might be required. Inserting faults on the resolver signal for position sensor simulation is a common test performed during ECU software validation. Following are three of the most important tests performed during runtime: LOS, Loss of Signal - This fault is performed by disconnecting either the sine or cosine signals or both from the controller. On the HIL simulator this can be achieved by the FIU. DOS, Degradation of Signal - This fault can be generated by changing the amplitude of the sine and cosine waveforms above or below the thresholds defined in the controller software. LOT, Loss of Tracking - This fault occurs when there is phase shift between the sine and cosine waveforms (i.e. the phase difference between the sine and cosine waveform is no longer 90 degrees).
Figure 11 shows the amplitude and angle deviation of the sine and cosine waveforms for Resolver failures
ECU and the electric drive model read the same rotor position. SIMULATION MODES - Real-time models of electric machines in dSPACE HILs can be triggered in three different modes: 1. External interrupt driven 2. PWM interrupt driven 3. Software oversampled Depending on the type of application, one of these triggering modes is used. External Interrupt Driven - This mode requires an external master PWM pulse. This pulse is used internally in the ECU to synchronize the 3-phases of the PWM input to the inverter. For this reason, the master pulse is not always available on an external connector. In this mode, the electric machine model has to be triggered at the center of the 3-phase PWM pulses. This usually happens to be the rising or the falling edge of the master pulse. An interrupt triggered by the master pulse can be used in this case to execute the model. PWM Interrupt Driven - If an external interrupt source is not available, it is possible to calculate and predict the PWM pulse centers on an FPGA and send an interrupt to the main processor. The first two pulses of the PWM signal are used to calculate the PWM period. Knowing the period, the center of the third pulse can now be predicted. Once the third pulse has passed, the actual time period is used to update the calculated time period. This ensures that the PWM pulse center prediction mechanism does not drift away from the actual pulse centers. An interrupt generation mechanism then keeps sending interrupts to the real-time processor at the predicted pulse centers. Like the external interrupt driven mode, this mode can provide stable simulation only up to a certain RPM. Beyond this RPM, one needs to use an oversampling mechanism. The PWM pulse oversampling mode allows generation of multiple interrupts between two successive PWM pulse centers. Interrupts can be generated at 2x, 4x, or 8x the PWM switching rate to achieve stable simulation at higher RPM values. Because this method uses previous PWM pulses to calculate the pulse centers, it can provide correct interrupts for only fixed switching rate applications. This method does not apply to variable switching rate PWM signals. Software Oversampled - This method relies on a fast, asynchronous execution of the electric motor model. The
recommended rate is at least 10x PWM switching frequency. At this rate, the simulation is quasi-continuous and does not have any delays in the current response time. The only disadvantage to this mode is the high computational requirement, which can sometimes be hard to achieve on real-time processors. To overcome this limitation, the current loop can be separated from the electrical machine model and run on an FPGA instead of the real-time processor. FPGAs can allow for below 1 s execution times. For this the motor simulation including the associated IO for current feedback is simulated on the DS5202 FPGA solution also known as E-motor simulation (EMS). The slow task which includes the model of the mechanical vehicle system is simulated on the processor board. An emotor sim S-function acts as an interface between the FPGA and the processor board.
CONCLUSION
In this paper, HIL Simulation technology for testing hybrid powertrain controllers is presented and different challenges were discussed. HIL simulation is a growing field and there are still a lot of challenges that need to be addressed. Newer technologies are being explored for potential solutions in real-time simulation and HIL testing.
REFERENCES
1. D. Ramaswamy, R. McGee, S. Sivashankar, A. Deshpande, J. Allen, K. Rzemien, and W. Stuart, A case study in hardware-in-the-loop testing: Development of an ECU for a hybrid electric vehicle, SAE Technical Paper Series 01 (2004). 2. S. Nabi, M. Balike, J. Allen, and K. Rzemien, An overview of hardware-in-the-loop testing systems at visteon, in Proc. SAE Conf., 2004, pp. 1322. 3. C. C. Chan, The state of the art of electric and hybrid vehicles, Proc.IEEE, vol. 90, pp. 247275, Feb. 2002. 4. C. C. Chan, Y. S. Wong, The state of the art of electric vehicles technology, the 4th International Power Electronics and Motion Control Conference 2004, IPEMC 2004, vol. 1, pp. 4657. 5. I. Husain, Electric and Hybrid Vehicles: Design Fundamentals, CRC PRESS, 2003. 6. C. C. Chan and Y. S. Wong, Electric vehicles charge forward, IEEE Power Energy Mag., vol. 2, no. 6, pp. 2433, Nov./Dec. 2004.
7. M. C.Wehrey, Whats newwith hybrid electric vehicles, IEEE Power Energy Mag., vol. 2, no. 6, pp. 3439, Nov./Dec. 2004. 8. Schupbach, R. and Balda, J., A versatile laboratory test bench for developing powertrains of electric vehicles, in 2002 IEEE 56th Vehicular Technology Conference, vol. 3, pp. 1666-1670, IEEE, September 24-28 2002. 9. G. Maggetto and J. Van Mierlo, Electric and electric hybrid vehicle technology: A survey, in Proc. IEE Seminar on Electric, Hybrid, andFuel Cell Vehicles, London, U.K., Apr. 2000, pp. 111.
Syed Ali Technical Support Engineer dSPACE, Inc sali@dspaceinc.com 248-295-4674
DEFINITIONS, ACRONYMS, ABBREVIATIONS

I/O HIL EV HEV PHEV ICE ECM TCM CAN ADC DAC HIL ECU IPC PWM FPGA Input/Output Hardware-In-the-Loop Electric Vehicle Hybrid Electric Vehicle Plug-in Hybrid Electric Vehicle Internal Combustion Engine Engine Control Module Transmission Control Module Controller Area Network Analog to Digital Converter Digital to Analog Converter Hardware in the Loop Electronic Control Unit Interprocessor Communication Pulse Width Modulation Field Programmable Gate Array
CONTACT
Amanjot Dhaliwal Senior Applications Engineer dSPACE, Inc adhaliwal@dspaceinc.com 248-295-4649 Shreyas C Nagaraj Applications Engineer dSPACE, Inc snagaraj@dspaceinc.com 248-295-4663

Hardware in The Loop Simulation For Hybrid Electric Vehicles dSPACE - SAE - 0901 0198

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Hardware in The Loop Simulation For Hybrid Electric Vehicles dSPACE - SAE - 0901 0198

Hochgeladen von

Copyright:

Verfügbare Formate

09AE-0198

FEATURES OF TYPICAL HYBRID HIL SYSTEMS

Speed [RPM] Rate Transition Torque [Nm]

In1 Out1 Position

Battery [V] INVERTER

From Battery Model

Figure 5 Task Configuration setup dialog

High Current Phase A

To Simulator DAC Channel

High Current Phase B

To Simulator DAC Channel To Simulator DAC Channel

High Current Phase C

Syed Ali Technical Support Engineer dSPACE, Inc sali@dspaceinc.com 248-295-4674

DEFINITIONS, ACRONYMS, ABBREVIATIONS

Das könnte Ihnen auch gefallen