INTEGRATED ONBOARD NETWORKING FOR IMA2G

Yuriy Sheynin*, Elena Suvorova*, Valentin Bukov**, Vladimir Shurman** *) Saint-Petersburg State University of Aerospace Instrumentation Saint-Petersburg, Russian Federation **) PLC Scientific and Research Institute of Avionic Equipment Zshukovsky, Moscow Region, Russian Federation

Keywords: IMA2G, SpaceWire, Zero Maintenance Equipment, Integrated Networking Architecture

Abstract Tools) project, [1] has shown, the AFDX The article presents developments of be the IMA2G integrated networking next generation onboard networking for interconnection. With its optimized for IMA2G that is based on the SpaceWire/GigaSpaceWire networking throughput architecture and protocols it has poor latency para technology. The IMA2G prospective vision requirements of time-critical fast-loop could be further strengthen by its integration applications where low latency is the with the Zero Maintenance Equipment (ZME) concepts. The article describes the SpaceWire predominant requirement. As a result, for such based backbone network as an integral parts of the distributed on-board architecture interconnection for IMA2G, gives examples with low latency & short period of applying typical subsystems on requirements, the AFDX networking is SpaceWire based interconnection. reduced to so-called LC-AFDX (Low Capacity AFDX), [2],

Field- in fact, reduced from scalable switch-based networking back to point-to- 1 Introduction point interconnections. An IMA2G networking technology should IMA2G should cover broader scope of support broad scalability in all domains: in avionics units and subsystems not only data number of nodes, in data rates, in throughput, computing resources. It should move to in latency constraints. Scalability should not distributed computing entity (unlike typically only give a way for reconfiguration, central computing resources in IMA1G), and increase(decrease) number of nodes and cover command/control, signal processing, IO integrated avionics resources gain, but resources also . It sets new requirements for an support structured isoefficiency in avionics backbone network as the IMA2G interconnection characteristics also. Packet integral interconnection. IMA2G backbone delivery and signaling latency should be network as an integral interconnection confined in required bounds. Scalability of should be able to provide all types of traffic network integral throughput should be in onboard avionics, substituting the separate accompanied by statistical equidistance of end and heterogeneous sensor busses, data busses, nodes and keeping bilateral throughput command busses, field busses and sideband between them in scaling network structure. It signals for time stamps distribution and hard would be vital for true flexibility of function real-time signaling. allocation that is claimed to be one of the As the SCARLETT (SCAlable & IMA2G key features. Real-time signaling with ReconfigurabLe Electronics plaTforms and

1 YURIY SHEYNIN et al.

strict latency constraints is important for support all types of traffic in the distributed on- synchronization, control in the loop, control board avionics, Table 1: signaling. Sensor buses with high-rate data streams between digitized signals sources and receivers; 2. Integrated Networking for IMA2G Command buses, that needs to deliver Evolution of integrated modular avionics command packets with deterministic from IMA1G to IMA2G is transition to delivery time; integrated architecture on-board systems. Target Data buses for distributed processing, with systems of an aircraft would not be isolated low latency delivery of data packets; subsystems, with boundaries implemented in Signal lines with hard real-time signals hardware and software structure of on-board distribution with ultra-low latency for equipment. They would become virtualised and synchronisation and control. distributed over on-board equipment structure. On-board processing, data acquisition and Table 1. Airborne interconnections communication facilities should form an Bussing Current bussing Prospective integral pull of resources for all the set of examples alternative aircraft on-board systems target tasks. From autonomous computers in the Sensor SpaceWire/ federative architecture we move to an integrated buses (FC) GigaSpaceWire computing entity for data and signal processing. Command MIL-STD SpaceWire, Logical boundaries between target systems buses 1553B SpaceWire-D, would not be reflected in a structure of on-board SpaceFibre processing and communication infrastructure. Further integration in IMA2G should cover data Data buses AFDX SpaceWire, processing in a distributed modular electronics (), GigaSpaceWire, (DME) architecture, as well as command and SRIO SpaceFibre control, I/O and signalling tasks. DME will have scalable distributed computing by integral Video ARINC818, SpaceWire, computing environment. IO would be separated buses FC-AV GigaSpaceWire, from computing modules and could be SpaceFibre positioned anywhere in the distributed Field buses SPI, I2C SpaceWire architecture. Real-time constraints in IO CAN, RS485, signaling and control should not lead to physical RS422 binding them to particular modules but could be distributed over the DME structure and could Time Proprietary SpaceWire migrate in system reconfiguration. synchronis bussing Reconfiguration mechanisms would work in ation virtually integral computing environment while busses being physically distributed and spread over the Sideband Proprietary, SpaceWire aircraft. These key features should be supported signals unit-specific in distributed computer architecture, system wiring, multiple software and scalable onboard networking wires interconnection. DME on-board architecture should move towards integral interconnection infrastructure, The Integrated Networking ARchitecture should be supported by an Integrated (INAR) for IMA2G and AZME has been Communications Network (ICN). It should developed, which is based on provide a communication entity that could

2 INTEGRATED ONBOARD NETWORKING FOR IMA2G

SpaceWire/GigaSpaceWire networking common time codes distribution, distributed technology, [3]. interrupt signals. Its components, e.g. The INAR gives a basis for building scalable SpaceWire NIC in end nodes, is very networking infrastructure with compact and compact in VLSI implementation and could light-weight routing switches, ready for be integrated into any types of nodes scalability and duplications for redundancy. It from computing nodes to simple sensor and provides high rate communications (up to 400 actuator chips/SiP. Further SpaceWire Mbit/s for SpaceWire, 1-5 Gbit/s for technology developments GigaSpaceWire, GigaSpaceWire links), better latencies than [6], SpaceFibre/SpaceWire-RT, give higher other networking technologies, efficient and rates (1-10 Gbit/s), longer links (to 100-200 m), compact implementation in chips. galvanic isolation, extended QoS features, [7]. INAR provides integral network GigaSpaceWire defines DC-balanced links with infrastructure for all types of traffic in DME: 8B10B coding and galvanic isolation options. high-rate data streams, command packets with The SpaceWire standard does not set any deterministic delivery time, data packets for limitations on the packet size. This feature can distributed processing and IO, common time be used for support of unpacketized data stream ticks distribution, ultra-low latency distribution (e.g. raw radar digital signal stream) or large of hard real-time signals. Interfacing INAR to packets for data streams with huge data items other interconnections (ARINC429, CAN, (e.g. video frames), in SpaceWire based AFDX, FibreChannel) for gradual evolution of communication infrastructures for on-board avionics is provided by gateway nodes. systems. In our design we included ability to, frame the incoming byte stream, supply it with an adequate packet descriptor type, format it as 3. INAR networking with the SpaceWire a packet, and send by the link to the network. technology Thus, we can do an entrance packetizing of a raw data stream. It could be a useful feature to The SpaceWire networking technology communicate with devices, which has not development was launched by the ESA information flow packetizing facilities inside initiative and has been done by the them. international SpaceWire WG that was formed Another SpaceWire important feature is and coordinated by the ESTEC/ESA. The first hard real-time signaling support. release of the SpaceWire standard had been These features correlate well with published in January 2003 (the current release prospective avionics IMA2G requirements. 2008, [4]). Nowadays SpaceWire is the Based on SpaceWire spacecraft on-board mature technology, it is supported by ESA, equipment integrated modular architecture is NASA, Roscosmos, JAXA; it has been used presented at the Fig.1. in a number of national satellites and Modern on-board systems use packetized spacecrafts and in international missions, [5]. digital streams flows to deliver signals and data SpaceWire defines full protocol stack- to and from sources and receivers. The switched from physical level to network level (in the SpaceWire/GigaSpaceWire digital signal links accompanying standards the Transport level offers: also). It uses high-rate serial duplex links increase of a distance from channels with low power consumption LVDS sensors/effectors to ISDS modules up to signals and automatic transfer rate adaptation any reasonable for on-board systems with continues scale of rates, 2-400 Mbit/s, values; it provides broad scope for IMA lay high-rate packets switching scalable out and placement on board; interconnections with routing switches, tolerant to faults and to intermediate faults protocols. SpaceWire has embedded system functions for real-time distributed architectures:

3 YURIY SHEYNIN et al.

change the links you need for higher throughput, longer distances or galvanic isolation and use the common SpaceWire network infrastructure elsewhere. The

GigaSpaceWire protocol stack introduces new PHY and Symbol layers, modifies the Exchange

layer; the SpaceWire Packet and Network layers are used without any changes. The DS encoding scheme is substituted with the DC-balanced 8b10b encoding which is currently used in a wide number of PSS HDS High-rate standards. With GigaSpaceWire Programmable Switching System for SpaceWire links the link transmission rate can be raised up to 1- High-Rate Digital Signals 2.5 Gbit/s (5 Gbit/s in future), the maximum cable length can be increased to 100 m with Programmable cable mass reduced more than twice up to 30 Sampled Signals Switches for g/m; galvanic isolation can be implemented. SpaceWire Data links Time Markers Lower rates could be used also in case one has a need just for galvanic isolation or longer distances. For the integrated network interconnection SpaceWire links it is important to support hard real-time signaling also (time ticks for synchronization, DAC ADC interrupts and alarm signals from IO units, urgent control signals to attached equipment,

Effectors etc.). Packet guaranteed low-latency, in microseconds, delivery of such control signals by a message delivery neither in AFDX, nor Fibre Channel, Sensor Fields (SF), Effector Fields (EF) nor 1553B. In SpaceWire packet transfer service is supplemented by specific mechanism of Fig. 1. Distributed Integrated Modular control signals hard real-time delivery, [8]. Spacecraft Avionics Architecture These control signals are transmitted over the network in some microseconds irrelevant to the scalability of sensors/effectors to ISDS load (or overload) of the network links and channels cumulative throughput; routs. The SpaceWire Time-code service reduction in hardware: in wiring, in cables ensures low-latency delivery of time-stamps; the weight, in interface circuitry; Distributed Interrupt mechanism provides programmable distribution of high-rate transmission of system-critical urgent signals digital signals between sources and and commands, with the receipt confirmation or recipients, with information flow without it. Latency of a control signal passing a multiplication, included; routing switch is 200-300 ns typical; delivery of reconfiguration of links between the signal from the source to any node of the sensors/effectors and ISDS modules, network is proportional to the network graph system fault-tolerance improvement. diameter and for practical network installations is 1-3 mcs. GigaSpaceWire is another type of a link in To ensure high reliability of the signals the SpaceWire technology, recently introduced delivery, the mechanisms provide broadcast and implemented. GigaSpaceWire provides its transmission, automatic acknowledgment of easy integration in a SpaceWire network:

4 INTEGRATED ONBOARD NETWORKING FOR IMA2G

signal delivery and fault detection, isolation and spurious coupling between them. Trusted recovery procedures. interconnection interface in end-nodes provides It is supported by the chips - processors protection from end-node applications and peripheral controllers with embedded malfunctioning that could disturb system level SpaceWire and GigaSpaceWire links, [9, 10], operation. Fig. 2. Deterministic model of fault-tolerance, d- faultless systems (no-failure operation with up to d system components failures) is used to govern INAR fault-tolerant structures development and estimation. Redundant sets of end-nodes computer modules/CNOR, peripheral modules, IO modules, along with Fig.2 A micropocessor and peripheral controller transparent tasks migration to available with embedded SpaceWire/ operating end-nodes, provide system-level GigaSpaceWire links operated redundancy. For fault-tolerance support in ZME at the 4. System Level Fault-Tolerance with system level the basic SpaceWire technology Operated Redundancy features are exploited: automatic detection of a link connection The IMA2G prospective vision could be further fault or breaking that is built in the strengthened by its integration with the Zero Maintenance Equipment (ZME) concepts, [11]. automatic connection recovery after a The ZME is airborne equipment that is designed transient fault in a link; to automatically recover without personnel adaptive routing, which is built in the intervention for a given time. Avionics that is Network level protocol, that provides created with substantial reduction of automatic selection of alternative rout if maintenance efforts gives to airlines undeniable an initial output port of a routing switch advantages in operating airship cost happens to be not connected, faulty or (approximately 50 %), possibilities of realizing busy on a forwarded packet arrival; more compact flight timetable and using fault-tolerance and recovery mechanisms airports equipped with a low level of surface built in the basic SpaceWire protocols for facilities. Operated redundancy of ZME Time-Codes and Distributed Interrupts computing nodes is complemented by system- distribution that know how to pave their level fault-tolerance of DME to convert it into ways to any node in the network ZME IMA2G. bypassing failed switches and links; For fault-tolerance support in INAR at no restrictions whatever on the system level the basic SpaceWire interconnection graph topology that gives technology features are exploited. System-level full scope for building redundant fault-tolerance is supported by INAR features interconnection topologies of any types; for building fault-tolerant network network clusterisation facilities (by infrastructure. INAR provides construction of regional-logical addressing) that enable scalable network interconnection with operated communications localization in a region in redundancy, adaptive and redundant packets and correlation with easily monitored, control signal tokens routing in it. Automatic controlled (and blocked, in case of a fault recovery from transient faults is a native feature propagation risk) packets inter-region of SpaceWire protocols at several layers. transition in dedicated points of clustered Automatic recovery from persistent faults is interconnection; done by intelligent SpaceWire routing switches. reconfigurablility of tracing logical Traffic partitioning ensures protection of packet connections between nodes by routs flows in the network interconnection from alignment in interconnection routing

5 YURIY SHEYNIN et al.

switches without changes in end nodes logical connections setup. TN R R R TN They are complemented by additional ... R R R ... features built in SpaceWire nodes and TN switches implementations to have full TN R R R exploitation of these important for fault- tolerance original SpaceWire technology features, to provide no-failure operation at the Fig.3 Adaptive routing by routing table system level of INAR and ZME avionics. In associated with an output port number adaptive routing a list of alternative output ports 4.1 Automatic detection of a link is defined without reference to a particular logic connection fault and connection recovery address. In this case, in the course of routing an output port is determined by the routing table. The SpaceWire standard provides Then it is checked if a list of alternative ports is mechanisms to detect single errors at the Link specified for this port; if there is such a list any level. Each symbol has the parity bit to detect of them could be selected for the packet caused by transient faults single errors. At the forwarding through the router to work around Exchange level a symbol sequence is checked faulty link, to balance links workload, etc. This and caused by link malfunctioning symbol type of adaptive routing could be efficient in sequence errors are detected. At this level multilink interconnection between adjacent changes of the D and S lines are checked and nodes, Fig.4 their long-duration non-changing is detected as the link failure (open-circuit connection or the TN TN link counterpart node failure). Router 5 7 Router 4 The GigaSpaceWire uses 8B10B encoding that also detects single errors in symbols. At the 6 8 9 upper layers symbol sequence errors are TN TN detected also (e.g. wrong K-codes in a sequence). Fig.4 Adaptive routing by port number 4.2 Adaptive routing Adaptive routing in SpaceWire networks may be used for dynamic by-passing network The SpaceWire has adaptive routing sections with faults, links with transient errors mechanisms associated with a logical address and disconnections or overloaded ones. and with an output port number. In the logical address adaptive routing the routing table specifies a list of alternative output ports that 4.3 Reconfigurablility of tracing logical could be used for transmission of packets with connections between nodes this logical address; any of the ports could be Packets transfer routes are specified in used for the packet transmission. The particular routing tables of the network nodes routing port number is designated dynamically in the course of the packet routing in correspondence of the listed ports status (ready, busy, failed, tables information specifies routes, by which a etc.). This type of adaptive routing could be packet would be transmitted through the used when there are multiple routs between the network. Reconfiguration of logical connections source and destination nodes, Fig.3. through the network would be done by updating routing tables in routing nodes.

6 INTEGRATED ONBOARD NETWORKING FOR IMA2G

4.4 Fault-tolerance and recovery another copy will run by another rout and will mechanisms in the Time-Codes and not be affected by that fault. Distributed Interrupts distribution

Time-codes are specific codes and 4.6 Network clusterisation mechanism in SpaceWire that are aimed for system time synchronization in terminal nodes. Another important feature is network Distributed interrupt codes are aimed for hard clusterisation. The SpaceWire has native real-time signaling in SpaceWire nodes. Due to features for network clusterisation. The so specific protocols of control codes distribution time-codes and distributed interrupts are spread structuring destination address in a packet, over a SpaceWire network with very low which may include address in the cluster and latencies, which are time-independent to data address of the cluster. The last one specifies a transmission network load, and reach any node node through which the packet will be of the network in some microseconds. forwarded into the cluster. Thus the cluster The time-codes and distributed interrupt boundary is known for the system. Additional codes (control codes) are distributed in the screening at the cluster border could protect its network by broadcasting and find any possible inward nodes from outward nodes faults and routes to reach any node on the network. In case malfunctioning (e.g. bubbling idiot). With the of fault in a link or a node the codes will trusted systems component concept, [12], the automatically run around and bypass it if the bridge node of the cluster could control inward interconnection graph remains a connected and outward packet and control signals flow. graph and there is a potential route in the network structure. 5 Cockpit videostreams distribution network segment example 4.5 Redundant interconnection topologies As an example of an INAR segment consider a The SpaceWire standard, its protocols and videostreams distribution network segment in mechanisms sets no limitations on a network the cockpit integrated display cluster. Video interconnection graph. We can build redundant streams distribution segment provides efficient INAR topologies that ensure reliability, fault and robust video data delivery from the tolerance to a specified number of faults of to the cockpit displays, nodes and links in the network. building task oriented, Cockpit Integrated A network fault tolerance against n faults Display Cluster for IMA2G/ZME. may ensure network persistency that keeps Conventional videostreams delivery transmission and routing of packets after the interconnections are built according the faults. It could be afforded by n+1 duplication ARINC 818 standard that uses FibreChannel of nodes and links. A packet is sent and runs (FC) bottom layer for its transport over the network as a single copy. On its run, in implementation. However analysis of the FC case of a fault on its way it would be lost; shows that its features however, next packets will run around faulty native videostream frames requirements and parts, due to redundancy, and the network will lead to superfluous data slicing, processing and keep operating. synchronization overheads in implementation For packets that should be delivered even that are caused by the FC limitations. The in case of faults, not only the network structure recent ARINC 818-2 revision makes this should be duplicated, but the packet discrepancy more substantial. transmission also. The packet is sent in multiple Juxtaposing the ARINC 818 and the copies that should be routed along different SpaceWire/GigaSpaceWire features, Table 2, routes in the network. Thus a fault in the rout of one could see that the SpaceWire networking one packet copy will not kill the packet, as technology well correlates with the

7 YURIY SHEYNIN et al.

videostreaming requirements and provides Table 2. ARINC 818 / 818-2 and embedded, ready-made mechanisms for its SpaceWire/GigaSpaceWire features support. SpaceWire/ Format of SpaceWire packets makes it easy to ARINC 818 GigaSpaceWire package natural video data units into SpaceWire packets. For instance, a video frame, say High rate serial High rate serial 2 Mbits/frame, could be packaged in a single channels channels with scalable SpaceWire packet, without its cutting into performance fragments, not to break down a display line to Packetized video data Packet switching pack it into a packet payload field, packing/unpacking them in a separate packet transfer network technology each, etc. It simplifies interfacing video Correlating packet Arbitrary packet length; sources/sinks to the network and increases size (packet payload) can fit any display line/ useful throughput for video streams delivery. with the display line/ fragment / image size Videostrems routing, multicasting or image fragment / broadcasting from multiple sources to multiple image size displays are provided by native SpaceWire features and is easily controlled by Channel Bonding Adaptive routing in a configuration and dynamic reconfiguration of (inverse multiplexing routing switch; routing tables in the SpaceWire switches. Thus to k physical links) automatic inverse better workload repartition between Pilot Flying multiplexing of a and Non Flying data and more efficient cockpit packet stream to k displays field organisation are achieved. output ports Redundant topology of the SpaceWire network segment provides fault-tolerance of the video New ARINC 818-2 streams distribution. Adaptive routing a native features SpaceWire feature, automatically, on the fly, Bi-directional Duplex links the switches data streams to healthy links bypassing interfaces (camera native feature of the faulty ones without network management configuring and SpaceWire/GigaSpace system interference. trimming, display - Wire links and routs With redundant interconnection topologies we can ensure fault tolerance to a specified number data from touchscreen, of faults of nodes and links in the network. At etc.) the Fig.5 the cockpit SpaceWire interconnection Video switching; Fast packet switching tolerant to any 2 faults of links and/or nodes is switching video data network technology. presented. streams Programmable routing Network operation recovery after transient tables. Low latency faults in links and nodes is embedded in the SpaceWire protocol stack at several layers. It is wormhole routing. done automatically by respective FSM in nodes Video streams Multicast support in and link controllers. multicasting routing switches

8 INTEGRATED ONBOARD NETWORKING FOR IMA2G

References

1 Hainaut D. SCAlable & ReconfigurabLe Fault-tolerant Electronics plaTforms and Tools - Towards Switch Switch Switch SpaceWire 1 2 3 network the next generation of Integrated Modular segment Avionics. An Introduction to SCARLETT. Aerodays 2011, Madrid, Spain, 2011. 2 Bernard S. and Garcia J.-P. Braking Systems with New IMA Generation. SAE International 2011, 6p. 3 Avakyan A., Boblak I., Bukov V., Fig. 5 Fault tolerant fly-by-wire systems; Chernyshov V., Sheynin Yu., Shurman V., 2 failures tolerant cockpit interconnection Suvorova E. A computer with operational redundancy and integrated onboard The SpaceWire routing switch is a compact networking as base for avionics of zero unit, Fig.6, that could be easily placed and maintenance equipment. Proceedings of the installed in aircraft on-board space. 28th International congress of the Aeronautical Sciences, ICAS 2012, 10 p. 4 SpaceWire Standard. ECSS Space Engineering. "SpaceWire Links, Nodes, Routers and Networks". ECSS-E-ST-50-12C, July 2008 5 Parkes S., Nomachi M., Sheynin Y. SpaceWire Missions and Architectures. 60th Fig. 6. 16-port SpaceWire routing switch International Astronautical Congress 2009. for airborne networks 6 Yablokov E., Sheynin Y., Suvorova E.,

Stepanov A., Solokhina T., Petrichcovitch Y., Glushkov A., Alekseev I. GigaSpaceWire 5 Conclusion Gigabit Links for SpaceWire Networks., SpaceWire-2013. Proceedings of the 5th The SpaceWire technology can provide International SpaceWire Conference, all the necessary IMA2G and ZME features Gothenburg 2013. Editors Steve Parkes and in the frame of common network architecture Carole Carrie. ISBN 978-0-9557196-4-6, and basic protocol stack with optimized Space Technology Centre, University of customization to particular needs and Dundee, Dundee, 2013, pp. 28-34. requirements of distributed applications in its 7 168. Raszhivin D., Sheynin Y., Abramov A. segments and clusters. The avionics subsystems Deterministic Scheduling of Space-Wire Data prototyping with INAR networking Streams, SpaceWire-2013. Proceedings of the infrastructure has proved its efficiency and 5th International SpaceWire Conference, conform the IMA2G and ZME requirements. Gothenburg 2013. Editors Steve Parkes and Methodology and tools for INAR-based Carole Carrie. ISBN 978-0-9557196-4-6, onboard networks design and configuration has Space Technology Centre, University of been developed, [13], to support practical Dundee, Dundee, 2013, pp. 141-144. design of DME avionics with INAR 8 Gorbachev S., Koblyakova L., Sheynin Y., networking. Stepanov A., Suvorova E., Suess M.,

ceWire-2013. Proceedings of the 5th International 9 YURIY SHEYNIN et al.

SpaceWire Conference, Gothenburg 2013. Editors Steve Parkes and Carole Carrie. ISBN 978-0-9557196-4-6, Space Technology Copyright Statement Centre, University of Dundee, Dundee, 2013, The authors confirm that they, and/or their pp. 35-41. company or organization, hold copyright on all 9 Solokhina T., Glushkov A., Alexeev I., of the original material included in this paper. Sheynin Y., Suvorova E., Shutenko F., The authors also confirm that they have --the Chipset for Distributed obtained permission, from the copyright holder Signal Processing and Control with of any third party material included in this paper, to publish it as part of their paper. The SpaceWire Conference. Conference authors confirm that they give permission, or Proceedings. Space Technology Centre, have obtained permission from the copyright University of Dundee, Dundee, 2007. ISBN: holder of this paper, for the publication and 978-0-9557196-0-8. 8 p distribution of this paper as part of the 10 Sakharov A., Skok D., Gussev V., Solokhina ICAS2014 proceedings or as individual off- T., Petrichkovich J., Sheynin Y., Suvorova E. prints from the proceedings. Radiation Tolerant SpaceWire Remote Terminal Controller ASIC (RMR-02P), SpaceWire-2013. Proceedings of the 5th International SpaceWire Conference, Gothenburg 2013. Editors Steve Parkes and Carole Carrie. ISBN 978-0-9557196-4-6, Space Technology Centre, University of Dundee, Dundee, 2013, pp. 213-215. 11 Bukov V N, Kutahov V P and Bekkiev A Yu. Avionics of zero maintenance equipment. International congress of the aeronautical sciences. CD ISBN 978-0-9565333-0-2, Report 7-1-1. 2010. 12 Kopetz H. Real-Time Systems. Design principles for distributed embedded application. 2nd edition, Springer, 2011. 13 Syschikov A., Suvorova E., Sheynin Yu., Sedov B., Matveeva N., Raszhivin D. .Toolset for SpaceWire Networks Design and Configuration. SpaceWire-2013. Proceedings of the 5th International SpaceWire Conference, Gothenburg 2013. Editors Steve Parkes and Carole Carrie. ISBN 978-0- 9557196-4-6, Space Technology Centre, University of Dundee, Dundee, 2013, pp. 149-153.

Contact Author Email Address [email protected], [email protected]

10