Time-triggered Communication Protocol Research Articles

Scheduling periodic task graphs for safety-critical time-triggered avionic systems

Time-triggered communication protocols, such as time-triggered protocol (TTP) and FlexRay, have the potential to solve many system integration and concurrent engineering issues in the aerospace industry. This paper investigates the scheduling of periodic applications on time-triggered systems. A novel scheduling problem is formulated to capture a unique feature commonly existing in the safety-critical time-triggered systems, i.e., in task graphs running in such systems, some nodes (i.e., tasks and messages) are strictly periodic while others are not. To address the problem, a novel scheduling algorithm called synchronized highest level first (SHLF) algorithm is presented. Moreover, to further improve schedulability, this paper also proposes two rescheduling and backtracking approaches, namely release time deferment (RTD) procedure and backtracking and priority promotion (BPP) procedure. Performance evaluation results are presented to demonstrate the effectiveness and competitiveness of our approaches when compared with existing algorithms.

Holistic Scheduling of Real-Time Applications in Time-Triggered In-Vehicle Networks

As time-triggered communication protocols [e.g., time-triggered controller area network (TTCAN), time-triggered protocol (TTP), and FlexRay] are widely used on vehicles, the scheduling of tasks and messages on in-vehicle networks becomes a critical issue for offering quality-of-service (QoS) guarantees to time-critical applications on vehicles. This paper studies a holistic scheduling problem for handling real-time applications in time-triggered in-vehicle networks where practical aspects in system design and integration are captured. The contributions of this paper are multifold. First, it designs a novel scheduling algorithm, referred to as <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Unfixed Start Time</i> (UST) algorithm, which schedules tasks and messages in a flexible way to enhance schedulability. In addition, to tolerate assignment conflicts and further improve schedulability, it proposes two rescheduling and backtracking methods, namely, <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Rescheduling with Offset Modification</i> (ROM) and <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Backtracking and Priority Promotion</i> (BPP) procedures. Extensive performance evaluation studies are conducted to quantify the performance of the proposed algorithm under a variety of scenarios.

An Automated Model Based Design Flow for the Design of Robust FlexRay™ Networks

The enormous increase of vehicle functions realized through electronic components significantly impacts the communication within the vehicle network. More functions are requesting higher bandwidth; safety applications require a deterministic communication scheme to ensure reliable system performance even under harsh real world conditions. The new FlexRay vehicle communication standard addresses these requirements, with production networks already on the road. The high transmission rate introduces new challenges for network developers dealing with the implementation of the electrical physical layer as the dynamic behavior of the system cannot be predicted using manual calculations. The FlexRay physical layer working group has therefore established a simulation task force dealing with issues related to FlexRay's physical layer implementation. This task force has developed a virtual prototype based methodology to give network developers early verification of FlexRay physical layer implementations. Topology variants that depend on equipment in the vehicle can be investigated quickly with regard to their robustness under nominal and even worst case conditions. This paper introduces an automated, simulation-based methodology based on the guidelines and criteria defined in the FlexRay physical layer specification. In addition, this paper shows how close OEMs, IC vendors, conformance testers and software tool vendors must work together to define and realize a robust design methodology that is based on a virtual prototype implementation of the FlexRay network. BASICS OF FLEXRAY COMMUNICATION SYSTEMS When developers are dealing with In-Vehicle network implementations they have to ensure that both the software part as well as the electrical physical implementations is robust. The design and verification of both parts is usually very time-consuming. Sufficient testing is not possible using vehicle hardware prototypes since these are usually not available in the very early design stage when network concepts need to be evaluated in terms of their robustness. This paper shows how to design and verify the physical layer implementation of FlexRay systems through an automated and robust simulation based engineering method. The focus of this paper is on the verification methodology. Details about the FlexRay protocol and how to model them are comprehensively described in [4]. The FlexRay protocol and its electrical physical layer are specified in the FlexRay protocol and the Electrical Physical Layer (EPL) specification. These activities are standardized through the FlexRay consortium which is a society of all major automotive OEMs and their suppliers. Unlike the most popular CAN communication protocol, FlexRay is a time triggered communication protocol with a maximum transmission rate of 10 MBit/s. This is 10x higher than the theoretical transmission rate of CAN which is 1 MBit/s (in practical applications the transmission rate of CAN is usually below 1 MBit/s to ensure enough robustness). FlexRay allows arbitrary topology types like linear, star, or even hybrid as shown in figure 1. Figure 2 shows a possible future vehicle Figure 1: FlexRay topology (source FlexRay EPL) 2008-01-1031 An Automated Model Based Design Flow for the Design of Robust FlexRayTM Networks

Reuse of CAN-Based Legacy Applications in Time-Triggered Architectures

Upcoming car series will be deployed with time-triggered communication protocols due to benefits with respect to bandwidth, predictability, dependability, and system integration. In present day automotive networks, controller area network (CAN) is the most widely used communication protocol. Today, up to five CAN buses and several private CAN networks result from the bandwidth limits of CAN in conjunction with constraints concerning bus utilization aimed at controlling transmission latencies. In this context, the upcoming introduction of time-triggered networks into series production offers the potential to reduce the number of CAN networks by exploiting the high bandwidth of the time-triggered network instead of CAN buses. Due to the elimination of CAN buses, the resulting reduction of wiring and connectors promises a significant reduction in hardware cost and reliability improvements. In order to support the reuse of existing CAN-based application software, this paper presents a solution for the emulation of a CAN communication service on top of an underlying time-triggered network. By providing to CAN-based applications the same interface as in a conventional CAN system, redevelopment efforts for CAN-based legacy software are minimized. For this purpose, a CAN emulation middleware operates between a operating system and the CAN-based applications. In a first step, the middleware establishes event channels on top of the communication network in order to support on-demand transmission requests at a priori unknown points in time. The middleware then emulates the carrier sense multiple access collision avoidance (CSMA/CA) media access protocol of a physical CAN network for passing messages received via event channels to the application in the correct temporal order. Finally, the application programming interface (API) of the widely used HIS/VectorCAN driver provides a handle-based programming interface with support for message filtering and callbacks. A validation setup with a time-triggered protocol (TTP) cluster demonstrates that the CAN emulation can handle CAN-based legacy software and a real-world communication matrix provided by the automotive industry

A standard for real-time smart transducer interface

Abstract In order to handle the inherent complexity of the multitude of available different transducer components, a generic interface approach is necessary. Such a universal smart transducer interface should provide precisely defined interfaces between smart transducers and their users, which are simple and precisely specified within the value domain and the temporal domain. The Object Management Group adopted a smart transducer interface standard that incorporates (i) real-time characteristics and functionalities for the smart transducer network (ii) online diagnostic service capability (iii) support for start-up and dynamic configuration (iv) a uniform naming and addressing scheme for all relevant data in the smart transducer system (v) a generic interface that enables the smart transducer system to interact with other systems via CORBA. This paper describes the main concepts and implementation experiences of this smart transducer interface. The approach integrates a time-triggered communication protocol with an appropriate access scheme, the so-called interface file system. This interface file system provides a unique naming and addressing scheme enabling access to internal transducer data via a CORBA gateway.

The time-triggered architecture

The time-triggered architecture (TTA) provides a computing infrastructure for the design and implementation of dependable distributed embedded systems. A large real-time application is decomposed into nearly autonomous clusters and nodes, and a fault-tolerant global time base of known precision is generated at every node. In the TTA, this global time is used to precisely specify the interfaces among the nodes, to simplify the communication and agreement protocols, to perform prompt error detection, and to guarantee the timeliness of real-time applications. The TTA supports a two-phased design methodology, architecture design, and component design. During the architecture design phase, the interactions among the distributed components and the interfaces of the components are fully specified in the value domain and in the temporal domain. In the succeeding component implementation phase, the components are built, taking these interface specifications as constraints. This two-phased design methodology is a prerequisite for the composability of applications implemented in the TTA and for the reuse of prevalidated components within the TTA. This paper presents the architecture model of the TTA, explains the design rationale, discusses the time-triggered communication protocols TTP/C and TTP/A, and illustrates how transparent fault tolerance can be implemented in the TTA.