Polled Device Data Acquisitions Using SOIS on MIL-STD-1553B

Communicating and scheduling data acquisitions using the MIL-STD-1553B protocol has evolved from the old approach with no hardware support to the current implementation with hardware support. The process involves time synchronization, communication cycles, frames, pre-allocated bandwidth, and polled data acquisitions. The introduction of ECSS 1553 services has further enhanced the data acquisition process, providing a structured framework for communication between devices.

• Data Acquisitions
• MIL-STD-1553B
• Communication Scheduling
• Hardware Support
• SOIS

yam_par Follow

Uploaded on Sep 27, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

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 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 CF Sync Msg Pre-allocated bandwidth, 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 2

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 3

4. Now with Hardware Support Applications Frame N Read Data Frame N+1 Read Data 1553 Schedule Data Pool Interrupt Interrupt Frame N Frame N+1 Data Write(s) Frame N Frame N+1 Data Read(s) Data Write(s) 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 4

5. Introduction of ECSS 1553 Services Applications Frame N Read Data Frame N+1 Read Data Data Acq Schedule Data Pool Sync Sync Frame N Frame N+1 Data Write(s) Frame N Frame N+1 Data Read(s) Data Write(s) Data Read(s) Data Acquisition and 1553 Schedules need to be coordinated 1553 Schedule ECSS 1553 Services Interrupt Frame N Frame N Interrupt Frame N+1 PDU Write(s) Frame N+1 PDU Read(s) Clock PDU Write(s) PDU Read(s) 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 5

6. Addition of SOIS Subnetwork Services Applications Frame N Read Data Frame N+1 Read Data Data Acq Schedule Data Pool Sync Frame N Frame N Sync Frame N+1 Data Write(s) Frame N+1 Data Read(s) Data Write(s) Data Read(s) Data Acquisition and 1553 Schedules need to be coordinated MAS SYS MAS SYS Sync Frame N Frame N Sync Frame N+1 PDU Write(s) Frame N+1 PDU Read(s) PDU Write(s) PDU Read(s) 1553 Schedule ECSS 1553 Services Interrupt Frame N Frame N Interrupt Frame N+1 PDU Write(s) Frame N+1 PDU Read(s) Clock PDU Write(s) PDU Read(s) 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 6

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 Frame N Read Ind Sync Frame N+1 Data Read(s) Frame N+1 Read Ind Data Read(s) Data DAS DAS Acquisition and 1553 Schedules need to be coordinated Frame N Frame N Frame N+1 PDU Write(s) Frame N+1 PDU Read(s) PDU Write(s) PDU Read(s) MAS SYS MAS SYS Sync Frame N Frame N Sync Frame N+1 PDU Write(s) Frame N+1 PDU Read(s) PDU Write(s) PDU Read(s) 1553 Schedule ECSS 1553 Services Interrupt Frame N Frame N Interrupt Frame N+1 PDU Write(s) Frame N+1 PDU Read(s) Clock PDU Write(s) PDU Read(s) 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 7

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

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 9

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 Frame N Read Ind Data Read(s) DAS DAS Data Acquisition and 1553 Schedules need to be coordinated Frame N Frame N Frame N Frame N+1 PDU Read(s) PDU Write(s) PDU Read(s) PDU Write(s) MAS MAS SYS Sync Frame N Frame N Frame N Frame N+1 PDU Read(s) PDU Write(s) PDU Read(s) PDU Write(s) 1553 Schedule ECSS 1553 Services Interrupt Frame N Frame N Frame N+1 PDU Write(s) Frame N+1 PDU Read(s) Clock PDU Write(s) PDU Read(s) MIL-STD-1553B BC Hardware RT Device Application sporadically requests data acquisition. Data returned in next frame How to determine between polled and ad-hoc acquisition 1553 API calls? RT Device CCSDS Spring 2013 Meeting Polled Data Acquisitions using SOIS and MIL-STD-1553B 10

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 11