Modeling and Simulating a Performance Hybrid Electric Vehicle

Transcription

1 Modeling and Simulating a Performance Hybrid Electric Vehicle A Thesis Presented in Partial Fulfillment of the Requirements for the Degree Master of Science in the Graduate School of The Ohio State University By Jason J. Ward, B.S. Graduate Program in Mechanical Engineering The Ohio State University 2015 Master s Examination Committee: Prof. Shawn Midlam-Mohler, Advisor Prof. Giorgio Rizzoni

2 c Copyright by Jason J. Ward 2015

3 Abstract As part of EcoCAR 3, an Advanced Vehicle Technology Competition, The Ohio State University is among sixteen teams challenged with the task of re-engineering a stock 2016 Chevrolet Camaro into a hybrid electric vehicle. Part of the Ohio State design process entails using model based design to develop a full vehicle model of the hybrid Camaro that can simulate energy consumption for various testing purposes. This thesis describes the design process behind developing the plant and control models, integrating everything together in a full vehicle model, performing fault insertion testing for mitigation development, and constructing the model architecture such that transfer between In-the-Loop platforms is easier than conventional methods. The full vehicle model developed will be refined and used by the Ohio State team throughout the four year EcoCAR 3 competition. ii

4 This is dedicated to my family and friends who have helped me over the years in my pursuit of higher education. Most importantly, this thesis is dedicated to my fiancé, Marcy, who has been there to support my efforts in school and EcoCAR. iii

5 Acknowledgments I would like to acknowledge my advisor, Prof. Shawn Midlam-Mohler, for his superb guidance and knowledge throughout this thesis work and throughout all five years of my tenure on EcoCAR. His ideas, thoughts, and management made each EcoCAR team successful and this thesis possible. I would also like to acknowledge my teammates on EcoCAR throughout the years. Eric Schacht, Travis Trippel, Andrew Garcia, Matthew Yard, and Katherine Bovee were some the leaders who mentored me and helped me develop the skills that I would need in the automotive field. I d also like to acknowledge the team members who have been a part of EcoCAR 3 and have helped make this thesis possible and make the first year of competition successful: Andrew Huster, Arjun Khanna, Sam Yacinthe, and Tom Brown. An additional acknowledgement to a great co-team leader of EcoCAR is due to M.J. Yatsko. And a special acknowledgement to Sarah Jadwin, who constantly reminded us all to take a step back and have a laugh every once in a while. She made EcoCAR fun for everyone. iv

6 Vita February 21, Born - Marietta, OH A.S. General Sciences, Washington State Community College A.A. Liberal Arts, Washington State Community College B.S. Mechanical Engineering, The Ohio State University Graduate Research Associate, The Ohio State University 2014-Present GATE Fellow, The Ohio State University Publications Research Publications K. Bovee, A. Hyde, M. Yatsko, M. Yard, M. Organiscak, E. Gallo, A. Huster, J. Ward, G. Rizzoni, S. Midlam-Mohler Refinement of a Parallel-Series PHEV for Year 3 of the EcoCAR 2 Competition. SAE Technical Paper, , Jan K. Bovee, A. Hyde, M. Yard, E. Gallo, M. Organiscak, A. Huster, M. Yatsko, J. Ward, S. Midlam-Mohler, G. Rizzoni Fabrication of a Parallel-Series PHEV for the EcoCAR 2 Competition. SAE Technical Paper, , Jan Fields of Study Major Field: Mechanical Engineering v

7 Table of Contents Page Abstract Dedication Acknowledgments Vita List of Tables ii iii iv v ix List of Figures x 1. Introduction Advanced Vehicle Technology Competition Motivation Project Objective Organization of Thesis Literature Review Model Based Design Motivation for Model Based Design Considerations in Model Based Design Automotive Plant and Control Model Development Process Model Setup and Development Model Validation and Verification vi

8 3. Component Plant Model Development Engine Plant Model Engine Simulation and Modeling Requirements Engine Model Interfaces Engine Model Development Transmission and Clutch Plant Models Transmission and Clutch Simulation and Modeling Requirements Transmission and Clutch Model Interfaces Transmission and Clutch Model Development Electric Machine and BAS Plant Model Electric Machine and BAS Simulation and Modeling Requirements Electric Machine and BAS Model Interfaces Electric Machine and BAS Model Development Energy Storage System Plant Model Energy Storage System Simulation and Modeling Requirements Energy Storage System Model Interfaces Energy Storage System Model Development Torque Coupling Plant Models Torque Coupling Simulation and Modeling Requirements Torque Coupling Model Interfaces Torque Coupling Model Development Accessories Plant Models Accessories Simulation and Modeling Requirements Accessories Model Interfaces Accessories Model Development Other Vehicle Component Plant Model Vehicle Component Simulation and Modeling Requirements Vehicle Component Model Interfaces Vehicle Component Model Development Subsystem Soft ECU Development Engine Soft ECU Engine Soft ECU Requirements Engine Soft ECU Development Transmission and Clutch Soft ECU Transmission and Clutch Soft ECU Requirements Transmission and Clutch Soft ECU Development vii

9 4.3 Electric Machine and BAS Soft ECUs Electric Machine and BAS Soft ECU Requirements Electric Machine and BAS Soft ECU Development Energy Storage System Soft ECU Energy Storage System Soft ECU Requirements Energy Storage System Soft ECU Development Accessories Soft ECUs Accessories Soft ECU Requirements Accessories Soft ECU Development Full Vehicle Model Development Requirements of Full Vehicle Model Vehicle Model Architecture Supervisory Control Soft ECU Development Supervisory Soft ECU Requirements Supervisory Soft ECU Development Signal Attributes Fault Insertion Testing Modeling Results Application in EcoCAR Automated Testing Integration Managing Workflow Knowledge Transfer Conclusions and Future Work Conclusions Future Work Bibliography viii

10 List of Tables Table Page 2.1 Ohio State EcoCAR xil Platforms Example Needs-Metrics Matrix [3] Battery Thermal Model Parameters Soft ECU and Associated Physical Controller Full Vehicle Model Requirements Ohio State University EcoCAR 3 Vehicle Technical Specifications Supervisory Soft ECU Requirements Vehicle Operating Modes Signal Attributes Affected by Corrupter EcoSIM3 Initial Modeling Results vs VTS Targets EcoSIM3 Cycle Velocity Error Crossover of Plant and Control Requirements for EcoSIM Model Release Schedule Specifications ix

11 List of Figures Figure Page 1.1 Ohio State EcoCAR 3 Architecture Traditional vs. MBD V-Diagram [1] Ohio State EcoCAR 2 Systems V-Diagram Requirements Maturity of Plant Models with MBD [2] Modeling Techniques for MBD [2] Modeling Methods Applicable to Plant Modeling [2] Requirements Management and the Project Management Triangle [3] Example Concept Selection Process [3] Example System Identification Process [3] Refinement Process for Input/Output in Modeling Cell Open Circuit Voltage vs SOC [7] Ohio State EcoCAR 3 Vehicle CAN Topology Control Model Isolation Example Clutch Stateflow Diagram General Model Architecture x

12 5.2 EcoSIM3 Full Vehicle Model Layout EcoSIM3 Simulation Parameters GUI Normal and Performance Modes Preliminary Shift Request Logic for EcoSIM EcoCAR 2 Data for Battery SOC EcoSIM3 Model Results for SOC EcoCAR 2 Data for Accelerator Pedal Position EcoSIM3 Model Results for Accelerator Pedal Position Fault Tree for a Missed Transmission Shift Logic Overview for Automated Shifting in EcoSIM Completed Gear Shift in EcoSIM Shifting Fault Logic for Clutch Fault Shift Failure and Fault Mitigation in EcoSIM EcoSIM3 505 Velocity Trace in CD Normal Mode EcoSIM3 505 Velocity Trace in CS Normal Mode EcoSIM3 505 Torque Outputs in CD Normal Mode EcoSIM3 505 Torque Outputs in CS Normal Mode EcoSIM3 505 Speed Outputs in CD Normal Mode EcoSIM3 505 Speed Outputs in CS Normal Mode EcoSIM3 505 Battery SOC in CD Normal Mode EcoSIM3 505 Battery SOC in CS Normal Mode xi

13 6.1 Refinement of Control Software through Testing EcoCAR 3 Vehicle Development Process with SMS and Controls EcoCAR 3 Model Release Schedule SourceTree and GitHub Version Control Software Team Members Responsible for EcoSIM3 Knowledge xii

14 Chapter 1: Introduction 1.1 Advanced Vehicle Technology Competition The continuing trends in the automotive industry to create fuel efficient and environmentally friendly vehicles drives current research to find innovative ways to rely less upon fossil fuels. A significant portion of research over the past few decades has been in the area of hybrid electric vehicles and the subsequent technologies. Over the past 27 years, the United States Department of Energy (U.S. DOE) has sponsored Advanced Vehicle Technology Competitions (AVTCs). Having partnerships with the North American OEMs and automotive industry suppliers and being managed by Argonne National Labs (ANL), the AVTC program has been a proving ground for the next generation of automotive engineers. AVTCs have also helped push the automotive industry and the up-and-coming engineers towards developing the most fuel-efficient and customer-desired vehicles on the market. EcoCAR 3 is the latest AVTC and has a four year vehicle development timeline. The premise of EcoCAR 3 is re-engineer a stock conventional vehicle to have a hybrid-electric powertrain to achieve the goals of increasing fuel economy, reducing overall well-to-wheel oil consumption, minimizing emissions, and maintaining or improving consumer acceptability of the vehicle. An aspect of EcoCAR 3 that has not 1

15 been emphasized as much in previous AVTCs is the performance of the vehicle. For this competition, the 16 involved teams will be creating a hybrid-electric Chevrolet Camaro. 1.2 Motivation The Ohio State University EcoCAR 3 team has designed a plug-in hybrid-electric vehicle (PHEV) to meet the needs of a performance hybrid for the competition. The vehicle architecture is shown in Figure 1.1. The vehicle powertrain contains a 2.0L 119kW Ford GDI I4 engine, a Tremec T-5 five speed automated manual transmission (AMT), a 16kW Denso integrated starter-generator (ISG) for the belted alternator starter (BAS) motor, a 150kW Parker-Hannifin electric machine, and an 18.9 kw-hr A123 Systems energy storage system. These components were all selected to best fit what was required by the Ohio State team to perform well in the competition and to best suit the capabilities of the Ohio State team. Figure 1.1: Ohio State EcoCAR 3 Architecture 2

16 To properly set up an environment in which accurate controls can be developed over the remaining years of competition, a robust full-vehicle plant model is needed. This full-vehicle model and simulation environment could also be used throughout EcoCAR 3 to finely-tune vehicle technical specifications (VTS) and conduct numerous types of fault insertion testing. This full-vehicle model also needs to be capable of being transferred for use in the various In-the-Loop environments that are necessary throughout the four year vehicle development process of EcoCAR 3, including Model-In-the-Loop (MIL), Software-In-the-Loop (SIL), Processor-In-the-Loop (PIL), Hardware-In-the-Loop (HIL), and Vehicle-In-the-Loop (VIL). 1.3 Project Objective The goal of this research is to present the process taken to design and build the component plant models, the control models, and the supervisory controller and how those all come together with actuators and sensors to create the full vehicle model known as EcoSIM3. The full vehicle model will be designed based upon appropriate assumptions and limitations of model accuracy and fidelity found through various methods, including component specifications, real world performance data, and a literature search. Within the scope of this project is the design of basic soft electronic control units (ECUs) for the full vehicle model that will be vastly improved upon in future work. The robustness of the software and its ability to move to different In-the-Loop platforms will also be taken into consideration along with the software s ability to handle fault insertion testing. Finally, the full-vehicle model should be designed with 3

17 knowledge transfer and ease of learning curve in mind for future members of the EcoCAR 3 team and the next AVTC competition. 1.4 Organization of Thesis The rest of this thesis is organized as follows. Chapter 2 will introduce the concept of model-based design (MBD), why it is useful, and how it has been used in the past. This chapter will also discuss the background for automotive plant model development process and a literature search on component plant models. Chapter 3 will list all the component plant models used in the vehicle, the specifications and requirements for each, and how every model was developed. Chapter 4 describes the steps taken to develop soft ECUs for the subsystem plant models which were developed in Chapter 3. Chapter 5 is going to cover the component model integration into a combined full vehicle model. It will also describe the overall structure of the full vehicle model, the signal routing and interfacing, and the controls developed to operate the model. Chapter 6 will explore how the full vehicle model developed will be used in the EcoCAR 3 competition. Covered is the automated testing integration, how the workflow for model and control development will be managed, and how knowledge transfer of the model will occur. Chapter 7 will draw conclusions on the outcomes of the project and discuss future work needed for the full vehicle model. 4

18 Chapter 2: Literature Review 2.1 Model Based Design Motivation for Model Based Design In the automotive industry, model based design (MBD) or model based development has for the most part become the standard of creating plant and control solutions for vehicles. Differing from the earlier, traditional methods of developing vehicle controls which included hand-coding software, MBD utilizes tools that make the process easier for engineers such as auto code generation. [1] defines what MBD is with respect to the automotive industry and describes some key advantages of the process over the original methods. The MBD process is a set of steps in which modeling is used to facilitate the understanding and early validation of the requirements defined in a typical engineering process [1]. This process and how it directly compares to the traditional methods can be further described by examining an engineering design V-diagram. The V-process is used in systems engineering development and is centered around the requirements for the system. The process documents requirements at the start of development, demands the system be designed to those requirements, and eventually validates the system design based upon the same requirements [1]. Figure 2.1 shows some 5

19 comparisons between the V-diagram process for traditional controls development and MBD. The development process starts on the left side of the V with requirements definition and design and progresses towards validation and verification on the right side of the V [1]. MBD inserts the ability to build models and run simulations to ensure compliance with customer requirements. Figure 2.1: Traditional vs. MBD V-Diagram [1] 6

20 Figure 2.2: Ohio State EcoCAR 2 Systems V-Diagram Requirements An example of this V-diagram that has been followed in the past by the Ohio State EcoCAR team is given in Figure 2.2. Each stage of the MBD process can be set up to have six element which should be defined prior to the execution of each stage (or phase) [1]: Phase Objective - captures a high level description of the purpose, scope, and goals of the development phase that is to be undertaken Phase Activities - the tasks associated with the development phase that are to be undertaken Phase Entry Criteria - define the measurements, documents, and/or artifacts needed in order to begin the tasks defined as part of the modeling phase 7

21 Phase Resources - individuals or items required for the successful completion of the phase activities Phase Deliverables - the required and/or suggested work products created during the development phase that is to be undertaken Phase Exit Criteria - the requirements necessary to complete the development phase that is to be undertaken The purpose of using MBD in the system development process is driven by three major benefits: cycle time reduction, quality improvement, and defect reduction [1]. These are all attractive areas for engineers on any project, especially in the automotive industry where system development time can be short due to customer and/or company demand to produce new vehicles every model year. MBD improves quality and lowers development/cycle times by introducing early validation of requirements through modeling and simulation [1]. [8] also indicates that using MBD ensures that the final product meets system requirements because models enable the identification and fixing of errors early on in the development process. Use of models also enables different engineering teams from different departments to work in parallel and to work together and communicate between the various stages of the design process Considerations in Model Based Design There is a solid understanding for the motivation of MBD in the system development process, but care must also be given to considering how to utilize the MBD process. [2] presents numerous considerations for control system development using MBD, the first of which is instilling a modeling culture within the organization responsible for the systems engineering development. Companies, university labs, and 8

22 other organizations may choose to employ different methods of embracing MBD from a top-down approach through rules and regulations, to a more organic route where the culture grows naturally among those designing the systems [2]. This is important because without all the designers and engineers on the same page with MBD, work cannot be done in parallel or in collaboration easily and a large portion of the advantages offered by MBD are void. Along with developing the culture of MBD, companies or lab groups need to invest in modeling resources and emphasize documentation. Setting up an organizational infrastructure that requires documentation of models helps engineers from different teams quickly and easily understand what each model is and its capabilities/limitations [2]. In addition to the key organization point, it is important that groups broadcast both the successes and the failures that occur [2]. With the knowledge that comes from these communications, engineers can improve malfunctioning models and have confidence in other models that have been proven to work for the design requirements. A large portion of MBD focuses on the plant model development because this model is central to accurate controls development for the system. The fundamental goal of designing a plant model is to validate the controls that are being developed [5]. The plant model represents the physical system for which the controls are being created and this demands an accurate plant model to ensure requirements are met. The plant model also allows the monitoring of state variables which cannot be measured in a physical system [5]. In the development of any plant model, especially in-depth vehicle powertrain models, it is imperative to employ a plant model development strategy. Design errors 9

23 can be found early through model verification and can be much easier and less costly to correct, therefore it advised to start plant model development early in the design process [2]. The model that is created at the initial stage is where critical decisions are often made for customer requirements [6]. Defining simulation and modeling goals is often the first step is creating a plant model, followed by defining interfaces for component models, understanding where domain interactions occur, and making sure to include sensor and actuator dynamics when first defining the structure of the model [2]. As pointed out in [2], a challenge at this stage is often that not all information needed is accessible. The EcoCAR team has faced this challenge in the past and has relied heavily on engineering judgment and experience from prior competitions. Within the early stage of plant model development, it is key to determine what physical effects need to be included in the model to provide an appropriate representation of the system dynamics [2]. The sticking point to this is that as more physical effects are accounted for and model fidelity increases, simulation times increase. This can create large problems further down the MBD process because of the inability to run quick and large-batch simulations. Model fidelity is a thorough representation of the physical system with respect to the needs of the control system [5]. To make the early stages of the development process go more smoothly and to ensure model fidelity only increases when it is needed, plant models are often created to be relatively simple to begin with and increase in complexity as the system design matures [2]. A generic look at this effect is shown in Figure

24 Figure 2.3: Maturity of Plant Models with MBD [2] Creating a MBD environment that provides extensive flexibility to create physical plant models using a wide range of methods for a variety of applications helps provide the most appropriate modeling technique for the analysis needs and requirements [2]. Some modeling techniques that do not create too computationally intensive models are listed below [2]: Signal Flow Models - a traditional method used to graphically express first principle equations as part of a block diagram and is typically used for modeling control algorithms but can be applied to detailed plant modeling Transfer Functions - typically used within signal flow models, transfer functions are common for simpler systems were the input/output relationship can easily be derived from first principle equations 11

25 Multi-Dimensional Lookup Tables - a relatively powerful technique that incorporates measured data into a model to define the input/output relationships Statistical Models - a technique that utilizes statistical methods with measured data to create input/output relationships derived from the data State-Space Models - similar to transfer functions, a state-space model is created by linearizing a more complex model at a specified operating condition Embedded Functions - uses predefined functions written in a common language, such as C++, by incorporating them into the system model Physical Network Approach - a non-causal method with domain-specific physical connections allowing for the energy exchange between physical components It is important to keep in mind that while data driven models that use items such as lookup tables or maps are very good for computation time and are useful when equations are unknown, they lack the dynamic behavior of models based on first principles [2]. Though the sacrifice of not having the exact dynamic behavior of a system is often times made because it is impractical to derive and implement the system level equations into a model. Physical models and their physical connections can often times be a benefit because the connections handle the subsystem boundaries and result in less rework as the models are improved over time or move between simulation platforms [2]. Statistical models can be derived from multiple data sets and used to characterize the plant, giving the model a higher degree of accuracy 12

26 while maintaining a relatively low execution times [2]. One final method looked at in [2] was a combination method in which complex components were replaced with statistical models to maintain higher accuracy but improve simulation capabilities. Figure 2.4 shows the difference in modeling detail presented by various modeling methods, and Figure 2.5 shows how different modeling methods fall on the range of fidelity from first principles modeling to data-driven modeling. Figure 2.4: Modeling Techniques for MBD [2] Figure 2.5: Modeling Methods Applicable to Plant Modeling [2] Investing in creating appropriate plant models can be critical to a development process s success. The model itself needs to match up with the analysis requirements and desired outcomes from simulation. The authors of [2] refer back to an old adage stating that All models are wrong; some are useful which captures the essence that models are approximations of physical behavior and there will always be some amount of inaccuracy. However, using the wrong model for an analysis can result 13

27 in very inaccurate results. Success in this area is dependent upon good requirement definition and capturing items with proper documentation [2]. Some final considerations when starting a MBD process focus on how to set up the model for future success. Planning for model reuse and starting with the end in mind will enable the work that is put into creating the model to pay off several times over. Designing models in which the fidelity can be adjusted without major rework can save time in the later stages of the design process should models need to be made more accurate [2]. Asking the following questions during the planning process can greatly help scope the modeling tasks and maximize reuse [2]: Who can benefit from the model and how will they use it? Does a model already exist that meets the needs or can an existing model be easily modifies? Can an existing high-fidelity plant model be used to parameterize a lower fidelity model? What additional effects may be required (thermal effects, tolerances, etc.)? Will this model need to run in real time? How does this model interact with the rest of the system? Setting a model up to utilize automation can also make it more usable in the future and decrease total time spent doing simulations to get desired results. Repetitive tasks that are essential and take up a lot of time such as control calibration, parameter optimization, and model validation are good candidates for automation [2]. Creating 14

28 scripts that use optimization techniques for automatic parameter tuning can be very efficient and used at the individual component level as well as the system or subsystem level [2]. Finally, models developed through the MBD process should be designed to be deployed across the In-the-Loop platforms. In-the-Loop, or xil, platforms are different stages used throughout the plant and control model development process and have several separated steps [4]: Model-In-the-Loop (MIL) - The first step in the development process, MIL incorporates both the plant and control models running in a simulation environment (such as Simulink) on a computer with non-compiled code. At this stage of simulation, the control code contains no ECU specific properties. The goal of this stage is to test the model architecture and the functions in a hardware independent manner to measure the validity of models Software-In-the-Loop (SIL) - In this stage, the control model is compiled into code that could theoretically be flashed onto actual ECU hardware. The plant model is kept uncompiled. At this stage and beyond, the plant and control model can be executed separately at their corresponding rates [6]. The purpose of this step is to run actual ECU code and simulate how the ECU would interact with the plant models which are representatives of real life systems. Processor-In-the-Loop (PIL) - The compiled control code is put onto the ECU hardware in this step and tested for input/output capability. The goal of this step is to ensure the software is compatible with the interfaces needed in the controller. 15

29 Hardware-In-the-Loop (HIL) - The compiled control code is left on the controller and the plant model is put onto a simulation computer system that represents the physical system being controlled. For EcoCAR purposes, as well as throughout the automotive industry, this is a dspace Hardware-In-the-Loop (HIL) system. In this stage, components that do not have very accurate plant models can actually be harnessed into the system and tested. The goal of this step is to thoroughly test the control code and how it responds and handles the changes that could occur with the real life systems but in real time on a bench setup. Vehicle-In-the-Loop (VIL) - The final step of the xil platforms is VIL, which is putting the control code and controller in the vehicle (for the purpose of EcoCAR) and conducting actual testing and calibration on the final product. An overview of how the Ohio State EcoCAR team utilizes xil testing throughout the MBD process is shown in Table 2.1. To maximize a model s value, they should be capable of being used during all stages of the xil process [2]. The models should be set up with a structure with which they can easily be transferred between platforms without many changes. This helps speed up the MBD process and creates a unified method of structuring models within a company or university lab group. The seamless transition capability and having a system model that captures all of the customer requirements and carries them throughout the xil process is critical to fast and sustainable success of the MBD process [6]. 16

30 Table 2.1: Ohio State EcoCAR xil Platforms Platform MIL SIL PIL HIL VIL Supervisory Controller Emulation Plant Emulation Source or Compiled Digital Code Secondary Controller Emulation Desktop w/ Simulink Desktop w/ Simulink Desktop w/ Simulink Desktop w/ Simulink dspace MABx Test Signals Rep. Plants dspace MABx dspace HIL dspace MABx Actual System Source Compiled Compiled Compiled Compiled Desktop w/ Simulink Case-bycase Case-bycase Case-bycase Case-bycase 2.2 Automotive Plant and Control Model Development Process Model Setup and Development The MBD process can be applied to various areas of engineering in which systems and their controls are being developed. However, in this project the focus will be on the automotive application and developing a vehicle model. Following along with what was presented in Section 2.1, this section of the literature will be devoted to the steps needed in MBD for development of a vehicle model and is mostly derived from [3]. Identifying customer needs and requirements is often considered the first step in the development process. The identification and definition of customer needs (or 17

31 model needs) creates a set of requirements that are, at the initial steps of the process, independent of any concept that may be chosen at a later time as a solution to the system being developed [3]. This is indicative of identifying what the system needs to do and not how it needs to be done. These requirements create the basis for the entire validation process (described in Section 2.2.2) [3]. It is important that during this initial stage, the customer or end requirements are captured and documented in their entirety with no ambiguities, incorrectness, or contradictions [3]. This if vital if the system is going to be correctly developed and tested to meet what the customer actaully wants. Should any uncertainty or wrong metric exist at this early stage, the model is highly likely to not succeed easily or quickly and much more engineering time and cost will be spent fixing the issue at a later time. It is also important to note that requirements continuously change, and constant updating/deleting or creation of new requirements throughout the entire MBD process is necessary [3]. This is due to the simple fact that customers needs sometimes change for a multitude of reasons both foreseen and unforeseen. Requirements can be classified in two different categories: functional and nonfunctional [3]. Functional requirements state how the system should act and respond. Non-functional requirements state the quality characteristics of and constraints on the system. With the need to facilitate changing requirements, the proper management of those requirements is imperative to the success of the project. The main purpose of requirement management is to establish a common understanding between the customer and the project and form the basis for planning and managing the project [3]. This includes the capturing of the requirements in the early stages and ensuring 18

32 that changes are made when needed throughout the development process. This management has been shown to play an important role in maintaining the scope of the project and is shown in Figure 2.6. Figure 2.6: Requirements Management and the Project Management Triangle [3] Another important aspect of starting off an MBD project is turning the customer requirements into specifications. Specifications are the requirements transformed into a metric with a value [3]. Specification creation can occur over two phases with the first being target specifications and the other being final specifications against which the system is verified [3]. Target specifications are the preliminary set of specifications defined from the requirements and are identified before the concept selection process [3]. The concept selected often results in modifications to the specifications which results in the final specifications [3]. 19

33 A truly important part of defining target specifications for the model is creating a needs-metrics matrix. This matrix identifies relationships between various customer needs and metrics, which can be defined using the following considerations [3]: Metrics should be measurable and tangible quantities (abstraction is not desired) Metrics should be representative of what the system is expected to do and not how to do what the system is expected to do Creating metrics that are dependent variables will offer greater freedom when the system is being designed Metrics in the initial stages should not be too rigid and specifying a range of values is a good practice to offer flexibility when designing An example needs-metrics matrix for an optimization design problem of an electrical system is shown in Table 2.2. The next step in the model development process is to go through concept selection. This can involve decomposing the design problem into submodels that constitute the functional flow of the system and then individually worked on to generate possible model concepts [3]. The purpose of this phase is to understand at a high level viewpoint the problem in hand and decompose it to identify potential concepts [3]. An example of the concept selection process that can be followed for control or plant model development is shown in Figure

34 Table 2.2: Example Needs-Metrics Matrix [3] 21

35 Figure 2.7: Example Concept Selection Process [3] 22

36 System identification is the next item to be considered for automotive MBD after a concept is decided upon. It is important to remember that no physical system can be exactly modeled and approximations based on prior knowledge and experimental data is likely to be an integral part of any model [3]. The system identification s outcome is a plant model that is representative of the actual physical system; however, if the case happens to be that a project s object is to improve on an existing control system, the outcome can include the existing control logic [3]. This has been important in the past on EcoCAR because of the development of new controls with older, previously used plant models. The system identification process depends primarily on the dependent parameters of the prior knowledge of the system, the objectives of the system (both plant and control system), and the availability of experimental data [3]. These are considered dependent variables because knowledge or information on one can help improve the other. Models developed under the system identification process can be classified as three types [3]: White Box Models - Models developed on the basis of physical laws and relationships that correspond to various physical parameters. Mathematical equations and first principles are typically used to completely represent the physical processes. Grey Box Models - Models in which not all parameters are known about the system. Physical parameters and math equations capture the working of the system but calibratable parameters that can be tuned based on experimental data are used to obtain realistic predictions. 23

37 Black Box Models - Models with no equations and are made up with simple or static maps derived from a significant amount of experimental data. These are advantageous because of the speed at which they can be run, but their fidelity depend greatly on the quality of data used to derive the models. An example of the system identification process is shown in Figure

38 Figure 2.8: Example System Identification Process [3] 25

39 2.2.2 Model Validation and Verification Validation and verification are important steps in the creation of models using the MBD process. While the terms are sometimes used interchangeably in industry, this paper will seek to specify the difference between the two and address them differently. As eluded to previously, requirements are indicative of what tasks a system is desired to perform by a customer. Specifications are derived from requirements and are definitions of how the system has to work to perform a desired task. The difference between verification and validation is as follows: validation is done to ensure requirements are met; verification is done to ensure specifications are met [3]. Validation of a model is evaluating the model s performance in representing the actual physical system being modeled [3]. Validation is done on, but not limited to: accuracy of the model, repeatability of simulation results, reproducibility, and sensitivity to both exogenous and endogenous variables [3]. The validation phase of the system identification process primarily focuses on [3]: Does the model serve the purpose of describing the actual physical system? Is the model representative of the experimentally observed data? Is the model robust enough? How sensitive is the model to its inputs or operating parameters? Though common knowledge, it is important to point out that only input that can help validate the model being developed is actual observed data. A typical method of model development is using one set of experimental data to calibrate a model and another set of experimental data to observe the model s performance and validate it. 26

40 Chapter 3: Component Plant Model Development Developing the plant models that best represent the systems being integrated into the Ohio State EcoCAR 3 vehicle involved topics covered in the literature review, including: Defining simulation and modeling requirements for each subsystem. These requirements, both functional and non-functional, should strictly set what is included in the model to achieve desired behavior and accuracy but not add unnecessary complexity. Defining interfaces that the model will use to pass or receive information being communicated between other plant models, actuators, sensors, and controllers. These interfaces could be Controller Area Network (CAN) buses, signal buses, or physical connections (represented in Simulink by normal signals). Determining what physical effects need to be modeled and how. This is crucial for getting the model to behave properly and for determining what type of model will be developed (map, first-principle, etc.) Identifying what assumptions and limitations will be considered and used for the model. These will allow models to be modified within reasonable means to behave properly. 27

41 Each of the bulleted items is addressed for all of the EcoCAR 3 models. These set up the foundation for a full vehicle model that is able to meet all of its requirements. The individual requirements for subsystem model, interfaces, physical effects to be modeled, and assumptions and limitations were derived from a variety of sources including an estimation on the level of fidelity needed, available data on the real-world subsystem, complexity of the real-world system, and previous modeling experience in EcoCAR. Figure 3.1: Refinement Process for Input/Output in Modeling The availability of real-world data lends to the inevitable reduction of what can be modeled for the plant models. A large part of this was the input/output (I/O) for the various controllers, actuators, and physical systems in the vehicle. The total I/O 28

42 that was known for these systems was listed and then refined to what was determined to be needed for the initial model release of the EcoSIM3 software. This process is outlined in Figure 3.1 and includes developing control models after the plant models are complete. 3.1 Engine Plant Model Engine Simulation and Modeling Requirements The engine plant model was made to mimic the real-world system of a Ford 2.0L GDI I4 flex-fuel engine that would use solely E85 as a fuel for competition efforts. To create such a model, requirements relating to both the functionality and the constraints of the system were defined. Based upon previous modeling experience with EcoCAR, it was determined that for an energy consumption analysis only fuel, torque, and speed needed to be obtained from an engine plant model. No thermal or high fidelity air path model was needed at this point to simulate the amount of energy used and torque produced from the system. The requirements for how the engine plant model reacts include being able to receive a torque request and a measured speed reading. These inputs would be used along with static maps to find parameters such as fuel rate used and engine efficiency. The model also needed to use a torque and speed input from the belt coupling it to the BAS motor. This was necessary because these parameters would be used for engine stop/start as well as for speed matching the engine and transmission during shifts should a clutch failure occur. The non-functional requirements for the engine plant model help identify the constraints of the system and the quality of its representation of the real-world system. 29

43 The engine model could not be set up performance maps for torque and efficiency taken from real-world data. Instead, the Ohio State EcoCAR team developed a scaling tool that generated fuel consumption and efficiency maps for an engine based upon size desired. This tool worked given a fuel consumption and efficiency map of a different sized engine of the same type (i.e.: naturally aspirated, direct injected, E85 fuel, etc.). Torque indices are scaled with the tool based upon displacement volume and the speed indices are scaled by the stroke length of the desired engine. This option was necessary because of the inability to acquire the performance maps from industry. Another necessity for non-functional requirements was ensuring that the plant model took into account real system limitations, such as maximum speed, minimum speed for engine operation, maximum torque output, and maximum fuel rate possible. Setting these limitations, using appropriate performance maps, and implementing proper I/O created an engine model that could mimic real life expected behavior Engine Model Interfaces As mentioned at the start of this chapter, it was critical to define system interfaces and how those interfaces can be implemented into the model. This meant that the proper I/O was in place for the type of engine model being created (energy/torque flow model) and no extra I/O was used for other types of models not developed (thermal, air path, first principle models). These include the speed and torque request inputs from the actuators part of the vehicle model, and the speed and torque input from the powertrain model specific to the belt coupling between the BAS motor and engine. This powertrain input tells 30

44 the engine model what speed and torque the BAS is operating at and helps link the torque flow of the vehicle together. To continue the torque flow throughout the model, the engine plant outputs the torque generated by the engine to the clutch model. The engine plant also outputs multiple signals to the sensor data bus that is used to transfer information back to the controllers and to the workspace for user calculations. These sensor outputs are the fuel flow rate used by the engine, the torque produced, and the speed of the engine Engine Model Development The engine plant model was set up to help facilitate the separation of models with respect to controls, actuators, plant, and sensors. The model only contains signals and information pertinent to the plant and representative of the engine itself. No actuator or sensor logic was included in the plant and the plant only interacts with the controllers through sensors and actuators. The model structure uses algorithms and look up tables to replicate the engine and was created to be low fidelity. This allows the model to contribute very little to the overall EcoSIM3 computational run time. Since an engine is a very complex system in a vehicle, it is easy to forecast that the Ohio State team will need to develop a more complex or higher fidelity model in the future to have a better representation of the system for controls development. The assumptions that were taken for the engine plant model were that the scaled engine performance maps from a 2.4L flex fuel GDI I4 engine were accurate representations of the system. If the industry supplier of the engine is able to give the map data in the future, these scaled maps would be replaced. The limitations of the model 31

45 are that only torque, speed, and fuel flow rate are determined. No thermal analysis was conducted or model constructed. 3.2 Transmission and Clutch Plant Models Transmission and Clutch Simulation and Modeling Requirements Similar to the engine plant model, the clutch and transmission plant models were created to mimic the real-world systems given the information available at the time of construction. The functional requirement of applying an efficiency to the torque transmitted through the clutch is representative of the fact that there is some clutch slippage in real life. In order to appropriately model the functionality of the clutch, zero torque is allowed to be transferred through the clutch when it is disengaged. The automated manual transmission plant model needed to use the gear command that was sent from the actuators to select the proper gear ratio. The model was required to have the proper gear ratios for each gear selection and it also needed to apply the gear ratio multiplication to the torque being transferred through the model. An efficiency to the torque was also required to mimic the losses seen in transmissions. The non-functional requirements for each model were directly related to the functional requirements. Having the correct gear ratios and the correct efficiency ensured that the model was constrained within the real-world limitations on the transmission Transmission and Clutch Model Interfaces Clearly defined interfaces for the models being developed at this point in the competition is key throughout all of the plant models with no exception for the clutch and transmission. The clutch plant model needed to interface with the actuators in 32

46 order to receive commands from the controller. The main purpose of this input is to engage and disengage the clutch. The clutch also receives an input from the powertrain in the form of the engine torque. The outputs of the model interface with both the powertrain and the sensor bus. The clutch torque out is the output to the powertrain that eventually goes to the transmission input and the clutch status (engaged or disengaged) is the output that gets put into the sensor data bus. The transmission also interfaces with the actuators, receiving a command for the desired gear. The interface with the clutch brings in the torque transferred through the clutch model. This torque goes through the gear ratio and efficiency multiplications and is output back to the powertrain to eventually go to the mechanical coupler. The transmission also has the output to the sensor data bus of transmission gear ratio Transmission and Clutch Model Development Along with the engine plant model, the clutch and the transmission models were set up to facilitate the isolation of plant models. The clutch model is structured as a purely algorithmic model with no static maps required to achieve the desired behavior. This makes the model very low fidelity and requires little computational run time. The assumption with the clutch model is that it takes a clutch request and disengages or engages. This in not representative of what the real life system will be. The system that will be developed in EcoCAR 3 will contain a hydraulic clutch actuator from which the pressure to move a throw-out bearing and disengage or engage the clutch will be created. The lack of information on the specific actuator that the Ohio State team will be using for competition was a large limitation and led to the exclusion of the clutch actuator from the vehicle model. Because of this 33

47 exclusion, the proper modeling of how the hydraulic force relates to the movement of the clutch could not be done. In future releases of EcoSIM3 for the team, this model will be updated. The transmission model is structured with both algorithms and look-up tables (for gear ratios). The current status of the model is low fidelity but as with the clutch model, the transmission plant model is missing key information pertaining to the shifting actuator that will be used by the Ohio State team for the competition. When this information is made fully available to the team by the industry sponsor, a plant model for the shift actuator that directly connects to the transmission will be created. 3.3 Electric Machine and BAS Plant Model Electric Machine and BAS Simulation and Modeling Requirements As another complex system, electric machines can be difficult to model in-depth. However, efforts were taken to narrow down what was necessary to include in the plant model in order to represent the power creation from an electric machine. The functional requirements that are associated with both the BAS and electric machine plant models include taking a desired torque request or a speed request (based on whether the machine is in speed or torque control mode) and outputting the power produced by the machine and the efficiency that the machine was operating at. Constraining the model to implement real system limitations included maximum and minimum torque curves for both the BAS and the electric machine. 34

48 3.3.2 Electric Machine and BAS Model Interfaces The BAS motor will physically interface with its inverter and the belt coupling to the engine in the vehicle. With this in mind, the defined interfaces in the BAS plant model include actuator inputs of speed and torque requests (which is a representation of the electrical current input by the inverter in real life). The powertrain output of the torque applied to the engine belt enables torque flow. The powertrain output of the power made by the BAS (or used from the battery) is made an output to the battery model. The sensor data bus also gets the outputs of efficiency, torque, speed, and power of the BAS system. The electric machine will physically interface with its inverter and the mechanical coupler in the rear of the vehicle. Interfaces in the electric machine model include speed and torque request from the actuator inputs, torque out to the mechanical coupler through the powertrain output, power out to the battery model, and sensor bus data. The bus data includes efficiency, torque, speed, and power Electric Machine and BAS Model Development Both the BAS and electric machine plant models were created to not contain any components of actuators, sensors, or controls. This was done to remain in line with the process of separation of models. Both plant models are comprised of algorithms and static maps, creating low fidelity representations of the systems that can run with little computational power. While this is a good attribute for the models to have at the present time, the complexity of the real world systems pushes the next iteration of these models to be higher fidelity to obtain more accuracy. 35

49 The BAS motor model is currently using a manufacturer-supplied map for both positive power output and for efficiency. However, for negative power (regenerative braking), the map is assumed to be an inverse of the positive map. This may not be correct because of slightly differing efficiencies with collecting power as opposed to delivering power. Once more information is gathered from the manufacturer, the model can be updated. The electric machine model is using manufacturer-supplied performance maps for all calculations. However, both the BAS and electric machine models assume no change in power output for temperature changes. In the future models developed for these systems, this will likely need to be taken into consideration. At this point in the competition and the design phase of the vehicle, it was not necessary to consider any small derating of power and torque production from slight increases in temperature. 3.4 Energy Storage System Plant Model Energy Storage System Simulation and Modeling Requirements The energy storage system (ESS) is a very complex system in real life and demanded more in-depth models from the start than did the other systems in the vehicle. The ESS was recreated by two models - an electrical model and a thermal model. The electrical model needed to take in the electrical power consumption from various components such the charger, electric machine, accessories, and BAS, and combine them into one net power usage from the ESS. In addition to this net power, the net electrical energy out of the ESS needed to be calculated by the model. The electrical model was also required to calculate battery and cell current and estimate battery 36

50 state of charge (SOC). In addition, cell internal resistance, open circuit voltage, and terminal voltage all needed to be determined. Finally, to interface with the thermal model, the electrical model needed to estimate the heat generated during the operation of the ESS. The thermal model had the functional requirements of taking in the heat generated calculation from the electrical model and determining the battery temperature to output back to the electrical model. To ensure the proper representation of real-world behavior in both models, the use of real performance data along side of first-principle equations was necessary. The limitations that the ESS would see in use in the vehicle, such as minimum SOC, charge and discharge rates, etc. needed to be included in the models as well Energy Storage System Model Interfaces The interfaces from the electrical and thermal models to models outside of the ESS is actually low in number compared to the data that is transferred within the two models. For the electrical model, only the power from the electric machine, BAS motor, and accessories are inputs. The sensor data bus outputs from the electrical model include the battery current, SOC, and battery voltage. The thermal model has an input of heat generation estimated by the electrical model, and a sensor data bus output of battery temperature Energy Storage System Model Development Being a complex system and requiring more of a grey-box, first principle dependent model than the other components in the vehicle, the ESS electrical plant model was 37

51 developed with a combination of first-principle equations, algorithms, and look-up tables. The ESS thermal plant model was developed with first-principle equations. The current calculation was modeled using Equation 3.1. This uses Ohm s Law and the relationship between the total power drawn from the battery and the battery voltage. I cell = P in V Batt n cells,parallel (3.1) The SOC estimation was calculated in the vehicle model by the method known as Coulomb counting, which integrates the battery current as shown in Equation 3.2. SOC = 1 Cap cell I cell dt (3.2) The open circuit voltage estimation is done separately for discharging and charging the battery but in the same manner. The open circuit voltage is derived from real-world A123 Systems test data with the prismatic cells which were modeled in EcoSIM3. The relationship between battery SOC and open circuit voltage is used for this and is very similar to the general SOC-open circuit voltage plot shown in Figure 3.2. This curve changes slightly depending on whether current is going in or being drawn out of the cell. 38

52 Figure 3.2: Cell Open Circuit Voltage vs SOC [7] The resistance estimation for the ESS model was done in a separate manner for discharging and charging like the open circuit voltage estimation. The data for cell internal resistances again came from A123. The static maps require an input of battery temperature and battery SOC to find the estimated internal resistance of the cell. This internal resistance was crucial to get correct in the early development phase of the EcoSIM3 model because it is used in the thermal model for estimating the amount of heat generated by the battery pack. This parameter was also used in calculating the battery terminal voltage. For terminal voltage calculations, Equation 3.3 is used in the battery electrical model. The relationship takes into account that a certain amount of potential is lost from the internal resistance of the battery cell. This is subtracted from the open circuit potential. 39

53 V T erm = V OCV I Cell R Cell (3.3) The heat created in the battery from internal resistance is based solely on the Joule Heating principle, as shown in Equation 3.4. Q Heat = I 2 CellR Cell n Cells,T otal (3.4) The ESS thermal model is build upon equations as well. The two main relationships used are shown in Equations 3.5 and 3.6. The parameters for these equations are listed in Table 3.1. R Sink is the resistance of the heat sink manifolds that will be on the bottom of the modules, defined by 1. The parameter, h is the heat transfer ha coefficient found from the experimental testing conducted in the previous EcoCAR competition. For EcoCAR 2, the Ohio State team had the same battery pack and a comparable cooling system. R T hermal is the thermal resistance of the cells as defined by A123 Systems. C B is defined as being the product of the thermal mass m thermal and the specific heat of aluminum, c p. T B is the battery temperature and T Amb is the ambient temperature. R eq = R Sink + R T hermal (3.5) C B dt B dt = Q gen T B T Amb R eq (3.6) Together, the thermal and electrical models create the medium fidelity ESS plant model. Because of the higher fidelity of this model, it was validated against real-world A123 data. The validation was done using a maximum continuous discharge test at 40

54 Table 3.1: Battery Thermal Model Parameters Parameters Value Units Description h 1.5 W/m 2 -K Heat Transfer Coefficient A m 2 Heat Transfer Surface Aera R thermal 4.3 K/W/cell Thermal Resistance c p 900 J/kg-K Specific Heat of Aluminum m thermal kg Thermal Mass of Module 180 Amps for 1064 seconds at an ambient condition of 25C. The temperature rise over the test matched the data from A Torque Coupling Plant Models Torque Coupling Simulation and Modeling Requirements The torque couplings in the vehicle model are set up to connect two or more components in order to transfer torque along the powertrain. The three that were built for this model were a belt coupling for the engine, a mechanical coupling for the output to rear differential, and the rear differential model. The Ohio State EcoCAR 3 vehicle will have electric accessories rather than beltdriven accessories, so the only component that required coupling to the engine was the BAS motor. To represent that, the belt coupling model was required to have the input of speed and torque requests, apply the belt ratio and efficiency to torque, 41

55 apply the belt ratio to the speed, and provide an output speed and torque to the engine plant model. The mechanical coupling plant model represents the power transfer unit that is being custom-designed by the team in collaboration with an industry partner. This coupling transfers torque from both the transmission and the electric machine to the rear differential of the vehicle. In order to represent this accurately, the model was required to have the inputs of electric machine torque and transmission output torque. The model also needed to apply a gear ratio to the electric machine torque and speed, apply an efficiency to that electric machine torque, and apply an efficiency to the transmission torque. The model was finally required to output a single torque value to the powertrain. The rear differential model was required to take in the mechanical coupling torque and speed outputs, apply a gear ratio to those parameters, apply an efficiency to the torque, and output the torque and speed to the powertrain. The Ohio State team is using the stock 2016 Camaro rear differential so the model was required to reflect its gear ratio and torque/speed limitations Torque Coupling Model Interfaces The list of interfaces for the torque coupling models is not extensive. These simple, low fidelity models only pass through speed and torque. The belt coupling model takes in a speed and torque from the BAS model and outputs a speed and torque to the engine model. The mechanical coupling model takes in speed and torque from both the transmission and the electric machine and outputs speed and torque to the rear 42

56 differential model. The rear differential model takes in that speed and torque and outputs speed and torque to the brakes and wheels models Torque Coupling Model Development Along with the other plant models described thus far, the torque coupling models were built to maintain consistency with the separation from control, actuator, and sensor components of the full vehicle model. All three models are low fidelity and are based solely on algorithms. Having the belt coupling, mechanical coupling, and rear differential developed this way allowed for low impact on computational run time from three very important models in the torque flow of the vehicle. The assumptions for these models include the gear ratios, efficiencies, belt ratio, and physical limitations. These were created with the most up-to-date information from the mechanical design of the vehicle. The information on the stock differential for the 2016 Camaro was not released at the time of the project so the team assumed the numbers from the 2015 Camaro. If the parameters for these models change in the future, the models can quickly and easily be updated. 3.6 Accessories Plant Models Accessories Simulation and Modeling Requirements The electric accessories on the vehicle were very important to include in the initial full vehicle model for EcoSIM3 because of their power draw from the high voltage battery and the effect that has on vehicle range and energy consumption. The accessories that would typically be belted to the engine in a conventional vehicle will be used as electrified components in the Ohio State EcoCAR 3 vehicle. These components include the air conditioning compressor (which will be replaced with a high 43

57 voltage air compressor, or HVAC system) and the engine coolant pump. Additional accessories that are accounted for in plant models are the DC-DC converter, the 12V Li-ion battery, an electrically heated catalyst, and an air injection pump. The HVAC plant model had the functional requirements of using a pulse-width modulated (PWM) input from the HVAC actuator as well as determining compressor speed, cooling power, and electrical power used. The model needed to reflect the real compressor in its limitations on compressor speed and amount for with the cooling power was required. The engine coolant pump model had similar functional requirements to the HVAC model. The pump model needed to take a PWM input from the actuators and determine the electrical power draw. This pump model also needed to be set up with the proper real world limitations of the pump the team has identified to use in the competition with how flow rate relates to power. The DC-DC converter is used to convert high voltage to low voltage for use with vehicle accessories and a supplement for the 12V battery on board the vehicle. For the Ohio State EcoCAR vehicle, the nominal high voltage will be 350V and the nominal low voltage bus will be at 14V. The component that the Ohio State team will be using is PWM-controlled rather than commanded through a CAN bus. The DC-DC plant model was required to take the PWM input and determine the current draw from the high voltage ESS. In addition to this, the output current from the DC-DC and the efficiency of operation was required from the plant model. To ensure that the plant model mimics the real DC-DC converter, the performance maps and application of the real-world limitations were required. 44

58 In addition to the DC-DC converter, a 12V Li-ion battery will be used in the vehicle s low voltage bus. The 12V battery is used as an additional energy source on the bus. The plant model for the 12V battery had very few requirements. The power drawn for the additional accessories that were not modeled needed to be accounted for (i.e.: headlights, radio, etc.). To mimic real world power demand, the model needed to reflect the current draw what was recorded during the previous EcoCAR competition for these components. In previous competitions, the Ohio State EcoCAR team has implemented an electrically heated catalyst (EHC). The EHC is used to pre-heat the catalytic converter to reduce cold start emissions when the engine is first started. The EHC is a very large current draw (150A max) which needed to be accounted for in the plant model. This was important to ensure that the electrical system in the vehicle could handle the use of an EHC. The plant model was required to take a PWM control input and determine a current draw based upon it. The plant needed to output the power draw to the ESS model. Along with the EHC, an air injection pump will be installed on the Ohio State vehicle. This air pump is required because it transfers heat from the EHC metal substraight to the main catalyst. Without the air pump, the EHC would melt from the heat. The air pump model was required to take a PWM input and relate that to the electrical power draw. 45

59 3.6.2 Accessories Model Interfaces The model interfaces for the accessories was a non-extensive list. The HVAC plant model interfaced with an actuator for the PWM command, the powertrain for power draw, and the sensor data bus for cooling power. The engine coolant pump plant model interfaces with an actuator for the PWM input and the powertrain for the power draw output to the ESS. The DC-DC converter interfaces with actuators for the PWM input, powertrain for the power consumption from the ESS, and the sensor data bus for current draw and efficiency. The 12V Li-ion battery model interfaces with the actuators to enable and turn on/off as well as the powertrain for power drawn from the ESS. The EHC and air pump models interface with the actuators for its PWM command, the powertrain for the EHC power drawn from the ESS, and the sensor data bus the current draw Accessories Model Development All of the accessory plant models that were created have low fidelity because of low-complexity requirements. All but the 12V battery model consist of static maps. As with all other plant models, the accessories were constructed for separation of models. Only the HVAC and the DC-DC converter had experimental maps used for the plant model, so all others were assumed and created based upon their maximum current or power rating and how a PWM would be applied to get a fraction of that max rating. 46

60 3.7 Other Vehicle Component Plant Model Vehicle Component Simulation and Modeling Requirements Some components or features weren t necessarily included in the powertrain of the vehicle but were still key factors in how the energy modeling and simulation was done. These include the brakes, wheels and tires, fuel tank, and vehicle properties for dynamics and rolling resistance. The brakes plant model needed to be created for both front and rear. For this application, the brakes needed to take in the torque out of the rear differential model and a brake pedal command. That brake pedal command needed to be changed into a friction torque that could be applied to the output torque. Since there needed to be a differentiation between front and rear brakes, a set brake bias also needed to be included some way into the model. For wheels and tires to be represented at this early stage of plant and control development, the models were only required to convert the torque output from the brake model into a tractive force. Wheel slippage and traction are items that will be addressed later in the EcoCAR 3 competition but were not pertinent to the initial development of the energy-based simulation vehicle model. The fuel tank plant model requirements were defined as needing to determine the amount of fuel left in the tank, therefore giving the amount of fuel used by the engine. The vehicle dynamics plant model s two basic functions were set as determining the road load force and determining vehicle speed. The plant needed to be constructed such that it took inputs from the powertrain (tractive force) and vehicle and road parameters (mass and driving grade) to find the two values. 47

61 3.7.2 Vehicle Component Model Interfaces The brake plant model needed to interface with the actuator input of brake pedal position and the powertrain input of the torque out of the rear differential plant model. The model also interfaced with the powertrain in that it output a torque to the wheels and tires plant model. The wheels and tires plant model interfaced with the powertrain for the input of the torque out of the brake models and an output of the wheel tractive force for both the front and rear wheels. It also interfaced with the sensor data bus for the torque out at the wheels. The fuel tank model interfaced only with the powertrain for an input of fuel flow rate from the engine plant model and the sensor data bus for the fuel volume used and the fuel volume left. Finally, the vehicle dynamics plant model interfaced with the powertrain for the tractive forces at the wheel, the simulation inputs for the vehicle mass and the driving grade, and the sensor data bus for the output of vehicle speed Vehicle Component Model Development All of these models were made to be low fidelity in order to achieve a low impact on computational run time. These models also still all maintain the separation from the controls, actuators, and sensors. The brake plant model utilized a lookup table relating the amount of friction torque applied to the pedal input. It also applies a brake bias, depending on whether it is the front or rear brake, to the friction torque output. Because information was 48

62 not made available about the 2016 Camaro s braking system at the time of model construction, the 2015 Camaro braking force was assumed. The fuel tank model and the wheels and tires are both set up as algorithms. The wheels and tires model assumed no wheel slippage and no variation of traction between the front and rear tires. The fuel tank model assumed no evaporation of the fuel over a given period of time and no losses anywhere in the fuel system. The vehicle dynamics model was based off of the model used in the previous EcoCAR competition, with updated coefficients and parameters for the vehicle road load equations. 49

63 Chapter 4: Subsystem Soft ECU Development In order to test the plant models that were developed and to start developing initial control strategies for the vehicle, the implementation of soft ECUs was used. Each of the soft ECUs presented in this chapter represent control logic that will be put onto a physical controller when the modeling process reaches the HIL phase. Table 4.1 lists the soft ECUs which were made for the initial EcoSIM3 model and what physcial controller they will eventually end up on in the vehicle. Figure 4.1: Ohio State EcoCAR 3 Vehicle CAN Topology 50

64 Table 4.1: Soft ECU and Associated Physical Controller Soft ECU Supervisory Engine BAS Electric Machine ESS Clutch Transmission Physical Controller dspace MABx Ford ECM Rinehart PM100DX Rinehart PM150DX A123 BCM MotoHawk RPC Accessories The diagram shown in Figure 4.1 displays the CAN topology for the vehicle which is how all the team-added and stock vehicle controllers will be harnessed to communicate to one another in the vehicle. Having all of these controllers communicate via CAN is very important for how the controller handshakes are set up to send out or receive information. As was part of the development process for the plant models, the soft ECUs were designed to facilitate the full isolation of the algorithm from other parts of the vehicle model such as actuators, plants, and sensors. This definition of control models, illustrated in Figure 4.2, will make the transition to SIL, PIL, and HIL much easier than if the control logic and algorithms were mixed in with actuator or plant models. 51

65 Figure 4.2: Control Model Isolation Example The complexity of the first attempts at soft ECUs depended upon several factors. One such factor was the signal replication, both for input/output (I/O) and for CAN. As mentioned in Chapter 3, the I/O and CAN for various components and controllers was refined to only include signals that were necessary to complete the energy-based simulations that EcoSIM3 was being built for. Extra I/O or CAN did not need to be represented. Another factor is how advanced the handshake logic is for the soft ECU. If all the necessary parameters for a handshake was known, then the control logic could have been created to send those signals out to other controllers. Without the complex handshakes in place, there were no reasons to develop the advanced logic. The final factor is what fault detection and mitigation logic exists in the model. If the proper I/O exists and the plant models were able to send back sensor information that was representative of the real world signal, then more advanced fault detection logic could be present. 52

66 Throughout this chapter the soft ECUs, excluding the supervisory controller, are explored in regards to their requirements and the development of their logic. 4.1 Engine Soft ECU Engine Soft ECU Requirements The soft ECU for the engine had very few requirements for what was needed at this early point in the modeling process. The control model needed to determine speed and torque for the engine. Multiple ways of determining speed needed to be accounted for because the engine and the systems associated with it could be in different operating modes. Specifically, the control model needed to address the engine off mode, the BAS speed control mode (for engine stop/start), and the normal driving mode. The list of requirements in not extensive because of the Ohio State team s ability to use a production-level control code for the engine in EcoCAR 3. The engine controller doesn t need to be developed and the engine plant model just needed to run appropriately, react to the situations and operating conditions it faced, and have real world limitations implemented on it Engine Soft ECU Development The engine soft ECU was developed with algorithms and was low fidelity, lending to the low computational run times of the vehicle. Because of the requirement of determining speed for various engine modes, the controller was constructed to switch between an engine off mode (zero speed), a BAS speed control mode for (where speed is directly and solely based off of BAS speed), and normal engine on mode (where speed is based off of vehicle speed). The engine torque request from the supervisory 53

67 controller is handled by applying a simple first order filter to the signal and applying real world limits to what can be requested of the engine. The assumptions of this controller were that it only needed to control the torque of the engine while supplying the plant model with speed information. In a real engine ECU, the control logic would be very advanced, but because the Ohio State team will be using a controls from the engine supplier for the competition, there was no need to further expand upon engine control at this point. It was also assumed that all engine startup logic, including heating the EHC and commanding the startup, would occur from the supervisory handshake for the engine controller because of the team s need to develop that logic on its own. 4.2 Transmission and Clutch Soft ECU Transmission and Clutch Soft ECU Requirements The transmission and clutch soft ECUs will eventually migrate to the same physical controller in the PIL and HIL phases of the model development. For that reason, they needed to work closely with one another to deliver good shifting logic. The transmission soft ECU needed to be able to read feedback from the sensors and determine the gear shifting logic. This logic needed to include a shift command, the desired gear, and a status on the progress of the shift. The logic also needed to appropriately time the shifts to match what could be expected in the real world with an automated manual transmission. The clutch soft ECU had the relatively simple requirement of determining the status the clutch needed to be in (engaged or disengaged) based upon the shift command and shift status. 54

68 4.2.2 Transmission and Clutch Soft ECU Development Both soft ECUs were created using Stateflow in Simulink. As a state machine, Stateflow allows for modeling sequential logic that is decision based. Moving from one state of the model to the next can be dependent upon certain criteria being met. Figure 4.3 shows a simple stateflow for the clutch status command control logic. In order to move from a state in which the clutch is engaged to the state where the clutch becomes disengaged, a gear change has to have been requested and there also has to have been no clutch failure. This clutch failure is part of the supervisory fault mitigation that is discussed in Section 5.5. To engage the clutch once again, the shift status has to show that the shift is complete and that torque can be reapplied to the transmission. Figure 4.3: Clutch Stateflow Diagram Much like the clutch soft ECU, the transmission soft ECU was developed using Stateflow. The shifting logic involved five different states: no shift requested, shift to neutral, in neutral, shift into gear, and in gear. The basis of this logic was developed 55

69 and proven in the previous competition, EcoCAR 2, where the Ohio State team automated a manual transmission. Based on what state the transmission was commanded to be in, several parameters would be sent out on the CAN bus. Shift status ranges from 0 to 4 and broadcasts to various controllers the progression of a shift. Shift command ranges from 0 to 2 and depicts whether the no shift is commanded, the transmission needs to shift into neutral, or the transmission needs to shift into gear. Shift complete defines whether the transmission is in the desired gear. The Stateflow determines the states based upon input from the supervisory controller, where the shift maps and associated shift logic was created. This is covered in Section Both the clutch and the transmission soft ECUs are low fidelity but are expected to become more complex as the model develops throughout the next three years of the competition. The major assumptions with these control models were that the specific I/O necessary for the clutch and shift actuators was not know at the time of development. The Ohio State team has identified a hydraulic clutch actuator and an electronic shift actuator for use in the EcoCAR 3 vehicle, but the information on actuator I/O has not yet been disclosed to the team. When that information does become available, the models will be updated to reflect what is needed to command the real actuators to handle clutch movement and transmission shifting. The models that were developed assumed that there were separate controllers for those two components and that only signals for requests were needed from the clutch and transmission control models. There was also an assumption for the delay in completing a shift. The gear shift timer logic portrayed what was observed in the previous competition from the team s earlier automated manual transmission. The timing is expected to be slightly quicker in EcoCAR 3 because of the use of different actuators. 56

70 4.3 Electric Machine and BAS Soft ECUs Electric Machine and BAS Soft ECU Requirements The electric machine soft ECU and the BAS soft ECU had similar requirements in what control logic they needed to contain because they were both representing similar controllers for two electric motors. The electric machine soft ECU had the requirements of determining the speed and torque requests for the machine. Because the electric machine is directly linked to the wheels in the vehicle (no clutch involved), the electric machine speed needed to be derived from vehicle speed. The logic for the electric machine torque request needed to come from a supervisory control command for torque. The BAS soft ECU also had to determine the speed and torque requests for the BAS motor. Where the requirements differed from the electric machine soft ECU is that the BAS was not meant for much torque transfer to the powertrain, but rather the stop/start of the engine. With this in mind, the BAS soft ECU needed to have different operating modes built in for torque and speed control Electric Machine and BAS Soft ECU Development Both the electric machine and the BAS control models were developed to be low fidelity models, but as with the transmission and clutch control models, they are expected to become more complex over the course of EcoCAR 3. Both the electric machine and BAS soft ECUs were made up entirely of algorithms. The speed determination for the electric machine was done simply by applying gear ratios that exist in the powertrain to the vehicle speed. The torque request that was created by the supervisory controller is a torque required at the axle. To convert this to the electric 57

71 machine torque required, the same gear ratios that were applied for speed request were applied again. The BAS soft ECU was created with a mode selection that could deliver different speed and torque requests based upon whether the BAS was in a speed control or torque control mode. For engine stop/start, the BAS motor was put into speed control to spin up the engine and control the firing and idle speed. For normal operation of the engine, the BAS motor is put into torque control. The BAS motor could also be disabled and produce/absorb zero power. 4.4 Energy Storage System Soft ECU Energy Storage System Soft ECU Requirements The requirements for the ESS soft ECU only dealt with the enabling and fault detection of the battery pack. This was because of the fact that the battery control module (BCM) and all the control software is given to the team with the donated battery pack from A123 Systems. Similar to the engine soft ECU development, the ESS soft ECU did not need to be modeled in-depth because of there being no need to develop full control software. However, it was important to define some requirements to allow interaction with the supervisory controller for certain commands that will eventually be going to the BCM. The ESS soft ECU needed to have logic that would allow for the closing and opening of battery contactors and identify a fault state if something were to occur unexpectedly. 58

72 4.4.2 Energy Storage System Soft ECU Development The ESS soft ECU that was used for EcoSIM3 was also used in the previous EcoCAR competition because the same battery pack and BCM was used then. The model consists of a Stateflow in which various states are entered based upon an enable signal from the supervisory controller and the status of the battery contactors. The logic first goes through a startup state in which a high voltage interlock (HVIL) monitor is enabled. HVIL is used in the vehicle as an electrical circuit in which switches from all high voltage components on the vehicle are placed in series. If a high voltage component, connector, or cover were to be removed, the HVIL would trigger a warning and open battery contactors. The next few states within the logic deal with enabling the ESS and waiting for the contactors to close. The final state is entered when contactors are closed and the ESS is fully functional. There is a fault state which can be entered if any step in the process is not completed correctly. The ESS soft ECU model is low fidelity and is not expected to become more complex over the remainder of the competition. The assumptions made for the control model were that the ESS plant model only needed to be enabled and have contactors closed for accurate modeling of energy consumption. 4.5 Accessories Soft ECUs Accessories Soft ECU Requirements The electrical accessories plant models that were made all have associated soft ECUs; however, the soft ECU models will all be going on the same physical controller in the PIL and HIL phases of model development. Since the plant models of all the 59

73 electrical accessories were relatively similar, the requirements for the soft ECUs reflect some amount of similarity. The HVAC, engine coolant pump, EHC, and air pump soft ECUs was required to deliver a PWM command to the actuators. The DC-DC converter soft ECU was required to deliver a setpoint voltage for the system to operate at, an enable for the DC-DC converter to turn on, and a PWM command for how much current draw was desired. The 12V Li-ion soft ECU was required to simply enable the low voltage battery Accessories Soft ECU Development Since the accessories soft ECUs shared many requirements, they all share the fact that they were constructed to be low fidelity models. These models are not expected to have the need for more complexity throughout the rest of the model development process because they were enabling and commanding power from the components the same way that they will in the actual vehicle. The HVAC soft ECU contains a lookup table that converts a driver input of incabin desired temperature and actual temperature to a PWM command for the compressor. The engine coolant pump soft ECU converts the reading of engine coolant temperature into a PWM command with another lookup table. The DC-DC converter soft ECU converts a current request into a PWM command and is based on experimental data from the manufacturer. The current request for the DC-DC converter comes from the sum of all other low-voltage electrical loads on the vehicle with the exception of the 12V battery. The EHC and air pump soft ECUs have fixed PWM outputs that are sent out via an enable signal from the supervisory control. 60

74 These fixed output values were taken from calibration data in the previous EcoCAR competition where similar components were used. 61

75 Chapter 5: Full Vehicle Model Development The full vehicle model was a combination of all the modeling work outlined thus far. The component plant models, the control models, and the supervisory controller (outlined in this chapter) all come together with actuators and sensors to create the full vehicle model known as EcoSIM3. The result of all this model development was the first iteration of a plug-in hybrid electric Camaro model that was capable of running drive cycle tests and simulation energy consumption. In this chapter, the requirements of the full vehicle model are described along with how the component plant and control models were integrated into the overall model. The full vehicle model architecture is explored as well as the development of the supervisory soft ECU. How signals were managed in the full vehicle model and how fault insertion, detection, and mitigation were handled is also outlined. 5.1 Requirements of Full Vehicle Model With the requirements of the component plant and control models being met with their construction, the higher-level requirements for the vehicle needed to be created to ensure the build of the full model would meet the needs of the Ohio State team. These requirements were aimed at items such as how the full model was structured, 62

76 how the energy flow occurred throughout the model, and how accurate the model was compared to a real vehicle. Table 5.1 shows these requirements. Table 5.1: Full Vehicle Model Requirements Full Vehicle Requirements Structured for isolation of models Realistic energy flow Good data visibility Follow good signal routing techniques Facilitate fault testing Easy transfer to xil platforms Meet VTS targets The VTS targets were created from modeling results using a different simulation environment called Autonomie. A post-transmission parallel hybrid pre-built model was used along with maps that represented the components to be used by the Ohio State team. In addition to these simulation results, the VTS targets were also influence by the Ohio State EcoCAR 3 team s target consumer and market. The consumer and market are large drivers of creating technical targets in industry. The extensive list of VTS targets for Ohio State is given in Table

77 Table 5.2: Ohio State University EcoCAR 3 Vehicle Technical Specifications Specification Units OSU Targets Acceleration, IVM-60 mph (Performance Mode) sec 5.6 Acceleration, IVM-60 mph (Normal Mode) sec 10.0 Acceleration, mph (Performance Mode) sec 3.3 Acceleration, mph (Normal Mode) sec 3.3 Braking, 60-0 mph ft. 128 Acceleration Events Torque Split (Front/Rear) % RWD Lateral Acceleration, 300 ft. Skid Pad G 0.85 Double Lane Change mph 55 Highway 20 min, 60 mph % 6% Cargo Capacity ft Passenger Capacity 4 Curb Mass Added to Stock Vehicle kg 274 Starting Time sec 2 Total Vehicle Range mi 328 CD Normal Mode EV CD Performance Mode Blended CD Mode Range mi 44 CD Mode Total Energy Consumption Wh/km 220 CS Mode Fuel Consumption Wh/km 532 UF-Weighted Fuel Energy Consumption Wh/km 188 UF-Weighted AC Electrical Energy Consumption Wh/km 140 UF-Weighted Total Energy Consumption Wh/km 330 UF-Weighted Total Energy Consumption mpg ge 63.5 UF-Weighted WTW Petroleum Energy Use Wh 56 UF-Weighted WTW Greenhouse Gas Emissions UF-Weighted WTW Criteria Emissions PE/km g GHG/km 115 Tier II, Bin 5 Figure 5.1 shows how the full vehicle model was required to have isolation among the controls, actuators, plants, and sensors. 64

78 Figure 5.1: General Model Architecture 5.2 Vehicle Model Architecture The full vehicle model with the integrated plant and control models has a very separated architecture. Figure 5.2 shows an overview of the EcoSIM3 model. The controls, actuators, powertrain plants, vehicle plants, and sensors are all exclusive to one another in their construction and integration into the full vehicle model. This allowed the full vehicle model to meet the isolation requirement and for the actuators and sensors to be grouped together to meet part of the fault testing requirements. 65

79 Figure 5.2: EcoSIM3 Full Vehicle Model Layout With this structure, the full vehicle model can much more easily be transferred to various xil platforms than would be possible with lumped control/actuator and plant/sensor models. The soft ECUs can be taken directly out of the controls subsystem and put on their respective physical controllers for the PIL and HIL platforms. With this separation, they can also easily be compiled and ran in the SIL platform. The plant models can easily be loaded onto the HIL simulator (if no physical component is being used on the test bench). In addition to the main vehicle model, other attributes of the simulation environment created can make using the model very user friendly. One such feature is the 66

80 simulation parameters graphical user interface (GUI). This GUI, shown in Figure 5.3, allows the user to select a variety of simulation parameters that are necessary for energy consumption simulation. These include the type of drive cycle or acceleration test desired, number of times to repeat desired test, and quick access to items such as driver PI control gains, vehicle mass, initial ESS SOC, and initial fuel capacity. Figure 5.3: EcoSIM3 Simulation Parameters GUI 67

81 To help create a user friendly, fast, and effective simulation environment, there are also inputs and outputs blocks in the main level of EcoSIM3. The inputs block takes all simulation parameters defined by the GUI and converts them into the units and signals expected by certain parts of the vehicle model. The outputs block creates high data visibility by gathering all signals on the sensor data bus and automatically outputs them to the Matlab workspace. These signals can then be used by automated post-processing scripts and stop functions within Simulink to plot and calculate anything the user wishes to implement. The driver model that is part of the model architecture was used in the previous EcoCAR competition for modeling how a driver interprets and responds to a drive cycle velocity trace. The driver model consists of a simple PI controller that produces an accelerator pedal position and a brake pedal position based upon the amount of error between the vehicle speed and the cycle velocity. 5.3 Supervisory Control Soft ECU Development A complex vehicle such as the hybrid Camaro designed by the Ohio State EcoCAR 3 team has numerous controllers, all of which need to talk with the others and most of which need a single controller commanding it to enable and do several other tasks. For this reason a supervisory controller is necessary in the design of the vehicle. The development process for the supervisory soft ECU was the same procedure as the other soft ECUs for the components; however, the supervisory controls interface with all the others so it needed to be finalized last. 68

82 5.3.1 Supervisory Soft ECU Requirements Much like the other soft ECUs, the supervisory soft ECU was required to be created with isolation of models in mind. The supervisory soft ECU will eventually go on its own controller during the PIL and HIL phases of the model based design process so it needed to be fully separated from any other control logic not specifically going to that controller. More supervisory soft ECU requirements are listed in Table 5.3. Table 5.3: Supervisory Soft ECU Requirements Supervisory Soft ECU Requirements Separate incoming signals Condition incoming signals Facilitate fault testing Evaluate energy use Select vehicle operating mode Create torque requests Provide torque security Create shift requests Condition outgoing signals Have handshakes to communicate Since the supervisory controller is likely to have a lot of information and signals coming into it from the CAN bus, a big requirement was to have the appropriate 69

83 separation of incoming signals from the bus and then conditioning the signals. Conditioning the incoming signals allows them to be put into the proper units and have other properties changed (i.e.: apply filters, etc.) to get the signal the control logic wants to see. Another major requirement for the supervisory soft ECU was the need for fault detection and mitigation. Because the supervisory ECU needed to act as the central command for the vehicle, all fault detection has an opportunity to be sent to the supervisory soft ECU for fault mitigation strategies. The supervisory soft ECU was further required to monitor the energy usage of the various components in the vehicle. This energy consumption requirement is also tied into the requirement to select vehicle operating modes and determining torque request from components. Based upon the need to operate in several different driving modes to meet Ohio State s VTS targets and the need for other non-driving modes (such as start up and shut down), the supervisory soft ECU was required to select the vehicle operating mode at any point when the vehicle is turned on. In order to keep the operations safe when the vehicle is turned on, the supervisory soft ECU was also deemed responsible for torque security. Torque security should ensure that no torque is transferred from any component when it is not requested and that torque delivered from components stays within the reasonable limits of the real world components. With the supervisory soft ECU being required to select the vehicle operating modes and torque requests, it also needed to be able to command shift requests to the transmission. Based upon the operating mode or the amount of energy being 70

84 used at a certain time, shift maps could have a chance of changing. Implementing this logic in the supervisory soft ECU is the most beneficial. Along the same lines as input conditioning and separation of incoming signals, the supervisory soft ECU was required to condition the outgoing signals and have handshakes in place to properly communicate signals to the other soft ECUs Supervisory Soft ECU Development Although a lot of logic exists in the supervisory soft ECU, all of the control models were designed to be low fidelity so that quick computational run times could still be achieved. The majority of the supervisory control is expected to grow and become more complex over the next few years of the competition. What was developed and is currently in the EcoSIM3 model serves as an initial version of the supervisory control model. The incoming signal separation was done by splitting the signals into three different categories: Driver Inputs, Mapped CAN Protocols, and Virtual Sensors. Driver Inputs serves to give feedback on the vehicle s current operation with relation to the desired drive cycle. Virtual Sensors are signals that are kept only within the supervisory soft ECU. These signals are needed for certain logic in the supervisory control model and do not exit it. All other signals that are input to the supervisory soft ECU from the CAN bus are mapped to various protocols for identification purposes. Some of these incoming signals needed certain conditioning like filtering or transferring into the correct engineering units. Certain controllers that are left in the vehicle like the body controller and brake controller will need to be given false signals for various stock powertrain or control 71

85 components that are taken out of the vehicle during initial tear down. These false signals are generated in the supervisory controller in the same mapped protocol area and are sent out via a CAN bus. A large assumption for this is that no information on what signals will need to be falsified for the 2016 Camaro is available. As a placeholder for early development, the signals from the previous EcoCAR vehicle were used. Fault detection and mitigation was started during the initial development of EcoSIM3 and the structure for it was fully in place in the supervisory soft ECU. The two fault areas that were most developed for the initial proof-of-concept mitigation strategies were clutch and transmission failures leading to missed shifts. The supervisory soft ECU was set up to either detect faults on its own or have fault detection signals sent to it, determine the proper mitigation strategy, and follow through until the fault is mitigated. Some faults could lead to change of operating modes such as from charge sustaining to a limp-home all-electric mode because of an engine failure. More on the specific clutch fault insertion testing and mitigation is given in Section 5.5. Energy usage was found by using the fuel consumed in the engine, the electrical power used by the electric machine, the electrical power used by the BAS motor, and the electrical power used by all the accessories. The supervisory controller also monitors the SOC output from the BCM. These various items help make the decisions as to what operating mode the vehicle should be in and what the various torque requests should be. In the future, energy usage will be used for an energy consumption minimization strategy (ECMS). ECMS can be used by the supervisory soft ECU as a more advanced way of determining what energy source power (or certain amounts of it) needs to come from at each timestep of vehicle operation. 72

86 The various vehicle modes were defined with the VTS in mind and for fault mitigation. Originally, the only two driving modes (operating modes in which the vehicle moves under normal power) were going to be a charge depleting (CD) mode and a charge sustaining (CS) mode. However, initial modeling results showed a 0-60 mph acceleration of about 12.1 seconds. This was way over the target VTS acceleration. It was determined that there would be a normal and a performance mode that the driver could switch between. These modes, as outlined in Figure 5.4, make control changes for the higher torque demand. For CD, the performance mode turns on the engine for extra torque. In CS, the torque requests change for performance mode. Figure 5.4: Normal and Performance Modes Aside from those four driving modes, there were seven other operating modes that the vehicle could be in. These are shown in Table 5.4. Startup allows the ESS to be enabled and contactors to close. Engine Start allows the BAS motor to spin up the 73

87 Table 5.4: Vehicle Operating Modes Vehicle Operating Modes Startup Charge Depleting (Normal) Charge Depleting (Performance) Charge Sustaining (Normal) Charge Sustaining (Performance) Engine Start Shutdown Accessory Charging Limp-Home (Engine Only) Limp-Home (EV Only) engine to start. Shutdown ensures that the rest of the vehicle is off and then opens the ESS contactors. Accessory mode acts as the mode conventional vehicles go into when a key is inserted and turned, but not to the ON position. This mode allows the essentials to run in the vehicle including low voltage power draw such as the driver infotainment or lights in the cabin. Charging was set up to enable the ESS for charging and nothing else. The two remaining operating modes are only entered if a fault mitigation strategy calls for it. The limp home mode with engine only would be the result of some issue arising from the high voltage system. In this case, the engine would still be allowed to deliver torque for continuing driving. The limp home mode 74

88 with electric vehicle (EV) only occurs as a result of a failure with the BAS motor, engine, clutch, or transmission. This limp home mode disengages the clutch and puts the transmission in neutral in order to only have the electric machine deliver torque to the wheels. The modes are selected from Stateflow logic that considers start up and shut down commands for the vehicle and various parts of the powertrain, battery SOC, vehicle speed, and performance mode request. The torque requests were constructed to vary with every driving mode for the vehicle. A maximum capable torque was first calculated based upon vehicle speed and whether the electric machine and/or the engine are enabled. From this, the driver input of accelerator pedal is used to create a driver requested torque. This driver requested torque was then passed through to the chosen operating mode for the vehicle. One example of how torque requests are made is in CD normal mode where 100% of the driver requested torque has to be met with the electric machine. Another example is CD performance mode where in this iteration of EcoSIM3, a torque split exists that requests a fraction of the total driver requested torque from both the engine and electric machine. In future releases of EcoSIM3, ECMS will be used to determine more appropriate torque requests from components. Shift request was another area that needed to be developed in the supervisory controller. Because shifting maps and what gears are used could change based upon operating mode of the vehicle, the shift request logic was embedded within each vehicle operating mode. In this version of EcoSIM3, only CD performance, the two CS modes, and the limp-home engine mode had the ability to shift because the other operating modes did not use the engine and therefore did not need any torque transfer through the transmission. The shift request logic was completed in Stateflow with a 75

89 very simple shift map, as shown in Figure 5.5. For future releases of the full vehicle model, the shifting logic will be very refined to reflect what is best for each operating mode with respect to energy consumption and performance. Figure 5.5: Preliminary Shift Request Logic for EcoSIM3 The supervisory soft ECU was also created with output conditioning of signals. This has been used to apply limits to signals and ensure that torque and speed requests are safe. The output conditioning will be used in the future to make other modifications to signals as needed. 76

90 Handshakes are the final main part of the supervisory soft ECU that had to be developed. There are handshakes for communication to each of the team-implemented controllers in the vehicle. These are the electric machine and BAS inverters, general control module (used for accessories, transmission, and clutch control), and the engine controller. The most refined handshake at the release of this version of EcoSIM3 was the transmission/shifting handshake. The purpose of this handshake was to take outputs from the shift request logic and create the appropriate signals required for the transmission and clutch soft ECUs. The handshake was constructed using Stateflow and goes through the shifting process from receiving the shift command, ramping down engine torque, shifting to neutral, and shifting into gear. It also included logic for if the transmission is in neutral to start a shift. The BAS handshake contains startup logic for the inverter as well as commanding if the BAS should be in speed control or torque control modes. The electric machine handshake also contains startup logic for its inverter as well as a speed setpoint based upon gear selector (PRNDL) position. There also exists electric machine speed and torque overrides for testing purposes in HIL and VIL. The engine handshake contains mostly startup logic for enabling and controlling the EHC and air pump before the engine is commanded to start. 5.4 Signal Attributes Most of the signals that are used throughout the full vehicle model and the sensor data bus were setup to be ideal signals. This means that the signals have no errors or corruption built in to mimic real world signals. This was done because the ideal signals were sufficient for the initial control logic development of the first release for 77

91 EcoSIM3. However, there were a select few signals that were chosen to be representative signals at the early stages of the model development. These representative signals had attributes similar to what would be observed in the physical vehicle. Model appropriate signal attributes with representative signals is a very important part of the MBD process because without it, controls will only be developed for ideal signals. When those controls move on to the HIL or VIL phase and start interfacing with signals that have error or quantization or other attributes, they can have unexpected behavior and be dangerous. The application of various attributes to signals was completed using a teamcreated corrupter. This corrupter subsystem (made for Simulink) can apply all of the attributes shown in Table 5.5. The corrupter blocks can be applied to any signal in the Sensors area of the full vehicle model. As described in Section 5.2, the Sensors area is where all of the signals on the data sensor bus pass through. Table 5.5: Signal Attributes Affected by Corrupter Corruption Type Update Rate Scale Error Bias Error Noise Amplitude Latency Quantization Filter Description Changes frequency of signal update Multiplicative error to signal Additive error to signal Implements noise of specified size Delay of signal Causes stepping in signal First order applied to signal 78

92 The signals that were chosen to be representative were very important to the initial operation of the model. These include the SOC, current, voltage, and temperature from the ESS, the electric machine speed, and the driver accelerator pedal. Real world test data from the previous EcoCAR competition was used to determine what signal properties needed to be adjusted for each signal. As an example, Figure 5.6 shows a portion of the battery SOC signal captured during a competition testing event. It was clear from this that the SOC signal is quantized by 0.5% SOC. This was applied in the corrupter for the SOC signal in the EcoSIM3 model and the results are shown in Figure 5.7 Figure 5.6: EcoCAR 2 Data for Battery SOC 79

93 Figure 5.7: EcoSIM3 Model Results for SOC An additional example is the driver accelerator pedal position signal. This is a critical signal to develop controls correctly for because of its use in the supervisory controller to determine the driver torque request. In the EcoCAR 2 data, shown in Figure 5.8, the accelerator pedal position has a noise amplitude in the signal of about 0.4% accelerator pedal position. This was implemented in the corrupter for the accelerator pedal signal in EcoSIM3 and the model results are shown in Figure

94 Figure 5.8: EcoCAR 2 Data for Accelerator Pedal Position 81

95 Figure 5.9: EcoSIM3 Model Results for Accelerator Pedal Position 5.5 Fault Insertion Testing Conducting fault insertion testing is very important to developing robust controls that are safe for vehicle operation. Striving to develop a complete set of faults that could occur during vehicle operation, determining how to insert and test for those faults in the MIL/SIL/HIL environment, and creating logic to mitigate fault situations is all part of fault insertion testing. This is a critical part of model based development because a vehicle s control system needs to have proper fault mitigation logic to handle situations before they become dangerous or destructive. 82

96 Two approaches can be taken to fault investigation: fault tree analysis (FTA) and design of failure modes and effects analysis (DFMEA). DFMEA is a bottom-up approach that looks at individual failures (such as a short in a wire, or a connector coming loose on the vehicle) and determines what trouble, or faults, the individual failure could cause (such as losing connection to a controller, etc.). This process is great for detailed fault investigation and is best used later in the MBD process when all systems, components, parts, and their interfaces are all fully defined. For the early stages of MBD, FTA is a much more manageable approach. FTA is a top-down analysis which first identifies a fault (such as battery contactors opening) and then determines what could have caused that fault (perhaps a charge buffer on the battery was surpassed). The approach taken for this early release of EcoSIM3 was FTA. An example fault tree for a missed transmission shift is shown in Figure For an example of fault insertion testing, the failure caused by the clutch not disengaging properly is explained in detail. 83

97 Figure 5.10: Fault Tree for a Missed Transmission Shift Figure 5.11: Logic Overview for Automated Shifting in EcoSIM3 84

98 The typical logic for shifting that was developed and implemented into the model is shown in Figure Once the supervisory controller determined that a gear shift was necessary, it commanded a torque reduction in the engine. Once the torque ramp down was complete, the clutch was commanded to disengage. After this occurred, the transmission was commanded to go to neutral. When it was finished going to neutral, the transmission was then commanded to go into the desired gear. Once that was complete, the clutch was commanded to engage. A signal indicating the clutch was engaged was then sent back to the supervisory controller marking the shift complete and engine torque ramp up could occur. An example of a completed shift is shown in Figure Figure 5.12: Completed Gear Shift in EcoSIM3 85

99 If the clutch were to become locked in the engaged position by some means, perhaps the clutch actuator failed, then fault detection and mitigation should be able to realize that this event occurred and properly shut down the front powertrain. Because it is not ideal to shut the entire vehicle down due to the safety concerns of the driver and passengers, the fault mitigation logic was designed to enter a limp-home mode using only the electric machine to propel the vehicle. The fault mitigation strategy for this particular fault is outlined in Figure Figure 5.13: Shifting Fault Logic for Clutch Fault 86

100 With this fault mitigation logic implemented into the supervisory soft ECU, the fault was inserted during a shift in a drive cycle while the vehicle was running in CD performance mode. The result is shown in Figure The results show that as soon as the fault was detected, the supervisory logic commanded shutdown of the front powertrain, shifted the transmission to neutral, and continued driving with the electric machine only. Figure 5.14: Shift Failure and Fault Mitigation in EcoSIM3 Throughout the rest of the model development process in EcoCAR 3, extensive fault insertion testing will be required to create robust software that is safe for all vehicle operation. 87

101 5.6 Modeling Results Referencing back to the VTS targets in Table 5.2 that the Ohio State team is trying to achieve in EcoCAR 3, the preliminary modeling results are far off and would be unacceptable during the later part of the MBD process. However, these results are expected at this phase. The plant models were built to be as accurate as they could given the limited data available in the first year of competition, but inaccuracies are inherent in the very first stages of MBD when the system, or in this case the vehicle, is still being designed. The control models developed in this project were made with unrefined logic and with only small amounts of manual testing. As the competition progresses, the team will continue to better the control models so that achieving the VTS targets will become a reality. Big influencers on the modeling results that have not been refined include the torque requests for the engine and electric machine and the shifting logic for the automated manual transmission. These key control models also will change for every operating mode of the vehicle, requiring them to be much more refined than they were for this project. Table 5.6 shows the overall results of the current state of EcoSIM3 and their relation back to the VTS targets and Table 5.7 shows the percent of time that the vehicle velocity was more than 2 mph different than the cycle velocity for each cycle tested. With the early state of the model, the vehicle was very well under the total vehicle range, mostly due to the high CS fuel consumption. The high CS fuel consumption also caused a higher overall energy consumption from the vehicle. The only two VTS targets met were the CD mode range and the CD energy consumption. With further control refinement throughout the remainder of EcoCAR 3, the control system should be able to achieve the VTS targets. 88

102 Table 5.6: EcoSIM3 Initial Modeling Results vs VTS Targets Specification Units OSU Targets EcoSIM3 Initial Results Total Vehicle Range mi CD Mode Range mi CD Mode Total Energy Consumption Wh/km CS Mode Fuel Consumption Wh/km UF-Weighted Fuel Energy Consumption Wh/km UF-Weighted AC Electrical Energy Consumption Wh/km UF-Weighted Total Energy Consumption Wh/km Table 5.7: EcoSIM3 Cycle Velocity Error Cycle CD Percent CS Percent HWFET US06 City US06 Hwy The rest of this section is a deep dive into a single drive cycle (the US 505 urban cycle) and its results to showcase the models ability to follow the desired test in various vehicle operating modes. Figure 5.15 shows the cycle and vehicle velocity for the 505 cycle with the vehicle in CD normal mode. The vehicle followed the cycle velocity very well and had 0% of the cycle time in which the velocity traces were more than 2 mph apart. 89

103 Figure 5.15: EcoSIM3 505 Velocity Trace in CD Normal Mode Figure 5.16: EcoSIM3 505 Velocity Trace in CS Normal Mode 90

104 Figure 5.16 shows the cycle and vehicle velocity for the 505 cycle with the vehicle in CS normal mode. For the most part, the cycle velocity is matched by the vehicle velocity. However, at the higher operating points, the vehicle struggles to maintain the demanding profile. This is due to the initial control strategy that exists for CS normal mode. Attempting to maintain a SOC in a hybrid electric vehicle while meeting high performance requirements is not a trivial task and will be better solved with future control models for this operating mode. Figure 5.17 shows the engine and electric machine torque outputs for the 505 cycle with the vehicle in CD normal mode. This figure shows that only the electric machine is delivering power during CD normal mode, as it should. The torque is within the reasonable limits of the electric machine and is representative of what would be expected from the drive cycle. Figure 5.17: EcoSIM3 505 Torque Outputs in CD Normal Mode 91

105 Figure 5.18: EcoSIM3 505 Torque Outputs in CS Normal Mode Figure 5.18 shows the engine and electric machine torque outputs for the 505 cycle with the vehicle in CS normal mode. The electric machine torque is reduced from what it was in the CD normal mode because of the inclusion of the engine in the operating mode. There is some oscillation of electric machine torque in the middle of the cycle and this is caused by the control strategy attempting to maintain a state of charge. This problem will also be resolved in future control models. Figure 5.19 shows the engine and electric machine speeds for the 505 cycle with the vehicle in CD normal mode. The engine is shown not to have any speed in CD normal mode and the electric machine speed is within the physical limitations of the real world component. 92

106 Figure 5.19: EcoSIM3 505 Speed Outputs in CD Normal Mode Figure 5.20: EcoSIM3 505 Speed Outputs in CS Normal Mode 93

107 Figure 5.20 shows the engine and electric machine speeds for the 505 cycle with the vehicle in CS normal mode. The engine is shown shifting and staying below about 2500 rpm during the urban drive cycle. This is beneficial for lower fuel usage. Figure 5.21 shows the battery SOC for the 505 cycle with the vehicle in CD normal mode. The SOC falls accordingly to the demand for electrical power throughout the cycle. The fraction of the battery charge that is lost during the test is expected in this operating mode. Figure 5.21: EcoSIM3 505 Battery SOC in CD Normal Mode 94

108 Figure 5.22: EcoSIM3 505 Battery SOC in CS Normal Mode Figure 5.22 shows the battery SOC for the 505 cycle with the vehicle in CS normal mode. The SOC setpoint of 18% was not kept throughout the short urban cycle. This is due in part to the control strategy not being refined enough but also due to the shortness of the cycle and it s aggressiveness. 95

109 Chapter 6: Application in EcoCAR 3 The full vehicle model developed throughout this project was created for use in the EcoCAR 3 competition. This chapter describes how the model will be applied towards the next several years of competition and what role it will play in developing a fully-functioning hybrid Camaro for during the competition. 6.1 Automated Testing Integration Throughout the previous EcoCAR competition, extensive automated testing was conducted on the controls developed for the vehicle. A similar process will be required of the controls developed in EcoCAR 3. The purpose of setting up automated testing is to conduct large amounts of requirements testing to make sure the controls meet the end vehicle requirements. These vehicle requirements include but are not limited to: the VTS targets, control functionality, reliability, accuracy, and safety. Table 6.1 shows the general crossover that exists between these control requirements and the initial plant requirements. These are all items that can be tested with large-scale automated testing. The testing capability and platform of the initial release of EcoSIM3 model is in the MIL environment. This platform has been used with mostly manual testing techniques for initial control testing. The next step for the full vehicle model is to 96

110 Table 6.1: Crossover of Plant and Control Requirements for EcoSIM3 move into the SIL environment, with the considerations for PIL and HIL following shortly after. While the MIL platform and the manual testing techniques have been very beneficial for initial control logic proof of concept and development, SIL and HIL will help determine the control strategies that are needed for the vehicle to meet the VTS and control requirements. This process of refined controls through testing is outlined in Figure

111 Figure 6.1: Refinement of Control Software through Testing To help out with the control refinement and enable easy automated testing, the team will be using dspace SYNECT automated testing software along with dspace AutomationDesk. With SYNECT, the team can import its own extensive testing requirements document and link those requirements to AutomationDesk tests. The tests, or execution plans, can contain a large number of consecutive tests that are ran at specific dates and times. Not only will this be helpful for large amounts of requirements testing, but it will also enable the team to schedule various types of controls work at the most efficient times possible. dspace SYNECT also contains results tracking that will help the team sort through results and how they relate to the requirements. The results tracking compiles test results and can display various metrics of interest. Viewing can be based upon 98

112 test conducted or on the execution plant and can show results over time to further provide insight on how the controls change the simulation results. SYNECT will also tell the user if a test for a requirement passed or failed which can make checking results very quick. 6.2 Managing Workflow Managing the workflow on the EcoSIM3 model thus far and continuing to manage it throughout the rest of the competition presents a challenge that is similar to other software development projects. To effectively stay on target with a timeline and milestones throughout the remaining years, several management techniques were researched, implemented, and will continue to be used. The vehicle development plan for EcoCAR 3 and how it pertains to the system modeling, simulation, and controls tasks is shown in Figure 6.2. Staying on track with this timeline is going to be critical to team s ability to complete all the work needed to develop controls, finish a vehicle, and place well in the competition. In order to comply with the milestone deadlines, a software release schedule was created for both plant models and control models. The schedule, shown in Figure 6.3, has offset releases for the plant and control models. For example, the version that this project has been developing is version P2.0 of the plant model. When this version becomes released, control model C1.0 will start to be worked on by the controls team. The C1.0 control software will be more refined than what was included with the P2.0 release. At the same time that C1.0 is being developed, the next iteration of the plant models (called P2.1) will be developed. This version of the plant models will have better defined I/O for some of the actuators missing in P2.0 and will have more 99

113 accurate maps and other items that P2.0 did not have. A short description of these models scheduled for release is given in Table 6.2. Figure 6.2: EcoCAR 3 Vehicle Development Process with SMS and Controls Figure 6.3: EcoCAR 3 Model Release Schedule 100

114 Table 6.2: Model Release Schedule Specifications Vehicle Plant Model Release Schedule Model Release Name Date Description P1.0 Jan-15 BEV model made in EcoSIM P1.1 Feb-15 Rough Autonomie PHEV model used for architecture selection P2.0 Apr-15 Low-fidelity EcoSIM PHEV model used for MIL/SIL purposes P2.1 Aug-15 Low-fidelity EcoSIM PHEV model tested in PIL and ready for HIL work P2.2 Jan-16 EcoSIM PHEV model with higher fidelity electrical components (EM, ESS, etc.) for full-electric vehicle controls development P3.0 May-16 EcoSIM PHEV model with higher fidelity conventional components (engine, trans, etc.) for all modes controls development P3.1 May-17 EcoSIM PHEV model refined with vehicle and component data from testing throughout year 3 Vehicle Control Model Release Schedule Model Release Name Date Description C1.0 Aug-15 Full-vehicle PHEV controls in EcoSIM for low-fidelity model C1.1 Jan-16 EcoSIM PHEV controls (all-electric driving) for low-fidelity model developed on HIL C1.2 May-16 EcoSIM PHEV controls for higher fidelity all-electric driving C2.0 May-17 EcoSIM PHEV controls for lower fidelity full modes driving C3.0 May-18 EcoSIM PHEV controls for higher fidelity full modes driving In addition to defining a schedule of software release so that projects can be completed in parallel, a tracking or version control system is required so that no confusion exists on model development. The benefits of version control are numerous 101

115 and important. Version control allows individuals and the team to keep track of changes made to software, models, script files, and any supporting files that are used for the model development process. This is incredibly important for EcoCAR because the team is dynamic and can t always be in the same place. This means that multiple people on the controls or modeling teams can be working on different parts of the same model and without version control, the progress of one person may not be identified or accepted by another. Backing up files associated with the full vehicle model and the model itself is a non-trivial task without version control because multiple people could attempt to backup different versions of the same model on a shared drive and accidentally erase progress. In addition, it would be tedious to take the steps necessary to know which of the models and files backed up are the most up to date, the most accurate, or which has certain features. This makes pulling software from a shared drive difficult for the engineers on the team. Fortunately, all of these issues can be answered with the use of a proper version control platform. For the EcoCAR 3 team, this platform has been SourceTree software which interfaces with GitHub. This platform is a full version control software which allows users to start a master branch, start side branches, push updated or new files for others to pull, or pull files from others to integrate into the model files on the user s computer. 102

116 Figure 6.4: SourceTree and GitHub Version Control Software As shown in the overview of Figure 6.4, the branch for EcoSIM3 P2.0 was created off of the master, developed, and eventually merged back with the master for a release to the rest of the team. This has proven to be useful for the team in the early stages of the MBD process and will continue to be crucial to the team s success in modeling and controls throughout EcoCAR Knowledge Transfer The best model and system could be set up for any team, but if the knowledge of that model and system isn t passed on to the future engineers working with it, then it is of little benefit to the project. For the Ohio State EcoCAR 3 team, knowledge transfer has been at the forefront of the work because of the turnover of students graduating from year to year. Proper documentation of the plant and control model development process used for EcoSIM3 and documenting individual control systems and changes to plant models has been key in training the rest of the team on the model. This documentation shows the assumptions, estimation, or real-world data used to create the plant models. In addition to the documentation and personal 103

117 training for the model and associated software, the Ohio State team has ensured that at least one graduate student will be responsible for the knowledge of what occurs during the MBD process for every year of the competition, as shown in Figure 6.5. Figure 6.5: Team Members Responsible for EcoSIM3 Knowledge With similar knowledge transfer systems in place over the last several AVTC competitions, Ohio State has been able to succeed in bringing in new students and continuing great success in modeling and developing controls. With the addition of the new version control system, the knowledge transfer process will be refined one step further. 104