SE With GoedelWorks 3
SE With GoedelWorks 3
SE With GoedelWorks 3
Altreonic
From
Trustworthy
Systems
Engineering
Deep Space
To with
GoedelWorks
3
Deep Sea
Altreonic
NV
Gemeentestraat
61A
B1
B-‐3210
Linden
Belgium
www.altreonic.com
info.
request
(@)
altreonic.com
September
2011
Last
update
-‐
July
2015
©
Altreonic
NV
Contact:
goedelseries
@
altreonic.com
The
name
of
Gödel
(as
in
GoedelWorks)
was
chosen
because
Kurt
Gödel's
theorem
has
fundamentally
altered
the
way
mathema-cs
and
logic
were
approached,
now
almost
80
years
ago.
What
Kurt
Gödel
and
other
great
thinkers
such
as
Heisenberg,
Einstein
and
Wi;genstein
really
did
was
to
create
clarity
in
something
that
looked
very
complex.
And
while
it
required
a
lot
of
hard
thinking
on
their
side,
it
resulted
in
very
concise
and
elegant
theorems
or
formulae.
One
can
even
say
that
any
domain
or
subject
that
s-ll
looks
complex
today,
is
really
a
problem
domain
that
is
not
yet
fully
understood.
We
hope
to
achieve
something
similar,
be
it
less
revolu-onary,
for
the
systems
engineering
domain
and
it's
always
good
to
have
intellectual
beacons
to
provide
guidance.
The
Gödel
Series
publica-ons
are
downloadable
from
our
website.
Other
-tles
in
the
series
cover
topics
of
Real-‐Time
programming,
steering
control
and
on
ARRL.
Copying
of
content
is
permi;ed
provided
the
source
is
referenced.
As
the
booklets
will
be
updated
based
on
feedback
from
our
readers,
feel
free
to
contact
us
at
goedelseries
@
altreonic.com.
PREFACE 3
1. Trustworthy Systems Engineering 6
1.1. What is a system? 6
1.2. What is a Trustworthy system? 8
1.3. What is Systems Engineering? 9
1.4. The subdomains of Systems Engineering 11
1.5. What is Resilience Engineering? 13
2. Unified Systems Engineering 15
2.1. A Process as a System 15
2.2. Unified Semantics 16
2.3. Interacting Entities Semantics 18
2.4. A unifying model for Systems Engineering 19
2.5. Systems Engineering: different views that need to be combined 20
2.6. An informal view on Systems Engineering with GoedelWorks 21
2.6.1. Real engineering is Process of iterations 23
2.6.2. Traceability and configuration management 24
3. Engineering real systems that can fail 25
3.1. ARRL: the Assured Reliability and Resilience Level criterion 25
3.2. Overview of existing criteria in the domain of trustworthiness 25
3.2.1. Safety Integrity Level 25
3.2.2. Quality of Service Levels 26
3.3. The ARRL criterion 27
3.4. Is this sufficient for antifragility? 28
3.4.1. Antifragility assumptions 28
3.4.2. Some industries are antifragile by design 29
3.4.3. Do we need an ARRL-6 and ARRL-7 level? 30
3.5. Automated traffic as an antifragile ARRL-7 system 30
3.6. Is there an ARRL-8 level? 31
3.7. Conclusions 32
4. The systems Grammar of GoedelWorks 33
4.1. Systems Grammar 33
4.2. Terminology and its conventions in GoedelWorks 36
4.3. Process Steps, instantiated as Work Packages in a concrete Project 38
4.4. In the end, any project is iterative 40
4.5. Systems Engineering as a collection of Views 41
5. Description of the GoedelWorks Environment 43
This
defini-on
is
s-ll
generic
and
fairly
vague.
In
the
following
chapters
we
will
make
this
defini-on
more
concrete
(when
we
look
more
into
the
details),
but
more
abstract
as
well
(when
we
try
to
find
the
common
proper-es
for
all
Systems).
Let's
start
by
taking
a
look
at
some
examples.
First
of
all,
our
natural
environment
is
full
of
Systems.
See
for
example
the
system
of
North
Carolina
in
the
picture.
Every
living
creature,
every
plant
is
a
so-‐called
biological
System.
All
of
these,
including
our
own
human
species,
interact
with
each
other
somehow,
in
the
System
that
we
can
call
"life
on
earth".
Also
earth
The many sub systems of the car as a System
The
Systems
that
interest
us
are
the
human-‐made
ones.
Ouen
such
a
System
needs
to
be
considered
together
with
two
other
Systems.
The
first
one
is
the
environment
in
which
the
System
will
be
used.
The
second
is
the
operator
interac-ng
with
the
System.
An
example
of
such
a
System
is
a
car.
These
Systems
are
ouen
very
complex
and
we
could
call
them
technological
Systems.
What
dis-nguishes
them
from
the
biological
Systems
is
that
they
are
the
fruit
of
our
human
intelligence
and
not
of
millions
of
years
of
evolu-on.
What
dis-nguishes
them
further
is
that
these
Systems
ouen
require
the
use
of
many
other
Systems
(called
tools)
to
make
them
and
the
use
of
many
components
and
many
Resources.
As
such,
such
a
technological
System
has
a
long
history
if
we
trace
the
origins
of
every
component.
Each
embodies
decades,
some-mes
centuries
of
human
knowledge.
And
while
these
Systems
are
not
as
complex
as
the
natural
ones,
they
are
ouen
the
result
of
a
concentrated
effort
to
produce
the
System
from
just
a
few
statements
that
describe
its
mission
("We
will
go
to
the
moon
and
return")
in
a
rela-vely
short
period
of
-me.
There
are
many
more,
dedicated
to
e.g.
steel
and
concrete
structures.
Ouen
these
are
more
"norma-ve"
rather
than
describing
a
Process.
The
major
concern
in
these
safety
standards
is
to
avoid
that
a
System
can
harm
or
kill
people.
The
point
of
view
is
one
whereby
the
risk
of
this
happening
must
be
small
enough
and
that
the
cause
of
this
happening
is
a
malfunc-oning
of
the
System,
either
because
some
parts
break,
or
because
external
events
(like
the
Titanic
hixng
an
iceberg)
cause
this
to
happen.
As
explained
in
the
previous
chapter,
any
System
is
part
of
a
larger
System
and
in
par-cular
the
environment
in
which
it
is
used.
A
well
executed
Systems
Engineering
Process
an-cipates
such
failures
and
depending
on
their
probability
of
occurrence,
their
severity
and
Trustworthy
System
Safety Security Usability Privacy
No
physical
fault
can
No
injected
fault
can
No
interface
fault
can
No
personal
data
can
cause
harm cause
harm cause
harm cause
harm
An example of a systems engineering project split in subdomains during development
Nevertheless,
once
the
System
Requirements
have
been
agreed
upon
and
specified,
engineers
will
select
implementa-on
technologies
each
requiring
different
knowledge
and
skills.
Hence,
the
engineering
Process
will
be
split
in
technical
subdomains,
each
developing
their
part,
auer
which
they
come
together
again
to
deliver
the
System.
The
different
subdomains
are
however
not
isolated.
Decisions
taken
in
one
domain
affect
the
capabili-es
in
another
domain.
For
example
when
a
certain
processor
is
selected,
it
will
determine
how
much
can
be
done
in
souware.
It
will
also
affect
the
power
consump-on
and
maximum
heat
dissipa-on.
A
good
System
design
is
one
whereby
the
right
trade-‐offs
are
made
to
achieve
the
goals.
The
perfect
solu-on
doesn't
exist
because
Requirements
will
conflict
and
one
solu-on
doesn't
fit
all.
Let's
take
a
look
at
a
typical
embedded
device
or
rather
a
System
with
embedded
technology
inside.
Think
about
a
printer,
a
pacemaker,
a
car,
a
house,
a
train,
an
airplane,
a
Mars
rover,
a
submarine
and
so
forth.
Whether
small
or
large,
you
are
likely
to
need
engineering
ac-vi-es
in
the
following
domains:
Mechanical
and
materials
engineering:
real-‐world
devices
are
subjected
to
an
ouen
aggressive
environment,
puxng
stress
on
the
embedded
device.
Vibra-ons,
shocks,
heat,
cold,
humidity,
chemicals
or
even
sunlight,
the
air
or
cosmic
radia-on
will
a;ack
the
packaging
and
the
physical
structure
of
the
System.
If
this
results
in
the
integrity
of
the
delicate
electronics
inside
being
damaged,
or
connec-ons
among
them
failing,
the
results
can
be
fatal.
SoBware
engineering:
on
clocked
reprogrammable
processors
a
souware
program
will
ouen
give
the
embedded
device
its
applica-on
specific
func-onality.
Whereas
the
hardware
state
machine
is
rela-vely
sta-c,
a
souware
state
machine
is
dynamic
and
its
behaviour
can
be
data
dependent.
Contrary
to
hardware
however,
a
souware
state
machine
has
no
proper-es
that
vary
with
external
influences,
hence
it
is
(theore-cally
at
least)
possible
to
fully
verify
and
predict
the
behaviour
of
souware
in
detail.
Souware
has
no
bugs,
only
errors.
There
are
undoubtedly
more
engineering
disciplines
that
come
into
play.
Human
interface
engineering
is
ouen
a
neglected
one.
Today,
Produc-on
Engineering
is
more
and
more
part
of
the
Development
Ac-vi-es.
Within
the
different
engineering
subdomains
one
can
find
more
specialised
subdomains.
Algorithmic
experts
will
develop
the
right
algorithm
to
process
the
data,
hydraulic
engineers
will
add
their
bit,
control
The South Pole Station Dome (being deconstructed)
A simplified iterative V-process model
Let's
take
as
an
example
the
development
of
a
piece
of
souware.
It
includes
ac-vi-es
of
wri-ng
the
source
code
statements,
compiling
them,
running
the
resul-ng
executable
and
tes-ng
it.
This
will
itera-vely
result
in
a
working
program.
But
depending
on
the
skills
of
the
souware
programmer,
this
can
take
less
or
more
-me
to
get
it
right.
A
skilled
programmer
will
follow
a
specific
set
of
steps
that
will
lead
him
faster
and
more
predictably
to
a
reliable
piece
of
souware.
In
essence,
a
skilled
programmer
has
developed
his
own
"Process"
to
deliver
a
be;er
job.
What
Systems
engineering
does
is
to
take
the
best
of
prac-ces
and
to
define
them
as
a
Process
that
should
be
followed
by
an
organisa-on
or
Project
team.
Standards
define
these
prac-ces
as
recommenda-ons,
although
cer>fica>on
might
impose
rather
strict
obliga-ons.
In
any
case,
any
organisa-on
will
have
its
own
history
and
heuris-c
prac-ces
and
they
must
be
integrated
with
what
standards
might
impose.
For
example,
the
souware
engineering
Processes
will
define
that
the
A unifying view on systems engineering
Reading
safety
engineering
or
Systems
Engineering
standards
can
be
a
daun-ng
Task,
certainly
the
first
-me.
There
are
several
reasons
for
this.
First
of
all,
these
standards
came
gradually
into
being
ouen
driven
by
an
industrial
or
societal
need.
Most
of
the
-me,
it
is
the
work
of
a
commi;ee,
stretched
over
many
years.
In
addi-on
few
scien-fic
work
has
been
done
on
the
subject,
although
much
work
has
been
done
on
specialised
subdomains.
For
this
reason
current
standards
are
ouen
heuris-c
in
nature,
albeit
newer
releases
of
the
standards
(e.g.
ISO-‐26262)
have
clearly
benefited
from
user
feedback.
It
should
be
noted
that
there
are
two
classes
of
standards.
European
standards
are
more
prescrip-ve
and
norma-ve,
whereas
US
standards
are
more
goal
oriented,
leaving
it
up
to
the
user
to
prove
that
they
have
done
everything
necessary
to
reach
the
goals.
Examples
are
e.g.
DO-‐178B/C.
These
standards
also
follow
more
the
philosophy
of
the
CMMI
maturity
Model,
whereby
quality
of
the
organisa-onal
Processes
(of
which
Engineering
is
one)
is
seen
as
a
result
of
the
"maturity"
and
capability
of
the
organisa-on
and
less
the
result
of
following
a
prescribed
Process.
To
get
a
clearer
picture
on
Systems
engineering,
we
have
analysed
different
Systems
Engineering
Processes
as
described
in
the
various
standards
and
publica-ons
and
tried
to
develop
a
generic
meta-‐Model
for
it
that
can
be
applied
to
almost
any
engineering
Project.
We
define
the
concepts
at
a
generic
level.
Together
they
create
the
meta-‐Model
of
Systems
engineering.
Domain
specific
concepts
can
further
be
derived
from
these
generic
concepts.
This
list
is
certainly
not
complete
but
new
terms
and
concepts
should
be
refinements
of
these
generic
terms.
Refinements
can
be
driven
by
a
specific
domain
or
Process
of
by
a
further
decomposi-on
and
defini-on
of
a;ributes.
A
typical
example
are
Specifica-ons
that
are
refined
into
Func-onal
Specifica-ons
such
as
Interface
Specifica-ons,
Implementa-on
Specifica-ons
and
Test
Specifica-ons
and
non-‐func-onal
Specifica-ons
that
ouen
are
related
to
proper-es
of
the
system
like
power
consump-on,
maintainability,
etc.
By
themselves
these
concepts
do
not
define
a
Systems
engineering
Process
or
Project
(as
we
will
see
further
this
dis-nc-on
is
for
prac-cal
reasons).
In
the
next
sec-ons
we
will
link
these
concepts
and
define
their
possible
state
a;ributes.
2.5. Systems
Engineering:
different
views
that
need
to
be
combined
A
major
issue
in
systems
engineering,
and
that
applies
also
for
many
of
its
subdomains,
is
that
engineering
a
system
or
product
requires
the
convergence
of
different
wide
ranging
views
that
each
look
from
a
different
perspec-ve.
This
partly
explains
why
one
finds
that
the
terminology
is
not
always
consistent
and
why
no
standard
or
reference
text
provides
coverage
of
all
aspects.
It
also
explains
why
one
finds
mul-ple
complementary
engineering
approaches
indicated
with
terms
like
“requirements
driven
engineering”,
“test
driven
engineering”,
“model
driven
engineering”,
etc.
In
reality,
one
needs
all
of
them.
The mental mapping from the intentional domain to the implementation domain
In
addi-on,
a
lot
of
the
engineering
ac-vi-es
really
happen
in
people’s
mind.
Engineering
is
really
the
discipline
that
allows
us
to
transform
ini-ally
abstract
ideas
and
concepts
into
real
tangible
objects.
This
transforma-on
is
really
like
a
mathema-cal
mapping
from
the
abstract
into
the
concrete
domain.
As
such,
this
is
reflected
in
Wi;genstein’s
defini-on
but
also
in
the
main
ac-vi-es
one
can
dis-nguish
in
an
engineering
project.
The
previous
two
diagrams
illustrate
this.
Requirements
and
Specifica-ons
capturing
is
about
proper-es
and
statements
about
the
system
and
its
components.
In
the
modelling
side
of
As
one
can
see,
the
Systems
Engineering
Process
has
wide
ramifica-ons.
It
starts
early
and
it
ends
long
auer
the
System
was
put
to
opera-onal
use.
It
is
important
also
to
see
that
the
System
is
actually
"defined"
by
3.2. Overview of exis>ng criteria in the domain of trustworthiness
The
classifica-on
leaves
room
for
residual
risks
but
those
are
not
considered
design
goals
but
rather
as
uncontrollable
risks.
Neither
the
user
nor
the
system
designer
has
much
control
over
them.
This
is
due
to
the
existence
of
non-‐linear
discrete
subsystems
(mainly
digital
electronics
and
souware)
which
was
elaborated
further
in
[5].
This
aspect
will
be
important
when
we
discuss
the
concept
of
an>fragility
further
in
this
text.
The
SIL
level
is
used
as
a
direc-ve
to
guide
selec-ng
the
required
architectural
support
and
development
process
requirements.
For
example
SIL-‐4
imposes
redundancy
and
posi-ons
the
use
of
formal
methods
as
highly
recommended.
ARRL
defini>on
Inheritance
Each
ARRL
level
inherits
all
proper-es
of
any
lower
ARRL
level.
property
ARRL-‐0 The
component
might
work
(“use
as
is”),
but
there
is
no
assurance.
Hence
all
risks
are
with
the
user.
ARRL-‐1 The
component
works
“as
tested”,
but
no
assurance
is
provided
for
the
absence
of
any
remaining
issues.
ARRL-‐2 The
component
meets
all
its
specifica-ons,
if
no
fault
occurs.
This
means
that
it
is
guaranteed
that
the
component
has
no
implementa-on
errors,
which
requires
formal
evidence
as
tes-ng
can
only
uncover
testable
cases.
The
formal
evidence
does
not
necessarily
provide
complete
coverage
but
should
uncover
all
so-‐called
systema-c
faults,
e.g.,
a
wrong
parameter
value.
In
addi-on,
the
component
can
s-ll
fail
due
to
randomly
induced
faults,
for
example
an
externally
induced
bit-‐flip.
ARRL-‐3 The
component
is
guaranteed
to
reach
a
fail-‐safe
or
reduced
opera-onal
mode
upon
a
fault.
This
requires
monitoring
support
and
some
form
of
architectural
redundancy.
Formally
speaking
this
means
that
the
fault
behaviour
is
predictable
as
well
as
the
subsequent
state
auer
a
fault
occurs.
This
implies
that
specifica-ons
include
all
fault
cases
as
well
as
how
the
component
should
deal
with
them.
ARRL-‐4 The
component
can
tolerate
one
major
fault.
This
corresponds
to
requiring
a
fault-‐
tolerant
design.
This
entails
that
the
fault
behaviour
is
predictable
and
transparent
to
the
external
world.
Transient
faults
are
masked
out.
ARRL-‐5 The
component
is
using
heterogeneous
sub-‐components
to
handle
residual
common
mode
failures.
3.7. Conclusions
Taleb
[10]
defines
an-fragile
mostly
in
the
context
of
a
subjec-ve
human
social
context.
He
quotes
the
term
to
indicate
something
beyond
robustness
and
resilience
that
reacts
to
stressors
(and
alike)
by
actually
improving
its
resistance
to
such
stressors.
Taking
this
view
in
the
context
of
systems
engineering
we
see
that
such
systems
already
exist.
They
are
dis-nguished
by
considering
the
system
as
a
component
in
a
greater
system
that
includes
the
opera-ng
environment
and
it
con-nuous
processes
and
all
its
stakeholders.
Further
differences
are
a
culture
of
openness,
con-nuous
striving
for
perfec-on
and
the
existence
of
numerous
mul--‐level
feedback
loops
whereby
independent
authori-es
guide
and
steer
the
system
as
a
whole.
The
result
is
a
system
that
evolves
towards
higher
degrees
of
an-fragility.
An
essen-al
difference
with
tradi-onal
engineering
is
that
the
system
is
con-nuously
being
redefined
and
adapted
in
an
an-fragile
process.
We
also
defined
two
new
levels
for
the
norma-ve
ARRL
criterion,
ARRL-‐6
indica-ng
a
system
that
preven-vely
seeks
to
avoid
failures
by
repair
and
ARRL-‐7
whereby
a
larger
process
is
capable
of
not
only
repairing
but
also
upda-ng
the
system
in
a
controlled
way
without
disrup-ng
its
intended
services.
Given
the
existence
of
systems
with
such
(par-al)
proper-es,
it
is
not
clear
whether
the
use
of
the
neologism
“an-fragile”
is
jus-fied
to
replace
reliability
and
resilience,
even
if
it
indicates
a
clear
qualita-ve
and
dis-nc-ve
level.
This
will
need
further
study.
Development The
Development
Ac-vity
is
the
ac-vity
that
actually
develops
or
implements
the
Work
Products.
Verifica>on A
Verifica-on
Ac-vity
is
the
ac-vity
that
verifies
that
the
development
was
done
according
to
the
agreed
upon
Process
Specifica-ons.
Tes>ng A
Test
Ac-vity
is
the
ac-vity
that
verifies
that
the
developed
and
verified
Work
Products
meet
their
approved
Specifica-ons.
Integra>on An
Integra-on
Ac-vity
combines
the
composing
Items
and
Work
Products
into
a
larger
System
or
subsystem
component.
Valida>on A
Valida-on
Ac-vity
is
the
ac-vity
that
auer
integra-on
of
all
System
components
and
Work
Products
validates
that
the
tested
Work
Products
meet
the
original
and
approved
Requirements.
Reviewing A
Review
ac-vity
is
a
confirma-on
measure
that
confirms,
best
independently,
that
an
Ac-vity
was
done
correctly
and
that
its
approval
was
jus-fied.
It
also
acts
an
extra
feedback
loop
to
detect
oversights.
Model A
Model
is
a
Work
Product
developed
in
a
Systems
engineering
Project
during
the
development
ac-vi-es.
The
finally
approved
System
is
considered
as
an
implementa-on
Model.
Item An
Item
is
a
generic
System
component,
making
abstrac-on
of
the
implementa-on.
Interac>on An
Interac-on
is
an
En-ty
that
creates
a
structural
connec-on
between
one
or
more
System
Items.
Link
A
Link
is
a
rela-onship
between
one
or
more
En--es.
We
dis-nguish
between
associa-ve
links
(e.g.
dependency
rela-onships),
decomposi-on
links
and
process
flow
links
(defining
a
par-al
order
in
-me).
4.3. Process
Steps,
instan>ated
as
Work
Packages
in
a
concrete
Project
As
we
will
see
further,
in
GoedelWorks
we
consider
that
a
System
is
the
result
of
a
specific
Project
whereby
a
specific
Process
is
followed.
In
a
Process
defini-on
we
will
find
a
typical
succession
of
Steps
that
generically
define
a
par-al
order
of
ac-vi-es.
Examples
of
such
Process
are
the
ASIL
flow
(single
V-‐model)
or
DO-‐178
(double
V-‐model).
In
a
concrete
organisa-on
these
will
have
combined
with
organisa-on
specific
Steps,
procedures
and
guidelines.
In
a
concrete
Project,
these
Process
Steps
are
instan-ated
as
concrete
Work
Packages.
In
GoedelWorks
the
Work
Package
has
been
structured
using
a
standardised
template,
a
par-al
order
of
Work
Package
Ac-vi-es
and
associated
Artefacts.
One
could
consider
these
as
the
micro
steps
of
a
small
itera-ve
V-‐model.
While
the
terminology
was
chosen
to
be
generic
(and
applicable
to
almost
any
Process
Step),
it
more
or
less
reflects
a
typical
Development
Work
Package
as
this
is
considered
as
the
core
of
an
engineering
Project.
In
the
table
below,
we
have
listed
the
standardised
Ac-vi-es
and
their
composing
phases.
Ac>vity
stages
Planning This
phase
extracts
and
refines
the
planning
done
at
the
Work
Package
level
into
a
planning
specific
for
the
Ac-vity.
Doing The
actual
work
to
be
done
in
the
Ac-vity.
Documen>ng A
documented
record
of
what
was
done
in
the
Ac-vity.
It
must
be
complete
in
the
sense
that
any
element
that
has
or
had
a
possible
impact
on
the
resul-ng
Work
Product
must
be
traceable
and
iden-fiable.
Confirma>on Each
ac-vity
needs
to
be
reviewed
for
residual
issues
and
oversights.
Ouen
dictated
by
Process
Requirements,
reviews
are
best
done
by
independent
people.
Their
goal
is
to
confirm
in
an
independent
way
that
the
objec-ves
were
met.
It
also
serves
as
addi-onal
feedback
that
seek
to
find
oversights.
The
Ac-vi-es
hence
produce
two
types
of
outputs.
The
actual
Items
developed
are
called
Work
Products
whereas
the
suppor-ng
evidence
are
called
Artefacts.
In
trustworthy
(and
hence
cer-fiable)
Systems
Engineering
any
product
comes
with
the
suppor-ng
evidence
(which
can
be
seen
as
a
contract)
that
it
meets
its
Requirements
and
Specifica-ons
and
that
it
was
developed
according
to
the
Required
and
Specified
Process
(that
is
meant
to
assure
the
trustworthiness
of
the
Work
Products).
The
final
steps
are
to
transfer
the
development
to
produc-on.
A
good
Systems
engineering
Project
will
have
been
designed
with
produc-on
and
deployment
issues
in
mind.
This
affects
quality
and
it
also
affects
the
(financial)
bo;om-‐line.
During
the
life
-me
of
a
System
(or
product)
good
Engineering
will
have
an-cipated
maintenance
and
even
upgrading
to
assure
that
the
System
keeps
performing
at
its
specified
level.
Finally,
when
the
System
will
be
taken
out
of
service,
it
will
need
to
be
disposed
off.
Modern,
environmentally
friendly
Engineering
will
have
thought
about
that
as
well.
A GoedelWorks screenshot of a Development Task Entity
The
next
diagram
illustrates
an
abstrac-on
of
the
Work
Package
internal
Ac-vi-es.
For
the
sake
of
simplicity,
we
ignored
the
blue
decomposi-on
links
as
they
apply
to
any
En-ty
and
mainly
clu;er
the
diagram.
It
illustrates
how
the
Ac-vi-es
of
a
Work
Package
depend
on
Project
Specifica-ons
derived
by
refinement
and
decomposi-on
from
Project
Requirements,
itself
possible
poin-ng
to
external
References.
Finally,
a
search
func-on
allows
to
filter
a
tree
and
display
all
the
En--es
containing
the
search
string.
In
the
example
below,
the
search
string
was
“Port”.
The
En-ty
Containers
are
sorted
according
to
the
Systems
Grammar.
Note
also
that
En--es
receive
a
naviga-on
tree
number.
This
number
will
change
dynamically
when
the
naviga-on
tree
is
modified.
Hence,
the
user
should
not
use
it
to
refer
to
an
En-ty
but
use
instead
the
e-‐id
unique
iden-fier.
The
la;er
is
also
reflected
in
the
url
displayed
in
the
address
bar,
for
easy
and
quick
reference
as
well
as
in
the
tab
of
the
En-ty
view.
The
naviga-on
tree
nodes
will
also
display
the
number
of
composing
En--es.
On
the
naviga-on
tree,
mul-ple
opera-ons
are
possible:
• Locking
the
tree:
his
is
to
avoid
that
the
user
accidentally
changes
the
posi-on
of
an
en-ty
in
the
naviga-on
tree
• Create
new
En--es
or
composi-onal
sub-‐En--es.
• Create
a
group
of
En--es
(via
a
pop-‐up
input
table)
• Set
the
Work
Flow
status
for
a
complete
branch.
• Import
data
from
a
CSV
file
(table
format).
Changing the Work Flow status of a group of Entities on the navigation tree
Entity view showing the html editor pane
Most
of
the
-me,
a
GoedelWorks
user
will
be
working
in
the
En--es
view.
In
the
main
view,
several
opera-ons
can
be
performed,
such
as
• Edi-ng
a
Summary
text,
the
descrip-on
(in
html
or
text),
• Leaving
and
reviewing
comments
• Changing
the
posi-on
in
the
naviga-on
tree.
• Reviewing
the
change
log.
• Genera-ng
a
dependency
or
most
ouen
the
precedence
tree.
Such
a
tree
can
be
in
a
graphical
or
textual
format
or
exported
as
a
graphml
file.
The
la;er
can
be
very
handy
to
analyse
a
graph
in
depth
using
an
external
graph
editor
(like
Yed).
• Defining
the
workflow
state
(any
of:
Defined,
In
Work,
Frozen
for
Approval,
Approved).
Note
that
when
an
Approved
En-ty
is
edited
again,
its
state
as
well
as
the
state
of
all
dependent
En--es
will
be
changed
to
“In
Work”
again.
• Defining
access
rights
and
permissions
depending
on
the
role
of
the
user.
This
can
be
defined
differently
for
any
sec-on
of
the
items
in
a
Naviga-on
tree.
Changes
to
en--es
are
recorded
at
the
En-ty
level
(where
revert
opera-ons
are
possible)
as
well
as
globally
displayed
at
the
portal’s
level.
Each
entry
in
the
log
will
record
the
en--es
content
before
and
auer
the
change
was
applied.
This
can
BE
very
helpful
when
analysing
later
on
what
changes
were
applied
and
why
they
were
applied,
as
well
as
who
was
the
user
making
the
changes.
As
a
general
principle,
no
informa-on
is
ever
physically
deleted
on
a
portal
(the
iden-fier
is
incremented
whenever
an
En-ty
is
created).
This
way,
all
design
decisions
are
recorded
for
future
reference
and
configura-on
management
is
unambiguous.
Even
deleted
en--es
remain
in
the
system
in
a
dedicated
Container.
En--es
can
be
decomposed
and
linked
to
mul-ple
other
En--es,
Process
as
well
as
Project
related,
which
also
affects
the
capability
to
reverse
changes,
especially
later
on.
This
has
an
impact
on
how
we
can
define
baseline
configura-ons.
The
la;er
must
be
a
coherent
set
of
En--es
(in
principle
each
the
being
the
most
up
to
date
ones)
as
well
as
coherent
set
of
links
between
the
En--es.
Therefore,
establishing
baseline
configura-ons
is
only
allowed
at
the
level
of
a
Process
or
a
Project,
as
illustrated
below:
Using
this
configura-on
capability,
one
can
define
for
example
product
families.
• Status
Report:
User
can
check
at
any
moment
the
implementa-on
and
tes-ng
status
of
any
project.
• Edit
en--es
in
a
table
format
• Import
of
version
control
system
items
as
GW
En--es
Import
of
version
control
system
items
as
GW
en--es
Integra-on
with
version
control
systems
• GoedelWorks
provides
the
user
with
an
interface
to
exchange
data
with
different
version
control
systems.
The
interface
is
achieved
through
Process
Artefacts
and/or
Project
Work
Products.
Content
is
copied
from
the
repository
to
GoedelWorks
and
kept
local.
Data
is
only
updated
on
user
request.
The
user
can
also
renew
the
contents
of
the
file
in
the
version
control
system
by
using
GoedelWorks
to
submit
a
new
version.
• Integra-on
with
souware
items:
Project
Work
Products
can
be
associated
with
souware
contents.
A
proper
source
code
editor
is
available
and
it
supports
many
programming
languages.
Contents
can
be
taken
from
version
control
systems.
5.4.8. Administration
The
administra-on
panel
is
reserved
for
users
with
the
necessary
administra-on
rights.
Without
going
into
details,
it
offers
several
op-ons
to
manage
the
portal
and
its
users.
We
list
them
briefly:
• Changing
the
welcome
message
and
welcome
image.
• Import
and
expor-ng
Processes
and
Projects
or
any
En-ty.
• Manage
the
uploaded
files
(a;achments
and
images
used
in
descrip-ve
texts).
5.4.9. Glossary
The
user
can
define
his
own
glossary,
currently
regrouping
the
terms
used
at
the
level
of
the
portal.
Glossary screenshot
The
Project
will
become
more
predictable
and
traceable,
errors
are
detected
in
an
early
stage
(when
they
cost
less
to
correct)
and
when
considering
life-‐cycle
costs,
it
might
turn
out
to
be
cost-‐efficient,
especially
if
support
and
maintenance
costs
are
included.
In
the
worst
case,
a
serious
issue
can
be
discovered
when
the
System
is
in
use
and
opera-onal.
Recalls
to
fix
these
issues
can
be
very
costly,
not
only
financially
but
also
in
reputa-on
damage,
etc.
Therefore,
Cer-fica-on
is
a
must
but
there
is
every
interest
to
reduce
the
cost.
Note
also
that
the
term
Qualifica-on
is
also
ouen
used.
It
is
very
much
like
Cer-fica-on
with
the
difference
that
there
are
ouen
there
no
legal
consequences
and
it
is
the
term
ouen
used
to
indicate
fitness
for
use
of
a
component
or
tool.
Hence,
it
is
ouen
the
integrator
that
is
responsible
for
assuring
that
a
tool
or
component
is
of
sufficient
quality
and
can
be
trusted
to
be
used
in
the
context
of
his
Project.
The
GoedelWorks
environment
contributes
to
this
on
several
levels
by
automa-ng
the
engineering
Process:
• The
organisa-on
uses
a
standards-‐aware
Process.
• The
approval
Process
reduces
rework
and
double
work.
• The
cer-fica-on
artefacts
are
generated
during
development.
• Organisa-ons
can
"pre-‐cer-fy"
by
following
the
Process.
7. References
[1]
Eric
Verhulst,
Bernhard
Sputh,
Jose
Luis
de
la
Vara,
Vincenzo
de
Florio,
ARRL:
a
novel
criterion
for
Composable
Safety
and
Systems
Engineering.
SafeComp/SASSUR
workshop.
Toulouse,
September
2013.
[2]
Eric
Verhulst,
Bernhard
Sputh,
Jose
Luis
de
la
Vara,
Vincenzo
de
Florio.
From
Safety
Integrity
Level
to
Assured
Reliability
and
Resilience
Level
for
composable
safety
cri-cal
systems,
ICSSEA,
Paris,
Nov.
2013.
[3]
Eric
Verhulst,
Bernhard
Sputh.
ARRL,
a
criterion
for
composi-onal
safety
and
systems
engineering.
A
norma-ve
approach
to
specifying
components.
IEEE
ISRRE2013,
Pasadena,
November
2013.
[4]
h;p://www.iec.ch/func-onalsafety/.
Func-onal
safety
of
electrical
/
electronic
/
programmable
electronic
safety-‐related
systems
(IEC
61508)
(2005)
[5]h;p://www.altreonic.com/sites/default/files/Altreonic_ARRL_DRAFT_WIP011113.pdf.
From
Safety
Integrity
Level
to
Assured
Reliability
and
Resilience
Level
for
Composi-onal
Safety
Cri-cal
Systems
(internal
white
paper)
[6]
h;p://www.rtca.org
[7]
IEC:
ISO:
Interna-onal
Standard
Road
vehicles
-‐
Func-onal
safety
-‐
ISO/DIS
26262
(2011)
[8]
BAA:
Aircrau
Crashes
Record
Office.
h;p://baaa-‐acro.com/index.html
(2013)
[9]
World
Health
Organisa-on:
WHO
global
status
report
on
road
safety
2013:
suppor-ng
a
decade
of
ac-on.
Technical
Report
(2013)
[10]
An-fragile.
Things
that
gain
from
disorder.
Nassim
Nicholas
Taleb.
Random
House
(Nov.
2012)
[11]
h;p://ec.europa.eu/environment/noise/home.htm
8. ANNEXES
1. ASIL
Roles
1.1. Configura-on
manager
1.2. Hardware
architect
1.3. Hardware
developer
1.4. Hardware
integrator
1.5. Project
manager
1.6. Quality
Assurance
manager
1.7. Safety
manager
1.8. Souware
architect
1.9. Souware
developer
1.10. Souware
integrator
1.11. Stakeholder,
defined
by
impact
analysis
1.12. Supply
manager
1.13. System
Architect
1.14. System
Integrator
1.15. Test
engineer
1.16. Valida-on
engineer
1.17. Verifica-on
engineerList
of
ASIL
Roles
Acknowledgements
While
GoedelWorks
is
a
development
of
Altreonic,
part
of
the
theore-cal
work
was
done
in
the
following
projects:
• EVOLVE
(Evolu-onary
Valida-on,
Verifica-on
and
Cer-fica-on).
This
is
an
EU
ITEA
project
executed
from
2007
-ll
2011
with
Open
License
Society
(Altreonic's
R&D
partner).
• ASIL
(Automo-ve
Safety
Integrity
Level).
This
is
a
Flanders'
Drive
project
executed
from
2008
-ll
2011,
with
support
from
IWT,
the
Flemish
Ins-tute
of
Science
and
Technology.
• OPENCOSS
(Open
Pla†orm
for
Evolu-oNary
Cer-fica-on
Of
Safety-‐cri-cal
Systems
(automo-ve,
railway,
avionics).
An
FP7
IP
EU
project
that
researches
way
to
reduce
the
cer-fica-on
costs
across
different
domains
(mainly
automo-ve,
avia-on
and
railway)