Mobile Networks and Applications

https://doi.org/10.1007/s11036-021-01846-x

SDTIOA: Modeling the Timed Privacy Requirements of IoT Service

Composition: A User Interaction Perspective for Automatic
Transformation from BPEL to Timed Automata
Honghao Gao1 · Yida Zhang1 · Huaikou Miao1 · Ramón J. Durán Barroso2 · Xiaoxian Yang3

Accepted: 8 July 2021

© The Author(s), under exclusive licence to Springer Science+Business Media, LLC, part of Springer Nature 2021

Abstract
With the development of the Internet of Things (IoT) and the Internet, new kinds of services based on IoT devices will benefit
everyone. As a key step in achieving a complex business structure based on a massive number of IoT devices, establishing
an effective service composition is extremely important. The emerging architecture of composition is related to process
management and is subject to security risks, such as privacy leaks. Traditional service composition methods have difficulty
verifying the timed privacy requirements of an IoT service composition. Therefore, this paper proposes an automatic method
of transforming Business Process Execution Language (BPEL) into timed automata for formal verification, with the aim
of formalizing timed privacy requirements for the IoT service composition and verifying the formal model returned to the
UPPAAL supporting tool. First, a privacy requirement template is introduced to analyze the structure of the IoT service
composition. Then, a timed computation tree logic (TCTL) property formula template is used to describe the privacy
requirements, especially time constraints. Second, an extended timed I/O automata model, namely, the Sensitive Data Timed
I/O Automata (SDTIOA) model, is proposed to formalize communication behavior, sensitive data treatment, and service
time. Third, the corresponding transformation rules and algorithms are designed for BPEL and SDTIOA. These models can
be adjusted through user interaction. Next, as a practical engineering application, we develop a prototype to show how to
work with UPPAAL and generate UPPAAL code from SDTIOA code. Finally, a case study is discussed to illustrate the
processes of modeling and timed verification for an IoT service composition.

Keywords IoT service composition · Privacy requirements · BPEL verification · Timed automata · User interactions ·
UPPAAL

1 Introduction combination of such devices [2]. An IoT service composi-

The emergence of the Internet of Things (IoT) has blurred
the boundaries between the physical world and the world
of data [1]. The IoT integrates real-world objects via the
Internet by means of numerous embedded sensors, com-
munication devices, and actuators. Specifically, data are
collected from the real world by IoT devices and then trans-
mitted to a processing center by using the Internet as a com-
munication network. Accordingly, IoT devices are accessi-
ble and can be connected to as ‘services’ at any time. Thus,
the realization of a business function requires a reasonable
 Xiaoxian Yang
xxyang@sspu.edu.cn
Extended author information available on the last page of the article.
tion is similar to a choreographed set of services, in which
multiple services supported by the IoT are selected and
scheduled in an appropriate way to complete complex tasks.
Due to the dynamic and heterogeneous characteristics of
IoT devices, such a service composition cannot ensure that
user data have been collected, disclosed, used, and stored in
accordance with the users’ preferences. Therefore, privacy
issues in this new field have received widespread attention
[3–9]. Moreover, depending on the hardware and locations
of the IoT devices, an IoT service composition may
have different running times during data communication.
Unfortunately, traditional methods of modeling privacy
requirements do not consider time. To better meet user
requirements, a time constraint (such as a timeout,
distributed denial of service (DDoS) or service interruption)
should be considered an important privacy requirement.
Other constraints may be that private data operations can

be performed only within a certain period or that two
private data operations exhibit either temporal dependence
or a mutually exclusive relationship within a specified
period. However, such constraints are difficult to establish
during service composition. Most studies have focused on
monitoring whether private data are illegally used [10];
however, discovering problems during the requirements
analysis phase would facilitate the early detection of bugs
and the construction of a more reliable system. In other
words, it is necessary to verify the relevant timed privacy
requirements when designing and determining an IoT
service composition.
From the implementation perspective, the Business Pro-
cess Execution Language (BPEL) [11] is a useful tool for
establishing service compositions. Suppose that BPEL actions
are mapped to IoT services. When coordinating IoT ser-
vices to complete complex tasks, the corresponding rules for
execution should be designed in detail. Additionally, BPEL
can encapsulate IoT data functions for third parties. How-
ever, BPEL cannot describe the time constraints for IoT
services. Collaboration between services is realized through
data exchange. As functional behaviors, data operations are
‘atomic’ processes. If private user data are disclosed to the
Internet, the data and subsequent operations on those data
cannot be controlled. It is difficult to detect possible dis-
closures of sensitive data from trusted to untrusted services.
We are also interested in whether sensitive data are dis-
closed to trusted services within certain time constraints.
In a case of low bandwidth and high throughput, IoT ser-
vices might be required to complete their operations within
a specified time; this scenario is characteristic of the IoT.
Therefore, whether user data can be disclosed to trusted ser-
vices within the specified time is another problem related to
privacy requirements.
We aim to transform BPEL into a formal model and ver-
ify this model against specified timed privacy requirements.
Our idea is inspired by timed model checking in formal
quantitative verification. However, the existing methods are
mainly manual in nature and require the user to have cer-
tain professional skills, such as formal input language and
code writing skills, to adjust the model in accordance with
the specific tool grammar [12]. Unfortunately, there is typ-
ically a knowledge gap between designers and verifiers;
the former often focus on system analysis and design for
system engineering, whereas the latter focus on formal
modeling and system verification. Thus, automatic model
transformation for BPEL is needed.
This paper proposes the Sensitive Data Timed I/O
Automata (SDTIOA) model, which is an automatic transfor-
mation method for modeling the timed privacy requirements
of IoT service compositions. We mainly investigate when
and how data operations occur considering time constraints.
The rules for transformation from BPEL to SDTIOA and
Mobile Netw Appl
from SDTIOA to UPPAAL [13] code are discussed. In addi-
tion, a visual platform is developed to support automatic
model transformation. The main contributions of this paper
are as follows.
First, a timed privacy requirement template for IoT ser-
vice compositions is proposed. For the relationships among
data operations, services and participants, privacy require-
ments are defined considering time constraints, authority
and dependence. Then, we introduce timed computation tree
logic (TCTL) formulas to describe the verification prop-
erties in accordance with the timed privacy requirement
template.
Second, the formal SDTIOA model is introduced to
formalize the behaviors of service interactions and data
exchange in BPEL business processes. This model includes
basic behaviors, communication time, and sensitive data
operations. The basic behavior is transformed from various
activities, and then, users can interactively select sensitive
data and specify the communication time.
Finally, an automatic tool is developed for practical use.
This tool allows the user to import BPEL and Web Ser-
vices Description Language (WSDL) code as input. Then,
the automatic transformation to generate the formal model is
executed through user interactions. As result, the corre-
sponding UPPAAL code is output from the input BPEL
code. Then, the timed privacy requirements can be verified
by the UPPAAL model checker.
The remainder of the paper is organized as follows.
Section 2 introduces the formal model and the UPPAAL
model checker input format. Section 3 presents the privacy
requirement template and describes the UPPAAL query
language. Section 4 describes the rules for transformation
from BPEL to SDTIOA and from SDTIOA to UPPAAL
input codes. Section 5 introduces the prototype and its
architecture. Section 6 presents a case study. Section 7
reviews related works. Section 8 concludes the paper and
discusses future work.
2 Preliminary Information
In this section, the concept of timed automata and the
formal definition of timed I/O automata (TIOA) [14] are
briefly introduced. Then, the formal definition of SDTIOA
is proposed by extending the sensitive data operation matrix
for TIOA. Finally, we analyze the structure of the input
language of the UPPAAL model checker for accepting
codes transformed from SDTIOA.
Formal methods of model checking include qualitative
and quantitative verification techniques. For a given system
model M and property φ, qualitative verification proves
whether M satisfies φ, i.e., M| = φ. For a given system
model M and property φc , quantitative verification proves
Mobile Netw Appl
whether M satisfies the quantitative property time constraint
c when property φ is satisfied, i.e., M| = φc .
Finite-state machines (FSMs) with clock sets are used as
the timed automata, and timed model checking is used for
quantitative verification. A clock set is a finite set of clock
variables with values in a range from 0 to some positive
number R. Comparison-based expressions in terms of these
clock variables can be used to describe the time constraints
of transformations. An invariant attribute is used to specify
an upper bound on time advancement at a certain location
to prevent the state from stopping. Thus, a state transition
will occur when the state clocks are within the invariant
constraint limits.
Definition 1 A timed I/O automaton is defined as the tuple
TIOA::= (S, S0 , V , A, E, I nv), where S is a finite set
of states; S0 ∈  S is the initial state; V is a finite set of
clocks; A = Ai Ao is a finite set of actions, with Ai and
Ao corresponding to input and output actions, respectively;
E ⊆ S × A × B(V ) × P (V ) × S is a finite set of edges,
with B(V ) being a set of constraint expressions v ∼ n (here,
v ∈ V is a clock, ∼∈ {≥, ≤, <, >, =} and n ∈ {R ∗ |R ∗ ∈
R, R ∗ ≥ 0}) and P (V ) being a set of clocks that need to be
reset; and I nv : S → B(V ) is a set of state invariants, with
→ representing the mapping process. An edge is expressed
in the form (s, a, b, c, s ) ∈ E, where s is the initial state, a
is an action label, b is a set of constraint clocks that must be
satisfied when actions along the edge are executed, c is a set
of clocks to be reset and s is the target state.
Definition 2 A sensitive data operation matrix s is defined
with dimensions of |W |×|L|, where |W | is 2, corresponding
to the disclosure and collection operations in BPEL, and
|L| is the number of sensitive data. For example, suppose
that there are three sensitive data a, b, and c in BPEL. We
can construct a sensitive data operation matrix for them as
shown in Table 1. The values in the matrix are either 1
or 0 based on whether a sensitive data operation occurs or
not. Table 1 describes the sensitive data operation matrix of
a BPEL process that discloses sensitive data a and c and
collects sensitive datum b. The disclosure operation is a
push behavior of the service, and the collection operation is
a pull behavior.
Definition 3 A sensitive data timed I/O automaton is
defined as the tuple SDTIOA::=(S, S0 , V , A, , E, I nv,
Table 1 An example of a sensitive data operation matrix
Operation Data a b
Disclose (push) 1 0
Collect (pull) 0 1
M), where S is a finite set of states;
S0 is the initial state; V
is a finite set of clocks; A = Ai Ao (Ai ∩ Ao = ∅) is a
finite set of actions, with Ai and Ao corresponding to input
and output actions, respectively;  is a finite set of |W |×|L|
sensitive data operation matrices; E ⊆ S × A × B(V ) ×
P (V ) ×  × S is a finite set of edges; I nv : S → B(V ) is a
set of state invariants; and M : S →  is a set of mappings
between states and sensitive data operation matrices. An
edge is expressed in the form (s, a, b, c, f, s ) ∈ E, where
s is the initial state, a is an action label, b is a constraint
clock set that must be satisfied when actions are executed
along the edge, c is the set of clocks to be reset, f is the
sensitive data operation matrix and s is the target state.
The components of the sensitive data operation matrix are
as follows: (s, a, b, c, f , s ) is an edge from s to s ,
where f is the moment at which a sensitive data operation
occurs. The symbol → represents the mapping process. If
f is not null, s → f is the mapping between the state
s and the sensitive data operation matrix. If f is null and
the mapping between the state s and the sensitive data
operation matrix is s → s , then s → s is the mapping
between the state s and the sensitive data operation
matrix. The mapping between the initial state S0 and the
sensitive data operation matrix is S0 → 0 , and all values
in 0 are 0.
In SDTIOA, the transformations between states describe
the structural control in BPEL. I nv and B(V ) constrain
the maximum and minimum communication times of a
service, respectively, and  represents the sensitive data
operations in BPEL. Model checking is widely used for
timed automata to verify systems with time attributes. The
time semantics in a timed automaton determine the changes
over time. These changes can be visually displayed as
changes in the values of the clocks. UPPAAL is a common
timed automaton model checking tool that considers integer
variables, structure data types, user-defined functions, and
synchronization channels for timed automata. Therefore, in
this paper, the UPPAAL input language is used to encode
SDTIOA.
Definition 4 As shown in Fig. 1, UPPAAL takes input for-
matted as an XML file. The structure of this file is mainly
composed of a global declaration part, a template part,
and a system part. Each template is composed of a dec-
laration part, a location part, an initial location part, and
a transition part. Global declaration: This part declares the
global variables and channels involved in the communi-
cation between the templates. Template declaration: This
part declares the functions and variables used in the tem-
c plate. Template location: This part declares the location
1
information for each state in the template, and tags can
0
be added to each state, such as invariant, urgent, and
other tags. Template initial location: This part declares the

Fig. 1 The structure of a UPPAAL input
initial location of the template. Template transition: This
part declares the transition information for the states in the
template, and tags can be added to a transition, such as
guard, synchronization, and other tags. System: This
part declares the executable systems of the model. In Fig. 1,
the labels ‘x’ and ‘y’ are the coordinates of the element in
the display interface.
UPPAAL is a popular tool for verifying the timed prop-
erties of a system. However, it requires users to formally
model the system of interest and master the syntax of
UPPAAL. Unfortunately, most designers of service compo-
sitions lack skills in formalizing models and writing input
codes for UPPAAL. Thus, it is necessary to be able to auto-
matically model a designed business process and transform
the model into the input language of UPPAAL.
3 Formal Description of Privacy
Requirements
In this section, the types of timed privacy requirements that
exist in an IoT service composition scenario are analyzed,
and these types are transformed into UPPAAL property for-
mulas. Then, a template is established to support mapping
between various types of timed privacy requirements and
the UPPAAL query language.
Definition 5 The privacy requirements in a service
composition scenario can be defined as follows. As shown
Mobile Netw Appl
in Fig. 2, a service composition scenario is composed of
several participants. Each participant is associated with a
business process and communicates with other participants
through services. The business process of each participant
includes several services that, in turn, are composed of
several data operations. A service composition collaborates
through data interaction, and the basic unit of data
interaction is a data operation. Therefore, data operations
can be considered atomic operations.
The data operations shown in Table 2 are considered
atomic operations. Consider the privacy requirements from
the perspectives of a business and an interaction. At the
business level, the authority to conduct a data operation
may lie at the service, participant, or system level. At the
interaction level, data operations may depend on other data
operations, services, and participants. The types of timed
privacy requirements that may appear in a service composi-
tion are defined in Table 2.
Definition 6 The query language of UPPAAL is a subset
of TCTL [15], but nested path formulas are not allowed.
The structure of a TCTL formula φ is as follows: φ :=
p|¬p|true|f alse|φ ∧ φ|φ ∨ φ|φ1 → φ2 |E[]φ|E <>
φ|A[]φ|A <> φ, where p is an atomic proposition and can
be an expression of the form c ∼ n, where c is a clock,
∼∈ (≥, ≤, <, >, =) and n ∈ {R ∗ |R ∗ ∈ R, R ∗ ≥ 0}; ¬p is
the negation of p; φ∧φ and φ∨φ represent the AND and OR
operations, respectively, between two formulas; φ1 → φ2
Mobile Netw Appl

Fig. 2 Structure levels of a

service composition scenario

means that if φ1 is true, then φ2 must be true; E[]φ means
that there exists a path such that for all states on the path, φ
is true; E <> φ means that there is a path such that there
exists a state on the path that makes φ true; A[]φ means
that for all states on all paths, φ is true; and A <> φ
means that for all paths, there exists a state on each path that
makes φ true. If c is a clock, then there exists a mapping
c → {R ∗ |R ∗ ∈ R, R ∗ ≥ 0}, and v(c) is used to represent
the value of the mapping of c. Then, c ∼ n is true if and only
if v(c) ∼ n. For example, in daily life, the following TCTL
formula holds: A[] door exists → E <> the door opens
within one minute, which means that for all doors that exist,
there is a path that allows them to open within one minute.
The UPPAAL query language has only one-path formulas,
that is, only one of E[], E <>, A[], and A <> exists in any
formula.
In Table 3, a mapping template between each privacy
requirement type in Table 2 and the query language of
UPPAAL is defined. In Table 3, the symbol d represents
a data operation, s represents a service, p, ..., pn represent
participants, p.d represents a data operation d of participant
p, and p.s represents a service s of participant p. The
symbol all represents the global clock, which is reset when
the scenario starts. The symbol p.c is the independent
clock of participant p, which is reset when participant p
starts. The symbol c d is a clock for data operation d, and
this clock will reset when data operation d triggers. Users
can transform various privacy requirements into the query
language of UPPAAL based on this template.
The aim of establishing a sensitive data operation
model is to verify privacy requirements. Thus, the privacy
requirements must be described in the query language
of UPPAAL. Unfortunately, most designers of privacy
requirements cannot skillfully code in the UPPAAL query
language. Therefore, it is necessary to design a mapping
template between privacy requirements and the query
language of UPPAAL.

Table 2 Specifications of timed privacy requirements

Description ID Type Explanation

Data operation 1 Overall level with time constraints
authority 2 Participants with time constraints
3 Service with time constraints
Time-constrained 4 A data operation depends on certain time
constraints after another data operation
triggers
dependence 5 A service depends on certain time con-
straints after a data operation triggers
6 A participant depends on certain time
constraints after a data operation triggers
The data operation is allowed with the
specified time constraints.
The data operation is allowed for a speci-
fied participant with the specified time con-
straints.
The data operation is allowed for a specified
service with the specified time constraints.
When a data operation triggers, another data
operation must trigger with the specified
time constraints.
When a service triggers, a data operation
must trigger with the specified time con-
straints.
When a participant triggers, a data oper-
ation must trigger with the specified time
constraints.
Table 3 Examples of privacy requirements described in the UPPAAL query language
ID Sample
1 Data operation d is allowed when
the scenario time is greater than t
2 Data operation d is allowed for
participant p when the scenario
time is greater than t
3 Data operation d is allowed for
service s when the scenario time
is greater than t
4 When data operation d triggers,
data operation d must trigger
within time t
5 When data operation d triggers,
service s must trigger within time
t d triggers
6 When data operation d triggers,
participant p must start within
time t
UPPAAL query language Explanation Table 2 ID
A[] p.d + p1.d + ... + pn.d > 0 imply all > t The trigger for d satisfies all > t 1
A[] p1.d + ... + pn.d == 0 and (p.d imply all > t) p1.d, ..., pn.d do not trigger, and 2
the trigger for p.d satisfies all >
t
A[] p.d + p1.d + ... + pn.d > 0 Each d must trigger for service s 3
imply (p.s or p1.s or... or pn.s) and all > t
and all > t
A[] p.d or p1.d or...or pn.d Each data operation d must 4
imply (c d < t and c d! = all) trigger within time t after data
operation d triggers
A[] p.s or p1.s or...or pn.s imply Each service s must trigger 5
(c d < t and c d! = all) within time t after data operation
A[] p.c == 0 imply c d < t and c d! = all) Each participant p must start 6
within time t after data operation
d triggers
Mobile Netw Appl
Mobile Netw Appl
4 Model Transformation
To verify whether an IoT service composition satisfies
the relevant privacy requirements, the service composition
is transformed into a formal model to support formal
verification. Figure 3 shows the architecture of the
transformation process. At the theory level, the main
concepts of the transformation are shown. The SDTIOA
formalism is first used to formally model each BPEL
input, and the results are then transformed into readable
UPPAAL inputs. At the implementation level, the main
implementation tasks are shown. First, the related data and
services are extracted from a group of BPEL codes, and
then, the user can select sensitive data and set the times for
the services to obtain sensitive data and be implemented.
Second, the process structure and the mapping between
a service and the corresponding data are extracted from
each BPEL code. The process structure is used to generate
states and transformations for SDTIOA. The mapping
between a service and the corresponding data is used to
associate sensitive data and generate sensitive data operation
matrices for SDTIOA. The services associated with time are
used to generate invariants and transformation conditions
Fig. 3 Architecture of the transformation process
for SDTIOA. Finally, the SDTIOA automata are used to
generate readable UPPAAL code. Each SDTIOA automaton
is used to generate a separate UPPAAL template, and the
global declaration part and the system declaration part are
generated from all SDTIOA automata together.
4.1 Extracting SDTIOA Automata from BPEL Inputs
A BPEL file is used as the source file for modeling
with SDTIOA. In BPEL, invoke, receive, reply, and
onmessage in pick are communication activities that
involve the disclosure and collection of data. invoke and
reply are services with push behavior, while receive
and onmessage are services with pull behavior. These
activities should be considered in the transformation
process. Structured activities are the basis of SDTIOA’s
transformation behavior. Therefore, structured activities,
including sequence, if , while and pick, are considered
in this section. Automaton modeling does not describe the
f low structure well; thus, the f low structure is not taken
into account in our model.
In BPEL, a service is bound to a portT ype and
operation. Therefore, portT ype operation is considered
 Mobile Netw Appl

a communication action. The terms label? and label!
represent an input action and an output action, respectively;
in is the maximum time constraint invariant for a
communication activity; b represents the minimum time
constraint transformation condition for a communication
activity;  represents the sensitive data operation matrix
for a communication activity, which is determined by the
mapping of the variables and the sensitive data; and 0
is a zero matrix that is used to reset or initialize sensitive
data operations in the model. For example, during model
transformation, a receive activity portT ype operation
will be transformed into an input action pT op?, and a
variable va will be transformed into the sensitive data
operation matrix . The activity time is artificially set.
After setting, the maximum time and minimum time of
the activity will be transformed into an invariant in and
a condition b, respectively. After the activity ends, the
sensitive data operation is reset by 0 .
The transformation rules for communication activities
in SDTIOA are defined as shown in Table 4. The main
objective in the transformation process is to consider
communication actions, sensitive data operations, and the
communication time to obtain an appropriate SDTIOA
model. A synchronous invoke activity is regarded as both an
invoke activity and a receive activity.
The transformation rules for structured activities in
SDTIOA are defined as shown in Table 5. The main
objective in the transformation process is to ensure the
invariance of the process structure. Notably, pick uses the
same transformation rules as If . Each act in Table 5
represents one of the communication activities listed in
Table 4. In the modeling process, each act needs to be
replaced with the corresponding automaton structure in
Table 4.
As shown in Algorithm 1, we design an abstract algo-
rithm for transforming BPEL into SDTIOA in accordance
with the rules defined in Tables 4 and 5. As shown in
Table 5, structured activities are transformed into states and
their transitions (S, E). BPEL starts from a structured activ-
ity, so the initial state is a structured activity. As shown
in Table 4, communication activities are transformed into
states S, actions A, transitions E, sensitive data operation
matrices , and invariants I nv. From a state S and a sensi-
tive data operation matrix , one can construct M : S → ,
and from a sensitive data operation, one can construct its
corresponding clock set V ; thus, for a communication activ-
ity, one can generate (S, V , A, , E, I nv, M) and then add
these elements to SDTIOA. Note that if a state has only one
input and output, no time constraint, and 0 as its sensitive
data operation matrix and the next output is not a receiving
action, this state will not affect the system time or private
data flow. Therefore, to solve the redundancy in SDTIOA,
such a state will be merged with the next state.
4.2 From SDTIOA Automata to UPPAAL Code
To verify an SDTIOA model, one of the main steps is to
transform the automata into UPPAAL code. In this section,
the process of transforming a scenario described by an
SDTIOA model into UPPAAL code is described. First, the
transformation steps are given. Then, we present an algo-
rithm (Algorithm 2) that briefly summarizes the process.

Table 4 Transformation rules for communication activities in SDTIOA

Communication activity Simple BPEL code SDTIOA

Receive <receive portType = “pT” operation = “op”

variable = “va” .../ >

Invoke (asynchronous) <invoke portType = “pT” operation = “op”

Inputvariable = “va”.../ >

Invoke (synchronous) <invoke portType= “pT” operation = “op”

Inputvariable = “va” Outputvariable =
“va1”.../ >

Reply <reply portType= “pT” operation = “op”

variable = “va” messageExchange =
“mE”.../ >

Onmessage <onmessage portType = “pT” operation =

“op” variable = “va” messageExchange =
“mE”.../ >
Mobile Netw Appl
Step 1: Global declaration. As shown in Fig. 4, the
global clocks and the channels are declared in this step.
There are three kinds of global clocks, a global clock all
and a clock set corresponding to sensitive data operations.
The clock t is used to control the time of a service and
will be reset before the service starts. The channels are
actions that SDTIOA uses to communicate. An action is
declared as a channel if it is simultaneously the input
action of one SDTIOA automaton and the output action
of another SDTIOA automaton. In fact, the input action
of one SDTIOA automaton must be the output action of
another SDTIOA automaton in a complete scenario. c1 − cn
correspond to the disclosure operations of data1 − datan,
and c(n + 1) − c2n correspond to the collection operations
of data1 − datan. When these operations trigger, the
corresponding clock will be reset.

Table 5 Transformation rules for structured activities in SDTIOA
Structured activity Simple BPEL code
Sequence <sequence> act1 act2 < /sequence>
If <if> condition = “” act1 condition = “” act2 < /if >
While <while> act1 < /while>
Step 2: Templates. As shown in Algorithm 3, tran() is
a function that transforms each SDTIOA automaton into a
corresponding template. This function transforms the sensi-
tive data operation matrices, states, and edges in SDTIOA
into template declarations, template locations, and template
transitions, respectively. The specific conversion rules are
introduced in steps 3 to 6.
Step 3: Declaration of a template. As shown in Fig. 5, the
template declaration declares the variables corresponding
Mobile Netw Appl
SDTIOA
to the cells of the sensitive data operation matrix and
the functions corresponding to the cell changes. For the
while structure in SDTIOA, additional integer variables are
generated to represent the number of loops. The clock c is
a local clock used to describe the time of each participant.
d1 − dn correspond to the disclosure operations of data1 −
datan, and d(n + 1) − d2n correspond to the collection
operations of data1−datan. When these operations trigger,
the corresponding variables will be set to 1.
Mobile Netw Appl

Fig. 4 Rules for the

transformation from SDTIOA
into the global declaration

Step 4: Location of a template. As shown in Fig. 6,
a state in SDTIOA is transformed into a location, and
an invariant in SDTIOA is transformed into an invariant
label at a specific location. To support time control for the
entire scenario, the time of states that have no invariant is
defined as 0. UPPAAL also provides a location label urgent
to describe these states. If the next transition of a state is an
input operation, no label is added.
Step 5: Initial location of a template. S0 in SDTIOA is
transformed into the initial template location.
Step 6: Transitions of a template. As shown in Fig. 7,
the edges in SDTIOA are transformed into the transition
part of each template. The transformation conditions
are transformed into the guard labels of the transition.
The transformation actions are transformed into the
synchronization labels of the transition. The reset clocks
and the functions generated in Step 3 are transformed into
assignment labels for the transition.
Step 7: System declaration. Each template corresponds to
a process, and the system consists of these processes.

Fig. 5 Rules for the

transformation from SDTIOA
into a template declaration

Fig. 6 Rules for the transformation from SDTIOA into a template location
5 Prototype Implementation
A prototype of the proposed approach was used for the
automatic generation of UPPAAL code for a scene model.
This section describes the components of the prototype that
a user can select and the parameters that the user can set in
an interactive way.
The first part of the prototype involves the importing of
service documents. As shown in Fig. 8, the prototype allows
users to import service documents described in WSDL.
Since each activity in BPEL is defined in WSDL in detail,
it is necessary to parse the WSDL code to obtain the basic
Fig. 7 Rules for the
transformation from SDTIOA
into a template transition
Mobile Netw Appl
data corresponding to the message type. Due to differences
in the sensitivity of different users to the same data, all basic
data are extracted. Users can select sensitive data from these
basic data in accordance with their preferences. Then, the
prototype extracts the mapping of the message type and the
basic data in WSDL and displays this information on the
right side of the interface.
The second part of the prototype involves the importing
of BPEL code. As shown in Fig. 9, the prototype allows
users to import BPEL files from all participants in a
scenario. The basic structure of each business process is
displayed on the left side of the interface, including the
Mobile Netw Appl
Fig. 8 Importing and extraction of WSDL documents
scope of structured activities, activity types, port types, and
variables of communication activities. For a while structure
in a business process, the prototype allows the user to set the
number of loops.
The final part of the prototype is communication time
setting. As shown in Fig. 10, the prototype allows the user to
set the time ranges of the communication services specified
in BPEL. Then, the prototype displays the services that are
set and the corresponding time ranges via the interface. The
time of all communication activities for which a time range
has not been set is 0 by default. If the user accidentally sets a
time for a communication activity that has no time, the user
needs only to revise the time of the communication activity
to (0,0) to reset this action.
As shown in Fig. 11, after clicking the button labeled
Model Generation, the user is allowed to choose sensitive
data from among all basic data involved in the scenario.
As shown in Fig. 12, the UPPAAL code of the sensitive
data operation model is displayed on the right side of the
interface. Users can export the UPPAAL code of the model
to a specified folder, and then, UPPAAL can be called to
view and verify the model.
6 Case Study
In this section, we present a case study of a workflow
used to model and verify an IoT service composition. This
workflow includes information on 1) how to perform model
transformation and 2) how to verify the timed privacy
requirements.
As shown in Fig. 13, this example involves an epidemic
system based on an IoT service composition with timed
interaction requirements. When a system is accessed by
many users, all services for querying or storing should
be completed in seconds or minutes. The camera and the
code scanner constitute the perception layer. The processor,
network transmitter, and network receiver constitute the
processing system. The network transmitter, network
receiver, and database constitute the network layer. The door
and alarm constitute the presentation layer. The epidemic
system seeks to quickly recognize a user who has been
infected or may have a risk of infection. The workflow
process is as follows. 1) When a person wishes to access
a location with multiple people, that person’s face and
green (health) codes, which include the person’s ID, track,

Fig. 9 Importing and extraction of BPEL files
address, etc., should be collected to determine whether
the person may be infected. 2) Then, the collected data
are sent to the user information database for consistency
checking. 3) If a Yes message is returned, the citizen
information database requests the person’s medical records
from the hospital information database. Otherwise, access is
prohibited. 4) If and only if there are no records of infectious
disease is the person allowed to access the location.
To more clearly describe the business process and
data flow of the participants, the Unified Modeling Lan-
guage (UML) diagram of the scenario is displayed. As
shown in Fig. 14, the sequence diagram of the partic-
ipants is as follows. 1) U ser: Present the green codes
and f ace to the System and wait to enter. The pro-
cessing of the user data is formalized as follows: <
user, (disclose), (f ace, address, I D, track), system >.
2) System: After collecting the green codes and face infor-
mation, determine whether the green codes meet the spec-
ified standard. If the standard is met, send f ace and I D
to the Citizen Information Database for further checking
and wait for feedback. Depending on the feedback, respond
to the user by opening the door or issuing a warning. The
Mobile Netw Appl
processing of the user data is formalized as follows: <
system, (collect), (f ace, address, I D, track), user >
. < system, (disclose), (f ace, I D), citizen db >. 3)
Citizen Information Database: In accordance with the com-
parison results for the collected face and ID information,
send feedback warnings to the system or disclose the ID to
the Hospital Information Database to query the user’s med-
ical records. The processing of the user data is formalized as
follows: < citizen db, (collect), (f ace, I D), system >.
< citizen db, (disclose), (I D), hospital db >. 4) Hos-
pital information database: In accordance with the user ID,
the user’s infectious disease risk is fed back to the system.
The processing of the user data is formalized as follows:
< hospital db, (collect), (I D), citizen db >.
6.1 Model Transformation
Then, we use BPEL to describe the business process for
each participant. As discussed in our description of the pro-
totype system, designers can import BPEL files and set time
ranges for communication services. Then, WSDL service
documents are imported to obtain basic data, and the user
Mobile Netw Appl
Fig. 10 Time setting
can select sensitive data from among the basic data involved in
all services. The service d c binds two portType operations,
namely, U ser initiate and U serCallback onResult.
U ser initiate has two communication types, I nvoke
and Receive, and the corresponding communication time
ranges are set to 2-10 and 1-7, respectively. Additional
communication time ranges set for services are shown
in Table 6. The corresponding relationship between each
portT ype operation and the basic data can be obtained
from the WSDL documents. For example, U ser initiate
contains four basic data types: I D, address, track, and
f ace. All portT ype operations and the corresponding
basic data specified in WSDL are shown in Table 7.
Note that ID, address, track, and f ace are selected as
sensitive data from the basic data in Table 7. Then, we
can generate an SDTIOA automaton for each participant.
Figures 15, 16, 17 and 18 show the SDTIOA automaton
of each participant and the corresponding UPPAAL dis-
play. As shown in Fig. 15, the user invokes the action
user initiate in the time range (2, 10) and then waits for
a message door or message alarm action in a time range
of (5, 10) or (3, 5), respectively. The left side of the figure
shows the SDTIOA automaton generated for the user in
accordance with the rules in Table 4. The first state rep-
resents the request to invoke the action user initiate, the
state invariant t < 10 indicates that the maximum time
of this action is 10, and the successful invocation of the
action needs to meet the minimum time constraint t > 2
and generates the sensitive data operation matrix F1 and
the corresponding reset clock C1 . The second state repre-
sents the execution of the action user initiate, and the
third state indicates that the action user initiate has exited.
When the action exits, the sensitive data operations gen-
erated by the current service are reset through F0 . In the
third state, the process enters the waiting state, waiting for
a message door or message alarm action, after which it
will enter the corresponding branch. To describe the new
action time range, it is necessary to use Ct to reset the
clock t to control the time range. Since the communication
behavior for message door and message alarm does not
involve sensitive data operations, no sensitive data opera-
tion matrix is generated. The right side of the figure shows
the corresponding UPPAAL model. In UPPAAL, the out-
put action user initiate in SDTIOA is described with the

Fig. 11 Selection of sensitive data
synchronization tag user initiate!. The invariant t < 10
is represented by the label t < 10 at the specified loca-
tion. The transformation condition t > 2 is described with
the guard tag t > 2. The variable operations in the sen-
sitive data operation matrix F1 and the reset clock set C1
are implemented by means of the function F C1(), which
is described by the assignment tag F C1(). Ct has only one
reset clock operation, which is described by the assign-
ment tag t := 0. A label with the service name d c is
added to the location to indicate which service is being exe-
cuted. For locations at which the time conditions do not
vary, urgent tags are used to ensure that the time remains
unchanged. As shown in Fig. 15, an additional transforma-
tion is added for the initial process. To model the timing
properties, in UPPAAL, the function init () is used to ini-
tialize all clocks. The respective clocks c are initialized to
ensure consistency between the business process time and
the template time. Figure 16 shows that the system waits
for a user initiate action with a time range of (1,7) and
then invokes a message alarm action with a time range
of (3,6) or a system query action with a time range of
(1,2). After the invocation of the system query action, if
Mobile Netw Appl
the message saf e action is received within the time range
(1,2), then the message door action is invoked in the time
range (3,6). If the message risk action is received within
the time range (1,3), then the message alarm action is
invoked within the time range (3,6). Figure 17 shows that
the Citizen DB waits for a system query action with a
time range of (1,3) and then invokes a message risk action
with a time range of (2,4) or a data query action with a
time range of (2,3). Figure 18 shows that the H ospital DB
waits for a data query action with a time range of (3,6) and
then invokes a message risk action with a time range of
(2,4) or a message saf e action with a time range of (2,4).
The structures in Figs. 16, 17 and 18 are similar to that in
Fig. 15. Actions are all described by synchronization tags,
invariants are described by invariant tags on the correspond-
ing location, transformation conditions are described by
guard tags, and reset clock sets and sensitive data operation
matrices are described by assignment tags. A service name
is added to the corresponding location to indicate the start
of the service. An additional transformation to the end node
is also added to terminate each process in Figs. 15, 16, 17
and 18.
Mobile Netw Appl
Fig. 12 UPPAAL code
The sensitive data operation matrices F0 , F1 , F2 , F3 , F4 ,
F5 , and F6 in Figs. 15, 16, 17 and 18 can be referenced from
Table 7. The symbol F0 indicates that an operation involving
sensitive data has ended.
In Table 8, d1 − d4 are used to represent the exposure
operations for ID, address, track, and f ace, respectively.
Additionally, d5 − d8 are used to represent the collection
operations for ID, address, track, and f ace, respectively. A
value of 1 for d1 − d8 indicates that the corresponding data
operation exists; otherwise, the value is 0. The sensitive data
operation matrices F0 , F1 , F2 , F3 , F4 , F5 , and F6 can be
described in terms of the values of d1 − d8.
The clock reset sets C0 , C1 , C2 , C3 , C4 , C5 , and C6 ,
shown in Table 9, correspond to the sensitive data operations
in Table 8. We use t1−t8 to denote the clocks corresponding
to d1 − d8, respectively. When d1 − d8 trigger, t1 − t8 are
reset, respectively. In addition, Ct is used to reset the clock
variable t, where t is used to control the clock during service
data communication. The clock t is immediately reset when
communication triggers.
Our prototype obtains related services and basic data
from the business processes, and the user is allowed to set
the service time ranges and select sensitive data. Then, the
prototype generates the corresponding SDTIOA automata
for the user based on the service time ranges and sensitive
data.
6.2 Verification of Timed Privacy Requirements
After the above process, UPPAAL is used to graphically
illustrate this transformation. In UPPAAL, each business
process has distinct d1 − d8 values to describe the cor-
responding sensitive data operations. To describe the time
dependence among data operations, we define t1 − t8
as global clock variables for different business processes.
When d1 − d8 trigger for any business process, t1 − t8 will
be reset, respectively. Each business process also has its own
corresponding clock c to describe the execution time of the
process. U ser represents the user business process, Sys rep-
resents the system business process, C data represents the
citizen information database business process, H data rep-
resents the hospital information database business process,
d c represents the perception layer collection service, and
s q represents the identity query service.

Fig. 13 Workflow for personnel access control for the prevention and control of infectious diseases
Next, as shown in Table 10, timed privacy requirements
are listed and transformed into corresponding formulas in
the UPPAAL query language in accordance with the rules
in Section 3. Then, the model generated by the prototype
can be opened in UPPAAL, along with the timed privacy
requirements transformed into the UPPAAL query language
in accordance with Table 3. Finally, this code is executed
to verify whether the designed scenario meets the relevant
timed privacy requirements.
The verification results produced by UPPAAL are dis-
played as shown in Fig. 19. UPPAAL can verify whether
the model meets the timed privacy requirements of the
user. The privacy requirements in Table 10 describe
the time-constrained data operation authority stipulations
for the given scenario, participants, and services. Addition-
ally, the time-constrained dependencies among data opera-
tions and participants, services, and other data operations
are established. Since this paper focuses on timed pri-
vacy requirements, the time constraints determine whether
Mobile Netw Appl
the requirements are satisfied. Therefore, different time
constraints are given for each privacy requirement during
verification.
As shown in Fig. 19, the privacy requirement
{A[]U ser.d8+ Sys.d8 + C data.d8 + H data.d8 > 0 for
all > 3} is satisfied; that is, all face collection operations
occur after 3 time units in the given scenario. However, the
privacy requirement {A[]U ser.d8+ Sys.d8 + C data.d8
+ H data.d8 > 0 for all > 4} is not satisfied. This
requirement indicates that at least one face data collection
operation should occur before 4 time units have elapsed in
the scenario.
7 Related Works
As service compositions are widely used to execute
complex functions, verification techniques are widely used
to verify the functional and nonfunctional requirements of
Mobile Netw Appl

Fig. 14 UML sequence diagram

Table 6 Communication time ranges of services

Service portType operation Communication activity Time range (s)

Perception layer collection service d c User initiate Invoke 2-10

Receive 1-7
UserCallback onResult Reply 3-6
Onmessage door 5-10
Onmessage alarm 3-5
Identity query service s q System query Invoke 1-2
Receive 1-3
systemCallback onResult Reply 2-4
Onmessage risk 1-3
Onmessage safe 1-2
Medical information inquiry service i q Data query Invoke 2-3
Receive 3-6
 Mobile Netw Appl

Fig. 15 SDTIOA automaton for a user and the corresponding UPPAAL display

Fig. 16 SDTIOA automaton for the system and the corresponding UPPAAL display
Mobile Netw Appl

Fig. 17 SDTIOA automaton for Citizen DB and the corresponding UPPAAL display

Fig. 18 SDTIOA automaton for H ospital DB and the corresponding UPPAAL display

Table 7 Basic data operations for services
portType operation Basic data
User initiate ID, address, track, face
UserCallback onResult sign door, sign alarm
System query ID, face
systemCallback onResult sign safe, sign risk
Data query ID
service compositions. In a service composition, privacy
requirements and time requirements are both important
nonfunctional requirements. As privacy concerns continue
to increase, timed privacy requirements have attracted
widespread attention [16–18]. Here, we present a review
of the major techniques and methods that are most closely
related to our work.
Many works have focused on the nonfunctional require-
ments of service compositions. To improve the quality of
service compositions, Gao et al. [19] proposed a predictive
service monitoring approach to support dynamic service-
oriented software evolution; they reduced the probability of
failure of Web services by ensuring that these services are
of high quality at run time, thereby improving the reliabil-
ity of critical applications. Because business processes are
commonly used to describe service compositions, Gao et al.
[20] proposed a service selection method for business pro-
cess modeling. The appropriate service was selected from a
set of candidate services, and the results were combined to
construct high-quality business processes. Later, Gao et al.
[21] proposed a cost-driven service composition approach
and recommended suitable services for compositions to
ensure a workflow solution with optimal performance, high
reliability, and low cost.
Studies related to the verification of BPEL have focused
on many different privacy requirements [10, 22]. Li et al.
[23] proposed a framework based on graph transformation
to determine whether business processes follow privacy
policies. They used a service privacy policy set described
using the Platform for Privacy Preferences Project (P3P) as
Table 8 Sensitive data operation matrices
Matrix Values Matrix
F0 0,0,0,0 F4
0,0,0,0
F1 1,1,1,1 F5
0,0,0,0
F2 0,0,0,0 F6
1,1,1,1
F3 1,0,0,1
0,0,0,0
Mobile Netw Appl
Table 9 Clock reset sets
Set Clocks Set Clocks
C1 t1, t2, t3, t4 C4 t5, t8
C2 t5, t6, t7, t8 C5 t1
C3 t1, t4 C6 t5
the privacy policy for the service composition and verified
the consistency of the P3P privacy policy and the BPEL
business process. Liu et al. [24] proposed a service-
based private data operation authority as the privacy policy
for a service composition, extended the corresponding
interface automata to model the interface behavior of the
services and verified the consistency of the private data
operation authority and the BPEL process. However, the
studies above considered service compositions involving
only a single service, and the dependencies within the
service composition were not considered. Lu et al.
[25] proposed behavior-aware privacy requirements and
used them as the privacy requirements of a service
composition. BPEL was modeled by extending the interface
automata and verifying the privacy requirements of the
combined behavior dependencies. None of the above studies
considered time constraints on the privacy requirements.
Research on timed service compositions has also
been performed to validate various time requirements.
Mateescu et al. [26] analyzed discrete-time BPEL and
transformed BPEL code into discrete-time transformation
systems. The association rules for activities and time
were defined to expand discrete-time BPEL and express
the relationship between an activity and discrete time in
the developed label migration system. Fares et al. [27]
transformed BPEL into Fiacre and considered timed BPEL
processes. The work of Mateescu and Fares was based
on timed BPEL processes. However, in many service
compositions, there is a corresponding time for each
activity in BPEL, especially communication activities.
These times influence the verification of the overall
service composition time. Song et al. [28] proposed a
timed Petri-net-based verification approach to verify the
time requirements for a BPEL process. They added the
times for services to the service-level agreements. Chama
Values
et al. [29] considered timed BPEL processes and used
0,0,0,0 Durational Action Timed Automata (DATA) to model
1,0,0,1 BPEL processes. The time requirements in BPEL were
1,0,0,0 verified by dividing all activities in a BPEL process
0,0,0,0 into instantaneous activities, specified-time activities, and
0,0,0,0 duration activities. Later, Chama et al. [30] extended their
1,0,0,0
work by modeling BPEL processes using Communicating
Durational Action Timed Automata (C-DATA). C-DATA
can model the communication behaviors of services and
describe the communication times for Web services. None
 Mobile Netw Appl

Table 10 Some privacy requirements and the corresponding formulas in the UPPAAL query language

ID Time-constrained privacy requirement UPPAAL query language Table 3 ID

1 If f ace is collected, the scenario time is greater than 3 A[] U ser.d8 + Sys.d8 + C data.d8 + H data.d8 > 0 imply all > 3 1
2 address collection can occur only in Sys, and the scenario time must be greater than 2 A[] (U ser.d6 + C data.d6 + H data.d6 == 0) and (Sys.d6 imply all > 2) 2
3 The track operation can be A[] U ser.d3 + U ser.d7 + 3
implemented only in the d c ser- Sys.d3 + Sys.d7 + C data.d3 +
vice, and the scenario time must C data.d7 + H data.d3 +
be greater than 2 H data.d7 > 0 imply
(U ser.d c or Sys.d c) and
all > 2
4 f ace must be collected within 5 time units after it is disclosed A[] Sys.d8 or C data.d8 imply (c4¡5 and c4! = all) 4
5 alarm or s q must occur within 6 time units after the collection of I D A[] Sys.alarm or Sys.s q imply (c5 < 6 and c5! = all) 5
6 The business process C data must begin within 3 time units of the disclosure of f ace A[] C data.c == 0 imply c4 < 3 and c4! = all 6

Fig. 19 UPPAAL verification results
of these works considered the time aspects of the privacy
requirements for service compositions.
Currently, BPEL is commonly used to describe ser-
vice compositions. Unfortunately, BPEL cannot describe
nonfunctional attributes, such as probability and communi-
cation time attributes. To address this problem, Gao et al.
[31] proposed a visualization platform to support probabilis-
tic model verification for service compositions by extending
the service probability attributes of BPEL and using the
Probabilistic Reward Labeled Transition System (PRLTS)
to model this probabilistic extension of BPEL. However,
their platform does not allow service time extensions for
BPEL.
With the increasing attention being paid to privacy
requirements, privacy policies that support time constraints
are gradually being considered for service compositions.
The design of a service composition needs to meet the
relevant privacy requirements. To verify timed privacy
Mobile Netw Appl
requirements, it is necessary to extend BPEL to consider
the communication time and use timed automata to model
this extension of BPEL. Unfortunately, formal modeling
and verification are not straightforward for the designers
of most service compositions. Therefore, we are motivated
to implement a prototype that can automatically generate
model-checker-readable code and has a designer-friendly
interface.
8 Conclusion and Future Works
The main contribution of this paper is to propose a method
to verify timed privacy requirements for IoT service com-
positions. First, the structure and data operations of a
service composition are analyzed to formalize the corre-
sponding timed privacy requirements. Second, SDTIOA is
used to model the input BPEL code with time constraints
Mobile Netw Appl
for expressing service composition behaviors. Then, trans-
formation rules are applied to transform SDTIOA automata
into UPPAAL code. Third, the UPPAAL model checker is
employed to verify the timed privacy requirements by run-
ning the transformed code jointly with the timed model and
timing properties. As a possible tool for supporting soft-
ware requirement analysis, the proposed approach allows
system designers to use a model checker without writing
its input code, which is instead automatically generated
via prespecified rules and can be adjusted through user
interactions.
In future work, we will consider the automatic generation
of verification properties and the addition of new graphical
model displays. Moreover, probabilistic behavior will also
be incorporated into an improved model to support the
modeling of random behavior, especially in regard to
uncertainty. Of course, by merging services that do not
handle private data, we can reduce the path of the model.
Meanwhile, we can also increase the path of the model to
support more complex verification of privacy requirements
in association with the concurrent data operations.
Acknowledgements This work was supported in part by the National
Natural Science Foundation of China (NSFC) under Grant No.
61902236 and National Key Research and Development Program of
China under Grant 2020YFB1006003.
References
1. Lemoine F, Aubonnet t, Simoni N (2020) IoT composition based
on self-controlled services. Journal of Ambient Intelligence and
Humanized Computing 11: 5167–5186
2. LeeI J, LeeK (2015) The Internet of Things (IoT): applications,
investments, and challenges for enterprises. Business Horizons
58(4):431–440
3. Jangjaccard J, Nepal S (2014) A survey of emerging threats in
cybersecurity. J Comput Syst Sci 80(5):973–993
4. Constante E, Paci F, Zannone N et al (2013) Privacy-aware web
service composition and ranking. International Conference on
Web Services 10(3):131–138
5. Labda W, Mehandjiev N, Sampaio P et al (2014) Modeling of
privacy-aware business processes in BPMN to protect personal
data. ACM Symposium on Applied Computing, pp 1399–1405
6. Roman R, Najera P, Lopez J et al (2011) Securing the internet of
things. IEEE Computer 44(9):51–58
7. Bertino E (2016) Data privacy for IoT systems: concepts,
approaches, and research directions. International Conference on
Big Data, pp 3645–3647
8. Butun I (2017) Privacy and trust relations in Internet of Things
from the user point of view. IEEE Annual Computing and
Communication Workshop and Conference, pp 1–5
9. Weber RH (2010) Internet of things: new security and privacy
challenges. The Internet of Things 26(1):23–30
10. Bhatia R, Gujral MS (2017) Privacy aware access control: a
literature survey and novel framework. International Journal of
Information Technologies and Systems Approach 10(2):17–30
11. OASIS WS-BPEL Technical Committee, Web Services Business
Process Execution Language Version 2.0 (2007). http://docs.
oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
12. Erl T (2008) SOA Principles of Service Design (Prentice Hall)
13. UPPALL (2019) UPPAAL web help. https://www.it.uu.se/
research/group/darts/uppaal/help.php?file=WebHelp
14. David A, Larsen KG, Legay A et al (2010) Timed I/O
automata: a complete specification theory for real-time systems.
ACM International Conference Hybrid Systems Computation and
Control, pp 91–100
15. Felten EW, Schneider MA (2000) Timing attacks on Web privacy.
Computer and Communications Security, pp 25–32
16. Alur R, Courcoubetis C, Dill D (1990) Model-checking for
real-time systems. Proceedings. Fifth Annual IEEE Symposium
on Logic in Computer Science, Philadelphia, PA, USA, pp 414–
425
17. Focardi R, Gorrieri R, Lanotte R et al (2002) Formal models of
timing attacks on web privacy. Electronic Notes in Theoretical
Computer Science, pp 229–243
18. Song D, Wagner D, Tian X et al (2001) Timing analysis
of keystrokes and timing attacks on SSH. Usenix Security
Symposium, pp 25–25
19. Honghao G, Huaikou M, Hongwei Z (2013) Predictive web
service monitoring using probabilistic model checking. Applied
Mathematics & Information Sciences 7(1L):139–148
20. Gao H, Chu D, Duan Y (2017) The probabilistic model checking
based service selection method for business process modeling.
Journal of Software Engineering and Knowledge Engineering
27(6):897–923
21. Gao H, Huang W, Duan Y, Yang X, Zou Q (2019) Research
on cost-driven services composition in an uncertain environment.
Journal of Internet Technology (JIT) 20(3):755–769
22. Joshaghani R, Black S, Sherman E et al (2019) Formal specifica-
tion and verification of user-centric privacy policies for ubiquitous
systems. International Database Engineering and Applications
Symposium
23. Li YH, Paik H, Benatallah B et al (2006) Formal consistency veri-
fication between BPEL process and privacy policy. Conference on
Privacy, Security and Trust
24. Liu L, Huang Z, Xiao F et al (2010) Verification of privacy
requirements in web services composition. International Sympo-
sium on Data, Privacy, and E-Commerce, pp 117–122
25. Lu J, Huang Z, Ke C et al (2014) Verification of behavior-aware
privacy requirements in web services composition. Journal of
Software 9(4):944–951
26. Mateescu R, Rampacek S (2008) Formal modeling and discrete-
time analysis of BPEL web services. In: Dietzj LG, Albani A,
Barjis J (eds) Advances in enterprise engineering i. CIAO! 2008,
EOMAS 2008. Lecture notes in business information processing,
vol 10. Springer, Berlin
27. Fares E, Bodeveix JP, Filali M et al (2011) Verification of timed
BPEL 2.0 models. In: Halpin T (ed) Enterprise, business-process
and information systems modeling. BPMDS 2011, EMMSAD
2011. Lecture notes in business information processing, vol 81.
Springer, Berlin
28. Song W, Ma X, Ye C et al (2009) Timed modeling and verification
of BPEL processes using time petri nets. International Conference
on Quality Software, pp 92–97
29. Chama IE, Belala N, Saidouni DE et al (2014) Formalization
and analysis of timed BPEL. Information Reuse and Integration,
pp 483–491
30. Chama IE, Belala N, Saidouni DE et al (2017) A timed semantics
for web services composition. International Journal of Business
Process Integration and Management 8(1):64–79
 Mobile Netw Appl

31. Gao H, Miao H, Liu L et al (2018) Automated quantitative

verification for service-based system design: a visualization
transform tool perspective. International Journal of Software
Engineering and Knowledge Engineering 28(10):1369–1397

Publisher’s Note Springer Nature remains neutral with regard to

jurisdictional claims in published maps and institutional affiliations.

Affiliations
Honghao Gao1 · Yida Zhang1 · Huaikou Miao1 · Ramón J. Durán Barroso2 · Xiaoxian Yang3

Honghao Gao
gaohonghao@shu.edu.cn
Yida Zhang
13365659603@163.com
Huaikou Miao
hkmiao@shu.edu.cn
Ramón J. Durán Barroso
rduran@tel.uva.es
1 School of Computer Engineering and Science, Shanghai
University, Shanghai 200444, Peoples Republic of China
2 Faculty of Telecommunication Engineering, University
of Valladolid, Valladolid, Spain
3 School of Computer and Information Engineering,
Shanghai Polytechnic University, Shanghai 201209,
Peoples Republic of China