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 [1]. Particularly, the automotive industry has adopted the functional safety standard ISO 26262 [2], which guides the development of the safetyrelated systems included in a specific class of road vehicles. To claim compliance with ISO 26262 from a process perspective, necessary pieces of evidence are: the safety plan, which is used to manage the execution of safety activities, as well as the corresponding confirmation review, which includes the compliance checking of planned processes against safety requirements. In [3,4], we have identified that automatic compliance checking of safety processes involves the definition of a finite state model of the process, where normative safety requirements provides the permissible states of the process elements. This task can be supported with available on the shelf tools. In particular, Formal Contract Logic (FCL) [5], a logic-based language stemming from business compliance, provides means to formalize normative requirements. However, formalizing safety requirements in FCL requires skills, which cannot be taken for granted. Patterns, which are "abstractions from concrete forms which keeps recurring in specific non-arbitrary context" [6], could represent a solution. In this paper, we follow Dwyer et al.'s specification patterns style [7], created to ease the formalization of systems requirements for finite state system model verification, to draw a general definition of safety compliance pattern. We also use specification patterns to identify and define Proceedings of the 1st Workshop on Technologies for Regulatory Compliance a set of ISO 26262-specific FCL compliance patterns. The defined patterns are instantiated to illustrate their applicability. This work will contribute to AMASS project [8], in particular, it aims at support the compliance management vision proposed, in which automotive is one of the 11 domains involved [9].
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.
This section recalls essential information required in our work.
ISO 26262 [2] addresses functional safety in automotive. The safety process influences functional safety. Thus, a confirmation review of the safety plan, which includes the compliance checking of the planned process against safety requirements is mandatory. The safety process can be either strictly planned, i.e., including all the activities provided by the reference process, or flexibly planned, i.e., by tailoring activities (omitting/performing them differently) [10]. According to ISO 26262:2, if a safety activity is tailored, a) the tailoring shall be defined in the safety plan and b) a rationale as to why the tailoring is adequate and sufficient to achieve functional safety shall be available.
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.
The Software unit design and implementation phase start. R2 8.1 Specify software units in accordance with the architectural design and the associated safety requirements.
R3 8.2 The detailed design will be implemented as a model or directly as source code.
R4 8.4.2 The software unit design shall be described using specific notations, which are listed as alternative methods.
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance
The specification patterns, formulated by Dwyer et al.'s [7], are "generalized descriptions of commonly occurring requirements on the permissible state sequence of a finite state model of a system." A selected set of Dwyer et al.'s patterns is presented in Table 2. The reader may refer to [11] to see the complete set of patterns with their entire descriptions. Each pattern has a scope, which is the extent of the program execution over which the pattern must hold. The types of scope that we consider in this paper are: global, which represent the entire program execution, before, which includes the execution up to a given state, and after which includes the execution after a given state.
Formal Contract Logic (FCL) [5] is a language designed to formalize normative requirements. FCL is implemented in Regorous, a tool developed by Data61/CSIRO in Australia 1 . An FCL rule is represented as follows:
r : a 1 , ..., a n ⇒ c, where: a 1 , ..., a n = 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 [12]. In the modeling of the rules, the normative effect requires a notation that clarifies the applicability of the norm (presented in Table 3). Thus, if an obligation has to be obeyed during all instants of the process interval, it is called maintenance obligation. If achieving the content of the obligation at least once is enough to fulfill it, it is called achievement obligation. An achievement obligation is preemptive if it could be fulfilled even before the obligation is actually in force. Otherwise, it is non-preemptive. If the obligation persists after being violated, it is a perdurant obligation, otherwise is a non-perdurant. A binary relation between rules (>) allows handling rules with conflicting conclusions.
Table 3. FCL rule notations [12] Notation Description
[P]P P is permitted
[OM]P There is a maintenance obligation for P
[OAPP]P There is an achievement, preemptive, and non-perdurant obligation for P
[OANPP]P There is an achievement, non-preemptive and perdurant obligation for P
[OAPNP]P There is an achievement, preemptive and non-perdurant obligation for P
[OANPNP]P There is an achievement, non-preemptive and non-perdurant obligation for P
This section introduces our definition of safety compliance pattern as well as our identified and defined ISO 26262-related compliance patterns.
As recalled in the introduction, automatic compliance checking of safety process involves the definition of a finite state model of the process, where normative safety requirements provide the permissible states of the process elements. This statement allows us to think of a process as a kind of system that can be verified. Thus, we can translate the specification pattern definition (see Section 2.2) into our context as follows: safety compliance patterns are patterns that describe commonly occurring normative safety requirements on the permissible state sequence of a finite state process model. With this definition, we can develop a mapping between specification patterns and safety compliance patterns, as follows: the presence of a state in a system can be interpreted as the state of the obligation imposed to an element in the process, and the scope corresponds to the interval in a process when the obligations formulated by the pattern are in force. In Section 3.2, we identify the safety compliance patterns extracted from ISO 26262.
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
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance 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.
Pattern: Address Phase. Recurring structure: A phase. Obligation for compliance: 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 address{Phase} is triggered by a previous task {optionalTriggeringObligation}, 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, tailor{Phase} and rationaleForOmiting{Phase} (See Formula 1).
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 {TriggeringObligation} prohibits the performing of the task perform{Task}. The permission of performing perform{Task} is granted after the preconditions are fulfilled perform{Preconditions} (See Formula 2).
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance 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 {TriggeringObligation} imposes the obligation of selecting a method select{Method1}.
The selection of a second method select{Method2}, derogates the previous selection select{Method1} (See Formula 3).
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 {TriggeringObligation} imposes the selection of methods according to the requirements select{mandatoryMethods}. The provision of the rationale is the permission that derogates the obligation (See Formula 4).
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).
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). 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).
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).
Patterns for the formal specification of system safety requirements are presented in [13]. These patterns consider the cases and the terminology used in industrial automation systems to facilitate formal verification. Our patterns, instead, are restricted to processcentered requirements. Some works provide patterns for facilitating the formalization of the normative requirements for compliance checking in areas like business process compliance, e.g., the works presented in [14,15] which extends Dwyer et al.'s specification patterns, and the work presented in [16], which uses REA (Resources, Events, and Agents) approach. A similar work, in the context of security, is presented in [17], which aims at providing a pattern structure for generating security policies for serviceoriented architectures. In our work, as in some of the previously mentioned works, we use Dwyer et al.'s specification patterns as a base for providing our definition for safety compliance pattern. Also, we identified and defined the safety compliance patterns present in some structures of the standard ISO 26262. Moreover, our patterns are formalized in FCL, a formal language that is explicitly created for compliance checking, providing precise structures for modeling, e.g., deontic effects, which facilitate the expression of normative requirements in a more natural way.
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 Proceedings of the 1st Workshop on Technologies for Regulatory Compliance providing more elaborated guidelines. Our work on safety compliance patterns is expected to be combined with previously achieved results [3,4] regarding the provision of a framework to increase efficiency and confidence in process compliance management.
Acknowledgments. This work is supported by the EU and VINNOVA via the ECSEL JU project AMASS (No. 692474) [8].