Download presentation
Presentation is loading. Please wait.
1
Spring CCSDS meetings Opening 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 SAFI Phase 1 Initial evaluation of AOCS I/Fs
CCSDS SOIS WG ESA, NASA, AFRL, UKSA SOIS service Specs EDS standard Other ? 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 Main Achievements Comment
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 Main outputs Main achievements Comment
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
Virtualization Service
What needs to be done 1) Virtual (function) spec for each class of device (star tracker, reaction wheel, etc) 3) Definition of the EDS Schema to be used for specifying the virtual Interface 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
Ambiguity resolution App App This diagram shows the process of designing communication between an application and a device. The application is shown with a full protocol stack, while the device is shown with an incomplete stack. With ICD’s, a designer must consider the choice of application software and devices, with the additional potential for designing some kind of adapter between them at one or more levels in the protocol stack. The adapter often takes the form of a device driver, or a wrapper for the device driver provided by the manufacturer of the device. With EDS and standard interfaces, the designer need only choose components that have matching interfaces. Algorithmic design tools have been developed (e.g., at Design-Net Engineering and Star Technologies) but are not essential. Nonstandard interfaces are supported by EDS’s also, requiring design effort similar to that for ICD’s, and the potential is present for development of adaptive layers in the protocol stack (e.g., at US Air Force Research Laboratory). Nonstandard interfaces in EDS’s will ultimately evolve into standard interfaces if they are used often. Pres Adapter Pres Sess Device Sess Device Trans Trans Net Net Link Link Phys Phys Phys Phys
18
Developing Mission Consoles
ICD EDS Mission Control Team Mission Control Team ICD ICD EDS ICD EDS EDS Software Developer This diagram shows the process of developing console displays to control a mission. With ICD’s a software developer is needed to deliver data to the screens. With EDS’s the mapping of data to the screens can be accomplished by the users of the screens through a drag-and-drop paradigm. The software for building the screens would use the electronic data sheets to populate the menus with candidate data items. The software for building the screens would only need to be developed once, and thereafter it would be available to future missions. (A prototype was developed at Interface Control Systems.) Jonathan Wilmot at NASA stated that, “For crewed vehicles, EDSes can be used at run-time to gather and interpret system data when coupled with a pub-sub MTS”. Console Console Adapter Devices on Vehicle Console Drag-Drop Adapter Devices on Vehicle
19
Generating Flight Software Headers
ICD EDS ICD Software Developer ICD EDS ICD Header Generator EDS EDS Headers Devices on Vehicle Headers Devices on Vehicle
20
Generating Routine Test Procedures
ICD EDS Software Developer ICD Software Developer ICD EDS ICD EDS EDS Procedure Generator Devices on Vehicle Devices on Vehicle Test Procedures Test Procedures
21
Export to Spacecraft Database
ICD EDS System Integrator ICD System Integrator ICD EDS ICD EDS 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)
Similar presentations
