Search

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

High demands on advanced safety and driving functions, such as active safety and lane departure warnings, increase a vehicle's dependency on automotive electrical/electronic architectures. Hard real-time requirements and high reliability constraints must be satisfied for the correct functioning of these safety-critical features, which can be achieved by using the AUTOSAR (Automotive Open System Architecture) standard. The AUTOSAR standard was introduced to simplify automotive system design while offering inter-operability, scalability, extensibility, and flexibility. The current version of AUTOSAR does not assist in the replication of tasks for recovering from task failures. Instead, the standard assumes that architecture designers will introduce custom extensions to meet such reliability needs. The introduction of affordable techniques with predictable properties for meeting reliability requirements will prove to be very valuable in future versions of AUTOSAR. In this paper, we propose a new Software-Component (SW-C) allocation algorithm called R-FLOW (Reliable application-FLOW-aware SW-C partitioning algorithm) for fail-stop processors to support fault-tolerance with bounded recovery times, and we integrate the R-FLOW algorithm into AUTOSAR. R-FLOW leverages different types of replication schemes to satisfy reliability and timing constraints, while offering a high degree of resource utilization and flexibility. Specifically, R-FLOW classifies real-time periodic tasks into Hard Recovery tasks, Soft Recovery tasks, andBest-Effort Recovery tasks. Hot Standbys are used for recovering from failures of hard recovery tasks, whereas Cold Standbys are utilized for recovering from failures of soft recovery and best-effort recovery tasks. With this goal in mind, we design and implement our proposed architecture within the guidelines of the current AUTOSAR framework. We have built an at-scale prototyping platform, comprising of Freescale HCS12X processing boards, a dual-channel FlexRay bus, and a CAN network. Our proposed architecture is evaluated on this platform using reliability and timeliness metrics in the context of different fault scenarios.

It is desirable that the nodes exhibit fail-silent behavior when designing distributed fault-tolerant systems. Bus Guardian (BG) is adopted to enforce the fail-silence property of the node in the FlexRay communication system. However, the BG is effective only in the static segment while in the dynamic segment it does not provide any protection. Therefore, a novel BG is proposed in this paper. The mechanisms of the novel BG are presented along with the node architecture necessary for implementing the presented technique. Mathematical analysis results show that the novel BG can effectively enforce fail-silence property in the entire FlexRay communication cycle.

This paper describes a process membership protocol for distributed real-time systems that use both time-triggered and event-triggered message passing for communication between its processing nodes (ECUs). TTCAN and FlexRay are examples of communication networks that support such systems. The membership protocol supports redundancy management in architectures where distributed applications such as braking, stability control, and collision mitigation share a common set of processing nodes. We assume that each such application consists of several processes executing on different nodes and that each node executes processes belonging to different applications. The protocol allows a group of cooperating processes to establish a consistent view of each other's operational status, i.e., whether they function correctly or not.

Future automotive applications, like high-speed control in power train or drive-by-wire systems, demand large bandwidth, deterministic communication behavior, and fault tolerance. FlexRay, a new standard communication system, is ideally suited to safety applications as well as applicable to the role of a central backbone in future ECU network architectures. The FlexRay physical layer specification is kept very generic to provide the network designer with a wide range of possibilities for optimization of the network implementation. Due to the highly transient behavior of the system, the developer of the network physical layer cannot manually predict the behavior of an entire FlexRay topology. To analyze design concepts like topologies, terminations, and ECU architectures much earlier in development phase, simulation is the only choice. Simulation can be used to predict physical behavior and to verify the physical layer implementation of a FlexRay network while accounting for component and environmental variations. Accordingly, the developer can use simulation in the design of a robust network to investigate the influence and interoperability of new components and ECU interfaces with the goal of improving quality in automotive networks. Using virtual prototypes or production networks in conjunction with Robust Design methods, the developer can analyze network extensions (e.g. through automated wire length variations) and verify the impact of device tolerances. This paper describes the required elements for simulating the FlexRay physical layer, including simulation models, simulation scenarios, and post-processing mechanisms needed to sufficiently evaluate system behavior. AUTOMOTIVE MARKET AND IN-VEHICLE NETWORKS Automotive networks, also known as in-vehicle networks, are used to connect sensors, actuators, and ECUs (Electronic Control Units) together while minimizing the amount of wiring required. This allows for easy sharing of available information among ECUs without integration of redundant hardware like additional wiring harnesses and associated connectors. This also leads to more modular distributed electronics along with heterogeneous network architectures. Virtually every new vehicle platform contains multiple communication networks, where several different protocol types are applied to address the needs of individual applications. The main categories of applications and their related protocols can be divided as follows: • Infotainment: MOST, D2B • Powertrain: CAN, FlexRay • Safety systems: FlexRay • Body electronics: LIN, CAN The costs of networked electronics in today’s mid-size Figure 1: Automotive bus systems on the world market (Source: Strategy Analysis) cars are already in the range of 40% of the total vehicle development costs. Figure 1 forecasts the increase of vehicle networking protocols used in automotive systems. The complexity of today’s vehicle networks has been increasing over the past years and will continue to increase in the future as more content for safety and comfort is integrated into the vehicle. This requires a well-defined and robust in-vehicle network that must guarantee safe and correct data communication while being robust to internal and external influences. This is the challenge of the network engineer responsible for the embedded and physical layer of the network. Unlike the embedded world, the physical layer of in-vehicle networks does not have an ideal logical behavior. There is a significant analog behavior of the physical layer that must be taken into consideration. The dependencies between analog components creates a significant challenge in the design in a system with an infinite number of variants, as no manual computation or any analytical solution exists that describes the complete behavior of the analog network. The following section describes the challenges network engineers face when they deal with the development of the physical layer implementation of FlexRay designs and how this challenge can be addressed using system simulation. FUNDAMENTALS OF FLEXRAY FlexRay was created at the end of the 1990’s by Automotive OEMs and suppliers. It is intended for applications that need high speed data transfer and timetriggered communication, like closed-loop control systems requiring hard real-time performance. FlexRay allows a variety of topology types while taking into account the physical constraints that are present in a system. Figure 2 shows a possible topology consisting of eight nodes and two active stars. The local timing information of each node is synchronized through the FlexRay protocol. The communication cycle in FlexRay consists of several segments, as shown in Figure 3. All message frames in the static segment have the same length while the lengths of frames in the dynamic segment can be adjusted as needed. Every communication starts with a Transmission Start Sequence (TSS) as shown in Figure 4. The TSS is a continuous low for a period defined for the network cluster and is used to open the gates of active stars and indicate the start of a FlexRay communication. Detailed information about the communication process is given in [1]. Each byte of the payload starts with the Byte Start Sequence (BSS), where the falling edge of the BSS is used to synchronize the local timing with the global time. The frames are terminated through the Frame End Sequence (FES). For frames inside the dynamic segment of the communication cycle, the FES is followed by the Dynamic Trailing Sequence (DTS), which is used to define the action point in the dynamic segment. In order to transmit signals across the network, a physical layer is needed to define how the logical states are represented by electrical voltages. The FlexRay Electrical Physical Layer (EPL) specification [2] describes the basic requirements for hardware used for this application, like bus drivers and active stars. In addition, the EPL specification gives rough recommendations on additional elements like common mode chokes and ESD protection components. The specification neither dictates nor prescribes the system implementation of the physical layer. In addition to the flexibility related to the choice of hardware components, FlexRay allows also a wide range of topology types. Possible topologies are

This paper makes an analytical overview of a hybrid network for off-highway vehicles where ISOBUS and FlexRay protocols co-exist. A functional analysis has been conducted and a methodo logy for a quantitative evaluation of the overall system (in terms of performance and reliability) is carried out.

Distributed systems in vehicles based for example on FlexRay require new approaches to testing. Testing solutions have to ensure the correct operation of the communication infrastructure as well as to assess the correct behavior of the application.

FlexRay is a new communication subsystem for future in-vehicle controls. There is a lack of mature model-based development methodologies to build complex FlexRay-based systems. In this paper we describe an end-to-end model-based development process for building a complex FlexRay-based distributed control system. We describe this in the context of safety critical x-by-wire systems for a realistic automotive application. This involves: control system modeling, functional simulation, and distributed software development. We first describe the process of functional and physical architecture design. Next we discuss the software development process dealing with software to hardware allocation, as well as scheduling of software and communication tasks on a time-triggered communication bus under stringent practical restrictions. We conclude by considering the integration issues relating to joint OEM/supplier development of distributed control systems. The above experience has been obtained during the model-based development of a FlexRay-based control system for a vehicle, which features by-wire steering, braking and propulsion.

Due to the increase in demand for comfort and safety features in today's automobiles, the internal vehicle communication networks necessary to accommodate these features are very complex. These networks represent a heterogeneous architecture consisting of several ECUs exchanging information via bus systems such as CAN, LIN, MOST, or FlexRay buses. Development and verification of internal vehicle networks include multiple design layers. These layers are the logical layer represented by the software application, the associated data link layer, and the physical connection layer containing bus interfaces, wires, and termination. Verification of these systems in the early stages of the design process (before a physical network is available for testing) has become a critical need. As a result, the need to simulate these designs at all their levels of complexity has become critically important. Internal vehicle networks can be simulated on many different ion levels using various model levels and modeling technologies. Early in the development process, analyses can be performed without having available any detailed models from the chip manufacturer or component supplier. Later in the development process, more accurate models can be integrated into the simulation process, including those provided by suppliers and chip manufacturers. This paper demonstrates a portion of the development and verification process of the physical layer of an internal vehicle CAN bus at Volkswagen using the Saber simulation environment. This paper also demonstrates the integration of portions of the logical layer into simulation so both logical and physical layers can be analyzed together.