CC BY
19
ОБРАБОТКА ИНФОРМАЦИИ И УПРАВЛЕНИЕ /
udc 004.057.4 Articles
doi:10.31799/1684-8853-2021-1-8-16
Analysis of requirements for modern spacecraft onboard network protocols
V. L. Oleneva, PhD, Tech., Associate Professor, orcid.org/0000-0002-1817-2754, Valentin.Olenev@guap.ru aSaint-Petersburg State University of Aerospace Instrumentation, 67, B. Morskaia St., 190000, Saint-Petersburg, Russian Federation
Introduction: New technologies are replacing the onboard space networks based on bus topologies. One of these technologies is SpaceWire. New communication protocols are being developed, expanding SpaceWire functionality. The protocol developers should provide all the required technical characteristics for data transmission and processing. Purpose: New technologies are replacing the onboard space networks based on bus topologies. One of these technologies is SpaceWire. New communication protocols are being developed, expanding SpaceWire functionality. The protocol developers should provide all the required technical characteristics for data transmission and processing. Results: The analysis of the existing demands on communication protocols resulted in a set of consolidated requirements for the physical-network layers' protocols and the transport layer protocols. The requirements cover the speed, latencies, transmission distance, transmitted information amount, fault detection functionality, time synchronization between the devices, quality of service, main user data types, and data transfer modes at the transport level. The existing SpaceWire protocols are defined as a special class of protocols, possessing unique characteristics. Practical relevance: The performed analysis can simplify the implementation of new onboard communication protocols and provide a required level of technique for new generation spacecraft.
Keywords — onboard networks, communication protocols, technical requirements, SpaceWire.
For citation: Olenev V. L. Analysis of requirements for modern spacecraft onboard network protocols. Informatsionno-upravliaiushchie sistemy [Information and Control Systems], 2021, no. 1, pp. 8-16. doi:10.31799/1684-8853-2021-1-8-16
Introduction
Communication technologies for onboard communication networks are rapidly developing. New standards and protocols, new principles and mechanisms of data transmission, new equipment that implement these mechanisms and protocols appear [1, 2]. The MIL-STD 1553 [3] bus has been used for data exchange in onboard systems since the 1970s, but the rapidly growing requirements for the functionality of spacecraft make its further use impossible. As a result, network topologies are replacing the buses according to the demands of the leading industrial companies. One of such technologies is SpaceWire.
Open standard ECSS-E-50-12C (SpaceWire protocol) was specifically developed for space applications, so it has a low implementation cost and complexity, high performance, and flexible architecture [4]. SpaceWire met all the requirements for aerospace applications [5, 6] and has become the dominant technology used for small sized spacecraft, landing modules, etc. [7, 8]. Later, the SpaceWire protocol was supplemented with the GigaSpaceWire protocol [9], which provides gigabit speeds, and in 2019, the next-generation standard ECSS-E-ST-50-11C (SpaceFibre protocol) was released [10]. However, currently SpaceWire remains the main protocol used in real missions.
The SpaceWire, GigaSpaceWire, and SpaceFibre protocol specifications cover the OSI model layers
from physical to network, and a number of transport protocols with different functionality and complexity have been developed. These transport protocols greatly extend the functionality of SpaceWire family protocols. Transport protocols were developed for SpaceWire, but due to compatibility at the network level, they can be used for GigaSpaceWire and SpaceFibre. An analysis of the existing transport protocols is given in the article [11]; [12] provides a detailed overview and comparison of the standards ECSS-E-ST-50-52C (RMAP), ECSS-S-ST-50-53C (CPTP), SMCS-ASTD-PS-001 (STUP), and the protocols STP [13] and JRDDP [14]. Overview shows that these transport layer protocols are not sufficient to provide different types of quality of service, reliable data delivery, and configuration flexibility. Therefore, the transport layer protocols continue to be improved within the missions of various space agencies. One such development by JAXA is the SpaceWire-R protocol [15], which introduced guaranteed data delivery and transport connections. ESA introduced the SpaceWire-D protocol [16], which for the first time introduced deterministic data delivery in the SpaceWire network [17]. For Russian spacecraft using SpaceWire networks, the STP-ISS protocol was created [18]. By that time STP-ISS provided the necessary transport-level mechanisms for the Russian industry. However, the requirements for on-board networks are changing as the technical capabilities for implementing different protocols.
The urgent remaining task is to form a consolidated set of requirements for communication protocols for onboard space networks it will further allow analyzing existing technologies for compliance and setting tasks for improving existing data transmission standards. Thus, current paper will consider the existing requirements for communication protocols. Based on this analysis, a set of consolidated requirements for the onboard space protocols will be derived. In addition, paper will show that the SpaceWire family protocols satisfies these requirements. The requirements for protocols presented in the article available in open sources, are collected from leading companies of space industry, space industry experts, real developers of onboard space equipment.
Overview of communication protocol requirements
The SpaceWire family of protocols can be divided into two main categories — these are protocols that describe the OSI (Open Systems Interconnection) layers from physical to network: SpaceWire, GigaSpaceWire and SpaceFibre, and many transport layer protocols that provide various end-to-end functionality (Fig. 1). Requirements for protocols at different layers of the OSI model will also differ and will be grouped into network-physical layer protocols and transport layer protocols.
A survey of experts from the Russian space industry conducted on the technical requirements for
communication protocols of the network-physical layers and the streaming service of the transport layer showed the following. Data packets should not be delivered to the wrong destination or filtered in the receiver. The network should be free of deadlocks, so packets that cannot reach the destination within a given fixed time should be dropped. The required Quality of Service (QoS) is guaranteed delivery, guaranteed bandwidth, multiple levels of priority (from fore to six). The network should provide reliable time synchronization — incorrect time stamps and interrupt codes should not be delivered to recipients. It should be possible to transfer high-speed data streams (for example, video streams) over separate virtual connections, while other traffic should continue to be transmitted over other connections.
In terms of the streaming data transmission (for example, video data), separate requirements were presented. It takes into account the features of the industry standards ARINC-818-2 and CCSDS 766.1-B-1, the characteristics of streaming video. A relatively constant rate of data entry into the network should be ensured. It could be achieved by limiting the maximum size and intensity of packet transmission to the network throughout the entire information exchange session. An important characteristic of streaming traffic is also the low latency for transmitting real-time streaming data. Therefore, protocols with the transport connection establishment should be used, which will reduce the length of the header of packets containing useful data. It is also preferable to use a simple data delivery mechanism implemented in hardware. It should be done to
Application layer
Multiple applications
i
Transport layer
RMAP
№TP
SpW-R
SpW-D
JRDDP
Network layer
Physical layer
SpaceWire
Network
Ö Data-Link
B ^ sg «
« £ Encoding
Physical
GigaSpaceWire
Network
Packet
Exchange
Symbol
Encoding
Physical
SpaceFibre
Network
Data-Link
Multi-Lane
Lane
Physical
■ Fig. 1. SpaceWire/SpaceFibre standards family
have a mode without buffering on the transmitter and receiver, with packet delivery without acknowledgements and resending. It is important to control the delivery of data to the receiver: checking the correctness of the packet header and the pay-load field; detection of the erroneous packets, lost packets and packets reordering. The new protocols should be compatible with SpaceWire\SpaceFibre networks [19, 20].
Another source of requirements is the comparison of communication architectures given in [21]. It contains the following NASA requirements for a rigid real-time distributed control system for mission-critical security systems on a manned spacecraft. The first parameter is high reliability and high accessibility. The use of modular components at all levels to ensure high reusability, flexibility and scalability. These components should support Plug & Play technology and, if possible, perform hot-swapping. The Plug & Play technology for SpaceWire has several implementations adapted to the requirements of various space agencies, and is successfully developing [22, 23]. Comprehensive functionality for fault detection, isolation and recovery (FDIR) and health monitoring should be provided. It is also noted that the ability to transmit large amounts of data at extremely high speeds is not mandatory. Most control circuits operate at a frequency of 100 Hz or less. For example, the space shuttle main engine controller operates at 50 Hz, and the flight control loop in the space shuttle computers operates at 25 Hz.
G. Kopets in his book [24] provides a set of requirements for the communication infrastructure of distributed real-time systems. The first group of requirements relates to temporary properties. The message transfer delay should be as low as possible to minimize the idle time of the control commands. It is necessary to ensure a minimum jitter, that is, the difference between the worst-case message latency and the best-case message latency. In such systems, it is necessary to have a global time value for all network nodes with proper accuracy (time synchronization). A reliable time synchronization algorithm should set the internal time of the network nodes so close to each other that the amount of time discrepancy during the offline operation does not exceed the specified accuracy interval. A fault-tolerant time synchronization algorithm should allow the specified number of errors in the network. Such a requirement in SpaceWire networks is represented by a mechanism for sending of high-priority timestamps, but time synchronization mechanisms are not described. They are represented at the transport layer, and only in the STP-ISS protocol [25].
The second group of requirements relates to error detection and recovery mechanisms. Reliability
of communication should be ensured through the use of reliable channel coding or algorithms based on broadcast. In systems that do not operate in real time, reliability can be achieved through retransmission. Mechanisms for control of the malfunction of components in time are needed. For example, the communication system should contain information on the permitted behavior of the component in time and can disable the component that violates the rules of operation (babbling idiots avoiding). Each network element should report about all component failures. It is necessary to use end-to-end confirmation of the success or failure of any action for any scenario. It is important to use mechanisms that ensure determinism. These requirements are fully taken into account in the second edition of the STP-ISS protocol, which provides determinism and mechanisms for detecting of duplicated control commands.
The last group of requirements covered in the book, which indirectly affects data transmission protocols, relates to the physical structure of a real-time communication system. This requirement is low cost and low weight of equipment.
Let us also consider the requirements of the Russian and European industry for communication protocols for on-board systems. Industrial companies within the framework of the FP7 Program SpaceWire-RT project [26] jointly elaborated this list of requirements.
To ensure timely data delivery, support of transmission rates of up to 20 Gbit/s for remote sensing missions, and speeds of up to 400 Mbit/s for low latency routing is required. The operation of the devices should be possible at a distance of up to 100 m for spacecraft applications, where equipment can be installed at a long distance. Additionally operation of the devices should be possible at a distance of 1 to 10 m for operation at high data rates between closely located equipment.
It is necessary to support the transmission of application messages with a size of at least 32 MB. Such packets are used to transmit raw data. Message sizes from 8 B to 64 KB should be supported to transmit commands and telemetry from application processes. In this case, the maximum latency for the transit of command packets over the network in real-time applications should be less than 100 ms. and for time synchronization packets up to 100 ns.
Protocols should provide capabilities for reliable delivery of important data that should be delivered without corruption. Determinism and configurable automatic confirmation for controlling non-intelligent devices and sensors should be provided. The protocols should provide mechanisms for automatic FDIR. At the same time, recovery could be implemented in most applications in soft-
ware. In some applications where short response times are hardly achievable, automatic recovery could be implemented at the network layer.
Time-critical commands require support for multi-path data transmission and support for multicast data transmission, for example, to deliver data to devices in a redundant system. The requirements states the need to support the transmission of timestamps.
The quality characteristics are given in a generalized table describing the support for communication requirements. Table 1 shows the main characteristics for each of the required traffic types.
Next, consider the requirements for the functionality of the onboard network from "Academician M. F. Reshetnev "Information Satellite System" within the framework of a joint project aimed at creating a modern transport protocol STP-ISS [15].
The maximum number of logical addresses specified in the corresponding protocol should determine the number of nodes in the network. From one to three logical addresses could be set for one network node. In accordance with the SpaceWire protocol, it is necessary to preserve the possibility of dividing the network into regions. The maximum number of logical addresses of a particular protocol should also determine the number of nodes in each region. When using path or regional-logical addressing, the number of transit switches in the network (or subnet) should be no more than 15.
From one to three units could represent each node of the onboard network. Each unit should have a separate logical address. Fig. 2 illustrates this requirement for a network node.
The requirements of "Academician M. F. Re-shetnev "Information Satellite System" are mostly focused on transport layer protocols, since the lower layer protocol (SpaceWire) has already been defined as a main protocol for future missions. The transport protocol is needed to provide transport services for onboard networks and should describe the data processing and exchange mechanisms, packet formats. It should transmit the following user data types from the transmitter application layer to the receiver application layer: control commands,
application messages, time-codes, interrupt signals and interrupt acknowledgements. Urgent packets and regular packets could represent application messages. The protocol itself should provide data transmission in two modes: connection oriented and connectionless.
Connection establishment is performed separately for each pair of receiver-transmitter remote network nodes (Fig. 3). The connection establishment initiator could be either an active or a passive device. Only one type of data should be transmitted over the transport connection. Control commands should not be transmitted in connection-oriented mode. The maximum number of transport connections for each node shall not exceed 8 connections in one direction. Within each transport connection, a flow control mechanism should be provided. Flow control means sending the information on the remaining free space in the receiving buffer to the transmitter of the transport connection.
In the connectionless mode, the segment of data transmitted to the transport protocol shall not be larger than 2048 B. Limit for the connection-oriented mode is 64 KB. If the size of the application message exceeds the maximum allowed size of the data segment, the application should perform segmentation of this message.
_Logical address Logical address
Unit A Unit B
■ Fig. 2. Logical addresses distribution for the network node unit
■ Table 1. Main characteristics for required classes of data
Class of data Distance Speed Latency Packet size Quality of service
Data Short and long From low to very high Not important Short to long Reserved bandwidth
Control commands Short and long Low Low Short to long Deterministic delivery
Telemetry Short and long Low Low Short Reserved bandwidth
Time stamps Short and long Low Very low Short High priority
Connection establishment Active device Passive device
1
r
Application Tr. protocol Tr. protocol Application
©
©
Connection closing
Active device
I-1
Application Tr. protocol
Connection"
closing
Passive device
I-
Tr. protocol
-1
Application
© ©
Connection closed
Connection
closed ,
■ Fig. 3. Example of transport connection establishment and closing mechanisms
Connection ciosed
©
©
The transport protocol should implement the following mechanisms for transmission errors detection: CRC check, validation of the packet data field length, confirmation of successful data reception, timeouts for detecting lost data packets. Data should be prioritized for different information flows (at least 3 priority levels for data packets and control commands). The transport protocol should contain a separate logical buffer for each priority data coming from the application layer.
Requirements for the provided quality of service for information flows should be provided in accordance with Table 2. Requirements for the data transmission latency are given for a data channel with transmission through 8 transit switches and transmission rates of 20 and 50 Mbit/s.
The column "Quality of service" states the following QoS types:
a) priority — higher priority data transmitted first;
b) scheduling — a single schedule is created for the whole network; transmitting nodes are allowed to send data according to this schedule. It is not managed in switches. Schedule is available in the local and remote nodes exchanging data, in the source and in the receiver (Fig. 4);
c) guaranteed delivery — confirmation of correct data delivery, re-sending by the source if there is no confirmation during the timeout (Fig. 5);
d) not-guaranteed delivery.
The scheduling quality of service should be carried out in accordance with the specified schedule. It is formed at the stage of the transport protocol configuration. At the same time, the protocol itself should be able to operate without the scheduling quality of service.
t
t
■ Table 2. Data streams' quality of service
Data type Length Generation frequency Delay, 20 (50) Mbps Quality of service Priority Confirmation
Control command 4 B > 1 ms < 1 (0.5) ms a, b, c 1 Yes
Urgent message 64 B > 0.5 ms < 1 (0.8) ms a, b, c 2 Yes
2 KB > 5 ms < 8 (5) ms
64 KB > 100 ms < 230 (150) ms
Regular message 64 B > 0.5 ms < 1.5 (1) ms a,b, c,d 3 Yes /No
2 KB > 5 ms < 10 (7) ms
64 KB > 100 ms < 300 (220) ms
Time-code 6 bit > 60 s < 0.1 ms a 0 No
Interrupt. interrupt acknowledge 5+1 bit > 5 ms < 0.1 ms a 0 Yes /No
Schedule
Processor
Memory
Onboard computer
■ Fig. 4. Example of data transmission scheduling for onboard networks
■ Fig. 5. Guaranteed quality of service example
The transport protocol should provide the further distribution for the time-codes and system interrupts from the local node application to the network. Similarly, the transport protocol should accept time-codes and system interrupts from the network and transmit them to the applications. The protocol could use the system time information from the time-codes to implement the Scheduling quality of service.
The transport protocol should detect duplicate control commands on the receiver and discard the duplicates.
It is necessary to provide the possibility of simplified configuration of the protocol for small-size networks (no more than 2 hops).
Consolidated requirements for the communication protocols at the physical-network level
Based on the provided industry requirements, it is possible to form consolidated requirements for communication protocols. Let us start with
the requirements at the physical-network levels:
1) support data transfer rates up to 20 Gbps, including intermediate speeds;
2) ensuring operation at distances up to 100 m;
3) reliable communication through the use of reliable channel coding;
4) providing comprehensive functionality for FDIR and efficiency monitoring at the data link layer;
5) point-to-point determinism;
6) ensuring time synchronization between devices. It is provided by supporting the transmission of time-codes. At the same time, synchronization should be reliable — erroneous time-codes and interrupt codes should not appear on the network and should be discarded;
7) support for transmitting of information with a size of 32 MB or more. For transmitting commands and telemetry — from 8 B to 64 KB;
8) support maximum data transfer latency:
a) for transmitting control commands less than 100 ms;
b) for time synchronization up to 100 ns;
c) for communication between two processor modules up to 100 ns in one link;
9) support multipath data transmission;
10) support multicast data transmission.
Consolidated requirements for communication protocols at the transport layer
The requirements at the transport layer relate to end-to-end transmission between the information transmitter and the receiver.
1) required quality of service: Guaranteed delivery, guaranteed bandwidth, priorities (from fore to six);
2) exchange of end-to-end acknowledgements;
3) support for the following main user data types:
a) control commands;
b) urgent packets;
c) regular packets;
d) time-codes;
e) interrupt codes and interrupt acknowledgments;
4) data transmission in connection-oriented and connectionless modes;
5) connection-oriented mode: connection for each receiver-transmitter pair; both active and passive devices could be initiators of data exchange; 8 unidirectional transport connections maximum; one transport connection for one data type; flow control mechanism; data segment length up to 64 KB;
6) connectionless mode: data segment length up to 2048 B;
7) command control length up to 4 B;
8) quality of service for Control commands and Urgent packets: priority, scheduling, guaranteed delivery;
9) quality of service for Regular Messages: priority, scheduling, guaranteed delivery, non-guaranteed delivery;
10) the transfer of time-code is carried out only in a non-guaranteed mode;
11) detection of duplicate control commands at the node receiver, discarding duplicates;
12) the possibility of a simplified protocol configuration for simple networks;
13) possibility to switch off the scheduling quality of service.
Additional requirements for the protocols are also:
1) interfaces to access the functions of the protocol (Service Access Points);
2) minimum data transfer delays;
3) the smallest possible footprint of the chip and the energy consumption. Since the mechanisms described in the protocols can be difficult to implement, require the additional memory (for example, segmentation, transport connections) and, as a result, occupy a large chip area. This may lead to exceeding the permissible weight and energy consumption characteristics for the spacecraft.
Conclusion
This article discusses the requirements for communication protocols for onboard networks from various open sources: scientific literature, project reports, and scientific articles. These requirements provide the important vision of what future data transfer protocols for spacecraft should look like. The analysis showed that many sources has the similar requirements. Therefore, on their basis, a number of main characteristics for the protocols of the physical-network layers and the transport layer are elaborated.
The article focuses on certain aspects of the operation of onboard networks and does not consider all possible parameters of the spacecraft operation. However, taking into account the authority of the analyzed sources, it can be concluded that these requirements are currently the focus of the global space industry in terms of communication protocols.
The requirements obtained during the analysis reflect the distinctive features of the SpaceWire/ SpaceFibre technology. It is a simple routing mechanism without buffering, which is able to transmit data of various unlimited lengths, and also has a
relatively small hardware implementation cost. It is the flexibility and scalability of protocols, the availability of opportunities for simplified configuration and assembly of networks using Plug-n-play technology. In addition, the SpaceWire family describes specialized types of high-priority packets for transmitting time data, as well as time synchronization mechanisms. It is important that this is an open technology that provides almost unlimited opportunities to expand the protocol family by transport layer protocols while maintaining compatibility with previous versions. The combination of these characteristics, concentrated in the protocols of the SpaceWire family, distinguishes these communication protocols for on-board networks into a separate group of space protocols that have characteristics that are not presented in other protocols.
The analysis of the requirements shows that the SpaceWire/SpaceFibre protocol family meets them. So they can be considered as the main ones for further application in the space industry. At the transport layer, at the moment, only the STP-ISS protocol meets all the described requirements due to the support of most mechanisms for ensuring the
1. Tavoularis A., Vlagkoulis V., Kostopoulos F., Le Ngoc T., Dellandrea B., Fossati L., Ilstad J., Jameux D. Space-Wire components, long paper: An IP core for the SpW family of protocols. 2016 International SpaceWire Conference (SpaceWire), Yokohama, 2016, pp. 1-8. doi:10.1109/SpaceWire.2016.7771642
2. Kapranova E. A., Nenashev V. A., Sergeev M. B. Compression and coding of images for satellite systems of Earth remote sensing based on quasi-orthogonal matrices. Proc. of SPIE, Image and Signal Processing for Remote Sensing XXIV, Berlin, Germany, 2018, vol. 10789, pp. 1078923-1-1078923-6. doi:https://doi. org/10.1117/12.2324249
3. Orly S., Elovici Y., Shabtai A., Shugol G., Tikochins-ki R., Kur S. Protecting military avionics platforms from attacks on MIL-STD-1553 communication bus. Computing Research Repository, 2017, pp. 1-15.
4. Parkes S. SpaceWire Users Guide. Dundee, Star-Dundee, 2020. 117 p.
5. Nepomnyashii O. V., Postnikov A. I., Goreva V. V., Varochkin S. S. Architecture of onboard management system for small satellites based on networking technologies. Issledovaniia naukograda, 2017, no. 1, pp. 22-29 (In Russian).
6. Parkes S., Armbruster P. SpaceWire: a spacecraft onboard network for real-time communications. 14th IEEE-NPSS Real Time Conference, 2005, Stockholm, 2005, pp. 6-10. doi:10.1109/RTC.2005.1547397
7. Notebaert O., Montano G., Planche T., Pruvost C., Wartel F., Schüttauf A., Herpel H., Honvault C.,
quality of service, reliable data transmission and various implementation profiles. At the same time, combinations of other existing protocols that solve specific narrowly focused tasks, also could provide the necessary performance characteristics. The use of the STP-ISS protocol is limited by the desire and ability of companies to use third-party protocols, so the development of new protocols is inevitable. The proposed requirements should be taken into account when developing these protocols in order to provide the important services for the new generation of onboard equipment.
Financial support
The paper was prepared with the financial support of the Ministry of Science and Higher Education and of the Russian Federation, grant agreement No. FSRF-2020-0004 "Scientific basis for architectures and communication systems development of the onboard information and computer systems new generation in aviation, space systems and unmanned vehicles".
Jameux D. Towards SpaceWire-2: Space robotics needs: SpaceWire missions and applications, long paper, 2016 International SpaceWire Conference (Space-Wire), Yokohama, 2016, pp. 1-9. doi:10.1109/Space-Wire.2016.7771614
8. Dello Sterpaio L., Marino A., Nannipieri P., Dinelli G., Davalle D., Fanucci L. A complete EGSE solution for the SpaceWire and SpaceFibre protocol based on the PXI industry standard. Sensors, 2019, vol. 19, no. 22, p. 5013. doi:10.3390/s19225013
9. Yablokov E., Sheynin Y., Suvorova E. GigaSpace-Wire — gigabit links for SpaceWire networks. Proceedings of the 5th International SpaceWire Conference, Gothenburg, 2013. pp. 28-34.
10. Parkes S., Ferrer Florit A., Gonzalez-Villafranca A. SpaceFibre interfaces and architectures. In 2019 IEEE Aerospace Conference, IEEE, 2019. pp. 1-8. https://doi.org/10.1109/AER0.2019.8741961
11. Peng T., Weps B., Hoflinger K., Borchers K., Ludtke D., Gerndt A. A new SpaceWire protocol for reconfigurable distributed on-board computers: SpaceWire networks and protocols, long paper. 2016 International SpaceWire Conference (SpaceWire), Yokohama, 2016. pp. 1-8. doi:10.1109/SpaceWire.2016. 7771624
12. Olenev V. L., Lavrovskaya I. I., Korobkov I. L., Dy-mov D. V. Analysis of the transport protocol requirements for the SpaceWire on-board networks of spacecrafts. Proceedings of 15th Seminar of Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program, Saint-Petersburg, 2014, pp. 6571. doi:10.1109/FRUCT.2014.6872424
13. Sheynin Y., Suvorova E., Schutenko F., Goussev V. Streaming transport protocols for SpaceWire networks. International SpaceWire Conference 2010, Saint-Petersburg, 2010, pp. 56-59.
14. Sandia National Laboratories. Joint Architecture System Reliable Data Delivery Protocol (JRDDP). Albuquerque, SNL, 2011. 72 p.
15. Mich W., Romanowski K., Tyczka P., Renk R., Kol-lias V., Pogkas N. Implementation and validation of the SpaceWire-R protocol. 2016 International Space-Wire Conference (SpaceWire), Yokohama, 2016, pp. 1-4. doi:10.1109/SpaceWire.2016.7771601
16. Gibson D., Parkes S., McClements C., Mills S. Space-Wire-D prototype and demonstration system. 2016 International SpaceWire Conference (SpaceWire), Yokohama, 2016, pp. 1-7, doi:10.1109/SpaceWire. 2016.7771645
17. Gibson D. Deterministic SpaceWire Networks. University of Dundee, 2017. 297 p.
18. Sheinin Iu. E., Olenev V. L., Lavrovskaya I. Ia., Dy-mov D. V., Kochura S. G. Development, analysis and design of STP-ISS transport protocol for onboard SpaceWire networks. Issledovaniia naykograda, 2016, no. 1-2, pp. 21-30 (In Russian).
19. Korobkov I., Suvorova E., Sheynin Y., Olenev V. Streaming services over SpaceFibre networks. Proceedings of 7th International SpaceWire Conference 2016, Yokohama, 2016, pp. 151-158. doi:10.1109/ SpaceWire.2016.7771621
20. Korobkov I. Adaptive data streaming service for onboard spacecraft networks. Proceedings of 17th Con-
ference of Open Innovations Association Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program, Yaroslavl, 2015, pp. 291-298.
21. National Aeronaut Administration (NASA). Comparison of Communication Architectures for Spacecraft Modular Avionics Systems. LLC-Create Space, 2018. 36 p.
22. Sheinin Iu. E., Rozhdestvenskaya K. N., Evdoki-mov A. S., Dymov D. V., Kochura S. G. SpaceWire-Plug-and-Play for future onboard JSC spacecraft networks. Modern Problems of Radio Electronics, 2018, pp. 196-200. Available at: http://efir.sfu-kras.ru/ downloads/sbornik-spr-2018.pdf (accessed 03 February 2020) (In Russian).
23. SkiSys SSL/08717/D0C/001. User Requirements — SpaceWire Plug-and-Play Protocol. Network Discovery Protocols, 2012. 84 p.
24. Kopetz H. Real-Time Systems. Design Principles for Distributed Embedded Applications. Second ed. Springer US, 2011. 378 p. doi:10.1007/978-1-4419-8237-7
25. Dymov D., Sheynin Y., Olenev V. STP-ISS transport protocol application for SpaceFibre on-board networks. 2020 7th International Conference on Control, Decision and Information Technologies (CoDIT), Prague, 2020, pp. 914-919. doi:10.1109/CoDIT49905. 2020.9263976
26. D1.1 Consolidated set of Requirements for Space-Wire-RT. Available at: http://spacewire-rt.org/Data/ Docs/SpWRT_D1-1_v2-00.pdf (assessed 2 December 2020).
УДК 004.057.4
doi:10.31799/1684-8853-2021-1-8-16
Анализ требований к современным протоколам для бортовых сетей космических аппаратов
В. Л. Оленева, канд. техн. наук, доцент, orcid.org/0000-0002-1817-2754, Valentin.Olenev@guap.ru ^анкт-Петербургский государственный университет аэрокосмического приборостроения, Б. Морская ул., 67, Санкт-Петербург, 190000, РФ
Введение: на смену устаревающим бортовым космическим сетям на базе шинных топологий приходят новые технологии, одной из которых является SpaceWire. Разрабатываются новые протоколы, расширяющие возможности SpaceWire. Необходима уверенность в том, что они будут обеспечивать все технические возможности для передачи и обработки данных на борту космических аппаратов. Цель: анализ существующих и разработка обобщенных требований к коммуникационным протоколам для бортовых космических сетей, которые позволят учитывать современные запросы космической индустрии. Результаты: в результате проведенного анализа сформирован набор консолидированных требований к протоколам физического-сетевого уровней и отдельно к протоколам транспортного уровня. Описаны требования, касающиеся скорости, задержек и расстояния передачи, объема передаваемой информации, функциональности для обнаружения неисправностей, синхронизации времени между устройствами, необходимых качеств сервиса и их свойств, основных пользовательских типов данных и режимов передачи данных на транспортном уровне. Существующие протоколы семейства SpaceWire выделены в отдельный класс протоколов, обладающих характеристиками, не присущими другим космическим протоколам. Практическая значимость: проведенный анализ позволит в значительной степени упростить процесс создания новых коммуникационных протоколов бортовых космических сетей, а также обеспечить необходимый уровень технологического оснащения космических аппаратов нового поколения.
Ключевые слова — бортовые космические сети, коммуникационные протоколы, технические требования, SpaceWire.
Для цитирования: Olenev V. L. Analysis of requirements for modern spacecraft onboard network protocols. Информационно-управляющие системы, 2021, № 1, с. 8-16. doi:10.31799/1684-8853-2021-1-8-16
For citation: Olenev V. L. Analysis of requirements for modern spacecraft onboard network protocols. Informatsionno-upravliaiushchie sistemy [Information and Control Systems], 2021, no. 1, pp. 8-16. doi:10.31799/1684-8853-2021-1-8-16
