1. Polled Device Data Aquisitions
Using SOIS on MIL-STD-1553B
Stuart Fowell, Richard Melvin, Olivier Notebaert, Felice Torelli
CCSDS Spring 2013 Meeting

2. MIL-STD-1553B Communication Scheduling
Time Synchronisation Cycle
(1Hz)
Communication
Cycle
(8Hz)
Communication
Frame #0
Communication
Frame #1
Communication
Frame #2
Communication
Frame #3
Communication
Frame #4
Communication
Frame #5
Communication
Frame #6
Communication
Frame #7
Sync
Sync
Sync
Sync
Sync
Sync
Sync
Sync CF
Sync
Msg
Pre-allocated bandwidth, populated
content
Pre-allocated bandwidth, populated
content
Pre-allocated bandwidth, populated
content
Pre-allocated bandwidth,
un-populated content
Pre-allocated bandwidth,
un-populated content
Pre-allocated bandwidth,
un-populated content
Spare
1553
Message #1
1553
Message #2 …
1553
Message #N
Spare
Polled data acquisitions pre-planned = populated content.
Typically request written to RT early in frame, response data read from RT later in frame & made immediately available to applications
Time-slots set aside for sporadic commands and data acquisitions
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

3. Old Approach with no Hardware Support
Applications
Frame N
Read Data
Frame N+1
Read Data
1553 Schedule
Data Pool
Interrupt
Data
Write
Data
Write
Data
Read
Data
Read
Interrupt
Data
Write
Data
Write
Data
Read
Data
Read
Clock
MIL-STD-1553B BC Hardware
RT Device
Applications directly implements time-slots and framing, writing & reading data for each time-slot and frame
RT Device
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

4. Now with Hardware Support
Applications
Frame N
Read Data
Frame N+1
Read Data
1553 Schedule
Data Pool
Interrupt
Frame N
Data Write(s)
Frame N
Data Read(s)
Interrupt
Frame N+1
Data Write(s)
Frame N+1
Data Read(s)
Clock
MIL-STD-1553B BC Hardware
RT Device
BC Hardware sends/receives next frame of data
Application prepares next communication frame & reads data retrieved from last communication frame
RT Device
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

5. Introduction of ECSS 1553 Services
Applications
Frame N
Read Data
Frame N+1
Read Data
Data Acq Schedule
Data Pool
Sync
Frame N
Data Write(s)
Frame N
Data Read(s)
Sync
Frame N+1 Data Write(s)
Frame N+1
Data Read(s)
Data Acquisition and 1553 Schedules need to be coordinated
1553 Schedule
ECSS 1553 Services
Interrupt
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Interrupt
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
Clock
MIL-STD-1553B BC Hardware
Standardise protocol across MIL-STD-1553B
Protocol implemented by ECSS 1553 Services instead of Application
Application still prepares next communication frame & reads data retrieved from last communication frame
RT Device
RT Device
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

6. Addition of SOIS Subnetwork Services
Applications
Frame N
Read Data
Frame N+1
Read Data
Data Acq Schedule
Data Pool
Sync
Frame N
Data Write(s)
Frame N
Data Read(s)
Sync
Frame N+1 Data Write(s)
Frame N+1
Data Read(s)
Data Acquisition and 1553 Schedules need to be coordinated
SYS
MAS
SYS
MAS
Sync
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Sync
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
1553 Schedule
ECSS 1553 Services
Interrupt
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Interrupt
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
Clock
MIL-STD-1553B BC Hardware
Applications isolated from subnetwork-specific protocols; however still need to understand polled rather than async. nature of underlying subnetwork
Application still prepares next communication frame & reads data retrieved from last communication frame
RT Device
RT Device
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

7. Addition of SOIS Device Access Service
Applications
Frame N
Read Data
Frame N+1
Read Data
Data Acq Schedule
Data Pool
Sync
Frame N
Data Read(s)
Frame N
Read Ind
Sync
Frame N+1
Data Read(s)
Frame N+1
Read Ind
Data Acquisition and 1553 Schedules need to be coordinated
DAS
DAS
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
SYS
MAS
SYS
MAS
Sync
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Sync
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
1553 Schedule
ECSS 1553 Services
Interrupt
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Interrupt
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
Clock
MIL-STD-1553B BC Hardware
If required by device interface, Applications no longer need to perform writes to trigger data being acquired from RT device, as this is handled by DAS
RT Device
RT Device
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

8. Addition of SOIS Device Data Pooling Service
Applications
Frame N
Acq Ind
Frame N
Read Sample(s)
Frame N+1
Acq Ind
Frame N+1
Read Sample(s)
Data Acq Schedule
DDPS
Sync
Frame N
Data Read(s)
Frame N
Read Ind
Sync
Frame N+1
Data Read(s)
Frame N+1
Read Ind
DAS
DAS
Data Acquisition and 1553 Schedules need to be coordinated
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
SYS
MAS
SYS
MAS
Sync
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Sync
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
1553 Schedule
ECSS 1553 Services
Interrupt
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Interrupt
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
Clock
MIL-STD-1553B BC Hardware
Applications no longer need to synchronise to subnetwork, as this is handed by DDPS
DDPS periodically acquires data and pools
RT Device
RT Device
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

9. Use Case: Polled and Sporadic Data Acquisitions (1/2)
Majority of applications, e.g. AOCS, use pooled data from DDPS acquired using polling
Sporadically individual application, e.g. OBCP, requires ad-hoc data directly acquired using DAS
If data happens to be already polled, results in a duplicate acquisition
Probably OK as such cases are relatively rare and budgeted for by an overhead within the communications schedule
Better to keep DDPS data polled at consistent frequency than occasionally slightly have more up to date in pool
However, how to distinguish requests at ECSS 1553 Services API?
Type 1 = pre-allocated populated vs. Type 2 = pre-allocated unpopulated
Could use different channels on PS/MAS API to imply different ECSS 1553 APIs/Types
However DDPS and Applications need to also distinguish to ensure correct channels used…
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

10. Use Case: Polled and Sporadic Data Acquisitions (2/2)
Applications
Frame N
Acq Ind
Frame N
Read
Sample(s)
Ad-hoc Frame N
Data Read(s)
Ad-hoc Frame N+1
Read Ind
Data Acq Schedule
DDPS
Sync
Frame N
Data Read(s)
Frame N
Read Ind
DAS
DAS
Data Acquisition and 1553 Schedules need to be coordinated
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Frame N
PDU Write(s)
Frame N+1
PDU Read(s)
SYS
MAS
MAS
Sync
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Frame N
PDU Write(s)
Frame N+1
PDU Read(s)
1553 Schedule
ECSS 1553 Services
Interrupt
Frame N
PDU Write(s)
Frame N
PDU Read(s)
Frame N+1
PDU Write(s)
Frame N+1
PDU Read(s)
Clock
MIL-STD-1553B BC Hardware
Application sporadically requests data acquisition. Data returned in next frame
How to determine between polled and ad-hoc acquisition 1553 API calls?
RT Device
RT Device
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B

11. Use Case: Polled DDPS using DVS implies use of DAS
One DVS request may expand to multiple DAS requests.
Hard to predict overall bandwidth usage
Hard to predict impact of config. change that causes an extra DVS value to be sporadically read/polled
As DVS is required for calibration and translation of AOCS inputs, usage may be high.
Possible solutions:
Have DAS do merging of redundant requests (working assumption in EDS TRP project)
Straightforward given a trivial or standardised Device-specific Access Protocol (DAP)
Problematic if the DAP is complex and defined in external datasheet.
Move DVS above DDPS
Requires ability to store calibration results in DDPS via an interface, as pooling calibrated values is of benefit
=> also allowing (e.g.) storing software status information from applications
Fits within de-facto ESA and SAVOIR OBSW architectures with DDPS replacing datapool – how well does it fit other architectures?
Expose a polling service from subnetwork layer
Can be implemented in hardware, lower level software, or internally depending on the nature of the lower layer.
Lot of rework to all layers above subnetwork
Get rid of DVS as a device responsibility:
Never actually completely solved device management problems (e.g. power switching, HPCs, software mode changes)
Requires coordination of multiple devices and/or non-device state information
Has complex, persistent internal state which cannot be made visible to ground or onboard automation
Complex mission-specific logic un-necessarily in hard(ish) real-time part of OBSW; extra costs for system testing
Implementation of (e.g.) common interfaces to different models of AOCS sensors may require AOCS-domain logic (coordinate transformations, time references, etc.)
Duplication with CCSDS MO (e.g. calibration)
CCSDS Spring 2013 Meeting
Polled Data Acquisitions using SOIS and MIL-STD-1553B