BATIC3S Project : Document collection 2005-2006

(1)

Report

Reference

BATIC3S Project : Document collection 2005-2006

MALANDAIN, Stéphane, et al.

Abstract

A collection of research reports, technical reports and articles for the first year of the BATIC3S project (a collaboration between the Université de Genève, the Ecole d'Ingénieurs de Genève, the Haute Ecole Valaisanne, and the Universidade Nova de Lisboa).

MALANDAIN, Stéphane, et al . BATIC3S Project : Document collection 2005-2006 . 2006, 142 p.

Available at:

http://archive-ouverte.unige.ch/unige:26578

Disclaimer: layout of this document may differ from the published version.

1 / 1

(2)

BATIC S Project

Document collection 2005-2006

3

The BATIC3S project collaboration:

HAUTE ECOLE VALAISANNE Ecole d'ingénieurs de Genève

European organization for Nuclear Research

Universidade Nova de Lisboa

Funded by the Hasler Foundation

(3)

List of Figures

1.1 Hierarchical tree of the system . . . 2

1.2 The door FSM . . . 4

1.3 The container FSM . . . 5

1.4 The thermostate FSM (for trays and water . . . 6

1.5 The exit FSM . . . 7

1.6 The water supply FSM . . . 8

1.7 The coffee, milk, tea and sugar FSM . . . 9

1.8 The cup supply FSM . . . 10

1.9 The arm FSM . . . 11

1.10 The money box FSM . . . 12

1.11 The FSM tree of the DVM. Boxed nodes (leaves) are Device Units; the others are Control Units. . . 14

1.12 The DVM CU FSM . . . 15

1.13 The Cold CU FSM . . . 16

1.14 The Hot CU FSM . . . 17

1.15 The Fdg CU FSM . . . 18

1.16 The Nat CU FSM . . . 19

1.17 The Water CU FSM . . . 20

1.18 The Cups CU FSM . . . 21

1.19 The FdgTr and NatTr CU FSM . . . 22

1.20 Use Case diagram . . . 27

1.21 Use Cases in a set diagram . . . 28

1.22 Use Cases in another set diagram . . . 29

2.1 An example of hierarchical control system: drink vending machine . . . 32

2.2 The general schema of the methodology . . . 33

2.3 The structure of the model . . . 38

2.4 Part of the System model and hierarchical communication . . . 39

2.5 The GUI Logical Model . . . 40

2.6 The GUI Visual Model . . . 41

3.1 Drink Vending Machine Class Diagram . . . 46

3.2 Drink Vending Machine State Chart . . . 47

3.3 Structure of the CO-OPN model . . . 48

3.4 One behaviour for giveDrinkBeer . . . 48

3.5 Schematic view of the transformation process from UML2 to CO-OPN . . . 50

3.6 Example of State Machines with Pseudo States . . . 51 v

(8)

vi LIST OF FIGURES

3.7 Test Intentions Coverage Algorithm . . . 54

5.1 Graphical decision tree. . . 108

5.2 Activity Chaining Graph for a specific task. . . 109

5.3 The mapping problem in interface models. . . 110

5.4 The “means/goals” abstraction hierarchy. . . 114

5.5 MOI architecture. . . 115

5.6 Rasmussen interaction model. . . 116

5.7 DWARF architecture. . . 118

5.8 Modeling of the control board. . . 121

5.9 Visualization of the control room of a Japanese nuclear plant. . . 122

5.10 The control board of a Volkswagen Touran car rendered in VRML. . . 122

6.1 Basic properties of the system . . . 127

6.2 Structure of an.obj file . . . 128

6.3 Example of OpenGL rendering in a Java application . . . 130

6.4 Some instance variables of anObject3DStructure . . . 131

6.5 Relations between an object, his structure and the drawer. . . 132

6.6 Positionnement de la camra . . . 133

6.7 Initial relational model of the database . . . 134

6.8 Relative position between two objects . . . 137

6.9 Stereoscopic visualisation . . . 137

6.10 Planar view of each eye and brain interpretation . . . 138

6.11 Stereoscopic visualisation system used for the BATIC³S project . . . 138

(9)

List of Tables

1.1 DVM state changes . . . 15

1.2 Cold state changes . . . 16

1.3 Hot state changes . . . 18

1.4 Fridge state changes (Fdg) . . . 19

1.5 Natural state changes . . . 19

1.6 Water state changes . . . 20

1.7 Cups state changes . . . 21

1.8 Tray state changes (FdgTr and NatTr) . . . 22

5.1 Comparison of the projects on the GUI Modeling. . . 123

5.2 Comparison of the projects on the Automation, Simulation and Verification Features.123 5.3 Comparison of the most common operational features on the studied projects. . 124

vii

(10)

viii LIST OF TABLES

(11)

Introduction

This volume collects the documents produced in the context of the BATIC³S project during the first year (10/2005 - 10/2006). These include technical reports, papers and surveys, and give a panorama of the first year’s activity.

The following people and institutions have contributed in various ways to the production of these documents:

• Ecole d’ingénieurs de Genève: Prof. Stéphane Malandain, Pierrick Zoss

• Université de Genève: Prof. Didier Buchs, Prof. Gilles Falquet, Matteo Risoldi, Kaveh Bazargan, Lu´ıs Pedro, Levi Lúcio, El Mustafa El Atifi

• Haute Ecole Valaisanne: Prof. Anne Le Calv´e

• Nova Universidade de Lisboa: Prof. Vasco Amaral, Bruno Barroca

• CERN: Dr. Robert Gomez-Reino Garrido

ix

(12)

x INTRODUCTION

(13)

Chapter 1 A DVM specification as a control system sample

V. Amaral, M. Risoldi, B. Barroca - 2006

1.1 Introduction

To build a first use case of the BATIC³S methodology and to establish what is missing in it, a simple control system has to be devised. This system has to present however a few complexity features, as a hierarchical structure and different use cases, so as to be simple without sacrificing generality.

This document specifies a Drink Vending machine system. It is a quite classical example in the domain of system models. However we tried to enrich it with a few complexities.

The machine can sell cold and hot beverages. The two subsystems are separated and independent.

The cold beverages, also, can be ”ambient temperature” ones or refrigerated ones. These two systems are independent as well.

The DVM is equipped with one money box, which is common to all systems.

In the following sections we will give more details on the hierarchy of the components, as well as on their states. Also user profiles and use cases will be discussed.

1.2 General structure

The hierarchical structure of the vending machine is represented in Figure 1.1.

The machine is composed of a hot drinks unit, a cold drinks unit, and the money box.

1.2.1 The cold drinks unit

The unit can sell refrigerated (’Fridge’) or non-refrigerated (’Natural’) drinks. This divides this unit into two subunits, which have the same structure (they will differ only in the different contained drinks and in the different temperatures thresholds).

This structure encompasses one or more Trays (each to a beverage), and one Thermostate. In turn, the tray is composed by one Container (that holds the beverages) and one Door (that lets one beverage at a time out of the Container). The container can sense a low number of beverages, as well as it can detect jams. The door also can detect jams of itself.

The cold unit also has an Exit tray, which is the ”hole” where the beverage is delivered to the customer. This exit is protected by a door, and can sense the presence of a drink in it, as well as detecting a jam.

1

(14)

2 CHAPTER 1. A DVM SPECIFICATION AS A CONTROL SYSTEM SAMPLE

DVM Cold

Fridge Tray

Door Container Thermostate Natural

Tray Door Container Thermostate Exit

Hot

Water

Water supply Thermostate Coffee

Milk Tea Sugar

Cups

Cup supply Arm Money box

Figure 1.1: Hierarchical tree of the system

(15)

1.2. GENERAL STRUCTURE 3

1.2.2 The hot drinks unit

This is the typical unit which adds water to a quantity of one or more powdered substances, providing a cup and optionally sugar.

The water is taken from a supply the machine is linked to (a water pipe). This can sense the lack of water. There is a thermostate checking the temperature of the water as it comes out.

There are reserves of the following powders: Coffee, Milk, Tea and Sugar. Each of these can sense when the level is low or absent.

The cup dispenser has a supply of cups, which as well can sense the quantity of cups being scarce or absent. The dispenser has also an arm which puts the cup in position to be filled and then retrieved.

1.2.3 The money box

It is where the coins go when they are intaken. It can sense when it’s almost full or full.

(16)

1.3 State machines

Following are the Finite State Machines (FSMs) of the leaves of the tree. In the next section we will describe how these compose into state machines for upper levels.

By convention we will indicate, for each state, its relevance for diagnostic. Green states should be interpreted as ”ok” states; yellow are ”warning” states; and red are ”error” states. For black and white print, light gray is ok; dark grey is warning; very dark gray with white text is error.

1.3.1 Door

OK Jammed

Figure 1.2: The door FSM

The door, during normal operation, is ”OK”. If it gets jammed, it goes to an error ”Jammed” state.

From this state it can go back to ”OK”.

(17)

1.3. STATE MACHINES 5

1.3.2 Container

OK LowNumber Empty

Jammed

Figure 1.3: The container FSM

A container with more than 5 drinks is ”OK”. With 5 or less drinks, it goes to the ”LowNumber”

warning state. With no drinks, it goes to the ”Empty” error state. From here, it can be refilled and go to ”LowNumber” or ”OK” (depending on the number of drinks reinserted). From ”LowNumber” it can also be refill ed to ”OK”.

From any of the states, the container can become ”Jammed”. From ”Jammed” it can go to any of the other states when unjammed (depending on the number of drinks remaining).

(18)

1.3.3 Thermostate (all)

TempOK TempWarn TempError

Figure 1.4: The thermostate FSM (for trays and water

The thermostate will have two thresholds of temperature,T1 andT2, whereT1> T2, thus identifying three temperature ranges. For the cold drinks unit thermostates:

1. ifT^◦< T1 the state is ”TempOK”

2. ifT1≤T^◦≤T2, the state is ”TempWarn”

3. ifT^◦> T2, the state is ”TempError”

For the water thermostate, the logic is inverted:

1. ifT^◦< T1 the state is ”TempError”

2. ifT1≤T^◦≤T2, the state is ”TempWarn”

3. ifT^◦> T2, the state is ”TempOK”

Of courseT1 andT2 will have different values for the three thermostates.

(19)

1.3.4 Exit

Free Occupied Jammed

Figure 1.5: The exit FSM

An empty and working exit will be in the state ”Free”. When it gets occupied by a drink, it goes to ”Occupied”. When the drink is taken, it goes back to ”Free”. From both these states it can go to

”Jammed”. From ”Jammed” it can go back to any of the other states (depending on the presence of a drink in the exit).

(20)

1.3.5 Water supply

OK Lacking

Figure 1.6: The water supply FSM

The water supply has to sense whether water is coming from the pipe attached to the machine. It is

”OK” when water is present, ”Lacking” when no water is coming.

(21)

1.3.6 Coffee, milk, tea, sugar

OK Low Empty

Figure 1.7: The coffee, milk, tea and sugar FSM

For all the powders of the hot drinks, we have a state ”OK” when there is at least 20% of the powder in stock; a ”LowQuantity” warning state when there is less than 20%; and an ”Empty” error state when there is no more powder. From ”Emtpy” the powder can be refilled to the other two states (depending on the quantity). From ”LowQuantity” also a refill to ”OK” can be done.

(22)

1.3.7 Cup supply

OK LowNumber Empty

Jammed

Figure 1.8: The cup supply FSM

A supply with at least 20 cups is ”OK”. With less than 20 cups, it goes to the ”LowNumber”

warning state. With no cups, it goes to the ”Empty” error state. From here, it can be refilled and go to

”LowNumber” or ”OK” (depending on the number of cups reinserted). From ”LowNumber” it can also be refilled to ”OK”.

From any of the states, the supply can become ”Jammed”. From ”Jammed” it can go to any of the other states when unjammed (depending on the number of cups remaining).

(23)

1.3.8 Arm

Free Occupied Jammed

Figure 1.9: The arm FSM

The arm of the cup supply has the same state machine diagram of the cold drink exit. This is not surprising as it absolves the same task (albeit with a different mechanics).

An empty and operating arm is in the state ”Free”. When it holds a cup (during or after drink serving) it is in the ”Occupied” state. From both states it can jam and go to the ”Jammed” error state.

From this state it can recover and go to any of the other two states (depending on the presence of a cup).

(24)

1.3.9 Money box

OK AlmostFull Full

Figure 1.10: The money box FSM

The money box is in the ”OK” state when there is at least 20% free capacity. It goes to the

”AlmostFull” warning state when the capacity is below 20%, and it goes to the ”Full” error state when the capacity is full. From ”Full” it can be emptied partially or totally and go to ”AlmostFull” or ”OK”

(depending on the resulting capacity). From ”Almostfull” it can also be emptied enough to go to ”OK”.

1.4 State machine composition

The hierarchical structure of the system has to be reflected in the way the FSMs compose. By composing we mean that the state of a node of the hierarchy depends on the state of its children nodes. For example, a node with 5 children will be in state ”Error” if all its children are in state ”Error”.

This composition can have complex rules; in fact, it is possible to establish ”majority rules” to say how many of the children must be in a certain state for the parent to change its state; actions (commands) can be associated to state changes; conditions can be verified; and so on.

To express the operational aspect of FSMs and their composition we chose to use SMI++; this is a language for FSM definition which was developed at CERN in the context of controls for high energy physics experiments by an original conception by M. Jonker, B. Franek, A. Vascotto and P. Vande Vyvre.

For further details on this language you can read its website¹.

1.4.1 The FSM tree

To express the structure of the FSM composition, we will make use of a tree which represents each FSM as a node, and the relationship between them as a branch of the tree. A node with N children means that that node will have a FSM which is dependent on the FSMs of the N children.

Following a well-established convention which is commonly used in control systems (and of which a description can be found in the JCOP² documentHierarchical Controls Configuration and Operation³ in which there are two types of nodes: Control Units and Device Units. Device Units (DU) are the ones that actually correspond to devices that can be controlled and monitored; Control Units (CU) are the ones that are used to monitor and control a sub-tree or a device below them.

In our DVM, the DU correspond to the hardware under the leaves of the tree, which are the real devices; they have a simple FSM (only states and transitions between them) and all they do is receiving commands and transforming them into actions on the device, and receiving data from the device and

1http://smi.web.cern.ch/smi/

2http://itco.web.cern.ch/itco/Projects-Services/JCOP/

3http://clara.home.cern.ch/clara/fw/FSMConfig.pdf

(25)

1.4. STATE MACHINE COMPOSITION 13 translating it into states. The CU instead correspond to the internal nodes of the tree that control and monitor the subtree and/or devices below them, and that implement logic behaviour through their FSM.

In this tree model, commands go ”down” and states go ”up”. Commands and states are the interface between objects (and also among objects and operators).

A representation of this FSM tree is shown in Figure 1.11. Names have been shortened for conve- nience, but they should retain a clear meaning; for example ”Fdg” is the Fridge, CupSup is the Cup Supply, and so on; you can refer to Figure 1.1, as the hierarchy corresponds. DUs have been put in evidence by a square around them.

1.4.2 FSMs for Control Units

As said, the FSMs for the CU manage the logic of the behaviour of the hierarchy. Here we will give the FSM of each CU and express their behaviour using tables.

(26)

DVM00pp

aaaa aaaaaa

aaaaaa aaaaaa

aaaa aaaaaa

aaaaaa aaaaaa --[[[[[[[[[[[[[[[[[[[[aa[[aaa[[OOmm

Cold11qq

cccccccc

cccccc cccccc ++WWWWWWWWccWWcccWWOOkk

Hot11qq

cccc cccccc

cccccc cccccc ss ccc33 gggggg

gggg xx gg88 q q q ,,YY&&YYYYM MYYYYq q qM MYYYYYYM MYYffllYOO MB

Fdg88xx

q q q

&&M Mq q qM MqM Mff

Nat88xx

q q q

&&M Mq q qM MqM Mff

ExitOO Water88xxq q q

&&M Mq q qM MM Mff CoffeeOO MilkOO TeaOO SugarOO Cups88xxq q q

&&M Mq q qM MM Mff

FdgTr88xx

q q q

&&M Mq q qM MM Mff FdgThOO NatTr88xxq q q

&&M Mq q qM MM Mff NatThOO WatSupOO WatThOO CupSupOO ArmOOFTDrOO FTCntOO NTDrOO NTCntOO

Figure1.11:TheFSMtreeoftheDVM.Boxednodes(leaves)areDeviceUnits;theothersareControlUnits.

(27)

1.4. STATE MACHINE COMPOSITION 15 DVM Control Unit

OK Warning Faulty

Figure 1.12: The DVM CU FSM

Cold Hot Moneybox DVM

OK OK OK OK

Warning not Faulty not Faulty Warning not Faulty Warning not Faulty Warning not Faulty not Faulty Warning Warning

Faulty any any Faulty

any Faulty any Faulty

any any Faulty Faulty

Table 1.1: DVM state changes

(28)

16 CHAPTER 1. A DVM SPECIFICATION AS A CONTROL SYSTEM SAMPLE Cold Control Unit

OK Warning Faulty

Figure 1.13: The Cold CU FSM

Fridge Natural Exit Cold

OK OK Free OK

Warning OK or Warning Free or Occupied Warning OK or Warning Warning Free or Occupied Warning OK or Warning OK or Warning Occupied Warning

Faulty any any Faulty

any Faulty any Faulty

any any Faulty Faulty

Table 1.2: Cold state changes

(29)

1.4. STATE MACHINE COMPOSITION 17 Hot Control Unit

OK Warning Faulty

Figure 1.14: The Hot CU FSM

(30)

Water Cups Coffee Milk Tea Sugar Hot

OK OK OK OK OK OK OK

Warning not Faulty not Empty any any any Warning

Warning not Faulty any not Empty any any Warning

Warning not Faulty any any not Empty any Warning

not Faulty Warning not Empty any any any Warning

not Faulty Warning any not Empty any any Warning

not Faulty Warning any any not Empty any Warning

not Faulty not Faulty Low any any any Warning

not Faulty not Faulty any Low any any Warning

not Faulty not Faulty any any Low any Warning

not Faulty not Faulty Empty not Empty any any Warning

not Faulty not Faulty Empty any not Empty any Warning

not Faulty not Faulty not Empty Empty any any Warning

not Faulty not Faulty any Empty note Empty any Warning

not Faulty not Faulty not Empty any Empty any Warning

not Faulty not Faulty any not Empty Empty any Warning

not Faulty not Faulty not Empty any any Low or Empty Warning

not Faulty not Faulty any not Empty any Low or Empty Warning

not Faulty not Faulty any any not Empty Low or Empty Warning

any any Empty Empty Empty any Faulty

Faulty any any any any any Faulty

any Faulty any any any any Faulty

Table 1.3: Hot state changes Fdg Control Unit

OK Warning Faulty

Figure 1.15: The Fdg CU FSM

(31)

1.4. STATE MACHINE COMPOSITION 19 Tray Thermostate Fridge

OK TempOK OK

Faulty any Faulty

OK TempWarning Warning

any TempError Faulty

Table 1.4: Fridge state changes (Fdg)

Nat Control Unit

OK Warning Faulty

Figure 1.16: The Nat CU FSM

Tray Thermostate Natural

OK TempOK OK

Faulty any Faulty

OK TempWarning Warning

Table 1.5: Natural state changes

(32)

20 CHAPTER 1. A DVM SPECIFICATION AS A CONTROL SYSTEM SAMPLE Water Control Unit

OK Warning Faulty

Figure 1.17: The Water CU FSM

Water supply Thermostate Water

OK TempOK OK

not Lacking TempWarning Warning

Lacking any Faulty

Table 1.6: Water state changes

(33)

1.4. STATE MACHINE COMPOSITION 21 Cups Control Unit

OK Warning Faulty

Figure 1.18: The Cups CU FSM

Cup supply Arm Cups

OK Free OK

not (Empty or Jammed) Occupied Warning

LowNumber not Jammed Warning

Empty or Jammed any Faulty

any Jammed Faulty

Table 1.7: Cups state changes

(34)

22 CHAPTER 1. A DVM SPECIFICATION AS A CONTROL SYSTEM SAMPLE FdgTr and NatTr Control Units

OK Faulty

Figure 1.19: The FdgTr and NatTr CU FSM

Door Container Tray

OK OK OK

OK LowNumber Warning

Jammed any Faulty

any Empty Faulty

any Jammed Faulty

Table 1.8: Tray state changes (FdgTr and NatTr)

(35)

1.5. USER PROFILES 23

1.5 User profiles

The universe of the DVM operators:

1.5.1 User

This operator is the regular client who want consume some item from the DVM. This operator is presented to the system by any of two different profiles.

• Base: This operator is the simple user that doesn’t register in the machine’s user DB. This user will be able to browse through the store options, select the product and pay. All the options will be inactive if the machine has operation errors. This is the only operator that doesn’t register into the system.

• Advanced: This operator registers himself on the machine (biometric devices, magnetic cards, etc.) and has a local profile. This profile will define the levels of ”trust” that allows him to solve problems on the machine with guided help (e.g. like the typical paper jam messages already existent in the present printer technologies). To do so, the machine will suggest training modes to update the personal profile and will apply certain criteria like age, professional skills or others to define the user permissions over the existing maintenance controls. Of course, some business- sensitive controls will always be restricted to this operator, (e.g the container door) - and so, no special training will be provided to this skill. Other interesting features would be to deal with the user’s preferences, e.g to have a menu option to select the typical meals the user is always looking for to work as a shortcut.

1.5.2 Technician

This operator is the regular technician from the assigned DVM’s maintenance company, so he is expected to have all the control over the DVM. However the machine restricts access to certain high-skilled maintenance controls, in order to protect the machine from incorrect operation. This operator is presented to the system by any of two different profiles.

• Base: This operator is allowed to fix and monitor basic common maintenance problems (e.g container jams and refuelling). Training modes will be presented to this operator, giving him the chance to gain access to the maintenance controls he’ll need to solve a certain problem.

• Advanced: After completing certain training tests the base operator profile is upgraded to advanced, where he’ll have the chance to get more maintenance control to the DVM (e.g internet problems and temperature problems).

1.5.3 Internet User

This operator is the regular client that wants to be informed about the status of the DVM remotely.

This operator is presented to the system by any of two different profiles. Both have special constraints.

The tasks are only monitoring, that is, they don’t have any control at all over the remote DVMs.

• Base: No shopping. Only monitors. Wants to know if the machine status, which products are available.

• Supervisor: This is the typical role for the vending machine corporation to be informed about the need to send technicians to repair, or solely to refuel the machines. Eventually some diagnosis could be done remotely and some reporting figures could be inferred (i.e. how much money the machine contains inside).

(36)

1.6 Use cases

1.6.1 User

Base

• List available products: The list of all available products on the DVM is displayed to the base user.

Some products may appear unavailable in case of some problem on the affected subsystem. If the DVM is completely inoperable, there will be no products presented.

• Select and buy drink: The user selects the desired drink and inserts the sufficient amount of money to pay the selected drink. After payment, the DVM will deliver the selected drink to the user.

If the inserted amount of money is above the required for the selected drink, the change will be returned to the user. If the DVM doesn’t have enough change to return, then the transaction will be aborted, returning all the inserted money to the user and an error message will be shown indicating that the DVM doesn’t have enough change to comply the users order.

• Complains report: The user can report complains and post suggestions to the DVM managers.

Advanced

• List available products: The list of all available products on the DVM is displayed to the advanced user. Some products may appear unavailable in case of some problem on the affected subsystem.

If the DVM is completely inoperable, there will be no products presented.

• Select and buy drink: The advanced user selects the desired drink and inserts the sufficient amount of money to pay the selected drink. After payment, the DVM will deliver the selected drink to the advanced user. If the inserted amount of money is above the required for the selected drink, the change will be returned to the advanced user. If the DVM doesn’t have enough change to return, then the transaction will be aborted, returning all the inserted money to the advanced user, and an error message will be shown indicating that the DVM doesn’t have enough change to comply the advanced user’s order.

• Register on system: The advanced user registers some credentials to uniquely identify him on the DVM system.

• Login on system: The advanced user enters on the DVM by introducing his personal credential which identifies him on the system. A specific user interface will be presented according to its specific user profile. If the login process fails, the current user’s profile is reset to ”base user”.

• Skill Training: The advanced user can be trained to solve and fix jams, and also to create high level controls. To complete each train, the DVM tests the advanced user’s new skills with few questions.

• Solves Basic Jams: After completing the training process, the advanced user is allowed to try to solve basic jams like door jams and exit jams with the assistance of the DVM.

• Create High Level Controls: After completing the training process, the advanced user is allowed to create high level controls which can combine several controls. E.g.: ”the user creates a button to automatically get a coffee with three measures of sugar”.

• Complains report: The advanced user can report complains and post suggestions to the DVM managers.

1.6.2 Technician

Base

• List available products: The list of all available products on the DVM is displayed to the technician.

Some products may appear unavailable in case of some problem on the affected subsystem. If the DVM is completely inoperable, there will be no products presented. This feature is useful to test the DVMs functionality.

(37)

1.6. USE CASES 25

• Select and buy drink: The technician selects the desired drink and inserts the sufficient amount of money to pay the selected drink. After payment, the DVM will deliver the selected drink to the technician. If the inserted amount of money is above the required for the selected drink, the change will be returned to the technician. If the DVM doesn’t have enough change to return, then the transaction will be aborted, returning all the inserted money to the technician and an error message will be shown indicating that the DVM doesn’t have enough change to comply the technician’s order. This feature is useful to test the DVM’s functionality.

• Register on system: The technician registers some credentials given by the DVM’s system administrator to uniquely identify him on the DVM system. The technician can then configure its own credentials.

• Login on system: The technician enters on the DVM by introducing his personal credential which identifies him on the system. A specific user interface will be presented according to its specific user profile. If the login process fails, the current user’s profile is reset to ”base user”.

• Skill Training: The technician can be trained to solve basic jams, container jams, refueling, power issues, and also to create high level controls. To complete each train, the DVM tests the technician’s new skills with few questions. After completing all ”basic” training, the technician is allowed to be automatically promoted to the ”advanced technician” profile.

• Solves Basic Jams: The technician is allowed to try to solve basic jams like door jams and exit jams with the assistance of the DVM. The ”basic jams” training process is optional.

• Solves Container Jams: After completing the ”container jams” training process, the technician is allowed to try to solve jams on all the containers.

• Refuel: After completing the ”refuel” training process, the technician is allowed to refuel supplies on all containers.

• Power[On—Off ]/Reset: After completing the ”power” training process, the technician is allowed to power on and off, as well as resetting the DVM system.

• Create High Level Controls: The technician is allowed to create high level controls which can combine several controls. The training process on creating high level controls is optional.

Advanced

• List available products: The list of all available products on the DVM is displayed to the advanced technician. Some products may appear unavailable in case of some problem on the affected subsystem. If the DVM is completely inoperable, there will be no products presented. This feature is useful to test the DVM’s functionality.

• Select and buy drink: The advanced technician selects the desired drink and inserts the sufficient amount of money to pay the selected drink. After payment, the DVM will deliver the selected drink to the advanced technician. If the inserted amount of money is above the required for the selected drink, the change will be returned to the advanced technician. If the DVM doesn’t have enough change to return, then the transaction will be aborted, returning all the inserted money to the advanced technician and an error message will be shown indicating that the DVM doesn’t have enough change to comply the advanced technician’s order. This feature is useful to test the DVM’s functionality.

• Register on system:The advanced technician registers some credentials given by the DVM’s system administrator to uniquely identify him on the DVM system. The advanced technician can then configure its own credentials.

• Login on system: The advanced technician enters on the DVM by introducing his personal credential which identifies him on the system. A specific user interface will be presented according to its specific user profile. If the login process fails, the current user’s profile is reset to ”base user”.

• Skill Training: The advanced technician can be trained to solve basic jams, container jams, refueling, power issues, temperature problems, internet problems and also to create high level controls.

To complete each train, the DVM tests the advanced technician’s new skills with few questions.

(38)

• Solves Basic Jams: The technician is allowed to try to solve basic jams like door jams and exit jams with the assistance of the DVM. The ”basic jams” training process is optional.

• Solves Container Jams: The advanced technician is allowed to try to solve jams on all the containers. The ”container jams” training process is optional.

• Solves Temperature Problems: After completing the training on ”temperature problems”, the advanced technician is allowed to try to solve temperature problems on both subsystems.

• Solves Internet Problems: After completing the training on ”internet problems”, the advanced technician is allowed to try to solve internet problems.

• Refuel: The advanced technician is allowed to refuel supplies on all containers. The ”refuel”

training process is optional.

• Power[On—Off ]/Reset: The advanced technician is allowed to power on and off, as well as resetting the DVM system. The ”power” training process is optional.

• Monitors Internet Interface: After completing the training on ”internet problems”, the advanced technician is allowed to monitor the internet interface.

• Monitors Thermostats: After completing the training on ”temperature problems”, the advanced technician is allowed to monitor temperature on both subsystems.

• Create High Level Controls: The advanced technician is allowed to create high level controls which can combine several controls. The training process on creating high level controls is optional.

1.6.3 Internet User

Base

• List available products: The list of all available products on the specified remote DVM is displayed to the base internet user. Some products may appear unavailable in case of some problem on the affected subsystem. If the specified remote DVM is completely inoperable, there will be no products presented.

• Register on system: The base internet user registers some credentials to uniquely identify him on the DVM system. This account can then be used to login as an advanced user on a local DVM.

• Login on system: The base internet user enters on the specified remote DVM by introducing his personal credential which identifies him on the DVM system. A specific user interface will be presented according to its specific user profile. If the login process fails, the user cannot access the list available products functionality.

Supervisor

• List available products: The list of all available products on the specified remote DVM is displayed to the supervisor. Some products may appear unavailable in case of some problem on the affected subsystem. If the specified remote DVM is completely inoperable, there will be no products presented. This feature is useful to test the DVM’s functionality.

• Register on system: The supervisor registers some credentials given by the DVM’s system administrator to uniquely identify him on the DVM system. The supervisor can then configure its own credentials. This account can then be used to login as a technician on a local DVM.

• Login on system: The supervisor enters on the specified remote DVM by introducing his personal credential which identifies him on the DVM system. A specific user interface will be presented according to its specific user profile. If the login process fails, the user cannot access any of the internet user’s functionality.

• Reporting: The supervisor is able to retrieve several reporting data (eg. complains report, money report, drink report).

(39)

1.6. USE CASES 27

• Power[On—Off ]/Reset: The supervisor is allowed to power on and off, as well as resetting the DVM.

Some views of the Use Cases are shown in Figures 1.20, 1.21 and 1.22

Select and buy drink

User (base)

User (advanced)

Register on system Login on system Complains report

Skill Training

Create High Level Controls Technician (base)

Refuel

Power[On|Off]/Reset

Technician (advanced)

Monitors Internet Interface

Monitors Thermostates Internet User (base)

Internet User (advanced) List available products

Lists Complains report Solves Basic Jams

Solves Container Jams

Solves Temperature Problems Solve Internet

Problems

Figure 1.20: Use Case diagram

Notes: We’re not considering the case of having a third level of profiles in which the other profiles can then be promoted if and only if they are both advanced tecnician’s and advanced internet user.

(40)

Select and buy drink

Register on system

Login on system

Complains report

Skill Training

Create High Level Controls

Refuel

Power[On|Off]/Reset

Monitors Internet Interface Monitors

Thermostates

List available products

Lists Complains report Solves Basic Jams

Solves Container Jams

Solves Temperature Problems Solves Internet

Problems

Figure 1.21: Use Cases in a set diagram

(41)

1.6. USE CASES 29

Monitors Internet Interface

Monitors Thermostats Solves Temperature

Problems Refuel

Solves Container Jams Skill Training

Create High Level Controls

Solves Basic Jams Select and buy drink

Complains report

Power[On|Off]/Reset

Lists Complains report

List available products

Register on system Login on system

Solves Internet Problems

Figure 1.22: Use Cases in another set diagram

(42)

(43)

Chapter 2 Towards a formal, model-based framework for control systems interaction prototyping

M. Risoldi, V. Amaral

Springer Lecture Notes in Computer Science, Proceedings of the RISE 2006 conference (to appear)

2.1 Abstract

This paper provides an overview of a starting project called BATIC³S (Building Adaptive Three- dimensional Interfaces for Critical Complex Control Systems). This project aims to bring a more viable approach in the fields of Graphical User Interfaces (GUI), software modeling and verification, automatic code generation, and adaptivity. The goal is to build a comprehensive methodology for semi-automated, formal model-based generation of effective, reliable and adaptive 3D GUIs for diagnosing control systems. This can be used to assist in GUI development for very complex systems, like industrial systems, high energy physics experiments and similar.

2.2 Introduction

Developing Graphical User Interfaces (GUIs) for complex control systems is costly, difficult and error prone. Large hardware systems as you can find in industries, physics research centers or transportation (airplanes) have a high complexity coming from the number of components, their hierarchical interaction and the large number of parameters to be monitored at once. This poses challenges in particular concerning the correctness of the control, the navigation issues and the paradigm for human interaction.

Therefore, it is of first importance to systematize the specification and modeling of systems, to find new ways of interaction and to minimize the development cost of GUI production in order to be able to test interfaces from a usability point of view.

In this paper we will present a work in progress, stating our views on how various software engineering techniques and aspects can be integrated and coordinated in a methodology to standardize and assist the development of such interfaces. We will speak through examples about what technologies we are using for it. Finally we will briefly illustrate two case studies that are currently guiding our work. A survey on related work, with analysis and a comparative study of previous approaches in the field of user interface prototyping for control systems, has been done in [7].

31

(44)

32 CHAPTER 2. TOWARDS A FORMAL, MODEL-BASED FRAMEWORK FOR...

2.3 The general approach

2.3.1 Definition of a control system

Control systems (CS) can be defined as mechanisms that provide output variables of a system by ma- nipulating the inputs (from sensors). The field of CS is wide, and ranges from the very simple to the very complex. To avoid a lack of applicability, we had to reduce the field to systems with some specific features. The definition of a CS we use (and a very widely accepted one) is a system which has a hierarchical organization, in which every elementary object can be grouped with others, and composite objects (groups) can be grouped as well, forming a hierarchical tree in which the root represents the whole system and the leaves are the actual devices that form it. Typically this grouping will reflect a physical container-contained composition (but it could follow other relations as well). Elementary and composite objects can receive commands and communicate states and alarms. Figure 2.1 shows a partial example of such a system, a simple drink vending machine (DVM). We will use it also in following examples.

DVM

Fridge Money

Unit

Door Container

Operator A

Operator B

Operator C

...

Hardware Hardware

Commands States and Alarms

Tray 1 ... Tray n

Hardware Thermostate

Figure 2.1: An example of hierarchical control system: drink vending machine

We can see basic, low level components: theDoor, the Containerand the Thermostate. These get input directly from the hardware (through sensors, for example), and have simple states which depend on this input (e.g. the Thermostate might have statesTempOk, TempWarningandTempError, depending on a temperature sensor). These basic components are grouped in various ways - Door and Container are grouped in aTray, which is a composite object; several trays and a Thermostate are grouped in a Fridge. The latter, and another compositeMoney Unit, are in turn grouped into the top object,DVM.

We see that the operators might have access to the system at various levels, either at a higher level or only to a part of it, according to their needs or their profile.

In such a system, commands should be able to be passed down in the hierarchy, so that for example Operator A is able to send commands not only to DVM, but also to Tray1. States and alarms, instead, should flow up, meaning that an object that fails should notify its state to its ancestor objects, which might in turn decide to update their states depending on this information. This is essential for diagnosing faults even at the highest levels.

(45)

2.3. THE GENERAL APPROACH 33

Widget LibraryWidget

Library

System &

GUI Description

Model

System Model

GUI Logical Model

Prototype Generator Widget

Library

GUI Prototype Driver Driver

System simulator

GUI Visual ModelGUI Visual ModelGUI Visual Model

HW system

System Structure

System Dynamic Behaviour System

Static Behaviour GUI

FSM User

Profiles Use cases

Adaptivity Rules

Simulation

Testing

Requirements

Code Generation

Prototyping

Figure 2.2: The general schema of the methodology

(46)

2.3.2 The methodology

Figure 2.2 shows how we defined the methodology for GUI building. There is an initial phase where the requirements and specifications for the system and GUI are gathered (top semicircle). From this information, a model is built semi-automatically (central square). Finally, a prototype is generated from the model (bottom semicircle). In the following sections we will analyze these three phases, explain some technological choices that have been made for their application, and discuss the advantages that we find.

2.4 Gathering requirements

We start with the requirements of the System and the GUI, which should be provided by the system engineers/technicians/users, what we call System Experts in general. These should include:

• A description of the system structure, in its hierarchical aspects (as in Figure 2.1) as well as in its geometrical properties (shape, location, dimensions of every component of the system that we shall represent in the GUI);

• The system behaviour, as in what commands objects can accept, and what values they may communicate; this is a concept akin to what we callinterfacefor a Class in OO programming;

• The dynamic behaviours for all the objects of the system, and also how they compose (i.e. how an object can react, by changing its state, to a child object’s state change);

• The FSM for the GUI, describing its initial and possible states (e.g. different levels of visualization, different operation modes) and how they might change in reaction to events;

• Use cases and user profiles, which are needed to establish adaptivity rules.

Adaptivity rules describe how the interface should react to a number of factors[42], including user knowledge, both static (profile) and dynamic (training), events in the system (faults, alarms) or particular actions. Adaptation is a complex and vast topic which would require an article on its own, and we will not treat it here.

2.4.1 Formalizing requirements

A problem that most developers meet at some point is that there is usually an impedence problem between the way of thinking of software developers and system experts. Software developers have their mind focused on getting requirements for building an interface, often ignoring or simply not understand- ing some of the requests coming from the system experts. System experts, on the other hand, might have a faint idea of what rigour is needed to express requirements for developers, but have a very deep knowledge of the information to provide, and it is only they who can say if a software meets the requirements or not. This risks causing production of poor software which only partially meets the requests and is a challenge to modify and maintain.

Previous research in the field [13] has shown with experimental data that efforts to provide a more un- derstandable specification can greatly help in reducing error rates and increasing comprehension. Other works [40] have shown that one important factor to reduce ambiguity and complexity of specifications is to define a precise domain to work with, although the conclusions point out that this is not enough and that no unique technique can ensure an all-purpose solution even for a specific domain. As we found in more research [38, 26, 6], there are however some clear advances whenever the field has some standardized ways of specifying it. If one can rely on having certain information under a certain form, there are stronger assumptions that can be done on the efficiency of a proposed solution.

We are trying to express the system features by defining a domain specific framework which is at the same time simple enough for system experts to use and formal enough for developers to work on. Also, we want this to be usable in practice, not only in theory. To achieve this, first of all we concentrated on a very specific domain, as we discussed when giving a definition of control systems. Then, we adopted a base for the framework which is in fact a composition of several approaches:

(47)

2.4. GATHERING REQUIREMENTS 35

• we use a domain specific language (DSL), suitable to express hierarchical and functional charac- teristics of objects.

• for storing this data we use a database (according to a very well-established schema for control systems[2]) containing the system composition, geometry and dataflow. Often this kind of database generally will already exist, because it’s used in the system engineering phase, for construction and testing. In other cases still it should not be difficult to build, because of its modularity and the fact that the information it asks for has normally been defined anyway.

• we are deriving a dynamic state-machine language from State Manager Language (SML) [15]; this solution also presents an advantage in which SML is a widely used language as it is integrated in one of the major monitoring and supervision softwares, PVSS II [14].

An example of specification is the following. Let’s consider a part of the hierarchy of the DVM of Figure 2.1: a fridge containing a tray and a thermostate, with the tray containing a door and a container for drinks. In Listing 2.1 the Container class is defined.

Listing 2.1: Definition of a Container c l a s s : C o n t a i n e r ;

t y p e : A;

geomshape : Box ;

d i m e n s i o n s : 1 0 0∗1 0 0∗9 0 0 ; c o o r d i n a t e s : 1 0∗2∗1 0 ;

p r o p e r t y drinkNumber : i n t e g e r ; method r e f i l l ( p1 : i n t e g e r ) ;

drinkNumber=drinkNumber+p1 ; end method ;

method buy ( ) ;

i f ( s t a t e !=Empty ) t h e n

drinkNumber=drinkNumber−1;

e l s e e x c e p t i o n ; end method ;

s t a t e : Empty / INITIAL STATE ; when r e f i l l ( p1 ) do r e f i l l e d ;

a c t i o n : r e f i l l e d ;

i f ( p o s t ( drinkNumber )>5) t h e n t e r m i n a t e a c t i o n / s t a t e=OK;

e l s e i f ( p o s t ( drinkNumber ) <= 5 && p o s t ( drinkNumber )>0) t h e n t e r m i n a t e a c t i o n / s t a t e=LowNumber ;

end a c t i o n ; end s t a t e ;

s t a t e : LowNumber ;

when buy ( ) do bought ;

when r e f i l l ( p1 ) do r e f i l l e d ; a c t i o n : bought ;

i f ( p o s t ( drinkNumber )=0)

t h e n t e r m i n a t e a c t i o n / s t a t e=Empty ; e l s e t e r m i n a t e a c t i o n / s t a t e=LowNumber ; end a c t i o n ;

a c t i o n : r e f i l l e d ; . . .

end a c t i o n ; end s t a t e ;

. . . \\ more s t a t e s d e f i n i t i o n s . . . end c l a s s ;

(48)

We can see the description of the base features of the object class - its name, type, and the geometrical features. The type is useful if we want to define features at a sub-class level: there might be different types of containers, and in each type we might have specific features, but still have a container. This can help in large scale systems, where the number of types is generally much more limited than the number of objects.

The functional features (properties and methods) are then listed. For each property we have its type; for each method we define the types of the parameters and an implementation. Note that in this phase the specification should abstract objects to focus on the control aspects; we don’t implement all the details of thebuymethod, but simply the fact that it takes one drink from the container.

Finally, there is the definition of the state machine. States are listed one after the other, and the initial state (hereEmpty) is indicated. For each state, where relevant, the possible events are listed, and the actions triggered by the event are written. Here, in the stateEmpty, whenever there is arefill event, the new value ofdrinkNumberis checked; if it is more than fine, the object goes to stateOK; if it is more than 0 but less or equal to 5, it goes to stateLowNumber. Note thepoststatement, which expresses the value of a propertyafter the event; this allows us to distinguish between pre- and post-conditions of events.

An interesting case to see is the definition of the state machine for a composite object, a Tray. In Listing 2.2 we can see how a state change can be triggered by the state change of a child object. The event here is the state change of a child object,container1. Complex events can be envisaged when there are several children objects, for example establishing a majority rule where the state turns to Faultyonly if the majority of children areFaulty.

Listing 2.2: State change trigger c l a s s : Tray ;

. . .

s t a t e : OK;

when c o n t a i n e r 1 i n s t a t e Empty do GOFAULTY;

a c t i o n : GOFAULTY t e r m i n a t e a c t i o n / s t a t e=F a u l t y ; end a c t i o n ;

end s t a t e ; . . .

end c l a s s ;

Listing 2.3: Instantiating a class o b j e c t : c o n t a i n e r 1 ;

c l a s s : C o n t a i n e r ; t y p e : A;

p a r e n t : t r a y 1 ; end o b j e c t ;

We then have to declare the instances of the classes, as in Listing 2.3. We are saying here that there is an objectcontainer1which belongs to the previously declared classContainer, and that it is a child of Tray. We can declare as many objects of this class as we want, and build complex hierarchies in a very simple recurring way (we will declare a Tray object to have a Fridge parent, we will declare a Fridge object to have a DVM parent...).

Since we can’t foresee system experts writing directly into a DSL or a database, unless we fall again in the difficulty problems approached by [13], we have to develop tools based on wizards which help them provide the requirements, and which represent the organization of the system in a comprehensible way.

Not only this, but also allow a partial specification of a system when the requirements are not complete (a common guideline in rapid software development).

2.5 Modeling

We want a model that expresses hierarchy. We need to model elementary and composite objects, with dynamic states that as we saw can be composite as well. We want to be able to interact with objects at

(49)

2.5. MODELING 37 various levels of the hierarchy (as in Figure 2.1). Another very relevant feature is concurrency: in any given real-world system, more events can occur at the same time, and they could trigger state changes or communications which are concurrent. In order to avoid the nightmare of having to model every single execution case, we needed a modeling language that already takes into account concurrency via its semantics.

The choice was the Concurrent Object-Oriented Petri Nets (CO-OPN) language [10, 8], a formalism based on Petri Nets with abstract algebraic data types. A strong motivation for the choice is that CO-OPN allows for mathematical verification of formal model properties (thanks to its strictly formal semantics) and for automated test generation and selection. Related work has been published on the subject ([24, 22]).

It is supported by a tool, CoopnBuilder, which allows Java code generation from the model. This can be used to generate and run tests on the model even before passing to the implementation phase [5, 23]. Finally, it has a coordination model, based onContexts[10], which goes further than typical Petri Nets strategies for hierarchy based on substitution of nets with transitions (see the remarks on limits of subnet substitutions with transitions in [29] and several papers by P. Palanque and R. Bastide, which can be found in [28]) and can efficiently scale for large systems thanks to its modularity.

2.5.1 Transforming requirements to a model using meta-modeling

By specifying the system as in the previous section, we have enough information to produce two outcomes.

The first is to construct a model ofthe system itself. This will be important with respect to testing the developed interfaces prior to implementing them. The second thing is to deduce elements of the GUI from the features of the system. There are two sources of information for this task: the nature of the data exchange with the object (what methods and parameters it has, if they are in input or output) and the type of paradigm of interaction (like 2D windows and buttons, 3D, textual...). These factors are processed according to tables of rules (similar to [40]) which establish a ”best guess” of what should be used to represent the object, eventually offering alternatives. The developer can still adapt this choice according to specific requirements. For example, the Containerobject has arefill method with an integer parameter. Rules could say that in this case a suitable 2D representation is a textfield (for the integer parameter) and a button (to send the command). The developer could choose to use a combobox instead of a textfield. This will be done using a transformation engine (called Model Transformer) with a graphical interface resuming relevant features for every object (and letting the developer make modifications to single objects or to whole classes).

To produce these outcomes, the completed specification, expressed in our DSL, is transformed automatically by the Model Transformer to a formal model of both the system and the GUI using the CO-OPN language. This is possible thanks to having both the meta-models of CO-OPN and of our DSL, and to meta-model based transformations which are defined between the two. The transformation technique from other languages to CO-OPN is a vast subject, for which related work has been published [32]. The structure of the resulting model is the subject of the following subsections.

2.5.2 A structured model

The model we use is structured in a way that separates functionality and visualization, in a way very much inspired to the Model-View-Controller pattern. With the information we gathered in the initial phase (and that we refined through the model transformer) we can produce three different models. The first, called System Model, represents the physical system. It models all its objects in their hierarchy and inter-communication aspects, by using CO-OPN contexts and synchronization between objects. It can be built using the information about the hierarchy of the system (for structuring the model), the data flow of every object (for defining every object’s methods/gates), and the dynamic behaviour of the system (for defining the internal state machine of every object as well as the synchronization axioms between objects). The second model, called GUI Logical Model, is a model of the GUI in its behavioural aspects.

We don’t have its actual visual representation here, but only its abstraction in terms of interaction - what objects make it up, what are their structural parameters, what they accept and return, and how they interface with the objects of the system in terms of commands and values. The third and last,

(50)

called GUI Visual Model, models the visual aspects of the GUI and the associated semantics. Models communicate with each other just like the interface communicates with the system (see Figure 2.3).

System Model

Dialog Box

Temp 4 State OK

OK

Model world Implementation world

Real System

GUI GUI Logical

Model

GUI Visual Model

Figure 2.3: The structure of the model

2.5.3 The System Model

As an example of the system model we can build one for our example specification of the DVM. A part of the System model is shown in Figure 2.4(a), using CO-OPN graphical notation. As a quick reference, large white squares are context, grey squares are objects; small black rectangles are methods, and small white rectangles are gates (events). Arrows represent axioms of synchronization between gates and methods. The underscore near some methods and gates represents its parameter, which is an algebraic data type (ADT) token.

The hierarchy is obtained by having CO-OPN contexts for each object; the context of a child object is contained in the context of the parent object (seeTrayContextwhich is contained inFridgeContext).

The functional aspects of objects are expressed with a CO-OPN object associated with each context (see theFridgeobject, associated withFridgeContext), that presents methods and events of the object, and that keeps state information. The object also models the implementation of methods via its internal Petri Net.

To model vertical communication in the hierarchy, every context has aCmd method and aReturn gate. These two have axioms that allow the routing of commands and messages in the hierarchy to the right objects. TheCmdmethod takes as parameters the name of the target object, the name of the method to call and its parameters. TheReturn gate gives back the name of the object sending the message, the name of the message and its parameters. Let’s see this with an example. In Figure 2.4(b) we are highlighting the sequence of synchronizations using thicker arrows, numbered 1-4 in sequence (the numbers in circles are only for illustration purposes, and not part of the CO-OPN formalism). We are calling theunlock method of theTray object. To do so we callCmd Tray unlock [] on the outmost context (in this caseFridgeContext). TheCmdmethod has 3 possible synchronizations: calling theCool orStop methods of Fridge, or passing the call to the child context. Axiom 2.1 in theFridgeContext will say that if the object name in theCmdcall is notFridge, the right synchronization is with the child

BATIC3S Project : Document collection 2005-2006

Report

Reference