The paper concludes by highlighting the process advantages and flexibility of such a system and the benefits to be gained from demonstrating advanced

Transcription

1 Using Rapid Prototyping tools for the integration of control systems for complex technology concept vehicles Pete James and Paul Cook Prodrive Ltd. ABSTRACT The construction of a robust technology demonstrator vehicle for evaluation by senior management is a vital tool in the process of bringing new technologies to the market place. The vehicle must be a fully functional test bench, able to highlight the advantages of the new technology, while at the same time indicating the areas requiring further development Prodrive has been involved for many years in the construction of advanced engineering concept vehicles, both for vehicle manufacturers and to demonstrate its own chassis and powertrain technologies. This paper looks at the proven methods developed by Prodrive to enable development of a running prototype vehicle and makes particular reference to the technologies used to bring a hybrid vehicle from specification to road in six months. The key to this rapid timescale was the development of the control system and the overall process control. INTRODUCTION Today s automotive market is driven by many factors, including legislation and the need for product differentiation. The main legislative demand upon vehicle manufacturers is the drive to minimize emissions and to maximize fuel economy. As the targets become more stringent, companies are turning to more innovative technologies to ensure their vehicle fleets meet the emissions and fuel economy targets. In addition to the legal requirements, product differentiation is also becoming more important in car design. The decision over which technology path to target is critical, yet the traditional method of constructing feasibility prototypes is often flawed because these projects fail to meet the market timescales set by the product planners. To ensure manufacturers produce competitively designed vehicles that satisfy the market drivers and legislation ahead of the competition, 1 companies are being forced to rapidly produce running prototypes in even shorter timescales. `çåíêçä=ëóëíéãë=áå=îéüáåäé Years To enable these new technologies prototypes to be made. Technologies from other industries as well as automotive need to be assessed. However, the types of control hardware employed in these new technologies, together with the corresponding communications protocols, vary from manufacturer to manufacturer. To select the best of the available technologies and combine it into one integrated system is traditionally expensive and logistically time consuming. However, Prodrive has now developed a method and hardware capability that allows this form of integration to be completed in rapid prototype timescales. This paper details the technical innovations in electronic control and software development, which form the backbone for the construction of various types of attribute demonstrators, together with the rapid prototyping processes developed by Prodrive. The paper is based upon the development of an integrated control system for the optimization of a hybrid vehicle. The vehicle in question was transformed from a specification document to a fully functional vehicle in six months.

2 The paper concludes by highlighting the process advantages and flexibility of such a system and the benefits to be gained from demonstrating advanced technology in the shortest time possible to senior management decision makers. RAPID PROTOTYPING ENABLERS The hybrid prototype, developed by Prodrive, was enabled through use of a number of new technologies. These included the use of the Proteus control unit, acting as both a high power ECU and a systems integration device, coupled with Prodrive s effective development processes. PROTEUS Proteus is a product developed by Prodrive as a solution to enable developers of real time software to quickly prototype complex real life control strategies (reference 1). Proteus provides the means for a control system, modeled in MATLAB, to be developed to control real world hardware in real time. This allows two completely separate control system models to be run simultaneously. For example, safety critical software can be developed in the MATLAB environment, run on one processor, and can be checked in real time using traditional C code on the second processor. Proteus also enables the user to read in variables from a wide range of signal types and to control a large number of actuators. It has CAN and serial communication interfaces and expansion ports to allow it to communicate with other control units and hardware. A custom MATLAB blockset then provides the interface between the Proteus hardware and the MATLAB model. The blockset is accessed via Simulink (see figure 3) and is compatible with the Simulink modeling tool. Proteus, and the development environment in which it is used, have been developed to run auto-generated code and to enable real time embedded control systems to be prototyped and developed quickly and easily. The Proteus configuration (figure 2) is based around the Motorola MPC555 PowerPC microprocessor. This device operates at 40MHz, has 26K SRAM and 448K of Flash memory within the processor. The MPC555 supports floating point operations making it ideal for auto-coded embedded systems. Proteus contains two MPC555 processors each connected to its own I/O circuitry. The two processors transfer information between each other across dual port RAM. Apart from sharing the dual port RAM, power supply and reset line, the two processors operate completely independently. Figure 3. The Proteus development environment Figure 2. Proteus hardware configuration 2 System development environment To enable software to be developed using Simulink, the blockset has been incorporated to give access to all the hardware features available in Proteus from within the Simulink environment (figure 4). These blocks allow the inputs, outputs and other functions to be controlled from within Simulink. The blockset is split into processor specific blocks and Proteus specific blocks. This allows

3 software to be developed using different hardware on the same processor. Files have been developed for the Real Time Workshop to allow the auto code process to build the code for the target ECU in one easy step. The model can be simulated in the same way as any other Simulink model, but it can also be run on the Proteus hardware alongside the control algorithm, thus comparing the model to the real world in real time. This feature can be used to perfect simulations and to provide hardware in the loop development. To overcome this, Proteus was used to integrate the various sub-system elements including those with diverse electrical architectures, with voltages ranging from 12 to 42 volts and even much higher. In this way Proteus fulfills the role of a high-level overall control unit mounted in the vehicle system. It can receive information from vehicle sub-systems and additional sensors, process this data, and transmit commands back to the sub-systems to control the vehicle. It also has the capability to control, at a low level, vehicle systems that do not have controllers. The combined use of Simulink and the Proteus blockset, to program Proteus, aids the development of both high and low level software, simultaneously. Figure 5 schematically describes the high level architecture of the system. In a vehicle powertrain system the primary control function is torque at the wheels. The torque at the wheels demand comes from the driver interface. In a conventional powertrain system, the main source for this torque comes from the IC power unit. However, in a hybrid vehicle the driver s torque demand can be achieved in different ways, depending upon the type of hybrid vehicle system designed. Torque Executive Functional Manager IC Engine Torque Supervisor Electric Motor Torque Supervisor Battery Control Supervisor FAS Torque Supervisor Figure 5: The high-level hybrid control hierarchy. Figure 4. List of blockset functions in Proteus The blocks are further split into three main functions: input functions, output functions and extended functions. The majority of the input and output function blocks are associated with a particular input or output pin on the Proteus unit. Other input and output functions can receive and transmit data from either of the CAN buses, this allows other units on the same bus to communicate. This data can then be controlled and used from within Simulink. Proteus as an integration tool One of the difficulties faced by engineers developing prototype vehicles is the enormous variety of communications protocols used in different technologies. 3 For example, in the scenario where a vehicle has a standard IC unit, with a combined starter generator, operating independently via its own embedded ECU, the torque demand of the driver would be accommodated by the engine control system. If the vehicle was then enhanced by an additional electric drive, also controlled by its own independent torque controller, then clearly balancing the interaction of the two systems seamlessly becomes more complex. Hybrid Vehicle Control using Proteus In the hybrid control hierarchy, figure 5, the role of Torque Executive and Functional Manager strategies is completed within the Proteus unit. Proteus receives the torque demand from the driver input and determines the most efficient way of meeting this demand. The Torque Executive (detail shown in figure 6) receives a demand input from the driver along with

4 status information about the batteries. From this data it decides on the most efficient method of producing the positive or negative torque required. The torque executive then sends its requirements to the functional manager, which, in turn, distributes the requirements to the various ECU sub-systems on the vehicle. The Functional Manager constantly monitors the status of the sub-system units, via the standard embedded ECU s. It then determines the torque available from the various power sources given the current state of each system and any prevailing environmental influences. The supervisor boxes, shown in figure 5, refer to the individual system ECU s, which continue to provide the local level control. This method achieves maximum utilization of existing control software saving hundreds of hours of re-coding. To efficiently control the hybrid vehicle components, a control model was designed using Simulink. The model, shown in figure 7, allowed the individual torques of the various power units to be co-ordinated to ensure the demands received from the driver were translated effectively between the electric motor, IC engine and starter alternator. Figure 6: The Torque Executive determines the most appropriate means to satisfy the driver s demands. 4

5 Figure 7: Hybrid car control model. 5

6 The control model, shown in figure 7, was developed as a strategy by a multi-skilled team of engineers including, powertrain, vehicle dynamics and control specialists. The Torque Executive strategy was initially developed and then cascaded down to the Functional Manager. By introducing expertise, information and specification requirements at an early stage, the strategy was developed to account for all the variations in modes of operation of the vehicle, including steady state running, transient operation and environmental changes. The detailed optimization strategies for enhanced fuel economy and emission performance were developed at the same time as other vehicle enhancements such as vehicle traction and stability control. It was in this area that Prodrive achieved a significant time saving. It was estimated that 80% of the working strategy was developed and understood within a couple of days. The strategy was then auto coded and bench test trials started. Compared to conventional software development methods this proved to be a major project saving in terms of cost and manpower. Communications interfaces The blocks on the left provide access to data being received from the external controller. The blocks on the right transmit data to an external controller. The Simulink blocks in the middle translate the data from one controller to another allowing different protocols to communicate. This technical ability enables systems from different suppliers to be brought together, regardless of CAN messaging systems. The Proteus unit, in simple terms, provides the role of an interpreter. The Simulink model was used to simulate the torque distribution between the IC engine and the electric motor depending on the driver demand signals. The model was then modified to ensure correct torque distribution and operation of the whole system. Other elements were added to the model to control output devices e.g. indicators to show the driver the torque distribution and charge state of the batteries, and to read sensor inputs e.g. battery or motor temperature. Once the model was thought to be operating correctly the input and output functions were changed for blocks from the Proteus blockset. An example of this can be seen in Figure 9, where digital and analogue inputs (identified by dark gray shaded blocks), used for ignition switch position input, are processed. Messages from the components and input sensors are controlled through a CAN bus. Driver demand is in the form of throttle position and a brake sensor. Figure 8 shows the CAN receive and transmit blocks being used within the hybrid control model. Figure 9: Example of part of the low-level hybrid car control model (Ignition Input Process) showing the Proteus Blocks in Simulink. Figure 8: CAN receive and transmit blocks from the Hybrid control model. 6 The model was then passed though the Real Time Workshop and the resultant target code downloaded directly to the Proteus hardware, which had been wired to the vehicle. Before the strategy was applied to the actual target vehicle, the model was fully tested in simulation mode, exercised through a test drive cycle to test each operation. The performance of each mode could then be evaluated and changes could be made in real time.

7 Vehicle tests were carried out and an iterative process of model refinement, rebuilding and downloading used until a satisfactory result was achieved. Where necessary, additional sensors were added to the vehicle and additional inputs allocated in Proteus. The signals were used within the model to refine it and to further control the system. Data derived was analyzed to evaluate the performance of the system and to determine the efficiency of the hybrid system. ROBUST VEHICLE BUILD The objective of any project involving the build of an active technology demonstrator is to be able to test the vehicle under a variety of test procedures and environments. In addition, because rapid prototyping methods accelerate the vehicle completion process, more time and budget can be allocated to the optimization of other vehicle attributes, such as vehicle dynamics. It is not enough therefore to purely build a demonstrator in reduced timescales. The attributes it is capable of demonstrating must be as broad in their range and as profound in their complexity as possible, due to the high cost of prototype technology. When building such vehicles, Prodrive s experience in constructing numerous World Rally Cars each year is an important factor. A World Rally Car contains many leading technologies in vital areas such as vehicle performance and stability. Each vehicle, to some degree, is unique and can easily be described as a technology demonstrator, rapidly built and then tested under extreme circumstances. It is this basic expectation that Prodrive applies to its main stream engineering vehicle demonstrators. Technology demonstrators must be tested to the full, both on chassis dynamometers, and then in the real world. Hybrid vehicle technology using electric DC motors leads itself not just to fuel economy and emissions enhancements, but also has a part to play in improving vehicle stability control during adverse conditions or adverse vehicle maneuvers. The robust vehicle-build process There are many important elements that ensure that technology prototypes can be produced in such a fast track process. Good communication and close proximity of key engineering skills are major factors. The motor sport industry is ideally placed to do this, as it consists of clusters of low volume manufacturers, experienced in the use of high cost materials and with a wealth of craftsmanship capabilities. It is this overall cocktail of skills and processes, coupled with close customer liaison that enable Prodrive to complete rapid prototype programmes in reduced timescales and budgets. CONCLUSION This paper has outlined some of the key aspects of the processes and hardware that are utilised by Prodrive to enable them to produce a highly accurate running prototype vehicle in short timescales from a clean sheet. The Proteus control unit dramatically cuts down the amount of up-front electrical and electronic work needed. This, combined with the MATLAB software, enables noncontrol systems based engineers to be employed at a tactical level across the project. Without devices such as Proteus and the use of MATLAB software coding, the time and manpower requirements for a project of this nature would be considerably higher. Proteus has been proven to provide an electronic control base with a broad scope capability capable of solving all control problems, on any vehicle or application. In addition, proven project management techniques combined with the availability of skilled designers and technicians within the rally development teams enhances the capability of Prodrive to meet the requirements of rapid prototypes in today s competitive automotive market. Demonstrators built and developed by Prodrive are tested in extreme circumstances, such as on low friction surfaces and in sub-zero temperatures. The sub-system technology must be robust enough to handle this. However, when this is not the case the subsystem technology must be designed into the vehicle in such a way that the vehicle itself provides the required environment. This is a key process in the overall success of such projects. 7

8 REFERENCES 1. James, P. Proteus, a rapid prototyping hardware tool for model based control systems, Prodrive Automotive Technology Ltd, Advanced Hybrid Vehicle Powertrains, Society of Automotive Engineers Inc., SAE2001, Special Publication SP1607. CONTACT Paul Cook is Head of Project Management at Prodrive based at the company s Automotive Technology headquarters in Warwick, UK. Peter James is Chief Engineer of Electronics and Firmware at Prodrive based at the company s Automotive Technology headquarters in Warwick, UK. He is responsible for the design and development of new electronic controllers for both development and production and plays a key role in the development of design methodologies and vehicle electrical and electronic architectures promoted and used by Prodrive. DEFINITIONS, ACRONYMS, ABBREVIATIONS Term: TPU, Timer Processing Unit, Motorola. USA MPC555 PowerPC microprocessor, Motorola. USA SIMULINK, Version 3, The MathWorks Inc. USA MATLAB, Version 5.3, The MathWorks Inc. USA CAN BUS, Controller Area Network for vehicle data transfer. Robert Bosch GmbH and Intel Inc. USA. Stateflow, MATLAB modeling tool, The MathWorks Inc. USA Mark Willows is Chief Engineer of Controls and Software at Prodrive based at the Automotive Technology headquarters in Warwick, UK. He is responsible for the development of control systems and software for a wide range of automotive projects ranging from new technology demonstrators to production designs. Prodrive Banbury Oxfordshire OX16 3ER England T +44 (0) F +44 (0) enquiries@prodrive.com 8