2012 KA Meeusen

8/9/2019 2012 KA Meeusen

http://slidepdf.com/reader/full/2012-ka-meeusen 1/89

Bachelor Final Project

Application of supervisor synthesis tothe design of Cruise Control

K.A. MeeusenSE420693

August 29, 2012

Eindhoven University of TechnologyDepartment of Mechanical Engineering

Systems Engineering GroupSupervisors:

Dr.ir. J.M. van de Mortel-FronczakDr.ir. M.A. Reniers

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen


SummaryWithin the automotive industry many electronic systems are used to control thebehavior of vehicles such as the Cruise Control function, vehicle stability functionand traction control function. All these functions are based on events happeningwithin or acting on the vehicle. These events can be time driven or discrete and bothcan be used within the same system. In order to control these events a supervisoris used. The supervisor is a product of the synthesis procedure according to thesupervisory control theory. The description of the components, called plants, andthe description of the desired behavior, called requirements, will after synthesisresult in a supervisor.In this project the applicability of Supremica to design supervisors for discrete-eventautomotive systems is examined. A comparison is made with a master project inwhich different tools were used for the same purpose. After the models of the CruiseControl are completed a translation methode is to MatLab Stateow is proposed.This translation translates the Supremica output into a Stateow model which canbe used for further processing.The Cruise Control function in Supremica is constructed according predened sys-tem requirements with extended nite automata. These system requirements are

the requirements which the Cruise Control function needs to fulll. Within theplants variables are used as observers to represent a state. These observers are usedin other requirements where the are used in guards. The guards placed on the tran-sitions between the states can allow or block a event from occurring. The guards aredened by variables which are updated by actions. Synthesis of the models resultedin a supervisor.In a previous project a translation from Scide in which the supervisor has been syn-thesized to Matlab Stateow is made. Since Supremica cannot export the output-lefor the supervisor in the required form, an attempt is done to create a translation-lein Windows Powershell. In this translation le the Supremica output-le is trans-

lated into a Stateow model. The difficulty is that Stateow works with a graphicalrepresentation and the position of the states are important for the hierarchy. In or-der to build this hierarchy, the hierarchy is examined and the meaning of the valuesin the output le need to be traced in order to be transformed. Unfortunately notall the meanings of the values could be found. This resulted in a translation lewhich is not nished yet.The comparison between the master project and this project is preformed for themodeling of the Cruise Control function and the translation to Matlab Stateow.

i

8/9/2019 2012 KA Meeusen


The main differences between the models are the number of models. The Supremicarequirements can, due to the use of the variables, be made compact. In the Scidemodels, a larger number of requirements is required to describe the same behavior.The second difference is the structure of the models. So the model describing theCruise Control Set Speed is made different.Besides the translation le another way to translate the Supremica output to State-ow is presented but not executed. The initial idea for the translation le was tomake a Stateow le in which a column of automata, modeled as AND-states, areplaced. Within these automata rows of OR-states are placed. All the states areplaced at constant intervals. With the help of Stateow Application ProgrammingInterface (API) the translation is likely be to made since the API has been usedbefore with success.The biggest disadvantage of Supremica is the reduction of the extended nite au-tomata to nite state automata before synthesis can be performed. The variables

are removed from the modeled plants and translated into plants themselves. Whenthe synthesis is completed the variables are not reintroduced. This means that whena state can have 5 variable values, the state is translated to ve states in the super-visor. The result is a supervisor which can be reduced in size by reintroducing thevariables.After naming the advantages and disadvantages the applicability of Supremica isreviewed. The conclusion on Supremica as a tool to design supervisor for the auto-motive industry is that the program can be used for small to medium sized systems.However, the reduction from extended nite automata to nite state automata is notideal for further processing with other tools. Within Stateow, variables are used

as observers for transitions like the modeling in Supremica. The reduction makes itdifficult to perform a translation of the supervisor to Matlab Stateow. This makesSupremica not the ideal tool to be used for the design of discrete-event systemsfor vehicles. When the reintroduction of the variables is completed and there is aworking translation to Stateow, Supremica can be a tool to design supervisors forthe automotive industry.

ii

8/9/2019 2012 KA Meeusen


SamenvattingIn de automotive industrie worden verschillende elektronische systemen gebruiktom het gedrag van voertuigen te controleren, zoals de Cruise Control functie en detractie controle. Al deze functies zijn gebaseerd op gebeurtenissen die gebeuren inen rondom het voertuig. Deze gebeurtenissen kunnen zowel tijds-gedreven zijn alsdiscreet en beide kunnen binnen hetzelfde systeem voorkomen. Om de discrete syste-men te reguleren kan er gebruik worden gemaakt van een supervisor. De supervisoris een product van een synthese procedure volgens de de supervisory control theorie.

Het beschrijven van de componenten, plants genaamd, en de beschrijving van hetgewenste systeem gedrag, gemodelleerd in eisen, resulteren samen na synthese ineen supervisor.In dit project wordt de toepasbaarheid van Supremica voor het ontwerpen van super-visors voor discreet-event systemen onderzocht, hiervoor is de Cruise Control functiegekozen als case study. Er wordt een vergelijking gemaakt met een master projectwaarin andere programma’s worden gebruikt voor hetzelfde doel. Nadat de mod-ellen zijn gemaakt wordt er een vertaling naar het door DAF Truck N.V. gebruikteontwikkelomgeving MatLab Stateow toegepast. Binnen deze ontwikkelomgevingkan verdere ontwikkeling en simulatie plaats vinden.

De Cruise Control functie in Supremica is gemaakt in extended nite automatavolgens gedenieerde systeem eisen. Deze systeem eisen zijn de eisen waaraan deCruise Control moet voldoen. Binnen de plants wordt gebruikt gemaakt van vari-abelen, welke gebruikt worden om de toestanden van het systeem te representeren.Deze variabelen kunnen in de eisen worden gebruikt om bij bepaalde systeem toe-standen gebeurtenissen toe te staan of juist te verbieden door middel van guards.De guards worden gedenieerd door middel van de variabelen, de variabelen kunnenvan waarde veranderen door acties welke de variabelen kunnen updaten. uiteindelijkzal de synthese van de plants en eisen samen leiden tot een supervisor.In het master project is er een vertaling van de gemaakte modellen in Scide gedaannaar MatLab Stateow. Omdat Supremica niet dezelfde output kan aanmaken alsScide is er een poging gedaan om een vertaling te maken naar MatLab Stateow doorgebruik te maken van Windows Powershell. In deze vertaling wordt de Supremicaoutput vertaald naar een Stateow model. Stateow werkt met een grasche rep-resentatie waarbij de positie van de states belangrijk is voor de hiërarchie. Omde omzetting van Supremica naar Stateow te maken moest dus de hiërarchie vanStateow worden achterhaald en kunnen worden nagebouwd. Echter niet alle ben-odigde waarden voor de omzetting zijn achterhaald waardoor er nog geen correcte

iii

8/9/2019 2012 KA Meeusen


vertaling plaats heeft gevonden.De vergelijking tussen het master project and dit project is gedaan tussen de mod-ellen en de omzetting naar MatLab Stateow. De grootste verschillen tussen demodellen zijn de aantallen. Door het gebruik van variabelen is het aantal modellen

van de Supremica modellen kleiner. Het tweede verschil is de structuur van de mod-ellen. Zo zijn onder andere de modellen die de Cruise Control Set Speed beschrijvenanders gemodelleerd.Naast de gewenste vertaling van Supremica naar Stateow is er een tweede maniervoorgesteld welke niet is uitgevoerd. Het idee achter de omzetting van Suprem-ica naar Stateow bestaat uit het maken van een kolom van automata, welkegemodelleerd worden als OR-states. In deze automaten worden rijen van AND-state geplaatst. Alle automaten worden onderling op een vaste afstand geplaatst.Door deze manier van plaatsen wordt voldaan aan de Stateow hiërarchie. Bij devoorgestelde methode wordt met behulp van de Stateow Application Programming

Interface (API) de vertaling gemaakt volgens de rij-kolom methode. De vertalingmet behulp van de API is al eerder gebruikt en daarom is de kans op een goedresultaat aanwezig.Het grootste nadeel van Supremica is de reductie van extended nite automatanaar nite state automata voordat er synthese plaats vind. De variabelen wordenverwijderd uit de gemaakte modellen en omgezet naar aparte plants. Wanneer desynthese gedaan is, worden de variabelen echter niet terug geïntroduceerd. Ditbetekent dat wanneer een state 5 verschillende variabele waarden kan hebben, devariabelen worden verwijderd en omgezet naar een extra plant met vijf verschillendestates. Dit werkt ook door in de supervisor. Het resultaat is een supervisor welke

in grootte gereduceerd kan worden door de variabelen te herintroduceren.Na het benoemen van de voor- en nadelen wordt de toepasbaarheid van Supremicabeoordeeld. De conclusie voor het gebruik van Supremica, voor het ontwerpen vansupervisor voor de automotive industrie, is dat het gebruikt kan worden voor kleinetot middel-grote systemen (tot 20 automata). Echter, het verwijderen van de vari-abelen is niet ideaal omdat het de vertaling naar andere programma’s bemoeilijkt.Binnen Stateow worden variabelen gebruikt om de toestand van systemen aan teduiden, net als tijdens het ontwerpen van de Supremica modellen. De verwijderingvan de variabelen maakt het daarom moeilijk om de omzetting naar MatLab State-ow te maken. Om deze reden is het niet ideaal om Supremica te gebruiken voor het

ontwerpen van supervisors, zolang er niets gedaan wordt aan het herintroducerenvan de variabelen.

iv

8/9/2019 2012 KA Meeusen


Contents1. Introduction 1

1.1. The Cruise Control Function . . . . . . . . . . . . . . . . . . . . . . . 21.2. Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Cruise Control in Supremica 72.1. Supervisory control theory . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Introduction in Supremica . . . . . . . . . . . . . . . . . . . . . . . . 92.3. System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4. Modeling the requirements . . . . . . . . . . . . . . . . . . . . . . . . 242.5. Supervisor synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3. Translation to Stateow 373.1. Output format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2. Stateow input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3. Translation le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4. Evaluation and Comparison 474.1. Comparison of the models . . . . . . . . . . . . . . . . . . . . . . . . 474.2. Comparison of translation . . . . . . . . . . . . . . . . . . . . . . . . 504.3. Applicability of Supremica . . . . . . . . . . . . . . . . . . . . . . . . 504.4. Conclusion on Supremica . . . . . . . . . . . . . . . . . . . . . . . . . 53

5. Concluding remarks 555.1. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Bibliography 59

A. XML code 61

B. Translation File 69

i

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen


1. IntroductionWithin the automotive industry many electronic systems are used. A number of these systems are used to control the behavior of vehicles such as the Cruise Controlfunction, vehicle stability function and traction control function. The Cruise Controlfunction will maintain a set speed by the driver so the accelerator pedal can bereleased without a throttle response. Different components and events can activateor deactivate the Cruise Control. All these functions are based on events happeningwithin or acting on the vehicle. These events can be time driven or discrete and both

can be used within the same system. Within the report the Cruise Control functionis taken in examination. The Cruise Control function has both discrete- eventsand is time driven as well. For instance the PID controller of the Cruise Controlis time driven and the enabling and disabling events are typically event driven.To control and allow certain discrete events under certain conditions a supervisorcan be created by the supervisory control theory. To create this supervisor severalprograms are available in which the discrete events can be modeled, analyzed andnally synthesized into a supervisor. In this report, the applicability of Supremica todesign a supervisor for a discrete-event system, such as the Cruise Control functionis examined. To examine the applicability of Supremica for designing supervisors

of automotive systems, a model of the Cruise Control function needs to be created.This model, a simplied model of the Cruise Control function whereby only thediscrete events of the Cruise Control function are implemented. The time-drivenevents, such as the PID-controller which controls the vehicles velocity, are not partof the described system used for the model. With the modeling of the Cruise Controlin discrete-events completed an analysis of the plants and requirements is done.This means that the plants and requirement made in Supremica are checked forcontrollability and non-blocking. This is followed by the possibility to create asupervisor by synthesis. For the usage of the supervisory control theory in theautomotive industry, the model has been translated to MatLab Stateow whichcan be used for simulation and analysis in combination with a larger time drivenenvironment. In order to translate the output of Supremica to Matlab Stateow, anattempt for a translation has been made. With this translation the models madeby Supremica should be translated to a Stateow chart model. The results of thetranslation is discussed and compared to [Hei12]. Within this earlier project, asimplied model of a Cruise Control function has been made as well but with adifferent program. In this report, a direct comparison between the models is made.After the list of advantages and disadvantages of Supremica, the applicability of Supremica as a tool for design of supervisors for automotive usage is examined.

1

8/9/2019 2012 KA Meeusen


1. Introduction

In the rst Chapter, the Cruise Control function is explained, followed by the re-search objectives. In the second chapter, the supervisory control theory is describedand a manual about the working of Supremica is presented and an example is given.After the examples the system requirements of the Cruise Control function are pre-sented, followed by the made models of the Cruise Control function. In the thirdchapter the translation to MatLab Stateow is covert. The Supremica output iscovert and the Stateow input structure is described. In Chapter four, the com-parison between the master project and this project is covert. The models and thetranslation methods are both compared to each other. In the fth and nal chapterthe concluding remarks and recommendations are given.

1.1. The Cruise Control Function

In this section, the working of the Cruise Control function is described. The CruiseControl function of a motor vehicle maintains the vehicles speed. This is donewithout the driver having to interfere by lifting or pressing the throttle. The CruiseControl function of the vehicle maintains a set speed and will take over the throttle.By adjusting the throttle the engine performance is inuenced in such a way thatthe vehicles speed remains constant.In Figure ?? , a general overview of Cruise Control environment with other compo-nents related to the Cruise Control function is shown as presented in [Hei12] and[Wij08]. Note that not all the components, such as the clutch, are included. Theoverview is a schematic overview of the essential components needed for the Cruise

Control to work.In the center of the overview stands the Cruise Control. In order to work properlythe Cruise Control function requires two types of input. The rst type of input is thevehicle data. Some of the vehicle data included are the vehicle speed and the states/ conditions of the engine, brakes and engine brake. The second type of input is thedriver input. The driver input includes the buttons on the steering wheel which areused to activate the Cruise Control and to set or adjust the CCSS (Cruise Controlset speed). The commands from the buttons are sent, with the input from the otherswitches in the vehicle, to the Input Arbitration. The input arbitration distributesthe signals to the correct components. The accelerator pedal is controlled by the

driver as well, but is displayed separately. The accelerator pedal can overrule theCruise Control in case of overtaking. If the accelerator pedal is used for a longertime, the Cruise Control will shut itself down since the driver has taken over thethrottle control.The various safety systems of the vehicle do have inuence on the Cruise Controlfunction as well. The variable speed limiter and the downhill speed control aretwo systems which have inuence on the vehicles (maximum) speed. Therefore theCruise Control function must communicate with these systems.

2

8/9/2019 2012 KA Meeusen


1.1. The Cruise Control Function

Figure 1.1.: Schematic view of the the Cruise Control environment

The main output of the Cruise Control function is the Fuel Request. The fuelrequired to maintain the current speed or accelerate to the new set speed is sentto the Fuel Arbitration. The Fuel Arbitration receives the fuel request from theaccelerator pedal and variable speed limiter as well. The Fuel Arbitration decideswhich of the requests is used to power the engine. The acceleration pedal must beable to overrule the Cruise Control if the acceleration pedal requires more fuel thanthe Cruise Control function. The vehicle speed cannot exceed the variable speedlimiter, so if the speed limiter speed is reached the fuel supply to the engine mustbe reduced.

The driver input for the Cruise Control of a DAF truck is done by three buttonson the steering wheel. These buttons are shown in Figure 1.2. Each of the but-tons has three positions; upside pressed, neutral and downside pressed. The left

button, in this report referred to as SetSpd_Button, sets the CCSS equal to theactual vehicle speed or deactivates the Cruise Control. The middle button, re-ferred to as Resume_Button, reactivates the Cruise Control and the CCSS whichwas set before deactivation is resumed. The lower position of the button deacti-vates the Cruise Control, just like the left button. The button on the right, theChange_Speed_Button, will change the CCSS by 0.5 km/h in both directions.

In Figure 1.3, from [Hei12, Wij08], the highlighted Cruise Control box from Figure isshown again, but more detailed. The Cruise Control exists of two main components,

3

8/9/2019 2012 KA Meeusen


1. Introduction

Figure 1.2.: The control buttons on the steering wheel

The CC_Control_Logic and the CC_Speed_Controller.The CC_Control_logic receives the commands from the driver. Together with thevehicle data and the fuel requests from the accelerator pedal, the CC_Control_Logiccontrols the CCSS-value and the activation of the Cruise Control. The CC_Control_Logic can activate the Cruise Control by activating the CC_Speed_Controller. Inorder to activate the CC_Speed_Controller a number of requirements must be ful-lled. These requirements require the vehicle data and driver commands as input forthe CC_Control_Logic. The CC_Control_Logic works with discrete events and istherefore a discrete-event controller.The CC_Speed_Controller is the part of the Cruise Control that controls the ve-hicles speed. If the Cruise Control is activated the actual vehicle speed must be-come the CCSS. The PID-Controller in the CC_Speed_Controller will adjust thefuel request of the Cruise Control so the CCSS will be reached and maintained af-terwards. To do so the actual speed and the CCSS are needed as input for theCC_Speed_Controller. The CC_Speed_Controller works with time-driven eventsand is therefore a continuous time-driven controller.In this report, the Cruise Control is taken as an example to evaluate the applicability

of Supremica for discrete-event systems. Therefore the focus is on the event drivenCC_Control_Logic.

1.2. Research Objectives

The current development procedure of DAF trucks N.V. is described by [Hei12]. Inshort the CC_Control_Logic is made by manual model based engineering (MBE).

4

8/9/2019 2012 KA Meeusen


1.2. Research Objectives

(?? )

Figure 1.3.: Internal Cruise Control system

The models coming out of the MBE are modeled in MatLab Stateow. MatLabStateow is a part of MatLab Simulink. The Stateow models are placed in aSimulink environment and tested under predened conditions. Afterwards adjust-ments to the models are made and tested again. This iterative form of developmentcan be time consuming. In this report, and in [Hei12] as well the development of a discrete event system is done by applying supervisor synthesis according to thesupervisory control theory . In Figure 1.4, a graphical representation of the develop-ment procedure is shown. For this report, the plant and requirements are modeledand synthesized in the program Supremica. With the models and a supervisoravailable, a translation to MatLab Stateow can be made. Stateow models can besimulated and validated. The supervisor synthesis should shorten the developmentprocess compared to the current DAF method.

5

8/9/2019 2012 KA Meeusen


1. Introduction

Figure 1.4.: Desired development scheme for discrete event controllers usingSupremica

1.3. Outline

The goal of this report is to evaluate the applicability of Supremica to design of supervisors for discrete-events systems in vehicles. To evaluate the applicability,the Cruise Control function has been chosen as a case shown. The Cruise Controlsystem and its working environment are explained in the previous section.Besides the evaluation of Supremica, a comparison with [Hei12] is made. Withinthat project SE synthesis and analysis tools have been used for the same purpose.The models made in [Hei12] are compared to the made models in this report anddifferences are highlighted. The translation from Supremica to Stateow is doneby an automatic translation, whereas in [Hei12] a manual translation is preformed.These two methods will be compared as well.In the following chapter the Supervisory control theory and usage of Supremicaare explained. A description of the modeling procedure in Supremica is given and

claried by an example. The third chapter contains the comparison of the modelsmade in the synthesis tools from this report and [Hei12]. In the end of this chapterthe applicability of Supremica is examined and explained. In the fourth chapter thetranslation from Supremica to MatLab Stateow is shown and the working methodexplained. A comparison between the automatic and manual translation is made aswell.

6

8/9/2019 2012 KA Meeusen


2. Cruise Control in SupremicaIn this chapter the Supremica model of the Cruise Control function is described.The Cruise Control function is a simplied model of a real Cruise Control and isdifferent in various ways from a real Cruise Control or lack certain options. However,when a working basic model of the Cruise Control function is available it is possibleto extend the existing model with more complex functions afterwards.First an introduction into the supervisory control is given, followed by a manualwhich explains how to build a Supremica model. Next, the system requirementson which the models are based are presented. Fourth, the individual models of the requirements and their variables are explained. With the models complete thesupervisor synthesis can be performed and the results are shortly reviewed followedby a discussion of the results.

2.1. Supervisory control theory

The supervisory control theory (SCT) also known as the Ramadge-Wonham frame-

work provides a method to automatically synthesize supervisors as originally de-scribed in [Ram87]. The supervisor observes the events that occur in the plants andcan prevent controllable event from occurring in the plants .More information canbe found in [Pin97]. Supervisors restrict the behavior of a plant so that the plant be-haves as the system requirements demand. The plants are the different componentsof a system which can produce events. When an event occurs the state of the plantmay change. By introducing requirements which describe the desired behavior, theplants are after synthesis restricted by the supervisor so that the correct behavior of the system occurs. In Figure 2.1 the control structure is displayed of a user operatedsystem as presented in[Jac09].

The resource control will control time-driven elements of the hardware. This can,for example, be a PID controller. The resource control is the layer where continuoussignals need to be processed. The high-level control will handle the discrete-events.This can be signals from the user or discrete signals from the resource control. Thesupervisor will control the system according to predened system requirements. Thesystem requirements are the requirements for the entire described system.In this project, the focus is on the high-level control for discrete-event systems. Whenonly the high-level control is taken into account the rest of the system can be modeled

7

8/9/2019 2012 KA Meeusen


2. Cruise Control in Supremica

Figure 2.1.: Control architecture for a user operated system

in plants. A plant is a description of a part of the system, most of the time a singlecomponent. The plants have to be modeled as discrete-event models. There are twotypes of discrete-events, controllable and uncontrollable events. The controllableevents can be, like the name suggests enabled and disabled by a supervisor. Theuncontrollable events cannot be enabled and disabled by a supervisor, but are forexample controlled by a user outside the controlled system.In Figure 2.2 the relation between the supervisor and the plant is shown schemat-ically. The supervisor enables some events so they can occur in the plants. Whenevents occur, the state of the plant may change. This change can be observed by thesupervisor and the supervisor can enable or disable certain controllable events. Theuncontrollable events should always be able to occur. The result of the interactionbetween the plant and the supervisor is the controlled behavior.In order to make the supervisor the plants have to be modeled. Besides the plants the

8

8/9/2019 2012 KA Meeusen


2.2. Introduction in Supremica

Figure 2.2.: Supervisory control scheme

system requirements must be modeled as well. Requirements describe the desiredbehavior of the system as dened in the system requirements. Note that the system

requirements and the requirements are not dened the same in this report. InFigure 1.4 the difference between the two type of requirements is shown. Thesystem requirements are shown on the left, where the requirement for the desiredbehavior is displayed in the middle. The requirements are the models of the systemrequirement which describe the desired behavior.The combination of the plants and the requirements deliver a supervisor accordingto the supervisory control algorithms. The synthesis should deliver a supervisorthat allows controllable events to occur if required and never blocks uncontrollableevents, the supervisor cannot force an event to occur. If uncontrollable events areblocked or if the combined models deliver an uncontrollable of deadlocking system,

the models are incorrect and need to be changed.


In this section, the possibilities of Supremica are described followed by a shortdescription about the basic modeling actions in Supremica. At the end,a simpleexample is shown which can be veried by hand as well.Supremica [Sup09] is a program in which large discrete-event systems can be mod-

eled and synthesized. The synthesis can be applied to the different sub-systems,called plants, in which the large system can be split up. Together with the systemrequirements, modeled in requirements, and the plants, Supremica applies supervi-sory control theory algorithms to create a possible supervisor for the system.In the plants are modeled as automate in terms of discrete-events and the differentstates each sub-system can be in. The different states are connected by transitionswhich can be labeled by events. The action that changes the state condition is anevent. An event occurs when one state changes into another state.

9

8/9/2019 2012 KA Meeusen



Events can be controllable and uncontrollable. Uncontrollable events are eventsthat cannot be supervised by the system. For example, pushing a button cannot becontrolled by the system but only a person. If the button is pressed the state of thebutton changes from "not_pressed" to "pressed". Controllable events are events thatcan be controlled by the system, for example a light bulb. The system can be pro-grammed to switch the light bulb on and off. In case of a light bulb that is switchedon and off by a push button, pressing the button is an uncontrollable event andswitching the light bulb is a controllable event when the system is described withsupervisory control. The relations between pressing the push button and switch-ing the light bulb on or off are described in the requirements of the system. Thecombination of the requirements and the plants will describe the system where thelight bulb will go on when the push button is pressed and will go off when the pushbutton is not_pressed.There are several programs which can be used for supervisory control synthesis likeSCIDE [Hen10]. Supremica uses extended state automata,this means that Suprem-ica allows the use of variables, guards and actions. The variables can be used asobservers or counters. The values of the variables are changed by actions and mon-itored by guards. Variables can only be placed on a transition together with oneor more events. This means that events can be controlled by certain states of thevariables through guards. The value of the variables can be changed by actions. Assaid before actions and guards can be used together of separately, but they have tobe connected to a discrete event. Time has not been implemented in Supremica andhas to be modeled another way by making the time depended actions uncontrollableor removed them from the models if allowed.

How to make a Supremica model

This section gives a short explanation of how to make a model in Supremica. If theresults of this project need to be reproduced or adjusted this manual can providesome of the required knowledge. On www.supremica.org there is a compact manualavailable as well [Ake07].First the Supremica application needs to be opened and a new Supremica le needsto be created. Within this Supremica le the plants and requirements will be mod-eled starting with the automata.Automata

Automata can be added by right clicking beneath the editor tab or by pressingALT+A as can be seen in Figure 2.3.The new dialog that appears is shown in Figure 2.4. Within this dialog there isan option of which type of automaton needs to be created. In case of Figure 2.4is chosen type plant. Every automaton must have a unique name. In this examplea "P:" is added in front, however this is not required. The "P:"is added in front of

10

8/9/2019 2012 KA Meeusen



Figure 2.3.: Adding new automata in Supremica

Push_button so a requirement for the Push_button can be added later on. Thisrequirement can have Push_button in the name as well for a better overview. Afterconrming the choice, a new automaton will be created.

Figure 2.4.: Dialog for creating a new automaton

States

The states of an automation represent the states the described component or subsys-tem can be in. Adding states in Supremica can be done by clicking the add statesbutton which is shown in Figure 2.5. The name of the state can be changed bydouble clicking and lling in a state name. The new initial state of the automaton is

11

8/9/2019 2012 KA Meeusen



shown by a small arrow pointing to it. The initial state is always the rst made stateof the automaton but can be changed by right clicking on the state and selecting"set initial".

Figure 2.5.: The add-states button

State can also be accepting, this means that the state will be the state when thesystem is in idle. When all components of the system are in idle, their states shouldall be accepting. Making a state accepting can be done by right clicking on the stateand selecting: marking followed by: accepting.Transitions

Transitions can be added after at least on state has been made. A transition can bea seloop in which case the start and end point of the transition is the same state.Most of the time transitions connect two different states. A transition is for onedirection only, as can be seen in Figure 2.6. This means that a transition whichconnects state A to state B can only go from A to B and not from B to A. Transitionscan be added by clicking on the arrow-marked button seen in Figure 2.5. When thetransitions have been added the states can be organized by pressing CTRL+L. Thismeans that Supremica will arrange the states and transitions in such a way that themade structure becomes clear.Events

Events can be added by right clicking in the window where the automaton is beingcreated or by pressing ALT+E. The event window appears and a unique name mustbe chosen as well as the level of controllability as can be seen in Figure 2.6. In orderto add an event to a transition the event must be dragged to the correct transitionarrow. An uncontrollable event is displayed in the plant with the name of the eventin Italic. The controllable events are displayed normal.Variables

The variables used in Supremica are variables used within the system [Ake06]. Soin case of a light bulb the amount of current running through the lamp is a variablethat cannot be used in Supremica. The state of the lamp however can be a variable,by example 0 for Off and 1 representing On. Variables can be added by pressingALT+V or by right clicking in the components tab and selecting "Add variable". Allthe variables must have a unique name and can only range over integers or speciednames. Specied names can be the state names or random names, if the variablesare used as observers for the states the specied names can be the same as the statename but may also be another name. Where state names and event names cannotbe the same, the variable names and the state names are allowed to be the same.

12

8/9/2019 2012 KA Meeusen



Figure 2.6.: Creating a new event

The range of the variables must be entered with two dot marks between the lowestvalue and the highest value. So if a variable lies between the values 0 and 1, itshould be entered like shown in Figure 2.7. In case the range is large the methodeis the same. For example: a variable ranges from -2 through 5, the following shouldbe entered: "-2..5". If names are used as values the names of the values should allbe specied. This is done by placing the names between curly brackets separated bycommas, for example: "{On,Off}". With the variable range entered, the initial valuehas to be set as well. The variables can have an accepting value like the states. If an accepting value is required it needs to be entered like Figure 2.7. If no acceptingvalues are required all values within the range are made accepting automatically.

Guards

When the variables have been created the guards can be used to allow an eventunder certain conditions. A guard can be added by double clicking on a transitionarrow. If done correctly a box like Figure 2.8 will appear. Within the box the guardand the action can be specied. A guard consists of three components, the variable,a sign and a value. The symbols which can be used as a sign to specify the guardare shown in Table 2.1. A guard can contain multiple expressions which need to bevalid in order fulll the guard requirements. In Table 2.2 the combination sign areshown. For example: variable X must be equal to one or larger than ten and thevariable Y must be unequal to four. The guard will be as follows: "(X==1 | X >10) & Y!=4". This way various system requirements can be put into one guard.

13

8/9/2019 2012 KA Meeusen



Figure 2.7.: Window for creating a new variable

Sign Meaning== Equal!= Not equal< Smaller than> Larger than

Table 2.1.: The usable guard symbols

Sign Meaning& And| Or

Table 2.2.: The combination signs

14

8/9/2019 2012 KA Meeusen



Figure 2.8.: Window for entering guards and actions

Actions

Actions are added to transitions the same way as guards are as shown in Figure 2.8.An action is performed after the guard is true provided that there is one. An actionis simply changing the value of a variable. This means that a guard can state that avariable has to be equal to 1 and the action can change that value to 0. If no guardis available the action is applied if the event occurs. In Table 2.3 the symbols forthe action are shown.

Sign Meaning= Set+ Add- Subtract* Multiply/ Divide

-= New value = old value - ...

+= New value = old value + ...Table 2.3.: The usable guard symbols

Analyzer and synthesis

Within the analyzer it is possible to examine the reduced automata made by theanalyzer of the modeled plants, requirements and of the variables. The number of possible states, events and transitions are calculated for very plant, requirement or

15

8/9/2019 2012 KA Meeusen



variable. Supremica transforms the variables to plants within the analyzer. Thismeans that the variables are removed from the plants and requirements and re-placed by plants named after the variable. These plants contain the structure of the variables constructed by Supremica. This transformation from extended niteautomata to nite automata is described in [Sko08]. For each plant, the automatonview can be shown. In Figure 2.9, a view of a plant in the analyzer is shown. Byexamining these automata early faults, like incorrect modeling, can be corrected.

Figure 2.9.: View of a plant in the analyzer

The states, events and transitions are shown in the analyzer view. The exclamationmark in front of the event name means that the event is uncontrollable. The hor-izontal arrow denotes the initial state. The state with the green circle means thisstate is accepting. Note that multiple states can be accepting since multiple statescan be set accepting during modeling.With the plants and requirements completed, the supervisor synthesis can be per-formed. Before the synthesis is performed however, the reduced automata derived inthe analyzer are examined and verication for controllability and non-blockingness.By pressing CTRL+V verication on controllability and non-blockingness can bedone without synthesis or synchronization. during verication of the models bySupremica looks for possible deadlocks between the combined models. If a stateoccurs with no outgoing transitions a deadlock occurs within the models. If thishappens the models are blocking. The models are uncontrollable if uncontrollableevents are blocked causing an error as well. This means the controllability is incor-rect.If the combined models are both nonblocking and controllable the synthesis can be

performed. This means that Supremica combines the plants and requirements fromthe analyzer and produces a supervisor. The produced supervisor will satisfy therequirements and plants.

Light switch example

In this section two short examples of a light switch, containing a light bulb and apush button or switch, are shown in different ways. The rst is the classical way,

16

8/9/2019 2012 KA Meeusen



where the model of the light switch is made with nite automata. The second wayis with the use of variables, so extended nite automata are used. The modeledsystem in both examples is the same, the light bulb should start burning when thepush button is pushed, whereby the push button must always have the option to bepushed or released since it is an uncontrollable events.

Example 1: Finite automata

The light switch consists of two main components, a light bulb which can be con-trolled by the system and a push button which is controlled by the user. Thepush button therefore contains uncontrollable events and the light bulb containscontrollable events. Both the light bulb and the push button have two possiblestates: pressed / Not_pressed and Lamp_burning / Lamp_not_burning respec-tively. Whereby the states "not_pressed" and "Lamp_not_burning" are both cho-sen the initial and the accepting states of the plants. The models for the light switchand the light bulb can be seen in the Figures 2.10 and Figure 2.11.

Figure 2.10.: The plant of the push button

Figure 2.11.: The plant of the light bulb

The plants are connected by a requirement. This requirement states that if the pushbutton is pressed, the light bulb will start burning until the push button is released.This requirement is shown in Figure 2.12.The automata that describe the system are now completed, so the next step isto start the synthesis and make a supervisor. To do so the analyzer needs to beopened. Within the analyzer all the made plants and requirement can be shownthe way Supremica sees them. If the different systems are modeled incorrectly the

17

8/9/2019 2012 KA Meeusen



Figure 2.12.: The requirement for the light switch

interpretation of Supremica will be incorrect as well. If the plants or requirementsare modeled incorrect, the incorrect behavior is described. This means that the

concerning plant or requirement should be corrected in order to get a correct model.The result of the synthesis is shown in Figure 2.13. From Figure 2.13 can be seenthat the uncontrollable events which describe the push button can always be usedby the user.

Figure 2.13.: Result of the synthesis with nite automata

Example 2: Extended nite automata

In the extended nite automata variables are used to monitor the states of the lampand the push button. Both variables can be 0 (off / not pressed) or 1 (on / pressed)and have 0 as initial value. The variables are changed by actions added to the events.This means that the plant of the Push_button will look like Figure 2.17.This way of working however has a small disadvantage. When the analyzer is opened

18

8/9/2019 2012 KA Meeusen



Figure 2.14.: Extended nite automata of the Push_button plant

Supremica translates the variables to a plant. When the plant of the push button isshown (Figure 2.15), a correct scheme of the push button is shown. When variableis removed from the plant of the push button and translated into an new plant inthe analyzer, two seloops can be seen as in Figure 2.16. The events placed onthe seloops at the states 0 and 1 will not occur since the model of the plant willrestrict this. When the plant derived from the variable is combined with the plantfor Figure 2.15 the seloops will be blocked and therefore removed in the supervisor.This means that both the variable and the plant still describe the same system.

Figure 2.15.: Analyzer interpretation of the Push_button plant

Figure 2.16.: Analyzer interpretation of the Push_button variable

The derived plant of the variable has four transitions of which two are actually used.This means that two transitions will be removed during the synthesis between theplants of the variable and the original push_button plant. In larger models with

19

8/9/2019 2012 KA Meeusen



multiple variables and larger ranges of integers the number of seloops will grow andslow the synthesis down. If the number of transitions becomes too large Supremicawill deadlock and crash, more information about this can be found in Section 4.3.This phenomenon can be avoided by restricting the unused seloops and therebylowering the initial number of transitions. The seloops are restricted by guards.The guard states that the push button can only be pressed if it is not pressed, so theassociated variable can only become 1 if it is equal to 0. This results into an adjustedplant as shown in Figure 2.17. Normally, adding a guard to an uncontrollableevent is not allowed since there is a possibility the event is not allowed to occur.However, the guard is constructed in such way that the guard is always true sothe uncontrollable action can always occur. The result of using the guard is thatthe seloops are removed as shown in Figure 2.18. The goal of the added guardsis to restrict the variable not the action. Even if the synthesis can be completedwithout adjustments, adding the additional guard will speed up the calculations.The result of the supervisor should be the same since the description of the systemis not changed as shown in Figure 2.21.By adding the guards the plant derived from the variable has been changed. Theplant derived from the push button plant has not changed and still looks like Figure2.15. In Figure 2.18 the new plants derived for the variable is shown.

Figure 2.17.: The modied push button plant

Figure 2.18.: Analyzer interpretation of the modied push button variable

Based on the modied description of the push button the model of the lamp canbe constructed. The plant for the lamp is shown in gure 2.19. The controllable

20

8/9/2019 2012 KA Meeusen



events Lamp_On and Lamp_Off are only able to occur when the push button ispushed or released respectively as stated in the guards. This means that the guardsin replace the entire requirement from Example 1. These guards can be placed in aseparate requirement so the plant does not change.

Figure 2.19.: The plant of the lamp with extended nite automata

The variable Push_Button is moitored by the guard in the lamp plant as shown inFigure 2.19. Now the derived plant from the variable contains the events Lamp_onand Lamp_off as well as shown in Figure 2.20. Note that the seloops have differentevents than the events between the two states.

Figure 2.20.: The derived plant for the variable Push_Button

For the entire system described with extended nite automata a supervisor can besynthesized. The result from the synthesis is shown in Figure 2.21. It is identicalto Figure 2.13 except for the state names since the requirement is replaced by avariable and guards.

The use of extended nite automata requires fewer automata when the requirementsare implemented in the plants. The plants should describe what the possibilities of the system are. The requirements describe the desired behavior. In Supremica therequirement can be translated into guards, the guards can be placed at requirementsor plants. Since the structure of the plants and requirements are equal, the guardscan be placed at the plants. This is allowed within Supremica, but the guards canalso be placed in a requirement automaton to maintain a clear difference betweente plants and requirements.

21

8/9/2019 2012 KA Meeusen



Figure 2.21.: Result of the synthesis with extended nite automata

If a controllable event depends on multiple other events to be true, especially if anor-function needs to be used, the use of variables can prevent the usage of large re-quirement automata describing when an event may occur. With the use of variablesthe made automata can stay relatively small and simple, only the guard will growin size.

22

8/9/2019 2012 KA Meeusen


2.3. System Requirements

2.3. System Requirements

In [Hei12], the applicability of modelbased systems engineering in combination withsupervisory control synthesis is examined. In [Hei12] the focus was on the productdevelopment in the automotive world, for DAF in particular. The Cruise Controlhas been chosen as case study. A comparison of the supervisor models made bySCIDE and MatLab Stateow is done. In order to compare the models and resultsof Supremica with the results of [Hei12], the same requirements are used in thisproject. The system requirements for the Cruise Control function are as follows:Enable Cruise Control if all the following conditions are valid:

• Engine is running.• Vehicle speed is over 30 km/h.• Brake is off.

Disable Cruise Control if any of the following conditions is valid:• Engine is switched off.• Vehicle speed is below 25 km/h.• Brake is applied.• Accelerator pedal overrules the Cruise Control for more than 3 minutes.

Automatic activation of the Cruise Control if all the following conditions are valid:• Cruise Control is switched on (by driver) and:

– Cruise Control speed is set (by driver) or,– Cruise Control Set Speed is already available and a resume-command isgiven or,

– Cruise Control Speed Change Button is pressed or,– Cruise Control Set Speed is reached and must be held (if CC_SetSpd is

available)• Engine brake is off.

Automatic de-activation of the Cruise Control if one of the following conditions isvalid:

• Cruise Control is switched off (by driver).• Engine brake is applied.

Additional requirements to the Cruise Control regarding the CCSS (Cruise ControlSet Speed):

• The CCSS must be erased if the engine is off.• The minimum CCSS is 30 km/h and the maximum is 85 km/h.

23

8/9/2019 2012 KA Meeusen



• The CCSS can only be set if the Cruise Control is inactive (but enabled)• The Cruise Control Set Speed can only be changed by the Change_Speed_button

when activated.• The CCSS must become the actual vehicle speed when the CCSS is set.• The Cruise Control must remember the last set speed.• If the Cruise Control becomes active the last set speed becomes the CCSS.• The CCSS can be increased or decreased by 0.5 km/h respectively.• If the vehicle reached the CCSS after in- of decreasing the set speed, the new

CCSS must be maintained.

2.4. Modeling the requirements

The plants of the Cruise Control functions and the related components have beenmade as extended nite automata. Extended nite automata are used so the vari-ables can be used as observers. The value of a variable represents therefore a certainstate of the component and can be used throughout the models. This way the re-quirements can be expressed in terms of these variables in order to allow certainevents under certain conditions.The Engine

The Engine is modeled like a simple switch or button with two states: Engine_Onand Engine_Off. The engine is initially in the off position which is also the acceptingposition as can be seen from Figure 2.22. When the Engine_On command, whichis uncontrollable, is given the engine becomes running. The engine state is changedto On and value 1 is given to the variable "Engine". The reverse happens when theengine is shut down by the uncontrollable event Engine_Off which is representedby the value 0 assigned to the variable Engine.The guard that needs to be true before an event can be performed is added to theEngine-plant as well. The added guards state that the engine can only be switchedon when it is in the off position and the other way round. The added guard speeds upthe supervisor synthesis and simplify the derived plants of the variables, as explainedin section 2.2.The Brake

The brakes of the vehicle are modeled, like the engine, as a switch or button withtwo states. Again the states are connected by events and a variable is used as anobserver. The events Brake_Off and Brake_On, both uncontrollable events, arerepresented by the variable "Brake" and have the value 0 for loosened brakes and 1for applied brakes. With brakes applied is meant that the brake pedal is used bythe driver, not how much percent of the stopping power is used.

24

8/9/2019 2012 KA Meeusen



Figure 2.22.: The model of the Engine

The Brakes are initially loosened and accepting since hte brakes only work if thedriver pushes the brake pedal. However in case of air-brakes, which are commonlyused in trucks, the initial and nal state should be "brakes_applied" due to theworking of air brakes. Synthesis in both cases have been tested and are both possible.

The Engine BrakeThe Engine brake is used for example when the vehicle drives downhill and theengine will be used as a brake to prevent the regular brake from overheating. Whenand if the Engine brake is used is decided by another processing unit in the vehicle.The Cruise Control function has therefore no control over the engine brake function.This means that the events acting between the two states are uncontrollable for theCruise Control. The engine brake can, like the regular brake, be On or Off andthe state can be change by the events Engine_Brake_Off and Engine_Brake_Onmonitored by the variable "Engine_brake". Because the Engine is initially and inthe end in the off position the engine brake is so as well.

Pedal overruleThe pedal overruling the Cruise Control may occur when the vehicle is overtakinganother vehicle. During the overtaking the driver may want to increase the speedfor a short period of time by pressing the acceleration pedal. After the overtakingthe pedal can be released allowing the Cruise Control to reduce the speed until theset speed is reached after which this speed is maintained.Whether the pedal overrules the Cruise Control depends on the fuel request asexplained in section 1.1. The required fuel use of the accelerator pedal and theCruise Control are compared within the Cruise Control block of Figure 2.25. The

component which requires the most amount of fuel will overrule the other. So if the accelerator pedal requires more fuel than the Cruise Control, the uncontrollableevent Pedal_overrule will be given. The events are uncontrollable since the pedal isoperated by the driver. The variable "Pedal_overrule" observes the state in whichthe pedal overrule function is currently.The pedal overrule function is initially in the off position which is also the accept-ing position of the system. The pedal can only overrule the Cruise Control if theCruise Control is enabled, therefore the guard function of the pedal_overrule event

25

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen



options which the driver can perform on the Cruise Control system. The driver setsthe Cruise Control Set Speed (CCSS) with the SetSpd_Button. The CCSS can beincreased and decreased by the Change_Speed_Button. If the driver wants to usethe Cruise Control again after disabling or deactivation the Resume_CC_Buttoncan be pushed. The Cruise Control can be deactivated by both the Resume_Buttonand the SetSpd_Button. The plant models only the buttons not the function linkedto the buttons. Initially all the buttons are in the neutral position, so no commandsare given, this is the accepting position as well. Each of the uncontrollable eventsis represented by a variable and controlled by a guard.The model of the SetSpd_Button is shown in Figure 2.29. The variables or observersrepresent button which is pressed, the event names show the action which need to belinked to the events. So when the Set_CCSS_Button_On event occurs, the CCSSmust be set equal to the actual vehicle speed according to the system requirements.The buttons however can be pressed if the Cruise Control is still disabled.

The Resume_Button and Change_Speed_button are shown in the Figures 2.30and 2.31 respectively. Note that the event names refer to the functions behind thebutton. The CC_Off switch is in both the plants of the Resume_Button and theSetSpd_button. This is because both buttons have the same function within thesystem.The following requirements combine the components working with the Cruise Con-trol function. These three requirements describe the desired behavior of the systemlike stated in the system requirements of Section 2.1. The requirements are theenabling and disabling, activation and deactivation and CCSS_control of the sys-tem. The requirement should exclude certain combinations of states which are not

allowed within the Cruise Control function to occur.Enabling / Disabling

The Cruise Control can be enabled if the guards, derived from the system require-ments, are all true. This means that all the following statements must be true beforethe Cruise Control can be enabled:

• Engine has the value 1 (running).• Vehicle_speed is 1 (over or equal to 30 km/h).• Brake is 0 (off).

For disabling the Cruise Control function one of the following conditions must besatised.• Engine has value 0 (off).• Speed25 is 0 (below 25km/h)• Brake is 1 (applied).• Timer is 2 (Accelerator pedal overrules the Cruise Control for more than 3

minutes).

27

8/9/2019 2012 KA Meeusen



The enabling and disabling of the Cruise Control are both controllable events con-trolled by the guards stated above. The variable "CC_on" represents the state of being enabled or disabled of the Cruise Control. The Cruise Control is initially in thedisabled position since all conditions are satised for this position. The acceptingposition is disabled as well for the same reason.Activation / Deactivation

For the activation of the Cruise Control a certain state must be reached. Theactivation and deactivation of the Cruise Control is done by controllable events.The initial and accepting state is deactivated, since the conditions are satised forthis position. The state of the activation requirement is represented by the variable"CC_active". Before activation all the following conditions must be valid:

• A button for activation is pushed:

– SetSpd_button is 1 (Pressed) or,– Resume_button is 1 (Pressed) or,– Change_Speed is not 0 (Pressed)

• CCSS = 1 (available)• CC_on = 1 (enabled)• Engine brake is 0 (off).

The CCSS value 1 means that there is a CCSS available, more information aboutthe CCSS values can be found in the third requirement. There needs to be a CCSSin order to let the CC_Speed_Controller work since the CCSS will be the referencesignal for the controller. The Engine brake has to be in the off position as well andthe Cruise Control must be enabled before activation can occur.The deactivation of the Cruise Control must occur if one of the following conditionsis valid:

• SetSpd_button is -1 (Off)• Resume_button is -1 (Off).• Engine brake is 1 (applied).• Vehicle_Speed is 0 (below 30 or over 85km/h).• CC_on is 0 (disabled).

The Cruise Control must be deactivated if the driver switches the Cruise Control off or if the engine brake function becomes active. Beside these requirements the CruiseControl must also be deactivated if the Cruise Control is enabled. This means thatthe conditions that enable the Cruise Control should be valid as well for as long asthe Cruise Control is activated. And nally the Cruise Control is deactivated if thespeed drops below 30 km/h over raises over 85 km/h.

28

8/9/2019 2012 KA Meeusen



Cruise Control Set Speed

The actual vehicle speed cannot be an internal variable of Supremica. Since theCC_Speed_Controller requires an actual speed as reference which Supremica cannotsupply, a translator is introduced. In Figure 2.34 the translator is implemented in

the Cruise Control function. Note that the changes to Figure 1.3 (which resultedin Figure 2.34) are only there to demonstrate the usage of the translator in orderto overcome the local variables of Supremica.As can be seen in Figure 2.34 the CCSS variable value is sent to the CC_translator.Within the translator the translation from the discrete variable to input referencesignal for the CC_Speed_Controller is preformed. The input of the translator isthe CCSS value, the output is the CC_SetSpd. The CC_SetSpd is the referencesignal for the CC_Speed_Controller. The transformation from the variable valueto the reference signal vehicle data like the vehicle speed are required which requiresthe vehicle data input as shown in Figure 2.34.

A siad before, the requirement for the CCSS controls, shown in Figure 2.35, theCCSS variable not the CC_SetSpd. The CCSS variable is then translated to a refer-ence signal (CC_SetSpd) for the CC_Speed_Controller. The CC_Speed_Controlregulates the actual vehicle speed but the CCSS is controlled by the Cruise Controlfunction and sent to the CC_Speed_Controller. The variable CCSS can have 4different values reach representing a different states as shown in Table 2.4.

CCSS-value Meaning0 No CC_SetSpd available1 CC_SetSpd available2 Increase CC_SetSpd by 0.5 km/h3 Decrease CC_SetSpd by 0.5 km/h

Table 2.4.: CCSS values

Initially, there is no CC_SetSpd available since the CC_SetSpd is erased when theengine is turned off, so the CCSS variable is 0. The rst Set_CCSS command canbe given by the SetSpd_button or by the Change_Speed_Button. When one of these buttons are pressed and the Cruise Control function is enabled, it will notbe activated yet. If all these conditions are true the controllable event Set_CCSS

can be preformed. When this event occurs the following command is sent to theCC_Speed_Controller: CC_SetSpd:=Actual_Vehicle_Speed. Within this com-mand the CC_SetSpd is the input / reference signal for the CC_Speed_Controlleris set equal the actual vehicle speed. In Table 2.5 the CC_Speed_Controller signalsare shown and by which event they are sent to the controller.With a CCSS variable other than zero, the CC_SetSpd can be increased or de-creased by 0.5 km/h. In order to raise or lower the CC_SetSpd the increase ordecrease buttons needs to be pressed. The increase or decrease buttons are part

29

8/9/2019 2012 KA Meeusen



of the Change_Speed_button. This action together with the active Cruise Controland availability of a CCSS fulll the guard so the controllable CCSS_Increase orCCSS_Decrease events are allowed. When the event CCSS_Increase is preformedthe CCSS variable changes to 2. The CC_SetSpd is adjusted by CC_SetSpd:=CC_SetSpd+0.5 and sent to the CC_Speed_Control as reference signal. The sameis done by CCSS_Decrease with CC_SetSpd:=CC_SetSpd-0.5. When the Increaseor decrease action is preformed the CCSS variable value in the Cruise Control func-tion will become 2 for increasing and 3 for decreasing the CCSS.

With the increasing or decreasing of the speed the new CCSS value will replace theold CCSS value within the system. This action is performed by the controllableevent Update_CCSS, this event effectively changes the CCSS variable value backto 1, meaning (new) CCSS_available. The CC_Speed_Control might not havereached that speed yet, however the new speed is already the reference speed for thecontroller. This allows the driver to increase the CC_SetSpd multiple times withouthaving to wait until the CC_SetSpd is reached by the CC_Speed_Control.

Besides increasing and decreasing the CC_SetSpd, there is also a possibility toresume the Cruise Control function and to re-set the CC_SetSpd. In both casesa CC_SetSpd is already available (CCSS variable is 1). To reactivate the CruiseControl and resume the CCSS, the stored CC_SetSpd must be reactivated. Thismeans that the controllable event Resume_CCSS will send the following signalto the CC_Speed_Control: CC_SetSpd:=CC_SetSpd_stored. This means thatthe old and stored CC_SetSpd value become the new CC_SetSpd value for theCC_Speed_Control again.

The option to re-set the CC_SetSpd can be used when the speed difference is toolarge to increase the CC_SetSpd by using the buttons increase and decrease. There-fore the driver can set a new CC_SetSpd which replaces the old one. The commandsent to the CC_Speed_Control will be the Set_CCSS command: CC_SetSpd:=Actual_Vehicle_Speed. After the resume or re-set events have been preformed theUpdate_CCSS event will "conrm" the choice and return to the state CCSS_available.Both the resume event and the re-set event can only occur if the Cruise Control func-tion is deactivated but enabled. The Cruise Control can only be reactivated if theconditions satisfy the Cruise Control reactivation.

Events CC_Speed_Controller signalSet_CCSS CC_SetSpd:=Actual_Vehicle_Speed

Increase_CCSS CC_SetSpd:=CC_SetSpd+0.5Decrease_CCSS CC_SetSpd:=CC_SetSpd-0.5Resume_CCSS CC_SetSpd:=CC_SetSpd_storedUpdate_CCSS (no signal)Table 2.5.: Commands to the CC_Speed_Controller

30

8/9/2019 2012 KA Meeusen


2.5. Supervisor synthesis

2.5. Supervisor synthesis

With the system requirements for the Cruise Control function the analyzer result canbe reviewed. The verication for controllability and nonblocking showed that theplants and requirements combined are nonblocking and controllable. Validation of the supervisor output must conrm if the supervisor is indeed describes the correctbehavior of the system.The number of potential states is 10319560704, which means that without the re-quirements the supervisor would be enormous. This number is reduced by thesynthesis to a supervisor with 25920 possible states of which 1 state is accepting.There are 51 possible events an 296280 possible transitions. The information aboutthe size of the supervisor after the synthesis is shown in Figure 2.36. A quick ex-ploration of the supervisor shows that the supervisor delivers the required behavioras dened in the system requirements. However another way of validation is neededin order to decide that the supervisor is correct, like the translation to Stateowfollowed by simulation in a controlled environment.

2.6. Discussion

The modeling of the Cruise Control function into Supremica can be done relativelycompactly. The plants can be modeled as nite state automata and be upgraded toextended nite automata using guards and actions as observers. The possibility totrace down early errors with the help of the analyzer and its functions, speeds up

the development process.The models made in Supremica have as strength that a connection between thetime driven CC_Speed_controller easily can be made. If there is a program whichcan use the Supremica output les as input, the Cruise Control function can beimplemented with the help of a translator which translates the CCSS variable.

31

8/9/2019 2012 KA Meeusen



Figure 2.23.: The model of the Brake

Figure 2.24.: The model of the Engine_Brake

Figure 2.25.: Model of the Pedal overrule function

32

8/9/2019 2012 KA Meeusen


2.6. Discussion

Figure 2.26.: Model of the Timer

Figure 2.27.: Model of the over 25km/h controller

Figure 2.28.: Model of the CCSS-box controller

33

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen


2.6. Discussion

Figure 2.32.: Requirement for the enabling

Figure 2.33.: Requirement for the activation

Figure 2.34.: Adjusted internal Cruise Control

35

8/9/2019 2012 KA Meeusen



Figure 2.35.: Requirement for the CCSS variable

Figure 2.36.: Operations statistics after the synthesis

36

8/9/2019 2012 KA Meeusen


3. Translation to StateowIn this chapter, a way is presented to translate the models and supervisor madein Supremica into a Matlab Stateow le. The reason a translation to Stateow iswanted is because the Stateow environment is part of the Matlab Simulink environ-ment. Within the Simulink environment simulations can be preformed whereby theother vehicle components are simulated as well. This provides an excellent way totest behavior of the system under supervision. First, the output format of Supremicais chosen from which the Stateow translation is made. Second, the elements and

values which Stateow requires to build a model are explained. After the structureof the translation le is explained, the recommendations for improvement are given.

3.1. Output format

In order to translate the models made in Supremica to Matlab Stateow the modelshave to be exported. Matlab Stateow cannot read the les Supremica produces,so an output le according needs to be produced and rewritten to Stateow input.Commonly used formats are sts-les and xml-les. The choice is made to export the

Supremica models in a xml-le. The reason there has been chosen for an xml-leis that when a supervisor is exported in an sts-le an error and an empty outputle are given. More information about the error is given in section 4.3. The outputfrom Supremica can be found in Appendix A.

3.2. Stateow input

The Stateow le has the format mdl. The Stateow les require a certain structure,the structure describes how the Stateow model is build up. In this section the

buildup of the Stateow le is explained.The difficulty of Stateow is that the build up of the mdl-le is based on the graphicalpositions of the components. This means the coordinates of the positions of thestates, transitions and events must be correctly dened in order to work. In Figure3.1 an example of the visual representation is given. The buildup of the modelswill be done in a main. This main is a overall state in which the automata will bebuilt. The main is dened as an OR-state. Since there is only one main OR-stateStateow will always look into this main state. Within the automata the different

37

8/9/2019 2012 KA Meeusen


3. Translation to Stateow

Figure 3.1.: Example of Stateow structure

states of the various plants will be modeled. The automata states are AND-states,this means that all the AND-states within the main can occur at the same time. Soin other words, both in Automaton 1 and Automaton 2 are states which representthe current state of the system. To show this graphically, the lines of the AND-states are made dotted lines. The states in the automata are the actual states of the plant. These states are OR-states again since just like Supremica only one statecan be valid at a time. Between the states in the automaton transitions are denedwith a label. The names of the states in this example are taken so that they can berecognized further on.The mdl-starts with round 730 lines of explanation about the Simulink model and

standard settings. These lines are not covered in this report. In 3.1 the buildup of the main state is shown, comments (with # in the front) are placed which explainthe values if known. The "chart" is a block within the Simulink model in which theStateow environment is built.Within the .mdl le the coordinates of the blocks are recorded in x and y coordinates.The x-direction goes from left to right and the y-direction goes from above to below.The base-point of a block in x and y are the values of the upper left corner. Thesize of the box is displayed in length and height, the length of the box is taken to

38

8/9/2019 2012 KA Meeusen


3.2. Stateow input

the right and the height is taken downwards from the base-point.

Table 3.1.: The denition of the chart state

The build up within the le is like a family tree. Within the chart "TreeNode" willpoint to the next and previous state (both if available). If there is no next stateon the same level, the tree will go to a lower lever called child. The rst child willbe named in the "TreeNode" and refer to the rst state in the lower level. All thechildren will refer to their parent state. All the different states have a unique id,this id number is used within the "TreeNode" to refer to the next state or transition.Beside the unique id, every component has a build number called ssIdNumber. Thisnumber is not used within the states. This Id just represents the order in which thecomponents are created. When elements are deleted the build id will not be reused.In Table 3.2 and Table 3.3 the code for the main and automaton is shown. If thefunction of the value is known, an explanation is given, unless the name providesenough information. Within the automaton the "rstTransition" is mentioned. Thismeans that within the automaton an initial state is dened as can been seen fromFigure 3.1. The states within the automaton do not have this reference to the rsttransition.In the transitions, the source state from which the transition starts and the desti-

39

8/9/2019 2012 KA Meeusen



Table 3.2.: Buiding code of the main

nation state are dened. The intersection vector contains 8 values, the meaningsof all 8 values are not exactly known. However the rst two values are related tothe direction of the transition. When a transition runs from left to right these twovalues are swapped compared to a similar transition running in the other direction(right to left). The other values can have something to do with a possible path of the transition arrow, although this is not sure.

At the end of the mdl-le two small extra components have to be added. Theinstance describes that the "Chart" is the initial state of the entire modeled sys-tem. From here the "TreeNode" will be followed. The target function describes theSimulink S-Function in which the working of stateow is dened.

3.3. Translation le

The idea behind the translation le is that it will read the xml-le and translatethe read values and strings into a Matlab Stateow structure as described in theprevious section. The reason a translation is required is that Simulink and thereforeStateow has no possibility to import an external model. The entire Conversionle can be found in Appendix B. Originally, the intension was for the conversionto use an m-le, because Matlab contains a function ReadXML [Mat02]. Thisfunction however uses DOMnode. DOMnode is a Document Object Model (DOM )[Ora01]. The programming language behind the DOMnode is Java. Due to the lackof knowledge about Java another programming language has been chosen. To avoidinstallation of compilers for the different languages Microsoft Powershell [Mic01]is chosen. Powershell is already installed on every computer using the Windowsoperating system. This means that the translation can be done on every Windowscomputer without additional programs. The usage of Windows Powershell producesa translation le with the .ps1 extension. By right clicking on the Powershell leand choosing edit the Powershell development environment will automatically open.

40

8/9/2019 2012 KA Meeusen


3.3. Translation le

File structure

When an xml-le is produced by Supremica, Powershell has to read the xml-le. In

short the le will read the xml-le and store the values and names of the plants andsupervisor in multiple lists. These lists are then used to calculate the structures of the Stateow charts.

In the translation le rst the xml-le is loaded and checked for emptiness in line nr8 of Appendix B. After the denition of a few constants regarding the position of thestates and automata the main function is shown from line 23 till 107 of Appendix B.Within the main function the various sub functions are called up. The sub functionsare dened after the main function. In Table 3.6 a piece of the xml-le is shown. Foreach automaton the following process is preformed for each event the id and label are

stored. The same is done for the state id and name. Finally for the transitions thesource, destination and matching event are stored in a list. These actions are doneby the sub functions make-automaton, make-state and make-transition respectively.

Since the position of all the states is important in Stateow for the hierarchy of thetree structure, the states are not allowed to overlap each other. The states must bein each other for a correct working. To accomplish this, the states of the modelsare all made the same size and placed behind each other. For each automaton thisproduces a row of states, so the y position of all the states within the automatahave the same value. The x position value is increased for each new state in theautomaton. When a second automaton is produced the y position of the automatonstate is lowered and the x value is reset to the initial value. The result is that withinthe main state a column of automata is made. Within each automaton contains arow of states like in Figure 3.1. The transitions between two stats are allowed tocross other states. So the transitions are all made horizontal lines running thoughthe row of states. The distance between the states are set equal, just like the size of the state. This means that the position string will always have the same values forthe length in x and y direction. The size of the automaton and the main for noware predened. However in a later stage of development the size of these must bemade variable so they will t over the automaton states.

After the xml has been processed the mdl le can be written. This is done separatelyfor the chart, automata, states and transitions since each requires a different setup.In front of the system description the general info is printed in the mdl-le, followedby the chart. The main state is factually a normal OR-state and therefore the Write-State is called to write the main state. After the main the automata are writtenfollowed by the states and transitions. During the writing the transition le willbuild the correct TreeNode for referencing.

41

8/9/2019 2012 KA Meeusen



Possible improvements and adjustment

The transitions le will translate the xml to a mdl, however due to the uncertaintyof the function of some values the mdl-le will not work yet. In this section, someimprovements and adjustments that need to be done are mentioned. Within thetranslation le there are some notes with tasks that need to be completed for correctusage. These tasks have not been done yet due to lack of time.First the size of the main state and the automaton are now predened. When largeautomata are produced the states of the automaton will exceed the automaton andmain state boundary. By making these sizes variable the states will always be withinthe automaton and main state. This can be done by writing the main state andautomaton as last. Hereby the number of states in a row can be used to determinethe length of the automaton state. The size of the main state can be calculated bythe number of automaton in the automaton column and their length.

The meaning of the remaining unknown values, like the intersection values, haveto be found and integrated into the translation. Most importantly a way has tobe dened to subtract the variables from the plants and to transform them backto extended nite automata and an "extended" supervisor. This way observers canbe used within Supremica which makes integration into a Simulink environmentpossible.

Running the le

In order to run the Powershell le and translate a xml-le to a mdl-le two possi-ble ways are available. The rst is by using the command prompt of windows, thesecond way is by opening the Windows Powershell prompt. First the Powershell-prompt, this can be opened by typing Powershell in the search-bar under the startmenu. When the Powershell prompt is opened the following command needs tobe typed: C:\> help Set-ExecutionPolicy. This text explains the security optionwhich need to be selected. The ExecutionPolicy needs to be changed, under admin-istrator rights, to RemoteSigned by entering: "C:\> Set-ExecutionPolicy remote-signed". This means that local les only can be used. When the ExecutionPolicyis changed, the following must be entered: "{working directory} .\{Translationle-name} .\{xmlle-name} > {mdl-le-name}".

The methode is almost the same when using the command prompt but it hasto be mentioned that the operation is done in Powershell. So when the Execu-tionPolicy is set correctly the following must be entered in the command-prompt:"{working directory} powershell .\{Translationle-name} .\{xmlle-name} > {mdl-le-name}". So if for example the le is in the directory "documents" on the "c"storage-disc of the computer and the le name is "test.xml", the following needsto be entered in the Powershell prompt: "C:/>document.\ powershell .\ Convert-XMLToMatlabStateowModel .\test.xml > test.mdl".

42

8/9/2019 2012 KA Meeusen


3.4. Discussion

3.4. Discussion

The translation le is not working yet and quite some work needs to be done in orderto get the translation working. However, the way of translating can be used in otherprograms. When the graphical information stored in the Matlab mdl-le can becreated by another program, the translation to Stateow can be done automaticallyeven for large plants and supervisors.The translation by Powershell has as advantage that the editor is already installed onevery windows computer. The disadvantage is that the code is complex compared tothe Matlab language. In Matlab however the readout of the xml required knowledgeabout Java where Matlab normally is a combination of c and c++ and Fortran asprogramming languages [Mat01].

43

8/9/2019 2012 KA Meeusen



Table 3.3.: Buiding code of the automaton

Table 3.4.: Building code of the transitions

Table 3.5.: Closing code for the .mdl le

44

8/9/2019 2012 KA Meeusen


3.4. Discussion

Table 3.6.: xml version of the brake plant

45

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen


4. Evaluation and ComparisonIn the second chapter, a Supremica model of the Cruise Control function has beenmade. In order to translate the made model to MatLab Stateow a translationprocedure has been made in the previous chapter. So the previous two chaptersresulted in a model of the Cruise Control function and a way to translate the resultsto Stateow.In this chapter the comparison between this project and [Hei12] is made. In [Hei12]a model of the Cruise Control function has been made as well. Where an attemptfor the translation in this project is done automatically, in [Hei12] the translationis done by cif2stateow. Cif2stateow is a tool developed by Albert Hofkamp andgenerates a MatLab m-le that can be integrated in the state based toolchain. Moreinformation about cif2stateow can be found in [Hen08].First the models of the Cruise Control function are compared and evaluated. Second,the way of translation to the MatLab Stateow charts is compared. At the end of this chapter the applicability of Supremica to design supervisors for discrete-eventin vehicles is examined.

4.1. Comparison of the models

In this section, the models of the Cruise Control function made by [Hei12] arecompared to the models made in Supremica. The models of [Hei12] are made withuse of the tool Scide (Supervisory Control Integrated Development Environment)[Hen10]. Scide is the development environment for supervisory control of the TU/e(University of Technology Eindhoven) and is capable of modeling extended niteautomata. First the difference in entering methods is describes, followed by thecomparison of the entered models.

Modeling methodWithin Supremica the extended nite automata are made by creating variableswhich can be changed by actions. These actions are coupled to transitions andevents. A guard can block the possibility of an event to occur if the variable valuedoes satisfy to the guard statement. Within Scide there is no possibility to createvariables. All the models within Scide are initially made as nite automata withcontrollable and uncontrollable events. The extended nite automata are createdwithin the requirements. This means the extensions for extended nite automata

47

8/9/2019 2012 KA Meeusen


4. Evaluation and Comparison

underline the idea that the requirements describe the desired behavior. In Figure4.1 from [Hei12] the plant for the minimal enabling speed is shown and in Figure4.2, from [Hei12] as well, the plant for the enabling of the Cruise Control is shown.

Figure 4.1.: Minimal Speed enabling plant in Scide

Figure 4.2.: Enabling plant in ScideThe plant for the enabling and disabling of the Cruise Control looks like the plantfrom Supremica. The difference is that there are no guards allowing the control-lable event Enable under certain conditions. The condition in which the Enableevent is allowed is described in a state-based requirement from [Hei12] in Figure4.3. The requirement states that when in the Plant MinSpd_Enabling the stateOver30 is valid, and the engine is running, the event Enable is allowed to occur.This requirement in Scide can be compared with the variables used as observers inSupremica.

Figure 4.3.: Enabling requirement in Scide

Steering wheel buttons

48

8/9/2019 2012 KA Meeusen


4.1. Comparison of the models

Between the models of [Hei12] and the models made in Supremica there are somedifferences. The rst big difference is the modeling of the steering wheel buttons. Bythe modeling of the Cruise Control in Supremica there is chosen to model the threebuttons and their functions. In [Hei12] is chosen to model the Input Arbitration (asexplained on page 49 in [Hei12]) as shown in Figure 1.3. In the Input Arbitrationthe signals from the buttons are received and sent to the CC_Control_Logic. Thismeans that only one signal at the time can be sent to the CC_Control_Logic.This shows in the model made of the Input Arbitration, Figure 4.14 in [Hei12]. Inthe Supremica model there is chosen to model the buttons instead of the InputArbitration. This actually means that from each button the signal will be sent tothe CC_Control_Logic. At the CC_Control_Logic however the result will be thesame. In the requirement describing the CCSS only one signal will be processed atthe time, which gives the same result as the model of the Input Arbitration.Setting the CCSS

In Figure 4.27 of [Hei12] the event-based requirement for setting the CCSS after aset command is shown. Where in the Supremica model variables are used to set theCCSS value, another approach is used in Scide models due to the lack of variables.The system requirements state that the Cruise Control cannot be activated if thereis no CCSS value. In the Supremica models this means that the CCSS variable valuemay not be 0 if the Cruise Control is activated. If all the conditions are satisfyingthe CCSS variable is 0, only the SetSpd_Button or Change_Speed_Button have tobe pressed to change the CCSS value to 1. This satises all the conditions and theCruise Control will be activated. In order to get the same result without blockinguncontrollable events and with nite automata there needs to be a requirement. In

Figure 4.27 of [Hei12] can be seen how the same problem is solved in Scide.Synthesis

By the synthesis of the Supremica models the duration of the synthesis is displayed.The duration of the synthesis depends on the background activity and computerspecications. With a low background activity (no other running programs) anda 3.2GHz processor (it is a single core process) the synthesis takes on average 3seconds over 10 tries. For a correct result a server should be used whereby the exactperformance easily can be measured. There are no records found of the duration of the supervisor synthesis in [Hei12]. So no synthesis time comparison can be done. Allthat can be found is a list of repaired errors and a control le of the supervisor. Thecontrol le describes for each controllable event when the event may occur. SinceScide uses the current states of certain plants in order to determine whether anevent is allowed or not, a control le gives a lot of information about the supervisor.This is because the le is simple to read and it is easy to see if the states are thecorrect ones as described in the requirements. Within Supremica no control le canbe produced. An option that Supremica has is to explore the supervisor states.Within the explore state option it is possible to simulate the behavior of the systemby choosing between the available events that are allowed to occur.

49

8/9/2019 2012 KA Meeusen



4.2. Comparison of translation

In this section, the comparison between the translation methods is made. Thisto combine the best from both methodes and propose a suggestion for an optimalmethode. Although the differences in translation are large, due to the differentinput and different translation and output, a comparison is made. In the end of thissection, a suggestion is done for the conversion from Supremica models to MatlabStateow based on applicability and feasibility.In [Hei12] the input for the translation is an sts-le which is translated by cif2stateow.Cif2stateow has no time integration and positioning of the Stateow objects. Inthe translation from xml to Stateow there is no timer implementation either. Butsince Supremica, in contrary to Scide, has no time integration this is no problem forSupremica models. The modeled timer of the Supremica models can be activatedby placing a clock of some kind in the Simulink environment and sent discrete timesignal to the timer plant.Another possibility may be a combination of the followed procedure in this reportand the use of the Stateow Application Programming Interface (API). The API hasbeen used for the development of cif2stateow by Alber Hofkamp. The API createthe models in Stateow whereby the working procedure of a column of automataand rows of states is used. As said before, the transitions can run over the otherstates without inuencing their function. This way a large Stateow model can bebuilt without having to know the exact function of all the values put in the mdl-le.

4.3. Applicability of Supremica

The main goals of this project was to examine the applicability of Supremica. Inthe previous sections and chapters a number of advantages and disadvantages havebriey been mentioned. In this section both the advantages and disadvantages arefully elaborated. In the end of the section the conclusion on the applicability of Supremica for automotive systems is given.

Advantages

The capability of Supremica to verify if the models are blocking and controllablewithout performing synthesis is useful. In case of larger systems where the synthesisrequires more time than the simplied model of the Cruise Control, the vericationcan verify if model conicts will occur. Since this can be done without preformingtime consuming synthesis, in the long therm the development time of the supervisorcan be shortened.The availability of variables to transform the nite automata into extended nite au-tomata speeds up the development process. This is because the system requirements

50

8/9/2019 2012 KA Meeusen


4.3. Applicability of Supremica

can easily be transformed into guards. When the variables are used as observers thediffenerences between Scide (and therefor the SuSyNa functions) and Supremica arenegligible. However when the variables are not used as observers, by example as acounter, the variables can be useful.

Disadvantages

The most important disadvantage of Supremica has to do with the synthesis. Asshown in [Sko08] the variables which make the extended nite automata are reducedby the analyzer to ordinary nite automata. This is done because the synthesisalgorithm cannot synthesize a supervisor based on extended nite automata. Whenthe synthesis is completed the created supervisor is not changed back to extendednite automaton form. herby is meant that the variables that were removed fromplants are back transformed to variables again. If the backward transformation

would exist it would reduce the size of the supervisor, as shown by the followingexample;A variable ranges over the values 1 through 6, so six different options for the variable,and the six values can occur at state A and state B. At state A the value of thevariable must be one, at state B the variable must be between 2 and 6. In Figure4.4, a graphical representation of the plant is shown.

Figure 4.4.: Example of a plant with a variable

When the plant and variable go into the analyzer the variable is translated to aplant as well, when the synthesis is applied a supervisor is created. Since only theplant and variable are entered in the synthesis the supervisor should just describethe plant from Figure 4.4. In Figure 4.5 the analyzer results of the a) the plant, b)the variable and c) the supervisor are shown. As can be seen from the state namesof the supervisor the variable value is processed in the state name. The ideal optionwould be if the variable value was removed from the state and transformed back toa variable. The result would be again the original plant for this case. So only two

51

8/9/2019 2012 KA Meeusen



states instead of six. If the described system contains multiple plants and variableslike the Cruise Control function, the number of states can be reduced signicantly.

Figure 4.5.: The analyzer results of the a) the plant, b) the variable and c) thesupervisor

Additional guards Like stated in section sec.2.2 the transitions (seloops) createdwhen the analyzer translates a variable to a plant can cause a non-terminationduring synthesis. This phenomenon can be explained. The additional guards canbe removed since they do not have any function. The guards will be removed by the

synthesis when the plant is combined with the variable. However it seems that whentoo many transitions are available, Supremica cannot perform the synthesis correctly.The additional guards added to the plant to remove the seloops can prevent thesynthesis from non-termination. Besides preventing a deadlock the additional guardswill speed up the synthesis since less transitions have to be removed. Experimentsshow that the non-terminating synthesis occurs when the number of transitionsapproaches 1 million. An important note is placed: during an experiment wherebyevery time an additional guard was removed from a plant, the deadlock synthesisoccurred. When the additional guard was added again, but all other additionalguards were removed, the deadlock did not occur. When the specic plant wasremoved and built again, in the exact same way, without additional guards no non-termination occurred. This error only occurred once but thanks to saving underdifferent names, the non-termination can be recreated for this specic case. Thissuggests a bug in the Supremica programming code, which can be bypassed byadding the additional guards. Whether the bug occurs depends on the size of themodels. When the number of automata is small the bug does not occur.Output le

When the Supremica models need to be exported, an extension needs to be chosen.

52

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen



for small to medium-sized (up to 20 automata) automotive systems, so there will beno non-termination during synthesis. Only if the process tools after Supremica arecapable of processing the output le made by Supremica, the usage of Supremica isuseful. This because a correct translation is required. The ideal situation would be if the process tool is capable of extracting the variables from the plants, requirementsand supervisor and returning them back to extended nite automata.

54

8/9/2019 2012 KA Meeusen


5. Concluding remarksThe purpose of this project was to evaluate the applicability of Supremica to thedesign of supervisors for discrete-event system is vehicles. To this end the CruiseControl function has been chosen as case study. The results from Supremica shouldbe compared to the results of a Master Thesis from [Hei12]. In the rst the con-clusions from this project are presented. In the second the recommendations forfurther research are given.

5.1. Conclusions

When the project started the Supremica model of the Cruise Control function wasthe rst goal to achieve. Without any knowledge of Supremica and a limited knowl-edge of supervisory control was Supremica easy to understand. The structure inwhich the models must be build for the nite state automata is similar to othertools like Scide. The upgrade to extended nite automata can be made easily with-out adjustments to the plant models, however the actions which can be performedon the variables are nowhere properly documented. The fact that the variables areinternal variables which can only be used between the models and not external (likethe vehicle speed) caused the early models of the Cruise Control function to crash.With the adjustment to internal variables which are used between the models andthe variable action known, the model of the Cruise Control function was completed.With the current knowledge, another Supremica model of another function can bemade in a shorter time. Therefore, it can be concluded that with more detailedinformation about the possibilities of Supremica the development process will beshortened. An extended manual has been made in section 2.2, this manual coversonly the basic modeling but is more detailed then [Ake07]. Advanced modeling withinternal simulation which should be possible within Supremica are not included inthe manual from section 2.2 and [Ake07].One of the advantages of Supremica, besides allowing variables, is the analyzer.Within the analyzer early faults and errors can be detected. By performing theincluded verication the models and supervisors can be checked on blocking andcontrollability. The disadvantages of the analyzer are that the extended nite au-tomata are reduced to nite state automata for synthesis. When the synthesis iscompleted the nite state automata are not transformed back. As shown in Section4.3. when a state can have multiple variable values the analyzer removes the vari-ables and makes a plant of the variable. The original plant is combined with the

55

8/9/2019 2012 KA Meeusen


5. Concluding remarks

plant made for the variable. The result is a plant with six instead of two states.When synthesis is preformed the plants with the six states will be used. This resultsin a large supervisor in which the number of states can be reduced by returning thevariables.

In section 4.3 the advantages and disadvantages are elaborated like the non-termi-nation when no additional guards are used to control the seloops made when theanalyzer reduces the extended nite automata. These seloops will be removedduring synthesis thanks to the original plant. Without the additional guards non-termination can occur when apparently a number of maximum transitions is ex-ceeded due to a programming bug. The additional guard will also speed up thesynthesis since less transitions have to be removed.

With the Supremica models completed a comparison has been made with [Hei12].The models made by [Hei12] in Scide are compared to the Supremica models. It isconcluded that the usage of the Supremica variables the reduced number of requiredrequirements in comparison to the models in Scide, although some differences inthe modeled result in less components. Both models are extended nite automata.Within Scide the requirements can be dened as state conditions, with Supremicathe requirements are dened as guards for the events.

In Section 4.4, the applicability of Supremica is evaluated. The conclusion onSupremica as a tool to design supervisors for the automotive industry is that the

program can be used for small to medium-size systems. However, the reduction fromextended nite automata to nite state automata is not ideal for further process-ing with other tools. Especially since the DAF trucks N.V. uses Matlab Stateow.Within Stateow variables are used as observers for transitions similar to modelingin Supremica. The reduction prevents a simple translation of the supervisor to Mat-lab Stateow. This makes Supremica not the ideal tool to be used for the design of discrete-event systems for vehicles.

For the translation to Matlab Stateow an attempt has been done to make a Mi-crosoft Powershell le. This Powershell le is capable of reading an xml le whichcan be selected as Supremica output. The Powershell translation le will read thexml and translate the xml to a Matlab Simulink le (.mdl). The translation does notwork properly yet due to unknown meanings of values in the mdl-le. This meansthat these values cannot be created for the xml le with the Supremica model. Thebuilding method described in Section 3.3 by using a column of automatons andwithin these automatons rows with states can be used in other translations as well.Therefore it is suggested to use the Stateow Application Programming Interface(API) in combination with the described building method.

56

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen


Bibliography[Hei12] M.H.R. van der Heijden. Master Thesis. Application of Supervisor Synthesis

to the design of Cruise Control, SE 420675, TU/e 03/2012.[Wij08] G. van de Wijdeven. Mechatronic requirements document: Cruise Control.

Internal Report (Condential) 7002 51050/08-114, DAF Trucks N.V., 2008.[Ram87] RJ Ramadge and WM Wonham: Supervisory control of a class of discrete

event processes, SIAM J. Control and Optimization, 25(1), pp. 206-230,

1987[Jac09] Jacobs, K.G.M., Markovski, J., Beek, D.A. van, Rooda, J.E. & Somers,L.J.A.M. (2009). Specifying state-based supervisory control requirements.(SE Report, No. 2009-06). Eindhoven: Technische Universiteit Eindhoven,40 pp.

[Pin97] Luz E. Pinzon. Explanation about the Ramadge and Wonham Network.http://rutcor.rutgers.edu/~pinzon/papers/rrr1/node4.html

[Hen10] D.Hendriks. Scide User Guide on SE wiki, 2010/05/19.http://se.wtb.tue.nl/sewiki/supcon/scide/start.

[Sup09] Supremica website. http://www.supremica.org[Ake07] Knut Akesson, Martin Fabian and Hugo Flordal. Supremica in a Nutshell

– Draft Department of Signals and Systems, Chalmers University of Tech-nology, Göteborg, Sweden October 9, 2007

[Hen08] D.Hendriks. CIF: Tooling on SE wiki.http://se.wtb.tue.nl/sewiki/cif/tooling.

[Mat01] Mathworks Matlab product overview.http://www.mathworks.nl/products/matlab/

[Mat02] Mathworks Matlab Product documentation: XML-read function.http://www.mathworks.nl/help/techdoc/ref/xmlread.html

[Ora01] Oracle documents. Document Object Model nodes.http://docs.oracle.com/javase/6/docs/api/org/w3c/dom/package-summary.html

[Mic01] Microsoft Development Nerwork. Getting started with Windows Powershell.http://msdn.microsoft.com/en-us/library/windows/desktop/aa973757.aspx

59

8/9/2019 2012 KA Meeusen


Bibliography

[Sko08] Markus Sköldstam, Knut Åkesson, and Martin Fabian. Supervisory ControlApplied to Automata Extended with Variables - Revised, Technical ReportR001/2008, Department of Signals and Systems, Chalmers University of Technology, Göteborg, Sweden, 2008.

[Ake06] Knut Åkesson, Martin Fabian, Hugo Flordal, Robi Malik. Supremica – Anintegrated environment for verication, synthesis and simulation of discreteevent systems, Proceedings of 2006 Workshop of Discrete Event Systems(WODES), Ann Arbor, Michigan.

60

8/9/2019 2012 KA Meeusen


8/9/2019 2012 KA Meeusen


A. XML code

<Transition source="0" dest="1" event="1" /><Transition source="0" dest="0" event="2" /><Transition source="1" dest="0" event="0" /><Transition source="1" dest="1" event="3" /></Transitions></Automaton>

- <Automaton name="R:CC_activation||CC_active" type="Plant">- <Events>

<Event id="0" label="Acceleration_CC_On" controllable="false" /><Event id="1" label="Activation_CC.{Resume_button}" /><Event id="2" label="Activation_CC.{SetSpd_button}" /><Event id="3" label="CCSS_Decrease" /><Event id="4" label="CCSS_Increase" /><Event id="5" label="CCSS_Resume" /><Event id="6" label="Deactivation_CC.{!CC_on}" />

<Event id="7" label="Deactivation_CC.{!CCswitch}" /><Event id="8" label="Deactivation_CC.{!Vehicle_Speed}" /><Event id="9" label="Deactivation_CC.{Engine_brake}" /><Event id="10" label="Deceleration_CC_On" controllable="false" /><Event id="11" label="Set_CCSS.{CCSS==0}" /><Event id="12" label="Set_CCSS.{CCSS==1}" /><Event id="13" label="Timer_off.{!CC_active}" /><Event id="14" label="Timer_on" /></Events>

- <States>

<State id="0" name="CC_activated.1" /><State id="1" name="CC_deactivated.0" initial="true"accepting="true" /></States>

- <Transitions><Transition source="0" dest="0" event="0" /><Transition source="0" dest="0" event="3" /><Transition source="0" dest="0" event="4" /><Transition source="0" dest="1" event="6" /><Transition source="0" dest="1" event="7" /><Transition source="0" dest="1" event="8" /><Transition source="0" dest="1" event="9" /><Transition source="0" dest="0" event="10" /><Transition source="0" dest="0" event="14" /><Transition source="1" dest="0" event="1" /><Transition source="1" dest="0" event="2" /><Transition source="1" dest="1" event="5" /><Transition source="1" dest="1" event="11" /><Transition source="1" dest="1" event="12" />

62

8/9/2019 2012 KA Meeusen


<Transition source="1" dest="1" event="13" /></Transitions></Automaton>

- <Automaton name="CCswitch||P:CC_on_off_switch" type="Plant">- <Events>

<Event id="0" label="Activation_CC.{Resume_button}" /><Event id="1" label="Activation_CC.{SetSpd_button}" /><Event id="2" label="CCswitch_off" controllable="false" /><Event id="3" label="CCswitch_on" controllable="false" /><Event id="4" label="Deactivation_CC.{!CCswitch}" /></Events>

- <States><State id="0" name="0.CCswitched_off" initial="true"accepting="true" /><State id="1" name="1.CCswitched_on" />

</States>- <Transitions>

<Transition source="0" dest="1" event="3" /><Transition source="0" dest="0" event="4" /><Transition source="1" dest="1" event="0" /><Transition source="1" dest="1" event="1" /><Transition source="1" dest="0" event="2" /></Transitions></Automaton>

- <Automaton name="P:Engine_Brake||Engine_brake" type="Plant">

- <Events><Event id="0" label="Activation_CC.{Resume_button}" /><Event id="1" label="Activation_CC.{SetSpd_button}" /><Event id="2" label="Deactivation_CC.{Engine_brake}" /><Event id="3" label="Engine_Brake_Off" controllable="false" /><Event id="4" label="Engine_Brake_On" controllable="false" /></Events>

- <States><State id="0" name="Engine_brake_applied.1" /><State id="1" name="Engine_brake_loosened.0" initial="true"accepting="true" /></States>

- <Transitions><Transition source="0" dest="0" event="2" /><Transition source="0" dest="1" event="3" /><Transition source="1" dest="1" event="0" /><Transition source="1" dest="1" event="1" /><Transition source="1" dest="0" event="4" /></Transitions>

63

8/9/2019 2012 KA Meeusen


A. XML code

</Automaton>- <Automaton name="Decrease_button||Increase_button||P:CC_Commands||SetSpd_button||Resume_button" type="Plant">- <Events>

<Event id="0" label="Activation_CC.{Resume_button}" /><Event id="1" label="Activation_CC.{SetSpd_button}" /><Event id="2" label="CCSS_Decrease" /><Event id="3" label="CCSS_Increase" /><Event id="4" label="CCSS_Resume" /><Event id="5" label="Decrease_CCSS_Button_Off" controllable="false" /><Event id="6" label="Decrease_CCSS_Button_On" controllable="false" /><Event id="7" label="Increase_CCSS_Button_Off" controllable="false" /><Event id="8" label="Increase_CCSS_Button_On" controllable="false" /><Event id="9" label="ResumeCC_button_Off" controllable="false" /><Event id="10" label="ResumeCC_button_On" controllable="false" />

<Event id="11" label="Set_CCSS.{CCSS==0}" /><Event id="12" label="Set_CCSS.{CCSS==1}" /><Event id="13" label="Set_CCSS_Button_Off" controllable="false" /><Event id="14" label="Set_CCSS_Button_On" controllable="false" /><Event id="15" label="Update_CCSS.{!Resume_button}" /><Event id="16" label="Update_CCSS.{!SetSpd_button}" /></Events>

- <States><State id="0" name="0.0.CCSS_Available.1.0" /><State id="1" name="0.0.No_Commands.0.0" initial="true"

accepting="true" /><State id="2" name="0.0.Resume_CCSS.0.1" /><State id="3" name="0.1.Increase_CCSS.0.0" /><State id="4" name="1.0.Decrease_CCSS.0.0" /></States>

- <Transitions><Transition source="0" dest="0" event="1" /><Transition source="0" dest="0" event="11" /><Transition source="0" dest="0" event="12" /><Transition source="0" dest="1" event="13" /><Transition source="0" dest="0" event="15" /><Transition source="1" dest="4" event="6" /><Transition source="1" dest="3" event="8" /><Transition source="1" dest="2" event="10" /><Transition source="1" dest="0" event="14" /><Transition source="1" dest="1" event="15" /><Transition source="1" dest="1" event="16" /><Transition source="2" dest="2" event="0" /><Transition source="2" dest="2" event="4" />

64

8/9/2019 2012 KA Meeusen


<Transition source="2" dest="1" event="9" /><Transition source="2" dest="2" event="16" /><Transition source="3" dest="3" event="3" /><Transition source="3" dest="1" event="7" /><Transition source="3" dest="3" event="15" /><Transition source="3" dest="3" event="16" /><Transition source="4" dest="4" event="2" /><Transition source="4" dest="1" event="5" /><Transition source="4" dest="4" event="15" /><Transition source="4" dest="4" event="16" /></Transitions></Automaton>

- <Automaton name="Engine||P:Engine" type="Plant">- <Events>

<Event id="0" label="Clear_CCSS" />

<Event id="1" label="Disable_CC.{!Engine}" /><Event id="2" label="Enable_CC" /><Event id="3" label="Engine_Off" controllable="false" /><Event id="4" label="Engine_On" controllable="false" /><Event id="5" label="Speed_OK" controllable="false" /><Event id="6" label="Speed_Over_25_On" controllable="false" /></Events>

- <States><State id="0" name="0.Engine_Off" initial="true"accepting="true" />

<State id="1" name="1.Engine_On" /></States>- <Transitions>

<Transition source="0" dest="0" event="0" /><Transition source="0" dest="0" event="1" /><Transition source="0" dest="1" event="4" /><Transition source="1" dest="1" event="2" /><Transition source="1" dest="0" event="3" /><Transition source="1" dest="1" event="5" /><Transition source="1" dest="1" event="6" /></Transitions></Automaton>

- <Automaton name="R:CCSS||CCSS" type="Plant">- <Events>

<Event id="0" label="Activation_CC.{Resume_button}" /><Event id="1" label="Activation_CC.{SetSpd_button}" /><Event id="2" label="CCSS_Decrease" /><Event id="3" label="CCSS_Increase" /><Event id="4" label="CCSS_Resume" />

65

8/9/2019 2012 KA Meeusen


A. XML code

<Event id="5" label="Clear_CCSS" /><Event id="6" label="Set_CCSS.{CCSS==0}" /><Event id="7" label="Set_CCSS.{CCSS==1}" /><Event id="8" label="Update_CCSS.{!Resume_button}" /><Event id="9" label="Update_CCSS.{!SetSpd_button}" /><Event id="10" label="Update_CCSS.{CCSS==2}" /><Event id="11" label="Update_CCSS.{CCSS==3}" /></Events>

- <States><State id="0" name="CCSS_Available.1" accepting="true" /><State id="1" name="Downgrade_CCSS.3" /><State id="2" name="No_CCSS.0" initial="true" /><State id="3" name="Re_Set_CCSS.1" /><State id="4" name="Resume_CCSS.1" /><State id="5" name="Upgrade_CCSS.2" />

</States>- <Transitions>

<Transition source="0" dest="0" event="0" /><Transition source="0" dest="0" event="1" /><Transition source="0" dest="1" event="2" /><Transition source="0" dest="5" event="3" /><Transition source="0" dest="4" event="4" /><Transition source="0" dest="2" event="5" /><Transition source="0" dest="3" event="7" /><Transition source="1" dest="0" event="11" />

<Transition source="2" dest="0" event="6" /><Transition source="3" dest="3" event="0" /><Transition source="3" dest="3" event="1" /><Transition source="3" dest="0" event="9" /><Transition source="4" dest="4" event="0" /><Transition source="4" dest="4" event="1" /><Transition source="4" dest="0" event="8" /><Transition source="5" dest="0" event="10" /></Transitions></Automaton>

- <Automaton name="P:Vehicle_Speed||Vehicle_Speed" type="Plant">- <Events>

<Event id="0" label="CCSS_Resume" /><Event id="1" label="Deactivation_CC.{!Vehicle_Speed}" /><Event id="2" label="Enable_CC" /><Event id="3" label="Speed_OK" controllable="false" /><Event id="4" label="Speed_Over_25_Off" controllable="false" /><Event id="5" label="Speed_not_OK" controllable="false" /></Events>

66

8/9/2019 2012 KA Meeusen


- <States><State id="0" name="Out_CCSS_box.0" initial="true"accepting="true" /><State id="1" name="Vehicle_speed_CCSS_box.1" /></States>

- <Transitions><Transition source="0" dest="0" event="1" /><Transition source="0" dest="1" event="3" /><Transition source="0" dest="0" event="4" /><Transition source="1" dest="1" event="0" /><Transition source="1" dest="1" event="2" /><Transition source="1" dest="0" event="5" /></Transitions></Automaton>

- <Automaton name="P:Timer||Timer" type="Plant">

- <Events><Event id="0" label="Disable_CC.{Timer==2}" /><Event id="1" label="Timer_3min" controllable="false" /><Event id="2" label="Timer_off" /><Event id="3" label="Timer_off.{!CC_active}" /><Event id="4" label="Timer_off.{!Pedal_overrule}" /><Event id="5" label="Timer_on" /></Events>

- <States><State id="0" name="Timer_disabled.0" initial="true"

accepting="true" /><State id="1" name="Timer_over_3min.2" /><State id="2" name="Timer_running.1" /></States>

- <Transitions><Transition source="0" dest="2" event="5" /><Transition source="1" dest="1" event="0" /><Transition source="1" dest="0" event="2" /><Transition source="2" dest="1" event="1" /><Transition source="2" dest="0" event="3" /><Transition source="2" dest="0" event="4" /></Transitions></Automaton>

- <Automaton name="P:Brake||Brake" type="Plant">- <Events>

<Event id="0" label="Brake_Off" controllable="false" /><Event id="1" label="Brake_On" controllable="false" /><Event id="2" label="Disable_CC.{Brake}" /><Event id="3" label="Enable_CC" />

67

8/9/2019 2012 KA Meeusen


A. XML code

</Events>- <States>

<State id="0" name="Brake_Applied.1" /><State id="1" name="Brake_loosened.0" initial="true"accepting="true" /></States>

- <Transitions><Transition source="0" dest="1" event="0" /><Transition source="0" dest="0" event="2" /><Transition source="1" dest="0" event="1" /><Transition source="1" dest="1" event="3" /></Transitions></Automaton>

- <Automaton name="Speed25||P:Speed_below_25" type="Plant">- <Events>

<Event id="0" label="Disable_CC.{!Speed25}" /><Event id="1" label="Enable_CC" /><Event id="2" label="Speed_OK" controllable="false" /><Event id="3" label="Speed_Over_25_Off" controllable="false" /><Event id="4" label="Speed_Over_25_On" controllable="false" /></Events>

- <States><State id="0" name="0.Speed_below_25" initial="true"accepting="true" /><State id="1" name="1.Speed_over_25" />

</States>- <Transitions><Transition source="0" dest="0" event="0" /><Transition source="0" dest="1" event="4" /><Transition source="1" dest="1" event="1" /><Transition source="1" dest="1" event="2" /><Transition source="1" dest="0" event="3" /></Transitions></Automaton></Automata>

68

8/9/2019 2012 KA Meeusen


B. Translation File

# -----------------------------------------------------# Author: Koen Meeusen# Description: Conversion of a ’Automata’ XML file into a# Mathlab model file# Date: 06 July 2012#

# Usage: Convert-AutomataToMatlabModel# -----------------------------------------------------

param ([Parameter(Position=0, ParameterSetName="InputMdl",ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]

[ValidateNotNullOrEmpty()] [String]$InputXML) # check for emptiness

& {# global constants

$global:AutomatoYIncrement = 140$global:AutomatoHeight = 120$global:StateXIncrement = 130$global:StateSize = (90, 60)$global:TransitionOffset = 10

#global numbers$global:BoxId = 0$global:IdNumber = 0

function main{

if ($inputXml -notlike "*.xml"){

throw "Convert-AutomataToMathlabModel:Inputfile does not have the extension .XML"

}

$ModelName = $(Split-String $(Split-Path $InputXml -Leaf)

69

8/9/2019 2012 KA Meeusen


B. Translation File

-RegexSeparator "\.")[0]$FullInputPath = resolve-Path $InputXml$xmlDoc = New-Object Xml.XmlDocument$xmlDoc.Load($FullInputPath.ProviderPath)

if ($xmlDoc.GetElementsByTagName("Automata")) {}else{

throw "Convert-AutomataToMathlabModel: Inputfile is not an’Automata’ XML file"

}

$MachineId = Get-NextBoxId$ChartId = Get-NextBoxId

$MainState = Make-State 0 $xmlDoc.Automata.Name $ChartId "Main"(0, 0, 1280, 1000) "OR_STATE" "SET_STATE"

$States = 0,0, $MainState$Transitions = 0,0$AutomatoY = 60

foreach ($Automaton in $xmlDoc.Automata.Automaton){

# Make Automation state in the MDL, give it a UID

()unique id).# Each Automation has a fixed height of 120 andendless width (infinit,

# but smaller than the chart). First position isat x=20,y=60

# incremented by y=140$AutomatoStateX = 20$AutomatoState = Make-State 0 $Automaton.name

$MainState.id "Main" ‘(20, $AutomatoY, 1240, $global:AutomatoHeight)

"AND_STATE" "CLUSTER_STATE"# Todo: Handle Initial tarnsition to state

(initial = true)$States += $AutomatoState$AutomatoY += $global:AutomatoYIncrement$LocalStates = 0,0#foreach ($xmlState in $Automaton.States.State)$StatesTodo = $Automaton.States.State.Countfor ($i = 0; $i -lt $StatesTodo; $i += 1)

70

8/9/2019 2012 KA Meeusen


{$xmlState = $Automaton.States.State[$i]

# For each state child of the automation giveit a UID and

# make a state in the MDL file. Each state hasa fixed size of 90x60 and lies

# within the automation horizontally arranged.First position

# is at x=40,y=20 (relative of automation)incremented by x=130

$StateMode = "Both" # next and prev link presentif ($i -eq 0){

$StateMode = "First" # Only next link present

}elseif ($i -eq $($Automaton.States.State.Count - 1)){

$StateMode = "Last" # Only prev link present}

# Todo: In case only one state the Statemode should be none!

$State = Make-State $xmlState.id $xmlState.name$AutomatoState.id $StateMode ‘

($AutomatoStateX, $($AutomatoY + 20), $global:StateSize[0],

$global:StateSize[1]) "OR_STATE" "CLUSTER_STATE"$LocalStates += $State$States += $State$AutomatoStateX += $global:StateXIncrement

}

$TransactionCount = 0foreach ($xmlTransition in $Automaton.Transitions.Transition){

# For each Transition of the automation give ita UID and# make a transition in the MDL file using the events.

Ensure that# the start touches the boundary of the source-state.

Same for# destination. transaction source start at the

right/bottom of# the state. Destination arrive at the left/top of

the state.

71

8/9/2019 2012 KA Meeusen


B. Translation File

$Transition = Make-Transition $xmlTransition$Automaton.Events.Event $LocalStates $AutomatoState.id$TransactionCount$Transitions += $Transition$TransactionCount += 1# Todo: Handle the additional parameters of the LinkNode

}}

Write-Model $OutputMdl $ModelName $MachineId $ChartId$States[2..$States.Count] $Transitions[2..$Transitions.Count]

}

function Make-State{

param ([string] $stateId,[string] $stateName,[int] $ParentState,[string]$mode,[int[]] $StatePosition,[string] $StateType,[string] $Decomposition)

$MyId = Get-NextBoxId# TreeNode list holds numbers:

# parent -> parent state for this state# FirstChild -> only for container# Next -> Next sibling (not for last state)# Previous -> Previous sibling (not for first state)[int[]] $treeNode = $ParentStateswitch ($mode){

"Main" { $treeNode += ($($MyId + 1), 0, 0) }"Both" { $treeNode += (0, $($MyId + 1), $($MyId - 1)) }"First" { $treeNode += (0, $($MyId + 1), 0) }"Last" { $treeNode += (0, 0, $($MyId - 1)) }default { $treeNode += (0,0,0) }

}

$State = New-Object PSObject$State | Add-Member NoteProperty "id" $MyId$State | Add-Member NoteProperty "ssIdNumber" $(Get-NextIdNumber)$State | Add-Member NoteProperty "labelString" $stateName#position [ x y width height ]

72

8/9/2019 2012 KA Meeusen


$State | Add-Member NoteProperty "position" $StatePosition$State | Add-Member NoteProperty "treeNode" $treeNode$State | Add-Member NoteProperty "xmlId" $stateId$State | Add-Member NoteProperty "stateType" $StateType$State | Add-Member NoteProperty "decomposition" $Decomposition

return $State}

function Make-Transition{

param ($xmlTransition, $xmlEvents, $LocalStates, $ParentState,[int] $Number)

$SourceState = $localStates[2..$localStates.Count] | where

{ $_.xmlId -eq $xmlTransition.source }$SourcePosition = $SourceState.position$DestonationState = $localStates[2..$localStates.Count] | where

{ $_.xmlId -eq $xmlTransition.dest }$DestinationPosition = $DestonationState.position$TransactionLabel = $($xmlEvents | where{ $_.Id -eq $xmlTransition.event }).label

$Arrow = ($($SourcePosition[0] + $SourcePosition[2]),$($SourcePosition[1] + 20 + $($Number *

$global:TransitionOffset)),$($DestinationPosition[0]),$($DestinationPosition[1] + 20 + $($Number *$global:TransitionOffset)))

$ArrowBox = ($(min $Arrow[0] $Arrow[2]),$(max $Arrow[0] $Arrow[2]),$(min $Arrow[1] $Arrow[3]),$(max $Arrow[1] $Arrow[3]))

$Transition = New-Object PSObject$Transition | Add-Member NoteProperty "id" $(Get-NextBoxId)$Transition | Add-Member NoteProperty "labelString"$TransactionLabel#Labelposition [ x y width height ]$Transition | Add-Member NoteProperty "labelPosition" ‘

$($($SourcePosition[0] + $SourcePosition[2] + 4), ‘$($SourcePosition[1] + 10 + $($Number * $global:TransitionOffset)), ‘$($TransactionLabel.Length * 5), 15)

73

8/9/2019 2012 KA Meeusen


B. Translation File

$Transition | Add-Member NoteProperty "ssIdNumber"$(Get-NextIdNumber)$Transition | Add-Member NoteProperty "srcId"$SourceState.id# Source intersection [ a? b? ? ? x y ? ? ]’) a and bare direction related$Transition | Add-Member NoteProperty "srcIntersection"$(0,0,0,0, $Arrow[0], $Arrow[1], 0, 0)$Transition | Add-Member NoteProperty "dstId"$DestonationState.id# Destination intersection [ a? b? ? ? x y ? ? ]’)a and b are direction related$Transition | Add-Member NoteProperty "dstIntersection"$(0,0,0,0, $Arrow[2], $Arrow[3], 0,0)# Todo: add ’midPoint’ and the mean of src and dst for

values X and Y$Transition | Add-Member NoteProperty "linkNode"$($ParentState, 0, 0)# Todo: ’dataLimits’ as the boundary-box of the arrow(minmax of X and Y Values witn minimum of 4)$Transition | Add-Member NoteProperty "dataLimits"$ArrowBox

return $Transition}

function Get-NextBoxId{

$global:BoxId += 1return $global:BoxId

}

function Get-NextIdNumber{

$global:IdNumber += 1return $global:IdNumber

}

function min([int] $A, [int] $b){

if ($a -lt $b){

return $a}

74

8/9/2019 2012 KA Meeusen


return $b}

function max([int] $A, [int] $b){

if ($a -gt $b){

return $a}return $b

}

function Write-Model{

param ($OutputFile, $ModelName, $MachineId, $ChartId,

$States, $Transitions)

$InstanceId = Get-NextBoxId$TargetId = Get-NextBoxId

Write-Output ’Model {’Write-ModelDetails $ModelNameWrite-Output ’}’Write-Output ’’Write-Output ’# Finite State Machines’

Write-Output ’#’Write-Output ’# Stateflow Version 7.1 (R2009a)dated Jul 17 2009, 10:24:20’Write-Output ’#’Write-Output ’StateFlow {’

Write-Machine $ModelName $MachineId $TargetIdWrite-Chart $ChartId $MachineId $States[0].idforeach ($State in $States){

Write-State $State $ChartId}

foreach ($Transition in $Transitions){

Write-Transition $Transition $ChartId}

Write-Instance $InstanceId $MachineId $ChartId

75

8/9/2019 2012 KA Meeusen


B. Translation File

Write-Target $TargetId $MachineId

Write-Output ’}’}

function Write-ModelDetails ([string] $ModelName){

## comment// some rules removed because of th length}

function Write-Machine{

param ([string] $ModelName, [int] $MachineId, [int] $TargetId)

Write-Output $(’ machine {’)

Write-Output $(’ id ’ + $MachineId)Write-Output $(’ name "’ + $ModelName + ’"’)Write-Output $(’ created "01-Jul-2012 10:31:44"’)Write-Output $(’ isLibrary 0’)Write-Output $(’ firstTarget ’ + $TargetId)Write-Output $(’ sfVersion 71014000.00001’)Write-Output $(’ }’)

}

function Write-Chart

{ param ([int] $ChartId, [int] $MachineId, [int] $MainStateId)

Write-Output $(’ chart {’)Write-Output $(’ id ’+ $ChartId)Write-Output $(’ name "Chart"’)Write-Output $(’ windowPosition [6 28.5 1248 702]’)Write-Output $(’ viewLimits [0 1204.5 0 666]’)Write-Output $(’ screen [1 1 1680 1050 1.333333333333333]’)Write-Output $(’ treeNode [0 ’ + $MainStateId + ’ 0 0]’)Write-Output $(’ viewObj ’ + $ChartId)Write-Output $(’ machine ’ + $MachineId)Write-Output $(’ subviewS {’)Write-Output $(’ }’)Write-Output $(’ ssIdHighWaterMark ’ + $(Get-NextIdNumber))Write-Output $(’ decomposition CLUSTER_CHART’)Write-Output $(’ chartFileNumber 1’)Write-Output $(’ userSpecifiedStateTransitionExecutionOrder 1’)Write-Output $(’ disableImplicitCasting 1’)

76

8/9/2019 2012 KA Meeusen


Write-Output $(’ }’)}

function Write-State{

param ($State, [int] $ChartId)

Write-Output $(’ state {’)Write-Output $(’ id ’ + $State.id)Write-Output $(’ labelString "’ + $State.labelString + ’"’)#Write-Output $(’ #position [ x y width height ]’)Write-Output $(’ position [’ + $State.Position + ’]’)Write-Output $(’ fontSize 12’)Write-Output $(’ chart ’ + $ChartId)#Write-Output $(’ #treeNode [ parent firstchild next previous]’)

Write-Output $(’ treeNode [’ + $State.treeNode + ’]’)Write-Output $(’ subviewer 2’)Write-Output $(’ ssIdNumber ’ + $State.ssIdNumber)Write-Output $(’ type ’ + $State.stateType)Write-Output $(’ decomposition ’ + $State.decomposition)Write-Output $(’ }’)

}

function Write-Transition{

param ($Transition, $ChartId)Write-Output $(’ transition {’)Write-Output $(’ id ’ + $Transition.id)Write-Output $(’ labelString "’ + $Transition.labelString + ’"’)#Write-Output $(’ #labelposition [ x y width height ]’)Write-Output $(’ labelPosition [’ + $Transition.labelPosition + ’]’)Write-Output $(’ fontsize 12’)Write-Output $(’ src {’)Write-Output $(’ id ’ + $Transition.srcId)#Write-Output $(’ #intersection [ ? ? ? ? x y ? ? ]’)Write-Output $(’ intersection [’ + $Transition.srcIntersection + ’]’)Write-Output $(’ }’)Write-Output $(’ dst {’)Write-Output $(’ id ’ + $Transition.dstId)#Write-Output $(’ #intersection [ ? ? ? ? x y ? ? ]’)Write-Output $(’ intersection [’ + $Transition.dstIntersection + ’]’)

77

8/9/2019 2012 KA Meeusen


B. Translation File

Write-Output $(’ }’)Write-Output $(’ chart ’ + $ChartId)#Write-Output $(’ #linkNode [ parent next previous ]’)Write-Output $(’ linkNode [’ + $Transition.linkNode + ’]’)Write-Output $(’ dataLimits [’ + $Transition.dataLimits + ’]’)Write-Output $(’ stampAngle NaN’)Write-Output $(’ subviewer 2’)Write-Output $(’ drawStyle SMART’)Write-Output $(’ slide {’)Write-Output $(’ }’)Write-Output $(’ executionOrder 1’)Write-Output $(’ ssIdNumber ’ + $Transition.ssIdNumber)Write-Output $(’ }’)

}

function Write-Instance{

param ($InstanceId, $MachineId, $ChartId)

Write-Output $(’ instance {’)Write-Output $(’ id ’ + $InstanceId)Write-Output $(’ name "Chart"’)Write-Output $(’ machine ’ + $MachineId)

Write-Output $(’ chart ’ + $ChartId)Write-Output $(’ }’)}

function Write-target{

param ($TargetId, $MachineId)

Write-Output $(’ tarrget {’)Write-Output $(’ id ’ + $TargetId)Write-Output $(’ name "sfun"’)Write-Output $(’ description "Default SimulinkS-Function Target.’)Write-Output $(’ machine ’ + $MachineId)Write-Output $(’ }’)

}

. main # return to the main function}

78

8/9/2019 2012 KA Meeusen


2012 KA Meeusen

Documents

Transcript of 2012 KA Meeusen