ISO 26262 demands a confirmation review of the safety plan, which includes the compliance checking of planned processes against safety requirements. Formal Contract Logic (FCL), a logic-based language stemming from business compliance, provides means to formalize normative requirements enabling automatic compliance checking. However, formalizing safety requirements in FCL requires skills, which cannot be taken for granted. In this paper, we provide a set of ISO 26262-specific FCL compliance patterns to facilitate rules formalization. First, we identify and define the patterns, based on Dwyer' et al.'s specification patterns style. Then, we instantiate the patterns to illustrate their applicability. Finally, we sketch conclusions and future work.
Safety critical systems designers rely on safety standards, which embody the public
consensus of acceptable risk [
The rest of the paper is organized as follows. In Section 2, we provide essential background. In Section 3, we provide our definition of safety compliance pattern as well as our identified and defined ISO 26262-related patterns. In Section 4, we instantiate the defined safety compliance patterns. In section 5, we present related work. Finally, in Section 6, we present conclusions and future work. 2
This section recalls essential information required in our work.
2.1 ISO 26262
ISO 26262 [
From a structure perspective, ISO 26262 is divided into parts, which are subdivided into clauses. Some clauses represent phases of the safety process, which also describe activities and tasks. ISO 26262 uses Automotive Safety Integrity Levels (ASIL), which are levels to specify item’s necessary safety requirements. Alternative methods to use in the planning of safety activities (e.g., tables) have to be chosen according to the higher recommendation for the ASIL assigned, but if not, a rationale shall be given that the selected methods comply with the corresponding requirement. Disjoint alternatives are also included in the text of the normative requirements. Frequently recurring expressions, which can guide the reading of the standard, can also be found, e.g., in accordance with. In Table 1, we recall a subset of requirements from ISO 26262:6 clause 8, which specifies the software unit design and implementation phase. 2.2
The specification patterns, formulated by Dwyer et al.’s [
Name Absence Existence Universality Precedence Response r : a1; :::; an ) c; where: a1; :::; an = Conditions of the applicability of the norm.
c = Normative effect.
If a rule has an empty antecedent, it represents the definition of a new term. Otherwise,
it represents the triggering of deontic notions, i.e., obligations, situations to which the
bearer is legally bounded, or that should avoid, and permissions. If something is
permitted the obligation to the contrary does not hold [
For identifying a safety compliance pattern in ISO 26262, we have delineated five methodological steps. The first step consists of the selection of a recurring structure in the standard since, as recalled in Section 2.1, safety requirements in ISO 26262 have implicit and explicit structures. The second step is the description of the obligation for compliance, namely, the reasons why the structure is required for safety compliance. The third step is the pattern description, based on similar (or a combination of) behaviors of the patterns described by Dwyer et al.’s (see Table 2). This description is contextualized to safety compliance, based on the mapping presented in Section 3.1. In this step, we also assign a name for the safety pattern, which reflects the related obligation for compliance. The fourth step is the definition of the scope of the pattern, which we also base on Dwyer et al.’s work. The fifth step is the formalization in FCL. To formalize the pattern, the scope defined for the pattern requires being mapped into the rule notations provided by FCL. Therefore, a global scope, which represents the entire process model execution, can be mapped to maintenance obligation, which represents that an obligation has to be obeyed during all instants of the process interval. A before scope, which includes the execution of the process model up to a given state, can be mapped to the concept of preemptive obligation, which represents that an obligation could be fulfilled even before it is in force. An after scope, which includes the execution of the process model until a given state, can be mapped to the concept non-preemptive obligation, which represents that an obligation cannot be fulfilled until it is in force. It should be noted that, in safety compliance, it is possible to define exceptions for the rules. Therefore, if the obligation admits an exception, the part of the pattern that corresponds to the exception is described as a permission, since, as recalled in Section 2.3, if something is permitted the obligation to the contrary does not hold. The obligation, to which the exception applies, is modeled as non-perdurant, since the permission is not a violation of the obligation, and therefore the obligation does not persist after the permission is granted. In this case, the obligation and a permission have contradictory conclusions, but the permission is superior since it represent an exception. These methodological steps have helped us to define an initial set of four ISO 26262 - related FCL compliance patterns, presented in Section 3.3. The description of our patterns has information related to the steps mentioned above. Therefore, the corresponding expressions in bold represent the elements of the pattern’s description.
In what follows, we define our safety compliance patterns in ISO 26262.
Every phase proposed by the safety model must be addressed. A phase can be omitted if tailoring is performed and a rationale is provided. Pattern description: Universality + absence - A phase must occur. Not addressing the phase requires its tailoring and the provision of a rationale. Scope: Global. FCL mapping: A maintenance obligation addressfPhaseg is triggered by a previous task foptionalTriggeringObligationg, which can be empty if the phase is checked for compliance in isolation from the other phases. The permission for not addressing the phase requires two antecedents, tailorfPhaseg and rationaleForOmitingfPhaseg (See Formula 1).
r : foptionalTriggeringObligationg ) [OM]addressfPhaseg r0 : tailorfPhaseg;rationaleForOmitingfPhaseg ) [P] addressfPhaseg r0>r Pattern: Perform Preconditions. Structure: The structure implicit in the expression in accordance with. Obligation for compliance: A task is prohibited until the preconditions are performed. Pattern description: Absence + precedence - A given task cannot occur within a scope. The task is permitted to be performed if the preconditions are performed. Scope: After. FCL mapping: A rule triggered by a previous rule fTriggeringObligationg prohibits the performing of the task performfTaskg. The permission of performing performfTaskg is granted after the preconditions are fulfilled performfPreconditionsg (See Formula 2).
r : fTriggeringObligationg ) [OANPNP] per f ormfTaskg r0 : per f ormfPrecondition1g;:::; per f ormfPreconditionNg ) [P]per f ormfTaskg r0>r (1) (2) Pattern: Select Disjoint Methods. Structure: Structure implicit when the word or is used to list two methods. Obligation for compliance: Only one method can be selected from a list of two. Pattern description: Existence + absence - A given method can be selected within a scope. The presence of a second method derogates the selection of the first method. Scope: After. FCL mapping: A rule triggered by previous obligations fTriggeringObligationg imposes the obligation of selecting a method selectfMethod1g. The selection of a second method selectfMethod2g, derogates the previous selection selectfMethod1g (See Formula 3).
r : fTriggeringObligationg ) [OANPNP]selectfMethod1g] r0 : selectfMethod2g ) [P] selectfMethod1g r0>r (3) (4) (5) Pattern: Select alternative methods. Structure: Alternative methods given in tables. Obligation for compliance: Methods should be selected according to ASIL/recommendation levels. Alternative methods can be selected if a rationale is provided. Pattern description: Response + absence - A given obligation has to occur. The provision of a rationale grants the permission to derogates the obligation. Scope: After. FCL mapping: A rule triggered by previous obligations fTriggeringObligationg imposes the selection of methods according to the requirements selectfmandatoryMethodsg. The provision of the rationale is the permission that derogates the obligation (See Formula 4).
r : fTriggeringObligationg ) [OANPNP]selectfmandatoryMethodsg r0 : provideRationaleForNotSelectfmandatoryMethodsg ) [P] selectfmandatoryMethodsg r0>r In this section, we instantiate the patterns defined in Section 3.3, using the ISO 26262 requirements presented in Table 1.
Requirement R1, which defines the phase software unit design and specification, can be specified by using the pattern Address Phase. We assume that the phase is checked in isolation from other phases (See Formula 5).
r1 :) [OM]addressSwUnitDesignAndImplementation r10 : tailorSwUnitDesignAndImplementation;rationaleForOmitingSwDesignAndImplementation ) [P] addressSwUnitDesignAndImplementation r10>r1 Requirement R2 have the expression in accordance with, which can be represented with the pattern Perform Preconditions. Specifically, the software architectural design and the associated safety requirements are preconditions to specify the software units. We assume that the triggering rule is addressSwUnitDesignAndImplementation (See Formula 6).
r2 : addressSwUnitDesignAndImplementation ) [OANPNP] per f ormSpeci f ySwUnit r20 : per f ormProvideSwArchitecturalDesign; per f ormProvideSa f etyRequirements ) [P]per f ormSpeci f ySwUnitfTaskg r20>r2 (6) Requirement R3 mentions the use of two disjoint implementation strategies, namely implementation as a model or directly as source code. Therefore, this requirement can be modeled using the pattern Select Disjoint Methods. We assume that the triggering rule is implementingSwUnit (See Formula 7).
r3 : implementingSwUnit ) [OANPNP]selectImplementingAsSourceCode(X) r30 : selectImplementingAsModel(X) ) [P] selectImplementingAsSourceCode(X) r30>r3 (7) Requirement R4 refers to a table with alternative entries. This requirement can be represented by using the pattern Select alternative methods. We assume that the triggering rule is performSpecifySwUnit (See Formula 8).
r4 : per f ormSpeci f ySwUnit ) [OANPNP]selectMandatoryNotations f orSwDesign r40 : provideRationaleForNotSelectMandatoryNotations f orSwDesign ) [P] selectMandatoryNotations f orSwDesign r40>r4 (8) 5
Patterns for the formal specification of system safety requirements are presented in [
In this paper, we use Dwyer et al.’s specification patterns style to provide our definition of safety compliance patterns. Also, we identify and define set of ISO 26262-specific FCL compliance patterns, which were extracted from implicit and explicit recurring structures provided by ISO 26262. In the last part of our work, we have instantiated the defined safety compliance patterns, to illustrate their applicability.
In future, we plan to examine other clauses of ISO 26262 to apply the proposed
patterns and discover additional ones. Once a complete catalogue of safety
compliance patterns embracing ISO 26262 is ready, we plan to facilitate their instantiation by
providing more elaborated guidelines. Our work on safety compliance patterns is
expected to be combined with previously achieved results [