Spring CCSDS meetings
Opening Plenary
Chris Taylor
ESA Estec
April 2012
ESA UNCLASSIFIED – For Official Use
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
ESA UNCLASSIFIED – For Official Use
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
ESA UNCLASSIFIED – For Official Use
Current Activities
•
•
•
SAFI Phase 1
Initial evaluation
of AOCS I/Fs
SAFI Phase 2
TBD
ASRA
Avionics
Functional
Specifications
CCSDS SOIS WG
ESA, NASA, AFRL, UKSA
• SOIS service Specs
• EDS standard
• Other ?
SAVOIR
ESA/Primes. Equip. Man.
• Avionics Architecture
• SAG
•
•
•
Savoir-faire
Software
architecture
IMA
ESA UNCLASSIFIED – For Official Use
•
ECSS
Communication
standards
ITT requirements
TRP activity on EDS
SciSys, Thales, Astrium
• ICD review
• EDS Formats
• EDS Prototype
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
ESA UNCLASSIFIED – For Official Use
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)
ESA UNCLASSIFIED – For Official Use
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)
ESA UNCLASSIFIED – For Official Use
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?
ESA UNCLASSIFIED – For Official Use
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
ESA UNCLASSIFIED – For Official Use
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
ESA UNCLASSIFIED – For Official Use
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
ESA UNCLASSIFIED – For Official Use
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
ESA UNCLASSIFIED – For Official Use
What needs to be done
1) Virtual (function)
spec for each class of
device (star tracker,
reaction wheel, etc)
AOCS
Device
AOCS
Device
AOCS
Device
SOIS Device
Virtualization Service
Conversion Functions
2) ICDs describing
how to communicate
with the device in
terms of commands
and protocols
Device
Protocol
Device
Protocol
Device
Protocol
SOIS Device
Access Service
Data link Standards
(ECSS for ESA)
ESA UNCLASSIFIED – For Official Use
3) Definition of the EDS
Schema to be used for
specifying the virtual
Interface
5) Definition of
conversion
methodology
4) Definition of the
EDS schema to be
used for specifying the
Device specific
protocol
Electronic Data Sheets
Active Descriptions of Interfaces
ESA UNCLASSIFIED – For Official Use
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
ESA UNCLASSIFIED – For Official Use
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.
ESA UNCLASSIFIED – For Official Use
Evolution of Design
1. ICD
1. EDS
ICD
EDS
Manufacturer
Human
Designer
Ambiguity
resolution
App
Pres
Designer
App
Adapter
Sess
Pres
Device
Sess
Trans
Trans
Net
Net
Link
Link
Phys
ESA UNCLASSIFIED – For Official Use
Phys
Phys
Device
Phys
Developing Mission Consoles
1. ICD
1. EDS
Mission
Control Team
ICD
ICD
ICD
Mission
Control Team
EDS
EDS
EDS
Software
Developer
Console
Adapter
ESA UNCLASSIFIED – For Official Use
Devices
on Vehicle
Console
DragDrop
Adapter
Devices
on Vehicle
Generating Flight Software Headers
1. ICD
1. EDS
Software
Developer
Headers
ESA UNCLASSIFIED – For Official Use
ICD
ICD
ICD
Devices
on Vehicle
Header
Generator
Headers
EDS
EDS
EDS
Devices
on Vehicle
Generating Routine Test Procedures
1. ICD
1. EDS
Software
Developer
Test
Procedures
ESA UNCLASSIFIED – For Official Use
ICD
ICD
ICD
Software
Developer
EDS
EDS
EDS
Procedure
Generator
Devices
on Vehicle
Test
Procedures
Devices
on Vehicle
Export to Spacecraft Database
1. ICD
1. EDS
System
Integrator
ICD
ICD
ICD
System
Integrator
EDS
EDS
EDS
Export
Manual input
S/C
Database
ESA UNCLASSIFIED – For Official Use
Devices
on Vehicle
S/C
Database
Devices
on Vehicle
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.
ESA UNCLASSIFIED – For Official Use
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)
ESA UNCLASSIFIED – For Official Use