Decision and control system of a solar powered train
Maria Beatriz Namorado Stoffel Feria´
Dissertac¸ao˜ para obter o grau de Mestre em Engenharia Electrotecnica´ e de computadores
J ´uri Presidente: Doutor Carlos Filipe Gomes Bispo Orientador: Doutor Joao˜ Fernando Cardoso Silva Sequeira Arguente: Doutor Hugo Filipe Costelha de Castro Vogal: Doutor Horacio´ Joao˜ Matos Fernandes
Abril 2012
Reasonable people adapt to the world. Unreasonable people persist in trying to adapt the world to themselves. Therefore, all progress depends on unreasonable people. George Bernard Shaw Acknowledgments
I would like to express my appreciation to my advisor Professor Joao˜ Sequeira for his guidance and continuous support through the development of my thesis. All the positive and constructive dis- cussions that we had during these last months motivated me and pushed me into wanting to do better, investigate more and find new solutions so that both of us could feel proud of our work. Abstract
This thesis addresses the design and simulation of a Decision and Control System (DCS) for a Solar Powered Train (SPT). An intelligent control approach is followed, namely by modeling the whole infrastructure as a discrete event system, represented by Petri nets (PNs), and designing a supervisory controller for the whole system. The DCS is able to manage all energy consumption devices onboard the train, namely, solar panels, batteries, sensors and computational devices, in order to ensure that the train finishes its missions successfully. The system uses previously acquired information on the topology of the line, e.g., length and slopes, locations of the intermediate stations, dynamics of the train, current solar irra- diance and weather forecasting, and passenger weight to determine boundaries on the train velocity profile. Many factors are also involved, such as panel electrical power output, obstacle detection, electric power consumed by engines and several other devices. The control system must take these factors into account and needs real-time observation of all of these variables, which is accomplished through sensors and data bases that can be accessed by the system. Given the energy requirements of all the devices onboard the train, the energy management system must determine if the proposed mission can be carried out successfully, and determine a corresponding range of admissible velocities for the train. The dynamics of the vehicle is also modeled, under Simulink environment, taking into account the effects of aerodynamic drag, friction of railways, gravitational forces and inertia. The whole system was simulated integrating PNs in a Matlab/Simulink environment, using for this purpose two key toolboxes: Netlab and Quasistatic Simulation (QSS). Netlab allows the interaction between PNs and Simulink simulation environment. QSS models the motion dynamics of a vehicle and all its main components such as engine, battery and gear system. The performance of the sys- tem is illustrated through several simulations in multiple realistic scenarios.
iii Keywords
Petri nets, solar powered train, supervisory control
iv Resumo
O objectivo deste trabalho consiste no desenvolvimento de um sistema de decisao˜ e controlo (SDC) para um comboio movido a energia solar. O sistema global, incluindo o comboio e estruturas exteriores, e´ modelado atraves´ de um sistema de eventos discretos, nomeadamente redes de Petri, sendo de seguida desenvolvido um controlador supervisor. O SDC tem a func¸ao˜ de gerir todos os equipamentos relacionados com o consumo e produc¸ao˜ de energia, nomeadamente paineis´ solares, baterias, sensores e computadores, por forma a assegurar que o comboio cumpre com sucesso o objectivo e chega com seguranc¸a ao seu destino. O sistema utiliza informac¸ao˜ a priori sobre a topologia da linha, nomeadamente comprimento e inclinac¸ao˜ de cada troc¸o, localizac¸ao˜ de estac¸oes˜ intermedias,´ irradianciaˆ solar no instante actual, previsao˜ meteorologica´ e peso transportado pelo comboio, por forma a estabelecer limites na veloci- dade do comboio. Os factores envolvidos sao˜ tais como o valor de potenciaˆ fornecido pelos paineis,´ a existenciaˆ de obstaculos´ na linha, a potenciaˆ necessaria´ por parte dos motores e outros equipamen- tos, entre outros. O SDC devera´ ter estes factores em conta e a observac¸ao˜ destas variaveis´ e´ feita em tempo real e atraves´ de sensores e bases de dados interligados com o sistema. Tendo em conta os requisitos energeticos´ de cada dispositivo, desde motores a todos os equipamentos electronicos,´ e tambem´ o objectivo a cumprir por parte do comboio, o SDC determina se este sera´ cumprido com sucesso e um correspondente leque de velocidades atingidas pelo comboio durante a missao.˜ A dinamicaˆ do ve´ıulo e´ modelada em Simulink e tem em conta os efeitos resistentes da aerodinamica,ˆ fricc¸ao,˜ gravidade e inercia.´ O sistema global e´ simulado em Simulink e com integrac¸ao˜ de redes de Petri, utilizando duas toolboxes fundamentais para este efeito: Netlab e QSS. O QSS permite mod- elar a dinamicaˆ do ve´ıculo e dos seus componentes principais tais como o motor, bateria e sistema de mudanc¸as. O Netlab por seu lado permite fazer a interacc¸ao˜ entre Simulink e as redes de Petri. Esta interacc¸ao˜ e´ fundamental uma vez que permite a realizac¸ao˜ de simulac¸oes,˜ estabelecendo uma comunicac¸ao˜ em tempo real entre o Simulink e a rede de Petri. O controlo de supervisao˜ e´ entao˜ aplicado, a´ dinamicaˆ do sistema e atraves´ da rede de Petri desenvolvida. O desempenho do sistema
v e do controlador supervisor e´ ilustrado em varias´ simulac¸oes˜ e em multiplos´ cenarios.´
Palavras Chave
Redes de Petri, Comboio solar, Supervisao˜
vi Contents
1 Introduction 1 1.1 Background ...... 2 1.2 Motivation ...... 2 1.3 Original Contributions ...... 4 1.4 Thesis Outline ...... 5
2 State of the Art 7 2.1 Solar Powered Vehicles ...... 8 2.2 Discrete Events Systems and Supervisory Controllers ...... 12
3 Vehicle Modeling and Simulation Environment 17 3.1 System Overview ...... 18 3.2 Vehicle Performance Analysis ...... 20 3.2.1 Aerodynamic drag force ...... 21 3.2.2 Rolling resistance ...... 22 3.2.3 Gravitational force ...... 22 3.2.4 Inertial force ...... 22 3.3 Vehicle modeling: QSS toolbox ...... 23 3.3.1 Quasistatic Approach ...... 24 3.3.2 Vehicle block ...... 25 3.3.3 Electric Motor ...... 26 3.3.4 Battery ...... 29 3.3.5 Gear System ...... 30 3.3.6 Application Example ...... 31 3.4 DES Modeling: Netlab toolbox ...... 36 3.4.1 Describing the Windows Netlab Interface ...... 36 3.4.2 Describing the Simulink interface ...... 37 3.4.3 Example of integration of a Petri Net in Simulink: ...... 38
4 Petri Net Model and Supervisory Controller 43 4.1 Petri net Model ...... 44 4.1.1 Train ...... 45
vii 4.1.1.A Petri net analysis ...... 46 4.1.2 Battery ...... 47 4.1.2.A Petri net Analysis ...... 49 4.1.3 Motor ...... 50 4.1.3.A Petri net analysis ...... 51 4.1.4 Cruise speed reference ...... 52 4.1.4.A Petri net analysis ...... 53 4.1.5 Overall system ...... 54 4.2 Supervisory Controller ...... 55 4.2.1 Synthesis of controller using linear constraints ...... 55 4.2.2 Synthesis of controller using generalized linear constraints ...... 56 4.2.3 Constraints involving the firing vector ...... 57
5 Results and Discussion 61 5.1 Power available ...... 62 5.2 Simulation Tool Model ...... 64 5.3 Acceleration Influence ...... 65 5.4 Deceleration Influence ...... 66 5.5 Weight Influence ...... 67 5.6 Gradient Influence ...... 68 5.7 Battery Requirements ...... 70 5.8 Obstacle on track scenario ...... 71 5.9 Cloudy Weather and Power failure scenario ...... 73 5.10 Three stations path scenario ...... 75 5.11 Time Restriction - Definition of required cruise velocity ...... 77
6 Conclusions and Future Work 83
Bibliography 85
Appendix A Appendix A A-1 A.1 Simulation Tool Manual ...... A-2 A.1.1 Vehicle block ...... A-3 A.1.2 Simple transmission system block ...... A-4 A.1.3 Electric motor block ...... A-5 A.1.4 Battery block ...... A-6 A.1.5 Location tracking block ...... A-7 A.1.6 Battery state control ...... A-8 A.1.7 Battery charging control ...... A-9 A.1.8 Obstacle detection laser range finder block ...... A-9 A.1.9 Panel block ...... A-10 viii A.1.10 Weight sensor block ...... A-10 A.1.11 Timed Petri net block ...... A-10 A.1.12 Supervisory controller ...... A-11 A.1.13 Velocity control block ...... A-12
ix
List of Figures
1.1 Artistic view of Helianto: a) Perspective view; b) Side view...... 3 1.2 Block diagram of the overall system...... 4
2.1 Racing solar cars: a) Race vehicles heading towards the finish line; b) The winner, Tokai University, Japan of the 2009 World Solar Challenge. c) The Dutch winner of the 2005 World Solar Challenge ...... 8 2.2 Top view of Belgium solar train and tunnel...... 12 2.3 Graphical representation of PN elements...... 13 2.4 An example of a PN graph...... 14
3.1 Block diagram of the overall decision and central system...... 19 3.2 Forces acting on a vehicle in motion...... 21 3.3 Generic Diagram of Quasistatic Approach...... 24 3.4 QSS library...... 25 3.5 QSS vehicle block: a) masked vehicle block; b) unmasked vehicle block...... 26 3.6 Electric motor efficiency map...... 27 3.7 QSS electric motor block: a) masked motor block; b) unmasked motor block...... 28 3.8 QSS battery block: a) masked battery block; b) unmasked battery block...... 30 3.9 QSS battery block: a) masked simple transmission block; b) unmasked simple trans- mission block...... 31 3.10 Top level Simulink model of a basic QSS application...... 32 3.11 List of driving cycles data files provided by QSS...... 32 3.12 Speed and distance covered along the driving cycle...... 34 3.13 Acceleration and power required by the motor during the driving cycle...... 35 3.14 Battery charge curve during the driving cycle...... 35 3.15 Netlab library...... 37 3.16 Simulink Netlab toolbox library...... 37 3.17 basic model of a train...... 38 3.18 Basic train model imported to Simulink...... 38 3.19 Model in Simulink...... 39 3.20 Simulation results...... 40 3.21 Simulation results overlapped and with offset...... 41
xi 4.1 PN representing the train sub-system...... 46 4.2 Petri Net designed representing the battery sub-system...... 48 4.3 Petri Net designed representing the motor sub-system...... 51 4.4 Petri Net representing the cruise speed reference...... 53 4.5 Petri Net representing the whole system...... 54 4.6 Petri Net model of supervised system...... 59
5.1 Irradiance...... 62 5.2 Power delivered by the 12 panels...... 63 5.3 Power required as a function of cruise velocity...... 63 5.4 Cruise velocities allowed...... 64 5.5 Simulation tool model...... 65 5.6 Peak power and battery energy use, given different acceleration values...... 66 5.7 Regenerated energy and braking phase duration given different values of deceleration. 67 5.8 Ratio of power demand to reference demand, given a range of carried weight...... 67 5.9 Cruise velocity and travel time given a range of carried weight ...... 68 5.10 Ratio of power demand to reference demand, given a range of track gradients, for a fixed route and velocity...... 69 5.11 Cruise velocity and travel time given a range of track gradient...... 69 5.12 Velocity during travel - obstacle scenario...... 71 5.13 Distance covered - obstacle scenario...... 72 5.14 Power delivered and required - obstacle scenario...... 72 5.15 Battery charge curve - obstacle scenario...... 72 5.16 Velocity profile - power failure scenario...... 73 5.17 Power delivered and required - power failure scenario...... 74 5.18 Distance covered - power failure scenario...... 74 5.19 Battery charge curve - power failure scenario...... 74 5.20 Track topology - three stations scenario...... 75 5.21 Velocity profile - three stations scenario...... 76 5.22 Covered distance - three stations scenario...... 76 5.23 Power delivered and required - three stations scenario...... 76 5.24 Battery charge curve - three stations scenario...... 77 5.25 Added Petri net - timed mission...... 78 5.26 Simulink model that defines the timed firing of transition 1...... 78 5.27 Simulink model that defines the firing of transition 2...... 79 5.28 Simulink model that defines minimum cruise velocity - timed mission...... 79 5.29 Velocity profile - timed mission...... 80 5.30 Minimum cruise velocity - timed mission...... 80 5.31 Covered distance - timed mission...... 80
xii 5.32 Power delivered and required - timed mission...... 81 5.33 Battery charge curve - timed mission...... 81
A.1 Simulation tool model...... A-2 A.2 Simulation tool global interface...... A-3 A.3 Vehicle block interface...... A-4 A.4 Simple transmission block interface...... A-5 A.5 Motor block interface...... A-6 A.6 Battery block interface...... A-7 A.7 Location tracking block...... A-7 A.8 Battery state control block...... A-8 A.9 Battery charging control block...... A-9 A.10 Laser range finder block...... A-10 A.11 Panel block...... A-10 A.12 Timed Petri net block...... A-11 A.13 Petri Net model of supervised system...... A-11 A.14 Velocity control block...... A-12
xiii
List of Tables
3.1 Typical rolling coefficients (source [1])...... 22 3.2 Driving cycle block...... 33 3.3 Vehicle block...... 33 3.4 Battery block...... 33 3.5 Electric Motor block...... 33 3.6 Simple transmission block...... 34
4.1 Conditions in sub-system train...... 45 4.2 Events and dependencies in sub-system train...... 45 4.3 Conditions in sub-system battery...... 48 4.4 Events and dependencies in sub-system battery...... 48 4.5 Conditions in sub-system motor...... 50 4.6 Events and dependencies in sub-system motor...... 50 4.7 Conditions in sub-system cruise speed reference...... 52 4.8 Events and dependencies in sub-system cruise speed reference...... 52 4.9 Constraints and corresponding supervisory control solutions and auxiliary variables. . . 58
5.1 Simulation parameters defined for minimum battery requirements...... 70 5.2 Battery energy densities (source:[2])...... 71 5.3 Requirements for three stations mission...... 75 5.4 Requirements for time restriction mission...... 79
A.1 Input and Output signals and parameters required for Location tracking block...... A-8 A.2 Input and Output signals and parameters required for Battery charging control system.. A-9 A.3 Input and Output signals and parameters required for Battery charging control...... A-9 A.4 Input and Output signals and parameters required for Laser range finder block...... A-10 A.5 Input and Output signals and parameters required for Panel block...... A-10 A.6 Input and Output signals and parameters required for Velocity control block...... A-12
xv Abbreviations
QSS Quasistatic Simulation
SPT Solar Powered Train
DES Discrete Event Systems
DCS Decision and Control System
RBD Reliability Block Diagram
PNs Petri nets
PN Petri net
xvi 1 Introduction
Contents 1.1 Background ...... 2 1.2 Motivation ...... 2 1.3 Original Contributions ...... 4 1.4 Thesis Outline ...... 5
1 1.1 Background
The need to find energy sources other than fossil sources for vehicles is pushing towards the development of electrical vehicles. The rising costs and shortage of fuel together with the pressing need to reduce air pollution are the main motives leading to the development of efficient and sus- tainable electrical vehicles. Since electric vehicles can be powered by a variable set of sources of electrical energy (renewable and non-renewable) and are emission free, they are an economic and environmentally friendly alternative to fossil fuels engines. However, autonomous electric vehicles have limited energy autonomy. This means that the time between recharges tends to be too small, resulting from the low energy density and high mass char- acteristics of batteries, in comparison to liquid fossil fuels that have high energy density, robust design, longer driving range and no battery charging requirements. In order to reduce the energy consump- tion and consequently increase the time between recharges and increase autonomy, two alterations can be implemented: First, vehicles can be built with lighter materials and with improved aerodynam- ics. Secondly, batteries can be placed onboard the vehicles so that they can be recharged while moving.
1.2 Motivation
This work was developed under the scope of project Helianto [3], which is a sustainable mobility project envolving several departments and scientific areas of IST (Instituto Superior Tecnico)´ including the Departments of Mechanic, Physics, and Electrical Engineering. The mission of this project is to research and create technological solutions for electric vehicles, with potential for industrialization. Taking into account the current project Helianto goals, the main purpose of this work is to design a Decision and Control System (DCS) that can efficiently manage the energy system of a Solar Powered Train (SPT). The SPT is an autonomous vehicle, powered exclusively by solar energy and rechargeable batter- ies. The goal is to achieve a viable public infrastructure with a practical application and environmental benefits. This makes it an economical, emission free and attractive means of transportation, namely for touristic purposes, since it can be used to establish the connection between urban centers and environmentally sensitive areas. Diesel trains are commonly used to transport passengers from ur- ban centers to leisure centers, namely beach shores. In fact this type of vehicle can be found on at least two beaches at the south of Portugal, namely Praia do Barril and Costa da Caparica. The primary application of the solar train would be to substitute these diesel trains and use the benefits of renewable energy allied to its non polluting characteristics to establish transport and still protect beaches ecosystem. Figure 1.1 shows an artistic impression of a solar train for tourism purposes, under the context of the project Helianto for a SPT.
2 (a) Perspective view.
(b) Side view.
Figure 1.1: An artistic view of the Helianto ultralight solar train.
To increase the vehicle autonomy, the train will also be equipped with regenerative braking and moving solar panels with an optimized energy capture, achieved by their automatic movement towards the sun. Figure 1.2 shows a simplified block diagram of the main components of the system (a detailed explanation is presented in Chapter 3).
3 Figure 1.2: Block diagram of the overall system.
The whole system is controlled by the supervisory controller block which receives as input, real- time information from the laser, weight sensor, solar panels and path following blocks. According to this information the supervisor acts on the speed and charge control blocks, which in turn provide the vehicle, motor and battery blocks the input control signals. This thesis intends to optimize energy onboard the train including the energy received from the solar panels and from the batteries, ensuring that the train reaches its final destination. In order to study and develop the DCS that manages the energy supply, all the components dealing with energy located: a) onboard the train; and b) located in the outside, namely at the stations and along the railway line; have to be modeled in the most realistic way. Modeling the overall system through Discrete Event Systems (DES) allows the supervisory energy management system to account for all relevant events. Moreover, DES have an elegant representation in the form of Petri nets (PNs), for which there are available powerful analysis tools.
1.3 Original Contributions
As a result of this thesis, a new simulation tool was set up in order to assess the feasibility studies concerning solar vehicle projects. This is a very practical tool that allows the simulation of multiple types of vehicles, multiple track features, different energy sources as well as different performance purposes for the vehicle. The tool supplies trustworthy results regarding project feasibility and required vehicle characteristics. The simulation environment used in this thesis was accomplished through Simulink/MATLAB and with the use of two key Matlab toolboxes: i) Netlab [4] allowed the design of a Petri net supervisory controller and the integration within Simulink and ii) QSS [5] which allowed the modeling of the dy- namics of the vehicle. Both have contributed to an efficient and realistic modeling of the solar vehicle.
4 1.4 Thesis Outline
The thesis is organized as follows. Chapter 2 presents a review of relevant work addressed in literature concerning the main topics. Chapter 3 discusses a possible infrastructure for a solar pow- ered train, together with some of the modeling options and dynamics involved. The tools used for the simulation are also described in this chapter. Chapter 4 presents a Petri net model of the overall system and the corresponding supervisory controller. Simulation results are discussed in Chapter 5, and the conclusions of the thesis are presented in Chapter 6.
5 6 2 State of the Art
Contents 2.1 Solar Powered Vehicles ...... 8 2.2 Discrete Events Systems and Supervisory Controllers ...... 12
7 This chapter presents relevant work available in literature and is divided in two sections. The first section presents work relating to solar powered vehicles and the second relating to discrete event systems and supervisory controllers.
2.1 Solar Powered Vehicles
Solar car racing refers to competitive races of electric vehicles which are powered by solar energy obtained from solar panels located on the surface of the car. The two most notable solar car distance races are the World Solar Challenge and the American Solar Challenge [6]. The objective of these competitions is to promote research on solar-powered cars. A variety of university and corporate teams enroll in these contests. Corporate teams participate in the races to give their design teams experience of working with both alternative energy sources and advanced materials. University teams participate in order to give their students experience in designing high technology cars and working with environmental and advanced materials technology. The World Solar Challenge is a solar powered car race which covers 3021 km through the Aus- tralian continent [7]. The race has a 20 year history, with the inaugural event taking place in 1987. Every year attracts about 20 teams from all around the world, most of which are universities or cor- porations such as TU Delft, University of New South Wales, Tokai University, and Honda and General Motors. In 2005, the Dutch team won this challenge for the 3rd time with a record average speed of 102.75 km/h over a distance of 3000 km, followed by the Australian (92.03 km/h) and the University of Michi- gan (90.03 km/h). The increasingly high speeds achieved in the 2005 race has led to the rules being changed for future solar cars, starting in the 2007 race. Major regulation changes were released for this race to increase safety, to build a new generation of solar cars, which with small alterations could be the basis for the proposal for sustainable transport and intended to slow down cars in the main event, which in previous years could easily exceed the speed limit (110 km/h). The winner in 2011 was the Japanese team with an average speed of 91.54 km/h. In figure 2.1 is possible to see some of the vehicles competing in World Solar Challenge.
(a) Race vehicles heading to- (b) The winner, Tokai University, (c) The Dutch winner of the wards the finish line (source: Japan of the 2009 World Solar 2005 World Solar Chal- [6]). Challenge (source: [7]). lenge (source: [6]).
Figure 2.1: Racing solar cars.
8 The solar contesting cars combine technology used in the aerospace, bicycle, alternative energy, and automotive industries. Unlike most race cars, solar cars are designed with severe energy con- straints imposed by the race regulations. These rules limit the energy used only to energy that is col- lected from solar radiation, although starting with a fully charged battery pack. As a result, it becomes a priority to optimize the design to account for aerodynamic drag, vehicle weight, rolling resistance and electrical efficiency. Solar cars use a range of batteries including lead-acid batteries, nickel-metal hydride batteries (NiMH), nickel-cadmium batteries (NiCd), lithium ion batteries, and lithium polymer batteries. The batteries store solar energy produced when the vehicle is stationary or traveling slowly or downhill. In order to do this the engines must allow regenerative braking, i.e., power is fed back into the battery during deceleration. A variety of solar cell technologies can be used: most often polycrystalline silicon, mono-crystalline silicon, or gallium arsenide. The cells are wired together into strings and in turn, strings are wired together to form a panel. The incidence of sunlight on a cell causes a voltage at the cell terminals. The total voltage produced by the panel is the sum of all connected cell series voltages, and is normally close to the nominal battery voltage. The power produced by the solar array depends on the weather conditions, the position of the sun and the capacity of the array; also the cell area should be maximized given the exposure surface. A typical panel has an efficiency of 20%, which means that only this part of solar energy is in fact transformed into electric energy. Aerodynamic drag is the main source of losses on a solar race car. For this reason it is important to reduce the vehicle frontal area as well as improving the dynamics of the exposed surfaces. The vehicle’s mass is also a significant factor. A light vehicle generates less rolling resistance and will need smaller lighter brakes and other suspension components. Rolling resistance can be minimized by using the right tires, inflated to the right pressure, correctly aligned, and by minimizing the weight of the vehicle. Efficient balancing of power resources and power consumption is the key to success during the race. A successful solar car racing team will need to have access to reliable weather forecasts in order to predict the power input to the vehicle from the sun during each race day. Furthermore, at any moment in time the optimal driving speed also depends on the remaining capacity of the batteries and other energy consumption parameters. The team members in the (normal) escort cars will continuously retrieve data remotely from the solar car about its condition and use this data as input for prior developed computer programs to work out the best driving strategy. It is equally important to charge the batteries as much as possible in periods of daylight when the car is not racing. To capture as much solar energy as possible, the solar panels are generally directed so that they are perpendicular to the incident sun rays. Often the whole car is tilted for this purpose. There have been several approaches to the implementation of control systems for vehicles running on limited energy sources. Energy management systems have been extensively studied in a multitude of applications. For example M. Godoy Simaes, N. N. Franceschetti, J. C. Adamowski [8] designed an advanced drive system control for a solar powered vehicle for racing purposes. This system extracts the maximum electrical power from a distributed solar array that covers the surface of the vehicle. The
9 energy transference is maximized by connecting each solar panel to a Maximum Peak Power Tracker (MPPT) that matches the panel impedance to the drive system. The ultimate goal for this vehicle is to achieve maximum average efficiency at the minimum weight. The average efficiency has to account for several external conditions such as road gradient and surface, predicted meteorological conditions and also the forces opposing motion, gravity, rolling resistance, and aerodynamic drag. The solar energy is either stored in an onboard battery or flows directly to the motor, according to the demand imposed by the driving. For a given stored energy in the battery and the prediction for a certain amount to be collected, the speed is set to be as close as possible to the optimum value. System monitoring is made through an on-board computer that monitors several variables and then sends them via radio link to a computer whose function is to manage all energy flux. The measurements of power on each solar panel, speed, torque and battery current are monitored by the on-board computer and then sent to the energy management computer. With this information it calculates how much charge is in the battery and based on a celestial sphere model, predicts the amount of power that each panel is delivering. This prediction is used to calculate the optimum average speed of the vehicle, aiming optimum energy management, it is also important to state that this speed is only valid for periods of stable weather conditions, which is evaluated by the team. In order to estimate the amount of available energy the following sequential procedure must be done: get geographical position coordinates, get local solar incidence reference, calculate the power on each panel, estimate the total energy captured for the route, estimate the stored battery energy, calculate the optimum speed for the route and finally keep track of the average speed. A study of energy management system of electric vehicles has been developed by Jinrui N, Fengchun S, Qinglian R in [9] in order to improve the energy management of an urban electric bus. According to these investigators, current electric vehicles comprise on-board energy generation, an energy storage system, and a driving system. The batteries used for energy storage are heavy, ex- pensive, maintenance requiring, and have much lower energy density than fossil fuels, so electric vehicles are constrained by performance and operational range. Since the vehicle operates with a very low power budget, an energy management system is required to control the flow of power and to maintain adequate reserves of energy in the storage devices. There are many structures of energy sources for electric vehicles that result from combinations between fuel cells, power batteries and super-capacitors. As a result of the study, and aiming to reduce the deep charge/recharge cycle and battery size it is best to use the combination super-capacitor plus battery. A super-capacitor is an electrochemical capacitor that has an unusually large amount of energy storage capability relative to its size when compared to conventional capacitors. The system proposed by the authors is composed by a power battery group, DC-link, capacitor power converter, super-capacitor, motor power converter, and traction motor. The load current of an electric vehicle varies greatly during acceleration and de- celeration and sometimes the load current exceeds the maximum charging or discharging current of the battery. The purpose of using a super-capacitor is to keep this current under proper limits and therefore improve the working condition of the battery and maintain its operational life. The control strategy of battery and super capacitor as energy storage devices depend on the capacity of the
10 super-capacitor. For instance if a large super-capacitor is used, the working current from the battery is almost unvarying during vehicle movement and together with the varying current from the super- capacitor provides enough power to the vehicle. Because of the high cost of large super-capacitors, there is the need to use advanced energy control strategies to control the charge/discharge criteria and its performance. For this it is necessary to access data such as working current and voltage of the battery, status of power battery group, initial status and working current of the super-capacitor, and the speed of the vehicle. A speed control strategy is important since speed determines the condition of the super capacitor in real-time. The super-capacitor should be fully charged when vehicle starts off and discharge for higher performance acceleration. As the vehicle reaches high speed there should be less energy stored in the super-capacitor so it can store regenerative energy during the breaking cycle and also during normal driving when traction battery is fully charged. The objective of the energy control strategy is to store appropriate amounts of energy in the super-capacitor to ensure that it is always working under the appropriate status. The calculations for this effect are based on the vehicle speed and depth of discharge. Through simulations, the performance of electric vehicles with super- capacitors was tested, and it was proven that they have a better performance than vehicles without it. The maximum speed with a super-capacitor is 96.17km/h and without it 68.77km/h. This happens because when accelerating, the super capacitor provides a very high rate of discharge, which the battery cannot provide. Also the average energy consumption is lower with a super-capacitor be- cause it can recover more braking energy with large current flows, while batteries can only recover a small amount of energy during regenerative braking. According to simulations the accelerating time and vehicle speed are also both improved with the super-capacitor. This shows that not only vehicle dynamic performance is improved, the working current of the battery is also reduced which lengthens its operational life. Concerning the subject of alternative energy sources powered vehicles: Renewables company Enfinity, along with Belgian rail infrastructure firm Infrabel installed 16,000 solar panels on the roof of a two-mile long rail tunnel [10] connecting Paris to Amsterdam by a high speed line. The project has a lifetime of 20 years. The tunnel was originally constructed to protect the forests by diverting trains through the mountains and also to protect the trains from falling ancient trees. Over two miles the solar panels are producing enough energy to power all the trains in Belgium for one day per year, in addition to provide around 50 percent of the energy used by the Antwerp station; this is approximately 3.5MWh of energy each year. While this two-mile stretch of solar panels will not power the whole line of trains, according to the company it is possible to consider the potential of running a whole high- speed rail line off the suns rays if there were tunnels located intermittently along the tracks. Figure 2.2 presents a top view of the tunnel:
11 Figure 2.2: Top view of Belgium solar train and tunnel (source: [10]).
According to Enfinity this green project was facilitated by the existence of the tunnel, since the toughest part about introducing new renewable energy projects is finding the right site to install them. Society offers resistance to wind turbines since they are visually polluting, and many people still prefer a slate roof to one covered with photovoltaic panels. For the Belgian train operators, apart from being a good opportunity to cut their carbon footprint because the tunnel had no other economic value, the project could also be delivered within a year since it did not attract the environmental protests that wind power does.
2.2 Discrete Events Systems and Supervisory Controllers
Systems of continuous and synchronous discrete variables have been the object of study of tradi- tional control theory. Cassandras has studied and described discrete event and event driven systems in [11]. As the scope of control theory is being extended into the domains of manufacturing , robotics, com- puter, and communication networks, there is the need to obtain models capable of describing systems that evolve according to the abrupt occurrence of physical events, at possibly unknown irregular time intervals. Such systems whose states change in response to events, are called discrete event systems (DES) and the corresponding models are called discrete events models. These dynamic systems require control and coordination to ensure the orderly flow of events. Thus it is necessary to use modeling tools capable of capturing the essential features of discrete, asynchronous and possibly non-deterministic systems. Petri Nets, also described in [11], are a powerful modeling tool that satisfies these requirements and have great descriptive power. They have been designed specifically to model systems with inter- acting components and as such are capable to capture many characteristics of event driven systems, namely concurrency, asynchronous operations, deadlocks, and conflicts.
12 S.Bogdan has established a connection between DES and manufacturing systems and in [12] details a matrix-based approach to the real-time application of control in discrete event systems and Flexible Manufacturing Systems (FMS) in particular. The algebra in which matrix operations are carried out enables fast and efficient calculations. Also matrix-based techniques are compared with Petri nets. In Petri nets, events are associated with transitions. In order for an event to occur, several condi- tions may have to be satisfied. Information related to these conditions is contained in places. Some places are viewed as the input to a transition: they are associated with the conditions required for this transition to occur. Other places are viewed as the output of a transition: they are associated with conditions that are affected by the occurrence of this transition.
A Petri net (PN) graph has three types of components: places pi, transitions ti, and weighted arcs w(pi, ti) connecting these and defining relationships between them. It is a bipartite graph in the sense that arcs cannot directly connect nodes of the same type; rather, arcs, labeled with their weight, connect place nodes to transition nodes and transition nodes to place nodes. A particular property that differentiates a PN from an ordinary graph is a marking m, which assigns a non-negative integer to each PN place.
A marking m(Pi) = l is characterized by l black dots (tokens) inside a circle representing place pi.
We say that pi is marked with l tokens. A marking vector m = [m(p1)m(p2)...m(pn)] represents a PN state, which means that the state space of PN with n places is described by all possible n-dimensional marking vectors. The capacity of the place is a property that refers to the maximum number of tokens that can be held by the place. If the maximum number of tokens in a place is k then we say the place is k-bounded. In Figure 2.3 it is possible to see the graphical representation of each PN component:
Figure 2.3: Graphical representation of PN elements.
Place pi is called an input place of transition ti if the weight of the arc connecting it to ti is positive
(w(pi, ti) > 0). The same holds for the input transition ti of place pi (w(ti, pi) > 0). A place that has no input transitions is called a source place, and the same for a source transition, which has no input places. A place or transition without output transitions and places, respectively, is called a sink. We say a transition is enabled if each input place is marked with at least w(p, t) tokens. An enabled transition will fire if the event that represents it occurs. In that case i) w(p, t) tokens are removed from each input place p of t, and ii) w(t, p) are added in each output place p of t. A Petri net graph is formally defined as follows,
PN = [P,T,I,O,M,m0],
13 where,
P = (p1, p2, ...pn) - a finite set of places,
t = (t1, t2, ...tm) - a finite set of transitions, I = P × T → (0, 1) - an input incidence matrix - relates places to transitions. O = T × P → (0, 1) - an output incidence matrix - relates transitions to places. M : I,O → (1, 2, 3...) - weight function,
m0 = (m01 ...m0n ) - initial value of the marking vector. Firing of transitions changes the Petri net state. The PN state evolves according to the PN State Equation:
T mk = mk−1 + W .t, where W = O − I is the PN incidence matrix and t is a transition vector composed by non-negative integers that correspond to the number of times a particular transition has been fired between current marking mk and previous marking mk−1. An example Petri net graph, with all weights set to 1, is defined as follows and represented in figure 2.4:
P = (p1, p2, p3, p4, p5),
t = (t1, t2),
−1 0 −1 0 W = O − I = 1 −1 0 −1 0 1
m0 = 1 1 0 2 0
Figure 2.4: An example of a PN graph.
Petri nets can be classified according to several properties. The ones focused by this thesis are: i) The concept of reachability in a Petri net refers to markings that can be reached from a given initial marking. A marking is reachable if it can be reached, given a determined transition firing sequence. If
14 it cannot be reached from any transition firing sequence, it is non reachable. ii) The notion of liveness is related with deadlock, i.e., a live PN is deadlock free. A deadlock corresponds to a marking from which no transition can be fired, locking the PN state evolution. Liveness guarantees that there is always a sequence that fires all transitions in the PN and therefore a live PN cannot get into deadlock. The concept of liveness leads to the concept of supervisory control. In manufacturing systems, one of the main concerns is to avoid deadlock situations on the processes. For this reason supervisory control is applied to PN which are not live, in order to prevent deadlock situations. Supervisory control is studied by S. Bogdan in [12] and by Cassandras in [11]. A description on the methods of supervisory controllers synthesis followed in this thesis can be found in chapter 5. Les Warrington and Jeffery A.Jones studied the representation of complex systems within Discrete Event Simulation. On their paper [13] it is discussed the design of a high fidelity discrete event simulation of aircraft reliability and maintenance, with the objective of modeling the complex system functionality and control of the associated state-space. Some modeling techniques such as Markov chains, Petri net, fault tree, event tree and Reliability Block Diagram (RBD) are reviewed and each computer and storage requirements compared. The paper focus on the memory efficiency of each method. Path and cut-sets, derived from Fault Tree, Event Tree or Reliability Block Diagram (RBD), were identified to be the most efficient computer representations but can only model static systems. In order to allow dynamic conditions to be analyzed they would have to be converted to a Markov chain or Petri net representation. A static system is one which does not respond in situations of component failure or other conditional system property. The alternative is a dynamic system, which can be modeled by one of the other methods, Petri nets or Markov chains and performs a richer analysis since they are able to represent every potential state of the system. The paper proposes a method that integrates methods such as Petri nets or Markov chains with path-sets to allow dynamic system modeling and still benefit from high computational efficiency. It was observed that there are parts of the system where its behavior is strongly dynamic and in that case a rich analysis method such as Petri nets or Markov chains is more appropriate. However the demonstrated memory efficiency of path sets makes them more suitable for systems with mostly static properties. It was concluded that it is possible to model systems with path sets and allow the use of petri nets or Markov modeling in specific dynamic areas of the system. For large systems, path-set representation rapidly becomes more efficient in storage requirements, even when Petri nets and Markov are used in some parts. This methodology permits to extend the efficiency of path-sets and was successfully incorporated into the working system. Discrete event systems modeling and simulation tools have also been studied by Reggie Davidra- juh in [14]. This paper describes development of a new Petri net tool called General Purpose Petri Net Simulator (GPenSIM) that is designed to facilitate modeling, simulation, and performance evaluation of discrete event systems. In this paper the author compares other modeling tools and explains his preference for Petri nets. Automata, State flow, and Petri nets are stated by the author as well-known tools to simulate discrete event systems. According to the author, although automata has a strong us- age in computer science it lacks structure and because of that it is unable to decompose a system into
15 modules. State flows are similar to Petri nets and it is easy to convert models from and to both repre- sentations, however it is much harder to learn State flow than Petri nets due to its syntactic, semantic, and graphical details. Besides, State flow also requires some knowledge of Simulink in addition to Matlab. Petri nets are widely accepted by science community for modeling and simulation of discrete event systems. This happens mainly due to its rigorous modeling techniques and because there is a number of Petri net tools available free of charge for academic usage. These are sophisticated tools flexible enough to model complex and large systems. Supervisory control systems have been discussed in [15]. In this work the main features of sev- eral modeling techniques are demonstrated, by applying them to a simple example and comparing the features of those models. The models tested are Markov chains, Petri nets, queuing networks, automata and finite-state machines, finitely recursive processes, min-max algebra and discrete simu- lation, and generalized semi-Markov processes. Because different models possess different features and are most suitable for different purposes, the properties of these models cannot always be shown to their maximal advantage by applying all these models to one standard example. The standard example consists in a simple production line with two machines in tandem with one buffer storage in between and an infinite supply of raw material (at the input of the first machine. After analyzing the control system obtained by each model, the authors classified them in two major categories: timed and untimed models. The untimed models, such as the finite-state machine model, untimed Petri net, and the finitely recursive process model, emphasize the state sequences and the event sequences of a discrete event system and ignore the timings of a system in every state. These models can primarily answer questions of a qualitative or logical nature, for example, as whether it is possible to control a discrete event system such that its state sequences or event sequences fall into a desirable set (finite-state machine model) and whether there are any deadlock loops in a system (Petri net model). The timed models, such as the Markov process model, queueing networks, and the generalized semi-Markov processes model, are mainly used to answer performance related questions such as system throughput and mean process time. The min-max algebra approach applies mainly to systems with deterministic event, and the Petri net model is more suitable for modeling systems with interacting concurrent components such as computer systems.
16 3 Vehicle Modeling and Simulation Environment
Contents 3.1 System Overview ...... 18 3.2 Vehicle Performance Analysis ...... 20 3.3 Vehicle modeling: QSS toolbox ...... 23 3.4 DES Modeling: Netlab toolbox ...... 36
17 This chapter is composed by three sections. The first presents a system description, including vehicle characteristics and key options and definitions for the energy management system. The sec- ond presents the QSS toolbox including an analyses on the motion dynamics of a vehicle and the main energy consuming effects considered by the DCS. Finally, the third section presents the Netlab toolbox.
3.1 System Overview
A key assumption of the project is that the topology of the track is known. Also, several stations are placed along the track at known locations. The train uses GPS and the information on the topology of the line, eventually with a selection of landmarks placed along the line, for pinpoint positioning accuracy. Obstacle detection sensors, e.g., laser range finders, are also placed on the frontal area of the train. Each station is equipped with a gate through which the passengers must go through to access the train. The gate system keeps count on how many people are in the station waiting for the train. Moreover, weight sensors at the gate floor allow an estimate of the total weight to board the train at each station. In general, the weight of the train will be much larger than that of the passengers. However, for the sake of completeness, the approach in this thesis accounts for this variable. The energy management system uses information from all energy sources and sinks and also from all the environment conditions. For example, an internet connection is used to access short term weather forecast services, if available, for the region where the train is operating. Its main function is to determine whether the mission can be accomplished considering the amount of energy available and if not, it determines the amount of energy to be charged in the stations so that the train arrives safely at the final destination. The train must be able to reach its destination relying only on the energy that comes from panels and batteries. If necessary it may recharge the batteries at each station. The engine is also equipped with a regenerative braking system that, when activated, recharges the batteries, contributing to en- ergy optimization. The range of velocities achieved by the train depends on the amount of power reaching the en- gine and therefore the power delivered by the solar panels is a fundamental factor that affects the performance of the train. Consequently, it is necessary to study the power/speed relation in order to determine a range of power that should be reaching the engine in order to define the range of velocities for the train. Several contingency situations must be considered by the control system: low irradiance prevent- ing the panels from delivering power, obstacles in the line, loss of satellite signal, weather and weight changes, and communication failure, for example, when receiving weather forecast or any other nec- essary variable. Proposed solutions for these situations are described later in this section. On a first approach, the amount of energy available must be estimated for the whole trajectory, this will allow the energy management system to determine if the mission will be carried out successfully and whether it is necessary to recharge the batteries. In case the train has already performed at
18 least one round, it is possible to use that information to estimate the available energy based on past experience. The accuracy of the energy estimate is expected to increase along with the number of round trips performed. It is necessary to keep a safe energy reservation that can support and deal with unpredictable situations such as obstacle avoidance, communication failure, and weight and weather changes. Therefore, the batteries must always be charged with a minimum value. This can be accomplished by a charging combination through the external sources (at the stations) and solar panels. The capacity of batteries should be such that it allows the train to move between two stations exclusively on batteries. This is a minimum requirement that will allow the train to reach the next station even if the solar panels are not operating properly, so that the passengers do not get stranded between stations. The energy management keeps direct communication with the laser range finder sensor and path following system. This communication is established to ensure that the system updates energy state variables as the train approaches a station and in the occurrence of urgent braking, for example when the laser sensor detects an obstacle on the tracks. When the brakes are active, the system needs to take into account the extra energy spent in motor startup and also the energy generated through regenerative braking. The figure below presents the block diagram for the overall system.
Figure 3.1: Block diagram of the overall decision and central system.
The system is essentially composed by four types of blocks. The first group of blocks is composed by the laser range finder, weight sensor, solar panels and track topology blocks. These blocks provide essential information to the system and cannot be controlled. The laser block communicates the supervisory controller the detection of any obstacle on the track. Thus the supervisory controller may act accordingly. The weight sensors are placed in each station gate, in order to weigh each passenger that enters, and therefore hold current record of weight at each station. It is also possible to know the destination of each passenger through the ticket, and therefore a weight estimation for each trunk can be obtained. Thus the supervisory controller has the information of the weight the train is required to carry in each trunk. The solar panels communicate directly to the supervisory controller the instantaneous
19 amount of power delivered. Based on this information the supervisory controller acts on the cruise velocity of the train, allowing only a velocity supported by the panels and within bounds. Lastly, the track topology block does not communicate directly with the supervisory controller but with the location tracking block. It contains the information concerning track topology such as length and slopes. The second group of blocks is composed by the vehicle, electric motor and battery blocks. These blocks simulate the dynamic behavior of each representative element and are provided with input variables which are controlled by the supervisory controller. The vehicle block receives input from the velocity control, which basically defines the velocity at which the train is required to move. It outputs the torque that is required in order to sustain that velocity. The electric motor on the other hand re- ceives input from the vehicle block, which corresponds to the torque that is required from the motor. In its turn, the motor communicates the battery the power it requires to sustain the torque. The battery receives as input the power the motor requires and delivers the requested power. Yet it is controlled by the battery charging control block which controls all discharges and charges occurring in the battery. The third group of blocks is composed by the location tracking, battery charging control and velocity control blocks. These blocks are controlled by the supervisory controller and provide the input values to the vehicle, motor and battery blocks.
The location tracking block holds information on the track topology, and along with the current velocity of the train and GPS signal, it determines its real-time location. As the station locations are already defined, by knowing the current velocity it is possible to determine the precise location where the vehicle is required to begin braking in order to stop at the right location. This location is further communicated to the supervisory controller. This track topology block also holds information concern- ing the gradient of the road at each location. Thus the supervisory controller has a priori information on the energy demand for each trunk which affects the velocity defined for that same trunk. The velocity control block communicates in real-time to the vehicle block the required velocity for the train. This block is controlled by the supervisory controller which defines a suited velocity according to the current location, laser range finder, weight carried and road gradient. The battery charging control block is also controlled by the supervisor and maintains real-time communication with it. The main function of this block is to make sure the battery charge never drops below the minimum functional value and also that a minimum previously specified charge value is always ensured, before the train leaves any station.
3.2 Vehicle Performance Analysis
In this section the dynamics of the longitudinal motion of a vehicle is analyzed as well as the main energy consuming effects occurring in the vehicle. In order to induce motion in a vehicle, a traction force Ft must be delivered by the engine, in order to overcome the resisting forces. A moving vehicle is acted by the following resisting forces [16]:
20 • Aerodynamic Drag force Fd
• Rolling Resistance Fr
• Gravitational Force Fg
• Inertial Forces Fa
The elementary equation that describes the longitudinal dynamics of a vehicle, derives from New- tons’ second law, and has the following form:
d m v(t) = F (t) − (F (t) + F (t) + F (t) + F (t)), (3.1) v dt t d r g a where Ft corresponds to the traction force generated by the motor, mv the vehicle mass, and v(t) the speed. The balanced force that generates motion corresponds to the traction force minus the sum of the resisting forces. The forces acting on the vehicle are shown in the figure below:
Figure 3.2: Schematic representation of the forces acting on a vehicle in motion (source: [16]).
3.2.1 Aerodynamic drag force
The aerodynamic resistance force Fd acting on a vehicle in motion, is the result of viscous friction of the surrounding air on the vehicle surface and the pressure distribution on the air over the body. This resistance is mainly caused by the vehicle body, but other items such as wheels, external mirrors or engine ventilation may also contribute. Usually this force is approximated by considering the vehicle to be a prismatic body with a frontal area Af and it is given by:
1 F = .ρ.A .C .v2, (3.2) d 2 f d where v is the vehicles speed, ρ is the air density and Cd is the aerodynamic drag coefficient that models the flow conditions. This parameter can be estimated by experiments in wind tunnels and may be assumed to be constant for energy requirement estimations [16].
21 3.2.2 Rolling resistance
The rolling friction force can be modeled as:
Fr = Cr.mv.cos(α), (3.3) where mv is the vehicle mass and g the acceleration due to gravity. The term cos(α) represents the influence of a non-horizontal road. The rolling friction coefficient Cr depends on many variables of which the most influential are the vehicle speed, the wheels, and the road surface. Vehicle speed has a small influence at lower speeds but its influence increases substantially when it approaches a critical value. Any moving wheeled vehicle will gradually slow down due to rolling resistance, but a steel wheeled train will roll much further than a bus with the same mass and rubber tires. This can be explained since the rolling coefficient is much higher for tires than for steel wheels. The table bellow presents typical coefficients for different type of wheels and surfaces:
Table 3.1: Typical rolling coefficients (source [1]).
Rolling Resistant Coefficient (c) Wheels and Surfaces 0.001-0.002 railroad steel wheels on steel rails 0.002-0.005 low resistance tubeless tires 0.005 dirty tram rails 0.006-0.01 truck tire on asphalt 0.01-0.015 ordinary car tires on concrete 0.03 car tires on tar or asphalt 0.04-0.08 car tire on solid sand 0.2-0.4 car tire on loose sand
For many applications, particularly when the vehicle speed remains moderate, the rolling friction coefficient Cr may be assumed to be constant. This simplification is adopted in this thesis.
3.2.3 Gravitational force
The gravitational force is induced by gravity when driving on a non-horizontal road and depends on the slope of the road. According to Figure 3.2, the force is positive when the vehicle travels on an uphill section and negative on a downhill section. It is modeled as:
Fg = mv.g.sin(α), (3.4) where mv is the total mass of the vehicle, g is the gravitational acceleration and α is the gradient angle in the horizontal plane.
3.2.4 Inertial force
The inertia of the vehicle and all rotating parts inside the vehicle causes fictitious forces. Equation (3.1) already accounts for the inertial force induced by the vehicle mass but not the inertia associated with the rotating masses. The rotating masses can be considered for calculations by adding its inertia
22 to the vehicle mass. Two different rotating masses are considered in this calculation: the wheels and the engine, composed by motor and transmission. The inertia torque associated to the wheels is given by:
d T (t) = I . .w (t) (3.5) w w dt w where Iw is the inertia of the rotating parts and ww is the rotational speed. This torque acts on the vehicle as an additional inertia force
Tw(t) Fw(t) = (3.6) rw where rw is the wheel radius. The wheel slip is not considered, i.e., v = rw.ww. and in this case,
Iw d Fw(t) = 2 . .v(t) (3.7) Iw dt Consequently the contribution of the wheels to the vehicle overall inertia is given by the following term
Iw mw = 2 (3.8) rw The same can be applied to the rotational parts of the engine assuming a constant gear ratio γ and a gear box efficiency of 100%,
d γ d Fw(t) = Ie. .(γ.ww(t)) = Ie. . .v(t)) (3.9) dt rw dt
γ γ2 d Fe(t) = .Te(t) = Ie. 2 . .v(t)) (3.10) rw rw dt
γ2 me(t) = 2 .Ie (3.11) rw
The equivalent mass of the rotating masses, me and mw should then be added to the vehicle mass in (3.1) as to include inertial effects on the vehicle motion.
3.3 Vehicle modeling: QSS toolbox
QSS is a Matlab/Simulink toolbox developed by ETH in Zurich (Swiss Federal Institute of Technol- ogy Zurich) [5]. It is a collection of Simulink blocks and m-files freely available for academic purposes. The QSS toolbox makes it possible for powertrain systems to be designed quickly and in a flexible manner and to easily calculate the energy consumption of such systems. Due to the extremely short CPU time it requires (i.e., on a regular PC, a speedup factor of 100 to 1000 for a conventional pow- ertrain), a QSS model is ideally suited for the optimization of the energy consumption under various control strategies [17]. QSS is a discrete tool, meaning calculations are performed at discrete time steps, and follows an quasistatic approach [16]. The quasistatic approach is a method used for the
23 prediction of energy consumption and the basic concept behind it is to reverse the cause-and-effect behaviour of dynamic systems. Rather than calculating velocities from given forces, based upon given velocities (at discrete times), the toolbox calculates accelerations and determines the corresponding forces.
3.3.1 Quasistatic Approach
In quasistatic approach the input variables for each step time are the velocity v(t) and the accel- eration a(t) of the vehicle, as well as the gradient of the road. These variables are assumed to be constant for each time step, which corresponds to one second. The force and torque required to be acting on the wheels are then computed, in order to drive the required input velocity and acceleration profile for a vehicle described by its main parameters (Af ,Cd,Cr, mv). The determination of the trac- tion force is accomplished by a discretization in time of the velocity and acceleration profile. These variables are defined for the given time instants v(ti) = vi; a(ti) = ai, ti = i.h, i = 0, ..., n. Accordingly, the traction force is computed for the average velocity and acceleration,
v + v v(t) =v ¯ = i i−1 , ∀t ∈ [t , t ] (3.12) i 2 i−1 i
a + a a(t) =a ¯ = i i−1 , ∀t ∈ [t , t ] (3.13) i h i−1 i where h = 1, for a one second step time. The basic equation used to evaluate the force required, in each second, to drive the profile is derived from (3.1),
F (ti) = mv.a¯i + Fd,i + Fr,i + Fg,i + Fa,i (3.14) using the expressions obtained in (3.2), (3.3) and (3.4) the force can be obtained by
1 F (t ) = m .a¯ + .ρ.A .C .v2 + C .m .cos(α ) + m .g.sin(α ) (3.15) i v i 2 f d i r v i v i
The rotating parts can be included by adding the masses mw and me, obtained in (3.8) and (3.11) respectively, to mv. The energy consumption necessary to sustain a determined torque and speed combination is directly mapped to the torque-velocity plane. Using the quasistatic approach it was possible to design a supervisory control system that opti- mizes the power flow in the propulsion system and the numerical effort is relatively low. The overall energetic predictions given by this method are accurate when compared with experiments on engine dynamometers. A simplified block diagram of a generic quasistatic simulation is presented in figure 3.3 and the respective variables are described throughout the next sections :
Figure 3.3: Generic Diagram of Quasistatic Approach (source: [16]).
24 Figure 3.4 shows the top level QSS library.
Figure 3.4: QSS library.
QSS library is composed by several simulation blocks each one concerning different functions such as driving pattern, vehicle, type of engine, gear system and energy source. In this simulation, the vehicle block is used to simulate the train and the electric motor block is chosen for the type of engine used. The gear system is composed by a simple transmission block and the energy source is a battery. The next sections describe each one of the blocks to be used in the simulation.
3.3.2 Vehicle block
The vehicle block includes the train specifications such as the overall weight, wheel diameter, frontal area, and friction, and aerodynamic coefficients. The input variables to this block are the train velocity and acceleration at each time step, and the output variables are the rotational velocity, acceleration, and the torque at the wheels. The main function of this block is to determinate the required torque, such that the velocity and acceleration requirements for the train are met. The torque is given by,
T (ti) = r.F (ti) (3.16) where F (ti) is the traction force given by (3.15). Equation (3.15) includes the contribution of all resistant forces such as aerodynamic drag, rolling resistance force, gravitational force and inertial forces. Thus, it is necessary to define friction and aerodynamic coefficients and rotating mass. These parameters can be defined in the vehicle block user interface presented in annex A.1. The rotating mass is considered a mass percentage value to simplify the calculations for inertial forces. Its contribution is measured by adding this value to the overall vehicle mass, as explained previously. Originally this block did not consider the road gradient for the calculation of the traction force. However, for this thesis, road gradient is an important factor to be analyzed in the simulation and therefore its contribution was added to the model through equation (3.4). The figure bellow shows the masked and unmasked vehicle block, where the added contribution of road gradient is evidenced in bold:
25 (a) QSS masked vehicle block.
(b) QSS unmasked vehicle block.
Figure 3.5: QSS vehicle block.
3.3.3 Electric Motor
The electric motor model is a single block whose inputs correspond to the demanded torque T (t) and rotational velocity ω(t). The output is the required electric power PEM at the motors DC link. A positive value of PEM is absorbed by the machine operating as a motor, a negative value is delivered by the machine working as a generator. Two operating modes are considered for the electric motor and they are respectively represented on two quadrants. The first quadrant represents the machine operating as a motor, when both torque and rotational velocity are positive. The electric power required by the motor in this case, can thus be expressed as follows:
1 PEM = ωEM .TEM . , ωEM > 0; TEM > 0 (3.17) ηEM (ωEM ,TEM )
26 The second quadrant represents the machine operating as generator when the rotational velocity is positive and torque is negative. The electric power delivered is expressed as follows:
PEM = ωEM .TEM .ηEM (ωEM ,TEM , ωEM ) > 0; TEM < 0 (3.18)
The third and fourth quadrant, for which the rotational speed is negative, are not considered since reverse movement is not relevant for the energy consumption determination. The efficiency can be obtained through a stationary efficiency map, defined for the first quadrant
(ωEM > 0; TEM > 0), as a function of the torque and rotational velocity. To avoid distinguishing between (3.17) and (3.18) the efficiency map is extended to the second quadrant by mirroring the efficiency, assuming that
1 ηEM (ωEM , −TEM ) = (3.19) ηEM (ωEM ,TEM ) By combining both efficiency maps, the electric power can be obtained by (3.18) in both operating modes. The generator mode is described by the lower half of the map and the motor mode by he upper half. The efficiency map obtained, as a function of rotational speed (rad/s) and torque (N.m) is shown in figure 3.6.
Figure 3.6: Electric motor efficiency map (source: [16]).
27 It is possible to see in the efficiency map that there are maximum values for torque and rotational velocity beyond which the motor does not operate. The electric motor block has a supervisory sub- block that terminates the simulation in case these variables exceed the maximum value allowed, in order to prevent overload and overspeed situations. The figure bellow shows the masked and unmasked electric motor block.
(a) QSS masked motor block.
(b) QSS unmasked motor block.
Figure 3.7: QSS motor block.
28 The vehicle block interface allows the definition of the motor scale factor, which is related to the maximum power delivered by the motor, the motor inertia, and the power required by auxiliaries. The interface is presented in annex A.2.
3.3.4 Battery
The battery is simulated by a single block with two inputs and two outputs. The block includes specifications such as the battery nominal capacity, initial charge and maximum current flow. It is possible to define them in the blocks interface presented in annex A.3. The first input corresponds to the electric power flowing into the battery. Depending on the motors operating mode the power can be positive, discharging the battery, or negative when charging the battery. If the power at the input is null then the battery remains at idle mode. The second input corresponds to the distance traveled by the vehicle. This value is used to output the energy consumption per kilometer until the current instant. The other output corresponds to the current battery charge. The model calculates the battery charge by integrating the power flowing into the battery. The maxi- mum current specification sets physical limitation to the amount of power entering the battery, when charging. In case this value is exceeded, the simulation is terminated. In the opposite situation, when the battery is discharging, the current is limited by the internal resistance of the battery. This model is only valid for normal operating range of the battery, i.e., between approximately 10 and 90% of the nominal capacity. Outside this range strong nonlinear effects may be observed and also the battery longevity or efficiency can be affected. During the vehicle acceleration phase, the battery can be subject to high peaks of energy demand which either overload it or are the reason for a vehicle to be equipped with unnecessary large batteries. This situation may be avoided by using super-capacitors which are able to attain very high power densities. Although the energy density is moderate, they are ideally suited to provide high peaks of energy demand. Together with batteries, the supercapacitors contribute to a lower battery weight and an efficient use of energy. Figure 3.8 bellow shows the masked and unmasked battery block.
29 (a) QSS masked battery block.
(b) QSS unmasked battery block.
Figure 3.8: QSS battery block.
3.3.5 Gear System
The gear system is simulated by the simple transmission block which provides the transmission of mechanical work between the vehicle and the electric motor. In this block, fixed and ideal relationships are set between torque and rotational velocities. The losses of this system are described by
Pout = ηgear.Pin − P0 (3.20)
where Pout and Pin represent the power leaving and entering the system respectively and P0 the idle speed losses. Through the blocks interface (annex A.4) it is possible to define specifications such as the gear ratio, efficiency of the system and idling losses. Figure 3.9 shows the masked and unmasked simple transmission block.
30 (a) QSS masked simple trans- mission block.
(b) QSS unmasked simple transmission block.
Figure 3.9: QSS simple transmission block.
3.3.6 Application Example
In order to illustrate some of the applications where this toolbox has proven to be useful, a basic example is presented. This example corresponds to a Simulink model composed by those QSS elements included in the solar train simulation, described on the previous sections. All parameters defined for each block are based on QSS toolbox examples. The goal is to simulate the behaviour of a vehicle, equipped with an electric motor and running exclusively on batteries. The model is composed by the vehicle, electric motor, simple transmission gear system, and battery blocks. In order to define a driving cycle for the vehicle, another block is added to the model: the driving cycle block. The purpose of this block is to define, for each time step, the velocity and acceleration profile for the vehicle. The top level of the application example model is shown in figure 3.10.
31 Figure 3.10: Top level Simulink model of a basic QSS application.
The driving cycle block interface (see annex A.5) provides the user with a selection of several pre- defined driving cycles for different types of vehicles. Once the user chooses a driving cycle, the block loads the cycle data such as time, velocity and acceleration, from the specified data file and makes it available on the output of the cycle block. QSS presents a variety of data files with different driving cycles, each one intended for different types of vehicles. The list of driving cycles provided by QSS are listed in figure 3.11:
Figure 3.11: List of driving cycles data files provided by QSS.
For instance, the driving cycle of a high speed train reaches high velocities and accelerations while a city car holds lower values. Thus the driving cycles associated with each of these vehicles are different. The driving cycle selected for this specific example takes into account the nature of the vehicle and the expected range of velocities. It is convenient to illustrate a variety of phases including acceleration, steady velocity, and deceleration phases, and analyze the behavior of each element of the model. For this purpose the chosen driving cycle is Europe-City obtaining the velocity profile shown in figure 3.12. The definition of a velocity profile implies a time restriction, by which the simulation stops automatically at the end of the driving cycle. The parameters defined through the driving cycle user interface are resumed in Table 3.2:
32 Table 3.2: Driving cycle block.
Parameter Value Cycle Europe-City Step size (s) 1 Enable automatic simulation stop ON
The vehicle block outputs the torque based on the velocity profile and the parameters defined through the user interface are resumed in Table 3.3:
Table 3.3: Vehicle block.
Parameter Value Total mass of the vehicle [kg] 3500+500 Rotating mass [Kg] 5 Vehicle cross section [m2] 3 Wheel diameter [m] 0.5 Drag Coefficient [-] 0.22 Rolling friction coefficient[-] 0.008
The total mass of the vehicle corresponds to the actual structure mass (3500 Kg) plus an extra half tonne mass, which corresponds to the batteries. This value was set specifically for this example so the driving cycle can be sustained exclusively by the batteries. It was considered an average energy density of 70 Wh/Kg, which leads to a charge capacity of 35 kWh. The battery specifications are presented in table 3.4.
Table 3.4: Battery block.
Parameter Value Energy capacity of battery [Kwh] 35 Initial charge of battery (%) 90 Minimum time to charge/discharge [min] 20
The electric motor is scaled up by a factor of 11 (in both quadrants), which means that it can deliver a maximum power of approximately 45 kW. This corresponds to the maximum power required to perform this driving cycle, so the scale factor must not be lower. The electric motor is coupled to the wheel at a fixed gear ratio. The gear ratio selected was 3. The parameters defined for the gear and motor blocks are summarized in tables 3.5 and 3.6 respectively.
Table 3.5: Electric Motor block.
Parameter Value Motor scaling factor[-] 11 Motor inertia[Kg.m2] 0.1 Auxiliaries power[W] 0
33 Table 3.6: Simple transmission block.
Parameter Value Gear ratio 3 Efficiency [-] 0.98 Idling losses (friction [W]) 50 Speed beyond which losses are generated [rad/s] 1
According to the presented parameter definitions for each block, a simulation of the example model shown in 3.10 was performed. The results are presented in figures 3.12, 3.13 and 3.14. All plots are presented as a function of time.
Figure 3.12: Velocity profile and distance covered along the Europe - City driving cycle.
34 Figure 3.13: Acceleration and power required by the motor during the driving cycle.
Figure 3.14: Battery charge curve during the driving cycle.
Figure 3.12 shows the covered distance and velocity profile assigned to the vehicle through the selected driving cycle Europe-City. It is possible to see that the Europe-City driving cycle is composed by three distinct phases. The first corresponds to an acceleration phase, until the vehicle reaches 15 km/h, then the vehicle maintains the speed, and lastly the vehicle decelerates until it stops. The second phase is very similar except for the cruise speed that rises to 32.5 km/h. The third phase
35 is also similar, except that the cruise velocity goes from 50 to 35 km/h and only then the vehicle stops. In figure 3.13 the power curve required by the motor during the driving cycle is presented. The acceleration values are also presented since there is a direct dependency between them and the power curve. The results are according to the expected operational behavior of a motor. During acceleration phase the required power curve has a peak, which increases with velocity. When the velocity stabilizes also does the power. The higher the velocity, the higher is the required power to sustain it. If the acceleration is negative, which means the vehicles brakes are active, the power curve has a negative peak. This means the motor is regenerating energy and storing it in the battery. The battery charge curve is presented in figure 3.14 and evolves according to the power curve. When the power required has a peak, the battery charge drops, delivering the power peak necessary to sustain the acceleration phase. Whenever the power curve is constant, during cruise velocity phase, the battery charge falls approximately linearly with time. If the power required is negative, the battery charge rises, accordingly to the occurrence of regenerative braking phase.
3.4 DES Modeling: Netlab toolbox
The train system is represented by a Petri Net model ruled by specific events that can occur in the system. The model corresponds to a sequence of states that follow a determined order and the state transitions are commanded by the occurrence of events. The tool used to design the Petri Net model was Netlab. Netlab is a Windows interface that allows the design and graphical simulation of Petri Nets. This tool also has an interface with Matlab Simulink which allows the Simulink to import the Petri Nets created in Netlab as a single block. In combination with Simulink, the Petri Nets can be extended with input and output places. When a place is set as an input, its marking is determined by Simulink and if it is set as an output, its marking is transferred to Simulink. This establishes a direct real-time communication between the Petri Net and Simulink. Netlab Windows interface itself allows the graphical simulation of Petri Net models, but during the simulation, transitions are set manually and the occurrence of these events can only be set by the user. The Simulink interface is therefore valuable since it allows the occurrence of events to be determined by an external model, designed in Simulink, and then sent to the Petri Net, which makes the simulation more realistic.
3.4.1 Describing the Windows Netlab Interface
The Windows Netlab interface is used to design the Petri Net. After designing the net it is possible to simulate its state progress by activating manually each transition, when enabled. The number of tokens in each place is visible and also the transitions enabled at each state. The simulation respects all basic rules of Petri Nets as described in [11] and [12]. There are several symbols available in Netlab library: place, input place, output place, transition, arc, and bidirectional arc. All symbols are illustrated in figure 3.15.
36 Figure 3.15: Netlab Library.
A comparison between Netlab symbols and common PN element symbols can be made through figure 3.15 and 2.3. Netlab input and output places do not appear in a common Petri Net language, but when it comes to the Petri Net rules they work just like a common place. The differences are detailed below. All places in the net are attributed with a capacity which corresponds to the maximum number of tokens allowed in the place. When a place reaches its capacity all events that preceed it are disabled, which means the transitions that preceed it cannot fire. An input place differs from a place since its marking is given by an external signal, namely by Simulink. The rounded value of the input signal will correspond to the number of tokens in the respective place in the net. The marking of an output place is independent from any external signal, it is given by the Petri Net. The only difference between an output place and a place is that its marking is transferred to an external signal in Simulink. The communication between the Petri Net and Simulink is in real-time.
3.4.2 Describing the Simulink interface
Netlab has its own library in Simulink which is composed by three blocks: Netlab block, display place pass through, trigger place source, and display place sink. The blocks are shown in the figure below.
Figure 3.16: Simulink Netlab toolbox Library.
The Netlab block allows Simulink to import a Petri Net and represent it in a single block which can be used in a Simulink model. The block representing the Petri Net has as many inputs and outputs as defined in the net, respectively as input and output places. The block is configured with only one input and one output so the input/output signals must be connected to a bus. The pass through block is the representation of a Petri Net place in Simulink. It assumes and displays the rounded input signal as the number of tokens and it cannot exceed its capacity. It is configured with only one input and one output, which corresponds to the current number of tokens. The source block allows manual triggering of the places marking, which is equivalent to the output signal, changing output value from 0 to 1 and vice-versa. The sink block displays the rounded input signal like a place, and it cannot
37 exceed its capacity.
3.4.3 Example of integration of a Petri Net in Simulink:
A simple example is shown below for a Petri Net imported from Netlab to Simulink and its interac- tion with the input and output signals. The Petri Net represents the most basic model of a train and it has three states: Start, Moving, and End. The net is represented in the figure below.
Figure 3.17: Basic model of a train.
From the Start state it is possible to go to the next state Moving and from this one to the last state End. The three state transitions are set by three events, 1, 2 and 3. These events are determined by Simulink and therefore it is necessary to add 3 places in Netlab to allow communication between Netlab and Simulink. The new net is described in the figure below:
Figure 3.18: Basic train model imported to Simulink.
As seen in figure 3.18 three places were added to the net with the purpose of setting the state
38 transitions and allow the progress of the system:
• Event StartMode Finished sets the transition from Start to Moving state.
• Event Moving Finished sets the transition from Moving to End states.
• Event End Finished sets the transition from End to Start states.
These three events are determined by simulink and each one of them is set according to the duration of each state. It is possible to see in the figure that each state has a specific duration. For instance Start state lasts for 2 units of time, so the event StartMode Finished will only be set 2 units of time after Start state is activated. The same thing happens to the other events, Moving Finished is set after 4 units of time, after Moving state activation and EndMode Finished is set after 2 units of time, after End state is activated. These timing rules allow an easier analysis of the progress and sequence of events of the Petri Net, along simulation time. The Simulink model where the Petri Net is represented is shown in the figure below.
Figure 3.19: Model in Simulink.
It is possible to see in the figure 3.19 that the Petri Net has 3 input places and 3 output places. The output places correspond to the states of Moving, Start and End. The input places correspond to events that set the state transitions StartMode Finished, Moving Finished and EndMode Finished. The signals that define the number of tokens in the input places are passed on to the net through the input bus and the signals generated by the output places are passed on to Simulink through the output
39 bus. The blocks Moving Processing and Start End Processing delay the activation of the events, for the specific duration of each state. The results of the simulation are shown in the figure below for a simulation time of 50 units of time.
Figure 3.20: Simulation results.
Each one of the graphics above represents the number of tokens in each state along time. The first shows the number of tokens in place Start. It is possible to see that it remains with one token for 2 units of time and after that remains with 0 tokens for 4+2 units of time. The second graphic represents place Moving and it remains with one token for 4 units of time and with 0 for 2+2 units of time. Lastly the third graphic represents place End and remains with one token for 2 units of time and with 0 for 2+4 units of time. These results are consistent with the structure of the model. The tokens pass on from the place Start to the place Moving and finally to place End remaining in the places for respectively 2, 4 and 2 units of time. Below it is shown a graphic of the number of tokens of the three places overlapped and with an offset. That allows a better understanding of the time sequence:
40 Figure 3.21: Simulation results overlapped and with offset.
It is possible to see that the time sequence of state transitions is according to the expected se- quence. After the Start state follows the Moving state and next the End state returning back to Start state, and so on.
41 42 4 Petri Net Model and Supervisory Controller
Contents 4.1 Petri net Model ...... 44 4.2 Supervisory Controller ...... 55
43 This chapter is composed by two main sections. The first section describes the PN representation of the system as well as an analysis overview. The second describes a supervisory controller and the constraints applied to the system.
4.1 Petri net Model
The representation of the train system through a PN was made in several stages. The system was divided into several sub-systems, each one representing distinct functional parts of the system. The purpose of this division is to reduce the complexity of the PNs design and to allow an easier analysis of each part of the system. Each one of these sub-systems was individually designed and tested. In the final stage, all of the sub-systems are properly joined together to form the whole system. The sub-systems in which the system was divided are listed below:
• Train movement
• Battery
• Motor
• Obstacle detection
• Cruise speed reference
In the following sections each sub-system is described as well as their PNs representations. Note that all models presented are under Netlab notation, namely places and transitions. Also there is an input place associated to each transition in order to set the firing of each transition. The firing occurs according to events associated with each transition and occurring within the Simulink model. This way the PN model is able to account for all events taking place, on a real-time scale. In order to visually simplify the presentation of the PN models, each input place associated with transitions is disregarded during the present section. A PN analysis is performed in each section to study the boundedness, conservation and reacha- bility of each PN as well as the existence of deadlocks. Regarding boundedness, a net is k-bounded if the maximum number of tokens in a place is k, for all reachable markings. If k = 1 then the net is conservative. Reachability is a property that is used to find if a marking is reachable or not. This property can be studied through the reachability tree which contains all reachable markings, within the PN state space. The reachability tree method is used to analyze the existence of deadlocks and the place and transition invariants are obtained in order to analyze boundedness and conservation. Through place invariants it is possible to find sets of places which number of tokens remains constant in all reachable markings. Transition invariants correspond to sequences of firing transitions that lead to the same marking. This property allows the study of operational cycles within the PNs.
44 4.1.1 Train
This part of the system represents the train movement along the track. The train line is assumed to be composed by several different trunks with different characteristics such as gradient and length. All trunks begin and terminate upon a station, where the train must stop once reached. The location of the train along the track is determined by the location tracking block which informs the management system whenever a station is reached. When the train stops at a station it remains there until the energy management system allows departure to the next trunk. The train may also stop between stations due to obstacle detection or power failure. In this case it remains at the specific location until the obstacle is no longer detected at which time the energy management allows the resume of the journey. Each state of the train is represented in the PN by a place. A single token is passed on from place to place representing the current status of the train. In order to make the PN representation of the process conditions and events were defined in Tables 4.1 and 4.2, along with the respective dependencies:
Table 4.1: Conditions in sub-system train.
Condition ID Condition a) Train moving (place 1) b) Train waiting to start moving (place 2) c) Train finishes trunk (place 3) d) Train waiting to resume movement (place 4)
Table 4.2: Events and dependencies in sub-system train.
Event ID Event Pre-conditions Post-conditions 1) Train begins to move b) a) 2) Train is ready to start moving c) b) 3) Laser is detecting an object a) d) 4) Laser stopped detecting the object d) a) 5) Train reaches a station a) c)
The PN is represented in figure 4.1:
45 Figure 4.1: PN representing the train sub-system.
According to the conditions defined in Table 4.1, it is possible to see that each place represents one of the four possible states of the train. The correspondence between conditions and places is also presented in Table 4.1. Whenever a token is placed inside a place it means the correspondent condition represents the current situation of the train. Condition a) and represents the train moving along a trunk. From this condition two events may occur: a station is reached or an obstacle is detected. If a station is reached transition 5 fires and the train evolves to condition c). Once the train is located on a station and before it proceeds the next trunk it must go through condition b). This condition states that all requirements are gathered in order to proceed to the next trunk. Among these there are the following conditions: i) passengers are already inside the train and ii) battery charge is above the safe value. If these conditions are met then transition 2 fires, placing the token in place 2 which means the train is ready to start the next trunk. From condition b) the train evolves again to condition a) when transition 1 fires. If an obstacle is detected while the train is moving, transition 3 fires and the train steps to condition d) until the object is no longer detected, at which point transition 4 fires, returning the train back to condition a). A detailed explanation of the decision process of the energy management system is further presented.
4.1.1.A Petri net analysis
An analysis was carried to the PN through Netlab and a few properties were extracted. The place
(P) and transition (T) invariants as well as the PN incidence matrix (W0) are represented as follows:
46 0 1 1 1 0 −1 1 −1 0 1 1 −1 1 0 0 0 P = T = 1 0 W = 1 0 0 −1 0 0 1 1 0 1 0 0 1 −1 0 0 1 There is only one set of place invariants which includes places from 1 to 4. Through the PN structure and the initial marking, it is possible to infer that the sum of tokens in those places is always 1, which makes all places 1-bounded. Thus the PN is conservative. The verification of conservation property confirms that model is consistent with the process, since simultaneous conditions are not allowed. For instance if the vehicle is moving, it cannot be stopped at a station; or even when an obstacle is detected, the vehicle cannot proceed journey as if no obstacle is on the track. All conditions are therefore mutual exclusive. There are two sets of transition invariants in this PN. Each one of them defines a transition se- quence that leads from one marking to the same one. The second operation cycle is composed by transitions 1, 2 and 5 and represents the events of stopping in a station and resuming movement to the next trunk. The first operation cycle is composed by transitions 3 and 4 and represents the train stopping due to obstacle detection and then resuming travel once the obstacle is no longer detected. Both these cycles correspond to realistic operational cycles of the concerned vehicle. Their oc- currence is relevant since it verifies the realist modeling of the process, therefore concluding that the main process events are in fact represented within the PN model. By analyzing the reachability tree it is possible to conclude that there are no deadlocks and that the net is live, since there are no dead transitions. This proves that the train state evolves according to the occurrence of events associated with energy and mission requirements, within the PN reachable set. Since there are no deadlocks the train does not get stranded during the mission, finishing it if possible taking into account energy requirements. Most importantly it is possible to conclude that the train condition evolves continuously independently of the PN marking, following a realistic behavior of the modeled process.
4.1.2 Battery
The sub-system dealing with the battery, handles all recharging and discharging processes. Two distinct battery properties are modeled: the stored charge condition and the charging/discharging process. In order to model the stored charge condition two charge thresholds are defined: i) the minimum charge value, which corresponds to the minimum charge allowed to the battery in order to prevent the risk of malfunction and ii) the safe charge value which represents the charge at which the vehicle must start up with, in order to ensure the mission can be energetically sustained, and also taking into account the occurrence of unfavorable conditions. The charging/discharging process can be described by three conditions: i) discharging, ii) charging and iii) idle. The goal is to make sure the battery remains with a minimum stored energy and simultaneously provides the necessary power for the train to finish the mission successfully. When the train reaches
47 a station, the amount of energy stored in the battery is checked and in case it does not reach the safety threshold, it recharges through the electric grid. A list of conditions and events is presented in tables 4.3 and 4.4 along with the respective dependencies:
Table 4.3: Conditions in sub-system battery.
Condition ID Condition a) Battery discharging (place 1) b) Battery idle (place 2) c) Battery charging (place 3) d) Battery charge below minimum value (place 4) e) Battery charge below safe value (place 5) f) Battery charge above safe value (place 6)
Table 4.4: Events and dependencies in sub-system battery.
Event ID Event Pre-conditions Post-conditions 1) Battery goes from discharging mode to idle a) b) 2) Battery goes from idle mode to discharging b) a) 3) Battery goes from charging mode to idle c) b) 4) Battery goes from idle mode to charging b) c) 5) Battery goes from charging mode to discharging c) a) 6) Battery goes from discharging mode to charging a) c) 7) Battery charge drops bellow the minimum value e) d) 8) Battery charge rises above the minimum value d) e) 9) Battery charge drops bellow the safety value f) e) 10) Battery charge rises above the safety value e) f)
The PN is presented in figure 4.2:
Figure 4.2: Petri Net designed representing the battery sub-system.
The battery is modeled by two sub-nets where the one on the left represents the battery charg- ing/discharging process and the one on the right represents the stored charge condition. Referring
48 to the first sub-net: the battery is described by three main conditions a), b) and c). The correspon- dence between places is presented in table 4.3. The initial condition of the battery is idle as a token is initially placed in place 2. This condition is verified whenever the power delivered by the panels is enough to sustain the power demand, or when the demand is null. Transitions 4 and 6 lead to condition c), from condition a) and b) respectively, representing the charging process of the battery. This condition is verified whenever the train is braking or re-charging at a station. Transitions 2 and 5 lead to condition a) where the battery discharges. This condition is verified when the train is accel- erating or when the power delivered by the panels are not enough to sustain minimum cruise speed. The second sub-net represents the charge condition and is represented by three conditions d), e) and f).The correspondence between places is presented in table 4.3. The events associated with this sub-net are defined by Simulink and are inevitably related with the charging/discharging state of the battery. When the battery charge is below minimum value, a token is placed in place 4. Once charge rises above minimum value transition 8 fires and the token is placed in place 5, under condition e). If charge rises above safety value transition 10 fires and the token is placed in place 6. The opposite condition sequence can occur, through transitions 9 and 10, in case the battery charge drops below safety and minimum value respectively.
4.1.2.A Petri net Analysis
An analysis was carried to the net through Netlab and some properties were extracted. The place
(P) and transition (T) invariants as well as the incidence matrix (M1) are presented as follows:
1 0 0 0 1 0 0 0 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0 0 1 0 0 1 0 −1 1 0 0 1 −1 0 0 0 0 0 1 0 0 1 0 0 0 1 1 0 1 −1 1 −1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1 0 0 0 −1 1 −1 1 0 0 0 0 P = T = 0 0 0 0 0 1 1 0 0 M1 = 0 1 0 0 0 0 0 0 1 −1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 −1 1 1 −1 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 −1 1 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1
There are two sets of place invariants, the first is composed by places 1 to 3 and the second by places from 4 to 6. Thus each sub-nets constitute one set of place invariants. Through the PN structure and initial marking, it is possible to infer that the sum of tokens in each set of places is always 1, which makes all places 1-bounded. Thus the PN is conservative. The verification of conservation property confirms that model is consistent with the process, since simultaneous conditions are not allowed. For instance if the battery is charging, it cannot be simultaneously discharging; or even when the charge is below minimum value, it is not possible that it is simultaneously above safety threshold. All conditions are therefore mutual exclusive. There are nine sets of transition invariants in this PN. They represent the charge cycles of the bat- tery considering rising and dropping before the established thresholds. Also the charging/discharging
49 cycles are represented considering vehicle requirements phase sequences which cause the switching between discharge, idle and charging conditions. All cycles correspond to realistic operational cycles of the battery. Their occurrence is relevant since it verifies the realist modeling of the battery charge processes and condition therefore concluding that the main events are in fact represented within the PN model. Through the reachability tree it is possible to conclude that there are no reachable markings lead- ing to deadlocks. The net is live as all its transitions. This analysis shows that the battery model covers all possible modes and charge states. It is also possible to switch between all states from one to another, without getting stranded in any condition and therefore providing the necessary energetic demand for the vehicle.
4.1.3 Motor
The sub-system representing the motor includes the main operations occurring within an electric motor. The motor is controlled by the energy management system which sets the start up and turn off of the motor. Three main operational phases are considered: i) acceleration, ii) deceleration, iii) cruise velocity phase and iv) motor off. It is important to distinguish between these phases since they are distinct from the point of view of the power demand. During acceleration phase the power demand is the highest, constituting a peak on demand curve. On the other hand, during deceleration there is also a power peak demand, though it is negative since the motor is delivering power. Finally during cruise velocity phase the power demand is constant. A set of conditions and events were defined in tables 4.5 and 4.6 along with the respective depen- dencies:
Table 4.5: Conditions in sub-system motor.
Condition ID Condition a) Motor off (place 1) b) Acceleration phase (place 2) c) Cruise velocity (place 3) d) Deceleration phase (place 4)
Table 4.6: Events and dependencies in sub-system motor.
Event ID Event Pre-conditions Post-conditions 1) Motor starts a) b) 2) Vehicle has reached cruise velocity b) c) 3) Vehicle decelerates c) d) 4) Motor turns off d) a) 5) Vehicle has reached cruise velocity d) c) 6) Vehicle accelerates c) b) 7) Vehicle accelerates d) b) 8) Vehicle decelerates b) c)
The motor Petri net is presented in figure 4.3:
50 Figure 4.3: Petri Net designed representing the motor sub-system.
Once the motor is started it accelerates until cruise speed is reached. Transition 2 fires once this happens and the token is placed in place 3 which represents condition c). Once the vehicle is traveling on cruise velocity two events may occur: the vehicle decelerates (in case it stops or slows down) or the vehicle accelerates (in case it is allowed to increase cruise velocity). Both events are represented, respectively, by the firing of transitions 3 and 6. Once the transitions fire, the token is re-placed from condition c) on conditions d) or b) respectively. Transition 4 fires whenever the vehicle is decelerating and stops. Once it stops the transition fires placing the token on condition a) which means the motor has been turned off. From condition d), it is also possible for transition 5 to fire. This event occurs in when the cruise velocity decreases and the vehicle decelerates until it reaches the new value. When it does transition 5 fires placing the token back in condition c). The same applies if the power delivered by the panel increases.
4.1.3.A Petri net analysis
An analysis was carried to the net through Netlab and some properties were extracted. The place
(P) and transition (T) invariants as well as the incidence matrix (M2) are presented as follows:
1 0 0 0 1 0 0 1 0 1 1 0 0 0 1 1 1 0 1 0 0 0 −1 0 0 1 0 0 0 0 1 1 0 0 0 1 0 0 1 −1 0 0 1 1 1 −1 P = T = M2 = 1 0 1 0 0 0 0 1 0 1 −1 0 1 −1 0 0 1 0 0 1 0 0 0 0 0 0 1 −1 −1 0 −1 1 0 0 0 1 0 1 0 0 0 0 0 1 1 1
There is one set of place invariants, composed by the four places. Since the net is composed only by four places and there is initially only one token placed in place one it is possible to conclude that the Petri net is conservative and 1-bounded. The verification of conservation property confirms that
51 model is consistent with the process, since simultaneous conditions are not allowed. For instance if the vehicle is accelerating, it cannot be simultaneously decelerate or remain on cruise velocity phase. All conditions are therefore mutual exclusive complying with the appropriate behavior of an electric motor. There are seven sets of transition invariants within the PN. Each one of them defines a transition sequence that leads from one marking to the same one. For the motor particular case, each cycle represents the succeeding sequence of phases occurring during travel, namely from start up to stop. Each phase can be followed by a numerous phase sequences, for instance acceleration can be fol- lowed by cruise velocity or deceleration and then back to acceleration; cruise velocity can be followed by acceleration or deceleration and back to cruise velocity. All cycles correspond to realistic opera- tional cycles of the vehicle. Their occurrence is relevant since it verifies the realist modeling of the motor phases, therefore concluding that the main events are in fact represented within the PN model. Through the reachability tree it is possible to conclude that there are no reachable markings lead- ing to deadlocks. The net is live as all its transitions. This analysis shows that the motor model covers all possible phases and phase sequences within the behavior of the vehicle and engine.The motor is able to switch between all phases without getting stranded in any of them and therefore providing the required response o the vehicle requirements.
4.1.4 Cruise speed reference
This part of the system represents the determination of the cruise speed reference for the vehicle. The cruise speed depends directly on the power that is being delivered by the panels at that moment. Since the QSS toolbox works with discrete speed values (1 second sampling time), also the power delivered by panels must be discretized with a sampling time of 1 second. Thus the cruise speed ref- erence is updated in each second. In order to make the PN representation of the process, conditions and events were defined in tables 4.7 and 4.8 along with the respective dependencies:
Table 4.7: Conditions in sub-system cruise speed reference.
Condition ID Condition a) Desired cruise speed (place 1) b) Power delivered by panels (place 2)
Table 4.8: Events and dependencies in sub-system cruise speed reference.
Event ID Event Pre-conditions Post-conditions 1) Cruise speed allowed by panels increases one unit b) a) 2) Cruise speed allowed by panels decreases one unit a) - 3) Power delivered by panels increases one unit - b)
The PN is represented in figure 4.4:
52 Figure 4.4: Petri Net representing the cruise speed reference.
As shown in the Net there are two conditions a) and b) representing respectively the power de- livered by panels and cruise speed reference. Condition a) corresponds to place 1 and number of tokens present in this place corresponds to the desired cruise speed for the train at that moment. Condition b) corresponds to place 2 and number of tokens present in this place corresponds to power delivered at that moment. For this net, the tokens placed in different places have different meaning, for instance, a token placed in place 2 corresponds to one power unit, 1 kW and a token in place 1 corresponds to one speed unit, m/s. These values are assumed, though other values can also be considered as long as coherence is maintained. Event 3 corresponds to a source transition that when fires, places a token in place 2, which means the power increases by one unit. This transition is controlled by an external Simulink signal which is responsible for placing in place 1 the number of tokens corresponding to the delivered power. Tran- sition 3 is only allowed to fire every second which means that the delivered power and consequently cruise velocity are sampled within a 1 second interval. Transition 1 fires once a token is placed in place 2, which means that if the power increases, also does the cruise velocity. Transition 2 fires whenever the power delivered decreases, and in that case the velocity reference must also decrease. The interpretation of the quantified tokens into power and velocity units is taken into account by Simulink when transferring the PN signals.
4.1.4.A Petri net analysis
An analysis was carried to the net through Netlab and some properties were extracted. The transition (T) invariants and incidence matrix (M3) are presented as follows:
1 1 −1 0 T = 1 M = 3 −1 0 1 1 There are no sets of place invariants since the net has a source transition which makes it un- bounded. Tokens placed in Place 2 correspond in fact to the amount of power delivered by the panels which does not hold a maximum defined value. Therefore place 1 is also unbounded since transition 1 can fire the same number of times as transition 3. There is one set of transition invariants in this Petri Net. It is composed by all the transitions of the PN. The operation cycle corresponds to the sequential firing of the source transition 3, the inter- mediate transition 1 and the sink transition 2. This sequence allows the cruise velocity to be updated depending on the available power. By analyzing the reachability tree it is possible to concluded that there are no deadlocks and the net is live, since there are no dead transitions. In fact the marking evolution of the PN depends exclusively on the amount of power delivered by the panels which is the
53 same to say the number of times the source transition 3 fires.
4.1.5 Overall system
The overall system is composed by each sub-system described in the previous sections. The global Petri Net is presented in figure 4.5:
Figure 4.5: Petri Net representing the whole system.
The incident matrix is composed by all the sub-matrices and takes the following form:
M0 0 0 0 0 M1 0 0 M = 0 0 M2 0 0 0 0 M3 The global incident matrix is represented as follows:
1 0 −1 1 −1000000000000000000000 −11000000000000000000000000 0 −1001000000000000000000000 0 0 1 −10000000000000000000000 0 0 0 0 0 −100100000000000000000 0 0 0 0 0 1 −1 0 0 0 1 1 −10000000000000 0 0 0 0 0 0 1 −1 0 1 −1000000000000000 0 0 0 0 0 0 0 1 −1 −1 0 −110000000000000 M = 0000000000000 −1 1 0 0 1 −1 0 0 0 0 0 0 0 00000000000001 −1 1 −1 0 0 0 0 0 0 0 0 0 000000000000000 −1 1 −1 1 0 0 0 0 0 0 0 00000000000000000001 −1 0 0 0 0 0 0000000000000000000 −1 1 1 −1 0 0 0 000000000000000000000 −1 1 0 0 0 000000000000000000000001 −1 0 00000000000000000000000 −1 0 1
The overall system is composed by four sets of place invariants, which correspond to the place invariants of each sub-system. The transition invariants also correspond to each of the sub-systems invariants. Both sets are represented as follows:
54 01000000000000000 01000000000000000 10000000000000000 10000000000000000 01000000000000000 00100000000010000 1 0 0 0 00101100000000000 1 0 0 0 00110100000000000 1 0 0 0 00100000000010000 1 0 0 0 00010000000000000 0 1 0 0 00001000000000000 0 1 0 0 00000100000000000 0 1 0 0 00000000000010000 0 1 0 0 P = T = 00000010000100000 0 0 1 0 00000010000001100 0 0 1 0 00000001000001010 0 0 1 0 00000001000100011 0 0 0 1 00000000000100011 0 0 0 1 00000000000001010 0 0 0 1 00000000100000000 0 0 0 0 00000000100000000 0 0 0 0 00000000010000000 00000000010000000 00000000000000101 00000000001000000 00000000001000000 00000000001000000
A system overview was performed through Netlab which concluded that there are no deadlocks and that the net is live, since there are no dead transitions. All properties are inherited from the sub-systems composing the overall system. Because sub-system Cruise Speed Reference is part of the overall net, its characteristics are assumed by the system which makes the net unbounded and consequently not conservative.
4.2 Supervisory Controller
A supervisory controller was designed for the whole system as to apply necessary constraints that must be satisfied in order to comply with the project requirements. The supervisor is a controller that applies to a system defined by a PN with incidence matrix Dp and initial marking vector u0. The controller uses the concept of PN place invariants and a detailed description of the method can be found in [18]. Firstly a set of restrictions of the real system are defined. These restrictions are mapped into the systems PN under the form of constraints. These constraints must be verified so that the system operates properly and the restrictions are respected. In order to do so, a supervisor is designed, consisting of arcs and places that must be added to the original Petri net model. The controller size is proportional to the number of constraints. The method of synthesis used to design the supervisor depends on the type of constraint defined. In the following section the constraints definition is explained as well as the methods used to design the supervisor.
4.2.1 Synthesis of controller using linear constraints This type of controller is designed for a system modeled by a PN with n places and m transitions. The goal is to get the net to satisfy constraints of the following form:
xux + yuy ≤ z, (4.1)
55 This equation ensures that the weighted sum of tokens in places ux and uy does not exceed the integer z. For instance if x = y = z = 1, the equation means that both places cannot be marked at the same time. A constraint of this type can be written in matrix form as
Lup ≤ b, (4.2) where up is the marking vector of the PN, L is a 1 x n integer vector and b is an integer. A controller that satisfies this type of constraints can be obtained using matrix notation and according to PN invariants [18]. Firstly the following vectors are defined by inspection from the constraint (4.1):
L = x y b = z The controller is then defined by:
Dp = −LDc, (4.3) where Dc is the PN incidence matrix and the vector Dp contains the arcs that connect the controller place to the transitions of the net. The new incidence matrix is then obtained by,
D D = c Dp The initial marking of the controller place must be such that the constraint is verified and depends on the initial marking of the original PN, u0. It can be determined by:
0 u = b − Lu0 (4.4) where u0 is an integer and corresponds to the marking of the controller place.
4.2.2 Synthesis of controller using generalized linear constraints Linear generalized constraints take the following form:
vx ≤ b + vy, (4.5)
This equation means that transition vx is only enabled to fire when transition vy has fired at least b times. A controller that satisfies this type of constraints can be obtained using a method based on place invariants for generalized linear constraints. According to this method described in [11], given the linear constraint,
Lup + F qp + Cvp ≤ b (4.6)
where up is the marking vector, qp the firing vector since t = 0 and vp the vector of enabled transitions. L = F = 0 and C is the vector obtained from the transition coefficients in (4.5).
and if b − LuP0 ≥ 0 then the controller with incidence matrix and initial marking, respectively
− + Dp = −Dp + Dp (4.7) where − Dp = max(0, LDc + C,F ) (4.8)
+ Dp = max(0,F − max(0, LDc + C)) − min(0, LDc + C) (4.9) and
uC0 = b − LuP0 (4.10) guarantees that constraints are verified for the states resulting from the initial marking.
56 4.2.3 Constraints involving the firing vector This type of constraints takes the following form:
vx ≤ ux, (4.11)
Where vx represents a transition and ux a place. This equation means that transition vx is only enabled to fire when place ux is marked. A controller that satisfies this type of constraints is easily implemented by inspection as proved in [18]. In these cases, arcs be added between ux and vx, meeting the constraint required.
A set of constraints of the real system is listed in order to implement the supervisor:
1. Once the battery crosses minimum value threshold it stops discharging. 2. While the battery remains under minimum charge value, it cannot discharge. 3. Cruise velocity cannot exceed a certain value. 4. The train is only allowed to begin traveling the next trunk in case the battery charge is above safety value. 5. While motor is at cruise velocity mode it switches to decelerating mode when a station is reached or an obstacle is detected. 6. While motor is off it only starts when the train is set to begin the next trunk or when an obstacle, causing the train to stop, is no longer detected.
According to these restrictions, a set of constraints for the global system, represented in Figure 4.5, is defined.
Restriction 1 can be verified through the generalized linear constraint:
v14 ≤ 1 + v20, (4.12) which guarantees that whenever a token is placed in place 12 (which states that the battery charge is below the minimum value), and in case a token is placed on discharging state (place 9), it moves to idle state (place 10). Vector C and integer b are defined by inspection from 4.12:
C1= [0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 -1 0 0 0 0 0 0]
b1=0
− finally the controller place can be defined through 4.7, 4.8 and 4.9 where Dp = max(0,C, 0) and + Dp = max(0, 0 − max(0,C)) − min(0,C). The controller takes the value:
Dp1 = [0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 1]
The initial marking for the new place in determined through 4.10: u01 = 0 − 0 = 0. Restriction 2 corresponds to a case of mutual exclusion between place 9, and place 12. Since restriction 1 itself, already prevents the battery from discharging once the battery charge drops below minimum value, an extra place and transition is required between place 13 and 12 so that the mutual exclusion can be applied. Thus, the mutual exclusion prevents the battery from beginning discharge once the charge is below minimum, while restriction 1 stops the battery discharge in case the battery charge drops below minimum value. Restriction 2 must only be applied after restriction 1 with respect to the new net obtained after applying supervisory controller according to constraint 1 and by adding an extra place and transition. It can be verified by the linear constraint:
u9 + u12 ≤ 1 (4.13) The following vectors can be extracted:
57 L2= [0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] b2 = 1
Dp2 = −L2Dc= [0 0 0 0 0 0 0 0 0 0 0 0 0 1 -1 0 0 -1 1 -1 1 0 0 1 0 0 0]
u02 = 1
where L2 and b2 are directly obtained through the constraints. u02 is obtained through (4.4) and finally Dp2 is determined by (4.3) and represents the new line that should be added to the incident matrix Dc. Restriction 3 can also be verified by a linear constraint. It takes the following form:
u15 ≤ 4 (4.14) and guarantees that the number of tokens in place 15 does not exceed 4. This means the maxi- mum speed is restricted to 4 units. The following vectors can be extracted:
L6= [0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0] b6 = 4
Dp6 = −L6Dc= [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 1 0 0]
u06 = 4
where L6 and b6 are directly obtained through the constraints. u06 is obtained through (4.3) and finally D6 is determined by (4.2) and represents the new line that should be added to the incident matrix Dc. Each controller corresponds to a place that performs a supervisory function within the Petri Net model. The remaining constraints involve the firing vector and can be implemented by adding two arcs in between the transition and place involved. Table 4.9 resumes the constraints as well as the controller places or arcs resulting from control solutions to each restriction.
Restriction Constraint L ; b ; C Controller place : D; u0 Number of Arcs added
1 v14 ≤ v20 C = C1 D = Dp1 , u0 = 0 –
2 u9 + u12 ≤ 1 L = L2; b = b2 D = Dp2 , u0 = 1 –
3 u15 ≤ 4 L = L6; b = b6 D = Dp6 , u0 = 4 – 4 v2 ≤ u14 – – 2 5 v8 ≤ u3; v8 ≤ u4 – – 4 6 v6 ≤ u1 – – 2
Table 4.9: Constraints and corresponding supervisory control solutions and auxiliary variables.
The supervised system is represented in the figure below:
58 Figure 4.6: Petri Net model of supervised system.
It is possible to compare that the supervised system corresponds to the the original unsupervised system plus including the controller places and new arcs added to the system. The incident matrix is hereby presented:
1 0 −1 1 −10000000000000000000000 −110000000000000000000000000 0 −10010000000000000000000000 0 0 1 −100000000000000000000000 0 0 0 0 0 −1001000000000000000000 0 0 0 0 0 1 −1 0 0 0 1 1 −100000000000000 0 0 0 0 0 0 1 −1 0 1 −10000000000000000 0 0 0 0 0 0 0 1 −1 −1 0 −1100000000000000 0000000000000 −1 1 0 0 1 −1 0 0 0 0 0 0 0 0 M = 00000000000001 −1 1 −10000000000 000000000000000 −1 1 −1 1 0 0 0 0 0 0 0 0 00000000000000000001 −1 0 0 0 0 0 0 0000000000000000000011 −1 0 0 0 −1 000000000000000000000 −1 1 0 0 0 0 000000000000000000000001 −1 0 0 00000000000000000000000 −1 0 1 0 00000000000000000000000 −1 1 0 0 00000000000001 −1 0 0 −1 1 −1 1 0 0 0 0 0 0 0000000000000 −1 0 0 0 0 0 −1 0 0 0 0 0 0 1
The supervised system is composed by a set of place and transition invariants respectively pre- sented as follows:
59 0100000000000000 0100000000000000 1000000000000000 1000000000000000 1 0 0 0 0 0 0100000000000000 1 0 0 0 0 0 0010000000000100 1 0 0 0 0 0 0010110000000000 1 0 0 0 0 0 0011010000000000 0 1 0 0 0 0 0010000000000100 0 1 0 0 0 0 0001000000000001 0 1 0 0 0 0 0000100000000001 0 1 0 0 0 0 0000010000000010 0 0 1 0 0 1 0000000000000111 P = T = 0 0 1 0 0 0 0000001000000000 0 0 1 0 0 0 0000001000010000 0 0 0 1 0 1 0000000100010000 0 0 0 1 0 0 0000000100000000 0 0 0 1 0 0 0000000000001000 0 0 0 0 1 0 0000000000011000 0 0 0 0 0 0 0000000010000000 0 0 0 0 1 0 0000000010000000 0 0 0 0 0 1 0000000001000000 0000000001000000 0000000000100000 0000000000100000 0000000000100000
A system overview was performed through Netlab which concluded that there are no deadlocks and the net is live, since there are no dead transitions. The net is not bounded or conservative. This is due to source transition 26 which is enabled to place an infinite number of tokens in place 16. Therefore it can be concluded that the properties of the original unsupervised system were kept. Most importantly, PN analysis results ensure that the train never stops such that the passengers get stranded and that the train finishes its mission. The supervised controller is used, by the Simulink tool model designed to simulate the train, to control the performance of the system and apply the restric- tions described within this section. The next chapter analyses several simulation results obtained by integrating the supervisor within the Simulink model.
60 5 Results and Discussion
Contents 5.1 Power available ...... 62 5.2 Simulation Tool Model ...... 64 5.3 Acceleration Influence ...... 65 5.4 Deceleration Influence ...... 66 5.5 Weight Influence ...... 67 5.6 Gradient Influence ...... 68 5.7 Battery Requirements ...... 70 5.8 Obstacle on track scenario ...... 71 5.9 Cloudy Weather and Power failure scenario ...... 73 5.10 Three stations path scenario ...... 75 5.11 Time Restriction - Definition of required cruise velocity ...... 77
61 In this section simulation results are presented and discussed. The performance of the train is an- alyzed for multiple scenarios and unpredictable situations such as obstacle detection and unfavorable weather conditions. The performance of the train is evaluated based on energy consumption,travel time and speed achieved.
5.1 Power available
The power delivered by the panels varies along the day, depending directly on location, irradiance and on the suns position, and therefore so does the performance of the train. The irradiance of the sun along the day corresponds to the power delivered by the sun per square meter (W/m2). The panels can only absorb part of this power, though is has to be taken into account that the efficiency depends on the technology and equipment. Currently the best achieved sunlight conversion rate (solar panel efficiency) is around 21% in commercial products [19]. This value is assumed throughout the remaining simulation results. The typical irradiance values can be obtained on a solar radiation data services website [20]. Since the main working season for the solar train is the summer, the most relevant irradiance values correspond to an average day in June, July, August and September, as to consider the overall sum- mer irradiance conditions in the region of Faro (South of Portugal). Figure 5.1 shows the average irradiance during a whole day, during summer and winter months.
Figure 5.1: Irradiance.
Irradiance during summer reaches a peak of around 1000W/m2 between noon and 2pm. During June, July and September the maximum irradiance actually exceeds this value, while during Septem- ber the peak lies between 900 and 1000W/m2. During winter months irradiance is much lower with a maximum peak of 600W/m2 during March, at the same time. The corresponding power absorbed by the panels varies along with irradiance through the follow- ing expression:
P = A × µ × I (5.1) where A corresponds to the panel surface area (m2), µ is the efficiency and I is the irradiance. For this particular case, in respect to helianto [3], it is considered that the panels dimensions are 1.6x1m and that 12 panels are placed in each carriage. Taking into account the area and number of panels placed on the train, which is composed by only one carriage, the power delivered by the panels along the day is represented in figure 5.2. Exceptionally this graph was obtained with a value of 17% efficiency which is also within the efficiency range of commercial solar panels.
62 Figure 5.2: Power delivered by the 12 panels.
The train motion must be sustained by the panels alone, whenever possible, which means that the cruise velocity should be such that the power delivered by the panels is enough to sustain it, without resorting to battery. Therefore the cruise velocity reached by the train depends directly on the amount of power delivered by the panels. In order to determine the relation between power and velocity a simulation was performed on Simulink using the vehicle block from QSS. An empty train of 4.5 tons was simulated on a null slope track. The velocity variable for the vehicle was linearly increased, from 0 to 50 km/h, in order to observe the power demand evolution. The curve obtained is represented in figure 5.3:
Figure 5.3: Power required as a function of cruise velocity.
From 5.3 is possible to observe that the curve is approximately linear. Using the Matlab function polyfit it was possible to interpolate the data curve obtaining the following linear function:
Pi = 0.1394v − 0.0916 (5.2) Through this relation is possible to determine the cruise velocity reached by the vehicle, given the time of the day, and considering the power delivered at that time. The allowed cruise velocity given the time of the day is represented in figure 5.4
63 Figure 5.4: Cruise velocities allowed.
It is possible to see that at dawn and sunrise the cruise speed is low and actually null between 8 pm and 6 am. The curve has a peak around noon where the cruise velocity achieved is around 25 km/h. Between 10 am and 16 pm the cruise velocity remains above 20 km/h. Considering the purpose of the helianto project it is considered that the minimum cruise velocity corresponds to 10 km/h. It is possible to observe that during summer months this velocity can be achieved from around 9 am to 5 pm. This requirement is assumed throughout the remaining simulation results. It is also assumed that the average power delivered long the day corresponds to 3 Kw. Until 9 am and after 5 pm the train requires the battery support in order to reach minimum cruise velocity. During winter months the velocity achieved is much lower not reaching 15 km/h.
5.2 Simulation Tool Model
A Simulink model was created in order to simulate the whole system, by integrating the supervisory controller and the infrastructure of the solar train. The model is represented in Figure 5.5:
64 Figure 5.5: Simulation tool model.
The model structure is similar to the block diagram of the overall system presented in Figure 3.1. The supervisory controller is represented by block Supervisory Controller and receives input signals through the inbus and outputs the controller signals through the outbus. All blocks receive direct or indirect commands from the supervisor in order to simulate the performance of the train according to requirements and constraints defined by the user. All requirements and characteristics of the solar vehicle can be defined through a intuitive user interface presented in Annex A. The simulation tool creates a realistic scenario for evaluating the performance of the train, allowing the definition of variables such as power delivered by panels, obstacles on the track, battery capac- ity and initial charge, distance to be covered, vehicle characteristics, carried weight, track gradient, acceleration/deceleration values and minimum velocity. A detailed description of the simulation tool can be found on the tool manual presented in Annex A.
5.3 Acceleration Influence
A suited fixed acceleration is studied with the purpose of minimizing energy consumption. The acceleration phase produces a power peak demand. During this phase energy demand is sustained by both panels and battery since the panels alone are not able to sustain the required power peak. The train is assumed to start up with fixed acceleration and a suited value is fixed as to avoid unnecessary variations of energy demand and consequently unnecessary power peaks. A balanced acceleration value must be set so that the power peak can be sustained by the panels and battery. It must also be considered the acceleration time and passengers comfort, which means the time the train takes to reach cruise velocity should not be too low nor too high, respectively. A range of acceleration values is tested as to define a suited and reasonable value for the start up of the train. A typical urban train acceleration value corresponds to 1 m/s2 which is considered comfortable, from the point of view of the passenger [21]. Since the solar train does not reach a typical range of speeds of an urban train, a possible range of acceleration values is considered from 0 to 1 m/s2.
65 Using the Simulink model represented in Figure 3.10, a simulation was performed aiming to de- termine the relation between acceleration and power peak demand and battery energy use, when maintaining a constant route. For this simulation, a cruise velocity for the vehicle was fixed on 20 km/h and the track gradient and carried weight are considered null. The acceleration value was lin- early increased in order to observe the power demand and battery energy use evolution. This relation is illustrated in Figure 5.6 where is represented power peak demand and percentage of battery energy use.
Figure 5.6: Peak power and battery energy use, given different acceleration values.
It is possible to see from Figure 5.6 that the response is non-linear, this happens because QSS toolbox considers several levels of consumption for different acceleration values. Also both peak power and battery energy use increase along with acceleration, as expected. Energy consumption is higher for the highest and lowest acceleration values. This can be explained since for the highest values the peak power is higher and therefore more energy is spent during acceleration. On the other hand for the lowest values the peak power is lower but it takes more time for the train to reach cruise speed, so the acceleration period is longer. It is intended to obtain an acceleration value that balances energy consumption, peak power and passenger comfort. This balance can be achieved by acceleration values between 0.15 and 0.35 m/s2 where the power peak and energy consumption are lower and also it is a reasonable value from the point of view of the passengers comfort. An acceleration of 0.35 m/s2 is assumed for all simulations described hereafter.
5.4 Deceleration Influence
A suited fixed deceleration (when braking) is studied with the purpose of increasing energy regen- eration. As the acceleration value, also the deceleration value is set to a fixed value. Deceleration is directly related to energy regeneration and therefore its value must be such that regeneration is opti- mized. The braking time and passengers comfort must also be considered, and so the deceleration value should not be too low nor too high, respectively. A range of deceleration values is tested in order to define a suited and reasonable value for the train braking phase. A typical urban train deceleration value corresponds to 1 m/s2 which is considered comfortable, from the point of view of the passenger [21]. A possible range of deceleration values is considered from 0 to 1 m/s2. Using the Simulink model represented in figure 3.10, a simulation was performed aiming to de- termine the relation between deceleration and percentage of regenerated energy and braking phase duration, when maintaining a constant route. For this simulation, a cruise velocity for the vehicle was fixed on 20 km/h and the track gradient and carried weight are considered null. The absolute de- celeration value was linearly increased in order to observe the regenerated energy and braking time evolution. This relation is illustrated in figure 5.7.
66 Figure 5.7: Regenerated energy and braking phase duration given different values of deceleration.
As predicted, braking phase duration decreases for higher deceleration values, this happens be- cause the higher the deceleration value, the later the train brakes in order to stop at the station. Regeneration increases with deceleration.However it is also necessary to consider passenger com- fort, and therefore deceleration cannot be too high. A reasonable value for deceleration can be found between 0.6 and 0.8 m/s2. A deceleration of 0.8 m/s2 is assumed for all simulations described hereafter.
5.5 Weight Influence
The weight carried by the train influences the power demand. Using the Simulink model repre- sented in figure 3.10, a simulation was performed aiming to determine the relation between weight carried by the train and power demand when maintaining constant velocity. For this simulation, a velocity for the vehicle was fixed, as well as the power delivered by the panels, and the weight variable was linearly increased, from 4.5 to nearly 20 tons, in order to observe the power demand evolution under normal and overweight situations. This relation is illustrated in Figure 5.8 where the ratio of power demand, Pi, to reference power demand, P0, is represented, given carried weight. The reference power demand, P0 corresponds to the power demand of the empty train, with a total weight of 4500 kg and moving at 25 km/h on a null slope track.
Figure 5.8: Ratio of power demand to reference demand, given a range of carried weight, for a fixed route and velocity.
67 From Figure 5.8 is possible to observe; i) that the curve is approximately linear. ii) and to identify two linearities a and b. Through the Matlab Polyfit function it was possible to interpolate the two data curves obtaining the following linear function:
4 Pi a : 0.0003m − 0.3194 for m < 1.3 × 10 = 4 (5.3) P0 b : 0.0002m − 0.7921 for m > 1.3 × 10 Through this function it is possible to estimate the power demand increase that results from the increase in carried weight. Finally combining equations 5.2 and 5.3 it is possible to obtain a estimation on the power demand that sustains a certain velocity, considering a given weight. The use of these linear models, and having previous knowledge of the carried weight, allows the adjustment of the velocity such that the power delivered by the panels is enough to sustain it. For instance an increase on power demand (due to weight) will consequently lead to a decrease of the velocity, given a constant amount of delivered power. Consequently the travel time increases along with weight. Thus it is necessary to fix a maximum weight such that the minimum cruise velocity is not crossed and the travel time is not too long. Figure 5.11(d) shows travel time and cruise velocity given the weight carried by the train, for a 1 km distance travel.
Figure 5.9: Cruise velocity and travel time given a range of carried weight .
For weight exceeding 8 tons it is possible to see that the cruise velocity is lower than the minimum value (10 km/h). This means that for weight exceeding 8 tons, the use of the battery charge is required in order to achieve minimum cruise velocity.
5.6 Gradient Influence
The slope of the track influences the power demand. Using the Simulink model represented in Figure 3.10, a simulation was performed aiming to determine the relation between track gradient and power demand when maintaining constant velocity. For this simulation, a velocity was fixed for the vehicle and the gradient variable was linearly increased, from 0 to 10% This relation is illustrated in Figure 5.10 where the ratio of power demand, Pi, to reference power demand, P0, is represented, given track gradient. The reference power demand, P0 corresponds to the power demand of the empty train, with a total weight of 4500 kg and moving at 25 km/h on a null slope track.
68 Figure 5.10: Ratio of power demand to reference demand, given a range of track gradients, for a fixed route and velocity.
From 5.10 is possible to observe: i) that the curve is approximately linear. ii) and to identify two linearities a and b. Through the Matlab Polyfit function it was possible to interpolate the two data curves obtaining the following linear function:
P a : 1.4875α + 0.9791 for α < 1.8% i = (5.4) P0 b : 1.1954α + 1.6407 for α > 1.8% Through these equations it is possible to estimate the power demand increase that results from in- crease of the track gradient. Similarly to the weight influence linear equation, by combining equations 5.2 and 5.4 it is possible to obtain a estimation on the power demand that sustains a certain velocity, considering a given gradient. The use of these linear models, and having previous knowledge of the track gradient, allows the adjustment of the velocity such that the power delivered by the panels is enough to sustain it. For instance an increase on power demand (due to gradient) will consequently lead to a decrease of the velocity, given a constant amount of delivered power. Also the travel time increases along with gradient. Thus it is necessary to fix a maximum gradient such that the minimum cruise velocity is not crossed and the travel time is not too long. The linear models obtained in 5.2, 5.3 and 5.4 are used in all simulations performed in order to define a velocity profile for the solar vehicle that meets the requirements, and taking into account gradient and carried weight. Figure 5.11 shows travel time and cruise velocity given the track gradient.
Figure 5.11: Cruise velocity and travel time given a range of track gradient.
For gradient exceeding 0.9% it is possible to see that the cruise velocity is lower than the minimum
69 value (10 km/h). This means that for trunks where the gradient exceeds this value the use of the battery is required in order to achieve minimum cruise velocity requirement.
5.7 Battery Requirements
The battery requirements are determined according to the objectives set for the solar vehicle and based on the characteristics of the battery block of QSS. The following parameters must be defined considering project requirements and battery functional restrictions: capacity; minimum functional charge, initial charge and current limit. It is possible to define these variables on the battery blocks interface. The battery has an open circuit voltage of 130 volts, when fully charged. The resistance depends on the charge state and the charge/discharge current of the battery. This current limit defines the minimum time the battery takes to charge/discharge completely. For electric vehicles public infrastructures it is available and highly recommended a quick charging system (see [22] and [23]). This system is adequate for quickly charging DC battery equipment and provides high power output allowing a total charging time up to 30 minutes, depending on the battery capacity. For this specific battery, an approximate time of 20 minutes is considered for charging/discharging the full battery through a quick charging system. This value is assumed for all simulations performed. The capacity of the battery is determined so that the train can finish the mission successfully and taking into account unexpected situations such as obstacles and power failure. For instance, one of the minimum requirements is that the train is able to move from one station to the next one, even if the panels are not delivering any power. This requirement is necessary in order to prevent the vehicle from getting trapped between two stations, without the possibility of recharging the batteries. In case this situation occurs it is considered that the train moves only at the minimum required velocity, in order to minimize energy consumption. A worst case scenario is defined, in order to ensure the battery capacity is enough to meet these requirements:
• Panels deliver no power.
• The train is carrying maximum weight. • The track slope is maximum (1% corresponds to an acceptable value [21]). • The distance from current station until the next corresponds to 1 km.
Several simulations are performed under these conditions using for this purpose the Simulink model represented in figure 3.10. On each simulation the battery capacity is increased until the train is able to reach the target (1 km). It is considered that the battery has an initial charge of 90%. The lowest capacity value that allows a successful carried mission corresponds to the minimum capacity allowed for the battery. The simulations results are summarized in table 5.1 for the minimum capacity value obtained:
Table 5.1: Simulation parameters defined for minimum battery requirements.
Parameter Value Battery capacity (minimum) 7 kWh Total weight 8 T Track gradient 1 % Covered distance 1 km
The results show that a battery capacity of 7 kWh is enough to allow the train to travel for 1 km resorting only to battery. Therefore this value corresponds to the minimum capacity allowed for the battery. This value defines the battery capacity throughout the remaining simulations results. In case the battery charge drops below 90% it is necessary to recharge it at the station, so that the safe arrival of the train at the next station is guaranteed. The battery charge must not drop below 10% or above 90% of the capacity, at the risk of malfunction.
70 The battery block already accounts for this restriction by terminating the simulation once these limits are crossed. Considering that a lead acid battery is used (see helianto characteristics in [3]), the batteries energy density in Table 5.2 is taken into account in order to estimate the total battery weight:
Table 5.2: Battery energy densities (source:[2]).
Battery type Energy density (Wh/Kg) Lead acid 40 Carbon zinc 36 NiMH 95 NiCad 39 Lithium ion 128
Considering an energetic density of 41 Wh/Kg for the desired battery type, the total weight of the battery corresponds to 170 Kg.
5.8 Obstacle on track scenario
An obstacle detection situation is simulated. For this scenario the train is intended to travel 1 km and the power delivered by the panels is constant and equal to 3 kW. The battery initial charge is set to 7 kWh. The train detects two obstacle during travel and must stop in between stations until the objects are no longer detected, after which it resumes travel until the next station. The obstacles are detected near kilometer 0.2 and 0.8 and block the track during 25 seconds each. The simulation results are shown in Figures 5.12, 5.14 and 5.15.
Figure 5.12: Velocity during travel - obstacle scenario.
71 Figure 5.13: Distance covered - obstacle scenario.
Figure 5.14: Power delivered and required - obstacle scenario.
Figure 5.15: Battery charge curve - obstacle scenario.
In figure 5.12 it is possible to see the simulation speed plot. The train reaches cruise velocity
72 around time unit 20. On time unit 40, when the obstacle is detected, the train brakes and stops. The obstacle detection is lost at time 65, after which the train accelerates and reaches cruise velocity again. Around time unit 160 another obstacle is detected repeating the procedure. Once it reaches final destination it decelerates again until it stops. Accordingly, in the distance plot (Figure 5.15) it is possible to see that the vehicle remains stopped on kilometer 0.2 and 0.8, where the obstacles were detected. Figure 5.14, shows the power demand and power delivered by the panels. The delivered power corresponds to 3 Kw and remains constant during the whole travel. This value allows a cruise velocity of 22.5 km/h and therefore the power demand during this phase corresponds precisely to the amount of power delivered by the panels no needing to resort to battery. Accordingly it is possible to see that the power demand peaks occur during acceleration phases and also during deceleration phase, where the peak is negative, meaning that power flowing to the battery. The battery charge plot is presented in figure 5.12 and is according to the power demand. The battery discharges during the acceleration phases and recharges during braking phase when regeneration occurs. During cruise velocity phase the battery keeps charge since the power delivered by the panels is able to support velocity values above minimum.
5.9 Cloudy Weather and Power failure scenario
The performance of the train depends on the power delivered by the panels. There are many factors influencing the solar irranciance such as year season, time of the day and weather conditions. Among these, the most unpredictable one is the weather. For instance if a cloud covers the sun, the irradiance will significantly decrease or even annul. This situation is illustrated through a simulation, where the power delivered by the panels suddenly drops, due to cloudy weather and finally annuls. Once the delivered power decrease is detected, the train decelerates until it reaches a velocity such that the panels alone are able to sustain it. When the delivered power drops to zero, the train decelerates again to minimum cruise velocity. This speed is mandatory since it guarantees that the train reaches the destination within the requirements. The velocity is supported exclusively by the battery, since the panels are delivering no power. For this scenario the train is intended to travel 1 kilometer and the power delivered by the panels is constant and equal to 3 kW until time unit 50, where a power drop occurs and the delivered power drops to 2 kW. Finally on time unit 100 the panels stop delivering power. The battery initial charge is set to 6.3 kWh (90% of total capacity). The results are shown in figures 5.16, 5.17, 5.18 and 5.19.
Figure 5.16: Velocity profile - power failure scenario.
73 Figure 5.17: Power delivered and required - power failure scenario.
Figure 5.18: Distance covered - power failure scenario.
Figure 5.19: Battery charge curve - power failure scenario.
The speed of the train along the travel is shown in figure 5.16, it is possible to see that once
74 the power decrease occurs, on time unit 50, the supported cruise velocity is re-calculated, by (5.2), dropping to 15 km/h. On time unit 100, when the delivered power annuls, the train decelerates until it reaches a a minimum cruise velocity of 10 km/h. The train remains traveling with this velocity until the target position is reached (1 km) where it brakes and stops. Accordingly, figure 5.17 shows that when the power decrease occurs, the required power also decreases because cruise velocity is lower. During power failure the required power is higher than the delivered power (which is null), so that minimum cruise velocity is sustained. In order to the train finishes the mission it is necessary that the motor resorts to battery during this phase. Figure 5.19 represents the current charge stored by the battery. It is possible to see that whenever the power demand is superior to the power delivered, the battery discharges. This verifies for the acceleration phase and also during the power failure phase, in order to support minimum velocity. The battery charge also decreases during power decrease phase, though the decay is smoother. This is not supposed to happen since the cruise velocity has been calculated in order to the panel support it without resorting to battery. However the linear model 5.2 obtained by the polyfit function, which determines the supported velocity given available power, is not completely accurate which leads to an error. In this case it is clear to verify that the supported velocity given by (5.2) is slightly higher than the actual supported velocity, which leads the battery to discharge. Figure 5.18 represents the distance traveled by the train during simulation. By comparing with Figure 5.16 it is possible to see that the traveled distance is consistent with the velocity profile.
5.10 Three stations path scenario
This section presents the results of a simulation performed for a scenario where the train is re- quired to stop in two stations. Figure 5.20 represents the track topology scenario and characteristics defined for the simulation:
Figure 5.20: Track topology - three stations scenario.
According to the scenario described in figure 5.20 the following parameters are defined through the user interface:
Table 5.3: Requirements for three stations mission.
Parameter Value Total distance 2 km Minimum velocity 10 km/h Acceleration 0.35 m/s2 Deceleration 0.8 m/s2 Track gradient [1;0 ]% Carried weight [4850 ; 6000] Kg Power delivered [3 ; 3] Kw Obstacles No obstacles
The simulation results are presented in figures 5.21, 5.22, 5.23 and 5.24:
75 Figure 5.21: Velocity profile - three stations scenario.
Figure 5.22: Covered distance - three stations scenario.
Figure 5.23: Power delivered and required - three stations scenario.
76 Figure 5.24: Battery charge curve - three stations scenario.
The trunk between station 1 and 2 has a slope of 1% and the train crosses this trunk with a total weight of 4850 kg. Since the power demand is high for such a gradient, the cruise velocity lowers to the minimum value allowed (10 km/h) as seen in figure 5.21, in order to minimize energy consumption. Still it is possible to see in figure 5.23 that the power demand that sustains this velocity remains above the delivered power. This means that the train needs to resort to battery in order to maintain minimum required velocity requirement. In fact in figure 5.24 it is possible to observe that the battery charge decreases linearly during the first trunk, not only during acceleration phase but also during constant velocity phase. It must be noted that the battery discharge caused the total charge to drop below the safety value, ensured at every station (90% of total capacity). Once the train reaches station 2 it must remain there for approximately 30 seconds in order to allow the safe entry and departure of passengers. Also, during the stop the battery must be recharged through the electric grid in order to charge back to the safety value. For this purpose the train is connected to the grid charger once arrives at the station. It is possible to see through figure 5.24 and 5.23 that while the train is stopped at the station, a power peak of 7 kW, from the electric grid, flows into the battery charging it back to the initial charge value. It is assumed that the battery is charged with a quick charging system, which is designed specifically for rechargeable electric vehicles. An average power of about 7 kW [24] can be delivered by this system which is enough, as seen, to recharge the battery back to safety value charge. Once the battery is recharged and the passengers are already in place, the train begins travel through trunk 2. This trunk has a null slope and the train carries a total weight of 6000 kg. From figure 5.21 and 5.23 it is possible to observe that the cruise velocity corresponds to nearly 15 km/h and is fully supported by the power delivered by the panels. Accordingly, the battery discharges only during acceleration phase and charges during final braking phase. It is possible to see from figure 5.22 that a total distance of 2 km has been covered within a total travel time of 11 minutes.
5.11 Time Restriction - Definition of required cruise velocity
So far the cruise velocity profile has been determined using the linear models obtained through QSS, defined by (5.2), (5.3) and (5.4). This model takes only into consideration the available power and cruise velocity is determined such that the battery energy consumption is minimized, respecting however a minimum velocity requirement. Yet no time goal is considered, and travel time depends exclusively on the amount of power delivered by the panels and ultimately on the minimum velocity restriction. This section describes a different process for defining the minimum cruise velocity, this time considering a maximum travel time requirement defined by the user. The goal pursued by this strategy is to lead the train to comply with a defined time schedule. The train must arrive at the stations within the defined schedule or before. In case the power delivered by the panels is not enough to sustain the necessary cruise velocity, the battery use is allowed and required in order to accomplish a successful mission. On the other hand, whenever the power delivered by the panels
77 allows a greater cruise velocity than required, the train arrives earlier at the station. However it must remain at the station, until schedule allows the departure for the next station. In order to comply with this goal, the system PN model is re-defined, this time including two extra key places representing respectively the travel time and traveled distance. The purpose of these places is to keep constant record on the distance that is yet to be traveled as well as the remaining maximum time to do it. This information is transferred to Simulink which determines the minimum cruise velocity at which the train must travel in order to comply with schedule. Both these places have null initial conditions since at the beginning of the simulation no time has passed nor distance has been traveled. The extra PN elements added to the model are presented in figure 5.25:
Figure 5.25: Added Petri net - timed mission.
Place 1 represents the time that has passed since the train began the journey. Each token placed represents one second. Transition 1 is the only input of this place and corresponds to a timed transition which fires on every second. Since Netlab does not include timed transition elements, transition is commanded by an external signal in Simulink that allows the firing whenever simulation time increases by one second. In figure 5.26 is represented the Simulink block that commands the firing of transition 1:
Figure 5.26: Simulink model that defines the timed firing of transition 1.
Place 2 represents the distance that has been covered since the beginning of the journey and each token within this place represents one meter. Transition 2 is the only input to this place and is commanded by an external signal in Simulink that allows the firing whenever the traveled distance increases by one meter. In figure 5.26 is represented the Simulink block that commands the firing of transition 2:
78 Figure 5.27: Simulink model that defines the firing of transition 2.
Also another block is added to the Simulink tool model with the purpose of defining a minimum cruise velocity. The block is represented in figure 5.28:
Figure 5.28: Simulink model that defines minimum cruise velocity - timed mission.
The inputs to this block correspond to number of tokens placed in places 1 and 2, transferred from the Petri net model. According to the distance and time goal defined through the user interface, the distance that is yet to be traveled is computed as well as the remaining time. The first parameter is then divided by the second one, thereby establishing the minimum cruise velocity for the vehicle. This result is updated on each second since the signal transfer from the Petri net to Simulink is real- time. It is important that this value is constantly updated in order to account for unexpected situations, namely, velocity changes that affect schedule. For instance if an obstacle is detected on the track and the train is caused to stop, the remaining time will decrease, while the distance to be covered will remain constant. This causes the minimum cruise velocity of the train to rise relatively to the value before the obstacle detection. An example is presented where the solar train is expected to comply with a schedule defined between two stations. Table 5.4 summarizes the mission requirements defined on the interface of the simulation tool:
Table 5.4: Requirements for time restriction mission.
Parameter Value Total distance 1 km Maximum time 360 s Track gradient 0% Carried weight 4500 Kg
The simulation results are presented on figures 5.29, 5.30, 5.31, 5.32 and 5.33:
79 Figure 5.29: Velocity profile - timed mission.
Figure 5.30: Minimum cruise velocity - timed mission.
Figure 5.31: Covered distance - timed mission.
80 Figure 5.32: Power delivered and required - timed mission.
Figure 5.33: Battery charge curve - timed mission.
Firstly is possible to observe in figure 5.32 that the power delivered by the panels has three distinct phases: until time unit 50, the power delivered corresponds to 3 Kw; between time units 50 and 100 the power is 2 Kw; and finally from time unit 100 until the end of the simulation the delivered power is null. In parallel with figure 5.29 it is possible to see that during phase 1 the cruise velocity corresponds to 22.5 km/h and when stepping to phase 2 decreases to 15 km/h due to the decrease on delivered power. During phase 3 cruise velocity holds the value of 8 km/s which corresponds to the minimum cruise velocity so that the train reaches the goal within the 360 seconds. The minimum cruise velocity curve is presented in figure 5.30 and is analyzed as follows: During acceleration phase the curve grows since the velocity is still low. Once cruise velocity is reached (22.5 km/h) and because it is higher than the minimum required velocity, the minimum velocity decreases linearly. This happens because the distance to the target decreases faster than it would if the train was traveling at minimum cruise speed. Thus whenever the train travels at a higher velocity than the minimum, it decreases. On time unit 50 velocity decreases to 15 km/h which is still higher than the minimum velocity and therefore minimum cruise velocity keeps decreasing although with a lower slope than on phase 1. It is convenient to define an absolute minimum traveling velocity so that the train reaches the station with an acceptable velocity. Finally from phase 3 until it stops, the train adopts the minimum velocity value, since the panels are delivering no power. This velocity decreases as the train approaches the final goal assuming null value once the train reaches the target. According to this it s possible to see that the battery charge discharges during acceleration phase
81 and also phase 3 and charges during deceleration phases. The time goal has been accomplished, as shown in figure 5.31. It is possible to see that 1 km target was reached at time 360 s as required.
82 6 Conclusions and Future Work
83 This thesis describes a simulation tool for a preliminar viability assessment of the Helianto solar train project. The main infrastructure required by the Helianto system was modeled as a DES, represented by Petri nets. Operational requirements were accounted by a supervisory controller designed using standard Petri nets control techniques, namely specifying linear constraints involving the marking of places and transitions in the Petri net. The dynamics of the Helianto train used the QSS toolbox which allows a realistic modeling of the key components of the train and infrastructure, namely vehicle body, electric motors, gear system, and battery power supply. QSS also models realistic dynamics effects such as aerodynamic drag, friction of rails, gravitational forces, and inertia. The DES modeling was implemented by the Netlab toolbox which allows the design and analysis of the Petri net systems and its integration with arbitrary Simulink components. The train was modeled after a collection of independent subsystems, each of them represented by a Petri net. Each net was tested and analyzed individually. Properties such as liveness, boundedness, conservativeness, and reachability were verified. All these subsystems were also found to be live and deadlock free. Additionally, the overall system Petri net was analyzed to reach similar conclusions. The performance of the train was evaluated based on energy consumption, travel time, and veloc- ity obtained for multiple scenarios, namely: obstacle on the track, power failure, multi-stations travel, and time schedule constraints. The influence of variables such as weight and road gradient was studied, and conclusions were drawn for the maximum feasible values for these variables. Also, constant acceleration and deceler- ation values were assessed with the purpose of minimizing both energy consumption and increasing regeneration respectively. A minimum battery energy capacity was determined that guarantees the train reaches the final destination station, even if the solar panels are not delivering enough power and considering maximum weight and gradient conditions. The results obtained are consistent with the physical intuition, showing that the velocity achieved by the train allowed the motion to be sustainable by the panels alone, resorting to batteries only during the acceleration phase, when a power peak demand occurs, or when a power failure occurs. The travel time factor is also considered, that is, the supervisor ensures that the train is able to meet a feasible pre-defined schedule. Additionally, if an obstacle is detected, the train stops, resuming travel once that obstacle is no longer detected and finishing the mission successfully. The simulation tool developed turned out to be a practical and adaptable tool that allows the simulation of multiple types of vehicles, multiple track features, different energy sources, as well as, different performance requirements. Moreover, it allows the preliminary assessment of projects on solar vehicles, delivering trustworthy results regarding project feasibility and necessary requirements. In order to test and simulate other types of vehicles and operating conditions it is possible to simply integrate new blocks within the simulation loop, so that the new desired features are included within the model. For instance, if a different vehicle is being tested, then the vehicle block in the Simulink model can be replaced by a new block which includes the new desired characteristics, allowing the assessment of that particular vehicle for a possibly different performance goal. Future work may in- clude (i) the integration of additional subsystems, either modeled as Petri nets or using other Simulink compatible packages, (ii) the development of user-friendly interfaces to allow the testing of alternative scenarios, and (iii) the testing of hardware-in-the-loop scenarios, with the Simulink system interfacing external hardware controlled according to the Petri net model developed.
84 Bibliography
[1] “Solar train,” Wikimedia Foundation, Inc., Accessed December 2011. [Online]. Available: http://www.wikipedia.org [2] Allaboutbatteries, Accessed April 2012. [Online]. Available: http://www.allaboutbatteries.com/ Battery-Energy.html [3] “Helianto project,” Instituto Superior Tecnico, TU Lisbon. [Online]. Available: http: //helianto.ist.utl.pt/ [4] “Petri net toolbox: Netlab,” Institute of Automatic Control, RWTH Aachen Univer- sity, 2008. [Online]. Available: http://www.irt.rwth-aachen.de/en/fuer-studierende/downloads/ petri-net-tool-netlab/ [5] “QSS-Toolbox,” Swiss Federal Institute of Technology Zurich. [Online]. Available: http: //www.idsc.ethz.ch/Downloads/qss [6] “Solar Car Racing,” Wikipedia, Accessed January 2012. [Online]. Available: http: //en.wikipedia.org/wiki/Solar car racing [7] “World Solar Chalenge,” Wikipedia, Accessed December 2011. [Online]. Available: http: //en.wikipedia.org/wiki/World Solar Challenge [8] M. G. Simaes, N. N. Franceschetti, and J. C. Adamowski, “Drive System Control and Energy Management of a Solar Powered Electric Vehicle,” IEEE Control Systems Magazine, 1998. [9] N. Jinrui, S. Fengchun, and R. Qinglian, “A Study of Energy management System of Electric Vehicles,” IEEE, 2006. [10] “Belgium Solar train,” Enfinity Corporation, Accessed December 2011. [Online]. Available: http://www.enfinitycorp.com/downloads/news-releases/europes-first-green-train
[11] C. G. Cassandras and S. Lafortune, Introduction to Discrete Event Systems, 2nd ed. Springer, 2008. [12] S. Bogdan, F. Lewis, Z. Kovacic, and J. M. Jr., Manufacturing Systems Control Design: A Matrix Based Approach. Springer, 2006.
[13] L. Warrington and J. A. Jones, “Representing Complex Systems within Discrete Event Simulation for Reliability Assessment,” 2003 proceedings Annual Reliability and maintainability Symposium, 2003. [14] R. Davidrajuh, “Developing a New Petri net Tool for Simulation of Discrete Event Systems,” Second Asia International Conference on Modeling and Simulation, 2008.
[15] X.-R. Cao and Y.-C. Ho, “Models of Discrete Event Dynamic Systems,” IEEE Control Systems Magazine, 1990. [16] L. Guzzela and A. Sciarretta, Vehicle Propulsion Systems: Introduction to Modeling and Optimization. Springer-Verlag Berlin Heidelberg, 2007.
[17] L. Guzzela and A.Amstutz, The QSS Toolbox Manual. Swiss federal institute of technology Zurich, [Online], 2008.
85 [18] J.Moody, K.Yamalidou, P.Antsaklis, and M.Lemmon, “Feedback control of Petri Nets based on place invariants,” Proceedings of the 33rd Conference on Decision and Control Lake Buena Vista, 1994.
[19] “World’s most efficient solar panel,” The independent, Accessed April 2012. [Online]. Available: http://www.independent.co.uk/environment/ worlds-most-efficient-solar-cells-ready-for-use-in-the-uk-2200508.html [20] Solar Radiation data, Accessed January 2012. [Online]. Available: http://www.soda-is.com
[21] J.M.S.Andre, Transporte Interurbano em Portugal. Lisbon: IST Press, 2006, vol. 2. [22] Efacec, Accessed April 2012. [Online]. Available: http://www.efacec.pt/PresentationLayer/ ResourcesUser/Catalogos202012/Mobilidade%20Electrica/SA68I1102B1 QC50 EN.pdf [23] Mobi, Accessed April 2012. [Online]. Available: http://www.mobie.pt/o-carregamento
[24] “Formas de carregamento de veiculos electricos em portugal,” Mobi - Mobilidade electrica,´ Accessed April 2012. [Online]. Available: http://www.cm-loures.pt/doc/Ambiente/RedeMobie.pdf [25] “Qss-toolbox,” 2008. [Online]. Available: http://www.idsc.ethz.ch/Downloads/qss
86 A Appendix A
A-1 A.1 Simulation Tool Manual
The simulation tool consists of a Simulink model (.mdl file) where the performance of a solar vehicle is simulated and described based on parameters defined by the user. The whole system is controlled by a supervisory controller in order to ensure all system requirements are complied, along with energy consumption optimization. The goal is to analyze the performance of the vehicle regarding to range of velocities achieved, travel time and energy requirements and consumption. This tool makes it possible for users to evaluate the realistic feasibility of the project and performance of the vehicle before the conditions specified. This allows the user to modify and adjust parameters so that the desired requirements are met and realistic vehicle parameters are defined for that purpose. Also the Simulink tool model is easily adapted to user modifications since the Matlab/Simulink platform is easily integrated with other toolboxes and functionalities. The model is composed by Simulink library blocks including blocks from two specific toolboxes: Netlab [4] and QSS [25]. The model is represented in figure A.1:
Figure A.1: Simulation tool model.
The supervisory controller block is part of Netlab toolbox and represents a Petri net. This block is capable of receiving input signals from Simulink and also to transfer place markings to Simulink. For this purpose the Petri net is composed by input and output places. Each input place marking is associated with one input signal and assumes its value. This is used for defining the firing of transitions within the supervisor. Each transition is then associated with an input place and fires whenever a token is placed there. In its turn, the marking of each output place is associated with each output signal, and its marking is transferred do Simulink. Through this communication the block is able to establish control over the external blocks at the same time that receives feedback. The user is able to define the simulation parameters through an intuitive interface (mask). The vehicle components have their own masks where the parameters
A-2 concerning motor, batteries and vehicle are defined. The global mask is represented in figure A.2:
Figure A.2: Simulation tool global interface.
Through the global mask the user is required to define: track topology (length and gradient), location of intermediate stations, weight carried on each trunk, performance requirements such as minimum cruise velocity and acceleration/deceleration values. It is also possible to define the location of obstacles on the track and the power delivered by the panels during the travel of each trunk. The following sections describe each block, included in model, as well as the functions associated with each one.
A.1.1 Vehicle block The vehicle block is part of QSS toolbox and a detailed description can be found in [17]. The main function of this block is to determine the required torque at the wheels such that the velocity and acceleration requirements are met by the vehicle. The vehicle specifications can be defined on the blocks interface presented in figure A.3:
A-3 Figure A.3: Vehicle block interface.
Since QSS is a discrete toolbox, the input and output variables of vehicles block are also discrete with a step time of 1 second [17].
A.1.2 Simple transmission system block The simple transmission system block is part of QSS toolbox and a detailed description can be found in [17]. The main function of this block is to provide the transmission of mechanical work between the vehicle and the electric motor. Fixed relations are set between torque and rotational speed, and transmission losses are taken into account. The specifications can be defined on the blocks interface presented in Figure A.4:
A-4 Figure A.4: Simple transmission block interface.
A.1.3 Electric motor block The electric motor block is part of QSS toolbox and a detailed description can be found in [17]. The main function of this block is to determine the power required by the motor in order to sustain the demanded torque. The motor specifications can be defined on the blocks interface presented in figure A.5:
A-5 Figure A.5: Motor block interface.
A.1.4 Battery block The battery block is part of QSS toolbox and a detailed description can be found in [17]. The main function of this block is to determine the evolution of amount of energy stored in a battery, according to the power demand. The battery specifications can be defined on the blocks interface presented in figure A.6:
A-6 Figure A.6: Battery block interface.
A.1.5 Location tracking block The main function of this block is to determine, for each step time, the location of the train according to the topology defined on the global interface. The content of the block is represented in figure A.7:
Figure A.7: Location tracking block.
In order to keep track of the vehicles position the block receives the signal corresponding to the velocity and integrates it, obtaining the travelled distance. Along with the track topology information and deceleration value, the block calculates the distance until the next station and determines the time instant at which the train must brake in order to stop at the station. The stop command signal is then sent to the supervisory controller. The input and output variables are resumed on table A.1:
A-7 Table A.1: Input and Output signals and parameters required for Location tracking block.
Inputs Outputs Parameters Velocity [m/s] Stop command Station Location Deceleration [m/s2]
For this block, the output signal corresponds to an input signal of the supervisor, which means that there is a transition associated with this signal, within the supervisor that fires whenever the signal is active.
A.1.6 Battery state control The main function of this block is to define, for each step time, the charge state of the battery. Signals are sent to the supervisor defining the current state of the battery:
• Above/below minimum value • Above/below safe value • Charging/discharging • Idle
The content of the block is represented in figure A.8:
Figure A.8: Battery state control block.
The input and output variables are resumed on table A.2:
A-8 Table A.2: Input and Output signals and parameters required for Battery charging control system.
Inputs Outputs Parameters Power required [W] Battery charge drops below minimum operational threshold Battery capacity [Kwh] Battery charge [Kwh] Battery charge rises above minimum operational threshold Battery charge rises above safety threshold Battery charge drops below safety threshold
A.1.7 Battery charging control The main function of this block is to define, for each step time, the power demanded/sent to the battery. The content of the block is represented in figure A.9:
Figure A.9: Battery charging control block.
In case the vehicle engine is working as a motor (during cruise velocity or acceleration phase), the power requested to the battery corresponds to the difference between the motor demand and the power delivered by the panels. Whenever the engine is working as a generator (deceleration phase), all the power coming from the engine is sent to the battery. In case the battery charge drops below the safety defined value, charge signal is sent to the supervisory controller which in turn ensures the batteries recharge at the next station. Also if the battery charge drops below minimum operational threshold, the supervisor disables further discharge. The input and output variables sent and received from the supervisor are resumed on table A.3:
Table A.3: Input and Output signals and parameters required for Battery charging control.
Inputs Outputs Panels [W] Battery demanded power [W] Motor required power [W] Disable discharge signal
A.1.8 Obstacle detection laser range finder block This block defines a Boolean signal which represents the detection of an obstacle by the laser range finder. The initial instant and duration of the positive flank are defined according to the param- eters defined on the global interface. The content of the block is represented in figure A.10:
A-9 Figure A.10: Laser range finder block.
Two output signals are sent to the supervisor: rise and fall of the signal, representing respectively the detection and loss of the obstacle. The input and output variables are resumed on table A.4:
Table A.4: Input and Output signals and parameters required for Laser range finder block.
Inputs Outputs Parameters Detection signal Obstacle location [m] Detection loss signal Duration [s]
A.1.9 Panel block This block defines a signal which represents the current power delivered by the panels. The amplitude of the signal is defined through the global interface. The content of the block is represented in figure A.1.13:
Figure A.11: Panel block.
The output signal are sent to the supervisor corresponds to the discretized power delivered by the panels. This value must be transferred as an integer since is corresponds to the number of tokens placed in the correspondent input place withi the supervisor. The input and output variables are resumed on table A.5:
Table A.5: Input and Output signals and parameters required for Panel block.
Inputs Outputs Parameters Panel power output [W] Power delivered [W] Duration [s]
A.1.10 Weight sensor block This block defines a signal representing the weight carried by the vehicle during travel at each step time. The amplitude of the signal is defined through the global interface. The output signal is sent directly to the vehicle block.
A.1.11 Timed Petri net block Since Netlab does not support timed Petri nets, this block plays the role of a timed transition which fires on each second. The content of the block is represented in figure A.11:
A-10 Figure A.12: Timed Petri net block.
A signal is generated consisting on the rise of the clock signal which increases each second. The signal is then sent to the supervisor enabling the firing of a transition on each second.
A.1.12 Supervisory controller The whole system is controlled by the supervisory controller block which main objective is to manage all consumption devices on the vehicle in order to ensure the mission is carried successfully. The supervisory controller corresponds to the supervised system Petri net represented in figure A.13:
Figure A.13: Petri Net model of supervised system.
For the sake of simplicity the supervisor model presented does not include the input places associ- ated with each transition. However, for the record, each transition is associated with one single place that commands each firing. The supervisor controls all blocks in the model through controlling signals connected to and from each block. The supervisory controller defines the cruise velocity at which the vehicle moves so that the panels are able to sustain it, without resorting to batteries, minimizing battery energy consumption. For this purpose the power delivered by the panels is quantified into to- kens, more specifically one token corresponds to 1 kW. This value is transferred, in each second, to a place in the Petri net. The desired cruise velocity is then obtained, in the same Petri net, based on the available power and also quantified into tokens. The velocity control block attributes a corresponding velocity to the quantified amount of tokens placed on the place representing the desired velocity. This value is then sent to th vehicle block.
A-11 A.1.13 Velocity control block The velocity control block is responsible for defining a velocity and acceleration for the vehicle, at each step time. This block is controlled by the supervisory controller in order to meet the requirements defined by the user. The content of the block is represented in figure A.12:
Figure A.14: Velocity control block.
The block receives as input the control signals from the supervisory controller block and outputs the feedback signals and also velocity and acceleration. Since QSS blocks operate only with discrete signals, velocity and acceleration values must be discretized with a sample time of one second. The control signals and output signals are listed on table A.6:
Table A.6: Input and Output signals and parameters required for Velocity control block.
Inputs Outputs Parameters Accelerating signal Velocity [m/s] Minimum velocity [m/s] Decelerating signal Reached cruise velocity signal Acceleration value [m/s2] Cruise velocity signal Stopped signal Deceleration value [m/s2] Desired velocity (tokens) Cruise velocity decrease signal Stopped signal Cruise velocity increase
The velocity control block attributes a corresponding velocity to the quantified amount of tokens placed on the place representing the desired velocity. The accelerating and decelerating signals when active, set the phase in which the vehicle is moving. If the vehicle is accelerating then the block in- creases velocity linearly assuming a slope according to the defined acceleration value. Once the vehicle reaches the desired velocity, a feedback signal reports to the supervisor, which in turn acti- vates cruise velocity phase. In case the decelerating signal is active, then the velocity control block decreases velocity linearly according to the defined deceleration value. In order to comply with mini- mum velocity requirement, the velocity control block holds this value as the minimum cruise velocity
A-12 allowed for the vehicle. In case the supervisor defines a lower desired cruise velocity sustained by panels this value is disregarded.
A-13 A-14