Software Process
TDDB47 Real Time Systems
Lecture 5: Design & implementation issues in
RT Systems
Calin Curescu
Real-Time Systems Laboratory
Department of Computer and Information Science
Linköping University, Sweden
•
•
•
•
•
•
Requirements specification
Planning
Architectural design
Implementation
Testing
Maintenance
•
Additional important activities:
– Prototyping prior final implementation
– Design of human-computer interface
– Criteria for assessing implementation languages
– … many more
The lecture notes are partly based on lecture notes by Simin Nadjm-Tehrani, Jörgen Hansson, Anders Törne.
They also loosely follow Burns’ and Welling book “Real-Time Systems and Programming Languages”. These
lecture notes should only be used for internal teaching purposes at Linköping University.
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
33 pages
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Levels of Notation
•
•
•
Informal
• E.g., natural language and various forms of imprecise diagrams
+ easy to understand
- many possible interpretations
Structured
• Graphical representation common
• Well defined
+ rigorous, structured
- not analyzable
Formal
• Precise due to mathematical basis
+ Analyzable
- Not easy to understand for people with no training
- Not structured enough (flat)
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Requirements Specification
•
•
Informal description
Extensive analysis of requirements
•
•
Defines system functionality
Explicit descriptions of
– (i) Temporal behavior
• e.g., maximum rate of interrupts
– (ii) Reliability
– (iii) Failure model (desired behavior)
• e.g., failure modes
Specify software acceptance tests
•
3 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Requirements Specification cont’d
•
Explicitly describes the functionality of the product and any
constraints it must satisfy
•
Problems
– Contradictory and ambiguous specifications
• Can be avoided by structured and formal notations
• Incomplete specifications
•
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
5 of 33
4 of 33
Notation of Requirements
•
Analysis phase of requirements specification
– Natural language is still the normal notation for this
phase
•
E.g. ADA specification
– Committee to pass judgment on what the standard
actually means (capture the semantics)
– Compiler writers forwarded thousand of queries to
committee
•
E.g. occam
– Formally specified (denotation semantics)
– ”No method will compensate for the requirements the customer
forgot to mention”
• Rapid prototyping can be of help
Testing
– Traceability of requirements, reviewing of requirements
2 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
6 of 33
Planning
•
Project planning
– Duration
– Cost
• Assign personnel
• Other resources
– Scope
Design principles
cost
duration
•
•
Specification says ”what” the product should do.
Design says ”how”
•
Decomposition
– Divide and Conquer
– At each level – appropriate level of description
Abstraction
– Consideration of details - postponed
– Still contains essential properties and features
scope
•
•
A good specification
– is a good foundation for accurate planning.
– Hence, detailed planning cannot and should not be done
before specification is finalized.
•
Overestimating vs. underestimating
•
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Keep track of design decisions
– Helps when it is needed to go back for redesigning
– Enhances maintainability
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
7 of 33
Design: Encapsulation
•
Decomposition is compositional if specification of the entire
software system can be verified by verifying the
specification of sub-components alone. (formal analysis)
•
•
Modules, classes, objects
Process abstraction
– Needed in concurrent environments
Component oriented-programming
Cohesion
•
poor
•
•
•
•
•
Cohesion and coupling
– Metrics for good encapsulation
– Cohesion: internal strength - GOOD
– Coupling: external strength - BAD
•
•
strong
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
9 of 33
Conincidental
– Elements (in the module) are only linked superficially, e.g.,
written in the same month
Logical
– Elements are related in terms of the overall system (not
software), e.g, all device drivers
Temporal
– Elements are executed at similar times, e.g., start-up routines
Procedural
– Elements are used together, e.g., user-interface components
Communicational
– Elements work on the same data, e.g., input data
Functional
– Elements work together to contribute to the overall system
functionality and its performance
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Coupling
•
Coupling is a measure of interdependence of program
modules
•
Tight coupling
– Exchange of control information between modules
Loose coupling
– Exchange of data (only) between modules
•
•
Valid for both sequential and concurrent programming
domains
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
11 of 33
8 of 33
10 of 33
Formal approaches
•
Avoid/remove (design) faults that lead to obvious bad things
– Properties
• Safety – “something bad will not happen”
• Liveness – “something good will happen”
•
Analyse behaviour in presence of selected combinations of
potential external faults
•
Temporal logic
– Augmented propositional/predicate logic
– Operators: always, sometimes, until, since, leads to
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
12 of 33
Model checker
Model: Petri nets
•
Answer:
Model:
Model
design requirements
checker
Yes: model satisfies
specification
•
No: counterexample
•
Specification:
•
System property
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
13 of 33
Place/transition or petri nets
– Simple, abstract, graphical
– Concurrent distributed systems
Elements
– Place
– Transitions
– Arcs
– Tokens
A transition can fire if there are tokens in every input place.
– When it fires, it consumes the tokens from its input places,
performs some processing task, and places a specified number
of tokens into each of its output places.
Very large and unwieldy representations
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
14 of 33
Petri net example
•
Petri net example
•
Timed petri net
free space
produce
Timed automata
•
Finite state machine (FSM)
– State
• Stores info about the past
– Transition
• Between states, condition that needs to be fulfilled
– Action
• Entry action, exit action, transaction action
•
Timed automata
– Clock constraints
attached to transitions
consume
number in buffer
P2
P1
transition
inputs
min
max
T1
P1 , P2
0
P1+200
T2
P3 , P4
P3+10
∞
T2
T1
P4
P3
[Alur,Dill,1994]
Examples from http://icebear.cmsa.wmin.ac.uk/~alison/embedded/lecture5.html
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
15 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
State space
•
State space search
– To check that a model M satisfies specification S, we
must check that no possible state in M contradicts S.
– Consider a model M with n Boolean state variables. This
leads to a potential state space of 2n.
– With 55 variables, at 1 GHz, it would take (in the worst
case) over 1 million years to visit every state!
16 of 33
Advanced techniques
•
Smart data structures for efficient representation of state space
•
Smart deduction engines (satisfiability checkers) that find proofs
fast
•
Smart abstractions of the design to capture the essential
properties
– Synchronous languages
• Assumes the system knows the relative order of signals, with
the fact they are simultaneous, or not.
– Exact duration not important
• Deterministic
• Can be can be used to generate complex state machines
automatically
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
17 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
18 of 33
Synchronous languages
•
Synchronises system behaviour with signals
– E.g. the clock signal
•
Assumes the system knows the relative order of signals,
with the fact they are simultaneous, or not
– Exact duration not important
– Computations are instant
Thus models the system as deterministic
Can be can be used to generate complex state machines
automatically
•
•
•
Examples: Esterel, Lustre, Signal
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
19 of 33
Design methods
•
Burns & Wellings identify:
– Structure system in concurrent tasks
– Support the development of reusable components
trough information hiding
– Defining behaviour aspects using finite-state machines
– Analyse the performance of a design to determine its
real-time properties
•
In traditional software development however timing issues
are first recognised in the test phase
•
Design methods – see examples in the book
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Implementation
•
Programming language bridging link between top-level
requirements and the executing machine code.
•
Assembly language
•
Sequential programming languages
– E.g., Jovial, Coral 66, RTL/2, C, C++
•
High-level concurrent programming languages
– Concurrency, encapsulation
– E.g., Modula, Modula-2, PEARL, Mesa, CHILL, Ada, Java
•
Real-time facilities
– Real-time Java
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
21 of 33
Real-time Java
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
General Lang. Design Criteria
•
Security
•
Readability
•
Flexibility
•
Simplicity
•
Portability
•
Efficiency
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
20 of 33
22 of 33
Security
•
Automatic detection of programming errors by compiler or
language run-time support system
+ early detection of errors
• cuts development costs
+ reduction of run-time overheads
(compile-time checking)
- complicated language
- compilation time increases
- compiler complexity increases
23 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
24 of 33
Readability
•
”... language should give sufficient
clarity.... reading program should
be enough, without resorting to
other documentation, to
understand what happens”
Flexibility
•
Allow programmer to express required operations in
straightforward manner and a coherent fashion
+ Avoid low-level operating system commands.
Expressive power!
+ reduced documentation costs
+ increased security
+increased maintainability
- increases length of program
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
25 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Simplicity
+ minimizes the effort required to produce compilers
+ reduces costs of programming training
+ non-ambiguous interpretation of language features
26 of 33
Portability
•
Hardware independence
– hard to achieve
•
Languages should isolate machine dependent parts from
machine independent parts.
Usability!
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
27 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
Efficiency
28 of 33
Testing/Integration
•
Avoidance of mechanisms that cause unpredictable runtime overheads
•
Testing must be extremely stringent (due to safetycriticalness)
•
Balanced against security, flexibility, and readability
requirements
•
Concurrency often result in subtle interactions
•
Testing is complementary to formal design methods
•
Not restricted to final systems
– Test system components
•
Dependable behaviour in arbitrarily incorrect environments
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
29 of 33
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
30 of 33
Testing: Simulators
•
•
•
•
•
•
•
•
Substitute for non-safe real-world experiments (e.g., nuclear
reactor meltdown)
Generation of abnormal and infrequent behavior
May enable better testing
Environment may be too complicated to build appropriate
simulator
Reproducibility of tests
Tests can be repeated
Are real-time systems themselves
Simulators are very costly, sometimes more costly than the
real-time software itself.
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
31 of 33
Reading
-
Chapter 2 of Burns & Wellings
-
Book chapter by Shumate et al., sections 5.1-5.4 for (a
design overview).
-
Short coverage of the synchronous languages in Burns &
Wellings chapter 12 (12.7.5)
-
Extra reading: Article by Halwbachs et. al. 1992 for those
who want to know more about modelling with synchronous
languages
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
33 of 33
Human Computer Interaction (HCI)
•
Pilot's computer error: the captain of an AA jet that crashed
in Colombia Dec 96, entered incorrect one-letter computer
command Æ killed 159!
•
Who is in control?
– Human user
– Computer system
– Mixed initiative
•
What is the best way to collaborate?
Lecture 5: Design & implementation issues in RT Systems
Calin Curescu
32 of 33