Conference Paper

Safety contract based design of software components

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

In this paper we discuss how to use a modified design methodology for contract based design (CBD) intended for development of software and component based systems by use of so called safety contracts. The primary purpose is to make a proposal on how to integrate safety contracts in a, for a tool, implementable way for automatic safety contract verification. This development technique is called safety contract based design (SCBD) in this paper. Focus is to discuss the similarities and differences between the actual contents in conventional CBD-contracts and safety contracts, and rules for how to verify agreements of safety contracts and how to ensure safety contract validity.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... A (software) contract is commonly used to specify the relation between system artifacts (or components), expressing the pre-and post-conditions of a system component [5]. A safety contract is a similar idea but instead of having pre(post)conditions, it contains assumptions and guarantees assuring a certain level of confidence (integrity) of such a component [6]. Thus, safety contracts can be used to specify safety standard requirements in the design phase, as it is stated in [6]- [8]. ...
... A safety contract is a similar idea but instead of having pre(post)conditions, it contains assumptions and guarantees assuring a certain level of confidence (integrity) of such a component [6]. Thus, safety contracts can be used to specify safety standard requirements in the design phase, as it is stated in [6]- [8]. ...
... Recall that safety contracts define safety constraints (or assumptions) and guarantees in the context of a system artifact, guaranteeing its functional properties and a certain level of integrity [6]. In this work, we explore the idea of specifying safety constraints and guarantees (forming a safety contract fragment, SCF [6]) of artifact components using OCL invariants within UML models. ...
Conference Paper
Full-text available
Safety becomes a primordial assessment in safety-related systems where human lives can be somehow put in risk, needing to comply with safety requirements defined by industry standards such as IEC 61508, ISO 26262 or DO-178C. Safety contracts are useful to specify these requirements (as assumptions and guarantees), thus assuring an expected level of confidence. To verify the safety requirements is measured to represent more than a half of the overall system development costs. In this paper, we propose a model-based verification that addresses safety verification from the early beginning of system development, thus saving costs. Namely, we use UML for system design and Object Constraint Language (OCL) for specifying safety contracts, while its verification is carried out using Petri nets. As case study, we assess the safety of an embedded system that models a fire prevention system in a hospital building.
... In a component-based system a contract defines the obligations to be met by a certain component and its dependencies [18]. As it is claimed in [19], a safety contract is similar to a (software) contract but instead of pre/post-conditions contains assumptions and guarantees that endorse a certain level of integrity of functional properties depending on the component's environment. ...
... In this paper, we adhere to the definition of a Safety Contract Fragment (SCF) given in [19]. A SCF conforms a safety contract as a set of assumptions -what it is expected to be met by the component's environment -and a set of guarantees, which specify the behaviour of a component under such an environment. ...
... Let C = I, O be a component of such a system having a set I of input ports and a set O of output ports. Let S C = A, G be a SCF [19] defined over a component C, where A = A + A * is a superset of disjoint sets A + , A * of OR and AND safety constraints, respectively, and G = G + G * is a superset of disjoint sets G + , G * of OR and AND guarantees 4 . A safety contract assumption A is a proposition that relates one or more of the input ports of a component. ...
Conference Paper
Full-text available
The verification of safety becomes crucial in critical systems where human lives depend on the correct functioning of such systems. Formal methods have often been advocated as necessary to ensure the reliability of software systems, albeit with a considerable effort. In any case, such an effort is cost-effective when verifying safety-critical systems. Safety requirements are usually expressed using safety contracts, in terms of assumptions and guarantees. To facilitate the adoption of formal methods in the safety-critical software industry, we propose the use of well-known modelling languages, such as UML, to model a software system, and the use of OCL to express the system safety contracts within UML. A UML model enriched with OCL constraints is then transformed to a Petri net model that enables to formally verify such safety contracts. We apply our approach to an industrial case study that models a train doors controller in charge of the opening and closing of train doors. Our approach allows to perform an early safety verification, which increases the confidence of software engineers while designing the system.
... Out of an extensive literature study (See Sec. II-C) of contract approaches [7], [8], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], only [10] was found to discuss the relation between SILs and contracts in any depth. In [10], inspired by the work in [25], 'safety contracts' are used as a mean to explicate the relation between the integrity levels of assumptions on the inputs and the guarantee on the outputs of a software component. ...
... Out of an extensive literature study (See Sec. II-C) of contract approaches [7], [8], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], only [10] was found to discuss the relation between SILs and contracts in any depth. In [10], inspired by the work in [25], 'safety contracts' are used as a mean to explicate the relation between the integrity levels of assumptions on the inputs and the guarantee on the outputs of a software component. ...
... II-C) of contract approaches [7], [8], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], only [10] was found to discuss the relation between SILs and contracts in any depth. In [10], inspired by the work in [25], 'safety contracts' are used as a mean to explicate the relation between the integrity levels of assumptions on the inputs and the guarantee on the outputs of a software component. The notion of inheritance of integrity levels inbetween requirement breakdown levels is also discussed, but the discussion is kept at non-formal level and is limited to the software domain only. ...
Conference Paper
In functional safety standards such as ISO 26262 and IEC 61508, Safety Integrity Levels (SILs) are assigned to top-level safety requirements on a system. The SILs are then either inherited or decomposed down to safety requirements on sub-systems, such that if the sub-systems are sufficiently reliable in fulfilling their respective safety requirements, as specified by the SILs, then it follows that the system is sufficiently reliable in fulfilling the top-level safety requirement. Present contract theory has previously been shown to provide a suitable foundation to structure safety requirements, but does not include support for the use of SILs. An extension of contract theory with the notion of SILs is therefore presented. As a basis for structuring the breakdown of safety requirements, a graph, called a contract structure, is introduced that provides a necessary foundation to capture the notions of SIL inheritance and decomposition in the context of contract theory.
... The contracts specify the input and output behaviour of a component and provide a guaranteed behaviour [10]. Such an approach can be used for software component safety contracts [11] as well as contract-based embedded system development [12,13]. ...
... The contracts specify the input and output behaviour of a component and provide a guaranteed behaviour [10]. Such an approach can be used for software component safety contracts [11] as well as contract-based embedded system development [12]. ...
... The contracts specify the input and output behaviour of a component and provide a guaranteed behaviour 10 . Such an approach can be used for software component safety contracts 11 as well as contract-based embedded system development 12,13 . Nevertheless, these approaches are not yet very common in the automotive domain. ...
... The contracts specify the input and output behaviour of a component and provide a guaranteed behaviour 10 . Such an approach can be used for software component safety contracts 11 as well as contract-based embedded system development 12 . ...
Article
Full-text available
An important trend in the automotive domain is to adapt established functional safety processes and methods for security engi- neering. Although functional safety and cyber-security engineering have a considerable overlap, the trend of adapting methods from one domain to the other is often challenged by non-domain experts. Just as safety became a critical part of the development in the late 20th century, modern vehicles are now required to become resilient against cyber-attacks. As vehicle providers gear up for this challenge, they can capitalize on experiences from many other domains, but must also face several unique challenges. Such as, that cyber-security engineering will now join reliability and safety as a cornerstone for success in the automotive industry and approaches need to be integrated into the mainly safety oriented development lifecycle of the domain. The recently released SAE J3061 guidebook for cyber-physical vehicle systems focus on designing cyber-security aware systems in close relation to the automotive safety standard ISO 26262.
... Contracts theory specifically adopted for specifying dependability attributes has been proposed in [18], [32]. None of these works discusses fault/failure propagation, relationship to Baysian networks, or fault management mechanisms. ...
... Safety-contract based design is a proposed methodology that can eliminate the need to re-examine software components for every product where they are used [6], [7]. With this methodology, safety elements out of context (SEooC) components are certified and accompanied with a safety contract that specifies under which circumstances the certification is valid. ...
Conference Paper
Full-text available
SafetyADD is a tool for working with safety contracts for software components. Safety contracts tie safety related properties, in the form of guarantees and assumptions, to a component. A guarantee is a property the component promises to hold, on the premise that the environment provides its associated assumptions. When multiple software components are integrated in a system, SafetyADD is used to verify that the guarantees and assumptions match when there are safety-related dependencies between the components. The initial goal of SafetyADD is to investigate how safety contracts can be managed and used efficiently within the software design process. It is implemented as an Eclipse plugin. The tool has two main functions. It gives designers of software components a way to specify safety contracts, which are stored in an XML format and shall be distributed together with the component. It also gives developers who integrate multiple software components in their systems a tool to verify that the safety contracts are fulfilled. A graphical editor is used to connect guarantees and assumptions for dependent components, and an algorithm traverses all such connections to make sure they match.
... The contracts specify the input and output behavior of a component and provide a guaranteed behavior [3]. Such an approach can be used for software component safety contracts [8] as well as contract-based embedded system development [4]. These contract-based approaches foster model-based development and traceability of development decisions. ...
... Here the contracts specify the input assumptions of a component and provide a guaranteed output behavior [8]. Such an approach can be used for safety contracts of software components [9], as well as contract-based embedded system development [10]. ...
Article
Full-text available
Increasing demands for safety, security, and certifiability of embedded automotive systems require additional development effort to generate the required evidences that the developed system can be trusted for the application and environment it is intended for. Safety standards such as ISO 26262 for road vehicles have been established to provide guidance during the development of safety-critical systems. The challenge in this context is to provide evidence of consistency, correctness, and completeness of system specifications over different work-products. One of these required work-products is the hardware-software interface (HSI) definition. This work-product is especially important since it defines the interfaces between different technologies. Model-based development (MBD) is a promising approach to support the description of the system under development in a more structured way, thus improving resulting consistency. Therefore, this paper presents a tool approach for an ISO 26262 aligned hardware-software interface definition. More specifically, the approach combines the versatility and intuitiveness of spreadsheet tools (such as Excel) and the properties of MDB tools (e.g. different views, levels of abstraction, central source of information, and information reuse) bidirectionally. The approach is capable of defining an ISO 26262 compliant HSI definition and enables automatic derivation of basic software configurations according to the HSI definition. This simplifies concurrent development of software and hardware across domain and company borders.
... Recent work include meta theories of contracts in [10], [13] and also in [22] with tool support [21], as well as extensions to modalities [59] in [27], [41] and to a stochastic setting in [15], [33], [43]. The use of contracts has been proposed for analyzes integration [80] and as a means to achieve functional safety in [5], [9], [11], [28] and also in [83] with tool support [84]. ...
... Söderberg and Johansson [14] discuss how to use a modified design methodology for contract-based design (CBD) intended for development of software and component based systems by use of safety contracts. The primary purpose is to make a proposal on how to integrate safety contracts in an implementable way (in a tool) for automatic safety contract verification. ...
Conference Paper
Full-text available
More effective, efficient and flexible ways to manage safety assurance are needed for the successful development and release of Automated Driving Systems (ADSs). In this paper we propose a set of desired assurance method criteria and present an initial overview of available safety assurance methods and how they contribute to the proposed criteria. We observe that there is a significant gap between the state-of-the-art research and the state-of-practise for safety assurance of ADSs and propose to investigate reasons for this as future work. A next step will be to investigate how to merge the elements from the different assurance methods to achieve a method addressing all criteria.
... • a Safety Manual containing the interface of the component. This can include a Safety Contract (Soderberg 2013) with assumptions and guarantees of the component that shall be fulfilled for the component to give correct service when included in an item. The Safety Manual could be made available to the customer first after negotiations with a customer have been started, as it may contain sensitive details. ...
Preprint
Full-text available
This paper outlines a business model for selling safety-related components. The goal is protection of the suppliers' intellectual property whilst providing confidence, to the customer, that the component is safe. The ideas in this paper are based on the Safety Element out of Context-concept as given in ISO 26262. To this we add ideas from IEC 61508-(a safety manual), and also describe a procedure to establish a safety certificate resulting from a third-party assessment. The ideal business model is contrasted with a fictitious inferior model that is based on experience in the industry.
... Similar work to [3][4][5] is presented in [46] and in [35] with tool support [90], and also in a more applied setting in [91,92]. The use of theory [3][4][5] has been advocated in [10][11][12][13][14][15] and the use of contracts in general has been proposed for analyzes integration [93] and as a means to achieve functional safety in [94,95] and also in [96] with tool support [97]. Contract theory has also been extended both with modalities [98] in [12,41] and to a stochastic setting in [37,42]. ...
Article
Full-text available
A general, compositional, and component-based contract theory is proposed for modeling and specifying heterogeneous systems, characterized by consisting of parts from different domains, e.g. software, electrical and mechanical. Given a contract consisting of assumptions and a guarantee, clearly separated conditions on a component and its environment are presented where the conditions ensure that the guarantee is fulfilled—a responsibility assigned to the component, given that the environment fulfills the assumptions. The conditions are applicable whenever it cannot be ensured that the sets of ports of components are partitioned into inputs and outputs, and hence fully support scenarios where components, characterized by both causal and acausal models, are to be integrated by solely relying on the information of a contract. An example of such a scenario of industrial relevance is explicitly considered, namely a scenario in a supply chain where the development of a component is outsourced. To facilitate the application of the theory in practice, necessary properties of contracts are also derived to serve as sanity checks of the conditions. Furthermore, based on a graph that represents a structuring of a hierarchy of contracts, sufficient conditions to achieve compositionality are presented.
... [34] and [69] aim at more applied approaches. Ruchkin et al. [63] and also in [66] (for tool support see [67]) suggest contracts for supporting integration. ...
Article
Full-text available
This paper addresses the specification of and reasoning about interactive real-time systems, their interfaces, and architectures as well as their properties in terms of assumptions and commitments. Specifications are structured into assumptions restricting the behavior of the operational context of systems and commitments about the system behavior (also called rely/guarantee or assumption/promise specification patterns in the literature). A logical approach to assumption/commitment contracts is worked out based on a mathematical system model:From assumption/commitment contracts plain interface assertions for the system are derived. Healthiness conditions based on the system model are worked out for assumptions. Safety and liveness properties for assumption/commitment contracts are identified. From interaction specifications describing the interaction between two systems assumption/commitment contracts for the involved systems are derived. Contracts for components in architectures are formulated in terms of assumptions and commitments and conditions are worked out to guarantee that assumptions for the composite systems guarantee the validity of the assumptions for components. Based on the theoretical foundation architectural issues are considered for a systematic use of assumption/commitment patterns in system specification and architecture design.
...  a Safety Manual containing the interface of the component. This can include a Safety Contract (Soderberg 2013) with assumptions and guarantees of the component that shall be fulfilled for the component to give correct service when included in an item. The Safety Manual could be made available to the customer first after negotiations with a customer have been started, as it may contain sensitive details. ...
Technical Report
This paper outlines a business model for selling safety-related components. The goal is protection of the suppliers' intellectual property whilst providing confidence, to the customer, that the component is safe. The ideas in this paper are based on the Safety Element out of Context-concept as given in ISO 26262. To this we add ideas from IEC 61508-(a safety manual), and also describe a procedure to establish a safety certificate resulting from a third-party assessment. The ideal business model is contrasted with a fictitious inferior model that is based on experience in the industry. 2 Introduction This paper outlines a business model for selling safety-related components. The goal is protection of the suppliers' intellectual property whilst providing confidence to the customer that the component is safe. The actors, e.g. supplier, customer etc., and their roles in the business model are described and explained. The business model is described in an ideal scenario. Commentary is given where ideal assumptions differ from reality e.g. as found from experience. As this is an ideal model, it may require effort (and expense) to use in a real scenario. However, it allows deficiencies in current practices to be highlighted and at least discussed. The business model assumes the use of a safety manual, in the interface to the customer; in the scope of components that are developed according to ISO 26262. Although this concept is not new (it is found in IEC 61508), it is not currently specified in ISO 26262. The ideal business model is contrasted with a fictitious inferior model that is based on experience in the industry. The background is the following: A supplier develops and offers a safety component. The offer is found by a potential customer through marketing, and negotiations leading to a purchase are initiated. The material used for marketing the component is based on properties from the development of the component. The customer requests a specification of the component (beyond initial marketing material), e.g. it's interface, properties, and evidence of conformance, e.g. to applicable safety standards. Since much of this data (specification sand evidence of conformance) is found in supplier documentation that also contains other information that the supplier should not expose, a challenge in this relationship is to control the exposure of the supplier's intellectual property to the customer. In the proposed business model this exposure is avoided by using a clear interface definition (a safety manual) and third-party certification, of product conformance and safety, to gain the customer's confidence without compromising the supplier intellectual property. Traditionally, system safety analysis started with the complete systems in scope, i.e. not components. Functional safety standards (a subset of system safety) originated from this complete systems approach. For example, in aerospace, process and nuclear industry there is a long-standing tradition to estimate system reliability, to analyse faults and to mitigate failures by system engineering. In the wake of several catastrophic incidents like the Seveso disaster in 1976 and the Bhopal disaster in 1984 (Seveso disaster, Bhopal disaster), the need for an industrial standard to assess functional safety became priority. In 1998 the IEC 61508, the first international functional safety standard, was published and helped raise awareness of functional safety in the industry. Its lifecycle approach to functional safety (design, 1 Corresponding author: carl.bergenhem@qamcom.se 2 This article is available at arxiv.org
... The contracts specify the input and output behavior of a component and provide a guaranteed behavior [9]. Such an approach can be used for software component safety contracts [10] as well as contract-based embedded system development [11,12]. Nevertheless, these approaches are not yet very common in the automotive domain. ...
Conference Paper
Full-text available
The automotive industry has an annual increase rate of software implemented functions of about 30 %. In the automotive domain the increasing complexity of systems became challenging with consumer demands for advanced driving assistance systems and automated driving functionalities, and the thus broadening societal sensitivity for security and safety concerns, such as remote control of cars by hacking their IT infrastructure. As vehicle providers gear up for the cyber-security challenges, they can leverage experiences from many other domains, but nevertheless have to face several unique challenges. The recently released SAE J3061 guidebook for cyber-physical vehicle systems provides high-level principles for automotive organizations to identify and assess cyber-security threats and design cyber-security aware systems in close relation to ISO 26262. Although functional safety and cyber-security engineering have a considerable overlap regarding many facets, such as analysis methods and system function thinking, the definition of system borders (item definition vs. trust boundaries) often differs largely. Therefore, appropriate systematic approaches to support the identification of trust boundaries and attack vectors for the safety- and cybersecurity-relates aspects of complex automotive systems are essential. In the course of this paper, we analyze a method to identify attack vectors on complex systems via signal interfaces. We focus on a central development artifact of the ISO 26262 functional safety development process, the hardware-software interface (HSI), and propose an extension for the HSI to support the cyber-security engineering process.
Conference Paper
According to EN 50129, manufacturers of rail vehicles shall justify via a safety case that their vehicles are adequately safe for their intended applications. MBASafe is a recently proposed and potentially innovative design and verification process. In the presence of compelling arguments concerning its adequacy as process evidence, MBASafe could support the safety claims within the required safety cases. In this paper, we contribute to partially justify the adequacy of MBASafe to act as process evidence. To do that, we first manually check if MBASafe includes EN 50128-compliant process elements, then we model MBASafe in compliance with Software Process Engineering Meta-model 2.0, then, we derive process-based arguments from the MBASafe process model by using MDSafeCer, the recently introduced Model Driven Safety Certification method. By doing so, we provide a twofold contribution: we further validate MDSafeCer in the rail domain and we strengthen MBASafe.
Article
The verification of safety requirements becomes crucial in critical systems where human lives depend on their correct functioning. Formal methods have often been advocated as necessary to ensure the reliability of software systems, albeit with a considerable effort. In any case, such an effort is cost-effective when verifying safety-critical systems. Often, safety requirements are expressed using safety contracts, in terms of assumptions and guarantees. To facilitate the adoption of formal methods in the safety-critical software industry, we propose a methodology based on well-known modelling languages such as the unified modelling language and object constraint language. The unified modelling language is used to model the software system while object constraint language is used to express the system safety contracts within the unified modelling language. In the proposed methodology a unified modelling language model enriched with object constraint language constraints is transformed to a Petri net model that enables us to formally verify such safety contracts. The methodology is evaluated on an industrial case study. The proposed approach allows an early safety verification to be performed, which increases the confidence of software engineers while designing the system.
Article
An EN 50129-compliant safety case should include process-related evidence in terms of quality as well as safety management. Potentially innovative engineering methods developed in academic settings could act as process-related evidence. However, to ease their acceptance within the rail industrial settings, the adequacy of these methods need to be justified. In this paper, we extend our previous work and we provide a broader justification including performance aspects aimed at showing that the entire MBA (Model-Based design methodology for Assessing performance and safety requirements of critical systems) is partly compliant with EN 50128. To do that, we tackle safety and performance process-related compliance as follows: we first manually check if MBA includes EN 50128-compliant process elements, then we model MBA in compliance with Software Process Engineering Meta-model 2.0, then, we derive process-based arguments from the MBA process model by using the MDSafeCer (Model Driven Safety Certification) method. By doing so, we provide a twofold contribution: we further validate MDSafeCer in the rail domain and we strengthen MBA.
Conference Paper
Full-text available
We study the relation between specifications of component behaviors and contracts providing means to specify assumptions on environments as well as component guarantees. We show how a contract framework can be built in a generic way on top of any specification theory which supports composition and specification refinement. Our contract framework lifts refinement to the level of contracts and proposes a notion of contract composition on the basis of dominating contracts. Contract composition satisfies a universal property and can be constructively defined if the underlying specification theory is complete, i.e. it offers operators for quotienting and conjoining specifications. We illustrate our generic construction of contracts by moving a specification theory for modal transition systems to contracts and we show that a (previously proposed) trace-based contract theory is an instance of our framework.
Article
Full-text available
Cyber-physical systems combine a cyber side (computing and networking) with a physical side (mechanical, electrical, and chemical processes). In many cases, the cyber component controls the physical side using sensors and actuators that observe the physical system and actuate the controls. Such systems present the biggest challenges as well as the biggest opportunities in several large industries, including electronics, energy, automotive, defense and aerospace, telecommunications, instrumentation, industrial automation. Engineers today do successfully design cyber-physical systems in a variety of industries. Unfortunately, the development of systems is costly, and development schedules are difficult to stick to. The complexity of cyber-physical systems, and particularly the increased performance that is offered from interconnecting what in the past have been separate systems, increases the design and verification challenges. As the complexity of these systems increases, our inability to rigorously model the interactions between the physical and the cyber sides creates serious vulnerabilities. Systems become unsafe, with disastrous inexplicable failures that could not have been predicted. Distributed control of multi-scale complex systems is largely an unsolved problem. A common view that is emerging in research programs in Europe and the US is “enabling contract-based design (CBD),” which formulates a broad and aggressive scope to address urgent needs in the systems industry. We present a design methodology and a few examples in controller design whereby contract-based design can be merged with platform-based design to formulate the design process as a meet-in-the-middle approach, where design requirements are implemented in a subsequent refinement process using as much as possible elements from a library of available components. Contracts are formalizations of the conditions for correctness of element integration (horizontal contracts), for lower level of abstraction to be consistent with the higher ones, and for abstractions of available components to be faithful representations of the actual parts (vertical contracts).
Article
Full-text available
This paper gives the main definitions relating to dependability, a generic concept including a special case of such attributes as reliability, availability, safety, integrity, maintainability, etc. Security brings in concerns for confidentiality, in addition to availability and integrity. Basic definitions are given first. They are then commented upon, and supplemented by additional definitions, which address the threats to dependability and security (faults, errors, failures), their attributes, and the means for their achievement (fault prevention, fault tolerance, fault removal, fault forecasting). The aim is to explicate a set of general concepts, of relevance across a wide range of situations and, therefore, helping communication and cooperation among a number of scientific and technical communities, including ones that are concentrating on particular types of system, of system failures, or of causes of system failures.
Safety Certification of Software-Intensive Systems with Reusable Components
  • Safecer
Contract-based design for cyber-physical systems alberto l sangiovanni-vincentelli, werner damm, and roberto passerone
  • L Taming Dr Alberto
  • Werner Sangiovanni-Vincentelli
  • Roberto Damm
  • Passerone