2. Contents
Introduction
Motivation for the use of formal methods
Applications of formal methods
Formal methods in CITADEL
Role of the formal methods
Modeling of dynamic architectures
● Parametrized architecture
● Dynamic parametrized architecture
● Specification of monitors
● Specification of properties
Verification of architectural configurations
Verification of information flows
Monitor synthesis and run-time verification
Model-based adaptation
Assurance case generation
FBK Software Modeling and Verification 2
5. FBK Software Modeling and Verification 5
Formal methods
Formal methods
A collection of techniques and supporting tools
Based on formal mathematical theories
Aimed at design, specification, and verification of systems
● Software and hardware systems
● Cyber-physical and real-time systems
The formal approach to building systems
Formal specification of the system requirements, and creation of
mathematical models of the system and of the relevant aspects of
the operational environment
● Facilitate understanding of the system requirements and the
system design
● Facilitate communication inside and between engineering teams
● Enable the use of automated computational techniques in order
to rigorously analyze the system design and verify that it
satisfies the requirements
6. FBK Software Modeling and Verification 6
Formal methods – motivation
The promises of formal methods
The use of formal methods results in significant improvement of
desirable system properties often lacking in software systems:
● Absence of defects
● Correctness
● Reliability
● Robustness
The use of formal methods encourages a more rigorous and
streamlined approach to design and development of complex
systems
● With formal methods, the disciplines of software and hardware
engineering become more similar to traditional (often more
rigorous) engineering disciplines
The use of formal methods opens a promising route to design,
development and operation of more complex systems that were
hitherto prohibitively difficult to design correctly, develop
economically, and/or operate efficiently, safely and securely
8. FBK Software Modeling and Verification 8
Applications of formal methods
Formal methods have been used in a wide range of applications
Hardware
● Microprocessors
● Controllers
Software
● Safety and security critical systems
Networking
● Network devices (routers, switches)
● Network protocols
● Network security
Transportation
● Avionics systems
● Railway systems
Finance
● Smart cards
Several standards for development of safety critical systems
encourage or mandate the use of formal methods
10. Formal methods in CITADEL
Role of the formal methods
FBK Software Modeling and Verification 10
11. Formal methods are used extensively in CITADEL:
Parametrized system architecture specification
Dynamic architecture specification
Behavior specification
Safety, security and functional properties
specification
Verification of the above properties
Monitors and monitoring properties specification
Monitor synthesis
Deployment specification
System adaptation and reconfiguration
Assurance case generation
FBK Software Modeling and Verification 11
Role of the formal methods
12. A
B C
D E
Node Hardware
SK MNS
Foundational Plane
Node Hardware
Subjects
Assurance Case
FBK Software Modeling and Verification 12
Role of the formal methods
Verification
Adaptation and(re)configuration
Certification
andmore
...
13. Role of the formal methods
The central formal artifact is the system model
The CITADEL Framework uses the system model for
various purposes
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 13
14. Role of the formal methods
The model is specified during system design and
can be used with various analysis tools in order to
analyze and verify the system design
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 14
15. Role of the formal methods
The model is used to represent the application and
its adaptive reconfigurations, as well as the
platform and application deployment
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 15
16. Role of the formal methods
The monitors specified in the model are used to
automatically generate monitoring code, and to
specify alarms raised by the Monitoring Plane
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 16
17. Role of the formal methods
The model is used by the Adaptation Plane to
search for the next architectural configuration of
the system
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 17
18. Role of the formal methods
The model is used by the Configuration Plane to
synthesize the reconfiguration steps in order to
effect system reconfiguration
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 18
19. Role of the formal methods
The model is used in the run-time generation of
the assurance case by the Certification Assurance
Plane
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 19
20. Formal methods in CITADEL
Modeling of dynamic architectures
FBK Software Modeling and Verification 20
21. The CITADEL Modeling language is an extension
of AADL, a standard architecture description
language
In the following, we overview the main features
of the language, on an example model:
Static architecture modeling (AADL)
Parametrized architecture modeling
Dynamic architecture modeling
Specification of monitors
Specification of system properties
The full example model code listing can be found
in the Appendix
FBK Software Modeling and Verification 21
Modeling of dynamic architectures
22. Architecture description language
Standardized by SAE International
A hierarchical architecture can be modeled
compositionally by specifying:
component types (interfaces)
● event ports
● data ports
component implementations
● subcomponents
● connections of ports of subcomponents
● can be empty (leaf components)
Architecture Analysis & Design Language (AADL)
FBK Software Modeling and Verification 22
23. Component types in AADL
subject databaseServer
features
input: in event data port sqlRequest.Data;
output: out event data port sqlResponse.Data;
heartbeat: out event port;
end databaseServer;
subject implementation databaseServer.impl
-- This implementation is empty.
end databaseServer.impl;
Component
category
Component
type name
Port name
Port type
subject databaseServer
input heartbeat
output
FBK Software Modeling and Verification 23
24. Component implementations in AADL
system sys
-- This type is empty.
end sys;
system implementation sys.impl
subcomponents
client: subject client.impl;
server: subject applicationServer.impl;
database: subject databaseServer.impl;
connections
port server.db_output -> database.input;
port database.output -> server.db_input;
port client.output -> server.input;
port server.output -> client.input;
end sys.impl;
Port
connection
Component
implementation
name
Subcomponent
name
Subcomponent
implementation
system implementation sys.impl
server database
input
output
heartbeatdb_output
db_input
input
output
client
output
input
FBK Software Modeling and Verification 24
25. For Adaptive MILS we want to model:
dynamic sets of components
dynamic connections
additional data associated with model elements
For example:
Clients can be
added / removed
Servers can be
added / removed
Ports can be
connected /
disconnected
set of clients set of servers
database
Components can be
trusted / untrusted
FBK Software Modeling and Verification 25
Modeling dynamic architectures
26. The diagram from the previous slide represents a
network of computers, in which
there is a database that contains sensitive data,
there are servers which can connect to the database,
there are clients which connect to servers.
The number of servers and clients is arbitrary, and
more clients and servers can be added.
Servers and clients are either trusted or untrusted
to access the sensitive data which is stored in the
database.
Trusted servers and clients can be compromised,
becoming untrusted.
Example model
FBK Software Modeling and Verification 26
27. Modeling dynamic architectures
To represent the above system, we model dynamic
reconfigurations at the level of the system architecture
Addition/removal of components
Connection/disconnection of ports
Mutable data associated with components
In the example reconfiguration shown below, an untrusted
client appears in the system and connects to the bottom
server; as a result, the server is considered untrusted and is
disconnected from the database
FBK Software Modeling and Verification 27
28. CITADEL Modeling Language
Based on AADL/SLIM
SLIM (System-Level Integrated Modeling
language) is an extension of AADL
● Nominal leaf component behavior (hybrid automata)
● Error behavior (probabilistic)
CITADEL Modeling Language features:
Parametrized system architecture
Architectural reconfigurations
Component types and implementations
Component behavior
Specification of monitors
Properties associated with model elements
FBK Software Modeling and Verification 28
29. Parametrized architecture
The CITADEL modeling language allows definition of a
parametrized architecture
A parametrized architecture is a specification of system
architecture with some free parameters
Static architectures can be instantiated from the parametrized
architecture by specifying the values of the parameters
FBK Software Modeling and Verification 29
?
?
?
?
?
?
Parametrized
architecture
Instantiation
Static architecture
instance
30. Modeling language semantics
Parametrized Architecture
Parametrized Architecture +
Configuration Transition System
I. Finite set of
models III. One model
with finitely many
reconfigurations
IV. One model with
infinitely many
reconfigurations
Define a configuration
transition system on
instantiation
instantiation
II. Infinite set
of models
FBK Software Modeling and Verification 30
31. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
FBK Software Modeling and Verification 31
32. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
Parameters can be of
simple types: index, bool, int, real,
enum(id1, …, idn)
set types: set of <simple_type>
indexed set type: set indexed by
<index set> of <simple_type, set_type>
FBK Software Modeling and Verification 32
33. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
Parameters can be of
simple types: index, bool, int, real,
enum(id1, …, idn)
set types: set of <simple_type>
indexed set type: set indexed by
<index set> of <simple_type, set_type>
Value of C is a set {c1
, c2
, …, cn
}
FBK Software Modeling and Verification 33
34. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
Parameters can be of
simple types: index, bool, int, real,
enum(id1, …, idn)
set types: set of <simple_type>
indexed set type: set indexed by
<index set> of <simple_type, set_type>
Set of Boolean values
{trustedClients[c] : c in C}
Value of C is a set {c1
, c2
, …, cn
}
FBK Software Modeling and Verification 34
35. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
Parameters can be of
simple types: index, bool, int, real,
enum(id1, …, idn)
set types: set of <simple_type>
indexed set type: set indexed by
<index set> of <simple_type, set_type>
Set of Boolean values
{trustedClients[c] : c in C}
Value of C is a set {c1
, c2
, …, cn
}
First-order logical formula
over parameters
FBK Software Modeling and Verification 35
36. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
Indexed sets of
subcomponents
FBK Software Modeling and Verification 36
37. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
Specification of
multiple connections
Indexed sets of
subcomponents
FBK Software Modeling and Verification 37
38. Parametrized architecture
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
clients: set indexed by C of subject client.impl;
servers: set indexed by S of subject applicationServer.impl;
connections
port database.output -> servers[s].db_input if trustedServers[s] for s in S;
port servers[s].db_output -> database.input if trustedServers[s] for s in S;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
end sys.impl;
Specification of
multiple connections
Connection guard (first-
order logical formula
over parameters)
Indexed sets of
subcomponents
FBK Software Modeling and Verification 38
39. ?
?
?
?
?
?
Diagram of the example parametrized
architecture
FBK Software Modeling and Verification 39
Example parametrized architecture
40. Example model instance
Diagram of an instance of the example model,
instantiated from the shown assignment to parameters
FBK Software Modeling and Verification 40
41. Configuration transition system
The dynamic behavior can be specified in the form of a
configuration transition system
Configuration transition system
Is associated with a particular parametrized architecture
Represents the space of possible system reconfigurations
Specifies a (possibly infinite) set of reconfiguration steps
● A reconfiguration step is formalized as a change in the values of
parameters
FBK Software Modeling and Verification 41
42. Parametrized Architecture
Parametrized Architecture +
Configuration Transition System
I. Finite set of
models III. One model
with finitely many
reconfigurations
IV. One model with
infinitely many
reconfigurations
Define a configuration
transition system on
instantiation
instantiation
II. Infinite set
of models
FBK Software Modeling and Verification 42
Modeling language semantics
43. Configuration transition system
CTS sys_cts
architecture
a: sys.impl;
initial
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])));
transitions
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
for s in a.S;
add_trusted_server[s]: step(next(a.S) = add(a.S, {s}) and
next(a.trustedServers[s]) = true)
for s not in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c}) and
next(a.connectedTo[c]) = s and
next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
end sys_cts;
FBK Software Modeling and Verification 43
44. Configuration transition system
CTS sys_cts
architecture
a: sys.impl;
initial
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])));
transitions
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
for s in a.S;
add_trusted_server[s]: step(next(a.S) = add(a.S, {s}) and
next(a.trustedServers[s]) = true)
for s not in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c}) and
next(a.connectedTo[c]) = s and
next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
end sys_cts;
Referenced parametrized
architecture, with a label
FBK Software Modeling and Verification 44
45. Configuration transition system
CTS sys_cts
architecture
a: sys.impl;
initial
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])));
transitions
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
for s in a.S;
add_trusted_server[s]: step(next(a.S) = add(a.S, {s}) and
next(a.trustedServers[s]) = true)
for s not in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c}) and
next(a.connectedTo[c]) = s and
next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
end sys_cts;
Referenced parametrized
architecture, with a label First-order logical formula
over parameters, defining
the set of initial architectures
FBK Software Modeling and Verification 45
46. Configuration transition system
CTS sys_cts
architecture
a: sys.impl;
initial
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])));
transitions
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
for s in a.S;
add_trusted_server[s]: step(next(a.S) = add(a.S, {s}) and
next(a.trustedServers[s]) = true)
for s not in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c}) and
next(a.connectedTo[c]) = s and
next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
end sys_cts;
Transition label
FBK Software Modeling and Verification 46
47. Configuration transition system
CTS sys_cts
architecture
a: sys.impl;
initial
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])));
transitions
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
for s in a.S;
add_trusted_server[s]: step(next(a.S) = add(a.S, {s}) and
next(a.trustedServers[s]) = true)
for s not in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c}) and
next(a.connectedTo[c]) = s and
next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
end sys_cts;
Specification
of multiple
transitions
Transition label
FBK Software Modeling and Verification 47
48. Configuration transition system
CTS sys_cts
architecture
a: sys.impl;
initial
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])));
transitions
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
for s in a.S;
add_trusted_server[s]: step(next(a.S) = add(a.S, {s}) and
next(a.trustedServers[s]) = true)
for s not in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c}) and
next(a.connectedTo[c]) = s and
next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
end sys_cts;
Formula specifying the transition
step (functional dependency,
implicitly includes frame condition)
Specification
of multiple
transitions
Transition label
FBK Software Modeling and Verification 48
49. Configuration transition system
CTS sys_cts
architecture
a: sys.impl;
initial
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])));
transitions
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
for s in a.S;
add_trusted_server[s]: step(next(a.S) = add(a.S, {s}) and
next(a.trustedServers[s]) = true)
for s not in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c}) and
next(a.connectedTo[c]) = s and
next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
end sys_cts;
Formula specifying the transition
step (functional dependency,
implicitly includes frame condition)
Specification
of multiple
transitions
Transition label
First-order formula over
parameters specifying the
transition guard
FBK Software Modeling and Verification 49
50. Monitor specification
system clientMonitor
parameters
client_id: index;
features
client_out: in event data port message.Data;
malicious_client: out event data port index {
Alarm => true;
MonitoringProperty => "never Malicious(last_data(client_out))";
AlarmArguments => "client_id";
};
properties
FDIR => true;
end clientMonitor;
system implementation clientMonitor.impl
end clientMonitor.impl;
FBK Software Modeling and Verification 50
A monitor is specified as an FDIR (Fault Detection,
Isolation and Recovery) component with an alarm port
51. Monitor specification
system clientMonitor
parameters
client_id: index;
features
client_out: in event data port message.Data;
malicious_client: out event data port index {
Alarm => true;
MonitoringProperty => "never Malicious(last_data(client_out))";
AlarmArguments => "client_id";
};
properties
FDIR => true;
end clientMonitor;
system implementation clientMonitor.impl
end clientMonitor.impl;
FBK Software Modeling and Verification 51
A monitor is specified as an FDIR (Fault Detection,
Isolation and Recovery) component with an alarm port
The monitor is an
FDIR component.
52. Monitor specification
system clientMonitor
parameters
client_id: index;
features
client_out: in event data port message.Data;
malicious_client: out event data port index {
Alarm => true;
MonitoringProperty => "never Malicious(last_data(client_out))";
AlarmArguments => "client_id";
};
properties
FDIR => true;
end clientMonitor;
system implementation clientMonitor.impl
end clientMonitor.impl;
FBK Software Modeling and Verification 52
A monitor is specified as an FDIR (Fault Detection,
Isolation and Recovery) component with an alarm port
The monitor is an
FDIR component.
It usually has input
port(s) connected
to virtual sensors.
53. Monitor specification
system clientMonitor
parameters
client_id: index;
features
client_out: in event data port message.Data;
malicious_client: out event data port index {
Alarm => true;
MonitoringProperty => "never Malicious(last_data(client_out))";
AlarmArguments => "client_id";
};
properties
FDIR => true;
end clientMonitor;
system implementation clientMonitor.impl
end clientMonitor.impl;
FBK Software Modeling and Verification 53
A monitor is specified as an FDIR (Fault Detection,
Isolation and Recovery) component with an alarm port
The monitor is an
FDIR component.
It usually has input
port(s) connected
to virtual sensors.
It has one or more alarm
ports. Alarm port name
malicious_client is used
as the name of the
generated alarm.
54. Monitor specification
system clientMonitor
parameters
client_id: index;
features
client_out: in event data port message.Data;
malicious_client: out event data port index {
Alarm => true;
MonitoringProperty => "never Malicious(last_data(client_out))";
AlarmArguments => "client_id";
};
properties
FDIR => true;
end clientMonitor;
system implementation clientMonitor.impl
end clientMonitor.impl;
FBK Software Modeling and Verification 54
A monitor is specified as an FDIR (Fault Detection,
Isolation and Recovery) component with an alarm port
The monitor is an
FDIR component.
It usually has input
port(s) connected
to virtual sensors.
It has one or more alarm
ports. Alarm port name
malicious_client is used
as the name of the
generated alarm.
This monitoring property
states that the received
data never indicates
malicious behavior.
55. Monitor specification
system clientMonitor
parameters
client_id: index;
features
client_out: in event data port message.Data;
malicious_client: out event data port index {
Alarm => true;
MonitoringProperty => "never Malicious(last_data(client_out))";
AlarmArguments => "client_id";
};
properties
FDIR => true;
end clientMonitor;
system implementation clientMonitor.impl
end clientMonitor.impl;
FBK Software Modeling and Verification 55
A monitor is specified as an FDIR (Fault Detection,
Isolation and Recovery) component with an alarm port
The monitor is an
FDIR component.
It usually has input
port(s) connected
to virtual sensors.
It has one or more alarm
ports. Alarm port name
malicious_client is used
as the name of the
generated alarm.
This monitoring property
states that the received
data never indicates
malicious behavior.
Additional data can be sent
with the alarm; in this case
the client identifier is sent.
56. Specification of properties
FBK Software Modeling and Verification 56
subject databaseServer
features
input: in event data port sqlRequest.Data;
output: out event data port sqlResponse.Data;
heartbeat: out event port;
properties
Contracts => ([
Name => "always_responds";
Assumption => "true";
Guarantee => "always (input implies in the future output)";
]);
end databaseServer;
subject implementation databaseServer.impl
-- Component behavior can be defined here.
end databaseServer.impl;
Properties can be specified in various ways. Here we show
an example property specified in the form of a contract on
the component behavior.
57. Specification of properties
FBK Software Modeling and Verification 57
subject databaseServer
features
input: in event data port sqlRequest.Data;
output: out event data port sqlResponse.Data;
heartbeat: out event port;
properties
Contracts => ([
Name => "always_responds";
Assumption => "true";
Guarantee => "always (input implies in the future output)";
]);
end databaseServer;
subject implementation databaseServer.impl
-- Component behavior can be defined here.
end databaseServer.impl;
Properties can be specified in various ways. Here we show
an example property specified in the form of a contract on
the component behavior.
The contracts can
be specified in the
block properties.
58. Specification of properties
FBK Software Modeling and Verification 58
subject databaseServer
features
input: in event data port sqlRequest.Data;
output: out event data port sqlResponse.Data;
heartbeat: out event port;
properties
Contracts => ([
Name => "always_responds";
Assumption => "true";
Guarantee => "always (input implies in the future output)";
]);
end databaseServer;
subject implementation databaseServer.impl
-- Component behavior can be defined here.
end databaseServer.impl;
Properties can be specified in various ways. Here we show
an example property specified in the form of a contract on
the component behavior.
The contracts can
be specified in the
block properties.
Contract name.
59. Specification of properties
FBK Software Modeling and Verification 59
subject databaseServer
features
input: in event data port sqlRequest.Data;
output: out event data port sqlResponse.Data;
heartbeat: out event port;
properties
Contracts => ([
Name => "always_responds";
Assumption => "true";
Guarantee => "always (input implies in the future output)";
]);
end databaseServer;
subject implementation databaseServer.impl
-- Component behavior can be defined here.
end databaseServer.impl;
Properties can be specified in various ways. Here we show
an example property specified in the form of a contract on
the component behavior.
The contracts can
be specified in the
block properties.
Contract name.
This contract does not define any
assumptions on the environment.
60. Specification of properties
FBK Software Modeling and Verification 60
subject databaseServer
features
input: in event data port sqlRequest.Data;
output: out event data port sqlResponse.Data;
heartbeat: out event port;
properties
Contracts => ([
Name => "always_responds";
Assumption => "true";
Guarantee => "always (input implies in the future output)";
]);
end databaseServer;
subject implementation databaseServer.impl
-- Component behavior can be defined here.
end databaseServer.impl;
Properties can be specified in various ways. Here we show
an example property specified in the form of a contract on
the component behavior.
The contracts can
be specified in the
block properties.
Contract name.
This contract does not define any
assumptions on the environment.
The property which should hold if
the assumptions are satisfied; in
this case the request should
always be followed by a response.
61. Formal methods in CITADEL
FBK Software Modeling and Verification 61
Verification of architectural
configurations
62. The architectural configurations, which are obtained from a
parametrized architecture by instantiation, can be analyzed in
numerous ways by the COMPASS toolset:
Model simulation (guided, randomized or by forcing signals)
Deadlock checking checks the presence of possible deadlocks
Model checking checks the model against one or more properties
Timing analyses (Zeno analysis, time divergence analysis)
Contract based analyses
● Monolithic and compositional contract verification
● Contract refinement validation
Depending on the modeled features, additional safety and
dependability analyses are supported:
Failure modes and effects analysis (FMEA)
Fault tree generation
Fault tolerance evaluation, based on a generated set of fault trees
Fault detection, isolation and recovery (FDIR)-based analyses
Verification of architectural configurations
FBK Software Modeling and Verification 62
63. For example, the following analyses are possible for the
previously specified contract for databaseServer:
If the behavior of the databaseServer is specified in terms of
hybrid automata (either directly in databaseServer or in its
leaf subcomponents), contract verification can be used to
check that the behavior satisfies the property stated in the
contract
If the decomposition into subcomponents of databaseServer
is specified, and the subcomponents are themselves
annotated with contracts, contract refinement validation can
be used to check that the decomposition and the
subcomponents’ contracts together entail the top-level
contract on the databaseServer
Similarly, if the databaseServer is embedded in a system
with a specified contract, the contract refinement validation
can be used on the parent system component
Verification of architectural configurations
FBK Software Modeling and Verification 63
64. Formal methods in CITADEL
Verification of information flows
FBK Software Modeling and Verification 64
65. Information flows in classic MILS
The classic MILS approach relies on strictly controlled
information flows in order to enable compositional
assurance of systems
A B
DC
Static MILS policy architecture
The problem: Decide whether information can flow from
a source component to a destination component
In classic MILS, the architecture is static and it is easy
to verify information flow properties, such as “there is
no information flow from component A to component D”
FBK Software Modeling and Verification 65
66. Information flows in Adaptive MILS
In adaptive MILS, verifying information flow is more
difficult, due to
Dynamic connections
Addition and removal of components
Potentially infinite number of architectural
reconfigurations
A B
DC
Information can flow from A to D across
architectural reconfigurations
A B
DC
FBK Software Modeling and Verification 66
67. Approach
Consider a fragment of the CITADEL modeling language
● No architecture hierarchy
● No component behavior
● Some restrictions on formulas in PA and CTS
Encode the model and the information flow property
using the theory of array, for model checker MCMT
Information flow verification
Dynamic
architecture
Add tokens
Dynamic architecture with
modeled information flows
Encode
array C bool;
array S bool;
…
array C_token bool;
array S_token bool;
initial …
transitions …
unsafe …
Array-based
transition system
FBK Software Modeling and Verification 67
68. The required property for the example model is that there is
no leak of data from the database to the untrusted clients.
Verification of the model without the highlighted parts (see
Appendix) produces the following counterexample, showing
that the model without the highlighted parts is unsafe:
● 1) the data flows from the database to a server while it is
trusted,
● 2) a reconfiguration happens making the server untrusted,
● 3) the data flows to an untrusted client.
Verification proves that the model with the highlighted parts
(see Appendix) included is safe.
● Highlighted parts introduce two phases (represented by the
Boolean parameter “protected”): connections to the database are
allowed only in the protected mode, while reconfigurations
downgrading the servers to untrusted status are allowed only in
the unprotected mode.
Example model verification
FBK Software Modeling and Verification 68
69. Formal methods in CITADEL
FBK Software Modeling and Verification 69
Monitor synthesis and run-time
verification
70. Monitor synthesis and run-time verification
BK-aware
Runtime
Monitor
Monitored
System
Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel
FBK Software Modeling and Verification 70
Monitors are synthesized at design time from the monitors
specified in the system model. At runtime the monitors generate
alarms which trigger adaptive system reconfiguration.
71. Monitor synthesis and run-time verification
BK-aware
Runtime
Monitor
Monitored
System
Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel
FBK Software Modeling and Verification 71
The core monitoring code of
the synthesized monitors is
generated based on the
monitoring property which is
specified in the system model.
Monitors are synthesized at design time from the monitors
specified in the system model. At runtime the monitors generate
alarms which trigger adaptive system reconfiguration.
72. Monitor synthesis and run-time verification
BK-aware
Runtime
Monitor
Monitored
System
Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel
FBK Software Modeling and Verification 72
The synthesized monitors
can be made more efficient
by taking into account
background knowledge (BK)
about the behavior of the
monitored system.
Monitors are synthesized at design time from the monitors
specified in the system model. At runtime the monitors generate
alarms which trigger adaptive system reconfiguration.
73. Monitor synthesis and run-time verification
BK-aware
Runtime
Monitor
Monitored
System
Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel
FBK Software Modeling and Verification 73
At runtime, the monitors are
instantiated/removed along
with the added/removed
monitored components.
Monitors are synthesized at design time from the monitors
specified in the system model. At runtime the monitors generate
alarms which trigger adaptive system reconfiguration.
74. Formal methods in CITADEL
Model-based adaptation
FBK Software Modeling and Verification 74
75. Model-based adaptation
As mentioned before, the system model is used in the
run-time adaptation of the application. We briefly
outline the main steps involved in the adaptation.
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 75
76. Model-based adaptation
As the application is running (in some architectural
configuration), the virtual sensors are sending data
to the Monitoring Plane.
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 76
Monitored data
77. Model-based adaptation
Some time later, the Monitoring Plane generates an alarm,
for example “malicious_client(1)”, signifying that suspicious
behavior by the client with identifier 1 has been detected.
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 77
ALARM malicious_client(1)
78. Model-based adaptation
The Adaptation Plane, based on the system model, the current
architectural configuration, and a reconfiguration strategy,
generates the model of the next architectural configuration.
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 78
Model of the next
architectural configuration.
79. Model-based adaptation
The Configuration Plane effects the reconfiguration
of the system by invoking platform primitives, also
instantiating and/or removing monitors as needed.
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 79
Reconfiguration commands
80. Formal methods in CITADEL
Assurance case generation
FBK Software Modeling and Verification 80
81. Assurance case generation
FBK Software Modeling and Verification 81
Patterns
Repository
Evidence
Repository
AM-ETB
Core Workflow
Assurance
Case
Assurance
Case
Pattern
System
Models
System
Properties
AM-ETB
Tool Agent
External
Tool
Error
Log
When the system is adaptively reconfigured, the assurance case for the
next architectural configuration of the system is automatically generated
by the Adaptive-MILS Evidential Tool Bus (AM-ETB).
AM-ETB takes as input a parametrized assurance case pattern which
defines the assurance case structure, instantiates it based on the model of
the current architectural configuration, and re-constructs the evidence
used in the assurance case by invoking tool agents that serve as an
interface to external verification tools.
83. The example model represents a network of
computers, in which
there is a database that contains sensitive data,
there are servers which can connect to the database,
there are clients which connect to servers.
The number of servers and clients is arbitrary, and
more clients and servers can be added.
Servers and clients are either trusted or untrusted
to access the sensitive data which is stored in the
database.
Trusted servers and clients can be compromised,
becoming untrusted.
Example model
FBK Software Modeling and Verification 83
84. Example model parametrized architecture
?
?
?
?
?
?
Diagram of the example model parametrized architecture
monitors are not shown
FBK Software Modeling and Verification 84
85. Example model instance
Diagram of an instance of the example model,
instantiated from the shown assignment to parameters
monitors are not shown
FBK Software Modeling and Verification 85
86. Example model listing (1/8)
package networkExampleModel
data sqlRequest
end sqlRequest;
data implementation sqlRequest.Data
end sqlRequest.Data;
data sqlResponse
end sqlResponse;
data implementation sqlResponse.Data
end sqlResponse.Data;
data message
end message;
data implementation message.Data
end message.Data;
FBK Software Modeling and Verification 86
87. Example model listing (2/8)
subject databaseServer
features
input: in event data port sqlRequest.Data;
output: out event data port sqlResponse.Data;
heartbeat: out event port;
end databaseServer;
subject implementation databaseServer.impl
end databaseServer.impl;
system heartbeatMonitor
features
heartbeat_in: in event port;
database_failed: out event port {
Alarm => true;
MonitoringProperty =>
"always (time_until(heartbeat_in) msec < HeartbeatTimeout)";
};
properties
FDIR => true;
end heartbeatMonitor;
FBK Software Modeling and Verification 87
88. Example model listing (3/8)
system implementation heartbeatMonitor.impl
end heartbeatMonitor.impl;
subject applicationServer
features
db_input: in event data port sqlResponse.Data;
db_output: out event data port sqlRequest.Data;
input: in event data port message.Data;
output: out event data port message.Data;
end applicationServer;
subject implementation applicationServer.impl
end applicationServer.impl;
subject client
features
input: in event data port message.Data;
output: out event data port message.Data;
end client;
FBK Software Modeling and Verification 88
89. Example model listing (4/8)
subject implementation client.impl
end client.impl;
system clientMonitor
parameters
client_id: index;
features
client_out: in event data port message.Data;
malicious_client: out event data port index {
Alarm => true;
MonitoringProperty => "never Malicious(last_data(client_out))";
AlarmArguments => "client_id";
};
properties
FDIR => true;
end clientMonitor;
system implementation clientMonitor.impl
end clientMonitor.impl;
FBK Software Modeling and Verification 89
90. Example model listing (5/8)
system sys
end sys;
system implementation sys.impl
parameters
C: set of index;
S: set of index;
trustedClients: set indexed by C of bool;
trustedServers: set indexed by S of bool;
connectedTo: set indexed by C of index;
protected: bool;
assumptions
size(S) > 0;
subcomponents
database: subject databaseServer.impl;
database_monitor: system heartbeatMonitor.impl;
servers: set indexed by S of subject applicationServer.impl;
clients: set indexed by C of subject client.impl;
client_monitors: set indexed by C of system clientMonitor.impl
where forall(c in C, client_monitors[c].client_id = c);
FBK Software Modeling and Verification 90
91. Example model listing (6/8)
connections
port database.output -> servers[s].db_input if protected and trustedServers[s]
for s in S;
port servers[s].db_output -> database.input if protected and trustedServers[s]
for s in S;
port database.heartbeat -> database_monitor.heartbeat_in;
port servers[s].output -> clients[c].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> servers[s].input if s = connectedTo[c] for s in S, c in C;
port clients[c].output -> client_monitors[c].client_out for c in C;
end sys.impl;
CTS sys_cts
architecture
a: sys.impl;
initial
not a.protected and
forall(c in a.C, forall (s in a.S, (not a.trustedClients[c] and s = a.connectedTo[c])
implies (not a.trustedServers[s])))
and forall(c in a.C, forall (s not in a.S, s != a.connectedTo[c]));
FBK Software Modeling and Verification 91
92. Example model listing (7/8)
transitions
protect: step(next(a.protected) = true);
add_trusted_server[s]: step(next(a.S) = add(a.S, {s})
and next(a.trustedServers[s]) = true)
for s not in a.S;
make_server_untrusted[s]: step(next(a.trustedServers[s]) = false)
when (not a.protected)
for s in a.S;
add_untrusted_client[c][s]: step(next(a.C) = add(a.C, {c})
and next(a.connectedTo[c]) = s
and next(a.trustedClients[c]) = false)
when (not a.trustedServers[s])
for c not in a.C, s in a.S;
add_trusted_client[c][s]: step(next(a.C) = add(a.C, {c})
and next(a.connectedTo[c]) = s
and next(a.trustedClients[c]) = true)
when (a.trustedServers[s])
for c not in a.C, s in a.S;
FBK Software Modeling and Verification 92
93. Example model listing (8/8)
make_client_untrusted[c][s]: step(next(a.trustedClients[c]) = false
and next(a.trustedServers[s]) = false)
when (a.trustedClients[c]
and s = a.connectedTo[c]
and not a.protected)
for c in C, s in S;
end sys_cts;
properties
Constants => "Malicious: function message.Data -> bool;
HeartbeatTimeout: clock msec := 10 msec;";
end networkExampleModel;
FBK Software Modeling and Verification 93