SOIS Application Support Services WG – Fall 2009 Meeting Stuart Fowell 26th-27th October 2009

Agenda 1/2 Monday 26th October AM: Latest Prototyping Activities ESA (Chris Taylor) RUAG (Johan Otterström) SciSys/Astrium (Stuart Fowell) Monday 26th October PM: SOIS In Practise TM/TC Modules (Stuart Fowell) PUS, DTN and CFDP (Chris Taylor, Stuart Fowell) File Services, Stores and Mass Memory (Aitor Viana Sanchez) APIs (Felice Torelli) DVS is not just for Plug-and-Play (Stuart Fowell) Matters Arising from WG Reviews MTS & FPSS SOIS Application Support Services WG – Fall 2009 Meeting

Agenda 2/2 Tuesday 27th October AM: Matters Arising from Agency Reviews TAS Outstanding RIDs DAS Outstanding RIDs DAS, DVS and Device Packet Protocols (Stuart Fowell) DDPS Outstanding RIDs DDPS and Application/Communication Synchronisation (Stuart Fowell) Tuesday 27th October PM: Joint meeting with AMS MTS Interoperability Testing (Stuart Fowell) Wed 28th – Thurs 29th October: Plug-and-Play Friday 30th October AM: Closing Plenary Remaining Work Plan (Stuart Fowell) Green Book Updates? SOIS Application Support Services WG – Fall 2009 Meeting

Latest Prototyping Activities SciSys/Astrium (Stuart Fowell) RUAG (Johan Otterström) ESA ECSS 1553 (Aitor Viana Sanchez) SOIS Application Support Services WG – Fall 2009 Meeting

SOIS In Practise TM/TC Modules (Stuart Fowell) PUS, DTN and CFDP (Chris Taylor, Stuart Fowell) Time Distribution (???) File Services, Stores and Mass Memory (Aitor Viana Sanchez) SOIS Application Support Services WG – Fall 2009 Meeting

APIs Defining concrete APIs from the abstract service interface (Felice Torelli) SOIS Application Support Services WG – Fall 2009 Meeting

DVS is not just for Plug-and-Play Device Virtualisation Service provides an abstraction from the variations of how common functions are implemented on different devices through the definition of common device classes and associated functions with specific device types defining how these common functions are in practise interfaced to Such an approach is already being nurtured in ESA’s AOCS for their sensors and actuators Typically in ESA/European Industry onboard software, there already is an Equipment Management layer Provides this abstraction, including Configuration of devices Engineering unit conversion, e.g. calibration curves Plug-and-Play/Electronic Data Sheets can provide dynamic or build-time automatic creation/management of this abstraction But the abstraction is valid even in traditional “static” systems So please do consider DVS as a stand-alone standard and not only as part of Plug-and-Play SOIS Application Support Services WG – Fall 2009 Meeting

Matters Arising from Agency Reviews Review of DAS, DDPS and TAS Red Books Issue 2 from 5th June – 7th August 2009 Comments received from INPE, ECSS and EADS-Astrium Positive “no-comment” from CNES and JAXA No comments received from NASA BNSC and ESA also didn’t comments but then they are authors! In total 87 comments received DAS: 27 comments DDPS: 32 comments TAS: 28 comments All RIDs and Dispositions have been posted on CWE Vast majority (61) were editorial from ECSS ECSS has provided an updated Red Books Authors will in the next few weeks complete the updates & post Issue 2.1 on CWE Couple of issues identified to be discussed at this meeting: DAS, DVS and Device Access Protocols DDPS and Application/Communication Synchronisation SOIS Application Support Services WG – Fall 2009 Meeting

DAS, DVS and Device Packet Protocols Where a protocol is required for accessing a device, where is this implemented? Is it in the Device Access Service (DAS) or the Device Virtualisation Service (DVS)? The purpose of the DAS is to isolate the user from the access method for the device The purpose of the DVS is to isolate the user from the particulars of how a device provides an interface to a standard function On this basis, the protocol to send command data and acquire data belongs in DAS and the preparation/interpretation of the data belongs in DVS This seems to split the responsibility as I’m sure the device’s protocol are typically defined covering both points Is there a “generic” device access protocol that can be defined? Can this be extracted from existing protocols and devices? Is this subnetwork specific? Can it be isolated from the Subnetwork Packet Service? Obviously there will be a number of existing devices that will not conform to this generic protocol – how are they handled? SOIS Application Support Services WG – Fall 2009 Meeting

DAS, DVS and Device Packet Protocols SOIS Application Support Services WG – Fall 2009 Meeting

DDPS and Application/Communication Synchronisation DDPS allows application to create a periodic data acquisition Two Issues: Synchronising acquisitions to the subnetwork schedule to avoid buffering and possible schedule drift Synchronising applications to the acquisitions to avoid possible schedule drift or polling Where a subnetwork is scheduled, optimal to synchronise DDPS acquisitions with the subnetwork schedule This should be done by DDPS using the Subnetwork Synchronisation Service to drive periodic data acquisitions… But does this mean that DDPS needs to be aware of the subnetwork schedule so as to determine when to acquire Or there is a need to add primitives to support synchronising TIME.indication doesn’t seem enough – what does it actually mean? Seems more related to getting the current time On the other hand Time Access Service does provide a synchronisation mechanism (metronome) but again how is this synchronised to the subnetwork schedule? Modify Subnetwork Synchronisation Service? SOIS Application Support Services WG – Fall 2009 Meeting

DDPS and Application/Communication Synchronisation DDPS as currently envisaged doesn’t allow for an application to synchronise to when acquisitions occur Therefore applications such as Attitude and Orbit Control need to periodically poll Period can be the same as the acquisition period, but no guarantees that the two periods don’t drift Easier & more efficient if there was a synchronisation mechanism so that when an acquisition occurs, the application is directly notified Examine details of service interface to see if this can be achieved Recommendation is to modify the DDPS_READ_SAMPLES.indication so that it can optionally be asychronously issued by DDPS when an acquisition occurs rather than purely in response to a DDPS_READ_SAMPLES.request This can be controlled by a flag on the DDPS_ADD_ACQUISITION_ORDER.request or the DDPS_START_ACQUISITIONS.request or could be part of the implementation or MIB of the service SOIS Application Support Services WG – Fall 2009 Meeting

DDPS and Application/Communication Synchronisation SOIS Application Support Services WG – Fall 2009 Meeting

Matters Arising from WG Reviews Number of comments on File and Packet Store Services Red Book Issue 1.4 contains RID Dispositions Remaining issue: FPSS and File/Packet Store Access Protocols Once resolved, ready for 2nd and final Agency/CESG Review leading to publication as Magenta Book Small number of comments received from EADS Astrium on Message Transfer Service AMS WG Chair (Scott Burleigh) confirms that it conforms to a profile of AMS Ready for 1st Agency/CESG Review Looking to perform interoperability testing with APL’s AMS implementation Corresponds to the MTS profile Needs mapping onto SOIS Subnetwork Packet Protocol SOIS Application Support Services WG – Fall 2009 Meeting

Joint SOIS ASS/SIS AMS Meeting MTS Interoperability Testing Test two implementations of the MTS profile of AMS Testing is a profile of AMS Interoperability Testing Plan Interoperability point is two implementations running on separate onboard processors interoperating over a subnetwork using a common SOIS Subnetwork Packet Service Single implementation of registrar and configuration server running on one processor Agreed to use a SpaceWire Packet Service as Transport Service Need to agree on a SpaceWire Packet Protocol – no standard available at this point in time Use SpaceWire IP Tunnel Implementations: JPL’s ION ESA/SciSys MTS Update required to both related to locating other implementation’s registrar SOIS Application Support Services WG – Fall 2009 Meeting

Remaining Work Plan Updated TAS Red Book with RID Dispositions & generic updates Submit for publication as Magenta Book Update DDPS Red Book with RID Dispositions, generic updates & resolution of Synchronisation issue Re-review WG/Agency or directly submit for publication as Magenta Book? Update DAS Red Book with RID Dispositions, generic updates & resolution of Device Access Protocols issue Update FPSS Red Book with resolution of File and Packet Store Access Protocols & generic updates Re-review within WG or directly submit for 2nd Agency Review? Update MTS Red Book with RID Dispositions & generic updates Submit for 1st Agency Review DVS Red Book? No progress on reviewing: Framework for device classes and types – e.g. add introspection? Definitive list of device classes – any missing? Standardisation on functions of individual device classes Fate of DES Red Book depends upon outcome of Plug-and-Play SOIS Application Support Services WG – Fall 2009 Meeting