CubeSat System Reference Model Profile Avatar
  1. OMG Specification

CubeSat System Reference Model Profile — All Issues

  • Acronym: CSRM
  • Issues Count: 21
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CSRM12-3 Informational Update to CSRM Profile Specification CSRM 1.1b1 open
CSRM12-2 Informational Update to CSRM Profile Specification CSRM 1.0 open
CSRM11-3 Create examples of use of the profile CSRM 1.0b1 CSRM 1.1b1 Resolved closed
CSRM11-1 Icons for profile CSRM 1.0b1 CSRM 1.1b1 Resolved closed
CSRM11-2 Add constraints to aid in correctness of profile useage CSRM 1.0b1 CSRM 1.1b1 Closed; Out Of Scope closed
CSRM11-4 Recommended Additions CSRM 1.0a1 CSRM 1.1b1 Closed; Out Of Scope closed
CSRM11-5 xmi profile CSRM 1.0b2 CSRM 1.1b1 Deferred closed
CSRM12-1 xmi profile CSRM 1.0b2 open
CSRM-31 Add comments to 7.6.3 ExtRequirement source/Risk elements CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-28 MeasurementSpecification missing documentation CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-26 VerificationActivity missing documentation on verificaionMethod CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-3 Change 7.6 SysML Extentions CSRM 1.0b1 CSRM 1.0 Closed; No Change closed
CSRM-2 Add relationship convenience attribute for Validated and other relationships CSRM 1.0b1 CSRM 1.0 Duplicate or Merged closed
CSRM-41 Modify Paragraph 2 to remove redundant reference to the machine readable file. CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-35 Clarify usage of Group stereotype CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-12 Recommended Additions CSRM 1.0a1 CSRM 1.0 Deferred closed
CSRM-4 Add constraints to aid in correctness of profile useage CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-9 Change names from CubeSat to Satellite. CSRM 1.0b1 CSRM 1.0 Closed; No Change closed
CSRM-5 Create examples of use of the profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-1 Icons for profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-16 Remove Section 0 from the document CSRM 1.0a1 CSRM 1.0 Closed; No Change closed

Issues Descriptions

Informational Update to CSRM Profile Specification

  • Key: CSRM12-3
  • Status: open  
  • Source: INCOSE ( Haifeng Zhu, David Kaslow)
  • Summary:

    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

  • Reported: CSRM 1.1b1 — Fri, 28 Jun 2024 19:35 GMT
  • Updated: Mon, 1 Jul 2024 15:22 GMT

Informational Update to CSRM Profile Specification

  • Key: CSRM12-2
  • Status: open  
  • Source: INCOSE ( Haifeng Zhu, David Kaslow)
  • Summary:

    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

  • Reported: CSRM 1.0 — Fri, 28 Jun 2024 19:24 GMT
  • Updated: Mon, 1 Jul 2024 15:22 GMT

Create examples of use of the profile

  • Key: CSRM11-3
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Disposition: Resolved — CSRM 1.1b1
  • Disposition Summary:

    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.

  • Updated: Mon, 25 Mar 2024 14:22 GMT
  • Attachments:

Icons for profile

  • Key: CSRM11-1
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Disposition: Resolved — CSRM 1.1b1
  • Disposition Summary:

    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.

  • Updated: Mon, 25 Mar 2024 14:22 GMT

Add constraints to aid in correctness of profile useage

  • Key: CSRM11-2
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Disposition: Closed; Out Of Scope — CSRM 1.1b1
  • Disposition Summary:

    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.

  • Updated: Mon, 25 Mar 2024 14:22 GMT

Recommended Additions

  • Key: CSRM11-4
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Disposition: Closed; Out Of Scope — CSRM 1.1b1
  • Disposition Summary:

    Close because this was against beta

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

  • Updated: Mon, 25 Mar 2024 14:22 GMT
  • Attachments:

xmi profile



Add comments to 7.6.3 ExtRequirement source/Risk elements

  • Key: CSRM-31
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    We are missing the comments to source and risk of ExtRequirement. The elements also need to be printed in the specification. Other tag definitions are also not printed and thus need to be displayed.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 21:53 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    *Add comments to 7.6.3 ExtRequirement *

    Add the following text to 7.6.3 after the Generalization section. To be clear, when complete with all changes we have for 7.6.3, paragraph should look like this:

    Description
    The «ExtRequirement» is a mix-in stereotype that contains generally useful attributes for requirements.
    Note: This stereotype should be used instead of the «extendedRequirement» in the SysML non-normative extension of SysML
    Generalization:
    • SysML::Requirements::Requirement
    Attributes
    • risk : RiskKind - Risk level of the requirement.
    • source : String - Source (originating person and/or organization) of the requirement.
    • /validatedBy : ValidationActivity[0..*] - The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
    Operations:
    • getValidatedBy - The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
    specification:
    Validate.allInstances()->select(base Abstraction.client=ref).base_Abstraction.supplier

  • Updated: Tue, 27 Sep 2022 12:48 GMT

MeasurementSpecification missing documentation

  • Key: CSRM-28
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Need to add documentation of MeasurementSpecification.summary (paragraph 7.28) and fix MeasurementSpecification.id missing documentation.

    The summary element is missing documentation.
    The id incorrectly indicates that it is the id of a requirement, rather than a MeasurementSpecification.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:38 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add documentation to summary and fix documentation in summary

    Add/change documentation as follows to the model and to the specification:

    MeasurementSpecification.summary
    add documentation: The summary is a textual description of constraints, and measurement activities used to provide insight into the progress made in the definition and development of the technical solution, risks, and issues.

    MeasurementSpecification.id
    From: The unique id of the requirement.
    to: The id of the MeasurementSpecification.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

VerificationActivity missing documentation on verificaionMethod

  • Key: CSRM-26
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    VerificationActivity.verificationMethod is missing documentation.

    Proposed fix: add documentation to
    The verificationMethod property indicates the primary method that VerificationActivity uses to verify a Requirement.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:13 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    add documentation to VerificationMethod and show attributes of VerificationActivity

    Change to: 7.4.3 VerificationActivity
    Add the following text to 7.4.3:
    In the profile, add documentation to the verifies attribute of <<VerificationActivity>>:

    The requirements that this VerificationActivity verifies.

    Add previously undocumented attributes (verificationMethod and verifies) of <<VerificationActivity>>: to the specification by adding the revised text to paragraph 7.4.3.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change 7.6 SysML Extentions

  • Key: CSRM-3
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Section 7.6 to be replaced with an official SysML extensions profile. Section 1.6 was a hack that allowed the specification to move forward.

    Unfortunately replacing this section with a SysML profile may not be easy because of issues with how vendors have implemented the SysML extensions. It may be simpler to replicate all or part of the extensions.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:51 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    No change to 7.6 SysML Extensions is required

    No change to 7.6 SysML Extensions is required.

    The creation of an official version of SysML Extensions seems unwise as all the vendors and lots of users would be affected. The current profile described in this section is adequate for our purposes.

    Note: We already voted on this, but having to recreate it because the result was lost.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Add relationship convenience attribute for Validated and other relationships

  • Key: CSRM-2
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    David Kaslow requested that derived properties be added to allow reporting.

    For example, a user of the profile should be able to add to a table a column that matches the Validated By or Validates concepts (and others) similar to how tables can display Verified By and Verifies.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:38 GMT
  • Disposition: Duplicate or Merged — CSRM 1.0
  • Disposition Summary:

    Issue resolved in CSRM-14

    CSRM-2 was re-opened to change the priority (I did not realize this could be modified), CSRM-14 essentially duplicates the issue and was already resolved. Best thing to do is to close this issue as a duplicate of CSRM-14.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Modify Paragraph 2 to remove redundant reference to the machine readable file.

  • Key: CSRM-41
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    As the spec already has a reference to the machine-readable file, this line is redundant.

    This line in paragraph 2 should be removed:

    dtc/22-04-06 - CSRM Profile - XMI File (see the description in Section 6)

    Reported by Pete Rivett during FTF review.

  • Reported: CSRM 1.0a1 — Fri, 17 Jun 2022 19:49 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Remove the following text in section 2 Conformance

    Remove the following text in section 2 Conformance

    dtc/22-04-06 - CSRM Profile - XMI File (see the description in Section 6)

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Clarify usage of Group stereotype

  • Key: CSRM-35
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Clarify the use of the Group stereotype.
    Pete Rivette wrote:
    7.1.12 says that <<Group>> groups related requirements but not which property is used to achieve that.

  • Reported: CSRM 1.0a1 — Thu, 16 Jun 2022 13:46 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add Clairifying info and paragraph to documentation of 7.1.12 Group

    Change the existing documentation of 7.1.12 Group to help understand how the element is used and examples of use.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Recommended Additions

  • Key: CSRM-12
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    Defer to RTF

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Add constraints to aid in correctness of profile useage

  • Key: CSRM-4
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer adding constraints to RTF

    This is rather complex and our team does not have the resources to address. It is also better to address the constraints as people begin to use the profile and as RTF possibly expands the standard.

    Note: We already voted on this in Ballot #1, but the result was lost.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change names from CubeSat to Satellite.

  • Key: CSRM-9
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Dave Kaslow proposes the following changes to stereotypes:

    From: CubeSatRequirement to: SatelliteRequirement
    From: CubeSatSubsystemRequirement to: SatelliteSubsystemRequirement
    From: CubeSatComponentRequirement to: SatelliteComponentRequirement
    From: CubeSatUseCase to: SatelliteUseCase
    From: CubeSatSubsystemUseCase to: SatelliteSubsystemUseCase

    Document attached was where the issue was raised.

  • Reported: CSRM 1.0b1 — Thu, 21 Apr 2022 19:43 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Issue created by mistake

    This issue related to a proposal and this was mistakingly created against the FTF. Closing with no change required.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Create examples of use of the profile

  • Key: CSRM-5
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    The profile is fairly straight forward with much of the vocabulary in MBSE and space domains. Deferring issue to RTF to reconsider for a later version.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Icons for profile

  • Key: CSRM-1
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    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.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    Punting this issue to the next release.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Remove Section 0 from the document

  • Key: CSRM-16
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Per standard process, Section 0 (zero) is to be removed from the Finalized document.,

  • Reported: CSRM 1.0a1 — Fri, 22 Apr 2022 20:42 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Change already made by OMG editor

    Closing subtask that was created by mistake..

  • Updated: Tue, 27 Sep 2022 12:48 GMT