AIAA S-117-2010 Space Systems Verification Program and Management Process《空间系统验证计划和管理过程》.pdf

《AIAA S-117-2010 Space Systems Verification Program and Management Process《空间系统验证计划和管理过程》.pdf》由会员分享，可在线阅读，更多相关《AIAA S-117-2010 Space Systems Verification Program and Management Process《空间系统验证计划和管理过程》.pdf（41页珍藏版）》请在麦多课文档分享上搜索。

1、 Standard AIAA S-117-2010 Space Systems Verification Program and Management Process AIAA standards are copyrighted by the American Institute of Aeronautics and Astronautics (AIAA), 1801 Alexander Bell Drive, Reston, VA 20191-4344 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-117-2010 Standard Space System Verification Program and Management Process Sponsored by American Institute of Aeronautic

4、s and Astronautics Approved November 2010 Abstract This document enforces a systematic approach to planning and executing verification programs for manned and unmanned space systems based on a distributed approach that corrects fundamental deficiencies associated with the traditional centralized ver

5、ification approach. Thus, this document corrects generic problems in conducting verification that existed even during post-Total System Program Responsibility or “Faster, Better, Cheaper” policy that prospered late 1990 through early 2000 for developing complex space systems. This standard is intend

6、ed to help those in the space community develop reliable systems that meet requirements while ensuring proper accommodations of heritage and/or commercial systems in their developing systems. It also helps to facilitate the closely coordinated validation activities with those of verification, as the

7、 distributed systems engineering processes utilized in the latter can be easily adopted by the former activities. AIAA S-117-2010 ii Published by American Institute of Aeronautics and Astronautics 1801 Alexander Bell Drive, Reston, VA 20191 Copyright 2010 American Institute of Aeronautics and Astron

8、autics All rights reserved No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America AIAA S-117-2010 iii Contents Foreword . v Introduction. vii 1 Scope . 1 2 T

9、ailoring . 1 3 Applicable Documents and Reference Documents . 1 3.1 Applicable Documents . 1 3.2 Reference Documents . 1 4 Vocabulary . 2 4.1 Acronyms and Abbreviated Terms 2 4.2 Terms and Definitions 3 5 Requirements for Space System (SS) Verification Program and Management Processes . 7 5.1 SS Ver

10、ification Program 7 5.2 SS Verification Plans . 10 5.3 Standardized Modular Distributed Verification Management Processes 11 5.4 Use of Distributed Verification Management Process for Late Changes and Heritage/Commercial Systems 17 Annex A A Typical Space System and an Example of WBS-WG-Based Verifi

11、cation Management Structure (Informative) 20 Annex B Review of Verification Plans for SS and Lower System Level, Including Those Developed by Subcontractor/Vendor (Informative) . 21 B.1 Outline Requirements 21 B.2 Document Delivery Requirements . 21 B.3 Review of Requirement Flow-Down and Establishm

12、ent of Specifications 21 B.4 Analysis, Test, Inspection, and Demonstration Plan for SS and Lower Level Systems (Based on VCRM Process) . 22 B.5 I 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 mu

13、ltiple levels of integration). External interfaces (external IFs) physical and operational connections originating with the developed system and terminating with other systems at the same or higher levels of integration AIAA S-117-2010 4 NOTE External IFs normally relate to interfaces between system

14、s that are developed or used by different agencies, customers, or contractors. These IFs are in general defined through interface requirement documents (IRDs) that capture both technical and programmatic requirements for the IFs. Subsequently, interface control documents (ICDs) that capture more det

15、ailed technical requirements will be developed in order to design development systems that satisfy these requirements. Ground 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

16、 also considered as a part of Ground Segment. These Networks/Terminals perform transmission of commands, data uploads, vehicle control, telemetry receipt, and data processing. They perform these functions using operational control nodes, satellite operations centers, geographically dispersed remote

17、tracking stations/terminals, antennas, and networks to connect the many elements. Ground support equipment Earth-bound equipment, in addition to the launch pad facilities, that are required by a specific launch vehicle NOTE Ground support equipment excludes the user segment equipment used for commun

18、ications, control, and data processing of the space system vehicle and its payload. Internal interfaces (Internal IFs) physical and operational connections between components within a system NOTE Internal interfaces generally refer to component-to-component interfaces such as those within space laun

19、ch vehicles or ground stations that are built for the same customer. However, 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

20、the same customer. Launch segment portion of the space system mission in which 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 t

21、he launch vehicle, launch-related Ground Support Equipment, launch pad facilities, Range Safety systems, and any launch control operations. Space segment refers to the ex-atmospheric portion of the Space System Mission NOTE The Space Segment may employ equipment, such as the space vehicle, post-laun

22、ch maneuvering system, and any other space-based systems needed to perform the 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

23、 of a space systems mission NOTE This standards focus is on 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. AIAA S-117-2010 5 Space system (SS) miss

24、ion consists of ground, launch, space, and user segments in which predetermined 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 mo

25、dules, etc.), associated subsystems, units, and the internal and external interfaces 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 prod

26、ucts NOTE The user segment consists of data receiving and processing equipment, 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 that the system has been built right (Refe

27、rence 2) System verification program and process verification program 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 proc

28、esses must be applied to ensure that each component specification and 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.

29、NOTE 2 Writing the verification requirements is an integral part of establishing the performance, functional, and other requirements that are recorded in specifications. Test Like You Fly (TLYF) verifies the planned flight sequences, timelines, command operations, data and telemetry downlinks, and d

30、eployment functions are tested under Flight Like operations and configurations during each applicable component I fabrication, assembly, integration, and test; operations; sustainment; and end-of-life product disposal or recycling), and any other work products (plans, baselines) required for the dev

31、elopment 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 development phase of a program in this context encompasses those phases starting from authority to proceed (ATP) after contract award to requireme

32、nts flow-down/specification development, design/analysis, manufacturing, and test (including factory and launch site tests), and sell-off phases. On-orbit test is considered as a part of the validation activities (Right system is built) and not addressed in this document. NOTE 5 The formation of WBS

33、-WGs enables well-coordinated and integrated 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 organi

34、zations external to those developing the 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

35、 formed to officially ensure that (1) WBS-WG activities are properly planned and executed such that their activities are consistent with the overall verification program and (2) configuration management is properly applied for WBS-WG activities and the overall verification program. NOTE 1 SS Verific

36、ation management board 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

37、to subcontractors and vendors 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. NOTE This requirement is to ensure that every level of system development imp

38、lements 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 working with programmati

39、c and technical review boards such as Requirement Change Board, Configuration Control AIAA S-117-2010 9 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 Board. NO

40、TE SS-Verification Management Board or equivalent review board will facilitate well coordinated verification activities with other discipline groups. 5.1.5 Coordination with validation activities including Development Test and Evaluation (DT also included are the cross-cutting areas of documentation

41、 and configuration management. NOTE 4 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

42、 are compatible with the top-level requirements determined by the requirements flow-up process. 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 delivered for review at each corresponding system level

43、s SRR, SDR, PDR, and CDR. NOTE 1 One of the most critical parts of the distributed verification program is to ensure that a thorough and solid specification is established for each level of a system being developed. This will be accomplished if the system developer for each level takes responsibilit

44、y/ownership of developing their specifications in coordination with their systems engineering organization. This approach is to ensure that requirement establishment and associated verification activities are well integrated. NOTE 2 In particular, each specification needs to include sections relatin

45、g to (a) the function, performance, constraints, and quality requirements for the product and (b) a detailed statement of the verification requirements for each separate requirement in the former section. It should be noted that the lack of a detailed descriptions in the latter section in specs caus

46、ed several costly late changes and post-launch failures. NOTE 3 Each of the top SS level requirements flowed down shall have documented traceability to the lowest level preferably using requirement flow-down (i.e., derived requirements) tracking computer program. NOTE 4 Each level of system develope

47、r shall ensure that their specifications also captured all the non-derived requirements that are specific to each of the systems being developed NOTE 5 Each level of system developer, if they use heritage systems, shall ensure that they perform requirement flow-up activities to ensure that each of t

48、he requirements in the heritage system specification is compatible with and supports the top-level system requirements. If not, then they shall modify noncompliant requirements accordingly. NOTE 6 Each of the requirements shall be well defined and objectively verifiable. NOTE 7 Each of the complianc

49、e documents shall also be properly flowed down from the top level specification to any of the applicable lower level specifications. AIAA S-117-2010 12 NOTE 8 The system level requirements need to be under CM control upon completion of SRR. Lower level requirements may be delayed in going under CM control until PDR. NOTE 9 These requirement flow-down and flow-up processes may preferably utilize computer data management software in order to effectively manage hundreds of top system level requirements flowed down to numerous lower level systems. NOTE 10 Validation of the develope