Stochastic Activity Networks Templates: Supporting Variability in Performability Models

Model-based evaluation is extensively used to estimate performance and reliability of dependable systems. Traditionally, those systems were small and self-contained, and the main challenge for model-based evaluation has been the efficiency of the solution process. Recently, the problem of specifying and maintaining complex models has increasingly gained attention, as modern systems are characterized by many components and complex interactions. Components share similarities, but also exhibit variations in their behavior due to different configurations or roles in the system. From the modeling perspective, variations lead to replicating and altering a small set of base models multiple times. Variability is taken into account only informally, by defining a sample model and explaining its possible variations. In this paper we address the problem of including variability in performability models, focusing on Stochastic Activity Networks (SANs). We introduce the formal definition of Stochastic Activity Networks Templates (SAN-T), a formalism based on SANs with the addition of variability aspects. Differently from other approaches, parameters can also affect the structure of the model, like the number of cases of activities. We apply the SAN-T formalism to the modeling of the backbone network of an environmental monitoring infrastructure. In particular, we show how existing SAN models from the literature can be generalized using the newly introduced formalism.


I. INTRODUCTION
Formal methods have been extensively used to estimate performance and reliability metrics of computer systems. They are especially useful for assessing non-functional properties of critical systems, for which experimental approaches are not always applicable. In fact, model-based evaluation [1] has the advantage of not exercising the real system, which may be dangerous, costly, or not feasible.
Traditionally, critical systems have been mostly isolated and monolithic, and the main challenge for model-based evaluation has always been the solution process, in term of efficiency of state-space generation and accuracy of results. More recently, the problem of specifying and maintaining complex models in convenient ways has increasingly gained attention. Modularization is an established approach in reducing the complexity in the specification of analysis models. However, one of the rising challenges consists in handling variability [2], [3] across system components.
Cyber-Physical System-of-Systems (CPSoS) [4]  interactions between them. Many of these elements share similarities, but at the same time they have a slight different behavior due to their individual configuration or role in the system. When modeling the entire system, these variations lead to replicating and altering a small set of base models multiple times. Furthermore, due to dynamicity and evolution [4], changes to components configurations are introduced over time, and models need to be updated to reflect such changes. Improving variability means anticipating certain kind of changes and make them easier to be implemented [3].
In the dependability [5] and performability [6] domain many works have proposed approaches to automatically generate formal models from design models (e.g., UML models) enriched with information on the failure/repair processes of components. The idea behind these works is that software and systems engineers can take advantage of formal models without being proficient in them, because model transformations embed the knowledge of experts in an automated "push-asingle-button" tool [7], [8].
While these approaches are good in providing an application-specific abstraction to users of a certain domain, they are not flexible enough to relieve dependability experts from the effort of modeling complex systems. In fact, they have two main limitations: i) they are tailored to the needs of system designers and not to those of formal methods experts, and ii) different transformation algorithms needs to be defined for different problems or classes of systems.
In this paper we address the problem of variability in performability models from the point of view of modeling experts, as opposed than targeting software and systems engineers. The focus is on specifying models considering variability, that is, anticipating and facilitating changes. We propose a new formalism based on Stochastic Activity Networks (SANs) [9] that we call Stochastic Activity Network Templates (SAN-Ts). The idea is to leave some parts of a SAN model unspecified, and to make them depend on parameter values. Differently from what is done for example in the Möbius tool [10], in SAN-T models the parameters can also affect the structure of the model, like the number of cases of an activity. This paper complements our recent work in [11], in which we defined a framework to improve reuse of performability models. The approach is based on the concept of libraries of model templates that interact using well-defined interfaces and composition rules, specified using the Template Models Description Language (TMDL). The framework proposed in [11] is not tied to a specific modeling formalism and can be applied in general to models that are composed by superposition of state variables (i.e., "state sharing"). To achieve such generality, we assumed as prerequisite the existence of i) a template-level formalism, ii) an instance-level formalism, and iii) a concretize function, which generates instance-level models from a template-level model. The work in this paper enables the application of the TMDL framework with SANs, since we introduce here a template-level formalism based on SANs and the associated concretize function.
The rest of the paper is organized as follows. In Section II we introduce the background and we discuss the related work. In Section III we present the overall idea of SAN templates with a running example, and then in Section IV we give their formal definition. In Section V we define how concrete SAN models can be derived from a SAN template (i.e., the concretize function). Then, in Section VI we apply the formalism to the modeling of the backbone network of an environment monitoring system. In Section VII we summarize how this paper complements the the TMDL framework introduced in [11]. Finally, conclusions are drawn in Section VIII.

II. BACKGROUND AND RELATED WORK A. Model-Based Evaluation
Model-based evaluation [1] is a well-known technique for the verification and validation of complex systems. It consists in estimating system-level metrics through formal models, which typically include stochastic behavior. Modelbased evaluation plays a key role in the assessment of critical systems and large-scale infrastructures, where exercising the real system is not feasible or risky.
Various kind of models can be used for this task. Approaches are typically categorized in combinatorial models and state-space models [1]. Combinatorial models include simple formalisms that describe which combinations of component failures lead to system failure, e.g., Fault Trees (FTs) [12]. These models are very popular in the industry, as they are simple to understand and they can be evaluated with wellknown formulas. However, they assume independent events and therefore they cannot represent complex interactions between components or dynamic behavior.
On the other hand, state-space models explicitly represent the different states of a system and the possible transitions between them. While being more powerful, these models can quickly become very complex, leading to well-studied problems like state-space explosion and stiffness [1]. One of the most popular formalisms are Stochastic Petri Nets (SPNs) and their numerous extensions [13]. In particular, the work in this paper is based on SANs, which can be considered a variant of SPNs [9], although adopting a different terminology (e.g., activity instead of transition).
SANs are widely used across different domains. For example, recent work has employed models based on SANs to evaluate control strategies of smart grids [14], the availability of a backbone network [15], the performance of scheduling algorithms [16], different metrics [17] and performability [18] in the railway domain, and the quality of experience of a distributed interactive application [19].

B. Stochastic Activity Networks (SAN)
A formal definition of Stochastic Activity Networks (SANs) was given by Sanders and Meyer in [9]. We recall here the basic definitions, on which we will base later for the definition of SAN templates.
An Activity Network (AN) is an eight-tuple [9]: where P is a finite set of places; A is a finite set of activities; I is a finite set of input gates; and O is a finite set of output gates. The function γ : A → N + specifies the number of cases for each activity, that is, the number of possible choices upon execution of that activity. τ : A → {timed, instantaneous} specifies the type of each activity; ι : I → A maps input gates to activities; and o : O → {(a, c) | a ∈ A ∧ c ∈ {1, 2, . . . , γ(a)}} maps output gates to cases of activities. Similarly to Petri nets, places can hold tokens. The number of tokens in each places determines the state of the network, also called its marking. More formally, if S is a set of places (S ⊆ P ), a marking of S is a mapping µ : S → N. The value µ(p) is the marking of place p, i.e., the number of tokens it holds. The set of possible markings of S is the set of functions An input gate is defined as a triple (G, e, f ), where G ⊆ P is the set of input places associated with the gate, e : M G → {0, 1} is the enabling predicate of the gate, and f : M G → M G is the input function of the gate. An output gate is a pair (G, f ), where G ⊆ P is the set of output places associated with the gate, and f : M G → M G is the output function.
An input gate g = (G, e, f ) holds in a marking µ if e(µ G ) = 1. We say that an activity a is enabled in a marking µ if all the input gates associated with it hold. Intuitively, the behavior of the network is regulated by the following rules: i) when an activity is enabled it can fire; ii) instantaneous activities have priority over timed activities; and iii) when an activity fires, one of its cases is selected. When an activity a fires in marking µ, the new marking is given by µ = f On (. . . f O1 (f Im (. . . f I1 (µ)))), where g i = (G Ii , e Ii , f Ii ) is the i-th input gate of the activity, and o j = (G Oj , f Oj ) is the j-th output gate of the selected case. That is, all the functions of all the input gates are computed first, and then all the functions of the output gates are computed. The complete characterization of the SANs behavior can be found in [9].
A marking in which no instantaneous activities are enabled is a stable marking. An activity network is stabilizing if, essentially, there is no marking from which it is possible to fire an infinite sequence of instantaneous activities.
Given an AN that is stabilizing in some initial marking µ 0 ∈ M P , a Stochastic Activity Network (SAN) is formed by defining functions C a , F a , and G a for each activity a, where: C a ∈ C is a function specifying the probability distribution of its cases; F a ∈ F is a function specifying the probability distribution of its firing delay; and G a ∈ G is a function that describes its reactivation markings [9].
That is: SANs have an intuitive graphical notation (see [9]). Places are represented as circles, instantaneous activities as thin bars and timed activities as thick bars. Input gates are represented as left-pointing triangles, while output gates as right-pointing triangles. Cases are represented as small circles next to the activity; if an activity has only one case, it is omitted from the diagram. Input arcs are considered a special case of input gate, in which the predicate e holds when there is at least one token in the connected place, and the function f removes one token from that place. Similarly, an output arc is a special case of output gate in which the function f simply adds one token to the connected place.
Evaluation metrics are defined using reward structures, and under certain conditions the stochastic process underlying a SAN has an exact solution. If it is not the case, they can be evaluated by discrete-event simulation. Practical support for the SAN formalism is provided by the Möbius [10] tool.

C. Related Work
The problem of simplifying the construction of performability models has been approached in different ways in the literature.
Different variants of the original Petri Nets (PNs) formalism [20] have been defined, some of them enabling more compact and reusable specifications. For example, Colored Petri Nets (CPNs) [21] allow tokens to be distinguished, by attaching information to them. In CPNs tokens can be of different data types, called colors. Hierarchical CPNs support modularization by means of substitution transitions, i.e., a transition is replaced by a whole subnet in a more detailed model. Stochastic Reward Nets (SRNs) [22] also contain features that allow for a compact specification of SPNs, e.g., marking dependency, variable-cardinality arcs, priorities, etc.
These PNs extensions fold a complex Petri net model into a compact specification. They can address variability aspects to some extent, for example combining different initial markings and marking-dependent properties. However, variable aspects are mostly limited to the behavior and not to the structure of the model. Besides that, these formalisms are used to specify concrete models, albeit complex, that can be directly analyzed. Using the terminology in [11], CPNs and SRNs are instancelevel formalisms. This paper focuses on specifying templatelevel models, from which different instances can be derived.
As mentioned earlier, SANs can also be considered a variant of SPNs [9]. In their Möbius implementation [23] they support tokens having different datatypes, including structured datatypes. The input gate and output gate primitives can be used to specify arbitrary complex predicates for the enabling of transitions (called activities) and for the effects of transition firings. SANs models can be composed using the Rep/Join state sharing formalism [24]; however, which state variables are composed, and how, must be specified manually. The Möbius implementation of SANs permits using variables, which however can only impact the behavior of the model and not its structure. In this paper we define parametric ("template") SAN models, whose structure and behavior can depend on parameters.
A well-established research line focuses on applying Model-Driven Engineering (MDE) [25] techniques to automatically derive dependability models from UML models or similar representations, e.g., see [7], [8], [26]. However, such approaches typically provide an application-specific abstraction to users of a certain domain, and then they automatically derive formal models defined by an expert. Instead, our approach is targeted at dependability modeling experts, and it focuses on constructing models that could be reused across different domains or systems.
It should be noted that existing modeling frameworks, e.g., Möbius [23] or CPNTools [21], provide some means for reducing the specification effort. For example, they both allow multiple instances of a submodel to be reused. However, instances have identical structure, and each of them still needs to be manually connected to the rest of the model.
The recent work in [27] proposed Dependency-Aware Replication (DARep), an efficient method to replicate SAN models while still maintaining their identity, as opposed to the traditional replica operator in which instances are indistinguishable. The method uses a matrix to specify dependencies across statevariables of instances, and an efficient algorithm [28] to reflect them in the discrete-event simulator generated by Möbius.
The work on DARep is probably the most similar to our proposal. However, there are two main differences between the two approaches. First, DARep focuses on replicating identical SAN models, with alterations in the state-variables shared between them. In this aspect, our approach is more general, since i) it allows variability in the entire structure of a SAN model (instead than on "interfaces" only), and ii) it permits to generate SAN instances that can be composed by either Join or Rep operators. Second, the main motivation behind DARep is to improve the performance of simulation solvers [27], while we focus on the formalization of the concept of SAN Template itself, and we consider solution methods out of the scope of this paper.

III. MOTIVATING EXAMPLE
In this section we introduce an example to motivate the approach we are proposing. We first provide an overview of the reference system, then we discuss the challenges in modeling it using ordinary SANs, and finally we extract a running example to be used in the rest of the paper.

A. The BEDCS System
The Brazilian Environmental Data Collection System (BEDCS), also known with its Portuguese name SBCDA (Sistema Brasileiro de Coleta de Dados Ambientais), is a largescale environmental monitoring infrastructure owned by the National Institute of Space Research of Brazil (INPE) [29], [30]. Among the other applications, it supports the monitoring of the Amazon rainforest, both in Brazil as well as in other South American countries [31], [32].
The BEDCS is composed of three segments: space, ground, and application ( Figure 1). The application segment features a deployment of approximately 800 automated platforms scattered throughout the country and at sea (oceanographic buoys). In each of these PCDs (Plataforma de Coleta de Dados -Data Collection Platform, DCP) groups of sensors are installed for collecting different kinds of environmental data. The space segment consists of satellites, which carry a data-collecting transponder and periodically receive the data collected by the DCPs. Satellites also collect data by themselves, typically Earth images or physics-related measurement like density of electrons. Finally, the ground segment consists of ground stations for the reception of data from satellites, a center for remote control and tracking, and a mission center responsible for data processing and dissemination to the end users. The data is stored at the mission center, where they are processed and made available to end users through a web interface.
Due to the large number of applications relying on it [34], the system has to fulfill strict non-functional requirements; among others: availability of the platform to end-users; reliability of the data collection functionality, in order not to miss data points; performance of data transmission, both DCPs to satellites and satellites to ground station. Note that low performance in data transmission may also cause data loss, in case the buffers of satellites or DCPs become full.
The system, which is in operation since the 90's, has gained importance in the Brazilian and International community over time, resulting in an increasing demand for system modernization, for the provision of new services, and for improvements in performance and dependability. In this context, model-based evaluation is a valuable tool to help engineers understanding the impact of maintenance actions, and to support informed design decisions.
The BEDCS is one of the two case studies of the ADVANCE project [35], whose objective is to define new Verification & Validation techniques for Cyber-Physical Systems. Within the project, the system is being analyzed according to different points of view, supporting INPE in its evolutive maintenance efforts.

B. Challenges
The BEDCS is a representative example of a CPSoS: it is composed of a large number of components, with complex interactions between them that possibly change over time, and it is organized as System-of-Systems (SoS) architecture. That is, its Constituent Systems (CSs) may have different governance and ownership (e.g., satellites and sensors deployed by thirdparties) and they are put together to provide a higher goal that could not be provided by individual CSs alone.
Model-based evaluation is the primary evaluation means for this kind of system, due to the difficulties in applying experimental approaches, especially at system level. However, when modeling systems like BEDCS with SANs or similar formalisms, practical issues concerning the scalability of these models arise. Scalability concerning the solution process is a well-known problem that has been addressed in several ways in the literature; e.g., see [1], [36]. Instead, in this paper we address the challenges concerning the specification and maintenance of such models.
In this perspective, the main challenge is represented by the large number of similar components, which exhibit variability aspects due for example of different roles, location, or configuration. Furthermore, these aspects can change over time, leading to what in software engineering is known as variability in space and time [37]. In the BEDCS case, variability exists in different aspects. As a simple example, each satellite may use a subset of the available communication protocols, which has impact on which DCPs it may receive data from. More in general, different kinds of relations and dependencies may exist between system components. Often, a certain relation or global behavior can be described in a general way; however, its practical instance varies depending on the number and kind of components involved, and possibly other context-dependent parameters.
To some extent, this problem is being addressed by modularization. When modeling a complex system with SANs, the complete model is typically built out of a well-defined set of submodels representing specific aspects of the system, which are then composed by state sharing following predefined rules. Basic building blocks are first identified (e.g., components or functions), and then examples of the corresponding SAN models are described. Variability is addressed by defining these building blocks in a general way, as "templates", explaining how variants can be derived from a general abstract structure.
In the literature, this kind of approach has been used by different authors in the construction of models based on SANs, but always in an informal way. See for example [14], [15], [19], [38]- [43]. In fact, while a SANs can be used to accurately describe the model of a specific instance of the building block, with its specific characteristics, the general structure of the model and its possible variations can only be described with examples or with descriptions in natural language. This is especially true when variations include modifications to the model structure, e.g., number and names of places or number of cases of activities.
The SAN-T formalism that we define in this paper aims to solve this problem, by providing a formal way to specify a general (i.e., template) SAN model and its possible variations. The idea is to provide an abstract representation of multiple SAN models that exhibit similar structure and behavior, but having some systematic differences that can be parameterized. Then, from such base skeleton, different variants can be generated, based on the values assigned to its parameters.

C. Running Example: The User Model
We introduce here one of the building blocks of the BEDCS model, which will be used as running example in the rest of the paper.
Among the other things, the BEDCS model has to take into account for different service kinds (e.g., raw picture data transfer or telemetry to satellites), having different characteristics but a similar behavior. Also, different kinds of user models are needed, having access to different subsets of these services, and accessing services with different probabilities. Metrics of interest are both related to performance (e.g., throughput) and reliability (e.g., disconnection probability).
The basic idea behind SAN-Ts is visualized in Figure 2. The SANs models in Figures 2(a)-(b) are adapted from [41], in which we modeled a vehicular network. We chose this example for its simplicity; a more extensive application of the SAN-T formalism is described later in Section VI.
The behavior represented by the two SAN models in Figures 2(a)-(b) is the following. Each user is initially in idle state, and may then request a network service. With a certain probability they can request one of the services that are available to them, by adding a token in the corresponding place. While the service is being delivered, a token stays in the place with the corresponding identifier (e.g., Req1 or Req6). The request can fail or be dropped; in these cases a token is received in the corresponding place, and the user returns to idle state. The figure shows two instances of the model of an user: an internal user may request services 1, 6, and 7, with the respective probabilities, while a press user may request services 3 and 7 only, with different probabilities.
It is clear that the two models have a similar structure. In fact, they differ only by: i) the number of services available to the user, ii) the identifiers of those services, and iii) the probabilities of the user requesting each service. The structure of these two models can be generalized by establishing the following informal rule: "Create one place ReqX for each of the services that are available to the user, and name them according to the identifier of these services. The activity Request should have the same amount of cases as the number of ReqX places, and each of them should have an output arc connecting the case to the corresponding ReqX place." This would result in a SAN "template", depicted in Figure 2(c), which abstracts the common structure among models of different users.
It should be noted that the template in Figure 2(c) does not represent the instances in Figures 2(a)-(b) only, but in general any SAN model that follows the same pattern. Having to maintain similar models that only differ from some details is a common issue in the modeling of complex systems. The actual formal definition of the User SAN-T model discussed above is provided later in Section IV-E.

A. Preliminary Definitions
We first introduce some basic notations that will be used in the rest of the paper. In particular, the following definitions clarify what is a parameter of a template model, and how it connects to the rest of the formalism.
We adopt the definitions of sort, operator, term and assignment from the ISO/IEC 15909 standard [44], which apply to a wide range of PN-based formalisms, including SANs.
According to this formalization, the set of possible values held by a place is defined by its associated sort (i.e., type).
A many-sorted signature is a pair (S, O), where S is a set of sorts and O is a set of operators, together with their arity. The arity is a function O → S * × S, where S * is the set of finite sequences over S, including the empty string ε. The arity function defines, for each operator, the number and sort of its input parameters (S * ), and the sort of the produced result (S). An operator can be denoted as o (σ,s) , where σ ∈ S * are the input sorts, and s ∈ S is the output sort. Constants are operators with empty input sorts, and are denoted as o (ε,s) or simply o s .
We denote with ∆ a set of parameters; an element of ∆ of sort s ∈ S is denoted with δ s . ∆ s ⊆ ∆ is therefore the set of parameters of sort s.
Terms of sort s ∈ S may be built from a signature (S, O) and a set of parameters ∆. Intuitively, these are all the possible expressions of sort s made of any legit combination of operators in O and parameters in ∆ [44]. The set of terms of sort s is denoted by TERM(O∪∆) s . To simplify the notation, in the rest of the paper we will use TERM s , unless there are ambiguities on the adopted O and ∆ sets.
A many-sorted algebra H = (S H , O H ) provides an interpretation of a signature (S, O). For every sort s ∈ S there is a corresponding set of values H s ∈ S H , and for every operator Given a many-sorted algebra H, and many-sorted parameters in ∆, an assignment for ∆ under H is a family of functions ξ, comprising a function ξ s : ∆ s → H s for each sort s ∈ S. The concept of assignment may be extended to terms, thus obtaining the family of functions Val ξ comprising the function Val s,ξ : TERM s → H s for each sort s ∈ S [44].
To support the subsequent definitions, we require the existence of at least the "integer", "real", "boolean", "set of integers", and "set of reals" sorts, in which we consider sets to be ordered. Formally, we assume a signature (S, O), such that {Int, Real, Bool, OrderedSet{Int}, OrderedSet{Real}} ⊆ S, and O contains the common operators applicable on such sorts. In particular, besides the standard arithmetic operators, in the rest of the paper we will use the size operator, |x|, which returns the number of elements in a set x, and the element at operator, x[i], which returns the i-th element in a set x. The corresponding many-sorted algebra is and O H containing the set of functions corresponding to operators in O, which are not detailed here for simplicity.

B. SAN-T Formal Definition
Based on the previous definitions, we can now introduce the formal definition of SAN-T. Formally, a Stochastic Activity Network Template (SAN-T) is a tuple: where ∆ is a set of parameters, and elements marked with a tilde accent,·, are modified versions of elements existing in plain SANs (see Section II-B), reformulated to take parameters into account. In more details: • ∆ is the sorted set of parameters of the template. •P is a finite set of place templates. A place template can be seen as a placeholder for multiple places that, in a regular SAN model, would be strongly related to each other and would vary in different instances of the same template. Based on parameters' values, a template place will be expanded to a precise set of concrete places. Place Req in Figure 2(c) is an example of place template. Formally, a place template is defined as a pair (τ, k), where τ is the name of the place, and k ∈ TERM OrderedSet{Int} is its multiplicity. Evaluating the term k with respect to an assignment ξ identifies a set of integer indices K ⊂ N. Such indices determine the set of places to which, with the given assignment of parameters, the place template is expanded. Normal places (i.e., those always expanding to a single place of ordinary SANs) are those for which Val ξ (k) = {1} for any assignment ξ. •Ã is a finite set of activity templates. •Ĩ is a finite set of input gate templates. •Õ is a finite set of output gate templates. •γ :Ã → TERM Int specifies the number of cases for each activity template. For any activity templateã ∈Ã, evaluatingγ(ã) with respect to an assignment ξ yields an integer number, which determines the number of cases of a under that assignment, i.e., Val ξ (γ(ã)) ∈ N. •τ :Ã → {timed, instantaneous} specifies the kind of each activity template, exactly as in ordinary SANs. •ι :Ĩ →Ã maps input gate templates to activity templates. •õ :Õ →Ã maps output gate templates to activity templates. In order to completely define the elements of a SAN-T, the concept of marking needs to be extended. In particular, we need to take into account for the existence of place templates. In general, the marking of a place template is not a single value (like in ordinary SANs), but a function, which associates a value to each index of the place template. We call this function the marking template of a place.
Let Based on these definitions of marking and marking template, most of the other elements of a SAN-T can be defined by adapting the definitions in [9] to made dependent on the assignment of parameters ξ. In the following, we denote with Ξ the set of all the possible assignments.
As in ordinary SANs, an input gate template defines an enabling condition for an activity template, and an input function that specifies how the marking is altered by the firing of the activity. An input gate template will always result in a single input gate in the concrete SAN model. Still, the projected output gate may depend on the assignment of parameters. Formally, an input gate template is defined as a triple (G,ẽ,f ), whereG ⊆P is the set of input places associated with the gate,ẽ :MG × Ξ → {true, false} is the enabling predicate, andf :MG × Ξ →MG is the input function.
In ordinary SANs, an output gate defines an output function that is executed upon the firing of an activity. Differently from an input gate, it is associated to individual cases of an activity. In SAN-Ts, an output gate template has a similar purpose. However, since the number of cases of an activity template is not known beforehand, the gate is connected directly to the activity. When a regular SAN is generated from the template, an output gate template will be expanded to multiple concrete output gates, depending on the number of cases of the activity to which it is connected.
Formally, an output gate template is a pair (G,f ), wherẽ G ⊆P is the set of output places associated with the gate, andf :MG × N × Ξ →MG is the output function of the gate. It should be noted that the output functionf depends on the index of the case of the associated activity template (N), as well as on the assignment of values to parameters (Ξ).
The probability of cases of an activity template is given by the case distribution assignmentC, which defines a functioñ Cã ∈C for each activity templateã ∈Ã. Such functions also depend on parameters, thusCã :MP (ã) × N + × Ξ → [0, 1], whereP (ã) is the set of input and output places of the activity. For the model to be well-formed,Cã(µ, i, ξ) = 0 should hold ∀i > Val ξ (γ(ã)), i.e., the probability of cases beyond those generated with the given assignment ξ should be zero.
Similarly, the firing time of activities is given by the activity time distribution assignmentF , which defines a functionF a ∈F for any timed activity template a, with F a : R ×MP × Ξ → [0, 1]. That is, the probability of a certain firing time (R) depends on the marking (MP ) and on the parameters assignment (Ξ).
The reactivation function of activity templates is given by the reactivation function assignmentG, such that for any timed activity template a, functionG a ∈G defines the reactivation markings, withG a :MP × Ξ → ℘(MP ) and ℘(MP ) denoting the power set ofMP .
Finally, the initial marking of a SAN-T should also depend on the assignment of values to parameters. For this reason, it is defined by the functionμ 0 : Ξ →MP . It should be noted that the original definition of SANs requires the initial marking µ 0 (ξ) ∈MP to be a stable marking in which the network is stabilizing (see Section II-B). However, because in SAN-T the actual structure of the model is not completely specified until a value is assigned to all the parameters, we relax this constraint. Well-formedness checks on the structure of the resulting SAN models can be performed at the time of instantiation, based on existing techniques that are applied to ordinary SAN models (e.g., [45]).

C. Arc Templates
One of the distinguishing features of SPNs and their extensions is their convenient graphical notation, which permits describing most aspect of a model using a diagram. In particular, SANs use input arcs and output arcs, represented by arrows in the diagram, as the graphical representation of particular cases of input gates and output gates, respectively. Following the same idea, we propose a graphical representation of a subset of the new concepts introduced in SAN-Ts.
1) Output Arc Templates: In ordinary SANs, an output arc connecting activity a and place p represents an output gate whose function simply adds a token to place p.
To use a similar notation in SAN-Ts we need to take into account for the varying number of cases of the activity, and for the multiplicity of the place. Without additional information, the interpretation of a "normal" output arc is ambiguous. For example, it is not clear whether the arc should add one token to all the instances of the place template, or only to one of them. Therefore, we extend this concept introducing output arc templates, which can be used in SAN-T models.
Considering a SAN-T model as defined above, an output arc template connects an activity template a src ∈Ã to a place template p dest ∈P . An output arc template has a label that defines the function f of the corresponding gate template in a compact way. The syntax of the label is given by the following grammar.
Here the term is a placeholder for the index of the case of the associated activity template a src , while ⊗ is a placeholder for the index of the concrete places generated from place template p dest .
The semantics of such label expressions is as follows. A label may specify an unconditional expression, out , or a conditional expression, int → out / out .
When an unconditional expression is specified, it means that the same expression is used for all the places derived from place template p dest . The expression may specify that the marking of the place(s) should be set to a certain value, int , or that a number of tokens should be added to the marking, + int . The actual value is specified by a term (i.e., expression) of integer type. Note that in this case the integer terms may also include the and ⊗ operators, and may therefore depend on them. For example, the label "+3⊗" specifies that to each place derived from p dest it should be added a number of tokens equal to three times its index.
A conditional expression allows specifying a different expression for a specific instance of the place template. The expression int → out means that for the place template with index int the specification out will be used, while for all the other ones the marking is left unchanged. An explicit assignment can be added for the other places, instead of leaving them unchanged, by adding a second out element. For example, the label "1 → +2/0" means that for instance of place p dest having index 1 the marking should be incremented by two tokens, while for all the other instances it should be set to zero.
When no label is specified, the label "+1" is assumed, that is, one token is added to all the instances of the p dest place. Note that when the place template has multiplicity {1} and the number of cases of the transition is fixed, an arc with label "+1" corresponds to a "normal" output arc.
2) Input Arc Templates: A similar approach can be followed for input arcs. However, in this case the label must also specify the input predicate, in addition to the input function.
An input arc template connects a place template p src ∈P to an activity template a dest ∈Ã. The label of an input arc template is defined by the following grammar, where ⊗ is a placeholder for the index of places derived from p src .
The label of an input gate template may specify explicitly both the predicate and the input function, [ pred ] func , or specify the input function only, − int , and leave the predicate implicit. The input function func is specified in a similar way as for output arc templates: it can set the marking of all the places to a specific value, or it can subtract a certain number of tokens.
The predicate is composed of a quantifier and a condition. The condition cond specifies a condition on the marking of the connected place template, while the quantifier specifies on which instances of that place the condition should hold.
The predicate ∀ cond is true when the markings of all the concrete places derived from p src satisfy the condition cond . The predicate ∃ cond is true if at least one place instance satisfies that condition. Finally, the predicate int cond is true if the marking of the place instance having index corresponding to int satisfies the condition. When the predicate is stated explicitly, the input function is applied only to places satisfying the condition, that is: all the places in the case of ∀ cond ; only the places satisfying the condition in the case of ∃ cond ; and only the place with index int in the case of int cond . For example, the label "[∃ = 1] 0" means that: i) the predicate is true if at least one of the place instances has exactly one token, and ii) the function sets the marking of all the place instances satisfying the condition to zero.
When no pred term is specified, the input function may only remove a certain number of tokens, and the predicate is considered to hold if all the place instances contain at least that number of tokens. If no label is specified at all, "−1" is assumed, that is, the gate is enabled if all the instances of the place contain at least one token, and the function removes one token from all of them. Note that, similarly as for output arc templates, an arc with label "−1" connected to place template with multiplicity {1} corresponds to a "normal" input arc.

D. Graphical Notation
Besides the extended notation for input arc templates and output arc templates, we also adopt some conventions in the graphical representation of SAN-Ts models. The main difference in notation is that "template elements" in the model are surrounded with a dashed line, as previously shown in Figure 2(c). With template elements, we mean model elements that have some kind of variability, in particular: i) place templates having non-unary multiplicity (i.e., k = {1}), ii) activities with a variable number of cases (i.e.,γ(ã) is not constant), iii) input gate templates connected to a place template with non-unary multiplicity, iv) output gate templates connected to a place template with non-unary multiplicity, and v) output gate templates connected to an activity having a variable number of cases.
Highlighting elements that have variability helps the modeler to better understand which parts of the model will change in the concrete SANs instances, that is, which parts of the model carry some variability aspect.

E. Example: User SAN-T Model
We now apply the proposed formulation of SAN-Ts to the running example introduced in Section III-C. A SAN-T model that abstracts the behavior of a generic User model has been shown, informally, in Figure 2(c). Here we show how such SAN Template can be specified in a formal way, according to the definitions given in the previous section.
Two parameters can be identified for the User template model. The first, s, identifies the number and indices of services that the user can access, and it is therefore of type  "set of integers". The second, pb, determines the probabilities of being selected of the different services, and it is of type "set of reals".
The variable elements of the model are essentially the activity template Request, its associated output gate template OGRequest, and the place template Req (see Figure 2(c)). The Request activity has a variable number of cases, given by the cardinality of the array of integers assigned to parameter s, and each of these cases is selected with a probability given by parameter pb. Place template Req is expanded to a number of concrete places that is again given by the cardinality of s. The selection of case i of the Request activity template results in the addition of a token in place Req i .
The graphical representation of the model, using the proposed notation, is shown in Figure 3. The output arc template connecting activity Request and place Req has the label "s[ ] → +1", which can be interpreted as follows: "The i-th concrete output gate adds one token to the instance of the Req place having index s[i], and leaves the other places unchanged." The complete formal specification of the User SAN-T model is provided in the following.
As a support to the specification in this section, and to those provided later, we define the following functions in F N , which can thus be used to define the marking of the SAN-T (see Section IV-B).
The formal specification of the User SAN-T model is then as follows.
Some aspects should be highlighted to better understand the above specification. All the place templates have multiplicity 1, except for place Req; similarly, all the activities have a fixed number of cases except for activity Request. The initial marking is 1 (actually, the function f 1 ) for place template Idle, and 0 (actually, the function f 0 ) for all the others. The set of input gate templates,Ĩ, also contains the input arcs of the model, which are considered a special case of input gate. In particular, ArcInFail and ArcInDrop are the input arcs connected to the Fail and Drop activities, respectively. Similarly, the set of output gate templates,Õ, also contains the output arcs ArcOutFail and ArcOutDrop.
The case distribution function assigns probability 1 to the first and only case of activity templates Drop and Fail, while for the cases of the Req activity template the probability of the i-th case is given by the i-th value of parameter p, which is of type "set of reals". For simplicity, the elementsF and G have not been detailed in the above specification, and they are discussed in the following.
In the reference model [41], the firing time of the Request activity is regulated by an uniform distribution, thusF Request is set accordingly. None of the activities are reactivating, that is,G Request =G Fail =G Drop = ∅, or, in other words, the set of reactivating markings is empty.
To fully specify the SAN-T, we need to complete the specification of input gates templates and output gates templates. We give here the specification of OGrequest only, which is the only output gate template in the User template that includes variability: Summarizing, the above specification means that the function of the output gate associated with the i-th case should put one token into the instance of the Req having index s[i] and remove all the tokens in the other instances (f 1 s[i] ), and leave the other places unchanged.

V. GENERATION OF SAN-T INSTANCES
To actually use SAN-T models for model-based evaluation, concrete instances must be generated, by assigning values to their parameters. Such instances, which are ordinary SAN models, can be evaluated in isolation, or composed into larger models using the TMDL framework [11] or the plain Rep/Join formalism [24].

A. Overview
Instances are generated by the concretize function, described in the following, which generates an ordinary SAN model from a from a pair (S ∆ , ξ). That is, it generates a SAN model from a SAN-T model S ∆ and an assignment of values to its parameters ξ.
Given a SAN-T S ∆ : S ∆ = (∆,P ,Ã,Ĩ,Õ,γ,τ ,ι,õ,μ 0 ,C,F ,G), and a parameter assignment function ξ, the concretize function generates a SAN model S ξ : The rest of the section describes how its element are derived from the SAN-T specification. We separate the presentation of the algorithm in two parts: i) concretization of the individual places, markings, and gates; and ii) concretization of the overall model structure. In all the following definitions, ξ is the assignment of parameters from which the instance should be generated.
B. Places, Marking, and Gates 1) Places: For each place template in the SAN-T model, one or more "normal" places are created in the instance model. How many places are created, and with which indices, is given by applying the assignment function on the multiplicity of the place template.
Formally, given a place templatep = (τ, k) ∈P of the SAN-T model, and being Val ξ (k) = {a 1 , . . . , a m } the indices obtained from applying the assignment function to the multiplicty specification, the places {τ ξ a1 , . . . , τ ξ am } are created in the concrete SAN model.
In the following we denote with Π(p, i) ∈ P ξ the i-th concrete place originating from place templatep. That is, Π(p, i) = τ ξ ai . 2) Marking: From any given marking of a SAN-T model a unique mapping to a marking of the generated SAN instance can be identified. Essentially, this is done by applying the marking template function to the index of the generated places.
Formally, given a marking of the SAN-T model,μ ∈MP , the marking µ ξ ∈ M P of the instance model is defined as: where: That is, the marking of the i-th place (τ ai ) generated from place templatep is obtained by applying marking template function (fp) to the index of the concrete place (a i ).
Given a markingμ ∈MP of the SAN-T model, we denote the corresponding marking µ ξ ∈ M P of the generated instance as Γ(μ). Conversely, given a marking µ ξ of the concrete (generated) SAN model we denote as Γ −1 (µ ξ ) the corresponding markingμ of the originating SAN-T.
3) Input Gates: Each input gate template of the SAN-T model is translated to exactly one input gate in the SAN instance. Given an input gate templateg = (G,ẽ,f ) ∈Ĩ, we denote with α(g) the corresponding input gate g ξ = (G ξ , e ξ , f ξ ) ∈ I ξ in the concrete SAN model, which is obtained as: That is, the input places of the concrete input gate, G ξ , are all the places generated from input place templates inG; the input predicate applied to a marking Γ(μ) is the result of applying the assignment function to the predicate of the gate template; and the input function applied to marking Γ(μ) is the input function of the gate template applied on markingμ and assignment ξ. 4) Output Gates: Differently from input gate templates, each output gate template may be expanded to one or more concrete output gates. The number of concrete output gates that should be generated depends on parameters, and more specifically, from the parameter that controls the number of cases of the connected activity.
Given an output gate template (G,f ) ∈Õ, we denote with β(g, i) the i-th output gate (G ξ i , f ξ i ) ∈ O generated from it in the SAN model, which is obtained as: That is, the output places G ξ are all the places generated from output place templates inG, and the output function applied to marking Γ(μ) is the output function of the gate template applied on markingμ, index i, and assignment ξ.

C. Overall SAN Definition
We can now provide the complete specification of the SAN derived from a SAN-T S ∆ and an assignment ξ. That is, we can precisely define all the elements in Equation 8, as follows: γ ξ (a) = Val ξ (γ (ã)); , 1), . . . , β(g, Val ξ (γ (ã))) |ã =õ(g)}; τ ξ =τ ; ι ξ (α(g)) =ι(g), ∀g ∈Ĩ; o ξ (β(g, i)) =õ(g), ∀g ∈Õ, ∀i ∈ {1, . . . , Val ξ (γ (ã))} ; The rationale behind the above derivation can be summarized as follows: i) the set of places P ξ is given by all the places derived from all the place templates inP ; ii) the set of activities remains unchanged; iii) the function γ, which specifies the number of cases of an activity, is the result of applying the assignment function to theγ function; iv) there is an input gate in I ξ for each input gate template inĨ; v) each output gate template inÕ is expanded to a certain number of output gates, given by the number of cases of the activity to which it is connected; vi) the function τ that determines if an activity is timed or instantaneous remains unchanged; vii) if an input gate template is connected to an activity template, then its concrete projection is connected to the projection of the activity template; viii) if an output gate template is connected to an activity template, then all its concrete projections are connected to the projection of the activity template; and ix) the initial marking µ ξ 0 is given by the initial marking of the SAN-T model, applied to the assignment ξ. Furthermore: • For each functionCã in the case distribution assignment C, a corresponding function C ξ a is included in C ξ , defined as C ξ a (Γ(µ), k) =Cã (µ, k, ξ) , ∀µ ∈ MP , ∀k ∈ N + . • For each functionFã in the activity time distribution assignmentF , a corresponding function F ξ a is included in F ξ , defined as F ξ a (Γ(µ), r) =Fã(µ, r, ξ), ∀µ ∈ MP , ∀r ∈ R. • For each functionGã in the reactivation function assign-mentG, a corresponding function G ξ a is added to G ξ , defined as G ξ a (Γ(µ)) = Γ(μ) |μ ∈G a (μ) ∀µ ∈MS.

D. Example: Instances of the User SAN-T
Following the concretize algorithm described in the previous section, we show here how it is possible to derive multiple instance of the User SAN Template defined in Equation 5 and depicted in Figure 2(c).
In particular, we show how the two concrete SAN models of Figure 2(a) and Figure 2(b) can be derived by different assignments of parameters. We define two different assignment functions, ξ UserInternal and ξ UserPress , which will result in the generation of the two SAN instances: The generation of the two instances follows a similar process, and for this reason we show only one of them in details. The SAN model UserInternal is derived by the template-assignment pair (S User , ξ UserInternal ), resulting in the following SAN model, where ActivityName(k) denotes the k-th case of the (concrete) activity ActivityName.  (1)), Elements F ξ and G ξ are not discussed in details, since their derivation is straightforward for this model. Also, as discussed before, the are no reactivation markings and therefore the functions G Request , G Drop , and G Fail are in this case the empty function.
It is instead worth detailing the processing of the output gate template OGRequest, which is affected by variability. In fact, in the SAN-T model it is connected to an activity template with a variable number of cases.
According to Equation 13, the number of concrete output gates that are generated from each output gate template is given by Val ξ (γ (ã)), whereã is the associated activity template. In our case, Val ξUserInternal (γ (Request)) = 3, and therefore three output gates are created: OGRequest 1 , OGRequest 2 , and OGRequest 3 . Each of these output gates is connected to the corresponding case of the Request activity (see o ξ in Equation 15).
The definition of each output gate, in terms of its input places and output function, is obtained by Equation 12. For the UserInternal instance they are defined as follows.
Each of the three gates adds a token to the corresponding place generated from place template Req, basically corresponding to the output arcs appearing in Figure 2(a).

VI. APPLICATION TO THE BEDCS NETWORK
In this section we show how the proposed SAN-T formalization can be used to model a real system. We apply the formalism to the modeling of the BEDCS, and in particular we discuss here the modeling of its backbone network.
To demonstrate the generality of our formalism, we base the BEDCS network model on the work in [15], in which the objective of the authors was to evaluate a backbone network in Norway, detailing failure correlation between system components. The model in [15] is based on SANs, and it has been defined in a modular way as typically done in the literature. However, as discussed in the motivations for the present work, in [15] elements are only described by examples, because they include variability aspects that cannot be represented using SANs alone.
Here we show how the SAN-T formalism can accurately define such SAN-based models, including their variability aspects. It should be noted that the authors of [15] defined their models without any collaboration with the authors of this paper, and they are not involved in this work.

A. Models of the Backend Network
We focus here on the modeling of the ground sector, and in particular of the backbone network connecting the ground stations. In fact, the ground segment is currently composed of four ground stations located in different states of Brazil: two receiving stations, in Cuiabá (MT) and Alcântara (MA), the mission center in Natal (RN), and the remote control center in São José dos Campos (SP) [33]. The two closest stations are more than 1000 km apart.
As mentioned above, we adopt the approach of [15] to model the BEDCS backbone network. That work fits particularly well to our problem, because the authors provided models for different architectural options, including traditional network infrastructures, as well as those based on Software Defined Networks (SDNs). Furthermore, the model takes into account for different kinds of correlation between component failures, due to e.g., physical proximity.
The modeling approach in [15] defines different kinds of building blocks for the system model, grouped in two categories: Component Blocks and Dependency Blocks.
The Component Blocks are simple SAN models that represent physical components of the system architecture. In particular, the authors consider a "template" model for a Link, an IPRouter, a SDNSwitch, and a SDNController. The variability in these models is given only by the rates associated with the firing of activities, and the probabilities associated with their cases. Therefore, these models can be represented by plain SANs.
The Dependency Blocks are used to model the occurrence of dependent failures between components. The model considers 7 kinds of dependencies between components: i) Geographical Proximity (GEO), when a small geographical distance results in common sensitivity to bad weather and natural disasters; ii) Physical Proximity (PHY), which causes a strong failure correlation (e.g., blackout); iii) Common O&M (COM), in which the Operation & Maintenance (O&M) is actually the GEO IG_GF OG_GR GEO_F GEO_R Working_S2 Figure 4: Example of the GEO building block specified with SANs, for two components. Figure reproduced from [15].
same for multiple network elements; iv) Misconfiguration (MIS), when elements share the same configuration or have a correlated logic; v) Compatibility Issue (CIS), when a simultaneous failure may occur on multiple network elements due to incompatibility issues among them; vi) Homogeneous Equipment (HEQ), that is, when a failure happens in a network element, another element with the same equipment may likely fail as well; and vii) Traffic Migration (TMI), that is, when a network element fails, it could happen that the replacement network element is not able to take over. Specific SAN models that represent these dependencies are "plugged" in the overall system model, according to the scenario to be represented. While these models have been described with examples in [15], they have variability that cannot be expressed with plain SANs, for example in terms of how many components, and which ones, are involved in the dependency.

B. Modeling with SAN-Ts
We discuss here how SAN-Ts can be used to formally specify such dependency blocks, in particular for the GEO and TMI dependencies. Models for the other dependencies can be defined in a similar way.
1) GEO Dependency Block: The original GEO dependency block as defined in [15] is depicted in Figure 4. The general idea of the block is as follows.
Places Working_S1 and Working_S2 represent the working state of the two components involved in the dependency, in this case two SDN switches (S1 and S2). If place Working_SX contains a token it means that the corresponding component is currently working. When both components are working, the activity GEO_F is enabled, meaning that the GEO common cause failure may occur. Once the failure has occurred, restoration is possible after some time, represented by the timed activity GEO_R. Restoration makes the involved components working again, by adding a token to the Working_SX places.
This block has been defined, as an example, for two components only. However, the GEO dependency may involve three or more switches and, in general, any number of components. The block can be generalized, informally as follows: "For each switch X involved in the dependency create a place Working_SX. The enabling predicate of the input gate IG_GF is true when all the places Working_SX contain a token, and the input function removes all the tokens from those places. The output function of gate OG_GR adds a token to all the Working_SX places." Using the proposed SAN-T formalism, the generalized "template" version of the block can be defined in a precise way, as follows. The corresponding graphical representation of the model is depicted in Figure 5(a) using gates, and in Figure 5(b) using the compact notation with arc templates. The SAN-T model has three parameters: n, the identifiers of the components involved in the dependency; λ f , the rate of occurrence of the GEO failure; and λ r , the restoration rate.
As in the previous examples, theG GEO F andG GEO F functions are empty, as none of the activities is reactivating. The firing distributions are negative exponential distributions based on the λ f and λ r parameters, that is,F GEO F (t) = 1 − e −λ f ·t andF GEO R (t) = 1 − e −λ r ·t . The gates GEO_FtoGEO and GEOtoGEO_R correspond to the two arcs incoming to and outgoing from the GEO place, respectively, which are "normal" arcs as in ordinary SANs. Conversely, the gates IG_GF and OG_GR are where the variability in the behavior resides, and its definition is thus detailed in the following.
2) TMI Dependency Block: The example in Figure 6 shows the introduction of the TMI dependency among two SDN switches. The idea is that upon software failure of one of them, there is a probability that traffic migration also causes the second switch to fail. This dependency does not actually add a new block to the system model, but instead it modifies the existing SAN models of the involved components.
The model in Figure 6 shows the SAN models of the two switches (S1 on the left, S2 on the right), and a new output gate OG_SW that represents the dependency. With respect to the normal model of the switch, a new case is added to the failure activity (SW_F_S1 and SW_F_S2), and it is connected to the newly introduced OG_SW output gate. It should be noted that the figure contains a slight abuse of notation (as in the original paper), because in principle an output gate can be connected to only one activity. We consider therefore two identical copies of the gate, each connected to one of the two activities.
As in the previous case, this dependency can span multiple switches; more in general, each switch can affect a different subset of the switches in the system. This dependency can be generalized and formalized by modeling the SDN switch as a SAN-T. Which switches will be affected by the TMI dependency, and whether the dependency must be represented at all, will be specified by the parameters of the template. A graphical representation of the resulting SAN-T model is provided in Figure 7, while its formal specification is provided in the following. SAN-TSwitchTMI = (∆,P ,Ã,Ĩ,Õ,γ,τ ,ι,õ,μ0,C,F ,G) The template has five parameters: k, the index of the switch represented by the instance; J, an array of identifiers of other switches that can be affected when the switch fails; p TMI , the probability that the TMI dependency occurs; and λ f and λ r as failure and repair rates of the switch, respectively.
Places Working_S and Failed_SW_S are template places, and their multiplicity is given by the union of index of the switch and those of the switches that should be affected by the TMI failure. That is, the generated SAN instances would contain a place Working_Sk and a place Failed_SW_Sk for the switch represented by the instance, and a place Working_Sj and Failed_SW_Sj for each other switch j ∈ J that can be affected by the dependency.
Gates Working_StoSW_F, Failed_SW_StoSW_R, and SW_RtoWorking_S correspond to the arc templates depicted in the figure. Their specification is given using the notation introduced in Section IV-C and thus they are not further detailed here. The specification of output gate template OG_SW is detailed in the following. Basically, for the first case of the activity it adds one token only to the place with the same index as parameter k, and for the second case it also adds a token to the places corresponding to the affected switches, and removes the token from their Working_S place.   Figure 8: Workflow of the TMDL framework for the automated generation of performability models [46].

VII. THE TDML FRAMEWORK
The work in this paper complements the TMDL framework that we defined in [11]. In this section we briefly recall it, and discuss the relation with the work in this paper.
The idea behind the TMDL framework is organized in three steps: i) there exist a library of parametric reusable submodels, defined with a template-level formalism, and called model templates; ii) based on the scenario to be modeled, a set of templates is selected and proper parameters are assigned; and iii) models in the instance-level formalism are automatically generated and assembled to obtain the overall system model. The corresponding workflow is detailed in Figure 8. In Step #1, a library of reusable model templates is created by an expert. In Step #2, the different system configurations that should be analyzed are defined in terms of "scenarios". Scenarios are composed of model variants, that is, a selection of model templates with their parameter assignment. In Step #3 all the needed model instances are automatically created and assembled, thus generating the complete system model for each scenario. Note that the steps in the workflow are not strictly sequential. In particular, the creation of the model library is performed once, and the library is stored for future access. What makes the model templates reusable is that they have well-defined interfaces and parameters. Briefly summarizing, interfaces specify how they can be connected to other templates, while parameters make it possible to derive different concrete models from the same template. A model template has a specification (of its parameters and interfaces), and an implementation.
The specification of a template is provided with the TMDL, a Domain-Specific Language (DSL) specifically defined for that purpose. The implementation of a template can be atomic or composite. A composite implementation simply specifies which other templates can be composed and how, and it is also specified with the TMDL. The implementation of an atomic template should be given using a template-level formalism, that is, a modeling formalism that defines partially specified models. Conversely, we call instance-level formalism the modeling formalism concretely used for the analysis, generated in Step #3 (e.g., "normal" SANs).
In [11] we introduced some assumptions, both for simplicity but also to keep the approach independent of a specific modeling formalism. In particular, we assumed that for a certain instance-level formalism (e.g., SANs) it was possible to define: i) a corresponding template-level formalism, to specify model templates; ii) a concretize function that, given a model in the template-level formalism and an assignment of values to its parameters, generates a model in the instancelevel formalism; and iii) a notion of compatibility between the TMDL specification of a template (i.e., interfaces and parameters) and its implementation with the template-level formalism.
In this paper we have provided a formal definition of Stochastic Activity Network Templates (SAN-Ts), and of the corresponding concretize function. These definitions enable the application of the TMDL framework considering SANs as the instance-level formalism.

VIII. CONCLUSIONS
In this paper we proposed a formal definition of Stochastic Activity Networks Templates (SAN-T), a formalism that generalizes SANs with the addition of variability aspects. SAN-T models define abstract models depending on parameters, from which concrete SAN models can be generated by assignment of values. Differently from other approaches, in SAN-Ts parameters may also affect the structure of the model, e.g., the number of places in the model or the number of cases of an activity. This formalism aims to simplify the specification of generic building blocks for complex models based on SAN, which is a common problem in the literature.
We demonstrated the applicability of the formalism by using it for the generalization of SAN-based models present in the literature. The proposed formalization can accurately describe the variation points present in the models, and at the same time provide a compact notation, thanks to the proposed extensions to the graphical notation of SANs.
This work complements our work in [11], in which we defined an approach to simplify the composition of models based on SPNs. As current and future work, we are working on two parallel directions. The first is to apply the methodology for the actual evaluation of a real system. In this paper we showed parts of the model of the BEDCS systems, a largescale infrastructure for environmental monitoring in Brazil. Further work is ongoing, in collaboration with the National Institute of Space Research of Brazil (INPE), within the ADVANCE project [35].
We are also working on providing tool support for the proposed formalism, to facilitate its application by other researchers. A prototype editor for SAN-Ts models, based on the Eclipse Modeling Framework (EMF) and the Sirius modeling tools is being developed as open source software. The architecture of the editor and tool under development has been presented in [46].