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

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

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

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

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

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

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

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

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

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

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