IN-RTIMe 2000
by Øystein Haugen
Engineering Real Time Systems
IN-RTIMe Fall 2000 / Slide 1
Øystein Haugen, Ericsson NorARC, Ifi UiO
Øystein Haugen in a nutshell
l 80-81: UiO, Research assistant for Kristen Nygård
l 81 : IN 105 together with Bjørn Kirkerud
l 81-84: Norwegian Computing Center, Simula-machine
l 84-88: SimTech, typographical applications
l 88-90: ABB Technology, SDL, prototype SDL tool, ATC
l 89-97: SISU project, methodology, V&V, ITU
l 93: Engineering Real Time Systems
l 96: Integrated Methodology -> TIMe
l 96-00: Rapporteur ITU for MSC
l 97: Practitioners’verification of SDL systems (dr. scient.)
l 97- : Ericsson, NorARC
l 98- : Ifi, UiO as Part time Associate Professor
l 99- : Participates in OMG wrt. UML 2.0
IN-RTIMe Fall 2000 / Slide 2
Øystein Haugen, Ericsson NorARC, Ifi UiO
Books and Curriculum
lTIMe - The Integrated Method (CD-rom from Sintef) Version 4
– Ifi has bought licences for restricted use within Ifi domain
– Students may buy CD-rom at a price of 40 Euro (=320 NOK)
lin addition a FrameReader licence must be aquired (30 USD =
220 NOK)
lØ. Haugen: Practitioners’verification of SDL Systems (dr.
scient Thesis 1, Ifi)
lTelelogic Tau will be used to support the exercises
IN-RTIMe Fall 2000 / Slide 3
Øystein Haugen, Ericsson NorARC, Ifi UiO
Goal
lThe seminar will aim at giving the candidates insight into the
different challenges of industrial real time systems
IN-RTIMe Fall 2000 / Slide 4
Øystein Haugen, Ericsson NorARC, Ifi UiO
Practical details
lWhen?
– Friday 9.15 - 12.00
lWhere?
– Seminar Room 3B
lExam
– Credits: 3
– Form: Oral
– Grades: 1.0 - 6.0
lObligatory Exercises
– There will be one obligatory exercise that preferably should be
done in groups
– The students may be asked to explain details in their solution
– Telelogic Tau shall be used for the exercise
IN-RTIMe Fall 2000 / Slide 5
Øystein Haugen, Ericsson NorARC, Ifi UiO
Engineering Real Time Systems
lEngineering?
lReal Time?
lSystems?
IN-RTIMe Fall 2000 / Slide 6
Øystein Haugen, Ericsson NorARC, Ifi UiO
Engineering?
lWell acknowledged and asserted techniques
lCreativity only when and where needed
lReplication of earlier efforts
lPragmatics more than theory
IN-RTIMe Fall 2000 / Slide 7
Øystein Haugen, Ericsson NorARC, Ifi UiO
Real Time?
lIn synchrony with real life
loften small amounts of time for each service
– e.g. Automatic Train Control
loften the actual durations are not significant
– no time reasoning
IN-RTIMe Fall 2000 / Slide 8
Øystein Haugen, Ericsson NorARC, Ifi UiO
Systems?
lreactive
lconcurrent
lreal-time
ldistributed
lheterogeneous
lcomplex
IN-RTIMe Fall 2000 / Slide 9
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe course structure
lTIMe
– Languages (UML, MSC and SDL)
– Method
lVerification
– Challenges (state space explosion)
– Solutions (simplification)
lExercises!
– Using Telelogic Tau 3.5
IN-RTIMe Fall 2000 / Slide 10
Øystein Haugen, Ericsson NorARC, Ifi UiO
Development of Languages
Hoare-logic
Hoare
CSP
Milner
CCS
FORTRAN
COBOL
Algol Pascal
Jones
VDM
SIMULA
Xerox PARC
SmallTalk
SDL-88
LOTOS (ISO)
ER-model
C
OODB
SQL
Bell Labs
C++
Microsoft
Windows
Apple
MacIntosh
OOA(Yourdon)
SDL-92 (ITU)
MSC (ITU)
IN-RTIMe Fall 2000 / Slide 11
Objectory
(Jacobsson)
OMT
(Rumbaugh)
Booch
UML (Rational / OMG)
Sun
JAVA
Øystein Haugen, Ericsson NorARC, Ifi UiO
UML – why
lWe have a need for an informal notation with tool support to
describe the object model in the very early domain modelling
phases
lWe want a notation where the decisions about whether entities
are dynamic objects, processes, variables or signals have
been deferred to later
lUML is supported by Rational, a strong driving force in the
marketplace
lUML is maintained by OMG (Object Management Group) which
also maintains CORBA
IN-RTIMe Fall 2000 / Slide 12
Øystein Haugen, Ericsson NorARC, Ifi UiO
UML Graphical Diagrams
lUML graphical diagrams:
Use:
Identifying main system functions
– Use case diagram
– Static structure diagrams:
lClass / object diagram
– Behavior diagrams:
lSequence diagram
lCollaboration diagram
lState diagram
lActivity diagram
– Implementation diagrams:
lComponent diagram
lDeployment diagram
Domain and application modeling
Interactions between objects
(Ditto), static communication
Class behaviour (state oriented)
Ditto (action oriented)
For software structure
For hardware/software structure
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 13
UML static structure model
multiplicity
association class
reading direction
*
Access Zone
association name
Entry Control
association role
IN-RTIMe Fall 2000 / Slide 14
option
ter
en
ay
m
{or}
Gate
class
Exit Control
*
*
Access Point
may use
*
User
Øystein Haugen, Ericsson NorARC, Ifi UiO
Specialization in UML
Simple AP
Access Point
Card Only AP
Card and PIN AP
generalization symbol
IN-RTIMe Fall 2000 / Slide 15
Øystein Haugen, Ericsson NorARC, Ifi UiO
UML – Summing up
lUML purpose (for TIMe): associations between concepts
without needing to fix the nature of every concept
lUML ambition: to become a language for complete
specification
IN-RTIMe Fall 2000 / Slide 16
Øystein Haugen, Ericsson NorARC, Ifi UiO
Asynchronously Communicating FSMs
1(1)
block type AccessPoint
SIGNAL opened,closed ; /* Door -> Controller */
SIGNAL open, close ; /* Controller -> Door */
/* signal lists (inp), (out) and (validity) defined in
enclosing block. This holds al so for signal 'Code' */
virtual
Controller
e
[(inp)]
[(outp)]
CE
[unlock,
lock]
[(inp)]
Panel
[(outp)]
Asynch
comm.
MSC
SDL
Door
[isOpen,
isCl osed]
d
[unlock,
lock]
[isOpen,
isClosed]
[(validity)]
P1
[opened,
[code]
D
closed]
P
D
apc:
U
Controller
[(vali dity)]
[open,
close]
CU
[(vali dity)]
[Code]
C
[Code]
Finite
State
Machine
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 17
Basic MSC in a nutshell
msc diagram
msc User_accepted
User
msc heading
condition
Idle
output event
Code
input event
AC System
OK
Card out
Door unlocked
IN-RTIMe Fall 2000 / Slide 18
instance
message to
the environment
(gate)
Unlock
instance end
Øystein Haugen, Ericsson NorARC, Ifi UiO
MSC references
msc AutoDoor
MSC reference
User
AC System
AutDoor
Idle
Unlock
User_Accepted
opened door
Door open
actual gate
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 19
msc User_rejected
MSC document
msc User_accepted
User
User
AC System
Idle
AC System
Code
Idle
Card out
NOK
Code
OK
Card out
Idle
Unlock
Door unlocked
msc Unlocked_unclosed
User
AC System
msc Unlocked_reset
User
msc Unlocked_timeout
AC System
AC System
door
Door unlocked
Push door
Door unlocked
Door unlocked
Push door
User
Opened
door
door
Opened
Closed
Lock
Lock
Idle
IN-RTIMe Fall 2000 / Slide 20
Idle
door
Error
Alarm
Idle
Øystein Haugen, Ericsson NorARC, Ifi UiO
High-level MSC
HMSC start
msc ACsystemOverview
loop
Idle
MSC reference
User accepted
User rejected
restrictive condition
Door unlocked
Unlocked_reset
Unlocked_timeout
Unlocked_unclosed
alternative
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 21
Inline Expressions
msc Unlocked_Idle
User
AC System
expression frame
Door unlocked
operator
door
alt
door
Lock
Push door
Opened
operand separator
door
alt
nested expression
Closed
Error
door
Lock
door
Alarm
Idle
IN-RTIMe Fall 2000 / Slide 22
Øystein Haugen, Ericsson NorARC, Ifi UiO
Concluding MSC
lMSC is simple, but expressive - intuitive, but formal
lMSC gives you ways to achieve overview:
– HMSC for overviewing large specifications
– Inline expressions for overviewing small variations
lMSC gives you ways to combine MSCs:
– MSC references
– MSC gates
– MSC reference expressions
lMSC gives you generalization mechanisms:
– MSC gates
– Substitution of MSCs, message names, and instance names
IN-RTIMe Fall 2000 / Slide 23
Øystein Haugen, Ericsson NorARC, Ifi UiO
SDL
lSDL is an object-oriented language
lSDL is complete, yet abstract
– SDL is “closed” ie. reasoning needs no extra information about the
actual implementation
lCommunication structure
lBehavior specification
lData and action language
lObject orientation
IN-RTIMe Fall 2000 / Slide 24
Øystein Haugen, Ericsson NorARC, Ifi UiO
SDL communication structure (processes)
SIGNAL opened,closed ; /* Door -> Controller */
SIGNAL open, close ; /* Controller -> Door */
/* signal lists (inp), (out) and (validity) defined in
enclosing block. This holds al so for signal 'Code' */
process type
signalroute
virtual
single process
e
declarations
1(1)
block type AccessPoint
Controller
[(inp)]
[(outp)]
CE
[unlock,
lock]
[(inp)]
Panel
Door
[(outp)]
process set
P1
[isOpen,
isCl osed]
d
[unlock,
lock]
[isOpen,
isClosed]
[(validity)]
[opened,
[code]
D
closed]
P
D
apc:
U
Controller
[(vali dity)]
[open,
close]
CU
[(vali dity)]
[Code]
C
[Code]
gate
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 25
SDL communication structure (blocks)
use of
packages
use SignalLib;
block set
use
AccessPointLib/AccessPoint,BlockingAccessPoint,LoggingAccessPoint ;
SYSTEM AccessControl
1(1)
[(val idity)]
CE
e
CF
[(outp)]
C
AccessPoint
e
[(inp)] bap(20):
C
lap(20):
e
[(inp)]
Logging
AccessPoint
[(val idi ty),
Enable,
Disable]
C
single block
[Code]
CentralUnit
CB
Blocking
AccessPoint
CG
[(outp)]
IN-RTIMe Fall 2000 / Slide 26
ap(100):
[(inp)]
[(outp)]
[Code]
C
[(val idi ty)] CL
[Code]
actual gate
Øystein Haugen, Ericsson NorARC, Ifi UiO
SDL behavior and action language
1(1)
virtual process type Controller
variables
dcl cur_panel PId ; /* current panel whose Code will be validated */
dcl cid, PIN integer ; /* temporary variables for the data attri butes of 'Code' */
procedure
start
unlockDoor
state
virtual OK
/* from
Central */
Code(cid,PIN)
input
/* from Panel */
task
output
(next) state
gate
OK
to cur_panel
cur_panel :=
sender
Code(cid,PIN)
via U
to
NOK
to cur_panel
procedure
call
unlockDoor
Idle
[Code]
[(val idi ty)]
virtual NOK
/* from
Central */
Central
Validation
P
virtual
transition
Validation
Idle
Idle
[opened,closed]
D
[open,close]
IN-RTIMe Fall 2000 / Slide 27
[(val idity)]
U
[Code]
Øystein Haugen, Ericsson NorARC, Ifi UiO
SDL is object-oriented
lTypes
– system types, block types, process types, service types,
procedures, signals, data types
– packages
lInheritance
– of structure
– of behavior
lVirtuality
– polymorphism as in Simula, C++ and Java
IN-RTIMe Fall 2000 / Slide 28
Øystein Haugen, Ericsson NorARC, Ifi UiO
Concluding SDL
l
l
l
l
l
l
l
l
l
Suitability. SDL is well suited for describing reactive systems involving
asynchronous signal exchange;
History. SDL has been used in a number of successful projects, esp. in
telecom;
Tools. There is adequate tool support for SDL and there are more than one
vendor;
Precision. SDL is a formal language. The formal definition is given in MetaIV (a
variant of VDM). This implies that the SDL description can be used for
•• understanding the system independently of the implementation;
•• communication between professionals in different organisations;
•• analysis and simulation;
•• derivation of implementation;
Standard. SDL is internationally standardised by ITU in Z.100;
Graphics. SDL is a graphical language (and a textual language);
Object orientation. SDL has full object orientation with inheritance and
virtuality;
Competence. There is sufficient SDL competence available;
Implementability. Using SDL supported by automatic code generation implies a
shift in development paradigm from being implementation oriented to design
oriented.
IN-RTIMe Fall 2000 / Slide 29
Øystein Haugen, Ericsson NorARC, Ifi UiO
How important are languages?
lNot very important
– “Syntactic sugar”
lVery important
– “Understanding through describing”
IN-RTIMe Fall 2000 / Slide 30
Øystein Haugen, Ericsson NorARC, Ifi UiO
TIMe
lAuthors
–
–
–
–
–
–
–
Rolv Bræk
SINTEF
Øystein Haugen
Ericsson (NR)
Geir Melby
Ericsson (SISU manager)
Birger Møller-Pedersen
Ericsson (NR)
Richard Sanders SINTEF
Tor Stålhane
SINTEF
+ others
SINTEF
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 31
Feature summary
lSupports design oriented development
lA step towards property oriented development
lFully object oriented and model based using
UML, SDL and MSC
lStrategies and guidelines for how to make models
lEmphasis on flexibility, reuse and quality by construction
lHypertext book available on CD-ROM
5. Property oriented
3. Design oriented
1. Implementation oriented
IN-RTIMe Fall 2000 / Slide 32
Øystein Haugen, Ericsson NorARC, Ifi UiO
TIMe at a glance
Problem domain
Domain Model
Domain concepts,
problems,
ideas
Specification
UML,
UML,MSC
MSC
Application design
Framework design
Architecture design
Product needs
Product family
UML,
UML,MSC
MSC
SDL,
SDL,MSC,
MSC,UML
UML
UML,
UML,......
Implementation
Instance needs
Market
needs
needs
C++,
C++,Java,
Java,......
System instance
instance
configuration
needs
needs
User satisfaction
system
IN-RTIMe Fall 2000 / Slide 33
Øystein Haugen, Ericsson NorARC, Ifi UiO
TIMe is a methodology
lMethodology: A collection of methods and guidelines for
when to use them.
lMethod: guidelines and rules for activities and descriptions
in given languages or notations.
lNotations:
– Unified Modeling Language (UML)
lLanguages:
– ITU-T Specification and Description Language (SDL)
– Message Sequence Charts (MSC)
IN-RTIMe Fall 2000 / Slide 34
Øystein Haugen, Ericsson NorARC, Ifi UiO
Activities and descriptions
Analysing
Analysing Domain
Domain Descriptions
Object
Models
Dictionary
Property
Models
Statement
System family descriptions
Analysing requirements
Specifications
Dictionary
Design
Design Models
Statement
Designing Application
Designing Framework
Object
Models
Property
Models
Auxiliary
Designing Architecture
Implementing
Implementation
IN-RTIMe Fall 2000 / Slide 35
Øystein Haugen, Ericsson NorARC, Ifi UiO
TIMe from SISU (1/3)
lTIMe is a result of the SISU Projects
– Improved productivity and quality of systems development for
Norwegian companies within the real-time domain.
IN-RTIMe Fall 2000 / Slide 36
Øystein Haugen, Ericsson NorARC, Ifi UiO
TIMe from SISU (2/3)
lSISU I (87-92):
– Engineering Real Time Systems (book)
lSISU II (93-96):
–
–
–
–
–
Methods and languages for making systems
Verification and Validation
Configuration Control
Process Quality
Integrated Methodology - Electronic Textbook
IN-RTIMe Fall 2000 / Slide 37
Øystein Haugen, Ericsson NorARC, Ifi UiO
TIMe from SISU (3/3)
l Participants:
– Alcatel, Ericsson, Siemens, Tandberg Data, Garex, Norsonic, Norapp,
Seem Audio, Stentofon, TrioVing,
– Telox, CAP Gemini, K.G. Knutsen,
– SINTEF, NR (Norwegian Computing Center), IFE
IN-RTIMe Fall 2000 / Slide 38
Øystein Haugen, Ericsson NorARC, Ifi UiO
Having used TIMe
lUse on many real products like:
–
–
–
–
–
PCMCIA GSM Adapter; Ericsson
13 GB data streamer; Tandberg Storage
Weapon terminal; Siemens for Swedish defence
Multi Role Radio; Alcatel and NFT-Ericsson
Alphacom (Intercom); Stentofon
IN-RTIMe Fall 2000 / Slide 39
Øystein Haugen, Ericsson NorARC, Ifi UiO
What is gained?
lGoals
– Modeling at higher level of abstraction
– Computer-aided analysis
– Some support for program generation
lCompanies report (from SISU project):
–
–
–
–
–
–
–
Fewer errors
Reduction in development effort
Better control over the development process
Less person dependent, more flexible staffing
Cooperation smoother
Methodology introduction: a serious business
Investment needed
IN-RTIMe Fall 2000 / Slide 40
Øystein Haugen, Ericsson NorARC, Ifi UiO
Verification and Validation
lBarry Boehm, 1981:
– Verification: To establish the truth of correspondence between a
software product and its specification (from the Latin veritas, “truth”).
Are we building the product right?
– Validation: To establish the fitness or worth of a software product for its
operational mission (from the Latin valere, “to be worth”).
Are we building the right product?
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 41
Development model
Requirements
Functional
requirements
Non-functional
requirements
verify
Developer
Design
Functional
design
needs
validate
Implementation
design
Developer
verify
validate
Implementation
hardware
validate
software
Owner
IN-RTIMe Fall 2000 / Slide 42
User
Øystein Haugen, Ericsson NorARC, Ifi UiO
Quality
lQuality
– process quality = meeting the specification
– system quality = playing the role required by the environment.
lQuality assurance
– Constructive methods that aim to generate the right results in the first
place
– Corrective methods that aim to detect errors and make corrections.
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe Fall 2000 / Slide 43
Practitioners’Verification of SDL systems
Mn-metric
SDLextensions
Confluent
design
Conditional
reduction
Real problems
(one case study)
Pseudo-practical
RPC-Memory Spec. Probl.
General Mn-proc.
with piecewise ex.
Basic
Mn-procedure
SDL
IN-RTIMe Fall 2000 / Slide 44
used
for
interesting theoretical
Alternating Bit Prot.
Toy examples
Reactive systems
Øystein Haugen, Ericsson NorARC, Ifi UiO