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

2. 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

3. 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

4. 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

5. 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

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

7. 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

8. 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

9. 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

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

11. 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

12. 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

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

14. 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

15. 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

16. 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