1 Introduction

To get more lift, the mass and power savings in commercial aircraft design and compactness demand in electric and hybrid aircraft have led the aircraft industry to transition from federated to integrated module architecture [1]. This is an ongoing activity expected to last many years. The space industry has also been on the outlook for new concepts of system architectures that are based on interoperability and reconfigurability for performance, efficiency, and cost savings. The operational capability and sustainability of current spacecraft are constrained by their inherent physical system architecture, highly customised monolithic design, and the limited or no availability of servicing and maintenance.

Modular Spacecraft Assembly and Reconfiguration (MOSAR) [2] is a European Union (EU) funded initiative made by an international consortium that aims to raise the degree of modularity of space systems by an order of magnitude to the current practice. The MOSAR concept is an in-orbit reconfigurable spacecraft that can benefit from the plug and play and common interfaces whether in hardware, software, communication, or computation. MOSAR complements the modular and efficiency-focused culture within the space industry. An area of opportunity identified in MOSAR is a common architecture that could provide two functionalities: intercommunications and the distribution of power throughout the spacecraft. This would result in spacecraft requiring less material for construction and being reusable due to the ability to reconfigure the system architecture for a variety of mission operations as well as easing the hardware and software integration.

Current spacecraft systems lend to bespoke and/or proprietary methods of deploying communication networks such as MIL-STD 1553B and Controller Area Network (CAN 2.0) [3]. A full protocol stack could provide the underpinning intercommunications between future spacecraft subsystems while running over a common physical medium that distributes electric power.

The space industry appreciates the use of modular components to reduce mission costs and development time. Plug and play avionics allow devices to be added to the spacecraft, replaced, or upgraded later in the manufacturing process. Thales Alenia Space has developed a SpaceWire and SpaceFibre [4] network interface that offers full galvanic isolation between modular devices. The project goal is to develop a space-suitable power delivery solution and an extension to the plug and play avionics such that power negotiation and management can take place within the modular network. Moreover, power delivery to a remote endpoint over Ethernet is required to be consistent with the existing spacecraft power standard ECSS-E-ST-20-20C. The present project builds on this work by adding Power over Ethernet (PoE) capabilities to communication links. However, before the delivery of power is made, the communication proof-of-concept is ensured. Therefore, the focus of this paper is the development of a handshaking protocol implemented for an embedded microprocessor of an onboard command and data handling (C&DH) system or on-board computer (OBC).

2 SpaceWire and IEEE 802.3 power over ethernet (PoE)

SpaceWire was introduced in 2003 and since then it has been implemented in several missions of major space agencies. The SpaceWire protocol defines data handling for both low-rate on-board communications such as housekeeping and high-rate science data interfaces such as mass memory, processor busses and interfaces to high-speed download antennas. The protocol specifies network routing and switches for increased onboard connectivity. The SpaceWire physical layer defines the electrical characteristics of the signal transmission such as differential signalling, skew, losses, voltage levels and termination impedances between the transmitter and the receiver. This includes wires, cables, assemblies and even printed circuit traces to efficiently carry the high-speed data achieving good signal integrity.

On the other hand, Ethernet an invention of Xerox Corp. is the de facto standard for terrestrial short distance networks since the 1970s. Ethernet has gone through a tremendous evolution considering the need for speed. Right about when SpaceWire was debuted, the IEEE 802.3af PoE interface came into existence for concurrent Ethernet data communications and delivery of up to 13 W of power to any device at 13 m. For meeting green aviation and sustainability goals, PoE [5] has been suggested for delivering power over fast Ethernet in linear or star network topologies. In commercial aviation, powering of non-avionics such as cabin lamps, flight entertainment systems and routine telemetry collection have been proposed over Ethernet [6]. Microsemi develops an array of modules and integrated circuits for powering non-critical flight systems over Ethernet.

SpaceWire and PoE are intended for two very different applications. However, the commonality is a layered approach of a network. This empowers SpaceWire to ride on the Ethernet stack which in turn has the capability of transmission over a shared physical medium for simultaneous Ethernet communication and power transfer. Such technology could leverage the high interoperability by replacing units in a spacecraft when late mission decisions are made. For instance, a different attitude determination and control unit may be plugged in during the assembly, integration and test (AIT) phase of the spacecraft that has power and data interfaces for a different sensors and actuators configuration than the one conceived originally. Similarly, a high data rate and high-power radiofrequency system may be substituted. Smaller AIT cycles, high reliability and mass, area, volume and cost savings would be added advantages. Naturally, the development of such technology is a significant undertaking given the complexity of diverse technologies involved and the severity of the space environment. The present work is a feasibility study of validating SpaceWire communications over Ethernet. This is done with a technology demonstrator constructed with Commercial Off The Shelf (COTS) hardware. The physical medium is not the standard Ethernet but the PoE. However, we do not show live powering ON/OFF of the devices on the network. Such a study is beyond the scope of this write-up.

2.1 An overview of the protocols

The ECSS SpaceWire specification is defined within the ECSS-E-ST-50-12C Rev. 1 Standard [7]. The rationale behind SpaceWire was to standardise the proprietary and ad hoc approach adopted by space equipment manufacturers for onboard data handling and communications. SpaceWire mandates the use of layers of the Open Systems Interconnection (OSI) concept, notably the physical, datalink, network, and application layers. A SpaceWire network facilitates telemetry, telecommand and payload/science data transfers to mass memory and provides interfaces to units on standard interfaces such as CAN [8].

The IEEE 802.3 Standard [9] is an international standard for local and metropolitan area networks, employing Carrier Sense Multiple Access/Collision Detection (CSMA/CD) and the Ethernet protocol for data communication. The Ethernet protocol implements the physical and datalink layer for data communications and the sublayers Media Access Control (MAC) and Logical Link Controller (LLC) make up the datalink layer of the OSI reference model.

The IEEE 802.3 standard defines the distribution of power over an Ethernet-based network, in addition to data transmission within a network. The latest PoE capability is stipulated through IEEE 802.3bt [10] utilising the 4-pair twisted pair cabling that has been qualified to be used within the standard. A PoE system comprises three elements, these are power supply defined as the Power Sourcing Equipment (PSE), the powered load defined as the Powered Device (PD) and twisted-pair cabling connecting the two devices. This functionality is illustrated in Fig. 1. There are up to 8 classes of power configurations. The PD may request any class of power from the PSE ranging from 4 to 90 W.

Fig. 1
figure 1

source over twisted pair

IEEE Ethernet PoE concept for powering a device from a

Full size image

2.2 Related research

Modularity has been sought after for a long time in spacecraft systems [11]. The majority of schemes have remained restricted and proprietary to the spacecraft bus manufacturers who attempt to achieve reconfigurable and reusable platforms accommodating a variety of payloads. US Air Force’s plug and play satellite PnPSat-1 [12] was the most recent notable effort. Concerning the communication aspect of modularity in the commercial and interplanetary missions, SpaceWire has flown on BepiColombo [13], Astro-H [14], Geostationary Operational Satellite R series [15] and several other missions. Ethernet has been considered for on-board communications [16] as well. For terrestrial applications, PoE is an established concept. However, in the space sector, this idea is still relatively new and therefore significant literature is lacking. The SpaceWire concept is well-accepted though. Within the community of interest for SpaceWire applications, there have been studies on how it can be more efficient. These studies include broader quality of services such as:

  1. i.

    Distribution of SpaceWire time codes for spacecraft synchronisation [17].

  2. ii.

    Synchronisation of SpaceWire interrupt codes delivery in onboard networks [18].

  3. iii.

    SpaceWire network management and discovery [19].

The implementation of transmitting SpaceWire packets over Ethernet has been investigated in literature [20, 21] identifying the methods, limitations, and issues that arise. The overarching issue is the limitation of the format of the Ethernet frame containing a fixed-sized header, payload, and error checking sections that in some scenarios are inefficient. SpaceWire packets, in principle, can have infinitely long payload sizes whereas Ethernet can only transmit a fixed length of between 46 and 1500 bytes. Therefore, it can be recognised that for SpaceWire payloads larger than 1500 bytes further processing within the network layer is required to re-build segmented data payloads.

The constraint of Ethernet frames also requires further processing to determine the SpaceWire datatype that is contained within the Ethernet payload, including N-Char data and broadcast codes which consist of time codes and interrupt codes. An interpretation of how this can be implemented is given in [22]. According to that illustration, the necessary artificial headers are inserted to allow the identification and size of the SpaceWire data being sent, and subsequently how this is handled within the receiving element via further processing.

The requirement of further SpaceWire headers to be inserted within the Ethernet frame resultantly has a detrimental impact on the efficiency of the communications link. Rozanov and Yablokov [21] conducted studies and depicted graphically the relationship between the number of bytes sent for the payload for both the Ethernet and SpaceWire protocols. They showed that the viability of the Ethernet protocol is only applicable where payloads of more than 30–40 bytes are transmitted per packet. Therefore, for the implementation of the combined SpaceWire and Ethernet protocol, this characteristic must be considered for the intended use case of spacecraft intercommunication.

3 SpaceWire PoE protocol stack

3.1 Full protocol stack proposal

The implementation of an integrated SpaceWire PoE protocol stack was identified by reviewing the existing layers of the Ethernet and SpaceWire protocols. Considering the OSI model, the full protocol stack can be described at a high level as shown in Table 1; the datalink and physical layer would be achieved by utilising the Ethernet protocol, and the network layer of the SpaceWire protocol. Additional layers of the OSI model, namely the application, presentation, transport and session layers are not required for the operation of the SpaceWire PoE protocol. The application and presentation layers were utilised for the development and functional testing of the SpaceWire PoE concept demonstrator only.

Table 1 High-level functional description of the SpaceWire PoE protocol stack
Full size table

3.2 Network layer implementation

The network layer of the SpaceWire PoE protocol stack is responsible for the formatting of the individual Ethernet frames. It was identified that further processing is required for the transmission of SpaceWire packets within Ethernet frames. Therefore, an artificial header one byte in size has been added within the payload of the Ethernet frame to address the type of data between an N-Char and control code as required in the SpaceWire protocol. Artificial headers and their respective values and meaning for the proposed SpaceWire PoE protocol stack are shown in Table 2. The table details the SpaceWire protocol value of how the packet is identified, the SpaceWire PoE adopted byte value and the functional description of each artificial header byte.

Table 2 Artificial header bytes for SpaceWire PoE protocol
Full size table

Figure 2 diagrammatically shows the proposed packet format for the SpaceWire PoE protocol. The coloured elements show the origin of the header requirements for the packet from each protocol. The proposed packet format is for the use case of transmitting N-Char data, where the minimum amount of data that can be sent is 0 bytes (46 bytes with padding) and a maximum of 1498 bytes per packet to meet the requirements of the Ethernet frame.

Fig. 2
figure 2

SpaceWire PoE implemented packet format

Full size image

Sending one SpaceWire packet per Ethernet frame is not the most efficient method of transmission, therefore, multiple SpaceWire packets with the appropriate header byte and EOP marker can be inserted into the Ethernet payload section. Further processing is required at the network level to separate the received frame into the individual SpaceWire packets transmitted.

3.3 Datalink and physical layer implementation

The datalink of the SpaceWire PoE protocol is responsible for the communications link, encoding of SpaceWire packets from the network layer, decoding of incoming bitstream from the physical layer and directing Ethernet frames to the MAC destination address. The physical layer of the SpaceWire PoE protocol is responsible for the driving and receiving of bitstream data signals over the physical medium. The datalink and physical layers can be implemented by a system deploying an Ethernet MAC interface and PHY driver compliant with IEEE 802.3 2008 [9].

4 SpaceWire PoE concept demonstrator system

4.1 System definition and use case

To verify the proposed implementation of the SpaceWire PoE protocol, the concept demonstrator system was developed in accordance with the following use case, which was defined in collaboration with space industry subject matter expert Thales Alenia Space UK, who are contributing towards project MOSAR.

“The use of a SpaceWire PoE common-architecture to switch ON and OFF nodes of the mission system, negotiate the demand upon the request of power if the node can supply then transfer the maximum power. The SpaceWire PoE common architecture will also be used to distribute SpaceWire packets within the mission system between nodes.”

To enable a rapid development lifecycle and due to the pandemic restrictions at the time this work was conducted, the technical scope of the concept demonstrator system was defined as below.

  1. i.

    Functional testing shall prove the capability only through qualitative criteria of incorporating the SpaceWire network layer into the Ethernet PoE protocol.

  2. ii.

    Functional testing shall be conducted with available COTS.

  3. iii.

    SpaceWire PoE network shall only consist of an end-to-end link (no routing switches).

4.2 System requirements

From the proposed SpaceWire PoE full protocol stack defined in Table 1 and the given use case, the requirements of the concept demonstrator system were elicited into a system requirements document (SRD) (Supplementary Annex A). The approach adopted was for the SpaceWire protocol requirements to be extracted for the network, datalink and physical layers; thereafter an analysis was conducted to assess the level of compliance that the proposed implementation of the SpaceWire PoE protocol stack would achieve in accordance with the SpaceWire protocol. Analysing the requirements from this perspective allowed for it to be evident where the Ethernet layers of the SpaceWire PoE protocol did not satisfy SpaceWire and what issues would be present if introduced into a SpaceWire network. The requirements of the SRD were defined as either threshold or objective. The threshold requirements were considered for the minimum level of compliance with the SpaceWire protocol. The objective requirements were defined as optional in the SpaceWire protocol and do not need to be implemented for the operation of SpaceWire PoE.

4.3 System hardware development

The datalink and physical layers of the SpaceWire PoE protocol for the concept demonstrator system were achieved by the integration of suitable hardware. To best replicate the typical topology of a spacecraft mission system that exploits a SpaceWire network and how it is utilised as a method of communication between mission subsystems, the system architecture of the concept demonstrator was designed as shown in Fig. 3. The SRD (Supplementary Annex A) defined the hardware requirements of each subsystem of the concept demonstrator system to achieve the given use case. Subsequently, the appropriate COTS equipment is described below.

  1. i.

    Master and slave node: Espressif Systems ESP32-Ethernet-Kit-V1.1.

  2. ii.

    PoE network router: Tenda desktop switch with 4-port PoE.

  3. iii.

    Cable: IEEE 802.3 CAT6 Ethernet.

Fig. 3
figure 3

Concept demonstrator physical system architecture

Full size image

4.4 System software development

The network layer of the SpaceWire PoE protocol was achieved by the implementation of bespoke software in the master and slave Ethernet nodes. The use of unified modelling language (UML) diagrams (Supplementary Annex B) supported the design and verification of the concept demonstrator software. These diagrams enabled the high-level software architecture to achieve the required functionality. The UML use case diagram of the concept demonstrator is shown in Fig. 4, identifying the primary actors in the system and required functionalities.

Fig. 4
figure 4

SpaceWire PoE UML use case diagram

Full size image

The scope of the sequence and state UML diagram only considers the transmission and receiving of SpaceWire packets between the master and slave Ethernet nodes. This is due to the fact that the PoE functionality is handled passively by the COTS hardware. The sequence diagram illustrates the software functions to be invoked for sending (red box in Fig. 5) and sending and receiving (yellow box in Fig. 5) of SpaceWire packets between nodes. The state diagram was generated to depict the different states of the master and slave nodes for the given use case and what event-driven actions would occur in software during the receiving and transmission of SpaceWire packets.

Fig. 5
figure 5

SpaceWire PoE concept demonstrator system

Full size image

4.5 Hardware and software integration

The hardware and software components of the concept demonstrator were integrated using built-in drivers and libraries within the ESP-IDF for the ESP32 development board, which could be flashed with the bespoke source code to enable SpaceWire PoE protocol functionality. The Ethernet network switch is IEEE 802.3at compliant, therefore, no additional firmware/software was required for its integration into the system. The whole realisation of the concept demonstrator system is shown in Fig. 5.

4.6 Concept demonstrator functional testing and analysis

Functional testing was conducted to validate the concept demonstrator system requirements had been met as specified within the SRD (Supplementary Annex A). Test cases were generated considering the SRD. The test cases were only generated for the network layer of the SpaceWire PoE protocol stack as compliance to the datalink and physical layers were achieved by the already IEEE 802.3 PoE standard compliant hardware.

The system was configured as shown in Fig. 3 for each test case. The arrows represent the connections between the components of the system, solid arrows being physical, and dashed wireless. The purpose of introducing the wireless element was to demonstrate that the system could function in isolation from other external power sources and to assure confidence that the only power being supplied to the master and Ethernet nodes was by the PoE. The WiFi client/server terminal window (PuTTY) allowed for the test data to be extracted during testing.

The system passed all 4 of the test cases, although full compliance with the system requirements was not achieved. The partial compliances were due to the lack of SpaceWire time code registers implemented in the slave and master nodes to hold the time value at a system level. Further development is needed for full compliance. The achieved compliance against the system requirements is documented in the SRD (Supplementary Annex A). The functional testing conducted demonstrates the full functionality of the concept demonstrator; a system with an implemented SpaceWire PoE full protocol stack that provides electrical power and communications.

5 SpaceWire PoE performance analysis

Theoretical assessments have been conducted on the SpaceWire PoE system to quantitively measure the performance between the SpaceWire, Ethernet and SpaceWire PoE protocols.

5.1 Transmission efficiency

Figure 6 shows the efficiency of the SpaceWire PoE system and related protocols in terms of the ratio of payload (SpaceWire) data per frame/packet in the scenario of sending one SpaceWire packet with a payload containing N-Char data in the range of 1–1498 bytes. The efficiency shown for each protocol is in the context of the packets/frames being implemented for an end-to-end link (no logical/path addressing for SpaceWire required).

Fig. 6
figure 6

SpaceWire PoE, SpaceWire, Ethernet frame and payload comparison

Full size image

It can be observed that the SpaceWire protocol is efficient for the transmission of smaller data payloads. The Ethernet protocol requires a minimum of 64 bytes to be transmitted even for smaller payloads and the inflection point on the graph signifies this change, therefore being less efficient in the range of sending between 0 and 46 bytes. The SpaceWire PoE protocol is only minimally less efficient than the Ethernet protocol in the range of 40–400 bytes due to the total header size of the frame being larger by 2 bytes for the header-byte and EOP marker, which eventually converges with the Ethernet protocol over 400 bytes where the difference in efficiency can be deemed negligible. The graph reinforces the assessment made within the SpaceWire community of interest, stating the efficiency losses when utilising Ethernet for transmission of SpaceWire data.

The maximum and minimum efficiencies of transmission are calculated using Eqs. 1 and 2. Equation 1 is used for SpaceWire packet lengths under or equal to 46 bytes, and Eq. 2 for SpaceWire packet lengths over 46 bytes.

$$\eta = 100\left(\frac{{L}_{SpW}-{L}_{SH}}{{L}_{eth}}\right)$$
(1)
$$\eta = 100\left(\frac{{L}_{SpW}-{L}_{SH}}{{L}_{EH}+ {L}_{SpW}}\right)$$
(2)

\(\eta\) is the efficiency (%), \({L}_{SpW}\) is the length of SpaceWire packet (bytes), \({L}_{eth}\) is the minimum length of Ethernet frame (bytes), \({L}_{EH}\) is the length of Ethernet frame headers (bytes), \({L}_{SH}\) is the length of SpaceWire PoE headers (bytes).

Table 3 shows the values used to derive the theoretical maximum and minimum efficiencies that the SpaceWire PoE protocol could achieve. Depending on the payload size performance can be \(1.5 \le \eta \le 98.7\).

Table 3 SpaceWire PoE maximum and minimum transmission efficiencies
Full size table

For more efficient use of the Ethernet frames implemented by the SpaceWire PoE protocol, multiple SpaceWire packets can be inserted per Ethernet frame. In the instance of multiple SpaceWire packets inserted into the Ethernet frame of varying length and type (N-Char or C-Code), the efficiency cannot be assumed to increase in a linear behaviour similar to that demonstrated in Fig. 6. To simulate the volatility of transmission efficiency for SpaceWire packets sent within an Ethernet frame, we randomised the length of the Ethernet frame payload and subsequently the length of each SpaceWire packet to be inserted within the frame.

The results shown in Fig. 7 are split into two datasets for comparison, that being the size of the SpaceWire packets being inserted into the Ethernet frames are between the ranges of 1–1498 bytes for the top plot and 1–250 bytes for the bottom plot. This was to demonstrate the disparity in efficiency depending on the use case for the SpaceWire PoE protocol in relation to sending larger packets for science data or sending smaller packets for telemetry data.

Fig. 7
figure 7

Ethernet frame transmission efficiency for carrying multiple SpaceWire packets

Full size image

For both plots, it can be observed that for SpaceWire data under or equal to 44 bytes the variance in efficiency is significant with no correlation with the number of packets sent. The use case of sending larger packets of SpaceWire data (1–1498 bytes) results in an efficiency nominally between 90 and 100%. This is due to the requirement of fewer header bytes and EOP markers within the frame, increasing the ratio of SpaceWire data to the total frame length. Achieving an equivalent efficiency of nominally between 90 and 100% for smaller packet sizes is achieved when ten or more are inserted into the Ethernet frame. This analysis helps assess the suitability of the SpaceWire PoE protocol for the individual use cases performing at a baseline efficiency.

The random nature of the data being generated for the plots cannot be visualised at the specific points of interest for the change of rate of efficiency, particularly the inflection point shown in Fig. 6.

5.2 Bandwidth

The maximum bandwidth that can be achieved in the link of each protocol is derived using Eqs. 3 and 4. The link speed was benchmarked at 100 Mb/s for all protocols. It is to be noted that SpaceWire is capable of link speeds of between 2 and 200 Mb/s and up to 400 + in specific cases.

$${P}_{n}= \frac{{L}_{s}}{{P}_{s} B}$$
(3)
$$BW={P}_{n} {P}_{S} B$$
(4)

\({P}_{n}\) is the No. of packets per second (Ns−1), \({L}_{s}\) is the Link speed (Mb/s), \({P}_{s}\) is the Size of packet (Bytes), \(B\) is the Size of byte (Bits), \(BW\) is the Bandwidth (Mb/s).

The maximum data rate achieved by each protocol is shown in Tables 4 and 5. In theory, SpaceWire packets (payload size) can be of infinite length. Therefore, to allow appropriate comparison with other protocols the payload size, Ps, for SpaceWire was defined to match the throughput of Ethernet and SpaceWire PoE at 100 Mb/s. In the context of the maximum utilisation of the bandwidth, SpaceWire is faster and subsequently more efficient by a margin of 1.81% in comparison to standard Ethernet. The margin would increase linearly as the speed of the SpaceWire link is increased.

Table 4 Packets and frames rates of Ethernet, SpaceWire and SpaceWire PoE
Full size table
Table 5 Bandwidth comparison of Ethernet, SpaceWire and SpaceWire PoE
Full size table

5.3 Power consumption

The total amount of power to transmit and receive SpaceWire data via the SpaceWire PoE protocol can be estimated from the use of the measured energy consumption determined in [22] which states the estimated power or energy consumption of the operation of an Ethernet network and the transmission of Ethernet packets over a network. The energy values used for further analysis of power consumption are shown in Table 6.

Table 6 Estimated power and energy consumption of Ethernet
Full size table

The total amount of power to process an Ethernet packet can be approximated using Eq. 5 and Pn being 8127. The value of 1.6 mW can be an underestimate due to this calculation considering the least number of packets sent per second, therefore, for high traffic consisting of small payloads this value could increase. The determined energy value of per-packet processing energy (Table 6) includes the processing of IP headers which does not apply to SpaceWire PoE protocol, although SpaceWire PoE protocol contains more bytes as headers for processing the data, especially in the instance of multiple SpaceWire packets within an Ethernet frame. Therefore, the mentioned value is an acceptable approximation for these theoretical calculations.

$${P}_{p}\approx \frac{{E}_{p}{P}_{n}}{t} \approx \frac{197.2 \times 8127}{1}\approx 1.6 mW$$
(5)

\({P}_{p}\) is the total power to process packets (mW), \({E}_{p}\) is the per packet processing energy (nJ), \({P}_{n}\) is the total no. of packets per second (Ns−1), \(t\) is the total time (s).

The amount of energy required for the entire lifecycle of an Ethernet byte is shown in Eq. 6. The definitions of the constants are given in Table 6.

$${E}_{b}=\left({E}_{rx}+{E}_{rs}\right)+\left({E}_{tx}+{E}_{ts}\right)$$
(6)

To derive the estimated maximum total power for the transmission of Ethernet bytes, Eq. 7 was used with Pn being 8127, to convert the given energy value to power consumption for the maximum number of bytes per second for a link speed of 100 Mb/s.

$${P}_{b}\approx \frac{{E}_{b}{P}_{s}{P}_{n}}{t}\approx \frac{3.4 \times {10}^{-9} \times 1500 \times 8127}{1}\approx 41.45mW$$
(7)

\({P}_{b}\) is the total power of bytes (mW), \({E}_{b}\) is the energy per byte (nJ), \({P}_{s}\) is the packet payload Size, \({P}_{n}\) is the packets per second (Ns−1), \(t\) is the total time (s).

From the derived power values for the processing and transmission of Ethernet data, the total maximum power consumption for a SpaceWire PoE enabled system can be expressed with Eq. 8.

$${P}_{T}\approx {{{P}_{C}+NP}_{E}+N(P}_{p}+{P}_{b})$$
(8)

\({P}_{T}\) is the total power consumption (W), \({P}_{C}\) is the power consumption of power sourcing equipment (W), \({P}_{p}\) is the total power to process packets (W), \({P}_{E}\) is the power consumed by Ethernet port (W), \({P}_{b}\) is the total power of bytes (W), \(N\) is the no. of Ethernet nodes in the system.

Table 6 shows the approximated total maximum power consumption of the implemented concept demonstrator system for varying data rates. The value of PC used is an estimate from the use of the electrical specifications of the power supply for the Ethernet network switch. The values of Pp and Pb are adjusted by a factor of 10 to consider the change in energy consumption due to the increase or decrease in time to transmit and receive a byte or process a packet for the data rates of 10 Mb/s and 1000 Mb/s. The number of nodes, N, reflects that the PSE shall be providing power to two nodes (master and slave). The power consumption of the embedded system has not been considered in this calculation, although it is assumed to be of negligible impact for these approximations.

The results from Table 7 are graphically presented in Fig. 8. It can be observed that the power consumption to establish and maintain the Ethernet link is responsible for much of the power consumption and the transmission of SpaceWire data is only minimal in comparison (shown on top of bar). The variance of data rates complements the findings in the supporting study [22] that the higher the data rate the higher the total power consumption.

Table 7 Total estimated power consumption for SpaceWire PoE protocol
Full size table
Fig. 8
figure 8

Estimated power consumption of concept demonstrator

Full size image

6 Implementation issues

The following key issues have been identified that require to be addressed to further the technology readiness level of the SpaceWire PoE protocol.

6.1 Efficiency volatility

The volatility in efficiency demonstrated in Fig. 8 is due to the insertion of artificial header bytes to distinguish the type of data being sent (N-Char or C-Code). The SpaceWire PoE system is not optimal for space system architectures that only require the transmission of SpaceWire data that consists of nominally smaller-sized packets or control codes that do not utilise the full length of an Ethernet frame. The SpaceWire PoE protocol is best utilised for sending larger-sized packets, that make full use of the Ethernet frame size or use multiple Ethernet frames to send packets that are larger than 1498 bytes. This functionality can be achieved with further development of the proposed SpaceWire on PoE protocol to include additional header bytes and flags for segmentation and building packets larger than 1498 bytes.

The SpaceWire PoE protocol for smaller packets can still be viable if the overall efficiency of the mission system is improved. For example, the adoption of a SpaceWire PoE mission system architecture loses efficiency in data transmission, although weight savings from reduced cabling eliminate the efficiency offsets.

6.2 IEEE 802.3 PoE functionality

During the development of the concept demonstrator, it was recognised there is an inability to access the PoE functionalities of COTS products to be optimised to the space industry use case. The nature of how PoE is currently applied in terrestrial applications is that it is introduced as a passive element where the power identification and control management are achieved through application specific integrated chips (ASIC) in COTS solutions. Therefore, for the implementation of a SpaceWire PoE system further development would be required to understand and implement how the PoE function can be optimised to perform as desired in accordance with the given use case to turn ON and OFF Ethernet nodes when required.

6.3 Detection and feedback of errors

The handling of error detection is processed in the data link layer of the SpaceWire PoE protocol. If an error is to occur, i.e. the cyclic redundancy check (CRC) is wrong, currently there is no capability to isolate whether the error occurred in the link or data. Therefore, no EEP marker (header-byte) is placed in the SpaceWire packet. For SpaceWire data that is larger than an Ethernet frame in size, this will need to be investigated as to how packets are recovered in the event of errors, although it could be determined that the CRC check is sufficient.

7 Future work

To progress the technology readiness level and validity for the deployment of a SpaceWire PoE system architecture in future spacecraft systems, the following areas of future work have been identified.

7.1 IEEE 802.3 PoE bespoke implementation

Further development is required by the concept demonstrator to evidence a bespoke implementation of the PoE functionality. This is primarily to enable and disable Ethernet nodes when required for the transmission of SpaceWire data as described by the use case.

7.2 Network discovery and configuration

To support the development of modular spacecraft design embodied by project MOSAR, further research and testing are to be conducted to determine how a SpaceWire PoE protocol enabled system performs under a changing network topology. This could be the detection, link, and transmission of data to a changing network consisting of Ethernet nodes and how this is managed by the system. Research in this area would directly support the current literature that is being generated by the community of interest, which contributes towards the synchronisation and harmonisation of modular spacecraft mission subsystems.

7.3 Interoperability to legacy SpaceWire and new SpaceFibre equipment

For terrestrial applications, PoE has shown promising interoperability [23]. For space applications, it is to be considered that the adoption of the new SpaceWire over PoE communications protocol within a spacecraft architecture may be interoperable with legacy systems that have adopted solely the SpaceWire communication and not for power transfer. The SpaceWire state machine is required to handle equipment that was developed for a previous standard of SpaceWire. If the receiver node is disabled, the ErrorReset state is entered. The plug and play MOSAR spacecraft units may encounter any connection problem which will be handled in an appropriate state such as disable/enable, link start and autostart. The link initialisation behaviour is time-dependent on the clock frequency. The advanced network behaviour aspects such as link error handling and recovery, timeouts and resetting will be implemented in the future as receiver nodes are added to the network. A further aspect is an implementation of fault detection, isolation and recovery routine which is critical to the plug and play MOSAR spacecraft. A legacy routing switch may encounter addressing problems as the network grows since the paths will require adaptive routing. Non-deterministic path addressing could lead to nodes being undiscoverable, inaccessible, stuck in an error state, inaccurate routing map or network unreliability. Beyond this, power demand/supply negotiation will take place for one of the eight classes.

A study is needed that ascertains if and how a system that has adopted the SpaceWire protocol can operate with the proposed SpaceWire PoE protocol. This will require analysis of the physical, datalink, and network layers similar to that conducted in the present work, except working in the reverse order. Such work could look to mitigate the potential interoperability issues.

The SpaceFibre standard [24] is backwards compatible with SpaceWire. Any equipment designed for SpaceWire over PoE would be able to handle data to/from SpaceFibre equipment. The SpaceFibre equipment must have its powering source. The other limitation of SpaceFibre is the 5 m electrical wire length which is kept short for high throughput data interfaces such as for imaging or scientific instruments.

7.4 Network layer refinement

The implementation of the network layer can be improved. The current implementation uses artificial headers that are one byte in size to distinguish different types of packets and the required SpaceWire markers such as the EOP and EPP. Further work can seek to refine the currently proposed protocol to reduce the overhead and/or increase the usefulness of the bytes sent within the Ethernet frame. Artificial header bytes for the SpaceWire PoE protocol could include single and/or multi-bit signifiers for type, packet number, length for more error resistant and efficient transmissions.

8 Conclusion and recommendations

Radiation-tolerant SpaceWire hardware is commercially available [25] and mechanical load, thermal and gamma dose tests have been reported for SpaceFibre [26]. However, the current readiness level of the SpaceWire over PoE technology is low for practical use in a mission especially considering the required ruggedness for the space environment. The present work aims to hash out the functionality of the SpaceWire communication on the Ethernet stack COTS equipment. The present findings are not exhaustive by any measure. A fully grown communications network remains to be tested after which device powering and power demand negotiation will be carried out. Once achieved a proper road map would require developing custom hardware and software in FPGA or ASIC and subjecting it to space qualification.

A SpaceWire PoE protocol concept demonstrator was developed and evaluated by functional testing and supported by a theoretical assessment of the performance of the proposed SpaceWire PoE protocol. The functional testing confirmed that a combined SpaceWire and Ethernet protocol stack can be implemented on COTS PoE hardware to achieve communications and power delivery between nodes on a shared physical medium. Theoretical analysis has quantified the degradation of efficiency in communications and estimated power consumption of a SpaceWire PoE enabled system. Implementation issues and future work were identified that will better inform the validity of SpaceWire PoE protocol deployed on spacecraft, for subsystems intercommunications and power distribution achieved through a singular architecture.

From this study, some recommendations can be made to further assess the validity of the SpaceWire over Ethernet in a PoE environment. The implementation of the SpaceWire PoE protocol is dependable on the wider sustainability and savings that are made on the intended spacecraft or mission system. Suitable engineering judgement should be made on the overall gain of implementing a singular system architecture for the transmission of data and distribution of power, where the potential savings of mass in cables, reusable resources and reduction in maintenance outweigh that of the loss in efficiency of not solely using SpaceWire network architecture. Various network topologies also need to be investigated for SpaceWire over PoE protocol as the network extends when the nodes come online or go away or are not detectable for example due to a corrupt routing table or addressing problem.

Once the communication matters are settled and the network performance is acceptable, the next step would be to implement the powering sequence feature to switch spacecraft units ON/OFF by querying the power demand of different units, negotiating, approving or denying the power or switching the units OFF upon malfunction.