Fall 2010 Meeting Stuart Fowell SOIS Application Support Services Red Books Status

2 SOIS Application Support Services Red Books Status - Fall 2010 Meeting Overview (1/2) Snapshot of books in CWE at “SOIS-APP/Meeting Materials/2010/Fall” TAS 1 st & 2 nd Agency Reviews completed Magenta Book reviewed by CESG prior to publishing Small number of comments to address prior to poll for publishing MTS 1 st Red Book completed Reviewed by CESG prior to 1 st Agency Review Small number of comments to address prior to 1 st Agency Review FPSS 1 st Agency Review complete Prototyping by ESA complete 2 nd Red Book complete – updates from 1 st Agency Review and Prototyping Ready for final approval from WG for 2 nd Agency Review

3 SOIS Application Support Services Red Books Status - Fall 2010 Meeting Overview (2/2) DAS and DDPS 1 st and 2 nd Agency Reviews completed Additional functionality for synchronising with subnetwork and with applications identified Red Books updated (issue 2.1) Agreed at Fall 2009 meeting Awaiting protototyping of additional functionality by SciSys (ESA’s SOIS Proof of Concept project) 3 rd Agency Review or direct to Magenta Book in Spring 2011? DES and DVS 1 st Draft of Red Books produced in 2009 Prototyped by SciSys (ESA’s SOIS Reference Implementation project) Awaiting completion of and alignment with Plug-and-Play architecture

4 SOIS Application Support Services Red Books Status - Fall 2010 Meeting TAS Magenta Book CESG Comments (1/4) CSS-1) Section 1.1 immediately discusses SOIS-compliant services as if the reader knows what SOIS is. I believe best practice is to spell out acronyms upon first use. Suggest spelling first use of acronym. But also see below re SOIS acronym in this document in general. Frustratingly this is exactly the same form of text as used in the published SOIS Subnetwork Services Magenta Books However, only an editorial change Propose we accept this & update document CSS-2) Section "vertical standaridsation" ? Seems the rationale of promoting inter-interoperability between spacecraft integrators and equipment vendors is a sufficient rationale? Don't standards in general try to be "horizontal" by operating across many missions? What is meant by "vertical" here? Suggest re-phrasing. Frustratingly this is exactly the same form of text as used in the published SOIS Subnetwork Services Magenta Books In this case, there is no horizontal standardisation as TAS does not have a peer-to-peer protocol, rather it provides a (potentially) local function, making use of a (potentially) synchronised time source Propose we reject this CSS-3) To the best of my knowledge, I believe CCSDS documents are not include CCSDS internal organizational artifacts as part of their formal publication. I do not recall other CCSDS documents prefixing a service identification with, as in this case, also the Area Identification. Why is this the SOIS Time Access Service and not simply the Time Access Service? The introduction (when fully spelled out) will make it clear that this is for spacecraft on board services. Suggest replacing all instances of "SOIS Time Access Service" with "Time Access Service". (Also, the document is not consistent about this -- in some places it calls out SOIS TAS, some places just TAS). Frustratingly this is exactly the same form of text as used in the published SOIS Subnetwork Services Magenta Books However, only an editorial change Propose we accept this & update document

5 SOIS Application Support Services Red Books Status - Fall 2010 Meeting TAS Magenta Book CESG Comments (2/4) CSS-4) definition of error bound: not clear what the addition of "notional" does to better convey the definition here? Also, the term appears only in the introduction -- ie the practice makes no further reference to this term; suggest removing it or (perhaps what was intended) add some linkage to where error data is returned. This definition has been in the TAS Red Book since at least issue 0.4. Accepted that it isn’t referred to further. “notional” – defn. “theoretical, speculative”. Is this replaced by the terms “precision” and “resolution” or does it also have relevance, e.g. the error bound could be larger than the precision or resolution, derived from the synchronisation mechanism? If yes, then keep the definition. Do we replace “notional” with “theoretical”, or add a note explaining the definition of “notional” for the hard-of-thinking? If keeping, then should “error bound” be indicated in the MIB or associated with each “time value”? Is it likely to change over time, if yes then associated with “time value”, if no then put in MIB. If associated with “time value”, the definition of the “time value” parameter should be updated to include an “error bound” component. Perhaps this should be optional? CSS-5) definition of time correlation: this is bit confusing -- the term is introduced but then practice goes on to say (on page 2-2) that time correlation is not in this practice; perhaps the definition is not required? Suggest removing the definition. Reject removal of definition It is important to distinguish between what time correlation is and what is performed by TAS, and therefore it is important to define what time correlation is

6 SOIS Application Support Services Red Books Status - Fall 2010 Meeting TAS Magenta Book CESG Comments (3/4) CSS-6) Section Purpose and operation were a little confusing -- what is the difference between "fine- grain" vs. "coarse-grain" -- its seems that TAS is for "coarse-grain" only applications; is there some specification that can be offered as part of the practice to differentiate fine vs. coarse-grain? E.g., are alarms delivered to within the nearest 1/100th second fine or coarse-grain? Or is there some other distinction? Accept. Update document to add an example of “coarse-grain” and “fine-grain” timers in terms of precision and resolution, distinguishing between e.g. OBT-synchronised coarse-grain and hardware-specific fine-grain timers CSS-7) Section Not clear if the discussion about MIB is in relation to the underlying layers or is the TAS MIB. It appears to be the TAS MIB? Suggest making this explicit. Accept. Update document CSS-8) Alarms and Metronomes -- Should the practice recommend at least minimum capacities -- e.g.., relative to the class of mission presumably there is at least a minimum number of alarms and metronomes that need to be supported ? Should this be required in the MIB ? (It seems to me that a robotic class mission with, e.g, 12 instruments, might demand more from TAS than a mission with only 1 or 2 instruments and a manned mission might be a very different situation). Reject recommending number of capacities for mission classes. Mission requirements on the number of capacities is very implementation-specific. Do other recommendations do this? To discuss. What value is there for putting the supported number in the MIB? What would online applications do with it? Perhaps appropriate for a Service Conformance Statement?

7 SOIS Application Support Services Red Books Status - Fall 2010 Meeting TAS Magenta Book CESG Comments (4/4) SIS-1) This is not a condition for approval, but rather a comment (perhaps a lament) on the Time Access Service: I struggle with why this isn't a Green Book. There is only one service that is mandatory (wallclock time), and the abstract service interface bears so little resemblance to the concrete (and widely implemented) POSIX interface provided as an example, that I just don't see what utility this document provides as a magenta book. The other two services are optional, and there's no meat in the MIB. The one table that seems to actually be quite useful is a mapping of the SOIS Time Access Service onto the POSIX API. Unfortunately, it is buried on page C-4 in an Informative Annex. It's the ONLY thing in this document that actually seems to *recommend* a concrete *practice.* (Indeed, it's the only place in the document where the word "recommend" is not boilerplate.) It is a typical service required by onboard applications, therefore has been defined in terms of provided services. In general computing, the POSIX interface doesn’t (to my knowledge) typically use a synchronised clock source, instead it uses an RTOS timer that is driven by a local oscillator. Is this an argument that TAS should have been combined with the time primitives of SYS? However, there is no requirement that the time source used by TAS should be synchronised so has the flexibility to be implemented as a POSIX service or a more bespoke implementation in e.g. hardware associated with the local clock source synchronised across an onboard network such as implemented in ESA’s CCSDS Time Manager IP core. Should the previous points be added to the document? SIS-2) Editorial: The following sentence seems to be grammatically incorrect (from p. B-2): "Depending on the sophistication of the local time source, it can detect missed correlation steps and can be configured such that the correlation operation never causes the indicated time to run backwards." The first part of this sentence doesn't assert "sophistication," so the second half shouldn't assert capability. If the first part of the sentence began "If the local time source is sufficiently sophisticated,..." or the second half were made subjunctive (can- >could in both places), I'd be more comfortable with the sentence. Accepted. Will take suggested change to first half of sentence.

8 SOIS Application Support Services Red Books Status - Fall 2010 Meeting MTS Red Book CESG Comments (1/2) SIS-1) In section 2.1, in the fifth paragraph on page 2-2, the term "MTS protocol" is inappropriate because (as is stated several times) the MTS Red Book specifies a service, not the protocol that is the means of providing that service. Change from: "It is recommended that the MTS protocol be the subset of the protocol provided by the AMS, defined in sections 4 and 5." to: "It is recommended that the MTS service be provided by an implementation of that subset of the AMS protocols which is defined in sections 4 and 5.“ Accepted. Document will be updated as suggested SIS-2) On Page 2-2, in the sentence " From subsection 2.3 of reference [1], the following AMS interactions are degraded to optional for MTS:" Change "degraded" to "deprecated“ Accepted. Document will be updated as suggested SIS-3) In sections and 3.2.4, it would be useful to define the formulation "in a synchronous manner". In particular, it's not obvious how the manner in which a service user sends an antecedent message (synchronous vs asynchronous) would have any effect on the issuance of a reply to that message. Ironically the term “synchronous manner” is copied from the AMS Red Book and the author of the AMS Red Book is the commenter here (Scott Burleigh)! AMS: “Synchronous query. Messages may be sent in a synchronous manner, i.e., suspending further activity until a reply is received.” BTW “antecedent” - defn. “one that proceeds another” Not sure what to suggest here…perhaps talk it over with Scott

9 SOIS Application Support Services Red Books Status - Fall 2010 Meeting MTS Red Book CESG Comments (2/2) SIS-4) If the SOIS QoS parameters are service class and channel number, as indicated in the discussion of "flow label" in 3.4.1, then it seems incorrect to use "QoS" as a synonym for service class; this seems to have been done later in that same paragraph and also in the NOTEs for Assert_invitation.request and Assert_subscription.request in Accepted. Text will be rationalised so that either QoS is used alone or explicitly replaced with “service class and channel” (and not “channel identifier” or “channel number”). In addition, reference will be made to the SOIS Subnetwork Packet Service for the definition of “service class and channel”

10 SOIS Application Support Services Red Books Status - Fall 2010 Meeting FPSS Red Book Updates Since 2 nd Agency Review Reviewed by ESA – ESOC Operators, from the perspective of providing file-based operations and how TM packets are retrieved from ESA spacecraft today (use of PUS in actual operator practise) Resulted in a number of refinements in FPSS (descriptive text, primitives, parameters) As well as agreeing that a number of their comments related to PUS, file-based operations extensions and implementation-specific issues Prototyping performed by ESA (Aitor) on RASTA System building on earlier Spanish MAMMA project Separates file store access protocol from low level block access protocol (used within file store implementation) Allows for user to be remote from file store, which itself may be spread across multiple mass memories accessed via a subnetwork Proposed that Issue 1.5 be put forward as Issue 2 for 2 nd Agency Review