Providing tool support for specifying safety-critical systems by enforcing syntactic contract conditions

Functional safety standards such as IEC 61508 and ISO 26262 advocate a particularly stringent requirements engineering where safety requirements must be structured in a hierarchical manner and specified in accordance with the system architecture. In contrast to the stringent requirements engineering in functional safety standards, according to previous studies, requirements engineering in industry is in general of poor quality. Contracts theory has been previously shown to be suitable for supporting such a stringent requirements engineering effort; this support has also been implemented in tools. However, to use these contract-based tools, requirements must be formalized, which is a major challenge in industry. Therefore, to support current industrial requirements engineering practice and the stringent requirements engineering in functional safety standards, it is shown how tool support can be provided even when requirements, and also architectures, are not formalized. This is achieved by enforcing syntactic, yet formal, conditions in contracts theory. Despite the need for further validation, initial findings in an industrial case study indicate high potential in realizing the proposed support in an industrial setting.


Introduction
Requirements engineering (RE) [12,35] is a well-established and recommended practice within the field of systems engineering.RE is particularly emphasized for achieving functional safety (FuSa), i.e., absence of unreasonable risk due to failures of electrical/electronic (E/E)-systems [37].In fact, the general FuSa standard IEC 61508 [36] advocates that requirements should form the backbone of a structured argumentation for the FuSa of an overall system.In such a structured argumentation, each requirement is a safety requirement, i.e., a requirement with a safety integrity level (SIL) [22,36,37,54] that specifies the required reliability [63] of a system or component, in order to achieve a tolerable level of risk.
In IEC 61508 and its derivative FuSa standards such as ISO 26262 [37] for the automotive domain, safety requirements must be structured in a hierarchical manner in accordance with the system architecture [38]: at each level, safety requirements must be allocated to architecture elements and trace links [15] must be established between requirements on different levels.An intended property characterized by this manner of structuring requirements is completeness, i.e., 'the safety requirements at one level fully implement all safety requirements of the previous level' [37].This is a property that also must be verified, and thus, a high degree of stringency is required when specifying requirements, their allocation, and their hierarchical structure.
Despite the demand on highly stringent RE to achieve FuSa, requirements in industry are in general of poor quality [2] and are typically incomplete [25], and this is also true for safety requirements [25,49].Considering a typical RE tool such as IBM Rational DOORS, other than basic impact analyzes, the tool neither gives feedback nor guides a user when specifying, allocating, and structuring requirements; thus, a property such as completeness must be established without any concrete support from the tool.The view in [70], which is shared in the present paper, is that RE is a complex and error-prone process that can benefit from more intelligent tool support in general.In fact, in order to comply with FuSa standards that require a particularly stringent RE, tool support, which gives feedback to and guides the user when specifying a system, is crucial.
Therefore, the present paper presents novel ideas on how such tool support can be provided when authoring specifications for a system in an industrial setting.This support is provided by applying the work in [6,68,73,75,76] that present a formal and general contracts [53] theory for modeling and specifying systems.
In particular, this contracts theory contains a concept called a contract structure that captures a hierarchical structuring of requirements based on a formal interpretation of completeness.Thus, establishing a contract structure sets a basis for achieving the stringent RE effort advocated by FuSa standards.Establishing a contract structure with the intent of achieving completeness consists of the tasks of specifying: (I) allocation of requirements to architecture elements; (II) architecture element interfaces consisting of port variables; (III) requirements; and (IV) trace links between requirements.
These tasks (I)-(IV) are also described in FuSa standards; however, the fact is that in contracts theory [6,68,73,75,76], these tasks are given formal semantics, i.e., interpretations in formal (mathematical) conditions.The present paper capitalizes on this fact by considering the support that can be provided for tasks (I)-(IV) by having a tool that evaluates these formal contract conditions.
Notably, there already exist approaches such as [13,14,16] where formal contract conditions are evaluated in tools.However, the tool support in these approaches is dependent on that contracts must be formally represented in the language linear-time temporal logic (LTL) [59].Despite the fact that formal representations have several advantages over non-formal ones, formal languages are difficult to use by non-experts [23] and in industrial practice, 'overcoming the burden of formalization is a major challenge' [10].Therefore, instead of focusing on enforcing all of the contract conditions in [6,68,73,75,76], the present paper instead identifies necessary conditions of the formal interpretations of tasks (I)-(IV) where these conditions can be evaluated even when requirements and architectures are not represented formally; in the following, such necessary conditions will be called syntactic contract conditions.
The rest of this paper is organized as follows.Section 1.1 provides an overview of the contributions and validation approach of the paper.Section 2 introduces relevant parts of the contracts theory in [6,68,73,75,76].Section 3 identifies syntactic contract conditions of tasks (I)-(IV) in this contracts theory, and as the main contribution, shows how support can be provided for tasks (I)-(IV) by enforcing these syntactic contract conditions.Section 4 then describes and draws conclusions from the industrial case study.Section 5 discusses related work, and Sect.6 summarizes the present paper and draws conclusions.

Contributions and validation
As the main contribution, the present paper provides support for tasks (I)-(IV) by evaluating their syntactic contract conditions.The proposed support is presented in the context of authoring specifications, containing requirements and interface descriptions, and that are structured in accordance with the architecture of a system.In the considered context, the proposed support is shown to provide feedback and guidance to a user authoring a specification.This sort of support for tasks (I), (II), and (IV) is shown to be possible to provide regardless of how requirements are represented in specifications and when architectures are represented formally or semiformally, as an hierarchy of interfaces consisting of port variables.For task (III), feedback and guidance can be provided when architectures are represented formally or semiformally and when requirements are represented formally or semiformally, i.e., as free text with distinguishable port variables.
Considering the generality of the underlying contract theory, the proposed support is applicable to systems in any domain, e.g., software (SW), hardware (HW), mechanical, electrical, etc, and also to heterogeneous systems [31,48,64], i.e., systems composed of parts from multiple domains.The applicability of the proposed support is indeed also not limited to any type of design flow; that is, the support prescribes neither a certain order in which specifications are authored nor an order in which content is entered within a specification.This flexibility in design flow caters to the fact that different developers have dissimilar, yet successful, approaches for optimizing systems development.For example, in some cases, e.g., when development is outsourced, a top-down design flow might be optimal; in other cases, a bottom-up flow or a hybrid approach is more suitable.
As an initial form of validation, an industrial case study was performed where the proposed support was implemented and integrated into the development tool chain of Scania-a global heavy trucks manufacturer located in Sweden.Despite the need for further evaluations, especially long-term empirical studies, the case study did not only indicate a strong potential in realizing the proposed support in an industrial setting, but also that solutions, needed for realizing the support, could by themselves increase the quality of specifications.For example, a key concept used for realizing this support was Linked Data [9], which was used to enable formal referencing in between specifications and to architecture data.In addition to providing a foundation for formal referencing, as shown in the present paper, Linked Data are also able to ensure consistency of data presented in specifications and can, therefore, be used to increase quality of specification in general.

Contracts theory
The notion of contracts was first introduced in [53] for formal specification of SW.However, the principles behind contracts can be traced back to early ideas on compositional [33,66] proof-methods [32,41,55].In [6,68,76], the use of contracts is extended from formal specification of SW to serving as a central systems engineering philosophy to support the design of systems in general.The work in [73] incorporates the work in [6,68,76] and presents a contracts theory that introduces new concepts such as architecture.This contracts theory is extended in [75] to a safety-critical context with the notion of SILs.Section 3 will later show how support can be provided for tasks (I)-(IV) by enforcing conditions from the contracts theory in [6,68,73,75,76].The present section summarizes established conditions and related notions from this contracts theory.To match the context in the present paper, these conditions and notions are sometimes presented from slightly different perspectives than in [6,68,73,75,76].Due to this difference in perspectives, and to make the present paper self-contained, this section is quite thorough in introducing these notions and conditions.

Assertions, elements, and architectures
The theory [6,68,73,75,76] relies on a general formalism called assertions for characterizing requirements and behaviors.Formally, an assertion is a set of runs, i.e., value sequences, over a universal set of variables .
Despite their runs being over , assertions can be syntactically represented by constraints, e.g., by equations, inequalities, or logical formulas, expressed over a subset of .For example, an assertion ′ , represented by equation u = v , is the set of all runs that are over and that are solu- tions to u = v .The necessary and sufficient set of variables to syntactically represent an assertion is called the set of variables constrained by and is denoted X , e.g., the set X � = {u, v} is the set of variables constrained by ′ .
The concept of elements [73,75,76] generalizes Heterogeneous Rich Components (HRCs) [8,18,42] as described in [6,68] and is used to represent any functional, logical, or technical design entity of a heterogeneous system, e.g., as a Systems Modeling Language (SysML) block [26].Formally, an element is an ordered pair (X, ) where: • X is a set of variables called the interface of where each x ∈ X is called a port variable; and • is an assertion, called the behavior of , such that the set of variables constrained by is a subset of X.
As an illustrative example of an element, let pot = X pot , pot be an element representing a potentiom- eter.The element and its port variables are shown in Fig. 1a as a rectangle filled with gray and white boxes on the edges of the rectangle, respectively.The port variables v ref , v branch , and v gnd represent the reference, branch, and ground volt- ages, respectively.Furthermore, h represents the position (0-100%) of the 'slider' that moves over the resistor and branches the circuit.Given a representation where it is assumed that the branched circuit is connected to a resistance that is significantly larger than the resistance of the potentiometer, the behavior pot can be syntactically represented by equation h = Fig. 1 In a, an element pot = X pot , pot , representing a potentiometer, is shown.In b, an architecture, representing a 'Level Meter system' and its parts, and a contract  lMeter = ({ lMeter }, lMeter , X lMeter ) , are shown A set of elements can be organized into an architecture [73,75,77], which describes a hierarchical nesting of elements.This hierarchical nesting can be viewed as a rooted tree; thus, in the following, terminology from graph theory [21] will be used to describe positions of elements in an architecture, relative to each other.The underlying principle is to combine individual behaviors using intersection where the sharing of port variables between elements captures the interaction points between the elements.
Prior to presenting a formal definition of architecture, the concept is introduced by considering a set of elements representing the parts of a 'Level Meter system' (LMsystem) as shown in Fig. 1b.The sharing of a port variable between elements is shown as either by a line connecting two or more boxes corresponding to the same port variable or by the appearance of the same box on edges of several rectangles.
The LM-system LMsys consists of a tank tank and an electric-system Esys , which further consists of the potentiometer pot shown in Fig. 1a, a battery bat , and a level meter lMeter .The slider h of pot is connected to a 'floater,' trailing the level f in the tank.In this way, the potentiometer pot is used as a level sensor to estimate the level in the tank.The estimated level is presented by the level meter lMeter where l denotes the presented level.
The behaviors bat , lMeter , and tank of the leaf elements bat , lMeter , and tank are represented by equations

5V
, and h = f , respectively.The behavior of a non-leaf element (X, ) is the assertion that is the projection [73,75,78] of the intersection of the behaviors of its children (X i , i ) N i=1 onto the interface X; syntactically, is represented by the constraints, representing ⋂ N i=1 i , limited to be only over X. Formally, this is represented as = proj X ( ⋂ N i=1 i ) where proj X denotes extended projection [73,74].For example, the behavior of Esys is proj {l,h} ( bat ∩ Lmeter ∩ pot ) , which can be syntactically represented by equation l = h.Definition 1 (Architecture) An architecture, denoted , is a set of elements organized into a rooted tree, such that: (a) for any non-leaf node = (X, ) , with children , it holds that (b) if there is a child � = (X � , � ) and a non-descendant �� = (X �� , �� ) of = (X, ) , such that x ∈ X � and x ∈ X �� , then it holds that x ∈ X.
The environment of an element in an architecture is denoted Env ( ) and is the set of elements { j } M j=1 such that each j = (X j , j ) is either a sibling or a sibling of a proper ancestor of .Let Env ( ) denote ⋂ M j=1 j , called the behavior of the environment Env ( ) .
□ As an example of an environment of an element in an architecture, the set { tank } is the environment of Esys in the architecture shown in Fig. 1b.

Contracts
A contract [6,68,73,75,76] , , X) specifies the behavior of an element with an interface X to be such that the guarantee is fulfilled, given that the assumptions in , where • is an assertion, called guarantee; • is a set of assertions i N i=1 where each i is called an assumption; and • X is a set of variables.□ For the sake of readability, let = ⋂ N j=1 i .An element = (X � , ) is said to satisfy [6,8,68,73,75] a contract ( , , X) if Referring to a contract for an element, characterizes the intent that the element is to satisfy the contract.
As an illustrative example of a contract, let ({ lMeter }, lMeter , X lMeter ) be a contract  lMeter for the ele- ment lMeter where the set of port variables constrained by lMeter and lMeter are shown as dashed lines in Fig. 1b.The guarantee lMeter , represented by equation l = f , expresses the intent that the indicated level, displayed by the meter, corresponds to the level in the tank.The assumption lMeter is represented by equation f =

Hierarchical structuring of requirements using contracts
Consider a scenario where it is infeasible to verify that a contract  is satisfied by an element in an architecture , due to the complexity of .A solution to such an issue is to establish contracts for proper descendants of until it is possible to verify that a descendant i of satisfies  i with the intent that: (1) ∩ ⊆ , and If an architecture only consists of two hierarchical levels, then property (3) corresponds to dominance/refinement of contracts as described in [4,6,7,61,68], the basic idea of compositionality [33,66], and in particular, the notion of completeness in ISO 26262 [37].Thus, property (3) is a central concept in this paper since completeness characterizes the particularly stringent RE advocated in FuSa standards such as IEC 61508 and ISO 26262.Note that there are many reasons for establishing property (3) other than the one considered in the scenario, e.g., to enable parallel development of elements as described in [73].
This section presents concepts originating from [75] that introduces a graph called a contract structure that organizes contracts with the intent of achieving property (3).Prior to presenting a formal definition of contract structure in Sect.2.3.2, an underlying concept of using a contract to express a relation between requirements is described in Sect.2.3.1.Sufficient conditions on a contract structure to achieve property (3) are then presented in Sect.2.3.3.

Contracts as requirement relations
Consider contract  lMeter for the element lMeter , as shown in Fig. 1b.In accordance with Sect.2.2, the intent is that the behavior of lMeter is to be such that the guarantee lMeter is fulfilled given that the assumption lMeter is fulfilled.Formulated differently, the guarantee lMeter is a requirement that is allocated to lMeter with the intent that lMeter is fulfilled if the assumption lMeter is fulfilled.This view is in accordance with [78] where guarantees are used to express safety requirements on elements.
Suppose that there is a scenario where the environment, which the element Lmeter is to be deployed in, is unknown, e.g., when developing Lmeter 'out-of-context' [37].The assumption Lmeter of the contract shown in Fig. 1b hence expresses the conditions that the environment of Lmeter is to fulfill in an arbitrary architecture containing Lmeter .However, in a specific architecture, such as the architecture shown in Fig. 1b, the assumption Lmeter can rather be seen as a requirement that is allocated to the potentiometer pot .This was also observed in [72,78] where, in the context of an architecture, assumptions are in fact references to other guarantees.Therefore, in the definition of a contract structure for a specific architecture in Sect.2.3.2, an assumption of a contract for an element will correspond to a guarantee of a contract for an element in the environment of .Formulated differently, the assumption of a contract for is a requirement allocated to an element in the environment of , while the guarantee is a requirement allocated to .To capture the cases where the use of explicit assumptions are indeed needed, e.g., when it is necessary to express that an assumption is to be fulfilled by two or more guarantees, contract structures can be trivially extended as described in [73].

Contract structure for architecture
Consider a set of contracts { LMsys ,  Esys ,  pot ,  bat ,  lMeter } where the guarantee of each contract  i is a requirement i allocated to an element i in the architecture shown in Fig. 1b.Now consider Fig. 2 where these guarantees are structured as nodes in an edge-labeled directed graph as an overlay onto the hierarchical structure of the elements in this architecture.
A guarantee i in a contract  i is an assumption of another contract  j , if there exists an arc labeled 'Assumption of' from i to j , visualized as a line with a circle filled with black at the end.For example, the arc from pot to lMeter represents that pot is an assumption of contract  lMeter .
As also shown in Fig. 2, an incoming arc labeled 'Fulfills,' visualized as an arrow, to a guarantee i of a contract Fig. 2 A contract structure for the architecture shown in Fig. 1b for an element i from a guarantee j of a contract for a child j of i , represents the intent of j ⊆ i .For example, the arc from the guarantee Esys to LMsys represents the intent of Esys ⊆ LMsys .Now that the concept of a contract structure for architecture has been introduced informally, the formal definition follows.The following definition is a simplification of a definition in [74], which is in turn based on a definition in [75] and concepts in [73].
Definition 3 ( Contract str ucture for architecture) Given an architecture and a set where each ordered set ( i,j , i,j , X i ) is a contract for an element i of and where each assumption in each set  i,j is either: (a) a guarantee of a contract for a sibling of i ; or (b) an assumption of a contract for a proper ancestor of i , then a contract structure for is an arc-labeled directed acyclic graph (DAG), such that: (i) the guarantees i,j are the nodes in the DAG; (ii) each arc is uniquely labeled either 'Assumption of' or 'Fulfills'; (iii) there is an arc labeled 'Assumption of' from a node k,l to i,j , if and only if k,l is in  i,j ; (iv) if there is an arc labeled 'Fulfills' from i,j to k,l , then k,l is a guarantee of a contract for a proper ancestor of i ; and (v) if a guarantee i,j is reachable from an assumption of a contract for a proper ancestor m of i , then is also an assumption of any contract where k is a proper ancestor of i and a descendant of m (including itself) and where k,l is reachable from i,j .□ As discussed in Sect.2.3.1 and as also shown in Fig. 2, conditions (a) and (b) of Definition 3 express that an assumption of a contract for an element correspond to a guarantee of a contract for an element in the environment of , i.e., an assumption is either a guarantee of a contract for a sibling of , or an assumption of a contract for a proper ancestor of .Furthermore, as expressed in conditions (i)-(v) of Definition 3 and shown in Fig. 2, each node in a contract structure corresponds to a requirement allocated to an element in and each arc either expresses that a requirement is an assumption of a contract or that the intent is that a requirement is to fulfill another requirement.
Consider the contract structure shown in Fig. 3 that is intended to clarify why the graph would not be a contract structure if the dashed arc is added to the graph, as expressed in condition (v) of Definition 3. In Fig. 3, the intent is that the guarantee 2 is to be fulfilled by the behavior of , regardless of its environment.However, if the dashed arc is added, then the above-mentioned statement is contradicted since the graph then specifies that 2 is to be fulfilled by the behavior of , given that its environment fulfills ′ .This is due to the fact that the graph also specifies that 1,1 is to, together with 1,2 , fulfill 2 , and the behavior of the child 1 of is to fulfill 1,1 , given that ′ is fulfilled.
For a more detailed explanation of the concept of contract structures, see [74] and also [75] where this concept is also applied in a major industrial case study.Contract structures recast the notion of decomposition structures as presented in [73] in the context of RE concepts and extends the notion from two levels to an arbitrary number.A similar concept to a contract structure is presented in [56,57] based on Bayesian networks, but with the specific focus to model failure propagation.

Sufficient conditions on requirements in contract structure
This section presents a theorem based on a contract structure where the theorem expresses sufficient conditions for property (3) to hold.This theorem corresponds to a theorem in [74] and formalizes the stringent RE effort in establishing completeness as advocated in FuSa standards such as IEC 61508 and ISO 26262.
Theorem 1 Given an architecture and set of contracts ℭ organized as a contract structure ℭ for , it holds that an element ∈ satisfies a contract (, , X) ∈ ℭ for = (X � , ) if: (i) for each contract  �� = ( �� , �� , X �� ) ∈ ℭ for a descendent element ′′ of where is reachable from ′′ and where ′′ does not have any incoming 'Fulfills' arcs, it holds that ′′ satisfies  ′′ ; (ii) it holds that (4) X = X � , and Fig. 3 A contract structure that would not be a contract structure if the dashed arc is added to the graph where X ′ is the interface of and where X Env ( ) is the union of the interfaces of the elements in the environment of ; and (iii) for each contract  �� = ( �� , �� , X �� ) ∈ ℭ for a descendent element ′′ of where is reachable from ′′ , it holds that ⋂ N i=1 i ⊆ �� where { 1 , … , N } is the set of direct predecessors of ′′ with 'Fulfills' arcs to ′′ .Condition (i) ensures that the antecedent, i.e., the if-part, of property (3) holds for each contract containing a lowestlevel requirement from where can be reached.Conditions (ii) and (iii) of Theorem 1 are sufficient to ensure property (3).Condition (iii) ensures that all of the 'Fulfills' arcs in paths from lower-level requirements to , do in fact hold.
Condition (ii) embeds condition (4), which corresponds to condition (2) presented in Sect.2.2, and also condition (5). Figure 4 shows an example of when condition (5) is violated with respect to contract  �� Esys = ({ �� Esys }, �� Esys , X Esys ) for the element Esys in the architecture previ- ously described in Sect.2.1.In this example, condition (5) is violated due to the fact that the guarantee ′′ Esys constrains a port variable that cannot be constrained by the behavior of Esys nor of its environment in the considered architecture, i.e., it holds X �� Esys ⊈ X tank ∪ X Esys .Now, to illustrate the use of Theorem 1, consider the contract structure shown in Fig. 2. Since X LMsys ⊆ X LMsys and since the relations lMeter ⊆ Esys and Esys ⊆ LMsys hold, it can be inferred, through the use of Theorem 1, that if the leaf elements of the architecture in Fig. 1b satisfy their contracts, then LMsys satisfies  LMsys .
Remark 1 (Circular reasoning) Since the assumptions and guarantees of a contract structure are organized into a (5) X ⊆ X Env ( ) ∪ X � , directed acyclic graph, the use of circular argumentation is avoided.Note that circularity can be resolved in other ways, e.g., by introducing assumptions about the computational model [1] or the timing model [52].

Extending contracts theory with SILs
As described in Sect.2.3, a contract structure supports a hierarchical structuring of requirements and the individual tracing of lower-level safety requirements to top-level safety requirements.This individual tracing of requirements is needed to comply with, e.g., ISO 26262 where the assignment of SILs to lower-level requirements on components is determined based on their individual tracing to higher-level requirements.
More specifically, in ISO 26262, SILs are assigned to top-level safety requirements.Considering that a SIL was in Sect. 1 described as a measure of the required reliability of a system or component in order to achieve a tolerable level of risk, a SIL for a requirement expresses the tolerable level of risk of violating the requirement.As the safety requirements on a system are broken down into safety requirements on sub-systems, SILs are either inherited from a requirement at a higher level to a requirement at a lower level, or decomposed, where the SIL is lowered, as a result of introducing redundancy into the system.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.
Exploiting the fact that a contract structure formalizes such a hierarchical structuring of requirements, the work in [75] presents formal definitions for assigning SILs to requirements in a contract structure in accordance with FuSa standards.These definitions of SIL assignment are presented in Appendix.Section 3 will describe shortly how these definitions can be used to also support the assignment of SILs to requirements organized as a contract structure.

Support for authoring specifications by enforcing syntactic contract conditions
Section 2 presented a general contracts theory for specifying systems.Considering RE in particular, this contracts theory includes Theorem 1 that can, in combination with Definition 3, i.e., the definition of a contract structure for an architecture, be used for achieving completeness between requirements on different levels in a hierarchy in accordance with property (3).Thus, this definition and theorem formalize the particularly stringent RE advocated in FuSa standards such as IEC 61508 and ISO 26262.
Esys , X Esys ) where condition ( 5) is violated Theorem 1 and Definition 3 sets the basis for describing the main contribution, i.e., how formal support can be provided for tasks (I)-(IV) in the context of authoring specifications.This section presents the main contribution, but prior to doing so, the considered context will first be described.

Application context: authoring specifications
This section describes the considered context for the proposed support.This context is based on the underlying idea of structuring specifications for a system in accordance with the system architecture.This system can be of any domain, e.g., SW, HW, mechanical, electrical, etc, and also a heterogeneous system, i.e., a system composed of parts from multiple domains.Structuring the specifications for a system in accordance with its architecture is an established idea [11,79] that is also advocated in FuSa standards such as ISO 26262.
More specifically, in the considered context, specifications, containing requirements, are to be allocated to a specific element in the architecture; a link Alloc, specifying what element that a specification S is allocated to, is assumed to be contained in the specification.The allocation of a specification has the meaning that its contained requirements are allocated to the element to which the specification is allocated to.A specification, allocated to a specific element, also contain a set of variables X spec that is intended to specify the interface of that element.
Requirements in different specification can also be linked with each other in accordance with Sect.2.3.2, and the information regarding the linkage is contained in the specifications.More precisely, a specification contains two sets Assu and Full for each contained requirement in the specification.The set Assu contains all incoming 'Assumption of' trace links to and Full contains all outgoing 'Fulfills' trace links from . Figure 5 shows an example intended to illustrate the underlying idea of the context, as explained above.The example involves three specifications S, S ′ , and S ′′ , struc- tured with respect to an architecture containing three elements , ′ , and ′′ where ′ is the root element.Specification S, allocated to element ′ , contains a requirement .Requirement has an outgoing 'Fulfills' trace link to a requirement ′ , contained in specification S ′ , and an incom- ing 'Assumption of' trace link from a requirement ′′ , contained in specification S ′′ .Specification S also contains a set X spec , specifying the interface of element .
Section 3.1.1,which now follows, will formalize what has been mentioned so far in this section.

Specifications
A system is specified by a set of specifications {S i } N i=1 where each S i is structured as an ordered set: • Alloc i is a variable, called the allocation of S i , that is either NIL,1 symbolizing that it does not have a value, or equal to an element representation; • X spec i is a possibly empty set of variables called the interface-specifying set of S i ; • i,j is a requirement assertion; • each Assu i,j is a possibly empty set of incoming 'Assumption of' trace links from requirements in ⋃ N i=1 { i,1 , … , i,N i } to i,j ; and • each Full i,j is a possibly empty set of outgoing 'Fulfills' trace links from i,j to requirements in Let  i,j denote the set of requirements with outgoing 'Assumption of' trace links to i,j in accordance with Assu i,j .Each specification S i specifies a set of contracts )} intended to be for the element Alloc i .This also means that if the allocation of a specification is equal to an element, then this means that each requirement, contained in the specification, is allocated to this element.
Consider organizing the set of requirements as nodes in a graph in accordance with each set Assu i,j and Full i,j .Assume, as part of the context, that the specifications in {S i } N i=1 are such that this graph is a DAG; that is, it is assumed that sets Assu i,j and Full i,j do not contain arcs that result in cyclic dependencies.From this assumption, it follows that this graph is a contract structure if conditions (i)-(v) of Definition 3 holds.Notably, three of these conditions, namely conditions (i)-(iii) already hold , where Fig. 5 Three specifications S, S ′ , and S ′′ , structured with respect to a system architecture containing three elements , ′ , and ′′ for such a graph.That is, the specification structure in itself enforces these conditions as long as the arcs in Assu i,j and Full i,j do not result in cyclic dependencies.
Note that there are ways, other than the one described above, in which trace links between requirements can be contained in specifications.For example, trace links could be contained in specifications separate to those containing requirements, or 'Fulfills' trace links could be contained in the specification containing the requirement to which the trace links are incoming, instead of outgoing.However, for the sake of the proposed support it does not matter; another way of containing trace links could be chosen, as long as the graph formed from the trace links is the same.

Formalization of tasks in considered context
Section 3.1.1formalized a structure for authoring specifications for a system.This structure will be assumed when presenting the proposed support for tasks (I)-(IV).As previously mentioned, the overall aim of completing such tasks is to achieve property (3), i.e., completeness, in between requirement levels.This section formalizes these tasks for the specification structure presented in Sect.3.1.1.
Given an architecture and a set of specifications {S i } N i=1 , consider organizing the set of requirements ⋃ N i=1 { i,1 , … , i,N i } as nodes in a graph in accordance with each set Assu i,j and Full i,j .From the previously considered assumption that this graph is a DAG, it follows that this graph is in accordance with conditions (i)-(iii) of Definition 3. Now consider the effort of achieving property (3), i.e., completeness, between each requirement level specified by {S i } N i=1 using Theorem 1.In accordance with the specification structure described in Sect.3.1, Definition 3, and Theorem 1, this effort consists of tasks (I)-(IV) as described in Table 1.The content of Table 1 will be described in Sect.3.2.

Semiformal representations of requirements and architecture
In Sect. 1, requirements and architectures were formally defined based on the notion of an assertion, i.e., set of runs.However, in an industrial setting, requirements and architecture would typically not be represented formally, but rather informally, e.g., as free text, or semiformally, e.g., as a model with a defined syntax but without a well-defined semantics.This section describes and formalizes semiformal representations of requirements and architectures.
An architecture is represented semiformally if it can only be determined that condition (a)-(i) and (b) of Definition 1 hold and not condition (a)-(ii).This means that it is possible to distinguish the hierarchical structuring of elements and their interfaces, but not their behaviors.
A requirement is represented semiformally if the set of variables constrained by can be distinguished, but not its where (X i , ) ∈ (6) (II) Specifying 'interfaces of architecture elements,' i.e., specifying each X spec i to be in accordance with condition (4) (of condition (ii) of Theorem 1): (III) Specifying 'requirements,' i.e., specifying each requirement i,j such that: condition (5) (of condition (ii) of Theorem 1) holds, i.e., X i,j ⊆ X Env  ( i ) ∪ X i if Alloc i = (X i , ) ; and (8) condition (iii) of Theorem 1 holds, i.e., where } is the set of direct predecessors of i,j with 'Fulfills' arcs to i,j (IV) Specifying 'trace links between requirements,' i.e., specifying each set Assu i,j and Full i,j such that: each assumption in each set  i,j is in accordance with conditions (a) and (b) of Definition 3, i.e., each assumption is either: (a) a guarantee of a contract for a sibling of i ; or (b) an assumption of a contract for a proper ancestor of i , if the set of requirements as nodes in a graph in accordance with each set Assu i,j and Full i,j , then this graph is in accordance with conditions (iv) and (v) of Definition 3, i.e., the graph is such that: (iv) if there is an arc labeled 'Fulfills' from i,j to k,l , then k,l is a guarantee of a contract for a proper ancestor of i ; and (v) if a guarantee i,j is reachable from an assumption of a contract for a proper ancestor m of i , then is also an assumption of any contract ( k,l , k,l , X k ) where k is a proper ancestor of i and a descendant of m (including itself) and where k,l is reachable from i,j set of runs.For example, the requirement LMsys , shown in Fig. 2, can be represented semiformally as free text embedding distinguishable port variables l and f: Level l, presented by the level meter, shall be equal to actual level f in the tank.
These semiformal representations will, as part of the considered context, be assumed to be used to describe architectures and requirements in specifications.

Feedback-and guidance-driven support for tasks (I)-(IV)
Consider the context described in Sect.3.1, or more specifically, consider a set of specifications, as described in Sect.3.1.1,containing only semiformal representations of requirements for a system described by a semiformal representation of an architecture .Given this context, this section describes how formal support can be provided for each of the tasks (I)-(IV).This is achieved by enforcing contract conditions associated with these tasks; the conditions that can be evaluated in the considered context are those that are syntactic, i.e., those that can be evaluated despite the requirements and architecture representations being semiformal, and not formal.This support is considered to be of two different types, feedback and guidance.Feedback is considered to be the cases where a user, authoring specifications, is notified that content in a specification violates one of the syntactic contract conditions.Guidance covers the cases where it is distinguished to the user, prior to inserting content, that certain content is in accordance with these syntactic contract conditions and some content is not.
Note that the violation of a syntactic contract condition in a specification S can, in special cases, be identified even prior to specifying Alloc, i.e., the allocation of specification S.However, the focus in the rest of this section will be on describing the support provided for task (II)-(IV) for authoring S whenever Alloc has indeed been specified to be equal to an element.Violations that can be identified whenever Alloc is NIL will in any case be identified when an element is eventually specified to be Alloc.

Task (I): Specifying allocation of requirements to architecture elements
As shown in Table 1, the formal interpretation of task (I) is a contract condition (i.e., condition 6) that is violated whenever the allocation Alloc i of a specification S i is NIL or is equal to an element that is not in architecture .This condition can indeed be evaluated despite the fact that is represented semiformally, which means that this condition is a syntactic contract condition.The fact that this condition is syntactic is shown in Table 2.This table also shows which of the contract conditions of task (II)-(IV) that are syntactic; the table will be fully justified in subsequent sections.This section now proceeds to describe the support that can be provided by evaluating condition 6 in Table 1.
Let Alloc i be specified to be an element (X, ) in archi- tecture .Notably, considering the contract conditions that can be evaluated in Table 1, i.e., those that are syntactic in accordance with Table 2, it is possible that certain conditions can be evaluated directly after specifying the allocation, but not prior.This means that, whenever Alloc i is NIL, it is pos- sible to guide a user in specifying the allocation Alloc i by distinguishing to the user between which elements (in the architecture) that Alloc i can and cannot be equal to without violating the syntactic contract conditions associated with tasks (II)-(IV).Consider the following example.
Example 1 Consider a set of specifications containing requirements and trace links specified in accordance with the graph shown in Fig. 2 except that the requirement lMeter has not yet been allocated.That is, the requirement lMeter is in a specification S i where Alloc i is NIL.Prior to specifying Alloc i , it is possible to distinguish, to a user authoring S i , that if Alloc i is equal to, e.g., Esys instead of lMeter , then conditions (a)-(b) in Table 1 will be violated since Esys is not in the environment of lMeter in this architecture.□ Example 1 showed how guidance can be provided when specifying the allocation of a specification by distinguishing to a user that conditions (a)-(b) in Table 1 would be violated if the allocation were to be equal to a specific element.However, more generally, such guidance can be provided not only by evaluating conditions (a)-(b), but rather all of the contract conditions that are in Table 1 and are syntactic in accordance with Table 2.

Task (II): Specifying architecture element interfaces consisting of port variables
As shown in Table 1, condition (7) is the only contract conditions associated with task (II) and this condition is a Yes syntactic contract condition in accordance with Table 2.This condition is syntactic since whenever the allocation Alloc i of a specification S i is equal to an element (X i , i ) in architec- ture , it can be evaluated whether or not the interface X i is equal to the interface-specifying set X spec i in S i without know- ing the behaviors of the elements in .As will be shown in this section, support when authoring S i can be provided by evaluating this condition.An example now follows.
Example 2 Let S LMsys be a specification containing an inter- face-specifying set X spec LMsys = {f } and that the allocation of S LMsys is equal to the element LMsys , shown in Fig. 1b.Through evaluation of condition (7) in Table 1, it possible to give feedback, to a user authoring S LMsys , that the interface X LMsys = {f , l} of LMsys and the interface-specifying set X spec LMsys are not equal; it is also possible to provide guidance to the user by distinguishing which port variables that are not in the interface-specifying set, but only in the interface, and vice versa.□ As shown in Example 2, guidance and feedback for task (II) can be given by evaluating condition (7) in Table 1.Note that such support can be provided without acknowledging neither the interface-specifying set of a specification nor the interface, of the element to which the allocation of the specification is equal to in the architecture, to be the source of correctness.Under development, it is also only natural that they are not equal and typically there is neither need nor desire to resolve this immediately.However, at point of deployment, the interface-specifying set and the interface in the non-behavioral architecture data should be in accordance with condition (7).

Task (III): Specifying requirements
In accordance with Table 1, condition (8) and condition (9) of Theorem 1 are the contract conditions associated with task (III), i.e., specifying requirements.While condition (8) can be evaluated by only knowing which port variables that the requirements constrain, to evaluate condition (9), the runs of the requirements must also be known.That is, as shown in Table 2, condition ( 9) is not a syntactic condition and cannot be evaluated in the given context.However, as also shown in Table 2, condition (8) is indeed syntactic and the following will describe how feedback and guidance can be provided by enforcing this condition.
Consider that the allocation of a specification is equal to an element in the architecture.By evaluating condition (8) in Table 1, it is possible to give feedback by identifying each distinguishable port variable in requirements contained in the specification where such a port variable violates condition (8).An example of when condition ( 8) is violated is shown in Fig. 4.
Furthermore, when specifying requirements in a specification where its allocation is equal to an element in the architecture, it is possible to guide a user by distinguishing between port variables that a requirement can and cannot be specified over in order for condition (8) in Table 1 to hold.An example of this now follows.
Example 3 Consider a user specifying a requirement in a specification where its allocation is equal to the element Esys in the architecture shown in Fig. 1b.It is possible to give guidance to the user by distinguishing that specifying the requirement over, e.g., the set {f , v branch } will violate condi- tion (8) in Table 1, but over {f , l, h} , it will not.□

Task (IV): Specifying trace links between requirements
As expressed in Table 1, conditions (a), (b), (iv)-(v) are the conditions associated with task (IV).As previously mentioned in Sect.3.1.2,given that circular dependencies are not specified between requirements, conditions (i)-(iii) of Definition 3 automatically hold for the given context.
Regarding conditions (a), (b), (iv)-(v), all of these can be evaluated without knowing the runs of neither requirements nor elements, and thus, as shown in Table 2, these conditions are syntactic.In fact, these conditions can actually be evaluated regardless of the representation format of the requirements.Thus, by considering these conditions when specifying 'Assumption of' and 'Fulfills' trace links to and from requirements in a specification S i , i.e., specifying the sets Assu i and Full i , it is possible to guide the user by dis- tinguishing between trace links that will and will not violate conditions (a), (b), (iv)-(v) in Table 1.Additionally, feedback can be provided if already established trace links violate these conditions.Examples of when these conditions are violated are presented in Sect.4.6 in the context of an industrial example system.

Applicability of proposed support
Sections 3.2.1-3.2.1 described the feedback-and guidancedriven support that can be provided for tasks (I)-(IV) by enforcing the syntactic contract conditions in Table 2.As previously mentioned, this support was described given the context in Sect.3.1.This section discusses the applicability of the considered context and the proposed support.
Regarding the context, it can be noted that it does not impose any constraints neither on the order in which specifications are authored nor on the order in which content is entered within a specification.That is, a specification for a leaf element in the specification can be authored prior to a specification for the root element, and vice versa.Also, the requirements in a specification can be specified prior to specifying the interfacespecifying set, and the other way around.This means that the context, and thus also the proposed support, is indeed not restricted to any type of design flow: top-down, bottom-up, or anything in between.As previously mentioned in Sect. 1, such flexibility caters to the fact that different developers have dissimilar, yet successful, approaches for optimizing systems development; a top-down design flow might be optimal when, e.g., development is outsourced, but may be less optimal in other cases.
Regarding the assumption concerning the use of semiformal representations, while much of the proposed support is indeed available even when informal representations of requirements are used, semiformal or formal representations of both requirements and architecture are required to achieve full support.However, if working toward achieving stringent RE, then a higher level of stringency in representations might be needed anyway, and in safety standards such as ISO 26262 and DO-178C for the avionic domain, semiformal or formal representations are actually required.All in all, the context is in essence nothing more than a formalized setting for achieving stringent RE, which means that the proposed support is, at least in concept, applicable for any company working with stringent RE, driven, e.g., by FuSa.

Additional condition-enforcing support
This section discusses how to provide additional support by enforcing conditions, other than the syntactic conditions in Table 2, from the theory described in Sect. 2. Notably, out of the conditions in Table 2, condition (9) of Theorem 1 was the only condition that was not discussed in Sect.3.2 since this condition cannot be evaluated unless requirements are represented formally.However, if requirements are indeed represented formally, e.g., in the language Temporal Logic of Actions (TLA) + [45], then an approach such as [81] can be used to evaluate condition (9) of Theorem 1.
As previously mentioned in Sect.2.4, the work in [75] presents formal definitions of SIL assignment given a contract structure for an architecture.These definitions can be found in Appendix.In the same manner that the syntactic contracts are evaluated to provide support in Sect.3.2, these definitions can also be evaluated to provide support for assigning SILs to requirements; notably, these definitions can also be evaluated regardless of the representation format of requirements and behaviors of elements in the architecture.An example will be presented in Sect.4.6.

Implementation of specification tool in an industrial setting
As previously mentioned in Sect. 1, as an initial form of validation, an industrial case study was performed at trucks manufacturer Scania where the support presented in Sect.3.2 was implemented in a specification tool, which was also integrated into Scania's development tool chain.This section will describe and draw conclusions from this case study, but first, the overall goal and challenges faced when implementing this specification tool are presented.

Goal and challenges of industrial case study
The main goal of the case study was to evaluate the potential of realizing the support presented in Sect.3.2 in an industrial setting.Since the proposed support assumes the context described in Sect.3.1, realizing the support is dependent on that both the tool support and the context are implemented.Formulated as queries, the main challenges faced when implementing the context were: (A) Do architecture data in a semiformal format exist?(Do machine-readable architecture representations exist where data on the hierarchical structuring of elements and their interfaces can be extracted?If such representations do not exist, can these data be obtained in some other way?) (B) If architecture data in a semiformal format exist, potentially in different formats and stored in different databases and tools, how can the data be extracted and combined into an overall semiformal architecture representation?(C) How to enable and manage links from specifications to architecture data and between requirements in the same or different specifications?
Similarly, the main challenge when implementing the proposed tool support was: (D) How to evaluate syntactic contract conditions over specification and architecture data, possibly distributed over different databases and tools?
Addressing queries (A)-(D) evaluates whether or not it is feasible for the proposed support to be technically implemented in an industrial setting and is considered to provide an initial form of validation of the proposed support.The validation would be initial since even if a solution technically addresses the challenges formulated by queries (A)-(D), the solution may still suffer from having a low degree of usability, which means that such a solution would still not be viable in an industrial setting.For example, if the number of actions required to embed a reference to a port variable in a requirement (to specify it semiformally) is too high, then engineers will most likely not specify requirements semiformally, and will thus not get the full benefits from the proposed support.With this in mind, usability was considered as a critical aspect when implementing the specification tool.However, evaluating usability requires long-term empirical studies involving engineers working toward achieving stringent RE, and given that stringent RE is not currently practiced to a large extent, such studies are currently difficult to perform.Therefore, the focus of the present paper is on addressing queries (A)-(D), rather than on evaluating the aspect of usability.However, despite not being adequately evaluated, the present paper will still report on and discuss how the aspect of usability was taken into account in the implementation of the specification tool.Now that the overall goal and challenges of the industrial case study have been presented, the present paper will proceed in describing the case study.This case study also included working with an industrial example system, which will first be introduced.This industrial example will in the following be used instead of the simplistic LM-system that has been used for illustrating theoretical concepts.After describing the case study, an evaluation section follows where queries (A)-(D) are addressed.

Fuel level display system
Fuel level display (FLD) is a safety-critical system installed on all trucks manufactured by Scania, with a functionality to provide an estimate of the fuel volume in the fuel tank to the driver.The system is safety-critical since running out of fuel results in loss of power steering which, in turn, makes a heavy truck near impossible to steer.FLD will be described in terms of an architecture and a contracts structure for this architecture as shown in Fig. 6a, b, respectively.

FLD architecture
As shown in Fig. 6a, FLD FLD consists of a fuel tank Tank and three electric control unit (ECU)-systems, i.e., an ECU with sensors and actuators: Engine Management System (EMS) EMS ; Instrument Cluster (ICL) ICL ; and Coordinator (COO) COO .In turn, COO is composed of a fuel sensor fuelSensor and an ECU ECU , which consists of an application SW component FuelSW and a platform PLAT , i.e., ECU HW and infrastructure SW, which FuelSW executes on.Due to space restrictions, only a breakdown of one ECU-system is considered and this breakdown is also limited; see [74] for a more complete architecture.
The element COO estimates the fuel volume actualFu-elVolume in the tank Tank by a Kalman filter that is implemented by fuelSW .The platform PLAT is to ensure that the inputs estFuelRateIn and sensFuelLevelIn and output estFuelVolumeOut to FuelSW correspond to the inputs est-FuelRate and sensFuelLevel and output estFuelVolume of COO , respectively.The port variable sensFuelLevel represents the position of a floater in the fuel tank FuelTank , as sensed by the fuel sensor fuelSensor and estFuelRate is an estimate of the current rate of fuel injected into the engine and is a controller area network (CAN) signal, transmitted in CAN message FuelEconomy from EMS .The estimated fuel volume is transmitted as the CAN signal estFuelVolume in CAN message DashDisplay.This CAN message is received by ICL where a fuel gauge indicatedFuelVolume in the display presents the information to the driver.

Contract structure for FLD architecture
Each requirement shown in Fig. 6b is a safety requirement where the subscript of each safety requirement denotes which element the requirement is allocated to, e.g., FLD is allocated to FLD .These safety requirements are, instead of being represented formally as in the examples of assertions in Sect.2.1, represented semiformally as free text with formal references to port variables.As example of a requirement, the overall safety requirement FLD on FLD is represented semiformally as: indicatedFuelVolume, shown by the fuel gauge, is less than or equal to actualFuelVolume.
As another example, the safety requirement ICL , which is allocated to ICL , is represented semiformally as indicatedFuelVolume corresponds to estFuelVolume.

Referencing and dereferencing using linked data
Now that the FLD system has been described, the design and implementation of the specification tool follow.Each specification authored in the specification tool is structured to contain the data described in Sect.3.1.1,i.e., the allocation of the specification, its interface-specifying set, requirements, and their trace links.In addition to data contained in a specification, data from another specification or even from another tool can be presented when opening the specification in the specification tool.This is achieved through referencing this other data in accordance with Linked Data [9]: inserting a reference means inserting a Uniform Resource Locator (URL) that is associated with the data that are to be presented; the URL does not only contain the data that are to be presented, but rather information on how the data should be retrieved.Inserted URLs can be dereferenced in a standardized manner using Hypertext Transfer Protocol (HTTP).Whenever a URL is inserted, the specification tool will first retrieve the data and then present it accordingly.Note that dereferencing may be done in several steps since URLs associated with certain data may also contain URLs associated with other data.In accordance with the specification structure, each data object contained in a specification, e.g., requirements, their trace links, port variables, is associated with a URL.Dereferencing of URLs is done automatically by the specification tool, thus, ensuring that the presented data are consistent, i.e., updated with the data that are associated with the URL.Consider the following example.
Example 4 Assume that architecture data in accordance with Fig. 6a are made available as Linked Data.Consider inserting an URL associated with the port variable indicatedFuelVolume [%] with the intent of specifying the requirement FLD semiformally.Upon insertion, the URL is dereferenced, which results in that the name of the port variable is presented in the specification and made to be distinguishable as a port variable.If the data associated with this address is modified, e.g., if indicatedFuelVolume [%] changes name to indFuelLevel[%] , then upon refreshing the specification containing the requirement FLD , this change will be immediately reflected in the specification.□ As shown in Example 4, Linked Data enable data in specifications to be consistent.This is a crucial property in an industrial setting.Consider that data in specifications are manually updated or imported/exported between specifications rather than being linked in accordance with Linked Data.In practice, ensuring that all referenced data between them are continuously updated is unmanageable even for a relatively small set of specifications.

Using RDF for publishing and consuming linked data
The following terminology will be used throughout the rest of this paper: a tool is said to publish data if this tool makes data available to other tools in accordance with Linked Data; and if a first tool dereferences addresses associated with data published by a second tool, then the first tool is said to consume data from the second tool.
In practice, in order to publish and consume data, a standardized underlying data model is needed and this model is typically Resource Description Framework (RDF) [43].Accordingly, the specification tool publishes the data contained in specifications as RDF triples, consisting of a subject (URL), a predicate (URL), and an object (URL or a literal).Consider that these published data are represented as a graph with subjects and objects as nodes and predicates as arcs, which will in the following be referred to as links.The specification tool publishes data such that, for each specification, it holds that: • for each contained requirement in the specification: • each 'Assumption of' trace link, from a requirement ′ to , corresponds to a link from ′ to ; • each 'Fulfills' trace link, from to another requirement ′ , corresponds to a link from to ′ ; and • each distinguishable port variable in corresponds to a link from to a port variable in architecture data; • each member in the interface-specifying set where this member is a reference to a port variable in architecture data corresponds to a link from the interface-specifying set to this port variable in architecture data; and • the allocation of the specification, whenever containing a reference to an element in architecture data, corresponds a link from each requirement in the specification to this element.
Using Linked Data and RDF also enables the language SPARQL2 [60] for querying data.The specification tool uses SPARQL for evaluating the syntactic contract conditions in Table 2.More specifically, these evaluations are done by traversing and dereferencing links between data, and thus, the evaluations are over consistent data.
Note that so far, the source of the architecture data has not been described.This will be done in Sect.4.5, which follows after this section.However, the fact is that, when using the Linked Data approach, the source of the architecture data is not important; the source could be the specification tool itself, an external tool, or several external tools, whichever are used for modeling the system architecture.

Integration of specification tool into industrial tool chain
The integration of the specification tool into the tool chain at Scania is shown in Fig. 7 where arrows represent flow of data and where tools/aspects preexisting the integration and new tools/aspects of the tool chain are color-coded with gray and white, respectively.Regarding the data flow shown furthest to the left in Fig. 7, this bidirectional arrow represents the saving and loading of specifications; each specification is saved as/ loaded from exactly one file, called a specification file.Specification files are saved and loaded as Extensible Markup Language (XML)-files in accordance with Darwin Information Typing Architecture (DITA) [30].DITA is an open standard for authoring specifications and publishing them as, e.g., PDF-documents.
Specification files are stored in the preexisting version control system (VCS) along with SW implementation files, i.e., source code files (e.g., .c-files)and files (e.g., Simulink [17] .mdlfiles) that generate source code.Relying on preexisting VCS allows versions of specifications and SW to automatically coevolve since new versions of specifications are automatically created whenever SW development is branched/merged.
The arrows other than the one furthest to the left in Fig. 7 capture publishing/consumption of data as described in Sect.4.4.In general, any tool can consume/publish data; for example, test management systems (TMS) can consume data published by the specification tool and link additional information to the requirements such as who, where, when, and how requirements have been or will be tested.As another example, the specification tool can consume data from change management (CM) tools and link requirements to change requests.More importantly, the specification tool consumes architecture data published by other tools in the tool chain.
Consider published architecture data.In the following, the present paper will distinguish between such data that either: (i) describes the implemented system; or (ii) specifies the intended architecture of a system.In the following, data of As examples of such distinction between data, data extracted from a .h-fileassociated with a .c-filecould be architecture-describing data and architecture-specifying data could be data in a high-level architecture model, represented in a language such as SysML, Unified Modeling Language (UML) [67], or Architecture Analysis and Design Language (AADL) [24].However, this architecture model could also describe an implemented system; thus, this categorization into architecture-describing and architecture-specifying data is subjective.The important aspect is that this categorization is made clear in a specific tool chain.The following will describe how this categorization was done in the industrial case study.
Regarding publishing of SW architecture-describing data, these data are obtained from tools, i.e., publishers, which automatically analyze and extract data directly from SW implementation files in VCS using architecture recovery [62,82].For example, SW variables and the functions that read and write to them are extracted from parsing .hand .c-codefiles.Relying on architecture recovery ensures that the published data are consistent with SW files.In addition, published architecture-describing data are also linked to version data.
In a similar manner, HW/physical architecture-describing data publishers automatically analyze and extract data from production-based sources containing data that describe the implemented parts of the system that is not SW.Examples of these sources are the product data management (PDM) system, which lists the elements present in a particular vehicle; databases, e.g., CAN-DB, which lists CAN messages and signals; and other sources, e.g., Excel-files describing properties of sensors and actuators and computer-aided design (CAD)-systems.

Authoring support in specification tool
With respect to authoring specifications, the specification tool functions similar to a typical text editor, e.g., Microsoft Word, where sections and tables, and also images and equations can be removed or embedded in free text simply by inserting them from the menu.As shown in Fig. 7, the visual design of the user interface (UI) of the specification tool is also similar to a typical text editor, only the requirements appear differently and are distinguishable as rectangles filled with light gray as shown in Fig. 7.
The rest of this section will describe the support provided by the specification tool when authoring specifications; this includes both the feedback-and guidancedriven support for tasks (I)-(IV) described in Sect.3.2, as well as other type of support that increases quality of specifications.However, prior to presenting this support, a principle is introduced for how the syntactic contract conditions in Table 2 are evaluated.
This principle is that the syntactic contract conditions are evaluated considering architecture-describing data rather than architecture-specifying data.This principle is motivated by the fact that at the point of deployment of a system, requirements and other specification data should express intended properties of the implemented system and not properties of models that describe the system as it was intended to be implemented.
However, during development of a system, it might be the case that certain architecture-describing data are not available; in an early design phase in particular, it might be the case that only architecture-specifying data are available.Thus, during development, it might be desirable or even necessary to, e.g., express requirements over port variables in the architecture-specifying data or to manually specify interfaces instead of inserting references to architecture-describing data.This is indeed allowed by the specification tool; in fact, the specification tool will generally not restrict the user from entering data into a specification; the specification tool will simply identify if syntactic contract conditions are violated with respect to the architecture-describing data.
In summary, a user is free to refer to or enter data other than architecture-describing data in, e.g., requirements-as needed during system development.However, these data should eventually be replaced with architecturedescribing data references and the specification tool will therefore continuously alert the user until this is done.

Task (I): Specifying allocation of requirements to architecture elements
As explained in Sect.3.1, specifying the allocation of a specification to an element means allocating the requirements in the specification to this element.Specifying the allocation is incorporated into the specification tool by having an option where the user is prompted to select, from a list of architecture elements, the architecture element that the allocation of the specification is to be equal to.In accordance with Sect.3.2.1, when selecting from this list, the specification tool will guide the user by distinguishing between elements (in the architecture data) that the allocation can and cannot be equal to without violating the syntactic contract conditions associated with tasks (II)-(IV).Specifying the allocation of a specification can be done at any time after creating the specification.Prior to specifying the allocation, the tool will continuously urge the user to specify the allocation.

Task (II): Specifying architecture element interfaces consisting of port variables
Specifying the interface-specifying set of a specification is realized by a concept called interface table, which specifies interface port variables and their properties.In general, a specification can have several interface tables, typically one for each port variable type, e.g., CAN signals, sensor inputs, etc., since their properties and thus the number of desired columns in the table may differ.The union of the interface tables is the interface-specifying set.An example of an interface table is shown in Fig. 8.When entering data into interface tables, the user can input references to port variables in the architecturedescribing data using auto-complete functionality.An example of the auto-complete functionality is shown in Fig. 9 when entering data into the table also shown in Fig. 8. Upon entering a reference, the specification tool will automatically dereference and present, not only the name of the port variable as given in the architecturedescribing data, but also other relevant properties.
Whenever the allocation of the specification is equal to an element in the architecture-describing data, in accordance with Sect.3.2.2, the specification tool will evaluate condition (7) of Table 1 and give feedback and guidance.An example is shown in Fig. 8 where the user is provided with the feedback (table row marked yellow and warning triangle) that the port variable estFuelRate is not a port variable of FLD , as described by the consumed architecture-describing data that are in accordance with Fig. 6a.
Notably, as shown in Fig. 9, the auto-complete functionality also guides the user by distinguishing between which of the port variables that are and are not in accordance with condition (7) of Table 1.For example, in Fig. 9, the port variables that are and are not in accordance with condition (7) are followed by a check-mark and crosses, respectively.Additionally, there is an option to automatically populate entire interface tables with references to the interface port variables in architecture-describing data in accordance with condition (7), thus ensuring consistency and saving much manual and error-prone work.In the specification tool, as previously indicated, there is an option to insert requirements into a specification.The user is free to specify a requirement as seen fit; even images and equations can be embedded.
Explicit support is given for specifying requirements in semiformal representation as free text with references to port variables; two examples of such a representation format were presented in Sect.4.2.2.This support for specifying requirements in semiformal representation is given by having auto-complete functionality for entering port variable references.Figure 10 shows an example where a list of port variable names appear as possible references when specifying the safety requirement fuelSW .
Similar to the support provided for task (II) and in accordance with Sect.3.2.3,whenever the allocation of a specification is equal to an element, the specification tool will give feedback on requirements specified prior to their allocation.That is, the tool will flag port variable references that violate condition (8) of Table 1.Furthermore, as shown in Fig. 10, the auto-complete functionality will guide the user by distinguishing to the user between port variables (listed by the auto-complete functionality in consumed architecture-describing data) that are and not are in accordance with condition (8).

Task (IV): Specifying trace links between requirements
In the specification tool, for a requirement in a specification, there are options to specify 'Assumption of' and 'Fulfills' trace links between and other requirements.
As shown in Fig. 10, this is done by selecting sources for 'Assumption of' trace links and targets for 'Fulfills' trace links for from a fold-down menu with lists for specifying such trace links; hovering over a specified trace link source or target and the requirement reference is dereferenced and its representation is presented, as exemplified in Fig. 10 for the requirement ICL .As also shown in Fig. 10, there is an option to view published data on requirements and their links as a navigable 'Requirements Graph' (similar to Fig. 6b) that shows in the context of neighboring requirements that are traceable from or to through specified requirement trace links.
In accordance with Sect.3.2.4,whenever the allocation of a specification is equal to an architecture element, the specification tool will guide the user in specifying trace links between and other requirements by distinguishing between 'Assumption of' trace link sources and 'Fulfills' trace link targets that are and are not in accordance with conditions (a), (b), (iv), and (v) in Table 1.As previously mentioned in Sect.3.2.4 and as will be exemplified below, each of these conditions can be evaluated regardless of the representation format of requirements.
As a first example of how the specification tool can provide guidance, consider a specification that contains COO and where the allocation of the specification is equal to COO .Consider also that all the requirements in the graph shown in Fig. 6b are allocated as described in Sect.4.2.2.In accordance with conditions (a) and (b), when selecting 'Assumption of' trace link sources for the requirement COO , only the requirements tank , ICL , and EMS from this graph will appear as sources distinguishable as being in accordance with conditions (a) and (b).The other requirements in the graph, e.g., PLAT,1 , will be distinguished to violate these conditions since these requirements are not allocated to an element in the environment of COO , to which COO is allocated.
As a second example, consider specifying 'Fulfills' trace links for the requirement fuelSW shown in Fig. 10.Given that each requirement PLAT,i has been allocated to PLAT , each of these requirements will be distinguished to violate condition (iv) in Table 1.Condition (iv) is violated since PLAT is not a proper ancestor of fuelSW , to which fuelSW is allocated.
Similar to condition (v) in Table 1, enforcing condition (v) also allows distinguishing between the selection of possible 'Fulfills' trace link targets.An example of a case where adding a 'Fulfills' trace link would violate condition (v) was previously presented in Sect.2.3.2 and is shown in Fig. 3.
Note that the specification tool will allow any trace links to be specified as long as these do not result in cyclic dependencies; even when trace links result in that syntactic contract conditions are violated.However, whenever specified trace links violate these conditions, the tool will provide feedback by notifying the user and flagging these trace links.

Condition-enforcing support for specifying SILs
As shown in Fig. 10, SILs can be specified for requirements in a specification.The specification tool evaluates the definitions of SIL assignment in Appendix to be able to give feedback on SILs specified for requirements.Without getting into specifics, an example of where these definitions would be violated is if the requirement COO shown in the contract structure in Fig. 6b is assigned with a lower SIL than the requirement FLD .

Evaluation of tool support
This section describes how the implementations solutions used in the industrial case study addressed queries (A)-(D), which can, as previously mentioned in Sect.4.1, be considered as criteria for evaluating technical implementability of the support described in Sect.3.2.This section also discusses these solutions from a usability perspective.
Regarding query (A) 'Do architecture data in a semiformal format exist?', it would have been convenient if semiformal architecture representations, together providing an accurate description of the entire truck, would have been directly available, e.g., as SysMl models.However, in an industrial setting such as the development tool chain of Scania, architecture representations are predominantly informal, not consistent with system implementations, and containing errors.However, while not being available directly, semiformal architecture-describing data were found to be indirectly available in implementation artifacts, e.g., code, and in production-based sources such as the PDM-system in the Scania case.
Consider query (B): 'If architecture data in a semiformal format exist, potentially in different formats and stored in different databases and tools, how can the data be extracted and combined into an overall semiformal architecture representation?'.Since it cannot be assumed that semiformal architecture-describing data are not available directly in an industrial setting, these data would have to first be made available.As described in Sect.4.5, this was achieved by the use of adapters that publish architecture data retrieved through architecture recovery [62,82], i.e., through parsing and analyzing implementation artifacts and productionbased sources.Considering that an individual adapter only would typically publish only a part of the architecture of a system, for the data published by the different adapters to form an overall architecture, the data need to be linked together.This can be achieved by relying on a common data model, e.g., an RDF schema, which enables such linkage given that each publisher is compliant with the subset of the data model that concerns its published data.
Regarding queries (C) 'How to enable and manage links from specifications to architecture data and between requirements in the same or different specifications?' and (D) 'How to evaluate syntactic contract conditions over specification and architecture data, possibly distributed over different databases and tools?', as described in Sects.4.3 and 4.4, the proposed solution, which is considered to be general, was to use Linked Data.As previously mentioned in Sect.4.4, evaluation of the syntactic contract conditions can then be performed by traversing and dereferencing links, and thus, the evaluation can be performed over consistent data.
Regarding performing evaluations over consistent data, this requires that each reference is dereferenced every time an evaluation is made.Since traversal can sometimes by extensive and the number of dereferences high for the evaluation of a single contract condition, making sure that the evaluation is over consistent data was observed to sometimes come at the cost of slower performance of the specification tool.Fast performance is however a critical factor for ensuring the usability of the feedback-and guidance-driven support described in Sect.4.6.That is, it is considered critical that a user gets immediate feedback when violating a contract condition such that it is clear what action caused the violation, and for guidance, that the choices are distinguishable almost directly to avoid slowing down the user.To enhance performance, the specification tool was therefore implemented such that it sometimes caches dereferenced data locally and re-uses these data when doing evaluations.Due to this re-use of old data, there is a slight possibility that the specification tool exhibits unsound behavior, e.g., providing a warning when there is no violation of a contract condition.Thus, a general observation is that there seems to be a trade-off between performance and performing evaluations over the most consistent data-investigations are currently ongoing for trying to find the right balance.
Usability was, as previously mentioned in Sect.4.1, considered as a critical factor when implementing the specification tool.One aspect of usability has already been discussed above, namely performance.Other usability aspects concern features implemented in the specification tool.One such feature is auto-complete functionality, which supports specifying semiformal requirements with little additional effort than specifying informal requirements.Another usability-related feature is the hovering functionality, which allows a user to quickly get a description of referenced data without tracing the reference back to its source.
In summary, the case study indicated that the proposed support is indeed possible to technically implement, even when semiformal architecture data are not available directly.Thus, despite the need for further validation, especially longterm evaluation of usability, the case study showed high potential in realizing the proposed support in an industrial setting.

Related work
As mentioned in Sect. 1, there already exist approaches where contract theory is used to provide tool support.For example, contracts theory is used to provide tool support for safety analyzes in [19], safety certification in [69], modelbased design in [5], and failure propagation modeling in [56,57].More similar to the present paper, the work [13,14] presents tool support for verifying contracts refinement, which in essence corresponds to verifying completeness.Even more similar to the present paper, the work [16] describes tool support for verifying a hierarchical organization of contracts related to a system architecture model.Despite the similarities between [13,14,16] and the present paper, as previously mentioned in Sect. 1, while the tool support in [13,14,16] requires that contracts must be formally represented in the language linear-time temporal logic (LTL) [59], the tool support described in the present paper does not require that contracts are specified in formal representation; in fact, the present paper describes how explicit support can be provided when requirements are specified in semiformal representation.
There are also other works [23,27,44] that focus on providing feedback-and/or guidance-driven tool support for specification, albeit with a fundamentally different approach from the present paper.That is, in contrast to the present paper where support is provided by enforcing formal conditions, the works in [23,27,44] rely on natural language (NL) processing to provide feedback and guidance on requirements represented in NL considering, e.g., text length and terms usage with respect to a domain ontology/dictionary.Hence, while the approach in [23,27,44] improves readability of requirements, the approach in the present paper enforces their correctness, and thus, the approaches complement each other.NL processing is also used in [50,51] to automatically cluster and create trace links between requirements.One main difference between support relying on NL processing and the support proposed in the present paper is that while the former cannot in general be guaranteed to be sound, the support in the present paper only enforces necessary conditions and will, thus, never generate false-positives.
In contrast to [23,27,44,50,51], but in accordance with the present paper, the works [2,3,28,29] describe formally founded support for RE.Similar to the present paper, the works [3,28] both focus on establishing trace links between requirements and design/architecture.However, while the approach in the present paper is applicable for any type design flow, i.e., top-down, bottom-up, or anything in between, the approach in [3] requires using model transformations for driving development and is therefore only applicable for a top-down design flow.In contrast to the present paper, but similar to the previously mentioned contract-based approaches [13,14,16], the support in [3,28] relies on formal representations of architectures and requirements.The work in [2] describes a formal modelbased development methodology using requirements refinement.However, analogous to [3], this methodology is only applicable to a top-down design flow and also prescribes the use of formal models and requirements.In comparison, the support in the present paper is applicable in a greater context and this is to cater to needs in current state of industrial practice where requirements and architectures are typically not represented formally and where design flows vary, sometimes even within the same company.
Regarding the relation between the present paper and the work in [29], while both providing support for authoring specifications, the present paper and [29] have different focuses and complement each other; the present paper focuses on tool support for tasks (I)-(IV) while [29] focuses on transformation between requirements specified in NL, the formal representation format Object Constraint Language (OCL) [71], and a semiformal representation format in between these.
There also exist tool support [20,65] for Goal-Oriented Requirements Engineering (GORE), see, e.g., I* [80] or Knowledge Acquisition in Automated Specification (KAOS) [46] or [34,47] for literature reviews, where [46,80] draw on ideas presented in [39,40,58].While such tool support is indeed similar to the support proposed in the present paper, one main difference lies in the flexibility of how requirements can be hierarchically structured.More specifically, in GORE models, the use of assumptions, also called expectations, cannot be used at lower requirement levels and are strictly limited to constrain the environment of a SW system.This is in contrast to the present paper where the proposed support builds on a contract structure, which can be used to structure requirements for a system in any domain and where assumptions can be used at all requirement levels.

Conclusion
This paper has presented tool support applicable when working with stringent RE, e.g., as advocated by FuSa standards such as IEC 61508 and ISO 26262.Despite the need for further evaluations, especially long-term empirical studies, an industrial case study showed high potential in realizing the proposed support in an industrial setting.
More specifically, as the main contribution, by evaluating syntactic conditions from established contracts theory, it has been shown how feedback-and guidance-driven support can be given for tasks (I)-(IV) when authoring specifications in accordance with a system architecture.It has been shown that such support can be given for structuring requirements, regardless of their representation format.In particular, if requirements are expressed with references to port variables in an architecture describing the implemented system, then feedback-and guidance-driven can be provided for both specifying and structuring requirements.Furthermore, with the use of the proposed guided auto-complete functionality for input of references to port variables in architecturedescribing data, transforming requirements specified in NL to incorporate such references is straightforward.Notably, this approach caters to needs in current state of industrial practice where requirements and architectures are typically not represented formally.Furthermore, moving to specifying requirements containing such references also allows powerful analyzes over data on requirements and architecture to answer queries such as 'what requirements are enforced on my CAN signal or SW-variable?'.
A proposed concept for enabling such analyzes in practice is Linked Data, which supports formal referencing and dereferencing of data in between specifications and architecture data.In accordance with the Linked Data approach, it has been shown that input of references to architecture-describing data, not just in requirements, but also in, e.g., interface tables, allows to enforce specifications to be consistent with these data.Moreover, if architecture-describing data are obtained through architecture recovery, as in the industrial case study, this actually means enforcing specifications to be consistent with the SW implementation.Notably, such consistency is not only a mandatory property when attempting to achieve FuSa, but rather a highly desirable property of specifications in general.
Hence, not only has this paper described how to provide tool support for the stringent RE effort advocated by FuSa standards, but also how to increase quality of specifications in general.
Funding Funding was provided by VINNOVA (Grant No.

2011-04446).
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http ://crea tive comm ons.org/lice nses /by/4.0/),which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Appendix: Extending contracts theory with safety integrity levels
This section presents an extension of contracts theory, as described in Sect.2, with the notion of SILs.The contained material can be considered as a compressed and polished version of the work in [75].

Definition of SIL
In Sects. 1 and 2.4, a SIL was described as a measure of the required reliability of a system or component, in order to achieve a tolerable level of risk, i.e., the combination of the probability of harm and the severity of such a harm.Formulated differently in the context of specifying a SIL for a requirement, the SIL specifies the tolerable level of risk of violating the requirement.Thus, prior to presenting a formal definition of a SIL in the context of contracts theory, it is necessary to define what it means for a requirement to be violated.
Given an architecture {(X i , i )} N i=1 and a contract (, , X) for an element in the architecture, the guarantee is violated if a run of ⋂ N i=1 i is executed where {} ⊈ .
Definition 4 (Safety integrity level for guarantee) Given an architecture and a contract (, , X) for an element in , a SIL for the guarantee , denoted SIL , is a uniquely specified discrete level that corresponds to a target range of the probability that the guarantee is violated, during an arbitrary time interval of a predefined length.□ Definition 4 is in accordance with the definitions in ISO 26262 and IEC 61508, given that a 'safety function' in IEC 61508 is, or can at least correspond to, a top-level requirement and that an automotive SIL (ASIL) for a requirement in ISO 26262 can be mapped to a range of the probability that the requirement is violated.SILs range from 1 to 4 in IEC 61508 and ASILs from A-D in ISO 26262.Consider that a SIL is assigned to the requirement LMsys , as shown in Fig 2, as a result of assessing the risk of LMsys in the context of a specific architecture.Following a certain standard, this would imply that the specific instructions of that standard would have to be followed with the aim of achieving a failure probability of LMsys within the target range as specified by the SIL for LMsys .

SIL inheritance in contract structure
As described in Sect. 1, in ISO 26262, safety requirements are to be structured at different hierarchical levels with the intent that safety requirements at one level are to fulfill all safety requirements at the higher level.Consider that two lower-level safety requirements are to fulfill a higher-level safety requirement.If the higher-level safety requirement has been specified with a SIL D, for example, then the two lower-level safety requirements will inherit SIL D. If one of the lower-level safety requirements is also derived from another higher-level safety requirement, then that the lower-level safety requirement will inherit the highest SIL of the higher-level safety requirement.
In this section, the concept of SIL inheritance will be formally defined in terms of a contract structure.Prior to presenting such a formal definition, the concept is introduced informally by the use of the following representative examples (a) and (b), as shown in Fig. 11.
(a) In Fig. 11a, the intent is that the behavior of ′ is to fulfill 1 and 2 , given that the behavior of fulfills .Therefore, the highest SIL for 1 and 2 , i.e., 2, is specified for .(b) In Fig. 11b, the intent is that the requirement , allocated to the child of an element ′ , is to fulfill both requirements 1 and 2 , allocated to .Hence, the highest SIL for 1 and 2 , i.e., 2, is specified for .The requirement R ′′ allocated to ′′ is intended to fulfill only R 3 and is thus specified with the SIL 1.
As expressed in examples (a) and (b), if the intent is to rely on that a requirement is not violated in order to ensure that a requirement i is not violated, then the requirement should inherit the SIL of i .For example, the behavior of Esys cannot fulfill the requirement Esys unless the potentiometer is installed correctly in the tank, as expressed by tank and shown in Fig. 2. Thus, the SIL for tank is inherited from Esys .
A formal definition of SIL inheritance will now follow.Note that to fully understand the formal definition, SIL inheritance needs to be explained simultaneously with SIL decomposition.Hence, a detailed explanation will follow in 'Appendix: SIL decomposition in contract structure' section.
Definition 5 (SIL inheritance in contract structure) Given an architecture and a set of contracts ℭ organized as con- tract structure for , SIL inheritance is the specification of a SIL to a guarantee in a contract  ∈ ℭ for an element ∈ such that SIL = max(SIL 1 , … , SIL N ) where each i is either: (a) a guarantee without any incoming arcs labeled 'Fulfills' and is a direct predecessor of i and an assumption in a contract where i is the guarantee; or (b) a guarantee in a contract for an ancestor of and a direct successor of .

SIL decomposition in contract structure
Consider a case where either one of two safety requirements can, in fact, fulfill another higher-level safety requirement alone and that the safety requirements are allocated to two elements that are 'sufficiently independent,' i.e., absence of failures whose probability of simultaneous or successive occurrence cannot be expressed as the simple product of the unconditional probabilities of each of them, between two or more elements that could lead to the violation of a safety requirement, or organizational separation of the parties performing an action [37].
Given such a case, it is possible to assign lower SILs to the safety requirements than to the higher-level safety requirement by applying 'SIL decomposition,' i.e., apportioning of safety requirements redundantly to sufficiently independent elements, with the objective of reducing the ASIL of the redundant safety requirements that are allocated to the corresponding elements [37].
In this section, the concept of SIL decomposition in the context of a contract structure is presented.As previously described, SIL decomposition can only be performed if redundancy is present in a system.In order to capture the intent of achieving redundancy, the definition of a contract structure, i.e., Definition 3, is extended with an ' OR ⊥ ' node.Two representative examples follow immediately after the definition to explain the extension.Definition 6 (Extension of contract structure for architecture) Given an architecture and a set ⋃ N i=1 {( i,1 , i,1 , X i ), … , ( i,N i , i,N i , X i )} w h e r e e a c h ( i,j , i,j , X i ) is a contract for an element i of and where each assumption in each set  i,j is either: (a) a guarantee of a contract for a sibling of i ; or (b) an assumption of a contract for a proper ancestor of i , then a contract structure for is an arc-labeled DAG, such that: (i) each node is either a guarantee i,j or an ' OR ⊥ ' node and each guarantee i,j is a node; (ii) each arc is uniquely labeled either 'Assumption of" or "Fulfills'; (iii) if and only if k,l is in  i,j , then there exists an arc labeled 'Assumption of' from a node k,l to either: (a) i,j ; or (b) an ' OR ⊥ ' node that has exactly one outgoing arc to i,j , labeled 'assumption of'; (iv) if there is an arc labeled 'Fulfills' from i,j to k,l , then k,l is a guarantee of a contract for a proper ancestor of i ; and (v) if a guarantee i,j is reachable from an assumption of a contract for a proper ancestor m of i , then is also an assumption of any contract ( k,l , k,l , X k ) where k is a proper ancestor of i and a descendant of m (including itself) and where k,l is reachable from i,j ; (vi) if an ' OR ⊥ ' node has an incoming arc labeled 'Ful- fills' from i,j , then the ' OR ⊥ ' node has exactly one outgoing arc to a guarantee k,l of a contract for a proper ancestor of i ; and (vii) each ' OR ⊥ ' node has at least two incoming arcs and where any two incoming arcs to the ' OR ⊥ ' node, are guarantees of contracts for two different elements.□ The two following representative examples (a) and (b), also shown in Fig. 12a, b, capture two scenarios with the intent to achieve redundancy.
(a) As expressed in Fig. 12a, the intent is that it is sufficient that either one of the behaviors of two 'sufficiently independent' [37] elements ′ and ′′ in the environment to an element fulfills the respective requirements ′ and ′′ , in order for the behavior of to fulfill , i.e., that ( � ∪ �� ) ∩ ⊆ .(b) As expressed in Fig. 12b, the intent is that either one of two requirements 1 and 2 on two sufficiently independent children 1 and 2 of an element is able to fulfill a requirement of a contract for , i.e., that Considering examples (a) and (b), it is hence possible to assign a potentially lower SIL to ′ and ′′ , and also to 1 and 2 , than the SIL for , by performing SIL decomposition.

Definition 7 (SIL decomposition in contract structure)
Given an architecture and a set of contracts ℭ organized as contract structure for , SIL Decomposition is the specification of a SIL to a guarantee in a contract  ∈ ℭ for an element ∈ such that ≤ SIL ≤ max(SIL 1 , … , SIL N ) , where each i is either: Consider Fig. 13a that is intended to clarify why inheritance of SILs, through the use of assumptions, only apply to guarantees without any incoming 'Fulfills' arcs, as expressed in part (a) of Definition 5.If SIL C has been assigned to , for example, then SIL B and A can be assigned to 1 and 2 , respectively, according to part (b) of Definition 7 and ISO 26262.According to part (a) of Definition 5, ′ should inherit SIL B from the requirement 1 without any incoming 'Fulfills' arcs, rather than the SIL for , since redundancy has been introduced into .The same reasoning can be applied to decomposition of SILs, through the use of assumptions, as shown in Fig. 13b and expressed in part (a) of Definition 7.

Remark 2
Although not explicitly mentioned in either ISO 26262 nor IEC 61508, if both SIL decomposition and inheritance can be applied to a requirement , then the maximum SIL should be assigned to .□

Fig. 6
Fig.6 An architecture of FLD and safety requirements in a contract structure for this architecture, respectively

Fig. 7
Fig. 7 Integration of specification tool into the industrial tool chain at Scania

Fig. 8
Fig. 8 Snapshot (tweaked for enhanced readability) of the main window of the UI of the implemented specification tool

Fig. 9
Fig.9Entering data into interface table using auto-complete functionality

Fig. 10
Fig. 10 Snapshot (tweaked for enhanced readability) of a requirement in the implemented specification tool

Fig. 11
Fig. 11 Two representative examples of SIL inheritance are shown in context of contract structures

□
Part (a) and (b) of Definition 5 corresponds to examples (a) and (b), respectively.

Fig. 12 Fig. 13
Fig. 12 Two representative examples are shown where the intent is to achieve redundancy

Table 1
Formalization of tasks in context of authoring specifications (I) Specifying 'allocation of requirements to architecture elements,' i.e., specifying each Alloc i such that:

Table 2
Identification of the contract conditions in Table1to either be syntactic or not