AutoFOCUS3 Tutorial - Pedestrian Traffic Light · 1 AF3 Overview AutoFOCUS3 Tutorial - Pedestrian...

1 AF3 Overview

AutoFOCUS3 Tutorial- Pedestrian Traffic Light -

(http://af3.fortiss.org)

Fortiss GmbH

An-Institut Technische Universität München

Method: Short overview

• Origin: FOCUS theory = mathematical theory [Broy]

o Notion of component

o Notion of execution

!= UML has no precise notion of execution

• Now: AutoFOCUS modelling language = much more than FOCUS

o Includes requirements, hardware modelling, formal methods, ...

• Methodology: Relatively connected to the SPES method [also Broy et al]

2 AF3 Overview

Tool: Short overview

• Objective: concrete bridge between academy and practice

• Originally (>15yrs): bring FOCUS into a tool

• Now: used to concretize lots of other research ideas

• Main features:

o Integration of various development phases into one tool

o Brings traceability, preserves the meaning

o Complete code generatio

o Formal verification

o DSE

o Open-source = free playground for extensions

3 AF3 Overview

Short presentation of the use case

• Pedestrian traffic light:

• In this example we model the controller of a simple pedestrian crossing with

a pedestrian light and a traffic light.→ we will spend lots of time on

requirements, but will also see features which go beyond requirements

4 AF3 Overview

Goal of this tutorial

• The tutorial describes the content of the model and how to use the model to

create a traffic lights system. We will show you

o The definition of requirements for a system

o The specification of an architecture

o The linking/allocation of the requirements to the components and their

verification

o Verification of the whole model using simulation

• For further information on how to model with AF3, please refer to the help

and the welcome screen. You can find help in the tool or on

http://af3.fortiss.org/.

• You can also access the full solution in AF3 (File Open AF3 Example

Load Simple Traffic Lights Example)

5 AF3 Overview

http://af3.fortiss.org/

1. Requirement analysis

The Requirements Analysis node contains artifacts which are necessary to

determine and structure the requirements of the system. The information you

elicited during the requirements engineering phase of your project will be stored

in this section. There are three different types of artifacts:

• Glossary entries will form the vocabulary of the problem domain of our

project.

• Requirements document describes the needs that our model must be able

to fulfill.

• Requirement sources give information about the original source of the

respective requirements.

6 AF3 Overview

1. Requirement analysis

• Create a “Requirements analyses”-node by right-clicking on your project

folder in the model navigator and selecting “Requirements analyses”.

Rename it “TL-requirements”

will spend lots of time on requirements, but will also see features which go

beyond requirements

7 AF3 Overview

2. Specifying the problem domain

• We are modeling the controller of a simple pedestrian crossing with a

pedestrian light and a traffic light.

• We need to specify: What exactly is a pedestrian in our model? What is

traffic in terms of our Traffic lights system? We need a clear definition of

every object and person that is part of our system, so that is why we capture

the vocabulary of our problem domain in Glossary Entries.

• Usually, the name of the artifact and its definition are sufficient for the entry,

but we need to be as precise as possible with these values. Abbreviations,

synonyms, images and smaller comments to the artifact will give a better

specification of the object, but are not necessarily required.


beyond requirements

8 AF3 Overview


• Create a new Glossary within TL-requirements, add a glossary entry and

open the entry view. At first create a new glossary – named 'Glossary' - with

a glossary entry to define the main user of our system - the pedestrian. Now

fill in the necessary information about the new artifact:

o The Name of the artifact is “Pedestrian”.

o The Definition of a pedestrian is: “A person who travels on foot.”

o A synonym for a pedestrian would be “Walker”.

• Abbreviations or additional pictures and comments are not needed. Fill the

mentioned information in your glossary entry and save the file.

• The result is shown on the next slide


beyond requirements

9 AF3 Overview


10 AF3 Overview

You should also add necessary entries for the Simple Traffic Lights model

(such as Controller” and “Traffic”) and fill their entries appropriately.

3. Specifying requirements

11 AF3 Overview

• Similarly to defining the vocabulary of the problem domain in the model, you

need to define the functional/non-functional requirements of your system

including use cases to define the behavior of your system. The name of the

artifact is “Pedestrian”.

o Create a requirement package, by right-clicking “TL-requirements” and

selecting “Requirements”

o Right-click “Requirements” and select ”Requirements Package”

o Right click ”Requirements Package” and select “Requirement”


12 AF3 Overview

• We will define a requirement of the traffic light controller which sets the

waiting time for pedestrians to a maximum of 2 minutes. Fill in the following

general information in the requirement:

o ID: “1” to the requirement.

o Title: “Pedestrian light timing constraint”

o Description: “Pedestrians should not wait longer than two minutes before

the pedestrian light switches to green.”

o Rationale: “Pedestrians need to move and vehicles must stop”

• You can see the solution on the next slide


13 AF3 Overview

Now that we have defined a requirement on timing constraint for pedestrians, a

similar requirement should be specified for the traffic (“Traffic light timing

constraint”).

4. Use cases & Scenarios

14 AF3 Overview

Add a Use Case for activating the pedestrian light.

• Create another “Requirements Package” within “Requirements” and rename

it “Use Cases Package”

• Right-click “Use Cases Package” and select “Use Case”

• Fill in the following information

o ID: “3”

o Title: “Activate pedestrian light“

o Description: „Pedestrian activates the traffic light controller. Traffic light

and pedestrian light are changed, so that the pedestrian can cross the

street. The indicator shows the actual state of the request.”

o Rationale: “The pedestrian wants to cross the street.”

o Priority: High – Must-be


15 AF3 Overview


16 AF3 Overview

• Use cases describe the interaction of the system with its environment. You

have already created a use case and filled in the necessary general

information. We can build on this example and create a failure scenario to

describe these interactions.

• Scenarios consist of several scenario steps. A possible failure of the system

could be the Controller switching traffic lights and pedestrian lights to red

simultaneously.

• Create a scenario for activating the pedestrian light.

o Right-click the Use Case “Activate pedestrian light” and select “Scenario”

o Rename it “Failure scenario” and fill in informations as followed.


17 AF3 Overview


18 AF3 Overview

Add an additional scenario to the use case for activating the pedestrian light

called “Activate traffic light to 'red' and pedestrian light to 'go'”. Consider that

this scenario is a success scenario and will need branches to “Failure Scenario”

in case that it fails in one scenario step. It should look like the following figure.


19 AF3 Overview

Furthermore, Actors should be added for each step

• Press the Actor-Button which is symbolized by a black stick figure.

• A new window should pop up. Here you can first add “Requirement sources”

by pressing the Green Plus Button.


20 AF3 Overview

• Furthermore you can add Actors by selecting “Requirement sources” and

pressing the Green Plus Symbol.

• You are now asked two choose between “Stakeholder” and “External

System”

• Add 2 stakeholders: Pedestrian, System Architect

• Add 3 External Systems: Indicator, Pedestrian light, Traffic light


21 AF3 Overview

• Finally adjust the fields “Actor” and “Action Type” accordingly (Please find

the results on the next page)


22 AF3 Overview

5. Message Sequence Charts

23 AF3 Overview

Another useful tool is the creation of message sequence charts to display

communication between actors in the system. In the following we are going to

specify the success scenario as a MSC.

• Therefor right-click the Use Case “3 – Activate pedestrian light” in the model

navigator and select “MSC Specification”

• Rename it “Success scenario as MSC”

• You can now draw Entities from Model elements via drag & drop in the

according field


24 AF3 Overview

Create a MSC for a Success scenario.

• Add 5 entities: Pedestrian, Traffic light controller, Indicator, Traffic light,

Pedestrian light

• Draw connections between entities

o press and maintain the “Alt” button

o click on an entity and maintain the mouse clicked

o you can now release “Alt”

o move the mouse on another entity and release the mouse

• You may also rename the connections in a meaningful manner

• Please go to the next slide for an exemplary solution


25 AF3 Overview

6. Data Dictionary

26 AF3 Overview

• After defining the requirements of our system as well as glossaries and

requirement sources, we will have to define the system architecture in order

to map these requirements.

• In AutoFOCUS 3, the system architecture is defined as a set of

communicating components that send and receive information via their

interfaces. Each component interface is defined by a set of input and output

ports respectively. The sender and receiver relation is defined by channels

that connect a sending port with a receiving port.

• Before we start defining our components, we need to define some data

structures first.

6. Data Dictionary

27 AF3 Overview

For the traffic lights system, we create a “Data Dictionary” and define traffic light

signals for both the pedestrian light and the traffic light.

• Right-Click your Top-node folder and select “Data Dictionary”

• You can now draw Entities from Model Elements via drag & drop into “Data

Dictionary”

6. Data Dictionary

28 AF3 Overview

Task 4: For the traffic lights system, we create a “Data Dictionary” and define

traffic light signals for both the pedestrian light and the traffic light.

• Now create 4 “Enumerations” with the following “Enumeration Members”

o IndicatorSignal: On, Off

o PedestrianColor: Stop, Walk

o Signal: Present

o TrafficColor: Green, Red, RedYellow, Yellow

• Furthermore, add 3 Funtions: “tGreen” (Definition: “return 2;”), “tRed”

(Definition: “return 5;”), and “tYellow” (Definition: “return 1;”), change their

Type to “int” in the Properties sections and delete the “Parameter”

Information

• Please see next slide for the solution

6. Data Dictionary

29 AF3 Overview

7. Component Architecture

30 AF3 Overview

Now it is time to build up our Component Architecture.

• Therefor right-click the Top-Node in the model navigator and select

“Component Architecture”

• Rename it “TL-Architecture”

• You can now draw Components from Model elements via drag & drop in the

according field

• You can also draw connections between Components, just as described in

MSC Specification


31 AF3 Overview

We will start by building our first layer architecture

• This will comprise of 3 Components

o Controller (processes the internal state of the traffic lights)

o Panel (simulates the traffic behavior of the system)

o Merge (merges button signals and forward them to the Controller)


32 AF3 Overview


33 AF3 Overview

Now we need to insert reasonable input & output components as well as

transitions between our components

• 1 Input: tlarchInButtonA

• 4 Output components: tlarchOutTrafficSignal, tlarchOutPedestrianSignal,

tlarchOutIndicatorSignalA, tlarchOutIndicatorSignalB

• Furthermore, transitions between the components should be added


o click on a state and maintain the mouse clicked




34 AF3 Overview


35 AF3 Overview

Don’t forget to name the Inputs and Outputs of the components

• Merge

o Inputs: mergeInButtonA, mergeInButtonB

o Outputs: mergeOutRequest

• Controller

o Inputs: ctrlInRequest

o Outputs: ctrlOutTrafficSignal, ctrlOutPedestrianSignal,

ctrlOutIndicatorSignalA, ctrlOutIndicatorSignalB

• Panel

o Inputs: panelInIndicatorSignalB, panelInIndicatorSignalA,

panelInPedestrianSignal, panelInTrafficSignal

o Outputs: panelOutButtonB

8. Controller Component

36 AF3 Overview

In the following we will focus on the component “Controller”


37 AF3 Overview

In the following we will focus on the component “Controller”

• The “Controller” checks for incoming request signals and processes them

into certain output signals.

• In order to build an infrastructure for “Controller” you can either select the

component in the model navigator or double click the “controller”-component

in the TL-Architecture

• Once you did this you can add a new component called “Behavior”

• You should also add transitions from the already existing Inputs and Outputs

to the “Behavior”-Component

o Input - Behavior: request

o Behavior – Output: trafficSignal, pedestrianSignal, indicatorSignalA,

indicatorSignalB


38 AF3 Overview


39 AF3 Overview

In the following we will create a “Automaton Specification” for the Behavior

Component

• Therefor right-click “Behavior” in the Model Navigator and select “Automaton

Specification”

• Rename the Automation specification “RootState”

The behavior of our controller refers to our 'Activate pedestrian light'

requirement and thus is dependent on the state of its traffic lights. The behavior


40 AF3 Overview

The behavior of our controller refers to our 'Activate pedestrian light'

requirement and thus is dependent on the state of its traffic lights.

• At first, 4 States should be added via drag & drop: Red, RedYellow, Yellow,

Green

• Furthermore, connections between the states should be added


o click on a state and maintain the mouse clicked




41 AF3 Overview

• We add two transition from the initial state to the green state (we suppose

that the system always starts with green traffic lights.): “initializeWithNoVal”,

“initializeWithPresent”

• Furthermore, we add the transitions “greenToYellow”, “redyellowToGreen”,

“yellowToRed”, “redToRedyellow”

• There should also be a transition from each state to itself, called

“countdown” (to make sure that the timing constraints defined by our own

requirements will be fulfilled)

• The “Green” state should also have an additional transition to itself called

“receive”

• Please check out the solution on the next slide


42 AF3 Overview


43 AF3 Overview

Now we will adjust Guards and Actions for the transitions

• initializeWithNoVal

• initializeWithPresent


44 AF3 Overview


• greenToYellow

• yellowToRed


45 AF3 Overview


• redToRedyellow

• redyellowToGreen


46 AF3 Overview


• countdown

• receive


47 AF3 Overview

Now we have to define the variable “time” in the “Data State” section of our

“Behavior” component.


48 AF3 Overview

Next we should go to our Use Case defined earlier and add the following Trace

from the Use Case to “Requirement 3 - Pedestrian light timing constraint”

Observe in the model navigator that the component now has a trace which

allows you to navigate back to the requirement:


49 AF3 Overview

As we described a certain behavior of our system in a use case previously, with

the completion of the state machine, we are now able to implement this

behavior by connecting said requirement with our architecture. Fill in the

necessary information in its Detail section now:

• Assign the scope of the Use case, which is our recently crafted Behavior

component.

• The main actor is our pedestrian.

• As a trigger, the pedestrian needs to activate the traffic lights controller by a

request. This request signal will be sent to our only input port of the Behavior

component.

• Try to think of what else should be inserted here Solution on next Slide


50 AF3 Overview

9. Merge Component

51 AF3 Overview

Now we need to define the “Merge” component which merges our first button

input with the button input from the panel component.

9. Merge Component

52 AF3 Overview

The only purpose of this component is to output a present signal to the

controller whenever one or both of the buttons have been pressed. We are no

going to build a Automaton Specification with 3 transitions, from the starting

state to itself:

• forwardA

• forwardB

• forwardBoth

9. Merge Component

53 AF3 Overview

10. Panel Component

We will now concentrate on the last component “Panel“. This component is

responsible for simulating our architecture and assess how it works out.

10. Panel Component

55 AF3 Overview

• The panel should consist of two smaller subcomponents: the HAL and the

Display with an operator panel.

10. Panel Component

56 AF3 Overview

The HAL or hardware abstraction layer is a component which we can be used

to initialize the system with default values for the traffic lights. So its main

purpose is to receive data of the controller component and forward them to the

display component. Several data state variables are defined in here (traffic light,

pedestrian light and indicator signals). The component reassigns the values of

the data state variables if the input is different from the current value.

10. Panel Component

57 AF3 Overview

Now we will build the Automaton Specification for “HAL”. Therefor we only need

to transitions from the init-state to itself with the following Guards and Actions:

• outputVariables

• setAndOutputVariables

10. Panel Component

58 AF3 Overview

10. Panel Component

59 AF3 Overview

The HAL component should output the initial values if the system has started,

but there hasn't been made any valid input yet

10. Panel Component

60 AF3 Overview

• The Display Component is responsible for the actual simulation of the

system. For this, we are going to prepare an operator panel specification on

our display component. It will receive input signals of our previously defined

HAL component.

• As the name is implying, this will display the result of our traffic light system.

Let us build up the model for our pedestrian lights in the operator panel.

Given that we have two different states for our pedestrian lights (on and off),

we should use two color displays…

10. Panel Component

61 AF3 Overview

In the following we will create an “Operator Panel” for the “Display “Component

• Therefor right-click “Display” in the Model Navigator and select “Operator

Panel”

• At first we should add Color Display elements via drag & drop, which will

display the result of our traffic light system

o TrafficRed, TrafficYellow, TrafficGreen

o PedestrianRed, PedestrianGreen

o IndicatorA, IndicatorB

• We also need a Button (“ButtonB”) for further incoming requests from

pedestrians

• Furthermore, we can add Labels for description purposes

• Please find the solution on the next slide

10. Panel Component

62 AF3 Overview

10. Panel Component

63 AF3 Overview

We need to define the reactions of these displays depending on the input

signals arriving at every time step. So when a Stop signal is entering the

component, we expect the pedestrian lights to show red light, while the other

one is inactive.

• Therefor, click on the “PedestrianRed” Color Display, select “Reactions” in

“Properties” and type in the following Guards

• Try to come up with guards for the other Color Displays. Please find the

solution on the next slides

10. Panel Component

64 AF3 Overview

• PedestrianGreen

• TrafficRed

10. Panel Component

65 AF3 Overview

• TrafficYellow

• TrafficGreen

10. Panel Component

66 AF3 Overview

• IndicatorA

• IndicatorB

10. Panel Component

67 AF3 Overview

• Finally, you have to enter a guard for the “ButtonB” (on select, it should

send a signal back to the actual system).

11. Simulation

68 AF3 Overview

Start the simulation by Right-Clicking TL-Architecture in your Model Navigator

and selecting “Run Simulator”.

• On default the traffic lights in the display screen should be on green, while

the Pedestrian lights are red for now. Indicator signals shouldn't be set yet.

• Press ButtonB to start the simulation.

After a short delay, indicator signals should glow for an instant and the traffic

light should switch from green to yellow to red.

When traffic lights are red, Pedestrian lights should be on Go mode. After a few

seconds passed, traffic lights are switching to RedYellow to Green.

When traffic lights are green again, Pedestrian lights should be on Stop mode.

The system will return to its initial state.

11. Simulation

69 AF3 Overview

Congratulations, you successfully

modeled a simple traffic light system!

You can now work on improving it or

dedicate to other projects now.

AutoFOCUS3 Tutorial - Pedestrian Traffic Light · 1 AF3 Overview AutoFOCUS3 Tutorial - Pedestrian...

Documents

Transcript of AutoFOCUS3 Tutorial - Pedestrian Traffic Light · 1 AF3 Overview AutoFOCUS3 Tutorial - Pedestrian...