FUNCTIONAL AND ARCHITECTURAL SPECIFICATION FOR POWER-TRAIN CONTROL SYSTEM DESIGN A. Balluchi+, A. Ferrari+, A. Sangiovanni-Vincentelli+,+++, R. Flora++, G. Gaviani++, W. Nesci++, G. Serra++ +PARADES EEIG, Via San Pantaleo, 66, 00186 Roma, Italy balluchi, aferrari,
[email protected] ++MAGNETI MARELLI POWERTRAIN SpA, Via del Timavo, 33, 40134 Bologna, Italy roberto.flora, giovanni.gaviani, walter.nesci, gabriele.serra @bologna.marelli.it +++EECS Dept., University of California at Berkeley, CA 94720
[email protected]
Abstract: The design of power-train controllers is among the most challenging problems in automotive electronics because of (i) the complexity of the functions that the system has to support, (ii) safety aspects, (iii) the interaction among mechanical-electrical components and (iv) tight cost limits. Time-to-market requirements and continuously changing specifications have contributed to the migration of most functions to software implementations. We have developed a paradigm for the design of power-train controllers based on a new set of principles such as function-architecture co-design and platformbased design. This method has allowed us to increase dramatically the re-use of design effort while leveraging IC technology. This approach has been facilitated by the introduction of new advanced system design environments based on the principles mentioned above. This methodology is suitable for any type of mechatronic system in which a correct balance among mechanical, electronic and information technologies is essential for selecting an efficient implementation. Copyright © 2002 IFAC Keywords: mechatronic systems, embedded systems, automotive, design methodology.
1. INTRODUCTION Electronics has been a mainstay of power-train design since its introduction in injection systems. During the first period of application of electronic to engine control systems and up to recent products, a heuristic approach to design was followed. From a set of continuously changing specifications provided by car manufacturers in an informal, natural language-based, way, control system designers: 1. Developed heuristic, often open-loop, control algorithms to match controlled engine behavior to the specifications; 2. Implemented the algorithms on a mixed mechanical-electrical architecture whose electronic part consisted of programmable components (such as microprocessors), Application Specific Integrated Circuits, and physical devices such as sensors and actuators. In normal practice, the architecture of the electronic component was fixed a priori, (micro-controllers with fixed-point arithmetic units and given instruction set). The specifications and the control algorithms were so much tuned to this architecture, that it became very difficult to verify, in an effective way, the functional behavior of the system. In addition, control algorithms were based on simple and intuitive rules that did not provide sufficient guarantees of correct behavior. Each time a system requirement was modified, the entire system had to be changed at a very low level of abstraction, thus resulting in long re-design cycles and potential functional correctness problems that were very hard to discover before onthe-road testing. This method is reasonable as long as the complexity of the design can be managed by a small team of designers, the available components are few and new components become available rather slowly compared to design cycles. With the challenges facing today the automotive industry, it was clear that this design methodology reached its end-of-life. The problems to be faced were: 1. Specifications were too informal to be carefully analyzed in terms of feasibility, cost and time-tomarket. 2. The design was considered at a level of abstraction that was too low: engine behavior, driver inputs and control algorithms were all described together, resulting in a cumbersome and too detailed view of the design. 3. The plant to be controlled was seen as a single entity and control laws were applied heuristically to subsystems. 4. Software implementing the algorithm did not have structure: the application software was merged with software for the control and management of sensors and actuators. 5. Task decomposition at the operating system level was done heuristically and the timing behavior of the system was analyzed on the implementation. 6. Electronic (micro-controllers, ASICs) and mechanical components were so intertwined with the
solutions that a change in hardware was, at best, very difficult. Moreover, a more guided exploration of the mechanical/electronic solution space was almost impossible. 2. OVERVIEW We have been involved in the development of a new methodology for the design process of a power-train control unit. The goal of our design process was to shorten the design cycle by a sizable amount (from 5 to less than 3 years) while reducing the cost of the electronic system and increasing its quality and functionality. Essential points of the new approach are: the conscious re-use of previously designed blocks and the capability of making decisions at early stages of the design process. Early decision-making is possible because of the introduction of mapping steps between functionality and architectures at all levels of abstraction so that estimates of cost and performance could be computed and guide the design process. The methodology, summarized in Figure 1, is described as a set of successive refinement steps from a level of abstraction as high as possible to the details needed for the final implementation (see also (Balarin, et al. 1997; Rowson and Sangiovanni-Vincentelli, 1996; Sangiovanni-Vincentelli, 2000)). In our approach, we identify five main levels of abstraction: system level, function level, operation level, architecture level, and component level. It is important to stress that the application of this design methodology caused to rethink the entire organization of R&D inside Magneti Marelli Powertrain. The top management of the company started a re-organization that took one year from conception to implementation after the work on the design methodology was completed. The new organization reflected closely the design flow. In the next sections, we provide a detailed overview of the design process. 3. SYSTEM LEVEL: FORMALIZATION OF SPECIFICATIONS Car manufactures define the specifications of powertrain control systems in terms of desired performances of the vehicle in response to driver’s commands. Additional requested specifications, defined by governments or car manufacturers associations, are concerned with fuel consumption, noise and tail pipe emissions. At the system level, the given specifications are analyzed and expressed in an analytical formalism. Specifications have to be clearly stated and negotiated between customer and supplier to make sure that they are realizable within the budget and time allowed for completing the design. The description of the specifications must not contain considerations regarding the implementation of the control system, since this may prevent from an efficient re-use of existing solutions. However, often car manufacturers define some details of the mechanical and electrical architecture (e.g. use of a particular sensors or actuators). The mathematical
Powertrain System Specifications
Operation Design
Performance Back-Annotation
System and Functions Verify Decomposition
Verify Behavior
Capture Electrical and Mechanical Architecture
Operations and Architecture Verify Architecture
Map System Behavior to Architecture
Verify Performance
Mapping
Mechanical, HW and SW Components Implementation
Verify Components
Components
DESIGN
Function Decomposition
SPECIFICATION
formalization of the specifications, along with suitable simulation environments and engineering spreadsheet tools, support the design process at this stage. We advocate that a hybrid system formalism – which allows the description of discrete and continuous interacting dynamics (see Antasaklis, and A. Nerode (1998) for tutorials on hybrid systems) – is essential for the formalization of the requested specifications at the system level. Indeed, the desired behavior of the controlled system has to be expressed in terms of a number of different operation modes (SangiovanniVincentelli, 1997; Balluchi, et al., 2000). The activation of a particular operation mode is determined by either the action of the driver on the car input commands or by engine conditions. Each operation mode is characterized by specific controlled outputs (e.g. engine speed in idle mode), on which a performance objective is defined: usually in the form of either a regulation or a tracking control problem. Further, a set of constraints on critical variables related to drivability, safety, and emissions are given. The specification contains also a quantification of the degree of robustness with respect to disturbances and parameter uncertainties that has to be guaranteed at the system level. Transitions between operation modes are also subject to specifications that are formalized exactly in the same terms.
Fig. 1. Overall design methodology: from specification down to implementation the design steps are clearly defined and traced. 4. FUNCTION LEVEL DESIGN The design of the functionality to be realized by the control system to meet the system specifications described above is very complex. A good quality of the design is obtained by decomposing the system into interacting sub-systems, referred to as functions. An example of a power-train system is described at the highest level of abstraction by the functional scheme reported in Figure 2, whose elements are: motion generation (driver interface, drivability management, cruise control, interaction with other subsystems), exhaust management (emissions in compliance with standard), combustion (efficiency and combustion management), ignition (spark timing and energy), mixing (air-fuel mixture preparation),
fuel management (fuel quantity and injection timing), and air management (fresh air and exhaust gas recirculation), communication (i.e. information communing from other system entities, e.g. through a CAN bus, etc.), diagnosis and recovery. The decomposition allows designers to address the complexity if it leads to a design process that can be carried out as independently as possible for each component. System specifications are spread out among the functional components so that the composition of the behaviors of the components is guaranteed to meet the requested objectives and constraints. The flow is described by the white arrows in Figure 2. fuel management motion generation
mixing
air management
combustion
exhaust management
ignition
communication
diagnosis recovery
Fig. 2. Functional representation of the system: solid arrows denote physical signals; dashed arrows describe the functional design flow. The graph is visited following a topological sort. At each step, the behavior of the current function is established by means of a tradeoff process with the functions associated with its successors in the graph (w.r.t. dashed arrows order). The selected behaviors are such that the requirements are fulfilled with the lowest estimated cost. If this procedure does not yield a feasible solution then the graph sort is arrested and the procedure failure is reported at the predecessor nodes, which have to device a different solution. To evaluate performance objectives and constraints, hybrid models of the behavior of the functions are used. A major difficulty in carrying out the design at the functional level is the lack of suitable tools. Currently available simulation and verification tools for hybrid systems such as HyTech (Henzinger (1995)), CheckMate (Chutinan (1999)) and d/dt (Bournez (1999)), are not mature enough to support industrial applications yet. Notice that no detailed solution is proposed at this stage, but with this step we have been able to simplify the design problem considerably. By means of the propagation of the system specification on the functions, some very high-level characteristics of the powertrain control system, which have a deep and widespread impact on the overall project activity, are defined. The application of this level of abstraction inside the development process in Magneti Marelli Powertrain yielded the creation of a team devoted to decompose the system
specifications into function specifications. This team is also involved in the formalization of systems specification. 5. OPERATION LEVEL DESIGN The output of the functional level design is a desired behavior for each function. At the operation level, such desired behaviors have to be obtained, satisfying also some local objectives and constraints. Solutions are expressed in terms of basic building blocks, called operations. If a functional behavior is not achievable, the previous design step has to be revisited to adapt the local objectives and constraints or to change the functional decomposition itself. The design loop is closed as early as possible to avoid major re-design steps at a later stage that may yield so much damage to schedule and profitability. In a first design attempt, for each function, control strategies achieving the given specifications are devised. The control strategies operate on variables that are measured on the physical domain and produce values of variables that act on the physical domain. Then, each control strategy is refined by introducing chains of elementary operations, so that the set of all solutions can be integrated in a unique operations network. The following different types of operations are used: 1) Measurement: sensing of a physical quantities. 2) Control: feedback and feedforward laws, filters, estimation / adaptation algorithms, supervisors, etc. 3) Command: actuation of plant inputs. 4) Transport: transfer of given entities between two points of the plant (physical process). 5) Storage: accumulation of a given entities in a point of the plant (physical process). 6) Transformation: production of new physical entities from some different entities (physical/chemical process). 7) Diagnosis: diagnostic algorithms. A hybrid formalism is used to represent the chain of operations, and extensive hybrid simulation and verification is used to validate that the chosen operational solution achieves the desired functional behavior. Simulink/Stateflow can be used to perform simulations of the closed-loop hybrid model. The design flow must take into account a negotiation table between the engineering groups in charge of defining the functions specifications and the engineering groups in charge of defining the operations specifications, in order to take into account conflicting goals. The activity aimed at the sharing of operations among different functions is called integration. A common characteristic of operations is that they may be “reused” in order to realize the behavior of several functions, i.e. a given operation may produce a result usable by two or more functions. Thus to select the set of operations to implement we must pay attention to their granularity so that they are complex enough to yield sizable savings in design time and yet simple enough to be usable in several functions.
A further characteristic of the operations is that they are the main objects that will be manipulated in the evaluation phase of different architectures. Realizing an operation fully or partially in software or hardware or mechanically has different impact on the performance of a given implementation as well as on the overall cost. Hence, at this level the perimeter between mechanical components and electrical components is defined, by mapping the operations network into the two different domains. The overall aim is to produce an arrangement, which will achieve the requested functional performance minimizing the cost of the control system. 6. ARCHITECTURAL LEVEL The design step at the architectural level produces a mapping between the behavior that the system must realize (operations) and the chosen system architecture, i.e. an interconnection of mechanical and electrical components (e.g., sensors, actuators, microprocessors and ASICs). The set of components either are available in a library of existing parts or must be designed ex novo. This architecture and component-selection task is the subject of intense research by the system design community. The most difficult problem to solve is how to rank different alternatives in terms of performance, cost, power consumption, reliability, and fault tolerance. In our case, the mix of mechanical and electronic components to be considered further complicates the problem. Our methodology is based on the work reported in (Balarin, et al. 1997; Rowson and SangiovanniVincentelli, 1996; Ferrari, et al., 2000; SangiovanniVincentelli, 2000; Ferrari and SangiovanniVincentelli, 1999). To rank different system architectures, the cost and performance of the mapped behavior must be estimated. The system cost is estimated as the sum of the component costs. Analysis and simulation are used to obtain an estimate of system performance. As shown in Figure 1, a non-detailed design for the mechanical domain is used to have a first rough estimate for the cost-performance tradeoff. For the electronic components, the behavioral description is mapped to the electronic system architecture whose performance is then estimated. The interface components, mainly sensors and actuators, have cost and performance effects on both mechanical and electrical domains and must be taken into account. The behavior decomposition in terms of operations is partially related to the chosen architecture since partitioning between mechanical and electronic components could require the design of new operations. For the electronic part of the design (see (Balarin, et al., 1997)), the estimation techniques were based on approximate timing models of the programmable units. From the high level description of the algorithms to be implemented, the code is automatically generated in optimal form and the performance of the selected architecture is evaluated.
This is a rather radical change with respect to the software development practice in the automotive industry where the software is not specified at the algorithmic level but rather at a much lower level of abstraction that is quite close to the architecture selected for implementation. It is not infrequent to encounter control software specifications expressed in terms of look-up tables. Look-up tables are indeed the most efficient way of carrying out complex arithmetic operations with micro-controllers that have integer ALUs. Hence, in this case, specifications are intimately linked to implementations, a clear violation in a clean design method. The model of each function (i.e. its description at the operation level) must be specified in an implementation-neutral way. This is essential for performing a correct analysis for the selection of the best architecture. The mapping of the functionality to the architecture consist either in the generation of code that runs on the programmable components of the architecture (micro-processors and/or DSPs), or in the generation of a gate net-list to be mapped into an ASIC or an FPGA, or both. These generation phase can be done either automatically or by hand, and is based on complex optimization strategies. For each architecture under consideration, we have a set of algorithms in place to implement effectively high level specification on the components of the architecture. The mapping process consists itself of several substeps. For example, if the selected architecture supports only fixed-point computations, then the control algorithms that are typically formulated using a floating-point notation, have to be mapped into a fixed-point representation. This operation is usually done by hand in a trial and error fashion and it is very time consuming. Designer experience and knowledge is today fundamental to obtain reasonable results. 7. COMPONENT LEVEL Once high-level restructuring operations like the one described above are completed and the architecture of the implementation has been selected, we need to: 1. Represent the resulting description of the operations in terms of the basic operations (instructions) of the programmable components of the architecture (software design). 2. Design the components of the architecture that are not available in the library. In Figure 1, the sub-steps corresponding to mechanical-electrical system mapping and to implementation are shown. Hardware and software are the by-products of mapping a set of operations respectively to application specific integrated circuits and to programmable components of the electronic architecture. “Hardware” component design follows standard design practices and for this reason it will not be addressed here. The software generation step is analogous to the compilation process in standard computing. However, in the embedded systems domain cost considerations are so important, that
inefficiencies in terms of memory and CPU occupation are hardly tolerated. Hence, embedded software designers often resort to the use of low level programming techniques that may involve assembly language programming with the obvious negative effects on the long-term maintainability and traceability of the code. Since operations are fully modeled using high level languages, e.g. Simulink/Stateflow, we have been able to exploit different software synthesis techniques that can produce object code that is competitive with hand designs (Balarin, et al., 1997, Koster, et al., 2001). We believe that software synthesis is essential to improve software quality and reduce time-to-market by a substantial amount. This software design methodology is also called model based software design flow. Software has an architecture as well. Software architecture (Ferrari and Sangiovanni-Vincentelli, 1999; Sangiovanni-Vincentelli, 2000) consists of the organization of the software in components that favor performance, re-use and debugging. In particular, the decomposition of software into application software and basic software is of great importance. Basic software is related to device drivers, real time operating systems and is delivered as a platform. Application software is related to the implementation of the control algorithm. This decomposition allows: the developer of application software to write his code independently of the peculiarities of the I/O devices used, the developer of the platform to build software and hardware components independently from the particular control algorithm. Unfortunately, most of the code in use today is not organized in this way: device drivers and algorithm implementation are tightly intertwined so that it is very difficult to migrate from an architecture to another. Today, sensors and actuators are distributed in the car since they are mostly in proximity with the mechanical components of the system, while the digital processing functions are centralized. The decision whether to decentralize the digital processing functions or to integrate the I/O functions should be completely transparent to the application software developer. Unfortunately, this is not the case today. A way of obviating to the drawbacks of the present software architecture is to provide a standard application program interface (API), that we call system API, to access any process information independently on the location, local or remote, of sensors and/or actuators. The hardware/software architecture and components implementing this API is called system platform (Ferrari and SangiovanniVincentelli, 1999; Sangiovanni-Vincentelli, 2000).
CONCLUSION We believe that a radical change in methodology is needed to solve the increasingly challenging design problems posed by the automotive industry. In this paper, we presented a new methodology for power-
train control systems design that is heavily based on abstraction, decomposition and, above all, on separation between Function design and Architectural design. Abstraction is an essential aspect in complexity reduction and in tighter quality control. We identified five levels of abstractions and given examples on how to use effectively these levels of abstraction. Decomposition is another important technique to enable a careful testing coverage and to analyze even the most complex control system. The implementation techniques are heavily based on an existing electronics system-design methodology (Rowson and Sangiovanni-Vincentelli, 1996;. Ferrari and Sangiovanni-Vincentelli, 1999; SangiovanniVincentelli, 2000)1. We demonstrated the entire design process with a complete product for engine control. Reusability stemming from the use of Functional level specifications was also demonstrated with the conversion of an existing product based on a particular chip-set to a new one characterized by a completely different chip-set (micro-controller and custom chips) with the same performance but better cost. This was made possible by the Layered SW structure implemented in Magneti Marelli Powertrain products according to the principles of software platform. The methodology allowed us to identify potential problems and opportunities that a traditional, singleprocessor architecture may have when additional complex functionalities, such as a robotized gearshift, are added to engine control. With the help of the methodology and of the supporting tools, we were able to specify a new multi-processor architecture tuned to the power-train control application for our IC partners (Ferrari, et al., 2000). ACKNOWLEDGMENTS We wish to thank Michele Pennese, Eric Massimelli, Paolo Marceca, Giacomo Gentile, Luigi Romagnoli, Giorgio Bombarda, Carlo Rossi, for the valuable collaboration during the development of the design methodology. REFERENCES Antasaklis, P.J., and A. Nerode (Ed.) (1998). Special Issue on Hybrid Control Systems. IEEE Trans. on Automatic Control, 43, (4). Balarin, F., et al. (1997). Hardware-software codesign of embedded systems: the Polis approach. Kluwer Academic Press, New York. Baleani, M., A. Ferrari, A. Sangiovanni-Vincentelli and C. Turchetti (2000). Hardware-Software Codesign of an Engine Management System. In: Proc. of Design Automation and Test Europe Conf. 2K. Paris. Balluchi, A., M.D. Di Benedetto, C. Pinello, C. Rossi, and A.L. Sangiovanni-Vincentelli (1999). Hybrid
1
See also http://www.cadence.com/whitepapers/vcc.html.
control in automotive applications: the cut-off control. Automatica, 35, 519-535. Balluchi, A., L. Benvenuti, M.D. Di Benedetto, C. Pinello, and A.L. Sangiovanni-Vincentelli (2000). Automotive Engine Control and Hybrid Systems: Challenges and Opportunities. Proceedings of the IEEE, 88, 888-912. Balluchi, A., M.D. Di Benedetto, C. Pinello, and A.L. Sangiovanni-Vincentelli (2001). Mixed Models of Computation in the Design of Automotive Engine Control. In: Proc. 40th IEEE CDC, 4, 3308-13, Orlando, FL. Bournez, O., O. Maler and A. Pnueli (1999). Orthogonal Polyhedra: Representation and Computation. In Proc. of HSCC1999. LNCS. Springer-Verlag, London. Chutinan, A. and B.H. Krogh (1999). Verification of polyhedral-invariant hybrid automata using polygonal flow pipe approximations. In Proc. of HSCC1999. LNCS. Springer-Verlag, London. Ferrari, A., S. Garue, M. Peri, S. Pezzini, L. Valsecchi and W. Nesci (2000). Design and Implementation of a Dual Processor Platform for Power-train Systems. In: Proc. of Convergence 2000. Detroit. Ferrari. A., and A. Sangiovanni-Vincentelli (1999). System Design: Traditional Concepts and New Paradigms, In: Proceedings of the 1999 Int. Conf. On Comp. Des., Austin. Henzinger T.A., P.-H. Ho and H. Wong-Toi (1995). A user guide to HyTech. In Proc. of the First Workshop on Tools and Algorithms for the Construction and Analysis of Systems.SpringerVerlag. New York. Rowson, J., and A. Sangiovanni-Vincentelli (1996). System Level Design. EE Times. Sangiovanni-Vincentelli, A. (1997). Embedded system design and hybrid systems. In: Control using logic-based switching, LNCIS, 222 (A.S. Morse (Ed.)), 17-38. Springer-Verlag, London. Sangiovanni-Vincentelli, A., (2000). Automotive Electronics: Trends and Challenges. In: Proc. of Convergence 2000. Detroit. Köster L., Thomsen T., Stracke R., Connecting Simulink to OSEK: Automatic Code Generation for Real-Time Operating Systems with TargetLink. In Proc. of Embedded Intelligence 2001, Nuremberg, Feb 14 - 16.
