![SysML Diagrams [2]](https://www.researchgate.net/profile/Tim-Kelly-10/publication/228812803/figure/fig1/AS:300870123180042@1448744435922/SysML-Diagrams-2_Q320.jpg)
Content uploaded by Tim Patrick Kelly
Author content
All content in this area was uploaded by Tim Patrick Kelly
Content may be subject to copyright.
Page
1
of
16
10AE
-
0181
Model
-
Based Assurance for Justifying Automotive Functional Safety
Ibrahim Habli
University of York
Ireri Ibarra,
Jaguar Land Rover
Roger Rivett
Jaguar Land Rover
Tim Kelly
University of York
Copyright © 2010 SAE International
ABSTRACT
With the
growing complexity of, and reliance
on, safety
-
related electrical/
electronic (E/E) systems in the
automotive sector, the development of an explicit safety case is highly recommended to provide assurance to
the different stakeholders interested in automoti
ve functional safety. The production of a safety case is explicitly
mandated by the draft automotive functional safety standard ISO26262.
A safety case should consider all
organisational and technical factors that may contribute
to safety. For example, it
should provide assurance for
the safe behaviours of a particular system as well as assurance for the process by which this system is
dev
eloped, operated and maintained
. In this paper, we address one component of the overall safety case, namely
the assuranc
e of the functional safety concept. In particular, we examine how model
-
driven development and
assessment can provide
a
basis for
the
systematic generation of functional safety requirements. We demonstrate
how an automotive safety case can be structurally
and traceably developed, justifying why and how the defined
functional safety requirements can adequately mitigate the risk of the identified hazards to an acceptable level.
A case study is also presented throughout this paper, discussing examples and less
ons learnt from the
development of a safety case for an air suspension system.
INTRODUCTION
Providing assurance for safety lies at the heart of a safety management system. This assurance can be implicit,
through compliance with a safety process as prescrib
ed within a particular safety standard. In contrast, this
assurance can be explicit, communicated by means of a clear safety case. A safety case presents an argument,
supported by evidence, that the system is acceptably safe to operate in a given environme
nt. A safety case
should consider all organisational and technic
al factors that may contribute
to safety. For example, it should
provide assurance for the safe behaviours of a particular system as well as assurance for the process by which
this system is
developed, operated and maintained. In the automotive sector, safety case development is
increasingly being adopted, partly due to the growing complexity of, and reliance on, E/E systems to perform
safety
-
related functions. The production of a safety case
is explicitly mandated by the draft automotive
functional safety standard ISO26262 (DIS ISO26262
-
2 6.5.3) [
1
].
Page
2
of
16
In this paper, we examine how a safety case can be developed for the assurance of the functional safety concept
for an automotive E/E system.
Th
e objective of the functional safety concept, as described in the draft
ISO26262, is to define a set of functional safety requirements which together satisfy all the safety goals
associated with the hazards determined during hazard analysis and risk assess
ment [
1
]. The functional safety
concept includes fault detection and failure mitigation, transitioning to a safe state, fault tolerance mechanisms,
driver warnings and arbitration logic
[
1
].
In particular, we examine how a model
-
driven approach can provide
a
basis for the systematic generation of the functional safety requirements considered in the safety case. We also
explore and evaluate how traceability between the design models and safety analyses can be enhanced by means
of explicit integration between
the safety case
, represented in
the Goal Structuring Notation (GSN)
[3]
,
and the
system
models
, represented in
the Systems Modelling Language (SysML)
[2]
.
A case study is presented throughout this paper, discussing examples from the development of a prel
iminary
safety case for a 4
-
corner air suspension system
1
.
The two main functions of this system are to maintain a level
vehicle at the target ride height and to allow changes in target vehicle ride height. These changes may either
occur automatically as a
result of constraints in vehicle speed or as a direct request from the driver using the
controls
provided.
The rest of the paper is organised as follows. In the next section, we introduce the model
-
based approach
considered in this paper, briefly discussi
ng the graphical notations used throughout the paper. The top
-
level
safety argument for the air
suspension
system is then presented, showing how it relates to contextual and system
models. Next, we present a fault mitigation argument, demonstrating the ade
quacy of the functional safety
concept to address certain hazardous conditions. The process perspective of assurance is then discussed by
describing
a process
-
based safety argument. Finally, a number of conclusions are presented.
MODEL
-
BASED APPROACH TO FU
NCTIONAL SAFETY ASSU
RANCE
Achieving integration between functional and behavioural design and safety analysis is essential for the
development of safety
-
critical systems. This is mainly because safety is a consequential attribute; i.e. safety
conditions su
ch as hazards and failure modes are often an outcome of certain unintended system functionalities
and behaviours in a given environment. When safety assessment results, such as failure modes and safety
requirements, are generated for a system function, it
is necessary to trace these results explicitly to the design
specifications, including all relevant environmental assumptions, concerning that function. This is why system
hazards are typically identified given the safety analysts’ understanding of the sys
tem and its environment. For
example, safety modes are often stated given certain assumptions about data sampling rates, levels of
independence, expected operation modes, maintenance procedures and end
-
user competencies. In this paper, we
consider how mode
l
-
based engineering can enhance integration between design and safety assurance,
specifically for automotive applications. In particular, we consider two graphical notations: SysML and
GSN
.
Both
SysML and GSN produce graphical representation
s
in a modular
and
hierarchical way. In particular,
m
odularity helps
in
handl
ing
the complexity of the system representation and safety argument by
supporting
the
creation of smaller chunks of informati
on that are scalable and manageable
.
1
Neither the author nor JLR shall be responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy o
r
omission herein. Without de
rogating from the generality of the foregoing neither the author nor JLR shall be liable for any indirect or
consequential loss caused by or arising from any information, advice or inaccuracy or omission contained herein.
Page
3
of
16
THE SYSTEMS MODELING
LANGUAGE (
SYSML)
Companies
which produce
complex
safety
-
critical systems
are increasingly adopting model
-
based approaches
to the development, assessment and assurance of E/E systems. This is best exemplified by the growing interest
in SysML [
2
], particularly in its
role in the description and analysis of systems requirements and design
architectures. SysML, which is
partly
based on the Unified Modelling Language (UML), offer
s
graphical means
for modelling the structural and behavioural aspects of systems through a se
t of syntactically
-
defined diagrams
(Figure 1). These diagrams are particularly useful for the documentation of early
-
lifecycle artefacts such as
requirements and design specifications. For example, use case diagrams, often used for requirements
specificat
ion, capture a particular usage of the system and the way in which the system should interact with its
environment. Conversely, block definition diagrams, normally used for architectural design definition, describe
the modular units of a system, e.g. contr
ol or monitoring units. The behaviours associated with these blocks are
typically described using a set of activity diagrams. Collectively, these diagrams provide an integrated
description of the system, depicted from the behavioural as well as from the st
ructural perspectives.
Fig. 1. SysML Diagrams
[2]
THE GOAL STRUCTURING
NOTATION (GSN)
Recently, there has been a marked shift towards safety standards that recommend or mandate the development
and management of well
-
structured and well
-
reasoned safety ar
guments. To effectively develop such
arguments, the safety sector is increasingly adopting graphical modelling notations for the representation of
safety arguments. This is partly because of the capability of graphical argumentation notations such as GSN t
o
address the difficulty of communicating and maintaining complex safety arguments described in free text [
3
].
GSN represents safety arguments in terms of basic elements such as goals, solutions, and strategies (Figure 2).
Arguments are created in GSN by l
inking these elements using two main relationships, ‘supported by’ and ‘in
context of’ to form a goal structure. The principal purpose of any goal structure is to show how goals (claims
about the system) are successively broken down into sub
-
goals until a
point is reached where claims can be
supported by direct reference to available evidence (solutions). As part of this decomposition, using the GSN it
is also possible to make clear the argument strategies adopted (e.g. adopting a quantitative or qualitativ
e
approach), the rationale for the approach and the context in which goals are stated (e.g. the system scope or the
Page
4
of
16
assumed operational role). To address the complexity of certain safety arguments, GSN supports the
decomposition of safety arguments into a
number of modules (i.e. argument modules), which reference one
another by means of Away Goal
s. This approach is often refer
red
to as '
modular safety cases
' [
4
].
Fig. 2. Principal Elements of the Goal Structuring Notation
OVER
VIEW OF THE APPROACH
As previously mentioned, this paper targets the justification of the functional safety concept for automotive E/E
systems. In particular, we address the justification of the functional safety concept by explicitly representing a
safety
argument which considers the adequacy of the functional safety requirements in mitigating the risk of the
identified system hazards. This safety argument is modelled in GSN and is traced to a set of contextual and
system models, defined in SysML (Figure 3
). These SysML models describe the environment within which the
system is deployed, the functions provided by the systems, the modular units comprising the system and the
behaviours exhibited by the system. These models provide the basis upon which the haz
ard analysis and risk
assessment activities are carried out. Further, these models provide the basis upon which the functional safety
concept is defined by showing the fault mitigation mechanisms deployed to reduce the risks of the identified
hazards. Most
of these SysML models of the environment and the system, particularly those specifying the fault
mitigation behaviours of the system, are referenced in the safety argument, maintaining a traceable link between
the safety assessment artefacts and the SysML
models. In the next sections, we describe this model
-
based
approach to functional safety assurance by discussing examples and lessons learnt from the development of a
safety case for an air suspension system. We first describe the top
-
level argument which
addresses a set of
identified hazards and how they relate to system functions within a particular environment. We then describe
the structure of the arguments addressing the risk of each identified hazard by means of explici
t mitigation
measures, describe
d in a set of SysML diagrams.
Page
5
of
16
x
x
i
x
x
x
I
P
x
x
x
x
4
x
x
x
x
x
x
x
u
x
I
P
x
Fig. 3. Overview of Relation between Safety Case and Context and System
HAZARD
-
AND RISK
-
DIRECTED SAFETY ARGU
MENT
Figure 4 shows the top
-
level safety argument for the air suspension system. The to
p
-
level
goal is a claim that all
due diligence has been performed. This is achieved by adopting industry best practice as defined in the relevant
functional safety standard, ISO 26262. The standard is hazard directed and
"
uses ASILs
[Automotive Safety
Inte
grity Levels]
for specifying the item's necessary safety requirements for achieving an acceptable residual
risk
" [
1
].
Therefore this argument is hazard
-
and risk
-
directed.
That is, the argument explicitly addresses the risk
of each identified hazard, showi
ng that each risk is acceptable. Hazards associated with
the air suspension
system are identified by considering the potential effects of the system's operation, and non
-
operation, in a
variety of different user situations. It is important to note that thi
s safety argument is described in the context of
an explicit definition of the system and its environment (
'AirSus_Def'
,
'AirSus_Env'
and
'C_Safety_Envelope'
).
This definition is referred to as
'Item Definition'
in the Draft ISO26262 (DIS ISO26262
-
3 5.5).
The item
definition for the air suspension system considered in this paper is described in terms of a number of SysML
models, namely:
Context and feature models: described in block definition and internal block definition diagrams
System requirements mode
ls: described in use case diagrams
(mainly high
-
level functionality)
System structure: described in block definition and internal block definition diagrams
System behaviours: described in activity diagrams
In the next subsections, we briefly discuss these
models and how they are linked to the safety conditions
considered within the safety argument.
Page
6
of
16
Fig. 4. Top
-
Level
Safety
Argument
CONTEXT AND FEATURE
MODELS
The context model defines factors in the environment of the air suspen
sion system with which the system
interact
s
. These factors are grouped in a number of packages, addressing:
Vehicle characteristics such as vehicle load and body type (pkg Vehicle)
Peer systems such as those providing ignition status and vehicle speed (pkg
OtherSystems)
Vehicle support covering maintenance and service (pkg Support)
Physical environment such as road and obstacle types (pkg PhysicalEnvironment)
Actors specifying persons affected by the system such as drivers, passengers and maintenance perso
nnel
(pkg Actors)
Further, this context model specifies which contextual factors are core, i.e. common to all system variants, and
which are optional. These factors play a key role in constraining the scope of the safety case
(e.g.
the
'
AirSus_Env
'
contex
t element in
Figure 4
)
. An example of how these contextual factors were specified for
vehicle characteristics (pkg Vehicle) is shown in Figure 5.
Page
7
of
16
<<
core
>>
Load
<<
core
>>
Driving phase
<<
core
>>
Non Stationary
<<
core
>>
Stationary
<<
core
>>
Parked
<<
core
>>
Ingress
/
egress
<<
core
>>
Body type
<<
core
>>
Drive type
<<
Optional
>>
Saloon
<<
Optional
>>
Estate
<
Optional
>>
4
x
4
<<
Optional
>>
Rear wheel drive
<<
Optional
>>
All wheel drive
<<
Optional
>>
Tow bar
<<
core
>>
Towing
<<
core
>>
Plant
(
End of Line
)
<<
core
>>
Garage
pkg
Vehicle
<<
core
>>
Normal height
<<
Optional
>>
Access height
<<
Optional
>>
Crawl height
<<
core
>>
Predefined Height
<<
Optional
>>
Off
-
road height
<<
core
>>
Vehicle Height
<<
Optional
>>
Not Predefined Height
<<
Optional
>>
Default height
<<
core
>>
Bump Stops height
Fig. 5. An Extract from the Air Suspension System Context Model
The feature model
of the air suspension system specifies the system’s core and optional functions and operating
states. Figure 6 shows an extract from the feature model, showing the different ways in which the target ride
height may change. For example, it shows that a cha
nge of the vehicle height can be initiated automatically by
the vehicle (core), manually by the maintenance team (core) or manually by the driver (optional, depending on
the vehicle type).
Fig. 6: An Extract from the Air Suspen
sion System Feature Model
FUNCTIONAL, STRUCTUR
AL AND BEHAVIOURAL S
YSTEM MODELS
The system definition is specified in terms of various SysML models describing the functional, structural and
behavioural characteristics of the system. In particular, the follo
wing models are generated:
Use Case Models: describing system functions captured in the feature model and how they relate to one
another and to their context
Block Definition and Internal Block Definition Models: describing the main components and
communic
ations in the system
Activity Diagrams: describing nominal and fault management behaviours of the system, detailing the
behaviour of each function under normal and impaired conditions.
Page
8
of
16
The main functionality of the air suspension system is to maintain an
d change the target ride height under all
rated vehicle operating conditions. This functionality is provided by controlling the quantity of air in the air
springs at all four corners of the vehicle in response to the signals from sensors that measure the s
uspension
height at each wheel. This functionality is described in Figure 7 in a SysML use case diagram. For example, the
use case
' Change target ride height'
specifies a particular function of the air suspension system which allows
the driver to request
several height settings for different driving conditions. Several different ride heights are
requested automatically for different operating conditions (including special conditions to assist in special
operations such as maintenance and transport). The u
se case diagram also shows how this function relates to the
system's environment by linking the use case
' Change target ride height'
to external factors such as
'Door
status'
,
'Terrain response'
and
'Road prompts'
. All of these factors are captured in the
context model introduced
in the previous section (ensuring explicit model
-
based traceability between the system functions and the
environment within which these functions can be used).
Fig. 7. SysML Use Case Diagram
The detai
led behaviours associated with each function captured in the use case diagram are specified using a
SysML activity diagram. For example, Figure 8 shows an activity diagram detailing the system behaviours
associated with the
'Deliver height'
function. This
activity diagram
describes two key operational behav
iours
related to raising and lowering
the vehicle based on several inputs such as '
Vehicle speed
', '
Lateral acceleration
'
and '
Door status
' (all of which trace
to the context model).
Page
9
of
16
Fig. 8. SysML Activity Diagram (Deliver Height)
In short, the top
-
level safety argument in figure 4 addresses the risk of system hazards as identified with
reference to the item definition described in SysML diagrams. This safety argument present
s a set of claims
regarding the acceptability of the risk associated with each system hazard. In this argument, each of these
claims is encapsulated with
in
a separate
argument module
which presents an argument supporting the claim
about the risk mitigation
of the hazard. For example, the claim about the risk of trap is described in an Away
Goal which is supported by an argument encapsulated in
the
'Trap Hazard Argument'
module (
illustrated
separately in
Figure
9
). The type of arguments encapsulated in these
modules support the claim concerning the
acceptability of the hazard risk by appealing to the adequacy of the functional safety concept to reduce the risk
of the hazard to an acceptable level. This is discussed in further detail in the next section.
Fig.
9
. Argument Module Reference
RISK MITIGATION SAFE
TY ARGUMENT
In this section, we discuss the structure of the argument addressing the claim regarding the acceptability of the
risk associated with a particular hazard by appeali
ng to the adequacy of the functional safety concept. The
Page
10
of
16
structure of the argument is depicted in Figure
10
(the name of the hazard and certain failure conditions were
removed for reasons of commercial sensitivity). The argument shows that the risk has bee
n adequately managed
in accordance with the ASIL defined for that risk. This argument justifies the defined risk classification against
the ISO26262 ASIL scheme, based on the estimated severity, probability of exposure and controllability of each
hazard. B
ased on the ASIL associated with the risk, the argument justifies that the risk has been managed by
eliminating causes of the hazard considered by that risk. Where there are faults which can impair the
elimination of these hazard causes, the argument addre
sses these faults by showing how fault
-
mitigation
measures have been defined to keep the vehicle in an acceptably safe state in presence of these faults.
Fig.
10
. Hazard Argument Module
For the air suspension system, the initi
al SysML models were analysed to determine how system failures could
lead to the hazards. The required fault management behaviours, necessary to mitigate all the
hazards, were
subsequently determined. These fault management behaviours were also captured in
Activity diagrams.
In
ISO26262 terms, the set of fault management behaviours constitute the functional safety concept which was
documented as a set of functional safety requirements, traceable to both the nominal and fault management
Activity diagrams.
Page
11
of
16
Three forms of fault
-
mitigation measure are considered in the safety argument of the air suspension system,
namely:
Lowering the vehicle to an acceptably safe height
–
the choice of this height depends on factors such as the
detection of certain faults a
nd previous vehicle height and speed
Disabling all requests for a vehicle height change
–
this includes automatic and manual requests
Warning the driver of a fault
–
different types of warnings are used, mainly depending on the critically of
the faults an
d the different configurations of the driver interface, e.g. choice of optional features supporting
textual messages in addition to core driver interface features such as warning lamps and chimes.
For instance, the mitigation of the failure condition cause
d by the inability to measure corner heights
(
'Vehicle_height_indeterminate'
) is described in the Activity diagram shown in Figure 1
1
. This Activity
diagram shows that, upon the detection of the inability to measure corner heights or control pressure, the
system
lowers the vehicle to the bump
-
stops height, disables height changes and informs the driver of a fault. The
argument within the air suspension system safety case corresponding to this fault mitigation behaviour is shown
in Figure 1
2
(contained withi
n the argument module supporting the claim
'Vehicle_height_indeterminate'
previously included
in Figure
10
).
Fig. 1
1
.
Inability to Measure Corner Heights SysML Activity Diagram
Page
12
of
16
Fig. 12. Height Mea
surement Argument Module
PROCESS
-
BASED SAFETY ARGUMEN
T
Finally, the air suspension system safety case includes an argument module addressing the assurance of the
hazard identification and risk assessment process (‘
Hazard Analysis Process Argument
’). This a
rgument is
referenced in Figure 4 by the ‘
Top
-
Level Argument
', specifically through the ‘
Ident_Haz
’ context element
referencing the away goal ‘
IdentHazards
’. The objective of this association is to justify the process by which
system hazards have been iden
tified and analysed. The argument presented within the ‘
Hazard Analysis Process
Argument
’ module, depicted in Figure 1
3
, provides assurance about the hazard analysis process by addressing
compliance with the ISO26262 guidance regarding hazard identificatio
n, hazard classification and ASIL
determination. The argument also justifies the competency of the team responsible for carrying out this process.
Further, there are cases where the classification of certain hazards cannot be determined merely based on exp
ert
judgment. In these cases, and in order to mitigate the potential for under
-
classification of these hazards,
additional vehicle tests are required in order to confirm certain assumptions concerning the controllability,
probability of exposure or severit
y of these hazards (‘
Underclass
’).
The argument depicted in Figure 1
3
is typically referred to as
process
-
based argument
[7].
In the previous
sections, we emphasised the fundamental role of the safety case for assuring the safety of the system itself. In
p
articular, we focused on one par
ticular type of safety argument
, namely
product
-
based arguments
. Product
-
based arguments address safety assurance by arguing over the acceptable safe behaviours of the system,
targeting, for example, claims concerning the to
lerability of the risks of all identified hazards and the
satisfaction of all defined safety requirements. These claims are then substantiated by direct evidence generated
from analysis, testing, simulation and in
-
service history. However, confidence in th
e safety of the system may
be undermined by uncertainties about the provenance of the product
-
based evidence. The trustworthiness of this
type of evidence depends on the quality of the underlying engineering process (i.e. the simple question:
why
should I
trust the evidence?
). Process elements such as competency of personnel, reliability of tools, suitability
of notations and soundness of methods constitute key criteria against which the trustworthiness of product
-
based evidence can be determined. Disregard
ed weaknesses and flaws in these process elements may propagate
into the safety
-
critical system itself. The process can fail to deliver its expected outputs and consequently
weaken confidence in the safety of the system.
Page
13
of
16
IdentHazards
Hazard analysis and risk
assessment identifies and
analyses relevant hazards in a
trustworthy manner
C
_
Process
Hazard analysis and
risk assessment
process
Stra
_
Process
Argument over process
compliance and
management of process
weaknesses
Process
_
Compliance
Hazard analysis and risk
assessment complies with
ISO
26262
guidance
C
_
Stan
with ISO
26262
guidance
Process
_
Weaknesses
Hazard analysis and risk
assessment process
weaknesses are suitably
managed
Stra
_
Activity
Argument over hazard
analysis and risk
assessment activities
C
_
Activities
Hazard analysis and
risk assessment
activities
J
C
_
Best
_
Practice
ISO
26262
guidance is a
recognised international ISO
standard
,
developed by the
automotive community
,
focusing
on E
/
E automotive systems
HazIdent
Situation analysis and hazard
identification was adequately carried
out and identified potential unintended
behaviours of the system that could
lead to a hazardous event
SitAnalysis
Situation Analysis
HazClass
Hazard classification was adequately
carried out and determined of the
severity
(
S
)
,
the probability of exposure
(
E
)
and the controllability
(
C
)
associated
with the considered hazard of the item
HazASIL
An automotive safety
integrity level
(
ASIL
)
was
determined for each
identified hazard
C
_
ASIL
ASIL Scheme
C
_
SEC
Hazard severity
(
S
)
,
probability of exposure
(
E
)
and controllability
(
C
)
HzTeam
The team undertaking hazard analysis
and risk assessment included persons
with a good knowledge and domain
experience of the
behaviour of system
,
and of the way that a vehicle and its
driver can behave
C
_
HzTeam
Hazard analysis
and risk
assessment team
Stra
_
Process
_
Weakne
sses
Argument over identified
process weaknesses
Underclass
Under
-
classifcation of new
,
not
previously examined behaviours
has been mitigated by additional
vehicle tests
A
Ass
_
Exp
_
Judgement
Most hazard
classifications can be
estimated by expert
judgement
Trust
_
Ev
Definition of
trustworthy
C
_
FM
_
Process
_
W
eaknesses
Identified process
weaknesses
Fig.
1
3
.
Hazard Analysis and Risk Assessment Process
-
Based Argument
A p
rocess
-
based argument like the one depicted in Figure 1
3
is often called a backing argument as it is used to
show that the direct, product
-
based evidence is “
both credible and soundly based
”
[
5
]. Process
-
based evidence
is typically generated based on two main criteria [
6
]:
Compliance with nationally and internationally recognised standards which are relevant to the domain and
criticality of the system
Selection of established techniques and t
ools and employment of competent technical and managerial
personnel, e.g. selection of qualified modelling tools or programming language safe subsets.
Eventually, the complete safety case should address all organisational and technical factors that may con
tribute,
to safety such as product design, development, deployment, operation and maintenance as well as organisational
maintenance of an adequate level of safety culture. From the draft ISO26262 perspective, the complete safety
Page
14
of
16
case should address
product
factors such as the functional and technical concepts as well as
process
factors such
as safety management and quality assurance
(illustrated in
Figure 1
4)
.
Fig. 1
4
.
Integrated Product
-
Based and Process
-
Based Arguments
SUMMAR
Y/CONCLUSIONS
In this section, we present an evaluation of the process and outcomes of the model
-
based assurance approach
presented in the previous sections, focusing on lessons learnt from the development of the SysML models and
safety case for the air su
spension system.
DEFINITION OF CONTEX
T AND FEATURE MODELS
A key advantage for creating the air suspension system’s context and feature models was the explicit
documentation of expert domain knowledge. Engineers were able to air their views, agreeing or dis
agreeing
with, or suggesting a different way for, the inclusion, exclusion or categorisation of certain contextual factors or
system features. Further, because these models capture permitted variations, decisions as to which elements are
core and which are
optional were easier to make and evaluate (and even revaluate whenever new information
had been uncovered). The context model was instrumental in contextualising the air suspension system safety
case, explicitly highlighting environmental factors and vehi
cle characteristics which allow system failures to
become hazards. These factors and characteristics were clearly referenced in the safety case. Finally, as a
positive side
-
effect, the air suspension system’s context and feature models were useful for crea
ting additional
diagrams for usages beyond safety analysis. For example, based on the context and feature models, a P
-
diagram
was created to analyse the completeness of identified input
-
output transformations (typically used for
robustness analysis).
SYSTE
M MODELLING IN SYSML
System models were created in order to document the structural and behavioural aspects of the system functions
defined in the feature model. More specifically, the behaviours of these functions were defined given specific
assumptions a
bout the system’s environment as captured in the context model. The most useful diagrams used
in this industrial application, as far as safety assurance is concerned, were the SysML activity diagrams. These
diagrams helped in specifying the nominal and fau
lt management behaviours of the system, which informed the
Page
15
of
16
creation and analysis of the system’s functional safety requirements. These functional safety requirements were
a main input to the development of the safety case, showing how the system, through t
he achievement of these
requirements, can eliminate or mitigate causes of the identified system hazards. Where there were uncertainties
about the assumed behaviours of certain functions, as uncovered by the SysML activity diagrams, further
analysis and veh
icle tests were required to confirm these behaviours. The fault management behaviours
captured in the activity diagrams played a fundamental role in ensuring sufficient coverage of how the system
reacts in the event of deviations from the nominal behaviour
s of the system.
Because of the complexity of the behavioural aspects of system functions and their relationships with one
another and with their environment, in addition to how these behaviours trace to the safety case, further work is
still required to
examine how ‘sophisticated’ modelling tools, such as those offering model merging, querying,
transformation and composition, can support the process of managing the context, feature, system and safety
case models and their interdependencies. Specifically f
or the air
suspension system case study,
Microsoft
Visio
worked well as far as the creation of a limited number of models was concerned. However, by the end of this
case study, around 70 models were created (covering the system’s context, feature, system a
nd safety case
definitions), making the manual traceability of the different concerns addressed by these models unreasonably
time
-
consuming. This was exacerbated by the fact that these models included system variations, the impact of
which can vary dependi
ng on the way in which these variations can be instantiated within different types of
environments, e.g. different vehicle usages, body types and interface characteristics. In short, tool
-
support is
essential for specifying and enforcing invariants and con
straints which are needed for ensuring explicit
traceability between the different models created in this pilot industrial application. Further, the case for tool
-
support becomes more urgent once a decision is made to extend this work to cover the technica
l safety concept
(e.g. low
-
level design), i.e. adding an extra layer of complexity in the relationships between the product line’s
context, system and safety case models.
In general, the ability to represent different technologies, e.g. electrical, pneum
atic and mechanical, with a
single notation such as SysML was an improvement on the previous situation where each technology used a
different notation. The use of a notation with defined syntax meant that the diagrams could easily be understood
by those wh
o were not involved with their creation, e.g. independent reviewers.
SAFETY CASE
The definition of well
-
structured and traceable context, feature and system models paved the way for the
development of the safety case. The relationship between the safety ca
se and the context, feature and system
models was bidirectional. The safety case was a driver for further information that needed to be part of the
context and system models, e.g. assumptions that needed to be m
ade in the safety case which
had no explicit
links with the system or context models. The safety case changed and evolved as more information was
captured in the context, feature and system models. Also,
the following issues
were identified and clarified as a
result of the need to define an explici
t
and traceable safety argument:
Terminology
ambiguities
Need
to make a clear distinction between different types of driver warnings
O
verlaps between the definition of certain fault types in the context and system models
Regarding compliance with ISO26262,
the safety case prompted the reassessment of hazard classifications in
order to be compatible with the ISO26262 classification scheme. Further, the development of the safety case
was an attempt to show how a saf
ety case can be developed in
light of the dra
ft ISO26262 functional safety
concept guidance. In particular, this case study provided a model
-
based assurance interpretation of that
Page
16
of
16
guidance by showing how SysML models can be used to analyse an explicit definition of an automotive item
which is traceab
le to the item’s safety case.
Finally, the safety argument presented in the ‘
Top
-
Level Argument
’
(Figure 4)
is stated within the context of the
identified hazards (‘
Ident_Haz’
). The validity of this context element is central to the assurance of this
argum
ent. To this end, a process
-
based argument was attached to that context element to justify the adequacy of
the hazard analysis process, through the away goal ‘
IdentHazards
’. This process
-
based argument, encapsulated
in the ‘
Hazard Analysis Process Argument
’ module (discussed in the previous section), justifies the adequacy of
hazard analysis by arguing over compliance with ISO26262 guidance and management of process weaknesses.
This interaction between product
-
based and process
-
based arguments highlighted t
he importance of process
-
based arguments, as a form of a backing argument, in justifying certain contextual assumptions stated within the
product
-
based argument.
REFERENCES
1.
ISO/TC 22/SC 3/WG 16,
"
ISO26262 DIS:
Road Vehicles
-
Road Safety," BL15,
Internatio
nal Organization
for Standardization
(ISO),
June 2009.
2.
Object Management Group (OMG), “
Systems Model
l
ing Language (SysML)
,” v1.1, OMG, November
2008.
3.
Kelly
T. P.
,
"
Arguing Safety
–
A Systematic Approach to Safety Case Management
,
"
DPhil Thesis,
Department
of Computer Science, University of York, UK, 1998.
4.
Bate
I. J.,
Kelly
T. P.
, “
Architectural Considerations in the Certification of Modular Systems
,”
21
st
International Conference on Computer Safety, Rel
iability and Security (SAFECOMP
02), September 2002
.
5.
Civ
il Aviation Authority (CAA),
“
CAP 670 SW 01: Acceptable Means of Compliance to CAP 670 SW 01:
Guidance for Producing SW 01 Safety Arguments for COTS Equipment
,”
Issue 2,
CAA,
2009.
6.
UK Ministry of Defence
(MoD), "Defence Standard 00
-
56:
Safety Management Re
quirements for Defence
Systems
,”
Part 2, Issue 4, UK Ministry of Defence, 2007.
7.
Habli I.,
Kelly
T
. P.
, “Process and Product Certification Arguments: Getting the Balance Right”, Workshop
on Innovative Techniques for Certification of Embedded Systems, in Con
junction the 12th IEEE Real
-
Time
and Embedded Technology and Applications Symposium, San Jose, California, USA, April 2006.
CONTACT INFORMATION
Ibrahim
Habli
(
C
orresponding
A
uthor
)
High
-
Integrity Systems Engineering
R
esearch
G
roup
University of York
York Y
O10 5DD
United Kingdom
Tel: +44 1904 433387
Fax: +44 1904 432708
Email: Ibrahim.Habli@cs.york.ac.uk
