Search

In order to enable the adoption of Time Sensitive Networking (TSN) by the industry and be more environmentally sustainable, it is necessary to develop tools to integrate legacy systems with TSN. In this paper, we propose a solution for the coexistence of different time domains from different legacy systems with their corresponding synchronization protocols in a single TSN network. To this end, we experimentally identified the effects of replacing the communications subsystem of a legacy Ethernet-based network with TSN in terms of synchronization. Based on the results, we propose a solution called TALESS (TSN with Legacy End-Stations Synchronization). TALESS is able to identify the drift between the TSN communications subsystem and the integrated legacy devices (end-stations) and modify the TSN schedule to adapt to the different time domains to avoid the effects of the lack of synchronization between them. We validate TALESS through both simulations and experiments on a prototype. Thereby we demonstrate that thanks to TALESS, legacy systems are able to synchronize through TSN and even improve features such as their reception jitter or their integrability with other legacy systems.

This paper proposes a method to efficiently map the legacy Ethernet-based traffic into Time Sensitive Networking (TSN) traffic classes considering different traffic characteristics. Traffic mapping is one of the essential steps for industries to gradually move towards TSN, which in turn significantly mitigates the management complexity of industrial communication systems. In this paper, we first identify the legacy Ethernet traffic characteristics and properties. Based on the legacy traffic characteristics we presented a mapping methodology to map them into different TSN traffic classes. We implemented the mapping method as a tool, named Legacy Ethernet-based Traffic Mapping Tool or LETRA, together with a TSN traffic scheduling and performed a set of evaluations on different synthetic networks. The results show that the proposed mapping method obtains up to 90% improvement in the schedulability ratio of the traffic compared to an intuitive mapping method on a multi-switch network architecture., FIESTA - Federated Choreography of an Integrated Embedded Systems Software Architecture

The IEEE Audio Video Bridging (AVB) Task Group (TG) was created to provide Ethernet with soft real-time guarantees. Later on, the TG was renamed to Time-Sensitive Networking (TSN) and its scope broadened to support hard real-time and critical applications. The Stream Reservation Protocol (SRP) is a key work of the TGs as it allows reserving resources in the network, guaranteeing the required quality of service (QoS). AVB's SRP is based on a distributed architecture, while TSN's is based on centralized ones. The distributed version of SRP is supported and used in TSN. Nevertheless, it was not designed to provide properties that are important for critical applications. Therefore, we propose a new version of SRP with enhanced services called Consistent Stream Reservation Protocol (CSRP). In this document we describe the SRP and CSRP UPPAAL models we developed and the queries we used to verify their termination and consistency properties., Comment: 17 pages, 12 figures, uppaal model descriptions, termination and consistency verification

[spa] Este artículo presente al diseño y parcial implementación del sfiCAN: un inyector físico de fallos para el bus CAN que permite la creación de una gran variedad de escenarios de fallos. El inyector de fallos reemplaza la topología bus del CAN por una estrella, cuyo elemento central es un hub con mecanismos de inyección de fallos. El inyector de fallos es fácilmente configurable, desde un PC conectado a un puerto dedicado del hub. Para ello se usa una especificación de inyección de fallos, la cual es traducida a un protocolo de configuración por encima de CAN. Este protocolo sólo es usado entre tests y por ello no interfiere en la ejecución de éstos. El propósito del inyector de fallos es comprobar el comportamiento de los nodos de una red CAN en presencia de errores en el canal. En particular, el comportamiento de los controladores CAN de los nodos y del software que se ejecuta en ellos, para los cuales la topología de estrella es transparente

[spa] Este artículo presente al diseño y parcial implementación del sfiCAN: un inyector físico de fallos para el bus CAN que permite la creación de una gran variedad de escenarios de fallos. El inyector de fallos reemplaza la topología bus del CAN por una estrella, cuyo elemento central es un hub con mecanismos de inyección de fallos. El inyector de fallos es fácilmente configurable, desde un PC conectado a un puerto dedicado del hub. Para ello se usa una especificación de inyección de fallos, la cual es traducida a un protocolo de configuración por encima de CAN. Este protocolo sólo es usado entre tests y por ello no interfiere en la ejecución de éstos. El propósito del inyector de fallos es comprobar el comportamiento de los nodos de una red CAN en presencia de errores en el canal. En particular, el comportamiento de los controladores CAN de los nodos y del software que se ejecuta en ellos, para los cuales la topología de estrella es transparente