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
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.
will spend lots of time on requirements, but will also see features which go
beyond requirements
8 AF3 Overview
2. Specifying the problem domain
• 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
will spend lots of time on requirements, but will also see features which go
beyond requirements
9 AF3 Overview
2. Specifying the problem domain
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”
3. Specifying requirements
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
3. Specifying requirements
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
4. Use cases & Scenarios
15 AF3 Overview
4. Use cases & Scenarios
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.
4. Use cases & Scenarios
17 AF3 Overview
4. Use cases & Scenarios
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.
4. Use cases & Scenarios
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.
4. Use cases & Scenarios
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
4. Use cases & Scenarios
21 AF3 Overview
• Finally adjust the fields “Actor” and “Action Type” accordingly (Please find
the results on the next page)
4. Use cases & Scenarios
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
5. Message Sequence Charts
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
5. Message Sequence Charts
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
7. Component Architecture
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)
7. Component Architecture
32 AF3 Overview
7. Component Architecture
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 press and maintain the “Alt” button
o click on a state and maintain the mouse clicked
o you can now release “Alt”
o move the mouse on another entity and release the mouse
7. Component Architecture
34 AF3 Overview
7. Component Architecture
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”
8. Controller Component
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
8. Controller Component
38 AF3 Overview
8. Controller Component
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
8. Controller Component
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 press and maintain the “Alt” button
o click on a state and maintain the mouse clicked
o you can now release “Alt”
o move the mouse on another entity and release the mouse
8. Controller Component
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
8. Controller Component
42 AF3 Overview
8. Controller Component
43 AF3 Overview
Now we will adjust Guards and Actions for the transitions
• initializeWithNoVal
• initializeWithPresent
8. Controller Component
44 AF3 Overview
Now we will adjust Guards and Actions for the transitions
• greenToYellow
• yellowToRed
8. Controller Component
45 AF3 Overview
Now we will adjust Guards and Actions for the transitions
• redToRedyellow
• redyellowToGreen
8. Controller Component
46 AF3 Overview
Now we will adjust Guards and Actions for the transitions
• countdown
• receive
8. Controller Component
47 AF3 Overview
Now we have to define the variable “time” in the “Data State” section of our
“Behavior” component.
8. Controller 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:
8. Controller Component
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
8. Controller Component
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.