Controller Area Network

Controller Area Network (CAN) is a popular and very well-known bus system, both in academia and in industry. CAN protocol was introduced in the mid eighties by Robert Bosch GmbH [7] and it was internationally standardized in 1993 as ISO 11898-1 [24]. It was initially designed to distributed automotive control systems, as a single digital bus to replace traditional point-to-point cables that were growing in complexity, weight and cost with the introduction of new electrical and electronic systems. Nowadays CAN is still used extensively in automotive applications, with an excess of 400 million CAN enabled microcontrollers manufactured each year [14]. The widespread and successful use of CAN in the automotive industry, the low cost asso- ciated with high volume production of controllers and CAN's inherent technical merit, have driven to CAN adoption in other application domains such as: industrial communications, medical equipment, machine tool, robotics and in distributed embedded systems in general. CAN provides two layers of the stack of the Open Systems Interconnection (OSI) reference model: the physical layer and the data link layer. Optionally, it could also provide an additional application layer, not included on the CAN standard. Notice that CAN physical layer was not dened in Bosch original specication, only the data link layer was dened. However, the CAN ISO specication lled this gap and the physical layer was then fully specied. CAN is a message-oriented transmission protocol, i.e., it denes message contents rather than nodes and node addresses. Every message has an associated message identier, which is unique within the whole network, dening both the content and the priority of the message. Transmission rates are dened up to 1 Mbps. The large installed base of CAN nodes with low failure rates over almost two decades, led to the use of CAN in some critical applications such as Anti-locking Brake Systems (ABS) and Electronic Stability Program (ESP) in cars. In parallel with the wide dissemination of CAN in industry, the academia also devoted a large eort to CAN analysis and research, making CAN one of the must studied eldbuses. That is why a large number of books or book chapters describing CAN were published. The rst CAN book, written in French by D. Paret, was published in 1997 and presents the CAN basics [32]. More implementation oriented approaches, including CAN node implementation and application examples, can be found in Lorenz [28] and in Etschberger [16], while more compact descriptions of CAN can be found in [11] and in some chapters of [31]. Despite its success story, CAN application designers would be happier if CAN could be made faster, cover longer distances, be more deterministic and more dependable [34]. Over the years, several protocols based in CAN were presented, taking advantage of some CAN properties and trying to improve some known CAN drawbacks. This chapter, besides presenting an overview of CAN, describes also some other relevant higher level protocols based on CAN, such as CANopen [13], DeviceNet [6], FTT-CAN [1] and TTCAN [25]

Application Agreement and Integration Services

Application agreement and integration services are required by distributed, fault-tolerant, safety critical systems to assure required performance. An analysis of distributed and hierarchical agreement strategies are developed against the backdrop of observed agreement failures in fielded systems. The documented work was performed under NASA Task Order NNL10AB32T, Validation And Verification of Safety-Critical Integrated Distributed Systems Area 2. This document is intended to satisfy the requirements for deliverable 5.2.11 under Task 4.2.2.3. This report discusses the challenges of maintaining application agreement and integration services. A literature search is presented that documents previous work in the area of replica determinism. Sources of non-deterministic behavior are identified and examples are presented where system level agreement failed to be achieved. We then explore how TTEthernet services can be extended to supply some interesting application agreement frameworks. This document assumes that the reader is familiar with the TTEthernet protocol. The reader is advised to read the TTEthernet protocol standard [1] before reading this document. This document does not re-iterate the content of the standard

Safety-Critical Communication in Avionics

The aircraft of today use electrical fly-by-wire systems for manoeuvring. These safety-critical distributed systems are called flight control systems and put high requirements on the communication networks that interconnect the parts of the systems. Reliability, predictability, flexibility, low weight and cost are important factors that all need to be taken in to consideration when designing a safety-critical communication system. In this thesis certification issues, requirements in avionics, fault management, protocols and topologies for safety-critical communication systems in avionics are discussed and investigated. The protocols that are investigated in this thesis are: TTP/C, FlexRay and AFDX, as a reference protocol MIL-STD-1553 is used. As reference architecture analogue point-to-point is used. The protocols are described and evaluated regarding features such as services, maturity, supported physical layers and topologies.Pros and cons with each protocol are then illustrated by a theoretical implementation of a flight control system that uses each protocol for the highly critical communication between sensors, actuators and flight computers.The results show that from a theoretical point of view TTP/C could be used as a replacement for a point-to-point flight control system. However, there are a number of issues regarding the physical layer that needs to be examined. Finally a TTP/C cluster has been implemented and basic functionality tests have been conducted. The plan was to perform tests on delays, start-up time and reintegration time but the time to acquire the proper hardware for these tests exceeded the time for the thesis work. More advanced testing will be continued here at Saab beyond the time frame of this thesis

Unification of Transactions and Replication in Three-Tier Architectures Based on CORBA

In this paper, we describe a software infrastructure that unifies transactions and replication in three-tier architectures and provides data consistency and high availability for enterprise applications. The infrastructure uses transactions based on the CORBA object transaction service to protect the application data in databases on stable storage, using a roll-backward recovery strategy, and replication based on the fault tolerant CORBA standard to protect the middle-tier servers, using a roll-forward recovery strategy. The infrastructure replicates the middle-tier servers to protect the application business logic processing. In addition, it replicates the transaction coordinator, which renders the two-phase commit protocol nonblocking and, thus, avoids potentially long service disruptions caused by failure of the coordinator. The infrastructure handles the interactions between the replicated middle-tier servers and the database servers through replicated gateways that prevent duplicate requests from reaching the database servers. It implements automatic client-side failover mechanisms, which guarantee that clients know the outcome of the requests that they have made, and retries aborted transactions automatically on behalf of the clients

Advanced information processing system: The Army fault tolerant architecture conceptual study. Volume 1: Army fault tolerant architecture overview

Digital computing systems needed for Army programs such as the Computer-Aided Low Altitude Helicopter Flight Program and the Armored Systems Modernization (ASM) vehicles may be characterized by high computational throughput and input/output bandwidth, hard real-time response, high reliability and availability, and maintainability, testability, and producibility requirements. In addition, such a system should be affordable to produce, procure, maintain, and upgrade. To address these needs, the Army Fault Tolerant Architecture (AFTA) is being designed and constructed under a three-year program comprised of a conceptual study, detailed design and fabrication, and demonstration and validation phases. Described here are the results of the conceptual study phase of the AFTA development. Given here is an introduction to the AFTA program, its objectives, and key elements of its technical approach. A format is designed for representing mission requirements in a manner suitable for first order AFTA sizing and analysis, followed by a discussion of the current state of mission requirements acquisition for the targeted Army missions. An overview is given of AFTA's architectural theory of operation