1 Introduction
2 Background and related work
2.1 The multi-paradigm modelling domain
2.2 Automatic generation of performability models
3 Overview of the approach in the MDE context
3.1 The model-driven multi-formalism knowledge base
-
detecting which are the most proper measures able to evaluate desired NFPs;
-
suggesting a modelling approach in terms of languages to use and of ways to structure high-level models (M-Rules);
-
determining a transformation chain able to generate a multi-formalism model on the base of the high-level one;
-
defining the most suitable solution processes for analysing the multi-formalism model.
-
a multi-DSM is a model that is composed of different DSMs and one or more MIMs (multi-DSM integration model);
-
a multi-formalism is a model that is composed of different formal models and one or more FIMs (formalism integration model).
4 On the integration model
A
, B
and C
(possibly built on different technologies such as fuzzy logic, neural networks and Bayesian networks). In this situation, a multi-formal model can be constituted by a function operating on \(P_A(\mathcal {E})\), \(P_B(\mathcal {E})\) and \(P_C(\mathcal {E})\) as example by calculating the average of the three probabilities:-
ad hoc neutral language (with respect to submodel languages): while the advantage is to have a single M-integration metamodel to define and to interoperate with, the disadvantage of this solution is the necessity to implement new model transformations from and to this ad hoc language;
-
shared language (with respect to submodel languages): M-integration language is one of the languages of the connected models. The advantage is the capability to reach a higher level of integration among connected models and multi-DSM since they share the same language. In this way, existing transformation chains may be reused as they are or by extending them. The problem here is constituted by a hardening of the interoperability issue between the languages.
-
intermediate language by defining an intermediate language, a complex model m-to-n model transformation is decoupled into two transformations. An m-to-1 M2M is defined to generate a model conformant in an ad hoc intermediate language, and then, this model is transformed in n different formalism by a 1-to-n M2M according to the type of analysis to perform. This situation happens, at a different levels of abstraction in the Möbius [19], Klaper [16] and CHESS approaches [34]. While the definition of a single intermediate formalism may ease the construction of a brand new framework, this approach is not able to reuse legacy transformations;
-
no intermediate language an existing M2M can be reused to generate the ith formal model from the jth high-level model as if the multi-formal high-level model were not present. In these cases, the existing transformations are to be extended to cope with the connected models. Few works are present in the scientific literature using this approach; an example is in [31] where two UML profiles and related transformation chains are used to model physical and cyber protection systems: in a joint application of them, the two model transformations are extended to handle concepts of the other profile.
-
hierarchical structure the model solutions are organised into a hierarchy with no cycle. Here it is possible to find an order of invocation of the solvers. An example is represented by the RAMS (reliability availability maintainability and safety) evaluation of the ERTMS/ETCS (the interoperable European railway signalling system) where system-level failure is decomposed into subsystem and component levels (reliability of trains, availability of central controllers, performance failures of communication networks) and then modelled by different formalisms [24]. Another example is in the power system domain [28] where authors use a hierarchical submodel structure and the analysis of the “upper level” model is possible after solving “lower level” ones;
-
cyclic structure the presence of cycles in the dependency relationships among solvers does not allow for a linear solution process but rather than asks for iterative process. The problem of convergence methods and times as well as the problem of the initial condition is open and can be reported to the fixed-point theory. A concrete example of this situation is in [6] where two formalisms are used to model a sensor network: Stochastic Activity Networks for modelling the node and the Markovian Agents for modelling the network. Since the solution of the lifetime of each node depends on the network layout (inter-distance among nodes) as well as the network depends on the evolution of each node, a fixed-point solution process is needed. Another example is in [23] where the author represents a computer controlled water tank by means of bond graph and VDM models: in this case the solution process is based on co-simulation and the two simulators (20-Sim and VDMTools) are orchestrated and executed together.
5 A methodology for performability assessment
Description | Value (mean) |
---|---|
MTTF of a robot arm | \(10^{5}\) h |
MTTF of a robot microcontroller | \(1.35\times 10^{4}\) h |
MTTF of a robot IO card | \(1.35\times 10^{4}\) h |
MTTF of a robot power unit | \(5.5\times 10^{3}\) h |
Time to finish a piece for the Machine 1 | 0.75 h |
Time to finish a piece for the Machine 2 | 1 h |
Time to finish a piece for the Machine 3 | 0.5 h |
Period to check the availability of a machine | 0.05 h |
-
As transformation chains for the
Performance View
andReliability View
, we rely on previous works. Concretely on [25] for the performance transformation and in [9] for the reliability transformation. It is worth observing that the two model transformation techniques have been proposed in the literature, so they are not an original contribution of this work. In the MDM-KB these concepts belong toTransformation::Chain
, while in Fig. 4 they are represented by two grey arrows.
Integration View
(cf., Fig. 4), Language::Integration
in the MDM-KB. Section 7.2 describes the model transformation from the Integration View
to the integration model
. Section 7.3 describes the Performability Solution Process
, which in the MDM-KB is represented by Analysis::SolutionProcess
.6 Performance and reliability modelling guidelines
6.1 Performance modelling
-
structural that can be represented by UML class, component or deployment diagrams, and
-
behavioural that are typically represented by a (set of) sequence or activity diagrams.
6.1.1 Performance view
<<gaStep>>
, and its execTime
tag is used to quantify such consumption (cf., the last four values of Table 1 and the execTime
tagged values of the gaStep
actions in Fig. 6).<<resource>>
stereotype and when more than one resource of a given type is needed then the resMult
tagged value indicates it (see the note symbol in Fig. 5). During workflow execution, resources need to be acquired, in an orderly way, for performing activities; for example, a robot is needed for moving a piece. In the same way, resources need to be released when the activity no longer needs them, so they could be used by another activity, which can be blocked while waiting for the resource availability. In the activity diagram (e.g. Fig. 6), the <<gaAcqStep>>
and <<gaRelStep>>
stereotypes are attached to the transitions that precede and follow the action(s) which need the resource to be executed. Moreover, the usedResources
tag indicates the name of the resources, while the priority
tag indicates the priority of this step for getting such resource.<<gaWorkloadEvent>>
stereotype to the initial node of the activity diagram. In the running example, the workload is closed and it represents the number of raw material and unfinished parts that are loaded into the cell.
<<gaAnalysisContext>>
and the associated tag contextParams
lists the variables, each one characterised by either the in$ or out$ property depending whether it represents an input or an output parameter. In the FMS example, there is an input variable (i.e. N), that represents the initial workload, and an output variable (i.e. thru), that represents the throughput of the system. The latter is assigned to the throughput
tagged value associated with the last step of the FMS workflow.6.1.2 Transformation to a performance model
<<resource>>
components (Fig. 5, e.g. Machine1, RobotSegment1). For each resource component, a GSPN place is associated (Fig. 7, the labelled places Machine1, RobotSegment1). The resMult
tagged value is used to set the initial marking of the place. When no tagged values are provided, a multiplicity one is assumed, then one token is set as initial marking.<<gaWorkloadEvent>>
stereotype is used to specify the workload. In particular, the closed workload population is mapped to the initial marking of the GSPN place representing the initial node of the activity diagram (cf. the tagged value assigned to the population—in Fig. 6—and the initial marking of place start—in Fig. 7).<<gaStep>>
timed actions are translated to timed transitions of the GSPN model; the execTime
tagged value is used to set the transition rate, i.e. the inverse of the value. The <<gaAcqStep>>
(<<gaRelStep>>
) transitions of the activity diagram represent the acquisition (release) of the resources, where the resources to be acquired (released) are specified by the usedResources
tag. Such transitions of the activity diagram are then translated to immediate transitions of the GSPN, that include in their input (output) set the places representing the resources. The priority of the immediate transitions of the GSPN is set to the priority
tagged value annotated to the mapped transitions of the activity diagram. By default, the priority is one and the increasing order criterion is assumed for priority assignment.
<<gaAnalysisContext>>
stereotype is used to declare the variables used in the diagram; the input variables result in either place marking or transition rate parameters in the GSPN model: e.g. in Fig. 6, the variable N is mapped to a place marking parameter. The output variables are translated to GSPN output parameters: e.g. the variable thru is mapped to the throughput parameter associated with the GSPN transition end.6.2 Reliability modelling
-
structural, which can be represented by UML class, component or deployment diagrams, and
-
behavioural, which are typically represented by a single or a set of state machine diagrams.
6.2.1 Reliability view
<<daComponent>>
is used to annotate each entity of the faulty components that can be affected by a thread and interacts with other entities (hardware and/or software) and with the physical world. A component can be made up of other interacting components. We applied this stereotype both on the considered faulty component (i.e. RobotSegment1) and on its subcomponents (i.e. arm, control unit, microcontroller, power and IO card). Among the different tags related to the stereotype <<daComponent>>
, we underline the usage of the resMult
tag to indicate the number of available instances of a component or subcomponent, and the fault
and repair
tags to specify, respectively, the intrinsic mean time to failure (MTTF) and mean time to repair (MTTR) of the component. Figure 8 shows the annotation of the reliability parameters, reported in Table 1, on the component diagram of the RobotSegment1. Observe that the MTTR associated with the control units is a variable, i.e. cuMTTR.
<<daRedundantStructure>>
is used to annotate the set of components that should not be a single point of failure, and the related tag ftLevel
is used to specify the minimum number of components needed to guarantee the service. In the running example, the subpackage ControlGroup has been tagged as a <<daRedundantStructure>>
, in which at least one ControlUnit is necessary to guarantee the service.failure.MTTF
tag, associated with the faulty robot component, in the UML component diagram.<<daStep>>
with the tagged value kind
equal to failure
. The subsequent transition startRepair, which leads the subcomponent in the repair state, is stereotyped by <<daActivationStep>>
, while the last one is a <<daReplacementStep>>
that models the replacement of the power, microcontroller and IO card components to terminate the maintenance.<<gaAnalysisContext>>
in order to declare the variables used in the diagram. Observe that the variable X is also used; however, it has not been declared in the diagram (cf., Fig. 8). Indeed X is a global variable, which is also used in the integration view, and therefore, it will be declared at a higher-level modelling view. We will come back to this issue in the next section.6.2.2 Transformation to a reliability model
<<daComponent>>
(e.g. RobotSegment1, ControlUnit in Fig. 8) and by <<daRedundant
Structure>>
(i.e. ControlGroup). Each <<daComponent>>
is translated to a node of the tree that can be either a basic event—i.e. a leaf—or a middle event—i.e. an intermediate node or the root. In particular, it is mapped (1) to as many middle events as the value of resMult
, if the fault
tagged value is null, or (2) to as many basic events as specified by the resMult
value, if the fault
tagged value is not null. Hence, arm, IO card, microcontroller and power generate basic events, whereas control unit and RobotSegment1 generate middle events. Packages stereotyped by <<daRedundantStructure>>
generate other middle events (Control Group, in the example). Gates are added to the RFT: an OR gate if the <<daComponent>>
does not belong to a <<daRedundant
Structure>>
(RobotSegment1 and ControlUnit), an AND gate if the <<daComponent>>
belongs to a <<daRedundant
Structure>>
with ftLevel=1 (ControlGroup). Arcs are then added to complete the RFT structure according to the hierarchical structure modelled in the UML component diagram.
<<daComponent>>
associated with the state machine (i.e. ControlUnit). Then, a repair arc is drawn to the repair box from all the basic events that are “ancestors” of the middle events triggering the repair box (i.e. in this case, power, microcontroller and IO card).<<daComponent>>
.
7 The approach for performability analysis
Integration View
(cf., Fig. 4). Section 7.2 describes the model transformation from the Integration View
to the integration model
. Section 7.3 describes the Performability Solution Process
of the methodology. The proposed case study is used as running example.
7.1 Integration view
-
The performance view (system-level) models the system process under normal (i.e. no faulty) condition together with the used resources, whereas
-
The reliability view (resource-level) focuses on the internal structure of the faulty resources, and the failure and repair processes of their subcomponents.
<<daStep>>
(from the DAM profile) and the resource failure rate is specified by the fault. occurrenceRate
tag.<<daFaultGenerator>>
and assigning a value to the numberOfFault
tag.<<gaAcqStep>>
and the failed resource is indicated by the usedResources
tag. Moreover, the priority of the fault process is assigned to the priority
tag.usedResources
tagged value annotated to the transition from the action to the final node. Two stereotypes are assigned to the activity diagram: <<daFaultGenerator>>
and <<gaAnalysisContext>>
to specify the maximum number of resource failures as input variable and to declare the variable (in$nf), respectively.fault.occurrenceRate
tag, where a variable X is used in the expression. The latter will be declared as a global variable as described in the following.Declaration | Usage | ||
---|---|---|---|
Package | View A | View B | |
CP | contextParams =(in$X) | NFP1 = (value=X) | NFP2 = (value=X) |
CEP | contextParams =(in$X) | NFP1 = (value=X) | NFP2 = (expr=f(X)) |
CR | contextParams =(inout$X) | NFP1 = (value=X,source=calc) | NFP2 = (value=X) |
CER | contextParams =(inout$X) | NFP1 = (value=X,source=calc) | NFP2 = (expr=f(X)) |
<<gaAnalysisContext>>
and by assigning the variable name to the contextParams
tag. Depending on the type of integrator operator, the variable can be declared either as input (in) or input/output (inout).X
is an output variable) and it is an input variable for the view B (in this case, no value needs to be set to the source property).X
within the performability analysis context of the running example. In particular, the stereotyped package consists of the three modelling views:-
integration view, including the model of Fig. 12.
7.2 The performability formal model
-
The mapping of AD transitions that model resources acquisition (i.e. the
<<gaAcqStep>>
stereotyped transitions annotated with theusedResources
andpriority
tagged values) to immediate GSPN transitions characterised by input places modelling the resources; and -
The mapping of variables (i.e. the
contextParams
tagged value associated with the<<gaAnalysis
Context>>
stereotyped diagrams) to GSPN input/output parameters.
numberOfFaults
tagged value of the <<daFault
Generator>>
stereotyped diagram, andfault.occurrenceRate
tagged value of the <<daStep>>
stereotyped actions.<<daStep>>
action to a timed transition, which is characterised by a firing rate equal to the fault.occurrenceRate
tagged value.GaAnalysisContext
, that includes all the views (i.e. performance, integration and reliability views); therefore, the variables declared in the context of the performability view can be used in all the included models.