Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Multi-Core (MC) Processor Qualification for Safety Critical Systems

Dr Mark Hadley & Mike Standish
Dstl, Software and Systems Dependability Team

  • Be the first to comment

  • Be the first to like this

Multi-Core (MC) Processor Qualification for Safety Critical Systems

  1. 1. © Crown copyright 2016 Dstl 21 November 2016
  2. 2. Multi-Core (MC) Processor Qualification for Safety Critical Systems Dr Mark Hadley & Mike Standish Dstl, Software and Systems Dependability Team DSTL/PUB098248. © Crown copyright (2016), Dstl. This material is licensed under the terms of the Open Government Licence except where otherwise stated. To view this licence, visit http://www.nationalarchives.gov.uk/doc/open-government- licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: psi@nationalarchives.gsi.gov.uk. © Crown copyright 2016 Dstl 21 November 2016
  3. 3. Caveat • The contents of this presentation should not be interpreted as representing the views of the Ministry of Defence (MOD), nor should it be assumed that they reflect any current or future MOD policy. • The information contained in this presentation cannot supersede any statutory or contractual requirements or liabilities and is offered without prejudice or commitment. © Crown copyright 2016 Dstl 21 November 2016 .
  4. 4. What’s To Come © Crown copyright 2016 Dstl 21 November 2016 . What is Multi- Core? Outline of the Problems Practical Research Findings An Interim Solution Summary
  5. 5. What is Multi-Core? © Crown copyright 2016 Dstl 21 November 2016 .
  6. 6. Multi-Core (MC): A Brief Description • Single-core architectures have their limitations: – Increased transistor density and higher clock frequencies cause more power to be consumed per chip. – Performance improvement resulting from an increase in the number of transistors is relatively poor. • MC is a solution to these limitations: – Better increase in performance using MC than a more complex single core design using the same die area. – MC can reduce the power required for the same level of computation. • Industry moving to MC and single-core chips are becoming obsolete. – Space, automotive, and avionics domains are all moving to MC. © Crown copyright 2016 Dstl 21 November 2016 MC - Multi-Core
  7. 7. MC Processor within an Architecture © Crown copyright 2016 Dstl 21 November 2016 Multi-Core Processor Core 1 RTOS App 3App 2App 1 L1/L2 Cache Core 2 L1/L2 Cache Core 3 L1/L2 Cache Core 4 L1/L2 Cache L3 Shared Cache Bus Interface MC – Multi-Core App – Application RTOS – Real-Time Operating System An example!
  8. 8. The Current Problems © Crown copyright 2016 Dstl 21 November 2016 .
  9. 9. MC has its Technical Challenges • MC chips and designs have less pedigree than single-core architectures. • How best to implement MC in terms of the Real-Time Operating System (RTOS)? – AMP (Asymmetric Multiprocessing), SMP (Symmetric Multiprocessing), BMP (Bound Multiprocessing), use of Hypervisors etc. – Combination of RTOS and Hypervisor (standard or DO-178B/C compliant)? • Number of architectural design issues: – Worst Case Execution Time (WCET). – Cache Coherence. – Interference – Shared Memory, Peripheral Devices. – Program Coherence – Concurrency (Task Scheduling), Sequence of Execution. © Crown copyright 2016 Dstl 21 November 2016 MC - Multi-Core
  10. 10. Lack of Guidance for Airborne Use • Neither RTCA/DO-254 nor RTCA/DO-178C documents specify how microprocessors should be assured: – (RTCA 2000. DO-254. Design Assurance Guidance for Airborne Electronic Hardware). – (RTCA 2011. DO-178C. Software Considerations in Airborne Systems and Equipment Certification). • Microprocessors are listed as Commercial-Off-The-Shelf (COTS) components in RTCA/DO-254 (Glossary of Terms). • CAST 32 provides some guidance (highlights potential issues), however, it only relates to 2 core microprocessors. – (CAST 2014. Position Paper: Certification Authorities Software Team (CAST) 32. Multi-Core Processors). © Crown copyright 2016 Dstl 21 November 2016 .
  11. 11. Practical Research Findings © Crown copyright 2016 Dstl 21 November 2016 .
  12. 12. Experiment Set-Up • Four different examples of Software Under Test (SUT): – Numerical Recipes (Mathematical algorithms). – Matrix Multiplication. – Memory Manipulation (General purpose activities). – Cache Intensive (Memory throughput biased). • Three different types of Enemy Process (EP), designed to target: – CPU Use. – Bus Use. – Cache Use. • Measure the effect of each EP on each SUT. – No combinations of different EPs were considered. © Crown copyright 2016 Dstl 21 November 2016 .
  13. 13. High-Level Results (1) • SUT: Memory Manipulation – Bus contention EP is biggest challenge for this form of SUT. Cache, less so; CPU has little observable effect. © Crown copyright 2016 Dstl 21 November 2016 EP - Enemy Process SUT – Software Under Test
  14. 14. High-Level Results (2) • SUT: Cache Intensive – Cache EP has biggest effect (not surprising). It also has a significant effect on predictability of timing. © Crown copyright 2016 Dstl 21 November 2016 EP - Enemy Process SUT – Software Under Test
  15. 15. • SUT: Cache Intensive; EP: CPU. – An EP appears to provide a performance boost to a SUT: effect is very small; but it serves as a reminder that MC microprocessors can yield unexpected behaviours. High-Level Results (3) © Crown copyright 2016 Dstl 21 November 2016 EP - Enemy Process SUT – Software Under Test MC – Multi-Core
  16. 16. An Interim “Solution” © Crown copyright 2016 Dstl 21 November 2016 .
  17. 17. A Stepped Journey © Crown copyright 2016 Dstl 21 November 2016 . “Uni-Core” “Reduced Multi-Core” “Full Capability Multi-Core” • “Simpler” architecture. • “Simpler” to verify. • Pedigree of use. • Difficulties obtaining low- level design data. • Reduced capability via restricted implementation. • Additional difficulties with verification. • Full capability via unrestricted implementation.
  18. 18. A Potential Approach © Crown copyright 2016 Dstl 21 November 2016 MC – Multi-Core RTOS – Real-Time Operating System AMP - Asymmetric Multiprocessing Only one “active” core within a MC processor with the other cores “non-active”. Implemented for software which can have a Catastrophic failure condition (“prevent continued safe flight and landing”) or Hazardous/severe-major failure condition (“serious or potentially fatal injuries to a small number of occupants”). Use of certified RTOS to ensure space and time partitioning within AMP cluster. Reduced power management to ensure no dynamic load shedding. MC processor usage argument within similar domains.
  19. 19. A Potential Approach (2) © Crown copyright 2016 Dstl 21 November 2016 Full set of “active” cores within a MC processor. Implemented for software which can have a Major failure condition (“discomfort to occupants, possibly including injuries”) or Minor failure condition (“some inconvenience to occupants”). Use of non-certified RTOS within SMP cluster. MC processor usage argument within similar domains. MC – Multi-Core RTOS – Real-Time Operating System SMP - Symmetric Multiprocessing
  20. 20. Summary • MC processors are now the prevalent form within most domains and will be increasingly within the airborne domain. • Lack of initial guidance on the qualification of MC processors. • Practical research has demonstrated that MC processors can display complicated behaviours. • A stepped approach achieves a balance between MC processor assurance and capability. © Crown copyright 2016 Dstl 21 November 2016 MC – Multi-Core
  21. 21. © Crown copyright 2016 Dstl 21 November 2016
  22. 22. © Crown copyright 2016 Dstl 21 November 2016

×