ss Vehicle Control Structures Because of the increasing complexity of vehicle control functions, a unified structure eases the understanding and development. Therefore, this chapter summarizes vehi- cle control structures and the model-based design workfiow with different simulation tools. 3.1 Overall Vehicle Control Structures Figure 3.1 shows the main signal flow from the driver's inputs acceleration pedal ped, Wheel steering angle dy, braking pedal position /%, transmission selector ty, and manual suspension selector usp.x to the vehicle outputs like velocity v, yaw rate W, etc. of a conventional vehicle (with automatic transmission) controlled by the driver. The driver uses mainly his own sensors like eyes, ears, and sense of balance and the estimation of the velocity ve and receives as a feedback the longitudinal and lateral acceleration ax and ay and a steering torque (“steering feel”). The main inputs act in a parallel way on the vehicle. However, vehicles have several crosscouplings to the outputs (as will be described by models later). In order to obtain a systematic view of the conventional and advanced driver- assistance systems, a hierarchical arrangement in several control levels results with regard to the signal flow leading to a multilevel control architecture as shown in Fig. 3.2. This also includes the implementation of more drive dynamic and environ- mental sensors, ‘The component control level includes the engine, transmission, power steering, brake control (ABS), and suspension control. These control systems obtain usually command inputs from the driver through the pedals and the steering wheel and a switch for the suspension if no higher level driver-assistance systems are active. In © Springer-Verlag GmbH Germany, part of Springer Nature 2022 35 R. Isermann, Automotive Control, ATZIMTZ-Fachbuch, utps:f/doi.org/10,1007/978-3-642-39440-36 3. Vehicle Control Structures mpi ce Loo} asive Ral, laynamicl—> -—— i O 1>@>[Sinals hve vehicle * fz} PO#" 3.1. Main signal flow of a conventional vehicle general, the component control systems for the chassis operate independently from each other, The driver-assistance systems (DAS) BSC, ACC, LKC, and TCS are arranged in a vehicle control level 1. These control systems receive information from the drive dynamic and surrounding/environment sensors, like ultrasonic sensors, radar of lidar, and video cameras, They give commands to the component control systems and support the driver in guiding the vehicle. In general, they operate independently from each other. According to the automotive vehicle control development and the different degrees of automation described in Chap.1 and Table 1.1, corresponding vehicle control levels 2-5 can be distinguished. Thus, partial automatic driving (PA) is dedicated to level 2, with, for example, parking control, braking control, and lane keeping control. Conditional automatic driving (CA) in level 3 includes longitudinal and lateral automatic driving on special roads like highways and rural roads, in traffic jams, and for parking. For high automatic driving (HA) in level 4, the automatic control is further expanded to more use cases. Full automatic driving (FA) then takes over automatic control for all situations. In general, the higher levels use the functions of the lower levels and therefore act on the lower levels. However, the control functions of a lower level can also be improved and extended for a higher level automatic control. For example, the limiting conditions as road types, speed ranges, and environmental conditions may be extended. Additional development of automated driving is the implementation of a commu- nication level which includes navigation functions, digital cards, Internet connection, and cloud services. Their size depends on the corresponding automatic control func- tions and grows with higher levels. ‘The control functions of the component control level in Fig. 3.2 are mostly inde- pendent from each other and could therefore be developed and implemented indi-37 3.1 Overall Vehicle Control Structures sjenay yeonyozesony wt uowioFwene pur sinduy soap weuny pea worsKs jonued IKEA ZEB “SY eas EI) fH svonss[]38 3. Vehicle Control Structures vidually and without disadvantages if delivered from different suppliers. This holds also for the control level 1 because these systems act mainly on one or two com- ponents. Hence, this decoupled structure or parallel structure is a way of “peaceful coexistence”. However, adding mote control systems in higher vehicle control levels, simultaneously involves more and more control systems of the lower levels, such that at least a “cooperative coexistence” is advantageous (Reichart and Bielefeld 2009). Application examples are full braking and adjustment of the suspension dampers to hard damping and collision avoidance systems which combine emergency braking and emergency steering. Finally, higher automatic driving requires centrally con- trolled overall systems with coordinated control of engine, transmission, steering, and brakes, by using a fusion of all environment sensors. This can also be understood asa general vehicle motion control Therefore, the classical automotive structures will change. However, these developments will be based on conventional and well-proven concepts, 3.2 Control Structures of the Powertrain 3.2.1 Control Structure of Internal Combustion Engines ‘The control of the powertrain, consisting of the internal combustion engine and/or electric drive, the transmission and the propeller shaft, and differential and wheel shafts are integrated parts of the vehicle overall control. Therefore, the control struc- tures of internal combustion engines and hybrid drives are briefly considered. ‘The control architecture of a gasoline engine is depicted in Fig. 3.3. Altogether, about seven main actuators manipulate the airflow and if provided the recirculated exhaust gas, and exhaust gas treatment through different control modules. The control modules are torque control, injection and air/fuel control, ignition control, knock control, air charge, and EGR control for normal operation of the warm engine. In addition, there are special control modules for the engine states cold start, warming- up, and idling. A corresponding control architecture for diese! engines is shown in Fig. 3.4. For more details, refer to, for example, Robert Bosch GmbH (2018), Guzzella and Onder (2004), and Isermann (2014). These different structures are limited to control func- tions. However, diagnosis functions are also realized in the control modules. With regard to vehicle control, the internal combustion engines ate subsystems which provide a certain torque (o the drive shaft with the accelerator pedal by the driver or electronically by, for example, the vehicle speed and distance con- trol (ACC) or by a traction control system (TCS). This will be considered in detail in Chaps. 6 and 19, where the longitudinal vehicle behavior is considered.39 3.2. Control Structures of the Powertrain are (c1oz suwanosy) szosuas ouios pur ‘sompour jonuo> “sxowenyoe “uonDafur 12aNNp MMU ouISUD suNOsed v Jo aman jonueD E°E-61 sorenje sof neyo aumose® ont oye F jonuos yonuos sion3. Vehicle Control Structures 40 (c1oz euwanasy) sxosuas amos pue ‘saqnpout jonuo> “siojenyoe “1oZzeqooqum puw uonsofur es UoURNLOS WIM BULBS [9SONp v Jo auMIDOIYOHE [ONUED y'E-BL ssoremoe < ¥ ¥ OF + 7 ee jonu0o anal jonu09 jouos aaa eso roses yo a 9 siege roars ont || Mato | | L_|3.2. Control Structures of the Powertrain 4a 3.2.2 Control Structure of Hybrid Drives A further step of the electrification of vehicles is the development of hybrid and elec trical drives. The combination of internal combustion engines (ICE) and electrical motors (EM) allows a further saving of fuel consumption and emissions through the operation of the combustion engines in ranges of better specific fuel consumption in part load, regenerative braking, and electrical driving and boosting. Figure 3.5 shows three basic structures, according to the kind of energy flow. A series hybrid drive is characterized by an ICE driving a generator (GEN) which charges a battery and which supplies the driving EM, acting on the wheels. The ICE is intended to operate stationarily with the best efficiency. Because of several energy conversions, this structure is usually not used for cars (except range extender configurations) but is, however, applied for locomotives and city buses. ‘The parallel hybrid drive allows the simultaneous (parallel) operation of the ICE and the EM. The EM is attached between the ICE and a gear or differential gear and either operates as a motor or charges the battery as a generator. If the EM is, directly coupled with the flywheel, it is called startet/generator. However, if the 24 JS 2 Pos 6 1 [oooo] 1 [ooo] at 5 7 a) <=> mechanical energy flow b)-—- == electrical energy flow c) 5 Basic structure of hybrid drives. a series hybrid: 1 ICE, 2 tank, 3 generator, 4 inverter, 5 battery, and 6 clectromotor; b parallel bybrid: 1 ICE, 2 tank, 3 clutch 1, 4 electromotor, generator, 5 clutch 2, 6 gear, 7 battery, and 8 inverter; ¢ power-split hybrid: 1 ICE, 2 tank, 3 planetary gear, 4 electromotor, 5 generator, 6 battery, and 7 invertera2 3. Vehicle Control Structures is separated from the ICE by a second clutch, electrical driving and regenerative braking are possible without towing losses of the ICE. A power-split hybrid drive is a combination of a series and parallel structure. A power-splitting planetary gear after the ICE allows supplying a part of the ICE power mechanically to the drive train and the other part to a generator. A direct transfer of the torque to the drive train is, because of the planetary gear, only possible if the generator consumes power. The generator power is then directly supplied to the EM and the drive train or itis used for charging the battery. This power-split hybrid drive allows a continuously controllable speed ratio between the ICE and the drive train, similar to a CVT-transmission. Based on these energy flow structures, different hybridization degrees can be dis- tinguished. The hybridization degree is understood as the ratio of the electrical power to the total power H = Pai/ Pot. Micro hybrids (Pa < SKW) typically have a par- allel structure and a startet/generator at the crankshaft or at the belt drive. Start/stop operation allows to reduce fuel consumption at standstill. Mild or medium hybrids (Pa < 15 kW) usually have a parallel structure as well, with one or two clutches. Besides start/stop, start of driving, boosting, and regenerative braking become possi- ble. Strong hybrids (Pe, © 30to 100 KW) can either be realized as parallel or power- split structures and allow, with larger battery capacity, longer electrical driving, ‘The design of the components and the optimization of hybrid drives requires a mechatronic overall consideration from the beginning. Figure 3.6 shows a possible control architecture for a parallel hybrid drive. The engine control and transmission control have to be supplemented by an electrical drive control for the power electron- ics, electromotor/generator and clutches, a battery control, and a regenerative/friction hyd management cngine ataive | [ranemission] | tatery brake cenit! central conte oat conta qe IOOOOFH {6 Overall control architecture of @ parallel hybrid drive3.2. Control Structures of the Powertrain 43 brake control. These subsystem-oriented control systems are linked together with a data bus to a hybrid drive overall management system, where the operation of the engine and electromotor power, battery charging and discharging, and regenerative braking with the generator and friction brakes is optimized. Figure 3.7 depicts a scheme for the optimization of the torque contribution by the combustion engine and the electromotor, which may be a basis for off-line and online use with regard to a driving cycle (Kunkel 2015). Hence, the electronic control and management functions increase considerably. This holds also for the diagnosis functions with the many added low-voltage and high-voltage components and the battery, where the state-of-charge is part of the operation and has to be monitored continuously. 3.3 Design of Vehicle Control Systems ‘The design and implementation of vehicle control functions have developed into a sophisticated and labor-intensive procedure. This is for many reasons, among them the multi-variable complexity of modern automobiles, the increase of driver- assistance systems, the high performance requirements of suppliers, manufacturers, and customers, and legislative certification limits for fuel consumption andemissions, safety, and competition. The development of partial, high, and finally full automatic driving requires the solution of a multitude of automatic control functions, The following sections summarize some general procedures for control-function design, control-software generation, required computers and software tools, and test benches. 3.3.1 Vehicle-Oriented Electronic Control Design ‘The design and implementation of electronic control and diagnosis systems are highly interrelated with the design of the mechanics, mechanical, electrical, hydraulic, and pneumatic components. It belongs to the design of mechatronic systems and requires a systematic development across the classical boundaries, With regard to the timeline of the workflow, a simultaneous or concurrent engineering in different domains has, to be performed; see, e.g. VDI 2206 (2003) and Isermann (2005). 3.3.1.1 V-Development Model ‘The development of the electronic vehicle control system can, according to the design of the control-software functions for mechatronic systems, be divided into 1, control-system design: * control-function development; * control-software development;3. Vehicle Control Structures 44 surenzomod pugiy Jo jontoo ox 107 sojnpowt Moy eUsis Ze “61g 7 enbiooxe |} ¥ saxeg esoufancoys eons = a ee Ww ‘enewoins) sssegp \« ynguues operates |] 55, ounginsip ames -y aonwerptoo> seh soposioud spaewsp nao ana snp NOLLVZINLLdO NIVULYIMOd GRIGAH33._Design of Vehicle Control Systems 45 2. control-system integration: © component integration; © calibration; © performance testing, ‘This design procedure is highly interrelated and requires many iterative steps and special development tools. It can favorably be represented in a so-called V-model, see Fig. 3.8, which covers all aspects from the analysis of the user requirements to acceptance tests; see, e.g. VDI 2206 (2003), Schiiuffele and Zurawka (2005), Isermann (2005), BRD (1997) with origins in Bohm (1979), STARTS Guide (1989), Brohl (1995), and Droeschel and Wiemers (1999), ‘A corresponding V-model can be given for the hardware development of the electronic control unit (ECU) which is assumed here to exist already. An alternative to the V-model is, e.g. the waterfall model, e.g. Royce (1970) which is organized sequentially in one direction with recursions. ‘The V-model has the intention that the results, documents, and tests of the right branch correspond to the development procedures of the left branch. A further developed version with more flexibility is the V-model XT (BRD 2004) as discussed in Borgeest (2008). Some important steps of the V-model for the development of control and software functions can be described as follows: 1, Requirements: © user requirements; * definition of general (overall) functions and data (rated values) of the final product (ECU); general solution outline; development and manufacturing costs; timely development and milestones; result: requirements document (does not include technical implementation), 2. Specifications definition of the product (ECU) that fulfills the requirements; ‘© partitioning in manageable modules for control and diagnosis; ‘specification of features and data of the modules; © consideration of the sources, tools, and limitations for the development and final manufacturing and maintenance; © specification of hardware data; specification of used software, compilers, and development systems; ‘result: specification document.3. Vehicle Control Structures 46. iso) sotetaroprod pute “uonesqre> ‘oTemyfos fox|UO9 ‘stioHoU JontOD Yo youdoyaA9p a4p 105 POA. gE “BL apes sae ee aoa. omar no svonnoyoods33._Design of Vehicle Control Systems a7 3. Control-system design: detailed partitioning into electronic, mechanic, hydraulic, pneumatic, and thermal components with their auxiliary power supplies; detailed fixing of type of sensors and actuators and their data; © detailed data of interfaces among ECU, sensors, and actuators; task distribution between sensors and actuators with integrated electronics and ECU; © specification of power-related data; © hardware design: data of microprocessors, data storages, interfaces, bus sys- tems, cabling, and plug systems; ‘control engineering design: — definition of sensor inputs and outputs to the actuators; — control-system structure: feedforward control (open loop) and feedback control (closed loop); required engine and component models; = model-based design; — calibration (parametrization) methods; — supervision and diagnosis functions; © reliability and safety issues; FMEA (fault mode and effect analysis) studies for sensor, actuator, and ECU faults and failures; © result: control-system design document. 4, Modeling and identification: © required mathematical models of vehicles, sensors, actuators, powertrain, transmission; theoretical/physical modeling; experimental modeling; use of modeling/identification tools; measurement procedures for test benches, design of experiments; kind of models: stationary (lookup tables, polynomials, neural networks); dynamic (differential equations, neural networks); © result: vehicle, powertrain, and component models, 5. Control-function development: hierarchical control structure; computer-supported design, manual design; ECU states: from start-up to shut-off; vehicle states (discrete): from start to shutoff; control functions: vehicle-state-dependent, time-dependent; sampling times and word length; supervision and diagnosis functions; model-in-the-loop simulation: vehicle models and ECU models;48 3. Vehicle Control Structures © rapid control prototyping with development ECU, bypass computer and test bench; # result: control structure and control algorithms. Control-software development: © software architecture layers, modules; ‘* software-component interfaces; © high-level language: selection, floating point (e.g. C-code, MATLAB/ Simulink); availability of compilers for target software; implementation of control functions and modules into software structure; standardization and reuse of software modules; code optimization; testing of software modules with, for example, model-in-the-loop simulation; rapid control prototyping with bypass computer and test-bench experiments; result: control software (modules) in high-level language. . ECU target software development and implementation: «transfer of high-level language control software into machine code with fix point arithmetic. Use of crosscompiler; test of control functions with simulated engine; © software-in-the-loop simulation; © hardware-in-the-loop simulation if real-time functions with components are of interest; © result: implemented control software in target ECU. 'U hardware and software testing: © the ECU with target hardware and software undergoes intensive function tests; ‘integration tests with simulated sensor signals and actuators in real time; * hardware-in-the-loop simulation with simulated sensor output signals, simu- lated or real actuators, and real-time simulated comprehensive engine model; automated test-runs; testing of reaction to extreme speeds and loads (outside of normal operation); reliability and safety tests; tests for electromagnetic compatibility (EMC); result: verification that the ECU meets its specifications. Calibration of the control functions: © free parameters of control algorithms, characteristic curves, ot lookup tables (maps) are adapted to the real vehicle and drive train;33 10. A. Design of Vehicle Control Systems 49 © supported by calibration tool with editors at implementation level or physi- cally defined level; off-line calibration; online calibration (test bench, real vehicle); basic calibration of the stationary behavior; dynamic calibration of the dynamic behavior; calibration by manual optimization; calibration by optimization with vehicle models; result: calibrated ECU control functions Calibration with fine-tuning final fine-tuning of free parameters with the engine and transmission; driving experiments with the target vehicle; use of calibration tools, off-line or online; result: adapted ECU functions to transmission and vehicle. Verification of specifications, Final ECU, driveability tests, and field tests: © final vehicle control functions are tested with the target vehicle; © performance tests for different loads and environmental conditions (summer, winter, weather); # driveability tests; result: validation of requirements. 3.3.1.2 Workflow for Control Development and Calibration The workflow for the control-function development is depicted in Fig.3.9 in more det ail, also showing the use of software tools, computers, and test-bench experiments. It begins with physical and/or experimental modeling. The control development then comprises engine simulation, control-function development, and optimization, supp- orted by an ECU prototype or prototyping computer for probing the control functions with the engine on the test bench. The next steps are then the software development and testing for the target ECU by using personal computers. Frequently, the ECU hardware and software testing is performed with hardware-in-the loop simulation, connecting the ECU with real actuators and sensor interfaces. Acorresponding workflow for the model-based calibration of the control functions is illustrated in Fig. 3.10. Based on the already gained physical and/or experimental engine models, the model-based calibration of the control functions is carried out. First, the basic stationary control functions, as, for example, reference variables dependent on the operation point, and then the calibration of the dynamic control functions, by using the dynamic engine, drive train models, and vehicle models, is executed.3. Vehicle Control Structures 50 awowdoyesap wonstny-jontos 107 mopIOM 6°E “B14 Sopsn. peo Buse so qousqnos Loa : apm os somos sino dans resorind Wuosied sndiiooad spine ow —--' aH 1s sepou Fens anager | fomeues | | Sam | Padopsor| spout sou oy, samupiay] BE FAT sxenyos ba assnyos esyd counas | ayo a Aga AoA aoa | Twourdojrap fone ajspour epee Stoo Su) joo) wogeymuys por wSsap jonu0> soon a goo. pu wossou39 2909 oo} ones PE asap ‘ue uppou armas51 33._Design of Vehicle Control Systems nga ‘uoneigie> uonsuny-onue> paseg-[apoul Jo; MOULOM OLE "Bld pean | adKovond seindiaos reuosied nga sromes pte yousqnsor Li f avaaup uusgyiod eqns reagan ursasaup fe -uoness pages oieq agg ase, pow pute aoqan oddns apyndatos oppo soo) anenijos52 3. Vehicle Control Structures These procedures are carried out either with personal computers or special cal- ibration computers. The last step is a fine-tuning with the vehicle on a roller test bench and on the road. ‘The following sections consider the model-based control-function development and calibration in more detail. Some basic control structures and controllers are summarized in Appendix A.1 3.3.2 Model-Based Control-Function Development with Special Design and Simulation Tools A systematic and efficient development of control functions and their optimization and calibration requires special simulation methods and computers, which support the control-function development as well as calibration and software testing. This, is part of the control-system integration, represented in the right branch of the V- development model in Fig. 3.8, and will be considered briefly in this section. 3.3.2.1 Model-in-the-Loop Simulation and Control Prototyping ‘The description of the overall procedure for vehicle control development in Sect. 3.3.1 has shown that different types of simulations are used for the development of control functions and control software; see Figs.3.9 and 3.10. ‘A design of new control functions in an early development phase may be based on simulations with vehicle and engine models and an ECU model, ie. control algorithms in a high-level language, as, for example, MATLAB-Simulink. This is called model-in-the-loop simulation (MiL.). Both, the ECU and the vehicle are then represented as a model, ie. a virtual picture of the real parts; see Fig.3.11a If some control functions of a real development ECU can already be applied to the real vehicle on a test bench or on the road, because the real-time functions from a former, similar vehicle can be used, some new control functions may be tested as prototypes with a special real-time computer in parallel to the ECU. This is called rapid control prototyping (RCP). Frequently, the new control functions operate in a bypass mode and use the interfaces of the ECU to the sensors and the actuators; see Fig.3.11b. The computing power for the experimental RCP computer exceeds that of the ECU and operates with a high-level language. Thus, the new control functions do not have to be implemented in machine code within the limited computer power and fix point restrictions of an ECU. This may save considerable development time by trying and testing new functions directly on a higher software level with the real engine, If development ECU is not available, a powerful real-time computer can be used if the required sensor and actuator interfaces are implemented. It is then called fullpass mode (Schiuffele and Zurawka 2005). 3.3.2.2 Software-in-the-Loop and Hardware-in-the-Loop Simulation Existing vehicle models in high-level language can be used for the validation of software functions as test candidates in an early development phase by software-33._Design of Vehicle Control Systems 53 real vehicle [1 vehicle model Ivehicle model} real time vehicle model real real ECU components ou Ea 111 Different simulation and prototyping methods for control functions and software devel- ‘opment. a Model-in-the-loop (MiL.) simulation. b Rapid control prototyping (RCP). ¢ Software-in- the-loop (SiL.) simulation, d Hardware-in-the-loop (HiL) simulation ECU target code ° ® in-the-loop simulation (SiL); see Fig.3.L1c, The software functions may already be implemented with fix point or floating-point arithmetic and required interfaces, before they arc implemented on the target ECU. Real-time behavior is not required. Fora final validation of control functions, the target ECU with its interfaces has to cooperate with real signals. In order not tose real vehicles on expensive test benches, real-time vehicle models are implemented in a powerful development computer. The sensor signals may be generated by special electronic modules and the output sig- nals are frequently transferred to real actuators, like an electrical throttle, injection system, or steering actuator. Thus, the real ECU with implemented software operates, with some real components, but with simulated real-time high- performance vehicle models and is known as hardware-in-the loop simulation (HiiL); see Fig.3.11d. The advantages are that, ¢.g. software functions can be tested under real-time constraints, validation tests are reproducible and can be automated, critical boundary conditions (high speed and high load) can be realized without being dangerous, the reaction to faults and failures can be investigated, onboard diagnosis functions can be tested, etc.; compare Sinsel (2000), Schaffnit (2002), and Zahn (2012). An alternative rep- resentation for MiL, RCP, and Hil is illustrated in Fig. 3.12.54 3. Vehicle Control Structures vehicle model ECU or ECU model ial simulation tool high performance real-time CN LB real-time computer y (by pass) real-time integrated mechatronie system real vehicle (CU + real actuators 3.12 Different couplings between models and real parts for the development of control func- tions ‘This short summary of simulation and prototyping methods shows how the devel- opment of ECU control functions can be supported by using programmed dynamic engine and vehicle models of different granularity and different stages of the devel- opment of the control software, as depicted in Fig.3.9. This is a basis for virtual vehicle control development. The computer-based and model-based development can also be used for a part of control calibration, as indicated in Fig. 3.10. 3.3.3 Control-Software Development According to the V-development model in Fig.3.8, the first steps are the control- system development and the control- function development in high-end software (c.g. MATLAB Simulink™, and Stateflow™), The next steps ate then the control- software development and the software implementation on the ECU for seties pro- duction, This is also depicted as part of the overall workflow in Fig. 3.9, using special software tools and computers for code generation and testing with compilers and real- time simulation. In the following, some remarks are given briefly for the software architecture code generation and software testing.33._Design of Vehicle Control Systems 55 3.3.3.1 Software Architecture The design of the software architecture has to consider many aspects from software development to the requirements of the target microprocessor and include connected modules which have to be flexible with regard to continuous changes and variants. Several software layers have to be defined. The minimum is two layers, a platform software and an application software, as shown in Fig, 3.13 (Schiuffele and Zurawka 2005). The platform software is oriented to the ECU and comprises the operating sys- tem, communications, and network management according to OSEK/VDX (2005) standards and diagnostic protocols. OSEK stands for “Open Systems and Interfaces, for Automotive Electronics” and is the result of a committee of major automotive ‘manufacturers and component suppliers to support portability and re-usability of application software under real-time constraints, started in 1993. It also contains standardized flash memory programming procedures. The standardization of the platform software is additionally advantageous during software development with regard to software changes and parametrization. Interfaces for measurement and cal- ibration via CAN protocols support the development phase as well (Borgeest 2008; Zimmerschied et al 2005). A hardware abstraction layer (HAL) gives access to the peripheral components of the ECU and is specified for the used microprocessors. The application software can be designed by the vehicle manufacturer and con- tains vehicle- specific functions, Standardization takes place for control functions, ranging from lookup tables and their interpolation to dynamic control algorithms. The standardization is, e.g. treated in the MSR-MEGMA working group and ASAM. (2012), ‘The configuration of standardized software components allows a specific appli- cation by using configuration tools. An automated configuration comprises, e.g. the handling of signals, messages, buses, nodes, and functions. It may contain export and import interfaces with data exchange formats and a documentation interface. More details like data models for engine and vehicle variants, storage in volatile (RAM) or nonvolatile memories (ROM, PROM, EPROM, or Flash memory), and description files for data structure can be found, ¢.g. in Schauffele and Zurawka (2005). Activities for an open industry standard of the automotive software architecture between suppliers and manufacturers are going on in the AUTOSAR consortium, (AUTomotive Open System ARchitecture) since 2003 (AUTOSAR 2012; Heinecke cet al 2004; ATZ extra 2013). One of the aims is an open and standardized automo- tive software architecture. The standard includes specifications describing software architecture components and defining their interfaces. ‘The AUTOSAR architecture separates the basis software from the application software and connects them by standardized interfaces; see Fig. 3.14. To master the complexity, several layers are defined (Wemnicke and Rein 2007). The connection to the microcomputer is provided by the lowest level, the microcontroller abstrac- tion layer, Here, the interfaces are defined to the memories, the /O-drivers, their communication, and additional features which are not part of the microcontroller. ‘The second layer is the ECU abstraction layer, comprising the hardware design of the ECU including the driver to external components. The service layer at the third evel provides basic software modules like the operating system, memory administra-56 3. Vehicle Control Structures function | £3 g é function g f z -Oh Y. flash loader 5 é interaction layer 3 diagnostic protox E ‘management z OSEK-NM hardware network layer ISO ardwate, layer bus driver(s) (CAN, K-line, LIN) (HAL) operating system OSEK-OS. 13. Software architecture composed of standardized software components (Schiuffele and Zurawka 2008) tion, and bus communication. This layer is relatively independent of the ECU hard- ware. The fourth level is the runtime environment (RTE), which separates the basis, software and application software and carries out the data exchange in both direc- tions. Therefore, the application software components have standardized interfaces, (o the RTE, The RTE also integrates the application software components (SWCs); see Fig. 3.15. This separation and integration with standardized interfaces enable a hardware-independent software development. The application software components can therefore be transferred to other ECU’s and reused. A virtual function bus (VFB) connects the various software components during the design and allows a configuration independent of specific hardware. Thus, the SWCs are runnable entities and can be linked together for development and testing. An exchange of information becomes possible through standardized software input and output ports. Thus validation of the interaction of the SWCs and interfaces is, possible before software implementation.33._Design of Vehicle Control Systems 57 application layer AUTOSAR Runtime Environment service layer complete ECU abstraction layer drives microcontroller abstraction layer microcontroller Fig.3.14 AUTOSAR layer structure of automotive software (Wernicke and Rein 2007) actuator ITOS. application software AUTOSAR | Notas component component software component AUTOSAR ‘AUTOSAR ‘AUTOSAR ‘UTOSAR interface interface interface interface & AUTOSAR Runtime Environment (RI & basic software ole Ea 1.3.15 AUTOSAR software architecture components and interfaces (RTE: runtime environment) (Kirschke-Biller 2011)58 3. Vehicle Control Structures 3.3.3.2 Code Generation The control-software development can start if the control functions are ready and available as function blocks in a high- level software platform like MATLAB™ (2011), Simulink™ (2011), and Stateflow™ (2011) (The MathWorks (2011)). MAT- LAB™ js broadly used as an integrated function development environment for numerical calculations with a large library of mathematical design and analysis pro- grams and special tool boxes. Simulink™ is an interactive development environment for modeling, analysis, and simulation with a graphical interface and is integrated into MATLAB™. It allows the handling of models and functions with block dia- grams. Stateflow™ is an expansion of Simulink™ to operate with discrete event state charts and flow diagrams. Based on the block-oriented control functions of this control-analysis-and simulation-oriented development environment, the series production code for the ECU is developed by using special tools. The control functions are specified in graphical form and they are converted in production C-code which runs on the target processor. Thereby, it is intended to reach a minimum of execution time, RAM and ROM resources, and stack size, compared to human programmer’s abilities. The process of code generation is performed in the following steps (Kiffmeier et al 1999), using a Software Development Tool (SDT) like Targetlink™ from dSpace or ASCET™ from ETAS or Real-Time Workshop™ from MathWorks. 1, The control-fuunction block ftom Simulink has to be replaced by a corresponding SDT block, taken from a block library. These blocks manage data which is used for the production code, as scaling parameters and data types. 2, In the case of fixed-point arithmetic, scaling parameters ate required. Therefore, ‘maximal and minimal values of variables have to be known. They can be obtained from model-in-the-loop simulations to determine the range of variables, in order to prevent overflows. The scaling can be done manually or automatically by simulation, For floating-point arithmetic, no scaling is needed, 3. Additional information for production code generation has to be specified. This, belongs to the partitioning of models or algorithms for, e.g. lookup table handling, like interpolation routines. 4. Off-line simulations on the host PC are performed with Simulink to detect prob- Jems with fixed-point arithmetic. The simulations are run with floating-point arith- metic. 5, The production C code is translated for the target microprocessor and loaded on an evaluation board. A communication link between the evaluation board and the host PC allows testing the microcontroller code together with a Simulink simulated process model. The code is readable by humans and the development is paralleled by documentation, which is automatically generated. Information on code size, execution times, and used RAM and ROM resources are also given. The result is a general portable ANSI C-code which runs on many microcomputers. However, some specific microcomputer adaptation always has to be taken into account. If manual coding has to be applied additionally, rules given by MSRA-C have to be followed. Special toolsets allow analyzing the timing behavior of the33._Design of Vehicle Control Systems 59 real-time operating system application OSEK, providing runtime performance and possible modifications, before coding. As the ECU-code must be prepared for the task of calibration, the variables are presented in standardized ASAM file format via a data dictionary. Further standards to be considered are OSEK/VDX and AUTOSAR. AUTOSAR structure elements are, for example, runnables, ports, and communication interfaces. Special computers for simulation and control prototyping and software tools for control-software development are compiled in the catalogs dSpace (2017) and ETAS (2017) As modern automotive control systems are interconnected by onboard data buses like CAN, FlexRay, and LIN, also the real-time cooperation of the vehicle ECU with other vehicle ECU's like for engine and transmission control, traction control (ICS), electronic stability control (ESC), and adaptive cruise control (ACC) has to be designed and monitored. 3.3.3.3 Software Testing The software testing is part of the verification comprised in the V-model for the development; see Fig. 3.8. Verification means that the developed functions meet the specifications, which are stated at the project start by the customer, by standards or legal regulations. More general is the validation where the final product is checked with regard to the overall requirements (Balzert 1998; Tran 2007); see the V-model in Sect.3.3.1. Validation ensures that the final product meets the user's needs and includes that the specifications are correct; see, e.g, IEFE-STD 610, Software testing can be understood as part of analytical quality assurance and contains the testing of the software. This quality assurance can be divided into ana- lyzing methods (static) and testing methods (dynamic) (Liggesmeyer 2002; Thaller 2002). The static, analyzing methods can be applied early because no running soft- ware is required. Methods are manual inspection, visualization, and data flow analy- sis, usually by different persons. Dynamic testing methods operate with the running software and it is checked if the functions meet the specifications. One distinguishes, functional tests which check the input/output behavior and consider the software program as a black-box and structural tests where the program is considered as a white-box. These structural tests can be divided into symbolic tests, diversification tests, and mutation tests (Schiifer 2012). An application of software testing during the early phases of the develop- ment avoids too many iteration cycles. In order to integrate hardware components, hardware-in-the-loop simulation (HiL) is used. Then the real-time software on the target ECU is tested with simulated real-time models of the engine or the vehicle and real components like actuators or injection systems in the laboratory, such as, avoiding tests with the real vehicle; see Sect. 3.3.2. Table 3.1 gives a summary of the various development test stands and tools for the control development. Vehicle modeling is required in the beginning and performed online and off-line with the vehicle test bench, Control-function development is3. Vehicle Control Structures 60 wwone> x x uso uondeunsuod jany pue worssru x x x Augean x sossanoid 138m © x x x x x unsere x | suoudoqonep « | aremyos aoa x x x x ‘uoneZamIn x x x x x | suamdoyanep suowdoyoaap x x uonejnuns « | uonsuny-jonue ¥ ¥ ‘oneup — x Areuones — ‘Aieyuaciadss « ¥ x ¥ x otskyde Furepow goa, ere utatsp woyssrmsuen (e2a0) Butaup “ourduo) youog | 2poryaa pareinuuts) prvoq stusuoduos Toa, asouren aang | sosuomendp royoy | _wonenqeas, rari | Oa) Ts ‘peor Ho 919A, owog 1801 OHA. ada a mH Bune s[oo1 ++ spurs i801 wowadoyaaaqy says suaurdoyoaap jonuo>, awotudopanop jones ajonaa 107 s[oo) pu spurs sa) Jo Kaas LE.33 Design ofVehicle Control Systems 61 mainly elaborated at test benches and with MiL, HiL, and RCP computers. Software development is usually done off-line with PCs and an ECU evaluation board. Fine- tuning for driveability and emission certification are worked out with the real vehicle. References ATZ extra 2013) 10 years AUTOSAR. The worldwide automotive standard for E/E-systems, Spe- cial issue. Automobiltechnische Zeitschrift, Springer Vieweg/Springer Fachmedien Wiesbaden GmbH, Wiesbaden AUTOSAR (2012) Automotive Open System Architecture. www.autosarorg Balzert H (cd) (1998) Lehrbuch der Software-Technik, vol 2, Spektrum Akadcmischer Verlag, Heidelberg, Bohm B (1979) Guidelines for verifying and validating software requirements and design specifi cations. North-Holland, Euro-IFIP Borgeest K 2008) Elektronik in der Fahrzcugtechnik. Vieweg, Wiesbaden BRD (ed) (1997) V-Modell-Entwicklungsstandard fir IT-Systeme des Bundes. hiip:/www.v- ‘modell. iabg.de/am97 htm BRD (ed) (2004) V-Modell-XT. http://v-modelliabg.de Brohl AP (ed) (1995) Das V-Modell -Der Standard fur Softwareentwicklung, 2nd ed. Oldenbourg, Miinchen Droeschel W, Wiemers M (eds) (1999) Das V-Modell 97 - Der Standard fiir die Entwicklung von TT-Systemen mit Anleitung fir den Praxiseinsatz, Oldenburg Veriag, Mtinchen Space (2017) dSpace catalogue 2017, éSpace GmbH, Paderborn "TAS (2017) ETAS catalogue 2017, ETAS Gmbll, Stuttgart Guzzella L, Onder C (2004) Introduction to modeling and control of internal combustion engine systems. Springer, Berlin Heinecke H, Schnelle KP, Fennel H, Bortolazzi J, Lundh L, Leflour J, Maté JL, Nishikawa K, Scharnhorst T (2004) AUTomotive Open System ARchitecture-an industry-wide initiative to ‘manage the complexity of emerging automotive E/E-architectures, In: SAE 2004 Convergence, pp 325-332 Isermann R (2005) Mechatronic Systems - Fundamentals, 2nd edn. Springer, London Isermann R (2014) Engine Modeling and Control. Springer, Berlin Isermann R (2017) Combustion engine diagnosis. Springer Viewer, Berlin Kiffmeier U, Késter L, Meyer M, Witke C (1999) Automatic prodective code generation for elec- tronic control units. Automatisierungstechnik - at 47:295-304 Kirschke-Biller F (2011) Autosar ~a worldwide standard current developments, roll-out and out- ook. In: 1Sth Intemational VDI congress electronic systems for vehicles, Baden-Baden, Germany Kunkel F (2015) Optimaler Betrcb von Dieselhybridantrieben, Dissertation TU Darmstadt. epubli GmbH Liggesmeyer P (ed) (2002) Software-Qualitit: Testen. Spektrum Akademischer Verlag, Heidelberg, ‘Analysieren und Verifiziren von Software Reichart G, Bielefeld J (2009) Einflisse von Fabrerassistenzsystemen auf die Systemarchitektur im Kraftfahrzeug, In: Winner H, Hakuli S, Wolf G (eds) Handbuch Fabrerassistenzsysteme, Ist edn, Vieweg+TeubnerIGWV Fachverlage GmbH, Wiesbaden, pp 84-92 GmbI1 Robert Bosch (ed) (2018) Automotive handbook, 10th edn. J. Wiley, Chichester, England Royce W (1970) Managing the development of large software projects. In: Proceed. IEEE, Wescon Schafer $ (2012) Modellbasierte Steuerung des Kiihlkreislaufes einer Brennstoffzelle mit automa- tisiertem Test der Software, Dissertation Technische Universitat Darmstadt, Fortsch.-Ber. VDI Reihe 8, Nr. 1219 VDI Verlag, Disseldorf Schaffnit J (2002) Simulation und Control Prototyping zur Entwicklung von Steuergeritefunktionen fiir aufgeladene Nutzfalrzeug-Dieselmotoren. Dissertation Technische Universitat Darmstadt. Fortschr-Ber. VDI Reihe 12, 492. VDI Verlag, Diisseldorf62 3. Vehicle Control Structures Schauffele 1, Zurawka T (2005) Automotive software engineering. SAE, Warrendale, PA Sinsel S (2000) Echtzeitsimulation von Nutzfahrzeug-Dieseimotaren mit Turbolader zur Entwick- lung von Motormanagementsystemen, Logos, Doctoral thesis, University of Technology, Darm- stadt. Berlin Guide STARTS (1989) The STARTS purchases Handbook: software tools for application to large real-time systems, 2nd edn. National Computing Centre Publications, Manchester ‘Thaller G (ed) (2002) Software-Test-Verifikation und Validation, Heinz-Heise-Verlag, Hannover ‘Tran E (2007) Veriication/validation/certification, In: Koopman P (ed) Topics in dependable embed- ded software, Carnegie Mellon University. Pittsburgh, PA VDI 2206, (2003) Design methodology for mechatronic systems. Beuth Verlag, Berlin Wemicke M, Rein J (2007) Integration of existing ECU software inthe autosar architecture. ATZ- Elektronik 1:20-25 Zatn S (2012) Arbeitsspiclaufgeliste Modellbildung und Hardwate-in-the-Loop-Simulation von Pkw-Dieselmotoren mit Abgasturbolader. Dissertation Technische Universitit Darmsta. Fortsch-Ber. VDI Reihe 12, 760. VDI Verlag, Diisseldorf ‘Zimmmerschied R, Weber M, Isermann R (2008) Statische und dynamische Motorvermessung zur ‘Aaslegung von Steuerkennfeldem cine kurze Ubersicht. Automatisicrungstechnik- at 93(2):87— 94