Final Report Summary - MISSION (Methodology and assessment for the applicability of ARINC-664 (AFDX) in Satellite/Spacecraft on-board communicatION networks)
Executive Summary:
ARINC-664 Part 7 specification (AFDX) provides the enabling technology for network I/O in Integrated Modular Avionics (IMA) architectures, since it is designed based on the IMA concepts and requirements (ARINC 653 specification), which is already an ESA roadmap (i.e. IMA4Space project).
In order to avoid the lack of flexibility, scalability, reliability and to improve security and qualification process in spacecraft on-board data networks, ARINC-664 (AFDX) could be the solution by offering hardware assisted service, determinism and standardisation as a minimum. Additionally AFDX has been validated and is in use today in the European avionics industry, which has in some areas quite similar requirements with the space domain, in which could be more easily adopted (over SpaceWire, or directly Ethernet for space).
Together with an intrinsic improvement of systems performance, product assurance and reliability, applying the concept of AFDX into spacecraft on-board system is expected to provide multiple benefits at all industrial level such as standardized and configurable systems, products and technology elements, easier and faster integration of complex systems, larger procurement basis, and easier sub-contracting scheme.
The MISSION project aimed to apply the IMA avionics concept on spacecraft, together with highly deterministic interconnected on-board network (ARINC-664, AFDX). It constituted an enabling technology harmonization and standardization action.
The project started on 01/01/2013, and its duration was 24 months. The partners involved in this project are TELETEL, CES, GTD, ASTRIUM and University of Surrey.
Project Context and Objectives:
The main objectives of the MISSION project include:
• To perform a state-of-the-art analysis for on-board data networks architectures, concepts and requirements in the space sector.
• To analyse the requirements for introducing ARINC-664 (AFDX) in satellite/spacecraft on-board data networks.
• To perform simulations for the applicability of ARINC-664 (AFDX) for space data networks.
• To design and develop ARINC-664 (AFDX) configuration and traffic profiles for space.
• To develop and validate a representative ARINC-664 (AFDX) over Ethernet ground demonstrator of the on-board architecture.
• To develop and validate a representative ARINC-664 (AFDX) over SpaceWire ground demonstrator of the on-board architecture.
• To widely disseminate the knowledge to be generated by the project and promote the adoption of the MIISSION approach in the space sector.
• To exploit the MISSION results for the benefit of the participating SMEs.
The MISSION approach includes:
• Define the methodology for applying ARINC-664 (AFDX) in on-board spacecraft/satellite communication networks
• Define the interfaces/modifications to existing on-board I/O subsystems
• Implement and validate an experimental prototype ARINC-664 (AFDX) network for spacecraft on-board communications
To date, there are many European SMEs developing products and solutions around the ARINC-664 (AFDX) and IMA technology in the avionics domain. The benefits MISSION aims to offer:
B1: Perform a feasibility study and validation (through simulations and demonstrators) towards the migration of the AFDX technology from the avionics domain to the space domain.
B2: Pave the way for the entire European AFDX community to exploit this know-how in the space market, thus providing them with significant competitive advantages and offering new business opportunities in the space sector.
B3: Allow the development of new Software, Hardware subsystems, solutions and products to be developed for the space market, thus its impact to the European Hi-Tech industry is expected to be high.
The MISSION project expected results include:
R1: The representative ARINC-664 (AFDX) over Ethernet ground demonstrator of the on-board architecture and the associated validation results.
R2: The representative ARINC-664 (AFDX) over SpaceWire ground demonstrator of the on-board architecture and the associated validation results.
R3: Simulation results providing recommendations for the applicability of AFDX in spacecraft/satellite on-board data networks.
R4: The consolidated evaluation results and roadmap for the deployment of ARINC-664 (AFDX) in the space sector.
R5: A methodology for applying ARINC-664 (AFDX) in spacecraft/satellite on-board data networks.
R6: The ARINC-664 (AFDX) configuration and traffic profiles for the representative on-board architecture.
Project Results:
1.3.1 CONTEXT
In Space domain a particularly for satellite architecture, inter communication links between the different equipment and the sensor actuators are mainly composed of MIL-STD-1553 for the platform and SpaceWire for the payload. Some others links such as Can buses, RS422 and proprietary solutions are also implemented for some specific needs.
Feedback from operational project on MIL STD 1553 shows that the bandwidth and the number of terminal are limited and imposes to duplicate the network. The costs and power consumption of terminals are constraints for reducing global costs. The lack of standard provides also heterogeneity and costs to redesign board and ground test software.
Feedback from operational project on SpaceWire shows that due to wormhole routing, network congestions have to be managed at software level, verification is complex, there is no native network management function and global performance is not at the level of what is possible regarding the features of the link. SpaceWire router use wormhole routing while Ethernet use store and forward approach. This difference is that if the destination port is busy the source is stalled until the port becomes free which is not acceptable in a deterministic network.
We can consider that those issues will increase in the future in terms of :
➢ Data rates and volumes with instruments technologies and new applications while ground space communications remains highly constrained
➢ Overall bandwidth and number of connected equipment or boards
➢ Applications needs for high performance real-time data exchanges and closed loop automation
➢ Equipment units that have to configured, uploaded, controlled and commanded
The lack of standardisation due to variability on buses and protocols is neither optimal nor desirable to limit costs for board software development, validation software and tools at ground level.
1.3.2 SOLUTION PROPOSED
The idea is to propose a unique solution that could cover both payload and platform needs in terms of performances and quality of service for mixing criticality. This will be an opportunity to impose a standard, having a unique technology on board and on ground for tests (limited number of interfaces and variability on acquisition boards, analysers). This will also impose a global configuration of the system that could be controlled, verified and help during feasibility analysis phases.
This solution is based on a network centric approach as it is done in aeronautical domain and called Space Data Communication Network (SDCN) based on Deterministic switched network. The determinism means to implement a protocol above a standard link such as SpaceWire or Ethernet). The idea is not to reinvent the wheel and to take benefit of a potential available market in terms of means and tools.
Among the technologies proposed (AFDX, Time Triggered Ethernet, SpaceWire D) we have analysed AFDX protocol and try to see through MISSION project if it is suitable for Space domain. SpaceWire D and Time Triggered Ethernet are not yet industrialised.
In such a technology, network interfaces of equipment or a device to the network are called End System (similar to an IO controller). The routing of message and the policy of the network is managed by switches. The two major components on which we will focus are End Systems and switches.
1.3.2.1 AFDX CONCEPTS
The protocol is standardised through ARINC664 standard and largely used in aeronautical domain and particularly by Airbus since the A380. Addressing, determinism and network management function are particularly interesting. AFDX means Avionic Full Duplex and is based on Ethernet 10, 100Mbits/s or 1Gbits/s. Switches realise the quality of services of the network.
Addressing and Framing
Inside an AFDX network, a message is uniquely identified by a UDP Source Port, a Source IP, a Destination MAC, a Destination IP and a UDP Destination Port.
The MAC Destination Address identifies a Virtual Link (VL). The MAC Source Address serves to identify the physical Ethernet interface, thus the source End System (ES), and is always unicast.
The IP header is made of an IP Source Address and an IP Destination Address. The IP Source Address identifies the transmitting ES partition whereas as the IP Destination Address identifies the targeted partition(s)
The UDP layer will be used to identify the UDP Source and Destination Ports numbers of each partition.
Addressing is really interesting because it is completely on line with Time and Space Partitioning and the notion of port and partition of the ARINC653 standard. This provides a complete end to end architecture (application to application through the network or not) as Integrated Modular Avionic (IMA).
Figure 9: AFDX protocol stack
Determinism
The determinism is guaranty by the notion of Bandwidth Allocation Gap (BAG)
• The packets to transmit are set on the media (Ethernet) at regular interval (the BAG Bandwidth Allocation Gap) not synchronise by applications
• The jitter on a VL in an end-system is bounded and cannot be more than 500 µs.
• The switch checks the allowable bandwidth and the packet characteristic and it is able to drop unexpected packet.
There is a scheduler in each end system to manage properly such as it is defined in configuration the frame to be transmitted.
Redundancy
Redundancy is one of the AFDX main features. There are two independent switched networks in an AFDX system, the A&B Networks. Each frame transmitted by an ES is sent on both networks, towards two independent set of switches. Therefore, each ES will receive two copies of each frame
Figure 10: AFDX hot redundancy
The redundancy proposed is quite different from the one applied in space domain due to cross strapping and cold redundancy.
Integrity checking
Integrity Checking (IC) is done for both A&B branch of the AFDX network. It is done for each VL individually and separately for each network. The IC is applied on the MAC layer and consists on checking the Sequence Number (SN) and identifying all invalid frames
The integrity checking makes the protocol non-compliant with standard Ethernet frame at End system and switch level. It will not be possible to mix AFDX frame to non AFDX frame.
Jitter and Latency
Frame from ports are sent when needed (available in the port). All the messages planed on a VL could be send or only some of them depending application constraints. This scheduler effect is the first impact on the jitter. The second one is introduced by switches and the last one more difficult to analyse and prevent are the drifts of clock on the different connected end system.
The jitter is a transmit latency appearing as a frame time offset within the BAG. The maximum timing jitter is defined and enforced for each BAG rate for every VL in the network, to maintain maximum bounded latency for all network traffic
Latency can perform at every level in an AFDX network during a message delivery. There can be latency of scheduling the virtual links, of transmission to the switch, of the switch management, of the transmission to the destination ES, of the message management at the destination ES
Fragmentation, reassembly
It is possible in a port to send messages that have to be fragmented to respect the size frame of an Ethernet frame. Mechanism is describe in the standard and could be manage by the End system. It is possible de manage 4 fragmentation/ reassembly buffers per VL. This feature is interesting for telemetry and telecommand, to avoid fragmentation at software level.
The network management function
AFDX describes the way to observe and control the behaviour of the network. On each end systems and switches a Management Information Base is update on all traffic information (number of frame received, rejected at switch level and the associated kind of errors)
The switch considers only frame as valid if:
• Destination address is valid
• VL is valid for the physical destination port
• Frame check sequence is valid
• Frame size is aligned
• Frame size is in the allowed range
• Frame size is less or equal to Lmax
• BAG is respected
It rejects frames that are not valid. This is the key feature to mix criticality on the network avoiding babbling idiot or perturbation from the payload to the platform part of the network.
The network Management Function could be implemented on board, on a specific equipment or on a network analyzer connected to a test port of a switch.
This function manages and controls the MIB. MIB information of a switch or end system is accessible though the network using SAP ports and SNMP protocol.
The MIB must be standardized in order open the market for other domain. It is generally structured in a hierarchical manner. Each element is referenced by a standardized object identifier. MIB II standardized by RFC 1213 is used for all TCP/IP equipment. MIB are described using ASN1 language (Abstract Syntax Notation One).
This is very powerful to manage Failure Detection and provide element to manage the recovery.
1.3.2.2 AFDX FOR SPACE
Topology
Actual type avionic architecture of a satellite could be presented on the following figure as an example.
Figure 11: Avionic architecture
The platform equipement are interconnected with 1553 and the payload with SpaceWire. Routers for SpaceWire are implemented in Mass Memory. End systems are SpaceWire IP in instruments and 1553 IPs on FPGA or ASICs (SCOC3 for the On Board Computer (OBC) ) on all the sensors/ actuators and systems of the platform.
In a similar way, a topology based on AFDX could be:
Figure 12: Architecture based on AFDX
End systems IPs (SpaceWire and 1553) are replaced by and AFDX IP and switches are placed as boards in mass memory, Remote Interface Unit (sort of interface for small systems such as thermistor or to make the link with legacy systems ) or On Board Computer.
This topology is an example and could change depending on the mission (element connected ) and RAMS/ FDIR constraints.
End system, switches design
The End System could be a board such as it is in aeronautical domain (implemented in all calculators connected to the network). But it will be very difficult to implement a board in a star tracker, a reaction wheel or an IMU. It is preferred to keep the idea of an IP integrated in components available for space (Radhard FPGA or ASIC)
The switches could be a system such as it is in aeronautical domain but it will be difficult to had qualified calculators in the global architecture for mass, power, environmental constraints and RAMS/FDIR aspects. So we prefers to integrate them as a board or an ASIC in the calculators already present in the architecture (Mass Memory, OBC or RIU).
To succeed, the footprint of the IP for End System has to be limited. This is why the VHDL has to be optimised by reducing the functionality (number of VL, ports, message, and fragmentation). Having a solution that could customize the VHDL depending on those criteria could be a solution to have many candidate to be connected on the link.
Designed IPs for AFDX above Ethernet End Systems are available on the market. Switches IPs are not yet. The PHY for space is also missing and an ESA study is launched to design a low power, low cost PHY for space constraints.
FDIR
Redundancy addressed by the standard concern the link (network redundancy) and it is suitable for space. But in space domain for RAMS and power consumption constraints, some equipment are redounded with cold redundancy.
Concerning redundancy of equipment, we are facing the following specific conditions in space domain:
• In cold redundancy, one function is operational and the redundant part is not powered. The same bus profile must be defined at configuration level with different addressing for the same software data structure.
• In warm redundancy, there is one active part of the function. The redundant one is powered for reduced functionality or to be already powered in case of failure of the nominal one.
• In hot redundancy, both operational and redundant functions are powered on and data profile is redounded.
A table in non-volatile memory is initiated at ground or by ground with nominal equipment or boards. This configuration is applied at restart by hardware for some equipment (OBC) and by OBC software command for others equipment.
Command on equipment with 1553 are the same indifferently coming from the two OBCs. Same configuration could be applied in nominal and redounded equipment connected. Just the address changes at bus Controller level.
With AFDX Master-Slave schema is no longer needed and data are sent in a more flexible way from equipment and OBC depending on static configuration. Data arrives on time such as it done with 1553 predefined bus profile without any command in that precise case. But all the traffic has to be planed and slot reserved for all communication even if the equipment is powered off. The configuration on redounded equipment has to be different from the nominal one in terms of addressing for VL routing at switches level. This will have an impact on the industrial process.
1.3.3 ACHIEVED RESULTS
This project has allowed the MISSION consortium to mature many critical points of the AFDX technology with respect to its suitability for being used in the space domain and provided the guidelines to make it operational.
• Modular IP with a suitable footprint for a space solution is available and could be implemented either within FPGA or developed in specific ASIC’s suitable for space flight.
• A data profile representative for space future application is available as well as the configuration to evaluate impact from different type of topology. These provide the sizing element to produce the VHDL for future implementation of network end points
• Performance analysis executed in a simulated environment have demonstrated that given the on-board network representative traffic, the data transfers jitters will be manageable without risks at application level., which is a critical feasibility point w.r.t. space critical missions.
• A very powerful configuration tool has been developed which will help designing the IP, evaluate feasibility of a topology and provide an abstract way to produce a configuration without being an expert on IP design or for UDP network protocol addressing.
• The dynamic market for AFDX already provides analysers and emulators of end systems.
Not all issues have been completely carried out an in particular, the switches functions and implementation issues are not completely explored. For instance, there is still no clear assessment of the level of complexity should be embedded in a routing switch (e.g. set of functions and number of ports) and whether a switch should always be implemented inside network connected equipment units or if it should also be developed as an independent unit. This later issue is closely linked to the specific mission’s use cases characteristics and topology as well as the business model for the production number of routing switches the space market could sustain...; so further studies for raising the technology maturity in the space domain should address this issue.
1.3.4 WAY FORWARD FOR INDUSTRIALIZATION
1.3.4.1 ASSESS BENEFITS AND SELECT THE TECHNOLOGY
As assessed by the MISSION study for the satellite use case, the main benefit of going from the current 1553B (on platforms) and SpaceWire (on Payloads) would be to rely on a unique technology for the whole spacecraft thus making a bench of cost cuttings in building blocks developments, equipment, on-board and ground software, test infrastructure, knowledge management etc... Another benefit is the enabling factor of AFDX for deploying IMA type of architecture which has demonstrated its efficiency in the aeronautical domain. Last but not least, the use of Ethernet technology in space would reduce the “space specific technology” domain enabling better synergy with the more affordable and more dynamic ground technologies mainly based on Ethernet networks. But in order to efficiently introduce Ethernet networks in space applications and in particular for the next generation satellites and other orbital systems to be developed in Europe, several issues and still need to be addressed and conditions to be met.
First, a global technology assessment should be performed by the European Space Industry involving Large Systems Integrators (Airbus, TAS, OHB...) and some key equipment providers with the support of European space agencies. This should aim at consolidating the benefits for the European space industry of an architectural evolution of the satellites platforms and payloads data handling systems towards an IMA/AFDX concept. Moreover, there must be other factors such as, for instance, a very strong threat of market losses due to aggressive international competition from US or emerging countries, to justify huge investments for a drastic cut of the spacecraft recurring cost. In such case, the new technology deployment could be justified for the development of a novel data-handling architecture paradigm. Indeed, if the evolution of the Payload data network toward an AFDX/Ethernet based solution can be quite natural since already organized around a SpaceWire Network and getting a direct benefit from the functions and performance brought buy the new standard, such change of the space avionics architecture on spacecraft platforms is not obvious: it is today based in European industry on 1553B bus or CAN bus and does not drastically require improvements and performance except the recurring cost. Evolution toward an IMA/AFDX network centric approach would be radical and will not be justifiable just for the replacement of the old but existing technology by an up-to-date one.
A second point to be addressed is a final selection of the most suitable technology(ies) among still several candidates. Indeed, potential other technologies than AFDX are being developed in parallel for space on-board network which could also enable the IMA approach, such as TTEthernet and SpaceWire-2:
• TTEthernet standard, is currently selected for critical applications in the Manned Flight domain (with MPCV/Orion project developed with ESA and NASA) and is a candidate for the Ariane 6 launcher development with ESA. It is not yet assessed for satellite use cases: this is planned to be addressed by CNES R&T program in 2015; The TTEternet protocol also claims at being compatible with the AFDX protocol.
• Evolution of the state-of-the-art SpaceWire standard (SpaceWire-2) which functionalities could be enhanced to support higher bandwidth, better determinism and network management; While SpaceFibre is currently being implemented allowing higher bandwidth with interoperability with SpaceWire networks but this development does not actually address the on-board networking requirements as established by the MISION project. The ESA roadmap plans for a deeper update of the SpaceWire standard to address future use around 2018.
Airbus Defence and Space made already a preferred approach for Ethernet based solution for its many benefits as confirmed for satellites in the MISSION study but also in other consolidation studies such as Avionique-X in a launcher use case. Trade-off for using AFDX or TTEthernet – or both (i.e. AFDX protocol implemented on TTEThernet devices) is programmed within the CNES R&T study to be started in 2015.
1.3.4.2 DEVELOPMENT ROADMAP
Industry can rely on a new standard for future missions only once the technology is proved to be mature enough (e.g. TRL6). For such technology proposed to eventually replace a the state of the art and reliable solution (e.g. 1553B+SpaceWire), a development roadmap has to be endorsed by other industrials and space agencies; the European Space Agency, which is one of the main European spacecraft customers and the reference technical authority for space standardisation should clearly be involved and supporting this roadmap. So getting ESA to run a TRP studies plan to consolidate the generic technology selection and the roadmap for Ethernet based on-board networks and IMA architecture is a priority.
Once a technology choice is clearly defined, the development of space qualified building blocks is enabled and to be tackled. The set of space building blocks to be developed is to be assessed in a global development roadmap and implemented in a step by step mode depending on the missions and market needs. For example:
• End points standard IP: to be integrated in interfacing devices such as endpoint interface FPGA’s or central computers core processing systems on chips (embedding processing and I/O function) or I/O controllers...
• Routing switch standard IP to be integrated in equipment interconnection FPGA or SoC;
From these IP’s, standalone interconnection devices could be developed later on such as end point standard component (a small ASIC or FPGA based device allowing direct I/O data storage and memory access), or a routing switch unit allowing to build ad-hoc network topology.
Developing space components (components that are robust to the space environment and in particular to the space radiations effects) is a long and expensive process, which return on investment is to be balanced with the benefits of switching to the new standard. To be sustainable, such development will have to be supported by shared industry and institutional efforts. The traditional way being for the member states to support the necessary R&T programs through GSTP in support to European Industry’s Competitiveness.
Standardisation efforts at the level of the ECSS (European Cooperation for Space Standardisation) shall be deployed in parallel to avoid multiple variants of the building blocks and communication protocols to be developed by the very inventive European engineering community and better guarantee interoperability of all the developed components.
Of course, supporting ground test devices, network configuration tools and software supporting the selected space communication standard should also be developed in parallel, but these, starting from the existing AFDX ecosystem, should be rather straight forward.
1.3.4.3 GETTING THE TECHNOLOGY ON-BOARD
In parallel with a roadmap securing the development activities of the technology up to a TRL6 maturity level, which is a minimum required for a selection on a scientific program, getting a boost in the maturity level up to TRL9 is necessary to get endorsement of the change by big industrial programs such as telecom or earth observation missions with commercial stakes attached. An early flight opportunity on a technology demonstration mission such as a Proba satellite from ESA or with an academic/university micro satellite program with DLR, UKSA or CNES would be a way to trigger the selection on a scientific or industrial mission through the “flight demonstration” effect which is a non-scientific but very efficient psychological factor.
1.3.5 CONCLUSION
The MISSION study’s results globally assess the feasibility of the AFDX technology concept for being use in space applications and also provide sufficient elements to start setting-up an industrialization road-map taking into account global usage and business model on the space market.
Potential Impact:
1.4 POTENTIAL IMPACT, DISSEMINATION, EXPLOITATION
1.4.1 POTENTIAL IMPACT
The expected results of the MISSION project include:
• The representative ARINC-664 (AFDX) over Ethernet ground demonstrator of the on-board architecture and the associated validation results.
• The representative ARINC-664 (AFDX) over SpaceWire ground demonstrator of the on-board architecture and the associated validation results.
• Simulation results providing recommendations for the applicability of AFDX in spacecraft/satellite on-board data networks.
• The consolidated evaluation results and roadmap for the deployment of ARINC-664 (AFDX) in the space sector.
• A methodology for applying ARINC-664 (AFDX) in spacecraft/satellite on-board data networks.
• The ARINC-664 (AFDX) configuration and traffic profiles for the representative on-board architecture.
MISSION will pave the way for the entire European ARINC-664 (AFDX) community to exploit its know-how in the space market, thus providing them with significant competitive advantages and offering new business opportunities in the space sector. It will allow the development of new SW, HW subsystems, solutions and products to be developed for the space market, thus its impact to the European Hi-Tech industry is expected to be high.
MISSION will constitute an enabling technology harmonization and standardization action. Together with an intrinsic improvement of systems performance, product assurance and reliability, it is expected to provide multiple benefits at all industrial level such as standardized and configurable systems, products and technology elements, easier and faster integration of complex systems, larger procurement basis, easier sub-contracting scheme.
1.4.2 DISSEMINATION
In summary, the MISSION consortium has completed the establishment of dissemination platform by means of:
• MISSION project website. The website will be kept updated following the project development.
• Publicity materials. Two versions of the MISSION brochures were created disseminated to the audiences that the consortium is contacting.
• Contact with the selected end users (or stakeholders). After contacting with those users interested in the MISSION context, the final version of Special Interest Group contact list is completed.
• Organization of events. Two workshops have been organized during the MISSION project period to promote MISSION concept and disseminate project results to the stakeholders and the SIG members.
• Participation to events. MISSION partners have participated to some technical events, workshop, conference, etc. to promote MISSION concept and engage in satellite communication related studies.
• Scientific publications. Research studies carried out within the MISSION project are properly summarized and spread through publications.
All relevant details are available with the deliverable D73.
1.4.3 EXPLOITATION
The following table provides an overview of the foreseen exploitable results of the MISSION project.
Exploitable Knowledge Exploitable product(s) or measure(s) Sector(s) of application Timetable for commercial use Patents or other IPR protection Owner & Other Partners involved
SW and VHDL subsystems implementing AFDX over SpW and associated demonstrator iSAFT product series Ground Test Systems, EGSEs Q4 2016 None so far. TELETEL
AFDX Switch Simulation AFDX network simulation Protocol Simulation N/A None. UNIS
AFDX over SpW demonstrator and switch simulation AFDX Switch component definition Space
On-board equipment 2018 None so far. ASTRIUM
Automatic AFDX configuration AFDX configuration tool Configuration of Space and potentially non Space networks 2017 None so far. GTD
AFDX new HW/SW platform AFDX End system, IMA architecture On-board systems 2016 None so far. CES
Table 2: Summary of Exploitable Results
1.5 BUSINESS ASSESSMENT – MARKET POTENTIAL OF THE PROJECT RESULTS
1.5.1 SW AND VHDL SUBSYSTEMS IMPLEMENTING AFDX OVER SPW AND ASSOCIATED DEMONSTRATOR
Currently in the area of satellite/spacecraft on-board data networks there are many technologies that can support deterministic data delivery including SpW-D, SpaceFibre, TTEthernet and AFDX over SpaceWire. All of the aforementioned technologies have their prons and cons and the “competition” for the most applicable technology is quite high. At the end one (1) or two (2) technologies will prevail with ESA, CNES and DLR being the ones that will make the final selection.
Once AFDX over SpaceWire is selected, the potential for the applicability of the project results to the Space market will be very promising. In this case, the companies participating in the MISISON project will have a significant competitive advantage in providing either flight equipment and subsystems or EGSEs and relative validation equipment.
1.5.2 AFDX SWITCH SIMULATION
As a partner from university, UNIS will mainly focus on academic activities rather than the business assessment. Therefore, UNIS will initiate the AFDX related research activities which provide potential opportunity for comprehensive comparisons amongst similar communication research work. UNIS will also initiate students’ activities by combining these research topics into students’ research projects.
1.5.3 AFDX OVER SPW DEMONSTRATOR AND SWITCH SIMULATION
For switch simulation, a more complete analysis of the results will help to prove sufficient precision to avoid implementing synchronisation of end system and simplify the IP design (costs in terms of IP footprint)
AFDX over SpaceWire demonstrator provides the initial element of feasibility and material to make SpaceWire determinist. The solution seems interesting to reuse cabling and hardware interface already on the market for space domain but for industrialisation same job in terms of IP, switches and tools has to be done.
1.5.4 AUTOMATIC AFDX CONFIGURATION
The business exploitation focus on IMA and AFDX technologies can be divided in two different strategies, the very direct exploitation of the results of the activities of consortium in the MISSION project and the exploitation of the general knowledge and experience achieved in the MISSION project.
Related with the direct exploitation, based on the results of the project, few partners of the consortium could play the role of technology provider for IMA for space solutions, in particular the provision of the solutions for the AFDX configuration and traffic profile in the potential development and production of AFDX communication for space systems. The preliminary results of the project already show that the configuration tool may be applied far beyond AFDX for space systems. Other markets or applications could be a new market to be assessed, the application of the traffic profile and configuration tool for AFDX shall be explored to different domains than space.
Secondly, the specific obtained results, in terms of knowledge, methods and industrial relationships, allow consolidating and demonstrating the innovative technology developed can be used, increasing those partners capabilities in future space missions.
1.5.5 AFDX NEW HW/SW PLATFORM
CES defined and promoted new technology laboratory platform and succeeded to initiate few sales as well as new opportunities. This represent today very limited business for CES but enable the company to further assess potential as well as to continue the development of collaboration with new ecosystem partners.
1.6 ROADMAP
1.6.1 MISSION WORKSHOPS, FEEDBACK RECEIVED AND INFLUENCE MADE
Two workshops were organised by the MISSION Project Team. The first one took place during the DASIA conference in Warsaw on the 4th of June 2014 (the main place where all space industry is represented) and the second one during the CCT Conference in CNES on the 2nd of December 2014.
1.6.1.1 DASIA CONFERENCE IN WARSAW
For the Dasia conference, the following presentations were proposed first in order to have an overview on the different technologies:
• Towards a network centric distributed time- and space partitioned platform architecture (C. Fidi, TTTech Computertechnik AG, Austria - M. Jakovljevic - TTTech AG, Germany - H.-J. Herpel, G. Willich - Astrium GmbH, Satellites, Germany)
• Maturation of the TTETHERNET technology for space applications (C. Fidi, TTTech Computertechnik AG, Austria - W. Steiner - TTTech AG, Germany - A. Füsser, B. Wolff - Airbus Defense and Space, Germany)
• TTEthernet, a promising candidate for r Ariane 6 (Rémi Clavier, Pierre Sautereau - Airbus Defence and Space, France - Jean-François Dufour – ESA/ESTEC, The Netherlands)
• An AFDX Network for Spacecraft Data Handling (Marie-Hélène Deredempt - Astrium SAS, Toulouse, France - Vangelis Kollias Teletel SA Athens, Greece - Zhili Sun - University of Surrey, UK - Ernest Canamares) GTD, Spain - Philippe Ricco - CES, Switzerland)
• μAFDX (Bruno Pasquier -AIRBUS group Innovation, France - Iris Gaillardet - AIRBUS, France)
We have suggested to the organisation committee to invite Airbus for a presentation of AFDX and µAFDX solution. This was really appreciated and they have provided many interviews during the conference.
Those presentations were followed by a workshop on high speed and deterministic links chaired by C. Honvault from ESA.
Through a first round table, the Primes presented the industrial view on constraints and requirements for selecting network types. Airbus Defence and Space presented the variability of systems:
• Satellites: Observation, Science, Telecommunications, Navigation, Constellations.
• Space exploration: Cruise vehicles, specific manoeuvers, planetary exploration etc.
• Space Transportation: Orbit service vehicles, Manned Flight, Launchers etc.
Airbus Defence and Space also presented the variability on networks and data links:
• 1553 for platform and payload control
• SpaceWire for Payload data
• Can bus
• RS422
• Other standards and specific links.
We have presented the main requirements for system inter connection such as performance aspects for bandwidth, low latency determinism, the need to mix criticality (payload and platform) and that the solution must be easily configurable, assemble and test. A standard is welcome to provide interoperability, limit the variability dependency linked to system providers’ implementation and generalise a network management function.
ESA considerations for the selection of network types were presented and it was suggested to create a Savoir network group. The objectives of Savoir groups (SAVOIR means Space Avionics Open Interfaces aRchitecture) are to improve the way to deliver space system by pre-developing products and building blocks based on well-defined specifications and interfaces based on an agreed Reference Architecture. The second objective is to support industrial competitiveness and enhance product orientation.
The following discussion of proper network selection in view of resources and performance was mainly driven by the future of the companies that provide today 1553 and SpaceWire space solutions. Most of the attendance was concerned by their future business depending on the choice that will be selected. This became a sensitive subject referring to business but the subject was addressed and we have put it on the table with a new vision on what could be the future of the SpaceWire. Lots of money are invested on SpaceWire to make it deterministic with no operational solutions already available but this was done and some consider that we are not so far to have an industrial solution referring to the investment. ESA has also invested a lot for TTe for Ariane6 and they don’t want to continue investing on so many potential solutions knowing now that the solution selected will cover all the needs. This was successful even if it is compromised to have AFDX as it is on satellite. This is mainly due to the fact that synchronisation is a secure way to design and an historical way of design.
1.6.1.2 CCT IN CNES
The conference was suggested and organised in December 2014. The attendance was composed of ESA, CNES, TAS and Airbus Defence and Space participants but also companies and universities or academic interested in the potential business in terms of feasibility studies and industrialisation of a new technology.
The presentations were the following:
• QoS-oriented communications within the DAPAR architecture ( Roger LLORCA-CEJUDO CNES)
• SpaceWire-D & SpaceFibre: High Speed Deterministic Networks (Thales Alenia Space)
• Space Application based onTTEthernet (Christian Fidi, TTTech
• Avionic-X Insights and perspectives (David MONCHAUX CNES)
• An AFDX Network for Spacecraft Data Handling (Marie-Hélène Deredempt (Airbus Defence and Space ), Vangelis Kollias (Teletel) Zhili Sun (Unversity of Surrey), Ernest Canamares (GTD) , Philippe Ricco (CES))
• Deterministic Ethernet –TTEthernet (Christian Fidi, TTTech)
• Automatic synthesis of distributed time---triggered real time implementations under complex non-functional constraints (Dumitru Potop INRIA)
• ESA: current works and projects on high-speed deterministic Time-Triggered networks (Jean-Francois Dufour)
No debate followed the presentations due to the number of question after each presentation. It was recall again that SpaceWire is well known and used in satellites, many EGSE & flight equipment suppliers exist so that competition is active and that SpW presents a wide freedom of implementation creating complexity but also flexibility.
1.6.2 FORESEEN ROADMAP
Some studies were launched on ESA side since 2009 for future launcher preparatory Phase with a first step on technologies trade-off, a TTe representative HW, a TTe to fly study for Multipurpose crew vehicle and a TTe switch maturation.
A TRP on Reliable High Speed Data Bus/Network for Safety Oriented Missions is already started, in which the work and the results of the MISSION project will be used as reference. And some other studies will follow such as a TRP on characterizing off-the-shelf Ethernet transceivers ICs. It is also planned to create an ECSS standard for TTe.
MISSION communication and investment to create a community around the “network for Space” subject is the starting point of new studies planned to be launched by CNES and ESA such as TRP on New Network Paradigm for Reference Architecture, Evaluation du protocole TT-Ethernet (CNES R-S15/PF-0005-078) and architecture système satellite Evaluation du protocole TT-Ethernet :implémentation bord (CNES R-S15/PF-0005-079).
1.6.3 STANDARDISATION REQUIREMENTS
With respect to standardisation, many scenarios can be possible, which are summarised in the following paragraphs.
• The solution selected is SpaceWire-D: The interface and the switch exist. Some tools and boards exist for EGSE. The IP for end system has to be designed and qualified. The standard has to be created. It will not answer to many requirements such as the need to mix criticality and the network management function.
• The solution selected is TTe with or without AFDX. The standard exists but could not be shared as it is. The IPs for switch and End System have to be qualified and many tools have to be developed (analyser, End System emulator, EGSE, Network management Function) and configuration tool has to be improved (could be based on GTD solution). PHY for space has to be designed.
• The solution selected is AFDX on Ethernet. The standard exists and there is a community. Tools are available, analysers, end system emulators, NMF, tools for configuration. IP for End system exist. The switch IP has to be designed and qualified. PHY for space has to be designed.
• The solution selected is AFDX on SpaceWire. The AFDX standard is applicable above SpaceWire link standard. IP for End System is available and could be adapted for SpaceWire interface. IP for switch has to designed and qualified. Many tools and board for EGSE have to be developed (End system emulator, Network management Function).
1.6.4 AIRBUS D&S PLANS AND COMMITMENTS TO UPTAKE PROJECT RESULTS
Continuing on AFDX will be difficult in the context and particularly if TTe solution is selected for Ariane6. It will be then possible to try to implement AFDX above TTe. This is necessary for time and Space partitioning. We will use all the material we have from the MISSION project (data profile, topology, and configuration) to build a satellite demonstration on TTe.
We have proposed to initiate a GSTP to demonstrate feasibility of TTE applied to satellite. We will test many possible topologies and analyse the problematic of cold redundancy in a Time triggered context.
List of Websites:
www.mission-project.eu
ARINC-664 Part 7 specification (AFDX) provides the enabling technology for network I/O in Integrated Modular Avionics (IMA) architectures, since it is designed based on the IMA concepts and requirements (ARINC 653 specification), which is already an ESA roadmap (i.e. IMA4Space project).
In order to avoid the lack of flexibility, scalability, reliability and to improve security and qualification process in spacecraft on-board data networks, ARINC-664 (AFDX) could be the solution by offering hardware assisted service, determinism and standardisation as a minimum. Additionally AFDX has been validated and is in use today in the European avionics industry, which has in some areas quite similar requirements with the space domain, in which could be more easily adopted (over SpaceWire, or directly Ethernet for space).
Together with an intrinsic improvement of systems performance, product assurance and reliability, applying the concept of AFDX into spacecraft on-board system is expected to provide multiple benefits at all industrial level such as standardized and configurable systems, products and technology elements, easier and faster integration of complex systems, larger procurement basis, and easier sub-contracting scheme.
The MISSION project aimed to apply the IMA avionics concept on spacecraft, together with highly deterministic interconnected on-board network (ARINC-664, AFDX). It constituted an enabling technology harmonization and standardization action.
The project started on 01/01/2013, and its duration was 24 months. The partners involved in this project are TELETEL, CES, GTD, ASTRIUM and University of Surrey.
Project Context and Objectives:
The main objectives of the MISSION project include:
• To perform a state-of-the-art analysis for on-board data networks architectures, concepts and requirements in the space sector.
• To analyse the requirements for introducing ARINC-664 (AFDX) in satellite/spacecraft on-board data networks.
• To perform simulations for the applicability of ARINC-664 (AFDX) for space data networks.
• To design and develop ARINC-664 (AFDX) configuration and traffic profiles for space.
• To develop and validate a representative ARINC-664 (AFDX) over Ethernet ground demonstrator of the on-board architecture.
• To develop and validate a representative ARINC-664 (AFDX) over SpaceWire ground demonstrator of the on-board architecture.
• To widely disseminate the knowledge to be generated by the project and promote the adoption of the MIISSION approach in the space sector.
• To exploit the MISSION results for the benefit of the participating SMEs.
The MISSION approach includes:
• Define the methodology for applying ARINC-664 (AFDX) in on-board spacecraft/satellite communication networks
• Define the interfaces/modifications to existing on-board I/O subsystems
• Implement and validate an experimental prototype ARINC-664 (AFDX) network for spacecraft on-board communications
To date, there are many European SMEs developing products and solutions around the ARINC-664 (AFDX) and IMA technology in the avionics domain. The benefits MISSION aims to offer:
B1: Perform a feasibility study and validation (through simulations and demonstrators) towards the migration of the AFDX technology from the avionics domain to the space domain.
B2: Pave the way for the entire European AFDX community to exploit this know-how in the space market, thus providing them with significant competitive advantages and offering new business opportunities in the space sector.
B3: Allow the development of new Software, Hardware subsystems, solutions and products to be developed for the space market, thus its impact to the European Hi-Tech industry is expected to be high.
The MISSION project expected results include:
R1: The representative ARINC-664 (AFDX) over Ethernet ground demonstrator of the on-board architecture and the associated validation results.
R2: The representative ARINC-664 (AFDX) over SpaceWire ground demonstrator of the on-board architecture and the associated validation results.
R3: Simulation results providing recommendations for the applicability of AFDX in spacecraft/satellite on-board data networks.
R4: The consolidated evaluation results and roadmap for the deployment of ARINC-664 (AFDX) in the space sector.
R5: A methodology for applying ARINC-664 (AFDX) in spacecraft/satellite on-board data networks.
R6: The ARINC-664 (AFDX) configuration and traffic profiles for the representative on-board architecture.
Project Results:
1.3.1 CONTEXT
In Space domain a particularly for satellite architecture, inter communication links between the different equipment and the sensor actuators are mainly composed of MIL-STD-1553 for the platform and SpaceWire for the payload. Some others links such as Can buses, RS422 and proprietary solutions are also implemented for some specific needs.
Feedback from operational project on MIL STD 1553 shows that the bandwidth and the number of terminal are limited and imposes to duplicate the network. The costs and power consumption of terminals are constraints for reducing global costs. The lack of standard provides also heterogeneity and costs to redesign board and ground test software.
Feedback from operational project on SpaceWire shows that due to wormhole routing, network congestions have to be managed at software level, verification is complex, there is no native network management function and global performance is not at the level of what is possible regarding the features of the link. SpaceWire router use wormhole routing while Ethernet use store and forward approach. This difference is that if the destination port is busy the source is stalled until the port becomes free which is not acceptable in a deterministic network.
We can consider that those issues will increase in the future in terms of :
➢ Data rates and volumes with instruments technologies and new applications while ground space communications remains highly constrained
➢ Overall bandwidth and number of connected equipment or boards
➢ Applications needs for high performance real-time data exchanges and closed loop automation
➢ Equipment units that have to configured, uploaded, controlled and commanded
The lack of standardisation due to variability on buses and protocols is neither optimal nor desirable to limit costs for board software development, validation software and tools at ground level.
1.3.2 SOLUTION PROPOSED
The idea is to propose a unique solution that could cover both payload and platform needs in terms of performances and quality of service for mixing criticality. This will be an opportunity to impose a standard, having a unique technology on board and on ground for tests (limited number of interfaces and variability on acquisition boards, analysers). This will also impose a global configuration of the system that could be controlled, verified and help during feasibility analysis phases.
This solution is based on a network centric approach as it is done in aeronautical domain and called Space Data Communication Network (SDCN) based on Deterministic switched network. The determinism means to implement a protocol above a standard link such as SpaceWire or Ethernet). The idea is not to reinvent the wheel and to take benefit of a potential available market in terms of means and tools.
Among the technologies proposed (AFDX, Time Triggered Ethernet, SpaceWire D) we have analysed AFDX protocol and try to see through MISSION project if it is suitable for Space domain. SpaceWire D and Time Triggered Ethernet are not yet industrialised.
In such a technology, network interfaces of equipment or a device to the network are called End System (similar to an IO controller). The routing of message and the policy of the network is managed by switches. The two major components on which we will focus are End Systems and switches.
1.3.2.1 AFDX CONCEPTS
The protocol is standardised through ARINC664 standard and largely used in aeronautical domain and particularly by Airbus since the A380. Addressing, determinism and network management function are particularly interesting. AFDX means Avionic Full Duplex and is based on Ethernet 10, 100Mbits/s or 1Gbits/s. Switches realise the quality of services of the network.
Addressing and Framing
Inside an AFDX network, a message is uniquely identified by a UDP Source Port, a Source IP, a Destination MAC, a Destination IP and a UDP Destination Port.
The MAC Destination Address identifies a Virtual Link (VL). The MAC Source Address serves to identify the physical Ethernet interface, thus the source End System (ES), and is always unicast.
The IP header is made of an IP Source Address and an IP Destination Address. The IP Source Address identifies the transmitting ES partition whereas as the IP Destination Address identifies the targeted partition(s)
The UDP layer will be used to identify the UDP Source and Destination Ports numbers of each partition.
Addressing is really interesting because it is completely on line with Time and Space Partitioning and the notion of port and partition of the ARINC653 standard. This provides a complete end to end architecture (application to application through the network or not) as Integrated Modular Avionic (IMA).
Figure 9: AFDX protocol stack
Determinism
The determinism is guaranty by the notion of Bandwidth Allocation Gap (BAG)
• The packets to transmit are set on the media (Ethernet) at regular interval (the BAG Bandwidth Allocation Gap) not synchronise by applications
• The jitter on a VL in an end-system is bounded and cannot be more than 500 µs.
• The switch checks the allowable bandwidth and the packet characteristic and it is able to drop unexpected packet.
There is a scheduler in each end system to manage properly such as it is defined in configuration the frame to be transmitted.
Redundancy
Redundancy is one of the AFDX main features. There are two independent switched networks in an AFDX system, the A&B Networks. Each frame transmitted by an ES is sent on both networks, towards two independent set of switches. Therefore, each ES will receive two copies of each frame
Figure 10: AFDX hot redundancy
The redundancy proposed is quite different from the one applied in space domain due to cross strapping and cold redundancy.
Integrity checking
Integrity Checking (IC) is done for both A&B branch of the AFDX network. It is done for each VL individually and separately for each network. The IC is applied on the MAC layer and consists on checking the Sequence Number (SN) and identifying all invalid frames
The integrity checking makes the protocol non-compliant with standard Ethernet frame at End system and switch level. It will not be possible to mix AFDX frame to non AFDX frame.
Jitter and Latency
Frame from ports are sent when needed (available in the port). All the messages planed on a VL could be send or only some of them depending application constraints. This scheduler effect is the first impact on the jitter. The second one is introduced by switches and the last one more difficult to analyse and prevent are the drifts of clock on the different connected end system.
The jitter is a transmit latency appearing as a frame time offset within the BAG. The maximum timing jitter is defined and enforced for each BAG rate for every VL in the network, to maintain maximum bounded latency for all network traffic
Latency can perform at every level in an AFDX network during a message delivery. There can be latency of scheduling the virtual links, of transmission to the switch, of the switch management, of the transmission to the destination ES, of the message management at the destination ES
Fragmentation, reassembly
It is possible in a port to send messages that have to be fragmented to respect the size frame of an Ethernet frame. Mechanism is describe in the standard and could be manage by the End system. It is possible de manage 4 fragmentation/ reassembly buffers per VL. This feature is interesting for telemetry and telecommand, to avoid fragmentation at software level.
The network management function
AFDX describes the way to observe and control the behaviour of the network. On each end systems and switches a Management Information Base is update on all traffic information (number of frame received, rejected at switch level and the associated kind of errors)
The switch considers only frame as valid if:
• Destination address is valid
• VL is valid for the physical destination port
• Frame check sequence is valid
• Frame size is aligned
• Frame size is in the allowed range
• Frame size is less or equal to Lmax
• BAG is respected
It rejects frames that are not valid. This is the key feature to mix criticality on the network avoiding babbling idiot or perturbation from the payload to the platform part of the network.
The network Management Function could be implemented on board, on a specific equipment or on a network analyzer connected to a test port of a switch.
This function manages and controls the MIB. MIB information of a switch or end system is accessible though the network using SAP ports and SNMP protocol.
The MIB must be standardized in order open the market for other domain. It is generally structured in a hierarchical manner. Each element is referenced by a standardized object identifier. MIB II standardized by RFC 1213 is used for all TCP/IP equipment. MIB are described using ASN1 language (Abstract Syntax Notation One).
This is very powerful to manage Failure Detection and provide element to manage the recovery.
1.3.2.2 AFDX FOR SPACE
Topology
Actual type avionic architecture of a satellite could be presented on the following figure as an example.
Figure 11: Avionic architecture
The platform equipement are interconnected with 1553 and the payload with SpaceWire. Routers for SpaceWire are implemented in Mass Memory. End systems are SpaceWire IP in instruments and 1553 IPs on FPGA or ASICs (SCOC3 for the On Board Computer (OBC) ) on all the sensors/ actuators and systems of the platform.
In a similar way, a topology based on AFDX could be:
Figure 12: Architecture based on AFDX
End systems IPs (SpaceWire and 1553) are replaced by and AFDX IP and switches are placed as boards in mass memory, Remote Interface Unit (sort of interface for small systems such as thermistor or to make the link with legacy systems ) or On Board Computer.
This topology is an example and could change depending on the mission (element connected ) and RAMS/ FDIR constraints.
End system, switches design
The End System could be a board such as it is in aeronautical domain (implemented in all calculators connected to the network). But it will be very difficult to implement a board in a star tracker, a reaction wheel or an IMU. It is preferred to keep the idea of an IP integrated in components available for space (Radhard FPGA or ASIC)
The switches could be a system such as it is in aeronautical domain but it will be difficult to had qualified calculators in the global architecture for mass, power, environmental constraints and RAMS/FDIR aspects. So we prefers to integrate them as a board or an ASIC in the calculators already present in the architecture (Mass Memory, OBC or RIU).
To succeed, the footprint of the IP for End System has to be limited. This is why the VHDL has to be optimised by reducing the functionality (number of VL, ports, message, and fragmentation). Having a solution that could customize the VHDL depending on those criteria could be a solution to have many candidate to be connected on the link.
Designed IPs for AFDX above Ethernet End Systems are available on the market. Switches IPs are not yet. The PHY for space is also missing and an ESA study is launched to design a low power, low cost PHY for space constraints.
FDIR
Redundancy addressed by the standard concern the link (network redundancy) and it is suitable for space. But in space domain for RAMS and power consumption constraints, some equipment are redounded with cold redundancy.
Concerning redundancy of equipment, we are facing the following specific conditions in space domain:
• In cold redundancy, one function is operational and the redundant part is not powered. The same bus profile must be defined at configuration level with different addressing for the same software data structure.
• In warm redundancy, there is one active part of the function. The redundant one is powered for reduced functionality or to be already powered in case of failure of the nominal one.
• In hot redundancy, both operational and redundant functions are powered on and data profile is redounded.
A table in non-volatile memory is initiated at ground or by ground with nominal equipment or boards. This configuration is applied at restart by hardware for some equipment (OBC) and by OBC software command for others equipment.
Command on equipment with 1553 are the same indifferently coming from the two OBCs. Same configuration could be applied in nominal and redounded equipment connected. Just the address changes at bus Controller level.
With AFDX Master-Slave schema is no longer needed and data are sent in a more flexible way from equipment and OBC depending on static configuration. Data arrives on time such as it done with 1553 predefined bus profile without any command in that precise case. But all the traffic has to be planed and slot reserved for all communication even if the equipment is powered off. The configuration on redounded equipment has to be different from the nominal one in terms of addressing for VL routing at switches level. This will have an impact on the industrial process.
1.3.3 ACHIEVED RESULTS
This project has allowed the MISSION consortium to mature many critical points of the AFDX technology with respect to its suitability for being used in the space domain and provided the guidelines to make it operational.
• Modular IP with a suitable footprint for a space solution is available and could be implemented either within FPGA or developed in specific ASIC’s suitable for space flight.
• A data profile representative for space future application is available as well as the configuration to evaluate impact from different type of topology. These provide the sizing element to produce the VHDL for future implementation of network end points
• Performance analysis executed in a simulated environment have demonstrated that given the on-board network representative traffic, the data transfers jitters will be manageable without risks at application level., which is a critical feasibility point w.r.t. space critical missions.
• A very powerful configuration tool has been developed which will help designing the IP, evaluate feasibility of a topology and provide an abstract way to produce a configuration without being an expert on IP design or for UDP network protocol addressing.
• The dynamic market for AFDX already provides analysers and emulators of end systems.
Not all issues have been completely carried out an in particular, the switches functions and implementation issues are not completely explored. For instance, there is still no clear assessment of the level of complexity should be embedded in a routing switch (e.g. set of functions and number of ports) and whether a switch should always be implemented inside network connected equipment units or if it should also be developed as an independent unit. This later issue is closely linked to the specific mission’s use cases characteristics and topology as well as the business model for the production number of routing switches the space market could sustain...; so further studies for raising the technology maturity in the space domain should address this issue.
1.3.4 WAY FORWARD FOR INDUSTRIALIZATION
1.3.4.1 ASSESS BENEFITS AND SELECT THE TECHNOLOGY
As assessed by the MISSION study for the satellite use case, the main benefit of going from the current 1553B (on platforms) and SpaceWire (on Payloads) would be to rely on a unique technology for the whole spacecraft thus making a bench of cost cuttings in building blocks developments, equipment, on-board and ground software, test infrastructure, knowledge management etc... Another benefit is the enabling factor of AFDX for deploying IMA type of architecture which has demonstrated its efficiency in the aeronautical domain. Last but not least, the use of Ethernet technology in space would reduce the “space specific technology” domain enabling better synergy with the more affordable and more dynamic ground technologies mainly based on Ethernet networks. But in order to efficiently introduce Ethernet networks in space applications and in particular for the next generation satellites and other orbital systems to be developed in Europe, several issues and still need to be addressed and conditions to be met.
First, a global technology assessment should be performed by the European Space Industry involving Large Systems Integrators (Airbus, TAS, OHB...) and some key equipment providers with the support of European space agencies. This should aim at consolidating the benefits for the European space industry of an architectural evolution of the satellites platforms and payloads data handling systems towards an IMA/AFDX concept. Moreover, there must be other factors such as, for instance, a very strong threat of market losses due to aggressive international competition from US or emerging countries, to justify huge investments for a drastic cut of the spacecraft recurring cost. In such case, the new technology deployment could be justified for the development of a novel data-handling architecture paradigm. Indeed, if the evolution of the Payload data network toward an AFDX/Ethernet based solution can be quite natural since already organized around a SpaceWire Network and getting a direct benefit from the functions and performance brought buy the new standard, such change of the space avionics architecture on spacecraft platforms is not obvious: it is today based in European industry on 1553B bus or CAN bus and does not drastically require improvements and performance except the recurring cost. Evolution toward an IMA/AFDX network centric approach would be radical and will not be justifiable just for the replacement of the old but existing technology by an up-to-date one.
A second point to be addressed is a final selection of the most suitable technology(ies) among still several candidates. Indeed, potential other technologies than AFDX are being developed in parallel for space on-board network which could also enable the IMA approach, such as TTEthernet and SpaceWire-2:
• TTEthernet standard, is currently selected for critical applications in the Manned Flight domain (with MPCV/Orion project developed with ESA and NASA) and is a candidate for the Ariane 6 launcher development with ESA. It is not yet assessed for satellite use cases: this is planned to be addressed by CNES R&T program in 2015; The TTEternet protocol also claims at being compatible with the AFDX protocol.
• Evolution of the state-of-the-art SpaceWire standard (SpaceWire-2) which functionalities could be enhanced to support higher bandwidth, better determinism and network management; While SpaceFibre is currently being implemented allowing higher bandwidth with interoperability with SpaceWire networks but this development does not actually address the on-board networking requirements as established by the MISION project. The ESA roadmap plans for a deeper update of the SpaceWire standard to address future use around 2018.
Airbus Defence and Space made already a preferred approach for Ethernet based solution for its many benefits as confirmed for satellites in the MISSION study but also in other consolidation studies such as Avionique-X in a launcher use case. Trade-off for using AFDX or TTEthernet – or both (i.e. AFDX protocol implemented on TTEThernet devices) is programmed within the CNES R&T study to be started in 2015.
1.3.4.2 DEVELOPMENT ROADMAP
Industry can rely on a new standard for future missions only once the technology is proved to be mature enough (e.g. TRL6). For such technology proposed to eventually replace a the state of the art and reliable solution (e.g. 1553B+SpaceWire), a development roadmap has to be endorsed by other industrials and space agencies; the European Space Agency, which is one of the main European spacecraft customers and the reference technical authority for space standardisation should clearly be involved and supporting this roadmap. So getting ESA to run a TRP studies plan to consolidate the generic technology selection and the roadmap for Ethernet based on-board networks and IMA architecture is a priority.
Once a technology choice is clearly defined, the development of space qualified building blocks is enabled and to be tackled. The set of space building blocks to be developed is to be assessed in a global development roadmap and implemented in a step by step mode depending on the missions and market needs. For example:
• End points standard IP: to be integrated in interfacing devices such as endpoint interface FPGA’s or central computers core processing systems on chips (embedding processing and I/O function) or I/O controllers...
• Routing switch standard IP to be integrated in equipment interconnection FPGA or SoC;
From these IP’s, standalone interconnection devices could be developed later on such as end point standard component (a small ASIC or FPGA based device allowing direct I/O data storage and memory access), or a routing switch unit allowing to build ad-hoc network topology.
Developing space components (components that are robust to the space environment and in particular to the space radiations effects) is a long and expensive process, which return on investment is to be balanced with the benefits of switching to the new standard. To be sustainable, such development will have to be supported by shared industry and institutional efforts. The traditional way being for the member states to support the necessary R&T programs through GSTP in support to European Industry’s Competitiveness.
Standardisation efforts at the level of the ECSS (European Cooperation for Space Standardisation) shall be deployed in parallel to avoid multiple variants of the building blocks and communication protocols to be developed by the very inventive European engineering community and better guarantee interoperability of all the developed components.
Of course, supporting ground test devices, network configuration tools and software supporting the selected space communication standard should also be developed in parallel, but these, starting from the existing AFDX ecosystem, should be rather straight forward.
1.3.4.3 GETTING THE TECHNOLOGY ON-BOARD
In parallel with a roadmap securing the development activities of the technology up to a TRL6 maturity level, which is a minimum required for a selection on a scientific program, getting a boost in the maturity level up to TRL9 is necessary to get endorsement of the change by big industrial programs such as telecom or earth observation missions with commercial stakes attached. An early flight opportunity on a technology demonstration mission such as a Proba satellite from ESA or with an academic/university micro satellite program with DLR, UKSA or CNES would be a way to trigger the selection on a scientific or industrial mission through the “flight demonstration” effect which is a non-scientific but very efficient psychological factor.
1.3.5 CONCLUSION
The MISSION study’s results globally assess the feasibility of the AFDX technology concept for being use in space applications and also provide sufficient elements to start setting-up an industrialization road-map taking into account global usage and business model on the space market.
Potential Impact:
1.4 POTENTIAL IMPACT, DISSEMINATION, EXPLOITATION
1.4.1 POTENTIAL IMPACT
The expected results of the MISSION project include:
• The representative ARINC-664 (AFDX) over Ethernet ground demonstrator of the on-board architecture and the associated validation results.
• The representative ARINC-664 (AFDX) over SpaceWire ground demonstrator of the on-board architecture and the associated validation results.
• Simulation results providing recommendations for the applicability of AFDX in spacecraft/satellite on-board data networks.
• The consolidated evaluation results and roadmap for the deployment of ARINC-664 (AFDX) in the space sector.
• A methodology for applying ARINC-664 (AFDX) in spacecraft/satellite on-board data networks.
• The ARINC-664 (AFDX) configuration and traffic profiles for the representative on-board architecture.
MISSION will pave the way for the entire European ARINC-664 (AFDX) community to exploit its know-how in the space market, thus providing them with significant competitive advantages and offering new business opportunities in the space sector. It will allow the development of new SW, HW subsystems, solutions and products to be developed for the space market, thus its impact to the European Hi-Tech industry is expected to be high.
MISSION will constitute an enabling technology harmonization and standardization action. Together with an intrinsic improvement of systems performance, product assurance and reliability, it is expected to provide multiple benefits at all industrial level such as standardized and configurable systems, products and technology elements, easier and faster integration of complex systems, larger procurement basis, easier sub-contracting scheme.
1.4.2 DISSEMINATION
In summary, the MISSION consortium has completed the establishment of dissemination platform by means of:
• MISSION project website. The website will be kept updated following the project development.
• Publicity materials. Two versions of the MISSION brochures were created disseminated to the audiences that the consortium is contacting.
• Contact with the selected end users (or stakeholders). After contacting with those users interested in the MISSION context, the final version of Special Interest Group contact list is completed.
• Organization of events. Two workshops have been organized during the MISSION project period to promote MISSION concept and disseminate project results to the stakeholders and the SIG members.
• Participation to events. MISSION partners have participated to some technical events, workshop, conference, etc. to promote MISSION concept and engage in satellite communication related studies.
• Scientific publications. Research studies carried out within the MISSION project are properly summarized and spread through publications.
All relevant details are available with the deliverable D73.
1.4.3 EXPLOITATION
The following table provides an overview of the foreseen exploitable results of the MISSION project.
Exploitable Knowledge Exploitable product(s) or measure(s) Sector(s) of application Timetable for commercial use Patents or other IPR protection Owner & Other Partners involved
SW and VHDL subsystems implementing AFDX over SpW and associated demonstrator iSAFT product series Ground Test Systems, EGSEs Q4 2016 None so far. TELETEL
AFDX Switch Simulation AFDX network simulation Protocol Simulation N/A None. UNIS
AFDX over SpW demonstrator and switch simulation AFDX Switch component definition Space
On-board equipment 2018 None so far. ASTRIUM
Automatic AFDX configuration AFDX configuration tool Configuration of Space and potentially non Space networks 2017 None so far. GTD
AFDX new HW/SW platform AFDX End system, IMA architecture On-board systems 2016 None so far. CES
Table 2: Summary of Exploitable Results
1.5 BUSINESS ASSESSMENT – MARKET POTENTIAL OF THE PROJECT RESULTS
1.5.1 SW AND VHDL SUBSYSTEMS IMPLEMENTING AFDX OVER SPW AND ASSOCIATED DEMONSTRATOR
Currently in the area of satellite/spacecraft on-board data networks there are many technologies that can support deterministic data delivery including SpW-D, SpaceFibre, TTEthernet and AFDX over SpaceWire. All of the aforementioned technologies have their prons and cons and the “competition” for the most applicable technology is quite high. At the end one (1) or two (2) technologies will prevail with ESA, CNES and DLR being the ones that will make the final selection.
Once AFDX over SpaceWire is selected, the potential for the applicability of the project results to the Space market will be very promising. In this case, the companies participating in the MISISON project will have a significant competitive advantage in providing either flight equipment and subsystems or EGSEs and relative validation equipment.
1.5.2 AFDX SWITCH SIMULATION
As a partner from university, UNIS will mainly focus on academic activities rather than the business assessment. Therefore, UNIS will initiate the AFDX related research activities which provide potential opportunity for comprehensive comparisons amongst similar communication research work. UNIS will also initiate students’ activities by combining these research topics into students’ research projects.
1.5.3 AFDX OVER SPW DEMONSTRATOR AND SWITCH SIMULATION
For switch simulation, a more complete analysis of the results will help to prove sufficient precision to avoid implementing synchronisation of end system and simplify the IP design (costs in terms of IP footprint)
AFDX over SpaceWire demonstrator provides the initial element of feasibility and material to make SpaceWire determinist. The solution seems interesting to reuse cabling and hardware interface already on the market for space domain but for industrialisation same job in terms of IP, switches and tools has to be done.
1.5.4 AUTOMATIC AFDX CONFIGURATION
The business exploitation focus on IMA and AFDX technologies can be divided in two different strategies, the very direct exploitation of the results of the activities of consortium in the MISSION project and the exploitation of the general knowledge and experience achieved in the MISSION project.
Related with the direct exploitation, based on the results of the project, few partners of the consortium could play the role of technology provider for IMA for space solutions, in particular the provision of the solutions for the AFDX configuration and traffic profile in the potential development and production of AFDX communication for space systems. The preliminary results of the project already show that the configuration tool may be applied far beyond AFDX for space systems. Other markets or applications could be a new market to be assessed, the application of the traffic profile and configuration tool for AFDX shall be explored to different domains than space.
Secondly, the specific obtained results, in terms of knowledge, methods and industrial relationships, allow consolidating and demonstrating the innovative technology developed can be used, increasing those partners capabilities in future space missions.
1.5.5 AFDX NEW HW/SW PLATFORM
CES defined and promoted new technology laboratory platform and succeeded to initiate few sales as well as new opportunities. This represent today very limited business for CES but enable the company to further assess potential as well as to continue the development of collaboration with new ecosystem partners.
1.6 ROADMAP
1.6.1 MISSION WORKSHOPS, FEEDBACK RECEIVED AND INFLUENCE MADE
Two workshops were organised by the MISSION Project Team. The first one took place during the DASIA conference in Warsaw on the 4th of June 2014 (the main place where all space industry is represented) and the second one during the CCT Conference in CNES on the 2nd of December 2014.
1.6.1.1 DASIA CONFERENCE IN WARSAW
For the Dasia conference, the following presentations were proposed first in order to have an overview on the different technologies:
• Towards a network centric distributed time- and space partitioned platform architecture (C. Fidi, TTTech Computertechnik AG, Austria - M. Jakovljevic - TTTech AG, Germany - H.-J. Herpel, G. Willich - Astrium GmbH, Satellites, Germany)
• Maturation of the TTETHERNET technology for space applications (C. Fidi, TTTech Computertechnik AG, Austria - W. Steiner - TTTech AG, Germany - A. Füsser, B. Wolff - Airbus Defense and Space, Germany)
• TTEthernet, a promising candidate for r Ariane 6 (Rémi Clavier, Pierre Sautereau - Airbus Defence and Space, France - Jean-François Dufour – ESA/ESTEC, The Netherlands)
• An AFDX Network for Spacecraft Data Handling (Marie-Hélène Deredempt - Astrium SAS, Toulouse, France - Vangelis Kollias Teletel SA Athens, Greece - Zhili Sun - University of Surrey, UK - Ernest Canamares) GTD, Spain - Philippe Ricco - CES, Switzerland)
• μAFDX (Bruno Pasquier -AIRBUS group Innovation, France - Iris Gaillardet - AIRBUS, France)
We have suggested to the organisation committee to invite Airbus for a presentation of AFDX and µAFDX solution. This was really appreciated and they have provided many interviews during the conference.
Those presentations were followed by a workshop on high speed and deterministic links chaired by C. Honvault from ESA.
Through a first round table, the Primes presented the industrial view on constraints and requirements for selecting network types. Airbus Defence and Space presented the variability of systems:
• Satellites: Observation, Science, Telecommunications, Navigation, Constellations.
• Space exploration: Cruise vehicles, specific manoeuvers, planetary exploration etc.
• Space Transportation: Orbit service vehicles, Manned Flight, Launchers etc.
Airbus Defence and Space also presented the variability on networks and data links:
• 1553 for platform and payload control
• SpaceWire for Payload data
• Can bus
• RS422
• Other standards and specific links.
We have presented the main requirements for system inter connection such as performance aspects for bandwidth, low latency determinism, the need to mix criticality (payload and platform) and that the solution must be easily configurable, assemble and test. A standard is welcome to provide interoperability, limit the variability dependency linked to system providers’ implementation and generalise a network management function.
ESA considerations for the selection of network types were presented and it was suggested to create a Savoir network group. The objectives of Savoir groups (SAVOIR means Space Avionics Open Interfaces aRchitecture) are to improve the way to deliver space system by pre-developing products and building blocks based on well-defined specifications and interfaces based on an agreed Reference Architecture. The second objective is to support industrial competitiveness and enhance product orientation.
The following discussion of proper network selection in view of resources and performance was mainly driven by the future of the companies that provide today 1553 and SpaceWire space solutions. Most of the attendance was concerned by their future business depending on the choice that will be selected. This became a sensitive subject referring to business but the subject was addressed and we have put it on the table with a new vision on what could be the future of the SpaceWire. Lots of money are invested on SpaceWire to make it deterministic with no operational solutions already available but this was done and some consider that we are not so far to have an industrial solution referring to the investment. ESA has also invested a lot for TTe for Ariane6 and they don’t want to continue investing on so many potential solutions knowing now that the solution selected will cover all the needs. This was successful even if it is compromised to have AFDX as it is on satellite. This is mainly due to the fact that synchronisation is a secure way to design and an historical way of design.
1.6.1.2 CCT IN CNES
The conference was suggested and organised in December 2014. The attendance was composed of ESA, CNES, TAS and Airbus Defence and Space participants but also companies and universities or academic interested in the potential business in terms of feasibility studies and industrialisation of a new technology.
The presentations were the following:
• QoS-oriented communications within the DAPAR architecture ( Roger LLORCA-CEJUDO CNES)
• SpaceWire-D & SpaceFibre: High Speed Deterministic Networks (Thales Alenia Space)
• Space Application based onTTEthernet (Christian Fidi, TTTech
• Avionic-X Insights and perspectives (David MONCHAUX CNES)
• An AFDX Network for Spacecraft Data Handling (Marie-Hélène Deredempt (Airbus Defence and Space ), Vangelis Kollias (Teletel) Zhili Sun (Unversity of Surrey), Ernest Canamares (GTD) , Philippe Ricco (CES))
• Deterministic Ethernet –TTEthernet (Christian Fidi, TTTech)
• Automatic synthesis of distributed time---triggered real time implementations under complex non-functional constraints (Dumitru Potop INRIA)
• ESA: current works and projects on high-speed deterministic Time-Triggered networks (Jean-Francois Dufour)
No debate followed the presentations due to the number of question after each presentation. It was recall again that SpaceWire is well known and used in satellites, many EGSE & flight equipment suppliers exist so that competition is active and that SpW presents a wide freedom of implementation creating complexity but also flexibility.
1.6.2 FORESEEN ROADMAP
Some studies were launched on ESA side since 2009 for future launcher preparatory Phase with a first step on technologies trade-off, a TTe representative HW, a TTe to fly study for Multipurpose crew vehicle and a TTe switch maturation.
A TRP on Reliable High Speed Data Bus/Network for Safety Oriented Missions is already started, in which the work and the results of the MISSION project will be used as reference. And some other studies will follow such as a TRP on characterizing off-the-shelf Ethernet transceivers ICs. It is also planned to create an ECSS standard for TTe.
MISSION communication and investment to create a community around the “network for Space” subject is the starting point of new studies planned to be launched by CNES and ESA such as TRP on New Network Paradigm for Reference Architecture, Evaluation du protocole TT-Ethernet (CNES R-S15/PF-0005-078) and architecture système satellite Evaluation du protocole TT-Ethernet :implémentation bord (CNES R-S15/PF-0005-079).
1.6.3 STANDARDISATION REQUIREMENTS
With respect to standardisation, many scenarios can be possible, which are summarised in the following paragraphs.
• The solution selected is SpaceWire-D: The interface and the switch exist. Some tools and boards exist for EGSE. The IP for end system has to be designed and qualified. The standard has to be created. It will not answer to many requirements such as the need to mix criticality and the network management function.
• The solution selected is TTe with or without AFDX. The standard exists but could not be shared as it is. The IPs for switch and End System have to be qualified and many tools have to be developed (analyser, End System emulator, EGSE, Network management Function) and configuration tool has to be improved (could be based on GTD solution). PHY for space has to be designed.
• The solution selected is AFDX on Ethernet. The standard exists and there is a community. Tools are available, analysers, end system emulators, NMF, tools for configuration. IP for End system exist. The switch IP has to be designed and qualified. PHY for space has to be designed.
• The solution selected is AFDX on SpaceWire. The AFDX standard is applicable above SpaceWire link standard. IP for End System is available and could be adapted for SpaceWire interface. IP for switch has to designed and qualified. Many tools and board for EGSE have to be developed (End system emulator, Network management Function).
1.6.4 AIRBUS D&S PLANS AND COMMITMENTS TO UPTAKE PROJECT RESULTS
Continuing on AFDX will be difficult in the context and particularly if TTe solution is selected for Ariane6. It will be then possible to try to implement AFDX above TTe. This is necessary for time and Space partitioning. We will use all the material we have from the MISSION project (data profile, topology, and configuration) to build a satellite demonstration on TTe.
We have proposed to initiate a GSTP to demonstrate feasibility of TTE applied to satellite. We will test many possible topologies and analyse the problematic of cold redundancy in a Time triggered context.
List of Websites:
www.mission-project.eu
