Peter Mendham

1
SOIS Plug-and-Play Use Cases and Requirements

• Peter Mendham

30 April 2016
2
Agenda

• Introduction and background
• Operational scenarios
• Scenario use cases
• Synthesising a use case
• Service level approaches and requirements
• Subnetwork level requirements
• Subnetwork support requirements
• Recommendations

3
Introduction

• Asked to review plug-and-play
• Use cases
• Definition
• Scope
• Requirements
• Starting point was the concept paper
• Plus any other published material available

4
Approach

• Back to basics
• Largely ignore the SOIS architecture
• Intend to review the architecture as an outcome
• Scenarios to use cases to requirements to a
  better defined purpose and scope

5
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 spacecrafts
onboard (sub-)network, without requiring
reconfiguration or manual installation of device
drivers by any user (higher-level service or OBSW
application).
6
Scenarios

• Rapid spacecraft development
• Automated integration and test
• FDIR assistance
• Ground segment access

7
Rapid Spacecraft Development (1)

• Many drivers to reduce spacecraft development
  time
• Commercial drivers lt 2 years
• Military drivers (e.g. ORS) lt 1 week
• Reduce development time through
• Standardised components
• Standardised interfaces
• Incremental qualification/VV (cf. IMA)
• Use of in-house/commercial off the shelf
• Rapid integration

8
Rapid Spacecraft Development (2)

• Plug-and-play enablers
• Removal of dependence on subnetwork configuration
• Reuse of applications independently from devices
• Reuse of devices independently from applications
• Increase portability of applications
• Beneficiaries
• System integrators (e.g. primes)
• Customers (e.g. agencies)
• Device manufacturers
• Permits/promotes inter-agency cooperation

9
Automated Integration and Test (1)

• During integration a number of configurations are
  necessary for
• Spacecraft
• EGSE
• Each configuration must be validated
• Use plug-and-play to permit
• Discovery of devices
• Automated configuration of services/applications
• Automated configuration of EGSE and other test
  equipment

10
Automated Integration and Test (2)

• Plug-and-play enablers
• Removal of dependence on subnetwork configuration
• Configuration of communications independent to
  applications
• Validate applications independent to
  communications
• Validate devices independently from applications
  etc.
• Beneficiaries
• System integrators (e.g. primes)
• Customers (e.g. agencies)
• Device and EGSE manufacturers
• Permits/promotes inter-agency cooperation

11
FDIR Assistance (1)

• Fault detection
• Detect the disappearance of subnetwork devices
• Might indicate a fault
• Isolation
• Use subnetwork features to isolate device
• Reconfigure routing/fail over bus
• Recovery
• Identify replacement device(s)
• Reconfigure subnetwork as necessary

12
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 developers
• System integrators (e.g. primes)
• Customers (e.g. agencies)
• Spacecraft operators (may see more reliable
  spacecraft)

13
Ground Segment Access (1)

• Automated adaptation of ground segment interface
  to accommodate
• Different spacecraft configurations
• Different devices
• Adapt telemetry expected
• Format and content
• Adapt telecommands issued
• Types available and format

14
Ground Segment Access (2)

• Plug-and-play enablers
• Device discovery
• Provide services independently from subnetwork
  configuration
• Service discovery by ground segment applications
• Beneficiaries
• Operational stakeholders
• Original space and ground segment customer(s)
  (e.g. agencies)
• System integrators (e.g. primes)
• Space and ground segment developers

15
Use Cases

• Use case for each scenario
• Presented as a process
• Or multiple processes
• Will eventually be drawn together into a
  synthesised use case

16
Rapid Spacecraft Development Use Case (1)

• Use case for iterative/incremental development
  and qualification/VV
• Use case for integration of devices into
  spacecraft
• Device driven process for subnetwork issues
• Application driven process for service issues

17
Rapid Spacecraft Development Use Case (2)

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

18
Rapid Spacecraft Development Use Case (3)

1. The application is loaded
2. 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

19
Automated Integration and Test Use Case (1)

• Many similarities to previous scenario
• Two parts
• Plug-and-play on spacecraft to adapt to
  integrated devices
• Plug-and-play of EGSE attached to spacecraft for
  integration and test

20
Automated Integration and Test Use Case (2)

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
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)

21
Automated Integration and Test Use Case (3)

1. EGSE is physically and logically integrated onto
   spacecraft network
2. EGSE subnetwork plug-and-play features discover
   the device
3. Subnetwork plug-and-play network management
   detects current network configuration and
   configuration of subnetwork-related device
   features and configures EGSE subnetwork services
   accordingly
4. Subnetwork plug-and-play assists in the discovery
   of services/capabilities of device
5. Capabilities are exposed through to (potentially
   standardised) EGSE applications via a suitably
   standardised interface
6. Test and/or VV 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)

22
FDIR Assistance Use Case (1)

• FDIR process utilises plug-and-play at four
  stages
• Initial integration
• Fault detection
• Fault Isolation
• Recovery
• Additionally, plug-and-play may be used to
  accommodate non-duplicate redundancy
• Such as 3 of 4 arrangements e.g. tetrahedral gyro
  arrangements

23
FDIR Assistance Use Case (2)

• 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

24
FDIR Assistance Use Case (3)

• Fault Detection
• The prime device ceases to be either physically
  or logically present on the subnetwork
• Network discovery determines the absence of the
  device either through active polling or passive
  notification
• Optionally, applications are notified of the
  absence of the device (and potential failure)
  and/or the lack of availability of particular
  services

25
FDIR Assistance Use Case (4)

• Fault Isolation
• Subnetwork plug-and-play network management
  reconfigures the subnetwork to isolate the failed
  prime device (if possible)

26
FDIR Assistance Use Case (5)

• Recovery
• Subnetwork plug-and-play network management
  carries out network configuration and
  configuration of subnetwork-related device
  features for the redundant device
• Subnetwork plug-and-play network management
  carries out configuration of subnetwork services
  to accommodate the redundant device

27
FDIR Assistance Use Case (6)

• Service Level Adaptation
• Subnetwork plug-and-play assists in the discovery
  of services/capabilities of the remaining
  device(s)
• A uniform service interface is presented to a
  (potentially standardised) application though
  synthesis of the services provided by the
  available devices
• Applications query the service interface to
  determine the availability of replacement
  services for the ones lost
• 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)
• 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

28
Ground Segment Access Use Case (1)

• Splits into two parts
• Onboard integration and discovery of devices
• Access by ground segment applications
• First part is the same as before
• Process of second part depends access
• Device oriented
• Service oriented

29
Ground Segment Access Use Case (2)

• Device Oriented
• The ground segment application queries the
  spacecraft service interface for the availability
  of a specific device or device type
• If the device is available the application
  obtains the service interface and binds to it,
  application features relating to the service are
  then enabled
• 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

30
Ground Segment Access Use Case (3)

• Service Oriented
• Ground segment applications query the service
  interface to the spacecraft to determine the
  availability of suitable services
• 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)
• 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

31
Synthesising a Use Case

• Separate levels
• Subnetwork level
• Service level (device capabilities)
• Subnetwork level is relatively easy
• Service level splits into three approaches
• Device-driven, device-bound
• Application-driven, device-bound
• Application-driven, service-bound

32
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
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

33
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

34
Application-Driven, Device Bound Use Case

1. The application queries the service interface for
   the availability of a specific device or device
   type
2. If the device is available the application
   obtains the service interface and binds to it,
   application features relating to the service are
   then enabled
3. If the device is not available the application
   either waits and then returns to step 1
   (re-query), or disables the features relating to
   the service

35
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

36
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 exposed
• Interface can be
• Manually written or auto-coded
• Generated online or offline
• Making use of an electronic data sheet

37
Manually Generated Device Interface
Application
Subnetwork
Device
Load/Enable
Instantiated I/F
VID/PID Class ID Instance ID
Device I/F
OBC
Manual Coding
EDS
Ontology
38
Auto-Coded Device Interface
Application
Subnetwork
Device
Load/Enable
Instantiated I/F
VID/PID Class ID Instance ID
Device I/F
OBC
Auto-coding
EDS
Primitive Ops
Ontology
Manual Coding
39
Online Generated Device Interface
Application
Subnetwork
Device
Generation
Generated I/F
VID/PID Class ID Instance ID
Primitive Ops
OBC
EDS
Manual Coding
Ontology
40
Device Interface Generation Comments

• Similarities
• All can/must use an EDS
• All utilise subnetwork level plug-and-play
• Importantly
• All are completely independent of subnetwork
• Except for EDS provision
• All are completely independent of service
  interface approach

41
Service Level Requirements

• Need device enumeration
• Need service virtualisation
• Service interface depends on approach
• Virtual device classes with standardised
  interfaces
• Could permit device-driven application
  loading/enabling
• Service interface permitting queries on service
  elements
• e.g. I need a service which gives me the
  temperature of this part of the spacecraft

42
Subnetwork Level Requirements

• Device discovery
• Management of subnetwork
• Subnetwork-specific features of devices
• Subnetwork resources
• Management of subnetwork addressing
• Reconfiguration of other subnetwork services
  appropriately

43
Subnetwork Requirements

• Network discovery
• Device discovery (polled/notified)
• Topology discovery
• Device identification
• Unique identification
• Type/class
• Configuration of subnetwork-specific device
  features
• e.g. address, link speed
• Configuration of subnetwork resources
• e.g. bus controllers, routers
• Sourcing of electronic data sheet

44
Subnetwork Network Management

• Issues of mechanism
• How addresses are set
• Subnetwork specific
• Independent of mission
• Issues of policy
• How addresses should be assigned
• Subnetwork specific
• Mission or mission class specific
• Mechanism and Policy should be separated

45
Subnetwork Plug-and-Play Architecture
Applications
Device Enumeration Service
Device Virtualisation Service
Device Access Service
Network Management Service
Device Discovery Service
Memory Access Service
Packet Service
Physical Layer
46
Subnetwork Plug-and-Play Architecture
Applications
Device Enumeration Service
Device Virtualisation Service
Device Access Service
Network Management Service
Policy
Defined Interface?
Network Management Service
Configuration
Device Discovery Service
Memory Access Service
Packet Service
Physical Layer
47
Plug-and-Play Scope

• Subnetwork and service levels are separable
• Subnetwork level scope
• Device discovery
• Device identification
• Subnetwork configuration and management
• Service level scope
• Service discovery
• Standardised virtual interface
• Query-able interface?
• Application binding

48
Conclusions and Discussion Points (1)

• Plug-and-play is highly beneficial
• It would seriously hinder the progress of
  platforms using SOIS not to have plug-and-play
• Requirements for subnetwork level are easily
  understood
• Requirements placed on subnetwork technologies
  are easily understood
• Scope of plug-and-play in the subnetwork context
  is easily definable and constrained
• A couple of minor changes necessary to subnetwork
  architecture
• Policy should be separated from mechanism
• Subnetwork is separable from service level

49
Conclusions and Discussion Points (2)

• A standard format for electronic data sheets
  would be useful to help tie subnetwork and
  service levels
• Service level plug-and-play is less constrained
• Different approaches possible
• Based on standardised device classes known a
  priori
• Based 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?