1、 StandardAIAA S-117A-2016 Space Systems Verification Program and Management ProcessAIAA standards are copyrighted by the American Institute of Aeronautics and Astronautics (AIAA), 12700 Sunrise Valley Drive, Reston, VA 20191-5807 USA. All rights reserved. AIAA grants you a license as follows: The ri
2、ght to download an electronic file of this AIAA standard for storage on one computer for purposes of viewing, and/or printing one copy of the AIAA standard for individual use. Neither the electronic file nor the hard copy print may be reproduced in any way. In addition, the electronic file may not b
3、e distributed elsewhere over computer networks or otherwise. The hard copy print may only be distributed to other employees for their internal use within your organization. AIAA S-117A-2016 Standard Space System Verification Program and Management Process Sponsored by American Institute of Aeronauti
4、cs and Astronautics Approved 3 June 2016 Abstract This standard is an AIAA mandatory 5 year review version of the original AIAA S-117-2010. This updated version continues to be intended for commercial/noncommercial manned or unmanned space programs to achieve a key Mission Assurance goal of “Robust
5、yet Cost Effective” systems by enforcing a “distributed” verification program for planning and executing “system is built right” verification activities It provides a set of requirements that utilizes a standardized set of “six” verification management processes starting from the earliest phase and
6、the lowest level of a program to develop a robust system since even a single overlooked deficiency could cause very costly late changes or catastrophic post-launch failures of any heritage/new space systems. AIAA S-117A-2016 ii As such, it corrects fundamental problems associated with the traditiona
7、l “centralized” approach, those dictated by “Total System Program Responsibility (TSPR)”, or “Faster, Better, Cheaper” policy that often caused program failures due to overlooking deficiencies in their systems. Finally, this verification standard facilitates the closely coordinated verification and
8、validation (V however, it is generically used to refer to any part of a system in this standard (i.e., all systems, in general, have multiple components that require multiple levels of integration). AIAA S-117A-2016 4 External interfaces (External IFs) Physical, data, and operational connections ori
9、ginating with the developed system and terminating with other systems at the same or higher levels of integration NOTE External IFs normally relate to interfaces between systems that are developed or used by different agencies, customers, or contractors. These IFs are in general defined through inte
10、rface requirement documents (IRDs) that capture both technical and programmatic requirements for the IFs. Subsequently, interface control documents (ICDs) that capture more detailed technical requirements will be established in order to design and develop systems that satisfy these requirements. Gro
11、und segment Earth-bound portion of a Space System mission NOTE Satellite Control Networks (SCN), such as Air Force SCN as well as Satellite Communications (SATCOM) Terminals, are also considered as a part of Ground Segment. These Networks/Terminals perform transmission of commands, data uploads, veh
12、icle control, telemetry receipt, and data processing. They perform these functions using operational control nodes, satellite operations centers, geographically dispersed remote tracking stations/terminals, antennas, and networks to connect the many elements. Ground support equipment Earth-bound equ
13、ipment, in addition to the launch pad facilities, that is required by a specific launch vehicle, or by a space vehicle prior to launch NOTE Ground support equipment excludes the user segment equipment used for communications, control, and data processing of the space system vehicle and its payload.
14、Internal interfaces (Internal IFs) Physical, data, and operational connections between components within a system NOTE Internal interfaces generally refer to component-to-component interfaces such as those within space launch vehicles or ground stations that are built for the same customer. However,
15、 space vehicle-to-ground or space vehicle-to-launch vehicle interfaces could be referred to as external interfaces for space vehicles, launch vehicles, or ground station builders, even though these components are built for the same customer. Launch segment Portion of the space system mission in whic
16、h the space vehicle is transported from the ground to its operational orbit Launch segment equipment Used for transporting space vehicle(s) to its (their) operational orbit(s) NOTE The Launch segment equipment can include the launch vehicle, launch-related Ground Support Equipment, launch pad facili
17、ties, Range Safety systems, and any launch control operations. Space segment Refers to the exoatmospheric portion of the Space System Mission NOTE The Space Segment may employ equipment, such as the space vehicle, post-launch maneuvering system, and any other space-based systems needed to perform th
18、e identified tasks during the space segment. Space systems (SS) Consists of equipment and/or people that are employed during the ground, launch, space, and user segments to perform coordinated tasks to achieve the objective of a space systems mission AIAA S-117A-2016 5 NOTE This standards focus is o
19、n the verification management associated with the space segment, launch vehicle, and ground segment including satellite control network terminals such as those belonging to the Air Force SATCOM system. Space system (SS) mission Consists of ground, launch, space, and user segments in which predetermi
20、ned tasks are performed in a coordinated manner to achieve a specific objective or mission Space vehicle Generally consists of the spacecraft bus, payload (such as for observation or detection sensors, communication relay modules, etc.), associated subsystems, units, and the internal and external in
21、terfaces User segment The portion of a Space System Mission in which the collective group of government agencies or commercial entities (organizations and individuals) uses and controls the space segment payload and its products NOTE The user segment consists of data receiving and processing equipme
22、nt, the raw or processed data, and the distribution system used to get the data to the customer. 4.2.2 System verification and validation related definitions Integration and test (I it should not subject the system to potentially damaging situations; it complements but does not replace other forms o
23、f perceptive testing (e.g., environmental, stress, performance and functional testing) (2) Operationally realistic “Like You Fly” (LYF) tests A test that represents the mission in terms of phase, transitions, environments, and events in an end-to-end system configuration (i.e., combination of hardwa
24、re/software and data when functioning as an AIAA S-117A-2016 6 integrated system), accepting mission inputs, executing mission functions and producing mission outputs according to the typical operational rhythm, timelines, and sequences resulting in end-user goals (products, services, and timeliness
25、). It may be referenced as an end-to-end, days-in-the-life (DITL) or weeks-in-the-life (WITL) mission operability test NOTE “Like You Fly” testing is a method to find flaws in the actual system to assure its ability to perform the mission post-launch. (3) Mission Characteristics. Operationally reali
26、stic characteristics include all aspects for operations in terms of components, conditions, transitions, transactions, processes, and environments. Characteristics are (a) end-to-end configuration,(b) time, sequence, and timeline, (c) environments (internal, ascent, space, command, ground and teleme
27、try), and (d) any relevant operational conditions that are present during the mission (people, processes, procedures). (4) Mission Critical Failure A condition that meets one or more of the following criteria: (a) Failure leading to inability to meet/achieve mission objective (e.g., payload or space
28、craft bus is no longer capable of supporting the mission objectives) (b) Inability to meet minimum performance specifications for primary mission (c) Degrading condition whose trend indicates a loss of mission before mean mission duration (MMD) or design life (d) Repetitive transient condition(s) th
29、at, uncorrected, would lead to an unacceptable loss of mission performance, data or services (e.g., satellite with processor susceptibility to single event upsets in orbit with mean time to upset much less than mean time to recovery from upset). System verification System verification addresses whet
30、her the overall system and its components, including interfaces, satisfy each specification, that is, the verification ensures the conformance to each requirement of their specifications; that the system has been built right (Reference 2) System verification program and process Verification program
31、and its processes ensure that the design, as produced, has resulted in a physical product that satisfies every requirement of a specification with the proof and traceable documentations NOTE 1 The verification program and its processes must be applied to ensure that each component specification and
32、associated requirements are properly established, and designs and analyses, manufacturing, and tests are properly completed with the documented evidence to show the proof of satisfaction against every requirement at its sell-off. NOTE 2 Writing the verification requirements is an integral part of es
33、tablishing the performance, functional, and other requirements that are recorded in specifications. Validation Confirms that each system level as built (or as it will be built) satisfies the stakeholders stated needs involving the buyer/third parties. NOTE 1 Requirement validation confirms the “righ
34、t system is being built“ (Reference 2). AIAA S-117A-2016 7 NOTE 2 In addition to Reference 2, other systems engineering standards, handbooks or papers such as References 3 and 4 are recommended for the general definitions of verification and validation (V fabrication, assembly, integration, and test
35、; operations; sustainment; and end-of-life product disposal or recycling), and any other work products (plans, baselines) required for the development of the system (see Reference 2). NOTE 3 See Annex A for an example of a required WBS-WG based Verification Management (VM) structure. NOTE 4 The deve
36、lopment phase of a program in this context encompasses those phases starting from authority to proceed (ATP) after contract award to requirements flow-down/specification development, design/analysis, manufacturing, and test (including factory and launch site tests), and sell-off phases. Initial on-o
37、rbit test that is considered as a part of the “system is built right” Verification plan as opposed to On-orbit flight certification which is a part of “Right system is built” Validation activities by the customer must be developed. NOTE 5 The formation of WBS-WGs enables well-coordinated and integra
38、ted verification activities for each individual component as well as the overall system that are being developed. Each WBS-WG will be populated by representatives from the other WBS-WGs as well as third parties such as the customer or contractors other organizations external to those developing the
39、system. This WBS-WG will be active on a continual basis throughout the development and delivery phases of its responsible system. 5.1.2 Verification management board or equivalent review board The SS verification management or equivalent review board shall be formed to officially ensure that (1) WBS
40、-WG activities are properly planned and executed such that their activities are consistent with the AIAA S-117A-2016 10 overall verification program and (2) configuration management is properly applied for WBS-WG activities and the overall verification program. NOTE SS Verification management board
41、or equivalent review board may be formed under a subset of program management or other review boards as long as it accomplishes the aforementioned review activities and associated configuration management for their verification program. 5.1.3 SS verification program flow-down to subcontractors and v
42、endors The requirement for establishing the verification program and verification management process described in 5.1 shall be flowed-down from the prime contractor to the subcontractors and vendors who supply HW/SW used by the developing system. NOTE This requirement is to ensure that every level o
43、f system development implements a standard set of verification management processes regardless of where the systems or lower-level systems are developed. 5.1.4 Verification activities coordinated with other review boards Each of the WBS-WG based verification activities shall be conducted by closely
44、working with programmatic and technical review boards such as Requirement Change Board, Configuration Control Management Board, Program Risk Management Board, Power-Weight Management Board, Parts, Materials and Processes Control Board, Failure Review Board as well as Quality Assurance Management Boa
45、rd. NOTE 1 SS-Verification Management Board or equivalent review board will facilitate well coordinated verification activities with other discipline groups. NOTE 2 Each space program may/may not officially establish any of these review boards depending on the programs complexity and budget as long
46、as the functional requirements associated with each of these technical/programmatic disciplines are properly/systematically addressed and satisfied throughout the development of the associated space system. 5.1.5 Coordination with validation activities including Development Test and Evaluation (DT a
47、lso included are the cross-cutting areas of documentation and configuration management. NOTE 4 It is recommended that a set of specific technical standards/guides, such as those relating to safety, mass properties management, critical clearance, radiation effects, electromagnetic interference/compat
48、ibility, failure mode and effect analysis, reliability, battery, solar cell/array, etc., be identified as compliance documents in the development of a space system. These list can be developed based on /proven documents such as those developed and published by NASA, AIAA, SMC, NRO, or ISO. (1) Examp
49、le 1: It is also recommended that NASA Verification Handbook, MSFC-HDBK-2221, Vols. 1 (b) capturing all the “derived” and specific requirements that are necessary to design and develop their system; and (c) capturing/modifying all the heritage system requirements that are compatible with the top-level requirements determined by the requirements flow-up process. 5.3.1.1 Flow-down/Flow-up requirements and CONOPS review The plan and results of the requirement flow-down/ flow-up from the top system level to the lowest unit level specifications and vice versa shall be deliver
