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

2. 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

3. 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

4. ESA UNCLASSIFIED – For Official Use Current Activities CCSDS SOIS WG ESA, NASA, AFRL, UKSA SOIS service Specs EDS standard Other ? TRP activity on EDS SciSys, Thales, Astrium ICD review EDS Formats EDS Prototype SAFI Phase 1 Initial evaluation of AOCS I/Fs SAVOIR ESA/Primes. Equip. Man. Avionics Architecture SAG ECSS Communication standards ITT requirements SAFI Phase 2 TBD ASRA Avionics Functional Specifications Savoir-faire Software architecture IMA

5. ESA UNCLASSIFIED – For Official Use 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

6. 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)

7. 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)

8. 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?

9. 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

10. 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

11. 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

12. 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

13. ESA UNCLASSIFIED – For Official Use 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 Device Protocol Device Protocol Device Protocol 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

14. ESA UNCLASSIFIED – For Official Use Electronic Data Sheets Active Descriptions of Interfaces

15. 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

16. 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.

17. ESA UNCLASSIFIED – For Official Use Evolution of Design 1.ICD1.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 Ambiguity resolution

18. ESA UNCLASSIFIED – For Official Use EDS ICD Developing Mission Consoles 1.ICD1.EDS Software Developer ICD Adapter Console Devices on Vehicle EDS Mission Control Team Console Devices on Vehicle Drag- Drop Adapter Mission Control Team

19. ESA UNCLASSIFIED – For Official Use EDS ICD Generating Flight Software Headers 1.ICD1.EDS Software Developer ICD Headers Devices on Vehicle EDS Header Generator Devices on Vehicle Headers

20. ESA UNCLASSIFIED – For Official Use EDS ICD Generating Routine Test Procedures 1.ICD1.EDS Software Developer ICD Devices on Vehicle EDS Procedure Generator Devices on Vehicle Test Procedures Software Developer Test Procedures

21. ESA UNCLASSIFIED – For Official Use EDS ICD Export to Spacecraft Database 1.ICD1.EDS System Integrator ICD Devices on Vehicle EDS Devices on Vehicle S/C Database System Integrator S/C Database Export Manual input

22. ESA UNCLASSIFIED – For Official Use 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.

23. 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)