A Framework for Certiﬁcation of Large-scale Component-based Parallel

Computing Systems in a Cloud Computing Platform for HPC Services

Allberson Bruno de Oliveira Dantas

, Francisco Heron de Carvalho Junior

and Lu

ıs Soares Barbosa

Mestrado e Doutorado em Ci

encia da Computac¸

ao, Universidade Federal do Cear

a, Fortaleza, Brazil

HASLab INESC TEC & Universidade do Minho, Campus de Gualtar, Braga, Portugal

Keywords:

Software Formal Veriﬁcation, Veriﬁcation as a Service (VaaS), Cloud Computing, Software Components,

High Performance Computing.

Abstract:

This paper addresses the veriﬁcation of software components in the context of their orchestration to build

cloud-based scientiﬁc applications with high performance computing requirements. In such a scenario, com-

ponents are often supplied by different sources and their cooperation rely on assumptions of conformity with

their published behavioral interfaces. Therefore, a faulty or ill-designed component, failing to obey to the

envisaged behavioral requirements, may have dramatic consequences in practice. Certiﬁer components, intro-

duced in this paper, implement a veriﬁcation as a service framework and are able to access the implementation

of other components and verify their consistency with respect to a number of functional, safety and liveness

requirements relevant to a speciﬁc application or a class of them. It is shown how certiﬁer components can be

smoothly integrated in HPC Shelf, a cloud-based platform for high performance computing in which different

sorts of users can design, deploy and execute scientiﬁc applications.

1 INTRODUCTION

Unlike in engineering, current software development

methods usually do not provide strong assurance con-

cerning software reliability. For this reason, great re-

search efforts, both in academia and industry, have

proposed mechanisms for formal veriﬁcation of soft-

ware. However, testing and a posteriori empirical er-

ror detection are still the usual practice.

The main reason of the poor dissemination of for-

mal methods is the inherent complexity of computa-

tional systems. Each line of code is a potential source

of errors in programs, especially parallel ones, lead-

ing to a large number of states, making it difﬁcult to

predict the behavior of an application and verify its

properties. This difﬁculty is increased in emerging

heterogeneous computing environments in High Per-

formance Computing (HPC). In fact, the use of formal

methods for improving HPC software, whose com-

plexity has increased signiﬁcantly in the recent years,

is very poorly explored in research initiatives.

HPC Shelf is a proposal of cloud computing plat-

form for providing HPC services (de Carvalho Silva

and de Carvalho Junior, 2016). It offers an environ-

ment to develop applications for the needs of special-

ists of a given domain, dealing with domain-speciﬁc,

computationally intensive problems by orchestrating

parallel components whose performance are tuned to

classes of parallel computing platforms. Such compo-

nents form parallel computing systems, orchestrated

through SAFe (Shelf Application Framework), a sci-

entiﬁc workﬂow management system.

In such a scenario, computational scientists and

engineers, typically with poor computer science back-

ground, need to be assured that the available compo-

nents behave as declared in their published interfaces.

Therefore, certiﬁcation of components, through

the veriﬁcation of functional and behavioral require-

ments relevant to applications, becomes an essential

ingredient of the HPC Shelf platform, as a way to in-

crease their conﬁdence levels.

In this paper, we introduce a component-based

certiﬁcation framework for components of HPC Shelf,

as a kind of VaaS (Veriﬁcation-as-a-Service) plat-

form. It is specially designed to deal with certiﬁer

components, a kind of components that can be con-

nected to components of parallel computing systems

for certifying them. The smooth orchestration of cer-

tiﬁer components within parallel computing systems

makes the proposed approach both integrated, in the

sense that no disruptive elements must be considered

in their architecture, and modular, as new certiﬁer

Dantas, A., Junior, F. and Barbosa, L.

A Framework for Certiﬁcation of Large-scale Component-based Parallel Computing Systems in a Cloud Computing Platform for HPC Services.

DOI: 10.5220/0006306802290240

In Proceedings of the 7th International Conference on Cloud Computing and Services Science (CLOSER 2017), pages 201-212

ISBN: 978-989-758-243-1

201

components may be included or released according

to the sort of veriﬁcation tasks required.

The certiﬁcation framework also introduces the

notion of tactical components, which help certiﬁer

components to access existing veriﬁcation infrastruc-

tures, including theorem provers and model checkers.

Tactical components, such as any components in HPC

Shelf, are inherently parallel. So, they can be im-

plemented using parallel programming techniques to

exploit the maximum performance of the underlying

cloud infrastructure during the certiﬁcation process.

Another concept introduced in this paper is the

parallel certiﬁcation system. Analogous to parallel

computing systems, in which a workﬂow component

orchestrates a set of solution components over a set of

virtual platforms in order to solve a problem, a paral-

lel certiﬁcation system contains a certiﬁer component

that orchestrates a set of tactical components accord-

ing to the needs of the certiﬁcation process required

by a set of certiﬁable components.

As a case study, this paper introduces a particular

family of certiﬁer components, so-called C4 (Com-

putation Component Certiﬁer Components), for veri-

fying functional and safety properties of computation

components. In order to compose tactical components

for C4 certiﬁers, we have studied the main veriﬁcation

techniques and associated tools that allow the veri-

ﬁcation of formal properties on the different classes

of parallel programs. Finally, a speciﬁc C4 compo-

nent and its tactical components have been applied

to certify components of Montage (Berriman et al.,

2004), an existing astrophotography software kit that

we have been modeled as an HPC Shelf application.

This paper has six more sections. Section 2 de-

scribes HPC Shelf. Section 3 presents the current de-

sign of the certiﬁcation framework. Section 4 presents

the architecture of the computation certiﬁers (C4) and

their tactical components. Section 5 contains the case

study. Related works are presented in Section 6. Fi-

nally, Section 7 concludes this paper.

2 HPC Shelf

HPC Shelf is a cloud computing platform for devel-

oping and deploying cloud-based HPC applications

that serve specialists of a given domain. For that,

it provides, to application providers, tools for speci-

fying problems and building the corresponding com-

putational solutions by orchestrating components of

different component kinds. Such computational so-

lutions are called parallel computing systems, built

out of components that address functional and non-

functional concerns related to both hardware and soft-

Figure 1: Components of a hypothetical parallel computing

system with tactical and certiﬁer components.

ware elements. For that, such components comply to

Hash (de Carvalho Junior et al., 2007), a model of

components intrinsically enabled for parallelism and

supporting the notion of component kinds.

2.1 Component Kinds of HPC Shelf

The component kinds of HPC Shelf are: plat-

forms, representing (virtual) distributed-memory par-

allel computing platforms; computations, imple-

menting parallel algorithms by exploiting the features

of a class of virtual platforms; data sources, repre-

senting data sources that may interest to computa-

tions; connectors, which couple a set of computa-

tions and data sources placed in distinct virtual plat-

forms; and bindings, for connecting service and ac-

tion ports exported by components for communica-

tion and synchronization of tasks, respectively.

A service binding connects a user to a provider

port, allowing a component to consume a service of-

fered by another component. Such ports are compat-

ible if a service binding exists for connecting them.

In turn, action bindings connect a set of action ports

that export the same set of action names. Two ac-

tions of the same name whose action ports are con-

nected in two components execute when both compo-

nents make them active at the same time (rendezvous).

Figure 1 depicts a scenario illustrating components

and their bindings, also including certiﬁer and tacti-

cal components, proposed in this paper (Section 3).

Components have a predeﬁned action port, called

LifeCycle, with the following actions for controlling

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

202

their life-cycle. Action resolve selects a component

implementation and a virtual platform for it, accord-

ing to a system of contextual contracts (Section 2.4).

Action deploy deploys a selected component in a par-

allel computing platform. Action instantiate instanti-

ates a deployed component, which becomes ready for

communication with other components through ser-

vice and action ports. Finally, action release releases

a component from the platform on which it is instan-

tiated, when it is no longer useful.

2.2 Stakeholders

The following stakeholders work around HPC Shelf.

A specialist (ﬁnal user) uses an application for speci-

fying problems using a domain-speciﬁc interface and

executing computational solutions built by the ap-

plication. A provider creates and deploys applica-

tions, by designing computational solutions built out

of components, in the form of parallel computing sys-

tems. A developer develops components of paral-

lel computing systems, tuned for exploiting the ar-

chitecture of a class of virtual platforms. For that,

they are experts in parallel computer architectures and

programming for them. A maintainer offers a paral-

lel computing infrastructure, from which virtual plat-

forms are instantiated.

2.3 Architecture

The architecture of HPC Shelf is based on the follow-

ing three elements: Front-End, Core and Back-End.

The Front-End is SAFe (Shelf Application Frame-

work) (de Carvalho Silva and de Carvalho Junior,

2016), a collection of Java classes and design pat-

terns that providers use for deriving applications. It

supports a language for specifying parallel computing

systems, so-called SAFeSWL (SAFe Scientiﬁc Work-

ﬂow Language). SAFeSWL is a language divided into

an architectural and an orchestration subsets. The ar-

chitectural subset is used to specify the components

and bindings of a parallel computing system. In turn,

the orchestration subset allows the deﬁnition of or-

chestration workﬂows of the parallel computing sys-

tems. Workﬂow components are in fact special con-

nectors which run directly on SAFe.

The Core manages the life-cycle of components,

from cataloging to deployment. Developers, certiﬁers

and maintainers register components and their con-

tracts through the Core. For that, the Core implements

an underlying system of contextual contracts. Appli-

cations access the services of the Core for resolving

component contracts and deploying the components

of parallel computing systems.

The Back-End is a service offered by a maintainer

to the Core for the deployment of virtual platforms.

Once deployed, virtual platforms may communicate

directly with the Core for instantiating components,

which become ready for direct communication with

applications through service and action bindings.

2.4 Contextual Contracts

HPC Shelf employs a system of contextual contracts

(de Carvalho Junior et al., 2016) that separates, for

a component, its interface, so-called abstract com-

ponent, from its implementation, so-called concrete

component. So, one or more concrete components

may exist in the Core’s catalog for a given abstract

component, to meet different assumptions about the

requirements of the host application and the features

of the parallel computing platforms where they can

be instantiated (context). For that, an abstract compo-

nent has a contextual signature, composed of a set of

context parameters. In turn, a concrete component

must be associated with a contextual contract that

types it, deﬁned by an abstract component and a set

of context arguments that valuate its context parame-

ters. During orchestration, when the action resolve

of a component, speciﬁed by a contextual contract

through SAFeSWL, is activated, a resolution proce-

dure for its contextual contract is triggered for choos-

ing of a speciﬁc concrete component that satisﬁes its

contextual contract. Examples of contextual contracts

will be presented in Section 4.2.

3 THE CERTIFICATION

FRAMEWORK

The certiﬁcation framework herein proposed intro-

duces a new kind of components, called certiﬁer com-

ponents, which makes it possible the certiﬁcation of

components of other kinds in a parallel computing

system. The connection between a certiﬁer compo-

nent and a component to be certiﬁed is called certi-

ﬁcation binding, a new kind of binding, which joins

service and action bindings. A component is consid-

ered certiﬁable if it is connected to one or more cer-

tiﬁer components through certiﬁcation bindings. A

certiﬁable component has an additional action in its

LifeCycle port, named certify. Another kind of com-

ponents, called tactical components, is also proposed

to meet the needs of certiﬁer components to access the

functionality of different veriﬁcation infrastructures.

A new stakeholder, the certiﬁer of components,

which deals with certiﬁer and tactical components, is

A Framework for Certiﬁcation of Large-scale Component-based Parallel Computing Systems in a Cloud Computing Platform for HPC

Services

203

proposed. They are specialists in formal methods and

have background in parallel programming.

3.1 Parallel Certiﬁcation System

A parallel certiﬁcation system is composed of:

• a set of tactical components, executing in a pre-

deﬁned virtual platform where all artifacts needed

by a given a proof infrastructure are deployed;

• a certiﬁer component, responsible for orchestrat-

ing the tactical components in a certiﬁcation task

through a workﬂow written in TCOL (Tactical

Component Orchestration Language);

• a set of certiﬁable components, linked to the cer-

tiﬁer component through certiﬁcation bindings.

Parallel certiﬁcation systems are extracted from

the SAFeSWL code of parallel computing systems,

and are responsible for performing certiﬁcation pro-

cedures on a set of components connected to the same

certiﬁer component. Note their analogy with paral-

lel computing systems, where the certiﬁer component

is analogous to the workﬂow component and tactical

components are analogous to solution components.

Therefore, the certiﬁer component is not associated

with a virtual platform, also running directly on SAFe.

3.2 Tactical Components

A tactical component represents a proof infrastruc-

ture, that is, it is composed of a suitable combination

of veriﬁcation tools. So, it can perform a ﬂow of ex-

ecution that goes from receiving a code written in the

language it understands, execute validations, conver-

sions and, ﬁnally, verify properties on such a code.

A tactical component has the following ports:

• a user service port, with operations to receive the

code of the certiﬁable component from the certi-

ﬁer component, possibly previously translated by

the certiﬁer component into the language that the

tactical component understands; receive from the

certiﬁer component formal properties to be veri-

ﬁed on that code; allow the certiﬁer component to

monitor the progress of the veriﬁcation of prop-

erties; and return to the certiﬁer the result of the

veriﬁcation process;

• an action port called veriﬁcation port, or Ver-

ify, containing the actions verify perform, ver-

ify conclusive and verify inconclusive;

• the default port LifeCycle that allows the certiﬁer

component to control its life-cycle.

When verify perform is activated, the tactical

component starts the veriﬁcation process of the for-

mal properties assigned to it. When this process ﬁn-

ishes, it activates verify conclusive, if the veriﬁca-

tion result was conclusive for all properties (true or

false), or verify inconclusive, meaning that the ver-

iﬁcation of one or more properties was inconclusive

(null). The veriﬁcation of a property is inconclusive

when the tactical component is prevented in some

way from applying its veriﬁcation technique to prove

or refute the property. Such a situation may occur

when there is some infrastructure failure on the virtual

platform that houses the tactical component, when the

property is written in a format that is not understood

by the tactical component, or when the veriﬁcation

timeout of the veriﬁcation tool is reached.

3.3 Ports and Bindings of Certiﬁers

For a component to be certiﬁed, one or more certiﬁer

components must be chosen from the catalog and con-

nected to it through certiﬁcation bindings within the

SAFeSWL architectural deﬁnition of the component.

When the application’s workﬂow activates the action

certify of a certiﬁable component, a parallel certiﬁca-

tion system is instantiated and executed for each as-

sociated certiﬁer component. certify is a new compo-

nent life-cycle action designed for this purpose.

The certiﬁcation of a component with respect to

a certiﬁer component is idempotent, that is, it is only

executed once, even though the action certify is acti-

vated several times in one or more applications. Each

certiﬁer component differentiates which properties it

veriﬁes are mandatory and which are optional. At

the end of the certiﬁcation process, the component

is considered to be certiﬁed with respect to the certi-

ﬁer component if all mandatory properties have been

proven. If so, the component receives a certiﬁcate

with respect to the certiﬁer component, which is reg-

istered in the Core in an unforgeable format.

To communicate with the component to be certi-

ﬁed, a certiﬁer component has a unique provider ser-

vice port with the following characteristics:

• through this port, SAFe passes, to the certiﬁer, the

component code, ad hoc formal properties (not

generated by the certiﬁer component itself nor an-

notated directly in the programs), if any, as well

as other information relevant to the certiﬁcation;

• through methods available on this port, the certiﬁ-

cation process of the component performed by the

certiﬁer component can be started by SAFe.

A certiﬁer component has also ports that are coun-

terparts of the veriﬁcation ports of the associated tac-

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

204

tical components. When SAFe requests the certi-

ﬁer component to start the certiﬁcation process, the

certiﬁer component performs the orchestration de-

ﬁned in the associated TCOL fragment, which at some

point will activate the action verify perform related

to each associated tactical component. If the ac-

tion verify perform is activated in a tactical compo-

nent, its process of veriﬁcation of formal properties

is started. When a tactical component activates ver-

ify conclusive and the action of the same name is ac-

tivated in the certiﬁer, the certiﬁer accesses the ser-

vice port of the tactical component in order to obtain

the result of the veriﬁcation of properties and make an

accounting of which have been proven or not.

Finally, when verify inconclusive is activated in

the tactical component and the same occurs in the cer-

tiﬁer, the certiﬁer accesses the service port of the tacti-

cal component to obtain a report. If the certiﬁer com-

ponent has been implemented with this capability, it

can request, either automatically or with the applica-

tion permission, to the Core that, if possible, instan-

tiate the same tactical component on another virtual

platform. If this is possible, the certiﬁer then restarts

the veriﬁcation process for the failed tactical compo-

nent. If not, the certiﬁer emits a message to the ap-

plication and continues its normal ﬂow of execution,

although considering the properties of responsibility

of the failed tactical component as inconclusive.

3.4 TCOL

The automatic application of different tactical compo-

nents to verify formal properties on a set of programs

is designed to enhance the certiﬁcation process. For

example, a speciﬁc property that was not proved by a

tactical component can be proved by others. More-

over, the parallel activation of tactical components

may lead to a decrease in the ﬁnal veriﬁcation time.

Based on this scenario, we propose a language that

allows the orchestration of a set of tactical compo-

nents by a certiﬁer component, called TCOL (Tacti-

cal Component Orchestration Language). In the cur-

rent prototype, TCOL is an extension of the orchestra-

tion subset of the workﬂow language of HPC Shelf,

SAFeSWL, which is admittedly efﬁcient for orches-

trating coarse-grained parallel components, such as

tactical components. The extension was made by the

addition of a new selection operator, switch. Here is

the abstract syntax of TCOL:

TASK ::= skip | perform action | start handle action |

wait handle | cancel handle | sequence TASK+ |

parallel TASK+ | repeat TASK | break |

continue | select {action: TASK}+ |

switch {condition: TASK}+

An action can be an action of one of the predeﬁned

ports: LifeCycle and Verify. A task (TASK), consists

of an orchestration of a set of actions. The orchestra-

tion performed by the certiﬁer is deﬁned by a higher-

level task that orchestrates internal tasks. There are

seven primitive tasks and ﬁve task combinators.

• skip denotes an empty action;

• break ends the iteration in which it is nested;

• continue forces the start of the next iteration;

• perform synchronously activates an action;

• start activates an action asynchronously, option-

ally handled by an identiﬁer (handle id);

• wait waits for the completion of an asynchronous

action, possibly blocking the orchestration thread

in which it was executed;

• cancel cancels the activation of an action previ-

ously activated asynchronously.

The task combinators are:

• sequence denotes the sequential execution of a

list of tasks, in the order they are declared;

• parallel expresses the concurrent execution of a

set of tasks, in which the combinator task ends

after completion of these tasks (fork-join model);

• repeat represents the iterative execution of a task,

in which this iteration is terminated when a break

is executed within its scope;

• select selects one from a set of tasks, where cho-

sen task is the ﬁrst one in the sequence whose

guard action is activated in the component;

• switch selects one from a set of tasks, where the

selected task is the ﬁrst one in the sequence whose

condition is evaluated to true.

The condition grammar of TCOL is similar to the

ones of C-like object-oriented languages. The current

set of variables that may appear in conditions is man-

aged by the certiﬁer and they are updated by it during

the certiﬁcation process. They are:

• formal properties: an associative array which

associates each pair <formal property, program>

to null, to say that none tactical component has

already tried or managed to verify (prove or dis-

prove) the property; false, whether the property

was veriﬁed by some tactical component but was

refuted; and true, whether some tactical compo-

nent managed to prove it;

• tc applied: an associative array that indicates, for

each tactical component orchestrated, whether it

has already been activated to verify the formal

properties assigned to it (false or true);

A Framework for Certiﬁcation of Large-scale Component-based Parallel Computing Systems in a Cloud Computing Platform for HPC

Services

205

• Context arguments: it is possible to use in con-

ditions the arguments assigned to the context pa-

rameters of the abstract certiﬁer by the contextual

contract of the concrete certiﬁer.

4 THE C4 CERTIFIER

C4 (Computation Component Certiﬁer Component) is

a kind of certiﬁers aimed at verifying formal proper-

ties of computation components.

In HPC Shelf, computation components have a set

of units, which represent processes that run on dif-

ferent processing nodes of the target virtual platform.

Commonly, a component has a single parallel unit,

representing a team of units programmed in SPMD

(Single Program Multiple Data) style, where the same

code is executed in each unit. The units work on dif-

ferent data partitions and synchronize by exchanging

messages. This is the programming model of MPI

(Dongarra et al., 1995). Parallelism in a unit may also

be exploited by launching threads on the virtual plat-

form node that places it by using OpenMP (OpenMP,

1997).

A computation component may also be consti-

tuted by multiple parallel units. Also, it may have sin-

gleton units, each one running a distinct program.This

is the MPMD (Multiple Program Multiple Data) style.

Proving functional and safety properties of

message-passing based parallel programs is consid-

ered a challenge task, even for SPMD.

4.1 Tactical Components for C4

We had performed a systematic survey for decid-

ing which existing formal veriﬁcation techniques and

tools tactical components could support for verifying

parallel programs in computation components. Our

ﬁndings are summarized in the following sections,

which discuss the two major classes of tools: deduc-

tive program veriﬁcation and model checking.

4.1.1 Deductive Tactical Components

Tactical components for deductive veriﬁcation are as-

sertional, since programs they verify must be dec-

orated with assertions of the Floyd-Hoare logic or

its extensions, such as: separation logic (Reynolds,

2002), for mutable data structures; Owicki-Gries rea-

soning (Owicki and Gries, 1976), for shared-memory

parallel programs; and Apt’s reasoning (Apt, 1986),

for distributed-memory ones.

A tactical component is purely assertional if the

properties it veriﬁes are only in the form of speciﬁca-

tion assertions, i.e., pre- and post-conditions of meth-

ods. In turn, a tactical component is non-purely as-

sertional when the properties it veriﬁes are ad hoc,

i.e., properties created by the component developer

and stored in the component to be veriﬁed on it.

For deductive veriﬁcation tools, the veriﬁcation

time is not proportional to the number of units of the

component. However, the application of these tools

to distributed-memory parallel programs, especially

MPI ones, is still incipient. In fact, we have found

that only ParTypes (L

opez et al., 2015) can verify

C/MPI programs, annotated in the syntax of VCC (Co-

hen et al., 2009), against a high-level communication

protocol, received by the certiﬁer as an ad hoc prop-

erty. With respect to thread-based programming in C

and Java, explicit safety properties annotated in pro-

grams, as well as implicit ones (e.g. ensure that the

program does not make access to unallocated mem-

ory locations), can be veriﬁed with VeriFast (Jacobs

et al., 2011), provided that they are annotated with

separation logic assertions. In turn, Frama-C (Cuoq

et al., 2012) is a very expressive tool for verifying se-

quential C programs annotated as methods pre- and

post-conditions.

VCC, VeriFast and Frama-C are veriﬁcation fron-

tends. They verify annotated programs written in a

high-level language, generally translating them to an

intermediate veriﬁcation language, which generates

veriﬁcation conditions (VCs) and applies them to an

automatic or interactive prover. Intermediate veriﬁca-

tion languages act as layers upon which veriﬁers are

built for other languages. Boogie (Barnett et al., 2006)

and Why3 (Bobot et al., 2011) are examples of them.

There is a wide variety of automatic provers, from

two main classes: SMT (Satisﬁability Modulo Theo-

ries) solvers and ATP (Automated Theorem Provers)

provers. SMT solvers determine when formulas in

ﬁrst order logic, in which some symbols of func-

tions and predicates have additional interpretations,

are satisﬁable. Among them, we can mention Alt-

Ergo, CVC3, CVC4 and Z3. ATP provers, in turn, deal

with the task of proving that a conjecture is a logical

consequence of a set of axioms and hypotheses. They

include E, SPASS and Vampire. There is also a prover

for verifying ﬂoating-point arithmetic, called Gappa.

In general, a deductive veriﬁcation tactical com-

ponent is composed of a veriﬁcation frontend, an in-

termediate veriﬁcation language, and a prover. Other

elements may appear. For example, plugins of veriﬁ-

cation frontends, such as Jessie and WP, for Frama-C,

and ParTypes, for VCC, may add new features.

When there is a single possible composition, the

tactical component is named with the most special-

ized tool. For example, ParTypes is composed of Par-

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

206

Types, VCC, Boogie, and Z3. In turn, when there are

multiple ones, the name is composed of excerpts from

the names of the tools. For example, JFWCVC4 is

composed of Jessie, Frama-C, Why3, and CVC4.

4.1.2 Model Checking Tactical Components

The scarcity of deductive veriﬁcation tools for MPI

programs has motivated us to investigate model

checking alternatives. The most relevant we have

found are ISP (In-situ Partial Order) (Vo et al.,

2009) and CIVL (Concurrency Intermediate Veriﬁca-

tion Language) (Siegel et al., 2015). They verify a

ﬁxed, although expressive, set of safety properties.

ISP veriﬁes properties like deadlock absence, asser-

tion violations, MPI object leaks, and communica-

tion races (unexpected communication matches) on

C, C++ and C# programs carrying MPI/OpenMP di-

rectives. CIVL, in turn, includes the veriﬁcation of

functional equivalence between programs.

All standard properties of a tactical component are

mandatory. For a speciﬁcation assertion to be consid-

ered mandatory, it must be preceded by the annotation

@Mandatory. Otherwise, it is optional. Finally, with

respect to ad hoc properties, the component developer

must make the distinction. Examples of standard and

ad hoc properties are present in the case study.

4.2 Contextual Contracts

In general, computation certiﬁers differ from one an-

other by the set of tactical components they are able to

orchestrate. Therefore, contextual contracts of these

components must express characteristics of their as-

sociated tactical components.

Each certiﬁer keeps track of the average veriﬁca-

tion time of each property it veriﬁes, keeping this in-

formation in the component description in the cata-

log of components. Thus, the component developer

can evaluate the cost/beneﬁt of verifying a particular

property. Moreover, it may be interesting to her to

establish a maximum time that she is willing to dis-

pense with the veriﬁcation of all formal properties on

her component. Thus, there is a quality context pa-

rameter in the certiﬁer that must be valued with this

time and the Core will only choose certiﬁers that are

able to verify the properties within that time. The ini-

tial maximum veriﬁcation time can be obtained by an-

alytical modeling or experimentation by the certiﬁer

developer. The Core keeps track of the occurrences

of violations in quality parameters, including veriﬁ-

cation time of certiﬁers. Such a kind of reputation

parameter inﬂuences the Core in determining the pri-

ority of components (certiﬁers) among the possible

choices calculated by the resolution procedure. How-

ever, a description of such a mechanism is out of the

scope of this paper.

The abstract C4 certiﬁer has currently the follow-

ing contextual signature:







programming language = P : PLTYPE,

separation logic = S : SLTYPE,

ﬂoating point operations = F : FPOTYPE,

existential quantiﬁer = E : EQTYPE,

message passing interface verif = M : MPIVERIFTYPE,

ad hoc properties = A : AHTYPE,

max veriﬁcation time = MV : INTEGER







Here is the description of the context parameters:

• programming language: denotes the program-

ming languages in which programs that the cer-

tiﬁer verify must be written;

• separation logic: states whether the certiﬁer or-

chestrates tactical components able to verify pro-

grams annotated with separation logic assertions;

• ﬂoating point operations: indicates whether the

certiﬁer is able to verify ﬂoating point operations,

by using the tactical component Gappa;

• existential quantiﬁer: indicates whether the as-

sertions of programs to be veriﬁed by the certiﬁer

contain existential quantiﬁers. SMT solvers are

not good at guessing witnesses for existentially

quantiﬁed variables (Franc¸ois Bobot et al., 2014).

In this case, if the certiﬁer orchestrates a set of

SMT solvers and ATP provers, it is advisable that

it ﬁrst invoke the ATP provers;

• message passing interface verif : states whether

that the certiﬁer is able to verify MPI programs;

• ad hoc properties: informs whether the certiﬁer

accepts ad hoc properties;

• max veriﬁcation time: denotes the certiﬁer max-

imum veriﬁcation time (seconds).

PLTYPE, SLTYPE, FPOTYPE, EQTYPE,

MPIVERIFTYPE, AHTYPE and INTEGER are

abstract qualiﬁer components that determine the

contractual bounds of the context parameters.

An example of contextual contract derived from

the contextual signature of C4 is the contextual con-

tract of the concrete certiﬁer C4ImplMo, which will be

better contextualized in the case study:

C4ImplMo : C4







programming language = C,

separation logic = NOSEPARATIONLOGIC,

ﬂoating point operations = NOFLOATINGPOINTOPERATIONS,

existential quantiﬁer = NOEXISTENTIALQUANTIFIER,

message passing interface verif = MPIVERIF,

ad hoc properties = ADHOCPROPERTIES,

max veriﬁcation time = 30







Based on this contract, we can state that C4ImplMo

veriﬁes C/MPI programs, accepts ad hoc properties

and its initial (experimental) maximum veriﬁcation

time is 30 seconds.

A Framework for Certiﬁcation of Large-scale Component-based Parallel Computing Systems in a Cloud Computing Platform for HPC

Services

207

0 <sequence>

1 <parallel>

2 <sequence>

3 <perform ac t i on = " re s olv e " comp = " ISP "/ >

4 <perform ac t i on = " de p l oy " c o mp = " I S P " / >

5 <perform ac t i on = " i n s t a nt i at e " comp = " I S P " / >

6 </sequence>

7 <sequence>

8 <perform ac t i on = " re s olv e " comp = " Pa r Ty p es "

9 <perform ac t i on = " de p l oy " c o mp = " P ar T yp e s "/ >

10 <perform ac t i on = " i n s t a nt i at e " comp = "

Pa r T yp e s " / >

11 </sequence>

12 </parallel>

13 <parallel>

14 <perform ac t i on = " v e ri f y_ p e r fo r m " c o mp = " I S P " / >

15 <perform ac t i on = " v e ri f y_ p e r fo r m " c o mp = "

Pa r T yp e s " / >

16 </parallel>

17 <perform ac t i on = " re l eas e " comp = " ISP "/ >

18 <perform ac t i on = " re l eas e " comp = " Pa r Ty p es " />

19 </sequence>

Figure 2: The orchestration of C4ImplMo in TCOL.

C4ImplMo orchestrates two tactical components,

a model checking one (ISP) and a deductive veriﬁ-

cation one (PARTYPES), which extend the following

contextual signature with no addition of parameters:

TACTICAL





message passing interface = M : MPITYPE,

number of nodes = N : INTEGER,

number of cores = C : INTEGER





The parameter message passing interface states

whether the tactical component is implemented

through the MPI library (note the difference between

this parameter and message passing interface verif

of C4). The parameters number of nodes and num-

ber of cores mean, respectively, the minimum num-

ber of processing nodes and processing cores per pro-

cessing node that the target platform of the tacti-

cal component must contain. The orchestration per-

formed by C4ImplMo is governed by the TCOL frag-

ment in Figure 2.

As concrete tactical components for the ones de-

scribed above, we cite, respectively, ISPImpl and

ParTypesImpl, which were implemented through the

MPICH2 library

and require at least 4 processing

cores in the target virtual platform:

ISPImpl : ISP [message passing interface = MPICH2, number cores = 4]

ParTypesImpl : PARTYPES [ message passing interface = MPICH2, number cores = 4]

In C4ImplMo, the valuations to the contextual sig-

natures of the associated abstract tactical components

were the following, thus making ISPImpl and Par-

TypesImpl possible candidates returned by the Core,

by considering that MPI is a supertype for MPICH2:

ISP [message passing interface = MPI]

PARTYPES [message passing interface = MPI]

Suppose that in order to make a speciﬁc computa-

tion component certiﬁable, its developer has created a

http://www.mpich.org/

certiﬁcation binding between it and C4, for which the

following contextual contract has been provided:





programming language = C,

ad hoc properties = ADHOCPROPERTIES,

message passing interface verif = MPIVERIF





This valuation states that she wants the compo-

nent to be certiﬁed by a certiﬁer that veriﬁes C/MPI

programs and accepts external properties (ad hoc).

Clearly, C4ImplMo is a candidate for this valuation.

5 CASE STUDY: Montage

Montage (Mosaic Astronomic Engine) (Berriman

et al., 2004) is an astrophotography software toolkit

for composing astronomical mosaics (sets of images

of a speciﬁc area) that preserve the calibration and

the position of the original input images and may rep-

resent areas of the sky that are too big to be played

by astronomical cameras. Montage is used as a case

study in several scientiﬁc workﬂow research projects.

The toolset has a number of independent and self-

executable components that can be orchestrated for

obtaining the mosaic. In general, each component

takes as input a set of ﬁles and input parameters, and

outputs ﬁles (possibly images) for other components.

We have encapsulated them as computation compo-

nents of HPC Shelf. For that, they provide a sin-

gle computational action, written in C. Those parallel

ones use MPI for simulating the parallel execution of

instances of another associated sequential component,

each one working on distinct input ﬁles.

We illustrate the use of Montage components with

an existing workﬂow that generates a mosaic of the

Pleiades star cluster

, with the following components:

• MARCHIVELIST: given a sky coordinate and an

archive name, it retrieves, from IRSA (Infrared

Science Archive)

, a list of images that overlap

that position and stores them into the archive;

• MARCHIVEEXEC: retrieves from the server the

FITS (Flexible Image Transport System)

images

of each image listed in an archive and stores them

into the current directory;

• MIMGTBL: generates metadata in a table from im-

ages contained in a directory;

• MPROJEXEC: reprojects images contained in a

directory, by using information contained in the

metadata table. In fact, it executes a set of in-

stances of the component MPROJECT in parallel.

Each one reprojects one or more images;

http://montage.ipac.caltech.edu/docs/pleiades tutorial.html

http://irsa.ipac.caltech.edu/ibe

http://ﬁts.gsfc.nasa.gov

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

208

Figure 3: The three sub-workﬂows of the Pleiades work-

ﬂow. At the end, the images of each color band are com-

bined by the component MJPEG.

• MADD: coadds all images previously corrected

into the ﬁnal image;

• MJPEG: generates a JPEG ﬁle for the ﬁnal image.

For each image that overlaps the center of the

Pleiades cluster, the workﬂow keeps three versions of

it, each one in a different color band (red, infrared and

blue). The images of the same band are stored, re-

spectively, in the data source components DSS2RDIR,

DSS2IRDIR and DSS2BDIR. The color bands are pro-

cessed by separate parallel sub-workﬂows. At the

end, the images of each color band are overlapped,

thus generating the ﬁnal image. Figure 3 shows the

orchestration logic of the computation components

of the Pleiades workﬂow. Due to the space restric-

tions, we have omitted, the contextual signatures of

the abstract components, the contextual contracts of

the concrete components, and the workﬂow code.

5.1 Certifying Montage Components

The highest processing load in Montage falls on the

parallel components, since their associated sequential

components perform the most critical computational

actions. Hence, our efforts focused on certifying these

components. They are: MADDEXEC, MBGEXEC,

MDIFFEXEC, MFITEXEC and MPROJEXEC. They

have a single parallel unit, running a SPMD program.

In order to certify the Montage parallel com-

ponents in batch mode, the developer may create

through SAFe a certiﬁcation application, i.e. ded-

icated to certify components, by creating a parallel

computing system containing the components to be

certiﬁed and the associated workﬂow, described in the

SAFeSWL fragment in Figure 4.

By assuming that certiﬁcation bindings between

0 <parallel

1 <sequence>

2 <perform ac t i on = " re s olv e " comp = " mA d dE x ec " />

3 <perform ac t i on = " ce r tif y " comp = " mA d dE x ec " />

4 </sequence>

5 <sequence>

6 <perform ac t i on = " re s olv e " comp = " mB g Exe c "/ >

7 <perform ac t i on = " ce r tif y " comp = " mB g Exe c "/ >

8 </sequence>

9 <sequence>

10 <perform ac t i on = " re s olv e " comp = " m D i ff E xe c "/ >

11 <perform ac t i on = " ce r tif y " comp = " m D i ff E xe c "/ >

12 </sequence>

13 <sequence>

14 <perform ac t i on = " re s olv e " comp = " mF i tE x ec " />

15 <perform ac t i on = " ce r tif y " comp = " mF i tE x ec " />

16 </sequence>

17 <sequence>

18 <perform ac t i on = " re s olv e " comp = " m P r oj E xe c "/ >

19 <perform ac t i on = " ce r tif y " comp = " m P r oj E xe c "/ >

20 </sequence>

21 </parallel>

Figure 4: SAFeSWL code for orchestrating the Montage

parallel components in the certiﬁcation application.

these components and C4 have been created, as de-

scribed in Section 4.2, the developer creates an appro-

priate service binding for information exchange be-

tween each one and C4, ﬁxes the choice of C4ImplMo

for each one, sets up the single program of each Mon-

tage parallel component to be veriﬁed by both tactical

components of C4ImplMo, ISP and PARTYPES, and

records on each component, as an ad hoc property,

a ParTypes protocol to be veriﬁed against the imple-

mentation of its program. Finally, the developer re-

quests the execution of the certiﬁcation application.

SAFe then creates automatically the certiﬁcation sys-

tem. Upon the activation of the action certify of a

component in the certiﬁcation workﬂow, the compo-

nent joins the parallel certiﬁcation system to be certi-

ﬁed.

The architectural certiﬁcation scenario concern-

ing to each Montage parallel component is simi-

lar and we particularize, for didactic purposes, for

the component MPROJEXEC, in Figure 5. For all

components, virtual platforms containing 20 process-

ing nodes were chosen. For the tactical compo-

nents of C4ImplMo, respectively, ISPImpl and Par-

TypesImpl were chosen, for which virtual platforms

with 4 processing node were chosen. As a Par-

Types protocol to be veriﬁed against the program of

MPROJEXEC, mProjExec.c, the protocol in Figure

6 was provided in this component. This protocol

states that mProjExec.c executes a sequence of eight

MPI Allreduce operations, each of which applies a

reduction (in this case, sum) of integers from all pro-

cesses and distributes the result back to all processes.

Operationally, when the orchestration concerning

to MPROJEXEC in the parallel certiﬁcation system

terminates, the vector formal properties, maintained

by the certiﬁer component, has the result of the veriﬁ-

cation of all properties, therefore considering MPRO-

A Framework for Certiﬁcation of Large-scale Component-based Parallel Computing Systems in a Cloud Computing Platform for HPC

Services

209

Figure 5: Certiﬁcation architecture of MPROJEXEC.

JEXEC certiﬁed with respect to C4ImplMo:

• formal properties[“mProjExec.c” , “no deadlock”] = true

• formal properties[“mProjExec.c” , “no MPI object leaks”] = true

• formal properties[“mProjExec.c” , “no communication races”] = true

• formal properties[“mProjExec.c” , “no irrelevant barriers”] = true

• formal properties[“mProjExec.c” , “protocol mProjExec”] = true

All parallel components except MBGEXEC were

certiﬁed. Indeed, ISP has detected a possible inter-

leaving in MBGEXEC that can lead to receiving an

empty buffer in a MPI Allreduce operation.

0 protocol m P r oj E xe c { allreduce sum integer[1]

1 allreduce sum integer[1]

2 allreduce sum integer[1]

3 allreduce sum integer[1]

4 allreduce sum integer[1]

5 allreduce sum integer[1]

6 allreduce sum integer[1]

7 allreduce sum integer[1] }

Figure 6: ParTypes protocol to be veriﬁed against the pro-

gram mProjExec.c, annotated with VCC assertions.

6 RELATED WORK

Veriﬁcation as a Service (VaaS) has been introduced

by (Schaefer and Sauer, 2011) to deal with scale prob-

lems of software formal veriﬁcation in large-scale

software systems. It is based on veriﬁcation work-

ﬂows, which can run on service-oriented computing

environments, reducing the complexity of veriﬁcation

services. Starting from a system and properties to

be veriﬁed, a veriﬁcation workﬂow can be performed

by invoking veriﬁcation tasks in an appropriate order.

The authors argue that cloud computing, by provid-

ing a service-oriented environment and an extremely

powerful shared processing infrastructure through an

abstract interface, becomes the best alternative to im-

plement VaaS architectures.

Only a few research initiatives on VaaS exist. In

(Mancini et al., 2015), a veriﬁcation service is pro-

posed to show system correctness with respect to un-

controllable events through an exhaustive hardware

simulation by considering all relevant scenarios. In

(Bellettini et al., 2015), a Map-Reduce algorithm for

checking CTL formulas on a cloud is proposed.

The closest initiative to our work is the frame-

work proposed by Hu et al (Kai Hu et al., 2016).

They propose a robust VaaS framework, focusing

mainly on the dualism with the main concerns of SaaS

(Software-as-a-Service), such as the storage of veri-

ﬁcation tools and results, scalability issues and fault

tolerance. Their approach, however, allows the avail-

ability of veriﬁcation tools in the cloud in a raw way,

thus requiring an application developer with skills in

the kind of veriﬁcation supported by the tool, which it

is not often true. Also, their approach does not make

it possible to make assumptions about the comput-

ing platforms on which the veriﬁcations will be per-

formed. Indeed, the use of parallel computing plat-

forms for accelerating veriﬁcations is not a concern.

This paper introduces the ﬁrst VaaS framework

aimed at HPC requirements. Also, it introduces in-

novative features compared to the framework of Hu

et al. For instance, application developers only select

certiﬁer components for certifying components they

desire, and the entire certiﬁcation process runs auto-

matically, by orchestrating tactical components in a

prescribed workﬂow. Moreover, certiﬁer and tactical

components make use of HPC techniques, being able

to exploit different levels of parallelism supported by

HPC platforms (distributed-memory, shared-memory,

multi/many-core, accelerators, etc). Indeed, acceler-

ating component certiﬁcation during orchestration is

a relevant concern since it is a prerequisite for running

certiﬁable components in an application.

7 CONCLUSIONS AND FUTURE

WORK

This paper introduced a VaaS (Veriﬁcation-as-a-

Service) framework on top of the HPC Shelf platform,

thus attending requirements of component-based high

performance computing (CBHPC) platforms.

Such a framework aims at attesting the reliabil-

ity of components, w.r.t. both malicious behavior of

third parties codes and anomalous or erroneous be-

havior caused by programming errors. Such errors

are potentially more common in parallel components

of HPC Shelf, possibly invalidating scientiﬁc studies,

due to the production of results that are erroneous or

whose reliability cannot be proven, as well as waste

precious time in long-running computations.

In order to make the process of certifying compo-

nents less disruptive as possible, the concept of paral-

lel certiﬁcation system, built of components, was in-

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

210

Figure 7: Execution times of the certiﬁcation application.

troduced for reusing the workﬂow already used by the

application provider to build parallel computing sys-

tems. In fact, component orchestrations in both kinds

of systems are operationally similar and can be over-

lapped without interference during execution.

The certiﬁcation framework is an ongoing project

whose initial prototype has been developed in C#/MPI

and validated through the Montage application. These

implementations can be found at https://github.

com/UFC-MDCC-HPC/HPC-Shelf-Certification.

Figure 7 shows the experimental time for execut-

ing the certiﬁcation application of the case study, by

varying the number of processing nodes and process-

ing cores per node engaged in the execution of the

tactical components. The sequential time was calcu-

lated outside HPC Shelf, simply by sequential calls to

the veriﬁcation tools through a Shell Script program.

The parallelism was justiﬁed in all cases, leading in

some cases to a certiﬁcation time of less than half the

sequential time. Such a gain can be useful to the ap-

plication provider, since the certiﬁcation of certiﬁable

components is a prerequisite for running them. We

think that this gain could become even more evident

if components have more programs to be certiﬁed or

the certiﬁer can orchestrate more tactical components.

An outstanding feature of the proposed certiﬁca-

tion framework is extensibility, since new certiﬁer and

tactical components may be smoothly added to deal

with the veriﬁcation of different component kinds

and different classes of properties as veriﬁcation tools

evolve. In particular, we intend to continue the in-

vestigation about veriﬁcation tools for MPI programs,

since MPI is a de facto standard in HPC.

We are also working on SWC2 (Scientiﬁc Work-

ﬂow Certiﬁer Component), a certiﬁer for certifying

workﬂows of parallel computing systems of HPC

Shelf w.r.t. behavioral properties (safety and live-

ness). The architecture of such a component and

the formal modeling of the workﬂows it performs to

the mCRL2 (Groote et al., 2007) veriﬁcation toolset

are aimed at enriching the formal speciﬁcations of

Figure 8: Map-Reduce workﬂow certiﬁcation times.

these components in order to increase their conﬁ-

dence levels (not only for the detection of design

errors on them) and will be presented in a sepa-

rate paper. An implementation of such a component

on top of the certiﬁcation framework was evaluated

through the certiﬁcation of the Map-Reduce (Dean

and Ghemawat, 2008) processing workﬂow and re-

veals promising results, as can be seen in Figure 8.

We also argue that the reliability requirements

of HPC Shelf components may be extrapolated to

other component-based service-oriented HPC plat-

forms. In particular, our immediate interest is to port

the workﬂow certiﬁcation service to other workﬂow-

based platforms, since the veriﬁable workﬂows pat-

terns in SWC2 are common to most of them.

From a broader perspective, we believe that the

inclusion, at design time of an application, of compo-

nents that in a reﬂexive way are able to inspect and

certify components is worth exploring for two rea-

sons. On the one hand, the inherent complexity of

cloud-based applications, given the heterogeneity of

resources and the open and decentralized control they

have, implies the need to scale up modeling and for-

mal veriﬁcation tools. On the other hand, the cloud

itself is an ecosystem in which components that or-

chestrate veriﬁcation engines may live and be invoked

to certify their own computations and the ways they

interact, as suggested in this paper. While the ﬁrst

perspective has already been the focus of a number of

research initiatives (see, for example, the ABS project

(Albert et al., 2014)), the second one constitutes an

open challenge to the software engineering commu-

nity. The HPC Shelf platform with reﬂexive certiﬁ-

cation of components enabled, as introduced in this

paper, is a step in this direction.

ACKNOWLEDGEMENTS

This paper is a result of the project SmartEGOV: Har-

nessing EGOV for Smart Governance (Foundations,

A Framework for Certiﬁcation of Large-scale Component-based Parallel Computing Systems in a Cloud Computing Platform for HPC

Services

211

methods, Tools) / NORTE-01-0145-FEDER-000037,

supported by Norte Portugal Regional Operational

Programme (NORTE 2020), under the PORTUGAL

2020 Partnership Agreement, through the European

Regional Development Fund (EFDR).

REFERENCES

Albert, E., de Boer, F. S., H

ahnle, R., Johnsen, E. B.,

Schlatte, R., Tarifa, S., and Wong, P. (2014). For-

mal modeling and analysis of resource management

for cloud architectures: an industrial case study using

real-time ABS. Service Oriented Computing and Ap-

plications, 8(4):323–339.

Apt, K. R. (1986). Correctness Proofs of Distributed Termi-

nation Algorithms. ACM Trans. Program. Lang. Syst.,

8(3):388–405.

Barnett, M., Chang, B.-Y. E., DeLine, R., Jacobs, B., and

Leino, K. R. M. (2006). Boogie: A Modular Reusable

Veriﬁer for Object-oriented Programs. In Proceedings

of the 4th International Conference on Formal Meth-

ods for Components and Objects, FMCO’05, pages

364–387. Springer-Verlag.

Bellettini, C., Camilli, M., Capra, L., and Monga, M.

(2015). Distributed CTL model checking using

MapReduce: theory and practice. Concurrency and

Computation: Practice and Experience.

Berriman, G. B., Deelman, E., Good, J. C., Jacob, J. C.,

Katz, D. S., Kesselman, C., Laity, A. C., Prince,

T. A., Singh, G., and Su, M.-H. (2004). Montage:

a grid-enabled engine for delivering custom science-

grade mosaics on demand. In SPIE Astronomical

Telescopes+ Instrumentation, pages 221–232. Inter-

national Society for Optics and Photonics.

Bobot, F., Filli

atre, J.-C., March

e, C., and Paskevich, A.

(2011). Why3: Shepherd your herd of provers. In

Boogie 2011: First International Workshop on Inter-

mediate Veriﬁcation Languages, pages 53–64.

Cohen, E., Dahlweid, M., Hillebrand, M., Leinenbach, D.,

Moskal, M., Santen, T., Schulte, W., and Tobies, S.

(2009). VCC: A practical system for verifying concur-

rent C. In Theorem Proving in Higher Order Logics,

pages 23–42. Springer.

Cuoq, P., Kirchner, F., Kosmatov, N., Prevosto, V., Signoles,

J., and Yakobowski, B. (2012). Frama-C. In Interna-

tional Conference on Software Engineering and For-

mal Methods, pages 233–247. Springer.

de Carvalho Junior, F. H., Lins, R., Correa, R. C., and

Ara

ujo, G. A. (2007). Towards an Architecture for

Component-Oriented Parallel Programming. Concur-

rency and Computation: Practice and Experience,

19(5):697–719.

de Carvalho Junior, F. H., Rezende, C. A., Silva, J. C., and

Al Alam, W. G. (2016). Contextual abstraction in a

type system for component-based high performance

computing platforms. Science of Computer Program-

ming.

de Carvalho Silva, J. and de Carvalho Junior, F. H. C.

(2016). A Platform of Scientiﬁc Workﬂows for Or-

chestration of Parallel Components in a Cloud of High

Performance Computing Applications. In Lecture

Notes in Computer Science. Springer.

Dean, J. and Ghemawat, S. (2008). MapReduce: simpliﬁed

data processing on large clusters. Communications of

the ACM, 51(1):107–113.

Dongarra, J., Otto, S. W., Snir, M., and Walker, D. (1995).

An Introduction to the MPI Standard. Technical Re-

port CS-95-274, University of Tennessee.

Franc¸ois Bobot, Jean-Christophe Filli

atre, Claude March

and Andrei Paskevich (2014). Let’s Verify This with

Why3. International Journal on Software Tools for

Technology Transfer (STTT), pages 1–19.

Groote, J. F., Mathijssen, A., Reniers, M., Usenko, Y., and

van Weerdenburg, M. (2007). The Formal Speciﬁ-

cation Language mCRL2. In Methods for Modelling

Software Systems: Dagstuhl Seminar 06351.

Jacobs, B., Smans, J., Philippaerts, P., Vogels, F., Pen-

ninckx, W., and Piessens, F. (2011). VeriFast: A pow-

erful, sound, predictable, fast veriﬁer for C and Java.

In NASA Formal Methods, pages 41–55. Springer.

Kai Hu, Lei Lei, and Wei-Tek Tsai (2016). Multi-tenant

Veriﬁcation-as-a-Service (VaaS) in a cloud. Simula-

tion Modelling Practice and Theory, 60:122 – 143.

opez, H. A., Marques, E. R. B., Martins, F., Ng, N., San-

tos, C., Vasconcelos, V. T., and Yoshida, N. (2015).

Protocol-based veriﬁcation of message-passing paral-

lel programs. In Proceedings of the 2015 ACM SIG-

PLAN International Conference on Object-Oriented

Programming, Systems, Languages, and Applications,

pages 280–298. ACM.

Mancini, T., Mari, F., Massini, A., Melatti, I., and Tronci, E.

(2015). SyLVaaS: System level formal veriﬁcation as

a service. In 2015 23rd Euromicro International Con-

ference on Parallel, Distributed, and Network-Based

Processing, pages 476–483. IEEE.

OpenMP, O. (1997). A Proposed Industry Standard API for

Shared Memory Programming. OpenMP Architecture

Review Board, 27.

Owicki, S. and Gries, D. (1976). An axiomatic proof

technique for parallel programs I. Acta informatica,

6(4):319–340.

Reynolds, J. C. (2002). Separation logic: A logic for shared

mutable data structures. In Logic in Computer Sci-

ence, 2002. Proceedings. 17th Annual IEEE Sympo-

sium on, pages 55–74. IEEE.

Schaefer, I. and Sauer, T. (2011). Towards veriﬁcation as

a service. In International Workshop on Eternal Sys-

tems, pages 16–24. Springer.

Siegel, S. F., Zheng, M., Luo, Z., Zirkel, T. K., Marianiello,

A. V., Edenhofner, J. G., Dwyer, M. B., and Rogers,

M. S. (2015). CIVL: the concurrency intermediate

veriﬁcation language. In Proceedings of the Interna-

tional Conference for High Performance Computing,

Networking, Storage and Analysis, page 61. ACM.

Vo, A., Vakkalanka, S., DeLisi, M., Gopalakrishnan, G.,

Kirby, R. M., and Thakur, R. (2009). Formal Veri-

ﬁcation of Practical MPI Programs. SIGPLAN Not.,

44(4):261–270.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

212