ARRL: A Criterion For Composable Safety and Systems Engineering Eric  Verhulst,  Bernhard  Sputh,  Altreonic  NV   Jose  Luis  de  la  Vara,  Simula  Research  Lab   Vincenzo  De  Florio,  University  Antwerp     24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 1 Content •  Safety  Integrity  Levels   •  Some  issues  with  the  SIL  criterion   •  QoS  and  Trustworthiness   •  Technology  domains  in  a  system   •  Introducing  the  normaHve  ARRL  criterion   •  Role  of  formal  models   •  An  ARRL  aware  process  paIern   •  Conclusions   •  Note:  Work  In  Progress!   24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 2 Some background projects •  ASIL  project   •  Project  with  Flanders  Drive  to  develop  a  common  "automoHve"  safety   engineering  methodology   •  IEC-­‐61508,  IEC-­‐62061,  ISO-­‐26262,  ISO-­‐13849,  ISO-­‐25119  and  ISO-­‐15998.  (+   CMMI,  AutomoHve  SPICE)   •  About  350  steps,  100  workproducts,  ...   •  ASIL  imported  in  GoedelWorks  portal   •  EU  FP7  IP  OPENCOSS   •  Project  with  17  EU  partners  (avionics,  raillway,  automoHve)   on  reducing  the  cost  and  effort  of  cerHficaHon   •  ISO-­‐26262,  DO-­‐178C/254/...,  CENELEC  50126-­‐128-­‐129   • Cross-­‐domain   l  LinkedIn discussion grops • Product  families   •  =>  there  is  interest  and  a  growing  awareness   24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 3 Some data for thought •  1.2  million  people  killed  in  cars  worldwide   •  35000  people  killed  in  cars  /yr  /Europe/US   • 1000  people  killed  in  airplanes  /yr  /worldwide   •  Why  the  difference?  =>  many  reasons   • The  Renault  Logan  is  the  most  reliable  car   •  Why?  Less  electronics,  proven  in  use  design   •  Is  it  also  safer?   •  The  US  is  considering  to  make  black  boxes  a   legal  requirement  in  cars   •  What  does  this  mean?  What  could  be  the  impact?   24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 4 Systems Engineering vs. Safety Engineering •  System  =  holisHc   •  Real  goal  is  "Trustworthy  Systems"   •  Cfr.  Felix  Baumgartner  almost  did  not  do  it  because  he  didn't   trust  his  safe  jumpsuit   •  TRUST  =  by  the  user  or  stakeholders   •  Achieving  intended  FuncHonality   •  Safety  &  Security  &  Usability  &  Privacy   •  MeeHng  non-­‐funcHonal  objecHves   • Cost,  energy,  volume,  maintainability,  scalability,  Manufacturability,..   •  So  why  this  focus  on  safety?   •  User  expects  guaranteed  “QoS”     24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 5 Safety and certification •  Safety  can  be  defined  to  be  the  control  of  recognized  hazards  to   achieve  an  acceptable  level  of  risk.   •  Safety  is  general  property  of  a  system   •  It  is  complex  but  there  are  moral  liabiliHes   •  It  is  not  100%  water-­‐Hght   •  CerHficaHon:  In  depth  review  =>  safe  to  operate   •  “Conformity  assessment”  (for  automoHve)   •  Not  a  technical  requirement:  confidence,  legal   •  Evidence  makes  the  difference:   •  Evidence  is  a  coherent  collecHon  of  informa@on  that  relying   on  a  number  of  process  ar@facts  linked  together  by  their   dependencies  and  sufficient  structured  arguments  provides   an  acceptable  proof  that  a  specific  system  goal  has  been   reached.     24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 6 Safety Integrity Levels (acc. IEC-61508) Category   SIL   Consequence  upon  failure   Catastrophic   4   Loss  of  mulHple  lives   CriHcal   3   Loss  of  a  single  life   Marginal   2   Major  injuries  to  one  or  more  persons   Negliglible   1   Minor  injuries  at  worst  or  material  damage   No  consequence   0   No  damages,  except  user  dissaHsfacHon   ≅ •  SIL    f  (probability  of  occurrence,  severity,  controllability)   •  As  determined  by  HARA   •  Criteria  and  classificaHon  are  open  to  interpretaHon     24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 7 Safety as a goal across domains Domain   General  (IEC-­‐61508)   (SIL0)   SIL1   SIL2   SIL3   SIL4   Programmable  electronics   Automo@ve  (26262)   ASIL-­‐A   ASIL-­‐B   ASIL-­‐C   ASIL-­‐D   -­‐   Avionics  (DO-­‐178/254)   DAL-­‐E   DAL-­‐D   DAL-­‐C   DAL-­‐B   DAL-­‐A   Railway  (CENELEC   (SIL0)   SIL1   SIL2   SIL3   SIL4   50126/128/129)   Risk reduction factors depend on domain and usage pattern! Detailed analysis reveals only partial mapping! 24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 8 Problems with SIL definition •  Poor  harmonizaHon  of  definiHon  across  the  different   standards  bodies  which  uHlize  SIL   •  Process-­‐oriented  metrics  for  derivaHon  of  SIL   •  SIL  level  determines  architecture  (system  specific)   •  EsHmaHon  of  SIL  based  on  reliability  es@mates   •  System  complexity,  parHcularly  in  sorware  systems,  makes  SIL  esHmaHon   difficult  if  not  impossible   •  based  on  probabiliHes  that  are  very  hard  if  not  impossible  to  measure  and   esHmate   •  Risk  figures  are  different  for  each  domain  =>  reuse?   •  The  law  of  Murphy  s@ll  applies:   •  The  next  instant  can  be  catastrophic   24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 9 The real issue with SIL •  SIL  is  a  system  level  concept   •  But  we  design  using  components  and  reuse   •  SIL  cannot  be  reused   •  But  components  can!   •  Engineers  always  reuse  exisHng  components   •   SIL  is  domain  specific   •  Components  are  domain  independent   •  Composability  unclear  issue.  Why?   •  =>  we  must  start  at  the  component  level   24.09.2013 - SASSUR Altreonic - From Deep Space to Deep Sea 10