1、The simulation architecture described above allows for an easily upgradeable simulation. The modular architecture allows the user to integrate new subsystem models as other team members and/or suppliers provide models of various controllers. The architecture also supports the various phases in VSC d

2、esign, development, and validation.MODEL BASED VSC DESIGN PHASEDesigning a new controller from scratch is a daunting task. In a typical production program, the controls team is improving upon previous designs. For example, the fuel control strategy for a new product will begin with the previous vehi

3、cles design. The controls team would determine the design deficiencies and improve the control system through their product development process. Since HEVs contain vast amounts of new technology, the controls engineer will often begin with the strategy from a research program, or sometimes nothing a

4、t all.Model based design tools are essential for developing a control strategy from a limited legacy design. The model architecture and design discussed in the previous section allows for a model based VSC design. The VSC subsystem shown in figure 3 will contain the VSC model. Figure 4 shows how the

5、 VSC model is included in the VSC subsystem. Figure 4: VSC subsystem modelThe VSC model (center block in figure 4 is sandwiched between an input harness and an output harness. The input harness reorganizes, filters and applies any signal processing required to modify the incoming signal to match the

6、 model requirements. The output harness modifies the outputs of the VSC model to the output signal specifications expected by the other control modules.Since the final goal is to use this strategy in a prototype vehicle, the VSC model must move from the simulation environment to the target module. T

7、he key to this process is to use the exact same model developed in the simulation for the target module. Several vendors have developed auto-code tools that will generate C-code from a SIMULINK model. This auto-generated code will be flashed into a rapid prototype target module. The model used for t

8、he auto code process is shown in figure 5. Figure 5: VSC auto-code modelThe center block in figure 5 is exactly the same model as the center block in figure 4. The input drivers block on the left serves a similar function as the input harness in figure 4. This block will have hardware interface subs

9、ystems that work with the rapid prototyping system. For example, an engine coolant temperature sensor is typically a resistive type input. The input driver subsystem will interface to a hardware circuit on the target module that can sense changes in resistance. From there the input driver will use t

10、he transfer function of the ECT sensor to determine the temperature of the coolant. This information will be conveyed to the VSC model in engineering units. The inverse process is employed for the outputs of the VSC model, where engineering units are converted to electrical signals.This simulation d

11、esign allows the controls developer to design and simulate the VSC on the desktop. From there, the model is exported to a target module using a rapid prototype hardware and software tools. This process can be quickly repeated to the point of sitting in a prototype vehicle, running a test, modifying

12、the VSC model to fix an issue, simulating the new model to verify fix, auto-coding the model, flashing the code into the target, and finally, verifying the fix on the vehicle. All of this can occur without leaving the vehicle.CODE BASED VSC DESIGN PHASERapid prototyping (RP tools are especially usef

13、ul in the early stages of controls development. However, as the product development process moves closer to production, the control strategy must move into the final target module. A vehicle system controller is a piece of strategy that could reside in its own module, or it could share space with an

14、other controller. As the production program goes through prototype build phases, the controls team will need to transition away from the RPtools. Typically, the production target module will require the control strategy to be based in C.As a result, the VSC model used in the simulation environment w

15、ill need to transition from model based to C-code based. This can occur by hand-coding the strategy from the model, or an auto-code generation tool could be used. Once C-code has been created, the C-code will become the base for the strategy.It is important that the model developed for the earlier p

16、hases in the product development process be re-used with the C-code. That way, the controls developer can continue to use the simulation environment as a place for testing out software and strategy changes. Presently, there are several methods for simulating C-code in the MATLAB environment. S-funct

17、ions and in-line function calls from STATEFLOW are two methods of simulating C-code.This process is accomplished using the architecture already discussed. After a VSC model has been developed using C-code, it will be integrated into the desktop simulation environment. The only part of the model that

18、 will change is the VSC subsystem. The VSC subsystem will appear exactly as shown in figure 4. The difference is that the middle block (VSC Model will now be C-code based. The input and output blocks will serve the same functions. The input block will modify the inputs from the model into the manner

19、 expected in the C-code. The outputs of the C-code will be modified to the specifications of the vehicle interface. The input/output blocks will serve the same purpose as the low-level and high-level drivers used inside the target module. The controls engineer is interested in simulating their contr

20、ol strategies. As such, it is not necessary to include all of the c-code that is run on the target module. This is especially important if the VSC will be sharing space on the same target with another controller.The final piece to consider when including c-code in a simulation is the calibration. Ty

21、pically, the calibration developed for the vehicle will significantly vary from the values defined in the source code. Subsequently, when simulating the C-code, it is imperative to have an accurate calibration. It is also important to simulate the c-code without modifying it for use in the MATLAB en

22、vironment. In summary, the simulation must be able to use the production c-code with the production calibration.To solve this problem, a combination of custom C-code functions and pearl scripts were developed. This calibration utility imports the production calibration into the simulation environmen

23、t without modifying the source code. This critical step enables the simulation to produce results that mirror real world test data.The simulation model originally developed for the vehicle system controller model is easily upgraded to use the production source code. The VSC strategist can use their

24、production C-code in a proven simulation environment. It also allows the user to gain confidence in the transition from Model based to C-code based implementation. By simulating both VSCs and comparing the results, the engineers can gain confidence in the transition.HARDWARE IN THE LOOPThe VSC commu

25、nicates with all major controllers in a hybrid electric vehicle. The actions of the VSC are based on the actions of the driver and the subsystems. Testing the control strategy in the VSC is a complex task. It will be nearly impossible to gain confidence in the VSC design by using a traditional softw

26、are test bench. The typical software test bench allows the user to manually control all of the inputs to the software. However, there are limited opportunities for including intelligent controls behind the set-points of the inputs. For example, it may not possible to modify an input to the VSC based

27、 on an output of the VSC. Since a HEV is a closed loop system with tightly coupled controllers, it is imperative that a more intelligent software testing platform is required.Hardware in the loop (HIL provides a solution that allows a user to simulate the system that the controller communicates with

28、. On a vehicle, the target module is connected to a series of sensors and actuators. On a HIL, the target module is connected to a real time model of the vehicle. Figure 5 pictorially summarizes the HIL methodology for testing a VSC.Figure 5: Hardware in the loop definitionThe same model developed f

29、or the desktop simulation can be used for the HIL. The architecture that allowedthe controls developer to simulate both the C-code and Model based implementations of the VSC will support a HIL application. For the HIL, the target module will replace the VSC subsystem model. Figure 6 shows how this w

30、ould look in the modeling environment. The subsystem model shown in Figure 6 is the samesubsystem shown in Figures 4 and 5. Figure 6: VSC subsystem model used on the HIL The input harness subsystem shown on the left side of Figure 6 contains HIL specific models that will communicate with the HIL dev

31、ice. For example, the plant model could generate an engine coolant temperature sensor signal. This would be transmitted through the model to the input harness. The input harness would convert this signal from engineering units to a resistance. This resistance would then be modified on the HIL circui

32、t that is connected to the physical module being tested on the HIL. The inverse occurs on the output side. The output harness receives signals from the target module and coverts the electrical signals into engineering units the model is expecting. For example, the VSC could request the air condition

33、ing clutch to be engaged. An output of the target module would change state, the HIL would recognize the change of state and it would send a signal to the plant model indicating that the VSC has requested air conditioning. The entire model will then be compiled into an executable and flashed on the

34、processor contained within the HIL. The HIL then simulates the model in real time with the same closed loop simulation used on the desktop. This allows the controls developer to test the VSC strategy running in real time on the target module.VALIDATIONThe shared model that is used on the desktop and

35、 for the HIL needs to reasonably match the vehicle behavior. The more accurate the model is, the more useful it becomes. It is important to understand how closely the model mimics the actual vehicle. The controls engineer must understand when the simulation will provide an adequate test platform for

36、 the VSC, and when vehicle level testing is required. Sometimes a prototype will notbe available and the simulation is the only place to conduct a test. As a result, the simulation should be continuously checked against vehicle data. The model should be improved as its deficiencies are discovered. T

37、he model developed for the Ford HEV Escape program has been validated using the following method: 1. Run a vehicle test in a controlled environment andrecord all relevant control parameters.2. Run the same test on the HIL using the samestrategy and calibration. 3. Compare results.A vehicle prototype

38、 was tested in a controlled manner on a chassis dynamometer. The resulting vehicle speed trace was fed into the closed loop driver model in the simulation. The closed loop driver model actuates the accelerator and brake pedals to match the vehicle speed trace. This method will ensure the velocity tr

39、ace recorded during the vehicle test will reasonably match the vehicle speed trace during the simulation. The HIL was used as the test platform for the simulation model. Figure 7 shows the vehicle speed trace that was recorded during the vehicle test. The vehicle speed trace that was a result of the

40、 closed loop driver on the HIL is show in dots on the same plot. As expected, there is a very good match between vehicle test data and simulation results. The closed loop driver model ensures the results will match.Figure 7: Vehicle Speed Trace for HIL and VehicleCloser inspection of the vehicle spe

41、ed and the accelerator pedal position reveal some differences. Figure 8 shows a portion of the drive cycle that illustrates the differences between the simulation andthe vehicle test. The graph shows that the simulated driver tends to depress the accelerator pedal later than the actual driver. Since

42、 the actual driver was following a predefined drive cycle and had a preview of the desired vehicle velocity during the test, the actual driver tended to anticipate the required pedal changes. There are some magnitude differences in the amount of accelerator pedal, but overall, there is a reasonablem

43、atch Figure 8: Close up accel pedal and vehicle speed plotsFigure 9 shows a comparison of the engine speed from the vehicle and the HIL. From a high level, the engine speeds match quite well. The engine on/off times are very similar and the magnitude of the two engine speedsis similar. Figure 9: Eng

44、ine Speed comparisonA closer view of the engine speed illustrates how the model deviates from the actual vehicle. Figure 10 shows a smaller portion of the drive cycle. The trends match very well. For every rise in engine speed on the vehicle, there is corresponding rise on the engine speed on the HI

45、L. However, there are some slight timing differences that can be attributed to the earlier accelerator pedal tip-ins previously described. There are also some significant magnitude differences. The engine speed on the vehicle tends to be higher than on the HIL. Theengine on/off times are very simila

46、r.Figure 10: Engine speed detailThe differences in engine speed shown in figure 10 can be explained by reviewing the engine torque differences. One of the main functions of a VSC is control the system such that the driver demanded power is delivered to the wheels while controlling the battery power

47、within acceptable limits. Reviewing the engine torque data in figure 11 illustrates that the delivered engine torque is higher on the HIL. Subsequently, the VSC determines that to meet the driver and battery power requirements, the engine speed must be higher. As a result, the engine speed for most

48、operating points is higher on the vehicle. The engine speed and torque are tightly coupled in a hybrid electric vehicle. As a result, small differences between the engine torques will result in changes in engine speed. Overall, the engine operating points are similar and provide a good enough match

49、for most simulation purposes. After all, each engine will be different and if the same test was conducted on another vehicle, the engine torque production could be different in some other way. Figure 11: Engine torque production comparisonIn addition to the engine, an HEV has an electric component to the powertrain. Figure 12 shows a close up of the battery power. There are some small differences, but overall, the battery power m