Can you have your cake and eat it

1
COTS

• Can you have your cake and eat it?

2
Introduction

• Stephen Porter BEng (Hons) Principal Engineer
• Employed at Datel since 1999
• Tornado GR4 CSG, rework for IMS
• Year at BarcoView, Belgium SuperPuma MkI MkII
  Engine Instrument Display
• A400M and 787

3
Contents

• Definitions
• COTS insertion into Safety Critical Systems
• Circle of Risk when responding to RFQ
• COTS insertion into Safety Related/Mission
  Critical Systems
• Ethernet Switch - Case Study
• COTS components generic use
• Suggestions
• Summary

4
Definitions

• COTS Commercial Off The Shelf
• For the purpose of this presentation True
  COTS i.e. No or an absolute minimum amount of
  modification and/or re-engineering of the
  baseline product is required.
• Not WOTS
• Not MOTS

System Prime
Subsystem COTS integrator
Customer
COTS component vendor
Integration
5
Safety Critical Systems

• Bespoke by nature why?
• Safety Related/Critical Systems each subsystem
  assigned a Safety Target.
• Two types of failure
• Systematic design faults
• Random h/w failure
• Systematic failures are mitigated through
  Development Assurance
• Random failure cant predict only detect and
  protect

6
Built in Tests (Random failure)

• Combination of dedicated h/w circuitry s/w to
  detect failures identified by the FMECA.
• Dedicated s/w deals with consolidation and
  reporting of failures and then mitigating them.
• Comprehensive work for Safety Critical Systems

7
Development Assurance (Systematic failures)

• Define and adhere to processes
• Confidence evidence that due diligence has been
  applied to development.
• More safety critical more process (and
  techniques)
• Includes any h/w and s/w to mitigate random
  failures

8
Development Assurance

• True COTS components within a subsystem
  already developed iaw known standards?
• i.e. is it appropriate to look for ticks in boxes
  
• h/w DO-254
• s/w DEF-STAN 00-55, DO-178b
• Not likely and not really need a system context
• Look to Systems Engineering standards they
  require collation of development assurance data
  from h/w and s/w development processes.

9
Development Assurance

• Missing data?
• Reverse Engineer
• Rely on History of Use argument
• Integrators need support from COTS component
  vendors to Reverse Engineer cost?
• Integrators need support from COTS component
  vendors to help with History of Use argument
• Sole use of History of Use argument not suitable
  for civil aerospace (ARP 4754)

10
Circle of Risk during RFQ response
Technical Risk

• Technical Risk
• Unsuitability of proposed solution goes
  undetected.
• Combined Risk
• Effort not completely costed for.
• Engineering Risk
• Development Assurance argument not possible

Combined Risk

• Max. Price
• Assumptions
• Dependencies

Engineering Risk
11
COTS for Safety Critical SystemsConclusions

• Cake?

• Research Development Programmes needed
• ASAAC ARINC 653 compliant architectures
• Early Design needed
• Not in the scope of supply for a lower cost base
  COTS integrator.
• Not expectation of customer who wants a COTS
  solution.

• Big and expensive?
• Same as bespoke?

12
Safety Related/Mission Critical Systems
A system where its failure can be mitigated by
the operation of another system or by operator
workaround.

• BAD NEWS
• Risks during RFQ response dont go away

• GOOD NEWS
• Less impact?
• More manageable?
• Realistic chance of costing?

13
Case Study

• Ethernet Switch for a tactical subsystem as part
  of an capability upgrade programme for an
  operational vehicle

• 24 Gbits/s Ethernet Ports
• Safety Target Acceptable failure rate 1 in
  10,000 operational hours

Tactical Management Computer
Subsystem 1
Ethernet Switch
Subsystem 2
Recording Device
Subsystem n
14
Attributes to aid COTS based provision

• An Ethernet switch has a defined function
• No more, no less
• System design conducive to system health
  monitoring and decision making being implemented
  in the Tactical Management Computer
• Limited access to configure the switch simplifies
  software development
• Open standards for interfaces with TMC

15
BIT protect against random failure

• Hardware vendor will support FMECA.
• But only really need to detect failure of
  function
• Interested in whether traffic is present and
  valid
• Detect Main components

16
New software development

• BIT functionality not present in current COTS s/w
  offering.
• Current COTS s/w offering is too feature rich
• e.g. web server for browser based configuration,
  not required.
• Reverse engineering the current s/w to make
  development assurance argument?
• Original vendor not interested
• Data not made available
• Develop new software, no SOUP costable.

17
New hardware development Security requirement

• Baseline switch is already a proven product.
• A requirement to ensure that operational data
  cannot be written to NVM.
• Addition of a physical inhibit, conveniently
  linked to On Ground configuration mode of
  operation for the switch, prevents writing to
  NVM.
• Minor rework not affecting baseline operation
  costable.

18
Case Study - Conclusion

• H/W provision modification -gt costed
• S/W development -gt costed
• New COTS product

• Cake?

• Suitable for similar applications
• Good chance of similar applications

19
COTS components generic usefor Safety
Related/Mission Critical Applications

• Weve considered two ends of the spectrum
• Need to consider insertion of COTS components
• Single Board Computers
• Graphics and I/O mezzanines
• Real Time Operating Systems
• Board Support Packages
• Vendor supplied BIT
• Costing problems again

20
COTS components generic use

• Consider any insertion involving reverse
  engineering to be not True COTS.
• Concentrate on History of Use to provide True
  COTS.
• Even costing in effort from Vendors to provide
  suitable History of Use introduces risk.
• Yet we know COTS components are in service and
  being inserted into new developments.
• So where is the development assurance data or the
  History of Use?
• Why no common approach from Independent Safety
  Authorities/Auditors?

21
Suggestions

• In the Security world products gain approval from
  CESG/DIPCOG (Defence INFOSEC Product Co-operation
  Group)
• Is a similar scheme applicable to COTS for Safety
  Related/Mission Critical applications?
• Can a mandated safety review of all proposals
  prior to contract award help?
• Reduces instances of Technical Risk i.e. detect
  Unsuitability of Proposed solution.

22
Suggestions

• As COTS products are integrated together to
  provide systems
• End customer retains
• Technical Configuration
• Project applicability i.e. record the System
  Context
• History of Use just property of the Vendor?
• Working group to bring industry and customer
  together to devise a database for History of
  Use evidence
• Make available to all bidders (a catalogue of
  components within context)
• Reduces risk allowing integrators with a lower
  cost base to compete?
• Induces a common approach by ISAs?

23
Summary
Costing COTS integration for

• Safety Critical Systems - Unlikely

• Safety Related/Mission Critical - Possible

• Generic integration of COTS components Possible
  but help would be useful

24
And finally

• Manage Align expectations

25
COTS

• Can you have your cake and eat it?