Embedded Systems

Lec_06

Analysis and Verification

 Objectives
• Identifying Various forms of methods for
specifying desired and undesired behaviors
• Verifying that an implementation conforms
to its specification

2
 Analysis and verification
 Invariants and Temporal Logic
 Equivalence and Refinements
 Reachability Analysis and Model Checking
 Quantitative Analysis
 Security and Privacy

3
 Invariants and Temporal Logic
 Every embedded system must be designed to meet
certain requirements
 Such system requirements are also called
properties or specifications

 “A design without specifications cannot be right

or wrong, it can only be surprising!”
paraphrased from Young et al. (1985)

4
 Invariants and Temporal Logic
 It is important to precisely state requirements to
avoid ambiguities inherent in natural Languages
 Such system requirements are also called
properties or specifications
 It is important to specify system properties
mathematically and precisely
 A mathematical specification of system properties
is also known as a formal specification

5
 Invariants and Temporal Logic
 Temporal Logic: as an example, one form of
mathematical formalism
 Temporal logic is a precise mathematical notation
with associated rules for representing and
reasoning about timing-related properties of
systems

6
 Invariants
 An invariant is a property that holds for a system
if it remains true at all times during operation of
the system
 Put another way, an invariant holds for a system if
it is true in the initial state of the system, and it
remains true as the system evolves, after every
reaction, in every state

7
 Equivalence and Refinements
 Comparing state machines and other modal
models, such as trace equivalence, trace
containment, simulation, and bisimulation

8
 Equivalence and Refinements
 Models as Specifications
– An alternative way to give requirements is to provide a
model, a specification, that exhibits expected behavior
of the system
– Typically, the specification is quite abstract, and it may
exhibit more behaviors than a useful implementation of
the system would
– But the key to being a useful specification is that it
explicitly excludes undesired or dangerous behaviors

9
 Equivalence and Refinements
 Models as Specifications
– This enables an engineering design process where we
start with abstract descriptions of desired and undesired
behaviors, and successively refine our models until we
have something that is detailed enough to provide a
complete implementation

10
 Equivalence and Refinements
 Type Equivalence and Refinement
– We begin with a simple relationship between two
models that compares only the data types of their
communication with their environment
– The goal is to ensure that a model B can be used in any
environment where a model A can be used without
causing any conflicts about data types
– We will require that B can accept any inputs that A can
accept from the environment, and that any environment
that can accept any output A can produce can also
accept any output that B can produce
11
 Equivalence and Refinements
 Type Equivalence and Refinement

12
 Equivalence and Refinements
 Language Equivalence and Containment
– To replace a machine A with a machine B, looking at
the data types of the inputs and outputs alone is usually
not enough
– The language L(M) of a state machine M is the set of
all behaviors for that state machine
– Two machines are said to be language equivalent if
they have the same language

13
 Quantitative Analysis
 A quantitative property of an embedded system is
any property that can be measured
 This includes physical parameters, such as
position or velocity of a vehicle controlled by the
embedded system, weight of the system, operating
temperature, power consumption, or reaction time
 Properties of software-controlled systems, with
particular attention to execution time

14
 Quantitative Analysis
 Problems of Interest
– Extreme- Case Analysis
– Threshold Analysis
– Average-Case Analysis

15
 Quantitative Analysis
 Programs as Graphs

16
 Quantitative Analysis
 Factors Determining Execution Time
– There are several issues one must consider in order to
estimate the worst-case execution time of a program

– Loop Bounds
– Exponential Path Space
» Execution time is a path property. In other words, the amount of time taken by the
program is a function of how conditional statements in the program evaluate to true or
false A major source of complexity in execution time analysis is that the number of
program paths can be very large—exponential in the size of the program

– Path Feasibility
– Memory Hierarchy
17
 Quantitative Analysis
 Other Quantitative Analysis Problems
– Memory Bound Analysis
» Embedded computing platforms have very limited
memory as compared to general-purpose computers
» Stack-Size Analysis
» Heap Analysis
– Power and Energy Analysis
» Power and energy consumption are increasingly
important factors in embedded system design

18
 Security and Privacy
 Cryptographic Primitives
– “Crypt” and “Graphia”
– the study of secret writing
 Protocol and Network Security
 Software Security
 Information Flow

19
 Security and Privacy
 Summary

20
Course Summary

21