Software Modeling and Verification

Software Modeling and
Verification
FBK Software Modeling and Verification 1

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

Introduction

Introduction
Motivation for the use of formal
methods

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

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

Introduction
Applications of formal methods

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

Formal methods in CITADEL

Role of the formal methods

 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

A
B C
D E

Node Hardware
SK  MNS
Foundational Plane
Node Hardware
Subjects
Assurance Case
Verification
Adaptation and(re)configuration
Certification
andmore
...

 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

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane

Modeling of dynamic architectures

 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
Modeling of dynamic architectures

 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)

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
input heartbeat
output

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
server database
input
output
heartbeatdb_output
db_input
input
output
client
output
input

 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
Modeling dynamic architectures

 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

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

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

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
?
?
?
?
?
?
Parametrized
architecture
Instantiation
Static architecture
instance

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

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
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
C: set of index;
S: set of index;
assumptions
size(S) > 0;
subcomponents
connections
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>

parameters
C: set of index;
S: set of index;
assumptions
size(S) > 0;
subcomponents
connections
end sys.impl;
enum(id1, …, idn)
Value of C is a set {c1
, c2
, …, cn
}

parameters
C: set of index;
S: set of index;
assumptions
size(S) > 0;
subcomponents
connections
end sys.impl;
enum(id1, …, idn)
Set of Boolean values
{trustedClients[c] : c in C}
, c2
, …, cn
}

parameters
C: set of index;
S: set of index;
assumptions
size(S) > 0;
subcomponents
connections
end sys.impl;
enum(id1, …, idn)
Set of Boolean values
{trustedClients[c] : c in C}
, c2
, …, cn
}
First-order logical formula
over parameters

parameters
C: set of index;
S: set of index;
assumptions
size(S) > 0;
subcomponents
connections
end sys.impl;
Indexed sets of
subcomponents

parameters
C: set of index;
S: set of index;
assumptions
size(S) > 0;
subcomponents
connections
end sys.impl;
Specification of
multiple connections
Indexed sets of
subcomponents

parameters
C: set of index;
S: set of index;
assumptions
size(S) > 0;
subcomponents
connections
end sys.impl;
Specification of
multiple connections
Connection guard (first-
order logical formula
over parameters)
Indexed sets of
subcomponents

?
?
?
?
?
?
 Diagram of the example parametrized
architecture
Example parametrized architecture

Example model instance
 Diagram of an instance of the example model,
instantiated from the shown assignment to parameters

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

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
Modeling language semantics

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;

CTS sys_cts
architecture
a: sys.impl;
initial
transitions
for s in a.S;
for s not in a.S;
end sys_cts;
Referenced parametrized
architecture, with a label

CTS sys_cts
architecture
a: sys.impl;
initial
transitions
for s in a.S;
for s not in a.S;
end sys_cts;
Referenced parametrized
architecture, with a label First-order logical formula
over parameters, defining
the set of initial architectures

CTS sys_cts
architecture
a: sys.impl;
initial
transitions
for s in a.S;
for s not in a.S;
end sys_cts;
Transition label

CTS sys_cts
architecture
a: sys.impl;
initial
transitions
for s in a.S;
for s not in a.S;
end sys_cts;
Specification
of multiple
transitions
Transition label

CTS sys_cts
architecture
a: sys.impl;
initial
transitions
for s in a.S;
for s not in a.S;
end sys_cts;
Formula specifying the transition
step (functional dependency,
implicitly includes frame condition)
Specification
of multiple
transitions
Transition label

CTS sys_cts
architecture
a: sys.impl;
initial
transitions
for s in a.S;
for s not 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

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;
 A monitor is specified as an FDIR (Fault Detection,
Isolation and Recovery) component with an alarm port

parameters
client_id: index;
features
Alarm => true;
};
properties
FDIR => true;
end clientMonitor;
The monitor is an
FDIR component.

parameters
client_id: index;
features
Alarm => true;
};
properties
FDIR => true;
end clientMonitor;
The monitor is an
FDIR component.
It usually has input
port(s) connected
to virtual sensors.

parameters
client_id: index;
features
Alarm => true;
};
properties
FDIR => true;
end clientMonitor;
The monitor is an
FDIR component.
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.

parameters
client_id: index;
features
Alarm => true;
};
properties
FDIR => true;
end clientMonitor;
The monitor is an
FDIR component.
port(s) connected
to virtual sensors.
as the name of the
generated alarm.
This monitoring property
states that the received
data never indicates
malicious behavior.

parameters
client_id: index;
features
Alarm => true;
};
properties
FDIR => true;
end clientMonitor;
The monitor is an
FDIR component.
port(s) connected
to virtual sensors.
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.

Specification of properties
features
properties
Contracts => ([
Name => "always_responds";
Assumption => "true";
Guarantee => "always (input implies in the future output)";
]);
end databaseServer;
-- Component behavior can be defined here.
 Properties can be specified in various ways. Here we show
an example property specified in the form of a contract on
the component behavior.

features
properties
Contracts => ([
]);
end databaseServer;
The contracts can
be specified in the
block properties.

features
properties
Contracts => ([
]);
end databaseServer;
The contracts can
be specified in the
block properties.
Contract name.

features
properties
Contracts => ([
]);
end databaseServer;
The contracts can
be specified in the
block properties.
Contract name.
This contract does not define any
assumptions on the environment.

features
properties
Contracts => ([
]);
end databaseServer;
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.

Verification of architectural
configurations

 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

 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

Verification of information flows

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”

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

 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

 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

Monitor synthesis and run-time
verification

Monitor synthesis and run-time verification
BK-aware
Runtime
Monitor
Monitored
System

Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel

 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.

BK-aware
Runtime
Monitor
Monitored
System

Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel

The core monitoring code of
the synthesized monitors is
generated based on the
monitoring property which is
specified in the system model.

BK-aware
Runtime
Monitor
Monitored
System

Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel

The synthesized monitors
can be made more efficient
by taking into account
background knowledge (BK)
about the behavior of the
monitored system.

BK-aware
Runtime
Monitor
Monitored
System

Adaptation
RUN
TIME
DESIGN
TIME SynthesisModel

At runtime, the monitors are
instantiated/removed along
with the added/removed
monitored components.

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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
Monitored data

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
ALARM malicious_client(1)

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
Model of the next
architectural configuration.

 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
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
Reconfiguration commands

Assurance case generation

Assurance case generation
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.

Appendix
Example model

 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

Example model parametrized architecture
?
?
?
?
?
?
 Diagram of the example model parametrized architecture
 monitors are not shown

Example model instance
 Diagram of an instance of the example model,
instantiated from the shown assignment to parameters
 monitors are not shown

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;

features
end databaseServer;
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;

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;

subject implementation client.impl
end client.impl;
parameters
client_id: index;
features
Alarm => true;
};
properties
FDIR => true;
end clientMonitor;

system sys
end sys;
parameters
C: set of index;
S: set of index;
protected: bool;
assumptions
size(S) > 0;
subcomponents
database_monitor: system heartbeatMonitor.impl;
client_monitors: set indexed by C of system clientMonitor.impl
where forall(c in C, client_monitors[c].client_id = c);

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 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
implies (not a.trustedServers[s])))
and forall(c in a.C, forall (s not in a.S, s != a.connectedTo[c]));

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;
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)
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])

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;

End

Software Modeling and Verification

More Related Content

What's hot

Similar to Software Modeling and Verification

Recently uploaded

Software Modeling and Verification