SE With GoedelWorks 3

Download as pdf or txt
Download as pdf or txt
You are on page 1of 71

 

Altreonic
From
Trustworthy  Systems  Engineering    
Deep Space
To with  GoedelWorks  3
Deep Sea

First  publica-on  in  


the  Gödel  Series  
Systems
Engineering
Trustworthy Systems Engineering with GoedelWorks 3

This  publica-on  is  published  under  a  

Crea-ve  Commons  A;ribu-on-­‐NonCommercial-­‐ShareAlike  3.0  Unported  License.

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  

Altreonic NV From Deep Space To Deep Sea Page 2 _


PREFACE  
This   booklet   is   the   first   of   the   Gödel*   Series,   with   the   sub-tle   "Systems   Engineering   for   Smar-es".     The   aim  
of   this   series   is   to   explain   in   an   accessible   way   some   important   aspects   of   trustworthy   systems   engineering  
with  each  booklet  covering  a  specific  domain.    
The   first   publica-on   was   en-tled   "Trustworthy   Systems   Engineering   with   GoedelWorks"   and   explains   the  
high  level  framework  Altreonic  applies  to  the  domain  of  systems  engineering.  It  discusses  a  generic  model  
that  applies  to  any  process  and  project  development.  It  explains  the  16  necessary  but  sufficient  concepts,  
further   elaborated   by   defining   a   standard   template   structure   for   a   Work   Package.   The   version   you   are  
reading   now   is   an   update   reflec-ng   the   metamodel   used   in   version   3   of   the   GoedelWorks   portal.   This  
version  is  based  on  a  more  extended  metamodel.  In  par-cular  it  provides  a  generic  template  metamodel  for  
the  internal  structure  of  a  Works  Package.    
Valida-on   of   the   approach   was   achieved   in   several   ways.   The   model   was   successfully   applied   to   the   import  
of  the  project  flow  of  the  ASIL  (Automo-ve  Safety  Integrity  Level)  project  whereby  a  common  process  was  
developed   based   on   the   IEC-­‐61508,   IEC-­‐62061,   ISO-­‐DIS-­‐26262,   ISO-­‐13849,   ISO-­‐DIS-­‐25119   and   ISO-­‐15998  
safety   standards   covering   the   automo-ve   on-­‐highway,   off-­‐highway   and   machinery   domain.   It   was   also   used  
for  in-­‐house  engineering  projects  such  as  the  Qualifica-on  Package  for  OpenComRTOS  Designer  and  for  the  
development  of  a  scalable  e-­‐vehicle.  
Through   these   Projects,   the   GoedelWorks   metamodel   has   undergone   further   refinements   and  
improvements,  bringing  it  closer  to  the  daily  prac-ce  of  a  rigorous  Engineering  Process.  In  parallel,  Altreonic  
has   developed   a   novel   criterion   called   ARRL   (Assured   Reliability   and   Resilience   Level)   providing   a   first  
guideline   on   how   components   or   subsystems   can   be   reused,   be   it   in   a   product   family   or   across   different  
applica-on   domains   while   taken   failure   mode   into   account.   The   ideas   behind   ARRL   reflect   very   well   the  
philosophy  behind  trustworthy  systems  engineering  and  therefore  we  dedicated  a  summarising  chapter  to  it  
even  though  ARRL  is  the  subject  of  another  booklet.  

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.                                    

Eric  Verhulst,  CEO/CTO  Altreonic  NV  

*:  pronuncia-on    [ˈkʊʁt  ˈɡøːdəl]  (  listen)  


Trustworthy Systems Engineering with GoedelWorks 3

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

Altreonic NV From Deep Space To Deep Sea Page 4 _


Trustworthy Systems Engineering with GoedelWorks 3

5.1. Principles of operation 43


5.2. Organisational functions of a GoedelWorks portal 44
5.3. GoedelWorks Systems Grammar 45
5.3.1. Top level view 45
5.3.1. View from inside a Work Package 46
5.4. Top level View in a GoedelWorks portal 47
5.4.1. Navigation tree view 49
5.4.2. The entity pane view 52
5.4.3. Query capability 52
5.4.4. GANTT chart 54
5.4.5. Change Log 55
5.4.6. Version and configuration management in GoedelWorks 55
5.4.7. Productivity supporting features 57
5.4.8. Administration 57
5.4.9. Glossary 58
5.5. A project example 59
5.5.1. The OpenComRTOS Qualification project 59
5.5.2. Planning the Qualification Project 59
5.5.3. The Planning Activities 61
5.5.4. Design Activities 61
5.5.5. Some statistics 61
6. Safety standards awareness in GoedelWorks 62
6.1. Safety standards for embedded reprogrammable electronics 62
6.2. ASIL: A safety engineering process focused around ISO-26262 62
6.3. Certification, qualification after validation 63
6.4. Organisation specific instances of GoedelWorks 65
7. References 65
8. ANNEXES 66
8.1. Entities supported in GoedelWorks 3 66
8.2. Entities defined in the ASIL Process 69
Acknowledgements 71

Altreonic NV From Deep Space To Deep Sea Page 5 _


Trustworthy Systems Engineering with GoedelWorks 3

1. Trustworthy  Systems  Engineering  

1.1. What  is  a  system?  


It  might  surprise  you,  but  while  the  word  "System"  has  its  origins  in  the  Greek  philosophy,  it  is  only  in  the  
last  50  years,  with  the  rapid  advance  of  electronics  and  computers  that  the  word  System  became  a  standard  
technical   term.   The   meaning   is   s-ll   the   same,   but   what   mo-vates   the   use   of   the   word   (vs.   for   example  
“machine”)  is  the  underlying  complexity.  Electronic  Systems  today  can  have  thousands  of  components,  each  
component   being   a   complex   System   in   itself.   A   modern   state   of   the   art   Processor   for   example   has   a   few  
billion  of  logical  elements.  S-ll,  what  we  see  on  the  outside  is  ouen  only  just  a  piece  of  plas-c  with  some  
-ny  metal  bumps  underneath.  Such  a  System  might  be  a  part  in  a  larger  System  such  as  your  laptop  or  your  
car.   Each   of   these   larger   Systems   might   again   be   just   a   component   of   a   larger   System.   For   example   your  
laptop   is   connected   to   the   internet   System   and   your   car   is   part   of   a   transporta-on   System.   In   these   two  
examples,  the  smallest  part  might  be  just  a  few  tens  of  nanometers  large,  the  largest  part  is  the  world  itself  
with   its   dimensions   that   is   about   10.000   billion   -mes   larger.   Therefore,   let's   consider   the   following  
defini-on:      
A  System  is  a  layered  and  structured  collec>on  of  subsystems,  oBen  called  System  components,  
that  together  act  as  a  whole  and  provide  a  specific  func>onality.    

The System of North Calorina (Carolina (Src: http:// www.enst.umd.edu)

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  

Altreonic NV From Deep Space To Deep Sea Page 6 _


Trustworthy Systems Engineering with GoedelWorks 3
-des).   Humans   are   also   social   beings   and   our   civilisa-on   is   full   of   social,   economic   and   poli-cal   Systems.  
Most  of  these  have,  more  or  less,  spontaneously  emerged  and  s-ll  evolve  every  day.  While  these  natural  
Systems  are  very  complex  and  interes-ng  to  study,  they  will  not  be  our  focus,  even  if  we  can  certainly  apply  
some  of  their  mechanisms  to  the  Systems  that  interest  us.  See  for  example  ARRL-­‐8  in  the  chapter  at  the  end  
of  this  booklet.  There  is  even  a  term  called  "social  engineering"  but  this  is  not  what  we  have  in  mind.  On  the  
contrary,  this  is  maybe  exactly  what  we  want  to  avoid  in  real,  trustworthy  Systems  Engineering  Projects.  

 
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.  

Altreonic NV From Deep Space To Deep Sea Page 7 _


Trustworthy Systems Engineering with GoedelWorks 3

1.2. What  is  a  Trustworthy  system?  


The   example   given   above   is   for   the   normal   earthling   perhaps  
too  far  away  from  his  daily  occupa-on,  but  illustrates  very  well  
the   concept   of   Trustworthy   Systems   Engineering.   The  
technology   was   s-ll   in   its   early   days,   there   weren't   that   many  
computers   yet,   but   a   goal   was   defined   to   bring   a   man   to   the  
moon  and  back  to  earth  safely.  This  set  a  process  in  mo-on  that  
would  produce  the  Saturn-­‐V  rocket,  the  Apollo  cabin  and  Lunar  
Lander   and   it   actually   set   14   people   on   the   moon   and   safely  
returned  them.  One  mission  even  showed  that  the  System  was  
resilient  enough  to  bring  back  astronauts  when  their  Apollo  life  
support  System  was  seriously  damaged  by  an  explosion.  Even  if  
astronauts   are   clearly   taking   more   risks   than   the   average  
person,   at   the   end   of   the   day,   what   it   came   down   to   was   that  
the   risk   was   an   accepted   risk   and   no   astronaut   would   have  
Apollo 13 safe return on earth
volunteered  to  step  into  the  Apollo  cabin  on  top  of  the  Saturn-­‐V  
rocket,   if   he   wouldn't   have   had   sufficient   trust   that   he   would  
safely   return.   Therefore,   space   programs   have   been   a   great   catalyser   for   developing   the   discipline   of  
Systems  Engineering.  Hence,  it  is  with  pleasure  that  we  recently  witnessed  the  landing  of  Philae,  part  of  the  
Rose;a   mission,   on   a   comet.   As   an   engineering   project   it   was   simple   yet   very   trustworthy   in   the   context   of  
many   unknown   parameters   of   the   mission.   On   board   was   the   Virtuoso   RTOS,   a   precursor   to   our  
OpenComRTOS  Designer.  It  made  a  small  contribu-on  to  a  large  interna-onal  team  effort  that  auer  10  years  
and  500  million  kilometers  away  gave  us  the  first  close-­‐up  pictures  and  soil  sample  analysis  of  a  comet.    
There  are  of  course  other  domains  where  Systems  engineering  developed  more  than  in  other  domains.  The  
avia-on  industry,  the  defence  sector,  the  shipping  industry,  the  medical  sector,  industrial  manufacturing  and  
railway   have   always   had   a   concern   for   safety,   especially   as   accidents   had   shown   that   things   could   go   wrong  
and  people  could  get  killed.  This  has  resulted  in  the  emergence  of  safety  standards.  Table  1  lists  the  most  
prominent  safety  standards.    

Examples  of  Safety  and  Systems  engineering  standards


IEC-­‐61508 Func-onal  Safety  of  Electrical/Electronic/Programmable  Electronic  Safety-­‐related  
Systems
ISO-­‐26262 Road  vehicles  -­‐-­‐  Func-onal  safety
DO-­‐178B/C Souware  Considera-ons  in  Airborne  Systems  and  Equipment  Cer-fica-on
DO-­‐254 Design  Assurance  Guidance  For  Airborne  Electronic  Hardware
EN-­‐50126 Railway  applica-ons  -­‐  The  Specifica-on  and  demonstra-on  of  reliability,  availability,  
maintainability  and  safety
ECSS-­‐E-­‐ST-­‐40C ESA  -­‐  Space  -­‐  Souware  Engineering

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  

Altreonic NV From Deep Space To Deep Sea Page 8 _


Trustworthy Systems Engineering with GoedelWorks 3
poten-al   consequences   takes   measures   to   keep   the   consequences   within   acceptable   limits.   In   the   less  
severe   cases,   a   simple   warning   will   be   raised   that   repair   is   needed,   but   indica-ng   that   the   System   is   s-ll  
func-onal.   In   more   severe   cases,   part   of   the   func-onality   will   be   lost   and   the   remaining   parts   will   try   to  
keep   the   System   as   func-onal   as   possible.   In   severe   cases,   a   shutdown   will   be   in   order   and   all   func-onality  
will  be  lost.  What  makes  safety  related  Systems  Engineering  challenging  is  that  there  is  a  long  dependency  
chain,   that   the   System   might   contain   millions   of   parts,   that   many   people   will   be   involved   and   that   many  
steps  have  to  be  taken.  The  challenge  is  to  make  this  Process  predictable  and  “managed”.  
There   are   however   other   classes   of   failure   causes   that   also   must   be   considered.   In   safety   most   of   the  
a;en-on   goes   to   physical   causes.   As   our   Systems,   increasingly   containing   compu-ng   devices   that   are   inter-­‐
connected   but   also   having   connec-ons   to   the   outside   world   (a   simple   USB   port   is   enough),   are   also  
vulnerable  to  deliberately  injected  faults.  This  is  ouen  done  in  a  way  to  avoid  detec-on.    
We   call   this   a   security   breach   because   the   integrity   of   the   System   was   jeopardised   without   any   physical  
damage.  Once  the  fault  has  been  introduced  and  ac-vated,  ouen  it  will  be  indis-nguishable  from  a  physical  
fault  and  the  safety  related  risks  are  the  same.        
Another   source   of   risks   is   the   human   user   itself   and   related   to   the   way   he   can   or   is   allowed   to   interact   with  
the  System.  In  this  case  the  risks  are  related  to  many  aspects.  Many  Systems  are  increasingly  complex  and  
no   user   is   supposed   to   know   all   the   details   of   the   inner   workings.   Hence   the   interface   with   the   System  
should   be   predictable   and   unambiguous.   For   new   users,   it   should   be   intui-ve.   As   the   user,   just   like   the  
environment,  it  is  part  of  the  larger  System  that  controls  the  System,  he  should  take  the  correct  ac-ons  at  
all   -mes.   To   minimise   this   risk,   we   say   that   the   usability   of   the   System   must   be   adequate.   The   challenge  
here   is   that   this   involves   familiarity,   hence   conven-on   and   even   adequate   training   while   the   diversity   in  
humans  is  large,  and  psychology  is  ouen  not  a  discipline  in  which  engineers  excel.  
Lately,  as  more  and  more  Systems  become  interconnected  and  increasingly  record  our  personal  data,  the  
need   to   protect   this   data   is   a   factor   as   well.   This   in   turn   results   in   privacy   issues   but   as   more   and   more  
financial  transac-ons  are  electronic,  and  our  private  data  can  be  abused  to  cause  financial  or  other  harm.  
Un-l   some   years   ago,   this   was   a   small   risk,   but   as   the   border   between   embedded   Systems   and   general  
purpose   compu-ng   Systems   (ouen   called   IT   Systems)   is   becoming   opaque,   this   aspect   is   gaining   in  
importance.  
With   this   view,   we   can   understand   that   what   really   ma;ers   is   that   a   user   (whoever   or   whatever   that   is)   can  
trust   the   System.   We   call   this   Trustworthiness.   It   is   clear   that   for   a   System   to   be   trustworthy,   it   is   not  
sufficient  to  be  safe.  We  define  it  as  follows:  A  trustworthy  System  is  a  System  that  a  user  can  trust  to  meet  
high  standards  of  safety,  security,  usability  and  privacy.  

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

1.3. What  is  Systems  Engineering?  


While   we   have   already   used   the   term   above,   we   have   not   elaborated   on   it.   Systems   Engineering   can   be  
defined  as  follows:    
Systems  Engineering  is  the  collecNon  of  AcNviNes  in  a  Systems  Engineering  Project  to  define  and  
develop  a  System  that  will  meet  all  expectaNons.  
This  is  a  very  generic  defini-on.  It  applies  to  any  human  made  System,  whether  it  is  a  social  or  a  technical  
one.   We   will   focus   our   a;en-on   on   those   Systems   that   are   complex   enough   to   pose   a   challenge   to   develop  
them   as   trustworthy   ones.   A   System   can   be   classified   as   complex   if   it   involves   many   ac-vi-es,   many  

Altreonic NV From Deep Space To Deep Sea Page 9 _


Trustworthy Systems Engineering with GoedelWorks 3
components  and  many  decisions  that  need  to  be  taken.  It’s  not  the  sheer  number  of  these  that  ma;er  but  
most   importantly   how   all   the   cons-tuent   elements   interact   (and   that   is   some-mes   in   very   indirect   and  
subtle  ways).  In  par-cular  we  are  mostly  concerned  with  embedded  Systems,  Systems  whereby  electronic  
hardware  and  souware  are  used  to  make  the  System  meet  all  its  Requirements.      
Systems   engineering   is   however   not   an   isolated   set   of  
ac-vi-es.  It  is  a  System  in  itself  that  follows  a  Process  with  
Ludwig Wittgenstein many   dependencies,   but   in   general   we   can   dis-nguish   3  
“Philosophical Grammar” main  ac-vity  domains:  
65 years ago. Organisa>onal   Processes:   Systems   engineering   can   only  
work   if   it   is   itself   embedded   in   an   organisa-onal    
“A blueprint serves as a environment  that  provides  the  pre-­‐condi-ons  for  success.  A  
picture of the object which the simple   example   is   recruitment   and   Human   Resources  
workman is to make from it. management.   A   Systems   engineering   Project   is   a   complex  
… for the builder or the one   and   it   requires   people   with   the   right   skills.   It   also  
engineer, the blueprint is used
requires   an   organisa-onal   culture   that   favours   a   true  
as an instruction or rule
engineering  culture.  The  la;er  is  not  restricted  to  technical  
dictating how he should
ac-vi-es.   An   efficient   organisa-on   that   is   capable   of   good  
construct the building or
communica-on   with   poten-al   users,   planning   Resources,  
machine. And if what he
procurement   of   parts   and   product   manufacturing   are  
makes deviates from the
equally  well  needed.  
blueprint, then he has erred,
built incorrectly and must try Suppor>ng   Processes:   to   execute   a   Systems   Engineering  
again.” Project,   the   organisa-on   needs   to   have   a   number   of  
technical  Processes  in  place  that  are  generic  for  all  Systems  
“… What we may call engineering   Projects.   Their   goal   is   to   support   the  
‘picture’ is the blueprint development   and   engineering   to   become   less   chao-c.   A  
together with the method of its simple  example  is  configura-on  management.  This  must  be  
application”. in  place  to  avoid  that  engineers  spend  their  -me  figuring  out  
what   changes   their   colleagues   made   to   other   parts   of   the  
Wittgenstein defined System.  It  is  also  essen-al  to  make  sure  that  the  final  System  
Systems Engineering has  a  well  known  and  coherent  configura-on.  
before the term even Development  Processes:  these  ac-vi-es  are  the  core  of  the  
existed. work   to   be   done.   While   the   most   gra-fying   ones   are   the  
development   itself,   true   Engineering   consists   of   a   lot   of  
other  ac-vi-es  like  defining  and  analysing  the  Requirements  
and   Specifica-ons,   developing   simula-on   Models,   verifying  
mathema-cally   (using   tools)   the   correctness   of   the   Models,   tes-ng   and   verifying   and   finally   integra-ng   and  
valida-ng  the  results.  
A  Systems  Engineering  Project  is  seldom  an  isolated  ac-vity  and  requires  a  full  life-­‐cycle  view.  Ac-vi-es  that  
have  an  impact  before  the  Systems  Engineering  Project  starts  are  for  example  the  formula-on  of  goals  and  
concepts,   Requirements   collec-on   (from   any   stakeholder)   including   legal   or   societal   Requirements.   There  
might  have  been  previous  Projects  in  which  sub-­‐system  parts  were  developed.  Ac-vi-es  that  must  be  taken  
into   account   auer   the   System   was   developed   are   first   of   all   the   produc-on   of   the   System.   Design   for  
produc-on   is   an   important   Requirement.   Once   the   System   enters   its   opera-onal   life,   users   must   be   trained  
and  the  System  must  be  supported  and  maintained,  maybe  even  upgraded  or  redesigned.  
Finally,  when  the  System  is  taken  out  of  service,  it  must  be  disposed  off.  When  the  System  is  safety  cri-cal,  
two   important   Requirements   will   have   to   be   met   as   well.   The   first   one   is   configura>on   management  
because  a  System  can  only  be  safe  if  all  its  components  work  perfectly  together.  There  have  been  airplane  
incidents   that   were   caused   by   using   a   slightly   different   screw   during   maintenance.   The   other   one   is  

Altreonic NV From Deep Space To Deep Sea Page 10 _


Trustworthy Systems Engineering with GoedelWorks 3
traceability.  When  something  fails,  trust  can  only  be  restored  and  improved  if  the  cause  and  chain  of  events  
resul-ng  in  the  failure  can  be  traced  back.    

1.4. The  subdomains  of  Systems  Engineering  


Seen  from  the  outside,  it  barely  ma;ers  how  a  System  is  composed,  what  technologies  were  used  and  how  
it  was  put  together.  Different  Systems  can  provide  the  same  or  similar  func-onality  to  its  users,  even  if  the  
underlying   technology   is   dras-cally   different.   Originally   radios   had   very   few   and   fairly   big   components.   By   a  
way   of   speaking,   one   could   almost   see   the   electrons   moving   in   the   amplifier   tubes.   Today,   one   can   listen   to  
internet  radio  while  there  is  no  longer  a  tradi-onal  radio-­‐wave  receiver  involved.  The  sound  arrives  in  digital  
packets  over  a  wire.  Radios  are  now  single  chip  devices  using  digital  logic  and  souware  to  provide  the  same  
func-on  as  the  original  coils  and  radio  tubes.  

 
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.  

Altreonic NV From Deep Space To Deep Sea Page 11 _


Trustworthy Systems Engineering with GoedelWorks 3
Power  and  energy  engineering:  all  embedded  systems  need  external  energy  to  func-on.  Increasingly,  it  is  
important  that  they  use  this  energy  efficiently  and  that  they  can  cope  with  varying  energy  sources.  A  good  
power  supply  design  will  increase  reliability  and  will  decrease  life-­‐cycle  costs.  
Hardware  engineering:  this  is  today  ouen  the  term  used  to  designate  all  electronic  engineering  ac-vi-es.  
Some  Projects  might  decide  to  develop  their  own  chips  (ASICs),  use  reprogrammable  ones  (FPGAs)  or  just  
buy   readily   available   processor   parts   (for   example   microcontrollers)   and   put   them   together   to   create   a   sub-­‐
system   component.   The   hardware   part   of   an   embedded   System   might   require   specialists   in   many   more  
specific  domains:  processor  design,  analog  design,  RF  design,  MEMS  (-ny  mechanical  parts  on  a  chip),  etc.  
While   the   analog   domain   is   ouen   less   complex,   given   the   scale   and   speed   of   the   circuits   they   remain   a  
challenge.  All  hardware  opera-ng  in  the  (synchronous)  digital  domain  is  clocked  and  the  issue  is  that  few  
billion   elementary   structures   (ouen   called   gates)   in   the   hardware   share   that   clock.   The   challenge   is   that  
these   billion   gates   operate   as   a   huge   state   machine   whereby   all   gates   must   remain   synchronised.   As   the  
-ming   parameters   of   the   gate   circuits   will   vary   with   temperature   and   supply   voltage,   this   is   not   a   trivial  
ma;er.  Today  these  issues  are  solved  by  applying  large  enough  robustness  margins  during  the  design  and  by  
carefully  controlling  the  produc-on  Process.  

Dependencies for embedded software

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  

Altreonic NV From Deep Space To Deep Sea Page 12 _


Trustworthy Systems Engineering with GoedelWorks 3
engineers  will  design  the  control  loops  to  keep  the  System  stable,  etc.  But  one  thing  is  certain,  they  all  must  
work  together  to  achieve  trustworthy  Systems  Engineering.  
In   addi-on,   there   is   a   long   dependency   chain   between   the   domains.   For   example,   when   developing  
embedded  applica-on  souware,  the  souware  engineer  will  need  to  do  more  than  just  write  his  small  part.  
He  will  link  third  party  libraries,  he  will  use  a  compiler  and  linker  in  the  assump-on  that  they  are  error-­‐free.  
Even   when   that   is   the   case,   the   correct   behaviour   will   depend   on   the   correctness   of   the   documenta-on   (of  
the   hardware   as   well   as   the   souware)   and   on   the   hardware   being   defect-­‐free.   Ouen,   this   will   not   be   the  
case  and  then  he  has  to  find  a  work-­‐around  so  that  the  applica-on  itself  is  s-ll  behaving  as  specified.  The  
example,  illustrated  in  Figure  6  illustrates  how  a  good  engineer  must  know  about  the  other  domains  he  is  
working  in  to  achieve  good  results.  

1.5. What  is  Resilience  Engineering?  


Auer  we  have  reached  beyond  safety  and  went  for  trustworthiness,  there  is  a  further  step  worth  pursuing,  
partly   because   it   is   becoming   inevitable.     As   Systems   become   larger   and   more   complex,   it   is   no   longer  
enough   to   design   them   for   trustworthiness   when   they   operate   normally.   We   must   think   in   terms   of  
providing   maximum   required   func-onality,   ouen   called   Quality   of   Service,   taking   into   account   that   the  
System  will  not  always  have  all  its  Resources  available.  This  is  more  in  line  with  the  way  biological  Systems  
work:  an  ant  colony  remains  an  ant  colony  even  if  a  fire  wipes  out  part  of  the  ant  popula-on.    
This  is  not  always  the  case  in  safety  engineering  prac-ces:  when  a  failure  is  detected  -­‐  and  this  can  be  one  
of  its  million  -ny  components,  the  System  will  either  shutdown  or  remain  opera-onal  in  an  ouen  severely  
degraded  mode,  or  either  coarse  grain  redundancy  will  be  used  to  keep  the  func-onality  at  its  original  level,  
but  a  next  failure  is  then  ouen  catastrophic.  
Resilience  engineering  works  differently.  It  will  look  for  architectures  that  can  tolerate  par-al  failures.  It  will  
not   seek   to   maintain   full   func-onality   but   will   seek   to   maintain   the   best   possible   func-onality   with   the  
Resources   available.   Resilient   Systems   have   ouen   architectures   that   are   very   modular   by   design   and   have   a  
redundant  but  distributed  capacity.  

 
The South Pole Station Dome (being deconstructed)

Altreonic NV From Deep Space To Deep Sea Page 13 _


Trustworthy Systems Engineering with GoedelWorks 3
A   simple   example   is   a   meshed   roof   construc-on.   The   roof   will   not   cave   in   because   some   rods   are   lost.  
Networked   Systems   (think   about   the   internet   of   a   mobile   communica-on   System)   ouen   also   work   this   way.  
In  the  control  engineering  domain  this  was  first  introduced  to  keep  Systems  stable  even  if  a  major  failure  
occurs.   Ouen   this   requires   running   a   simula-on   Model   in   the   control   loop.   Examples   are   flight   control  
Systems  that  control  the  plane  using  only  the  engines  when  for  example  parts  of  the  wings  are  damaged.  In  
general  a  resilient  system  will  be  designed  to  be  fault  tolerant  in  all  cases.  If  a  failure  is  detected  it  will  not  
simply  go  into  a  so-­‐called  safe  mode  (like  limi-ng  the  engine  to  1000  rpm  and  flashing  a  warning),  it  will  
retain  all  func-onality  but  with  less  redundancy  should  a  subsequent  failure  occur.  This  approach  is  ouen  
avoided   for   reasons   of   cost.   This   is   true   if   the   measures   are   applied   on   an   exis-ng   architecture.   A   well  
chosen  architecture  is  however  resilient  by  design  and  then  the  life  cycle  cost  can  even  be  lower.  
An   important   difference   with   more   classical   approaches   is   that   a   resilient   System,   besides   having   a   more  
resilient   architecture,   gracefully   adapts   itself   to   a   change   in   the   available   Resources.   It   will   not   fail  
immediately,   but   e.g.   recover   from   the   errors,   maybe   even   repair   itself,   rearrange   Resources   so   that   it  
remains   "alive".   Auer   all,   this   is   the   ul-mate   goal   of   any   System.     Recently,   systems   that   adapt   and   even  
become   be;er   auer   they   experience   issues   (a   general   term   for   anything   that   could   or   went   wrong)   have  
been  called  an--­‐fragile,  to  indicate  that  there  is  a  step  beyond  resilience.  We  will  explore  this  deeper  in  the  
chapter  on  the  ARRL  (Assured  Reliability  and  Resilience  Level)  criterion.


Altreonic NV From Deep Space To Deep Sea Page 14 _


Trustworthy Systems Engineering with GoedelWorks 3

2. Unified  Systems  Engineering  


In  this  chapter  we  outline  a  generic,  unifying  approach  to  systems  engineering.  Based  on  the  premise  that  
engineering  is  essen-ally  domain  independent  but  that  each  domain  applies  the  same  type  of  Process  Steps  
in  a  domain  specific  way.  

2.1. A  Process  as  a  System  


We  have  un-l  now  been  speaking  about  Systems  in  terms  of  something  physical  that  has  to  be  developed.  It  
answers  the  ques-on  of  "what"  is  it  that  we  need  to  develop.  In  Systems  engineering,  it  is  however  equally  
important   "how"   it   is   developed.   Therefore,   a   Systems   engineering   Project   has   two   main   types   of  
components:  the  Process  that  is  followed  and  the  development  Project  of  the  System  itself.  

 
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  

Altreonic NV From Deep Space To Deep Sea Page 15 _


Trustworthy Systems Engineering with GoedelWorks 3
souware  tools  like  the  compiler  must  be  qualified  first,  an  adequate  version  management  System  needs  to  
be  used,  coding  rules  need  to  be  obeyed,  peer  review  need  to  be  in  place,  etc.  The  la;er  aspect  also  hints  at  
a  third  component  that  defines  the  Project:  the  Work  Plan.  It  defines  when  the  different  Ac-vi-es  should  
be  executed  using  specified  Resources.      
Another   example   is   tes-ng   of   hardware.   Tes-ng   will   verify   that   the   System   and   its   component   meet   the  
Specifica-ons.   This   is   only   possible   if   the   tes-ng   happens   in   controlled   circumstances.   For   example,   the  
Specifica-ons  must  be  stable  and  approved,  the  test  set-­‐up  must  be  well  defined  and  repeatable  and  the  
test   procedure   must   be   defined.   The   tes-ng   will   produce   a   deliverable   as   well,   i.e.   the   test   report.   The   way  
to  see  this  is  that  the  tes-ng  Process  is  like  a  small  Project  that  requires  specific  Resources  and  produces  a  
specific  product,  the  test  report.  Hence,  one  can  see  that  a  Process,  in  casu  a  Systems  Engineering  Process  is  
also   a   System   that   needs   to   be   developed   first.   The   sub-­‐system   components   can   include   humans,  
equipment   or   simply   all   that   is   needed   to   produce   a   report,   but   it   remains   an   Ac-vity   that   must   be  
trustworthy.  
One  of  the  first  processes  to  be  developed  (and  imposed)  was  the  so-­‐called  waterfall  model.  It  imposes  a  
linear   process   flow   whereby   requirements   are   developed,   then   fed   into   development   auer   which   the  
system  is  tested  and  validated  to  see  if  it  meets  the  original  requirements.  While  correct  in  principle,  such  a  
rigid   process   rapidly   breaks   down   because   it   assumes   that   the   requirements   are   complete   and   perfect.  
Therefore  the  waterfall  model  was  made  more  itera-ve  by  introducing  feedback  and  verifica-on  steps  early.  
This  became  to  be  known  as  the  V-­‐model.  This  is  s-ll  one  of  the  best  models  as  it  equally  applies  for  very  
small   systems   and   with   very   small   steps.   Such   a   process   is   then   ouen   called   agile   or   itera>ve.   In   reality   any  
process  can  be  itera-ve  if  not  only  the  order  of  the  steps  is  considered  but  also  the  state  of  the  different  
process  en--es.  This  will  be  explored  further  when  discussing  the  GoedelWorks  dependency  rela-onships.    

2.2. Unified  Seman>cs  


As  we  have  seen  in  the  previous  sec-ons,  Systems  Engineering  touches  many  domains.  We  focused  on  the  
technical   ones,   but   there   are   more.   Systems   Engineering   starts   with   formula-ng   a   goal   and   that   involves  
management,  poli-cal,  societal,  financial  and  many  more  people.  The  first  ques-on  to  ask  is  whether  they  
all   speak   about   the   same   System.   Even   if   they   do,   their   perspec-ve   can   be   vastly   different.   The   second  
ques-on  is  whether  they  speak  the  same  language.  They  might  use  different  terms  to  talk  about  the  same  
thing  or  they  might  use  the  same  term  to  designate  a  different  
thing.  
Even  in  the  technical  domains  this  is  very  ouen  the  case.  This  
“… I don’t want to get is  because  terms  and  words  have  a  context  and  a  context  has  
bogged down in semantics history.   When   a   new   domain   emerges,   people   ouen   borrow  
causing problems”. terms  from  another  field  and  select  it  based  on  analogies.  Or  
the  word  might  have  its  origin  in  a  different  natural  language  
Pervez Musharaf and   is   then   erroneously   imported.   In   the   technical   domain,  
people   ouen   will   use   acronyms,   typically   not   understood   by  
newbies   in   the   field   but   also   it   might   happen   that   the   original  
meaning  of  the  acronym  was  lost  in  -me.  
This   is   an   essen-al   observa-on   for   Systems   Engineering.   As   we   have   seen,   the   scale   and   complexity   of  
Systems  Engineering  is  very  wide  and  it  is  obvious  that  it  involves  a  lot  of  communica-on  between  people  
coming  from  different  domains.  If  they  don't  understand  each  other,  how  can  they  then  develop  the  right  
System  and  do  it  right?  Let's  take  a  simple  example,  the  word  'scheduling'.  For  the  produc-on  engineer,  this  
means  the  order  in  which  a  product  is  produced  on  a  produc-on  line.  For  the  electronic  hardware  engineer,  
this  means  mapping  his  signals  correctly  in  the  clock  domain.  For  the  souware  engineer,  it  means  defining  
the   order   of   execu-on   of   souware   processes.   Moreover,   people   also   develop   a   sense   for   orders   of  
magnitude.  For  the  produc-on  engineer,  -me  might  be  measured  in  minutes.  For  the  souware  engineer,  it  

Altreonic NV From Deep Space To Deep Sea Page 16 _


Trustworthy Systems Engineering with GoedelWorks 3
is   likely   microseconds   or   milliseconds.   For   the   hardware   engineer,   it   is   more   likely   nano-­‐   or   picoseconds.  
When  each  of  them  says  'this  is  fast',  they  are  most  certainly  thinking  about  very  different  -me  intervals.  
The   same   applies   when   we   dig   into   the   details   of  
technical   Specifica-ons.   Consider   for   example  
communica-on   protocols.   Some   of   them   are   described  
requiring   1000's   of   pages.   How   sure   are   we   that   two  
devices  allegedly  speaking  the  same  protocol  will  never  
have   differences   in   their   protocol   implementa-on?   A  
single  -ny  difference  and  the  communica-on  can  hang.  
Another   example   are   processor   instruc-on   sets.   Most  
processors,   even   within   the   same   family,   will   have  
subtle   differences   and   will   use   different   terms.   And  
when   we   look   in   the   world   of   souware,   we   see   an  
explosion   of   terms,   interface   func-ons,   all   vaguely  
describing   the   same   things   but   with   obnoxious  
differences  and  side-­‐effects  when  using  them.    
What   above   examples   illustrate   is   that   in   Systems  
Engineering   it   is   not   sufficient   to   define   terms   and  
func-onali-es,   one   must   also   define   their   associated  
behaviour.   This   means   that   when   terms   and   language  
are   used   one   must   also   define   their   seman>cs   in   their  
context.   Moreover,   the   seman-cs   should   be   the   same  
everywhere.   We   call   this   "unified   seman>cs"   and   it  
results  in  two  main  benefits:  
Firstly,   unified   seman-cs   means   that   the   same   term   is  
used   in   a   unique   way   with   a   unique   meaning.   An  
important   consequence   is   that   overlapping   seman-cs  
must   be   avoided,   each   term   should   describe   a   well  
defined   and   unique   behaviour   or   property   of   the  
System.   This   is   linked   with   another   important   property  
that   is   beneficial   in   any   good   system   architecture:  
orthogonality.  Choosing  the  right,  orthogonal  terms  will  
ouen  help  in  finding  the  right  orthogonal  architecture.  
Secondly,   specifying   terms   and   concepts   in   a   correct  
way   is   an   important   first   step   in   Systems   engineering.  
The   reason   being   is   that   it   is   the   first   step   in  
formaliza>on.   One   can   compare   Systems   Engineering  
with   the   ac-vi-es   of   wri-ng   a   novel   composed   of  
sentences.  If  we  don't  want  to  have  gibberish  at  the  end,  we  must  agree  on  the  meaning  of  the  terms  and  
we  must  agree  on  gramma-cal  rules  on  how  to  construct  valid  sentences.  
The  meaning  of  the  terms  and  the  Grammar  rules  do  not  define  the  sentences  themselves.  They  define  a  
framework  that  is  more  abstract  than  the  sentences  we  will  formulate.  This  is  ouen  called  a  meta-­‐Model.  
We  ouen  use  the  term  System  Grammar  in  the  context  of  Systems  Engineering.  To  reduce  the  confusion,  in  
the   remainder   of   this   booklet   we   will   ouen   use   an   upper   case   le;er   to   designate   a   term   that   has   to   be  
understood  in  the  specific  meaning  of  the  system  grammar  detailed  further  on.  

Altreonic NV From Deep Space To Deep Sea Page 17 _


Trustworthy Systems Engineering with GoedelWorks 3

2.3. Interac>ng  En>>es  Seman>cs  


In   the   previous   sec-on   we   mainly   talked   about   behaviour   and   proper-es   of   a   System   and   why   it   is  
important   that   we   describe   these   in   a   unique   way.   The   behaviour   and   the   proper-es   of   a   System   are  
however  what  we  some-mes  call  'emerging  proper>es'.  While  a  System  can  be  composed  of  tens  or  even  
billions   of   composing   parts,   none   of   them   will   result   in   the   observed   behaviour   on   its   own.   It   is   all   the  
components  working  together  'in  concert'  that  are  responsible  for  the  behaviour.  At  a  more  abstract  level  
we  use  the  terms  'En>>es'  and  'Interac>ons'.  We  can  then  describe  the  structural  proper-es  of  a  System  as  
'Interac>ng  En>>es'.  How  they  fit  together  we  call  that  the  'architecture'.  Note  that  this  is  at  an  abstract  
level.   In   a   Process   for   example   En--es   can   be   humans   that   take   a   set   of   wri;en   Requirements   (another   set  
of   En--es)   and   transform   them   into   wri;en   Specifica-ons   (another   set   of   En--es).   The   Interac-ons   are  
‘reading',  'wri-ng'  and  likely  also  mee-ngs  during  which  the  Requirements  and  Specifica-ons  are  discussed.  
In  the  technical  domain,  En--es  and  Interac-ons  can  ouen  
be   iden-fied   in   a   more   concrete   way.   An   En-ty   will   be   a  
Wikipedia defines system as physical   component   (a   sub-­‐system)   and   an   Interac-on   will  
follows: be   a   concrete   exchange   of   informa-on,   obeying   much  
stricter   protocols   than   human   language   allows.   Note   that  
(from Latin systema) “whole
the   Interac-on   can   also   involve   transfer   of   materials     or  
compounded of several parts energy  (e.g.  a  hydraulic  pressure).  This  view  has  a  number  
or members. It is a set of of   benefits.   First   of   all   it   neatly   expresses   how   a   System   is  
interacting or interdependent composed  of  smaller  Systems,  etc.  Interac-ons  on  the  other  
entities forming an integrated hand   allow   us   to   use   a   component   without   needing   to  
whole.” know  all  its  internal  details.  It  is  sufficient  to  know  how  the  
Interac-on  is  defined.  Interac-ons  and  protocols  allow  us  to  

hide  the  inner  state  of  a  composing  En-ty,  even  the  way  it  
System characteristics include: is   implemented,   without   jeopardising   the   way   the   System  
1. structure, will  behave.  
2. a set of behavioural norms, Referring  to  the  no-on  of  unified  seman-cs  in  the  previous  
3. interconnectivity and sec-on,  one  can  see  that  there  is  a  benefit  to  keep  this  view  
4. units that function of  a  System  as  a  set  of  En--es  and  Interac-ons  consistent  
independently within the in   all   phases   of   the   Systems   Engineering   Process.  
Concretely,   it   pays   off   to   map   Requirements   and  
system
Specifica-ons   fairly   orthogonally   to   well   defined   En--es  
and   Interac-ons.   As   we   will   see   further,   these   are   the  
components   of   various   types   of   “Models”,   used   e.g.   for  
simula-on,   formal   verifica-on,   architec-ng,   etc.   Hence,   it   will   be   beneficial   that   all   these   Models   have  
similar   seman-cs.   For   the   implementa-on   this   means   that   we   should   be   targe-ng   a   concurrent,   event-­‐
driven  programming  model  and  that  even  the  hardware  should  facilitate  this  kind  of  programming  model.  
Simula-on  models  are  for  example  ouen  based  on  large  system  loops  (convenient  for  simula-on)  but  this  
ouen   means   that   such   simula-on   code   is   not   easily   translated   into   a   concurrent,   or   even   distributed  
program.  This  also  makes  such  code  less  portable.  The  same  applies  for  Formal  Models  that  ouen  rely  on  
the   no-on   of   a   global   state   machine.   Again   that   might   be   convenient   for   verifica-on,   but   not   what   the  
souware  needs.    

Altreonic NV From Deep Space To Deep Sea Page 18 _


Trustworthy Systems Engineering with GoedelWorks 3

2.4. A  unifying  model  for  Systems  Engineering  

 
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.  

Altreonic NV From Deep Space To Deep Sea Page 19 _


Trustworthy Systems Engineering with GoedelWorks 3

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

A simplified view of a systems engineering Project

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  

Altreonic NV From Deep Space To Deep Sea Page 20 _


Trustworthy Systems Engineering with GoedelWorks 3
engineering  we  select  en--es  and  define  how  they  interact  so  that  they  fulfil  the  required  proper-es.  This  
mapping  phase  can  be  seen  as  what  really  happens  when  we  develop  the  system.    Similarly,  when  execu-ng  
the   project,   then   the   different   Ac-vi-es   need   to   be   planned   in   -me.   We   call   this   the   Work   Planning,  
tradi-onal  the  domain  of  “Project  Planning”.  

2.6. An  informal  view  on  Systems  Engineering  with  GoedelWorks  


So,   how   do   we   go   about   "Engineering"   a   System?   The   first   ac-vity   to   perform   is   to   figure   out   what   the  
System  should  be  able  to  do.  This  is  ouen  called  Requirements  and  Specifica>ons  capturing.  Requirements  
will   be   collected   from   many   sources,   ouen   called   the   stakeholders.   Given   that   there   are   many   sources,   a  
first  challenge  will  be  to  make  sure  that  the  Requirements  are  well  understood.  Seman-cs  come  into  play  
but   also   correctness.   Words   can   be   very   vague   and   have   mul-ple   meanings.   The   first   stakeholder   is   the  
poten-al  user.  What  does  he  expect  the  System  to  deliver?  Other  stakeholders  can  be  people  with  different  
interests:   financial,   poli-cal,   technical,   produc-on   related,   etc.   Ouen   these   Requirements   will   act   like  
boundary  condi-ons.    
In   the   GoedelWorks   metamodel   we   strictly   dis-nguish   between   Requirements   and   Specifica-ons.  
Requirements  are  ouen  qualita-ve  in  nature  and  the  collected  Requirements  will  ouen  not  form  a  coherent  
set.   There   will   be   conflic-ng   Requirements,   nice-­‐to-­‐have   Requirements,   must-­‐have   Requirements   as   well   as  
Requirements  that  are  not  even  related  to  the  System  to  be  developed.  Ouen,  Requirements  will  not  be  a  
sufficient   base   for   the   engineering   ac-vi-es   to   start.   Therefore,   Requirements   must   be   quan-fied   and  
translated  into  concrete  Specifica>ons.  The  Requirement  might  say  "the  car  will  be  a  be;er  one  than  the  
compe-tor’s   model".   The   Specifica-on   will   give   concrete   numbers   like   speed,   accelera-on,   fuel  
consump-on,  capability,  etc.  Specifica-ons  cover  mul-ple  domains.  Most  Specifica-ons  will  only  cover  the  
func-onality   in   normal   opera-ng   condi-ons.   Other   Specifica-ons   will   cover   issues   of   tes-ng.   Important   but  
not   always   trivial   to   obtain   are   the   Specifica-ons   that   cover   the   cases   when   things   are   not   normal,   like  
component  failures  or  externally  introduced  failures  or  even  damages  to  the  System.      
Once   Specifica-ons   have   been   determined,   engineers   can   start   looking   for   possible   implementa-ons.   We  
call   this   the   Modelling   ac>vi>es   because   the   Process   is   itera-ve   and   mul-ple   Models   will   need   to   be  
developed.   Simula>on   Models,   including   souware   based   virtual   prototypes,   can   be   used   to   find   the   best  
possible  implementa-on,  but  they  play  an  important  role  in  verifying  the  soundness  of  the  Requirements  
and   Specifica-ons.   It   answers   ques-ons   like   “is   this   really   what   we   want?”   and   “what-­‐if-­‐   ques-ons”.   Formal  
Models  can  be  used  to  verify  and  prove  that  the  implementa-on  will  be  safe,  or  at  least  that  some  essen-al  
proper-es  can  be  guaranteed.  These  two  types  of  Models  can  ouen  be  developed  in  very  different  ways  and  
using   very   different   tools   than   the   implementa>on   Models.   It   can   be   beneficial   that   the   implementa-on  
Model  is  obtained  from  a  simula-on  Model  (as  it  avoids  a  transla-on  step)  but  not  always  (because  it  also  
limits  the  conceptual  views  on  the  System).  Many  people  might  not  consider  the  final  implementa-on  as  a  
Model,  but  the  reality  is  that  many  implementa-ons  can  meet  the  Specifica-ons.  Implementa-on  Models  
are  really  architectural  Models  as  they  define  how  the  System  is  structured.  This  is  where  the  En--es  and  
Interac-ons   come   into   play.   They   are   the   execu-on   seat   of   the   Specifica-ons   and   the   way   they   are  
structured  will  result  in  the  System's  behaviour  and  proper-es  as  specified.  
The   above   paragraphs   were   mainly   concerned   with   defining   and   implemen-ng   the   right   System   (the  
"what").  Engineering  however  is  also  about  the  "how"  to  get  there  and  how  to  do  that  in  the  right  way.  This  
is  related  to  the  Process  that  needs  to  be  followed  with  a  Process  being  composed  of  a  number  of  Steps  
that  should  be  followed.  In  a  concrete  Project,  these  Steps  become  the  Works  Packages,  each  having  their  
oxn   specific   Work   Plan.   A   concrete   Work   Plan   defines   how   the   resources   are   to   be   used   and   when.   In   a  
trustworthy  Systems  Engineering  Project,  this  entails  more  than  developing  the  System  and  its  components.  
As  we  have  seen  above,  part  of  the  work  is  to  collect  the  Requirements  and  Specifica-ons  and  to  make  sure  
they   are   complete   and   correct.   Regre;ably,   this   effort   is   not   always   explicitly   planned   for   whereas   research  
has  shown  that  incorrect  Requirements  and  Specifica-ons  are  the  most  prominent  cause  for  Projects  failing  

Altreonic NV From Deep Space To Deep Sea Page 21 _


Trustworthy Systems Engineering with GoedelWorks 3
Packages.  These  are  the  core  ac-vi-es  of  each  Project.  They  require  Resources,  Specifica-ons  as  input  and  
consist  of  sub-­‐Work  Packages  and  a  number  of  dis-nc-ve  Ac-vi-es,  ouen  designated  as  Tasks.  
The   work   starts   in   parallel   to   the   Requirements   and   Specifica-ons   Work   Package   to   collect   background  
informa-on   and   relevant   References.   A   good   Project   is   not   developed   in   the   void   and   should   avoid  
reinven-ng   the   wheel.   In   addi-on,   for   cer-fica-on   purposes   the   relevant   standards   should   be   made  
available,   databooks   collected,   etc.   Organisa-on   specific   rules,   procedures   and   Resources   must   also   be  
available.  We  call  such  informa-on  References.  These  are  strictly  speaking  not  part  of  the  Project,  but  can  
be  very  valuable  sources  of  informa-on.    
A   concrete   Systems   engineering   Project   will   start   with   Work   Package   ac-vi-es   that   verify   that   the  
organisa>on   itself   is   capable   of   execu-ng   and   suppor-ng   the   Project.   Is   the   right   Systems   Engineering  
culture   in   place?   Is   there   a   trustworthy,   cer-fied   quality   System?   How   is   Human   Resources   planning  
organised?   Not   all   these   ques-ons   need   to   have   a   fully   affirma-ve   answer   to   allow   Systems   Engineering.  
Small  and  lean  organisa-ons  can  produce  trustworthy  products  as  well.        
In  parallel  the  suppor>ve  Processes  need  to  be  verified.  Version  management,  configura-on  management,  
test   capabili-es,   documenta-on,   procurement   including   qualifica-on   procedures   for   acquiring   external  
components,  souware  tools,  or  subcontrac-ng,  etc.  should  be  in  place  before  the  Project  starts.  
The  major  work  is  the  development  itself.  The  first  work  to  be  done  is  to  carefully  analyse  the  Requirements  
and   the   general   context   in   which   the   System   will   be   used.   From   these   a   coherent   and   complete   set   of  
Specifica>ons  must  be  derived  from  the  Requirements.  Specifica-ons  are  related  to  the  use  of  the  System  
and  the  proper-es  it  must  have,  but  already  at  this  stage,  three  groups  of  Specifica-ons  must  be  completed.  
The   most   obvious   ones   are   the   "normal   case"   ones.   These   are   related   to   the   use   of   the   System   when  
everything   is   opera-onal   and   the   System   is   used   as   intended.   A   second   class   is   related   to   tes-ng,   called   the  
"test   cases".   These   must   be   specified   because   testability   will   impact   on   the   design.   For   example   test   points  
will  draw  extra  current  or  state  variables  and  parameters  need  to  be  logged,  requiring  extra  memory.    
The  third  group  is  the  most  difficult  one.  These  are  related  to  when  faults  or  malfunc-ons  occur.  We  call  
these   the   "fault   cases".   Finding   these   requires   a   careful   analysis,   ouen   called   de   HARA   (Hazard   And   Risk  
Analysis)  in  the  context  of  safety  engineering,  but  this  equally  applies  to  security  related  faults.  This  step  
will   try   to   develop   the   general   hazard   and   fault   Models   for   the   System   (called   Safety   or   Security   Cases),  
resul-ng   in   Specifica-ons   for   the   System   to   mi-gate   or   even   annihilate   the   effects   of   the   hazard   and   faults.  
In   principle   this   step   has   to   be   done   independently   from   the   implementa-on   while   these   Specifica-ons  
must   be   available   before   any   development   or   architecture   is   defined.   This   is   because   they   can   have   an  
important  impact  on  the  implementa-on  and  its  architecture,  especially  if  the  consequences  of  failures  or  
security   breaches   are   severe.   Once   an   implementa-on   has   been   decided   upon,   we   also   need   to   inves-gate  
the   effects   of   faults   in   any   of   the   components.   This   ac-vity   is   ouen   called   a   FMEA   (Failure   Mode   Effect  
Analysis)   and   is   complementary   to   the   HARA   described   above.   Such   analyses   lead   to   pre-­‐condi-ons   in  
terms  of  the  quality  and  reliability  of  the  components  and  the  produc-on  process  (to  reduce  the  risks  up  
front)   but   are   needed   to   assure   and   assess   the   required   behaviour   when   hazards   and   faults   occur.     The  
careful  reader  will  have  no-ced  that  above  analysis  reflects  the  ARRL  criterion  we  discussed  in  the  previous  
chapter.  
Once  development  can  start,  each  Work  Package  will  produce  one  or  more  so-­‐called  Work  Products.  They  
are  well  defined  deliverables  and  implement  the  Specifica-ons.  We  can  divide  these  Works  Products  in  two  
large  groups.  The  first  group  contains  the  physical  resul-ng  Items  of  the  development  done  and  together  
they   cons-tute   the   System   being   developed.   The   other   set   of   outputs   are   related   to   the   Process  
requirements.  They  carry  the  contract  that  comes  with  the  WorkProducts  in  terms  of  documented  evidence  
that  the  Process  was  followed.  We  call  these  Artefacts.  
For  this  to  happen  the  Work  Package  will  need  Resources  (people,  equipment,  templates,…)  and  each  Work  
Package   will   be   composed   of   a   generic   set   of   Tasks.   These   can   be   grouped   in   the   following   seven   Ac-vi-es,  
each  consis-ng  of  smaller  phases.  

Altreonic NV From Deep Space To Deep Sea Page 22 _


Trustworthy Systems Engineering with GoedelWorks 3
be  executed  in  an  itera>ve  and  incremental  way  (some-mes  called  an  agile  process  although  the  term  agile  
is   not   free   from   religious   fac-onism).   This   provides   early   feedback   allowing   finding   issues   early   on.   The  
metamodel   however   expresses   completeness   and   defines   dependency   rela-onships.   The   Engineering  
Process  executed  in  a  Project  is  very  much  one  of  Refinement  and  Decomposi>on  whereby  we  gradually  
come  closer  to  a  final  realisa-on.    
At  every  moment  decisions  are  taken  and  at  every  moment  these  decisions  must  be  confirmed  to  be  the  
right   ones.   Hence   the   metamodel   does   not   express   an   absolute   order   in   -me   for   the   Ac-vi-es   but   a   par-al  
order   in   -me   of   confirmed   decisions.   The   Refinement   and   Decomposi-on   Process   however   creates   a  
dependency  graph  and  hence  imposes  a  strict  order  in  which  the  different  Project  En--es  can  be  approved.  
Similarly,   a   strict   control   of   the   configura-on   is   needed   as   well.   Whenever   a   cons-tuent   En-ty   in   the  
dependency  chain  is  changed,  it  might  violate  one  of  the  dependency  rela-onships  or  introduce  unwanted  
side-­‐effects.    Hence,  a  Project  configura-on  is  not  just  the  collected  en--es  at  a  given  point  in  -me,  but  a  
complete  graph.  Before  the  last  en-ty  has  been  approved,  this  graph  might  not  be  coherent.  For  example,  it  
might   have   missing   en-ty   nodes,   missing   dependency   or   decomposi-on   links   and   en--es   that   are   in   the  
process  of  being  developed.    
Hence  strict  configura-on  management  is  a  must.  Note  that  it  applies  as  well  to  the  composing  En--es  of  a  
system   as   well   as   to   how   these   En--es   interact.   It   also   applies   to   the   composing   Ac-vi-es   in   a   Work  
Package.  If  any  of  these  is  changed  auer  being  approved,  then  all  depending  Ac-vi-es  and  En--es  need  to  
be  reviewed  before  they  can  be  approved  again.    
GoedelWorks  allows  to  generate  automa-cally  the  dependency  and  precedence  graph  for  any  Project  En-ty  
and   hence   also   makes   it   easy   to   use   these   graphs   for   execu-ng   an   impact   analysis   when   for   example   a  
Requirement  or  Specifica-on  was  changed  or  when  a  change  is  considered.  The  same  feature  makes  it  easy  
to  e.g.  verify  the  completeness  and  coherency  of  a  Project.  For  example,  if  a  Specifica-on  has  no  dependent  
Test  Ac-vity,  then  we  know  that  the  system  cannot  be  approved  as  being  in  its  final  configura-on.  

2.6.1. Real  engineering  is  Process  of  iterations  

The Iterative nature of a project is more pronounced in the beginning

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  

Altreonic NV From Deep Space To Deep Sea Page 23 _


Trustworthy Systems Engineering with GoedelWorks 3
the  Project  that  developed  it  as  well  as  by  the  Process  that  was  used.  As  we  have  seen,  a  Process  is  also  a  
System  and  it  requires  the  same  steps  for  developing  it  in  a  Project.  To  illustrate  this,  consider  the  tes-ng  
ac-vi-es.   They   will   follow   a   test   plan,   developed   according   to   a   template   prescribed   by   the   test   Process.  
Developing   a   test   plan,   even   as   a   template,   requires   the   same   steps   as   we   described   above   (Requirements,  
Specifica-ons,  Development,  Verifica-on,  Tes-ng,  Valida-on,  ...).  The  Work  Product  is  a  test  plan  template,  
that  is  subsequently  is  used  as  a  Resource  for  a  Work  Package  whereby  the  test  plan  is  a  template  and  filled  
in  specifically  for  the  System  or  System  component  to  be  tested.  This  instance  of  the  test  plan  then  becomes  
a  Resource  for  the  real  Test  Tasks  to  be  done  on  the  Work  Product  in  Development.  Similarly,  when  a  System  
uses   components,   procured   from   an   external   or   internal   party,   this   becomes   a   Resource   for   the  
development  whereas  the  component  was  first  developed  in  a  previous  Project.  Therefore  one  can  see  that  
Systems   engineering   is   not   an   isolated   ac-vity.   In   the   bigger   scheme   of   things,   each   Project   will   have   its  
place  in  a  culture  and  environment  with  a  history  and  itself  will  give  direc-on  to  future  Projects.  
Another  aspect  is  that  Systems  engineering  as  described  above  seems  to  follow  a  sequence,  a  Flow  from  
beginning  to  end.  Viewed  from  a  distance  this  is  true.  A  good  Engineering  Project  will  know  that  for  example  
Requirements  are  never  really  "final".  Feedback  from  Development,  Tes-ng,  etc.  will  detect  weaknesses  in  
the   Requirements   and   Specifica-ons   and   hence   the   la;er   might   need   to   be   adjusted.   Once   Development   is  
done  and  Valida-on  was  approved,  most  likely  the  Systems  will  not  exactly  meet  all  Specifica-ons  due  to  
small   varia-ons   introduced   during   Development,   uncertain-es   on   design   parameters   and   System  
components   acquired   from   elsewhere.   Determining   the   final   values   is   called   characteriza-on   (because   it  
specifies  a  specific  instance  of  the  System  that  was  developed).  

2.6.2. Traceability  and  configuration  management    


If  nothing  is  final  and  if  the  order  of  execu-ng  the  different  Steps  and  Ac-vi-es  is  itera-ve,  how  can  we  then  
arrive   at   a   System   that   can   be   validated?   The   way   to   reach   this   goal   is   state   configura>on   management.   As  
the  a;en-ve  reader  will  have  seen,  the  Flow  imposes  a  dependency  chain.  Actually  mul-ple  ones,  one  for  
each   Work   Product   back   to   the   original   Specifica-ons   and   Requirements   and   then   addi-onal   ones   for  
Integra-on  and  Valida-on.  The  final  System  can  only  be  approved  (released  for  produc-on  or  deployment)  
if   all   preceding   Ac-vi-es,   intermediate   Processes   and   Project   En--es   had   been   approved   before.   This   is  
necessary  for  two  main  reasons.      First  of  all,  the  configura-on  of  the  System  must  be  consistent  to  allow  
Valida-on  and  Cer-fica-on.  Else,  we  would  have  many  uncertain-es.  But,  secondly  it  will  save  a  lot  of  effort  
and  Resources.  For  example,  if  Tes-ng  is  done  before  Verifica-on  is  done,  it  is  very  likely  that  Tes-ng  will  not  
just  find  func-onal  errors,  but  simple  errors  due  to  some  of  the  Development  not  being  done  according  to  
the  specified  Process  (simple  example:  a  wrong  name  was  used  for  a  variable).      
The  most  important  state  transi-on  is  when  a  Project  En-ty  goes  from  e.g.  "in  work"  to  "approved".  At  that  
moment,   its   configura-on   must   be   frozen.   But   because   there   is   a   precedence   chain,   it   creates   a   par-al  
order  of  the  approval  steps  to  be  taken  for  developing  the  Work  Product.  This  is  the  key  to  allow  concurrent  
engineering   on   the   different   Work   Products   (Process   artefacts,   System   components).   One   can   work   on  
anything  in  parallel,  but  approving  en--es  can  only  be  done  in  the  order  specified  in  the  dependency  graph.  
It   also   means   that   the   architecture   of   System   will   allow   more   concurrent   engineering   and   development  
when  it  is  itself  decomposed  in  concurrent  En--es  with  well  defined  Interac-ons.  This  is  a  key  observa-on  
for   what   is   called   today   "evolu>onary"   valida-on   and   cer-fica-on.   Today   many   Projects   are   related   to  
families   of   products   and   ouen   changing   one   part   will   create   a   new   member   of   the   product   family.   If   the  
architecture   is   not   sufficiently   modular   and   concurrent,   then   the   whole   System   must   be   re-­‐cer-fied   (re-­‐
verified,   re-­‐tested,   re-­‐integrated   and   re-­‐validated).   With   a   concurrent   architecture,   this   work   can   be  
reduced,  although  never  fully  eliminated.  


Altreonic NV From Deep Space To Deep Sea Page 24 _


Trustworthy Systems Engineering with GoedelWorks 3

3. Engineering  real  systems  that  can  fail  


The  a;en-ve  reader  will  have  no-ced  that  engineering  a  trustworthy  system  is  much  more  than  an  error  
and  trial  process.    While  experience  is  a  valuable  asset,  following  a  systema-c  approach  can  help  in  reducing  
the  residual  errors  and  hence  will  increase  the  trust  one  can  have  in  the  system.  As  such,  this  remains  vague  
on  what  this  means  in  the  context  of  situa-ons  whereby  faults  or  hazards  occur  and  the  trust  in  the  system  
performing   as   intended   can   be   lost.   What   we   no-ced   is   that   while   safety   and   engineering   standards  
emphasise   the   process   to   be   followed,   they   are   ouen   specific   for   a   given   system.   Very   li;le   is   said   about  
how   this   applies   to   other   systems,   even   if   they   reuse   many   of   the   same   components.   The   result   was   the  
elabora-on  of  the  ARRL  (Assured  Reliability  and  Resilience  Level)  criterion.    
The   Assured   Reliability   and   Resilience   level   criterion   is   introduced   to   be   able   to   classify   components   and  
systems  according  to  the  way  they  can  be  trusted,  especially  in  the  context  of  fault  behaviour.  This  chapter  
can  be  read  independently  from  the  other  chapters  but  it  gives  a  mental  framework  that  helps  to  come  to  a  
systema-c  way  of  engineering  trustworthy  systems  and  products.  

3.1. ARRL:  the  Assured  Reliability  and  Resilience    Level  criterion    


Systems   engineering   aims   at   developing   systems   that   meet   the   requirements   and   constraints   of   its  
stakeholders.   Increasingly   systems   must   not   only   provide   their   intended   func-onality,   but   it   must   also   be  
guaranteed   in   a   cer>fiable   way   that   such   systems   remain   safe   (and   secure)   when   subjected   to   faults   or  
hazardous  situa-ons.    
From   the   safety   point   of   view,   the   lower   the   required   residual   risks   should   be,   the   higher   the   safety   related  
requirements,  ouen  expressed  as  SIL  (Safety  Integrity  Levels).  The  same  applies  for  the  subsystems  whose  
faults  can  induce  a  safety  risk.    
We   have   argued   before   [1,2,3]   that   this   view   is   rather   narrow.   In   reality   what   ma;ers   is   how   much   the  
stakeholders  (including  the  users)  consider  the  system  as  trustworthy  whereby  safety  is  one  of  the  specified  
proper-es.  Similarly,  what  a  user  expects  is  a  guaranteed  QoS  (Quality  of  Service)  level.  Depending  on  the  
level,   it   guarantees   that   the   system   will   be   able   to   deliver   its   intended   func-onality   even   if   faults   occur.  
Hence,  the  ul-mate  case  is  one  whereby  the  system  survives  faults.  As  this  criterion  is  very  wide,  this  led  to  
the  introduc-on  of  a  novel  more  norma-ve  criterion,  called  ARRL  (Assured  Reliability  and  Resilience  Level)  
that  differen-ates  between  the  failure  condi-ons  and  how  the  system  coops  with  it.  
Depending   on   the   severity   of   the   fault   scenario   and   the   desired   con-nuity   of   the   system’s   func-ons   this  
requires   increasingly   higher   levels   of   ARRL.   In   tradi-onal   systems   engineering,   the   con-nua-on   of   the  
services   is   achieved   by   reconfiguring   the   architecture   and   by   redundancy.   The   ques-on   is   whether   this   is  
sufficient  or  a  necessary  condi-on  to  reach  the  novel  property  of  an>fragility  [10].  Before  we  answer  the  
ques-on,  we  recapitulate  the  exis-ng  no-ons  of  SIL,  QoS  and  ARRL  

3.2. Overview  of  exis>ng  criteria  in  the  domain  of  trustworthiness  

3.2.1. Safety  Integrity  Level  


We   consider   first   the   IEC   61508   standard   [4],   as   this   standard   is   rela-vely   generic.   It   considers   mainly  
programmable   electronic   systems.   The   goal   is   to   bring   the   risks   to   an   acceptable   level   by   applying   safety  
func-ons.  IEC  61508  starts  from  the  principle  that  safety  is  never  absolute;  hence  it  considers  the  likelihood  
of  a  hazard  (a  situa-on  posing  a  safety  risk)  and  the  severity  of  the  consequences.  A  third  element  is  the  
controllability.   The   combina-on   of   these   three   factors   is   used   to   determine   a   required   SIL   (Safety   Integrity  
Level),  categorised  in  4  levels,  SIL-­‐1  being  the  lowest  and  SIL-­‐4  being  the  highest.  These  levels  correspond  
with  norma-ve  allowed  Probabili-es  of  Failure  per  Hour  and  require  corresponding  Risk  Reduc-on  Factors  

Altreonic NV From Deep Space To Deep Sea Page 25 _


Trustworthy Systems Engineering with GoedelWorks 3
that  depend  on  the  usage  pa;ern  (infrequent  versus  con-nuous).  The  risk  reduc-on  itself  is  achieved  by  a  
combina-on   of   reliability   measures   (higher   quality),   func-onal   measures   as   well   as   assurance   from  
following  a  more  rigorous  engineering  process.  The  safety  risks  are  generally  classified  in  4  classes,  roughly  
each  corresponding  with  a  required  SIL  level  whereby  we  added  a  SIL-­‐0  for  completeness.  It  must  be  said  
however  that  the  standards  allow  quite  some  room  for  interpreta-on,  in  par-cular  when  it  comes  to  the  
use  of  probabili-es  and  assessment  of  the  controllability  factor.  

Safety  Risk  Classifica>on


Category Typical  SIL Consequence  upon  Failure
Catastrophic 4 Loss  of  mul-ple  lives
Cri-cal 3 Loss  of  a  single  life
Marginal 2 Major  injuries  to  one  or  more  persons
Negligible 1 Minor  injuries  at  worst  of  material  damage  only
No  Consequence 0 No  damages,  except  user  dissa-sfac-on

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.    

3.2.2. Quality  of  Service  Levels  


A  system  that  is  being  developed  is  part  of  a  larger  system  that  includes  the  user  (or  operator)  as  well  as  the  
environment  in  which  the  system  is  used.  Note  as  well  that  this  is  a  hierarchical  no-on.  A  system  can  be  a  
subsystem  or  a  component  in  a  large  system  and  can  also  include  services  and  processes  that  support  the  
final  mission  of  a  system.      
From  the  user’s  point  of  view,  the  system  must  deliver  an  acceptable  and  predictable  level  of  service,  which  
we  call  the  Quality  of  Service  (QoS).  A  failure  in  a  system  is  not  seen  as  an  immediate  risk  but  rather  as  a  
breach  of  contract  on  the  QoS  whereby  the  system’s  malfunc-on  can  then  result  in  a  safety  related  hazard  
or  loss  of  mission  control,  even  when  no  safety  risks  are  present.  As  such  we  can  see  that  a  given  SIL  is  a  
subset  of  the  QoS.  The  QoS  can  be  seen  as  the  availability  of  the  system  as  a  resource  that  allows  the  user’s  
expecta-ons  to  be  met.    

Quality  of  Service


QoS-­‐1 There   is   no   guarantee   that   there   will   be   resources   to   sustain   the   service.   Hence   the   user  
should   not   rely   on   the   system   and   should   consider   it   as   untrustworthy.     When   using   the  
system,  the  user  is  taking  a  risk  that  is  not  predictable
QoS-­‐2 The   system   must   assure   the   availability   of   the   resources   in   a   sta-s-cally   acceptable   way.  
Hence,   the   user   can   trust   the   system   but   knows   that   the   QoS   will   be   lower   from   -me   to   -me.  
The  user’s  risk  is  mostly  one  of  annoyance  and  dissa-sfac-on  or  of  reduced  service.
QoS-­‐3 The  system  can  always  be  trusted  to  have  enough  resources  to  deliver  the  highest  QoS  at  all  
-mes.  The  user’s  risk  is  considered  to  be  negligible.

Altreonic NV From Deep Space To Deep Sea Page 26 _


Trustworthy Systems Engineering with GoedelWorks 3
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  an>fragility  further  in  this  text.    

3.3. The  ARRL  criterion  


We   introduce   the   ARRL   or   Assured   Reliability   and   Resilience   Level   to   guide   us   in   composing   safe   and  
trustworthy   systems.   The   different   ARRL   classes   are   defined   in   Table   3.   They   are   mainly   differen-ated   in  
terms  of  how  much  assurance  they  provide  in  mee-ng  their  contract  in  the  presence  of  faults.  The  reader  
should  keep  in  mind  that  the  term  component  can  also  be  a  (sub)-­‐system  or  system  ac-ng  as  components  in  
a  larger  system.  
We  should  men-on  that  there  is  an  implicit  assump-on  about  a  system’s  architecture  when  defining  ARLL.  
A  system  is  composed  by  defining  a  set  of  interac-ng  components.  This  has  important  consequences:  
• The  component  must  be  designed  to  prevent  the  propaga-on  of  errors.  Therefore  the  interfaces  must  
be   clearly   iden-fiable   and   designed   with   a   “guard”.   These   interfaces   must   also   be   the   only   way   a  
component   can   interact   with   other   components.   The   internal   state   is   not   accessible   from   another  
component,  but  can  only  be  made  available  through  a  well-­‐defined  protocol  (e.g.  whereby  a  copy  of  the  
state  is  communicated).  
• The   interac>on   mechanism,   for   example   a   network   connec-on,   must   carry   at   least   the   same   ARRL  
creden-als  as  the  components  it  interconnects.  Actually,  in  many  cases,  the  ARLL  level  must  be  higher  if  
one  needs  to  maintain  a  sufficiently  high  ARRL  level  at  the  level  of  the  (sub)-­‐system  composed  of  the  
components.  
• Hence,   it   is   be;er   to   consider   the   interface   as   a   component   on   itself,   rather   than   for   example   assuming  
an  implicit  communica-on  between  the  components.  

Altreonic NV From Deep Space To Deep Sea Page 27 _


Trustworthy Systems Engineering with GoedelWorks 3

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.4. Is  this  sufficient  for  an>fragility?  


The   norma-ve   ARRL   levels   describe   as   the   name   says,   levels   of   reliability   and   resilience.   They   approach   the  
no-on   of   graceful   degrada-on   by   redundancy   but   assuming   that   in   absence   of   faults   the   system  
components  can  be  considered  as  error-­‐free.  The  addi-onal  func-onality  and  redundancy  (that  is  also  error-­‐
free)  is  to  be  seen  as  an  architectural  or  process  level  improvement.  But  in  all  cases,  contrary  to  the  an--­‐
fragility   no-on,   the   system   will   not   gain   in   resilience   or   reliability.   It   can   merely   postpone   catastrophic  
failures   while   maintaining   temporally   the   intended   services.   It   does   this   by   assuming   that   all   types   of   faults  
can  be  an-cipated,  which  would  be  the  state  of  the  art  in  engineering.  

3.4.1. Antifragility  assumptions  


However,   the   proposed   scheme   introduces   already   two   concepts   that   are   essen-al   to   take   it   a   step   further.  
Firstly,   there   is   redundancy   in   architecture   and   process   and   secondly,   there   is   a   monitoring   func-on   that  
acts  by  reconfiguring  the  system  upon  detec-ng  a  fault.  
So,  how  can  a  system  become  “be;er”  when  subjected  to  faults?  As  we  introduce  a  metric  as  a  goal,  we  
must  somehow  measure  and  introduce  feedback  loops.  If  we  extrapolate  and  scale  up,  this  assumes  that  
the   system   has   a   type   of   self-­‐model   that   it   can   use   to   compare   its   current   status   with   a   reference   goal.  
Hence,   either   the   designer   must   encapsulate   this   model   within   the   system   or   the   model   is   external   and  
becomes  part  of  the  system.  If  we  consider  systems  that  include  their  self-­‐model  from  the  start,  then  clearly  
becoming  a  “be;er”  system  has  its  limits,  the  limit  being  the  designers’s  idea  at  the  moment  of  concep-on.  
While   there   are   systems   that   evolve   to   reach   a   be;er   op-mum   (think   about   neural   networks   or   gene-c  
algorithms),  these  systems  evolve  towards  a  limit  value.  In  other  words  they  do  not  evolve,  they  converge.    

Altreonic NV From Deep Space To Deep Sea Page 28 _


Trustworthy Systems Engineering with GoedelWorks 3
If  on  the  other  hand  we  expand  the  system  as  in  Figure  1,  then  the  system  can  evolve.  It  can  evolve  and  
improve   because   we   consider   its   environment   and   all   its   stakeholders   of   which   the   users   as   part   of   the  
system.  They  con-nuously  provide  informa-on  on  the  system’s  performance  and  take  measures  to  improve  
upon  it.  It  also  means  that  the  engineering  process  doesn’t  stop  when  the  system  has  been  put  to  use  for  
the  first  -me.  It  actually  never  ends  because  the  experience  is  transferred  to  newer  designs.  
There   are   numerous   examples   of   an-fragile   systems   already   at   work,   perhaps   not   perfect   all   the   -me  
though   most   of   the   -me.   A   prime   example   is   the   avia-on   industry   that   demonstrates   by   its   yearly  
decreasing  number  of  fatali-es  and  quality  of  service  that  it  meets  the  criterion  of  an-fragility.  Moreover,  it  
is   a   commercial   success.   So   let’s   examine   some   of   its   proper-es   and   extract   the   general   principles,   as  
reflected  in  the  avia-on  standards  and  prac-ce  [6].  

Lessons  to  be  learned  from  avia>on  safety


Avia-on  specific Generic  property
The  industry  has  a  long  track  record         The  domain  has  undergone  many  technological  
changes  whereby  an  extensive  knowledge  was  built  
up.
Development  of  systems  follows  a  rigorous,   The  process  is  open  and  reflects  the  past  
quan-fiable,  cer-fiable  process,  that  is  widely   experience  and  is  cer-fied  by  an  independent  
published  and  adopted. external  authority.
Cer-fica-on  and  Qualifica-on  requirements  foster   Systems  are  designed  to  be  transparent  and  simple,  
developing  “minimal”  implementa-ons  that  s-ll   focusing  on  the  must-­‐haves  and  not  on  the  nice  to  
meet  the  opera-onal  requirements. haves.
Airplanes  are  designed  to  be  100%  safe  and  to  be   Any  devia-on  is  considered  a  failure  that  must  be  
operated  in  100%  safe  condi-ons.  The  domain  has  a   corrected.  By  design  the  system,  its  components  
goal  of  perfec-on. and  opera-ng  procedures  aim  at  absence  of  service  
and  safety  degrada-on.
Any  failure  is  reported  in  a  public  database  and   Any  issue  is  seen  as  a  valuable  source  of  
thoroughly  analysed. informa-on  to  improve  processes  and  systems.
Airplanes  are  operated  as  part  of  a  larger   A  (sub)system  is  not  seen  in  isola-on  but  in  its  
worldwide  system  that  involves  legal  authori-es,   complete  socio-­‐economic  context.  This  larger  
the  operators,  the  manufactures,  the  public  and   system  is  self-­‐regula-ng  but  supervised  and  
supervising  independent  authori-es. controlled  by  an  independent  authority.
Airplanes  have  a  long  life  -me  and  undergo  mid-­‐life   The  focus  is  on  the  service  delivered  and  not  on  the  
updates  to  maintain  their  serviceability system  as  a  final  product.
Fault    condi-ons  are  preven-vely  monitored.  The   A  process  is  in  place  that  maintains  the  state  of  the  
system  is  fault  tolerant  through  redundancy,   system  at  a  high  service  level  without  disrup-ng  the  
immediate  repair  and  preven-ve  maintenance. services  provided.

3.4.2. Some  industries  are  antifragile  by  design    


To   remain   synop-c,   we   will   list   a   few   key   principles   of   the   avia-on   industry   and   derive   from   them   key  
generic  principles  which  apply  to  other  systems  and  provide  them  with  an-fragile  proper-es.  
Table  4  can  also  be  related  to  many  other  domains  that  have  a  significant  societal  importance.  Think  about  
sectors  like  medical  devices,  railway,  automo-ve,  telecommunica-ons,  internet,  nuclear,  etc.  They  all  have  
formalised   safety   standards   which   must   be   adhered   to   because   when   failing   they   have   a   high   impact   at  
socio-­‐economic  level.  

Altreonic NV From Deep Space To Deep Sea Page 29 _


Trustworthy Systems Engineering with GoedelWorks 3
At   the   same   -me,   systems   like   railway   that   are   confined   by   na-onal   regula-ons   clearly   have   a   higher  
challenge  to  con-nue  delivering  their  services  at  a  high  level.  As  a  counter  example  we  can  take  a  look  at  
the  automo-ve  sector.  Many  more  people  are  killed  yearly  in  traffic  than  in  airplanes,  even  if  cars  today  are  
stuffed  with  safety  func-ons.  In  the  next  sec-on  we  will  explore  this  more  in  detail.  
Deduc-ng   some   general   proper-es   out   of   the   table   4,   we   can   see   that   systems   that   could   be   termed  
an-fragile  are  first  of  all  not  new.  Many  systems  have  an-fragile  proper-es.  Ouen  they  can  be  considered  as  
complex  (as  there  are  many  components  in  the  system)  but  they  remain  resilient  and  an-fragile  by  adop-ng  
a  few  fundamental  rules:  
• Openness:  all  service  cri-cal  informa-on  is  shared  and  public.  
• Constant  feedback  loops  between  all  stakeholders  at  several  different  levels.  
• Independent  supervising  authori>es.  
• The  core  components  are  designed  at  ARRL-­‐4  and  ARRL-­‐5  levels,  i.e.  fault  tolerant.  

3.4.3. Do  we  need  an  ARRL-­‐6  and  ARRL-­‐7  level?  


An  ARRL-­‐5  system  can  be  seen  as  a  weak  version  of  a  resilient  system.  While  it  can  survive  a  major  fault,  it  
does  so  by  dropping  into  an  ARRL-­‐4  mode.  The  next  failure  is  likely  catastrophic.  However  airplanes  are  also  
designed   as   part   of   a   larger   system   that   helps   to   prevent   reaching   that   state.   Con-nuous   build-­‐in-­‐test  
func-ons   and   diagnos-cs   will   detect   failures   before   they   become   a   serious   issue.   Ground   crews   will   be  
alerted   over   radio   and   will   be   ready   to   replace   the   defec-ve   part   upon   arrival   at   the   next   airport.   We   could  
call  this  the  ARRL-­‐6  level  whereby  fault  escala-on  is  constrained  by  early  diagnos-cs,  monitoring  and  the  
presence   of   a   repair   process   that   maintains   the   opera-onal   status   at   an   op-mal   level.   Note   that   in   large  
systems  like  server  farms  and  telecommunica-on  networks  similar  techniques  are  used.  Using  monitoring  
func-ons   and   hot-­‐swap   capability   on   each   of   the   1000’s   of   processing   nodes,   such   a   system   can   reach  
almost  an  infinite  life-me  (economically  speaking).  Even  the  technology  can  be  upgraded  without  having  to  
shut  down  the  system.    
The  la;er  example  points  us  in  the  direc-on  of  what  a  norma-ve  ARRL-­‐7  level  could  be.  It  is  a  level  whereby  
the   system   is   seen   as   a   component   in   a   larger   system   that   includes   a   con-nuous   monitoring   and  
improvement   process.   The   later   implies   a   learning   process   as   well.   The   avia-on   industry   seems   to   have  
reached  this  maturity  level.  The  term  maturity  is  no  coincidence,  it  reminds  of  the  maturity  levels  as  defined  
by  CMMI  levels  for  an  organisa-on.  The  table  below  summarises  the  new  ARRL  levels  whereby  we  remind  
the  reader  that  each  ARRL  level  inherits  the  proper-es  of  the  lower  ARRL  levels.  

ARRL-­‐6  and  7  defini>ons


ARRL-­‐6 The  component  (or  subsystem)  is  monitored  and  designed  for  preven-ve  maintenance  
whereby  a  suppor-ng  process  repairs  or  replaces  defec-ve  items  while  maintaining  the  
func-onality  and  system’s  services.  
ARRL-­‐7                     The  component  (or  subsystem)  is  part  of  a  larger  “system  of  systems”  that  includes  a  
con-nuous  monitoring  and  improvement  process  supervised  by  an  independent  
regula-ng  body.

3.5. Automated  traffic  as  an  an>fragile  ARRL-­‐7  system  


As  we  discussed  earlier  [1,  2,  3,  5],  the  automo-ve  sector  does  not  yet  meet  the  highest  ARRL  levels  as  well  
as   in   the   safety   standards   (like   IEC-­‐26262)   [7]   and   in   reality   (1000   more   people   are   killed   in   cars   than   in  
airplanes  worldwide  and  even  a  larger  number  survive  with  disabili-es)[8,9,11].  The  main  reason  is  not  that  
cars   are   unsafe   by   design   (although   fault   tolerance   is   not   supported)   but   because   the   vehicles   are   part   of   a  

Altreonic NV From Deep Space To Deep Sea Page 30 _


Trustworthy Systems Engineering with GoedelWorks 3
much  larger  traffic  system  that  is  largely  an  ad-­‐hoc  system.    Would  it  be  feasible  to  reach  a  similar  ARRL  level  
as  in  the  avia-on  industry?  What  needs  to  change?  Can  this  be  done  by  allowing  autonomous  driving?  
A  first  observa-on  is  that  the  vehicle  as  a  component  now  needs  to  reach  ARRL-­‐4,  even  ARRL-­‐5  and  ARRL-­‐6  
levels.  If  we  automate  traffic,  we  might  be  able  to  take  human  errors  out  of  the  equa-on,  but  then  following  
design  parameters  become  crucial:  
• The   margin   for   driving   errors   will   greatly   decrease.   Vehicles   already   operate   in   very   dynamic   condi-ons  
whereby   seconds   and   cen-metres   make   the   difference   between   an   accident   and   not   an   accident.   With  
automated  driving,  bumper  to  bumper  driving  at  high  speed  will  likely  be  the  norm.  
• The   driver   might   be   a   back-­‐up   solu-on   to   take   over   when   systems   fail,   but   he   is   unlikely   to   be   well  
enough    trained  and  therefore  to  react  in  -me  (seconds).  
• A  failing  vehicle  can  generate  a  serious  avalanche  effect  whereby  many  vehicles  become  involved  and  
the  traffic  system  can  be  seriously  disrupted.  
• We   can   expect   that   the   psychological   acceptance   for   accidents   will   be   much   lower   for   when   the  
accident   was   caused   with   the   computer   at   the   steering   wheel   than   when   a   human   driver   is   at   the  
steering  wheel.    
Hence,   vehicles   need   to   be   fault   tolerant.   First   of   all   they   constantly   monitor   and   diagnose   the   vehicle  
components   to   prevent   pro-­‐ac-vely   the   failing   of   subsystems   and   secondly   when   a   failure   occurs   the  
func-on  must  be  maintained  allowing  to  apply  repair  in  a  short  interval.  
A  second  observa-on  is  that  the  automated  vehicle  will  likely  constantly  communicate  with  other  vehicles  
and   with   the   traffic   infrastructure.   New   vehicles   start   to   have   this   capability   today   as   well,   but   with  
automated  vehicles  this  func-onality  must  be  guaranteed  at  all  -mes  as  a  disrup-on  of  the  service  can  be  
catastrophic.  
A  third  observa-on  is  that  the  current  road  infrastructure  is  likely  too  complex  to  allow  automated  driving  in  
an  economical  way.  While  research  vehicles  have  been  demonstrated  the  capability  to  drive  on  unplanned  
complex  roads,  the  ques-on  is  whether  this  is  the  most  economical  and  trustworthy  solu-on.  
Automated  traffic  can  be  analysed  in  a  deeper  way.  Most  likely,  worldwide  standardisa-on  will  be  needed  
and  more  openness  on  when  things  fail.  Most  likely,  fully  automated  driving  providing  very  dense  traffic  at  
high   speed   will   require   dedicated   highways,   whereas   on   secondary   roads   the   system   will   be   more   a  
planning  and  obstacle  avoidance  assistant  to  the  driver.    
One  can  even  ask  if  we  should  s-ll  speak  of  vehicles.  The  final  func-onality  is  mobility  and  transport.  For  the  
next  genera-on,  cars  and  trucks  as  we  know  them  today  might  not  be  the  solu-on.  A  much  more  modular  
and   scalable,   yet   automated,   transport   module   that   can   operate   off-­‐road   and   on   standardised   auto-­‐
highways   is   more   likely   the   outcome.   Users   will   likely   not   own   such   a   module   but   rent   it   when   needed  
whereby   operators   will   be   responsible   for   keeping   it   func-oning   and   improving   it   without   disrup-ng   the  
service.  Independent  authori-es  will  supervise  and  provide  an  even  playing  field.  Openness,  communica-on  
and  feedback  loops  at  all  levels  will  give  it  the  an-fragility  property  that  we  already  enjoy  in  avia-on.  At  that  
moment,  Mobility  will  have  become  a  Service.  

3.6. Is  there  an  ARRL-­‐8  level?  


One   can   ask   the   ques-on   whether   we   can   define   addi-onal   ARRL   levels.   ARRL   levels   0   to   7   are   clearly  
defined   in   the   context   of   (tradi-onal)   systems   engineering   whereby   humans   are   important   agents   in   the  
required   processes   to   reach   these   levels.   One   could   say   that   such   a   system   is   self-­‐adap-ve.   However   the  
an-fragile   proper-es   (even   when   only   par-ally   fulfilled)   are   designed   in   and   require   conscious   and  
deliberate   ac-ons   to   maintain   the   ARRL   level.   If   we   look   at   biological   systems   we   can   see   that   such   systems  
evolve   without   the   interven-on   of   external   agents   (except   when   they   stress   the   biological   system).  
Evolu-on  as  such  has  reached  a  level  whereby  the  “architecture”  is  self-­‐adap-ve  and  redundant  without  the  
need  for  conscious  and  deliberate  ac-ons.  We  could  call  this  the  ARRL-­‐8  level.  

Altreonic NV From Deep Space To Deep Sea Page 31 _


Trustworthy Systems Engineering with GoedelWorks 3

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.


Altreonic NV From Deep Space To Deep Sea Page 32 _


4. The  systems  Grammar  of  GoedelWorks  
Just  by  defining  concepts,  we  don't  have  a  System.  This  is  true  for  the  Project  domain  and  this  is  true  for  the  
Process  domain.  In  the  Project  domain,  we  create  a  System  by  defining  how  the  different  En--es  interact.  In  
the  Process  domain,  we  define  how  the  different  En--es  are  related.  The  concepts  and  their  rela-onships  
define  an  emerging  Process  that  has  meaning  just  like  the  Grammar  rules  on  the  terms  of  a  sentence  give  
the  sentence  a  specific  meaning.  Therefore,  we  call  this  the  Systems  Grammar.  

4.1. Systems  Grammar  


To  understand  the  emergence  of  meaning  in  a  Project,  one  must  look  at  how  a  System  emerges  in  a  Process.  
It  is  ini-ally  very  much  a  mental,  cogni-ve  Process  done  by  humans.    
When   a   stakeholder   speaks   or   thinks   about   the   "Mission"   of   a   System,   he   probably   has   a   mental   picture  
about  the  System.  Likely  this  picture  will  resemble  something  he  knows  from  seeing  in  the  real  world  or  a  
virtual  world  (e.g.  movies  and  SF-­‐novels).  What  follows  is  a  mental  Process  of  refinement.  The  mission,  as  a  
top   level   Requirement   (e.g.   “We   need   a   deep   ocean   submarine"),   is   decomposed   in   more   specific  
Requirement   statements   about   the   System   un-l   an   atomic   level   has   been   reached,   e.g.   "the   submarine  
should  be  yellow".    The  Process  is  one  of  decomposi>on  and  refinement,  not  one  of  deriva-on.  We  call  this  
a  structural  link  and  it  only  applies  to  En--es  of  the  same  type  (in  this  case  Requirements).  As  is  ouen  the  
case,   Requirements   will   be   overlapping   and   not   necessarily   fully   coherent.   As   they   are   defined   without  
much   analysis,   there   will   be   conflic-ng   Requirements,   certainly   when   we   take   into   account   the   boundary  
condi-ons  of  a  real  implementa-on.  Engineering  is  always  a  trade-­‐off  exercise.  
Once   everyone   agrees   on   the   Requirements   (subject   to   further   inves-ga-on)   that   are   to   be   retained,   we  
can  consider  these  Requirements  as  "Approved".  Ouen  this  is  ouen  called  the  Kick-­‐Off  point  in  a  Project,  at  
least  if  it  is  decided  to  go  ahead  with  the  next  steps.  Some  Projects  will  start  earlier,  some  Projects  will  then  
stop  as  this  decision  acts  as  a  "gate"  for  the  next  steps.  
The   next   step   is   to   refine   the   Requirements   into   hard   Specifica>ons.   What   this   means   is   that   we   derive  
concrete   Specifica-ons   from   the   Requirements.   Concrete   means   that   they   become   measurable,   verifiable  
and   also   implementable.   They   should   also   be   unique.   One   can   consider   Specifica-ons   as   quan-fied   or  
qualified  Requirements,  which  indicates  that  there  is  some  con-nuity  whereby  Requirements  evolve  un-l  
they   become   concrete   enough   to   be   called   Specifica-ons.   Prac-cally   speaking,   we   can   select   or   develop  
designs   that   meet   the   Specifica-ons   and   we   can   define   tests   that   allow   us   to   verify   and   validate   it.   The  
rela-onship   between   Requirements   and   Specifica-ons   is   one   of   dependency.   We   call   this   an   associa>on  
link.  Mul-ple  Requirements  will  result  in  mul-ple  Specifica-ons  and  mul-ple  Specifica-ons  will  be  derived  
from  mul-ple  Requirements  whereby  the  presence  of  orthogonality  (“separa-on  of  concerns”)  helps  to  see  
order  in  chaos.  Similarly,  Verifica>on  Tasks  will  have  associa-on  links  with  the  Specifica-ons  for  the  Process  
to   be   followed   during   the   Development   Tasks   and   Test   Tasks   will   have   an   associa-on   link   with   the  
Specifica-ons   for   the   proper-es   of   the   Work   Products   developed   during   the   development.   "Process"   and  
"Project"  can  be  seen  as  the  container  of  the  "how"  and  the  "what"  aspects  of  Systems  engineering.  
The   actual   development   work   to   be   done   is   the   development   of   En--es   that   implement   the   Specifica-ons.  
We  call  these  the  Work  Products.  For  Process  En--es,  these  will  typically  be  templates  or  guidelines  (when  
developing  a  Process).  For  Project  En--es,  these  will  be  reports  or  documented  evidence  (when  the  Work  
Product   is   a   Project   Requirement)   or   the   System   or   its   System   components   (when   the   Work   Product   is   a  
Project  Requirement).  The  Work  Products  are  the  result  of  the  work  done  in  Work  Packages,  composed  of  
Tasks   (Planning,   Design,   Development,   Verifica-on,   Test,   Integra-on,   Valida-on   and   Review   Tasks).   Hence  
Tasks  are  linked  in  a  Work  Package.  Valida>on  Tasks  were  not  discussed  yet  and  they  verify  that  the  Work  
Product   meets   their   Requirements   (answering   the   ques-on   "is   this   the   right   En-ty?").   A   Work   Package   is  
also   linked   with   the   inputs   it   needs:   with   Specifica>ons   (for   the   Work   Products)   and   with   its   required  
Resources.  One  could  see  the  Specifica-ons  also  as  Resources,  but  for  clarity  it  is  be;er  to  separate  them.  
Trustworthy Systems Engineering with GoedelWorks 3
In  a  System  development  Project  the  Work  Package  produces  Models  as  their  Work  Products.  Models  can  
further   be   decomposed   in   sub-­‐Models   and   finally   into   Items   and   Interac>ons.   A   Model   has   hence   an  
associa-on   link   with   a   Work   Package   and   a   structural   link   with   it   composing   Items.   One   can   also   consider   a  
Model   as   a   subtype   of   a   Work   Product,   but   the   separa-on   was   kept   for   a   clearer   dis-nc-on   between  
Process  and  Projects.        
Note   that   almost   any   En-ty   can   be   decomposed   into   smaller   sub-­‐En--es.   Addi-onal   En--es   that   are  
related   to   a   Project   are   References   that   can   be   associated   with   Requirements   and   Change   Requests   and  
Issues.  The  la;er  two  can  be  associated  with  any  En-ty.  
The   result   of   introducing   these   links   can   best   be   illustrated   graphically.   The   dependency   graph   was  
generated  for  the  Requirement  5  with  id-­‐869  in  the  OpenComRTOS  Qualifica-on  Package.  First  we  look  at  
the  textual  representa-on  below.  We  can  follow  the  trace  from  the  Requirement  REQ-­‐5  being  refined  into  
Specifica-on  SPC-­‐3  with  sub-­‐Specifica-ons  SPC-­‐3.1,  3.2  and  3.3  with  defined  Tests  (TST)  and  dependent  Test  
code  (WPT)  but  also  the  implementa-on  code  (WPTs  with  a  link  to  where  it  is  stored    in  the  version  control  
repository).   This   representa-on   is   however   not   so   easy   to   navigate,   hence   the   next   figure   show   the  
screenshot  and  an  exported  graphml.  The  la;er  can  be  manipulated  in  a  graphml  editor  or  viewer  (example:  
Yed).  

Dependency  Tree  for  REQ-­‐5:  


REQ-­‐5:  Priority  based  preemp-ve  scheduling  
-­‐-­‐SPC-­‐3  -­‐  Scheduler    
-­‐-­‐-­‐-­‐TST-­‐2.2.6.2  -­‐  Empty  Ready-­‐List  (002)    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.6.2  -­‐  Empty  Ready-­‐List  (002)    
-­‐-­‐-­‐-­‐SPC-­‐3.2  -­‐  Priority  based  scheduling    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐1.18  -­‐  Scheduler    
-­‐-­‐-­‐-­‐-­‐-­‐TST-­‐2.2.1.1.4  -­‐  Raise  a  Raised  Event  _WT    
-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.1.1.4  -­‐  Raise  a  Raised  Event  _WT    
-­‐-­‐-­‐-­‐-­‐-­‐TST-­‐2.2.1.1.7  -­‐  Test  synchroniza-on  in  a  Raised  Event    
-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.1.1.7  -­‐  Test  synchroniza-on  in  a  Raised  Event    
-­‐-­‐-­‐-­‐-­‐-­‐TST-­‐2.2.1.1.9  -­‐  Test  a  Not  Raised  Event  _WT    
-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.1.1.9  -­‐  Test  a  Not  Raised  Event  _WT    
-­‐-­‐-­‐-­‐-­‐-­‐TST-­‐2.2.1.1.11  -­‐  Test  a  Not  Raised  Event  _NW    
-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.1.1.11  -­‐  Test  a  Not  Raised  Event  _NW    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐2.47  -­‐  src/kernel/L1_kernel_scheduler.c    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐2.53  -­‐  include/kernel/L1_task_api.h    
-­‐-­‐-­‐-­‐SPC-­‐3.3  -­‐  Fifo  scheduling    
-­‐-­‐-­‐-­‐-­‐-­‐TST-­‐2.2.6.1  -­‐  Scheduler    
-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.6.1  -­‐  Scheduler_001  (yield)    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐1.18  -­‐  Scheduler    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐2.47  -­‐  src/kernel/L1_kernel_scheduler.c    
-­‐-­‐-­‐-­‐SPC-­‐3.1  -­‐  Scheduling  Policy    
-­‐-­‐-­‐-­‐-­‐-­‐TST-­‐2.2.3.3  -­‐  Suspend  a  Running  Task    
-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.3.3  -­‐  Suspend  a  Running  Task    
-­‐-­‐-­‐-­‐-­‐-­‐TST-­‐2.2.3.4  -­‐  Resume  a  Suspended  Task    
-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐3.3.3.4  -­‐  Resume  a  Suspended  Task    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐2.45  -­‐  src/kernel/L1_kernel_resume_task_service.c    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐2.51  -­‐  src/kernel/L1_kernel_suspend_task_service.c    
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐1.18  -­‐  Scheduler  
-­‐-­‐-­‐-­‐-­‐-­‐WPT-­‐2.47  -­‐  src/kernel/L1_kernel_scheduler.c  

Altreonic NV From Deep Space To Deep Sea Page 34 _


Trustworthy Systems Engineering with GoedelWorks 3
 
A unifying view on systems engineering

A .dot dependency graph in GoedelWorks

A dependency graph exported to a graphml viewer/editor

Altreonic NV From Deep Space To Deep Sea Page 35 _


Trustworthy Systems Engineering with GoedelWorks 3

4.2. Terminology  and  its  conven>ons  in  GoedelWorks  


The  a;en-ve  reader,  especially  when  familiar  with  exis-ng  standards  might  no-ce  some  dis-nct  differences  
between   the   GoedelWorks   terminology   and   the   one   used   in   e.g.   safety   and   systems   engineering   standards.  
For   example   most   standards   will   not   use   the   term   specifica-on   and   only   talk   about   requirements.   Some  
standards   differen-ate   them   by   using   qualifiers.   E.g.   DO-­‐178,   the   avionic   standard   speaks   of   High   Level  
Requirements  (HLR)  and  Low  Level  Requirements  (LLR),  the  la;er  ouen  been  associated  with  the  details  of  
the   implementa-on.   Some   other   standards   like   ECCS   (the   ESA   standard)   mix   the   two.   Even   if   this   can   be  
explained   (Specifica-ons   evolve   by   decomposi-on   and   refinement   from   Requirements),   it   leads   to  
confusion  because  as  we  have  seen,  we  need  clear  and  unambiguous  concepts  to  communicate.  Another  
example   is   the   use   of   the   terms   verifica-on,   tes-ng   and   valida-on.   These   are   also   very   ouen   used  
differently  depending  on  the  standard  and  the  context,  ouen  resul-ng  in  confusion.    
Solving  this  issue  is  not  trivial.  One  has  essen-ally  two  op-ons.  The  first  op-on  is  to  invent  a  new  term.  This  
has  as  drawback  that  it  has  to  be  created  and  introduced  (ouen  people  use  acronyms  for  achieving  this).  
The  second  op-on  is  to  use  a  term  in  natural  language  that  exists  with  a  close  enough  generally  accepted  
meaning.   This   is   the   op-on   adopted   in   GoedelWorks.   In   order   to   reduce   the   possible   confusion,   each   of  
these  GoedelWorks  key  terms  is  capitalised  and  in  the  portal  a  standardised  acronym  is  used.  See  Annex  for  
a  detailed  list.  
In  the  table  below  one  can  find  the  specific  terminology  used  in  GoedelWorks.  It  covers  the  main  En--es.  
Further   on   we   will   see   that   a   GoedelWorks   Project   consists   of   a   number   of   Works   Packages,   as   instances   of  
a  prescribed  Process  Steps.  A  Work  Package  has  itself  a  number  of  Artefacts  that  cons-tute  the  evidence  for  
the  performed  Ac-vi-es.  These  also  serve  as  inputs  to  the  next  Tasks  that  need  to  be  done.  Following  the  
dependency  rela-onships,  they  also  need  to  be  approved  before  the  following  Tasks  can  be  approved.  

Altreonic NV From Deep Space To Deep Sea Page 36 _


Trustworthy Systems Engineering with GoedelWorks 3

GoedelWorks’  specific  Terminology


Term Defini>on
System The  System  is  the  En-ty  under  considera-on  as  the  object  of  the  Systems  
Engineering  ac-vi-es.  This  is  called  the  System  under  development.  It  interacts  
with  two  other  Systems.  The  environment  is  the  external  System  in  which  the  
System  will  be  placed  and  the  user  or  operator,  with  whom  the  System  fulfills  its  
mission.    
Mission The  Mission  is  the  top  level  Requirement  for  which  the  System  is  being  
developed.
Requirement A  Requirement  is  any  statement  by  any  stakeholder  that  is  related  to  the  mission  
of  the  System.  
Specifica>on A  Specifica-on  is  a  mapping  of  the  Requirements  into  a  verifiable  Requirement,  
ouen  by  quan-fying  and  qualifying  the  Requirement  statements.  A  Specifica-on  
must  have  a  “ Test  Case”  else  it  might  be  ques-onable  if  it  can  be  verified  that  the  
Developed  En-ty  meets  its  Specifica-ons.
Reference A  Reference  is  any  relevant  input  or  informa-on  that  is  generic  but  is  necessary  or  
useful  to  carry  out  the  engineering  Project  or  Process.  Ouen  it  will  be  external  to  
the  Project  but  related  to  it.
Process A  Process  is  a  well  defined  number  of  Steps  and  Ac-vi-es  that  define  how  a  
Project  has  to  be  executed.  It  also  defines  the  Artefacts  and  Work  Products  that  
must  be  delivered  allowing  Verifica-on  and  Valida-on  of  the  Project  execu-on.  
This  can  be  used  for  Qualifica-on  of  Cer-fica-on  of  the  System  developed.
Project A  Project  encompasses  all  ac-vi-es,  including  those  required  by  the  Process  
agreed  upon,  that  contribute  to  the  realiza-on  of  the  System  under  development.  
A  Project  is  composed  of  a  number  of  Work  Packages,  instances  of  the  Steps  
defined  in  the  Process.
Work  Package A  Work  Package  is  a  set  of  Ac-vi-es  that  are  related  to  the  development  of  the  
Work  Products.  A  Work  Packages  consists  of  Planning,  Designing,  Development,  
Verifica-on,  Test,  Integra-on,  Valida-on  and  Review  Ac-vi-es.  Work  Packages  
require  Specifica-ons  and  Resources  to  be  able  to  execute  the  ac-vi-es.  
Work  Product A  Work  Product  is  the  end-­‐result  of    a  Work  Package  and  is  one  the  concrete  
En--es  that  need  to  be  developed  to  develop  the  Systems  as  a  whole.
Artefact An  Artefact  is  an  En-ty  that  is  produced  along  side  the  Work  Product  as  a  piece  of  
evidence  that  the  Work  Product  and  hence  the  whole  system  meets  its  
Requirements.
Resource A  Resource  is  an  En-ty  that  cons-tutes  a  Requirement  for  execu-ng  Work  
Package  Ac-vi-es.  The  main  ones  are  human  Resources  qualified  to  take  up  a  
specific  Role  in  the  Project.  Other  Resources  are  most  of  the  -me  material  in  
nature.
Role A  Role  is  a  human  Resource  mee-ng  specific  Requirements  in  terms  of  
Capabili-es  as  defined  by  the  Process  Specifica-ons.
Planning Planning  defines  how  and  when  the  available  Resources  should  be  used  to  
execute  a  given  Ac-vity.
Designing The  Design  Ac-vity  defines  how  the  system  will  be  architecturally  structured  and  
how  the  different  Ac-vi-es  contribute  to  it.

Altreonic NV From Deep Space To Deep Sea Page 37 _


Trustworthy Systems Engineering with GoedelWorks 3

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.  

Altreonic NV From Deep Space To Deep Sea Page 38 _


Trustworthy Systems Engineering with GoedelWorks 3

Work  package  ac>vi>es


Kick-­‐Off The  star-ng  moment  for  a  Work  Package.  The  Kick-­‐Off  mee-ng  is  a  team  event  whereby  
the   objec-ves   of   the   Work   Package   are   clearly   iden-fied,   the   Process   to   be   followed  
defined,  Resources  assigned  and  approval  is  obtained  from  the  stakeholders  (external  as  
well  as  internal  to  the  Work  Package).
Planning This   Ac-vity   defines   how   and   when   the   Resources   will   be   used   to   meet   the   Project’s  
objec-ves.  It  assigns  the  Resources  and  defines  a  planning  in  -me.  
Designing This  ac-vity  defines  how  the  Work  Product  will  be  structured.  It  defines  for  example  the  
architecture,   lay-­‐out,   algorithms,   etc.   One   could   say   that   it   develops   Models   without  
execu-ng  them.  All  the  Design  Models  should  support  the  Development.
Developing This   Ac-vity   consists   of   the   actual   work   to   be   done.   It   is   the   core   ac-vity   supported   by   all  
other  ac-vi-es  to  reach  the  objec-ves  in  a  trustworthy  way.  The  end  results  are  Models  
(simula-on,  formal,  etc.)  with  the  Implementa-on  Model  being  the  concrete  goal  of  the  
Project.  It  focuses  on  developing  “the  right  thing”.  In  the  souware  domain  people  might  
call  this  ac-vity  “Implementa-on”  but  generally  speaking  Development  is  the  term  used  
across  mul-ple  domains.
Verifica>on This   Ac-vity   verifies   that   the   development   was   done   as   prescribed   according   to   the  
Process  Requirements  and  Specifica-ons.  It  focuses  on  developing  “the  right  way”.
Tes>ng This  Ac-vity  consists  of  verifying  that  the  developed  Items  meet  their  func-onal  and  non-­‐
func-onal   Specifica-ons.   Tes-ng   is   likely   to   be   repeated   auer   integra-on   at   the   system  
level.  The  resul-ng  measurements  are  then  called  “Characteris-cs”.
Integra>on This   Ac-vity   combines   the   composing   Items   of   the   developed   Work   Products   into   a   single  
en-ty   (that   can   be   a   system,   sub-­‐system   or   component).   It   can   be   seen   as   part   of  
Development   but   the   focus   is   here   on   the   interac-ons   and   connec-ons   between   the  
Items.
Valida>on This  Ac-vity  will  verify  that  the  Work  Product’s  Requirements  are  met.  Auer  Integra-on,  
the   focus   is   on   verifying   that   the   “right   system”   was   developed.   The   measured  
characteris-cs   might   differ   from   the   Specifica-ons   and   a   decision   is   to   be   made   to  
approve  the  Work  Products  on  basis  of  the  intended  Requirements.
Review This   Ac-vity   will   combine   the   results   of   all   Ac-vi-es   and   conduct   a   review   seeking  
oversights  and  residual  issues.  In  principle,  Review  ac-vi-es  are  done  during  any  ac-vity  
and  preferably  involve  independence  and  peer  review  as  ouen  prescribed  in  the  Process  
Requirements  and  mandated  by  the  standard  to  comply  with.
Release When   all   Ac-vi-es   and   their   corresponding   evidence   have   been   approved,   the   Work  
Products  can  be  released,  for  example  to  transfer  them  to  the  produc-on  facili-es.  At  this  
stage,  the  Work  Products  and  their  evidence  will  be  “frozen”  and  enter  strict  configura-on  
management.

Altreonic NV From Deep Space To Deep Sea Page 39 _


Trustworthy Systems Engineering with GoedelWorks 3
Each  of  these  Ac-vi-es  can  further  be  divided  in  four  main  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.  

4.4. In  the  end,  any  project  is  itera>ve  


A  superficial  reading  of  the  preceding  chapters  might  raise  the  ques-on  if  what  we  describe  is  a  classical  
waterfall   or   V-­‐Model   for   the   engineering   Process.   This   means   that   the   different   ac-vi-es   follow   a   strict  
linear   order   in   -me   (Requirements-­‐Specifica-ons-­‐Work   Packages-­‐   etc.   -­‐   Work   Products).   This   is   a   wrong  
view   and   not   desirable.   First   of   all   in   a   Systems   engineering   Project   nothing   is   sta-c   unless   frozen   or  
approved.  Most  of  the  -me  En--es  will  be  "in  work".  Secondly,  most  Systems  engineering  Projects  will  need  
to  deliver  hundreds  or  thousands  of  Work  Products  and  concurrent  engineering  is  almost  a  must.  Thirdly,  
Systems  engineering  is  an  itera-ve  Process.  Requirements  might  have  resulted  in  unrealis-c  Specifica-ons  
or  while  working  on  the  implementa-on,  new  issues  will  have  been  discovered  and  therefore  Specifica-ons  
adapted.  Therefore,  the  classical  V-­‐Model  is  in  reality  an  interconnected    composi-on  of  mul-ple  V-­‐Models,  
essen-ally  one  for  each  Work  Product.  This  applies  as  well  for  the  Process  Artefacts  (e.g.  documents  and  
reports)  as  for  the  Project  Work  Products  (e.g.  the  System  Models  and  En--es  developed).  
To  bring  order  in  its  execu-on  Systems  engineering  works  with  "states"  for  all  Project  En--es.  Each  En-ty  
(for  example  a  Specifica-on)  starts  his  life  when  it  is  created.  We  call  this  state  'Defined".  Once  defined,  it  
has  to  be  completed  and  worked  upon.  We  call  this  state  "In  Work".  At  some  point  in  -me,  the  Specifica-on  
will   be   frozen,   we   call   this   "Frozen   for   Approval".   If   the   Specifica-on   is   then   approved,   we   call   this  
"Approved".   At   this   moment   anyone   making   any   change   to   the   Specifica-on   results   in   the   Specifica-on  
being  put  to  "In  Work"  again.  
Why   is   this   important?   Configura-on   management   is   related   to   the   associa-on   and   structural   links.   For  
example  Specifica-ons  are  input  to  the  Test  Tasks.  If  the  Specifica-ons  are  not  frozen  and  approved,  tes-ng  
will  have  to  restart  whenever  the  Specifica-ons  are  changed.  What  results  is  that  all  Work  Products  can  only  

Altreonic NV From Deep Space To Deep Sea Page 40 _


Trustworthy Systems Engineering with GoedelWorks 3
be   approved   if   all   preceding   En--es   have   been   approved.   This   defines   the   final,   approved   System  
configura-on.  The  links  automa-cally  create  a  chain  of  approval  events  that  synchronise  the  Project  at  the  
state   transi-ons   to   "Approved",   hence   a   par-al   order   in   -me.   As   long   as   everything   is   not   "approved"   work  
can  proceed  in  parallel,  provided  there  is  not  a  dependency.  This  also  shows  why  a  modular  and  concurrent  
architecture  is  beneficial.  Not  only  does  it  promote  concurrent  and  itera-ve  engineering,  it  will  also  be  more  
resilient  as  errors  (and  faults)  will  have  less  global  impact.  
GoedelWorks  handles  the  state  transi-ons  using  the  following  rules:  
• No  En-ty  can  be  approved  unless  all  its  preceding  En--es  have  been  approved.  
• No  En-ty  can  be  approved  unless  all  its  composing  structural  En--es  have  been  approved.  
This   is   illustrated   with   the   following   screenshot   whereby   invoking   the   edit   mode   on   an   Approved   en-ty  
triggers  a  warning.  

4.5. Systems  Engineering  as  a  collec>on  of  Views  


The  reader  might  be  surprised  that  most  of  Systems  Engineering  can  be  described  with  only  a  handful  of  
types  of  En--es  and  2  types  of  rela-onships.  This  is  the  result  of  formalisa-on  work  whereby  a  hierarchy  of  
meta-­‐Models,   Models   and   specific   instances   was   further   refined   and   grouped   in   an   orthogonal   way.   The  
result  was  a  concrete  Systems  Grammar.  
What   makes   Systems   Engineering   confusing   is   that   several   views   on   the   System   are   simultaneously   present  
and  this  ouen  results  in  different  terminologies  in  the  natural  language  domain.    
In   the   Requirements   and   Specifica-on   phase,   the   subject   of   interest   is   a   mostly   related   to   proper-es   of   the  
System.   As   this   should   be   done   before   an   implementa-on   (a   System   Model   with   its   En--es)   has   been  
selected,  the  difficulty  is  that  one  has  to  think  abstractly.  Certainly  for  the  HARA  phase  this  is  a  challenge  as  
one  has  to  think  about  failure  cases  that  should  not  happen  at  all  (but  eventually  they  will).    
In  the  development  phase,  the  Specifica-ons  will  have  been  mapped  onto  Models  and  their  En--es.  This  is  
an  architectural  view.  
In  the  planning  phase,  the  a;en-on  shius  to  Resource  planning  with  milestones  and  deliverables.    
The   most   confusing   is   perhaps   that   before   a   trustworthy   Systems   engineering   Process   can   proceed,   the  
methodology  must  be  defined  and  concretely  this  means  that  the  Process  is  defined.  Developing  a  Process  
is  a  Project  in  itself.  It  will  follow  a  similar  Process  as  the  one  it  will  develop,  although  more  on  an  intui-ve  
base  because  there  is  not  standard  Process  defined.  Process  Requirements  come  from  many  stakeholders  
through   external   and   internal   standards   and   regula-ons.   They   have   a   societal   context,   for   example   because  
safety   and   security   related   risks   have   to   be   mi-gated   by   law   and   cer-fica-on   will   ouen   be   a   legal  
Requirement  before  the  System  can  be  put  in  service  or  the  product  can  be  commercialised.  While  these  
standards  speak  of  Work  Products,  these  are  actually  Requirements  and  Specifica-ons  for  the  development  
Projects.  If  a  specific  organisa-on  has  adopted  such  a  standard  based  Process,  it  will  likely  have  developed  
template  versions  to  reduce  the  administra-ve  and  management  burden  on  the  engineering  itself.  Hence,  
we  see  that  a  Work  Product  like  e.g.  a  test  plan  will  morph  from  a  Reference  into  a  Process  Requirement,  
into   a   Process   Specifica-on,   into   a   template   and   finally   into   a   specific   test   plan   resul-ng   in   a   test   report.  
Similarly,  a  component  procured  for  the  execu-on  of  a  Project,  might  have  followed  a  similar  path.  In  each  
of  these  steps  is  likely  to  be  given  different  names.  

Altreonic NV From Deep Space To Deep Sea Page 41 _


Trustworthy Systems Engineering with GoedelWorks 3
The  result  is  that  a  System  under  development  when  approved  and  released  for  produc-on  is  more  than  
the  System  itself.  It  is  the  result  of  all  the  different  views  combined.  As  trustworthiness  and  quality  are  long  
term  issues,  it  shows  the  importance  of  traceability.  It  also  shows  how  this  is  embedded  in  the  culture  of  
the  organisa-on,  the  region,  the  society  and  the  educa-on  that  people  receive.


Altreonic NV From Deep Space To Deep Sea Page 42 _


Trustworthy Systems Engineering with GoedelWorks 3

5. Descrip>on  of  the  GoedelWorks  Environment  


In   this   chapter   we   describe   the   GoedelWorks   environment.   Based   on   a   unifying   systems   grammar,   it  
supports   defining   Processes,   Projects   and   Work   Plans   in   a   traceable   way   so   that   the   evidence   (as   Artefacts)  
remains  linked  with  the  Work  Products,  facilita-ng  Qualifica-on  and  Cer-fica-on.  

5.1. Principles  of  opera>on  


The  GoedelWorks  environment  is  composed  of  a  server  program  that  manages  all  the  data  in  a  repository  
and   manages   the   interac-on   with   the   users,   who   use   a   client   souware   through   a   web   browser.   User   can  
create,  modify  and  delete  en--es,  either  belonging  to  a  defined  Process  or  a  defined  Project.  

   
A GoedelWorks screenshot of a Development Task Entity

Some  principles  apply:  


• As  a  conven-on  GoedelWorks  En--es  start  with  an  uppercase  le;er,  else  the  acronym  will  be  
used.  
• Each  En-ty  receives  a  unique  iden-fier  upon  its  crea-on.  This  is  for  reasons  of  traceability.  
• En--es  are  never  physically  deleted  but  moved  to  a  Container  with  deleted  en--es.  
• On  the  naviga-on  tree,  en--es  are  grouped  in  Containers  per  type  of  En-ty.  
• The  user  can  create  dependency  links  as  permi;ed  by  the  System  Grammar  (see  below).  
• An  En-ty  can  be  decomposed  into  sub-­‐En--es.  
• When  being  edited,  a  write-­‐lock  is  automa-cally  created  and  no  other  user  is  allowed  to  make  
modifica-ons.  Reading  is  always  allowed.  
• Different  users  have  access  rights  to  an  en-ty  depending  on  the  permissions  that  were  set  for  
the  his  roles.  
• Each  change  to  an  En-ty  is  logged  whereby  the  En-ty  receives    a  unique  revision  number.  

Altreonic NV From Deep Space To Deep Sea Page 43 _


Trustworthy Systems Engineering with GoedelWorks 3
• En--es  of  the  same  type  are  grouped  in  Containers.  
• GoedelWorks   is   not   document   based   but   En--es   can   have   documents   (actually   any   file)   as  
a;achments   and   the   user   can   export   En--es   (or   complete   Projects   and   Processes)   to   a  
-mestamped  hyperlinked  html  or  pdf  document.  
• Some   en--es   can   be   'linked'   with   version   control   systems,   such   as   Subversion   and   Git.   In   these  
cases   the   full   content   of   the   repository   item   (as   well   as   the   informa-on   about   the   revision  
number   in   the   version   control   system,   the   -mestamp   of   the   latest   modifica-on   and   the   user  
who   did   it)   is   copied   to   the   GoedelWorks   repository,   so   that   it   remains   independent   from  
external   repository.   The   user   is   also   allowed   to   modify   the   document   and   send   the  
modifica-ons  to  the  version  control  system  

5.2. Organisa>onal  func>ons  of  a  GoedelWorks  portal  


Adop-ng  a  GoedelWorks  portal  brings  many  organisa-onal  func-onali-es  together  in  a  single  environment.  
We  list  some  of  the  most  important  ones:  
A  GoedelWorks  portal  acts  like  a  structured  knowledge  repository:  while  GoedelWorks  offers  the  choice  to  
organise  for  example  a  Process  or  a  Project  according  to  its  Systems  Grammar,  this  is  not  a  must.  The  user  
can   define   small   Containers   (incomplete   according   to   the   System   Grammar)   and   fill   it   with   data   about   a  
specific  topic.  However,  he  can  gradually  structure  the  data  (for  example  by  linking  the  data  with  references)  
so  that  the  data  becomes  a  structured  knowledge  repository,  easy  to  navigate  and  easy  to  share.  
• A   GoedelWorks   portal   acts   like   a   safe   communica-on   and   collabora-on   pla†orm:   accessible  
from  any  browser,  teams  can  easily  cooperate  anywhere  and  any-me,  while  the  data  remains  
consistent  with  its  version  managed  at  the  central  repository.  
• A   GoedelWorks   portal   acts   like   an   organisa-onal   set   of   guidelines:   organisa-ons   can   easily  
define  their  internal  processes  and  integrate  them  with  standards  based  Processes  they  have  to  
follow   for   e.g.   Qualifica-on   or   Cer-fica-on.   When   execu-ng   Projects,   users   can   link   their  
Ac-vi-es  to  the  Process  Specifica-ons.  
• A  GoedelWorks  portal  acts  like  a  structured  engineering  environment,  suppor-ng  a  systema-c  
execu-on  of    (engineering  and  other)  Projects.  The  Systems  Grammar  is  gently  enforced  so  that  
the   users   automa-cally   but   incrementally   define   all   the   Project   En--es   and   dependencies.  
When   Requirements   change,   execu-ng   an   impact   analysis   is   a   ma;er   of   seconds   to   generate  
the  dependency  tree.  
• A   GoedelWorks   portal   allows   to   generate   the   evidence   needed   for   Qualifica-on   and  
Cer-fica-on   of   engineered   systems   and   products.   While   a   Project   is   filled   up   with   En--es,  
dependency   trees   ensure   that   the   Project   can   only   be   approved   when   all   Ac-vi-es,   Work  
Products   and   Artefacts   are   present   and   were   approved   in   the   right   order.   Moreover,   as  
GoedelWorks’   System   Grammar   acts   like   a   domain   independent   meta-­‐model,   the   Project   can  
ouen  be  used  for  Qualifica-on  or  Cer-fica-on  across  mul-ple  domains.  

Altreonic NV From Deep Space To Deep Sea Page 44 _


Trustworthy Systems Engineering with GoedelWorks 3

5.3. GoedelWorks  Systems  Grammar  

5.3.1. Top  level  view  


The  diagram  below  illustrates  the  view  in  GoedelWorks  that  a  System  or  Product  is  the  result  of  a  Project  
that  is  executed  by  following  a  specified  Process.  The  different  Steps  of  a  Process  are  ouen  defined  to  be  
followed   in   a   rela-ve   order   (but   itera-on   is   allowed).   As   such   a   Process   can   be   domain   and/or   organisa-on  
specific   but   generally   independent   of   a   specific   Project.   In   a   Project   corresponding   Works   Packages   are  
executed  as  an  instance  of  the  Steps  defined  in  a  Process  flow.  

Top level view of the Systems Grammar in GoedelWorks

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.    

Top level view of the Work Package inputs and outputs

Altreonic NV From Deep Space To Deep Sea Page 45 _


Trustworthy Systems Engineering with GoedelWorks 3
The  WorksPackage  also  depends  on  Process  Specifica-ons  and  Project  Resources.  Part  of  these  Resources  
are  Project  template  Artefacts  (e.g.  for  the  different  reports).  A  Work  Package  hence  produces  Project  Work    
Products  as  well  as  the  associated  Project  Artefacts,  essen-ally  the  underlying  evidence  (ouen  in  the  form  
of  a  document  or  report)  that  the  Work  Package  delivered  what  was  specified.  

5.3.1. View  from  inside  a  Work  Package  


The  next  diagram  on  the  following  page  shows  the  Ac-vi-es,  Work  Products  and  Artefacts  seen  from  the  
inside  of  a  Work  Package.    
Everything   starts   with   Planning,   subsequently   detailed   for   each   type   of   Ac-vity   (Planning   Design,  
Development,   Verifica-on,   Tes-ng,   Integra-on,   Valida-on   and   Review).   Each   Ac-vity   then   results   in   a  
Report  that  is  reviewed,  first  at  the  level  of  the  Ac-vity  itself,  and  then  at  the  level  of  the  Work  Package.  The  
la;er  steps  acts  as  confirma-on  measures.  
The   GoedelWorks   user   has   an   interest   in   keeping   the   general   dependency   chain   in   his   mind   when  
developing   a   Project.   The   Systems   Grammar   however   does   not   impose   a   specific   order   of   execu-on   and  
ouen  a  top-­‐down  approach  will  be  adopted  to  meet  in  the  middle  with  a  bo;om-­‐up  approach.  A  Project  can  
be  finalised  if  two  condi-ons  are  met:  
• The  dependency  tree  is  complete  and  coherent.  
• All  En--es  in  the  graph  have  been  finalised  and  approved  according  to  their  dependencies.  
• In   prac-ce,   the   la;er   statements   mean   that   there   must   be   at   least   a   single   path   from   any  
Requirement  to  any  Work  Product  and  Artefact  and  that  no  En-ty  should  be  leu  unconnected.  
The  order  of  approval  can  only  be  top-­‐down.  For  this  reason,  when  star-ng  a  new  Project,  some  
planning  is  helpful.  If  the  ini-al  grouping  is  well  done,  less  effort  will  be  needed  to  re-­‐organise  
the  Project  En--es  to  form  a  logical  and  coherent  set.  

Altreonic NV From Deep Space To Deep Sea Page 46 _


Trustworthy Systems Engineering with GoedelWorks 3

Altreonic NV From Deep Space To Deep Sea Page 47 _


Trustworthy Systems Engineering with GoedelWorks 3

5.4. Top  level  View  in  a  GoedelWorks  portal  


GoedelWorks   can   be   run   from   any   web   browser,   although   it   is   recommended   to   use   the   latest   versions   and  
to  use  a  screen  with  a  high  resolu-on.  
When  opening  the  browser  and  entering  the  account  name  and  password,  the  user  will  be  presented  with  
the  main  GoedelWorks  view.  It  has  the  following  panes:  
• The  En--es  view  on  the  right.  
• The  naviga-on  view  on  the  leu  (called  the  En-ty  Tree).  
• At  the  top  several  tabs  are  visible,  top  to  bo;om:  
• En--es  (normally  open),    
• Glossary,  Query,    
• Administra-on,    
• Change  Log  
We  will  look  at  these  more  in  detail  in  the  next  sec-ons.


Altreonic NV From Deep Space To Deep Sea Page 48 _


Trustworthy Systems Engineering with GoedelWorks 3

5.4.1. Navigation  tree  view  


The  naviga-on  tree  panel  allows  the  user  to  quickly  navigate  his  portal.  At  the  top  level  we  see  Containers  
(CNT)   for   the   deleted   as   well   as   the   ac-ve   defined   Processes   and   Projects.   As   men-oned   before,   in   a  
GoedelWorks  portal  all  En--es  live  forever,  even  when  deleted  and  receive  a  unique  iden-fier  when  being  
created.  The  reason  for  this  decision  is  to  support  life-­‐-me  traceability  as  well  as  providing  the  capability  to  
review  past  decisions  or  to  recover  earlier  versions  of  the  en--es.  

A GoedelWorks screenshot of a navigation tree

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”.  

Altreonic NV From Deep Space To Deep Sea Page 49 _


Trustworthy Systems Engineering with GoedelWorks 3

Applying a search filter on the navigation tree

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).  

Altreonic NV From Deep Space To Deep Sea Page 50 _


Trustworthy Systems Engineering with GoedelWorks 3
Internal model of a GoedelWorks Package

Tabular creation of Entities as a group

Changing the Work Flow status of a group of Entities on the navigation tree

Exporting navigation tree Entities

Altreonic NV From Deep Space To Deep Sea Page 51 _


Trustworthy Systems Engineering with GoedelWorks 3

5.4.2. The  entity  pane  view  

 
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.  

5.4.3. Query  capability  


Using  the  Query  tab,  the  user  can  define  and  create  his  queries  in  his  Project.  A  filter  can  also  be  applied  to  
the  naviga-on  tree  to  reduce  the  number  of  irrelevant  en--es.  

Altreonic NV From Deep Space To Deep Sea Page 52 _


Trustworthy Systems Engineering with GoedelWorks 3
Of  par-cular  interest  is  the  capability  to  generate  a  status  overview  of  a  Project.  A  table  is  then  generated  
showing  for  example  which  Specifica-ons  are  tested,  implemented  and  what  their  workflow  status  is.  The  
resul-ng  report  can  then  be  exported.  

Generated status report according to the links between the Entities


Altreonic NV From Deep Space To Deep Sea Page 53 _


Trustworthy Systems Engineering with GoedelWorks 3

5.4.4. GANTT  chart  


GoedelWorks   has   the   capability   to   generate   GANTT   charts   showing   the   planned   use   of   Resources   and  
planned  execu-on  in  -me  of  Work  Packages  and  their  Ac-vi-es.  Note  however  that  this  func-on  does  not  
calculate   any   scheduling.   It   displays   the   planned   execu-on   in   -me   based   on   the   star-ng   and   termina-on  
-mes  as  entered  by  the  portal  users.  

Gantt chart displaying Activity timelines

Altreonic NV From Deep Space To Deep Sea Page 54 _


Trustworthy Systems Engineering with GoedelWorks 3

5.4.5. Change  Log  

Change log entry of an Entity

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.  

5.4.6. Version  and  configuration  management  in  GoedelWorks  


GoedelWorks   provides   life   -me   support   for   version   and   configura-on   management   for   all   En--es   in   a  
portal.  This  is  achieved  by  following  following  main  principles:  
• No   En-ty   is   ever   physically   deleted.   When   deleted   it   is   moved   to   a   Deleted   En--es   Container   so  
that  it  always  can  be  recovered  and  reviewed.  
• Every  En-ty  receives  a  unique  iden-fier  upon  crea-on.  No  iden-fiers  are  reused.  
• Every  change  is  recorded  as  a  unique  -mestamped  event  recorded  as  a  version  number  
• Every  En-ty  has  an  associated  change  log  
Using  these  principles  it  is  possible  to  track  the  version  and  changes  made  and  even  to  revert  changes  to  
any  En-ty,  whether  Process  of  Project  related.  This  is  illustrated  in  the  following  diagram.  

Altreonic NV From Deep Space To Deep Sea Page 55 _


Trustworthy Systems Engineering with GoedelWorks 3
As   such,   one   must   remember   that   contrary   to   for   example   a   souware   repository,   what   cons-tutes   a  
coherent  set  of  repository  items  is  not  just  a  collec-on  of  files  in  folders  but  a  dependency  graph.    

Recording of Entity versions using a global unique identifier of changes

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.  

Configuration management in GoedelWorks

Altreonic NV From Deep Space To Deep Sea Page 56 _


Trustworthy Systems Engineering with GoedelWorks 3

5.4.7. Productivity  supporting  features  


A  GoedelWorks  portal  also  has  a  growing  of  addi-onal  func-ons  that  increase  the  produc-vity  of  the  user,  
reducing  the  number  of  clicks  to  achieve  the  same  effect.  We  list  a  few:  
• “Derive”  opera-on:  As  Specifica-ons  are  derived  from  Requirements,    Users  can,  for  instance,  create  
new  specifica-ons  based  on  a  selected  requirement.  A  new  specifica-on  is  shown  in  the  editor.  The  
ini-al   values   of   the   fields   are   copied   from   the   selected   requirement.   When   the   en-ty   is   saved   a  
dependency   link   is   created.   From   a   Specifica-on   a   Work   Product   and   a   Work   Package   can   be  
generated.  
• “Purge”:  If  an  authorised  user  decides  that  a  deleted  en-ty  (or  all  the  deleted  en--es  in  a  container  
for  deleted  en--es)  should  be  completely  removed  from  the  system,  then  he  is  free  to  wipe  them.  
This  process  will  remove  the  data  on  the  database  as  well  as  any  a;achments.  A  message  is  kept  in  
the  log  though,  that  the  en-ty  was  purged.    
• Snapshot  feature:  the  user  can  create  a  snapshot  of  a  Project/Process.  A  snapshot  is  a  self-­‐contained  
zip   file   containing   the   PDF/HTML   representa-on   of   the   en-ty   and   copies   of   any   a;achments   and  
version   control   system   items   (in   case   of   folders,   the   complete   content   of   the   folder   is   copied,  
recursively)  
• Fill   reports:   the   user   can   ask   the   system   to   pre-­‐fill   the   valida-on   and   verifica-on   reports   with   a  
template.   He   does   this   by   selec-ng   on   the   naviga-on   tree   a   Requirement   (of   a   Requirements  
Container.   The   Valida-on   report   will   then   be   filled   with   the   template   (for   example,   the   list   of   all  
Requirements.  An  example:  
REQ-1 (id-1) Vehicle Speed (Approved)
- Derived specifications:
SPC-1 (id-2) Max speed (Approved)
SPC-2 (id-3) Torque (Approved)
- Justification: to be filled in.

• 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).  

Altreonic NV From Deep Space To Deep Sea Page 57 _


Trustworthy Systems Engineering with GoedelWorks 3
• Sexng  default  permissions  for  each  user  group  (read,  write  and  export  rights).  
• SMTP  sexng  for  no-fica-on  mails;  
• Viewing  the  error  log;  
• User  management:  personal  contact  details,  group  membership  and    session  log.  
• Managing  and  crea-ng  user  groups;  
• Cleaning  up  locked  en--es.  

5.4.9. Glossary  
The  user  can  define  his  own  glossary,  currently  regrouping  the  terms  used  at  the  level  of  the  portal.  

Glossary screenshot

Altreonic NV From Deep Space To Deep Sea Page 58 _


Trustworthy Systems Engineering with GoedelWorks 3

5.5. A  project  example  

5.5.1. The  OpenComRTOS  Qualification  project  


As   an   example   we   concisely   present   the   Qualifica-on   Project   of   the   OpenComRTOS   kernel.   This   concerns  
only   the   RTOS   kernel   of   OpenComRTOS   Designer,   a   modelling   and   programming   environment   for  
programming  parallel  and  concurrent  applica-ons,  running  on  a  system  with  poten-ally  mul-ple  processing  
nodes.  The  design  was  originally  done  using  formal  methods.  
At   the   -me   of   star-ng   the   Project,   the   development   was   already   completed   (having   reached   v.1.6).   The  
RTOS  was  already  in  use  as  well  as  ported  to  several  targets.  The  Qualifica-on  Project’s  goal  is  to  develop  all  
the  evidence  to  support  the  qualifica-on  of  the  RTOS  kernel  itself.  This  evidence  can  then  be  used  to  assess  
the   cer-fica-on   for   different   standards   (DO-­‐178,   IEC-­‐26262,   etc.)   as   the   approach   taken   is   generic   and  
independent  of  a  specific  domain.  This  is  a  valuable  posi-on  as  OpenComRTOS  is  a  tool  that  can  be  used  
across  different  domains  without  requiring  changes.  

5.5.2. Planning  the  Qualification  Project  


In   this   project   the   star-ng   point   was   the   exis-ng   source   code   v.1.6   of   the   OpenComRTOS   kernel   (with   a  
Processor   specific   part   being   the   Freescale   powerPC   specific   code).   This   was   ini-ally   imported   and   updated  
as  the  Project  progressed.  As  the  original  kernel  was  formally  developed,  the  available  project  data  in  the  
form  a  book  is  referenced  too.  Furthermore,  we  list  all  the  Resources  that  are  needed.  These  include  tools  
such  as  the  formal  modelling  tools,  the  development  souware,  version  management  souware,  test  chains,  
etc.  See  the  following  figure  displaying  the  PowerPC  tools.  

Screenshot of the Work Package Plan Entity

Altreonic NV From Deep Space To Deep Sea Page 59 _


Trustworthy Systems Engineering with GoedelWorks 3
Next  a  decision  was  to  be  made  on  how  to  structure  the  Work  Plan.  Should  we  use  several  Work  Packages?  
Given  that  the  input  was  exis-ng  and  well  tested  source  code,  the  development  of  the  Qualifica-on  Package  
came   down   to   filling   in   the   gaps,   star-ng   with   the   exis-ng   Requirements   and   Specifica-ons   and   then  
making   sure   that   the   traceability   graph   from   Requirements   to   all   Works   Products   is   complete.   This   includes  
the  default  and  standardised  Work  Package  Ac-vi-es.  It  starts  by  defining  a  Work  Package  Plan  whereby  the  
scope  of  the  Project  is  clearly  defined.  

Screenshot of the Resources used in the Qualification Package Project

The  execu-on  of  the  Qualifica-on  essen-ally  proceeded  as  follows:  


All  references,  resources,  source  code  were  imported  via  the  SVN  repository  
The  general  Requirements  are  refined  into  Specifica-ons,  grouped  into  several  classes:  
• Func-onal   Specifica-ons:   these   are   related   to   the   behaviour   of   the   RTOS   in   terms   of   services  
offered  to  the  applica-on.  
• Non-­‐func-onal  Specifica-ons:  these  are  related  to  derived  proper-es  (e.g.  code-­‐size).  
• Interface  Specifica-ons:  these  are  actually  developed  during  the  Design  Ac-vity.  
• Implementa-on  Specifica-ons:  these  are  actually  developed  during  the  Design  Ac-vity.  
Note   that   an   alterna-ve   Project   organisa-on   could   have   been   to   have   a   dedicated   Work   Package   related   to  
the   Design   only.   This   is   certainly   a   must   for   larger   projects   but   it   also   indicates   that   the   engineering  
organisa-on  has  the  freedom  to  decompose  the  Project  in  less  or  more  Work  Packages.


Altreonic NV From Deep Space To Deep Sea Page 60 _


Trustworthy Systems Engineering with GoedelWorks 3

5.5.3. The  Planning  Activities  


The  Work  Package  Ac-vi-es  are  planned  at  the  level  of  the  Work  Package  itself  as  well  as  at  the  level  of  the  
Ac-vi-es.  It  is  clear  that  at  the  WP  level,  the  focus  is  on  coordina-ng  the  work  and  the  review  ac-vi-es.  

5.5.4. Design  Activities  


The  Design  Ac-vi-es  produce  a  detailed  Design  Report  that  analyses  the  Requirements  and  Specifica-ons  
and  the  defines  an  architecture  and  detailed  implementa-on  that  the  Development  Ac-vity  can  use.  

Screenshot of the Generic Hub Work Product Entity

5.5.5. Some  statistics  


To  illustrate  how  extensive  the  evidence  can  be,  we  provide  following  sta-s-cal  data:  
• Number  of  lines  of  code  (C  and  some  assembler):  6500  
• Number  of  En--es:  1320  
• Number  of  Links:  1697  dependency  links  and  1221  structural  links.  
• Project  requirements:  18  
• Project  Specifica-ons:  311  
• Project  Work  Products:  541  
• Project  Tests:  372  
• Number  of  pages  in  pdf  snapshot:  1508  
• A;achements:  177


Altreonic NV From Deep Space To Deep Sea Page 61 _


Trustworthy Systems Engineering with GoedelWorks 3

6. Safety  standards  awareness  in  GoedelWorks  


One  of  the  issues  in  Systems  engineering  is  that  when  Cer-fica-on  is  a  Requirement,  many  standards  can  be  
applicable.  Moreover,  legal  Requirements  will  differ  from  country  to  country  and  depend  on  the  applica-on  
domain.  In  addi-on,  standards  are  ouen  either  prescrip-ve  but  ouen  outdated  with  respect  to  technology,  
either  goal  oriented  but  leaving  it  up  to  the  engineering  organisa-on  to  follow  a  cer-fiable  Process.  This  is  a  
bit  strange  as  we  have  shown  that  Systems  engineering  is  very  universal.  
The   current   situa-on   is   due   to   historical   reasons   and   the   state   of   the   prac-ce,   including   legal  
preoccupa-ons  in  rela-onship  to  liability  issues.  For  the  purpose  of  this  discussion  we  will  limit  ourselves  to  
cer-fiable  safety  standards,  applicable  in  the  context  of  the  automo-ve  and  machinery  industry.  These  were  
introduced   when   the   complexity   increase   resul-ng   from   the   introduc-on   of   programmable   electronics  
forced  to  think  more  systema-cally  about  how  Systems  with  safety  risks  needed  to  be  developed.  

6.1. Safety  standards  for  embedded  reprogrammable  electronics  


The  root  of  these  standards  is  IEC-­‐61508.  It  covers  the  complete  safety  life  cycle,  but  needs  interpreta-on  
for  a  sector  specific  applica-on.  It  originated  in  the  Process  control  industry  sector.  
The   safety   life   cycle   has   16   phases   which   can   be   roughly   divided   into   three   groups:   analysis,   realisa-on  
(development)  and  opera-on.  All  phases  are  concerned  with  the  safe  func-oning  of  the  System.  Composed  
of   7   Parts,   Parts   1-­‐3   contain   the   Requirements   of   the   standard   (norma-ve),   while   4-­‐7   are   guidelines   and  
examples  for  development  and  thus  informa-ve.  
Central  to  the  standard  are  the  concepts  of  risk  and  safety  func>on.  The  risk  is  seen  as  a  sta-s-cal  func-on  
of   the   hazardous   event   and   the   event   consequence   severity.   The   risk   is   reduced   to   a   tolerable   level   by  
applying   safety   func-ons   that   may   consist   of   electric,   electronic   or   embedded   souware   or   other  
technologies.   While   other   technologies   may   be   used   in   reducing   the   risk,   IEC   61508   only   considers   the  
electric,  electronic  and  embedded  souware.  
From  this  standard,  extensions  were  developed  for  specific  segments.  For  example:  
• Automo-ve:  coding  standards  like  MISRA  and  later  on  ISO-­‐26262  
• Avionics:  DO-­‐178B/C  and  DO-­‐254  
• Railway:  EN-­‐50128  
• Process  Industry:  IEC-­‐61511  
• Nuclear  Power  Plants:  IEC  61513  
• Machinery:  IEC  62061  

6.2. ASIL:  A  safety  engineering  process  focused  around  ISO-­‐26262  


While   in   principle   GoedelWorks   can   support   any   type   of   Project   and   Process,   its   meta-­‐Model   was   tuned   for  
Systems   engineering   Projects   with   a   par-cular   emphasis   on   safety   cri-cal   Processes   whereby   the   final  
system  or  product  will  have    to  pass  qualifica-on  or  cer-fica-on.  As  such,  it  has  been  used  in  the  context  of  
the   automo-ve   domain,   avionics,   railway   and   space.   Organisa-ons   can   add   and   develop   their   own  
Processes  as  well  as  import  them  (when  made  available  in  a  proper  format).  
The  first  Process  that  was  imported  is  the  ASIL  Process.  The  ASIL  Process  is  a  Process  based  on  several  safety  
engineering  standards,  but  with  a  focus  on  the  automo-ve  and  machinery  domain.  It  was  developed  by  a  
consor-um  of  Flanders  Drive  members  and  combines  elements  from  IEC  61508,  IEC  62061,  ISO  DIS  26262,  
ISO  13849,  ISO  DIS  25119  and  ISO  15998.  These  elements  were  obtained  by  dissec-ng  these  standards  in  

Altreonic NV From Deep Space To Deep Sea Page 62 _


Trustworthy Systems Engineering with GoedelWorks 3
semi-­‐atomic  requirement  statements  and  combining  them  in  a  itera-ve  V  Process  Model.  It  was  enhanced  
with  templates  for  the  Work  Products  and  domain  specific  guidelines.  
In  total  the  ASIL  Process  iden-fied  about  3800  semi-­‐atomic  requirement  statements  and  about  100  Process  
Work  Products,  although  this  is  a  s-ll  an  on-­‐going  effort.  The  ASIL  Process  also  iden-fies  3  Process  domains:    
• Organisa-onal  Processes.    
• Safety  engineering  and  development  Processes.  
• Suppor-ve  Processes.  
The  ASIL  Process  Flow  was  imported  by  mapping  all  ASIL  En--es  onto  GoedelWorks  En--es  and  adding  the  
missing  En--es,  associa-on  and  structural  links.  Examples  are:  
• Upon  Work  Package  crea-on,  a  set  of  Tasks  is  added  and  structurally  linked.  The  user  can  then  
add  more  Tasks  as  needed.  
• Specifica-on  and  Requirements  En--es  are  added  for  the  Work  Products.  
For  this  reason  the  imported  ASIL  s-ll  needs  to  be  completed  to  create  an  organisa-on  or  Project  specific  
Process.   It   is   also   likely   that   organisa-on   specific   Processes   will   need   to   be   added.   This   is   made   possible  
since  each  En-ty  in  GoedelWorks  can  be  directly  edited  in  the  portal.  

6.3. Cer>fica>on,  qualifica>on  aBer  valida>on  


If   a   Systems   Engineering   Project   reaches   the   Valida-on   stage   and   the   System   is   approved,   why   is  
Cer-fica-on  s-ll  needed?  Cer-fica-on  is  first  of  all  a  legal  Requirement.  By  defini-on,  it  is  not  good  prac-ce  
if   cer-fica-on   would   be   done   by   the   same   organisa-on   that   executed   the   Project.   Even   the   best  
organisa-on  and  best  possible  Process  is  s-ll  executed  by  humans  and  the  goal  of  the  Systems  Engineering  
Process   is   to   maximise   success   in   a   cost-­‐efficient   way.   Therefore,   Cer-fica-on   has   to   be   seen   as   an  
addi-onal  re-­‐valida-on  step  executed  by  an  external  audi-ng  organisa-on.  Cer-fica-on  does  not  a;empt  to  
discredit  the  Project's  results,  it  seeks  confirma-on  that  the  Requirements,  at  least  those  relevant  for  the  
Cer-fica-on,   were   met   and   that   there   is   evidence   that   everything   was   done   that   needed   to   be   done.  
Therefore,   Cer-fica-on   is   ouen   based   on   examining   and   reviewing   the   "Artefacts",   essen-ally   the   trail   of  
evidence  generated  during  the  Project,  but  it  will  also  execute  spot  checks  and  anything  else  that  might  be  
needed.  
Producing   the   evidence   is   something   that   must   be   done   during   the   Project   when   the   work   is   actually   done.  
Examples   are   test   reports,   issue   tracking   records,   mee-ng   reports,   etc.   This   work   is   what   ouen   scares  
companies   as   it   doesn't   come   for   free.   Following   a   Process   cost   extra   -me   and   Resources,   but   has   also  
benefits.    

Altreonic NV From Deep Space To Deep Sea Page 63 _


Trustworthy Systems Engineering with GoedelWorks 3

General set-up of the GoedelWorks environment.

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.    

Altreonic NV From Deep Space To Deep Sea Page 64 _


Trustworthy Systems Engineering with GoedelWorks 3
The   cost   of   running   a   Systems   engineering   Project   will   also   be   reduced   because   the   GoedelWorks   server  
keeps  track  in  a  central  repository  of  all  changes  and  dependencies.  In  addi-on,  people  all  over  the  world  
can  collaborate  because  all  data  is  centrally  located  and  edited.  

6.4. Organisa>on  specific  instances  of  GoedelWorks  


The   GoedelWorks   environment   is   a   very   flexible   tool   for   Systems   engineering.   It   provides   the   following  
func-onali-es  for  a  distributed  team:  
• Project   support   from   Requirements   unto   release   for   produc-on   (no   need   to   use   the   ASIL  
Project  Flow).  
• Process  support  from  Requirements  unto  release  for  produc-on    (with  ASIL  Project  Flow).  
• Customisa-on  and  comple-on  of  the  ASIL  Flow,  depending  on  the  industry.  
• Developing  new,  domain  specific  Process  Flows.  
• Adding  organisa-on  specific  Processes.  
• Crea-ng   a   snapshot   of   the   Project   in   html   or   pdf   format,   i.e.   export   the   project   or   process  
contents   in   HTML   or   PDF   formats,   as   well   as   other   formats   such   as   a   self-­‐contained   archive  
(with  a;achments  and  source  code  repositories).  
• Genera-ng  dependency  and  precedence  trees.  
• Import  and  expor-ng  projects,  processes  or  any  other  en-ty  type.  En--es  from  a  given  portal  
can  be  reused  on  another  portal  through  this  interface.  
• User  management.  
• Knowledge  management.  

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  

Altreonic NV From Deep Space To Deep Sea Page 65 _


Trustworthy Systems Engineering with GoedelWorks 3

8. ANNEXES  

8.1. En>>es  supported  in  GoedelWorks  3


Altreonic NV From Deep Space To Deep Sea Page 66 _


Trustworthy Systems Engineering with GoedelWorks 3

En>>es  and  their  acronyms  in  GoedelWorks


SYS System
PRO Process
PRJ Project
REF Project  Reference
REQ Project  Requirement
SPC Project  Specifica>on
RES Project  Resource
WP Project  Work  Package
WPT Project  Work  Product
ISS Issue
CHR Change  Request
PLA Work  Package  Planning
WPPD Work  Package  Plan
WPPR Work  Package  Planning  Review
WPPRR Work  Package  Planning  Review  Report
WPR Work  Package  Review
DSP Design  Plan
DS Design
DSRP Design  Report
DSRV Design  Review
DSRR Design  Review  Report
DVTP Development  Plan
DVT Development
DVTRP Development  Report
DVTRV Development  Review
DVTRR Development  Review  Report
VETP Verifica>on  Plan
VET Verifica>on
VETRP Verifica>on  Report
VETRV Verifica>on  Review
VETRR Verifica>on  Review  Report
TSTP Tes>ng  Plan
TST Tes>ng
TSTRP Tes>ng  Report
TSTRV Tes>ng  Review
TSTRR Tes>ng  Review  Report

Altreonic NV From Deep Space To Deep Sea Page 67 _


Trustworthy Systems Engineering with GoedelWorks 3

INTP Integra>on  Plan


INT Integra>on
INTRP Integra>on  Report
INTRV Integra>on  Review
INTRR Integra>on  Review  Report
VALP Valida>on  Plan
VAL Valida>on
VALRP Valida>on  Report
VALRV Valida>on  Review
VALRR Valida>on  Review  Report
RVWP Review  Plan
RVW Review
RVWRP Review  Report
RVWCNF Confirma>on  Review
RVWCRR Confirma>on  Review  Report
WPRR Work  Package  Review  Report
REF Process  Reference
REQ Process  Requirement
SPC Process  Specifica>on
RES Process  Resource
STP Process  Step
ART Process  Artefact

Altreonic NV From Deep Space To Deep Sea Page 68 _


Trustworthy Systems Engineering with GoedelWorks 3

8.2. En>>es  defined  in  the  ASIL  Process  


This   annex   lists   an   extract   of   the   key   En--es   iden-fied   by   the   ASIL   project   in   the   analysed   safety   standards.  
This   is   used   as   an   example   Process   flow   whereby   a   user   can   define   his   own   Process   or   import   another   One.  
For  more  detailed  informa-on,  please  contact  us  at:  goedelseries  (@)  altreonic.com  

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  

2. ASIL  Work  Products  grouped  into  categories  


2.1. Change  management  (3)  
2.2. Configura-on  management  (2)  
2.3. Decommission  and  disposal  (2)  
2.4. Documenta-on  (2)  
2.5. Hardware  related  (10)  
2.6. Installa-on  and  commissioning  (8)  
2.7. Integra-on  and  tes-ng  (6)  
2.8. Project  planning  (2)  
2.9. Produc-on  (4)  
2.10. Qualifica-on  (4)  
2.11. Safety  related  (18)  
2.12. Souware  related  (18)  
2.13. Supplier  related  (12)  
2.14. System  related  (4)  
2.15. Valida-on  (2)  
2.16. Verifica-on  (3)  

Altreonic NV From Deep Space To Deep Sea Page 69 _


Trustworthy Systems Engineering with GoedelWorks 3

3. ASIL  Work  Packages  grouped  into  related  steps  


3.1. Organisa-onal  Processes    (19)  
3.2. Suppor-ng  Processes    (75)  
3.3. Document  management    (3)  
3.4. Supply  agreement  management    (24)  
3.5. Configura-on  management    (18)  
3.6. Change  management    (9)  
3.7. Verifica-on    (8)  
3.8. Confirma-on  measures    (6)  
3.9. SIMPLAR  Constraints    (19)  
3.10. Decomposi-on  of  safety  integrity  levels    (1)  
3.11. Criteria  for  coexistence    (1)  
3.12. Safety  analyses    (8)  
3.13. Analysis  of  dependent  failures    (3)  
3.14. Qualifica-on  of  hardware  components    (3)  
3.15. Qualifica-on  of  souware  components    (3)  
3.16. Qualifica-on  of  souware  tools    (6)  
3.17. Proven  in  use  argument    (5)  
3.18. System  Safety  &  Engineering  Development  Processes    (261  )  
3.19. Defini-on  scope  of  Project    (15)  
3.20. Defini-on  methodology  of  HARA  and  safety  goals    (6)  
3.21. Execu-on  of  HARA  and  safety  goals    (37)  
3.22. Func-onal  safety  concept    (4)  
3.23. System  development  planning    (4)  
3.24. System  design    (20)  
3.25. Hardware  development  planning    (4)  
3.26. Hardware  design  and  development    (18)  
3.27. Souware  development  planning    (4)  
3.28. Souware  design  and  development    (11)  
3.29. Souware  unit  tes-ng    (4)  
3.30. Souware  integra-on  and  tes-ng    (5)  
3.31. Hardware  integra-on  and  tes-ng    (5)  
3.32. Hardware  souware  integra-on  and  tes-ng    (4)  
3.33. System  and  vehicle/machine  integra-on  and  tes-ng    (4)  
3.34. Safety  valida-on    (5)  
3.35. Prototype  installa-on    (4)  
3.36. Produc-on    (6)  
3.37. Installa-on  and  commissioning    (3)    
3.38. Opera-on,  maintenance  and  repair    (10)  
3.39. Decommissioning  or  disposal  (  7)  

Altreonic NV From Deep Space To Deep Sea Page 70 _


Trustworthy Systems Engineering with GoedelWorks 3

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)

Altreonic NV From Deep Space To Deep Sea Page 71 _

You might also like