Microprocessor Selection and Evaluation for Critical · PDF fileMicroprocessor Selection and...

Microprocessor Selection and Evaluation for Critical Real‐Time

Systems

Results from Project AFE 43 of theAerospace Vehicle Systems Institute (AVSI)

31 July 2008

Agenda• Presentation (approximately 45 Minutes)

– Project Members, Project Objectives and History, Industry and FAA

Partnership, FAA Guidance – Chuck Kilgore, FAA SDS Program Manager

– Project Approaches, The Problem “Why is Change Needed” –

Bob Manners, Apptis, Project Management Committee Chairman

– AEH Compliance Challenges and Issues, Emerging SoC Technologies –

Joe Marotta (Chief Engineer, Honeywell)

– Determinism, Safety Nets, SoC Challenges, Open Tasks, Published Reports –

Brian Petre (Lead Engineer/Technologist, GE Aviation)

– Panel Discussion (approximately 45 Minutes)

Microprocessor Selection & Evaluation 2

Project Stakeholders

• AVSI David Redman, Fred Fisher

• BAE Systems Kyle Deutsch, Bob Green

• Boeing Arnold Nordsieck, Nina Hester

• FAA Barbara Lingberg, Chuck Kilgore, Manny Papadopoulos, Bob Manners (Apptis)

• GE Aviation Brian Petre

• UTC Kirk Lillestolen

• Honeywell Joseph Marotta, Eric Peterson

• Lockheed Martin Floyd Fazi, Craig Treece

• Texas A&M Univ. Rabi Mahapatra, Jason Lee, Amitas Biswas, Nikhil Gupta

• Subject Matter Experts from all of the participating members

Project Objectives

This project investigates assessment criteria and safety concerns for microprocessors, and develops methods and procedures to:

1) Facilitate the safe, economical qualification of microprocessor applications with complex, nondeterministic architectures.

2) Attempt to integrate regulatory and development/integration requirements to identify and develop common techniques and tools that facilitate the smooth transition from initiation to certification for aerospace vehicles.

3) Determine methods to predict, evaluate and tune microprocessor embedded system performance and safety.

4) Provide guidance to select and evaluate microprocessors for safety critical aerospace applications.

5) Provide recommendations to the Federal Aviation Administration for regulations and policy development regarding system design of safety critical systems using emerging commercial‐off‐the‐shelf microprocessor components.


Microprocessor Selection & Evaluation


Phase 1 Phase 3Phase 2 Phase 5Phase 4

Industry SurveyGuidance EvaluationLiterature Search

BOMV Value?SIMICSRAVEN ATG

Microprocessor Approval FrameworkRisk AnalysisBOMV Models

MPC7447MPC8540OpenSPARC T1

SoC Risk AnalysesMPC8572ETI TMS320VC5470

Issue ClassesHandbook Template

Safety NetSystem BehaviorValidationArchitecture StdsHandbook

Honeywell andUTC Join

Now

LockheedMartin joins

BAE SystemsBoeing, FAA &Smiths Aerospace(nka GE Aviation)Initiate the Project

Aerospace Industry/FAA R&D Partnership

• Common Goals:– Achieve Safety (Good Business / One FAA Mission).– Reduce Cost (Aircraft Development / Certification).– Quality (Customer Satisfaction / Public Responsibility).

• Prepare for increased Future Demand.– Estimated one billion passengers in the U.S. alone by 2015,– Triple airspace use by 2025, AND/OR, – Increased need for fuel-efficient, cost-effective vehicles.


Current Guidance

• Current guidance (AC‐20‐152) states as a note to manufacturers of aircraft products or appliances incorporating custom micro‐coded components:

” We recognize that the hardware life cycle data for commercial‐off‐the‐shelf (COTS) microprocessors may not be available to satisfy the objectives of RTCA/DO‐254.

Therefore, we don’t intend that you apply RTCA/DO‐254 to COTS microprocessors. There are alternative methods or processes to ensure that COTS microprocessors perform their intended functions and meet airworthiness requirements.

Coordinate your plans for alternative methods or processes with us early in the certification project.”

• Currently DO‐254 section 11.2 considers the following, and it does not adequately cover emerging microprocessor technology:• Availability – obsolescence• Suitability – applicability to proposed application• Stability – as measured by the change rate volume• Testability – testable in the application as mfg intended • Management and tracking of their use…..


The Problem Set (1 of 3)Why is change needed?

1. Both industry and the regulatory agencies find that Systems withembedded COTS microprocessors are becoming increasingly more difficult to develop, assess and obtain qualification.

2. Both hardware and software are becoming more complex and less deterministic making it much harder to accomplish design assurance.

3. Evolving technologies in microprocessors and SoCs are not manufactured to meet the requirements for critical real‐time system application.

4. COTS manufacturers typically do not provide detailed public documentation into the inherent component risks and quality characteristics.



5. New methods are needed to predict, design, evaluate and tune system performance and safety of these evolving microprocessor embedded systems.

6. Current de facto standards (e.g., DO‐178 and DO‐254) need to be augmented to cover the evolving technologies and complexities ofcritical systems with embedded microprocessors. DO‐254 Section 11.2 (COTS Usage) is only a start.

7. Reduced die areas for BIT and BITE, limited pin access for testing on chips with millions of transistors and complete systems incur limited test capability.

– Core Accessability– Core Interaction– Core Isolation



8. Software is not a standalone solution to hardware issues.

9. Software solutions (DO‐178) alone may not address the problem at the silicon and micro‐coded level (e.g., architecture design & safety nets may be required).

10.Software solutions do affect the embedded technology’s execution times and affect the integrated performance/operational needs.

All of these lead to the need for updated guidance and associated


Project Approaches

• The team chose to seek a solution using the evolving COTS

microprocessors and SoCs.

• Surveyed industry on use of microprocessors in critical systems (limited

response).

• Evaluated Coverage of Existing Guidelines (DO‐178 and DO‐254).

• Buffer Oriented Modeling and Validation.

• Microprocessor Approval Framework.

• Detailed Risk Analyses of microprocessors/SoCs.

• Handbook of Microprocessor Selection and Evaluation.


Approaches NOT Evaluated

• Less complex non‐COTS microprocessors.

• Disabling non‐deterministic functions.

• Lock‐step multiple processor architectures.


Rationale for Choices

• COTS performance, throughput, storage, speed, capabilities are magnified by the rapidly evolving technology.

• Avionics hw/sw systems are increasingly complex and evolving rapidly.– Added functionality/requirements.– New human support and interface capabilities.– More complex interfaces with ground support systems.

• Abandoning the evolutionary growth of COTS microprocessor capabilities will eventually require a massive technical jump.


Today’s Challenges• Having each applicant uniquely design, assess and qualify airborne electronic hardware

(AEH) (e.g. microprocessors including SoCs) presents challenges:– All approaches are owned by the developer and unique to each application thus preventing the

development of Industry‐wide solutions.

– Additional pressure is placed on both regulators and developers to cover a wide variety of technologies and approaches for these unique approaches to design assurance.

– Common approaches are not developed to implement incremental design assurance based on common tools and techniques for development and certification.

• Even with common (standardized) industry‐wide approaches each solution needs to be tailored to the unique application. (It’s no longer a cookie cutter world).

• Differences between domestic and foreign approvals can result from differences in experience with ad hoc approaches to design assurance.

– Assessment and qualification coordination difficulties can arise between various regulatory authorities, especially if the guidance is vague.

– Issue papers and Certification Review Items (CRIs) are starting to require processor compliance data and the requirements may not be common across all projects.


Possible AEH Compliance Issues With Microprocessors

• Lack of available design assurance data, since suppliers do not typically develop processors for aerospace applications.

• Service history can be weak or unavailable.– New processors may have limited service history, if any at all.– There is no economic incentive for processor suppliers to collect and

provide service history data.– Reuse from non‐civil aerospace and commercial electronics

applications may not be applicable to civil aerospace applications.– ITAR could be an issue for some available service history (and design

assurance) data.


Emerging Current and Near‐Future Microprocessor & SoC Technologies (1 of 2)

• Silicon Technologies are shrinking rapidly.– 65nm, 45nm, 35nm and even 22nm are on the near horizon, leading

to more complex devices.

• As devices become more complex and replace discrete components with SoC’s, testability and visibility decrease drastically.– More and more data transactions are occurring within a single device.– The addition of non‐blocking internal switch fabrics allow more to

occur within the same clock cycle.– This means SoC determinism is decreasing.

• Multicore devices are becoming the norm.– In the near future it may become difficult to find single core devices

with the peripherals of multicore devices.


Emerging Current and Near‐Future Microprocessor/SoC Technologies (2 of 2)

• IO Mediums like PCIe, SRIO, and GigE at speeds in the GHz are becoming the norm. – which means more high speed, sensitive signals will need to be utilized in

flight control designs.

• SoC’s are becoming more and more configurable.– which means processors can not be deemed safe for flight, it must be done at

the system level.– Multiple designs with the same SoC can utilize completely different

technologies.– New issues like software reconfiguration are becoming safety problems.

• Errata lists are becoming longer due to the density and complexity of the transistors.– Microprocessors and SoC’s are being targeted towards the consumer market

with quick turnover and new revisions, rather than correcting errors.


Technology Determinism

• Determinism is the ability to predict Hardware, Software and System responses to stimuli.

• Interactions within hardware can cause non‐deterministic results (e.g., execution times may be non‐deterministic).

• Challenge is the ability to control and demonstrate acceptable determinism despite the lack of traditional insight to typical integrated circuits.

• Once a micro‐coded device is configured, its determinism is similar to a hardware integrated circuit.


Safety Net Methodology Approach• The methodology focuses on the assumption that a processor/SoC will

misbehave and safety requires the ability to protect against unexpected behavior, damage, injury, and instability over the service life at a level above the device itself.

• Safety nets (solutions) must provide the ability to protect against unintended/misleading behavior at a higher level through a combination of techniques (building blocks) such as, but not limited to:

• External monitoring of safety related behavior• Redundancy• External watchdogs• Architecture that allows run‐time correction.

• Safety net design is becoming a more complex, application specific art form that will be required to detect, resolve, and validate component failure in a run‐time environment to required levels of availability and safety.

• Tools/Simulation will be covered in the Panel Discussion


SoC Challenges

Three areas of SoC challenge were found to be common:

1) Shared resource effects on timing.• minimal documentation of device behavior.• Example: if analyzing a shared bus, does the documentation specify the

arbitration policy? what other information is necessary?• Worst case timing conditions may be difficult if not impossible to control for

testing.

2) Register status and configuration.• multiple configuration or reconfiguration, pin configuration.• unexpected register change.• accommodation of excessive capabilities (e.g. interrupts).

3) Visibility and debug limitations.• tool support.• debug interfaces / Hardware support.• modeling support (Simics / ISS availability).• Debug of real‐time applications requires special time intervention and potential

limits to maintain partitioning.


Open Tasks for Phase 4/5

• Recommended guidance updates.

• Safety net methodologies.

• Evaluating system behavior for safety.

• Incremental accreditation for proof of safety.

• Validation for emerging selection guidelines and evaluation methods.

• Standards.


FAA Reports


Publicly Available Reports

DOT/FAA/AR-06/34 - Microprocessor Evaluations for Safety-Critical Real-Time Applications: Authority for

Expenditure No. 43 Phase 1 Report

DOT/FAA/AR-08/14 - Microprocessor Evaluationsfor Safety-Critical, Real-Time Applications Authority

for Expenditure No. 43 Phase 2 Report

Panel Discussion


Panel Discussion Slides


Full System Simulation

• Can simulate complete computer, subsystem or system.

• Can execute complete software stacks– BSP, OS, middleware, applications.

• Executes on a desktop PC– Can be distributed– Can be integrated with other simulations


Full System Simulation

• Virtutech (Simics), Vast Systems, CoWare, Mentor Graphics, etc., have full system simulation environments

– Differentiated by model availability (processor support), simulation speed, cost

– Virtutech and Freescale have teamed on new multi‐core SoC hybrid models

• Cycle accurate (and functional) but slower• Functional only and faster


Why Use Simulation? (1 of 2)

• Architectural exploration.

• Performance analysis.– Hybrid simulations now provide fast simulation speeds, (more) accurate timing and accurate behavior.

• (Early) software development.

• Better visibility and debugability.

• More reliable and repeatable.


Why Use Simulation? (2 of 2)

• Simulations can be set up with conditions that may be difficult or impossible to for a test (e.g. fault response or worst case timing).

• Simulation can be used to acquire memory access trace

– Trace used by Lockheed Martin tool for optimization of software/cache interactions

• Simulation can be used for some HW/SW integration and some V&V– If only need standalone environment

– Attempting to integrate aircraft simulation to provide closed‐loop integrated environment


Acronyms (1 of 2)

• AC Advisory Circular• AEH Airborne Electronic Hardware• ATG Automatic Test Generator• AVSI Aerospace Vehicle Systems Institute• BIT Built‐in‐Test• BITE Built‐in‐Test‐Equipment• BOMV Buffer Oriented Modeling & Validation• BSP Board Support Package• CEH Complex Electronic Hardware• COTSCommercial‐off‐the‐shelf• CRI Certification Review Item (= Issue Paper)• DO‐178B Software Considerations in Airborne Systems and

Equipment Certification• DO‐254 Design Assurance Guidance for Airborne Electronic

Hardware and Equipment Certification


Acronyms (2 of 2)• FAA Federal Aviation Administration• GHZ GigaHertz• GigE Highspeed Ethernet Connection• I/O Input/Output• ISS Instruction Set Simulation• ITAR International Traffic in Arms Regulation• nka now known as • nm nano‐meter• OS Operating System• PC Personal Computer• PCIe PCI Express• R&D Research and Development• RTCA RTCA, Inc. (formerly known as Radio Technical Commission for

Aeronautics)• SoC System‐on‐a‐Chip• SRIO Serial RapidIO• TAMU Texas A&M University• V&V Verification and Validation


Date post:	15-Mar-2018
Category:	Documents
Upload:	phungnhi
View:	225 times
Download:	1 times

Microprocessor Selection and Evaluation for Critical · PDF fileMicroprocessor Selection and...

Documents