Integrating variability and safety analysis models using commercial UML-based tools

Software Product Line Engineering (SPLE) has been proven to reduce development and maintenance costs, improving the time-to-market, and increasing the quality of product variants developed from a product family via systematic reuse of its core assets. SPLE has been successfully used in the development of safety-critical systems, especially in automotive and aerospace domains. Safety-critical systems have to be developed according to safety standards, which demands safety analysis, Fault Tree Analysis (FTA), and assurance cases safety engineering artefacts. However, performing safety analysis, FTA, and assurance case construction activities from scratch and manually for each product variant is time-consuming and error-prone, whereas variability in safety engineering artefacts can be automatically managed with the support of variant management techniques. As safety is context-dependent, context and design variation directly impact in the safety properties changing hazards, their causes, the risks posed by these hazards to system safety, risk mitigation measures, and FTA results. Therefore, managing variability in safety artefacts from different levels of abstraction increases the complexity of the variability model, even with the support of variant management techniques. To achieve an effective balance between benefits and complexity in adopting an SPLE approach for safety-critical systems it is necessary to distinguish between reusable safety artefacts, whose variability should be managed, and those that should be generated from the reused safety artefacts. On the other hand, both industry and safety standards have recognized the use of model-based techniques to support safety analysis and assurance cases. Compositional safety analysis, design optimization, and model-based assurance cases are examples of techniques that have been used to support the generation of safety artefacts required to achieve safety certification. This thesis aims to propose a model-based approach that integrates modelbased development, compositional safety analysis, and variant management techniques to support the systematic reuse and generation of safety artefacts in safety-critical software product line engineering. The approach contributes to reduce the effort and costs of performing safety analysis and assessment for a particular product variant, since such analysis is performed from the reused safety artefacts. Thus, variant-specific fault trees, Failure Modes and Effects Analysis (FMEA), and assurance case artefacts required to achieve safety certification can be automatically generated with the support the model-based safety analysis and assurance case construction techniques.

The growing size and complexity of software in embedded systems poses new challenges to the safety assessment of embedded control systems. In industrial practice, the control software is mostly treated as a black box during the system's safety analysis. The appropriate representation of the failure propagation of the software is a pressing need in order to increase the accuracy of safety analyses. However, it also increase the effort for creating and maintaining the safety analysis models (such as fault trees) significantly. In this work, we present a method to automatically generate Component Fault Trees from Continuous Function Charts. This method aims at generating the failure propagation model of the detailed software specification. Hence, control software can be included into safety analyses without additional manual effort required to construct the safety analysis models of the software. Moreover, safety analyses created during early system specification phases can be verified by comparing it with the automatically generated one in the detailed specification phased.

Brake is a safety critical system for railway vehicles and brake failures have caused many catastrophic accidents in the history. Detailed accident investigation reports are available and National Transportation Safety Board (NTSB) also makes safety recommendations to Federal Railroad Administration and the industry. However, there is limited research on how to improve the brake safety from the perspective of design, system integration and safety analysis. In this paper, a framework for braking safety design and analysis is introduced, which includes four parts: failure alarming system, safety design, safety analysis and preventative maintenance. For failure alarming, according to the severity level, the failures will be notified to the operator, to Operation Control Center (OCC) or saved for the maintainer. For safety design, redundant design for fail-safe feature, automatic braking, brake release, weight control, ergonomics design for easy operation and maintenance are discussed and several application examples are illustrated. In the safety analysis section, Preliminary Hazard Analysis (PHA) as a semi-quantitative analysis, Failure Modes, Effects, and Criticality Analysis (FMECA) as a bottom-up method and Fault Tree Analysis as a top-down method are used. The hazards details, system assurance actions and closure references are recorded in the Hazard Tracking Log (HTL) to ensure all the safety related items are well tracked and documented. Preventative Maintenance (PM) which is regularly performed on the brake components to lessen the likelihood of failing is also discussed in combination with the reliability prediction and safety analysis for a balance of safety and economy. The safety design framework and principles introduced in this paper can also be applied into other railway systems, such as Propulsion, Signaling, Doors, etc. and may provide insights to similar industries such as automotive, energy and so on.

Most embedded software in the consumer electronics is generally developed through derivation from legacy software. Many new projects are derived from preexisting ones, through modification of functionality, optimization of performance and application new features. Particularly in the digital AV (audio & video) domain, the rise of 'digital convergence' has lead to a need for the functionality of products to be integrated and unified across different products. In this situation, a product line approach might be more efficient and effective rather than a product-oriented approach. The characteristics of this environment make the product line approach ideal for the digital AV domain. In this paper, we present our experience of designing product line architecture as a common, reference architecture in the digital AV domain. We describe our development process with application on a case project. We also show concrete principles and guidelines to design and build a software product line in consideration of the characteristics of the digital AV domain. We developed guidelines with our experience and domain knowledge in the digital AV domain mainly focused on reusability, maintainability and flexibility. We believe that concrete design principles and guidelines can significantly enhance those attributes in the productization. As a case study, we describe how to find, extract and develop core assets of the product family against our process and guidelines. We found candidates of architecture and core assets, and then extracted target architecture via re-engineering. With the analysis information and domain knowledge of legacy system, we developed a reference architecture with commonality and variability of the target domain. We used the term 'software platform' for the reference architecture and set of core assets as an implementation of software product line. We evaluated the platform against the guidelines as a design guideline itself and quality attribute as well.

BackgroundThe software product lines (SPL) enable development teams to fully address a systematic reuse of shared assets to deliver a family of similar software products. Mobile applications are an obvious candidate for employing an SPL approach. This paper presents our research outcomes, based on empirical data from an industry-level development project. Two development teams were confronted with the same functionalities set to be delivered through a family of native mobile applications for Android and iOS.MethodsEmpirical data was gathered before, during and after a year of full-time development. The data demonstrate the impact of a SPL approach by comparing the SPL and non-SPL multiple edition development. One family of products (Android apps) was developed using an SPL approach, while another (iOS apps), functionally the same, was developed without employing an SPL approach. The project generated a volume of raw and aggregated empirical data to support our research questions.ResultsThe paper reports a positive impact of an SPL approach on product quality (internal and external) and feature output per week. As data shows, it also increases the delivery of functionalities (240% in 6 more editions), while investing the same amount of effort needed for a single-edition development. As a result of system-supported separation of development and production code, developers had a high confidence in further development. On the other hand, the second team delivered less new functionalities, only two new application editions, and lower software quality than the team that manages multi-edition development by employing an SPL approach.

Software Product Lines are growing as a systematic way for achieving reuse in software companies. It involves three processes: domain engineering, application engineering and management. In domain engineering, assets that will be reused by products are developed, composing the core assets. In this context, the product line architecture, also called Domain Specific Software Architecture (DSSA), is an essential member in the collection of core assets. A good DSSA increases the probability of the success of applications that will be instantiated from it. In order to design a good DSSA, a process should be followed to manage domain’s variability and commonality. On the other hand, companies that are moving from single system development to software product lines need systematic activities for taking advantage of existing assets to develop a DSSA. Thus, this paper presents a systematic review on domain design approaches, which can be useful for companies to understand the current scenario, and to choose a more suitable one or adapt them for their needs.

Architectural design modeling has emerged as a discipline in a complex system development. To implement early safety analysis, techniques for architectural design have been extended to concern the safety property. Various safety standard profiles, quantitative and qualitative analysis methods are proposed for assessment. However, few of them focuses on the feedback of the safety properties or analysis results on the adjustment to improve original architecture. In this paper, we present an approach to combine safety analysis with architecture modeling. First, we extend the meta-model of our architecture description language - Breeze/ADL with safety elements for design. Second, safety specifications are generated from Breeze/ADL, and then to be converted into Open FTA for FTA (Fault Tree Analysis). Our Breeze/ADL also supports rule definitions to adjust the architecture, to cope with safety problems. Moreover, model checking will be applied to verify the correctness of the adjustment. Finally, the tool Breeze/SA demonstrates the feasibility of our approach.

A software product line (SPL) usually involves a shared set of core assets and a series of application products. To ensure consistency, the evolution of the core assets and all the application products should be coordinated and synchronized under a unified evolution process. Therefore, SPL evolution often involves cross-product propagation and synchronization besides application derivation based on core assets, presenting quite different characteristic from the evolution of individual software products. As software architectures, including the product line architecture (PLA) and application architectures, play a central role in SPL engineering and evolution, architecture-based evolution analysis is a natural way for analyzing and managing SPL evolution. In this paper, we explore common practices of architecture evolution and the rationale behind in industrial SPL development. To this end, we conduct a case study with Wingsoft examination system product line (WES-PL), an industrial product line with an evolution history of eight years and more than 10 application products. In the case study, we reviewed the evolution history of WES-PL architecture and analyzed several typical evolution cases. Based on the historical analysis, we identify some special problems in industrial SPL practice from the aspect of architecture evolution and summarize some useful experiences about SPL evolution decisions to complement classical SPL methodology. On the other hand, we also propose some possible improvements for the evolution management in WES-PL.

<div class="htmlview paragraph">Fault tree analysis (FTA) evolved from the aerospace industry in the 1960’s. A fault tree is deductive logic model that is generated with a top undesired event in mind. FTA answers the question, “how can something occur?” as opposed to failure modes and effects analysis (FMEA) that is inductive and answers the question, “what if?” FTA is used in risk, reliability and safety assessments. FTA is currently being used by several industries such as nuclear power and chemical processing. Typically the automotive industries uses failure modes and effects analysis (FMEA) such as design FMEAs and process FMEAs. The use of FTA has spread to the automotive industry. This paper discusses the use of FTA for automotive applications. With the addition automotive electronics for various applications in systems such as engine/power control, cruise control and braking/traction, FTA is well suited to address failure modes within these systems. FTA can determine the importance of these failure modes from various perspectives such as cost, reliability and safety. A fault tree analysis of a car starting system is presented as an example.</div>

Software product family or line is a software engineering paradigm that systematizes reuse. In software product line engineering, two phases are distinguished: domain engineering which is in charge of developing a common infrastructure and assets and application engineering which makes use of those assets to generate the products. One of the key aspects of product lines is variability and its management. However, the main focus has been on functional variability and quality variability in software product lines has not received so much attention by researchers. In a product line different members of the line may require different levels of a quality requirement, for instance they could differ in terms of their availability, security, reliability, etc. Due to this variability, quality evaluation in software product lines is much more complicated that in single-systems. One alternative is to evaluate all the products of a line but it is very expensive and ways of reducing evaluation efforts are necessary. In this direction, the paper presents a method for facilitating cost-effective quality evaluation of a product line taking into consideration variability on quality attributes.

A layered approach to automated electrical safety analysis in automotive environments

We present a study on software fault tree analysis (SFTA) conducted at the Software Assurance Technology Center at NASA Goddard Space Flight Center. While researchers have made various attempts at SFTA, software assurance practitioners have been slow to adopt it. One reason is the intense manual effort needed to identify and draw the fault trees for the code of large software projects. Another is the lack of commercial tools to assist in the technique for software. Most SFTA research efforts have been directed at requirements or code. Performing SFTA on the design may enable application of SFTA to critical code only, thus reducing the amount of effort. We attempt to develop a relationship between UML/spl trade/ design diagrams and fault tree symbology to enable adaptation of a commercial FTA tool to at least one software design language. Such a result would reduce the amount of fault tree effort both for size (design instead of code) and for manual effort.

A key process in software product line (SPL) engineering is product derivation, which is the process of building software products from a base set of core assets. During product derivation, the components in both core assets and derived software products are modified to meet needs for different functionality, platforms, quality attributes, etc. However, existing software configuration management (SCM) systems do not sufficiently support the derivation process in SPL. In this paper, we introduce a novel SCM system that is well-suited for product derivation in SPL. Our tool, MoSPL handles version management at the component level via its product versioning and data models. It explicitly manages logical constraints and derivation relations among components in both core assets and derived products, thus enabling the automatic propagation of changes in the core assets to their copies in derived products and vice versa. The system can also detect conflicting changes to different copies of components in software product lines.

Fault tree analysis (FTA) is one of the most prominent techniques used in risk analysis, this method aimed to identify how component failures lead to system failure using logical gates (i.e. AND, OR gates). However, some limitations appear on FTA due to its static structure. Bayesian networks (BNs) have become a popular technique used in reliability analysis; it represents a set of random variables and their conditional dependencies. This paper discusses the advantages of Bayesian networks over fault tree in reliability and safety analysis. Also, it shows the ability of BN to update probabilities, to represent multi-state variables, dependent failures, and common cause failure. An example taken from the literature is used to illustrate the application and compare the results of both fault tree and bayesian networks techniques.

Most of the functions of civil aircraft are achieved through software at present. Therefore, the safety of airborne software has become an important part of safety analysis. However, to achieve complex functions, the onboard software becomes very complicated, and it is usually difficult to guarantee safety. ARP4761(Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment) is an important safety assessment guideline for civil aircraft, but it believes that software development can satisfy safety as long as the software development process complies with the software development standards, instead of incorporating the software into the safety analysis process. To improve airborne software safety, this paper proposes a safety analysis method based on the ARP4761 process which is tailored to adapt to the software. In the software requirements and design, the method uses FHA(Functional Hazard Assessment) to analyze the hazards of the software and define the hazard levels, then use FTA(Fault Tree Analysis) to build a software fault tree, and carry out CCA(Common Cause Analysis) analysis based on the fault tree; after the software development is completed, the method uses FMEA(Failure Modes and Effects Analysis) and FMES(Failure Modes and Effects Summary) to summarize the failures of the software and return these failures to the fault tree to determine whether the software can meet the defined requirements. At the end of the article, an anti-icing software is used as an example to explain the process and effectiveness of the method.