ASTM F3153-22

This document is not an ASTM standard and is intended only to provide the user of an ASTM standard an indication of what changes have been made to the previous version. Because
it may not be technically possible to adequately depict all changes accurately, ASTM recommends that users consult prior editions as appropriate. In all cases only the current version
of the standard as published by ASTM is to be considered the official document.
Designation: F3153 − 15 F3153 − 22
Standard Specification for
Verification of AvionicsAircraft Systems and Equipment
This standard is issued under the fixed designation F3153; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope
1.1 This specification provides a process by which the intended function and compliance with safety objectives of avionics
systems may be verified by system-level testing.for performing system level verification of aircraft systems and equipment. It
provides a means of compliance that can be used for systems and equipment with software and Airborne Electronic Hardware
(AEH) that have not been addressed by traditional development assurance methods.
1.2 This process can be used to show compliance to regulations that require a demonstration that functionality was implemented
as intended, including safety mitigations that address failure conditions for software and AEH aspects for aircraft systems and
equipment.
1.3 While this specification was developed with systems and equipment installed on aircraft certification level 1 and 2 (or class
I and II in accordance with Advisory Circular (AC) 23.1309-1) normal category aeroplanes in mind, the content may be more
broadly applicable. It is the responsibility of the Applicant to substantiate broader applicability as a specific means of compliance
and obtain concurrence for its use from the applicable Civil Aviation Authority (CAA).
1.4 Software and hardware development assurance are not in the scope of this specification and this specification should not be
used if a development assurance process is required.When using this specification, regulations that govern system safety
requirements applicable to the aircraft still apply. In complying with those regulations, additional architectural mitigations such as
redundancy, independence, separation, system monitors, etc., may be required in addition to the verification process specified in
this specification.
1.5 The specification intentionally does not attempt to define its own applicability with regard to the type, category, class of
aircraft, or criticality of function to which avionics systems verified by the specification may be applied as doing so could
ultimately place system level verification activities expected by this specification increase as the severity of the failure conditions
applicable to or affected by the function increase. Those functions, which have hazardous and catastrophic failure conditions,
receive additional activities through this process to provide detailed scrutiny. For normal category aircraft, refer to Practice F3309,
Practice F3230the language of the specification in conflict with external requirements and guidance. Aircraft applicability, intended
use, and limitations must ultimately be determined by the designer, installer, and recognizing body., or AC 23.1309-1 for more
information on the identification and classification of system failure conditions. Involvement of the applicable CAA personnel or
their designees in this system verification process should be discussed early in the project.
1.6 This verification process specifically addresses definition, identification, and verification of system functions. Processes
This specification is under the jurisdiction of ASTM Committee F39 on Aircraft Systems and is the direct responsibility of Subcommittee F39.03 on Design of Avionics
Systems.
Current edition approved July 15, 2015April 1, 2022. Published September 2015April 2022. Originally approved in 2015. Last previous edition approved in 2015 as
F3153–15. DOI: 10.1520/F3153-15.10.1520/F3153-22.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
F3153 − 22
conducted under this specification may not satisfy all applicable external requirements; additional review on the part of the system
developer, integrator, or installer may be required to meet specific requirements or the specified mission of the aircraft, or both.
1.7 The values stated in inch-pound units are to be regarded as standard. No other units of measurement are included in this
standard.
1.8 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility
of the user of this standard to establish appropriate safety safety, health, and healthenvironmental practices and determine the
applicability of regulatory limitations prior to use.
1.9 This international standard was developed in accordance with internationally recognized principles on standardization
established in the Decision on Principles for the Development of International Standards, Guides and Recommendations issued
by the World Trade Organization Technical Barriers to Trade (TBT) Committee.
2. Referenced Documents
2.1 ASTM Standards:
F3060 Terminology for Aircraft
F3061/F3061M Specification for Systems and Equipment in Aircraft
F3230 Practice for Safety Assessment of Systems and Equipment in Small Aircraft
F3309 Practice for Simplified Safety Assessment of Systems and Equipment in Small Aircraft
2.2 Aeronautical Radio, Inc. (ARINC) Standard:
ARINC Mark 33 Digital Information Transfer System (DITS), Specification 429, Parts 1–15, November 2012
2.3 Federal Aviation Administration (FAA) Advisory Circular:
AC 23.1309-1E System Safety Analysis and Assessment for Part 23 Airplanes
2.4 RTCA Standards:
DO-178( ) Software Consideration in Airborne Systems and Equipment Certification
DO-254( ) Design Assurance Guidance for Airborne Electronic Hardware
3. Terminology
3.1 The following are a selection of relevant terms. See Terminology F3060 for more definitions and abbreviations.
3.2 Definitions:
3.2.1 defect, n—an unexpected or improper behavior.
3.2.2 intended function, n—a capability the system is designed to provide when installed on an aircraft.
3.2.3 system, n—a combination of components, parts, and elements that are interconnected to perform one or more functions.
3.2.4 test scenario,case, n—a set of inputs, pre-conditions, execution steps, expected results, and pass/fail crtieria defined by the
manufacturer to verify proper function. Test scenarioscases are derived from the intended functions established for the system.
3.2.5 verification, n—confirmation, through the collection and review of objective evidence, that specified requirements have been
fulfilled.
4. Process Overview
4.1 Fig. 1 provides an overview of the system verification process defined by this specification.
5. Organizational RequirementsConfiguration Management
5.1 An organization complying with this specification shall manage under configuration control all life cycle data which are
For referenced ASTM standards, visit the ASTM website, www.astm.org, or contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM Standards
volume information, refer to the standard’sstandard’s Document Summary page on the ASTM website.
Available from ARINC Industry Activities, SAE ITC, 16701 Melford Blvd, Suite 120, Bowie, MD 20715, https://www.aviation-ia.com/product-categories/arinc.
Available from FAA’s Dynamic Regulatory System, Federal Aviation Administration, 800 Independence Avenue, SW, Washington, DC 20591, https://drs-uat.faa.gov/
browse.
Available from RTCA, 1150 18th NW, Suite 910, Washington, D.C. 20036, https://www.rtca.org.
F3153 − 22
FIG. 1 System Verification Process Overview
generated by applying this specification.must have a documented engineering configuration management process that is used for
any system whose function is verified by this process.
5.2 The organization shall keep a record of the documentation used to show compliance of each approved system configuration
produced to all applicable consensus specifications and regulatory requirements in effect at the time of manufacture.At a minimum,
this engineering configuration management process shall:
5.2.1 Uniquely identify and control the configuration of all system artifacts and data generated under this process.
5.2.2 Keep a record of the documentation used to show compliance of each approved system configuration produced to all
applicable consensus specifications and regulatory requirements in effect at the time of manufacture up to system retirement.
5.2.3 Ensure that changes to the system and documentation affecting compliance are tracked and the change process for
developing, reviewing, and incorporating revisions to compliance documentation is controlled.
5.2.4 Ensure that the most recent and appropriate revision of data, or the revision documented in the plans, is used during each
verification activity.
5.2.5 Establish a problem-reporting process to capture, document, communicate, and track system defects to their resolutions and
closure. A summary of the problem reports should be made available to the certifying authorities.
F3153 − 22
5.2.5.1 Problem reports are required to track any defects and their impact on the system.
5.2.5.2 Problem reports must be used for tracking resolution and closure of system defects.
5.2.5.3 When justifying the deferral of an open (that is, unresolved) problem report to a future system revision, it must be shown
that the system is safe and compliant with the applicable regulations.
4.3 Revisions to documentation affecting compliance shall be tracked and the change process for developing, reviewing, and
incorporating revisions to compliance documentation shall be controlled.
4.4 The organization must ensure and verify the use of the proper revision of any compliance document.
6. Product Definition ProcessPhase
6.1 Function Identification:System Description:
6.1.1 Document the intended function(s)Provide a thorough description of the system. This description should include information
such as:
6.1.1.1 Textual description of the system operation.
6.1.1.2 List of all inputs and output parameters at the system level.
6.1.1.3 Block diagrams.
6.1.1.4 System schematics.
6.2 Function Classification:Intended Function:
6.2.1 Identify and document the intended functions performed by the system.
6.2.2 For each function identified underin 5.16.2.1, determine and document whether it is tothose functions that will be verified
under this specification or by other means.specification. Identify which functions shall be verified through other means,
NOTE 1—Other means of verification may be proprietary or may be based on other standards, as best suits the developer’s objectives with regard to safety,
marketability, and compliance concerns. and reference the process to be used.
6.2.3 For each function identified in 6.2.2:
6.2.3.1 Identify the failure conditions applicable for each function.
NOTE 1—This information is typically generated as part of the system safety assessment process. It is not expected that the applicant recreate the failure
condition analysis for this specification, but to utilize the information from the Functional Hazard Assessment (or equivalent) that would be generated
as part of the system safety assessment process. For normal category aircraft, refer to Practice F3230, Practice F3309, or AC 23.1309 for more information
on the identification and classification of system failure conditions.
NOTE 2—The system verification should include the range of failure conditions expected in the inputs/outputs and computation/communication aspects
of the various functions in the system. This would include hard failures (open circuits, short circuits, out-of-range input/output (IO) devices and
interfaces); and soft failures (drifts, offsets, in-range erratic behavior, repetitive intermittence).
6.2.3.2 Define and document the environmental and operating conditions to be supported by the system. While it is beyond the
scope of this specification to address environmental qualification of the system hardware, this action will provide a clear
understanding of the intended system functionality and performance under expected operating and environmental conditions. For
example, a primary display may be intended for installation on aircraft that support operation in Instrument Flight Rules (IFR) into
known icing conditions up to 26 000 ft. The requirements and subsequent verification performed in this specification should be
appropriate to support functionality of the system through the range of expected conditions.
F3153 − 22
6.3 Function Specification: Define System Level Requirements:
6.3.1 For each function identified for verification under this specification in 5.26.2.2, document the specifications of the function,
including:specify the system level requirements that define the following:
6.3.1.1 A description of the function,The proper operation and performance of the system when performing its intended function.
6.3.1.2 An explanation of the intended use of the function, andThe system mitigations that protect against failure conditions (such
as monitors, annunciations, redundancy, independence, etc.).
NOTE 3—If the mitigation is provided by another system that is not verified under this specification, such as Technical Standard Order Authorization
(TSOA) appliance, then this step is not required.
6.3.1.3 Operating parameters or limitations that apply to the function.The expected system behavior given abnormal system inputs
or
NOTE 2—The requirements of 5.1 and 5.3 may be met by a suitably annotated copy of the system’s user or installation manual or by means of reference
to a third-party specification (such as a TSO minimum performance standard). operating conditions.
NOTE 4—The depth of the system requirements needed to adequately define the function will depend on the criticality of the functions provided by the
system. For example, the music radio function of a datalink entertainment system could likely be defined by a very simple set of high-level requirements.
Whereas a function that provides primary flight information would require a more detailed set of requirements to define its intended function and proper
operation.
NOTE 5—The requirements of 6.1 and 6.3 may be met by a suitably annotated copy of the system’s user or installation manual or by means of reference
to a third-party specification (such as a Technical Standard Order (TSO) minimum performance standard). Refer to Appendix X2 of this specification for
more guidance on ACs and Minimum Performance Standards (MPS).
7. Verification Methods
7.1 Verification of system level requirements established in accordance with 6.3 can be accomplished by one or more of the
following verification methods:
7.1.1 System Level Verification Testing and Demonstration:
7.1.1.1 The “Test” verification method is the verification of a system using a controlled and predefined series of inputs, data, or
stimuli to ensure that the system will produce a very specific and predefined output as specified by the requirements. When a
system model is used to generate inputs, data, or stimuli for a verification test, the predictive properties and limitations as compared
to the physical system should be assessed and documented.
7.1.1.2 Demonstration is the manipulation of the system as it is intended to be used to verify that the results are as expected.
7.1.1.3 For purposes of this specification, testing and demonstration methods should be considered and documented in the same
way.
7.1.1.4 Verification of system requirements by test or demonstration shall be accomplished using Section 8.
7.1.2 Inspection:
7.1.2.1 Inspection is the nondestructive examination of a system using one or more senses (for example, visual, auditory, tactile,
etc.). It may include but is not limited to simple physical manipulation and measurements.
7.1.2.2 Verification of system requirements by inspection shall be accomplished using Section 9.
7.1.3 Analysis:
F3153 − 22
7.1.3.1 Analysis is the verification of a system using models, calculations, or testing equipment, or combinations thereof. Analysis
allows someone to make predictive statements about the expected system performance based on extrapolation of known data and
assumptions.
7.1.3.2 Verification of system requirements by analysis shall be accomplished using Section 10.
7.2 For each function and associated system level requirements, the applicant shall identify which verification method will be
used. It is expected that most of these requirements will be addressed by system level verification testing. However, some
requirements may be more appropriately addressed by one or more of the other verification methods listed in 7.1.
8. Verification ProcessTests/Demonstration
8.1 Functional Verification Test Planning:
6.1.1 Document the system test plan.
8.1.1 For each function identified for verification under this specification insystem level requirement identified as requiring
verification by test/demonstration, the applicant 5.2:shall document the system verification test plan(s) that define one or more test
cases and pass/fail criteria.
8.1.1.1 Define a series of test scenarios and pass/fail criteria that trace to the functional requirement and that verify the function’s
correct operation within the set limits. In When developing the test scenarios, cases, the applicant should consider known failures
in similar systems or components, or both.
8.1.1.2 Testing may be conducted using bench tests, aircraft ground and flight tests, or a combination thereof, as appropriate for
the function being evaluated.
8.1.1.3 The test scenario should include failure conditions when appropriate and important to the system level function.These tests
plans shall include test cases needed to verify proper function of the system under normal
NOTE 3—Where applicable, make use of a functional, non-functional, ground, and flight tests, providing direct reference to the specifications documented
in 5.3 that make this specific test necessary. and abnormal conditions. Appendix X1 provides guidance on the types of normal and
abnormal conditions that should be considered when developing this test plan.
8.1.2 Test plans/procedures must:
8.1.2.1 Be performed on test articles that are representative of the final system configurations that will be approved. To accomplish
this, the following should be included:
(1) Include the definition of the test article(s) and test setup(s) on which testing is to be performed.
(2) Identification (for example, part number and revision) of test article(s).
(3) Document the test equipment required, including models or simulations if used, to generate inputs, data, or stimuli, and
calibration requirements.
8.1.2.2 Provide a trace between the test cases and the system requirements that they verify.
8.1.3 A review of the test plan shall be conducted to ensure that the test plan fully represents the system requirements, verifies
interactions between requirements and functions, and performs robustness testing for normal operations and failure conditions.
NOTE 6—Applicants may choose to document their test plans as one or more documents. Some CAAs may want participation by their specialists or their
designee in some aspects of this testing. Consideration should be given to packaging those aspects in their own test plan(s). It is the responsibility of the
applicant to establish participation expectations with the CAA early in the program.
6.2 Testing:
6.2.1 Execute the previously defined test scenarios.
6.2.2 Review test results and document pass/fail for each test scenario.
F3153 − 22
8.2 Test Failure Resolution: Conducting System Level Verification Tests:
8.2.1 Establish test article(s) and test setup(s) required by 8.1.2.1.
NOTE 7—Some CAAs may require some of these tests to
...