Resumen Inglés
Universidad Universidad Politécnica de Cataluña (UPC)
Grado Ingeniería de Aeronavegación - 3º curso
Asignatura Aviónica
Año del apunte 2017
Páginas 6
Fecha de subida 24/06/2017
Descargas 5
Subido por

Vista previa del texto

T-3 System Development Systems development is the process of: Defining, Designing, Testing, Implementing. Needed to ensure the end success and efficiency of the safety assessment process, hardware and software design.
ARP-4754A AIRCRAFT AND SYSTEM DEVELOPMENT PROCESS Aircraft Function Development: Typical aircraft functions may include: Flight Control, Aircraft Aspects of ATC, Automatic Flight Control, Engine Control, Collision Avoidance, Communication, Navigation, Passenger Safety… System implementation: - Information flow from the system process to the Hardware & Software processes: Requirements allocated to hardware and software; Development assurance level(s); Allocated failure rates and exposure interval(s) for hardware failures; System description; Design constraints; System verification activities; Evidence of the acceptability - Information flow to the system process from the Hardware & Software processes: Derived requirements; Description of hardware or software architecture; Evidence of system/item verification activities; Hardware failure rates; Problem or change documentation that may impact requirements; Any limitations of use; Data to facilitate integration of the H/S into the system; Details of proposed H/S verification activities - Information Flow between Hardware Design Life Cycle and Software Life Cycle Processes: Derived requirements needed for H/S integration; Instances where H/S verification activities require coordination; Identified incompatibilities between the H/S - Hardware/Software Design & Build: Electronic H/S integration procedures, Hardware drawings, Software source code, Breadboard or prototype hardware, Lab/flight test articles - Hardware/Software Integration (electronic): equipment under configuration control together with development assurance data and H/S life cycle data.
- Aircraft/System Integration: a verified integrated system, along with the data demonstrating that the system satisfies all functional and requirements.
INTEGRAL PROCESSES Development Assurance Level Assignment: - ERROR: An omitted or incorrect action by a crewmember or maintenance person, or a mistake in requirements, design, or implementation.
- FAILURE: An occurrence which affects the operation of a component, part or element such that it can no longer function as intended - FAILURE CONDITION: A condition influencing the aircraft and/or its occupants, direct or consequential, which is caused by failures or errors, considering flight phase and relevant adverse events - FUNCTION: Intended behavior of a product based on a defined set of requirements regardless of implementation - INDEPENDENCE: o Separation of responsibilities that assures the accomplishment of objective evaluation o Minimizes the likelihood of common mode errors and cascade failures between aircraft/system (with the severity of the Failure Condition Classification) ▪ Examples of Item Independence: Different technology, operating systems, computer/software languages, microprocessors ▪ Examples of Functional Independence: Decelerate on the ground (wheel brakes, engine thrust reversers and ground spoilers), Control direction on ground (nose wheel steering, differential braking, and the rudder at high speed), Control aircraft in the air (flight control surfaces and vectored thrust), Provide relative aircraft position (Communication and Navigation) - The Development Assurance Process: o establishes confidence that system development has been accomplished in a disciplined manner to limit the likelihood of errors o measure of rigor applied to the development process to limit the likelihood of Errors (safety level) occurring during the development process of aircraft/system functions and items that have an adverse safety effect.
o assigned depending on the classification of Failure Conditions considering the possible independence between development processes limiting the consequences of errors - Function development phase [FDAL]: requirements for Functions are developed and allocated to items; it includes validation.
Item development phase [IDAL]: items are developed: (DO254/ED-80 DO-178B/ED-12B) - Requirements Capture: Safety Requirements and Functional Requirements: Customer, Operational, Performance, Physical and Installation, Maintainability, Interface, Additional Certification Requirements Modifications to aircraft or systems: - Modification Process Overview: Develop a modification management process and co-ordinate it with all stakeholders, Perform modifications using the approved process, Conduct and document an initial modification impact analysis, Determine a classification for the modification, Integrate the modification into the item, system and aircraft, Conduct and document a modification summary, Maintain configuration control of data related to the modification - Modification Management Process: Description of the proposed modifications, Results of an initial modification impact analysis, Proposed modification implementation strategy, Implementation and integration of the modification using the agreed implementation strategy, Results of verification activities on the implemented modification, Results of the final modification accomplishment summary activities, Updates to the aircraft configuration management data - Modification Impact Analysis: o Safety related information is changed. For example: Failure condition classification(s) changed, Development Assurance Level, Safety margins are reduced, Architectural Assumptions, Validity of the environmental qualification test results is affected, V&V methods or procedures are modified o Operational or procedural characteristics are changed. For Example: Aircraft operational or airworthiness characteristics, Flight crew procedures, Increased pilot workload, Situational awareness, warnings, cautions or advisories, Displayed information to make flight decisions Results should be reflected in: The appropriate certification, The verification activities needed to assure that no adverse effects, The modification summary with impact of the modifications T-4 Hardware (ED-80/D0-254) Intent: ensure the safety of in-flight hardware by imposing a structured and rigorous development process.
System Processes: - feed information down into DO-254 - identifies requirements assigned to hardware items (DO-254) - ARP 4754A and ARP 4761 are the standards - Determines the design assurance level (DAL) of the hardware item based on function and safety analysis - DO-254 iterates with the System Process any time a modification to requirements affecting system Planning: first step in the DO-254 process - Capture precisely “how” project will meet all DO-254 - Main planning document is the Plan for Hardware Aspects of Certification (PHAC) which provides an overview of the compliance process and references the secondary documents involved - First Stage of Involment (SOI) audit is held at end of planning process Requirements Capture: first step in the Hardware Design - Expand requirements handed down - Writing precise, unambiguous, unique, complete and testable requirements is very important - Iteration with Req Cap occurs any time a new requirement is derived - Iteration with Sys Proc occurs any time a new or changed requirement affects the system Conceptual Design: second step - Examine validated requirements and form into a design concept: Block Diagram, High Level description, Focus on how safety requirements will be met Detailed Design: third step - Develop each requirement in detail: Writing HDL code, Synthesizing into technology specific netlist - Second audit, SOI-2, is held when the detailed design has stable requirements Implementation: fourth step - For FPGAs, the netlist is: Taken through back-end placement and routing processes, Turned into the devicespecific bitstream, Loaded into an FPGA device Product Transition: final step - Team test the processes to ensure they can get from the controlled design code to the exact same programmed FPGA device - SOI audit, SOI-4, is typically held - Demonstrating this process is the hand-off the Manufacturing Processes, beyond the scope of DO-254 Supporting Processes: - Validation and Verification: Validations means ensuring that the hardware device being developed has the right set of requirements (Are we building the right thing?); Verification means ensuring that the device, as it is being designed, meets the requirements (Are we building the thing right?). Third SOI audit, SOI-3, is held to demonstrate both simulation results and device performs its function - Configuration Management: means controlling each designated document, data item, design object, and tool that has significance in the project. It includes ensuring: Unique identification, Versioning, Access control, Archival - Process Assurance: task of monitoring the actual work being done against the plans. Process Assurance manager often runs mock audits to find and fix any deviations from plans prior to the actual audits held by the Certification Authorities - Certification Liasion: process of interacting with the certification authorities, (FAA or representatives). Occurs during various SOI audits COTS & IP/COTS IP COTS: Commercial-of-the-shelf: components, integrated circuits that are developed by a supplier for multiple customers, whose design and configuration are controlled by the specification from the suppliers or industry.
IP: Intellectual Property CAST (Certification Authorities Software Team) position is as follows: " COTS IP implemented in a custom micro-coded device for use in airborne systems should be commensurate with its intended use and should satisfy” T-5 Software (DO-178B/C) Software Planning: - Five Plans: PSAC (Plan for Software Aspects of Certification),SDP (Software Development Plan ), SVP (Software Verification Plan), SCMP (Software configuration management plan ), SQAP (Software Quality Assurance Plan ) - Three Standards: Software Requirement, Software Design, Software Coding Software Requirements Process: - Foundation to good software; - Refine Systems Requirements; - Allocate enough time; - Software Requirement Cycle; - Bi-Directional Tracing; - Baseline SWRD.
- More detailed requirements produced thought analysis of the system requirements and architecture.
Software Design: - Architecture: Structural-based, Object-oriented; - Low-level Requirements: Bi-Directional Tracing - SWDD Software Implementation - Coding: Languages and compilers, Good programming, Standards, Traceability - Integration: Build process, Load process, Analyze memory and addresses Software Integration Process (foto) Software Verification - Reviews: Plans, requirements, design, test data - Analyses: Code and integration, Coverage - Tests: RBTs, integration, Cases, procedures, results, Tracing - Verification of Verification: SCA, MC/DC; Test data reviews - Problem Reporting: Failures become PR or CR, PR or CR process, CIA - SVCP Software Configuration Management Beginning to End, All life cycle data, SCI: Life cycle data and versions, SLECI and Problem Reporting Software Quality Assurance Customer’s needs, Review plans and write SQAP, Life cycle data audits and approval, Reviews, Witness tests, builds, and loads, Problem reporting, Conformity review, Document activities for records Software Certification Develop and submit PSAC, PSAC approval, Submittal and approval of SCI and SAS, SOIs DO-178C Benefits - Greater upfront requirements clarity Fewer coding iterations, bugs, defects Improved configuration management, hardware integration, re-usability, customer satisfaction, management awareness of true schedule status, differentiation vis-à-vis your competitors Easier regression testing, More thorough testing Decreased single-point personnel failures, Wider market acceptance T-6 Transversal Activities Integral Processes (foto) Verification Process Verification Model: Verification Planning: - Identification of the system or item configuration - Collation of all requirements appropriate to the considerate level - Definition of the specific verification methods to be employed to show compliance with each requirement, based on the development assurance level.
- Definition of the criteria to be used to assess the evidence resulting from each verification method applied.
- Identification of system verification credit taken for hardware or software verification activities.
Verification Methods: - Inspection and Review: See if fulfill the requirements; Inspection that the system or item meets established physical implementation and workmanship requirements; Design reviews showing how the system or item is expected to perform in normal and non normal conditions.; Test reviews establishing the applicability of test cases to system or item requirements.
- Analysis: Examination - Test: corrected and completed; o For each test, must be specified: Required inputs; Actions required; Expected results and the tolerances associated with those results.
o Test result data should contain, as a minimum, the following: The version of the test specification used and of the system or item being tested; The version or reference standard for tools and equipment used, together with applicable calibration data; The results of each test including a PASS or FAIL declaration; The discrepancy between expected and actual results; A statement of success or failure of the testing process including its relationship to the verification program.
- Service Experience: If system used before or new… - Traceability: Outcome of one phase compiles with requirements initially established for that Verification Data: - Verification Plan: strategies to show how the implementation satisfies its requirements . A verification plan might include: Roles and responsibilities associated with conducting the verification activitie; Description of the degree of independence of the design and verification activities; Application of verification method(s); Data to be produced; Sequence of dependent activities;A schedule of key verification activities.
- Procedure and results must be written - Verification Matrix must be build (foto) - Verification Summary : provides visibility for the evidence used to show that the system or item implementation satisfies its requirements. The summary should include: A reference to the verification plan and a description of any significant deviations from the plan; The verification matrix; A reference to the problem report system; A description of any open problem reports and an assessment of the related impact on safety; dentification of supporting data or data sources Software Verification Process Configuration Management Objectives: Replication capability, Fluxes Control, Evidence generation for approval, Traceability Activities: Identification, Baselines and Traceability, Change revision, Reports about configuration state, Control of lifecycle environment, Data control category Quality Assurance Process Objectives: - Plans: To ensure the necessary plans are in place or developed, and then maintained for all aspects of system development - Development according to plan: To ensure development activities and processes are conducted in accordance with those plans.
- Evidence available: To ensure evidence is available to show the implementation of the plans.
Process Assurance Plan: - Project communications, coordination and sequencing, and progress monitoring mechanisms are defined - Change control, operational, and maintenance procedures are defined.
- Sufficient project review opportunities are defined to best achieve the timely detection of development errors.
- Sufficient coordination with the certification authorities is planned.
Activities Project Plan Reviews: - Applicable procedures and practices are documented - Defined communication practices ensure the timely exchange of information between the applicable processes and affected personnel.
Planning Update Procedures: for plan updates due to process, schedule, or technical changes are defined Planning Update Tracking: Plan updates are appropriately tracked and controlled Evidences: - Dated and approved project plans - Reports, metrics, and summaries of reviews, as required by the plans - Actual data developed from design, verification, validation, configuration management, and certification activities - Confirmation of timely process assurance reviews Certification Liaison Objectives Evidences: Propose a certification plan - A functional and operational description of: aircraft on which the system will be installed; the system elements. It should establish the functional, physical, and information relationship between the system and other aircraft systems and functions.
- A statement of the relationship of this certification plan to any other relevant system certification plan(s.) - A summary of the functional hazard assessment and of the preliminary system safety assessment (system safety objectives and preliminary system development assurance levels.).
- A description of unique design features used in meeting the safety objectives.
- A description of the new technologies to be implemented.
- The system certification basis including any special conditions.
- The proposed methods of showing compliance with the certification basis, including an outline of the anticipated development assurance processes - A list of the data to be submitted and the data to be retained under configuration control, along with a description or sample of data formats.
- The approximate sequence and schedule for certification events.
- Identification of the personnel or specific organization responsible for certification coordination.
Activities; Certification Authorities; EASA Involved Regulations; SAE Recommendations; Authority migration ...