Libraries and Resources
SEAM provides access to several internal libraries and resources that projects can make use of, shown in Figure IV.1. TThe available resources include embedded applications, the NASA R&M Objective Hierarchy in GSN format, and example Requirement Models. There are two types of libraries available in SEAM: the Definitions folder containing failure labels for SysML models and tags for GSN models; and Libraries folder that contain model SysML components and subsystems. Each of these libraries and resources will be talked about individually in this chapter.
Figure IV.1 All the libraries and resources currently available in SEAM.
Apps
SEAM can run web-based applications locally, through the Apps folder. Figure IV.2 shows the Apps page and available applications. Applications are opened locally in the SEAM project and run like normal, including any login information. There are currently only two apps available, but more will become available in the future.
Currently available applications:
Figure IV.2 Apps page. Currently available applications that can included in SEAM projects are CRÈME and R-GENTIC.
Definitions
The Definitions folder contains sub-libraries for labels and tags used throughout a project to link different models together and complete coverage checks. The two available sub-libraries are Failure Label and Tag Library, shown in Figure IV.3. More Definitions sub-libraries may be added in the future as the need arises.
Figure IV.3 Definitions folder page. FailureLabels and TagLibrary subfolders are contained within.
Figure IV.4 shows the FailureLabel sub-library with nine (9) pre-made failure labels. Failure labels are used in SysML models to identify the specific effects (consequences) caused by a failure mode to propagate through the connections, as shown in Figure IV.7. The failure labels shown in the figure are generic labels that are used in SysML model templates and are given as examples. Table IV.1 gives a brief definition for each of the default failure labels. Users can add as many failure labels as needed for their projects by dragging more "FailureLabel" blocks from the toolbar on the left into the main folder page.
Figure IV.4 FailureLabel folder page. Failure labels to be used throughout the project are created here.
Table IV.1. Definitions of example failure labels.
| Failure Label | Definition |
|---|---|
| Detla_Power_Event | A temporary, self-recovering change in power. |
| Step_Power_Change | An abrupt change from a high power state to a low power state or vice versa. The change in power state persists until the system acts on it. |
| Gradual_Power_Change | A slow change in power state over time. |
| Incorrect_Power_State | An incorrect power state. |
| Transient_Signal_Error | A temporary, self-recovering change in signal. |
| Persistent_Signal_Error | An abrupt change in signal state that persists until the system acts on it. |
| Stuck_Signal_Error | A persistent change in signal state that cannot be acted upon. |
| Parametric_Signal_Change | A slow change in single state over time. |
| Loss_of_Signal | A loss of signal. |
The TagLibrary page is shown in Figure IV.5. Tags are used in GSN elements that are cross referenced in SysML models to associate the SysML model to its GSN goal. The tags are presented in coverage checks for the GSN models. The example TagLibrary folder only contains one tag, "RadiationCheck," but users are able to create as many tags as needed by dragging more "Tag" blocks from the toolbar on the left into the main folder page.
Figure IV.5 TagLibrary folder page. Tags to be used in GSN models for the project are created here.
Libraries
The Library folder contains template SysML models that can be used throughout any SysML models in the project. Projects can have an unlimited number of Library folders. Figure VI.6 shows an example library that contains four (4) SysML models of commonly used components in the system. Models in libraries can have multiple instances throughout a project, and all instances automatically update when the library model is updated. This reduces the amount of time spent updating models when changes are made to system components. Figure IV.7 shows the SysML fault model for the Sensor component within the Library. All aspects within this model are carried over to all instances of this model in the project. If any aspect is changed, it is also changed in all instances. More is said about the specifics of SysML models in Chapter 6.
Figure IV.6 Library page. This example Library contains four (4) SysML components.
Figure IV.7 Sensor fault model in Library.
R&M Objective Hierarchy
The NASA Reliability and Maintainability (R&M) Standard "specifies technical objectives and related strategies for NASA programs and projects to be used in planning, executing, and evaluating Reliability and Maintainability,1" and is expressed in GSN format. This standard provides a useful starting place for GSN models.
Link to NASA R&M Standard: https://standards.nasa.gov/standard/nasa/nasa-std-87291
Figure IV.8 NASA R&M Objective Hierarchy. The Hierarchy is in GSN format as a reference for users.
Requirements Models
Requirements models can be created from scratch following SysML standards or imported from Cameo/ MagicDraw models. Requirements in the requirement models are cross-referenced with goals in GSN models to indicate where certain Goals in GSN model are derived from. Figure IV.9 shows example requirements.
Figure IV.9 Requirements Model page.