The activities aims at defining a new communication paradigm for the On-Board Reference Architecture based on SpaceWire networks and the framework required to support the design of spacecraft communication network. The new paradigm, fully compliant with the SpaceWire standard (ECSS-E-ST-50-12C) shall ensure the interconnection of SpaceWire devices and the determinism of their communications. This new approach will be developed and integrated in a framework. It will be applied on a representative Use Case applying on both AOCS and payload applications.

In the short term, the results of this study shall ease the definition of the new generation of on-board architecture and their verification using representative scenarios. In addition, the results of this study should be taken into account in the definition of a new version of the SpaceWire switches and possibly to provide inputs to the next version of the SpaceWire standard. At longer term, the determinism of communication on a high performance bus is of great interest and its implementation shall simplify and standardize the communications within spacecraft's with the objective to ease their integration and validation.The SAVOIR (Space Avionics Open Interface Architecture) group defined an avionics reference architecture where on-board communication links form its backbone. They allow connecting together the main electronic functions of the spacecraft. Generally they are split into several serial links to segregate the data flows and to propose an adapted link to the various data rate exchanges, e.g. low-speed communication links for Avionics (MIL-STD-1553B) and high-speed communication links for payloads (SpaceWire). A new trend is emerging where a single high-speed communication network is used for transferring both avionics and payload data. At ESA, a recent example is Bepi-Colombo relying on a SpaceWire network for part of its avionics and for the whole payload data system. At JAXA, the ASTRO-H spacecraft (X-ray observatory) is entirely based on SpaceWire network communications, meaning that all computers, actuators and sensors for both platform and payloads share a same SpaceWire network. - The problem / The challengeOn both projects, the system designers, developers and testers faced the problem of possible contingencies at the level of SpaceWire networks. To avoid this problem on Bepi-Colombo, the number of SpaceWire switches has been increased in order to multiply the possible paths between the nodes. On Astro-H, JAXA has developed a methodology with associated protocol and tools to generate static communication schemes to be applied by all the units connected to the SpaceWire network. However, this approach leads to an important reduction of the overall network data throughput and shall be restricted to small spacecraft with low latency constraints in term of communications. A more generic approach needs to be defined for providing solutions to future missions. It shall be compliant to the On-Board Software Reference Architecture and support new concepts as Integrated Modular Avionics. In addition, it shall ease the definition and simulation of the network communications for all type of spacecraft's in order to help the system designer to find the best solution and to adapt it all along the life of the project.- The proposed solution: full application of the SpaceWire standardMeanwhile, the SpaceWire switches evolve through the implementation of functions defined as optional by the standard such as the Packet Distribution Service. This capability of broadcasting packets through the network opens the way for the implementation of new communication schemes for SpaceWire networks. A simple scheme includes a node (master/network controller) that can send requests to all other connected nodes (slaves) that return answers. This scheme is similar to the one used on MIL-STD-1553D and the one proposed in SpaceWire-D. It benefits from the increase of data throughput but does not optimise the network use even if several requests could be performed at a same time. Another scheme could be based on consensus and coordination algorithms (studied in the A3M TRP activity) where all nodes are able to agree on the limited number of nodes that are authorized to communicate at a given time. This scheme is more complex to implement but greatly optimizes the use of the network.Another path for evolution concerns the arbitration policy at the level of the switches that is required by the SpaceWire standard (the arbitration is in charge of selecting the communication ports that can be connected). The arbitration policy implemented in the existing SpaceWire switches is extremely simple (round-robin with or without priority management). The determinism and the reliability of the communications within a SpaceWire network can be fundamentally increased by more advanced policies. For instance, an arbitration policy could check the compliance of the data traffic with respect to predefined tables of allowed paths with respect to the addressing and possibly the protocol identifier (direct application to SpaceWire-D). A more advanced arbitration policy could be able to survey the communication throughput (paths and quotas) of all the connected devices. In any case, SpaceWire FDIR concepts shall be taken into account at the arbitration policy.The new communication scheme to be proposed shall ensure deterministic communications and maximum reliability. It shall include a detailed analysis of new arbitration policies and can take advantage of the packet distribution service if necessary.- Validation of the conceptThe proposed communication scheme and related services shall be developed, integrated and verified in a discrete event simulation environment. Several environment exists on the market. It shall be noticed that OpNet has already been used to provide SpaceWire simulation in the frame of the MOST project. (MOST is made available by ESA but an OpNet license is required). The simulation environment shall support the definition of different topologies and the simulation of representative data transfers through dedicated scenarios.As generating scenarios for such simulation environment may be laborious, one may take advantage of an automated generation using dedicated environment as TASTE. The implementation of representative application with TASTE can be used to generate communication profiles to be used in the simulation environment.A Use Case including both AOCS and payload applications shall be defined and developed for the simulation environments. This Use Case shall be as representative as possible in term of data exchanges and throughput. - The tasks related to this activity are then:1. Establishment of requirements concerning the determinism of communications in the On-Board Reference Architecture and definition of a representative Use Case.2. Identification and selection or the specification of a communication scheme compatible with SpaceWire networks. The work to be performed shall cover both node and switch aspects. It shall take into account the availability of the packet distribution and arbitration features. A new arbitration policy shall be proposed to meet the previously defined requirements. 3. Development and verification of the new communication scheme using a discrete event simulation environment and implementation of the representative Use Case.4. Analysis of the results, assessment and proposition for improvements.