TTEthernet for Integrated Spacecraft Networks

Aerospace projects have traditionally employed federated avionics architectures, in which each computer system is designed to perform one specific function (e.g. navigation). There are obvious downsides to this approach, including excessive weight (from so much computing hardware), and inefficient processor utilization (since modern processors are capable of performing multiple tasks). There has therefore been a push for integrated modular avionics (IMA), in which common computing platforms can be leveraged for different purposes. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and design complexity. However, the application of IMA principles introduces significant challenges, as the data network must accommodate traffic of mixed criticality and performance levels - potentially all related to the same shared computer hardware. Because individual network technologies are rarely so competent, the development of truly integrated network architectures often proves unreasonable. Several different types of networks are utilized - each suited to support a specific vehicle function. Critical functions are typically driven by precise timing loops, requiring networks with strict guarantees regarding message latency (i.e. determinism) and fault-tolerance. Alternatively, non-critical systems generally employ data networks prioritizing flexibility and high performance over reliable operation. Switched Ethernet has seen widespread success filling this role in terrestrial applications. Its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components make it desirable for inclusion in spacecraft platforms. Basic Ethernet configurations have been incorporated into several preexisting aerospace projects, including both the Space Shuttle and International Space Station (ISS). However, classical switched Ethernet cannot provide the high level of network determinism required by real-time spacecraft applications. Even with modern advancements, the uncoordinated (i.e. event-driven) nature of Ethernet communication unavoidably leads to message contention within network switches. The arbitration process used to resolve such conflicts introduces variation in the time it takes for messages to be forwarded. TTEthernet1 introduces decentralized clock synchronization to switched Ethernet, enabling message transmission according to a time-triggered (TT) paradigm. A network planning tool is used to allocate each device a finite amount of time in which it may transmit a frame. Each time slot is repeated sequentially to form a periodic communication schedule that is then loaded onto each TTEthernet device (e.g. switches and end systems). Each network participant references the synchronized time in order to dispatch messages at predetermined instances. This schedule guarantees that no contention exists between time-triggered Ethernet frames in the network switches, therefore eliminating the need for arbitration (and the timing variation it causes). Besides time-triggered messaging, TTEthernet networks may provide two additional traffic classes to support communication of different criticality levels. In the rate-constrained (RC) traffic class, the frame payload size and rate of transmission along each communication channel are limited to predetermined maximums. The network switches can therefore be configured to accommodate the known worst-case traffic pattern, and buffer overflows can be eliminated. The best-effort (BE) traffic class behaves akin to classical Ethernet. No guarantees are provided regarding transmission latency or successful message delivery. TTEthernet coordinates transmission of all three traffic classes over the same physical connections, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. Common computing platforms (e.g. LRUs) can share networking resources in such a way that failures in non-critical systems (using BE or RC communication modes) cannot impact flight-critical functions (using TT communication). Furthermore, TTEthernet hardware (e.g. switches, cabling) can be shared by both TTEthernet and classical Ethernet traffic

On TTEthernet for Integrated Fault-Tolerant Spacecraft Networks

There has recently been a push for adopting integrated modular avionics (IMA) principles in designing spacecraft architectures. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and de- sign complexity. Ethernet technology is attractive for inclusion in more integrated avionic systems due to its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components. Furthermore, Ethernet can be augmented with a variety of quality of service (QoS) enhancements that enable its use for transmitting critical data. TTEthernet introduces a decentralized clock synchronization paradigm enabling the use of time-triggered Ethernet messaging appropriate for hard real-time applications. TTEthernet can also provide two forms of event-driven communication, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. This paper explores the application of TTEthernet technology to future IMA spacecraft architectures as part of the Avionics and Software (A&S) project chartered by NASA's Advanced Exploration Systems (AES) program

Metodología para la determinación de protocolos de comunicación a nivel industrial a partir del ancho de banda y tipo de señal eléctrica

En la presente monografía se expondrán características de distintos protocolos: creación, funcionamiento y aplicabilidad según variables como ancho de banda y tipo de señal eléctrica. Finalmente se propondrá una metodología para elegir el protocolo de comunicación más conveniente según la necesidad del usuario; esto, haciendo uso de las investigaciones previamente realizadas por distintos autores en este campo.This monograph will present characteristics of different protocols: creation, operation and applicability according to variables such as bandwidth and type of electrical signal. Finally, a methodology will be proposed to choose the most convenient communication protocol according to the user's needs; this, using the research previously carried out by different authors in this field.EspecializaciónEspecialista en Electrónica DigitalCONTENIDO PREFACIO............................................................................................................................. 7 1.1. DEFINICIÓN DEL PROBLEMA.............................................................................. 7 1.2. JUSTIFICACIÓN....................................................................................................... 9 1.3. OBJETIVOS............................................................................................................. 10 1.3.1 OBJETIVO GENERAL....................................................................................... 10 1.3.2 OBJETIVOS ESPECIFICOS............................................................................... 10 MARCO REFERENCIAL ................................................................................................... 11 2.1 ESTADO DEL ARTE .............................................................................................. 11 2.1.1 IoT (Internet of Things – Internet de las Cosas) .................................................. 11 2.1.2 Protocolos de comunicación................................................................................. 13 2.2 MARCO CONCEPTUAL ........................................................................................ 14 2.2.1 Internet de las cosas (IoT) .............................................................................. 14 2.2.2 Software para IoT ........................................................................................... 15 2.2.3 Hardware para IoT.......................................................................................... 15 2.2.4 Protocolos de comunicación........................................................................... 15 2.2.5 Redes de comunicación .................................................................................. 16 2.2.7 Analítica de datos ........................................................................................... 16 2.3 MARCO TEÓRICO ................................................................................................. 17 2.3.1 Aplicaciones IoT industriales......................................................................... 17 2.3.2 Redes para IoT................................................................................................ 17 2.3.3 Modelo OSI .................................................................................................... 18 2.3.4 Protocolos de comunicación en la industria ................................................... 23 2.3.5 Plataformas IoT .............................................................................................. 32 METODOLOGÍA................................................................................................................. 33 2.4 Elección de protocolos de comunicación.................................................................. 33 3.2 Características en las capas de los protocolos de comunicación ................................ 34 3.2.1. MQTT.................................................................................................................. 34 3.2.2. CoAP................................................................................................................... 35 3.2.3. AMQP ................................................................................................................. 37 3.2.4. HTTP................................................................................................................... 38 3.2.5. HART.................................................................................................................. 40 3.2.6. Modbus................................................................................................................ 42 3.2.7. IPv6 .................................................................................................................... 44 3.2.8. DeviceNet .......................................................................................................... 46 3.2.9. Zigbee.................................................................................................................. 48 3.2.10. Bluetooth Low Energy (BLE)........................................................................... 50 3.2.11. Z-Wave.............................................................................................................. 52 3.2.12. NFC................................................................................................................... 54 3.2.13. SigFox ............................................................................................................... 56 APLICACIÓN DE LOS PROTOCOLOS DE COMUNICACIÓN SEGÚN LA NECESIDAD ....................................................................................................................... 58 RESULTADOS .................................................................................................................... 59 CONCLUSIONES Y TRABAJOS FUTUROS ................................................................... 61 Bibliografía........................................................................................................................... 6

One solution for TTEthernet synchronization analysis using genetic algorithm

Bezbjednosno-kritični sistemi poput aviona ili automobila zahtijevaju visoko-pouzdanu razmjenu poruka između uređaja u sistemu, što se postiže primjenom determinističkih mreža. Pravilno uspostavljanje međusobne usklađenosti časovnika, kao i konstantno održavanje vremenske usklađenosti, svrstavaju se među najbitnije aspekte determinističkih mreža među kojima su i TTEthernet mreže. Ukoliko časovnici mrežnih uređaja nisu vremenski usklađeni, deterministička razmjena poruka u mreži nije izvodljiva. S obzirom da se informacije o najkritičnijim funkcijama sistema prenose preko determinističke klase poruka, očigledno je da ovakvi servisi neće biti dostupni sve dok se časovnici ne usklade. Teza se bavi procjenom najgoreg slučaja vremena koje je potrebno da protekne da bi se časovnici mrežnih uređaja međusobno uskladili, u slučaju da u mreži postoji jedan uređaj pod otkazom. Procjene su vršene pomoću OMNeT++ simulacija uz primjenu genetskog algoritma. Simulacije pokazuju da se vrijeme neophodno da se uspostavi usklađenost časovnika u TTEthernet mreži značajno povećava pod uticajem uređaja pod otkazom, a samim tim se produžava i vrijeme nedostupnosti najkritičnijih servisa mreže. Simulacije pokazuju da se za mrežu posmatranu u tezi, za izabrane parametre mreže dobija procijenjena vrijednost medijane jednaka 489579μs za najgori slučaj uspostavljanja vremenske usklađenosti u mreži.Safety-critical systems like airplanes and cars demand high-reliable communication between components within the system, which is achieved by using deterministic networks. Proper establishing and maintenance of synchronization of device clocks in the network components represents one of crucial aspects in deterministic networks where belong TTEthernet as well. If device clocks are not synchronized, deterministic communication is not feasible. Keeping in mind that most critical information has been exchanged between the network components using deterministic traffic class, it is obvious that such services will not be available until the clocks in the network are synchronized. The thesis deals with estimation of worst-case startup time for observed TTEthernet network, in case that one device in the network is under failure. The estimation is performed by OMNeT++ simulations and using genetic algorithm. The simulations show that startup time of the network is extended significantly under impact of faulty component. Also, unavailability of most critical services in the network is extended for the same time. For the network simulated in this thesis, estimated median value equals 489579 μs for worst-case startup time