DO254 DMAP Training 2011 Trailer

1,937 views
1,766 views

Published on

Updated DO254 training trailer by DMAP

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,937
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
80
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

DO254 DMAP Training 2011 Trailer

  1. 1. DO-254 Training A comprehensive approach to the design assurance guidance for airborne electronic hardware Presented by James Bezamat
  2. 2. Topics <ul><li>Training Introduction </li></ul><ul><ul><li>Trainer Presentation </li></ul></ul><ul><ul><li>Objectives </li></ul></ul><ul><li>Design Assurance Introduction </li></ul><ul><ul><li>Basics : CEH and design assurance </li></ul></ul><ul><ul><li>Background </li></ul></ul><ul><ul><li>DO-254 in a nutshell </li></ul></ul><ul><ul><li>Rigorous structured development </li></ul></ul><ul><ul><li>Limitations and expectation </li></ul></ul><ul><ul><li>Design assurance Level </li></ul></ul><ul><ul><li>Safety and System level considerations </li></ul></ul><ul><ul><li>Independence Consideration </li></ul></ul><ul><ul><li>Verification/Validation definitions </li></ul></ul><ul><ul><li>DO-254 Scope </li></ul></ul><ul><ul><li>Simple/Complex </li></ul></ul>JB 2010 DO-254 Training <ul><li>Hardware Design Life Cycle </li></ul><ul><ul><li>Planning Process </li></ul></ul><ul><ul><li>Hardware Design Processes </li></ul></ul><ul><ul><ul><li>Requirements Capture </li></ul></ul></ul><ul><ul><ul><ul><li>Derived requirements </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Requirement standards </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Validation Process </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Traceability (part 1) </li></ul></ul></ul></ul><ul><ul><ul><li>Conceptual Design </li></ul></ul></ul><ul><ul><ul><li>Detailed Design </li></ul></ul></ul><ul><ul><ul><ul><li>Top Level Drawing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Hardware/Software Interface Data </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Detailed Design Document and HDL code </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Coding standards </li></ul></ul></ul></ul><ul><ul><ul><li>Implementation </li></ul></ul></ul><ul><ul><ul><li>Production Transition </li></ul></ul></ul>
  3. 3. Topics <ul><li>Verification Process </li></ul><ul><ul><li>Independence </li></ul></ul><ul><ul><li>Robustness </li></ul></ul><ul><ul><li>Unitary Tests </li></ul></ul><ul><ul><li>Code Coverage </li></ul></ul><ul><ul><li>Verification Data </li></ul></ul><ul><ul><ul><li>Hardware Verification Cases Procedures </li></ul></ul></ul><ul><ul><ul><li>Hardware Verification Results </li></ul></ul></ul><ul><ul><li>Verification completion </li></ul></ul><ul><ul><li>Traceability (part 2) </li></ul></ul><ul><ul><li>Automation </li></ul></ul><ul><li>Configuration Management Process </li></ul><ul><li>Process Assurance </li></ul><ul><li>Certification Liaison Process </li></ul><ul><ul><li>Hardware Accomplishment Summary </li></ul></ul>JB 2010 DO-254 Training <ul><li>Additional Considerations </li></ul><ul><ul><li>Reuse </li></ul></ul><ul><ul><li>COTS </li></ul></ul><ul><ul><li>Service Experience </li></ul></ul><ul><ul><li>Tool Assessment </li></ul></ul><ul><li>Modulation based on DAL </li></ul><ul><li>Special considerations for Level A & B </li></ul><ul><li>Conclusion </li></ul><ul><li>Glossary and acronyms </li></ul>
  4. 4. Training Objectives <ul><li>To be prepared to manage a Design Project with the clear and complete understanding of what is request for certification. </li></ul><ul><li>To understand the actual impact of DO-254 introduction in Electronic Designs methods. </li></ul><ul><li>To be convinced that DO-254 guidance is the best way to improve quality in your designs. </li></ul><ul><li>To establish internal baselines for procedures, standards, practices and checklists to minimize cost impact and optimize of DO-254 introduction </li></ul><ul><li>In a word : to become DO-254 fluent </li></ul>JB 2010 DO-254 Training
  5. 5. DO254/ED-80 in a Nutshell <ul><li>Title : “Design Assurance Guidance for Airborne Electronic Hardware” </li></ul><ul><li>Authors : RTCA (DO-254) / EUROCAE (ED-80) </li></ul><ul><li>Date : April 2000 (first rev.) </li></ul><ul><li>Recognized as a standard by FAA in 2005 (Advisor Circular AC 20-152) </li></ul><ul><li>Clarification added by Certification Authorities in 2006 (CAST-27) </li></ul><ul><li>Additional considerations in various CAST papers. </li></ul><ul><li>FAA Guide on reviews and audits in 2007 (CEH job Aid) </li></ul><ul><li>FAA Order 8110.105, July 2008 for certification staff </li></ul><ul><li>Now a worldwide standard for Civil Aviation industry. </li></ul><ul><li>Spreading into adjacent fields (defense, transportation, medical …) </li></ul>JB 2010 DO-254 Training • EASA – European Aviation Safety Agency, EU counterpart of FAA, pronounced “ ee ah sa” • FAA – Federal Aviation Administration, the US authority governing aviation • RTCA – Radio Technical Committee on Aeronautics, a private, not-for-profit corporation that develops consensus-based recommendations RTCA functions as a Federal Advisory Committee. • EUROCAE – European Organization for Civil Aviation Equipment, equivalent of RTCA in the US, pronounced “Euro Kay” Introduction
  6. 6. Avionic Basic : Design Assurance <ul><li>Defensive systems such as design assurance, assurance oversight, operator intervention, system fault tolerance, built in tests, error capture </li></ul>JB 2009 DO-254 Training Vector of accident opportunity Latent Failures, Local Triggers Intrinsic Defects, Atypical Conditions Courtesy of James Reason Introduction
  7. 7. Independence <ul><li>DO-254 (April 2000) </li></ul><ul><li>“ All verification of Level A and B functions should be independent.” (Appendix A) </li></ul><ul><li>DO-254 + CAST-27 (June 2006) </li></ul><ul><li>“ For Levels A and B, the validation processes should be satisfied with independence.” ( CAST-27 7.c ) </li></ul><ul><li>Nota : independence of validation is also requested by CRI F-09 </li></ul><ul><li>best practice : all verification and validation activities must be conducted with independence whatever the DAL is </li></ul>JB 2010 DO-254 Training CRI – Certification Review Item, additonnal considerations to use DO-254 for certification aspects , specific to a program (e.g. CRI F-08 and F-09 for A400M) Introduction
  8. 8. <ul><li>DO-254 (April 2000) </li></ul><ul><li>« Hardware Item - An item that has physical being. This generally refers to LRUs, circuit board assemblies, power supplies and components. » ( Appendix C Glossary ) </li></ul><ul><li>“ These design processes may be applied at any hierarchical level of the hardware item, such as LRUs, circuit board assemblies and ASICs/PLDs .” ( chapter 5 ) </li></ul><ul><li>DO-254 + CAST-27 (June 2006) + FAA AC 20-152 (June 2005) </li></ul><ul><li>“ Therefore, the objectives and guidelines of DO-254/ED-80, together with the clarification of this CAST paper, will provide the needed guidelines to be satisfied at the device level for those custom micro-coded devices “ ( CAST-27 5.c ) </li></ul><ul><li>“ We don’t intend that you apply RTCA/DO-254 to every type of electronic hardware.” ( FAA AC 20-152 2.c ) </li></ul>General Scope JB 2010 DO-254 Training Line Replaceable Unit Introduction
  9. 9. System development life cycle (ARP4754) JB 2010 DO-254 Training Plans Spec. Archit. Code Synth P&R Plans Spec. Archit. Schem P&R Verif. Integration Integration Test Plans HW. Spec. Arch. SW/HW Integration Test PLD CCA LRU (hard) Hard. Interf. Detail. System Spec. (ARP4754) Safety Assessment Airworthiness Constraints LRU (soft) SW. Spec. Certification Plan Test LRU System Integration Design Life Cycle
  10. 10. Requirements JB 2010 DO-254 Training <ul><li>General Definition : </li></ul><ul><ul><ul><li>«  Requirement - An identifiable element of a specification that is verifiable.  » (Appendix C Glossary ) </li></ul></ul></ul><ul><ul><li>Req. AR_PLD1_HRS_5 Status Monitoring </li></ul></ul><ul><ul><li>Status of all channels shall be monitored and be available through CPU interface </li></ul></ul><ul><li>More : </li></ul><ul><ul><li>A requirement should be correct and complete </li></ul></ul><ul><li>Correctness of a requirement statement means the absence of ambiguity or error in its attributes. </li></ul><ul><li>(ARP 4754) </li></ul><ul><li>Completeness of a requirement statement means that no attributes have been omitted and that those stated are essential. (ARP 4754) </li></ul>Ident Title Definition Requirements Capture
  11. 11. Requirement Standards <ul><li>Rule :Requirements shall not describe design solution </li></ul><ul><ul><li>A conflict management shall be implemented in case of interrupt register update during processor read. In that case the PLD shall update the register after the processor read. </li></ul></ul><ul><ul><li>No interrupt information shall be lost. </li></ul></ul>JB 2010 DO-254 Training Requirements Capture
  12. 12. Traceability (part 1) : general relations JB 2010 DO-254 Training Validation Process System requirements Hardware System requirements Software System requirements Hardware CCA requirements Hardware PLD requirements Safety requirements Safety assessment
  13. 13. Conceptual design data example <ul><ul><li>Architecture description </li></ul></ul><ul><ul><ul><ul><li>Each channel contains a Controller that calculates the instantaneous phase of a sinusoidal carrier. This carrier signal is mixed with the input signal in the quadrature mixer to remove any frequency or phase offset on the input signal. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>The Controller is built around a 32-bit accumulator. Each clock cycle the accumulator is incremented with the value IFreq, programmed by the register IFREQ. </li></ul></ul></ul></ul>JB 2010 DO-254 Training Conceptual Design Process Transmitter control 64x16 RAM CPU Interface FIFO Control Speed select _tx1 Tx2 _tx3 _tx4 _tx5 _tx6 _tx7 Tx8 activation
  14. 14. Design Life Cycle JB 2010 DO-254 Training Detailed Design Process
  15. 15. Top Level Drawing definition <ul><li>According to CAST 28 and CAST 27 10 c </li></ul><ul><ul><li>in line with a configuration index HCI (as for DO-178B and ARP 4754) + HECI </li></ul></ul><ul><ul><li>HCI – Hardware Configuration Index : an Addendum to the HAS which identifies the specific hardware baseline configuration for technical data, part number, revision (10.9). It may also identify documentation baseline, Quality Assurance Records index </li></ul></ul><ul><ul><li>HECI – Hardware Environment Configuration Index, which describes all the tools and the environment used during design life cycle. </li></ul></ul><ul><ul><li>Nota : this definition is appropriate for a FPGA/ASIC design. It must be adapted to other type of hardware items (refer to definition dossier content) </li></ul></ul>JB 2010 DO-254 Training Detailed Design Process
  16. 16. Production transition for LRU : activities <ul><li>Definition dossier development for first prototype </li></ul><ul><ul><li>CCA definition dossier </li></ul></ul><ul><ul><li>Design data, mechanical drawings, bill of materiel, optional equipment </li></ul></ul><ul><li>Manufacturing and control dossier development for first prototype </li></ul><ul><li>Tooling for manufacturing and test </li></ul><ul><li>Produce the first LRU (prototypes) </li></ul><ul><ul><li>final assembly </li></ul></ul><ul><ul><li>Qualification Test </li></ul></ul>JB 2010 DO-254 Training Production Transition Process
  17. 17. Production transition for CCA : activities <ul><li>Definition dossier development for first prototype </li></ul><ul><ul><li>Design data, electronic schematics, layout files, bill of materiel, optional equipment </li></ul></ul><ul><li>Manufacturing and control dossier development for first prototype </li></ul><ul><ul><li>assembly instructions, Inspection Instructions and test instructions, calibration </li></ul></ul><ul><li>Tooling for manufacturing and test </li></ul><ul><li>Produce the first CCA (prototypes) </li></ul><ul><ul><li>PCB manufacturing </li></ul></ul><ul><ul><li>Component Assembly (automated and manual insertion process) </li></ul></ul><ul><ul><li>Test in-situ, integration test </li></ul></ul>JB 2010 DO-254 Training Production Transition Process
  18. 18. Production transition for PLD : activities <ul><li>Definition dossier development for first prototype </li></ul><ul><ul><li>Design data, netlist, layout files, configuration index, hardware/software interface data </li></ul></ul><ul><ul><li>programming specification, component identification, marking form, checksum </li></ul></ul><ul><ul><ul><li>To be included in CCA definition dossier </li></ul></ul></ul><ul><ul><li>Test pattern for production (ASIC only) </li></ul></ul><ul><li>Manufacturing and control dossier development for first prototype </li></ul><ul><ul><li>Fabrication procedures, PLD on CCA assembly instructions, test specification </li></ul></ul><ul><li>Tooling for manufacturing and test </li></ul><ul><li>Produce the first PLD (prototypes) </li></ul><ul><ul><li>Bitstream generation </li></ul></ul><ul><ul><li>Component programming </li></ul></ul><ul><ul><li>Test in-situ, integration test </li></ul></ul><ul><ul><li>Prototype fabrication and test by subcontractor (ASIC only) </li></ul></ul>JB 2010 DO-254 Training Production Transition Process
  19. 19. Means of Independence <ul><li>Examples from appendix A : </li></ul><ul><ul><li>1. Requirements or designs are reviewed by another individual. </li></ul></ul><ul><ul><li>Should be used for Design Review team. </li></ul></ul><ul><ul><li>2. Test cases or procedures are developed by another individual. </li></ul></ul><ul><ul><li>A clear separation between designer and verification/test engineer </li></ul></ul><ul><ul><li>3. Test cases or procedures developed by the designer are reviewed by another individual. </li></ul></ul><ul><ul><ul><li>Should be used for unitary tests developed by unitary function designer </li></ul></ul></ul><ul><ul><li>4. An analysis performed by the designer is reviewed by another individual or a review team. </li></ul></ul><ul><ul><li>5. A different test is performed that confirms the results of testing by the designer, such as a test during flight test confirms a hardware item test or software verification tests, developed independently and performed on the target hardware item, confirm the results of testing by the designer. </li></ul></ul><ul><ul><li>Should add assurance credits </li></ul></ul><ul><ul><li>6. Test or analysis results are verified by a tool. </li></ul></ul><ul><ul><li>Some analysis (verification reports) may be automated to generate simulation report (passed/failed, parameters and environment extraction) </li></ul></ul>JB 2010 DO-254 Training Verification Process
  20. 20. CCA Robustness <ul><li>DO-254 (April 2000) </li></ul><ul><li>“ Requirements derived from the hardware safety assessment that have safety implications should be uniquely identified. </li></ul><ul><li>NOTE: Derived requirements may address conditions, such as: </li></ul><ul><ul><li>Specific constraints to ensure that functions of a higher design assurance level can withstand anomalies of functions .. </li></ul></ul><ul><ul><li>range of data inputs </li></ul></ul><ul><ul><li>reset states, Supply voltage </li></ul></ul><ul><ul><li>time-related functions </li></ul></ul><ul><ul><li>timing under normal and worst-case conditions. </li></ul></ul><ul><ul><li>Signal noise and cross-talk. </li></ul></ul><ul><ul><li>unused functions..” (chapter 5.1.2(4) Requirements Capture Process) </li></ul></ul><ul><li>DO-254 + CAST-27 (June 2006) </li></ul><ul><li>“ both normal and abnormal operating conditions should be captured as derived requirements and addressed in the tests. Where necessary and appropriate, additional verification activities, such as analysis and review, may have to be performed to address robustness aspects. “ ( CAST-27 8.b ) </li></ul><ul><li>best practices : Dedicated tests should be produced during qualification (temp. , supply) </li></ul><ul><li>Deeper in-lab tests should be performed to check noise sensibility, critical timings … </li></ul>JB 2010 DO-254 Training Verification Process
  21. 21. Verification at PLD level JB 2010 DO-254 Training Plans Spec. Archit. Code Synth P&R Plans Spec. Archit. Schem P&R Verif. Integration Integration Test Plans Hard. Spec. Arch. Integration Test PLD CCA LRU Hard. Interf. Detail. System Spec. Safety Assessment Airworthiness Constraints Qualif. Verification Process
  22. 22. Verification Process at PLD level by tests <ul><li>Simulation performed on HDL model </li></ul><ul><ul><li>Standard simulation (log generated) </li></ul></ul><ul><ul><li>Self-check cases (SUCCESS/FAILURE) </li></ul></ul><ul><ul><li>Chronogram analysis (if needed) </li></ul></ul><ul><ul><li>Unitary, integration and top level tests (depending on design) </li></ul></ul><ul><ul><li>RTL and gate level simulations </li></ul></ul><ul><li>Qualification Testing on prototypes </li></ul><ul><ul><li>Functional Testing </li></ul></ul><ul><ul><ul><li>dedicated test board (reproduce simulation env.) </li></ul></ul></ul><ul><ul><ul><li>Final/ Mock-up CCA (actual application) </li></ul></ul></ul><ul><ul><li>Environmental Qualification Testing </li></ul></ul><ul><ul><ul><li>Robustness (temp., supply conditions) </li></ul></ul></ul><ul><ul><ul><li>Safety of flight (noise, vibration) </li></ul></ul></ul><ul><ul><li>Characterization </li></ul></ul><ul><ul><ul><li>Robustness (timing, electrical, power margins) </li></ul></ul></ul><ul><li>Integration </li></ul><ul><ul><li>Functional Testing on CCA (part of CCA verification activities) </li></ul></ul>JB 2010 DO-254 Training Verification Process
  23. 23. Traceability (part 2) <ul><li>“ Hardware traceability establishes a correlation between the requirements, detailed design, implementation and verification data that facilitates configuration control, modification and verification of the hardware item.” (10.4.1) </li></ul><ul><li>1. A correlation between the system requirements allocated to hardware and the requirements. </li></ul><ul><li>2. A correlation between the requirements and the hardware detailed design data. </li></ul><ul><li>3. A correlation between the hardware detailed design data and the as-built hardware item or assembly. </li></ul><ul><li>4. A correlation between the requirements, including derived hardware requirements, and detailed design data and the verification procedures and results. </li></ul><ul><li>5. The results of a traceability analysis. </li></ul>JB 2010 DO-254 Training Verification Process
  24. 24. Traceability activities <ul><li>Mandatory </li></ul><ul><ul><li>From HRS/HDD requirements to verification procedures coverage (HVCP) </li></ul></ul><ul><ul><li>From HRS/HDD requirements to verification results coverage (HVR) </li></ul></ul><ul><li>Additional </li></ul><ul><ul><li>Correlation between verification cases procedures description and HDL simulation code (conformity matrix) </li></ul></ul><ul><ul><li>Correlation between proposed means of verification (justification plan) and verification results (reports, analysis) </li></ul></ul>JB 2010 DO-254 Training Verification Process Traceability matrix example
  25. 25. Process Assurance <ul><li>“ Process assurance ensures that the life cycle process objectives are met and activities have been completed as outlined in plans or that deviations have been addressed.” (8.0) </li></ul><ul><li>“ The process assurance activities are primarily focused on monitoring the development activities to ensure that they are proceeding in accordance with the approved plans. For this project, the emphasis is on ensuring the internal consistency of the set of controlled data we accumulate throughout the development effort.” (case study NASA 2002) </li></ul><ul><li>“ Process assurance activities should be achieved with independence in order to objectively assess the life cycle process, identify deviations and ensure corrective action.” (8.0) </li></ul>JB 2010 DO-254 Training Process Assurance
  26. 26. Process Assurance Engineer activities <ul><li>Process Assurance Engineer may be a member of the Quality Department dedicated to the CEH project </li></ul><ul><li>Audits are an effective method for performing Process Assurance activities </li></ul><ul><li>Plan, design review, verification review, requirements review are audited then approved by PAE. More generally, each checklist used during reviews are audited by PAE. </li></ul><ul><li>Design, Validation and Verification audits may be based on sampling data and assessment of the completion of the design objectives (from requirements to implementation) </li></ul><ul><li>PAE participates in the approval of each of the design documents (plans, design documents, verification documents, HAS ..) </li></ul><ul><li>Participation to Risk assessment board </li></ul>JB 2010 DO-254 Training Process Assurance
  27. 27. Reviews <ul><li>Progress review are schedule milestones </li></ul><ul><ul><li>With customer (also called DRB, Design Review Board) </li></ul></ul><ul><ul><ul><li>IDR (initial Design Review / Kick Off Review), could include the Plan review </li></ul></ul></ul><ul><ul><ul><li>PDR (preliminary Design Review), check the Design (validation, conceptual or detailed) </li></ul></ul></ul><ul><ul><ul><li>CDR (Critical Design Review), check the Design and partial verification activities </li></ul></ul></ul><ul><ul><ul><li>FDR (Final Design Review) or FQR (Qualification), ready for certification </li></ul></ul></ul><ul><ul><li>With authorities </li></ul></ul><ul><ul><ul><li>SOI1 (Stage of Involvement), Plan review </li></ul></ul></ul><ul><ul><ul><li>SOI2 , Design Review </li></ul></ul></ul><ul><ul><ul><li>SOI3 , validation and verification activities </li></ul></ul></ul><ul><ul><ul><li>SOI4, final review, ready for certification </li></ul></ul></ul><ul><ul><ul><li>Note : Design Review Boards may be used as a drafting review of SOI reviews </li></ul></ul></ul><ul><ul><li>Best practices : reviews could be prepared with the support of had hoc checklists (increase review productivity) </li></ul></ul>JB 2010 DO-254 Training Process Assurance SOI checklists PDR
  28. 28. Reuse of PLD <ul><li>The intention to use previously developed hardware should be stated in the PHAC. </li></ul><ul><li>Initial baseline must be identified </li></ul><ul><ul><li>Specification </li></ul></ul><ul><ul><li>Design Data </li></ul></ul><ul><ul><li>Implementation data </li></ul></ul><ul><ul><li>Datasheet </li></ul></ul><ul><li>Configuration Management and Process Assurance considerations should also be addressed for each use of previously developed hardware. </li></ul><ul><li>Configuration management process should include </li></ul><ul><ul><li>Traceability from the hardware product and life cycle data of the previous application to the new application. </li></ul></ul><ul><ul><li>Change control processes that can manage change requests from different applications of the common item. </li></ul></ul>JB 2010 DO-254 Training Additional considerations : reuse
  29. 29. COTS microprocessor usage <ul><li>DO-254 + FAA AC 20-152 (June 2005) </li></ul><ul><li>“ Therefore, we don’t intend that you apply RTCA/DO-254 to COTS microprocessors. </li></ul><ul><li>There are alternative methods or processes to ensure that COTS microprocessors perform their intended functions and meet airworthiness requirements.” ( CAST-27 12.b ) </li></ul>JB 2010 DO-254 Training DO-178B Additional considerations : COTS and IP
  30. 30. COTS usage <ul><li>DO-254 (April 2000) </li></ul><ul><li>“ ..typically the COTS components design data is not available for review . </li></ul><ul><li>The certification process does not specifically address individual components, modules, or subassemblies, as these are covered as part of the specific aircraft function being certified. </li></ul><ul><li>As such, the use of COTS components will be verified through the overall design process . ( 11.2 Additional considerations ) </li></ul>JB 2010 DO-254 Training Additional considerations : COTS and IP
  31. 31. Tool assessment flow chart JB 2010 DO-254 Training Major question : output independently assessed ? False good idea : relevant history ? Additional considerations : tool assessment
  32. 32. Design assurance considerations for Level A and B functions <ul><li>The longest and most dense section of the DO-254 guidance. </li></ul><ul><li>DO-254 structured processes and strict development process objectives : </li></ul><ul><ul><li>Detect introduction or existence of errors then eliminate them </li></ul></ul><ul><li>For complex functions of level A&B (critical functions) this is not enough to eliminate all errors </li></ul><ul><li>For these additional architectural means to catch and detect errors are required </li></ul><ul><li>It is up to the applicant to select one or more of these methods or propose another method that would provide design assurance.” (appendix B) </li></ul><ul><li>Proposed additional methods : </li></ul><ul><li>Functional failure path analysis and methods </li></ul><ul><li>Design assurance methods for level A & B functions </li></ul><ul><ul><li>Architectural mitigation </li></ul></ul><ul><ul><li>Product service experience </li></ul></ul><ul><ul><li>Advanced verification methods </li></ul></ul>JB 2010 DO-254 Training Appendix B
  33. 33. It’s time to conclude JB 2010 DO-254 Training
  34. 34. Why should we adopt DO-254 approach ? <ul><li>DO-254 paves the way for better quality in your design. </li></ul><ul><li>DO-254 processes may be used for all your projects, in order to guarantee a constant level of quality </li></ul><ul><li>E.g. the independence criteria should be mandatory in all hardware designs (whatever the complexity) </li></ul><ul><li>DO-254 compliant set of data is the best way to optimize the reuse issue </li></ul><ul><li>It is also a powerful tool for subcontractor management </li></ul>JB 2010 DO-254 Training
  35. 35. DO-254 complaints <ul><ul><li>Additional workload with no added value </li></ul></ul><ul><ul><ul><li>Additional documents </li></ul></ul></ul><ul><ul><ul><ul><li>Loosing time writing formal docs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Actual design work very limited (less than 10%) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Proofreading and audit on documents are useless </li></ul></ul></ul></ul><ul><ul><ul><li>Additional reviews </li></ul></ul></ul><ul><ul><li>Project management issues </li></ul></ul><ul><ul><ul><li>Extra Delay on project schedule </li></ul></ul></ul><ul><ul><ul><li>Will we have time to do it? </li></ul></ul></ul><ul><ul><ul><li>Will it no be skipped due to strong project deadlines? </li></ul></ul></ul><ul><ul><li>Follow-up, problem reporting and change request impacts on schedule </li></ul></ul><ul><ul><ul><li>A minor and trivial change may impact a huge amount of data and document (generally with a redo of the design life cycle, from HDL code to component) </li></ul></ul></ul>JB 2010 DO-254 Training
  36. 36. DO-254 Advantages(2) <ul><li>Additional workload, with no added value </li></ul><ul><ul><li>Additional documents </li></ul></ul><ul><ul><ul><li>All agreements and design decisions are put on paper </li></ul></ul></ul><ul><ul><ul><ul><li>Forces designer to think about the design </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Problems due to miscommunication or misunderstanding are solved early and rationale is visible throughout the course of the project (important for years project) </li></ul></ul></ul></ul><ul><ul><ul><li>Facilitates transfer of design and knowledge to </li></ul></ul></ul><ul><ul><ul><ul><li>Subcontractor, other team :Loosing less time in explaining how it works, complete, unambiguous and self-sufficient data set. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Documentation : Can reuse design data in other docs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>test division : Explain the functionality and how to test </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Production : Understand the board </li></ul></ul></ul></ul><ul><ul><ul><li>Tools will help and automate certain activities </li></ul></ul></ul><ul><ul><li>Lot of reviews </li></ul></ul><ul><ul><ul><li>Helps to discover design errors early in the process </li></ul></ul></ul><ul><ul><ul><li>Team work : you’re not alone in the design </li></ul></ul></ul><ul><ul><ul><li>Better ideas by peer reviews </li></ul></ul></ul>JB 2010 DO-254 Training
  37. 37. DO-254 Advantages(3) <ul><li>Project management issues </li></ul><ul><ul><li>Additional Delays </li></ul></ul><ul><ul><ul><li>Less problems during production or at customer site means less time lost in </li></ul></ul></ul><ul><ul><ul><ul><li>Solving the actual problem </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Production stops </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Customer discussion </li></ul></ul></ul></ul><ul><ul><ul><li>Good requirement document with traceability </li></ul></ul></ul><ul><ul><ul><ul><li>Makes non-compliancy very clear and easier detectable </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Indicate clearly what still needs to be implemented </li></ul></ul></ul></ul><ul><ul><li>Skipped by time pressure </li></ul></ul><ul><ul><ul><li>Audits and review by QA will guarantee that the process is and will be followed </li></ul></ul></ul><ul><ul><ul><li>Deviations need to be justified and agreed upfront </li></ul></ul></ul><ul><ul><ul><li>Extra delay must be properly evaluated during the planning phase of the project </li></ul></ul></ul>JB 2010 DO-254 Training
  38. 38. DO-254 Advantages(4) <ul><li>Change impact </li></ul><ul><ul><li>Additional workload </li></ul></ul><ul><ul><ul><li>Avoid insignificant changes that occur at the project closure </li></ul></ul></ul><ul><ul><ul><ul><li>A management and organizational issue </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Each designer must be responsive for the quality of his production </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Who is able to decide that such change is insignificant in term of safety ? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>No exception allowed (process assurance responsibility) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Cost can be minimized with intensive use of automatic procedures and checklists. </li></ul></ul></ul></ul><ul><ul><ul><li>Change request from customer or from integration level </li></ul></ul></ul><ul><ul><ul><ul><li>A clear and documented process is preferable than a quick and undocumented patch. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Preserve future reuse or release </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Extra cost and delay must be evaluated and planned at the very beginning of the project (Risk management) </li></ul></ul></ul></ul>JB 2010 DO-254 Training
  39. 39. DO-254 Advantages(5) <ul><ul><li>Conclusion </li></ul></ul><ul><ul><li>All what is requested by DO-254 guidance is work design team have to do anyhow. </li></ul></ul><ul><ul><li>All processes and standards are based on best practices and may be used for non DO-254 projects </li></ul></ul><ul><ul><li>By formalizing it, we will avoid </li></ul></ul><ul><ul><ul><li>Redundant work </li></ul></ul></ul><ul><ul><ul><li>Useless discussions on not written statements </li></ul></ul></ul><ul><ul><ul><li>Forgetting things </li></ul></ul></ul><ul><ul><ul><li>Costly surprises at the end of project (not meeting specs) </li></ul></ul></ul><ul><ul><ul><li>Hidden features </li></ul></ul></ul><ul><ul><li>Avoiding all this will make </li></ul></ul><ul><ul><ul><li>Projects more predictable </li></ul></ul></ul><ul><ul><ul><li>Projects more manageable </li></ul></ul></ul><ul><ul><ul><li>Designs more reliable, robustness -> easier life for designers </li></ul></ul></ul><ul><ul><ul><li>More confidence in the design </li></ul></ul></ul><ul><ul><ul><li>Design more reusable </li></ul></ul></ul>JB 2010 DO-254 Training

×