Requirements, architectures and risks
We advocate the use of risk-based reasoning to help make good architectural decisions. We explore the adaptation of a risk management process and tool to this purpose.
risk requirements architectures↗
SEARCH · Engineering Papers
Results for “risk requirements architectures”
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.
Nasa Conjunction Assessment Risk Analysis Updated Requirements Architecture
The NASA Conjunction Assessment Risk Analysis (CARA) program has been performing routine on-orbit satellite conjunction risk analysis for unmanned NASA spacecraft since 2005, and has developed a robust operations procedure and set of recommended best practices for operational conjunction assessment. However, a number of recent developments in Space Situational Awareness and commercial space operations conduct, such as the immanent deployment of much more sensitive space sensing systems and the launching of much larger satellite constellations, have begun to challenge these standard collision risk parameters and calculations. In response CARA has pursued a multi-year evaluation initiative to re-examine risk assessment algorithms and techniques, to develop needed improvements, and to assemble analysis-based operational requirements. This paper gives an overview of the principal parts of the Conjunction Assessment (CA) risk assessment process used at CARA, outlines the technical challenges that each part presents, surveys the possible solutions, and then indicates which particular solution is being recommended for NASA.
Newman, Lauri K.↗
NASA Conjunction Assessment Risk Analysis (CARA) Updated Requirements Architecture
The NASA Conjunction Assessment Risk Analysis (CARA) program has been performing routine on-orbit satellite conjunction risk analysis for unmanned NASA spacecraft since 2005, and has developed a robust operations procedure and set of recommended best practices for operational conjunction assessment. However, a number of recent developments in Space Situational Awareness and commercial space operations conduct, such as the immanent deployment of much more sensitive space sensing systems and the launching of much larger satellite constellations, have begun to challenge these standard collision risk parameters and calculations. In response CARA has pursued a multi-year evaluation initiative to re-examine risk assessment algorithms and techniques, to develop needed improvements, and to assemble analysis-based operational requirements. This paper gives an overview of the principal parts of the Conjunction Assessment (CA) risk assessment process used at CARA, outlines the technical challenges that each part presents, surveys the possible solutions, and then indicates which particular solution is being recommended for NASA.
Newman, L. K.↗
Systems Engineering and Technology Considerations of a Mars Ascent Vehicle
A Mars Ascent Vehicle (MAV) systems engineering study is underway to define the driving requirements, system architecture, major risks, and required technology developments to support the launch of a rock core sample to a specified delivery orbit for later retrieval and return to Earth. The proposed MAV would essentially be a small-scale launch vehicle, the first of its kind to be launched autonomously from another planet. The MAV would be a flight element of the proposed Mars Sample Return (MSR) campaign architecture, which currently assumes a 2018 launch of the sample caching mission and a 2024 (Earth) launch date of the MAV and lander, with arrival on Mars in 2025. After 9 months on the surface the MAV would be erected and launched to a specified delivery orbit. In the delivery orbit it would release its payload, a 5 kg sphere containing the rock core sample. An orbiter would rendezvous and capture the payload, returning it to Earth a year later.
entry, descent, and landing (EDL)↗
Probabilistic risk reduction
We present an integrated approach to risk assessment and risk mitigation that is well suited to planning the development of complex software systems.
risk requirements architectures↗
NASA Space Nuclear Propulsion (SNP) MBSE Initiatives
NASA’s Space Nuclear Propulsion (SNP) program is developing several MagicDraw SysML models to support the development of high performance Nuclear Thermal Rocket Engines (NTRE). Currently, the Demonstration Rocket for Agile Cislunar Operations (DRACO) project is aiming to perform the first ever flight demonstration of an NTRE, and NASA is developing a DRACO Insight Project Model Based Systems Engineering (MBSE) model to capture, define, analyze, and report on the flight and ground test system architecture, functional behavior, requirements, risks, and lessons learned. Additional models are in work for engine component trade trees, fault detection sensor coverage analysis using a Goal Function Tree (GFT) plugin, stakeholder engagement, and technology maturation projects. The GFT plugin is the Galois, Inc. Failure Recovery Instruction Generation using Automata derived from Traditional Engineering models (FRIGATE) tool. A new capability for Jira to MagicDraw data sharing using the OpenPDM collaboration platform is under development with partner Victory Solutions, Inc. to enhance risk impact analysis.
Space Nuclear Propulsion (SNP)↗
Managing Flagship Missions to Reduce Cost and Schedule
Flagship missions are highly complex with highly nested systems. This level of complexity poses unique management problems as complexity influences risk which, in turn, affects cost and schedule. Establishing a strong technical and programmatic leadership team is critical to mission success. Developing and using a mission architecture is critical to informing the management organization, product ownership, interface and integration relationships, schedule organization, and integration and test paths. In highly nested systems, the mission phasing can be significantly out of sync with product phasing. Targeted technology development prior to Phase A is critical to reducing risk. Early architecture, concept design, and requirements development is critical to reducing risk. Modular design; pathfinders; parallel manufacturing and integration and test paths; and properly handling institutional requirements across interfaces are all management techniques that can be applied to reduce risk. NASA’s large strategic missions, sometimes referred to as flagship missions, are designed to provide answers to some of the most compelling scientific questions being asked. These types of missions are a series of highly nested subsystems that pose unique management problems when compared to more traditional instrument and spacecraft designs. They typically have an overall architecture that is very complex and nested; they typically require a tremendous amount of technology development; they typically involve many contractors and subcontractors with many associated contracts; and they typically involve staff from all over the world. Successful management of a flagship requires the balance between science requirements, engineering and technology capabilities, and resource constraints. Mismanaging these flagship missions can and will lead to significant cost and schedule growth, both of which are detrimental to NASA’s overall reputation which, in turn, is detrimental to the development of future flagship missions. While many of the same management principles used on smaller instruments and spacecraft are relevant, managing flagship missions requires an evolution of those current best practices to better address the specific needs and additional complexity and vastness of these missions. This paper explores how to leverage lessons learned from previous flagship missions to better manage flagship missions in the future.
Hylan, Jason↗
Architecture and Information Requirements to Assess and Predict Flight Safety Risks During Highly Autonomous Urban Flight Operations
As aviation adopts new and increasingly complex operational paradigms, vehicle types, and technologies to broaden airspace capability and efficiency, maintaining a safe system will require recognition and timely mitigation of new safety issues as they emerge and before significant consequences occur. A shift toward a more predictive risk mitigation capability becomes critical to meet this challenge. In-time safety assurance comprises monitoring, assessment, and mitigation functions that proactively reduce risk in complex operational environments where the interplay of hazards may not be known (and therefore not accounted for) during design. These functions can also help to understand and predict emergent effects caused by the increased use of automation or autonomous functions that may exhibit unexpected non-deterministic behaviors. The envisioned monitoring and assessment functions can look for precursors, anomalies, and trends (PATs) by applying model-based and data-driven methods. Outputs would then drive downstream mitigation(s) if needed to reduce risk. These mitigations may be accomplished using traditional design revision processes or via operational (and sometimes automated) mechanisms. The latter refers to the ‘in-time’ aspect of the system concept. This report comprises architecture and information requirements and considerations toward enabling such a capability within the domain of low altitude highly autonomous urban flight operations. This domain may span, for example, public-use surveillance missions flown by small unmanned aircraft (e.g., infrastructure inspection, facility management, emergency response, law enforcement, and/or security) to transportation missions flown by larger aircraft that may carry passengers or deliver products. Caveat: Any stated requirements in this report should be considered initial requirements that are intended to drive research and development (R&D). These initial requirements are likely to evolve based on R&D findings, refinement of operational concepts, industry advances, and new industry or regulatory policies or standards related to safety assurance.
Young, Steven↗
Status of Constellation Pressure Garment Development
The Constellation Program requires the development of a space suit system to meet new requirements for launch, entry, and abort crew survival functions, microgravity intravehicular and extravehicular activities, and lunar surface exploration. This paper summarizes recent work and the current status of the NASA Constellation Space Suit Element Pressure Garment and Crew Survival Subsystem (PG/CS). The emphasis of the work by the PGS/CS team has been in the areas of feasibility studies toward PGS/CS architecture definition, risk mitigation, and requirements development. Included are results from component level engineering studies, testing in the Orion Vehicle and Orion seat mockups, microgravity testing on the Reduced Gravity Aircraft, occupant protection sled testing, analyses and studies, and their implications on Constellation PG/CS subsystem.
Ross, Amy↗
Method for Tracking and Communicating Aggregate Risk Through the Use of Model-Based Systems Engineering (MBSE) Tools
Large, complex projects can identify a significant number and variety of risks, throughout the project life cycle. These risks are analyzed, mitigated, closed or accepted as independent uncertainties. Once closed or accepted, it is easy for projects to lose awareness of their impact. In reality, each of these risks contributes some amount to the overall risk posture of the project. The ability to track and effectively communicate this aggregate risk has represented a challenge to project management. There have been previous attempts to create a schema to communicate the aggregate effect of risks, without notable success. Most of these attempts have centered on some additive metric derived from the scoring of likelihood and consequence values. This, in and of itself, is a logical approach, but all too often the scores were then aggregated to a level where all context was lost. One weakness has been a lack of attempt to create linkages or logical groups of the risks upon which useful aggregation could then occur. The overall move to model-based (systems) engineering (MBSE) has opened up a vast frontier of opportunities to better integrate all project data. MBSE provides an underlying layer that links data items to each other. Objectives link to requirements, which then link to functions, functions to physical architecture items, and so on, as far down as projects want to model. While it started with a focus on modeling requirements based on things like use cases, efforts are now underway to integrate safety and mission assurance (S&MA) information and analyses, such as risks. This effort, called Model Based Mission Assurance (MBMA), is yielding models that are more useful and are a more accurate representations of the systems. MBSE models, with this ability to link related items, provide a new means of tracking and communicating aggregate risks. In the proposed method, risks are added into the models as distinct items, having attributes that communicate a scoring derived from the likelihood and consequence values as charted on the standard NASA 5x5 risk matrix. Like earlier efforts, each box in the 5x5 has an associated scoring, which may include both a current score and potential post-mitigation/control score. The risk items are then linked to elements of the model, such as system objectives/goals, requirements, functions, or physical architecture items, with "Risk to" relationships. These risks will then be communicated by use of reports generated from the model, detailing all risks and/or hazards linked to model elements. These reports can include aggregate impacts, including a current scoring and potential future state scoring based on the planned mitigations and/or controls. These reports will show all risks, open, accepted, and closed, linked to project objectives or requirements. When run as part of an upcoming risk acceptance discussion, these reports will serve to remind the team of all previous risks that relate to the effected portion of the system. When included as part of periodic program or project reviews, risk reviews, and safety reviews, this method can improve the overall understanding of the system's true risk posture. This proposed method takes full advantage of the advances that modern modeling techniques provide, with a minimal investment of additional time. Utilizing the model environment also enables a near constant access to current state of aggregate risks.
model based mission assurance↗
C-Band Airport Surface Communications System Standards Development. Phase II Final Report. Volume 2: Test Bed Performance Evaluation and Final AeroMACS Recommendations
This report is provided as part of ITT s NASA Glenn Research Center Aerospace Communication Systems Technical Support (ACSTS) contract NNC05CA85C, Task 7: New ATM Requirements-Future Communications, C-Band and L-Band Communications Standard Development and was based on direction provided by FAA project-level agreements for New ATM Requirements-Future Communications. Task 7 included two subtasks. Subtask 7-1 addressed C-band (5091- to 5150-MHz) airport surface data communications standards development, systems engineering, test bed and prototype development, and tests and demonstrations to establish operational capability for the Aeronautical Mobile Airport Communications System (AeroMACS). Subtask 7-2 focused on systems engineering and development support of the L-band digital aeronautical communications system (L-DACS). Subtask 7-1 consisted of two phases. Phase I included development of AeroMACS concepts of use, requirements, architecture, and initial high-level safety risk assessment. Phase II builds on Phase I results and is presented in two volumes. Volume I is devoted to concepts of use, system requirements, and architecture, including AeroMACS design considerations. Volume II (this document) describes an AeroMACS prototype evaluation and presents final AeroMACS recommendations. This report also describes airport categorization and channelization methodologies. The purposes of the airport categorization task were (1) to facilitate initial AeroMACS architecture designs and enable budgetary projections by creating a set of airport categories based on common airport characteristics and design objectives, and (2) to offer high-level guidance to potential AeroMACS technology and policy development sponsors and service providers. A channelization plan methodology was developed because a common global methodology is needed to assure seamless interoperability among diverse AeroMACS services potentially supplied by multiple service providers.
Hall, Edward↗
C-Band Airport Surface Communications System Standards Development. Phase II Final Report. Volume 1: Concepts of Use, Initial System Requirements, Architecture, and AeroMACS Design Considerations
This report is provided as part of ITT s NASA Glenn Research Center Aerospace Communication Systems Technical Support (ACSTS) contract NNC05CA85C, Task 7: New ATM Requirements-Future Communications, C-Band and L-Band Communications Standard Development and was based on direction provided by FAA project-level agreements for New ATM Requirements-Future Communications. Task 7 included two subtasks. Subtask 7-1 addressed C-band (5091- to 5150-MHz) airport surface data communications standards development, systems engineering, test bed and prototype development, and tests and demonstrations to establish operational capability for the Aeronautical Mobile Airport Communications System (AeroMACS). Subtask 7-2 focused on systems engineering and development support of the L-band digital aeronautical communications system (L-DACS). Subtask 7-1 consisted of two phases. Phase I included development of AeroMACS concepts of use, requirements, architecture, and initial high-level safety risk assessment. Phase II builds on Phase I results and is presented in two volumes. Volume I (this document) is devoted to concepts of use, system requirements, and architecture, including AeroMACS design considerations. Volume II describes an AeroMACS prototype evaluation and presents final AeroMACS recommendations. This report also describes airport categorization and channelization methodologies. The purposes of the airport categorization task were (1) to facilitate initial AeroMACS architecture designs and enable budgetary projections by creating a set of airport categories based on common airport characteristics and design objectives, and (2) to offer high-level guidance to potential AeroMACS technology and policy development sponsors and service providers. A channelization plan methodology was developed because a common global methodology is needed to assure seamless interoperability among diverse AeroMACS services potentially supplied by multiple service providers.
Hall, Edward↗
Second Generation RLV Space Vehicle Concept
NASA has a long history of conducting development programs and projects in a consistent fashion. Systems Engineering within those programs and projects has also followed a given method outlined by such documents as the NASA Systems Engineering Handbook. The relatively new NASA Space Launch Initiative (SLI) is taking a new approach to developing a space vehicle, with innovative management methods as well as new Systems Engineering processes. With the program less than a year into its life cycle, the efficacy of these new processes has yet to be proven or disproven. At $776M for phase 1, SLI represents a major portion of the NASA focus; however, the new processes being incorporated are not reflected in the training provided by NASA to its engineers. The NASA Academy of Program and Project Leadership (APPL) offers core classes in program and project management and systems engineering to NASA employees with the purpose of creating a "knowledge community where ideas, skills, and experiences are exchanged to increase each other's capacity for strong leadership". The SLI program is, in one sense, a combination of a conceptual design program and a technology program. The program as a whole doesn't map into the generic systems engineering project cycle as currently, and for some time, taught. For example, the NASA APPL Systems Engineering training course teaches that the "first step in developing an architecture is to define the external boundaries of the system", which will require definition of the interfaces with other systems and the next step will be to "define all the components that make up the next lower level of the system hierarchy" where fundamental requirements are allocated to each component. Whereas, the SLI technology risk reduction approach develops architecture subsystem technologies prior to developing architectures. The higher level architecture requirements are not allowed to fully develop and undergo decomposition and allocation down to the subsystems before the subsystems must develop allocated requirements based on the highest level of requirements. In the vernacular of the project cycles prior to the mid 1990's, the architecture definition portion of the program appears to be at a generic Phase A stage, while the subsystems are operating at Phase B. Even the management structure of the SLI program is innovative in its approach to Systems Engineering and is not reflected in the APPL training modules. The SLI program has established a Systems Engineering office as an office separate from the architecture development or the subsystem technology development, while that office does have representatives within these other offices. The distributed resources of the Systems Engineering Office are co-located with the respective Project Offices. This template is intended to provide systems engineering as an integrated function at the Program Level. the program management of SLI and the MAT agree that "program/project managers and the systems engineering team must work closely together towards the single objective of delivering quality products that meet the customer needs". This paper will explore the differences between the methods being taught by NASA, which represent decades of ideas, and those currently in practice in SLI. Time will tell if the innovation employed by SLI will prove to be the model of the future. For now, it is suggested that the training of the present exercise the flexibility of recognizing the new processes employed by a major new NASA program.
Bailey, Michelle↗
Aerocapture Design Study for a Titan Polar Orbiter
In 2014 a team at NASA Goddard Space Flight Center (GSFC) studied the feasibility of using active aerocapture to reduce the chemical Delta V requirements for inserting a small scientific satellite into Titan polar orbit. The scientific goals of the mission would be multi-spectral imaging and active radar mapping of Titan's surface and subsurface. The study objectives were to: (i) identify and select from launch window opportunities and refine the trajectory to Titan; (ii) study the aerocapture flight path and refine the entry corridor; (iii) design a carrier spacecraft and systems architecture; (iv) develop a scientific and engineering plan for the orbital portion of the mission. Study results include: (i) a launch in October 2021 on an Atlas V vehicle, using gravity assists from Earth and Venus to arrive at Titan in January 2031; (ii) initial aerocapture via an 8-km wide entry corridor to reach an initial 350X6000 km orbit, followed by aerobraking to reach a 350X1500 km orbit, and a periapse raise maneuver to reach a final 1500 km circular orbit; (iii) a three-part spacecraft system consisting of a cruise stage, radiator module, and orbiter inside a heat shield; (iv) a 22-month mission including station keeping to prevent orbital decay due to Saturn perturbations, with 240 Gb of compressed data returned. High-level issues identified include: (i) downlink capability - realistic downlink rates preclude the desired multi-spectral, global coverage of Titan's surface; (ii) power - demise of the NASA ASRG (Advanced Stirling Radioisotope Generator) program, and limited availability at present of MMRTGs (Multi-Mission Radioisotope Generators) needed for competed outer planet missions; (iii) thermal - external radiators must be carried to remove 4 kW of waste heat from MMRTGs inside the aeroshell, requiring heat pipes that pass through the aeroshell lid, compromising shielding ability; (iv) optical navigation to reach the entry corridor; (v) the NASA requirement of continuous critical event coverage for the orbiter, especially during the peak heating of the aerocapture when the radio link will be broken. In conclusion, although Titan aerocapture allows for considerable savings in propellant mass, this comes at a cost of increased mission complexity. Further architecture study and refinement is required to reduce high-level mission risks and to elucidate the optimum architecture.
Nixon, Conor A.↗
Risk Trade-Space Analysis for Safe Human Expeditions to Mars
We assessed the integrated safety, health, and performance risk to crews on long-duration missions, specifically to Mars. Using a systems approach rather than one focused on individual countermeasures, we examined the trade space around several such risks to identify high-potential risk mitigation strategies and characterize aspects of Mars mission architectures that could lower aggregated risk. Current Mars Design Reference missions would require durations well over two years and would increase crew exposure to radiation and microgravity well beyond ISS levels, likely resulting in significantly reduced performance beyond our current capability to mitigate that could jeopardize mission success. A “fast Mars transit” round-trip mission concept was studied using an innovative flight dynamics approach to quantify the minimum total mission energy required for a Mars transit with total mission duration less than 400 days. This approach holds promise for sending humans to Mars and returning them safely with acceptable, potentially mitigatable, exposure to microgravity and radiation using current or near-term technologies. The fast transit concept would also result in fewer time-driven vehicle failures and enable sustainable deployment of humans and infrastructure to Mars on a regular cadence, allowing steady exploration and colonization of Mars. Finally, we conclude that reliance on the Low Earth Orbit (LEO) mission operations paradigm – i.e., one of near-complete real-time dependence on experts at Mission Control to manage the combined state of the mission, vehicle, and crew – is high risk given the communication delays and limited resupply of any Mars mission, and this risk is not eliminated by the shorter missions durations of fast transit scenarios. Based on historical trends, it is highly likely that the crew will face a high-consequence problem of uncertain origin during Mars transit when ground support will be greatly reduced. While it may be possible to reduce anomaly rates through improved reliability analysis and testing, and to reduce anomaly impacts through added robustness, such mitigations address only known failure modes and known uncertainties. Therefore, a radical shift in the Human-Systems Integration Architecture (HSIA) that defines the operational paradigm, systems design, and human-systems interactions is required to improve the risk posture to an acceptable level regardless of mission duration.
Mars↗
Full Mission Astronaut Radiation Exposure Assessments for Long Duration Lunar Surface Missions
Risk to astronauts due to ionizing radiation exposure is a primary concern for missions beyond Low Earth Orbit (LEO) and will drive mission architecture requirements, mission timelines, and operational practices. For short missions, radiation risk is dominated by the possibility of a large Solar Particle Event (SPE). Longer duration missions have both SPE and Galactic Cosmic Ray (GCR) risks. SPE exposure can contribute significantly toward cancer induction in combination with GCR. As mission duration increases, mitigation strategies must address the combined risks from SPE and GCR exposure. In this paper, full mission exposure assessments were performed for the proposed long duration lunar surface mission scenarios. In order to accomplish these assessments, previously developed radiation shielding models for a proposed lunar habitat and rover were utilized. End-to-End mission exposure assessments were performed by first calculating exposure rates for locations in the habitat, rover, and during Extra-Vehicular Activities (EVA). Subsequently, total mission exposures were evaluated for the proposed timelines. Mission exposure results, assessed in terms of effective dose, are presented for the proposed timelines and recommendations are made for improved astronaut shielding and safer operational practices.
Adamczyk, Anne↗
VIPER – Volatiles Investigating Polar Exploration Rover: Mission Overview
VIPER is a low cost, lunar volatiles detection and measurement mission that will be delivered to the lunar south pole by one of NASA’s Commercial Lunar Payload Services partners and will characterize the nature of the volatiles in the area and extrapolate this data to create global lunar water resource maps. It will be the first mining expedition on another world while simultaneously addressing fundamental planetary science questions. Prospecting for lunar water at the poles is the next step in understanding the resource potential and addressing key theories about water emplacement and retention. It now appears that potentially economically significant amounts of water ice exists at the poles of the Moon, however, the distribution of this water is still not understood at a level sufficient to fully evaluate economic models. The water ice (and other potential volatiles), the “ore body”, needs to be understood at the scales of 10s to 100s of meters to evaluate localization, extraction and processing techniques. To accomplish this, VIPER will survey permanently-shadowed regions, semi-permanent shadowed regions, and even semi and full sunlit areas in order to have a comprehensive survey of polar region volatiles, to best inform future mission architectures. In order to characterize the volatiles, a payload suite consisting of a neutron spectrometer, mass spectrometer, near infrared spectrometer and a 1-meter drill will be hosted on the VIPER mobile lunar rover platform. Since VIPER is a relatively low cost, schedule-constrained, risk-tolerant mission, there are architectural limitations that require unique mission planning constraints to enable exploration of the lunar south pole region. These regions offer unique challenges such as uncertain terrain conditions, rock and crater hazards, lunar dust, multipath communications effects, extreme thermal environments and multiple overlapping planning constraints. Mission design/traverse planning, system design capabilities and mission operations are all highly linked through initial development phases. We will describe the current mission overview and the unique approaches taken by the VIPER project based on our programmatic framework and unique mission environment.
VIPER↗
Model-Driven Development of Safety Architectures
We describe the use of model-driven development for safety assurance of a pioneering NASA flight operation involving a fleet of small unmanned aircraft systems (sUAS) flying beyond visual line of sight. The central idea is to develop a safety architecture that provides the basis for risk assessment and visualization within a safety case, the formal justification of acceptable safety required by the aviation regulatory authority. A safety architecture is composed from a collection of bow tie diagrams (BTDs), a practical approach to manage safety risk by linking the identified hazards to the appropriate mitigation measures. The safety justification for a given unmanned aircraft system (UAS) operation can have many related BTDs. In practice, however, each BTD is independently developed, which poses challenges with respect to incremental development, maintaining consistency across different safety artifacts when changes occur, and in extracting and presenting stakeholder specific information relevant for decision making. We show how a safety architecture reconciles the various BTDs of a system, and, collectively, provide an overarching picture of system safety, by considering them as views of a unified model. We also show how it enables model-driven development of BTDs, replete with validations, transformations, and a range of views. Our approach, which we have implemented in our toolset, AdvoCATE, is illustrated with a running example drawn from a real UAS safety case. The models and some of the innovations described here were instrumental in successfully obtaining regulatory flight approval.
Safety case↗