From peter.m.shames at jpl.nasa.gov Fri Feb 21 18:26:16 2020 From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (US 312B)) Date: Fri, 21 Feb 2020 18:26:16 +0000 Subject: [Sea-sa] Application and Support Layer (ASL) status and request for feedback and support for a new RASDS work item Message-ID: <4474DCF8-4D30-481B-8637-F1CF0D0C1004@jpl.nasa.gov> Dear SAWG, As you all know, the work on the Application and Support Layer (ASL) Green Book, CCSDS 371.0-W-0, is (slowly) coming to a close. That document should be sent out for CESG review and approval in the next batch of documents from the CCSDS Chief Technical Editor. There will be the typical 2 week polling period and then a period where we work off and resolve any issues that surface from that review. We have given the key Areas involved in this (MOIMS & SOIS) lots of opportunities to comment upon, and improve upon, the contents of the document. Regardless, I anticipate that we may get a significant set of comments back from this review. We will cross that bridge when we come to it. When we started the ASL work we agreed to use the RASDS methodology, as documented in CCSDS 311.0-M-1. We voted to re-confirm the RASDS until we had time to return to work on it. We also found some useful ways to extend that core framework to do a better job of representing data flows in the Functional viewpoint, to represent the Services viewpoint using a table of services and operations, and to use a modified version of SysML to better represent the Information viewpoint. I think these are excellent extensions of what is already in RASDS and propose that we incorporate them in a next revision of that document. In parallel with this work in CCSDS we have been having some side discussions with our "sister" organization in ISO, TC20/SC14. They also have an interest in extending RASDS. They need exactly the same sorts of viewpoints that we already have defined, Enterprise, Functional, Connectivity, Communications, and Information, but their work products need other viewpoints as well. These include Service (same issues we have), Operations (may be relevant for some MOIMS work), and Physical/Structural ones (not typically a CCSDS concern). Working together with the SC14 to do these extensions should be an excellent approach for both groups. We still need to work out the details, but I believe that having more smart people in the room is a net benefit if we are all working together toward a common goal. See the SC14 current working document reflecting their desired approach to extending RASDS (SC14 Architecture Framework). What has been in discussion in the CESG and CMC is a liaison proposal for us, CCSDS – ISO TC20/SC13 (CCSDS), and ISO TC20/SC14 (SC14) to work together, jointly, to extend RASDS to add these new Viewpoints. This liaison arrangement was approved by the CESG but then got hung up in the CMC on some wording and organizational details. I am now taking this up again and a new CMC resolution has been drafted and sent to a joint ad hoc working group for concurrence. I am attaching it here for your review (CCSDS – SC14 Liaison Resolution SEA). It will shortly be sent to the CMC with a request for approval. This is all "management stuff", but there are also technical aspects I expect you to be more interested in. In addition to incorporating the SCCS and ASL updates to RASDS, and adding the SC14 viewpoints, I am proposing that we further clarify that this methodology, while it uses Powerpoint (or other drawing tool) representations for convenience, is wholly suitable as a framework for MBSE style representations. I propose to tackle this in two ways: 1) by clarifying this methodology vs representation distinction in the text of the body of the document; 2) by adding a new Annex where SysML representation examples for the viewpoints will be provided. Over the years there have been a number of papers and projects published that used RASDS in exactly this way, so examples are pretty easy to come by. I've attached a paper I authored that we can reference, along with SysML models (A Representative Application of a Layered Interface Modelling). Perhaps some of you know of other examples we can leverage. Another potential related work item I want you to be aware of is that the SC14 would like to incorporate their set of vocabulary terms from their normative specs into our current SANA Glossary of Terms (https://sanaregistry.org/r/terms). This will not require much work on our part, other than the clean-up that we must, in any case, do of our own use of terms. The other CCSDS Areas have started to do what they need in this regard. Here too, I think there may be a benefit from us working together with SC14. The SC14 team leading this terminology effort has been supported by some colleagues from the Ukraine (from the Technical Standardization Committee of Ukraine "Rocketry and Space-Rocketry" ) who have created an excellent representation and analysis of the SC14 terminology. The SC14 leadership is exploring with these colleagues whether they would be willing to also do a similar analysis of the CCSDS terminology. This is still very much just in a "discussion" stage, but it could be a very useful outcome for everyone. The last, and most important, topic in this rather long email is this, I would like to request your specific answers to the following questions: 1. Do you support, from a programmatic point of view, the liaison relationship with SC14 and the work proposed? 2. Do you support, from a technical point of view, updating the RASDS document to include the SCCS and ASL extensions along the lines just described? 3. Do you support, from a technical point of view, extending the RASDS document to include the SC14 additions just described? 4. Do you support, from a technical point of view, clarifying the use of SysML to represent RASDS architectural representations? 5. Do you have an interest in supporting any of this work within the SAWG and will your agency support your involvement? Your programmatic and technical feedback (questions 1-4) is important, regardless of whether you and your agency are willing to support the work. I'd like to understand if what is being proposed makes sense to you. Your willingness to support this work (question 5), and your agency's support for that, is essential if we are to be successful in creating this new work project in SEA and having adequate resources to get the work done. I would like to encourage all of you to think about this and see if this is something that you and your agencies are willing to support. We do not need a huge team, but we do need enough active involvement to get the work done. Very best regards, Peter ________________________________________________________ Peter Shames CCSDS Systems Engineering Area Director Jet Propulsion Laboratory, MS 301-490 California Institute of Technology Pasadena, CA 91109 USA Telephone: +1 818 354-5740, Fax: +1 818 393-6871 Internet: Peter.M.Shames at jpl.nasa.gov ________________________________________________________ We must recognize the strong and undeniable influence that our language exerts on our ways of thinking and, in fact, delimits the abstract space in which we can formulate - give form to - our thoughts. Niklaus Wirth -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CCSDS - SC14 Liaison Resolution SEA-R-2020-02-001.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 185181 bytes Desc: CCSDS - SC14 Liaison Resolution SEA-R-2020-02-001.pptx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SC14 Architecture Framework June 2019.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 1150848 bytes Desc: SC14 Architecture Framework June 2019.pptx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: A Representative Application of a Layered Interface Modeling (meta) 2019-12-10.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 2234381 bytes Desc: A Representative Application of a Layered Interface Modeling (meta) 2019-12-10.pptx URL: