[Ccsds-omg-liaison] Initial AB Review of CubeSat Reference Model [to be continued]

[Pete Rivett]

Interesting question about conformance. There are a few aspects:
a) is a modeling tool able to load and support the CSRM profile?
b) is a modeling tool able to additionally load the actual CSRM model?
Despite the model not being normative, the tool is clearly pretty useless
for CSRM purposes if it can load only the profile but not the reference
model/framework that everyone is supposed to start from. In the sense of
tool conformance the reference model is like a test so there's nothing
wrong IMO with using it for conformance
c) is an actual Cubesat model conformant with the constraints in the
profile? Since the constraints in the profile are normative then this can
be part of formal compliance
d) is an actual Cubesat model consistent with the structure in the
reference model? This relates more to your "strongly encouraged" point. I
think this aspect could be taken further (in FTF) with regard to indicating
what must be retained and what dispensed with. It might not represent
formal compliance with the specification but we could use a milder phrase
such as "consistent with".

a) and b) relate to the modeling tool; c) and d) relate to an actual model.
All are, I think, appropriate.

Pete

On Wed, 9 Jun 2021 at 20:01, Manfred Koethe <koethe at 88solutions.com> wrote:

> Hi Dave,
>
> Please find below my very initial review of the current CSRM Submission.
> The quality has substantially improved, but, and I’m sorry to say that, the
> current document is still somewhat disappointing.
>
> I still need to go through the other parts, but are at the moment a bit
> crippled by a hardware failure.
>
> Kind regards,
>
> Manfred
> ___________________
> Manfred Koethe
> 88solutions Corporation
> koethe at 88solutions.com
> +1 (619) 736-1001
>
>
> Initial AB Review: Cube Sat Reference Model [ Part 1 ]
>
> General Note
> -------------------
> The whole document needs a "gramar refurbishment" for improved
> readability. As a non-native (and in particular German) speaker, I don't
> feel qualified to provide fully detailed instructions. I wil try my best,
> however. :-)
>
> Clause 1 Scope
> ----------------------
> In general, I find the the Scope clause rather washed-out and confusing.
> Length is not the criterion here, but clarity is.
>
> The 4th paragraph is particularly confusing:
> "A mission-specific CubeSat team will download the CSRM normative
> Specification XMI file from OMG and import it into their own graphical
> modeling tool. It is anticipated that the mission-specific CubeSat team
> will use non-normative material to guide development of their
> Mission-Specific Model (MSM). The mission team identifies the systems
> engineering methodology to be followed and revises the MSM organization,
> elements, relationships, and diagrams as needed."
>
> It should at least make clear that the CSRM Specification consists of a
> normative profile that defines the necessary stereotypes (and is supposed
> to be used as-is), and an unpopulated, educational CSRM model skeleton as a
> starting point for a project-specific cube sat model.
>
> In summary, Clause 1 Scope should just state three things:
>
> - This is a specification to aid the development of CubeSat Space-Ground
> Systems Models
> - It consists of a normative Profile defining all required stereotypes
> - And it consists of an unpopulated skeleton CubeSat SysML model as
> starting point for project-specific development.
>
> If you can find some nice words around these three key points and get rid
> of all that stakeholder blah blah, that would make a nice, concise and
> attractive Scope clause.
>
> Clause 2 Conformance
> --------------------------------
> The only normative part of this specification is the CSRM Profile, which
> is fundamental to everything else. Therefore, you need to state that:
>
> "Conformant implementations must implement the CSRM Profile in its
> entirety."
>
> [ ideally, the Profile should be usable "as-is, out of the box", however
> experience shows that some form of customization by tool vendors could
> improve the usability of the Profile in the respective tool, therefore it
> is valid to refer to an "implementation" here. ]
>
> For the "educational" part of CSRM, you can legally only state:
>
> "CubSat model developers are strongly encouraged to use the provided
> skeleton model without altering its structure to maximize the opportunity
> for reuse and/or interchange."
>
> Since the provided csrm model itself is not normative, you cannot put more
> force here.
>
> Clause 3 Normative References
> -------------------------------------------
> Besides citing SysML, I believe you need to cite domain-specific documents
> too. I saw  a message from you including such kind of documents, you need
> to reference them here in Clause 3.
>
> Clauses 4 and 5
> -----------------------
> Both clauses should point to Annex B, therefore Clause 5 needs correction.
>
> [ it would improve the structure of the document to make abbreviations,
> references and glossary three separate annexes ]
>
> Clause 6 Additional Information
> -------------------------------------------
> It would be good style to start Clause 6 with an "How to read this
> specification", pointing to the various parts, and in particular enumerate
> which part is normative, which part is informative, and which part is
> educational.
>
> Then, if you really want to talk about all the stuff around stakeholders,
> etc., which you stuffed into the Scope, here would be the right place to
> clean all that stuff out of the Scope and consolidate it in a subclause of
> Clause 6. And since Clause 6 is implicitly non-normative, you don't need to
> mark the moved stuff as informative.
>
> Clause 7 CSRM Profile
> --------------------------------
> Since this specification is a collection of normative, informative and
> educational parts, I recommend to mark Clause 7 explicitly as "normative".
>
> In the first sentence of 7.1, replace "the sysML" by "SysML".
>
> Figure 2 is not readable. Please use (and provide) a SVG vector graphic.
>
> Subclause 7.1.1: The first sentence is incomplete. Also, I'm not sure if
> the whole stakeholder discussion needs to be repeated here, I find it
> rather confusing. Brevity would be helpful. Maybe eliminate thee first
> paragraph, or at least substantially compact it.
>
> Subclause 7.1.3: If MissionNeed "drives everything else", and you are not
> using alphabetic ordering, then why not starting Clause 7 with MissionNeed?
> [ just a thought...]
>
> Subclause 7.1.5: It does not "define the system's expectations" but the
> "expectations on the system's capabilities".
>
> Subclause 7.16: describing "CubeSatRequirement" as "Requirement of the
> CubeSat system" is rather lame and not helpful. Also, shouldn't it be
> "requirements on the CubeSat system"? Your sentence is semantically the
> inverse direction....
>
> Reading on, I have a rather fundamental question:
> You are using the language (in 7.1.6 and following subclauses) "XYZ
> Requirement is a requirement of XYZ", which means XYZ requires something.
> Are you not meaning "XYZ Requirement" is a requirement that XYZ needs to
> fulfill? Then the phrase should be something like "XYZ Requirement" is a
> requirement on (or for) XYZ". Please clarify, this is very important.
>
> Reading on even more, ALL the requirements descriptions are very lame, and
> implying the inverse semantic direction. This MUST be corrected since it
> confuses the reader.
>
> Subclause 7.1.11: What is a "space segment"? This is really in need of a
> few more senseful words.
>
> Subclause 7.1.12: "This element is not intended to be refined, verified,
> satisfied, or verified." What? What does that mean?
>
> Subclause 7.1.13: The description does (IMHO) match the element is is
> supposed to describe.
>
> Subclause 7.1.14: "SegementRequirement : A requirement of a segment" -
> really???
>
> IN SUMMARY OF SUBCLAUSE 7.1: ALL descriptions (and I really mean ALL) of
> the requirements MUST be redone. What you provided is terse to the extreem,
> as if every character would cost extra. Also, from my understanding, ALL
> given description describe the semantic inverse. The descriptions in the
> current form are not acceptable, since no user would understand them
> correctly.
>
> Subclause 7.2.4: The description misses some words to make it fluently
> readable.
>
> Figure 4 is not readable. Please use (and provide) a SVG vector graphic.
>
> Subclause 7.3.3: The description misses some words to make it fluently
> readable.
>
> Figure 7 is not readable. Please use (and provide) a SVG vector graphic.
>
> Annex B
> ------------
> Why are specific tools mentioned here?
>
> "Clean XMI File" is *not* a tool artifact, but an XMI file free of any
> tool-specific notations and/or extensions.
>
> ==> I need to do another pass through the Annex B, so expect more
> comments...
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20210610/6c99f919/attachment-0001.htm>