07 September 2015 Peter Mendham SOIS Plug-and-Play: Use Cases and Requirements.

April 19, 2023

Peter Mendham

SOIS Plug-and-Play: Use Cases and Requirements

CCSDS Fall Meeting: SOIS PnP Use Cases and Requirements2

Agenda

Introduction and backgroundOperational scenariosScenario use casesSynthesising a use caseService level approaches and requirementsSubnetwork level requirementsSubnetwork support requirementsRecommendationsComments to encourage discussion


Introduction

Asked to review plug-and-play…Use casesDefinitionScopeRequirements

Starting point was the concept paperPlus any other published material available


Approach

Back to basicsLargely ignore the SOIS architectureIntend to review the architecture as an outcomeScenarios to use cases to requirements to a better defined purpose and scope

Device Virtualisation Service

Device Access Service

Device Enumeration Service

Applications

Packet ServiceMemory Access

ServiceDevice Discovery

Service

Network Management Service

Physical Layer


Definitions of Plug-and-Play

Generic definition (various sources)

SOIS definition (concept paper)

Plug-and-play encompasses the characteristics of an interface or device specification to facilitate the discovery of a hardware component in the system and the automatic configuration of that component such that it may be used without user intervention.

Plug-and-play encompasses the mechanisms necessary to establish communication services between two data systems in a spacecraft’s onboard (sub-)network, without requiring reconfiguration or manual installation of device drivers by any user (higher-level service or OBSW application).


Scenarios

Rapid spacecraft developmentAutomated integration and testFDIR assistanceGround segment access


Rapid Spacecraft Development (1)

Many drivers to reduce spacecraft development time

Commercial drivers: < 2 yearsMilitary drivers (e.g. ORS): < 1 week

Reduce development time throughStandardised componentsStandardised interfacesIncremental qualification/V&V (cf. IMA)Use of in-house/commercial off the shelfRapid integration


Rapid Spacecraft Development (2)

Plug-and-play enablers:Removal of dependence on subnetwork configurationReuse of applications independently from devicesReuse of devices independently from applicationsIncrease portability of applications

Beneficiaries:System integrators (e.g. primes)Customers (e.g. agencies)Device manufacturersPermits/promotes inter-agency cooperation


Automated Integration and Test (1)

During integration a number of configurations are necessary for:

SpacecraftEGSE

Each configuration must be validatedUse plug-and-play to permit

Discovery of devicesAutomated configuration of services/applicationsAutomated configuration of EGSE and other test equipment


Automated Integration and Test (2)

Plug-and-play enablers:Removal of dependence on subnetwork configurationConfiguration of communications independent to applicationsValidate applications independent to communicationsValidate devices independently from applications etc.

Beneficiaries:System integrators (e.g. primes)Customers (e.g. agencies)Device and EGSE manufacturersPermits/promotes inter-agency cooperation


FDIR Assistance (1)

Fault detectionDetect the disappearance of subnetwork devicesMight indicate a fault

IsolationUse subnetwork features to isolate deviceReconfigure routing/fail over bus

RecoveryIdentify replacement device(s)Reconfigure subnetwork as necessary


FDIR Assistance (2)

Plug-and-play enablers:Device discovery (addition/removal notification)Device isolation (depending on subnetwork)Transparent subnetwork reconfiguration for identical redundant devices

Beneficiaries:Software developersSystem integrators (e.g. primes)Customers (e.g. agencies)Spacecraft operators (may see more reliable spacecraft)


Ground Segment Access (1)

Automated adaptation of ground segment interface to accommodate

Different spacecraft configurationsDifferent devices

Adapt telemetry expectedFormat and content

Adapt telecommands issuedTypes available and format


Ground Segment Access (2)

Plug-and-play enablers:Device discoveryProvide services independently from subnetwork configurationService discovery by ground segment applications

Beneficiaries:Operational stakeholdersOriginal space and ground segment customer(s) (e.g. agencies)System integrators (e.g. primes)Space and ground segment developers


Use Cases

Use case for each scenarioPresented as a process

Or multiple processes

Will eventually be drawn together into a synthesised use case


Rapid Spacecraft Development Use Case (1)

Use case for iterative/incremental development and qualification/V&VUse case for integration of devices into spacecraft

Device driven process for subnetwork issuesApplication driven process for service issues



1. Device is physically and logically integrated onto spacecraft network

2. Subnetwork plug-and-play features discover the device

3. Subnetwork plug-and-play network management carries out network configuration and configuration of subnetwork-related device features

4. Subnetwork plug-and-play network management carries out configuration of subnetwork services

5. Subnetwork plug-and-play assists in the discovery of services/capabilities of device

6. Capabilities are exposed through to (potentially standardised) applications via a suitably standardised interface



1. The application is loaded2. The application queries the service interface for

the availability of a specific device or device type

3. If the device is available the application obtains the service interface and binds to it, application features relating to the service are then enabled

4. If the device is not available the application either waits and then returns to step 2 (re-query), or disables the features relating to the service


Automated Integration and Test Use Case (1)

Many similarities to previous scenarioTwo parts:

Plug-and-play on spacecraft to adapt to integrated devicesPlug-and-play of EGSE attached to spacecraft for integration and test



1. Device is physically and logically integrated onto spacecraft network

2. Subnetwork plug-and-play features discover the device3. Subnetwork plug-and-play network management carries out

network configuration and configuration of subnetwork-related device features



6. Capabilities are exposed through to (potentially standardised) applications via a suitably standardised interface

7. Applications registered to use the available service interfaces are either loaded or have the appropriate service-related functions enabled (if they are already loaded)



1. EGSE is physically and logically integrated onto spacecraft network

2. EGSE subnetwork plug-and-play features discover the device3. Subnetwork plug-and-play network management detects

current network configuration and configuration of subnetwork-related device features and configures EGSE subnetwork services accordingly


5. Capabilities are exposed through to (potentially standardised) EGSE applications via a suitably standardised interface

6. Test and/or V&V applications registered to use the available device service interfaces are either loaded or have the appropriate service-related functions enabled (if they are already loaded)


FDIR Assistance Use Case (1)

FDIR process utilises plug-and-play at four stages:

Initial integrationFault detectionFault IsolationRecovery

Additionally, plug-and-play may be used to accommodate non-duplicate redundancy

Such as 3 of 4 arrangements e.g. tetrahedral gyro arrangements



Initial Integration• Subnetwork plug-and-play features discover both

prime and redundant devices• Subnetwork plug-and-play network management

carries out network configuration and configuration of subnetwork-related device features

• Subnetwork plug-and-play network management carries out configuration of subnetwork services;

• Subnetwork plug-and-play assists in the discovery of services/capabilities of device

• Capabilities of both devices are exposed through to (potentially standardised) applications via a suitably standardised interface



Fault Detection1. The prime device ceases to be either

physically or logically present on the subnetwork

2. Network discovery determines the absence of the device either through active polling or passive notification

3. Optionally, applications are notified of the absence of the device (and potential failure) and/or the lack of availability of particular services



Fault Isolation1. Subnetwork plug-and-play network

management reconfigures the subnetwork to isolate the failed prime device (if possible)



Recovery1. Subnetwork plug-and-play network

management carries out network configuration and configuration of subnetwork-related device features for the redundant device

2. Subnetwork plug-and-play network management carries out configuration of subnetwork services to accommodate the redundant device



Service Level Adaptation1. Subnetwork plug-and-play assists in the discovery of

services/capabilities of the remaining device(s)2. A uniform service interface is presented to a (potentially

standardised) application though synthesis of the services provided by the available devices

3. Applications query the service interface to determine the availability of replacement services for the ones lost

4. If suitable services are available the application obtains the service interface and binds to it, application features relating to the service are then enabled (this may require adapting the service interface e.g. type conversions, frame rotations)

5. If suitable services are not available the application either waits and then returns to step 2 (re-query), or disables the features relating to the services


Ground Segment Access Use Case (1)

Splits into two partsOnboard integration and discovery of devicesAccess by ground segment applications

First part is the same as beforeProcess of second part depends access

Device oriented Service oriented



Device Oriented1. The ground segment application queries the

spacecraft service interface for the availability of a specific device or device type





Service OrientedGround segment applications query the service interface to the spacecraft to determine the availability of suitable servicesIf suitable services are available the application obtains the service interface and binds to it, application features relating to the service are then enabled (this may require adapting the service interface e.g. type conversions)If suitable services are not available the application either waits and then returns to step 2 (re-query), or disables the features relating to the services


Synthesising a Use Case

Separate levelsSubnetwork levelService level (device capabilities)

Subnetwork level is relatively easyService level splits into three approaches

Device-driven, device-boundApplication-driven, device-boundApplication-driven, service-bound


Subnetwork Level Synthesised Use Case

1. A change is made to the devices physically and/or logically integrated onto spacecraft subnetwork

2. Subnetwork plug-and-play features discover the addition or removal of a devices

3. Subnetwork plug-and-play network management carries out network configuration and configuration of subnetwork-related device features




Device-Driven, Device-Bound Use Case

1. The subnetwork indicates the availability of a device or device class, potentially via a higher level service

2. Applications registered to use the available device service interfaces are either loaded or have the appropriate service-related functions enabled (if they are already loaded), or are simply informed


Application-Driven, Device Bound Use Case

1. The application queries the service interface for the availability of a specific device or device type




Application-Driven, Service-Bound

1. Applications query the service interface to determine the availability of suitable services on the basis of the service elements they provide;

2. If suitable services are available the application obtains the service interface and binds to it, application features relating to the service are then enabled (this may require adapting the service interface e.g. type conversions)

3. If suitable services are not available the application either waits and then returns to step 1 (re-query), or disables the features relating to the services


Where Does the Device Interface Come From?

Something has to know how to talk to the device (i.e. a device driver)Independent concern to how interface is exposedInterface can be:

Manually written or auto-codedGenerated online or offline

Making use of an electronic data sheet


Manually Generated Device Interface

EDS

Manual Coding

Load/Enable Instantiated I/FVID/PIDClass ID

Instance ID

SubnetworkDevice

Application

DeviceI/F

OBC

Ontology


Auto-Coded Device Interface

EDS

Auto-coding

Load/Enable Instantiated I/FVID/PIDClass ID

Instance ID

SubnetworkDevice

Application

DeviceI/F

OBC

PrimitiveOps

OntologyManual Coding


Online Generated Device Interface

EDS

Generation Generated I/FVID/PIDClass ID

Instance ID

SubnetworkDevice

Application

OBCPrimitiveOps

Ontology

Manual Coding


Device Interface Generation Comments

SimilaritiesAll can/must use an EDSAll utilise subnetwork level plug-and-play

ImportantlyAll are completely independent of subnetwork

Except for EDS provision

All are completely independent of service interface approach


Service Level Requirements

Need device enumerationNeed service virtualisationService interface depends on approach

Virtual device classes with standardised interfacesCould permit device-driven application loading/enablingService interface permitting queries on service elements

e.g. “I need a service which gives me the temperature of this part of the spacecraft”


Subnetwork Level Requirements

Device discoveryManagement of subnetwork

Subnetwork-specific features of devicesSubnetwork resources

Management of subnetwork addressingReconfiguration of other subnetwork services appropriately


Subnetwork Requirements

Network discoveryDevice discovery (polled/notified)Topology discovery

Device identificationUnique identificationType/class

Configuration of subnetwork-specific device features

e.g. address, link speed

Configuration of subnetwork resourcese.g. bus controllers, routers

Sourcing of electronic data sheet


Subnetwork Network Management

Issues of mechanismHow addresses are setSubnetwork specificIndependent of mission

Issues of policyHow addresses should be assignedSubnetwork specificMission or mission class specific

Mechanism and Policy should be separated


Subnetwork Plug-and-Play Architecture

Applications

Physical Layer

Device Enumeration

Service

Device Virtualisation

Service


Device Discovery Service

Memory Access Service

Packet Service

Network Management

Service


Subnetwork Plug-and-Play Architecture

Applications

Physical Layer

Device Enumeration

Service

Device Virtualisation

Service


Device Discovery Service

Memory Access Service

Packet Service

Network Management

Service

ConfigurationNetwork

Management Service

Policy

Defined Interface?


Plug-and-Play Scope

Subnetwork and service levels are separableSubnetwork level scope:

Device discoveryDevice identificationSubnetwork configuration and management

Service level scope:Service discoveryStandardised virtual interfaceQuery-able interface?Application binding


Conclusions and Discussion Points (1)

Plug-and-play is highly beneficialIt would seriously hinder the progress of platforms using SOIS not to have plug-and-play

Requirements for subnetwork level are easily understoodRequirements placed on subnetwork technologies are easily understoodScope of plug-and-play in the subnetwork context is easily definable and constrainedA couple of minor changes necessary to subnetwork architecturePolicy should be separated from mechanismSubnetwork is separable from service level


Conclusions and Discussion Points (2)

A standard format for electronic data sheets would be useful to help tie subnetwork and service levelsService level plug-and-play is less constrainedDifferent approaches possible

Based on standardised device classes known a prioriBased on a query-able service interface to permit service inspection

Should both be supported?Should subnetwork and service level plug-and-play be separated in the context of SOIS?

07 September 2015 Peter Mendham SOIS Plug-and-Play: Use Cases and Requirements.

Documents

Transcript of 07 September 2015 Peter Mendham SOIS Plug-and-Play: Use Cases and Requirements.