scispace - formally typeset
Search or ask a question
ReportDOI

ACTIVE: A Tool for Integrating Analysis Contracts

TL;DR: ACTIVE is the first extensible framework able to integrate independently-developed analysis plugins guaranteeing their correct interaction and execution, and it is shown how this framework model plugin interactions in a formal way in order to enable automatic verification.
Abstract: : In this paper we present ACTIVE, a tool and framework to semantically integrate independently-developed analysis plugins in OSATE, a tool for modeling systems in the Architecture Analysis and Design Language (AADL). In the paper we analyze the problems that occur when independently-developed analysis plugins are executed on an AADL model and how these problems can lead to invalid analysis results. We show how our framework model plugin interactions in a formal way in order to enable automatic verification. These interactions are captured in an analysis contract that describes inputs, outputs, assumptions, and guarantees. The input and outputs in the contract allow us to determine the correct order in which plugins must execute. The assumptions and guarantees, on the other hand, capture the conditions that must be valid to execute a plugin and the one that are expected to be valid afterwards. The ACTIVE framework allows the inclusion of any generic verification tool (e.g. model checkers) to verify these conditions. To coordinate all these activities uses two components: the ACTIVE EXECUTER and the ACTIVE VERIFIER. The ACTIVE EXECUTER executes the plugins in the required order calling the ACTIVE VERIFIER every time assumption and guarantees need to be verified. The ACTIVE VERIFIER, in turn identifies and executes the verification tool that needs to be invoked based on the target formula. Together, they ensure that the plugins are always executed in the correct order and under the correct conditions guaranteeing a sound verification process. To the best of our knowledge ACTIVE is the first extensible framework able to integrate independently-developed analysis plugins guaranteeing their correct interaction and execution.

Summary (3 min read)

1. Introduction

  • Development of Cyber-Physical Systems (CPS) relies on analysis tools that use their own specialized abstractions.
  • The application of this abstraction to tasks that do not honor these restrictions leads to incorrect schedulability results via RMS.
  • Virtual integration aims at addressing the issue of dependent abstractions by providing methods to resolve dependencies and conflicts among tools and models used in CPS engineering [7].
  • The authors contract verification approach relies on specification of verification domains, which are comprised of a set of symbols and their interpretation that enables us to describe analysis contracts from that domain in a precise manner.
  • ACTIVE was developed on top of the OSATE2 2 toolkit, and uses the AADL [4] architectural description language.

2. Managing Interaction of CPS Analysis Plugins

  • AADL provides a description language to capture main software and hardware structures of a CPS (e.g., threads and processors) and subsystems they belong to, along with connections between structures and subsystems.
  • This model is then transformed into an AADL instance model – an XML-based representation of the actual system, rather than component types.
  • The error model plugin [4] relies on an annex to specify error sources and propagations.
  • A plugin that modifies the thread-to-processor allocation might invalidate the result of any prior schedulability plugin applied to the affected threads and processors.
  • The authors identify three parts of this problem: (i) describing plugin interactions with enough detail to not only capture real conflicts but also avoid signaling false ones; (ii) executing plugins in a right sequence and at a right time; and (iii) verifying applicability assumptions of analysis plugins.

2.1 Representing Plugin Interactions

  • In order to enable reasoning about plugin interactions, the authors must model these interactions by representing data flows between the plugins and the AADL models.
  • Several implementations of schedulability tests rely on ratemonotonic assumptions without stating them explicitly.
  • It could also be satisfied with other scheduling policies under certain specific system configurations.
  • One of the biggest challenges to represent plugin interactions come from the extensibility requirement.
  • This is because the AADL semantics allows different plugins to have slightly different interpretations of the properties.

2.2 Correct Plugin Execution

  • To ensure the correct execution of a plugin it is necessary to respect its data dependencies and ensure that its assumptions are never violated as different plugins are executed.
  • Since OSATE discourages plugin interaction, it is challenging to invoke plugins programmatically.
  • The limited feedback mechanisms in OSATE were also designed with a human user in mind, making it difficult to monitor analysis execution and determine the time when it is safe to start the next analysis.
  • In particular, it is important to leave the option open to run plugins without the proper integration in cases when specifications have not been completed, or they do not hold.

2.3 Extensible Assumption Verification

  • An analysis plugin integration tool needs to use state-ofthe-art verifiers to ensure that analyses are only used when they are known to produce correct results.
  • Since the analysis plugin integration problem manifests itself in multiple domains that contribute to CPS, verifiers need to be tailored to domain-specific abstractions and applied in their corresponding contexts.
  • Finally, the computational subsystem is part of the whole system, which also includes physical devices (such as rotors) and properties (such as mass).
  • Tools for timed automata verification, such as UPPAAL [5], use the refinement relation rather than an arbitrary composition.
  • Roughly corresponding to the parts of this problem, the three following sections present the main components of their tool ACTIVE.

3. Contract Language as AADL Annex

  • The location of the information that defines the interaction between analysis plugins is critical to the extensibility of their platform.
  • Reusing the same contracts across different models.
  • M. Existence of a verification domain, with a semantics defined within a verification tool that automatically explores its behavior, guarantees correctness of their analysis contracts approach.
  • Static functions S map directly to AADL’s properties, some of which are standard and some of which are defined by users in a declarative model.
  • Finally, the execution semantics T is defined by a combination of static function specified by the model (e.g., thread periods and deadlines) and verifier-specific runtime behavior (e.g., how the state of system changes when a new thread arrives).

4. ACTIVE EXECUTER

  • Ensuring that a set of analysis plugins is executed correctly requires more than the specification and verification of individual analysis contracts.
  • This section describes ACTIVE EXECUTER– a plugin execution controller in their tool.
  • Edges in this graph represent input-output dependences between two contracts.
  • Here the authors say that an analysis plugin depends on another if the former reads a property or a component set that the latter modifies.
  • The analyses in the sequence are then executed one by one, exchanging their data through the instance model.

5. ACTIVE VERIFIER

  • The verification of analysis assumptions is the most complex aspect of ACTIVE since it requires the combination 3 wiki.eclipse.org/Platform_Command_Framework of abstractions coming from diverse scientific fields into a common logic.
  • The first subformula, including <Quan>, <Var>, and <PredicateExpression>, can be processed with a general-purpose SMT solver: as the authors showed in Section 3, all atoms and operators of <PredicateExpression> are determined from the AADL models, thus rendering quantified <PredicateExpression> amenable to an efficient validity check.
  • Typically this matching is somewhat known to en- 4.
  • Each verifier is augmented with a verification engine that governs the application and execution of the verifier through the following functions: Verifier’s initialization and parameter selection.
  • This way, all components and properties are easily accessible to verifiers without the need to traverse levels of hierarchy in AADL.

6. Conclusion

  • A tool addressing the problem of AADL analysis plugin interactions.the authors.
  • In particular, the authors discussed how analysis plugin integration errors pose a risk of invalidating analysis results without user’s knowledge.
  • Solving this problem entails, first of all, representing analysis interactions in a formal way to enable automatic reasoning.
  • Finally, the assumptions and guarantees need to be verified using a potentially wide variety of verification tools.
  • These major ACTIVE components were designed to be extensible to accommodate new verification domains, analysis plugins, and domain-specific verifiers.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

ACTIVE: A Tool for Integrating Analysis Contracts
Ivan Ruchkin
1
Dionisio De Niz
2
Sagar Chaki
2
David Garlan
1
1
Institute for Software Research, Carnegie Mellon University, USA, {iruchkin,garlan}@cs.cmu.edu
2
Software Engineering Institute, Carnegie Mellon University, USA, {dionisio,chaki}@sei.cmu.edu
Abstract
Development of modern Cyber-Physical Systems (CPS) re-
lies on a number of analysis tools to verify critical prop-
erties. The Architecture Analysis and Design Language
(AADL) standard provides a common architectural model
to which multiple CPS analyses can be applied. Unfortu-
nately, interaction between these analyses can invalidate
their results. In this paper we present ACTIVE, a tool de-
veloped within the OSATE/AADL infrastructure to en-
sure correct analysis interaction. We describe the prob-
lems that occur when multiple analyses are applied to an
AADL model and how these problems invalidate analysis
results. Interactions between analyses, implemented as OS-
ATE plugins, are formally described in A CTIVE in order to
enable automatic verification. In particular, these interac-
tions are captured in an analysis contract consisting of in-
puts, outputs, assumptions, and guarantees. The inputs and
outputs help determine the correct order of execution of
the plugins. Assumptions capture the conditions that must
be valid in order to execute an analysis plugin, while guar-
antees are conditions that are expected to be valid after-
wards. ACTIVE allows the use of any generic verification
tool (e.g., a model checker) to validate these conditions. To
coordinate these activities our tool uses two components:
ACTIVE EXECUTER and ACTIVE VERIFIER. ACTIVE EX-
ECUTER invokes the analysis plugins in the required or-
der and uses ACTIVE VERIFIER to check assumptions and
guarantees. ACTIVE VERIFIER identifies and executes the
verification tool that needs to be invoked based on the tar-
get formula. Together, they ensure that plugins are always
executed in the correct order and under the correct con-
ditions, guaranteeing correct results. To the best of our
knowledge, ACTIVE is the first extensible framework that
integrates independently-developed analysis plugins ensur-
ing provably-correct interactions.
Keywords analysis contracts, cyber-physical systems,
model checking, virtual integration
The 5th Analytic Virtual Integration of Cyber-Physical Systems Workshop
December 2, 2014, Rome, Italy.
Copyright is held by the author/owner(s). The proceedings are published by
Linköping University Electronic Press.
AVICPS website:
http://www.analyticintegration.org/
1. Introduction
Development of Cyber-Physical Systems (CPS) relies on
analysis tools that use their own specialized abstractions.
These abstractions, however, interact with each other. Ne-
glecting these interactions leads to incorrect analysis re-
sults and design choices. For instance, selecting an other-
wise valid scheduling policy may violate the assumptions
of a functional correctness analysis (e.g., model checking)
and lead to a deadlock-prone system being declared safe.
Alternatively, such a scheduling policy could violate the
assumptions of a processor frequency scaling analysis and
lead to a non-schedulable allocation of tasks. Similarly,
modifying a controller algorithm may alter its execution
time and periodicity, thereby affecting schedulability [3].
Verification tools are particularly sensitive to their un-
derlying domain abstractions, and incorrect application of
these abstractions leads to invalid results. For instance,
the original schedulability equations for Rate-Monotonic
Scheduling (RMS) [6] use task abstractions that both re-
strict these tasks to be independent of one another and to
forbid them to pause their computation. The application of
this abstraction to tasks that do not honor these restrictions
leads to incorrect schedulability results via RMS.
Vir tual integration aims at addressing the issue of de-
pendent abstractions by providing methods to resolve de-
pendencies and conflicts among tools and models used in
CPS engineering [7]. In our recent work we developed an
approach for virtual integration based on the specification
and verification of contracts between analysis tools [8].
Our approach allows us to describe and verify the interac-
tions between analyses from different scientific domains.
Our contract verification approach relies on specifica-
tion of verification domains, which are comprised of a
set of symbols and their interpretation that enables us to
describe analysis contracts from that domain in a pre-
cise manner. Examples of verification domains include the
scheduling and battery domains, which are concerned with
analyses of properties of real-time threads (e.g., schedula-
bility) and batteries (e.g., thermal runaway), respectively.
Formally, a verification domain is a signature to a mixed-
logic language in which dependencies, assumptions, and
guarantees of each analysis, that belongs to this domain,
are specified as a contract. These contracts are algorithmi-
cally evaluated against a system architecture to verify if the
system satisfies the assumptions of the analyses, and if the
contracts of the analyses are compatible with one another.

Previously, we focused [8] on the theoretical founda-
tions of the analysis contract approach. However, a num-
ber of significant practical issues were not addressed. For
instance, the initialization and execution of CPS analysis
and verification tools have many peculiarities. For exam-
ple, many user-facing tools cannot be easily incorporated
into a bigger toolchain. At the same time, specifications of
verification domains and contracts must be reused to avoid
unnecessary duplication, and, on the other hand, need to
be adjusted correctly to each model’s context. The missing
part is a virtual integration platform to manage tool inter-
actions. One key requirement for such a platform is exten-
sibility: adding new tools and verification domains should
be simple so that analysis integration is practical.
In this paper, we present our tool ACTIVE
1
(
Analysis
Contract Integration Verifier), which implements the anal-
ysis integration approach. ACTIVE was developed on top
of the OSATE2
2
toolkit, and uses the AADL [4] archi-
tectural description language. AADL offers a convenient
way t o represent the structural aspects of the system that
determine critical quality attributes in real-time systems.
Moreover, AADL provides an annex mechanism to embed
custom sublanguages in its models. We use an AADL an-
nex to define a mixed specification language that includes
first-order logic and Linear Temporal Logic (LTL) [9] to
describe both static and dynamic properties of the system.
This allows us to use state-of-the-art verifiers that target
different parts of the specification.
Given that our goal is to develop an extensible platform
for virtual integration of CPS analyses, we incorporate sev-
eral analysis tools (e.g., a bin packing algorithm for thread-
to-processor allocation) and contract verifiers (like SMT
and Spin) into ACTIVE. To handle tool integration, A CTIVE
includes (i) a language to describe analysis contracts, (ii)
a mechanism to execute analyses i n the correct order, and
(iii) a contract verification engine to verify if the analysis
contracts hold. All three parts are extensible with new ver-
ification domains (e.g., controller simulation) and types of
verification (e.g., probabilistic model checking).
The rest of the paper is organized as follows. In Section
2 we break down and discuss the management of analysis
tool interactions on the example of AADL analysis plugins.
Section 3 focuses on the representation of analysis i nterac-
tions in ACTIVE, while Section 4 and 5 demonstrate our
solutions to behavioral challenges of using multiple analy-
sis and verification tools. Section 6 concludes this paper.
2. Managing Interaction of CPS Analysis
Plugins
AADL provides a description language to capture main
software and hardware structures of a CPS (e.g., threads
and processors) and subsystems they belong to, along with
connections between structures and subsystems. Compo-
nents are annotated with properties from various scientific
domains. Examples of such properties include thread pe-
riod, processor frequency, and scheduling policy (all from
1
Can be downloaded at https://github.com/bisc/active
2
https://wiki.sei.cmu.edu/aadl/index.php/Osate_2
the real-time scheduling domain), and battery dimensions,
cell scheduling algorithm, and required battery voltage
(from the battery domain). A system designer defines com-
ponent types along with their subcomponents, interconnec-
tions, and properties to create the AADL declarative model
of a system. This model is then transformed into an AADL
instance model an XML-based representation of the ac-
tual system, rather than component types.
In OSATE, analysis algorithms are implemented as plu-
gins that have access to both the declarative and the in-
stance AADL models. AADL allows designers to augment
these models with tool-specific descriptions known as an-
nexes that define sublanguages embedded in AADL de-
scriptions. For example, the error model plugin [4] relies
on an annex to specify error sources and propagations. It
reads components and properties from the instance model
and error annex specifications from the declarative model
to produce, for example, a fault impact report.
While OSATE supports rapid development of analysis
plugins, it does not support controlling undesirable inter-
actions between different plugins in order to prevent incor-
rect results. In particular, OSATE provides extension points
to add annexes (via sub-language grammars and compil-
ers) and analysis invocation actions (via toolbar buttons or
menu items). Once a plugin is invoked, it is given access to
AADL models to carry out the desired operations and re-
turn the control back to the user. Each analysis plugin thus
tends to focus on a specific technical concern, accessing
components, properties, and annex clauses relevant to that
concern, but ignoring t he effects of other plugins.
The lack of support to capture and control the effects
that plugins have on each other can lead to incorrect results.
For instance, a plugin that modifies the thread-to-processor
allocation might invalidate the result of any prior schedula-
bility plugin applied to the affected threads and processors.
Similarly, if a plugin depends on the scheduling policy of
a processor (say Rate-Monotonic Scheduling) and another
plugin modifies this policy (to, say, Earliest-Deadline First)
the results could be invalidated. Worst of all, more often
than not, these errors go unnoticed given the lack of an
infrastructure to capture and verify these subtle plugin in-
teractions. Unfortunately, OSATE currently lacks ways to
manage the co-operative execution of analyses, let alone
verify their assumptions formally.
To address the issue of CPS analysis interaction system-
atically, an integration tool needs to manage analysis plu-
gins at the level of the abstractions that these analyses use.
We identify three parts of this problem: (i) describing plu-
gin interactions with enough detail to not only capture real
conflicts but also avoid signaling false ones; (ii) executing
plugins in a right sequence and at a right time; and (iii)
verifying applicability assumptions of analysis plugins. All
three parts need to be addressed in an extensible way so as
to not lose the benefits of the flexible OSATE design. We
go deeper into each part of the problem below.
2.1 Representing Plugin Interactions
In order to enable reasoning about plugin interactions, we
must model these interactions by representing data flows

between the plugins and the AADL models. In other words,
we must identify the parts of the model that different plu-
gins change. This dataflow description would allow us to
prevent the incorrect order of plugin execution where the
output from one plugin is invalidated by the output from
another plugin executed afterwards.
Also, we must represent the assumptions a plugin
makes about the model under analysis. For example, sev-
eral implementations of schedulability tests rely on rate-
monotonic assumptions without stating them explicitly.
More importantly, plugin assumptions may be related to the
system behavior rather than its structure. Thus predicates
over only the structural models in AADL are inadequate
for expressing such assumptions. For example, one plugin
may assume that a task may only be preempted by others
with shorter deadline than its own. This assumption is triv-
ially satisfied if we used Deadline Monotonic Scheduling.
However, it could also be satisfied with other scheduling
policies under certain specific system configurations. This
can only be discovered with enough information about the
behavior of the system with the different policies.
Finally, the way an analysis is identified in a specifica-
tion must reflect the operations performed by the analysis
on a model precisely. Many plugins come with several re-
lated operations; for example, a resource allocation plugin
provides three operations: allocation of threads to proces-
sors (what we further call bin packing), a utilization-based
schedulability test, and a priority inversion test. Just men-
tioning the name of the resource allocation plugin does not
differentiate the operations properly.
One of the biggest challenges to represent plugin inter-
actions come from the extensibility requirement. First of
all, we must be able to change the plugin interaction spec-
ification independently from the plugin implementation.
This is because the AADL semantics allows different plu-
gins to have slightly different interpretations of the prop-
erties. For instance, we have seen AADL models where
threads are assumed to be periodic by default while other
models explicitly require the use of the Periodic value
in the Dispatch_Protocol property, and yet others
use the Hybrid value for the same property.
Another important aspect of the extensibility is the sup-
port of new domains that may introduce new types of com-
ponents, properties, or even behavioral specification con-
structs. For example, to introduce analyses for multi-cell
reconfigurable batteries, one would have to introduce a new
device type, with new AADL properties (such as battery
cell number and geometry), and runtime properties to cap-
ture dynamic cell connectivity. These changes must affect
only AADL models, and not the plugin integration tool.
2.2 Correct Plugin Execution
To ensure the correct execution of a plugin it is necessary
to respect its data dependencies and ensure that its assump-
tions are never violated as different plugins are executed.
In practice, a correct plugin execution implies the follow-
ing steps: (i) before the plugin is called we need to ensure
that all the other plugins have finished their work and com-
mitted their changes to the AADL model; (ii) the plugin
assumptions must be validated on the model on which the
plugin will be run; (iii) if an analysis plugin ends with an
error, the sequence of execution has to be stopped.
Many OSATE plugin are made with human user inter-
action in mind: they expect to be run from toolbars and
menus. Since OSATE discourages plugin interaction, it is
challenging to invoke plugins programmatically. Once a
plugin has been invoked, monitoring its progress is an-
other challenge: many plugins use tools external to OSATE,
without any feedback. The limited feedback mechanisms
in OSATE were also designed with a human user in mind,
making it difficult to monitor analysis execution and deter-
mine the time when it is safe to start the next analysis.
Like the specification, correct plugin execution needs to
be achieved with minimal changes to existing plugins and
the OSATE tool. Plugins still need to run individually on
user’s command, and major changes to their control flow
are not acceptable. OSATE cannot be profoundly modified
either. In particular, it is important to leave the option open
to run plugins without the proper integration in cases when
specifications have not been completed, or they do not hold.
2.3 Extensible Assumption Verification
An analysis plugin integration tool needs to use state-of-
the-art verifiers to ensure that analyses are only used when
they are known to produce correct results. Since the anal-
ysis plugin integration problem manifests itself in multiple
domains that contribute to CPS, verifiers need to be tai-
lored to domain-specific abstractions and applied in their
corresponding contexts. For example, a dynamic model of
a thread scheduler cannot be used to verify assumptions
about a flight controller behavior. In addition, given the ex-
istence of specifications involving static and dynamic prop-
erties of the system it is necessary to enable the verification
of both types of properties in a scalable way.
AADL models are hierarchical: a set of threads may be
composed in a thread group, which in turn contributes to a
software subsystem. A software subsystem may be part of
a computational subsystem, which also includes processors
and memory devices. Finally, the computational subsystem
is part of the whole system, which also includes physical
devices (such as rotors) and properties (such as mass).
Choice of a hierarchy is left up to the designer, allowing
multiple ways to describe the same system.
Unfortunately, many verifiers rely on their own system
decomposition, which may not agree with AADL. Tools for
timed automata verification, such as UPPAAL [5], use the
refinement relation rather than an arbitrary composition.
Hence, our challenge is to create mechanisms that use
verifiers (some of which are unknown yet) for a custom-
built AADL model at a proper level of hierarchy. Domain-
specific verifiers, for instance, need to access their relevant
abstractions without being aware of other components.
Management of analysis plugin interactions is a major
obstacle to creating an extensible platform for virtual in-
tegration of CPS analyses. Roughly corresponding to the
parts of this problem, the three f ollowing sections present
the main components of our tool ACTIVE. We view our so-
lutions from two positions: functionality achieving their

goal correctly, and extensibility allowing addition of new
elements, such as analyses and verifiers, to the platform.
3. Contract Language as AADL Annex
The location of the information that defines the interaction
between analysis plugins is critical to the extensibility of
our platform. We evaluated three potential locations: (i) in-
side the analysis plugin itself; (ii) in the OSATE tool; or
(iii) in the AADL model. Encapsulating the specification
inside the plugin has the benefit that the description always
travels with the plugin. On the other hand, storing the spec-
ification in a central database of specifications inside the
OSATE tool facilitates collaboration and reuse of contracts.
Unfortunately, both of this options diminish extensibility
given that the exact specification of the interactions may
change depending on the project and the plugins used in it,
as discussed in Section 2.1. That is, semantic variations in
the interpretation of AADL in a particular model need to
be accounted for without changing the plugin or OSATE.
In ACTIVE we use an AADL annex (like many analy-
sis plugins do) to represent analysis dependencies and as-
sumptions. In this case, an annex instance is attached to a
declarative AADL model and can be used whenever this
model, or any derived instance model, is used. We refer
to our analysis interaction specification as an analysis con-
tract. An analysis contract has the following parts:
Name: names the analysis contract and the plugin wrap-
per to be called when an analysis is invoked (in Section
4 we explain analysis plugin wrappers in detail).
Input: a comma-separated list of elements: AADL
component types (e.g., thread) and property names
(e.g., thread.Period). The property names are pre-
fixed with a component type to identify the dependency
more precisely. By including a component type in its in-
put, an analysis plugin declares that it accesses the set
of components; and by including a property, it declares
that it reads the property values from an instance model.
If a property is included as part of the input or output,
the related component is also included implicitly.
Output: a list of same type of elements as that of the
input. The only difference is semantic: the analysis de-
clares that it changes the set of components or the val-
ues of a property. Although the specification of inputs
and outputs is in terms of AADL types, the changes are
meant to be done to the instance model.
Assumes: a set of assumptions that must hold for an
analysis to be applicable. Each assumption is a logi-
cal formula, as explained below. Given that we may not
have a complete definition of when an analysis is appli-
cable, assumptions describe at least the sufficient condi-
tions of its applicability. If an analysis is always appli-
cable, this part can be omitted.
Guarantees: a set of formulas that must hold on the
model after the analysis terminates. These formulas
are syntactically equivalent to the assumption formulas.
They can be used to satisfy the assumptions of other
contracts. In such a case, these assumptions do not need
to be reverified. However, if the guarantee are not met,
the assumptions of other contracts that depend on it
must be reverified.
Assumes and guarantees contract formulas have the fol-
lowing syntax in ACTIVE:
ContractFormula ::=
(
<Quan>
(<Var>:<Type> ’,’)+
( ’|’ <PredicateExpression> )?
’:’
)?
<LTLExpression>
Contract formulas consist of two subformulas: an op-
tional first-order quantification and a mandatory main ex-
pression, often written in LTL. In the first subformula,
<Quan> is a first-order quantifier, taking a value of ei-
ther forall or exists. <Var> introduces a quan-
tified variable name of an AADL component having
type Type. Variables are quantified over <Predicate-
Expression>, which is a logical predicate over the
AADLs model components and properties with the
usual logical operators and, or, and not. The <LTL-
Expression> encodes a domain-specific behavioral
property using a combination of logical operators above
and the LTL modalities Globally G, Eventually F, and Un-
til U. However, if necessary, <LTLExpression> can be
limited to predicate logic.
The operator : is implicative when used in a
forall formula (where it denotes that “all variable valua-
tions that satisfy condition <PredicateExpression>
should also satisfy <LTLExpression>”) and conjunc-
tive when used in a exists formula (where it de-
notes that “all variable valuations that satisfy condition
<PredicateExpression> should also satisfy <LTL-
Expression>”). We choose our mixed-logic language
over Quantified LTL [9] because the latter prevents a
cleaner split of f ormulas between general-purpose SMT
solvers and domain-specific verifiers (see details in Section
5), and brings in unnecessary complexity.
Consider an example from the scheduling domain. Fig-
ure 1 shows a contract for a processor fr equency scaling
analysis. The goal of this analysis is to minimize the pro-
cessor frequency to limit energy expenditure of the sys-
tem. It reads threads, processors, thread deadlines, and
thread bindings (allocations) to processors. It outputs the
CPU frequency. An implicit assumption of this analysis
is that threads run under the deadline monotonic schedul-
ing policy. This is captured in a formula stating that “ev-
ery pair of distinct threads allocated on the same proces-
sor should behave as if scheduled by a deadline-monotonic
policy. The first part of the formula (before the colon) in-
dicates the condition for which all possible pairs of threads
should be evaluated. The second part (after the colon) is an
LTL expression that features a domain-specific predicate
CanPreempt, which is true in any runtime state iff t1 is
executing but t2 is ready to execute, but not executing.

Figure 1: A contract for frequency scaling analysis.
Figure 2: A contract for the LLREK analysis.
Figure 3: Annex subclause indicating the analyses to use.
Another example of an analysis is verification of safe
concurrency based on the tool LLREK [1]: the tool takes
source code of each thread annotated with safety assertions
and determines whether the assertions are met. A contract
for this analysis is shown in Figure 2. The analysis reads
a number of thread properties and outputs whether the sys-
tem was found to be safe with respect to its annotated asser-
tions. LLREK has two assumptions: first, implicit deadline
tasks, i.e., tasks whose relative deadlines are equal to their
periods; second, it assumes fixed-priority scheduling, i.e.,
thread pre-emption is acyclic. In other words, if thread t1
preempts thread t2, then t2 never preempts t1. Other ex-
amples of contracts, for instance for electric and thermal
analysis of multi-cell batteries, can be found in [8].
To improve convenience and reuse of contracts, we sep-
arate the definition of contracts (as in Figures 1 and 2),
which we call a library of contracts, from the application
of these contracts to a system, which we call a usage sub-
clause (shown in Figure 3). Usage subclauses enable the
association of analyses to models. In this way a user can
control applicability of analyses at a macro-level, reusing
the same contracts across different models.
Our approach explained in [8] relies not only on the
specification of contracts (where the mapping between con-
ceptual and practical aspects is more s traightforward), but
also on verification domains that define the formal under-
pinnings for both the specification and the analysis of the
contracts within a verification tool (e.g., Spin). Formally,
a verification domain σ is comprised of domain atoms A,
static functions S, runtime functions R, execution seman-
tics T , and domain interpretation for atoms and static func-
tions [[·]]
σ
. These elements are augmented by an architec-
tural model that provides the interpretation [[·]]
M
. Existence
of a verification domain, with a semantics defined within
a verification tool that automatically explores its behavior,
guarantees correctness of our analysis contracts approach.
In ACTIVE, verification domains are not specified in one
place, but are comprised of various elements of AADL and
contract annexes. For some atoms a A, [[a]]
σ
is provided
by OSATE. For example, i ntegers, booleans, and reals are
standard types in AADL. Other elements of A are inter-
preted by the [[·]]
M
, e.g., threads, processes, memory ele-
ments, processors, systems, and other sets of components.
Static functions S map directly to AADLs properties,
some of which are standard and some of which are defined
by users in a declarative model. Only static functions can be
used in <PredicateExpression> so that the seman-
tics of <PredicateExpression> could be fully con-
structed based on the AADL instance model values. Stan-
dard types have a default value, which contributes to [[S]]
σ
.
For the most part, however, interpretation of static func-
tions comes from [[S]]
M
in the form of values that properties
have in a particular AADL instance model.
Unlike some static functions, runtime functions R are
strictly domain-specific, e.g., CanPreempt. Their inter-
pretation comes from a domain-specific verifier and, as far
as AADL models are concerned, these functions do not
exist. Finally, the execution semantics T is defined by a
combination of static function specified by the model (e.g.,
thread periods and deadlines) and verifier-specific runtime
behavior (e.g., how the state of system changes when a new
thread arrives). Thus, all formal elements of σ are covered
in ACTIVE , to which the formal conclusions of correctness
can now be transferred.
4. ACTIVE EXECUTER
Ensuring that a set of analysis plugins is executed correctly
requires more than the specification and verification of in-
dividual analysis contracts. Specifically, it requires coor-
dination and proper sequencing of the execution of these
analysis and their verifiers. This section describes ACTIVE
EXECUTER a plugin execution controller in our tool. The
purpose of this controller is, on the one hand, to interact
with the user and, on the other hand, to coordinate the ex-
ecution of analyses. The scheme of ACTIVE EXECUTER is
shown in Figure 4.
From the OSATE user’s perspective, ACTIVE EXE-
CUTER identifies dependencies between analyses, builds a
dependency graph, and presents it to the user to allow him
to select an analysis to run. When invoked on an instance

Citations
More filters
Proceedings ArticleDOI
01 Jul 2017
TL;DR: In this paper, database language is suggested as an enabling technology and a lean technique to the purpose of cyber-physical systems (CPSs) design, model checking and maintenance, and an example with best available embedded database technology is conducted by means of a deployment test on tiny embedded electronics.
Abstract: The complexity of cyber-physical systems (CPSs) poses new challenges in their design, model checking and maintenance. The hardware and software designers are in search, more than ever, for simple and interoperable approaches that render the complexity of CPSs a treatable matter. In this work, database language is suggested as an enabling technology and a lean technique to the purpose. An example with best available embedded database technology is conducted by means of a deployment test on tiny embedded electronics.

16 citations


Cites background or methods from "ACTIVE: A Tool for Integrating Anal..."

  • ...Along with the former technological context, assumeguarantee (A/G) contracts are a prominent framework for CPSs analysis, design and development [5,6]....

    [...]

  • ...Although XML can bear equivalent information content of standard relational databases, on the XML back-end there usually are database systems for data storage [6]....

    [...]

  • ...In this sense, a valuable contribution comes from formal frameworks based on the assume-guarantee concept in contracts [5,6]....

    [...]

  • ...This technique has been already formalized with the notion of contracts [5,6] and successful applications of formal methods for model checking and planning [4,18]....

    [...]

Proceedings ArticleDOI
16 Oct 2015
TL;DR: This paper uses formal specification of analysis contracts to expose security assumptions and guarantees of analyses from reliability, control, and sensor security domains and demonstrates how this approach can help discover and prevent vulnerabilities using a self-driving car example.
Abstract: Designing secure cyber-physical systems (CPS) is a particularly difficult task since security vulnerabilities stem not only from traditional cybersecurity concerns, but also physical ones. Many of the standard methods for CPS design make strong and unverified assumptions about the trustworthiness of physical devices, such as sensors. When these assumptions are violated, subtle inter-domain vulnerabilities are introduced into the system model. In this paper we use formal specification of analysis contracts to expose security assumptions and guarantees of analyses from reliability, control, and sensor security domains. We show that this specification allows us to determine where these assumptions are violated, opening the door to malicious attacks. We demonstrate how this approach can help discover and prevent vulnerabilities using a self-driving car example.

13 citations


Cites methods from "ACTIVE: A Tool for Integrating Anal..."

  • ...Specifically, we have the capacity to automatically translate deterministic contracts written using only first-order quantification over variables in bounded sets into SMT programs and verify them using the Z3 SMT solver with the existing implementation of the active tool [55]....

    [...]

  • ...The active toolset was developed to support automated analytic integration [55]....

    [...]

  • ...We execute the sequencing algorithm in the active tool [55] to determine these dependencies and sequence the analyses in a way that respects the dependencies [56]....

    [...]

Journal ArticleDOI
TL;DR: This article presents an approach to systematize and then automate the analysis of non-functional properties in Model-Based Systems Engineering using a combination of constraint languages and specification languages to solve the problem of temporal predictability of embedded systems.

11 citations


Cites methods from "ACTIVE: A Tool for Integrating Anal..."

  • ...They detail an implementation of this approach through the ACTIVE tool, dedicated to AADL, in [52]....

    [...]

  • ...Secondly, the ACTIVE tool [52] provides only behavioral verification with model checking, whereas we focus on the analysis of real-time properties using the real-time scheduling theory....

    [...]

13 Mar 2017
TL;DR: This thesis advances several important concepts regarding the integration issue and shows that an analysis is basically a program with preconditions and postconditions, which means that analysis can be integrated to any kind of model as soon as an implementation of accessors to model internals is provided.
Abstract: The development of embedded systems is a complex and critical task, especially because of the non-functional requirements. In fact, embedded systems have to fulfill a set of non-functional properties dictated by their environment, expressed for example in terms of timing, dependability, security, or other performance criteria. In safety-critical applications for instance (e.g. an airplane), missing a non-functional requirement can have severe consequences, e.g. loss of life, personal injury, equipment damage, environmental disaster, etc. Models and analyses are valuable asset to design complex embedded systems. Modeling enables to represent the system properties, whereas analysis makes it possible to evaluate them. Yet, modeling and analysis techniques have been historically investigated separately in software/systems engineering. On the one hand, ModelDriven Engineering uses domain-specific models as primary artifacts to develop a system. On the other hand, mathematically-based analysis techniques such as realtime scheduling analysis, model-checking, dependability analysis, etc. makes it possible to analyze the diverse non-functional properties of computer systems. Thus, a major contribution to improve the development of embedded systems, and the main objective of this thesis, will be to integrate models, as defined by the basic principles of Model-Driven Engineering (i.e. the triad model, metamodel, model transformation), with mathematical-funded analysis approaches to analyze the nonfunctional properties of embedded systems. This thesis aims at providing a general and coherent view on this problem by investigating two fundamental questions: • How to apply an analysis on a model? (technical issue) • How to manage the analysis process? (methodological issue) This thesis advances several important concepts regarding the integration issue. First of all, we revisit the way model transformations are done to accommodate specific analysis engines. Arguing that an analysis is less based on a particular model syntax than specific data, we promote query mechanisms called accessor to analyze the non-functional properties of a system at design time. These accessors enable to extract data from a model and then analyze them. Expected benefit is that analysis can be integrated to any kind of model as soon as an implementation of accessors to model internals is provided. Next, we aim at formalizing the analysis execution. We show that an analysis is basically a program with preconditions and postconditions. The preconditions are the properties to hold true on an input model to successfully execute the analysis. Postconditions are the properties guaranteed on the model after the analysis execution. With preconditions and postconditions, an analysis is complete and sound.

5 citations


Cites background or methods from "ACTIVE: A Tool for Integrating Anal..."

  • ...[182, 183, 184] that study a problem close to ours....

    [...]

  • ...[183] where the authors define contracts through an AADL annex language)....

    [...]

  • ...[182] define the contracts in terms of the AADL type system (AADL property sets, AADL components such as threads and processors) through a sub-language annex; the ACTIVE tool presented in [183] is developed within the OSATE/AADL infrastructure; analyses as part of OSATE relies on more usual ad hoc model transformations....

    [...]

  • ...They detail an implementation of this approach through the ACTIVE tool in [183]....

    [...]

Proceedings ArticleDOI
13 Apr 2015
TL;DR: This paper presents an approach for the systematic and correct execution of analyses on real-time system models along with a proof-of-concept, using contracts to reason about models, analyses and goals.
Abstract: In the design of real-time systems, models are usual artifacts to capture and represent the various features of the system. They are later analyzed to check for their correctness. A key issue is to handle models and analyses in a systematic, consistent and efficient way. This paper presents an approach for the systematic and correct execution of analyses on real-time system models along with a proof-of-concept. The contribution aims at 1) directing the analyses targeting goals and 2) using contracts to reason about models, analyses and goals. An example of goal is to enrich a model with missing information or to obtain precise data to conclude about the system quality. In our approach, contracts are used to formally depict both the properties required and provided by the analyses, but also models and goals. Through the concept of contracts, we identify all the feasible paths to execute the analyses in order to reach a goal.

5 citations


Additional excerpts

  • ...We finally conclude in Section VI. 1555-0885/15 $31.00 © 2015 IEEE DOI 10.1109/ISORC.2015.29 236...

    [...]

References
More filters
Book ChapterDOI
29 Mar 2008
TL;DR: Z3 is a new and efficient SMT Solver freely available from Microsoft Research that is used in various software verification and analysis applications.
Abstract: Satisfiability Modulo Theories (SMT) problem is a decision problem for logical first order formulas with respect to combinations of background theories such as: arithmetic, bit-vectors, arrays, and uninterpreted functions. Z3 is a new and efficient SMT Solver freely available from Microsoft Research. It is used in various software verification and analysis applications.

6,859 citations

Book
03 Jan 1989
TL;DR: In this paper, the problem of multiprogram scheduling on a single processor is studied from the viewpoint of the characteristics peculiar to the program functions that need guaranteed service, and it is shown that an optimum fixed priority scheduler possesses an upper bound to processor utilization which may be as low as 70 percent for large task sets.
Abstract: The problem of multiprogram scheduling on a single processor is studied from the viewpoint of the characteristics peculiar to the program functions that need guaranteed service. It is shown that an optimum fixed priority scheduler possesses an upper bound to processor utilization which may be as low as 70 percent for large task sets. It is also shown that full processor utilization can be achieved by dynamically assigning priorities on the basis of their current deadlines. A combination of these two scheduling techniques is also discussed.

5,397 citations

Proceedings ArticleDOI
04 Jun 1990
TL;DR: An algorithm is developed for model checking, that is, for determining the truth of a TCTL formula with respect to a timed graph, and it is argued that choosing a dense domain, instead of a discrete domain, to model time does not blow up the complexity of the model-checking problem.
Abstract: This research extends CTL model-checking to the analysis of real-time systems, whose correctness depends on the magnitudes of the timing delays. For specifications, the syntax of CTL is extended to allow quantitative temporal operators. The formulas of the resulting logic, TCTL, are interpretation over continuous computation trees, trees in which paths are maps from the set of nonnegative reals to system states. To model finite-state systems the notion of timed graphs is introduced-state-transition graphs extended with a mechanism that allows the expression of constant bounds on the delays between the state transition. As the main result, an algorithm is developed for model checking, that is, for determining the truth of a TCTL formula with respect to a timed graph. It is argued that choosing a dense domain, instead of a discrete domain, to model time does not blow up the complexity of the model-checking problem. On the negative side, it is shown that the denseness of the underlying time domain makes TCTL II/sub 1//sup 1/-hard. The question of deciding whether a given TCTL formula is implementable by a timed graph is also undecidable. >

911 citations

Book
05 Oct 2012
TL;DR: This introductory reference and tutorial is ideal for self-directed learning or classroom instruction, and is an excellent reference for practitioners, including architects, developers, integrators, validators, certifiers, first-level technical leaders, and project managers.
Abstract: Conventional build-then-test practices are making todays embedded, software-reliant systems unaffordable to build. In response, more than thirty leading industrial organizations have joined SAE (formerly, the Society of Automotive Engineers) to define the SAE Architecture Analysis & Design Language (AADL) AS-5506 Standard, a rigorous and extensible foundation for model-based engineering analysis practices that encompass software system design, integration, and assurance. Using AADL, you can conduct lightweight and rigorous analyses of critical real-time factors such as performance, dependability, security, and data integrity. You can integrate additional established and custom analysis/specification techniques into your engineering environment, developing a fully unified architecture model that makes it easier to build reliable systems that meet customer expectations. Model-Based Engineering with AADL is the first guide to using this new international standard to optimize your development processes. Coauthored by Peter H. Feiler, the standards author and technical lead, this introductory reference and tutorial is ideal for self-directed learning or classroom instruction, and is an excellent reference for practitioners, including architects, developers, integrators, validators, certifiers, first-level technical leaders, and project managers. Packed with real-world examples, it introduces all aspects of the AADL notation as part of an architecture-centric, model-based engineering approach to discovering embedded software systems problems earlier, when they cost less to solve. Throughout, the authors compare AADL to other modeling notations and approaches, while presenting the language via a complete case study: the development and analysis of a realistic example system through repeated refinement and analysis. Part One introduces both the AADL language and core Model-Based Engineering (MBE) practices, explaining basic software systems modeling and analysis in the context of an example system, and offering practical guidelines for effectively applying AADL. Part Two describes the characteristics of each AADL element, including their representations, applicability, and constraints. The Appendix includes comprehensive listings of AADL language elements, properties incorporated in the AADL standard, and a description of the books example system.

303 citations

Proceedings ArticleDOI
08 Apr 2013
TL;DR: This paper shows how design contracts can facilitate interaction between 2 groups: control and software engineers and proposes guidelines on how to choose, derive and employ them.
Abstract: This paper introduces design contracts between control and embedded software engineers for building Cyber-Physical Systems (CPS). CPS design involves a variety of disciplines mastered by teams of engineers with diverse backgrounds. Many system properties influence the design in more than one discipline. The lack of clearly defined interfaces between disciplines burdens the interaction and collaboration. We show how design contracts can facilitate interaction between 2 groups: control and software engineers. A design contract is an agreement on certain properties of the system. Every party specifies requirements and assumptions on the system and the environment. This contract is the central point of inter-domain communication and negotiation. Designs can evolve independently if all parties agree to a contract or designs can be modified iteratively in negotiation processes. The main challenge lies in the definition of a concise but sufficient contract. We discuss design contracts that specify timing and functionality, two important properties control and software engineers have to agree upon. Various design approaches have been established and implemented successfully to address timing and functionality. We formulate those approaches as design contracts and propose guidelines on how to choose, derive and employ them. Modeling and simulation support for the design contracts is discussed using an illustrative example.

119 citations


"ACTIVE: A Tool for Integrating Anal..." refers methods in this paper

  • ...Interactions between analyses, implemented as OSATE plugins, are formally described in ACTIVE in order to enable automatic verification....

    [...]

Frequently Asked Questions (1)
Q1. What are the contributions in "Active: a tool for integrating analysis contracts" ?

The Architecture Analysis and Design Language ( AADL ) standard provides a common architectural model to which multiple CPS analyses can be applied. In this paper the authors present ACTIVE, a tool developed within the OSATE/AADL infrastructure to ensure correct analysis interaction. The authors describe the problems that occur when multiple analyses are applied to an AADL model and how these problems invalidate analysis results.