sle toolkit 18 april 2005 athens, greece csts - 1 csts charter & sle toolkit status 11 april...

18 April 2005Athens, Greece CSTS - 1

SLE Toolkit

CSTS Charter&

SLE Toolkit Status

11 April 2005Y.Doat


SLE Toolkit

Contents

A. CSTS Charter

B. Available documentation

C. SLE Tool Kit Environment

D. Association

E. Operations

F. Service Specialization

G. Summary of questions


SLE Toolkit

CSTS Charter - Goals1. Tool Kit Recommendation derived from SLE;

2. Guidelines for new service specification based on Tool Kit;

3. Prototype based on a dummy service;

4. RUFT and Radiometric Recommendations;

5. SLE API Proxy Recommendation: Internet to SLE Protocol;

6. SLE API best practices;

7. Maintenance of existing SLE books.


SLE Toolkit

CSTS Charter - Planning

Spring 2005

913.1

914.0

914.1

914.2

915.x

916.x

• ISP Recommendation (RB);• API Core Specifications (MB);• Summary of Concept & Rationale (GB);• API Programmer’s Guide (GB);• API Supplements for RAF, RCF, ROCF (MB), • API Supplements for CLTU, FSP (MB).

Autumn 2005

• Tool Kit Draft Recommendation

Spring 2006

• Prototype demonstration• RUFT & Radiometric Draft Recommendation


SLE Toolkit

Available Documentation (so far)

• ESA SLE Toolkit – Commonality Analysis – Technical Note

• JAXA: Cross Support Generic Service Part 1: Toolkit

• NASA: Working documents


SLE Toolkit

SLE API

ImplementationImplementation

Tool Kit

SLE Toolkit EnvironmentWhere do we stand?

TCP/IP

API Proxy

API Association API Operation

Derived Service

User/Provider Application

API Proxy(Based on ISP)

Also called ‘data type.


SLE Toolkit

ESA/JAXA:• Association:

– Bind– Unbind– Peer-Abort

Association

NASA:• Association:

– Bind– Unbind– Peer-Abort


SLE Toolkit

List of OperationsESA/JAXA

Start

Stop

Transfer-Data

Status-Report

Schedule-Status-Report

Sync-Notify

Async-Notify

Get-Parameter

Invoke-Directive

Throw-Event

ESA/JAXA NASAStart Start

Stop Stop

Transfer-Data Confirmed Transfer-Data

Unconfirmed Transfer-Data

Status-Report Status-Report

Schedule-Status-Report Covered by SET

Sync-Notify Event-Notify

Async-Notify

Get-Parameter Get-Parameter

Set-Parameter

Invoke-Directive

Throw-Event


SLE Toolkit

Operation: THROW-EVENT

• “The user shall invoke the FSP-THROW-EVENT operation in order to cause the provider to forward to SLE Complex Management an event that requires management action” [FSP]

• Question:

Do we want to keep a dedicated operation for interactions between Data Transfer and SLE Management?

• Note: In Toulouse we agreed to keep all existing operations.


SLE Toolkit

Operation: INVOKE-DIRECTIVE

• “The user shall invoke the FSP-INVOKE-DIRECTIVE operation to invoke the TC directives as necessary in order to (re-)establish the commanding capability ” [FSP]

• Question:Do we want to keep this operation clearly targeting TC? Do we see such a need for other services?

• Note: In Toulouse we agreed to keep all existing operations.


SLE Toolkit

New operation: SET

• NASA propose to add a SET operation covering among others SCHEDULE-STATUS-REPORT.

• Question:Do we accept new operations? What other operations would be required?


SLE Toolkit

Operations: Confirmed & UnconfirmedTRANSFER-DATA

• NASA propose a CONFIRMED-TRANSFER-DATA and an UNCONFIRMED-TRANSFER-DATA.

• Forward and Return TRANSFER-DATA do not have the same meaning:– Forward: Transfer-data, provider to confirm, provider to use async-

notification if problem– Return: Transfer-data is used to deliver only the data

• Question:Do we need to have distinct operations for confirmed and unconfirmed PDU? Can we call them TRANSFER-DATA & DELIVER-DATA?


SLE Toolkit

Operations Format

All operations are made of:• Header

– Invoke identifier;– …

• Data:– Common Data (if any);– Opaque Data.


SLE Toolkit

Operations : Common typesTwo alternatives:1. All SLE Types made available by the tool kit. In case a specialized

service would need a new type it would use the OPAQUE Type facility.E.g.: CommonType ::= CHOICE {

[1] SleTypeA, [2] SleTypeB, [3] OpaqueType – Octet String

}

2. Only OPAQUE Type made available by the tool kit. Each specialized service declares its own types.E.g: CommonType ::= OpaqueType – Octet String

Question:Which alternative do we select? Discuss pros & cons.


SLE Toolkit

Service Specialisation

Forwardcommon

RAF

ROCF

RCF

CLTU

FSP

Return common

RUFT

COMMON (Abstract)

Tracking Monitoring …

Common Type:

• Common (e.g. invoke-Id.)

• Opaque Common-type

Opaque Common-Type:

• Radiometric

Opaque Common-Type:

• Monitoring

Opaque Common-Type:

• Common Return

• Opaque Return-Type

Opaque Return-Type:

• RUFT Types


SLE Toolkit

Summary of questions

1. Do we freeze the set of operations or do we allow extensibility? I.e.

• define all operations at top level or

• Derived service may define additional operation.

2. THROW-EVENT & INVOKE-DIRECTIVE: Keep or disregard?

3. Do we accept new operations at top level: SET, …?

4. Do we merge SYNC-NOTIFY & ASYNC-NOTIFY into one operation?

5. Confirmed and unconfirmed TRANSFER-DATA or TRANSFER-DATA & DELIVER-DATA?

6. Common types: All identified SLE types in Tool Kit or leave freedom to new services?


SLE Toolkit

Summary of Questions7. Procedure approach ?

• Interdependency between operations;• Mandatory/Optional behaviour.• E.g.:

– BIND / UNBIND / PEER-ABORT;– If Transfer-Data is required one must implement Start and

Stop.On Stop reception:

• Forward: clear buffer;• Return: stop Transfer-Data.

– Throw-event implies an asynchronous notification.– Schedule-status-report implies Status-Report.– Get-parameter.


SLE Toolkit

Summary of questions8. Allow bi-directional operations ?

• Do we allow all operations to be bi-directional? E.g:

– Bi-directional DELIVER-DATA. We know the behaviour (procedure)

associated with this operation in Return services. What would it be in Forward services?

– Bi-directional TRANSFER-DATA. We know the behaviour (procedure) associated with this operation in Forward services. What would it be in Return services

– Bi-directional notification ?


SLE Toolkit

Summary of Questions 9. Layered or Abstract Approach ?

• Layered approach:– Define set of operations;– Specify services provided by layer using a set of

operations (API);– The toolkit is a layer that does not impose

application behavior.

• Abstract Service:– Specify set of operations;– Specify end-to-end => the abstract service

imposes application behavior implying interoperability.

– The toolkit is the abstract service.

sle toolkit 18 april 2005 athens, greece csts - 1 csts charter & sle toolkit status 11 april...

Documents