Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software 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.

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

At least 793 records · Page 44

Optimal Propellant Maneuver Flight Demonstrations on ISS

In this paper, first ever flight demonstrations of Optimal Propellant Maneuver (OPM), a method of propulsive rotational state transition for spacecraft controlled using thrusters, is presented for the International Space Station (ISS). On August 1, 2012, two ISS reorientations of about 180deg each were performed using OPMs. These maneuvers were in preparation for the same-day launch and rendezvous of a Progress vehicle, also a first for ISS visiting vehicles. The first maneuver used 9.7 kg of propellant, whereas the second used 10.2 kg. Identical maneuvers performed without using OPMs would have used approximately 151.1kg and 150.9kg respectively. The OPM method is to use a pre-planned attitude command trajectory to accomplish a rotational state transition. The trajectory is designed to take advantage of the complete nonlinear system dynamics. The trajectory choice directly influences the cost of the maneuver, in this case, propellant. For example, while an eigenaxis maneuver is kinematically the shortest path between two orientations, following that path requires overcoming the nonlinear system dynamics, thereby increasing the cost of the maneuver. The eigenaxis path is used for ISS maneuvers using thrusters. By considering a longer angular path, the path dependence of the system dynamics can be exploited to reduce the cost. The benefits of OPM for the ISS include not only reduced lifetime propellant use, but also reduced loads, erosion, and contamination from thrusters due to fewer firings. Another advantage of the OPM is that it does not require ISS flight software modifications since it is a set of commands tailored to the specific attitude control architecture. The OPM takes advantage of the existing ISS control system architecture for propulsive rotation called USTO control mode1. USTO was originally developed to provide ISS Orbiter stack attitude control capability for a contingency tile-repair scenario, where the Orbiter is maneuvered using its robotic manipulator relative to the ISS. Since 2005 USTO has been used for nominal ISS operations.

Bhatt, Sagar↗

Swamp Works- Multiple Projects

My Surface Systems internship over the summer 2013 session covered a broad range of projects that ranged multiple aspects and fields of engineering and technology. This internship included a project to create a command center for a 120 ton regolith bin, a design and build for a blast shield to add further protection for the Surface Systems engineers, a design for a portable four monitor hyper wall that can extend as large as needed, research and programming a nano drill for a next generation robot, and social media tasks including the making of videos, posting to social networking websites and implementation of a new weekly outreach program to help spread the word about the Swamp Works laboratory. The objectives for the command center were to create a central computer controlled area for the still in production lunar regolith bin. It needed to be easy to use and the operating systems had to be Linux. The objectives for the hyper wall were to build a mobile transport of monitors that could potentially attach to one another. It needed to be light but sturdy, and have the ability to last. The objectives for the blast shield included a robust design that could withstand a small equipment malfunction, while also being convenient for use. The objectives for the nano-drill included the research and implementation of programming for vertical and horizontal movement. The hyper wall and blasts shield project were designed by me in the Pro/Engineer/Creo2 software. Each project required a meeting with the Swamp Works engineers and was declared successful.

Carelli, Jonathan M.↗

Radio Frequency Identification for Space Habitat Inventory and Stowage Allocation Management

To date, the most extensive space-based inventory management operation has been the International Space Station (ISS). Approximately 20,000 items are tracked with the Inventory Management System (IMS) software application that requires both flight and ground crews to update the database daily. This audit process is manually intensive and laborious, requiring the crew to open cargo transfer bags (CTBs), then Ziplock bags therein, to retrieve individual items. This inventory process contributes greatly to the time allocated for general crew tasks.

Wagner, Carole Y.↗

Environmental Control System Software & Hardware Development

ECS hardware: (1) Provides controlled purge to SLS Rocket and Orion spacecraft. (2) Provide mission-focused engineering products and services. ECS software: (1) NASA requires Compact Unique Identifiers (CUIs); fixed-length identifier used to identify information items. (2) CUI structure; composed of nine semantic fields that aid the user in recognizing its purpose.

student↗

Development and Use of the SPACE Computer Code for Analyzing the Space Station Electrical Power System

This special publication tells the story of the dedicated efforts of very talented individuals to create a preeminent space electrical power system modeling and simulation tool called SPACE, short for System Power Analysis for Capability Evaluation. This computer model has evolved for 30 years, withstanding the test of time and obsolescence, and garnering international recognition for its ability to simulate complex space electrical power systems. The analytical results from this model have saved millions of dollars in hardware redesign, testing, and verification for NASA's International Space Station (ISS) and its European and Russian partners. SPACE has played a pivotal role in the station's design and development and continues to support its ongoing operation. It has also extended its reach beyond the ISS to other key NASA programs, where it guides the design and planned operation of NASA's Multi-Purpose Crew Vehicle Orion and simulates electric power system operation in a dusty atmosphere on Mars' surface. The SPACE lineage was created by a core civil servant staff, supplemented by a cadre of interns and other temporary helpers. They created a tightly integrated tool that includes all phenomena that impact a solar array and battery space power system performance. SPACE is self-contained, requiring no other software modules and associated license fees. SPACE "rings true" in that is has been extensively validated with ISS on-orbit telemetry data. This report is being released as the generation of engineers who created it are nearing retirement, passing the baton to a new generation. This next generation will carry the code into the future, no doubt further evolving it to be able to assure mission planners that newly conceived systems will successfully power NASA's next endeavors. As a previous SPACE code developer and analyst, I have worked alongside many of the people mentioned in this report. The engineers who created the code, along with those just now learning it, are among the best and brightest at NASA. It is an honor to write this foreword as the present Branch Chief under which the legacy of SPACE continues to thrive.

Electrical Power System↗

Lander Lighting Solution to Reduce Pilot & Autonomous Approach Errors

The south pole lighting environment will have harsh low inclination sunlight, making overhead judgement of surface features difficult. Autonomous solutions are great, however, the need for visual monitoring and independent go/no-go decisions remain. Our project proposes that lunar landing systems will be better served by including a powerful landing light system that improves visibility of surfaces from overhead by illuminating the ground at critical distances for the crew to make last minute decisions regarding an approach. The project utilized computer-based optical modeling software to predict requirements for a potential landing light system. The analysis based the lamp prediction from commercially available LED chip sets and lamp optics. The goal was to illustrate a method to raise the surface contrast of a landing site within an acceptable contrast threshold for most camera systems and human observers to recognize hazards that would not be noticed with low inclination sunlight alone. The Apollo lunar landings benefitted from overhead sun or dark conditions. The surface lighting at the Lunar South Pole is a harsh environment where surfaces are lit from a low inclination angle by the sun (from the side). This change in lighting condition precipitates a need for updated lunar landing systems that facilitate improved recognition of landing sites, and thereby increase pilot awareness of landing hazards. The reliance on LIDAR and other autonomous mechanisms alone is risky given the known usage of visual monitoring for operator concurrence on current spacecraft programs and present-day autonomous land-based vehicles. Visual monitoring via cameras or windows requires the surface contrast to be within 3 orders of magnitude for reasonable recognition of objects. Artificial overhead illumination, when sufficiently sized, provides a means to even out contrast problems created by low inclination sunlight, potentially reducing piloting errors. Current vehicle requirements do not specify this type of guidance for the purpose of increasing mission success. An optical ray-trace simulation model was developed in Zemax Optics Studio to predict the best combination of LED power, LED optics, lamp quantity, and lamp location to raise the surface contrast to within 2 orders of magnitude from 3 orders required to further increased visibility and reduce risk. The project considered the following design constraints: potential base diameter of lander, approach distance(s) for a go-no-go decision point (200 meter), solar inclination angle (2-7), lunar surface reflectance (10%), LED chip sets, LED focusing optics, LED power, lamp quantity, lamp locations, and illumination diameter of lunar surface landing zone. The results can be used to establish minimum design constraints for vehicle landing light systems. With a solar inclination angle ranging from 2-7 degrees, the horizontal illumination of the lunar surface is attenuated by about 10% when compared to overhead illumination from the Sun. This modifies the sun's maximum of 130,000 lux to 13,000 lux horizontal illuminance. The artificial lighting system was designed to provide an 18-meter-wide illumination zone, to create viewing clearances around a 6-meter-wide lander. The system provides an average illuminance of 300 lux, meeting the 2 orders of magnitude criteria. The solution utilized modern Chip On Board LEDs, that each utilized 17 watts, with focusing Total Internal Reflection (TIR) lenses. A lighting system of 300 LEDs was arrayed along the "bottom" of a “lander”. With 17 watts per LED, the system is estimated to require 5100 watts. This is a large amount of power, but it would only be needed during critical phases during the landing. LED lighting systems can be dimmed, and it is assumed that as the lander arrives closer to the landing site, the lighting system power can be adjusted as needed to produce the necessary surface illuminance. The designed reduction of contrast improves reliability of safety assessments using real time visible light camera systems and out the window viewing by the crew.

T A Clark↗

Interactive Mars: A Direct-Experience Mission

As NASA prepares to explore Mars, we describe an innovative architecture that could be based on public-private partnerships to offset the costs of such a mission, while demonstrating many of the key technologies—propulsion, communications, autonomy, and landing systems—that will be needed for future human exploration. We propose that NASA could use this capability to deliver dozens of small rovers to several sites on Mars to enable the creation of interactive games that would be operated commercially and sponsored privately. NASA would get a reduced cost to demonstrate a portion of the infrastructure needed for human exploration, and the private sector would get access to a new market and sponsorship opportunities for a broadly popular activity. In addition, our proposed architecture could enable a new, intuitive means for scientists to interpret data and conduct ground operations. This proposal is to broadly develop the overall concept, while focusing on the design of the novel communications system, developing requirements for the software architecture needed to control the rovers and implement gaming, and developing gaming concepts.

Carolyn R. Mercer↗

Formal Verification, Distributed Computing, and Path Planning Algorithms

The safety- and mission-critical nature of much of the work done at NASA requires algorithms and software to be exceedingly reliable. Formal methods techniques are one way of ensuring this high level of robustness. This talk will discuss the development and formal verification of autonomous aircraft path planning algorithms related to the Bellman-Ford shortest path algorithm, including consideration of distributed computation of the algorithm.

Formal Methods↗

Compact star-field sensor (SFS)

A compact SFS may can be deployed in small space vehicles. The SFS may have a small size, weight, and low power requirements. The hardware, software, catalogs, and calibration algorithm of the SFS provide highly accurate attitude information that can be used for pointing. For instance, accurate attitude determination may be provided that supports pointing of a deployable high gain helical antenna. A full “lost in space” attitude solution, accurate to about an arcminute, may be accomplished in under a minute. The SFS may be fully reprogrammable on orbit, allowing continued algorithm development and deployment after launch.

79 ASTRONOMY AND ASTROPHYSICS↗

Evaluation of Portable Programming Models to Accelerate LArTPC Detector Simulations

The Liquid Argon Time Projection Chamber (LArTPC) technology is widely used in high energy physics experiments, including the upcoming Deep Underground Neutrino Experiment (DUNE). Accurately simulating LArTPC detector responses is essential for analysis algorithm development and physics model interpretations. Accurate LArTPC detector response simulations are computationally demanding, and can become a bottleneck in the analysis workflow. Compute devices such as General-Purpose Graphics Processing Units (GPGPUs) have the potential to substantially accelerate simulations compared to traditional CPU-only processing. The software development that requires often carries the cost of specialized code refactorization and porting to match the target hardware architecture. With the rapid evolution and increased diversity of the computer architecture landscape, it is highly desirable to have a portable solution that also maintains reasonable performance. We report our ongoing effort in evaluating Kokkos as a basis for this portable programming model using LArTPC simulations in the context of the Wire-Cell Toolkit, a C++ library for LArTPC simulations, data analysis, reconstruction and visualization.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Megawatt Scale Charging System Architecture

The paper presents a novel and futuristic architecture for a megawatt charging system (MCS) capable of charging light, medium, and heavy-duty vehicles. The station architecture consists of multiport systems with each multiport interfacing the grid, EV, PV, and energy storage system through an intermediate DC bus. The station being a “system of systems” requires a complex software layer with intelligence, control, and communication for effective coordination and utilization of the power electronic interfaces and the assets. The paper elaborates on the station architecture and the associated software layer used for control and coordination. Additionally, the paper provides an approach to utilize hardware-in-the-loop (HIL) capabilities to validate such architectures.

Krishna Moorthy, Radha↗

The Implementation of Satellite Attitude Control System Software Using Object Oriented Design

NASA established the Small Explorer (SNMX) program in 1988 to provide frequent opportunities for highly focused and relatively inexpensive space science missions. The SMEX program has produced five satellites, three of which have been successfully launched. The remaining two spacecraft are scheduled for launch within the coming year. NASA has recently developed a prototype for the next generation Small Explorer spacecraft (SMEX-Lite). This paper describes the object-oriented design (OOD) of the SMEX-Lite Attitude Control System (ACS) software. The SMEX-Lite ACS is three-axis controlled and is capable of performing sub-arc-minute pointing. This paper first describes high level requirements governing the SMEX-Lite ACS software architecture. Next, the context in which the software resides is explained. The paper describes the principles of encapsulation, inheritance, and polymorphism with respect to the implementation of an ACS software system. This paper will also discuss the design of several ACS software components. Specifically, object-oriented designs are presented for sensor data processing, attitude determination, attitude control, and failure detection. Finally, this paper will address the establishment of the ACS Foundation Class (AFC) Library. The AFC is a large software repository, requiring a minimal amount of code modifications to produce ACS software for future projects.

Reid, W. Mark↗

Software Validation Work With The ZPPR-15 Data

The analysis activities for fast reactors involve using many different pieces of software that are relied upon for their predictive capabilities. For this software to be considered reliable, documented proof that the predictions of the software are accurate is required. In this manuscript, the validation work that covers some of the Argonne software used in fast reactor design activities is discussed and displayed. This validation work includes neutron and gamma flux distributions, reaction rate distributions, and reactivity worth. In an ideal world, a reactor development program would have access to a comprehensive set of experimental facilities to help inform the design aspects of the reactor itself. While thermal-hydraulics experiments, and to a limited degree mechanical experiments, can be carried out today for validation needs, neutronics related experimental facilities are rather impractical because of the lack of experimental facilities. Given the desired time table for construction of new reactors, the reconstitution or creation of new neutronic experimental facilities is untenable and thus those reactor development programs must rely upon any available experimental measurements that are qualitatively similar to the design. While a methodology has been proposed to assess the similarity between the past experimental measurements and the reactor itself, that aspect is beyond the scope of this manuscript. In this manuscript, the focus is entirely placed on the analysis results for a series of experiments carried out at the ZPPR facility in Idaho in the mid-1980s. In this regard, this manuscript only shows the validation of the stated neutronics software for specific loadings of the ZPPR reactor. Because of the fuel form, its proposed enrichment, and the material content of the reactor core, the ZPPR-15 experiments were identified as potential validation data for the reactor. The ZPPR-15 experiments were intended as mockups of a 330 MWe Integral Fast Reactor program which was a follow on program to the Clinch River Breeder Reactor. In the ZPPR-15 series of experiments, measurements of the neutron spectrum, control rod worth, sodium void worth, foil reaction rate distributions, Doppler worth of heated samples, gamma dose, and axial expansion worth were all carried out and published. In many cases, these reactivity coefficients are good candidates to validate the reactivity coefficient calculation scheme used by the analysis software and included in the safety analysis activities of fast reactor development projects today. This manuscript discusses the modeling methodology and accuracy of the calculated experimental results using the LANL software MCNP and the ANL software package ARC (Argonne Reactor Codes). As will be shown, for many of the experimental measurements, the two software packages are found to be good predictive analysis tools for those experiments. In other cases, problems with the analysis methodology or underlying cross section data are exposed which indicates where predictive analysis is not as reliable. Finally, in some of the measurements the conclusion is reached that the experimental measurement cannot be reproduced with the analysis software as it is simply too difficult.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Software Validation Work With The ZPPR-15 Data

The analysis activities for fast reactors involve using many different pieces of software that are relied upon for their predictive capabilities. For this software to be considered reliable, documented proof that the predictions of the software are accurate is required. In this manuscript, the validation work that covers some of the Argonne software used in fast reactor design activities is discussed and displayed. This validation work includes neutron and gamma flux distributions, reaction rate distributions, and reactivity worth. In an ideal world, a reactor development program would have access to a comprehensive set of experimental facilities to help inform the design aspects of the reactor itself. While thermal-hydraulics experiments, and to a limited degree mechanical experiments, can be carried out today for validation needs, neutronics related experimental facilities are rather impractical because of the lack of experimental facilities. Given the desired time table for construction of new reactors, the reconstitution or creation of new neutronic experimental facilities is untenable and thus those reactor development programs must rely upon any available experimental measurements that are qualitatively similar to the design. While a methodology has been proposed to assess the similarity between the past experimental measurements and the reactor itself, that aspect is beyond the scope of this manuscript. In this manuscript, the focus is entirely placed on the analysis results for a series of experiments carried out at the ZPPR facility in Idaho in the mid-1980s. In this regard, this manuscript only shows the validation of the stated neutronics software for specific loadings of the ZPPR reactor. Because of the fuel form, its proposed enrichment, and the material content of the reactor core, the ZPPR-15 experiments were identified as potential validation data for the reactor. The ZPPR-15 experiments were intended as mockups of a 330 MWe Integral Fast Reactor program which was a follow on program to the Clinch River Breeder Reactor. In the ZPPR-15 series of experiments, measurements of the neutron spectrum, control rod worth, sodium void worth, foil reaction rate distributions, Doppler worth of heated samples, gamma dose, and axial expansion worth were all carried out and published. In many cases, these reactivity coefficients are good candidates to validate the reactivity coefficient calculation scheme used by the analysis software and included in the safety analysis activities of fast reactor development projects today. This manuscript discusses the modeling methodology and accuracy of the calculated experimental results using the LANL software MCNP and the ANL software package ARC (Argonne Reactor Codes). As will be shown, for many of the experimental measurements, the two software packages are found to be good predictive analysis tools for those experiments. In other cases, problems with the analysis methodology or underlying cross section data are exposed which indicates where predictive analysis is not as reliable. Finally, in some of the measurements the conclusion is reached that the experimental measurement cannot be reproduced with the analysis software as it is simply too difficult.

Aliberti, Gerardo↗

FPGA-Based, Self-Checking, Fault-Tolerant Computers

A proposed computer architecture would exploit the capabilities of commercially available field-programmable gate arrays (FPGAs) to enable computers to detect and recover from bit errors. The main purpose of the proposed architecture is to enable fault-tolerant computing in the presence of single-event upsets (SEUs). [An SEU is a spurious bit flip (also called a soft error) caused by a single impact of ionizing radiation.] The architecture would also enable recovery from some soft errors caused by electrical transients and, to some extent, from intermittent and permanent (hard) errors caused by aging of electronic components. A typical FPGA of the current generation contains one or more complete processor cores, memories, and highspeed serial input/output (I/O) channels, making it possible to shrink a board-level processor node to a single integrated-circuit chip. Custom, highly efficient microcontrollers, general-purpose computers, custom I/O processors, and signal processors can be rapidly and efficiently implemented by use of FPGAs. Unfortunately, FPGAs are susceptible to SEUs. Prior efforts to mitigate the effects of SEUs have yielded solutions that degrade performance of the system and require support from external hardware and software. In comparison with other fault-tolerant- computing architectures (e.g., triple modular redundancy), the proposed architecture could be implemented with less circuitry and lower power demand. Moreover, the fault-tolerant computing functions would require only minimal support from circuitry outside the central processing units (CPUs) of computers, would not require any software support, and would be largely transparent to software and to other computer hardware. There would be two types of modules: a self-checking processor module and a memory system (see figure). The self-checking processor module would be implemented on a single FPGA and would be capable of detecting its own internal errors. It would contain two CPUs executing identical programs in lock step, with comparison of their outputs to detect errors. It would also contain various cache local memory circuits, communication circuits, and configurable special-purpose processors that would use self-checking checkers. (The basic principle of the self-checking checker method is to utilize logic circuitry that generates error signals whenever there is an error in either the checker or the circuit being checked.) The memory system would comprise a main memory and a hardware-controlled check-pointing system (CPS) based on a buffer memory denoted the recovery cache. The main memory would contain random-access memory (RAM) chips and FPGAs that would, in addition to everything else, implement double-error-detecting and single-error-correcting memory functions to enable recovery from single-bit errors.

Some, Raphael↗

SAS4A/SASSYS-1 Commercial Grade Dedication Example Report for a Generic Sodium Pool-Type Fast Reactor Application

In the U.S., a key component of the commercialization of advanced reactors is completion of a license application, which must ultimately be approved by the Nuclear Regulatory Commission (NRC). The approval of the license application by the NRC is contingent on satisfactory demonstration of the design basis and the response of the advanced reactor design to transient and accident scenarios using accepted codes and methods. This report describes the qualification and dedication requirements that the advanced reactor safety analysis system software SAS4A/SASSYS-1 are expected to need to fulfill to be used for sodium-cooled pool-type fast reactor licensing. The qualification and dedication requirements are identified through performance critical characteristics and evaluation model acceptance criteria representative of the advanced reactor design considered for licensing. This document captures, additionally, the verification process developed to demonstrate that the software fulfills the qualification and dedication requirements for a generic sodium-cooled pool-type fast reactor as part of the commercial grade dedication process. Like most software that has primarily existed in the research and development space, the most significant challenge facing SAS4A/SASSYS-1 for use in a licensing framework is the availability of a documentation basis describing the code pedigree. SAS4A/SASSYS-1 has been used for licensing of the fast flux test facility (FFTF) and the JOYO sodium-cooled fast reactor in Japan, as well as the design of the CRBR Plant. However, the historical verification and validation (V&V) activities supporting SAS4A/SASSYS-1 development do not align with modern software quality assurance (SQA) and V&V requirements. Two approaches to use of SAS4A/SASSYS-1 in a commercial licensing framework have been identified: commercial-grade dedication (CGD) and software qualification. The methods and requirements prescribed in the ASME NQA-1-2008/2009 Standard and Regulatory Guide 1.203 on the evaluation model development and assessment process (EMDAP) have been used as guidance to define the CGD and qualification processes, respectively. A qualification and dedication requirements matrix has been developed which utilizes fundamental software verification. In this process, software verification is defined as a software quality process aimed at defining software requirement specifications, developing software design documentation, and performing and documenting acceptance testing of the code against requirements. A key element of software qualification and dedication includes determination of software acceptance with respect to critical characteristics relevant to the functional requirements of the software. To assist with identification of cross-cutting transient phenomena and functional requirements, domestic SFR vendor designs have been reviewed to identify a reference SFR design. For this report, the reference design is defined as a pool-type reactor with metal alloy fuel, a liquid-metal intermediate heat transport system, and passive decay heat rejection systems. Given this reference, a series of high-level cross-cutting phenomena was identified for a general class of single-fault undercooling or reactivity insertion transients that scopes the design basis space, with the goal of assisting with prioritization of documentation development efforts for key transient models in SAS: 1) Reactivity feedback response prior to scram; 2) System-wide thermal inertia; 3) Transition in natural circulation flow regime in heat removal systems; 4) Decay heat generation; 5) Steady-state fuel characterization; 5) Clad/fuel behavior at elevated temperatures; 6) Point kinetics and decay heat; 7) Pump coastdown behavior; 8) Core flow redistribution in loss of forced convection; 9) Pool stratification. As a demonstration of CGD of SAS4A/SASSYS-1 for a sodium pool reactor, a software qualification and dedication gap analysis as it relates to code documentation has been performed. This effort leverages the framework established as part of the SAS4A/SASSYS-1 SQA Program. This CGD demonstration provides a framework that vendors can build upon to demonstrate the applicability of the SAS4A/SASSYS-1 software for licensing a sodium-cooled pool-type fast reactor.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

Bridging the Gap Between Requirements and Simulink Model Analysis

Formal verification and simulation are powerful tools for the verification of requirements against complex systems. Requirements are developed in early stages of the software lifecycle and are typically expressed in natural language. There is a gap between such requirements and their software implementations.We present a framework that bridges this gap by supporting a tight integration and feedback loop between high-level requirements and their analysis against software artifacts. Our framework implements an analysis portal within the fret requirements elicitation tool, thus forming an end-to-end, open-source environment where requirements are written in an intuitive, structured natural language, and are verified automatically against Simulink models.

Mavridou, Anastasia↗

Bridging the Gap Between Requirements and Simulink Model Analysis

Formal veri fication and simulation are powerful tools for the veri fication of requirements against complex systems. Requirements are developed in early stages of the software lifecycle and are typically expressed in natural language. There is a gap between such requirements and their software implementations. We present a framework that bridges this gap by supporting a tight integration and feedback loop between high-level requirements and their analysis against software artifacts. Our framework implements an analysis portal within the fret requirements elicitation tool, thus forming an end-to-end, open-source environment where requirements are written in an intuitive, structured natural language, and are veri fied automatically against Simulink models.

FRET↗