“Safety Model and Systems Model - GSN/MARTE/SysML/SafeML integration in Robotics” by Toshi Okamura(Change Vision, Inc), Geoffrey Biggs(AIST) We tried to model a wheelchair robot system with GSN/SafeML(Safety), SysML(System) and MARTE(realtime software) together to prove that those models can effectively express the problem domain and the solutions.

1. Safety
Model
and
Systems
Model
-­‐
GSN/MARTE/SysML/SafeML
integra;on
in
Robo;cs
Geoffrey
Biggs
(AIST)
Toshihiro
Okamura(Change
Vision,
Inc.)

2. Agenda
• Introduc;on
• Background
and
Goals
• Sample
Models
• Conclusion

3. Introduc;on

4. Change
Vision,
Inc.
• Founded
February
22,
2006
• Representa-ve
-­‐
President
and
CEO :
Kenji
Hiranabe
• Loca-ons
– US
Office(Ohio)
– Headquarters(Tokyo,
Japan)
– Fukui
Office(Fukui,
Japan)
• Products
– Modeling
Tools
"Astah"

5. Lightweight,
easy-­‐to-­‐use,
and
free
UML
modeler,
For
free.
Full-­‐featured
edi;on
with
UML,
ERD,
DFD,
Flowchart,
CRUD,
Mind
Maps
and
Requirements
Table
integrated
together.
Simple
SysML
Edi;on
Simple
GSN
Edi;on
Astah
Family
June, 2013
June, 2014

6. Our
Projects
Kenji Hiranabe
Toshihiro Okamura
Geoffrey Biggs
Kenji Taguchi
GSN/Assurance Case
Safety and Systems Models
for Robotics
Last Year
Yoshihiro Nakabo
....

7. Background
and
goals

8. SysML・
UML/
MARTE
GSN
Describes system
safety cases.
Describes system
and software
models
SafeML
Example robot (from AIST)
(Extension to SysML)
Describes hazards and harms
related to the system
Goal:
• Demonstrate the effectiveness of using GSN/SafeML/SysML/MARTE together.
Overview

9. l Semi-­‐automated
wheelchair
developed
at
AIST
l Automa;cally
prevents
collisions
l Fault
tolerant
design
l Safety
analysis
already
performed
Example
Robot

10. Modelling
process
GSN
• Design
argument
for
how
system
will
be
developed
to
be
safe
(safety
analyses
to
be
performed,
design
methods,
etc.)
SysML
• Model
a
system
that
meets
the
requirements
SafeML
• Add
safety
analysis
results
to
system
model
to
a]ain
traceability
between
safety
analysis
and
system
features
(safety
requirements)
SysML
• Revise
system
design
to
implement
required
safety
features
MARTE
• Add
implementa;on
details
and
analyse
model
for
feasibility
of
design
GSN
• Revise
argument
based
on
actual
steps
performed
and
work
products
• Link
GSN
argument
to
system
model
to
provide
context
and
solu;ons
Language
Objectives

11. Modelling
process
(1
of
6)
System requirements
Proposed safety
achievement plan
S
R

12. Modelling
process
(2
of
6)
Proposed safety
achievement plan
(planned safety analyses,
design processes, …)
Initial system design (system model)
Hazard analysis, …
SysML
GSN
S
System requirements
R

13. Modelling
process
(3
of
6)
Initial system design
(system model)
Hazard analysis, …
SysML
Safety model
System model
with safety information
SysML
+
SafeML
SafeML

14. Modelling
process
(4
of
6)
System model
with safety information
SysML
+
SafeML
Revised system model
with safety information
SysML
+
SafeML

15. Modelling
process
(5
of
6)
Revised system model
with safety information
SysML
+
SafeML
System model
SysML
+
SafeML
+
MARTE
Implementation details
for feasibility analysis
MARTE

16. Modelling
process
(6
of
6)
System model
SysML
+
SafeML
+
MARTE
Actual safety
achievement plan
(performed safety analyses,
design processes, …)
GSN
Integrated safety case and
system model
SysML
+
SafeML
+
MARTE
+
GSN

17. Sample
Models

18. GSN
• Used
GSN
to:
– Visually
design
the
safety
argument
by
planning
the
assurance
process
ac;vi;es
and
ar;facts
– Visually
show
that
the
designed
safety
argument
is
supported
by
evidence
produced
through
the
planned
assurance
process.

19. GSN
Control System is
acceptably safe to
operate
G1
Operating Role
and Context
C1
Control System
Definition
C2
Tolerability
targets (Ref Z)
C3
All identified hazards
have been eliminated or
sufficiently mitigated
G2
Hazards identified
from FHA (Ref Y)
C4
Argument over each
identified hazards
S1
Hazard H1 has been
eliminated
G4
Probability of Hazard H2
occuring < 1x10-6 per
year
G5
Formal
Verification
Sn1
A
All hazards have
been identified
A1
Goal
(Claim) Context
Assumption
Solution
(Evidence)
Strategy
SupportedBy
InContextOf
Probability of Hazard
H3 occuring < 1x10-3
per year
M2
Module
GSN is a graphical
argumentation notation that can
be used to document explicitly
the individual elements of any
argument and, perhaps more
significantly, the relationships that
exist between these elements
See: GSN Community Standard Version 1
http://www.goalstructuringnotation.info/
What is GSN:
http://astah.net/editions/gsn/why-gsn
Related to:
SACM standard in SysA TF

20. GSN
model
Safety
requirement
verification
result
Sn6
* Hazard analysis
statement
* Risk assessment
statement
C6
DRC is acceptably safe
G1
All hazards have been
identified sufficiently
G4
Basic Requirement for Safety:
(1) DRC should be safe for using
in the second office in the main
building of AIST
(2) DRC should be safe for users
who are not familiar with electric
wheelchair
C2
Hazard
analysis
statement
Sn1
Risks have been
analyzed and evaluated
properly. And the ways
of eliminating the risks
are analyzed properly.
G5
Risk
assessment
statement
(each phase)
Sn2
Activities in each phases
of the lifecycle of DRC
have been figured out
G10
Primitive hazards have
been figured out
comprehensively by
using the hazard
identification checklist
of JIS B 9700 and
ISO13482
G12
Product brief
C7
Hazard identification
checklist of
JIS B 9700:2013 (Table
B.1)
C9
Hazard identification
checklist of ISO13482
(Annex A)
C11 The lists of hazards for
each phases of the
lifecycle have been
created by matching the
activities and the
hazards figured out by
checklists
G13
Table B.3: 'List of risky
activities' of JIS B 9700
(Standard for safety of
machinery)
C8
Phase：
Specification, transport,
installation, setting,
maintenance,
emergency response,
removal
Figuring out hazards and
activities to identify risks
that inhibit the safety
S2
Kinds of improper use
have been identified
G11
Hazard identification
checklist of
JIS B 9700:2013 (Table
B.3)
C10
Product brief
C1
Discuss separately with
deriving safety
requirements and
implementing safety
requirements
S1
Hazard analysis
statement
C5
Required risk reduction
measures have been
defined properly
G17
Risks have been
reduced to less than the
allowable level by risk
reduction measures
G18
Safety requirements
have been derived
properly from the risk
reduction measures
G6
All safety requirements
have been implemented
G3
Safety
requirement
definition
document
Sn3
All risks have been
estimated by following
the estimation rules
G15
Acceptable range of
risk has been decided
properly
G16
Safety requirement
definition document
C4
The way of estimating
risks has been defined
concretely
G14
Safety requirements
have been led to
properly
G2
Break down by activities
S3
The completed product
has satisfied all safety
requirements
G9
The way of testing the
completed product has
been defined property
depending on the safety
requirements
G8
Validation
plan
document
Sn5
Safety requirements
have been adapted to
the design
G7
System design
model (SysML,
SafeML)
Sn4
ISO13482:2014
(Standard related to the
safety of the personal
care robots)
C3
(1)
(2)
(3)
(4)

21. GSN
model
(1)
DRC is acceptably safe
G1
Basic Requirement for Safety:
(1) DRC should be safe for using
in the second office in the main
building of AIST
(2) DRC should be safe for users
who are not familiar with electric
wheelchair
C2
Product brief
C1
Discuss separately with
deriving safety
requirements and
implementing safety
requirements
S1
All safety requirements
have been implemented
G3
Safety requirement
definition document
C4
Safety requirements
have been led to
properly
G2
ISO13482:2014
(Standard related to the
safety of the personal
care robots)
C3

22. GSN
model
(2)
All hazards have been
identified sufficiently
G4
Hazard
analysis
statement
Sn1
Activities in each phases
of the lifecycle of DRC
have been figured out
G10
Primitive hazards have
been figured out
comprehensively by
using the hazard
identification checklist
of JIS B 9700 and
ISO13482
G12
Product brief
C7
Hazard identification
checklist of
JIS B 9700:2013 (Table
B.1)
C9
Hazard identification
checklist of ISO13482
(Annex A)
C11 The lists of hazards for
each phases of the
lifecycle have been
created by matching the
activities and the
hazards figured out by
checklists
G13
Table B.3: 'List of risky
activities' of JIS B 9700
(Standard for safety of
machinery)
C8
Figuring out hazards and
activities to identify risks
that inhibit the safety
S2
Kinds of improper use
have been identified
G11
Hazard identification
checklist of
JIS B 9700:2013 (Table
B.3)
C10
Safety requirements
have been led to
properly
G2

23. GSN
model
(3)
* Hazard analysis
statement
* Risk assessment
statement
C6
Risks have been
analyzed and evaluated
properly. And the ways
of eliminating the risks
are analyzed properly.
G5
Risk
assessment
statement
(each phase)
Sn2 Phase：
Specification, transport,
installation, setting,
maintenance,
emergency response,
removal
Hazard analysis
statement
C5
Required risk reduction
measures have been
defined properly
G17
Risks have been
reduced to less than the
allowable level by risk
reduction measures
G18
Safety requirements
have been derived
properly from the risk
reduction measures
G6
Safety
requirement
definition
document
Sn3
All risks have been
estimated by following
the estimation rules
G15
Acceptable range of
risk has been decided
properly
G16
The way of estimating
risks has been defined
concretely
G14
Safety requirements
have been led to
properly
G2
Break down by activities
S3

24. GSN
model
(4)
Safety
requirement
verification
result
Sn6
All safety requirements
have been implemented
G3
Safety requirement
definition document
C4
The completed product
has satisfied all safety
requirements
G9
The way of testing the
completed product has
been defined property
depending on the safety
requirements
G8
Validation
plan
document
Sn5
Safety requirements
have been adapted to
the design
G7
System design
model (SysML,
SafeML)
Sn4

25. SysML:
Overview
• Used
SysML
to:
• Structure
system
requirements
• Perform
domain
analysis
• Model
system
design

26. SysML
model
• Analysis
of
domain
using
block
diagram
• Iden;fy
relevant
en;;es
for
use
case
analysis

27. SysML
model
• Requirements
analyzed
using
top-­‐down
approach
from
use
cases
• SysML
used
to
structure
requirement
rela;onships

28. Top-­‐down
system
design

29. SafeML
• Modeling
language
for
recording
informa;on
regarding
safety
of
a
system
• SysML
profile
• Tool
for
communica;on
amongst
development
team
members
• Based
on
safety
standards
and
analyses
– Models
analysis
results
and
safety
features

30. SafeML
• Models
results
of
safety
analyses,
safety
feature
design
• Used
to
model
link
known
hazards
and
safety
requirements
• Provides
traceability
of
safety
informa;on

31. SafeML
[package] Safety diagram s [36a. Riding user touches a wheel during m otion and gets their hand or fingers caught]bdd
< < Hazard> >
< < block> >
M oving m echanical com ponent s
< < Harm > >
< < block> >
Dislocat ed joint s, broken bones or choking
< < block> >
Wheel cover
< < DefenceResult> >
< < block> >
Wheel covers result
< < block> >
Elect ric m ot or
< < block> >
Wheel
< < Harm Context> >
< < block> >
36a. Riding user t ouches a wheel during m ot ion and get s t heir hand or fingers caught
< < deriveHzd> >< < deriveHzd> > < < block> >
Wheel
< < deriveHC> >
< < PassiveDefence> >
< < block> >
Wheel covers
< < requirem ent> >
text = The wheels
shall be covered
such that the user
and objects
cannot touch
them during
m otion.
Id = 140
Wheel covers
< < reqDefence> >
< < satisfy> >

32. [package] Safety diagram s [36a. Riding user touches a wheel during m otion and gets their hand or fingers caught]bdd
< < Hazard> >
< < block> >
M oving m echanical com ponent s
< < Harm > >
< < block> >
Dislocat ed joint s, broken bones or choking
< < block> >
Wheel cover
< < DefenceResult> >
< < block> >
Wheel covers result
< < block> >
Elect ric m ot or
< < block> >
Wheel
< < Harm Context> >
< < block> >
36a. Riding user t ouches a wheel during m ot ion and get s t heir hand or fingers caught
< < deriveHzd> >< < deriveHzd> > < < block> >
Wheel
< < deriveHC> >
< < PassiveDefence> >
< < block> >
Wheel covers
< < requirem ent> >
text = The wheels
shall be covered
such that the user
and objects
cannot touch
them during
m otion.
Id = 140
Wheel covers
< < reqDefence> >
< < satisfy> >
SafeML
System components, activities, etc.
Sources of
hazard
Hazard
Potential
harm
Hazardous
situation/event
Result of safety
measure
Safety
measure
Safety
requirement

33. SafeML
[package] Wheelchair robot [Wheelchair robot]b d d
< < block> >
Elect ric m ot or
< < block> >
Wh eel
< < block> >
Drive t rain
< < block> >
Drive u n it
< < system > >
< < block> >
Wh eelch air rob ot
Right drive unit
< < block> >
Wh eel cover
2
[package] Safety diagrams [36a. Riding user touches a wheel during motion and gets their hand or fingers caught]bdd
< < Hazard> >
< < block> >
Moving mechanical components
< < Harm> >
< < block> >
Dislocated joints, broken bones or choking
< < block> >
Wheel cover
< < DefenceResult> >
< < block> >
Wheel covers result
< < block> >
Electric motor
< < block> >
Wheel
< < HarmContext> >
< < block> >
36a. Riding user touches a wheel during motion and gets their hand or fingers caught
< < deriveHzd> >< < deriveHzd> > < < block> >
Wheel
< < deriveHC> >
< < PassiveDefence> >
< < block> >
Wheel covers
< < requirement> >
text = The wheels
shall be covered
such that the user
and objects
cannot touch
them during
motion.
Id = 140
Wheel covers
< < reqDefence> >
< < satisfy> >

34. SafeML:
Automated
analysis

35. MARTE
• Used
MARTE
to
model:
– Timing
of
control
soeware
– Deployment
of
soeware
into
execu;on
hardware

36. MARTE
Control softwarepkg
Control software
isPeriodic}
{durationElements="10ms..2ms";
<<SwTimerResource>>
<<SwSchedulableResource>>
Partner comms
isPeriodic}
{durationElements="10ms..2ms";
<<SwTimerResource>>
<<SwSchedulableResource>>
Command processor
isPeriodic}
{durationElements="10ms..2ms";
<<SwTimerResource>>
<<SwSchedulableResource>>
User Interface driver
{mechanism="Blackboard"}
<<MessageComREwource>>
Internal comms
isPeriodic}
{durationElements="10ms..2ms";
<<SwTimerResource>>
<<SwSchedulableResource>>
Safety monitor
isPeriodic}
{durationElements="10ms..2ms";
<<SwTimerResource>>
<<SwSchedulableResource>>
Motor control
<<HwComputingResource>>
<<block>>
Microprocessor
<<HwRAM>>
<<block>>
RAM
<<HwROM>>
<<block>>
ROM
+ partnerComm
+ safMon
+ cmdProc + ui
+ ic
+ rAM+ microprocessor
+ rOM+ microprocessor
+ motorCtrl

37. Conclusion

38. Points
of
interest
Initial system design (system model)
Hazard analysis, …
SysML
Safety model
System model with safety information
SysML
+
SafeML
SafeML
SafeML
is
effec;ve
at
providing
traceability
between
system
and
safety
informa;on

39. Points
of
interest
Revisions to design (safety features)
SysML
Revised system model with safety information
SysML
+
SafeML
System model
SysML
+
SafeML
+
MARTE
Implementation details for
feasibility analysis
MARTE
MARTE
has
features
poten;ally
useful
in
modeling
robo;cs,
such
as
;ming
But
MARTE
is
huge
and
the
cost
to
learn
it
is
high

40. Points
of
interest
System model
SysML
+
SafeML
+
MARTE
Implementation details for
feasibility analysis
MARTE
Actual safety achievement plan
(performed safety analyses,
design processes, …)
GSN
Integrated safety case and
system model
SysML
+
SafeML
+
MARTE
+
GSN
GSN
provides
a
good
bird’s-­‐eye
view
of
safety
argument
Trying
to
include
detail
leads
to
over-­‐complicated,
hard-­‐to-­‐
understand
diagrams

41. Points
of
interest
• Using
GSN,
SysML,
SafeML
and
MARTE
together,
each
for
their
strengths,
works
well
• Model
tool
support
is
essen;al
– Especially
a
tool
that
allows
integra;ng
many
languages/profiles
into
a
single
model

42. Future
Topics
• New
Integrated
Modeling
Plagorm
will
be
ready
in
near
future.
Model
Integrated
Modeling
Plagorm
UML
UML
Profile
GSN
Other
Models
SysML
MARTE
Applica;on
(Astah)
SafeML

43. Thank
you
Toshihiro Okamura
We
are
exhibi;ng
the
tools.
Please
stop
by!
Michael Jesse Chonoles