SEARCH · Engineering Papers

Results for “requirements”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS1980

Monitoring and control requirement definition study for Dispersed Storage and Generation (DSG). Volume 2, appendix A: Selected DSG technologies and their general control requirements

A consistent approach was sought for both hardware and software which will handle the monitoring and control necessary to integrate a number of different DSG technologies into a common distribution dispatch network. It appears that the control of each of the DSG technologies is compatible with a supervisory control method of operation that lends itself to remote control from a distribution dispatch center.

Source record↗

NASA NTRS1991

Space Transfer Vehicle Concepts and Requirements Study. Volume 2, Book 2: System and Program Requirements Trade Studies

During the 90-day study, support was provided to NASA in defining a point-of-departure space transfer vehicle (STV). The resulting STV concept was performance optimized with a two-stage LTV/LEV configuration. Appendix A reports on the effort during this period of the study. From the end of the 90-day study until the March Interim Review, effort was placed on optimizing the two-stage vehicle approach identified in the 90-day effort. After the March Interim Review, the effort was expanded to perform a full architectural trade study with the intent of developing a decision database to support STV system decisions in response to changing SEI infrastructure concepts. Several of the architecture trade studies were combined in a System Architecture Trade Study. In addition to this trade, system optimization/definition trades and analyses were completed and some special topics were addressed. Program- and system-level trade study and analyses methodologies and results are presented in this section. Trades and analyses covered in this section are: (1) a system architecture trade study; (2) evolution; (3) safety and abort considerations; (4) STV as a launch vehicle upper stage; and (5) optimum crew and cargo split.

Weber, Gary A.↗

NASA NTRS2019

Spacecraft Requirements Development and Tailoring

Spacecraft design is managed through the use of design requirements. Requirements are flowed from the highest level, the overall spacecraft, to systems, subsystems and ultimately individual components. Through the use of requirements, each part of the spacecraft will perform the functions that are required of it and will interface to the rest of the spacecraft. Functional requirements are used to make sure every component performs as expected and interface requirements ensure that each component works within the larger design environment where it operates. Writing good requirements is difficult and the verification of requirements can be expensive and time consuming. Because of this difficulty and expense, it is important that each requirement truly be “required” and critical to the overall performance of the vehicle. It is also important that requirements can be changed or eliminated as the system matures to minimize verification cost and schedule. The Capsule Parachute Assembly System (CPAS) Project is developing the parachute system for the NASA Multi-Purpose Crew Vehicle (MPCV) Orion Spacecraft. Throughout the development and qualification cycle for CPAS, requirements have been evaluated, added, eliminated, or more generically, “tailored”, to ensure that the system performs as required while minimizing the verification cost to the Program. One facet of this tailoring has been to delete requirements that do not add value to the overall spacecraft or are not needed. A second approach to minimize the cost of requirement verification has been to evaluate requirements based on the actual design as it has matured. As the design of the parachute system has become better understood, requirements that are not applicable have been eliminated. This paper will outline the evolution of CPAS requirements over time and will show how careful and considered changes to requirements can benefit the technical solution for the overall system design while allowing a Project to control costs.

Mcmichael, James H.↗

NASA NTRS1998

Testing, Requirements, and Metrics

The criticality of correct, complete, testable requirements is a fundamental tenet of software engineering. Also critical is complete requirements based testing of the final product. Modern tools for managing requirements allow new metrics to be used in support of both of these critical processes. Using these tools, potential problems with the quality of the requirements and the test plan can be identified early in the life cycle. Some of these quality factors include: ambiguous or incomplete requirements, poorly designed requirements databases, excessive or insufficient test cases, and incomplete linkage of tests to requirements. This paper discusses how metrics can be used to evaluate the quality of the requirements and test to avoid problems later. Requirements management and requirements based testing have always been critical in the implementation of high quality software systems. Recently, automated tools have become available to support requirements management. At NASA's Goddard Space Flight Center (GSFC), automated requirements management tools are being used on several large projects. The use of these tools opens the door to innovative uses of metrics in characterizing test plan quality and assessing overall testing risks. In support of these projects, the Software Assurance Technology Center (SATC) is working to develop and apply a metrics program that utilizes the information now available through the application of requirements management tools. Metrics based on this information provides real-time insight into the testing of requirements and these metrics assist the Project Quality Office in its testing oversight role. This paper discusses three facets of the SATC's efforts to evaluate the quality of the requirements and test plan early in the life cycle, thus preventing costly errors and time delays later.

Rosenberg, Linda↗

NASA NTRS2014

Loads and Structural Dynamics Requirements for Spaceflight Hardware

The purpose of this document is to establish requirements relating to the loads and structural dynamics technical discipline for NASA and commercial spaceflight launch vehicle and spacecraft hardware. Requirements are defined for the development of structural design loads and recommendations regarding methodologies and practices for the conduct of load analyses are provided. As such, this document represents an implementation of NASA STD-5002. Requirements are also defined for structural mathematical model development and verification to ensure sufficient accuracy of predicted responses. Finally, requirements for model/data delivery and exchange are specified to facilitate interactions between Launch Vehicle Providers (LVPs), Spacecraft Providers (SCPs), and the NASA Technical Authority (TA) providing insight/oversight and serving in the Independent Verification and Validation role. In addition to the analysis-related requirements described above, a set of requirements are established concerning coupling phenomena or other interaction between structural dynamics and aerodynamic environments or control or propulsion system elements. Such requirements may reasonably be considered structure or control system design criteria, since good engineering practice dictates consideration of and/or elimination of the identified conditions in the development of those subsystems. The requirements are included here, however, to ensure that such considerations are captured in the design space for launch vehicles (LV), spacecraft (SC) and the Launch Abort Vehicle (LAV). The requirements in this document are focused on analyses to be performed to develop data needed to support structural verification. As described in JSC 65828, Structural Design Requirements and Factors of Safety for Spaceflight Hardware, implementation of the structural verification requirements is expected to be described in a Structural Verification Plan (SVP), which should describe the verification of each structural item for the applicable requirements. The requirement for and expected contents of the SVP are defined in JSC 65828. The SVP may also document unique verifications that meet or exceed these requirements with Technical Authority approval.

George James↗

NASA NTRS2011

Optical Property Requirements for Glasses, Ceramics and Plastics in Spacecraft Window Systems

This is a preliminary draft of a standard published by the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) that is intended to provide uniform window optical design requirements in support of the development of human-rated spaceflight hardware. The material covered in this standard is based on data from extensive testing by the Advanced Sensing and Optical Measurement Branch at NASA Langley Research Center, and compiled into requirements format by the NASA JSC Structural Engineering Division. At the time of this initial document release, a broader technical community has not reviewed this standard. The technical content of this standard is primarily based on the Constellation Program Orion Crew Exploration Vehicle Window Optical Properties Requirements, CxP 72407, Baseline. Unlike other optical requirements documents available for human rated spacecraft, this document includes requirements that ensure functionality for windows that contain glass/ceramic and/or plastic window substrate materials. These requirements were derived by measuring the optical properties of fused silica and aluminosilicate glass window assemblies and ensuring that the performance of any window assembly that includes a plastic pane or panes will meet the performance level of the all-glass assemblies. The resulting requirements are based upon the performance and parameter metrology testing of a variety of materials, including glass, transparent ceramics, acrylics, and polycarbonates. In general, these requirements are minimum specifications for each optical parameter in order to achieve the function specified for each functional category, A through D. Because acrylic materials perform at a higher level than polycarbonates in the optics regime, and CxP/Orion is planning to use acrylic in the Orion spacecraft, these requirements are based heavily on metrology from that material. As a result, two of the current Category D requirements for plastics are cited in such a way that will result in the screening out of polycarbonates. It is acknowledged that many polycarbonates can perform the functions of Category D, such as piloting and imagery with lens with apertures up to 25mm, without performance issues. Therefore, this forward warns users that certain requirements, such as birefringence and wavefront, for Category D plastics need to be revised to allow those polycarbonates that perform adequately in Category D to be accepted, while at the same time, screen out those materials that do not perform up to par. At the time of document release, the requirements in question have been identified by a TBD beside the proposed requirement criteria (which is based upon acrylic performance). Vehicles that are designed with acrylic materials for windowpanes are encouraged to use the values presented in this document for all requirements, in order to ensure adequate optical performance.

Lynda R Estes↗

NASA NTRS2008

Space Transportation System Availability Requirements and Its Influencing Attributes Relationships

It is essential that management and engineering understand the need for an availability requirement for the customer's space transportation system as it enables the meeting of his needs, goal, and objectives. There are three types of availability, e.g., operational availability, achieved availability, or inherent availability. The basic definition of availability is equal to the mean uptime divided by the sum of the mean uptime plus the mean downtime. The major difference is the inclusiveness of the functions within the mean downtime and the mean uptime. This paper will address tIe inherent availability which only addresses the mean downtime as that mean time to repair or the time to determine the failed article, remove it, install a replacement article and verify the functionality of the repaired system. The definitions of operational availability include the replacement hardware supply or maintenance delays and other non-design factors in the mean downtime. Also with inherent availability the mean uptime will only consider the mean time between failures (other availability definitions consider this as mean time between maintenance - preventive and corrective maintenance) that requires the repair of the system to be functional. It is also essential that management and engineering understand all influencing attributes relationships to each other and to the resultant inherent availability requirement. This visibility will provide the decision makers with the understanding necessary to place constraints on the design definition for the major drivers that will determine the inherent availability, safety, reliability, maintainability, and the life cycle cost of the fielded system provided the customer. This inherent availability requirement may be driven by the need to use a multiple launch approach to placing humans on the moon or the desire to control the number of spare parts required to support long stays in either orbit or on the surface of the moon or mars. It is the intent of this paper to provide the visibility of relationships of these major attribute drivers (variables) to each other and the resultant system inherent availability, but also provide the capability to bound the variables providing engineering the insight required to control the system's engineering solution. An example of this visibility will be the need to provide integration of similar discipline functions to allow control of the total parts count of the space transportation system. Also the relationship visibility of selecting a reliability requirement will place a constraint on parts count to achieve a given inherent availability requirement or accepting a larger parts count with the resulting higher reliability requirement. This paper will provide an understanding for the relationship of mean repair time (mean downtime) to maintainability, e.g., accessibility for repair, and both mean time between failure, e.g., reliability of hardware and the system inherent availability. Having an understanding of these relationships and resulting requirements before starting the architectural design concept definition will avoid considerable time and money required to iterate the design to meet the redesign and assessment process required to achieve the results required of the customer's space transportation system. In fact the impact to the schedule to being able to deliver the system that meets the customer's needs, goals, and objectives may cause the customer to compromise his desired operational goal and objectives resulting in considerable increased life cycle cost of the fielded space transportation system.

Rhodes, Russel E.↗

NASA NTRS2015

The Use of UML for Software Requirements Expression and Management

It is common practice to write English-language "shall" statements to embody detailed software requirements in aerospace software applications. This paper explores the use of the UML language as a replacement for the English language for this purpose. Among the advantages offered by the Unified Modeling Language (UML) is a high degree of clarity and precision in the expression of domain concepts as well as architecture and design. Can this quality of UML be exploited for the definition of software requirements? While expressing logical behavior, interface characteristics, timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achieving the additional aspects of the expression and management of software requirements that stakeholders expect, especially traceability, is far less so. These other characteristics, concerned with auditing and quality control, include the ability to trace a requirement to a parent requirement (which may well be an English "shall" statement), to trace a requirement to verification activities or scenarios which verify that requirement, and to trace a requirement to elements of the software design which implement that requirement. UML Use Cases, designed for capturing requirements, have not always been satisfactory. Some applications of them simply use the Use Case model element as a repository for English requirement statements. Other applications of Use Cases, in which Use Cases are incorporated into behavioral diagrams that successfully communicate the behaviors and constraints required of the software, do indeed take advantage of UML's clarity, but not in ways that support the traceability features mentioned above. Our approach uses the Stereotype construct of UML to precisely identify elements of UML constructs, especially behaviors such as State Machines and Activities, as requirements, and also to achieve the necessary mapping capabilities. We describe this approach in the context of a space-based software application currently under development at the Jet Propulsion Laboratory.

model-based engineering↗

NASA NTRS2020

Bridging the Gap Between Requirements and Model Analysis : Evaluation on Ten Cyber-Physical Challenge Problems

Formal verfication and simulation are powerful tools to validate requirements against complex systems. [Problem] Requirements are developed in early stages of the software lifecycle and are typically written in ambiguous natural language. There is a gap between such requirements and formal notations that can be used by verification tools, and lack of support for proper association of requirements with software artifacts for verification. [Principal idea] We propose to write requirements in an intuitive, structured natural language with formal semantics, and to support formalization and model/code verification as a smooth, well-integrated process. [Contribution] We have developed an end-to-end, open source requirements analysis framework that checks Simulink models against requirements written in structured natural language. Our framework is built in the Formal Requirements Elicitation Tool (fret); we use fret's requirements language named fretish, and formalization of fretish requirements in temporal logics. Our proposed framework contributes the following features: 1) automatic extraction of Simulink model information and association of fretish requirements with target model signals and components; 2) translation of temporal logic formulas into synchronous dataflow cocospec specifications as well as Simulink monitors, to be used by verification tools; we establish correctness of our translation through extensive automated testing; 3) interpretation of counterexamples produced by verification tools back at requirements level. These features support a tight integration and feedback loop between high level requirements and their analysis. We demonstrate our approach on a major case study: the Ten Lockheed Martin Cyber-Physical, aerospace-inspired challenge problems.

Mavridou, Anastasia↗

NASA NTRS1989

Electrical, Electronic, and Electromechanical (EEE) parts management and control requirements for NASA space flight programs

This document establishes electrical, electronic, and electromechanical (EEE) parts management and control requirements for contractors providing and maintaining space flight and mission-essential or critical ground support equipment for NASA space flight programs. Although the text is worded 'the contractor shall,' the requirements are also to be used by NASA Headquarters and field installations for developing program/project parts management and control requirements for in-house and contracted efforts. This document places increased emphasis on parts programs to ensure that reliability and quality are considered through adequate consideration of the selection, control, and application of parts. It is the intent of this document to identify disciplines that can be implemented to obtain reliable parts which meet mission needs. The parts management and control requirements described in this document are to be selectively applied, based on equipment class and mission needs. Individual equipment needs should be evaluated to determine the extent to which each requirement should be implemented on a procurement. Utilization of this document does not preclude the usage of other documents. The entire process of developing and implementing requirements is referred to as 'tailoring' the program for a specific project. Some factors that should be considered in this tailoring process include program phase, equipment category and criticality, equipment complexity, and mission requirements. Parts management and control requirements advocated by this document directly support the concept of 'reliability by design' and are an integral part of system reliability and maintainability. Achieving the required availability and mission success objectives during operation depends on the attention given reliability and maintainability in the design phase. Consequently, it is intended that the requirements described in this document are consistent with those of NASA publications, 'Reliability Program Requirements for Aeronautical and Space System Contractors,' NHB 5300.4(1A-l); 'Maintainability Program Requirements for Space Systems,' NHB 5300.4(1E); and 'Quality Program Provisions for Aeronautical and Space System Contractors,' NHB 5300.4(1B).

Source record↗

NASA NTRS2003

Requirements Development for the NASA Advanced Engineering Environment (AEE)

The requirements development process for the Advanced Engineering Environment (AEE) is presented. This environment has been developed to allow NASA to perform independent analysis and design of space transportation architectures and technologies. Given the highly collaborative and distributed nature of AEE, a variety of organizations are involved in the development, operations and management of the system. Furthermore, there are additional organizations involved representing external customers and stakeholders. Thorough coordination and effective communication is essential to translate desired expectations of the system into requirements. Functional, verifiable requirements for this (and indeed any) system are necessary to fulfill several roles. Requirements serve as a contractual tool, configuration management tool, and as an engineering tool, sometimes simultaneously. The role of requirements as an engineering tool is particularly important because a stable set of requirements for a system provides a common framework of system scope and characterization among team members. Furthermore, the requirements provide the basis for checking completion of system elements and form the basis for system verification. Requirements are at the core of systems engineering. The AEE Project has undertaken a thorough process to translate the desires and expectations of external customers and stakeholders into functional system-level requirements that are captured with sufficient rigor to allow development planning, resource allocation and system-level design, development, implementation and verification. These requirements are maintained in an integrated, relational database that provides traceability to governing Program requirements and also to verification methods and subsystem-level requirements.

Rogers, Eric↗

NASA NTRS2008

From Informal Safety-Critical Requirements to Property-Driven Formal Validation

Most of the efforts in formal methods have historically been devoted to comparing a design against a set of requirements. The validation of the requirements themselves, however, has often been disregarded, and it can be considered a largely open problem, which poses several challenges. The first challenge is given by the fact that requirements are often written in natural language, and may thus contain a high degree of ambiguity. Despite the progresses in Natural Language Processing techniques, the task of understanding a set of requirements cannot be automatized, and must be carried out by domain experts, who are typically not familiar with formal languages. Furthermore, in order to retain a direct connection with the informal requirements, the formalization cannot follow standard model-based approaches. The second challenge lies in the formal validation of requirements. On one hand, it is not even clear which are the correctness criteria or the high-level properties that the requirements must fulfill. On the other hand, the expressivity of the language used in the formalization may go beyond the theoretical and/or practical capacity of state-of-the-art formal verification. In order to solve these issues, we propose a new methodology that comprises of a chain of steps, each supported by a specific tool. The main steps are the following. First, the informal requirements are split into basic fragments, which are classified into categories, and dependency and generalization relationships among them are identified. Second, the fragments are modeled using a visual language such as UML. The UML diagrams are both syntactically restricted (in order to guarantee a formal semantics), and enriched with a highly controlled natural language (to allow for modeling static and temporal constraints). Third, an automatic formal analysis phase iterates over the modeled requirements, by combining several, complementary techniques: checking consistency; verifying whether the requirements entail some desirable properties; verify whether the requirements are consistent with selected scenarios; diagnosing inconsistencies by identifying inconsistent cores; identifying vacuous requirements; constructing multiple explanations by enabling the fault-tree analysis related to particular fault models; verifying whether the specification is realizable.

Cimatti, Alessandro↗

NASA NTRS2011

NASA's Human Rating Requirements - A Historical Interpretive Perspective

Section 3.0 of NASA's Human Rating Requirements for Space Systems, NPR 8705.2, represents technical engineering requirements that the Agenc y requires of Human Space Systems. In many cases the requirements are not unlike requirements for any space system, crewed or uncrewed, th ey deal with successfully accomplishing the mission objectives. Howev er, they go one step further and have requirements that go beyond suc cessful completion of the mission and dictate functions or actions ne cessary to assure the survival of the crew. In that regard they are u nique from other space system requirements. Even with their uniquenes s the technical requirements of the NPR 8705.2 have been relatively u nchanged in overall intent over the revisions. They all have provided for system redundancy, crew habitable environment, crew situational awareness, crew operation, system control, emergency egress and abort systems. In a few cases the intent of the requirement was changed in tentionally, either to restrict certain types of systems or their fun ctions, or to encompass lessons learned from previous programs. For t he most part the requirements are non controversial and represent the current best practices for human space systems, however, a few requi rements are always debated and have evolved over revisions of the NPR due to studies conducted with various programs like the Orbital Spac e Plane and the Constellation Programs. Those requirements will be di scussed using results of trade studies conducted during past programs highlighting how these particular requirements have evolved through the revisions of the NPR. Comments will also be provided for requirem ents that although not debated, have provided challenges in interpret ation.

Langford, Gerald↗

NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗

NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗

NASA NTRSDate not supplied

Authoring, Analyzing, and Monitoring Requirements for a Lift-Plus-Cruise Aircraft

Requirements specification and analysis is widely applied to ensure the correctness of industrial systems in safety critical domains. Requirements are often initially written in natural language, which is highly ambiguous, and as a second step transformed into a language with rigorous semantics for formal analysis. [Question/problem] In this paper, we report on our experience in requirements creation and analysis, as well as run-time monitor generation using the Formal Requirement Elicitation Tool (FRET), on an industrial case study for a Lift-Plus-Cruise concept aircraft. [Principal ideas/results] We study the creation of requirements directly in the structured language of FRET without a prior definition of the same requirements in natural language. We focus on requirements describing state machines and discuss the challenges that we faced, in terms of creating requirements and generating monitors. We demonstrate how realizability, i.e., checking whether a requirements specification can be implemented, is crucial for understanding temporal interdependencies among requirements. [Contribution] Our study is the first complete attempt at using FRET to create industrial, realizable requirements and generate run-time monitors. Insight from lessons learned was materialized into new features in the FRET and JKind analysis frameworks.

Requirements engineering↗

NASA NTRSDate not supplied

Authoring, Analyzing, and Monitoring Requirements for a Lift-Plus-Cruise Aircraft

Requirements specification and analysis is widely applied to ensure the correctness of industrial systems in safety critical domains. Requirements are often initially written in natural language, which is highly ambiguous, and as a second step transformed into a language with rigorous semantics for formal analysis. In this paper, we report on our experience in requirements creation and analysis, as well as run-time monitor generation using the Formal Requirement Elicitation Tool (FRET), on an industrial case study for a Lift-Plus-Cruise concept aircraft. We study the creation of requirements directly in the structured language of FRET without a prior definition of the same requirements in natural language. We focus on requirements describing state machines and discuss the challenges that we faced, in terms of creating requirements and generating monitors. We demonstrate how realizability, i.e., checking whether a requirements specification can be implemented, is crucial for understanding temporal interdependencies among requirements. Our study is the first complete attempt at using FRET to create industrial, realizable requirements and generate run-time monitors. Insight from lessons learned was materialized into new features in the FRET and JKind analysis frameworks.

Requirements engineering↗

NASA NTRS1995

Planetary and deep space requirements for photovoltaic solar arrays

In the past 25 years, the majority of interplanetary spacecraft have been powered by nuclear sources. However, as the emphasis on smaller, low cost missions gains momentum, the majority of missions now being planned will use photovoltaic solar arrays. This will present challenges to the solar array builders, inasmuch as planetary requirements usually differ from earth orbital requirements. In addition, these requirements often differ greatly, depending on the specific mission; for example, inner planets vs. outer planets, orbiters vs. flybys, spacecraft vs. landers, and so on. Also, the likelihood of electric propulsion missions will influence the requirements placed on solar array developers. The paper will discuss representative requirements for a range of planetary missions now in the planning stages. Insofar as inner planets are concerned, a Mercury orbiter is being studied with many special requirements. Solar arrays would be exposed to high temperatures and a potentially high radiation environment, and will need to be increasingly pointed off sun as the vehicle approaches Mercury. Identification and development of cell materials and arrays at high incidence angles will be critical to the design. Missions to the outer solar system that have been studied include a Galilean orbiter and a flight to the Kuiper belt. While onboard power requirements would be small (as low as 10 watts), the solar intensity will require relatively large array areas. As a result, such missions will demand extremely compact packaging and low mass structures to conform to launch vehicle constraints. In turn, the large are, low mass designs will impact allowable spacecraft loads. Inflatable array structures, with and without concentration, and multiband gap cells will be considered if available. In general, the highest efficiency cell technologies operable under low intensity, low temperature conditions are needed. Solar arrays will power missions requiring as little as approximately 100 watts, up to several kilowatts (at Earth) in the case of solar electric propulsion missions. Thus, mass and stowage volume minimization will be required over a range of array sizes. Concentrator designs, inflatable structures, and the combination of solar arrays with the telecommunications system have been proposed. Performance, launch vehicle constraints, an cost will be the principal parameters in the design trade space. Other special applications will also be discussed, including requirements relating to planetary landers and probes. In those cases, issues relating to shock loads on landing, operability in (possibly dusty) atmospheres, and extreme temperature cycles must be considered, in addition to performance, stowed volume, and costs.

Bankston, C. P.↗