Aircraft Systems Mechanical, Electrical and Avionics.pdf Chap System Design and Development

Transcription

1 UNIVERSITY OF SALENTO SCHOOL OF INDUSTRIAL ENGINEERING DEPT. OF ENGINEERING FOR INNOVATION Lecce-Brindisi (Italy) MASTER OF SCIENCE IN AEROSPACE ENGINEERING PROPULSION AND COMBUSTION Aircraft Systems Mechanical, Electrical and Avionics.pdf Chap System Design and Development LECTURE NOTES AVAILABLE ON Prof. Eng. Antonio Ficarella University of Salento - antonio.ficarella@unisalento.it REVIEW R00 DATE 15/12/2013 FILE RESPONSIBLE propasdesignr00.odp Antonio Ficarella antonio.ficarella@unisalento.it 1/40

2 INTRODUCTION 2/40 aircraft systems are becoming more complex and more sophisticated for a number of technology and performance reasons. In addition, avionics technology, while bringing the benefits of improved control by using digital computing and greatly increased integration by the adoption of digital data buses, is also bringing greater levels of complexity to the development process The design of an aircraft system is subject to many rigours and has to satisfy a multitude of requirements derived from specifications and regulations. Systems Design Development Processes life cycle for an aircraft or equipment - various activities

3 System Design 3/40 There are several agencies who provide material in the form of regulations, advisory information and design guidelines whereby aircraft and system designers may satisfy mandatory requirements. Key Agencies and Documentation Society of Automobile Engineers (SAE) - ARP ARP 4761 Federal Aviation Authority (FAA) Joint Airworthiness Authority (JAA) Air Transport Association (ATA) Radio Technical Committee Association (RTCA) - DO-178b - DO-254

4 4/40 ARP 4761 represents a set of tools and techniques ARP 4754 is a set of design processes DO-254 offers guidance for hardware design and development DO-178B offers advice for the design and certification of software

5 System Development Processes ARP /40 System development Certification process and coordination Requirements determination and assignment of development assurance level Safety assessment process Validation of requirements Implementation verification Configuration management Process assurance Modified aircraft

6 Methodologies and Techniques ARP /40 Functional Hazard Assessment (FHA) Preliminary System Safety Analysis (PSSA) System Safety Analysis (SSA) Fault Tree Analysis (FTA) Dependency Diagrams Markov Analysis (MA) Failure Modes and Effects Analysis (FMEA) Failures Modes and Effects Summary (FMES) Zonal Safety Analysis (ZSA) Particular Risks Analysis (PRA) Common Mode Analysis (CMA) Contiguous safety assessment process example

7 DO-178B Overview Design Assurance for Airborne Software 7/40 Introduction System Aspects relating to Software Development Software Life Cycle Software Planning Process Software Development Process Software Verification Process Software Configuration Management Process Software Quality Assurance Process Certification Liaison Process Overview of Aircraft and Engine Certification Software Life Cycle Data Additional Considerations

8 DO-254 Overview Design Assurance Guidance for Airborne Electronic Hardware Introduction System Aspects of Hardware Design Assurance Hardware Design Life Cycle Planning Process Validation and Verification Process Configuration Management Process Process (Quality) Assurance Certification Liaison Hardware Design Life Cycle Data Additional Considerations 8/40

9 9/40

10 Major Safety Processes 10/40 Functional Hazard Analysis (FHA) Preliminary System Safety Analysis (PSSA) System Safety Analysis (SSA) Common Cause Analysis (CCA)

11 Functional Hazard Analysis (FHA) 11/40 The FHA identifies system failures and identifies the effects of these failures. The FHA identifies the data in first two columns of the table

12 Preliminary System Safety Analysis (PSSA) 12/40 The PSSA examines the failure conditions established by the FHA(s) and demonstrates how the system design will meet the specified requirements. Various techniques such as Fault Tree Analysis (FTA), Markov diagrams design strategies which need to be incorporated in the system design to meet the safety requirements. system redundancy requirements, how many channels, control strategies, dissimilarity of control, dissimilar hardware and/or dissimilar software implementation. given the high degree of integration and interrelationship between major aircraft systems, this is likely to be a multi-system, multi-disciplinary exercise coordinating the input of many systems specialists

13 System Safety Analysis (SSA) 13/40 whereas the PSSA identifies the requirements, the SSA is intended to verify the that the proposed design does in fact meet the specified requirements

14 Common Cause Analysis (CCA) 14/40 The purpose of the CCA is to identify common cause or common mode failures in the proposed design and assist in directing the designers towards strategies which will obviate the possibility of such failures. Such common cause failures Failure to correctly identify the requirement Failure to correctly specify the system Hardware design errors Component failures Software design and implementation errors Software tool deficiencies Maintenance errors Operational errors

15 Requirements Capture 15/40 requirements capture is a key activity in identifying and quantifying all the necessary strands of information which contribute to a complete and coherent system design Top-down approach Bottom-up approach

16 Top-Down Approach 16/40 requirements capture by decomposing the system requirements into smaller functional modules

17 Bottom-Up Approach 17/40 The bottom-up approach is best applied to systems where some of the lower level functions may be well understood and documented and represented by a number of submodules

18 Fault Tree Analysis (FTA) 18/40

19 Dependency Diagram 19/40 The dependency diagram offers an alternative tool to the FTA for the analysis of architectural alternatives and also to establish whether a particular architecture will meet its mandated integrity goal The dependency diagram has the superficial advantage that its structure maps readily on to a system architecture diagram

20 Failure Modes and Effects Analysis (FMEA) 20/40 Failure modes are identified Mode failure rates are ascribed Failure effects are identified The means by which the failure is detected is identified

21 Component Reliability 21/40 failure rate of a component or element Analytical by component count Historical by means of accumulated in-service experience

22 Dispatch Reliability 22/40 Dispatch availability is key to an aircraft fulfilling its mission The ability to be able to continue to dispatch an aircraft with given faults has been given impetus by the commercial pressures of the air transport environment where the use of dual-redundancy for integrity reasons

23 23/40 This means of specifying the dispatch requirement of part of an aircraft system leads to an operational philosoph first step towards a philosophy of no unscheduled maintenance. For an aircraft flying 12 hours per day a typical utilisation for a widebodied civil transport this definition dictates a high level of availability for up to a 120 hour flying period. The ability to stretch this period in the future perhaps to 500 hour operating period as more reliable systems become available, could lead to a true system of unscheduled maintenance.

24 Markov Analysis 24/40 This approach is useful when investigating systems where a number of states may be valid and also are inter-related. This could be the case in a multichannel system where certain failures may be tolerated but not in conjunction with some failure conditions.

25 Development Processes 25/40 The Product Life Cycle

26 Concept Phase 26/40 The concept phase is about understanding the customer s emerging needs and arriving at a conceptual model of a solution to address those needs. The customer s requirement will be made available to industry so that solutions can be developed specifically for that purpose, or that can be adapted from the current research and development (R&D) base.

27 27/40

28 Definition Phase 28/40

29 29/40 Developing the concept into a firm definition of a solution Developing system architectures and system configurations Re-evaluating the supplier base to establish what equipment, components and materials are available or may be needed to support the emerging design Ensuring that materials are selected with knowledge of appropriate legislation determining their use to control Health & Safety and environmental issues Defining physical and installation characteristics and interface requirements Developing operational and initial safety models of the individual systems Quantifying key systems performance

30 Design Phase 30/40

31 Build Phase 31/40

32 32/40 In the case of some of the more complex, software-driven equipment, design will be overlapping well into the test phase Electrical models equipment electrically equivalent to the final product but not physically representative Red label hardware equipment which is physically representative but not cleared for flight Black label hardware equipment which is physically representative and is cleared for flight either by virtue of the flight-worthy testing carried out and/or the software load incorporated

33 Test Phase (Qualification Phase) 33/40

34 Operate Phase 34/40

35 Disposal or Refurbish 35/40 The process of disposal of aircraft and equipment needs care to be taken in the safe removal of hazardous materials and the most appropriate method of destruction, storage and reuse of materials.

36 Development Programme 36/40

37 V' Diagram 37/40 Level 1: Used in critical systems application and subject to the greatest levels of control in terms of methodology: quality, design, test, certification, tools and documentation Level 2: Used for essential applications with standards comparable to Level 1 but less stringent in terms of test and documentation Level 3: Used in non-essential applications and with less stringent standards generally equivalent to a good standard of commercial software

38 38/40

39 Extended Operations (ETOPS) 39/40 Extended Operations (ETOPS) of multi-engine aircraft was introduced in response to calls for the relaxation of operations of two-engine aircraft allowing them to be operated further from diversion airports than had previously been allowed. Under this guidance two-engine aircraft are allowed to fly up to 180 minutes from an airport suitable to receive the aircraft provided necessary criteria are met. In the meantime engine reliability as measured by the In-Flight Shut-Down (IFSD) has reduced to less than half that experienced in the mid-1980s. The major premise is based upon the aircraft-engine combination maintaining a target IFSD at or below 0.02 per 1000 engine hours which the model shows allows safe ETOPS flight for a 180 minute diversion.

40 40/40 the FAA has issued regulations permitting 240 minutes ETOPS for specific geographical areas such as polar routes These flights in the most severe operating conditions place demands not only upon the aircraft-engine combination but upon other systems such as fuel; ECS and pressurisation, cargo fire hold suppression, oxygen and others. Another requirement is for aircraft to be fitted with SATCOM when operating for more than 180 minutes to ensure that the flight crew can remain in contact with air traffic control throughout the ETOPS segment.