DLR ITCT (Inputs To Current Topics)

CCSDS CSSM Technical Meetings

London, United Kingdom

9 November – 14 November 2014

Friendly provided to you by: Marcin Gnat™, DLR GSOC

Contents

• Simple Schedule Blue Book (General and RID’s)• Generic File Transfer• RFI, data volume – planning information• Agency metrics/characteristics on accounting

Simple Schedule of Services BB

Simple Schedule of Services BB – RID’s (1)

• General:

• Rather good acceptance (book is short and mostly clear)• Standardization of scheduling interface (watch out -> scheduling interface, not

only Published Schedule or Simple Schedule) seems to be VERY welcome.• However, seems there is some mess-up with understanding (we standardize

actually from the end -> published schedule is a result of whole complex process. Many questions related to schedule request (service request)). -> Green Book helps only partially.

• Columbus / ISS

• Currently support over TDRS, almost permanent access, contact times pre-scheduled by NASA

• As of today no specific comments to the Blue Book as such, it seems to be usable for Columbus in the future (however this will be strongly driven by general ISS Program).

Simple Schedule of Services BB – RID’s (1)

• Other specific questions/concerns (less RID’s, more rather things which we may consider to describe better in the document):

• Where belong things like Antenna Maintenance?

• Probably this would just limit the antenna free time (different paradigm as now -> typically one “books” explicitly Antenna for the maintenance, now one would have to set the maintenance time as “not free”).

• For how long period the Antenna Free time shall be provided?

• Actually good question. Technically (depending on implementation) we can provide even Antenna Free Time for CW34 in Year 2300. Question is, how much does this make sense, operationally? How we obligate (If at all) the users to get the update?

Simple Schedule of Services BB – RID’s (1)

• Other specific questions/concerns (less RID’s, more rather things which we may consider to describe better in the document, ct’):

• Chapter 1.1.1 (Purpose) Page 1-1

• Add another reference:• b1) mission planning, e.g., to ensure that the actual planning information is

available at the ground station/relay satellite operator, to allow full automatic ground station/relay satellite operation

• Chapter 1.3.2.2 (Mission Planning)

• Add another use case:• In another mission planning use case the user agency provides the provider

agency with a schedule that gives the provider agency the information it requires to plan its uplink/downlink resource operations with respect to the final space craft schedule. This allows the provider agency to use the ground station/relay satellite resources (like power, tape space, personal, mechanical/electrical switch cycles) in a more efficient way. Furthermore it can increase the level of automation to the point of full-automatic operation of the ground station/relay satellite.

Simple Schedule of Services BB – RID’s (1)

• Text change proposal Chapter 1.3.2.2 (Mission Planning)• Change “days” into “minutes”• The planning process will typically go through a number of cycles, starting

months before the actual activities are expected to take place and being finalized a few minutes before execution.

• RID’s (which did not make it into official form):

• Time Code

• Why the time code B used and not time code A? Is there a special reason for that? Why the presence of “Z” for “Zulu Time” is an option? It should be obligatory.

Simple Schedule of Services BB – RID’s (2)

SUBMITTING ORGANIZATION (Agency, Center): DLR, EOC ------------------------------------------------------------------REVIEWER'S NAME: Damerow, Heiko CODE: E-MAIL ADDRESS: Heiko.Damerow@dlr.de TELEPHONE: +49 3981 480 209 ------------------------------------------------------------------DOCUMENT NUMBER: CCSDS 902.1-R-1 Red Book, Issue 1DOCUMENT NAME: Simple Schedule Format SpecificationDATE ISSUED: September 2014PAGE NUMBER: 3.7 PARAGRAPH NUMBER: 3.2.7.3 RID SHORT TITLE: Enumeration style ------------------------------------------------------------------DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format)To apply a common style for enumeration please use only capital lettersand underscores for semantic separation of terms. C_BAND, KA_BAND, RANGING

Simple Schedule of Services BB – RID’s (2)

SUBMITTING ORGANIZATION (Agency, Center): DLR, EOC------------------------------------------------------------------REVIEWER'S NAME: Damerow, Heiko CODE: E-MAIL ADDRESS: Heiko.Damerow@dlr.de TELEPHONE: +49 3981 480 209 ------------------------------------------------------------------DOCUMENT NUMBER: CCSDS 902.1-R-1 Red Book, Issue 1DOCUMENT NAME: Simple Schedule Format SpecificationDATE ISSUED: September 2014PAGE NUMBER: 3.7 PARAGRAPH NUMBER: 3.2.7.3 RID SHORT TITLE: Extension of class ServiceInfo ------------------------------------------------------------------DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format)

The available class ServiceInfo parameters would not unambiguously characterize a service. The recommendation is to have serviceStartTime, serviceStopTime, dataRate and channelIdent to characterize the specific service.

Simple Schedule of Services BB – RID’s (2)

SUBMITTING ORGANIZATION (Agency, Center): DLR, EOC------------------------------------------------------------------REVIEWER'S NAME: Damerow, Heiko CODE: E-MAIL ADDRESS: Heiko.Damerow@dlr.de TELEPHONE: +49 3981 480 209 ------------------------------------------------------------------DOCUMENT NUMBER: CCSDS 902.1-R-1 Red Book, Issue 1DOCUMENT NAME: Simple Schedule Format SpecificationDATE ISSUED: September 2014PAGE NUMBER: 3.7 PARAGRAPH NUMBER: 3.2.7.3 RID SHORT TITLE: Schedule Confirmation ------------------------------------------------------------------DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format)

Each schedule should at least responded by a schedule confirmation.

Generic File Transfer

Generic File Transfer – considerations

• In general (surprisingly) a welcome approach (esp. standardized protocols, folders, etc..), even not a highest priority for DLR

• Suggestions to reference (and consider) the Security working group documents:• Algorithms Blue Book (encryption and authentication methods)• Network Layer Security (Book in work)

• Missing description / considerations on duration of file storage on server. When should they be removed? Who does that? Do we drop that to be clarified in some ICD’s?

• What about consideration of very large files (videos)? Experience from Columbus shows it is not so simple, and internet is not a good solution at all.

• Careful consideration – and explanation of the decision – is needed regarding transport protocol and security layers. Why WebDAV/TLS and not FTP over SSH?

Planning Information

Planning Information – AI# 2014-0826-03

• Mission Analysis for LEOP (prepared by FD)• RFI

• FD can perform some check on conflicts (but rather reactive)• registration at ITU, exclusion zones• hinder analysis (GEO, broadcasting)• LEOP, on orbit servicing (multiple s/c launch with same freq. band, antenna

shading of serviced object)• Data volume

• Mainly domain of mission planning – depending on on-board storage use, upcoming data take orders, respective planning and recommendations or requests are generated.

• Rough estimation is performed in early design phases (analysis from PI / S/C Manufacturer). This is used as input to the design (i.e. storage capacity, bandwidth of links).

Planning Information – AI# 2014-0826-03

• Costs• based on assumed passes the cost is estimated• general cost estimates for the mission are combined effort personnel,

contractors, investments, maintenance, facilities usage (detailed estimates are internal, customer may get rather general view, at most divided to personnel, investments and facility usage).

• Resource Conflicts• covered by mission planning, scheduling and just human work

• To consider regarding the BB: Geometrical events are produced by FD, whereas data volumes, costs or resource conflicts are covered by other entities. This will lead to question who is responsible for generating planning information (Because these different things are covered by same file format and defined in one BB, people will tend to think “it’s not my business” and push the interface away).

Accountability

Accountability – AI #2014-0401-01

• No specific / pre defined format are in use• In most cases any reporting on accountability / quality is done “on request”• Post pass reports as base for reliability statistics• Reliability statistics is prepared regularly (monthly or quarterly), but for the internal

reference only (not really distributed to customers).• Question: is the post pass report part of accounting or rather service monitoring?

• Metrics / characteristics:• Number of requested passes• Number of total passes (executed)• Number of good passes*• Number of bad support G/S• Number of bad support (other reasons)• Reliability % G/S only• Reliability % other only

*) good pass does not necessarily means everything was perfect, it is rather a arbitrary decision of the project. I.e. command uplink drops down for one minute during the pass, but at that time the S/C hasn’t been actually commanded, the pass may be declared as “good”.

Accountability – AI #2014-0401-01

Reliability Some Spacecraft (example) WHM Passes 2014

MONTH TOTAL good support bad support others bad G/S support RELIABILITY on G/S RELIABILITY not depending on G/Sjan 43 42 0 1 97,67% 100,00%feb 18 18 0 0 100,00% 100,00%mar 21 19 0 2 90,48% 100,00%apr 17 17 0 0 100,00% 100,00%may 18 18 0 0 100,00% 100,00%jun 15 14 1 0 100,00% 93,33%jul 13 13 0 0 100,00% 100,00%

aug 15 13 0 2 86,67% 100,00%sep 21 21 0 0 100,00% 100,00%oct 0 0 0 0 #DIV/0! #DIV/0!nov 0 0 0 0 #DIV/0! #DIV/0!dec 0 0 0 0 #DIV/0! #DIV/0!

TOTAL/year 181 175 1 5 97,24% 99,45%