ESTEC, Noordwijk, Netherlands27 Oct 2009

SERVICE ARCHITECTURE SERVICE ARCHITECTURE FOR SPACE -- BOFFOR SPACE -- BOF

1

INTRODUCTIONErik Barkley (5 Min)

2

PROPOSED BOF Agenda

Draft Agenda, Service Architecture for Space BOF, 27 October 2009ID Topic Lead Time (min) Planning Comments1 Introduction E. Barkley 5 Review BOF Agenda.

2 Why this BOF? A. Hooke 15 Motiviations for this BOF; programmatic considerations; What is the problem that we are to solve with this BOF/new WG?

3 MOIMS Area Inputs N. Peccia 20 Scope of relevant WGs; Brief description of recommenations currently in progress; status

of recommendations; What should new WG achieve from Area perspective?

4 SE Area Inputs P. Shames 20 Scope of relevant WGs; Brief description of recommenations currently in progress; status of recommendations; What should new WG achieve from Area perspective?

5 CSS Area Inputs E. Barkley 20 Scope of relevant WGs; Brief description of recommenations currently in progress; status of recommendations; What should new WG achieve from Area perspective?

6 Overlap Analysis P. Shames 25 CCSDS Reccomendations overlap analysis. Break 10 (Because we will need it)

7Potential WG

Scope Discussion

E. Barkley 40

Based on WG surveys, analyses, etc what fits within the proposed new WG? What are its goals? E.g., A CCSDS service "map" ? Clear distinction between service layers, protocol layers?Develop precise lexicon/terminology definitions?Information Model ? Definition of acrhitecture framework & components?

8Domain

Knowledge Dicussion

TBD 20 Identification of key domain knowledge needed in composition of new WG (for input to CMC)

9 WG Formation Discussion E. Barkley 40

From a technical perspective, based on proposed SOA scope, are some WGs dissolved? Which WG's have charters modified? What has to occur to close WGs that are folded into the new WG?

10 Conclusion E. Barkley 20 Considerations of next steps, e.g., drafting SOA for Space Charter, review of action items generated, etc.

(Reserve Time) 5

3

Agenda Adjustments (If Any)

4

Suggested Ground Rules

• For input presentations, hold questions until end of presentation• Presenters – allow 3 – 5 minutes for questions @ end of

presentation• Attempt to quickly determine need for an action item vs

lengthy discussion (time budget)• For discussions, generally suggest that action

items be considered if no apparent resolution in a timely manner

• I will attempt to keep an eye on the clock, but I am only the junior AD, so I need your help

5

WHY THIS BOF?Adrian Hooke (15 Min)

6

MOIMS AREA INPUTSNestor Peccia (20 Min)

7

SE AREA INPUTSPeter Shames (20 Min)

8

CSS AREA INPUTSErik Barkley (20 Min)

9

CSS AD -- Potential First Goal/Step• The Spacecraft Onboard Interfaces

Services Area shall define the onboard data handling interface between a payload or subsystem and its carrier spacecraft.

• The Space Link Services Area shall define the data handling interfaces between two free-flying spacecraft and between a free-flying spacecraft and a ground support network.

• The Cross Support Services Area shall define the data handling interface between a ground support network and a ground user facility.

• The Mission Operations and Information Management Services Area shall define the mission control application protocols that traverse the logical (end-to-end) interface between a user facility and a payload or subsystem in space, and between two ground user facilities. 

• The Space Internetworking Services Area supports the Mission Operations and Information Management Services Area and shall define the end-to-end data communications protocols that traverse interface between a user facility and a payload or subsystem in space.

• The Systems Engineering Area supports each of the other five Areas and shall define the common services (e.g., data security) that pervade the whole space system.

(Extracted from Draft Strategic Operating Plan, CCSDS A01.1-Y-1.1, September 2006)

+

= ?(Extracted from Reference Model for Service Oriented Architecture 1.0, OASIS Standard, October 2006)

Some common understanding between CCSDS Areas re some accepted general industry-wide understanding of what a “service” definition contains or “talks” about ?10

CSS WG Survey

CSTS ScopeSM Scope

CSA Scope

11

(Preliminary) CSS Area Goal for new WG• Clear understanding of service (inter-area) service inter-relationships

• a CCSDS-wide model or service “map” [CCSDS Reference Model]

• Clear understanding of accepted CCSDS-wide “enterprise model”• What are the parties/actors involved ? [CCSDS Reference Model]

• What do CCSDS recommended service standards contain?• PDUs, State Tables, Behavioral Requirements, Information Exchange Protocol(s) ?

[Guidelines, Normative Templates?]

• Common terminology/lexicon across CCSDS• Where is the CCSDS acronym list? • Where is the overall CCSDS information model ? [Information Model]

• When services are defined, what is expected in terms of cross support definitions?• E.g, definition of PDUs• What are the parameters of the service that need management, and how much?

[Guidelines, Normative Templates?]

• What is the relationship of this architecture to the CSA architecture• Is one more oriented to the overall picture (CSA)?• Is one more oriented to the IT (Information Technology) aspects of cross

support (Service Architecture for Space) [CCSDS Reference Model]

12

Information Model Example

Service Level Agreement

Service Request

Planning Request

Hypothetical Plan

Service Package

Committed Schedule

Proposed Service Package

Uncommitted Schedule

Proposed Service Level

Agreement

May Become

0..*

0..*

0..*

0..1Constrains

Is Constrained by1..*

1..1

May Become

0..1

1..1

Recorded in

In Response to

1..1 Records

1..*

May Be Used in Deriving

May Be Constrained by

0..*

May Constrain

0..*

In Response to

0..1

1..1

May Be Derived from

Service Accountability

Data

Composed of

1..1

Contained in 0..*

Recorded in

1..1 Records

1..*

May Be Derived from May Be

Used in Deriving

Execution of Produces

Reports on Execution of

1..1

1..1

May Be Derived from

0..1

May Be UsedIn Deriving

0..1

Derived from

Becomes1..1

1..1

References to trajectories and configuratuion profiles omitted for clarity of diagram. Planning Request, Proposed Service Package, and Service Package each refer to these items.

13

RECOMMENDATIONS OVERLAP ANALYSIS

Peter Shames (25 Min)

14

TAKE A BREAK (10 MIN)

15

POTENTIAL SCOPE FOR NEW WG (DISCUSSION)

Erik Barkley (40 Min)

16

DOMAIN KNOWLEDGE (DISCUSSION)

Erik Barkley (20 Min)

17

WG FORMATION (DISCUSSION)

Erik Barkley (40 Min)

18

CONCLUSION (DISCUSSION)Erik Barkley (20 Min)

19