[Sea-sa] CCSDS SAWG telecon minutes - 19 Jan 16

[Shames, Peter M (312B)]

Agenda, 19 Jan 2016 Telecon

  1.  Review Roger’s top level view of the MOIMS layered service architecture
  2.  Review Ray's similar top level view of the SOIS layered service architecture
  3.  Review Yonghui's view of the “Plug and Play” parts of the SOIS architecture

Attendees: Roger Thompson,  Yonghui Hwang, Jean-Loup Terraillon, Johnathan Wilmot, Ray Krosley, Eduardo Bergamini, Xiongwan He, Peter Shames


Meeting materials are in the CWE at: SEA Area / SEA-SA / Meeting Materials / 2016 / 2016 Telecon Materials http://cwe.ccsds.org/sea/docs/Forms/AllItems.aspx?RootFolder=%2Fsea%2Fdocs%2FSEA-SA%2FMeeting%20Materials%2F2016%2F2016%20Telecon%20Materials&View={50B434A7-BB62-4E03-A971-45271E7C0B86}&


Action Items from 1 Dec 2015

  1.  RT  to develop a RASDS style view of the SM&C top level architecture
     *   Not done due to other pressing commitments
  2.  RK to develop a RASDS style version of the SOIS top level architecture
     *   Reviewed at this meeting, more below
  3.  YH to develop a RASDS style version of the SOIS Plug and Play architecture
     *   Reviewed at this meeting, more below

Notes from 19 Jan 2016

  1.  YH presented the revised SOIS Plug and Play diagram.  He included functions and information flows on the diagram, as requested.
     *   YH also provided a separate list of the major functions and their nominal set of interfaces
     *   There were some questions about features shown in the original diagram, such as the “Software Bus" and whether that was actually the MTS, the inclusion of a “Sync” element that appears to really have been DDS, and the meaning of the “Adapter”.
     *   JW amd RK, who both have a deeper understanding of SOIS were able to clear these questions up and will work with YH to refine the diagram
     *   General agreement that this sort of function and data flow diagram is what is needed across the set of materials we are developing
     *   Also agreement that the details of the interfaces (or services) offered by each function is important, but some question about the best way to represent this
  2.  RK presented the revised SOIS top level set of diagrams.  He included the top level SOIS view showing functions and layers.  In succesive diagrams he showed a set of four functional groups
     *   RK also provided on each chart the major functions and their behaviors.
     *   A quite complete set of services with identified interfaces for each function was shown on a separate UML Class diagram, which provides a pretty compact representation.
     *   This set of diagrams had been reviewed by the SOIS team prior to this telecon, which was very useful as their inputs had already been baked in
     *   The set of functional groups was incomplete since it left out the plug and play functions that YH was addressing separately.
     *   There was some discussion of the choice of functional group names since they did not always adequately reflect the functions that were included and some functions, like Command and Data Acquisition Services, which appear on the top level SOIS chart, were left out (or included in what was called Communication Protocols).

Post meeting analysis and discussion

  1.  What follows are some notes based on analysis of what was presented, with the intent of providing some better guidance as to how we might proceed.
  2.  The diagrams that were presented were of several different types:
     *   Function and data flow diagrams with identified parameter types (RASDS functional view)
     *   Functional groupings (also RASDS functional view, but without labeled data flows), but including good overview behavioral descriptions for each function
     *   List of functions and the major data items visible at the interfaces, and a different diagram with similar content but using UML class representation and showing each of the types of interface requests that are provided
     *   There were some questions about features shown in the original diagram, such as the “Software Bus" and whether that was actually the MTS, the inclusion of a “Sync” element that appears to really have been DDS, and the meaning of the “Adapter”.
  3.  With the intent of providing a good overall description of the agrregate architecture for each CCSDS Area, and to provide in a concise form the necessary features of the architecture, I suggest we adopt at least this set of views:
     *   One top level architecture diagram extracted from the relevant CCSDS document (in whatever style they chose)
     *   One top level architecture diagram in RASDS style, restating the original so they can see the mapping
     *   One (or more as needed) function and data flow diagram showing identified information types on the flows between functions
     *   A list of functions, behavioral descriptions, and key interfaces  The UML class diagram is useful for the latter, but the more tabular form that Yonghui used may be a more compact way to describe this.
     *   I think we will need decent information models for the information types that are exchanged (item 3), but want to avoid drilling down to too much detail, so a simple notional model may suffice.  I’m attaching a couple I made for the Registry Management Policy document that I think are effective.  If someone has an alternative please provide it.
     *   Last item, which we discussed, is some sort of more dynamic behavior description.  This could be a UML activity style diagram or something similar rendered in another way.  Of particular interest are how dynamic behavior, such as device discovery, works.  One or more diagrams for different phases may be needed, but we can defer this for now.
  4.  Proposal: I have taken the materials that Yonghui and Ray provided and combined them into one package.  I have also psoposed some edits to these, to make them more consistent.  That is attached.
     *   Please review and comment before the next meeting
     *   Please provide all materials in RASDS style and PPT format.  Yonghui’s were a PDF which cannot be edited.  I think we all have Powerpoint and the free Open Office app can read and write these if cost is an issue.
     *   If we wish to use UML–style diagrams, which I am not opposed to, we will need to identify a low cost or free tool that we can all use, regardless of the OS platform we are running.  If anyone has a good suggestion please provide it.

Action Items

  1.  RT: produce a first cut at the MOIMS top level models in alignment with the proposed approach.  If you have issues with this suggest an alernative approach that we can all adopt.
  2.  YH: update the diagrams as discussed.  Provide PPT format ready to integrate with the rest of the package.  Provide at least a simple information model for key informaiton types.
  3.  RK: update the diagrams as discussed.  Align diagrams with this proposed approach or suggest an alernative that we can all adopt.  Provide at least a simple information model for key informaiton types.
  4.  PS: post a Doodle poll for the next meeting, nominally one of the last two weeks in Feb.  Post a Doodle poll for which days of the CCSDS spring Meeting week are prefered by the team.
  5.  All: if you are not already on the SEA-SA mailing list please go to http://mailman.ccsds.org/cgi-bin/mailman/listinfo and sign up for SEA-SA.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20160121/c331b65c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SOIS Services.v3.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 514186 bytes
Desc: SOIS Services.v3.pptx
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20160121/c331b65c/attachment.pptx>