ESA UNCLASSIFIED – For Official Use Spring CCSDS meetings Opening Plenary Chris Taylor ESA Estec April 2012

ESA UNCLASSIFIED – For Official Use

Spring CCSDS meetingsOpening Plenary

Chris Taylor

ESA Estec

April 2012


Goals for the week

• This is a critical week for the SOIS area!

• We are under budget attack from all sides and although we are covered for this year, we need to show results if we are to continue

• My perception is that we have sufficient resources to deliver but we need to focus the effort, share the tasks and follow through on commitments

• On the negative side we are late with all our specs and we still don’t have a clear work plan for the future

• To be positive, we have serious commitment in ESA on the work performed under the SAVOIR effort and we need to take benefit from this to support and coordinate with the CCSDS effort


What needs to be done this week

1. A review of the status of all outstanding books

• An assessment of what needs to be done to complete each book and the time and effort required

• Assignment of book captain for each book along with contributors

• Update of the charter accordingly

2. The preparation of an updated work plan for the functional interfaces and use of EDS

• Review the work being performed in SAFI and EDS at ESA and determine what should be done in the CCSDS

• Discuss the possibilities for coordination between the groups

• Develop a CCSDS plan of work and agree who does what

• Commit resources, prepare proposal and update charter


Current Activities

CCSDS SOIS WGESA, NASA, AFRL, UKSA

• SOIS service Specs• EDS standard• Other ?

TRP activity on EDSSciSys, Thales, Astrium• ICD review• EDS Formats• EDS Prototype

SAFI Phase 1• Initial evaluation

of AOCS I/Fs

SAVOIRESA/Primes. Equip. Man.

• Avionics Architecture• SAG

ECSS• Communication

standards• ITT requirements

SAFI Phase 2• TBD

ASRA• Avionics

Functional Specifications

Savoir-faire• Software

architecture• IMA


Savoir

1. Main objectives• Reduce costs and risk in the avionics procurement process

2. Main Achievements• Savoir has reinvigorated the link between ESA procurement and supply including the

prime-sub relationships

• It has recognized the advantages to be gained by all when issues are viewed from the different perspectives of customer and supplier in a common forum

• It has brought together the various disciplines that are responsible for the avionics

• It has provide the focus and steer for European research activities

• It has begun to produce innovative output to reform/improve the procurement process

3. Comment• There is an urgent need to consolidate the previous work into concrete outputs that

can be applied by projects and industry


ASRA – (Savoir Working group)

1. Main objectives

• Identify the main differences in the ESA specifications which are cost drivers for industry

• Define a common set of reference architectures and identify building blocks

• Define a set of functional requirements for building blocks

• Propose improvements to existing ECSS and ITT documentation

2. Main Achievements so far

• Reference architectures

• Functional specs (under review)


SAFI- (Savoir working group) activity 1

1. Main objectives

• Focused on interfaces to AOCS devices

• First activity was really used to investigate approach and align the various disciplines

2. Main Achievements

• Main output was feasibly – yes, for star trackers and reaction wheels, there is sufficient commonality to home in on a single functional interface

• Other devices (gyros) may be more difficult

• Separate presentation on phase one result from ESA (Fabio)


SAFI- (Savoir working group) activity 2

• Main objectives (TBC)

• Build on the results of phase 1

• Define functional interface for star trackers and reaction wheels

• Comments

• We have some capacity to influence this group depending on the CCSDS work we take on

• SciSys will all so be part of this group in a coordination role

• I have asked for the possibility of NASA participation if wanted?


Savoir-Faire (Savoir working group)

• Main objectives

• Define a standard software architecture for flight avionics

• Outputs

• Basic approach defined

• Leaning towards a software bus with SOIS services for communications

• Next step oriented towards IMA


EDS TRP on EDS

• Main objectives

• Review a selection of AOCS ICDS

• Define EDS Schema

• Prototype overall concept in within SOIS framework

• This activity, led by SciSys, is in the negotiation phase and can be steered by what is performed in CCSDS and SAFI

• Inputs to be provided this week


ECSS data link standards

• Main Objectives

• Specify a set of data link standards covering physical and datalink layers for all commonly used buses

• Standardize the access protocol to avoid reinventing the wheel for each project (less development and testing)

• Main outputs

• So far we have specs coving Milbus and SpaceWire

• We are working on Can, an updated SpaceWire and an RS442 based protocol for UART based connectivity

• Comment

• All standards are driven by the CCSS SOIS subnetwork services


CCSDS SOIS

1. Main objectives• To develop a layered set of communication services applicable to all avionics infrastructures

2. Main outputs• SOIS has delivered a set of subnetwork services that are now being used to drive all ECSS

datalink protocol standards (MilBus, CAN Bus, SpaceWire and any future work)

• SOIS will release this year a completed set of services aimed at avionics applications (access to sensors, mass memory and messaging

3. Main achievements• SOIS has succeeded in highlighting the differences between the monolithic approach taken by the

typical avionics implementations versus that taken in commercial ground communications

• It has mapped the communications requirements required by all spacecraft into an layered architecture, separating the services required from the how they are implemented

• This is leading the way to a standard set of communications protocols and a common architecture with opportunity to provide interchangeable software and hardware building blocks

4. Comment• Most importantly it has made people think about the architecture


What needs to be done

SOIS Device Virtualization Service

AOCS Device

1) Virtual (function) spec for each class of device (star tracker, reaction wheel, etc)

SOIS Device Access Service

Data link Standards(ECSS for ESA)

2) ICDs describing how to communicate with the device in terms of commands and protocols

DeviceProtocol

DeviceProtocol

DeviceProtocol

AOCS Device

AOCS Device

3) Definition of the EDS Schema to be used for specifying the virtual Interface

4) Definition of the EDS schema to be used for specifying the Device specific protocol

Conversion Functions 5) Definition of conversion methodology


Electronic Data Sheets

Active Descriptions of Interfaces


Origin: ICD

1. Present Scope of Interface Control Documents

• Inputs and outputs of a single system

• Interface between two specific systems

• Complete protocol stack from physical to application layer for one component

2. Criticism of ICD’s

• Static documentation of detail that becomes out of sync with actual component

• Human communication is sometimes necessary for clarity.

– Tends to be error prone


SOIS EDS’s

1. Support configurable components.

• An EDS describes the interface of a component across the entire protocol stack that it supports.

• The EDS’s of the flight component industry form a query-capable database in which designers may choose components for their system.

• Semantic clarity through

– Standard ETSI interfaces and nonstandard interfaces

– Dictionary of Terms used in EDS’s

– Semantic explanation of syntactic schema of EDS’s

2. SOIS EDS develops with component.

• Algorithmic usage of EDS in design tools, in simulation, and optionally during vehicle commissioning, continually tests and assures currency and coverage of interface details.

3. SOIS EDS stabilizes the semantics offered by providers of data and services, assuring reusability of components across missions.


Evolution of Design

1. ICD 1. EDS

Human Designer

ICD

Adapter

Phys

Link

Net

Trans

Sess

Pres

App

Phys

Device

Designer

EDS

Phys

Link

Net

Trans

Sess

Pres

App

Phys

Device

Manufacturer

Ambiguityresolution


EDSEDSICD

ICD

Developing Mission Consoles

1. ICD 1. EDS

Software Developer

ICD

AdapterConsoleDevices

on Vehicle

EDS

Mission Control Team

ConsoleConsoleDevices

on VehicleDrag-Drop Adapter

Mission Control Team


EDSEDSICD

ICD

Generating Flight Software Headers

1. ICD 1. EDS

Software Developer

ICD

Headers Devices on Vehicle

EDSHeader Generator

Devices on Vehicle

Headers


EDSEDSICD

ICD

Generating Routine Test Procedures

1. ICD 1. EDS

Software Developer

ICD

Devices on Vehicle

EDS

Procedure Generator

Devices on Vehicle

Test Procedures

Software Developer

Test Procedures


EDSEDSICD

ICD

Export to Spacecraft Database

1. ICD 1. EDS

System Integrator

ICD

Devices on Vehicle

EDS

Devices on VehicleS/C

Database

System Integrator

S/CDatabase

Export

Manual input


Summary

1. EDS’s are accessible for algorithmic usage.

2. SOIS EDS’s support and enforce standard interfaces.

3. EDS’s provide a path for standardization of new interfaces

4. EDS’s remove human interpretation and errors from the tool chain

5. Single machine readable source for data definitions across development, test, flight, and operations

6. From an historical viewpoint, the change from ICD’s to EDS’s is comparable to other conversions from paper to digital media, such as medical records and drafting.


Questions

• Can the common data dictionary be defined separately or is it part of the functional interface?

• If SAFI takes on the ST and RW, what are the remaining devices and which group could define them?

• Can the work on schema proceed before we have the functional and access protocols defined?

• Could we separate the schema for functional and access protocols (the access protocols will initially all be different as will the mapping between them)

• We need to give some attention to the EDS export to the spacecraft database (presumably TC and TM as in SAFI 1)