adding schedulability analysis to the octopus...

Adding Schedulability Analysisto the Octopus Toolset

Ajith Kumar

August 23, 2011

Master Thesis

Eindhoven University of TechnologyDepartment of Mathematics and Computer ScienceDesign and Analysis of Systems GroupAndManipal Institute of TechnologyDepartment of Information and Communication Technology

In cooperation with:Embedded Systems InstituteEindhoven, The Netherlands

Supervisor at TU/e:Dr. Mohammad Reza MousaviAssistant [email protected]

Supervisor at MIT:Dr. BalachandraAssociate [email protected]

Graduation Tutor:Dr. Nikola TrckaPostdoctoral [email protected]

Abstract

Embedded systems are computing systems responsible for performing one or more spe-cific functions within a host device. In the early design phases of embedded systems,multiple design choices need to be considered. Manually analyzing the feasibility ofthe designs is time consuming, lots of design parameters have to be considered, whereexploration of the design space using each parameter is complicated hence impractical.Thus an integrated toolset that could assist in exploring the design space and choos-ing a near optimal design is of great benefit to the designers. This exploration usuallyinvolves analyzing the design choices using various tools with specific analysis methodsthat focus on one of the chosen design parameters. The design parameters are alwaysapplication dependent. The Octopus toolset is one such design space exploration tooldeveloped by Embedded Systems Institute in collaboration with various Dutch compa-nies. The toolset assists the users in making a near optimal design choice for a system.It uses a graphical modeling language called Design Space Exploration IntermediateRepresentation (DSEIR).

Embedded systems typically have (strict) real-time constraints and usually work ina resource-constrained environment. For hard-real time systems with hard-deadlines,meeting deadline requirements is one of the critical factors for making design decisions.This property can be checked by performing schedulability analysis on the designs, whichensures that the resource requirement of the system is satisfied throughout its execution.Schedulability analysis is an important analysis method for analyzing design choices, andhence is a useful addition to the Octopus toolset. The goal of this thesis is to incorporateschedulability analysis as an analysis technique in the Octopus toolset.

We first investigate the possible approaches to add schedulability analysis to the Octopustoolset. During this investigation we observed broader requirements for the accomplish-ment of the primary goal, thereby dividing it into two phases namely, making schedula-bility analysis possible in the Octopus toolset and making this analysis procedure scalablefor arbitrary DSEIR models.

The first phase includes devising an approach to perform schedulability analysis basedon model checking. Model checking was chosen owing to its merits over the other meth-

iii

ods. The Octopus toolset consists of a branch performing model checking on the DSEIRmodels using the model checker Uppaal, upon which we build the support for schedu-lability analysis. Completion of first phase included adding of the deadline feature intoDSEIR and creating a deadline detection mechanism in Uppaal and embedding this intothe DSEIR to Uppaal translation module in the Octopus toolset.

After the completion of the first phase, we analyze the scalability of our approach toarbitrary DSEIR models, which are tuned to simulation and are sufficiently large models.Given the practical limitations for model checking in Uppaal and general problems likestate-space explosion in large models, we required a method to approximate the inputmodels into an abstract form with focus on state-space reduction. We construct analgorithm to perform abstraction based on syntax analysis, applying which we get asound approximation of the original DSEIR model.

Acknowledgements

This thesis is a part of my master project that I have performed in the group of Designand Analysis of Systems at Eindhoven University of Technology, the Netherlands, inco-operation with Embedded Systems Institute, TU/e Campus, Eindhoven, the Nether-lands.

Coming to the end of my thesis work, I would like to take this opportunity to thankeach and everyone who have directly or indirectly contributed to this project. Firstly Iwould like to thank Prof.dr.Twan Basten for providing me this opportunity to pursue mymasters project in the Embedded Systems Institute (ESI), under the direct supervisionof Dr. Nikola Trcka and Dr. Mohammad Reza Mousavi and also guiding me throughthis project. Dr. Mohammad Reza Mousavi, my graduation supervisor at TU/e, hasprovided me with constant support and guidance, ensuring the smooth run of my thesis.Dr. Nikola Trcka, my daily tutor at ESI has walked me through the ups and downsof my thesis, correcting me whenever I deviated from the desired path. I also wouldlike to express my heart-filled gratitude to Dr. Nikola Trcka and Dr. Mohammad RezaMousavi for their patient review on several versions of my report, helping me improvemy documentation skills.

I am thankful to Dr. Balachandra for being my project coordinator from ManipalUniversity and for his evaluation. I am grateful to Prof.dr. Mark van den Brand, theprogram director for the Manipal Program for his valuable guidance at every step on theway through this master‘s study at TU/e. I would like to thank all the people involvedwith the Octopus project, Frans Reckers, Dr. Martijn Hendricks, Bram in‘t Groenand all others who made my thesis possible. I have to mention my friend/colleagueAshwini Moily, without whom working on this project would not have been as fun. Wehave worked together for various parts of our project, acted as reviewers for each otherand so on; I owe my gratitude to you. Special thanks to Reinier van Eck, director ofESI for his encouraging support through the thesis period. This project would not havebeen possible without the support of Prof.dr. Manohara M. Pai, Prof.dr. Jos Baeten andProf.dr. Mark van den Brand, who gave me the opportunity to come to the Netherlands.I must express my appreciation to my friends Alok Lele, Shreya Adyanthaya, AbhinavSingh, Guru Prasanna, Shravan Shetty, Supriya Dsouza and Vinod Menezes for their

v

patient listening to my presentations and support. Last but not the least; I owe mygratitude to all my other friends and my family who stood by me through all the highsand lows of this course and the project.

vi

Contents

1 Introduction 1

1.1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Motivation and Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.7 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Design Space Exploration Intermediate Representation 9

2.1 DSEIR Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Running Example in the DSEIR Syntax . . . . . . . . . . . . . . . . . . . 17

2.2.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Uppaal 23

3.1 Uppaal Timed Automata Modeling Language . . . . . . . . . . . . . . . . 24

3.2 Uppaal Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Existing DSEIR Translation to Uppaal 31

4.1 Generic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.2 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.4 Restrictions in Translation . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Syntax Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 DSEIR Translation of Running Example . . . . . . . . . . . . . . . . . . . 40

vii

5 Extending DSEIR with Deadlines 435.1 Extending Task Automatons . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Application of the Extension on the Running Example . . . . . . . . . . . 465.3 Application of Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3.2 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.3.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.3.4 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Data Abstraction 556.1 Motivation and Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2 Parameter Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.2.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2.2 Syntax analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2.3 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.3 Model Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.4 Necessary Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.5 Abstraction Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7 Verification 797.1 Revised Model Checking Scheme . . . . . . . . . . . . . . . . . . . . . . . 797.2 Abstraction and Verification of Running Example . . . . . . . . . . . . . . 83

8 Abstraction Fitness 868.1 Simulation Based Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.1.1 Syntax Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

9 Conclusions 91

10 Future Scope 93

viii

Chapter 1

Introduction

1.1 Preface

Embedded Systems Institute (ESI) is a leading research-based institute that tries tobridge the gap between academia and industry. It focuses on embedded systems tech-nology through open innovation research. This master project is a part of an ESI con-solidation project, building on the result of the Octopus project [1].

1.2 Context

During the early stages of the design of an embedded system, choosing among the avail-able design alternatives becomes a huge challenge. The Octopus toolset developed in theOctopus project uses model-driven design space exploration (DSE) approach to overcomethis challenge. The model-driven DSE approach aims at providing support for modeling,analyzing and selecting appropriate design alternatives during the early phases of systemdevelopment. This helps in making a good design decision after considering the variousmetrics of interest such as timing, energy usage and cost, as well as the multiple designparameters such as the number and type of processing cores, sizes and organization ofmemories, interconnects, scheduling and arbitration policies. Figure 1.1 shows a designspace exploration process in which a near optimal design is selected from an availabledesign space with multiple design choices. Users initially have multiple designs for asingle project and need to decide the best one among them. Manually, this is done byanalyzing these designs using various analysis tools and depending on the results andrequirements deciding the optimum design. Performing these analyses manually poseschallenges in maintaining consistency in the designs, also this process is time consuming.A DSE tool could assist the users in making design decisions faster, the Octopus toolset

2 Chapter 1. Introduction

Figure 1.1: The design space exploration process

is one such DSE tool. The toolset currently provides support for:

• High-level modeling of embedded systems, with a clear separation of concerns inapplication, platform, and the application-to-platform mapping.

• Formal analysis of functional correctness and performance, and

• Exploration of alternatives and synthesis of optimized designs.

Figure 1.2 shows the high level plug-in based architecture of the Octopus toolset. Itconsists of 5 modules which form the core of Octopus. These modules are:

• Modeling module: Interface to input user models, the Octopus toolset providesa graphical editor to design the user models.

• Kernel module: The modeling language called Design Space Exploration Inter-mediate Representation (DSEIR) used to represent the user models.

• Analysis module: The input models in the DSEIR language are subject tovarious analysis altogether via the tools in analysis module.

• Diagnostic module: Diagnostic tools for detecting the cause of failure (if any).

• Search module: The tools for searching through the entire design space for near

1.3. Motivation and Related Work 3

optimal design options by checking the models against various properties via theanalysis tools.

Figure 1.2: A high level plug-in based architecture of the Octopus toolset [1]

The various analysis tools can be seen in the main architecture in Figure 1.3. The ideaof Octopus is not to provide new methods but rather to provide connections betweendifferent tools, all based on the assumption that no single tool/method can answer alldesign questions. This architecture depicted allows for:

• Easy reuse of models among different tools, while providing model consistency

• Systematic and combined use of different tools and

• Domain-specific abstractions to support different application domains and easyreuse of tools across domains.

1.3 Motivation and Related Work

Schedulability Analysis is defined in [2] as follows: The problem of real-time schedulabil-ity analysis involves establishing that a set of concurrent processes will always meet itsdeadlines when executed under a particular scheduling discipline on a given system. Em-bedded systems often involve monitoring and controlling of complex physical processesusing applications running on dedicated execution platforms in a resource-constrainedmanner. These resources include memory, processing power as well as the time allottedfor execution. Such systems could be part of larger systems which can be sometimeslife-critical systems, for example in an airplane. For a real-time system with hard dead-


Figure 1.3: Low level architecture of the Octopus toolset [1]

lines, it is critical to ensure that the deadlines of all the tasks are met. The challenge ofschedulability analysis is to guarantee that the scheduling principle to be implementedavoids any deadline violations. Thus we need a method to ensure its smooth working.

In the Octopus toolset context, among the various questions affecting the decision makingin DSE is the schedulability of the design. To obtain a proper design that ensures smoothrunning of the system by satisfying all the requirements, it would also require the toolto ensure schedulability. The problem can be solved by imposing task deadlines andautomatically checking if they are always met. This would help the tool to immediatelyeliminate infeasible design options. Traditionally, there are two methods to determinethe schedulability of multiprocessor systems:

• Utilization bound tests: Utilization bound tests are theoretical tests based oncertain formulas, which depend on the number of processors and the utilization ofthe tasks. This method is safe but pessimistic.

• Simulation: Simulation of a system execution is the artificial representation of thetemporal behavior exhibited by the system during its runtime. This method is

1.4. Problem Statement 5

unsafe and does not perform exhaustive exploration of the state space.

In view of the drawbacks of utilization bound tests and simulation, it would be valuableif we could have a method for exact schedulability analysis without the pessimism ofthe utilization bound tests. The method suggested by Guan et al. [3] was to analyzeschedulability without any pessimism by transforming the schedulability problem intoreachability analysis problem of timed automata. Uppaal [4], a tool for timed automatamodel checking is used for this purpose.

1.4 Problem Statement

The core problem of this project is to perform schedulability analysis of models de-signed in Octopus via model-checking using Uppaal, thereby avoiding pessimistic andnon-exhaustive approaches.

Though the overall problem statement only mentions about schedulability analysis andmodel-checking, the actual task is much broader. In the Octopus toolset users can definetheir models using the DSEIR language. This model is entirely in the DSEIR syntax andthen needs to be translated into corresponding Uppaal syntax. Uppaal, or in generalany model checking tool, is prone to the state-space explosion problem. In the Octopustoolset, models are tuned for simulation, making them less applicable for exhaustiveanalysis methods. Thus these models can have large number of instances causing state-space explosion. So in a broader sense the problem statement can be divided into twophases:

• To make schedulability analysis possible in Octopus.

• To make schedulability analysis scalable for arbitrary DSEIR models.

The first point refers to providing an option in the Octopus toolset to perform schedula-bility analysis on the models designed. The second point refers to making Schedulabilityanalysis scalable to be applied on arbitrary models represented in DSEIR, with few syn-tax restrictions applied on the model. In Section 1.5 we describe the approach used tosolve these problems.

1.5 Approach

This section describes our approach towards solving the problems described in Section1.4. The DSEIR language provides necessary syntax support for the users to representtheir system in the form of models. A model usually represents a finite system. We


build the solution over the infrastructure provided by the Octopus toolset, to performtranslations to the Uppaal syntax. The problems addressed in this thesis are:

• Making schedulability analysis possible in Octopus :

– Extending the DSEIR language to include the deadline feature.

– Modifying the existing Uppaal translation from the DSEIR language by addinga mechanism to detect violation of deadlines.

– Automation of the entire process.

• Making schedulability analysis scalable for arbitrary DSEIR models in Octopus byperforming data abstraction.

The first part is achieved by extending the DSEIR language syntax with deadline whichis essential for performing schedulability analysis. The Octopus toolset previously con-sisted of a module (DSEIR translator) that translates the user defined model into aUppaal model, but lacks the deadline violation detection mechanism, which is requiredto perform schedulability analysis. Thus we model a deadline violation detection mech-anism in Uppaal and test it. As a next step, the DSEIR translator module is extendedto support the deadline violation detection mechanism. These additions make schedu-lability analysis possible in the Octopus toolset. Hence we have an additional analysistool, achieving the first goal of the thesis goals. This part is treated in Chapter 5.

The second part focuses on the modeling part of the DSEIR language. Using Octopustoolset, problems can be represented generically in terms of three components namely,application, platform (resources) and mapping of these tasks to respective resources. Therepresentation consists of finite/infinite systems with non-deterministic behavior becauseof the different possibilities for task execution. A task model in DSEIR has large numberof task instances but tends to repeat same behavior in different task instances, consider-ing these repetitions every time, tends to be an overhead to the model-checking tool andalso increases the state-space. Hence the second part of our approach is to automaticallyextract the repetition patterns and similarity between different task instances thus iden-tifying similar task instances and combining them. We consider methods like simulationand syntax analysis that could be used for performing the abstraction. The methods andthe procedure for abstraction are explained in Chapter 6. The new model created fromthis automatic extraction is an abstract approximation of the original model, usually anover-approximation. The over-approximation is the price paid to obtain reduced state-space. We also require to make necessary changes in the verification procedure to omitthe false-negative’s (obtaining non-schedulable results for schedulable systems) that areobtained owing to the over-approximation. These necessary changes are described inChapter 7. In Chapter 8 we then discuss a method to check the fitness of the parameterabstractor method.

1.6. Example 7

1.6 Example

In this section we describe an example which demonstrates some aspects of the schedula-bility problem. We describe this example in the DSEIR language with brief descriptionof the terms used; a detailed description is given in Chapter 2. We have 2 tasks, where Aexecutes for 5ms and B executes for 4ms except for a value of (b % 1000) == 805 whereit executes for 5ms. This execution time is obtained from the load shown in Figure 1.5.(It is actually the product of load and processing time of the resource which is required,but for simplicity we consider processing time of constant 1.) Both these tasks sharea single CPU and A has a priority higher than B. The task model is shown in Figure1.4. We have, A with parameter “a” which is also its port binding. It is initialized withthe value 1. The guard over the edge from A to itself states that “a” is continuouslyincremented by 1 until it reaches a value of 1000 indicating we have 1000 instances toexecute. We have also defined the deadline for A and B in Figure 1.5, with 6ms for bothA and B. (Note that deadline was not initially a part of the DSEIR language, it wasadded on later as a part of the solution.) Also there is a delay on the edge from A to itself(>> 4) which is set to 4ms. The working will be, A starts and executes for 5ms thenstarts again after a delay of 4ms. During this delay B executes. But for one conditionwhen B executes for 5ms, after 4ms of its execution it is pre-empted by A since there isonly one CPU and A has higher priority. Thus B will miss its deadline since it will haveto wait for 5ms to start again making the count 4ms(initially executed) + 5ms of A thuscrossing the deadline of 6ms. Thus B fails to meet its deadline, given the solution forthe first part of the problem this failure can be detected using the schedulability analysistechnique.

Figure 1.4: a)Example task-set in DSEIR syntax. b) The priority, deadline and scheduler of thetasks

Figure 1.5: Load of the tasks in the example task-set


These task-models can also have the state-space explosion problems. Consider a casewhere we try to verify this system directly on Uppaal. We have to check for all 1000instances, hence the state-space has 2000 different states at least (accounting for bothA and B with simple addition, actual value could be much higher). If we consider eachtask instance has 3 states during execution, the state space would be still 6000 states.Accounting for worst case combinations, the state-space growth would be exponential,forinstance the combination could be something like 1000 of A × 1000 of B. Thus the systemcould become intractable for a bigger system like this with large number of instancesfor each task. The second part of this thesis aims at solving this problem by performingdata abstraction and considerably reducing the state-space.

1.7 Overview

This section describes the structure of the report. The structure and the syntax of theDSEIR language are explained in detail in Chapter 2. The model checking tool, Uppaal,is described in Chapter 3. The existing DSEIR translation is described in Chapter 4.Chapter 5 describes the solution provided to the first problem of designing the deadlockdetection mechanism in Uppaal and extending the existing translation of DSEIR toUppaal. We also treat the running example here to show how schedulability checks onthe system can be performed in the Octopus toolset. Chapter 6 realizes the second goal ofthe thesis, namely, performing abstraction of the model in order to make model-checkingscalable. Also an algorithm that is used to perform abstraction and its intermediatesteps are explained in detail in the same section. The application of algorithm is thendemonstrated by applying it on the running example. Chapter 7 explains the verificationprocedure for schedulability analysis, this includes some revision in the model checkingscheme. Chapter 8 describes the methods to measure the fitness of the abstractionprocedure used for providing scalability to the schedulability analysis technique. Finally,we conclude the thesis in Chapter 9 and present some recommendations for future workin Chapter 10.

Chapter 2

Design Space ExplorationIntermediate Representation

The Octopus toolset follows the Y-chart approach (Figure 2.1). The essence of theY-chart approach is an orthogonal specification of application and platform and theircombination in the mapping. It supports clear separation of application and platform. Inthe Y-Chart approach [5], initially an architecture is designed in the specific compositionas shown in Figure 2.1, implemented, analyzed and then diagnosed. These analysisresults are then diagnosed to find the cause of failures, if any. The diagnosis results areused by the designers to improve the initial design by making necessary modifications toprevent the observed failures. The Octopus toolset has a similar work-flow. We createan initial design and improve it with analysis and diagnostics feedback.

Figure 2.1: Octopus toolset using Y-Chart approach[5]

Using the Design Space Exploration Intermediate Representation(DSEIR) language any

10 Chapter 2. Design Space Exploration Intermediate Representation

generic problem can be modeled as an input to the Octopus toolset. The DSE basicallyinvolves defining a model in terms of three components: Application, Platform and theMapping of the application onto the platform. This problem-specific model (specific tothe user) is then analyzed and possible flaws detected through the analysis are diag-nosed. After analysis and diagnostics, if any problems are found, the cycle is repeatedby redefining the initially defined model and proposing solutions to the problems found.The diagnostic information helps in proposing the solution. This entire process can bemanual or automatic. In this chapter we introduce the DSEIR language and its syntaxconstructs required for modeling in detail, in Section 2.1. We then define a runningexample in the DSEIR constructs in Section 2.2 which will also be used in the rest ofthis thesis to explain the application of various approaches used in this thesis.

2.1 DSEIR Language

This section is largely derived from the Octopus documentation [6], we here describe thesyntax of the DSEIR language in terms of its three basic parts, which are, application,platform and mapping. Each part is explained in detail with both syntax and examplediagrams.

2.1.1 Application

In DSEIR an application is modeled in terms of atomic tasks as the basic building blocks.Moreover, an application consists of global variables, local variables, a task-flow graph,start-statements, end-statements, edges, ports, task load, and task handovers betweenvarious tasks. We explain each of these concepts with its syntax. Figure 2.2 showsthe generic syntax of DSEIR models. An instance of this syntax is given in Figure 2.3.Below, we explain the concept of local and global variables and task-flow graph followedby its tasks and other entities of the application.

Global Variables are variables that are used to store data and are visible to every entitypresent in the task-flow perspective. The declaration syntax of global variables is shownin Figure 2.2, they are declared along with the name of the application (SyntaxofApp()).An example of a global variable can be seen in Figure (2.3) where “c” is a global variableinitialized with an integer value 1.

A local variable is a variable that is declared within any task and is local to that particulartask. The syntax for declaration of the local variables is “Type Variable” as shown inFigure 2.2. The example model in 2.3 shows “Int x” as a local declaration for task A.

The task-flow graph specifies the flow of tokens between individual tasks. The token

2.1. DSEIR Language 11

Figure 2.2: Task-flow perspective syntax diagram

Figure 2.3: Task-flow perspective example

flow represents the flow of control and data between individual tasks, thus representingdata dependency and execution sequence as in general scheduling terms. On a globalperspective the tasks and their connections with other tasks via edges can be viewed asa task graph, the edges represent the dependency (data or control). For example, “a *10” on the edge from task A to B is the value passed onto B by A.

The task in DSEIR is comparable to a task in real-time systems. It has several attributesand it executes (fires) to complete some actions for the system. In DSEIR task is identicalto a function in a programming language, having zero or more parameters of given types.When each parameter of a task is given a value, a task instance is obtained. A taskinstance executes for a required amount of time depending on its load (explained later),during its execution it consumes some tokens and produces some. A task is said to be inthe “ready” state in scheduling terms when it has enough tokens in its ports. Each taskhas a task guard associated with it, which is an expression that evaluates to a booleanvalue and needs to be true for the task to execute. The guard is by default true; if notspecified. Task declaration syntax can be seen in the model of Figure 2.2. For example,in Figure 2.3 A and B are tasks, the task guard of A is true and for B it is b < 11.The task parameters of A and B are respectively “a” and “b”, which are both of type


Integer.

The tasks can also contain a set of start-statements and end-statements. Like the nameitself suggests they are executed in the beginning and end of task execution and usuallyaffect the local variables. In the example, shown in Figure 2.3, x = 1 is the startstatement assignment and x = 0 is the end-statement assignment.

Edges are used to connect a task and the port of another task. They represent transferof data and control from one task to another via tokens. As explained before, tokens arepassed through edges and this passing is guarded by a condition on the edge. Conditionis an expression which evaluates to a Boolean value. For example, in Figure 2.3 theedge from A to B has the condition as a > 4 and the value to pass is a ∗ 10. Thecondition is considered to be true if absent. The edges are also associated with a delay,the time taken by the tokens to pass through the current edge. The value of delay is zeroby default and is represented as “>> Delay” as shown in the syntax describing model(Figure 2.2).

A port acts as a destination to an edge coming from another task and is contained insidea task. Port binds (assigns) the value from the input edge to its binding expression. Incases where the initial value of the port is set, the initial binding happens using thisinitial value. The binding expression is a mathematical expression that consists of taskparameters, but usually it contains only one task parameter to which the value fromthe edge or initial value is directly assigned. Ports also have conditions associated withthem which are similar to conditions on edges. If the condition on the port evaluatesto false then binding does not happen. For example, in Figure 2.3 the condition for theport in Task A is true and the binding expression consists of only a parameter “a”.

A task that has all the required tokens in its ports is said to be “enabled” and willbegin executing when it is allocated with resources (platform) by the schedulers. A portcan contain more than one token at a time and requires ordering schemes. Port can beunordered ; in such a case the task can non-deterministically choose any token and use itto bind. It can alternatively be FIFO, in which case the token that has first arrived mustbe used first. The ports can be unbounded i.e., can have arbitrary number of tokens.After the firing of the task the tokens are said to be consumed and hence removed fromthe port (The binding expressions are assigned to a default value, e.g. 0 indicating thatthe tokens are removed). The tasks can also produce tokens while firing, which are thensent through the output edge from the task.

Along with a task, certain properties of the task can also be defined such as the Taskload which defines the resource requirements of a task. Task load also partially decidesthe execution time of the task. The load does not change during the execution of atask instance and also that unit of load is considered the same for each service type. Inother frameworks tasks may directly request for resources, but in DSEIR, resources arehandled by the schedulers and they provide services to the tasks. The tasks here request


services rather than resources. Services can be of type COMPUTATION, STORAGE,TRANSFER or any other user-defined type.

Figure 2.4: Load perspective diagram syntax

Figure 2.4 shows the declaration of load and handover between two tasks in the DSEIRsyntax. Load expression is a mathematical expression which results to a constant ora distribution over a specified range when evaluated, it is usually dependent on theparameters of the task or sometimes simply a constant or range. Figure 2.5 shows anexample of the load perspective. We can see the mathematical expression for load overservice type INTERNAL STORAGE in task A, which is dependent on a parameter “a”.The remaining expressions are just constants.

Figure 2.5: Load perspective diagram example

The handover expression is also similar to the load expression. To model resource reser-vations and situations where one task needs to transfer rights over some resource toanother, DSEIR introduces the notion of task handover. A handover is an integer ex-pression associated to each edge (considered zero if absent). This expression is evaluatedat the end of the execution of the current task instance; it can depend on the task param-eters and other local or global variables. The amount of resource that has been handedover is then released by the resource receiving it or is transferred over to another taskuntil it is released.

2.1.2 Platform

The execution of a task requires resources. In DSEIR resources and tasks are not directlymapped onto each other. Instead resources provide services and tasks requests for theseservices. These requests for services are allocated by the scheduler on the basis of the


scheduling policies and the availability of the resource. The types of resources consideredhere are usually CPU, GPU, FPGA and MEMORY. Along with the resources theirattributes, given below, are also defined:

• Service Type: Defines the type of services provided by the resources in the model.The possible service types are COMPUTATION, STORAGE, TRANSFER andany other user-defined types.

• Resource Name: Defines the name of a resource used in the model, e.g., CPU orMEMORY.

• Capacity: Defines the capacities of the resources managed by the scheduler, e.g.,the capacity of CPU is defined to be 1.

• Processing Time: Defines the processing time required by the respective resourceto process unit load. E.g.Processing time of CPU is 4 time units per 1 unit of load.So if the load on the service type provided by CPU is 10 then the total time takenby CPU to process this load amount is 40 time units.

Figure 2.6: Resource perspective syntax diagram

Figure 2.7: Resource perspective diagram example

Figure2.6 shows the declaration of two resources which provide the same service type.Figure 2.7 shows a declaration of a resource named as Memory with capacity 100 unitsand processing time as 0 time units. This resource provides a service of service typeINTERNAL STORAGE.

Tasks put some load on their required service types which are granted by the schedulerand mapped to the resources that provide them (service type). The mapping of a servicetype to the resource that provides that particular service type, by the scheduler is shown


in Figure 2.8. The amount of the resource to be provided is decided dynamically duringrun time and is usually problem specific. Some of the resources like processing units(CPUs) are also associated with attributes like pre-emptivity. This attribute of pre-emption is defined in the scheduling perspective in Figure 2.8. In Figure 2.8, the whitecircle connecting the resource to a service type means that the resource is pre-emptiveand the black circle connecting the second service type represents non pre-emptiveness.The amount on the edge from the white circle to the resource describes the amount ofresource to be allocated to that specific task requesting this service type. This amountcan either be a constant value or the load value defined by the requirement of thetask. For the concept of pre-emption, consider a scenario where two tasks X and Yare contending for the same service type provided by one single resource R. Task Yhas a priority higher than X. Task X is currently executing and has finished 50% ofits execution, when task Y is enabled (has enough tokens in its ports) and is ready toexecute. At this moment task X is pre-empted and Task Y is allowed to execute. TaskX can continue only after task Y has finished execution.

Figure 2.8: Scheduling perspective syntax diagram

Figure 2.9 shows an example of a scheduler mapping resources to the respective servicetype they provide. Here, amount allocated in case of CPU is either 1 or none and isnot dependent on the value of any parameters. But in the case of M1 and M2 theamount allocated is set to be the amount of load requested by task A for the particularservice type. The load expression can be dependent on the task parameters, hence thisallocation also becomes dependent on parameters.

2.1.3 Mapping

A scheduler provides tasks with resources requested by them. In DSEIR, a scheduler ismapped onto a task or a set of tasks depending on the service type they require. Consideran example, tasks A and B have requirements for service types COMPUTATION anda resource called CPU that provides the COMPUTATION service type. Thus these 2tasks can share a scheduler like in the example shown in Figure 2.10.


Figure 2.9: Scheduling perspective diagram example

Figure 2.10: Mapping perspective syntax diagram

This mapping is defined along with certain attributes of the task which are set in themapping perspective, they are:

Priority : Defines the priority of each task. It is a mathematical expression which resultsinto an integer constant when evaluated. The expression can be used to specify dynamicpriorities. For static priorities we can define a constant. The priority of the task willdetermine the task that will be granted a resource when there is an ambiguity like tworesources are ready at the same time and requesting for the same service type.

Deadline: Defines the relative deadline of a task, in a set of tasks. It is a schedulingterm which defines the latest time until which a task can execute. It is a mathematicalexpression which results into an integer constant when evaluated or a distribution. Note:This feature was not existing previously in the DSEIR syntax and has been added lateron in the context of this thesis. The schematic view of mapping a task to a particularscheduler along with an example is shown in Figure 2.10. The concrete example showsthe integer constants declared for priority and deadline of Task A, for the deadline oftask B “if b> 2 then 20 else 10” is an expression which evaluates to an integer constantdepending on the value of the parameter “b” local to Task B. If the “condition” in the“If statement” evaluates to true the deadline will be 20 or else 10. Both the tasks sharethe same scheduler (sAB).

2.2. Running Example in the DSEIR Syntax 17

2.2 Running Example in the DSEIR Syntax

The Octopus toolset provides some example models specified in the DSEIR language.We use one of this to describe the problems solved by this thesis. First we take one ofthese example models and use that to illustrate various concepts of DSEIR syntax.

This example consists of a task-set with 3 tasks namely, scan, image processing andprint as well as resources and schedulers which maps these tasks into required servicetypes. The basic job of this system is to process the pages to be printed and thenprinting them. The task-set execution is initiated by initializing scan which is to beexecuted first in the sequence. The data (page numbers) about the pages to be printedand their corresponding page sizes are transferred to scan task which performs a set ofoperations given this data and transfers the results to the next task (image processing)after finishing its execution. Image processing task also performs some operations andtransfers the page data to the next task (print), which prints the page.

2.2.1 Application

The DSEIR model for this example is shown in Figure 2.11 and explained in detail in thissection. The ports of tasks scan, image processing and print task are respectively namedas “inA”, “inB” and “inC”. Scan task is initialized by providing it with a token; thisaction is executed by setting the initial values for the port of scan task. In the currentexample the initial value for the port binding is [1, dist(sizeDist)] where sizeDist is aprobability distribution for the appearance of elements (array elements), with probabilityof each element in the distribution. It is defined as an array “int sizeDist[] = [1, 20, 2, 50,3, 30]” which means that constant 1 appears with 20% probability, 2 with 50% probabilityand 3 with 30% probability, the declaration can be seen in the global declarations. Thefile name has been set to ODSE.

Once the ports have enough tokens, scan task waits for its execution until its resourcerequirements and priorities are satisfied. After scan task has finished execution it pro-duces two tokens, of which one is sent over an edge to scan task itself and re-consumedfor the execution of its next instance and the other token is sent over the edge to port“inB” and is consumed by scan task for its execution. The token to be sent from scantask to itself, reaches only if the guard condition over the edge from scan task to its port“inA” is satisfied.

After execution, image processing task produces a token which is passed on to print taskfor the execution of its current instance. Print task executes but does not produce anytokens. Note that each task here has its parameter name as pageSize, since it is a localvariable the names can be the same. The edges, conditions, expressions, handover andthe port bindings are defined as follows:


Figure 2.11: Task-flow perspective diagram for the printing example

• Scan task:

– Edge to “inA”: Here numObjects is a global variable which is set to 5. Thisin combination with the guard on the edge from scan task to its port “inA”defines that scan task executes for 5 instances, since after that the guard overit evaluates to false. The value expression (pageSize[1] = pageSize[1]+1) overthe edge has the values that are used to bind the variables of port “inA”.This expression changes the element at index 1 of pageSize array and passesthe new array onto the port.

– Edge to “inB”: The value expression (pageSize) over the edge has the valuesthat are used to bind the variables in port “inB”. There is also some amountof handover that takes place from scan task to image processing task. Inthis case it is the RESULT STORAGE and 20 units are handed over. Thehandover is shown in Figure 2.12. Scan task initially claims 20 units of servicetype RESULT STORAGE, after its execution it does not release this resourcebut transfers the same amount (since handover expression and load expressionof scan task are same) to image processing task which uses this storage toperform its operations, and does not have to explicitly claim it.

– Port “inA”: Binds pageSize (binding Expression of “inA”) array with thevalues provided by the value expression (pageSize array with one of its ele-ments altered) on the edge to “inA”. This binding happens always whenevertokens are produced by scan task and the guard over the edge evaluates totrue, since the condition for port binding is explicitly specified as true. In thebeginning “inA” is initialized by binding its variables with the initial valuesonto an integer array of size (pageSize) which stores this information.


Figure 2.12: Load perspective diagram for the printing example

• Image processing task:

– Edge to “inC”: The value expression over the edge to “inB” (pageSize) pro-duces the value that is used as binding to “inC”.

– Port “inB”: Binds pageSize array with the values provided by the value ex-pression on the edge to “inB”.

• Print task:

– Port “inC”: Binds pageC an integer variable with the value provided by theexpression (pageSize[0] array access of element at index 0) on the edge to“inC”.

Scan task requires the services of type COMPUTATION, INTERNAL STORAGE andRESULT STORAGE, the amount of load to be provided to the task is decided by the


scheduler. The behavior of the scheduler is problem specific. If the available amount ofa resource is less than the requested amount by the task then the scheduler grants theresource only if its possible for the task to execute with the allocated amount (This isknown apriori and amount defined as a constant in this case is irrespective of the loadrequest of the task, thus load could be more than or equal to the constant). If it is notpossible, scheduler does not grant the resource and waits for the requested amount to beavailable. The load expression defined for each service type decides the amount of loadat each instance. The detailed definition of load of each task is given in Figure 2.12.

2.2.2 Platform

The execution of the task requires services of different types, which are provided bythe resources and are allocated to the tasks by the scheduler. Allocation is done bythe scheduler on the basis of the scheduling policies and the availability of the resource.There are four resources considered here, namely:

• CPU

• GPU

• FPGA

• MEMORY (M1 and M2)

The resource definitions are shown in Figure 2.13.

Figure 2.13: Resource perspective diagram for the printing example

The resources are defined along with their attributes such as resource name, processingtime, capacity and service type. The processing time for the CPU, GPU and FPGA in


the current example ranges over an unknown distribution from 9 to 11. An unknowndistribution is a type of distribution where the values are non-deterministically chosenfrom the given interval, i.e. the probability of the elements are unknown. The capacitiesof these resources are pre defined with CPU and GPU defined as 1 unit, FPGA has 1unit and each memory has 100 units. The processing time of the memory resources M1and M2 is 0. The tasks are mapped onto their requested resources by schedulers. Theallocation of service types will be done dynamically during the execution depending onthe requirement of tasks and their priority.

In this particular example there are schedulers that manage a particular set of tasks.These schedulers then map the tasks onto the resources that they manage. Further themapping of the service types required by the tasks to the service types provided by theactual resources is also done by the schedulers. This is shown in Figure 2.14.

Figure 2.14: Scheduling perspective diagram for the printing example

2.2.3 Mapping

The mapping of each task to scheduler is shown in Figure 2.15. “sA”, “sB” and “sC” areschedulers. The tasks are defined with their respective priority and deadline expression.

Scan task requires 3 types of services COMPUTATION, INTERNAL STORAGE andRESULT STORAGE. The scheduler “sA” for scan task maps the services to the re-sources CPU and Memory M1. The actual load is defined in the application part inFigure 2.12. Similarly image processing task and print task use scheduler “sB” and


“sC” respectively, for the mapping to services required by them. In this example thescheduler grants the amount requested by the task if available, and otherwise no serviceis granted until the requested quantity becomes available.

Figure 2.15: Mapping perspective diagram for the printing example

The mapping also describes the priorities. Here scan task has the highest priority,followed by image processing task and print task. Due to task dependency (Figure 2.11the edges describe dependency) usually the execution starts with scan task followed,respectively by image processing task and print task. Along with the priorities, deadlineis also defined in the mapping perspective.

Chapter 3

Uppaal

Uppaal is a toolbox for verification of real-time systems jointly developed by UppsalaUniversity and Aalborg University [7]. In Uppaal, the concept of timed automata is usedto model processes in a system. A network of communicating timed automata forms theentire system. The definition of these processes also includes various attributes andfunctions with data types such as integer or user defined structured data type. Channelsynchronization are used to synchronize two or more processes. The purpose of usingUppaal in this thesis is to perform schedulability analysis via model checking. One of themain problems we address in this thesis is state-space explosion, which is also a problemin any model checking tool and also is extensively addressed in the literature regardingUppaal [7]. Uppaal provides a graphical user interface which can be used by the usersfor creating, editing and simulating the input models followed by verifying the inputmodels. Verification involves specifying the property of the model in a logical querylanguage and exhaustively searching the state space to make sure that the specifiedproperty is satisfied. For more information about Uppaal and its components refer [8].

In this section we briefly describe the modeling language of Uppaal, the specificationlanguage used to verify and also how the tool works. For a more detailed explanation ofthe Uppaal syntax we refer the Uppaal documentation [9]. In explaining the syntax, wemostly confine ourselves to the constructs that are used in the remainder of this report.

To illustrate the syntax we use a coffee machine example, depicted in Figure 3.1. Thefeatures missing in this example are explained in separate illustrations.

The coffee machine example models the behavior of a system with three components,a coffee machine, a person and an observer. The person repeatedly tries to insert acoin, tries to extract coffee after which he will make a publication. Between each twoactions the person requires a suitable time-delay before being ready to participate inthe next one. After receiving a coin the machine should take some time for brewing the

24 Chapter 3. Uppaal

Figure 3.1: Coffee machine example [10]

coffee. The machine should time-out if the brewed coffee has not been taken before acertain upper time-limit. The observer should complain, if at any time more than 8 time-units elapse (expressed by the constant timeout in the model) between two consecutivepublications.

3.1 Uppaal Timed Automata Modeling Language

Uppaal modeling language is based on timed automata, which are finite-state machines,extended with the concept of time [8]. Time is represented by clock variables. All clocksin the model progress synchronously. In Uppaal, a system is modeled as a network ofseveral such timed automata in parallel. Each timed automaton is an instantiation of atemplate automaton. The Uppaal syntax has 3 sorts of declarations, given below:

• Global declarations: The declarations in the main section which are visible toall templates. The declarations can include clock variables, integers, user definedvariables, constants, channel and user-defined functions. The global declarationsfor the coffee machine example are given below:

// Only Synchronization channels are declared. - comments

urgent chan coin, coffee, publication;

int count; //Used to count the number of coffee’s served.

• Local/Template declarations: Local declarations are similar to the global decla-

3.1. Uppaal Timed Automata Modeling Language 25

rations except for the fact that a variable defined in this section is local to thatparticular template. An example of a local definition for the person template inthe coffee machine example is given below:

clock y; // A clock variable used in the template

• System declarations: System declarations are used to instantiate the templatesinto processes and execute them in parallel. A process instance of a template isdefined by giving it a process name and instantiating it parameters. Templateswithout any parameter can be readily used as processes. System declaration startswith the keyword system and continues by naming all process to be composed inparallel. For the coffee machine example the system declarations are given below:

Obs = Observer(8);// Process instantiation

system Person, Machine, Observer; //Calling all the processes

In this example we can see that observer is a parameterized template with a parametertimeout, this is instantiated in the system declarations with the value 8. Figure 3.2shows the parameterized template of observer.

Figure 3.2: Parameterized template Observer in coffee machine example

Other elements of the Uppaal modeling syntax are:

• Synchronization: There are three types of synchronization in Uppaal, describedbelow:


– Binary Synchronization: Channels are used for message passing between edgesof different templates. They can be declared using the syntax “chan vari-able name” either in the local declarations or in the global declarations. Anedge labeled with variable name! synchronizes with another edge labeledvariable name?, where variable name! acts as the sender and variable name?acts as a receiver. In the coffee machine example the binary channels arecoin, publication and coffee. This type of synchronization is also known ashand-shaking.

– Broadcast channels: Channels can also be declared as broadcast channels,using the syntax “broadcast chan variable name”. The difference between abinary channel and a broadcast channel is that the broadcast channels syn-chronize a send with as many “receive” as “enabled”. For example, considerthe Figure 3.3 which represents a scenario with 3 templates A, B and C, withone broadcast channel test. A sends two messages and both B and C receivethem. So in working all these automata work synchronously, i.e, when Amoves from A1 to A2 both B and C mimic the same due to the synchroniza-tion channel.

Figure 3.3: Example for broadcast channel

– Urgent channels: These channels enforce a synchronization when the edge is“enabled”, i.e., do not allow the time progress when both sending and receiv-ing actions can be taken. Edges having urgent channels cannot have guardswith clock variables. Syntax for urgent (respectively, urgent broadcast) chan-nels is “urgent chan name variable name” (respectively, “urgent broadcastchan variable name”). For example, all three channels in the coffee machineexample, i.e., coin, coffee and publication of the coffee machine example areurgent channels.

• User functions: Users can define functions similar to imperative languages such asC++ or C functions except that they cannot use pointers. These functions canhave parameters as input and can produce an output. Functions can be global aswell as local, depending on their use. For example, in the Observer template thefunction countFunction is declared in its local declarations as:

3.1. Uppaal Timed Automata Modeling Language 27

int countFunction(int count){

count = count+1;

return count;

}

//This function is used to count the number of times coffee is served.

• Data types in Uppaal:

– Clock Variables: Clock variables are used in Uppaal to keep track of time.Clock variables are of type real. They can be declared as “clock variable name”as used in the coffee machine example. There is a possibility to reset the clockand also pause the clock. The actions are defined as : “x‘==1” to indicatethe clock running, “x‘==0” to indicate the clock is paused and x = 0 to resetthe clock. All clocks in Uppaal progress synchronously. The coffee machineexample uses a clock variable “y” in the person template.

– Structured Data types: Along with the normal data-types such as integers,arrays of integers and clocks, Uppaal also allows user defined structured data-types; record-types can be defined using the keyword typedef struct. Forexample, consider the definition “typedef struct {int start time; int end time;}task”. It defines a record type named task which has two components namely,start time and end time, both of type integer.

– Bounded Integers: The Integer definitions can be bounded in Uppaal. E.g.,int [0,10] var; specifies that the variable var can take values ranging from 0to 10.

– Constants: Values that are constant throughout the model can be defined as“const int variable = value”, in global declarations.

Next we discuss the structure of a template automaton. Each template consists of a setof locations, transition edges between locations and local declarations. We define eachcomponent of the templates in detail:

• Locations: Locations along with the parameters and the valuations of variablesand clock are used to describe the state of a system. A location is denoted by ablue circle. Figure 3.4 shows the location which are listed below:

– Normal: a typical location in an automaton is depicted by a circle.

– Initial: Defines the starting location of a process template. It is denoted byan encircled location.

Locations can also have invariants defined. Clocks, integer variables, and constantscan be referenced in the invariants [9].


Figure 3.4: Types of locations

In the example model (Figure 3.1), all 3 templates have an initial location andseveral normal locations. Each location can also be given a name; e.g., in theexample model, Idle, Ready, WaitCoin, WaitCof, Go and Complain are locationnames. The WaitCof location has an invariant (y<=2) which is defined over theclock variable and specifies the amount of time the system can be in that location.

• Edges: The edges are used to connect two locations to denote possible transitions.It is defined along with various attributes such as the ones given below:

– Select: Defines a variable and a range of values from which the variable cannon-deterministically take a value. In Figure 3.5, x: int[0,10] defines that“x”obtains a value in the range from 0 to 10 non-deterministically, when theedge from location 1 to location 2 is taken.

Figure 3.5: Example of an edge

– Guard: Defines the condition, which has to be true in case the edge associatedwith the guard is to be taken. A guard is of Boolean type and consists ofinteger or clock values. Clock values are always compared with integer values.In Figure 3.5 the edge from 1 to 2, has a guard x < 10. This states that thisedge can be taken only when x < 10. In the coffee machine example, in persontemplate the guard “y==2” can be seen over the edge WaitCof to Go.

– Synchronization: Defines the synchronization labels that affects a particularedge or is initiated by a particular edge. The label is either in the form Chan-nelName! Or ChannelName?. The synchronization variables in Figure 3.1are publication! and coffee!. In Figure 3.5, channel! denotes synchronizationvariable.

– Update: Defines update operations on variables. For example, in Figure 3.5the variable “x” is updated with value 0. In the observer template of the

3.2. Uppaal Query Language 29

coffee machine example, the count variable is first updated to 1 and thenupdated using valued calculated by the function countFunction(count).

3.2 Uppaal Query Language

To perform model checking, we need a logical language to define the properties thatthe model should satisfy. The query language used in Uppaal is a subset of the TCTL(Timed Computational Tree logic) [11]. Similar to TCTL the query language consists ofstate formulae and path formulae. Path formulae can be classified into safety, livenessand reachability. We particularly consider the reachability and safety in this project.

• State formulae: A state formula is a logical expression with unary or binary op-erators combining components that represent the process template. For example,a state formula for the coffee machine example can be “y==2”. A state formulacan also be used to check whether the system is resided in a particular location, byusing the syntax “process.location”. For checking deadlocks Uppaal has a specialkeyword “deadlock”. System reaches a deadlock when no outgoing transition isenabled and then the clock variables halt as well.

• Path formulae: A path formula quantifies a logical formula over some or all pathsin the system. “E” is used to existentially quantify over paths and “A” universallyquantifies over all paths in the system. In combination with the above mentionedquantifiers, one can use the modalities <> and [] respectively, to specify eventualityand invariance of a logical formula. These combinations (required combinationsare only specified) are spelled out as follows.

– A[] φ - For all paths φ always holds.

– E<> φ - There exists a path where φ eventually holds.

Two particular types of formulae that we consider in the remainder of this report arereachability and safety. Reachability is to check whether a particular state formula canbe satisfied in some reachable state. A formula of the form E<> φ can be used forthis purpose. For example in the coffee machine example it can be checked whether thecomplain state can be reached by using the formula “E<> Observer.Complain”, thisshows that the timeout of 8 seconds has happened since complain location is reached. Ifthis query returns false, it means that the system never reaches the complain location,i.e., two consecutive servings of coffee takes place within 8 time units.

Safety properties are used to ensure that some properties never hold or always hold.Safety properties can also be represented as a reachability problem by checking if thenegation of the considered property is reachable. Checking that deadlock never occurs


is a kind of safety property. It can be checked using the formula “A[] not deadlock”,which means deadlock never occurs along any path.

Chapter 4

Existing DSEIR Translation toUppaal

The Octopus toolset already has the required infrastructure for translation of the usermodel in the DSEIR syntax to a model in the Uppaal syntax. Also creation of necessaryquery files for checking the newly created model. The work-flow of the entire systemis shown in flow diagram in Figure 4.1. Given a user model, DSEIR model is createdmanually. This DSEIR model is then translated to Uppaal syntax using the existingtranslation support, i.e., the DSEIR translator. A suitable query file is created manuallyfor the corresponding Uppaal model file using the Uppaal query file creator of Octopus.The query file consists of the properties that need to be verified, written in the querylanguage of Uppaal. Using the created Uppaal model file and the query file we apply theUppaal verifier to check whether the property is satisfied or not. In case the property issatisfied the model is verified otherwise a trace file is generated witnessing the violationof the property. This trace file is then converted into a user readable format and stored.This kind of analysis framework can also be seen in [12], with verification trace providedas output.

In this section, we first describe the existing translation support to Uppaal. This isdone using a generic model which is defined in Section 4.1. Using this generic model,the mapping of a task in DSEIR syntax into an automaton in the Uppaal syntax isdescribed in Section 4.2 along with the working of the corresponding Uppaal model.The application of this translation on the running example is treated in Section 4.3.

32 Chapter 4. Existing DSEIR Translation to Uppaal

Figure 4.1: The existing work-flow for formal verification in the Octopus toolset

4.1 Generic Model

Consider a generic model with two tasks A and B. Here the two tasks have variousparameters, A has “n” parameters and B has “m” parameters. The number of ports inA is “x” and B is “m”. In DSEIR, the number of ports should be at least equal to thenumber of parameters, with each of those ports having their binding expression as oneof those parameters. A has “z” edges in this example and B has no edges here.

4.1.1 Application

The task-flow perspective diagram of the generic model can be seen in Figure 4.2. Thetask parameters of A and B are “a1 · · · an” and “b1 · · · bm” respectively. Task A has“x” ports with “n” ports with only parameters as binding expressions and remaining“(x-n)” ports contain “E” a mathematical expression containing operators, constantsand parameters. The distribution of ports with only parameters and the rest are notnecessarily in sequence always, hence they can be spread over the “x” ports in any order.The sequence numbers “Aa”, “Ab” indicate this randomness, here “a” and “b” couldbe any value between 1 and “x”. The operator set for “E” is {+,−, ∗, /,%} and thelogical operator set for “C” is {<,>,≤,≥,==}. For example, a + b is a mathematicalexpression, a + b > 5 is a conditional expression. The notations “A1 · · · Ax” describethe initial values of the ports. The initial value of a port is an array with 0 or more

4.1. Generic Model 33

Figure 4.2: Task-flow perspective of the generic model

elements.

Edges that connect the tasks have their own conditional expressions “Ce” and valueexpressions “Ee”. There are “z” (some number) edges for task A in this model. Notethat all “m” ports of B may not always have edges from task A, but can have edges fromother tasks as well. “TGa” and “TGb” are task guards of A and B respectively.

Figure 4.3 shows the load and mapping perspective of the generic model. Task A requires“p” service types with load amount associated with each of those service types, similarlyB requires “q” service types. Service types of A has numbering from 11 to 1p and B has21 to 2q to specify that both can request for different service types, they could be sameas well.

Figure 4.3: a)Load perspective of the generic model. b)Mapping perspective of the generic model


Figure 4.4: Resource perspective of the generic model

4.1.2 Platform

Figure 4.4 shows the resource declaration for the generic model. We have “u” resourcesproviding “service type 1” and “v” resources providing “service type (p+q)”. There aretotal “(p+q)” service types required by tasks A and B. We skip the scheduling perspec-tive diagram here since it does not add any information to the translation description.

4.1.3 Mapping

The last perspective in Figure 4.3 shows the scheduler mapping of the tasks with theirpriority and deadline defined respectively. Priority and deadline of each task is alsodefined. They are mathematical expressions which evaluate to an integer.

4.1.4 Restrictions in Translation

The current infrastructure for translation to Uppaal consists of certain restrictions onthe input DSEIR model it can translate, they are listed below:

• Ports cannot have conditions.

• Ports can have only single variables in their expressions.

• Delay on edges is not supported.

• Dynamic task priorities are not supported.

• Global Variables are not supported.

The generic model here follows these restrictions and is constructed using a subset ofthe actual DSEIR construct.

4.2. Syntax Mapping 35

4.2 Syntax Mapping

This section describes the details of mapping a task in DSEIR syntax into an automatonin the Uppaal syntax and creating necessary local, global and system declarations forthe same. As described earlier a task is translated into template automaton in Uppaalsyntax. From the scheduling theory perspective a task usually has two states; it can beidle or active. The DSEIR translation to Uppaal hence creates two locations, namelyidle and active for a particular task automaton. All tasks have these two locations. Sincetasks can also be pre-empted and initialized there can be more locations. When a taskhas its initial values set, it has an extra location in the translation called initialize. Whena task has a service type which is provided by a pre-emptable resource then the translatedautomaton has a location named pre-empted which is reached when this particular taskis pre-empted by a higher priority task. Hence there are 4 types of translations possibleas listed below:

• Idle, active (only and common for the rest of the types).

• Initialize and pre-empted (as extra states).

• Initialize (only as extra state).

• Pre-empted (only as extra state).

We discuss the translations with respect to the generic model defined previously. Thetranslation of task A with initial values and pre-emptable resource requirement into atemplate, is shown in Figure 4.5. This translation in Figure 4.5 has four locations; withinvariants shown with colour maroon. The locations of the automaton for task A are:

• Initialize: When the initial values of a task are set, it will have this location. TaskA in the generic model has its initial values set hence it contains the locationinitialize.

• Idle: From the initialize location, Task A goes to the idle location where it waitsfor enough number of tokens in the port, priority requirements to be satisfied andresources to be available.

• Active: In the active location the task has acquired all the resources and is run-ning. The time for which the task will be active is decided by the processing time(Figure 4.4) and the task load (Figure 4.3). Two functions are used to determinethe minimum and maximum duration possible for its execution, namely the min-Duration() and maxDuration() respectively. These functions are declared local toeach task template. Invariants are used in this location so as to prevent the CPUfrom executing the task for a time more than the maxDuration(). minDuration()is checked to complete at least the minimum duration of execution before returning


Figure 4.5: A task model with all possible locations

to the idle location by the guard on the edge active to idle. These functions aredefined in the local declarations which are defined later in this section. A clockvariable “x” is used to keep track of the time elapsed in executing the task. Herex‘ == 1 symbolizes that the clock is ticking when in active location.

• Preempted : When the task instance is in the active location and is running on a pre-emptable resource like CPU then the task instance can be pre-empted. Hence thislocation is reached when a task instance is pre-empted. Preemption is determinedby checking the active status of other tasks that contend for the same resource.In the current example the task A requires a pre-emptable resource and hence hasthe location pre-empted. The invariant x‘ == 0 of this location pauses the clockvariable “x” since task A is not being executed when in this location.

All the resources considered in the generic model providing (p+q) service types (Figure4.4) are declared in the global declaration section along with their corresponding ca-pacity “C”. Also the parameters of the task are declared and initialized to value 0, theguard “is task enabled?” depends on the Boolean function “enabled()” and the variable“active task” which is initially set to false and is set to true when the system goes fromidle to active location, are declared in global declarations. The synchronization channel


“hurry” is also declared in the global declarations. Note that C here is from the resourceperspective and not from task-flow perspective.

//Global Declarations

//Channel

urgent broadcast chan hurry;

//Resources

Data_type Resource11 = C11;

Data_type Resource12 = C12;

...

Data_type Resource(p+q)v = C(p+q)v;

//Parameters

a1 = 0;

...

bm = 0;

bool enabled(){

if (required resources available)

return true;

else

return false;

}

bool active_task = false;

The guard “is priority satisfied?” and other functions “claim()”, “consume()”, “re-lease()”, “produce()” are declared in the local declarations (local to each template ortask). These can be seen in Figure 4.5. The guard “is priority satisfied?” is used tocheck if priority requirements of the task are satisfied, is true when any higher prioritytasks is not in active location. The functions “claim()” and “release()” represent thetask claiming the required amount of resource from the available amount when it startsexecution and releasing it after execution. Functions “produce()” and “consume()” areused to represent consumption and production of tokens, before the task starts firingand after respectively. These are declared in the local declarations, where “consume”is more of a representative function setting the ports to a default value. “produce()”sets the binding expression on the port to the value expression on the incoming edgedepending on the condition of the edge. These functions are listed below in a snapshotof local declarations for the generic model.

//Local declarations

clock x;

bool is_priority_satisfied(){

return (!active_t1) && ... (!active_t2)

// ( for each t1,t2 that belongs to the set of all higher priority tasks);

}

//For our generic model if B has higher priority than A then the statement


//would be "return(!active_B)"

void claim(){

Resource11 = Available_amount - LoadA1;

...

}

void release(){

Resource = Available_amount + LoadA1;

...

}

void consume(){

E1 = 0;

...

Ex = 0;

}

void produce(){

if (Ce1)

b1 = Ee1;

...

if (Cem)

bm = Eem;

...//All other edges, maybe to other tasks as well

if (Cez)

Ex = Eez;

}

int minDuration(){

return min(LoadA1) * P11;

}

int maxDuration(){

return max(LoadA1) * P11;

}

}

We then discuss the edges and their attributes:

• The edge from initialize to idle: can contain select and update statements, herethe ports are set with initial values.

– The initial values are bind to the binding expression of the ports, which canbe a single variable like “a1” or a binding expression like “Ex” as shown inFigure 4.5. Select is optional and is usually set when the model requiresselecting a random value from a given set. For example when the initial valueof a port is selected randomly from the range (1 to 4), select statements areused.


• The edge from idle to active: This edge can have all the 4 attributes namely, select,guard, synchronization and update, set. Select can be present depending on themodel behavior, hence we omit it and present the rest.

– The 3 guards are, “is priority satisfied?”, “is task enabled?” are explainedpreviously and “do ports have enough tokens?”. The last one checks if portshave sufficient tokens to fire/execute the task. The actual guard conditionthat can be seen in the task automaton, for the guard “do ports have enoughtokens?” is shown in the following example we check for port P1 and P2 insome task.

0 < numOfTokensP1 && 0 < numOfTokensP2;

//This guard depends on the variables numOfTokens (P1 and P2)\\

which has a count of number of tokens in ports P1 and P2 (respectively).

– Includes a urgent broadcast synchronization channel “hurry” that is used toforce the model to take this edge, whenever the edge is enabled. Note: Onlysend is used since the purpose of it is to force the model to take the edge andnot to propagate any message.

– The update part of the edge ensures the execution of the functions definedin the local template declarations of the task automaton namely “claim()”,“consume()”, “active task = True” and “x=0”. Here “x” is a local clockvariable defined for each task and can be seen in the local declarations. It isreset when the task moves from Idle to active. It is used to keep track of theexecution time of each task.

• The edge active to idle: This edge has a guard and some update statements.

– The guard is “x >= minDuration()” ensures that the task has executed toat least a minimum duration of execution.

– The functions in the update section are “release()” , “produce()”, “active task= False” and “progressCount++”.

• The edge from active to pre-empted : Contains a guard, a synchronization channeland an update statement.

– The guard checks if any higher priority task is active. In case a higher prioritytask is active the current task is shifted from the active to pre-empted location.

– The urgent broadcast synchronization channel “hurry”.

– The update statement updates the variable active taskName to indicate thatthe task is not active anymore.


• The edge from pre-empted to active: Similar to the edge from active to pre-empted.

– The guard checks if any higher priority task is active. In case no higherpriority task is active the current task is shifted from pre-empted to activelocation.

– The synchronization “hurry” on the edge ensures that it is taken wheneverpossible.

– The update statement updates the variable “active taskName” to indicatethat the task is active again.

The translation for a regular task such as task B without initial values and pre-emptableresource is shown in Figure 4.6. The edge in the task automaton is bidirectional thetask can go from idle to active and vice-versa. The attributes over the edges are similarto the previous translation. Finally the system declarations part calls in all the taskautomatons to be executed in parallel.

Figure 4.6: Normal DSEIR translation for task B

4.3 DSEIR Translation of Running Example

The existing Uppaal translation of the printing example described in Chapter 2 hasbeen implemented in the Octopus toolset. Our translation creates one automaton pertask in the form of a template in Uppaal syntax. The translation of scan task in thisexample model using our translation scheme is given in Figure 4.7, the task is renamedto task A. The translations for the rest of the tasks (task B and task C corresponding to

4.3. DSEIR Translation of Running Example 41

image processing task and print task respectively) are shown in Figure 4.8 and Figure4.9 respectively.

Figure 4.7: Automaton of scan task(task A)

Figure 4.8: Automaton of image processing task(task B)


Figure 4.9: Automaton of print task (task C)

Chapter 5

Extending DSEIR with Deadlines

The first goal of the thesis is to make schedulability analysis possible in Octopus. Giventhe description of the current translation as discussed in Chapter 4, we identify the ad-ditions that would help us build the schedulability analysis procedure on the existinginfrastructure. The necessary additions that we require to the existing DSEIR transla-tions are:

1. The DSEIR language already consists of tasks, loads and resources but lacks dead-line, an important feature required to perform schedulability analysis.

2. The current implementation considers only execution of tasks and pre-emption, wenow need to consider the newly added deadline feature.

Solving the first part is fairly simple and can be done by adding an attribute to thetask in the DSEIR language. We then incorporate this change in the DSEIR translationby creating corresponding translation rule for deadlines in the Uppaal syntax. Focusingon the second part, schedulability analysis can be realized by creating a mechanismin Uppaal that monitors each task using their relative deadline and moves to an errorstate if a deadline is missed. This allows for embedding schedulability analysis into areachability checking problem. The approach to be taken is divided into two steps:

• We need to initially create possible deadline detection mechanisms in Uppaal. Thisstep involves creating some models, validating and verifying them.

• The next step is to modify the existing DSEIR translation to incorporate thisdeadline detection mechanism.

The extension of the current translation, to realize the second part along with the de-signs discussed in detail in Section 5.1. These changes are then also incorporated intothe DSEIR translation by making the necessary changes to the existing one. The new

44 Chapter 5. Extending DSEIR with Deadlines

translation then considers deadline as one of the attributes of the tasks and adds thedeadline detection mechanism. The changes that will occur in the work-flow throughthe modifications made in this section are reflected in the work-flow diagram depictedin Figure 5.1. The changes are, namely, the addition of the deadline feature and thedeadline detection mechanism to the translation procedure and the simultaneous cre-ation of a deadline query depending on the model and use it in the verification process.The running example is used to explain the working procedure with respect to the newtranslation, as well as verification process in Section 5.2. In this chapter, we describethe general framework that would be applied to any DSEIR model performing schedu-lability analysis. We then compare this framework with another schedulability analysisframework described in [13]. This is done by first describing the scheduling frameworkin DSEIR terms and applying schedulability analysis on it, is explained in Section 5.3.

Figure 5.1: Work-flow with the extended DSEIR translation

5.1. Extending Task Automatons 45

5.1 Extending Task Automatons

In this section, we explain the designs used for creation of a deadline detection mech-anism. Since we are using Uppaal we consider performing schedulability analysis, inthe form of reachability analysis. The idea of performing reachability analysis for sim-ilar analysis procedures can be found in detail in [13, 3]. We create an extra locationcalled stop/error which is reached when a task misses its deadline and still has someexecution time left. The schedulability property can then be verified using the formula“E<> Task.Stop”, which states that “There is a path in the system on which the systemeventually moves to the Stop location”. The expected result is “false” or “property notsatisfied”. In case the property is true, the model violates a deadline. In order to verifyschedulability by means of a safety property, we specify the query as “A[] not Task.Stop”,which states “Across all the path the system never goes to the stop location”.

Firstly we thought of using the clock comparison with relative deadlines by creating aclock that starts when the system starts in and by capturing the starting time and ob-taining the difference between the current time and the starting time, thereby detectingdeadline violations. But this was not feasible since Uppaal does not allow for capturingclock values during verification. Thus we then decided to use clock guards to capturethe deadline violation scenario.

Figure 5.2: Uppaal model with deadline detection mechanism - First approach

In the first model (Figure 5.2) we added a new location stop and an edge to this locationfrom each of the 3 other locations idle, active and pre-empted. A guard is placed onthese edges, which is used to ensure that the task has exceeded its deadline and thuscan reach the stop location then. This model uses an additional clock (“y” because themodel already has a clock variable “x”) which keeps track of the lifetime of a task (time


to deadline). In this model, once a task is initialized, a new clock variable “y” startsticking which is used to check deadline violations; it is reset every time the task goesfrom active to idle because this is when the task becomes “ready”.

Figure 5.3: a) The Idle to Active location in the initial approach, b) The addition of Readylocation in between

In DSEIR, the concept of “phase” in its scheduling theory sense is not present, however,a task is said to be “ready” only when its ports have enough tokens. The clock for thedeadline detection, has to start ticking when the task becomes ready. But in the modelof Figure 5.2 the task is not “ready” when it is in the idle location. As we can see inFigure 5.3 a), we check that “Do Ports have enough tokens?” and directly go to activealong with checking other conditions required to be “active”. In practice, it is not alwaysthe case that a task can go from idle to active directly, but it might sometimes remainin the ready state until the resources are available and the priority is satisfied. Thus weidentified that the model in Figure 5.2 does not faithfully represent the “ready” state ofa task. Hence we first add a new location to the model, called ready. We then divide theguards on the pervious “idle to active” edge over two edges, namely the “idle to ready”and “ready to active”. We present this second approach in Figure 5.3 b) and Figure5.4. Although we have added this ready location, we still preserve the previous model(without ready and Stop) for analysis procedures that do not involve deadlines in thembecause it is consistent and properly represents the models that do not have deadlines.Thus we have 2 options of implementation for DSEIR translation to Uppaal dependingon whether the deadline should be considered or not.

5.2 Application of the Extension on the Running Example

We now apply the new modified DSEIR translation to the running example. Here thetask A, task B, and task C are corresponding representations of scan, image processingand print tasks respectively. We explain only the new elements that are included in theUppaal model created using the modified DSEIR translator. The rest of the elements

5.2. Application of the Extension on the Running Example 47

Figure 5.4: Uppaal model with deadline detection mechanism - Second approach

remain the same as discussed previously. As mentioned earlier two new locations areadded to the automaton and named as the stoplocation and the ready location. Theadditional clock variable used here is “y”. The attribute for defining the deadline isalso used in the model deadline A(), which is a function that returns an integer valueon evaluation. Also the variable progressCount is eliminated from the translated model,which causes unnecessary state-space explosion. The state-space explosion is causedbecause it was initially designed to keep track of the number of task executions in themodel, but when we create infinite models through abstraction (with elimination ofconditions explained in Chapter 6), this is one number that keeps on increasing due towhich the verification never obtains any result.

The templates of the task automata of task A and task B from the example are shownin Figure 5.5 and Figure 5.6. The running of the model remains almost same as previousexcept of the deadline detection mechanism and with respect to the newly insertedlocation ready. The changes occurring due to the insertion of the location has beendescribed previously. We proceed further with the description of the deadline detectionmechanism. The clock variable “y” is started when the task becomes ready and goeson until it is reset again through the edge from “idle to Ready”. Also note that theclock value keeps on progressing when the system is in idle location but has no effectwhatsoever on the model, since it is reset when going from “idle to ready. Deadlineviolations can be found by comparing this variable with the current relative deadline.


Figure 5.5: Template of the modified automaton of task A

Hence, when the deadline violation takes place in any of the locations namely, ready,active or pre-empted, the corresponding edge leading to the stop state is taken. Thetranslation for task C is similar to task B, model changes in variable names.

Verifying the Deadline Violation

We define the models in Uppaal in the form a of a reachability problem, hence we usethe following formula, to check whether the Error state (stop location) is reached or not.

E<> (A.Stop or B.Stop or C.Stop)

Checks for the property that if any instance of task A, or task B or task C violates thedeadline in any state. The expected result for a proper model here is that the propertyis not satisfied; we obtain this result for the current example and is shown in Figure 5.7.Note that the schedulability analysis implemented is an entirely automated process wheregiven the DSEIR model, the Octopus engine will transparently perform translations, call

5.3. Application of Extension 49

Figure 5.6: Template of modified automaton of Task B

Uppaal, verify, fetch the results and displays then. Figure 5.7 is manually checked anddepicted here for understanding purpose.

5.3 Application of Extension

Alexandre et al. explained in [13] the procedure to create a scheduling framework in Up-paal to define a range of classical schedulability problems. We now model this schedulingframework using the DSEIR language. We use this example to compare between themanually created model in Uppaal following the approach in [13] and the automaticallygenerated version by the Octopus toolset.

[13] also includes an example model that consists of 5 tasks, and is explained in detailin this section. The task dependency graph of this task-set is shown in Figure 5.8. Thistask-set is a general real time task-set with certain attributes set accordingly. Thesetasks are defined using the following attributes.

1.Best case execution time(BCET) 5.Best case execution time(BCET)2.Worst case execution time(WCET) 6.Maximum period3.Deadline 7.Priority4.Offset 8.Initial Offset


Figure 5.7: Model checking results for the running example, displayed in Uppaal verifier

Figure 5.8: Task-flow graph of the scheduling framework example in general scheduling terms

5.3.1 Application

Given the syntax definition of the DSEIR language, this scheduling framework is modeledin the DSEIR language with the help of tasks, ports and tokens. This example requires


periodicity in its model since the tasks are periodic in nature, but DSEIR has no conceptof periods. Although this could be modeled via self loop on each task with (period -execution time) as the delay on its edge, we model it differently owing to the restrictionthat delay is not supported, specified in Section 4.1.4. An extra task can be used alongwith the pre-existing tasks which is used to model period. This special task is the Inittask which produces 6 tokens, one for each task including itself. We use a single taskfor this purpose, since all tasks have equal periods. This token is used to indicate thestart of a new period. Figure 5.9 shows the model. The various dependencies betweenthe tasks are modeled via the token and port system so as to make the dependent taskswait for their predecessors. The basic requirement for the tasks to begin execution is tohave at least one token on each of its ports.

The idea of modeling an extra task for imitating periodicity can be applied genericallyto other models as well. Although for models with different periods for different tasks,an extra task can represent the period for each task, the representation of this periodthrough the delay can be more useful. This concept has to be further investigated sincedelay is not directly applicable when variable load/execution times are involved.

Figure 5.9: Task-flow perspective of the scheduling framework example

5.3.2 Platform

This task-set uses 3 resources providing service type COMPUTATION and one resourceproviding the service type TRANSFER. The service type COMPUTATION is used by


Figure 5.10: Load perspective of the scheduling framework example

the Init task and other tasks A, B, C and D. E uses the service type TRANSFERprovided by the resource bus. The resources used and the scheduling of those resourcescan be seen in Figure 5.11 and Figure 5.12, respectively.

Figure 5.11: Resource perspective of the scheduling framework example

5.3.3 Mapping

The task-set uses 4 schedulers. The mapping perspective diagram is shown in Figure5.13.

We then successfully translate this DSEIR model to Uppaal model and check for schedu-lability using the schedulability query.

E<> (A.Stop or B.Stop or C.Stop or D.Stop or E.Stop)

OR

A[] not (A.Stop or B.Stop or C.Stop or D.Stop or E.Stop)


Figure 5.12: Scheduling perspective of the scheduling framework example

.

Figure 5.13: Mapping perspective of the scheduling framework example

5.3.4 Statistics

The modeling framework given by Alexandre et al. is a manually built model in Uppaal.In Octopus we manually build the corresponding model using DSEIR and then it istranslated to Uppaal syntax using automatic methods. We obtain the statistics byrunning some tests on both of these models. We consider 3 test cases with 5, 10 and12 tasks on both models. For the initial test case of 5 tasks, we model it from [13]example. For test case with 10 and 12 tasks, we replicate some of its tasks keeping thenumber of resources the same and increasing the period value correspondingly. Lookingat the results (Table 5.1) we infer that although for small number of task instancesthe automatic model is slower than the manual model. For larger model (large number


of instances) the automatically generated model has a much smaller state-space, lowertiming and memory requirements, though the reason for this huge difference is notentirely known. Also DSEIR is far more expressive than the manual model since itallows for handover, variable instances for each tasks via condition on edges and passingactual data between tasks. Although we can conclude that the DSEIR based automaticmodels can be successfully used as modeling framework for schedulability analysis, anddo not suffer from performance degradation due to the automation process, it is stillan open research area to be investigated. In Table 5.1, a cell for specifying memoryrequirement of the manual model with 12 tasks is left blank since the value could notbe obtained.

Table 5.1: Performance Comparison

Feature No of tasks Manual Automatic Model

States 5 983 56

Time 5 0.08s 0.7s

Memory 5 10MB 50MB

States 10 282996 190

Time 10 116s 2s

Memory 10 364MB 95MB

States 12 3224144 224

Time 12 44mins 2.6s

Memory 12 - 201MB

Chapter 6

Data Abstraction

In Chapter 5, the first goal of the thesis was achieved, i.e., schedulability analysis ismade possible for DSEIR models. This analysis process includes automatic translationto Uppaal and mechanized verification of this translated model. Although schedulabilityanalysis is now possible its scalability to larger models remains an issue. Applying DSEIRtranslation and performing model checking on such models results in the state-spaceexplosion problem. Thus the next part of the thesis is to make schedulability analysisscalable on arbitrary DSEIR models, with focus on the reduction of the state space.

In a DSEIR model, a task can have numerous instances but these instances share partof their behavior. Thus if we are able to identify data parameters of these instancesthat can be unified and unify them, we obtain abstract models that approximate thebehavior of a class of instances. To perform the abstraction, we need to:

• Identify the data parameters that can be abstracted.

• Perform data abstraction on these data parameters.

• Transform the original model to a new abstract model using the obtained abstrac-tions.

Although the behavior of the abstract model approximates the behavior of the concreteinstances, it can also comprise new behavior that is not present in any concrete instance.This is the price paid for obtaining reduced state-space. The abstraction procedurechanges the previous work-flow (Figure 4.1) for schedulability analysis in Octopus. Thenew work-flow diagram is shown in Figure 6.1. On an abstract note, the change is thatafter a DSEIR model is created, the next step now is to create an abstract model usingthe new abstractor function in DSEIR. After an abstract model is created, the work-flow uses the same old flow of actions, omitted in Figure 6.1 for the sake of brevity. The

56 Chapter 6. Data Abstraction

Figure 6.1: New work-flow diagram with abstraction procedure incorporated

work-flow will be further explained in detail in Section ??

In this chapter we first describe the motivation to perform abstraction in detail, with anexample in Section 6.1. Also in this section we present the design approaches that canbe used to extract the data from the user model and to create an abstraction from it.The abstraction algorithm is described in Section 6.2. The necessary helper functionsrequired by the algorithm are explained in Section 6.4. An example is used to illustratethe working of the abstraction algorithm in Section 6.5.

6.1 Motivation and Approach

State-Space Explosion: Models used in Octopus can contain tasks with a large numberof instances resulting in numerous combinations of elements/attributes and hence ahuge state-space. The state-space grows exponentially with the increase in number ofattributes of an arbitrary model. Thus the model checking procedure becomes timeconsuming and the verification tool may reach its resource limits, abruptly stopping theprocedure and giving no results.

Consider an example task model with 3 tasks A, B and C, whose possible task execution

6.1. Motivation and Approach 57

Figure 6.2: a) State-space explosion b) State-space of abstracted model

flows are A− >B− >C or A− >C− >B. Assume all of these tasks have “n” instances.In such a case the state-space of the model created using the current DSEIR translationwill be as the one shown in Figure 6.2 a), the right hand side shows the state-space of theabstracted model. Along the execution sequence each task might have a lot of repetitionsin terms of its task instances. Assume that A1 and A3 might be same in terms of thevalue all its attributes; they are still considered as different instances in the state spaceand represented twice. There can also be a scenario where after 2 instances of each task,this one execution pattern (Ax = A(x + 2) = A(x + 4) · · · where x = 1 · · ·n − 2 samefor B and C) is repeated “(n/2)-1” times (-1 for first execution) when the total taskinstances are “n” for each task. Note that both A(x+2) and Ax represent instances, thebrackets are to show that 2 is added on to value of x. Although repeating the executionsequence has no effect whatsoever on the model-checking results because the behaviordoes not vary when the instances and the execution sequence is same, it is still verifiedfor all instances since they have different attribute values. For example, A1 and A10 areequal in terms of their execution time and other important factors but have differentinstance number which is sufficient to differentiate them in state-space. Thus ideally weneed to check only one execution sequence of the cycle to verify the properties. Theeffect of this abstraction procedure on the load is shown in Figure 6.3. We eliminatethe instances by capturing the load of all instances and replacing with an instance thatrepresents all possible loads with a range of load specified by its minimum and maximum([minA,maxA]). Note: In DSEIR each instance could have a range specified as its loadvalue. The bounds of this range are calculated using the following set of formula:

minAi = minimum(minMaxExpEvaluator(LoadAi)), i = 1 · · ·n

maxAi = maximum(minMaxExpEvaluator(LoadAi)), i = 1 · · ·n

minA = lower bound(minA1(LoadA1)...minAn(LoadAn))

maxA = upper bound(maxA1(LoadA1)...maxAn(LoadAn))

//lower_bound and upper_bound is used because


their input is a range with two bounds.

The function MinMaxExpEvaluator used here is explained later.

Given an input expression it gives the minimum and

maximum possible values for that expression.

Figure 6.3: The effect of abstraction on load values

Also in a case where the task instances repeat but not the same execution sequence westill have considerable reduction in state-space by eliminating these instances. To createan abstract model we need to know all possible values, for all the attributes through allthe instances of the task. Thus we require an approach to capture all possible valuesand record them into a new model that approximates the original model.

Approach

The data that can be abstracted in the DSEIR model is the parameter values of thattask. Currently it can take a range of values considering all the possible instances of atask. The procedure of abstraction has two steps as shown in Figure 6.1. The steps arelisted below:

• We perform parameter (data) abstraction by mapping parameter values into arange of values, by finding the minimum and maximum value that the tasks cantake during the execution of the input model. We create a map in which eachparameter is mapped onto its respective range specified by minimum and maximumvalues. The effect of parameter abstraction on the parameters is shown in Table6.1. We discuss the parameter abstraction in detail in Section 6.2. Note: here {}represents a set and [] represents range.

Table 6.1: Effect on parameter values

Parameter Previous Values New Valuea1 {a11...a1m} [min({a11...a1m}),max({a11...a1m})]. . .

. . .

an {an1...ank} [min({an1...ank}),max({an1...a1k})]

• In the next step we use this parameter map and certain functions to transformthe DSEIR model into an abstract model. This step is further subdivided into twoparts, listed below:

6.1. Motivation and Approach 59

– Abstracting the load and deadline expressions. The effect of parameter ab-stractions on the load value and deadline value is shown in Figure 6.4 andFigure 6.5, respectively. The priority value is also affected in the transforma-tion which is shown in the mapping perspective along with deadline value.The new priority values are constants and hence dynamic priority is not sup-ported like in original DSEIR.

Figure 6.4: a)Affect of abstraction on load value

Figure 6.5: Affect of abstraction on deadline value and priority

– Transformation of the model using the new values for load and deadline,value expressions over the edges are changed to a constant (1) since they areno longer required for calculations but are preserved to maintain the task-flowand the conditions on the edges are eliminated, this change can be seen inFigure 6.6.

This transformation step is further explained in detail in Section 6.3


These two steps, parameter (data) abstraction and model transformation can be seen inthe new work-flow in Figure 6.1. Also the change in the 3 parts of the DSEIR modelnamely, application, platform and mapping is explicitly specified.

Figure 6.6: Affect of abstraction on value expression and condition, on the edges

6.2 Parameter Abstraction

The parameter (data) abstraction from the DSEIR model can be done in different ways.We have identified two possible ways in which this can be done, namely, using simulationand syntax analysis. The basic function of both methods is to identify the range of valuesa particular parameter can take and to record it. In the following sections we discussthese possible solutions in detail along with their advantages and disadvantages.

6.2.1 Simulation

One of the solutions to create an abstract model is by simulation. In this approach,we run the DSEIR model and record all the data through this process. Using thisrecorded data the possible values for each and every parameter in the DSEIR modelcan be obtained. The data is recorded in a trace file. We then parse this trace file toget the range of parameter values. The range is used to create a parameter map. Thisparameter map is used in further abstraction procedure steps. Although this is an easyway to obtain the parameter values, it has the following disadvantages:

• Is time consuming when models become large.

6.2. Parameter Abstraction 61

• Considers only one execution sequence at a time, due to which it is not exhaustive.

Although we do-not directly use this method for the purpose of abstraction, we use itas a verification method to check the results obtained from the syntax analysis methodof data abstraction; this is explained in Chapter 8.

6.2.2 Syntax analysis

The other possible solution for parameter abstraction is syntax analysis. In this approachwe syntactically analyze the DSEIR model parsing the expressions and conditions acrossthe tasks, ports and edges to obtain, the range of values that the parameters in theinput DSEIR model can take. This approach is better than simulation since it is notas time consuming and it also exhaustively goes through the model until a fixpoint isreached for the parameter values. Although syntax analysis imposes some restrictions onthe DSEIR model in order to be feasible to apply the algorithm. These restrictions arebased on the restrictions on the DSEIR translation to Uppaal. The trade-off here is thatthis method is typically is pessimistic and conservative. The algorithm that performsabstraction through syntax analysis and the restrictions involved are explained in detailin the following section.

6.2.3 Algorithm

In this section we explain the parameter abstraction algorithm in detail. The inputmodel for the abstractor algorithm is the DSEIR model. The algorithm considers thetask-flow perspective, load perspective and mapping perspective. The output of thisalgorithm is a mapping of parameters to their respective range, which is specified by itsminimum and maximum values.

Input :

The input of the algorithm is a user defined model in DSEIR with restrictions. Therestrictions in the translation to Uppaal discussed in Section 4.1.4 are also consideredhere. The restrictions are listed below:

• The number of ports should be equal to the number of parameters, with each ofthose ports having their binding expression as one of those parameters. The taskcannot have extra ports as in the actual DSEIR construct.

• The local declarations, start and end-statements are not considered.

• There should be one task that has initial values set for all of its ports.


• The conditional operators are now limited to {<,>,≤,≥,=}.

• The maximum number of iterations should be known.

• Resource allocation does not depend on deadline values.

Prior to describing the algorithm, we introduce the generic DSEIR model used as inputhere, which is a subset of the actual DSEIR model. Note: That for one of the require-ments like there should be one task that has initial values for all of its ports, in caseof more tasks with initial values, the task with maximum outgoing edges and has atleast one self loop is chosen. The task-flow perspective of this model, with the imposedrestrictions is shown in Figure 6.7. The load and the mapping perspectives are shownin Figure 6.8. The description of the generic task model can be found in Chapter 4.The symbols and notations used here are derived from the previous description. Thechange caused due to the restriction affects only the task-flow perspective; the restriction“number of ports = number of parameters” allows “n” ports for A and “m” ports for B.

Figure 6.7: Generic input model(Task-flow perspective)

Figure 6.8: Load perspective of the generic input model


We use an algorithm to perform the data abstraction, where we obtain the range ofvalues for the parameters. The following algorithm performs this task:extractData(DSEIR Model DSEIR,Integer maxIterations)

1 Parameter 7→List<Integer> parameterMap2 Integer Current parameter min,Current parameter max3 Integer negativeInfinity← −9999994 Integer positiveInfinity← 9999995 Set<Task> setOfTasks← getTasks(dseir)6 Task task7 Parameter parameter8 for (Every task ∈ setOfTasks)9 do Set<Parameter> parameterSet← getParameters(task)

10 for (Every parameter ∈ parameterSet)11 do Port p← findPort(parameter)12 Set<Integer> initial values← initialValue(p)13 if (initial values 6= ∅ )14 then Current parameter min← min(initial values)15 Current parameter max← max(initial values)16 else17 Current parameter min← negativeInfinity18 Current parameter max← positiveInfinity19 end if20 parameter 7→ [Current parameter min,Current parameter max]21 end for22 end for23 //The parameterMap for the generic model can be seen in Table 6.224 Task initTask← findInitialTask(dseir)25 Parameter 7→List<Integer> parameterMap(previous), parameterMap(current)26 parameterMap(current)← parameterMap27 Integer i28 while ((parameterMap(previous) 6= parameterMap(current)) ∧ i < maxIterations)29 do List<Task> taskList30 taskList← addToList(taskList, initTask)31 parameterMap(previous)← parameterMap(current)32 parameterMap(current)←33 findMinMax(parameterMap(current), init task, taskList)34 i← i+ 135 end while36 Output parameterMap(current)

Note: We have also used several functions through this algorithm which are explainedbriefly but not defined, since it is not important. Those functions are listed below:


Table 6.2: The parameter table

Parameter Min-Max Value

a1 [a1min, a1max]

.. ..

an [anmin, anmax]

b1 [b1min, b1max]

.. ..

bm [bmmin, bmmax]

• getTasks: Input: DSEIR model, Output: All the tasks present in the model inthe form of a set.

• getParameter: Input: task, Output: All the parameters of the task.

• findPort: Input: parameter, Output: The port in which the parameter forms thebinding expression.

• initialValue: Input: port, Output: The initial values of the port in the form of aset.

• findInitialTask: Input:DSEIR model, Output: The initial task of the task-set,which is always first in the execution sequence.

• addToList: Input: List and the element to be added, Output: The input Listwith the added element.

The algorithm/pseudo-code extractData is the main algorithm that takes DSEIRmodel and maximum possible iterations as input and provides the data parameter values(range) as output. It has 2 integer constants negativeInfinity and positiveInfinity whichspecifies extreme values a parameter could attain. The next step is to check for eachparameter in each task for the existence of initial values on the port they reside (A1 toAn w.r.t the Figure 6.7). Then a mapping of parameter to their intimal minimum andmaximum values (constructing a range) is created. Its declaration is shown in line 1 ofthe algorithm where parameter maps to a list of integer (with 2 values). The parameterswhich reside on ports with initial values set have proper minimum and maximum values,the rest have negativeInfinity and positiveInfinity as minimum and maximum, respec-tively. This parameter map is shown in Table 6.2. Each parameter is mapped to itspossible range specified as a list with 2 values minimum and maximum. Then we startfrom initial task of the task-set and traverse through the entire task-flow perspective ofthe DSEIR model to obtain the minimum and maximum values. The while loop stopswhen 2 consecutive iterations end up having same parameter map (indicating that afixed point is reached) or when maxIterations is reached.


The notion of maxIterations is used to here to terminate the algorithm in cases whereit goes on infinitely. The algorithm can run infinitely in conditions where the model hasa loop in which the edges do not have any guard conditions. An example model thatcould run infinitely is shown in Figure 6.9. In this example the edge from task D to taskE and task E to D does not have any condition, hence the algorithm does not terminateon this loop, this is one case where maxIterations comes into play. Although, the valueof maxIterations needs to be an input for this algorithm, the method to determine thisis unknown yet and is predicted to be dependent on the model.

Figure 6.9: An example model where maxIterations is required to terminate

This algorithm calls another function findMinMax which performs the traversing pro-cedure through the application, is defined as:findMinMax(Parameter 7→ List<Integer> parameterMap,Task task,List<Task> taskList)

1 List<Task> processedTaskList;2 Parameter 7→List<Integer> backupMap3 if (hasOutGoingEdges(task))4 then return parameterMap5 end if6 Set<Edge> outGoingEdges← getEdgesFrom(task)7 Edge edge8 for (Every edge ∈ outGoingEdges)9 do backupMap← parameterMap

10 Task taskNew← destinationTask(task, edge)11 //Over the edge12 Condition Ce← conditionOf(edge)13 //“Ce” is the condition on the edge considered can be seen in Figure 6.7.14 List<Expression> expressionList← GuardEvaluator(Ce, parameterMap);


15 //Guard Evaluvator is a helper function and is further explained in 6.416 Parameter 7→ List<Integer> bufferParameterMap17 bufferParameterMap← solve(expressionList, parameterMap)18 //Solve is a helper function and is further explained in 6.419 expressionList← clear(expressionList)20 Expression Ee← valueExpression(edge)21 List<Expression> minMaxList22 minMaxList←MinMaxExpEvaluavator(Ee, bufferParameterMap)23 //MinMaxExpEvaluvator is a helper function here and is24 further explained in 6.425 expressionList← addList(expressionList,minMaxList)26 //At the port27 Port p← destinationPort(task, edge)28 Parameter Pa← parameterInPort(p)29 // Pa ∈ {a1 · · · an, b1 · · · bm}30 expressionList← addToList(expressionList,Pa)31 parameterMap← Solve(expressionList, parameterMap)32 if (processedTaskList has taskNew)33 then continue //skips the new edge34 else35 processedTaskList← addToList(processedTaskList, initTask)36 if (check(TGp, parameterMap))37 then parameterMap←38 findMinMax(parameterMap, taskNew, taskList);39 else40 parameterMap←41 findMinMax(backupMap, taskNew, taskList);42 end if43 end if44 end for

The simple function calls used in this algorithm/pseudo-code are listed below:

• clear: Input: List, Output: Given the input list clears the elements of the list andoutputs an empty list.

• addToList: Similar to the one explained previously for the first algorithm.

• getEdgesFrom: Input: task, Output: The outgoing edges of the task.

• destinationTask: Input: task and one of its edge’s, Output: The task at thedestination of the considered edge.


• conditionOf : Input: edge, Output: The condition (conditional expression) overthe edge.

• valueExpression: Input: edge, Output: The value expression over the edge.

• destinationPort: Input: task and one of its edge’s, Output: The port at thedestination of the edge.

• parameterInPort: Input: port, Output: The parameter present as the bindingexpression in the port.

The findMinMax algorithm traverses through the entire task-flow perspective start-ing from the initial task and covering all the tasks, edges to syntactically analyze theexpressions and conditions that lie on them. This is a recursive algorithm which callsitself until tasks with no outgoing edges are reached as the stopping criteria. Until thestopping criterion is reached, starting from the initial task each edge is traversed. Thistraversal includes checking the effect of the guard condition on the parameter (if any) inthe conditional (Guard) expression. This is done using the helper functions GuardE-valuator and Solve. A guard can restrict the value of a parameter range, for exampleif a = [4,5] and the guard condition is a < 5 then the temporary range is stored in thebufferParameterMap will be a = [4,4]. The bufferParameterMap is a temporary mapvariable which is used in only in calculations of a particular edge. This temporary mapwould be used in the calculation of the minimum and maximum of the value expression(Ee) over the edge.

The helper function MinMaxExpEvaluator is used for this purpose, resulting in theminimum and maximum value for the input expression. We perform the binding tothe parameter on the destination port of the considered edge; the range of the valueexpression (Ee) is used for this purpose. New values for the parameter are obtained viaSolve helper function. The task guard TGp (p ∈ {A,B} task-set) is checked using thenew parameterMap values via an extra function Check which if satisfied, the modifiedparameterMap will be used, otherwise the backupMap, backup parameter map is used.A processedTaskList is maintained which stores the tasks that are processed already toprevent repetitions of the procedure on the same task. After an edge is processed wego to the destination task of the edge on a recursive call, which is processed next. Theoutput of this step consisting of the algorithm is an updated parameter map shown inTable 6.2 with all parameters mapped to their minimum and maximum value that theycan take during the execution of the input model.


6.3 Model Transformation

Once we obtain the minimum and maximum values of the parameters in the first stepthrough the parameter abstraction, we then use these values in the next step of abstrac-tion to translate the DSEIR model into an abstract model. During this translation, weuse the obtained parameter map to find the range of load and deadline for each task,since the load and deadline values are dependent on their respective task parameters, thepriority values are also affected. The effect on priority is that the function MinMaxEx-pEvaluator is applied on to it and the maximum value of the range obtained is used asthe final priority value. They are specified as mathematical expressions, hence we needto find the minimum and maximum for the load and deadline expression. This can bedone using the helper function MinMaxExpEvaluator. The input for this function isthe load/deadline expression and the parameter map obtained in the first step, outputis a range specified using 2 values (minimum and maximum). The resulting values fromthe helper function are then specified as an unknown distribution in the abstract modelranging from the minimum to the maximum value. Note that, the min and max storedin this load expression inside the unknown Distribution are not always the min and maxof the load expression but depends on the parameters if any present in the expression.With this change in the load, deadline expressions and elimination of condition on edgesand equating value expression as constant integer 1 on all the edges, we obtain the ab-stract DSEIR model. The final mapping perspective can be seen in Figure 6.11. Thefinal task-flow perspective of the model is depicted in Figure 6.10.

Figure 6.10: Task-flow perspective of the output

6.4 Necessary Functions

The algorithm requires some helper functions for its execution. In this section we explainthese necessary helper functions in detail.

6.4. Necessary Functions 69

Figure 6.11: Mapping perspective of the output

Figure 6.12: Load perspective of the output

Equation Solver

The function solve referred to previously in the abstractor algorithm is an equationsolver. Given an equation and the parameter table it solves the equation, for one pa-rameter at a time until all parameters are solved. For example given an equation a+ 2 = 10, then it solves for “a” as “a = [10,10] - [2,2] = [8,8]”. This new obtainedrange is compared with the old range to obtain a new range. This is done using therangeCalculations function defined in 6.4.

Range Calculations

In the main algorithm we convert the data parameters to a range of values specifiedthrough the minimum and the maximum of the range. Through the algorithm execu-tion, the range of the parameters changes, i.e., it is replaced with a new range if found.This is called inside the solve function where the parameters are given values, then rangecalculations are done to obtain actual new values from possible values and old values (ofthe parameter). It is different for the different type of expressions (conditional expres-sions and normal mathematical expressions). The algorithm of the range calculationsfunction is shown.calculateRange(Old min,Old max,New min,New max)

1 Result min = Old min2 Result max = Old max


3 if (Normal Expression)4 then //Min part5 if (Old min == negativeInfinity)6 then7 Result min = New min89 else if (New min < Old min)

10 then11 Result min = New min12 end if13 end if14 // Max Part15 if (Old max == positiveInfinity)16 then17 Result max = New max1819 else if (New max > Old max)20 then21 Result max = New max22 end if23 end if2425 else if (Conditional Expression)26 then //When the ranges are disjoint27 if ((New min > Old max) ‖ (New max < Old min))28 then29 return [Result min and Result max]30 end if31 //Min Part32 if (New min == negativeInfinity)33 then34 Result min = Old min3536 else if New min > Old min37 then38 Result min = Old min39 end if40 end if41 //Max Part42 if (Old max == positiveInfinity)43 then44 Result max = New max45

6.4. Necessary Functions 71

46 else if New max > Old max47 then48 Result max = New max49 end if50 end if51 end if52 end if53 return [Result min and Result max];

An example of range calculations: old list [3,5] new list [2,5] - resulting list [2,5].

Guard Evaluator

This section explains how the guards are evaluated to solve for the parameters in theguard, in order to obtain the range to which the parameters are reduced by the guardconditions. This function takes a conditional expression (guard) and the parameter mapas input and produces a new temporary parameter map as output. For example, Guardevaluations are done as:

• (Mathematical Expression logicalOperator constant). E.g. (a + b) < Constant

• a = newConstant dualof(operator) y

– Here newConstant depends on the logical operator, E.g. for a+1 < 5 new-Constant will be a = 4 -1 or in a + 1 > 5 then a = 6 - 1.

– For the set that we consider {<,>,>=, <=,=}.

∗ <, newConstant = constant − 1;

∗ >, newConstant = constant + 1;

∗ >= ,<=, =, newConstant = constant

• Dualof(operator) are defined for mathematical operators +,- (dual-set),/,*(dual-set)

• Example: a + [5,6] < 10

– a = [9,9] - [5,6] ([9,9] is obtained via GuardEvaluator)

– a = [3,4] (done via MinMaxExprEvaluator) This is the new possible tempo-rary range of a. In the actual calculations this will be compared with theexisting range of A, consider it to be a = [2,6] the resulting range will be [2,4]


values above 4 clipped because of the guard condition.

Expression Evaluator

This helper function evaluates a given expression provided that the parameter ranges forthe parameters in the expression are provided, gives the minimum and maximum possiblevalues for a particular expression. It parses and solves both mathematical expressionsand logical expressions. For logical expressions it uses a special 3-valued logic with valuestrue, false and unknown. More information about this function is provided in [14]. Forexample, consider an expression (a + b) with a = [2,4] and b =[3,6] , The range of theexpression is [5,10].

6.5 Abstraction Example

In this section we show the application of the abstraction algorithm to an exampleDSEIR model. The task-flow perspective of this DSEIR model can be seen in Figure6.13. The load perspective of the DSEIR model can be seen in Figure 6.15. We perform

Figure 6.13: Task-flow perspective of the example problem

data abstraction on this model using the abstraction algorithm, to first extract the valueof the parameters. This is achieved in the following steps:

• The range of the parameters is calculated based on the initial values on the port

6.5. Abstraction Example 73

Figure 6.14: Mapping perspective of the example.

of the tasks. Note that initial value [4,6] on the port means two tokens and notrange as we will use the same notation for a range as well.

• A mapping of the parameter to their respective ranges is created and can be seenin the form of a table in Table 6.3.

Table 6.3: Initial parameter values

Parameter Min-Max Value

a [4,6]

b [negativeInfinity,positiveInfinity]

Ca [negativeInfinity,positiveInfinity]

Cb [negativeInfinity,positiveInfinity]

Da [negativeInfinity,positiveInfinity]

Db [1,1]

e [negativeInfinity,positiveInfinity]

• Task to edge mapping is created, to be used in the function

• getEdgesFrom in task.findMinMax.

• Initial task of the model is obtained using the funtion findInitialTask. The resultobtained is task A in this case.

• We iterate over the all the tasks until a fixed point is found for the parametervalues or the maximum number of iterations are passed.


Figure 6.15: Load perspective of the example.


Table 6.4: Task-edge map

Task Edges

A aToA, aToB, aToC, aToD

B bToC

C -

D dToE

E eToD

• The iteration includes calculating parameterMap(current) using findMinMax.Figure 6.16 shows the execution of the algorithm, for one iteration. There aretotal 7 edges in the model. The algorithm starts from A (initial task) and goesthrough these edges iteratively starting with the edge to B. For parameter “a” oftask A and “Db” of task D the ranges (using initial values) are set to [4, 6] and[1, 1] respectively as shown in Table 6.3. We use these values and the rest fromthe table in the findMinMax function. When guards are present on the edges,parameters present in the guard conditions obtain temporary values, which is usedin the value expression of that edge. We explicitly specify in the explanation whentemporary values are used.

Figure 6.16: One iteration of the parameter abstraction algorithm on the working example

We explain each of the steps in the iteration, below:

– 1) aToB: old b = [negativeInfinity,positiveInfinity]


b = temp ab + 1new b = [5,5]

– 2) bToC: old Ca = [negativeInfinity,positiveInfinity]Ca = [5,5] / 2new Ca =[2,2]

– 3) aToC: old Cb = [negativeInfinity,positiveInfinity]Cb = temp acnew Cb = [6,6]

– 4) aToD: old Da = [negativeInfinity,positiveInfinity]Da = [4,6] * 2new Da = [8,12]

– 5) dToE: old e = [negativeInfinity,positiveInfinity]e = [8,12] + [1,1] + [4,5]new e = [13,18]

– 6) eToD: old Db = [1,1]Db = temp e - 2new Db = [1,13]

– 7) aToA: old a = [4,6]a = temp aa + 2new a = [4,8]

After these 7 steps the cycle is repeated again with the new values becoming oldvalues to the next iteration, also temporary values are refreshed depending on thenew ranges. The process is continued until two iterations have same parametervalues.

• After the parameter map is obtained we apply the model transformation as ex-plained previously, to obtain new task-flow perspective with conditions on edgeseliminated and their value expressions set to constant 1. The output task-flowperspective diagram obtained through the model translation can be seen in Figure6.17.

• During the model translation, we also calculate the load of each task on each servicetype they require, using the parameter map obtained during data abstraction.The final load diagram of this example model is shown in Figure 6.18, in thisfigure every load value is displayed as an unknown distribution in the range. Themapping perspective is shown in Figure 6.19, with deadline values changed to therange specified via an unknown distribution similar to the load values. There isno effect on priority since it is a constant.


Figure 6.17: Task-flow perspective of the output model

Table 6.5: Performance Comparison

Feature Original model Abstract model

States 28,842 1057

Time 2.22s 0.25s

Memory 21MB 14MB

Results of Abstraction

In this section we discuss the performance gain in abstracting the original model. Wemanually performed some performance comparisons using the Uppaal tool, similar to theone in Chapter 5. The resulting abstract model shows reduction in state-space and betterperformance when compared to the original model. The result is backed by recordedstatistics that can be seen in table 6.5. The correctness of this parameter abstractionmethod is also verified and applied on the running example later in Chapter 8.


Figure 6.18: Load perspective of the output model

Figure 6.19: Mapping perspective of the output model

Chapter 7

Verification

The new model obtained from the abstraction process is an abstraction of the originalmodel. This new model is an over-approximation that can contain behavior not existingin the original system. This makes the current model checking scheme inapplicableto this scenario producing false negatives (“not-schedulable”) for schedulable systems,because of non-existing behavior. Thus we make an attempt to eliminate such falsenegatives, and consider only those results that could help in making the design decisionsfor the Octopus toolset.

In this chapter we discuss a revised scheme for model checking in Section 7.1. We applythis revised model checking scheme to the running example along with the abstractionprocedure to perform schedulability analysis on the running example and is explainedin Section 7.2.

7.1 Revised Model Checking Scheme

We investigate possible approaches to overcome this problem. In the proposed solu-tion we apply new model checking formulas to get more accurate results consideringthe over-approximation. These formulas are different from the ones used in Chapter 4.Given the current output model (abstract model), the load and deadline are specified asindependent unknown distributions of values in a given range. Considering all the com-binations of load and deadline values is tedious and time consuming. Hence we decidedto consider some specific cases here, which are enough to capture possible schedulabilityinformation, remaining cases which could result in false negatives are omitted. Thesecases are listed below;

• In the first case we check the model with respect to the combination of minimum

79

80 Chapter 7. Verification

Table 7.1: Model checking results

Case No [maxDuration(), minDuration()] Result

1 maxDeadline No Not-Schedulable

2 maxDeadline Yes Non-Conclusive

3 minDeadline Yes Schedulable

4 minDeadline No Non-Conclusive

possible deadline (minDeadline) and range of execution time. The formula usedfor this is: A[] (A.minDeadline) imply not(A.Stop).

• In the second case we check the model with respect to the combination of maximumpossible deadline and range of execution time. The formula used for this is: A[](A.maxDeadline) imply not(A.Stop).

Note: Although we mention the load and deadline combinations, we actually consider theexecution time in the verification process. As explained earlier, in DSEIR the executiontime is defined as the product of load and processing time of the service type it executeson. Since the processing time is a constant and load is the varying term, we here mentionload in our explanation.

We use the above 4 cases in combination of 2 parts, where one component is constantin both, thus obtaining 4 cases, to form an analysis of the system in terms of schedu-lability. The 4 different cases are shown in Table 7.1. In the table, maxDeadline andminDeadline refer to maximum and minimum possible deadline respectively and max-Duration() and minDuration() refer to maximum and minimum possible duration ofexecution respectively. We discuss these 4 cases resulting in 3 possibilities shown below:

• Schedulable: This result suggests that the system is schedulable for all possiblecombinations of load and deadline, since the range of execution satisfy the mini-mum deadline here (The minimum possibility for the all the instances of the task).This is an ideal case that rarely happens.

• Not schedulable: This result suggests that for the current setting the system is notschedulable. This case is resulted when one of the execution values in the rangedoes not meet the maximum deadline, which is the maximum the task can have forall its instances. This possibility could still result in false negatives which cannotbe prevented. This is the trade of we make to obtain reduced state-space. Thiscase can be further refined by considering only minDuration() or maxDuration()along with maxDeadline (2 queries) resulting in an answer “No” to declare thesystem as non-schedulable. This would not have any false negatives since boththese values are always part of the original system.

• Non-conclusive: This result suggests that the verification results for the system

7.1. Revised Model Checking Scheme 81

considered is non-conclusive, since we cannot confirm either that it is schedulableor not. If the results of these conditions were to be considered either false positivesor false negatives could be the result. Two cases result in this value and are listedbelow:

– When the range of execution is able to meet the maximum deadline. Giventhe consideration of maximum value for deadline in combination with mini-mum duration (is included in the range) we can neither conclude the systemis “schedulable” nor as “not schedulable” hence we describe it as a non-conclusive case.

– When the range of execution is not able to meet the minimum deadline. Thisis similar to the previous case in a different way since we cannot expect allthe execution duration values to have the minimum deadline as their deadlineand hence we can only say it is non-conclusive case.

We particularly focus on the result that system is non-conclusive, which is obtained intwo cases here because it is not a usual result. We do not consider model checkingthe cases which result in this possibility. Further in this section we describe this casejustifying the reason to omit it. We obtain this result because the approximation alsoconsiders values that do not include in the original model and hence schedulabilityanalysis can fail for those values not included in the actual system. Consider a systemwith three tasks A, B and C. The DSEIR model of such a system is shown in Figure 7.1.From this model we obtain an abstracted form. In Figure 7.2 we show only the load andmapping perspective of the abstract model, since we concentrate on the execution timeand deadline only. Execution time is the combination of load and processing time andsince processing time is a constant namely 1, it is entirely dependent on the load in thisexample.

When this model is translated into the Uppaal syntax and verified, we obtain a non-conclusive result for the case number 4 for schedulability check from the table 7.1. Thisalong with the option to generate the trace allows us to see where the system fails. Inthe original model, task A has two possible load values 2, 4 and the deadline rangesfrom 3 to 9. B and C have constant load values of 5 and 6 since their minimum andmaximum values are equal. Given the processing time as constant 1, the load values canbe considered as the execution time. Considering the application of case number 4 (or3) we consider minimum deadline of 3 for A and maximum duration of execution time4, which is originally impractical to consider and declare not schedulable considering theresults. Thus we omit these false negatives by declaring the system as non-conclusive.

With the new model checking scheme defined we verify the running example after ab-straction procedure is applied on it, explained in Section 7.2.


Figure 7.1: The perspective diagrams of the example model. 1) Task-flow perspective 2) Loadperspective 3) Mapping perspective 4) Resource perspective 5) Scheduling perspective

7.2. Abstraction and Verification of Running Example 83

Figure 7.2: The final load and mapping perspectives

7.2 Abstraction and Verification of Running Example

The resulting final task-flow perspective will be as shown in Figure 7.3. Resulting loadperspective will be as shown in Figure 7.4. Also the mapping perspective is depictedin 7.5. The figures are shown just to depict the effect of abstraction on the runningexample, with eliminated condition and value expressions over the edge, modified loadand deadline values. Further in this section we also apply the new model checkingschemes to verify the running example for schedulability property.

Figure 7.3: Task-flow perspective of the output model


Figure 7.4: Load perspective of the output model

Figure 7.5: Mapping perspective of the output model

7.2. Abstraction and Verification of Running Example 85

Figure 7.6: Model checking results for the running example

After the abstraction procedure applied on the running example, to complete the schedu-lability analysis on this model, we verify it using the new model checking scheme. Theresult obtained is as shown in Figure 7.6 shows that this system is schedulable since itsatisfies case number 3, here A corresponds to scan, B to image processing and C toprint.

Chapter 8

Abstraction Fitness

In the view of this project, this chapter explains a process to assist the users in measuringthe effectiveness of the proposed solutions. In this thesis we have proposed an algorithmto abstract the DSEIR model in order to reduce the state-space. We have performeddata abstraction on the DSEIR models to achieve this. Thus now we intend to provide amethod to measure the fitness of the results obtained through the abstraction algorithmwhich follows syntax analysis method for performing abstraction. The chapter is mainlyconcerned with the parameter abstraction part discussed in Section 6.2. The modeltransformation part is not treated, since it meagerly performs transformation of themodel based on range of the parameters obtained via data abstraction. The methodin which we measure the fitness/precision is discussed in Section 8.2, in abstract termswe perform a comparison of parameter values obtained using other known methodsversus the parameter abstraction method. Since we deal with parameter values, we canuse simulation to obtain the parameter values of the original model. We explain thissimulation based comparison technique in the following section.

8.1 Simulation Based Comparison

By simulating DSEIR models we can obtain the minimum and maximum values eachparameter can take in the model. This process is applied on the DSEIR models automat-ically via simulator in the Octopus toolset that simulates and provides us an executiontrace. This execution trace is parsed and the parameter values are obtained. The work-flow of this comparison task can be seen in Figure 8.1. A DSEIR model taken as inputfor two methods namely , parameter abstraction and simulation which result in a pa-rameter map. This parameter map is compared for abstraction fitness and further use ofparameter abstraction method on a considered model is dependent on the result of thismeasurement. This precision measure is a relative measure, measured using the results

86

8.1. Simulation Based Comparison 87

Figure 8.1: Work-flow showing the use of abstraction fitness

of simulation. We illustrate this by treating the running example.

The task-flow perspective, load perspective and the mapping perspective diagrams ofthe running example model can be seen in Section 2. We show the results from theapplication of data abstraction using both approaches, i.e., the simulation method andthe syntax analysis method.

8.1.1 Syntax Analysis

In this section, we show the results of the application of the abstraction procedure on therunning example discussed in Section 2.2. The parameter map obtained for the modelusing the syntax analysis method for abstraction is shown in the Table 8.1.

Table 8.1: Parameter Map obtained for the Running example via syntax analysis.

Task Parameter Min-Max Value

Scan pageSize[0] [3,5]


Image Processing pageSize[0] [3,5]


Print pageSize [3,5]

88 Chapter 8. Abstraction Fitness

Table 8.2: Parameter Map obtained for the Running example via simulation

Task Parameter Min-Max Value





Print pageSize [3,5]

8.2 Results

We validate the performed data abstraction by comparing the parameter values obtainedin syntax analysis method with the parameter values obtained from simulation as shownin the simulation work-flow in Figure 8.1. The obtained values can be seen in Table 8.2.The goal of this method is to provide a measure of fitness of the parameter abstractionmethod to the user. By construction of the algorithm, we know that the abstraction isconservative for the data parameter values. Thus being conservative we have:

• PO set of parameters in the original model and PA set of parameters in the ab-stracted model

• ∀p ∈ PO we have corresponding pa ∈ PA

• Also if p = {minO . . .maxO} and pa = {minA . . .maxA} then

minA ≤ minO & maxA ≥ maxO.

Thus p ⊆ pa

We can evidently see that here the parameter abstraction procedure is conservative forthe running example, from the data presented in Table 8.1 and Table 8.2. The methodapplied for abstraction performs over-approximation, we can have parameter values thatare not in the set of original parameter values, hence being conservative is not alwaysuseful to the user. In cases where the results are conservative but the difference betweenthe actual data and obtained data is large, the fitness is reduced like the example depictedin Figure 8.2, alternatively a useful case can be seen in Figure 8.3. Figure 8.4 shows theactual data range and the data range obtained from the abstraction procedure.

The variables diff min specifies the difference between the minimum(lower bound) ofthese two ranges and diff max specifies the difference between the maximum(upper bound)of the two ranges. The idea is to keep this difference minimum. The fitness(F) of theparameter abstraction method can be measured either using these variables or using thelength of abstracted data and actual data. This measures the precision in which the

8.2. Results 89

Figure 8.2: The ranges obtained with large difference

Figure 8.3: The ranges obtained with small difference

Figure 8.4: The ranges obtained using the different methods, the actual data range - simulationmethod and abstracted data range - parameter abstraction method, with differences depicted

parameter abstraction method reproduces the original values. We display fitness value(F) for a single parameter range mathematically as:

abstracted length = upper bound(abstracted data range)−lower bound(abstracted data range)

actual length = upper bound(actual data range)− lower bound(actual data range)

Assuming that no other factors affect the fitness, we can say:

F =actual length

abstracted length

90 Chapter 8. Abstraction Fitness

We then define total fitness(FT ) of a task model with “n” parameters, as:

FT =

∑ni=1 Fi

n

Table 8.3: Fitness values of the parameter

Task Parameter abstracted length actual length Fitness

Scan pageSize[0] 3 3 1

Scan pageSize[1] 3 2 0.67

Image Processing pageSize[0] 3 3 1

Image Processing pageSize[1] 3 3 1

Print pageSize 3 3 1

For the current example we write this difference and measure the total fitness. First wetabulate the fitness of each parameter in Table 8.3. Looking at the table for the examplewith 5 tasks (n=5) we have;

FT =4.67

5= 0.934

We can also specify it in terms of accuracy as 93.4% accurate. Note that, for a parametertype of array, each array element is considered a separate parameter for calculation. Weconclude that higher the value of the total fitness, more effective is the abstractionprocedure on the considered model, for ideal case where the abstracted range and actualrange are equal we obtain result as 1. Since the parameter abstraction is conservative,abstracted range can never be smaller than the actual range hence we can say that eachFi ∈ [0, 1], for i = 1 · · ·n and “n” being the number of parameters, hence also FT ∈ [0, 1]for any considered model.

Chapter 9

Conclusions

The primary goal of this thesis was to incorporate schedulability analysis to the Octo-pus toolset. During the design phase we found that the DSEIR models are tuned tobe simulation models and hence are less applicable for exhaustive analysis approachessince it causes extensive delay or crashing of the analysis tool. Hence we planned toachieve this goal into two phases, namely to make schedulability analysis possible in theOctopus toolset, and then to make it scalable for arbitrary DSEIR models, applicable toexhaustive analysis approaches.

The approach in the first phase included making some design decisions to add deadlineas a modeling primitive to the DSEIR language, also making it usable by the scheduler.After adding this feature, we investigated the possibility of re-using the existing infras-tructure in the Octopus toolset to build schedulability analysis. We extend the existingDSEIR translation to Uppaal to incorporate deadline detection mechanism to supportschedulability analysis. Hence now schedulability analysis is possible in the Octopustoolset. We have also identified an obstacle for our method, in the existing translationto Uppaal syntax during this thesis, where a state “ready” was not precisely defined, andrectified this problem. Note that this is an obstacle to perform schedulability analysisand not a problem otherwise. We have then compared this schedulability frameworkbuilt in DSEIR against the schedulability analysis framework proposed by Alexandre etal. [13] for performance measures. Although for smaller set of tasks (5 tasks), therewas no phenomenal difference in the time, memory usage and state-space, for greatertask-sets (10 and 12 tasks) the automatic model (DSEIR to Uppaal converted mod-els) had better performance, proving that these models do not suffer from performancedegradation due to the automation process.

To make schedulability analysis scalable to DSEIR models with focus on the reductionof the state-space, we required to perform data abstraction on the model. We consideredtwo approaches, namely, simulation and syntax analysis to make this possible. Owing to

91

92 Chapter 9. Conclusions

the limitations of simulation approach we chose the syntax analysis method and designedan algorithm to perform abstraction using syntax analysis method. This algorithm per-forms data abstraction and model conversion on input DSEIR models, resulting in anabstract model with reduced state-space. The abstraction procedure commonly createsan over-approximation of the input model, along with specifying load and deadline val-ues as ranges. The model checking scheme gets affected, by this over-approximationproducing false negatives and by the need to check all combinations of load and deadlinevalues during verification. We solve this by successfully creating a revised model check-ing scheme, with an attempt to eliminate false negatives and reducing the state-spacerequired to be searched by checking appropriate combinations of load and deadline val-ues, enough to conclude with proper results. Yet some false negatives could be produced,which can be eliminated by considering the second refinement. Some queries that couldresult in non-conclusive or false negative results are omitted. This scalability feature isapplicable only on a restricted subset of DSEIR owing to the limitations of the parameterabstraction algorithm and the DSEIR translation to Uppaal.

By construction the parameter abstraction procedure is conservative, but being conserva-tive does not always imply usefulness/fitness. Thus we also provide a method to measurethe fitness of the parameter abstraction algorithm by comparing parameter values withthe one’s obtained by simulating the input model. We also define the total fitness of themodel, which is equal to 1 in an ideal case when the parameter ranges obtained usingparameter abstraction and simulation are equal, otherwise lies in the range [0,1].

Chapter 10

Future Scope

Through this project phase, considering the work done we also describe some recom-mendations to follow up on the current work:

• Scale the abstraction procedure: Currently the abstraction procedure can be ap-plied on models based on a subset of the DSEIR syntax. Scaling this to the entireDSEIR syntax would make abstraction procedure applicable to arbitrary DSEIRmodels.

• Improve the abstraction procedure: Currently the abstraction procedure some-times induces new values into the abstracted model, which is not present in theoriginal model. By improving the abstraction procedure to capture only the con-crete values we, could omit the Non conclusive case in the schedulability analysisresults giving proper results. This will also increase the fitness of the procedure.

• Periodic Tasks: A suitable method, similar to the extra task for representingperiodic tasks have to be investigated. The delay over the edges is also an optionto represent periodicity.

• Infinite models: The effect of abstraction procedure on the models that requiremaxIterations to terminate have to be investigated further in detail.

• Manual models v/s automatic models: To investigate reasons for the difference inthe expected results and the obtained results for this comparison is an area forfuture work.

• Probabilistic schedulability analysis: A computing systems always includes inter-rupts which is not part of a normal application and hence cannot be specified withthe system. These appear as sporadic tasks appearing in between the executionof normal tasks and are of usually higher priority than other tasks in the system.

93

There is a need to consider these in the schedulability analysis, but being exter-nal to the system they are not explicitly specified. A probabilistic analysis forschedulability can be done based on their expected interference with the regulartasks.

94

References

[1] T. Basten, E. Van Benthum, M. Geilen, M. Hendriks, F. Houben, G. Igna, F. Reck-ers, S. de Smet, L. Somers, E. Teeselink, N. Trcka, F. Vaandrager, J. Verriet,M. Voorhoeve, and Y. Yang, “Model-Driven Design-Space Exploration for Embed-ded Systems: The Octopus toolset,” in Leveraging Applications of Formal Methods,Verification, and Validation (T. Margaria and B. Steffen, eds.), vol. 6415 of LectureNotes in Computer Science, pp. 90–105, Springer Berlin / Heidelberg, 2010.

[2] A. Fredette and R. Cleaveland, “RTSL: A Language for Real-Time SchedulabilityAnalysis,” in Real-Time Systems Symposium, 1993., Proceedings., pp. 274 –283,IEEE, dec 1993.

[3] N. Guan, Z. Gu, M. Lv, Q. Deng, and G. Yu, “Schedulability Analysis of GlobalFixed-Priority or EDF Multiprocessor Scheduling with Symbolic Model-Checking,”in Proceedings of the 2008 11th IEEE Symposium on Object Oriented Real-TimeDistributed Computing, pp. 556–560, IEEE Computer Society, 2008.

[4] “www.uppaal.org.” Uppaal website.

[5] B. Kienhuis, E. Deprettere, P. van der Wolf, and K. Vissers, “A Methodology toDesign Programmable Embedded Systems,” in Embedded Processor Design Chal-lenges (E. Deprettere, J. Teich, and S. Vassiliadis, eds.), vol. 2268 of Lecture Notesin Computer Science, pp. 321–324, Springer Berlin / Heidelberg, 2002.

[6] N. Trcka and B. in ’t Groen, “DSEIR - The Modeling Language of Octopus.” Usermanual, 2011.

[7] J. Bengtsson, K. Larsen, F. Larsson, P. Pettersson, and W. Yi, “Uppaal - a ToolSuite for Automatic Verification of Real-Time Systems,” 1996.

[8] R. Alur and D. Dill, “Automata for modeling real-time systems,” in Automata, Lan-guages and Programming (M. Paterson, ed.), vol. 443 of Lecture Notes in ComputerScience, pp. 322–335, Springer Berlin / Heidelberg, 1990.

95

[9] G. Behrmann, A. David, and K. Larsen, “A Tutorial on Uppaal,” in Formal Methodsfor the Design of Real-Time Systems (M. Bernardo and F. Corradini, eds.), vol. 3185of Lecture Notes in Computer Science, pp. 33–35, Springer Berlin / Heidelberg,2004.

[10] “http://www.comp.nus.edu.sg/ cs5270/notes/chapt6a.pdf.” Coffee machine exam-ple.

[11] R. Alur, C. Courcoubetis, and D. Dill, “Model-checking for real-time systems,”in Logic in Computer Science, 1990. LICS ’90, Proceedings., Fifth Annual IEEESymposium one, pp. 414 –425, IEEE, 1990.

[12] J. Madsen, M. R. Hansen, and A. W. Brekling, Model-Based Design for EmbeddedSystems, ch. Modeling and Analysis Framework for Embedded Systems, pp. 121–141. CRC Press, 2010.

[13] A. David, J. Illum, K. G. Larsen, and A. Skou, Model-Based Design for EmbeddedSystems, ch. Model-Based Framework for Schedulability Analysis Using UPPAAL4.1, pp. 93–119. CRC Press, 2010.

[14] A. Moily, “Model Transformations for Throughput Analysis using SynchronousData Flow Graphs in Octopus,” Master’s thesis, Technical University of Eindhoven,August 2011.

96

adding schedulability analysis to the octopus...

Documents