Observe that, in general, there can be several places in the red cloud, depending on the number of SM states specified as failure states; let's denote such a set of places as P D.
Conversely, the set of operational system states corresponds to the set of DSPN markings Up where none of the places is marked. The definition and computation of such formulas are commonly supported by DSPN tools currently available in the Petri Net community see Appendix C Similar formulas apply to compute availability measures. In the example, the measure to be predicted is the failure occurrence rate of the control application see DAM annotation in the SM of the application in Figure 2.
The choice of the appropriate DSPN solver depends mainly on two factors: a the characteristics of the DSPN model and b the dependability metric to be evaluated. Concerning the first factor, numerical methods derive a system of linear equations from the DSPN model and solve it by using either exact or approximate mathematical techniques [ 16 ].
- Shakespeare: Hamlet. A Student Guide (Second Edition) (Landmarks of World Literature).
- Communication Systems Engineering - Solutions Manual.
- Dakini Teachings: Padmasambhavas Oral Instructions to Lady Tsogyal.
- About tool support.
- Cationic Ring-Opening Polymerization of Heterocyclic Monomers.
- Book Embedded Systems Analysis And Modeling With Sysml Uml And Aadl ?
Unfortunately, existing DSPN analytical methods suffer from the well-known state-space explosion problem. Discrete event simulation can be used as an alternative method [ 17 ]. The second factor affects the type of analysis to be used: transient versus steady state.
For transient analysis, the system behavior is observed during a finite time interval, while for steady state analysis system behavior is observed for a sufficiently large period so that the analysis becomes time-independent. Typically, the reliability survival function is computed under transient state assumption while mean value metrics, such as MTTF, can be estimated in steady state. Let us consider the following question: could the system carry out its computations in the presence of faults due, for example, to software bugs or nodes failures?
In order to answer such a question, the engineer should assess the proposed system design both with and without the fault-masking mechanism. In the first case, the UML design is as shown in Figure 2 , while in the second case the voter is omitted and only one replica is created.
Two different DSPN models will be derived automatically, and the failure occurrence rate will be computed for each one. Two fault input parameters were considered: the replica fault rate and the maximum number of faults that may affect the replicas during the experiment. In both figures, the cases with and without the voter are represented. Figure 6 shows the measure under the one-fault assumption , that is, only one fault may occur during the experiment, so at most one replica is affected.
Figure 7 shows the results in the case when two or three independent faults may occur concurrently. As expected, the application failure rate increases as the number of fault occurrences grows from one to three. Moreover, when the replica fault rate grows, the probability that a replica fault affects the normal application behavior increases, and so does the application failure rate.
On the other hand, when triple redundancy and voting is designed, the application is tolerant to a single replica fault, independently of the replica fault rate Figure 6 , green curve. It is worth noting that the proposed analysis approach is flexible and powerful, especially due to the automation of the model transformation technique. The automatic derivation of DSPN models is flexible enough to easily manage different UML designs that specify different fault-tolerance solutions.
Thus timely feedbacks can be provided to the software engineers when they need to assess dependability solutions for a given design.
- EMBEDDED SYSTEMS: ANALYSIS AND MODELING WITH SYSML, UML AND AADL by KORDON
Paper [ 18 ] extensively surveys works on dependability modeling and analysis of software systems specified with UML. The survey analyses 43 papers from the literature published in the last decade on the topic. Herein, we consider the ones that mainly focus on reliability and availability analysis and propose model transformations which can be automated.
The most comprehensive approach has been proposed in [ 19 , 20 ], where a UML profile for annotating software dependability properties compliant with the taxonomy and basic concepts from [ 3 ] is proposed. A model transformation process derives timed Petri net models via an intermediate model from the annotated UML models. The approach supports the specification of error propagation between components, as well as independent and dependent failures. In particular, it is possible to discriminate between normal and failure states and events, and to assign common failure mode occurrence tags to redundant structures.
The main drawback of this work is the introduction of unnecessary redundant information in the UML model, as sometimes the joint use of more than one stereotype is needed. Pai and Dugan [ 21 ] present a method to derive dynamic fault trees from UML system models. The method supports the modeling and analysis of sequence error propagations that lead to dependent failures, reconfiguration activities, and redundancies. The papers [ 22 — 25 ] address specifically the reliability analysis of UML-based design. D'Ambrogio et al.
Embedded Systems: Analysis and Modeling with Sysml, UML and Aadl
The annotations defined in [ 23 ] are used by Grassi et al. The method uses an intermediate model that acts as bridge between the annotated UML models and the analysis-oriented models. In particular, discrete time Markov process models can be derived for the computation of the service reliability. Finally, the work [ 28 ] proposes a model-to-model transformation technique to support the availability evaluation of railway control systems. The availability model is a repairable fault tree that is automatically generated from the UML models use case, component, and state machine diagrams , properly annotated with MARTE and DAM extensions.
A standard specification framework is yet needed for dependability assessment of UML-based specifications. DAM is a step toward this goal, as it is a comprehensive approach attempting to unify a great number of efforts carried out by the researchers in the last decade. Software quality includes a number of very different NFPs e. We envisage that a future research goal is to devise model transformation techniques that support a comprehensive analysis in presence of conflicting NFPs e. All of these are used by the modeler to assign values to tags, according to the VSL syntax the annotations in Figure 2 show several examples.
Tags of NFP types are characterized by several qualifiers: source defines the origin of the specification such as required, assumed, predicted, and measured ; statQ defines the type of a statistical measure such as a maximum, minimum, or mean ; unit indicates the measurement unit for a given NFP. The entire set of DAM stereotypes, as well as the set of UML metaclasses extended by stereotypes can be found in [ 13 ]. A DAM subset supports the specification of system dependability properties at service level e. Other stereotypes can be used to specify fault-tolerance redundancy structures e.
Finally, some stereotypes enable the characterization of the threats affecting the modelled system e. The former indicates the number of concurrent faults and the latter characterizes the nature of the fault. It also defines new dependability specific types either as specialization of basic NFP types e. A Petri net PN —shown in Figure 9 —is a bipartite graph, in which the vertices can be either transitions or places. The transitions, graphically depicted by bars, represent events that may occur in the system; the places, represented by circles, are used to model conditions.
The directed arcs, shown by arrows, describe which places are pre- or postconditions for which transitions. Places may contain tokens, depicted by black dots; the initial distribution of tokens over the places of a PN is called initial marking. The PN dynamics is governed by the transition enabling and firing rules.
A transition is enabled whenever there is at least a token in each of its precondition places, and it may fires if there are not enabled transitions with higher priority. When it fires, a token is consumed from each of its precondition places and a token is produced in each of its postcondition places see Figure 9. A reachable marking is then a marking reached through the firing of a transition sequence from the initial one.
In Deterministic and Stochastic Petri Nets DSPNs , common metrics are the probabilities associated to the reachable markings, which can be either time-dependent transient metrics or time-independent steady-state metrics. DSPNs are characterized by two types of transitions: immediate and timed. Once enabled, an immediate transition fires immediately while a timed transition has an associated firing delay, which can be a constant value deterministic or a mean value of the negative exponential distribution stochastic.
Place and transition labels have been introduced to enable the net composition. For the modelling step, several tools support UML design. National Center for Biotechnology Information , U. Journal List ScientificWorldJournal v. Published online Sep 3. Petriu 3. Dorina C. Author information Article notes Copyright and License information Disclaimer. Received May 25; Accepted Jun This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. This article has been cited by other articles in PMC.
Abstract Assessment of software nonfunctional properties NFP is an important problem in software development. Introduction Model-driven development [ 1 ] MDD is an evolutionary step that changes the focus of software development from code to models, with the purpose of automating the code generation from models. Open in a separate window. Figure 1. Integrating dependability modeling and analysis in a UML-based software development.
The design model illustrates the following: how dependability techniques can be modeled with UML behavioral diagrams and DAM annotations introduce dependability parameters; how DAM leverages this design for dependability analysis purposes. Figure 2. In order to define the system fault assumptions, a software engineer has to consider the following main issues: which components can be affected by faults and in which states, the maximum number of faults that can concurrently affect the system components, the complete fault characterization, such as the fault occurrence rate.
State Machines Specification Our UML-SMs specification illustrates how the engineer can model specific dependability techniques while describing the system normal behavior.
DAM Specification The fault masking specification i. States Figure 3 a shows the transformation of a simple state with an entry action and a do-activity. Figure 3. Timing Specs The doActivities annotated with corresponding processing demands, are translated into timed transitions, as in Figure 3 a , and the value field of the hostDemand tagged-value is mapped to the input time parameter of the corresponding DSPN transition. Figure 4. Composition of the DSPN subnets over interface places. Figure 5.
Analysis and Assessment Results Let us consider the following question: could the system carry out its computations in the presence of faults due, for example, to software bugs or nodes failures? Figure 6. Figure 7. Related Work Paper [ 18 ] extensively surveys works on dependability modeling and analysis of software systems specified with UML. Conclusion A standard specification framework is yet needed for dependability assessment of UML-based specifications. Appendix A. Figure 8. Introduction to Petri Nets A Petri net PN —shown in Figure 9 —is a bipartite graph, in which the vertices can be either transitions or places.
Figure 9. References 1. Selic B. The pragmatics of model-driven development. IEEE Software. Stephen Kan H. Metrics and Models in Software Quality Engineering. Basic concepts and taxonomy of dependable and secure computing. Queueing Networks and Markov Chains. An introduction to generalized stochastic Petri nets. Microelectronics Reliability. Process algebra for performance evaluation. Theoretical Computer Science.
Embedded Systems: Analysis and Modeling with SysML, UML and AADL
Fault Tree Handbook. Nuclear Regulatory Commission; Automatic verification of real-time systems with discrete probability distributions. Object Management Group. Unified Modeling Language. Software Engineering Institute, Carnegie-Mellon. Final report. Morgan Kaufmann; Software and Systems Modeling.
Merseguer J, Bernardi S. Discrete Event Dynamic Systems.
- Embedded Systems: Analysis and Modeling with SysML, UML and AADL.
- Use AADL to analyze and design embedded systems;
- Nikon D90.
Randell B, Xu J. The evolution of the recovery block concept. One key aspect of model-based development is selecting the appropriate design language to represent the platform-specific architecture. To tune a system architecture, the design language must support multiple analysis approaches so trade-offs can be made across domains.
An architecture design language must also support incremental analysis during the development and multiple levels of fidelity for system evaluation. This incremental aspect allows the architecture specification to be used throughout the lifecycle. AADL Architecture Analysis and Design Language is a standard, extensible architecture-description language that satisfies these requirements. Intended applications include surveillance, avionics, flight management, engine and power-train control, medical devices, industrial process-control equipment, and aerospace.
Compared with other modeling languages, such as SysML and UML, AADL provides strong semantics for standard categories of hardware and software components so that common analysis approaches and well-defined system integration can be accomplished from the specs. The language, designed especially for embedded systems, is extensible through user-definable properties supported with a property sublanguage checked by AADL compilers and through user-defined annexes. Annex extensions can be standardized for industry-wide use. In addition, with operational modes, AADL can also support system-dynamics modeling.
The language has a standard meta-model, graphical definition, and textual language. A number of toolsets support the language, many of them open source. Surveillance-system design In this example, let's first look at the user requirements. The user wants to install a surveillance system to monitor three houses far from the office. No local networks are available in those locations.
To effectively prevent intruders, the detection must be quick, in less than two seconds. This latency spec is an end-to-end, system-level performance requirement. One solution is to deploy three web cameras to monitor these houses. The cameras will send information to the computer in the office building wirelessly. However, the limited bandwidth of wireless communication can't accommodate all the video-stream data.
Related Embedded Systems: Analysis and Modeling with SysML, UML and AADL
Copyright 2019 - All Right Reserved