LOGIC : Software Engineering, Systems Engineering, Testing, and Simulation

1. Simulation Interoperability Standards Organization (SISO) - https://www.sisostandards.org

1.1. Space Reference Federation Object Model (SpaceFOM) (SISO-STD-018-2020)

SISO-STD-018-2020 defines a collection of HLA-compliant data constructs, modeling standards, and execution control process standards that support interoperability between simulations in the space domain. It is designed to link simulations of discrete physical entities into distributed collaborative simulations of complex space related systems. The data files associated with SISO-STD-018-2020 may be downloaded from the SISO Product Data Files webpage.

https://www.sisostandards.org/resource/resmgr/standards_products/siso-std-018-2020_srfom.pdf

1.2. Simulation Interoperability Readiness Levels (SISO-STD-2024)

SISO-STD-024-2024 is the Simulation Interoperability Readiness Level (SIRL) standard and should be used in conjunction with User’s Guide for Simulation Interoperability Readiness Levels (SIRL) Standard: Assessing Risks to Development of Interoperable Distributed Simulation Solutions. The purpose of the SIRL standard is to create a framework for senior decision-makers, simulation developers, and simulation integrators to make rapid, quantitative, evidence-based assessments of the feasibility and risk of attempting to integrate simulations prior to committing effort and funds to doing so.  Applying SIRL determines does NOT determine whether simulations are interoperable, rather it helps determining whether a rapid, accurate assessment of potential interoperability is possible on the basis of engineering evidence in form of documentation. A complete assessment requires the actual evidence.

https://www.sisostandards.org/resource/resmgr/standards_products/siso-std-024-2024_sirl.xlsx

1.3. Federation Engineering Agreements Template (SISO-STD-012-2013)

SISO-STD-012-2013 provides a standardized format for recording federation agreements to increase their usability and reuse. The template is an eXtensible Markup Language (XML) schema from which compliant XML-based federation agreement documents can be created. Creating the template as an XML schema allows XML-enabled tools to both validate conformant documents, and edit and exchange agreements documents without introducing incompatibilities.

https://www.sisostandards.org/resource/resmgr/standards_products/siso-std-012-2013_federation.pdf

2. Institute for Electrical and Electronics Engineers (IEEE) - https://www.ieee.org

2.1. High Level Architecture for Modeling & Simulation (HLA) (IEEE-STD-1516-2010, IEEE-STD-1516.1-2010, IEEE-STD-1516.2-2010)

Rules (1516) This standard, describing the framework and rules of the High Level Architecture (HLA), is the capstone document for a family of related HLA standards.

https://standards.ieee.org/ieee/1516/3744/

Interface Specification (1516.1) This document, the second in a family of three related HLA documents, defines the standard services of and interfaces to the HLA runtime infrastructure (RTI). These services are used by the interacting simulations to achieve a coordinated exchange of information when they participate in a distributed federation.

https://standards.ieee.org/ieee/1516.1/3745/

Object Model Template (1516.2) 

This document, the third in a family of three related HLA documents, defines the format and syntax (but not content) of HLA object models.

https://standards.ieee.org/ieee/1516.2/3746/

2.2. Distributed Simulation Engineering and Execution Process (DSEEP)/DSEEP Multi-Architecture Overlay (DMAO)/DSEEP Verification, Validation, and Acceptance/Accreditation (VV&A) Overlay (IEEE-STD-1730-2022, IEEE-STD-1730.1-2023*, IEEE-STD-1730.2-2022)

DSEEP (1730) The DSEEP is intended as a high-level process framework into which the lower-level systems engineering practices native to any distributed simulation user can be easily integrated. Simulation architectures include Distributed Interactive Simulation (DIS), High Level Architecture (HLA), and Test and Training Enabling Architecture (TENA). https://standards.ieee.org/ieee/1730/10715/

DMAO (1730.1) A recommended practice for applying the Distributed Simulation Engineering and Execution Process (DSEEP) to the development and execution of distributed simulation environments that include more than one distributed simulation architecture is described. The distributed simulation architectures to which the recommended practice applies include Distributed Interactive Simulation (DIS), High Level Architecture (HLA), and Test and Training Enabling Architecture (TENA). The DSEEP Multi-Architecture Overlay (DMAO) identifies and describes multi-architecture issues and provides recommended actions for simulation environment developers faced with those issues. The DMAO also augments the DSEEP lists of inputs, recommended tasks, and outcomes with additional inputs, recommended tasks, and outcomes that apply to multi-architecture simulation environments. This document is an overlay to the DSEEP, which is a separate recommended practice.

DSEEP VV&A Overlay (1730.2) This recommended practice provides guidelines for verification, validation, and acceptance or accreditation (VV&A) of a distributed simulation and provides a more detailed view of the VV&A processes implied by and aligned with the DSEEP.

*The DMAO was successfully balloted in 2023, but isn't yet published awaiting final editorial revision.

2.3. IEEE Standard for Environmental Specifications for Spaceborne Computer Modules (1156.4-1997)

Fundamental information on minimum environmental withstand conditions for space electronics is provided. The intent is to achieve uniformity and reproducibility in the test conditions for all spaceborne computer modules that may make up larger systems and are purported to have a rated environmental performance level. The specifications pertain to both the natural and artificial environments to which spaceborne computer modules may be exposed. These conditions include, but are not limited to, thermal, mechanical, electrical, and radiation stresses.

This standard will be designed for use in conjunction with P896.10 (Spaceborne Futurebus+ Profile Specifications) for specification of environmental withstand conditions applicable to spaceborne computer modules/circuit boards and all of the components attached to the modules.

Environmental conditions for computer modules intended for use in space vehicles are not currently covered by existing standards. The space vehicle environment is characterized by thermal, mechanical, and electrical conditions not shared by office, industrial, shipboard, and aircraft environments. This environmental standard will promote development of cost-effective, high-reliability computer modules for space.

https://ieeexplore.ieee.org/document/603627

3. Functional Mock-up Interface - https://fmi-standard.org/

3.1. Functional Mock-up Interface

The Functional Mock-up Interface is a free standard that defines a container and an interface to exchange dynamic simulation models using a combination of XML files, binaries and C code, distributed as a ZIP file. It is supported by 180+ tools and maintained as a Modelica Association Project. 

https://fmi-standard.org/

Notes:

  • This website refers to the interface as a standard, but there's no evidence on the website that they're a standards development organization.

4. International Organization for Standardization (ISO) - https://www.iso.org

4.1.  Industrial automation systems and integration; Product data representation and exchange; Part 243: Application protocol: For modelling and simulation information in a collaborative systems engineering context (MoSSEC)(ISO 10303-243:2021)

This document specifies the use of the integrated resources necessary for the scope and information requirements for modelling and simulation information in a collaborative systems engineering context (MoSSEC). The following are within the scope of this document:

  • the representation of the collaborative understanding of the requirements and their verification;
  • the representation of the elements that together comprise a set of "results" for a study including the audit-trail of what is to be done, and what has been done, and evolution;
  • the representation of the definitions of models and key values that are part of the modelling;
  • the representation of information concerning organization and person in those organizations;
  • the representation of properties and documents;
  • the representation of a collaborative package of work that is launched to drive the evolution and maturity of something;
  • the identification of a breakdown of something, the identification of the elements that comprise a breakdown, the parent-child relationships between breakdown elements and the identification of relationships between elements in different breakdowns;
  • the representation of interfaces including connections, ports and definitions;
  • the identification of which breakdowns, interfaces and models are included in an architecture;
  • the representation of key values as distributions enabling the representation of uncertainties;
  • the representation of justifications, assumptions and approvals to aid and record decision making;
  • the representation of information used for security and trust so each organization is then to be able to enforce their own human resources and security policies.

https://www.iso.org/standard/72491.html

4.2. Software, systems and enterprise — Architecture description (ISO/IEC/IEEE 42010:2022)

This document specifies requirements for the structure and expression of an architecture description (AD) for various entities, including software, systems, enterprises, systems of systems, families of systems, products (goods or services), product lines, service lines, technologies and business domains.

This document distinguishes the architecture of an entity of interest from an AD expressing that architecture. Architectures are not the subject of this document.

This document specifies requirements for use of the architectural concepts and their relationships as captured in an AD. It does not specify requirements for any entity of interest or its environment.

This document specifies requirements for an architecture description framework (ADF), an architecture description language (ADL), architecture viewpoints and model kinds in order to usefully support the development and use of an AD.

This document specifies conformance to the requirements for an AD, ADF, ADL, architecture viewpoint and model kind.

This document does not specify the processes, architecting methods, models, notations, techniques or tools by which an AD is created, utilized or managed.

This document does not specify any format or media for recording an AD.

https://www.iso.org/standard/74393.html

Notes:

  • Joint standard with the International Electrotechnical Commission (IEC) and the Institute of Electrical and Electronics Engineers (IEEE)

5. American Institute of Aeronautics and Astronautics (AIAA) - https://www.aiaa.org

5.1. Moving Mechanical Assemblies for Space and Launch Vehicles (AIAA S-114A-2020)

This standard specifies general requirements for the design, manufacture, quality control, testing, and storage of moving mechanical assemblies (MMAs) to be used on space and launch vehicles. This standard is applicable to the mechanical or electromechanical devices that control the movement of a mechanical part of a space or launch vehicle relative to another part. The requirements apply to the overall MMA as well as to the mechanical components and instrumentation that are an integral part of these mechanical assemblies.

https://doi.org/10.2514/4.106132.001

5.2. Space Systems—Metallic Pressure Vessels, Pressurized Structures, and Pressure Components (ANSI/AIAA S-080A-2018)

This standard establishes baseline requirements for the design, analysis, fabrication, test, operation, and maintenance of metallic pressure vessels, pressurized structures, batteries, heat pipes, and cryostats, dewars, sealed containers, accumulators, and pressure components such as lines, fittings, hoses, and bellows made of metals. These components are used for pressurized, hazardous, or nonhazardous liquid or gas storage in space systems including spacecraft and launch vehicles. 

https://doi.org/10.2514/4.107061.001

Notes:

  • Joint standard with American National Standards Institute (ANSI)

6. NASA - https://www.nasa.gov/

6.1. NASA Procedural Requirements (NPR) Software Engineering Requirements 7150.2D

Engineering requirements for software acquisition, development, maintenance, retirement, operations, and management consistent with the governance model contained in NASA Policy Directive (NPD) 1000.0, NASA Governance and Strategic Management Handbook.

https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7150_002D_&page_name=main

6.2. NASA Software Assurance & Software Safety Standard (NASA-STD-8739.8)

The purpose of the Software Assurance and Software Safety Standard is to define the requirements to implement a systematic approach to Software Assurance (SA), software safety, and Independent Verification and Validation (IV&V) for software created, acquired, provided, or maintained by or for NASA. Various personnel in the program, project, or facility, and Safety and Mission Assurance (SMA) organizations can perform the activities required to satisfy these requirements. The Software Assurance and Software Safety Standard provides a basis for personnel to perform software assurance, software safety, and IV&V activities consistently throughout the life of the software, that is, from its conception, through creation to operations and maintenance, and until the software is retired.

https://standards.nasa.gov/standard/nasa/nasa-std-87398

6.3. Software Formal Inspections Standard (NASA-STD-8739.9)

The Software Formal Inspections Standard is designed to support the inspection process of software developed for NASA. Its goal is to provide a framework and model for an inspection process that will detect and eliminate defects as early as possible in the software lifecycle.

https://standards.nasa.gov/standard/NASA/NASA-STD-87399

6.4. NASA Software Engineering Handbook

This handbook provides users and practitioners with guidance material for implementing the requirements of NPR 7150.2, NASA Software Engineering Requirements. Use of this handbook is intended to provide “best-in-class” guidance for the implementation of safe and reliable software in support of NASA projects. This handbook is a key component of the NASA Software Working Group’s (SWG) implementation of an Agency-wide plan to work toward a continuous and sustained software engineering process and product improvement.

The SWG designed this Handbook for the community that is involved in the acquisition, management, development, assurance, maintenance, and operations of NASA software. Readers can use it to sharpen their skills in specific areas or suggest valuable guidance for others in the NASA software community. Novice and experienced software team members can use the Handbook as an easily accessible reference or manual that captures the broad knowledge base of numerous experts who have extensive experience in all aspects of NASA’s software systems.

https://swehb.nasa.gov/

7. International Deep Space Interoperability Standards - https://www.internationaldeepspacestandards.com/

7.1. International Software System Interoperability Standards (ISwSIS) (NTR 20205008534)

The purpose of this ISwSIS is to provide basic data interface standards that allow developers to independently design compatible cislunar and deep space spacecraft software systems. At the highest level, seamless data exchange and data interpretation between spacecraft and between spacecraft modules, where two or more modules comprise the spacecraft, is the objective.

The same data exchange and interpretation standards can apply to the software systems and subsystems residing within any one module, however there is latitude on the part of the spacecraft module developers to determine when and if the data standard is to apply.

Compatible software systems among software, hardware, and human interfaces for spacecraft systems is critical to the success of human exploration. Enabling the use of National Aeronautics and Space Administration (NASA), International Partner, commercial, and other software assets interchangeably, decreases development and procurement costs, and reduces operational and training complexity.

Note, since Orion has existing specifications that define units, applicable Consultative Committee for Space Data Systems (CCSDS) standards, and other interoperability requirements, the standards documented herein are applicable to Gateway, new program spacecraft, and visiting vehicles only.

https://ntrs.nasa.gov/api/citations/20205008534/downloads/ISwSIS%20Software%20Standard_NASA-102020_Draft.docx.pdf

Notes:

  • In some places, it's like a profile, citing existing standards.
  • In some place, it establishes requirements directly.

8. American Institute of Aeronautics and Astronautics (AIAA) - https://www.aiaa.org

8.1. Space Plug-and-Play Architecture: Standards Development Guidebook (AIAA G-133-1-2013)

This Guidebook provides an overview for spacecraft platform (system), subsystem, and component (including payload) developers with spacecraft plug-and-play architectures to promote rapid design, fabrication, integration, and test. Included is an introduction to SPA, providing an informative reference for the uninitiated reader. It also includes a summary of the SPA standards. The standard user is directed to the SPA standardsfor detailed requirements. In cases where material in this document differs from a SPA standard, the standard will take precedence.

https://doi.org/10.2514/4.102295.001

8.2. Standard: Space Systems — Structures, Structural Components, and Structural Assemblies (AIAA S-110-2005)

This document establishes a standard for the design, analysis, material selection and characterization, fabrication, test, and inspection of structural items in space systems, including payloads, spacecraft, upper-stages, and expendable and reusable launch vehicles. This standard, when implemented on a particular space system, will assure high confidence in achieving safe, reliable operation in all phases of the mission. This document applies specifically to all structural items including fracture-critical hardware used in space systems during all phases of the mission—with the following exceptions: adaptive structures, engines, solid rocket nozzles, and thermal protection systems.

https://doi.org/10.2514/4.477713.001



Comments:

These types of standards don't fit neatly into the focus areas. We should discuss as a team whether these should be in scope.

Posted by morsekl1 at Feb 02, 2024 13:04