Spring CCSDS meetings Opening Plenary

1. Spring CCSDS meetingsOpening Plenary Chris Taylor ESA Estec April 2012

2. 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. What needs to be done this week • 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 • 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. Current Activities • CCSDS SOIS WG • ESA, NASA, AFRL, UKSA • SOIS service Specs • EDS standard • Other ? • SAFI Phase 1 • Initial evaluation • of AOCS I/Fs • SAFI Phase 2 • TBD • SAVOIR • ESA/Primes. Equip. Man. • Avionics Architecture • SAG • TRP activity on EDS • SciSys, Thales, Astrium • ICD review • EDS Formats • EDS Prototype • ASRA • Avionics Functional Specifications • ECSS • Communication standards • ITT requirements • Savoir-faire • Software architecture • IMA

5. Savoir • Main objectives • Reduce costs and risk in the avionics procurement process • 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 • Comment • There is an urgent need to consolidate the previous work into concrete outputs that can be applied by projects and industry

6. ASRA – (Savoir Working group) • 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 • Main Achievements so far • Reference architectures • Functional specs (under review)

7. SAFI- (Savoir working group) activity 1 • Main objectives • Focused on interfaces to AOCS devices • First activity was really used to investigate approach and align the various disciplines • 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. 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. 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. 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. 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. CCSDS SOIS • Main objectives • To develop a layered set of communication services applicable to all avionics infrastructures • 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 • 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 • Comment • Most importantly it has made people think about the architecture

13. What needs to be done 3) Definition of the EDS Schema to be used for specifying the virtual Interface 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 5) Definition of conversion methodology 2) ICDs describing how to communicate with the device in terms of commands and protocols Device Protocol Device Protocol Device Protocol 4) Definition of the EDS schema to be used for specifying the Device specific protocol SOIS Device Access Service Data link Standards (ECSS for ESA)

14. Electronic Data Sheets Active Descriptions of Interfaces

15. Origin: ICD • 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 • 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. SOIS EDS’s • 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 • 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. • SOIS EDS stabilizes the semantics offered by providers of data and services, assuring reusability of components across missions.

17. Evolution of Design • ICD • EDS ICD Manufacturer EDS Human Designer Designer Ambiguity resolution App App Adapter Pres Pres Sess Device Sess Device Trans Trans Net Net Link Link Phys Phys Phys Phys

18. Developing Mission Consoles • EDS • ICD Mission Control Team Mission Control Team ICD EDS ICD EDS ICD EDS Software Developer Console Console Devices on Vehicle Devices on Vehicle Drag-Drop Adapter Adapter Console

19. Generating Flight Software Headers • ICD • EDS ICD EDS ICD Software Developer Header Generator EDS ICD EDS Devices on Vehicle Headers Devices on Vehicle Headers

20. Generating Routine Test Procedures • ICD • EDS Software Developer ICD EDS ICD Software Developer EDS ICD EDS Procedure Generator Devices on Vehicle Devices on Vehicle Test Procedures Test Procedures

21. Export to Spacecraft Database • ICD • EDS System Integrator ICD EDS ICD System Integrator EDS ICD EDS Export Manual input Devices on Vehicle Devices on Vehicle S/C Database S/C Database

22. Summary • EDS’s are accessible for algorithmic usage. • SOIS EDS’s support and enforce standard interfaces. • EDS’s provide a path for standardization of new interfaces • EDS’s remove human interpretation and errors from the tool chain • Single machine readable source for data definitions across development, test, flight, and operations • 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. 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)