JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS

J. Softw. Evol. and Proc. 2014; 26:829836

Published online 7 September 2014 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/smr.1670

An approach to manage the concept phase of ISO 26262

Masao Ito1,*, and Koichi Kishida2
1

Nil Software Corp, 2-17-7, Kinuta Setagaya, 1570073, Japan

Software Research Associates, 4-1, Kioi-cho, Chiyoda, 1028578, Japan

ABSTRACT
We face two difculties when applying ISO 26262[1] in the concept phase. ISO 26262 is the functional safety standard in the automobile eld and requires strict safety requirements. Usually, it is not
easy to divide requirements into safety parts and non-safety parts because they are closely connected
with each other. That is, we have to perform two activities, functional development and functional
safety activity, simultaneously. Other difculty is a term item. From the denition, the item is a
system (1.129) or array of systems to implement a function at the vehicle level. In concept phase,
we apply hazard analysis to an item, not system. The system denition comes after item denition
and hazard analysis and risk assessment. So, it is hard to use the conventional methods (e.g. Failure
Mode and Effect Analysis (FMEA) and Fault Tree Analysis (FTA)).
To support this situation, we propose a method and a tool. Our method is an extension of knowledge
acquisition in automated specication, and we also use the Goal Structuring Notation and scenariosituation
matrix. The drawback of multi-diagrams approach is the difculty of maintaining the integrity of data, but
the linkage mechanism of our tool provides the good navigation measure to transit a node of a diagram into
the other node of a different diagram.
Although we aim to support the scope of part 3 of ISO 26262, we believe this approach is not
limited to the automobile eld and can be used in a wide range of elds Copyright 2014 John
Wiley & Sons, Ltd.
Received 11 June 2014; Accepted 16 June 2014
KEY WORDS:

ISO 26262; functional safety; requirements; KAOS; GSN; DSPO; hazard analysis

1. INTRODUCTION
There are various methods to analyse the safety of a system by using the detail information of
its design. But the assumption of those methods that a system is clearly decomposed might need
the rework of design after analysing safety. The functional safety standard for automobile ISO
26262 requires the hazard analysis and risk assessment before system design. It means that we
cannot use the detail design information of a system; therefore, it is hard to apply the
conventional methods.
First, we indicate the characteristics of ISO 26262 and issues of it (Section 2); then, we present our
approach to match into the standard (Section 3), after introducing a tool that supports our idea (Section
4) and we compare them to the related works (Section 5). Finally, we conclude them (Section 6).
It is important to note the way of work in the concept phase, because we check or assess these
activities based on their better understanding.

*Correspondence to: Masao Ito, Nil Software Corp, 2-17-7, Kinuta, Setagaya, 1570073, Japan.

E-mail: nil@nil.co.jp
Copyright 2014 John Wiley & Sons, Ltd.

830

M. ITO AND K. KISHIDA

Figure 1. Meta-model of elements in the concept phase.

2. CHARACTERISTICS OF ISO 26262 IN THE EARLY PHASE

We focus on the early phase of the process that ISO 26262 requires, that is, the concept phase. We
examine the two characteristic points in this phase. One is the special term item in this standard. The
second is the safety case. It is dened in the management of functional safety (ISO 26262 Part 2)
and used the entire lifecycle (22.4.6). So, we have to consider it also in the concept phase.
In Figure 1, we depict the keyword and their relationships in the concept phase as a meta-model. The
central idea is the keyword item (Section 2.1), and it generates two types of requirements:
the conventional requirements and the functional safety requirements. The safety case assures the
performance of safety activity with the evidence through the entire development lifecycle
(Section 2.2).

2.1. The term item

The denition of the term item is system (11.129) or array of systems to implement a function at the
vehicle level, to which ISO 26262 is applied (11.69). From this denition, we may think an item is a
system, but in the early phase of a new project, there is no clear denition of the system. And in the
guideline (part 10 of [1]), the type of relationship between the item and system is a realization. At
rst, the item is only a kind of concept, which is not a concrete one, and becomes a system as its
development proceeds.
The concept phase starts from the item denition, and we initiate the safety lifecycle and do the hazard
analysis and risk assessment (HARA). In this activity, we identify hazards and classify hazardous events
and describe the safety goal with the Automotive Safety Integrity Level (ASIL). Safety goal is the toplevel safety requirement, and we will derive functional safety requirements from it. In this process, it is
the item that we are hard to deal with because the conventional hazard analysis methods are premised on
the well-described system. So, we have to answer the questions shown in the succeeding texts:
How can we describe and dene an item?
What method can we use to perform HARA against the item denition?
2.2. Safety case
There is another activity that we have to perform in the concept phase. Part 3 of ISO 26262 denes
the activities for management through the safety lifecycle. We focus on the next request: This
requirement shall be complied with for items that have at least one safety goal with an ASIL
(A), B, C or D: a safety case shall be developed in accordance with the safety plan (26.4.6.1).

The guideline (part 10) was released 8 months later after the other parts are issued, so we may think that the new denition is appropriate currently.

Copyright 2014 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2014; 26:829836

DOI: 10.1002/smr

AN APPROACH TO MANAGE THE CONCEPT PHASE OF ISO 26262

831

Figure 2. General view of our approach.

Safety goals are dened in the concept phase, so we have to start indicating evidences and
arguments showing that a safety goal is achieved.
So, we have a question shown in the succeeding texts:
How can we correlate the safety goal with the safety case?

3. OUR APPROACH
To answer the previous questions that we present in Section 2, we propose a method as a solution. This
approach uses three models: the goal model, the safety case and scenariosituation matrix. The goal
model is used in requirement elicitation phase, and it is the hierarchical expression of users top goal.
We focus on the early phase of system development. So, this model is the centric role in our approach.
We can use the goal model of knowledge acquisition in automated specication (KAOS) method for
this purpose. The safety case is widely used in the development of safety-critical system and consists of
facts about the site (system), reasoned arguments about the risks and the conclusion [2]. The Goal
Structuring Notation (GSN) is the graphical representation of the safety case. The scenariosituation
matrix (SSM) gives us the scenarios in the complicated situation. For example, the automobile runs on
very complicated situations, and other than self-vehicle, we have to consider the location and speed of
other cars and pedestrians, trafc information and weather condition. The scenario is dened by the
combination of those elements of the situation. First, we briey introduce each technique (KAOS, GSN
and SSM) and then present our method and the process that indicates how we use those techniques.
Figure 2 shows a general view of our approach and the relations of those three techniques.
We use the adaptive cruise control (ACC) system for an explanation purpose. ACC is
Enhancement to conventional cruise control systems that allows the subject vehicle to follow a
forward vehicle at a preselected time gap by controlling the engine, powertrain, and/or the service
brake [3].

3.1. Knowledge acquisition in automated specication

Knowledge acquisition in automated specication approach (e.g. [46]) is a typical method in the
Goal-Oriented Requirement Engineering eld. It has six models: goal model, obstacle model, object
Copyright 2014 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2014; 26:829836

DOI: 10.1002/smr

832

M. ITO AND K. KISHIDA

model, agent model, operation model and behaviour model. The key model in them is the goal model
as a hub to other models, and it can include the elements of other models (for example, we can use
agent node or operation node within the goal model). The top goal is rened with AND/OR
relationship between a goal and subgoals, and nally, we can get the requirements. The structure is
tree like, but strictly speaking, an acyclic directed graph.
There are several nodes. We will just show some of them for the explanation purpose: The
goal node is desired functional or qualitative behaviour. The requirement node is the low-level
goal (i.e. a terminal goal of a goal graph). The obstacle node is the condition whose
satisfaction may prevent some goals. The softgoal is the goal that does not have a clear-cut
criterion for their satisfaction.
3.2. Goal Structuring Notation
The GSN (e.g. [79]) is a graphical argument notation which can be used to document explicitly the
elements and structure of an argument and the arguments relationship to evidence. Usually, GSN is
used to describe the safety case or assurance case (that covers the wider range than safety case does,
e.g. security). It has several types of nodes. The main nodes are goal (requirements or claim),
argument (connector between goal and evidence, originally used as the same node as the goal) and
evidence (solution). And there are context node, assumption node and justication node to
complement the main nodes.
3.3. Scenariosituation matrix
We also introduce the SSM. In order to analyse the safety or security of a system in the early phase, it is
necessary to take all into account about the target system and other objects existing in its environment.
The scenario consists of the combination of elements of the situation, and we can write scenarios
depending on various situations (generally, the element belongs to a category). Each scenario helps
us in nding hazards and the threats of the system.
In ACC, the category of the element of situation is like subject car, target car, perimeter (e.g.
pedestrian), road type, road condition, regulation, environment or driver. And, for example,
the category subject car has the element like speed, acceleration, jerk and engine state.
The scenario is the sequence of events with the dened situation. For example, under rainy weather,
we drive the car around 100 km/h on the highway. This includes the environment (rainy weather), the
speed of the subject car (100Km/h) and road type (on the highway). By using this matrix, we can
create the complicated situation and prevent the oversight of situations.
We use this SSM in two places; rst, hazard analysis to nd hazards in the hazard analysis phase,
and the second is the calculation of the ASIL in the risk assessment phase.
3.4. Process
In order to develop or consolidate requirements, we rst use the goal model of KAOS. By using AND/
OR renements, we can get the base of the item denition. On the way to renements, we might notice
the obstacles to achieve a goal. In safety point of view, an obstacle node is a candidate for hazard. We
may analyse hazard in a more formal way: In [10], we propose the Dependability Software Process
Optimization method, which is a hazard analysis method and based on hazard and operability
(HAZOP) [11]. The basic idea is quite simple. If we choose the guideword NOT, we try to negate
the goal node. If, for example, a goal is Recognize a forward car, we then think what if we cannot
recognize a forward car (i.e. NOT is one of guidewords in HAZOP). With other guidewords, we
may be able to nd other obstacle nodes.
Because we conne our discussion to the automobile domain in this paper, the SSM is specialized for
the operation modes of the car, like driving and parking. Usually, situations are very complicated, but we
can cover them with just choosing elements from each category (that is, categories are orthogonal). We

In this context, the obstacle is not a stone or something on the road. It obstructs achievement of goal in KAOS method.
And it belongs to one of the obstacle categories: hazard, threat, dissatisfaction, misinformation, inaccuracy and
unusability. In this paper, we focus on the obstacle of hazard category.

Copyright 2014 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2014; 26:829836

DOI: 10.1002/smr

833

AN APPROACH TO MANAGE THE CONCEPT PHASE OF ISO 26262

Table I. ISO 26262 (part 3) and our approach.

ISO 26262 requirements and recommendations
35

Item denition

35.4.1

35.4.2

36

Initiation of
safety lifecycle

36.4.1
36.4.2

37

Hazard analysis
and risk
assessment

37.4.1
37.4.2
37.4.3
37.4.4

38

Functional
safety concept

Our approach

The functional and nonfunctional requirements of

the item as well as the
dependencies between the
item and its environment
shall be made available.
The boundary of the item,
its interfaces, and the
assumptions concerning its
interaction with other
items and elements, shall
be dened .
Determination of the
development category
Impact analysis and possible
tailored safety lifecycle, in
the case of modication
Initiation of the hazard
analysis and risk assessment
Situation analysis and hazard
identication
Classication of hazardous
events
Determination of ASIL
and safety goals

37.4.5

Verication

38.4.1
38.4.2

General
Derivation of functional
safety requirements

38.4.3

Allocation of functional
safety requirements

38.4.4

Validation criteria

38.4.5

Verication of the
functional safety concept

The requirement node that

comes from the goal or
softgoal nodes can be used
to express the functional
or non-functional
requirements of the item.
The boundary can be written
by UML, and we can link
to it in the goal model. But
it is out of our scope in
this paper.
N/A (just decide new
development or modication)
The impact analysis can be
done through our goal model.
Distinguish the element of the
item whether it has the internal
safety mechanism or not.
Use the SSM and DSPO.
N/A (just follow the standard)
Use Table 4 of part 3. Safety
goals correspond to the
solutions that are backed by
evidence and arguments.
Correctness can be veried
through the arguments
of GSN.
N/A
The goal nodes of KAOS
that solves the problem
of obstacle node are the
base of functional safety
requirements
If architecture is writing
in UML, we can allocate
each requirement to classes
or parts.
In GSN, we can present
the controllability or
effectiveness (49.4.3.2).
It is supported by arguments
of GSN.

SSM, scenariosituation matrix; DSPO, Dependability Software Process Optimization; ASIL, Automotive Safety
Integrity Level; GSN, Goal Structuring Notation; KAOS, knowledge acquisition in automated specication.

can nd the obstacle node more easily with SSM, and each obstacle node is a candidate of the hazard.
Then, we can consider a hazard event occurred as the realization of a hazard.
Now we can calculate the ASIL. There is no special technique, but SSM is very useful for deciding
the elements of ASIL (i.e. severity, exposure and controllability); the SSM and the goal model give us
the relation between the consolidated situation and obstacle (hazard).
The goal node that solves the problem of the obstacle node expresses solutions to handle a hazard,
and for recording their rationale, we can use the GSN notation. In GSN, the argument node and the
evidence node assure the validity of the solution.
Table I shows the relation between ISO 26262 (part 3) and our approach.
Copyright 2014 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2014; 26:829836

DOI: 10.1002/smr

834

M. ITO AND K. KISHIDA

Figure 3. A tool Nirvana with plug-ins and other connecting tools.

4. TOOL
In this section, we present a tool Nirvana, which supports our approach. Nirvana is a platform with the
plug-in mechanism. There are many types of plug-ins that support several methods such as UML,
KAOS or GSN. In our approach, the linking between models is essential, and Nirvana provides this
feature (Figure 3). The data could be managed in an integrated fashion through a data base
management system. There are several import links shown in the succeeding texts:
Goal model to other models of KAOS (e.g. object model and obstacle model).
Goal model to diagrams of UML (e.g. class diagram and nite state machine diagram).
Goal model to GSN (it assures that a solution to a hazard is valid).
To describe the boundary of item, we can use the class diagram of UML instead of object model
of KAOS.

5. RELATED WORKS
Model-based Analysis & Engineering of Novel Architectures for Dependable Electric Vehicles [12] is
one of the large European research projects. The origin of this project is the Electronics Architecture
and Software Technologies (EAST)-Embedded Electronic Architecture [13], and it was inherited
by the Advancing Trafc Efciency and Safety through Software Technology (ATESST) and
ATESST2 project [14]. Those projects support the development of embedded system of
automobile. There are two important characteristics. First, it covers the whole lifecycle and
supports the notation based on UML/SysML for various description including safety requirements,
Copyright 2014 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2014; 26:829836

DOI: 10.1002/smr

AN APPROACH TO MANAGE THE CONCEPT PHASE OF ISO 26262

835

which is called EAST-architecture description language (ADL) [15, 16]. Secondly, it supports the
environment and vehicle level description with feature and variants. Namely, it supports the product
line engineering.
The Model-based Analysis & Engineering of Novel Architectures for Dependable Electric Vehicles
(MAENAD) supports the full lifecycle development of the automobile, and our proposal refers only to
the concept phase. So, if we focus on our scope, we can nd that there are some differences between
them. In the hazard analysis, the MAENAD uses the use case and scenario. On the other hand, we
use the SSM to cover every possible situation. And we use GSN to describe the safety case that
helps us to structure the arguments. Certainly, the EAST-ADL of the MAENAD clearly denes
the meta-model of safety case, but our approach can seamlessly connect between item denition
and safety case.
As for combination of notations, use the notation of KAOS and GSN. In [17], authors extend the
KAOS method in order to describe arguments in the goal model. In this approach, we may only
have to prepare a single diagram. Our approach uses several models to satisfy the various intentions.
ISO 26262 requires the various expressions in each lifecycle phase, which is the reason why we
provide the several models and use them in accordance with the standard.

6. CONCLUSION
We propose a method for the concept phase of ISO 26262. In this phase, the process starts from
denition of item that is an abstraction of systems. And the end of this phase is we have to describe
the functional safety requirements with normal functional and non-functional requirements,
simultaneously. In order to conform to this request, we use the three notations: KAOS, GSN and
SSM. In KAOS, normal requirements are expressed as goal nodes or softgoal nodes in the goal
model. Hazards are expressed as obstacle nodes, and safety goals are denoted as goal nodes with
the solution renement link. The validity of the relationships between a hazard and a safety goal is
expressed in a GSN diagram. SSM has two roles. First, we use it for exhaustive hazard analysis, and
then we reuse it for the base of ASIL calculation. To connect those three expressions, we use the
linkage mechanism in our supporting tool.
REFERENCES
1. ISO. ISO 26262. Road VehiclesFunctional Safety, ISO (ed.). ISO: Geneva, Switzerland, 2011.
2. Lees FP, Ang ML. Safety Cases Within the Control of Industrial Major Accident Hazards (CIMAH) Regulations,
1984. Butterworths: London; Boston, 1989.
3. SAEInternational. Adaptive Cruise Control (ACC) Operating Characteristics and User Interface (J2399),
SAEInternational (ed.). SAEInternational: Warrendale, PA, 2003.
4. Dardenne A, Fickas S, Lamsweerde AV. Goal-directed concept acquisition in requirements elicitation, Proceedings
of the Sixth International Workshop on Software Specication and Design, 1991, vol. 97403:1421.
5. van Lamsweerde A. Requirements Engineering: From System Goals to UML Models to Software Specications.
John Wiley & Sons Ltd.: Singapore, 2009.
6. van Lamsweerde A, Letier E. Integrating obstacles in goal-driven requirements engineering, 1998; 5362.
7. Kelly T, McDermid J. Safety case construction and reuse using patterns, 1997; 55.
8. Origin Consulting Limited. GSN community standard version 1, 2011. Available: http://www.
goalstructuringnotation.info/documents/GSN_Standard.pdf [Accessed July 2014].
9. Spriggs J. GSNThe Goal Structuring Notation: A Structured Approach to Presenting Arguments. Springer Verlag:
Dordrecht, The Netherlands, 2012.
10. Ito M. Explorative hazard analysis process in requirement phase. In Euro SPI 2010. Grenoble Institute of Technology: France, 2010; 7.257.31.
11. CEI/IEC. Hazard and Operability Studies (HAZOP Studies)Application Guide, CEI/IEC 61882:2001, IEC (ed.).
IEC, 2001.
12. MAENAD Consortium. Available: http://www.maenad.eu/ [Accessed July 2014].
13. EAST-EEA. Embedded Electronic Architecture, Version 1.02, EAST-EEA (ed.). EAST-EEA, 2004.
14. ATESST2 Consortium. Available: http://www.atesst.org/ [Accessed July 2014].
15. Chen D, Lnn H, Trner F, Blom H. EAST-ADL assessment and update suggestions, 2007. Available: http://www.
atesst.org/home/liblocal/docs/ATESST_Deliverable_D2.2.2_V1.1.pdf [Accessed July 2014].
Copyright 2014 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2014; 26:829836

DOI: 10.1002/smr

836

M. ITO AND K. KISHIDA

16. Sandberg A, Chen D, Lnn H, Johansson R, Feng L, Trngren M, et al. Model-based safety engineering of
interdependent functions in automotive vehicles using EAST-ADL2. In Computer Safety, Reliability, and Security,
vol. 6351, Schoitsch E (ed.). Springer: Berlin, Heidelberg, 2010; 332346.
17. Brunel J, Cazin J. Formal verication of a safety argumentation and application to a complex UAV system. In
Computer Safety, Reliability, and Security, vol. 7613, Ortmeier F, Daniel P (eds.). Springer: Berlin Heidelberg,
2012; 307318.

Copyright 2014 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2014; 26:829836

DOI: 10.1002/smr