DARP Workshop System of Systems Safety Cases Parallel Session 18 th & 19 th April 2007

1. DARP WorkshopSystem of Systems Safety CasesParallel Session 18th & 19th April 2007 Ringmaster / Professional Passenger…. Dr Dai Morris Director Analysis, Experimentation & Simulation, UK MoD

2. Background • MoD CSA’s DSAC NEC Architecture Workshop • Noted safety assessment is an integral part of the ‘NEC solution’ • Asked DAES ‘to form a view of how to develop a Safety Case for the wider [NEC] system of systems’ • The Challenge Set: • What is currently being done by others that we can utilise now? • Or needs to be better utilised now • What problems are currently being considered for fixing by others in the near future? • And how do we remain engaged • What is left to be done? • With compelling reasons why MoD should undertake this? • How do we (I?) disseminate and progress findings

3. Agenda • ‘Background Reading • Summary Intro • Some ‘starter for 10’ questions • NECTISE Presentation by Tim Kelly, University of York • Failure Analysis Presentation by Paul Caseley, DSTL • Focus on • Who in MoD should own the NEC Safety issue • If we can’t do a SoS Safety Case, what ‘next best’ • What is different between NEC SoS and other SoS

4. NECTISE Presentation Summary • (Words directly from Tim Kelly, University of York) • Reality = Platform safety cases will be produced separately (at different times, by different organisations) • Need an acceptance process that considers (better) the possible operational context(s) • Need to certify ‘safe’ collaborations ahead of time • Focus on equipment safety cases must be broadened for SoS • E.g. arguments of safe (operational) use (operational doctrine) essential

5. Conclusions (1) • What is different between NEC SoS and other SoS • NEC SoS lacks a clear boundary definition? • Unlike, perhaps, a Carrier Group • More dynamic and less stable? • Nodes reconfiguring ‘on the fly’ • Tempo • Potential rapid feedback and emergence of behaviour • A whole new class of possibilities for emergent behaviour

6. The SoS safety case ‘domain’ Now? Incremental Certification Level of planned change in systems / components of SoS Level of ad-hoc / non-engineered immediate federation of system components & boundary uncertainty Need for a new approach to safety management to generate a ‘case for safety’

7. Conclusions (2) • Who (in MoD?) should own the NEC Safety issue • Distributed Problem • DE&S for equipment; FLC for training… • Pose CBM (NEC) Management Board the question? • Need a single integrating point • Responsible for interfaces and interstitial issues • With additional specific responsibilities for each DLoD owner • May assist the security problem as well?

8. Conclusions (3) • If we can’t do a SoS Safety Case, what's ‘next best’ • Do we have a regulator? • Don’t yet have an owner? • But do have a need to discharge (and demonstrate that we are discharging) our duty of care responsibility • “Safety Management System” to focus on: • Predictive • Defining, managing and scrutiny of safety arguments • But any resulting “Safety Case” may not look ‘traditional’ • Process, organisation based argument? • ‘Traffic Light’ process not unlike wider command assessment of risk • Scenario based concept? • ‘In process’ • Real time monitoring of Provenance of Data • In live ops as well as training / mission rehearsal • Identifying lessons • Ensure the capture of all relevant (emergent) behaviour • Provenance of Data also important here

9. Questions