Rationale:
System Adaptability is an increasingly important topic, as it’s an effective way to reduce significant cost overrun and schedule delays, which frequently exist in aerospace industry. It is also listed in INCOSE SE Vision 2035 as one of the backbone technology (ref: "Paul Schreinemakers", leader of FuSE – Future Systems Engineering initiative in INCOSE).
Recent progress in this topics include: Boeing’s adoption of adaptability technique to achieve sustainability (https://www.linkedin.com/feed/update/urn:li:activity:7159262285008437249/ ) and proposal of including adaptability into IEEE Smart Cities standards, etc.
Adaptability is a very important and desirable property of a reference architecture. That allows users to easily adapt to changes in the future, which almost always happen in the aerospace industry. Overly restrictive architecture often cause high cost when requiring changes in the late stages of the development cycle. Thus, it is important to emphasize that CSRM is adaptable per INCOSE’s definition of adaptability in SEBoK.

Recommended Updates:

Doc number: dtc/23-12-05
Page 1

Add one sentence is Section 2:
The CSRM reference architecture defined in conformance with the CSRM Profile accommodates architecture adaptability [REF of SEBoK] and provides necessary facilities (mission profiles). The conformance definition enables user production of high system adaptability per the standard SEBoK definition of adaptability.

Add a reference in Section 3:
[REF of SEBoK] IEEE, INCOSE, Steven Institute of Technology, Systems Engineering Body of Knowledge (SEBoK), version 2.9, System Adaptability Chapter, URL: https://sebokwiki.org/wiki/System_Adaptability , 2024

Rationale:
System Adaptability is an increasingly important topic, as it’s an effective way to reduce significant cost overrun and schedule delays, which frequently exist in aerospace industry. It is also listed in INCOSE SE Vision 2035 as one of the backbone technology (ref: "Paul Schreinemakers", leader of FuSE – Future Systems Engineering initiative in INCOSE).
Recent progress in this topics include: Boeing’s adoption of adaptability technique to achieve sustainability (https://www.linkedin.com/feed/update/urn:li:activity:7159262285008437249/ ) and proposal of including adaptability into IEEE Smart Cities standards, etc.
Adaptability is a very important and desirable property of a reference architecture. That allows users to easily adapt to changes in the future, which almost always happen in the aerospace industry. Overly restrictive architecture often cause high cost when requiring changes in the late stages of the development cycle. Thus, it is important to emphasize that CSRM is adaptable per INCOSE’s definition of adaptability in SEBoK.

Recommended Update:
Doc number: dtc/23-12-05
Page 1

Add one sentence is Section 2:
The CSRM reference architecture defined in conformance with the CSRM Profile accommodates architecture adaptability [REF of SEBoK] and provides necessary facilities (mission profiles). The conformance definition enables user production of high system adaptability per the standard SEBoK definition of adaptability.

Add a reference in Section 3:
[REF of SEBoK] IEEE, INCOSE, Steven Institute of Technology, Systems Engineering Body of Knowledge (SEBoK), version 2.9, System Adaptability Chapter, URL: https://sebokwiki.org/wiki/System_Adaptability , 2024

Originally the first versions of CSRM had examples. However, when the spec was reduced to a profile, the examples were removed. Because of some of the changes, not all examples are viable, so it is proposed we create new examples. Dave Kaslow also requested that the examples be categorized as a simplified and expert use of the profile to aid adoption by students.

Add mention of Educational examples

We have updated and feel that the CSRM is good enough to include, with the specification as educational attachments. We also need to change the text of the specification to mention the availability of MDZIP and XMI versions.

Attached are example versions of the CSRM as ZIP collections in both MDZIP and XMI formats. I will attach a version with the latest version of XMI as part of the release.

The original icons used for stereotypes in the profile were drafts and need to be replaced with better versions. The icons also need to be delivered as SVG.

The document does not currently show these icons, so diagrams need to be updated or an appendix added to the icons.

Icons supplied as educational attachment for use by implementors

Add the following paragraph to section 2, Conformance.

The profile of this version contains icons for most of the stereotypes. These icons are to be considered educational examples that may be replaced with implementation-specific versions. As an aid to implementers, a collection of Scalable Vector Graphic (SVG) files used for the current icons in the profile (currently embedded as encoded SVG) are included as an educational attachment that may be used as a starting point for implementers to create implementation-specific icons.

Constraints should be added to aid in the creating of correct models. For example, an MoE needs to be related to a moeRequirement which in turn is refined by a moeSpecification.

In addition, by categorization and content of warings and error of the constraints, we could add hints for new users of minimal and advanced concepts.

Defer tp RTF 1.2

Need a better set of actual uses of the model to create and test constraints. Defer to 1.2 RTF.

To make the case for updating CSRM stereotypes. Once agreement is reached, updates to the CSRM Specification will be developed.
This is a big deal and needs lots of discussion.

Figures 1 lists CSRM element stereotypes. Black font denotes current baseline as captured in the normative CSRM Profile. Blue font denotes recommended additions.

Figure 2 lists requirement elements related properties that are part of the SysML language.

Figure 3 illustrates one of many ways to establish relationships between the mission stakeholders, requirements, technical measures, and use cases stereotypes. These stereotypes are denoted by italicized font in Figure 1.
The relationships are captured in the element specifications and are displayed and maintained in diagrams and tables as shown in Figure 1.
Object Constraint Language

There has been discussion about codifying the allowable relationships using Object Constraint Language (OCL). OCL is a declarative language describing rules applying to Unified Modeling Language (UML) models. For example, a refine relationship can exist between a requirement. and any other model element, whereas a derive relationship can only exist between requirements.

That could be done founded on the examples in Figure 3. This would be of limited benefit. A mission team will be using the stereotypes and relationships best suited to their mission and the stereotypes in Figure 3 are very limited as compared to Figure 1.

A case could be made to established relationships for the stereotypes in Figure 1. But that is out-of-Scope for the SSWG CSRM effort.

An Issue that Needs Resolution.

The intent of defining addition stereotypes as shown in Figure 1 is to provide stereotypes for a variety of mission architectures. However, several of the stereotypes are identified as CubeSat stereotypes. But they are not unique to CubeSats. The only thing that makes a model a CubeSat model is the incorporation of a CubeSat form factor such as the Cal Poly CubeSat Design Specification.

My recommendation is to rename the stereotypes as show in Table 1 below.

Table 1. Renaming of Stereotypes (Proposed name changes from Figure 1)
CubeSatRequirement SatelliteRequirement
CubeSatSubsystemRequirement SatelliteSubsystemRequirement
CubeSatComponentRequirement SatelliteComponentRequirement
CubeSatUseCase SatelliteUseCase
CubeSatSubsystemUseCase SatelliteSubsystemUseCase

Close because this was against beta

This issue is no longer relevant. Should have been closed in FTF instead of deferred.

Both Firefox and Chrome give the following error when clicking on the link to the XMI format on page https://www.omg.org/spec/CSRM

XML Parsing Error: not well-formed
Location: https://www.omg.org/spec/CSRM/20210801/CSRSM-Profile-XMI.xmi
Line Number 116, Column 99:

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Both Firefox and Chrome give the following error when clicking on the link to the XMI format on page https://www.omg.org/spec/CSRM

XML Parsing Error: not well-formed
Location: https://www.omg.org/spec/CSRM/20210801/CSRSM-Profile-XMI.xmi
Line Number 116, Column 99: