300 likes | 410 Views
Standard Onboard interface Services – Overview and status. Chris Taylor Stuart Fowell October 09. SOIS - main drivers.
E N D
Standard Onboard interface Services – Overview and status Chris Taylor Stuart Fowell October 09
SOIS - main drivers • The SOIS set of recommendations are intended to standardise the communication services and protocols used within the flight data handling system. The main motivation for the work is cost reduction: • Provision of requirements for subnetwork services/protocols • Standard protocols - less development and test, standardised test equipment • Common services regardless of media - less changes in middleware • Standardisation of interfaces to subsystems, payloads and sensor/actuators • Reduced vendor costs, opportunity for reusable multi-vendor building blocks • Simpler payload integration and multi-Agency interoperability • Standardisation of services to mission application software • Insulation from specific hardware and hardware changes • Reduced porting costs across missions • Opportunity to align with mission operations standards
SOIS – layered model Communication Management Application Layer Applications Application Support Layer CMD & Data Acquisition Services Time Access Service File Services Message Transfer Service Device Enumeration Service Transfer Layer Transport Protocol Network Protocol Subnetwork Layer Packet Service Memory Access Service Synchronisation Service Device Discovery Service Test Service Datalink Extension Protocols Datalink Specific Protocols
SOIS C&DA service detail Command & data Acquisition Services Device Data Pooling Service Device Virtualisation Service Device Access Service
SOIS - Protocols • While SOIS CCSDS specifications initially concentrate on services there is also a need to specify protocols that implement the services • The SOIS protocol specs are being developed in different ways • Subnetwork protocols are under preparation within the ECSS and SpaceWire working groups • Application support protocols: • CMD & Data Acquisition and Enumeration Services will be supported by SOIS and proprietary developed protocols • Time Access service willdirectly interface with a local application • File Services will require a device specific access protocol • Message Transfer service will adopt the CCSDS Asynchronous Message Service Protocol (last stages of publication)
SOIS – Subnetwork Protocol Standard Subnetwork Layer Packet Service Memory Access Service Synchronisation Service Device Discovery Service Test Service Milbus ECSS available CANbus ECSS in progress SpaceWire ECSS planned
Application Layer CFDP Users Applications PUS etc Communication Management CFDP Application Support Layer CMD & Data Acquisition Services Time Access Service Device Enumeration Service Message Transfer Service File and Packet Store Services Transfer Layer Transport Protocol Network Protocol Subnetwork Layer Packet Service Memory Access Service Synchronisation Service Device Discovery Service Test Service Datalink Extension Protocols Datalink Specific Protocols
SM&C, PUS AMS, SOIS relationships - Discussion • In order for us to proceed in a coordinated way it is necessary to determine how these three standards relate (PUS is not yet adopted by CCSDS so serves here only as an example) • SM&C defines a set of mission operations services, it does not define how these should be implemented • PUS defines services for command and control, some of which are directly compatible with those defined by SM&C. It also defines a messaging protocol (SM&C message abstraction layer?) and a transport protocol (intimately coupled with the SPP) • AMS provides a messaging service and protocol but does not define the contents on the messages (part of the SM&C message abstraction layer?) • SOIS defines communication related services across the onboard subnets and application support services that insulate applications from the specifics of the underlying hardware
SM&C, PUS and SOIS relationships – Onboard Architecture • It us unclear (to me) where the Standard SM&C API resides: • Is it provided BY, or provided TO, the applications implementing the SM&C services? • The present architecture (fig 2.3. of the Green book) seems to indicate an API being provided TO the applications • This is a crucial point for SOIS as we are not providing mission operations services, rather we provide communication related services in support of mission Applications • Assuming that SM&C defines a standard API to be provided by onboard applications, then the mapping of between applications and SOIS is a local matter (although this should also be standardised) • The collaboration needed with SOIS is therefore to ensure that the services provided by SOIS are sufficient to support the Applications providing the SM&C services
SOIS, PUS, AMS and SM&C – (not 100%) SM&C SM&C Compliant API ? PUS SMC Service 2 SM&C service 1 SM&C Service N AMS Flight Applications Command and Data Acquisition Services Message Transfer Services File Transfer Time Access Services File & Packet Store Services AMS Messages CFDP SOIS Application Support Layer Services PUS Packets SOIS Packet service Test Service Device Discovery Service Memory access service Synchronisation service Subnetwork Services Payloads Onboard sub-systems TM/TC Spacelink Sensors & Actuators File and packet store Time Source Ground Applications AMS PUS Services Cross Support I/F
SOIS - main drivers • The SOIS set of recommendations are intended to standardise the communication services and protocols used within the flight data handling system. The main motivation for the work is cost reduction: • Provision of requirements for subnetwork services/protocols • Standard protocols - less development and test, standardised test equipment • Common services regardless of media - less changes in middleware • Standardisation of interfaces to subsystems, payloads and sensor/actuators • Reduced vendor costs, opportunity for reusable multi-vendor building blocks • Simpler payload integration and multi-Agency interoperability • Standardisation of services to mission application software • Insulation from specific hardware and hardware changes • Reduced porting costs across missions • Opportunity to align with mission operations standards
Application Layer CFDP Users Applications PUS etc Communication Management CFDP Application Support Layer CMD & Data Acquisition Services Time Access Service Device Enumeration Service Message Transfer Service File and Packet Store Services Transfer Layer Transport Protocol Network Protocol Subnetwork Layer Packet Service Memory Access Service Synchronisation Service Device Discovery Service Test Service Datalink Extension Protocols Datalink Specific Protocols
SOIS Specification Status (October 09) • Subnetwork services • Completed, imminent publication by CCSDS • Application support services • Ready for issue as Magenta Books • Device Access Service Issue 2 • Time Access Service Issue 2 • Ready for 2nd Agency Review • File and Packet Store Services Issue 1.4 • Message Transfer Service Issue 0.3 • Under Development • Device Virtualisation Service Issue 0.1 • Device Enumeration Service Issue 0.1 • Device Data Pooling Service Issue 2
SOIS, PUS, AMS and SM&C – (not 100%) SM&C SM&C Compliant API ? PUS SMC Service 2 SM&C service 1 SM&C Service N AMS Flight Applications Command and Data Acquisition Services Message Transfer Services File Transfer Time Access Services File & Packet Store Services AMS Messages CFDP SOIS Application Support Layer Services PUS Packets SOIS Packet service Test Service Device Discovery Service Memory access service Synchronisation service Subnetwork Services Payloads Onboard sub-systems TM/TC Spacelink Sensors & Actuators File and packet store Time Source Ground Applications AMS PUS Services Cross Support I/F
PUS including File based services SOIS Application support services Protocols Mass memory SOIS subnetwork services Packet Protocol ECSS protocols Space data link protocols Onboard datalink
PUS including File based services SOIS Application support services Protocols Mass memory SOIS subnetwork services Packet Protocol ECSS protocols Space data link protocols Onboard datalink
Ground Utilisation of Packets and File based On-board Services PUS PFUS Spacecraft M&C Services SM&C/PUS Packets On-board Data Management Services SOIS File Store File Delivery File Management CFDP SOIS Packet and Data Link Protocols Space Link Standards
System Services Application BB OBCP interpreter PUS library/ TMTC Plan/ Autonomy Framework AOCS MTL services Thermal OBT Mgmt Mission TL/ Mode mgmt Equipment Mgmt Context Mgmt Power Central FDIR P/L Manager Libraries:Math, Security, Payload,… SSMM Mgmt Software bus DevicesSensors(Star Trackers, Sun sensors, Gyros, Earth sensors, magnetometers)Actuators(Reaction wheels, magneto torquers, thrusters, etc) Payloads &Instruments Execution framework SOISApplication Suppport Layer Subnetwork Layer Middleware services Standardized devices Legacy devices RTOS TM/TC SSMM HDSW BSP Standardized devices Solid StateMassMemoryFile Mgt CompressEncrypt Payload Data Processing DSP SecurityUnit OBC Hardware Sensorandactuators CPU/ NGmP OBTimer DSP Payload Control Computer RTU/Intelligent IO SGM CAN RS422 RAM ADCs / DACs HWwatchdog MIL-1553 SpW EEPROM BootPROM Digital Sensorbus SOIS Layers SOIS Layers SOIS Layers Onboard Communications H/W(e.g. MIL-STD-1553B, SpaceWire, CAN RS422) Reference Architecture and Building Blocks Space Avionics Open Interface Architecture (SAVOIR) SAVOIR Advisory Group : SAG : TEC-EC-ED-SW Nat. Agencies and Industry High Speed Telemetry Encryption Storage Compression Networks SOIS Layers
PUS- SOIS discussion • In principle PUS and SOIS are complementary: • SOIS provides standard onboard communication related services to assist in harmonising flight implementations and insulating mission applications from specific hardware details • PUS standardises operational services and protocols and may take benefit from the SOIS flight services • In practise, there are some overlaps and omissions which will need to be resolved: • The boundary of PUS within the flight system • The capability of the present SOIS to support all PUS services • The way in which file transfer is performed • We will also have to take account of the emerging SM&C standards and how they influence both standards
Application Layer CFDP Users Applications PUS etc Communication Management CFDP Application Support Layer CMD & Data Acquisition Services Time Access Service Device Enumeration Service Message Transfer Service File Services Transfer Layer Transport Protocol Network Protocol Subnetwork Layer Packet Service Memory Access Service Synchronisation Service Device Discovery Service Test Service Datalink Extension Protocols Datalink Specific Protocols
SOIS, PUS ------- ------- PUS Service 1 PUS Service 2 PUS Service X PUS Service PUS Service N Flight Applications PUS File transfer protocol CFDP Command and Data Acquisition Services Message Transfer Services Time Access Services File & Packet Store Services etc. Application Support Layer Services SOIS PUS Packets SOIS Packet service Test Service Device Discovery Service Memory access service Synchronisation service Subnetwork Services Payloads Onboard sub-systems TM/TC Spacelink Sensors & Actuators File and packet store Time Source PUS Services Ground Applications
SOIS, PUS, AMS and SM&C – (not 100%) SM&C SM&C Compliant API ? PUS SMC Service 2 SM&C service 1 SM&C Service N AMS Flight Applications Command and Data Acquisition Services Message Transfer Services File Transfer Time Access Services File & Packet Store Services AMS Messages CFDP SOIS Application Support Layer Services PUS Packets SOIS Packet service Test Service Device Discovery Service Memory access service Synchronisation service Subnetwork Services Payloads Onboard sub-systems TM/TC Spacelink Sensors & Actuators File and packet store Time Source Ground Applications AMS PUS Services Cross Support I/F
SOIS Meeting Objectives • Application Services WG (Mon-Friday CF204) • Time Access service Submission for publication • File and Packet Store services RID Processing before submission for final Agency review • Message Transfer Service RID processing before submission for Agency review • Device Enumeration service Rid disposition and Update • Device Virtualisation Service Rid disposition and Update • Device data Pooling Rid disposition and Update • Device Access service Rid disposition and Update • Subnetwork Services WG (No meeting) • All books finished Pending CESG check before publication and WG closure • Wireless WG (Mon-Wed Room:Dj124/TB206) • Asset Tracking and Management Develop Magenta first draft • Intra-vehicle communications Initiate Magenta book • Green Book Pending CESG check before publication • Area/Joint WG • Plug & Play (Wed/Thu) WG Discussion and proposal for how to proceed • AMS (Tue PM) WG Discussion on possible testing • PUS (Thu PM) SOIS contribution to BOF • SOA (Tue AM) SOIS contribution to BOF • CFDP & DTN (Wed/Thu) WG Discussion
Application support WG • Main goals for this week • Finalise text for those books ready for publication (MTS, Time, File services) • These will all need modifying to refer to ISO 7498 and not define ISO definitions inline in the text. Remove MIB where applicable • Decide if file transfer is a service provided by SOIS, decide how it fits with CFDP • Decide how the other service definitions should proceed with or without plug and play • For the plug and play session, we must determine: • The scope of the activity deciding what we will and will not cover in SOIS • What is needed within this scope and if there are candidates for adoption • If there is enough common ground with at least two Agencies in order to proceed • If we should raise a separate WG or continue the topic within the APS WG • The more examples we have of how SOIS operates in practice the better. • We must update the Green book to better reflect the latest SOIS approach, identify actions and victims