Ethernet-Based and Function-Independent Vehicle Control-Platform: Motivation, Idea and Technical Concept Fulfilling Quantitative Safety-Requirements from ISO 26262

Armbruster, Michael; Fiege, Ludger; Freitag, Gunter; Schmid, Thomas; Spiegelberg, Gernot; Zirkler, Andreas

doi:10.1007/978-3-642-29673-4_9

Cited by 9 publications

(4 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A better CRC polynomial has been proposed in [40], which helps raise the HD of Ethernet CRC to 6 at 1500 bytes payload without any other changes. The bubbling idiot problem in switched Ethernet network could also be solved by the novel network fuses as implemented in [43].…”

Section: B Automotive Ethernet Fault Detection Capabilitymentioning

confidence: 99%

A qualitative comparison of FlexRay and Ethernet in vehicle networks

Zeng

Khalid

Chowdhury

2015

2015 IEEE 28th Canadian Conference on Electrical and Computer Engineering (CCECE)

View full text Add to dashboard Cite

This paper presents a qualitative study of FlexRay and Ethernet in in-vehicle communication networks. Although both protocols have experienced fast growth in the past years, they still have some important deficiencies that deserve attention. This qualitative study has not only outlined the important shortcomings of in-vehicle FlexRay and Ethernet, but also identified their unique competitive edges, respectively. Intensive analyses of both protocols are carried out from three key perspectives: system cost, data transmission capacity and fault detection capability. Some improving approaches have also been pointed out. It is revealed that at the current stage FlexRay is better than Ethernet in transmitting time critical signals deterministically, but has higher cost and complexity. Ethernet, though less deterministic than FlexRay, possesses much greater bandwidth and can transmit data at quite small latency and jitter. This qualitative study has indicated that both protocols need further improvement to meet the requirements of future in-vehicle networks, yet Ethernet may lead the development and expand faster. I. INTRODUCTIONEncoded communication channels have long been used to transmit signals among different controllers in in-vehicle networks. The typical motivations for this fact are: 1) To reduce cable cost. Since wire harness subsystem is the third most expensive and heaviest subsystem after engine and chassis [1], adopting coded communication is obviously a wise strategy to follow. 2) To save package space. As vehicles are built smaller in size but more enriched in functions, routing of wire harness has become increasingly challenging. 3) To cater the demands for higher bandwidth. Nowadays some luxury cars, even not fully featured, already have more than 70 ECUs and 2500 signals to transmit [2], letting alone accommodating the rising demands from ADAS and infotainment systems. 4) To enhance communication safety. Digital transmission has unparalleled advantages in resisting external disturbance over traditional point-to-point analog wires. Moreover, digital signals can be encrypted to further enhance data security in transmission.After LIN (Local Interconnect Network) and CAN (Controller Area Network), FlexRay and Ethernet are two most recently developed wired in-vehicle communication networks. FlexRay was firstly public released in 2004 and has gradually become an ISO standard after 2009. FlexRay is commonly understood as the protocol for X-by-Wire applications, and can provide deterministic communication for chassis and vehicle dynamic controls. BMW is the first

show abstract

Section: B Automotive Ethernet Fault Detection Capabilitymentioning

confidence: 99%

A qualitative comparison of FlexRay and Ethernet in vehicle networks

Zeng

Khalid

Chowdhury

2015

2015 IEEE 28th Canadian Conference on Electrical and Computer Engineering (CCECE)

View full text Add to dashboard Cite

show abstract

“…To minimize the influence between network data with mixed criticalities and mixed transmission rates, the preemption mechanism standardized in TSN is used [7]. Multiple Virtual Local Area Networks (VLANs) are used to define disjoint path for critical data and to protect the network rings from circulating packets [8]. The network guarantees that all sensors and actuators are accessible everywhere in the vehicle, and that critical data is transmitted in a deterministic period of time.…”

Section: The Race Platformmentioning

confidence: 99%

An Automated Electric Vehicle Prototype Showing New Trends in Automotive Architectures

Buechel

Frtunikj

Becker

et al. 2015

2015 IEEE 18th International Conference on Intelligent Transportation Systems

Self Cite

View full text Add to dashboard Cite

Abstract-The automotive domain is challenged by the increasing importance of Information Technology (IT) based functions. To show the possibilities of modern IT systems, a demonstrator car was developed in RACE (Robust and Reliant Automotive Computing Environment for Future eCars) based on a completely redesigned E/E architecture, which supports the integration of mixed-criticality components and offers features like Plug&Play. This paper presents the architecture and components of this vehicle prototype, which is equipped with modern systems such as Steer-by-Wire without mechanical fallback. It was designed to support future driver assistance systems, e.g. to carry out autonomous parking maneuvers onto an inductive charging station, a task, which is hard to achieve accurately enough for a human driver. Therefore, a special emphasis lies on the description of the sensor set for automated operation.

show abstract

“…We tackle the development of a scalable, uniform, open and thus easily expandable base platform with the aim to reduce the complexity of automotive HW/SW architectures. The basic principles of this platform have been already presented in [3] and [4].…”

Section: System Architecturementioning

confidence: 99%

A Formal Model for Constraint-Based Deployment Calculation and Analysis for Fault-Tolerant Systems

Becker

Schätz

Armbruster

et al. 2014

Software Engineering and Formal Methods

Self Cite

View full text Add to dashboard Cite

In many embedded systems like in the automotive domain, safety-critical features are increasingly realized by software. Some of these features are often required to behave fail-operational, meaning that they must stay alive even in the presence of random hardware failures.We propose a new fault-tolerant SW/HW architecture for electric vehicles with inherent safety capabilities that enable fail-operational features. In this paper, we introduce a constraint-based approach to calculate valid deployments of mixed-critical software components to the execution nodes. To avoid harm, faulty execution nodes have to be isolated from the remaining system. We treat the isolations of execution nodes and the required changes to the deployment to keep those software components alive that realize fail-operational features. The affected software components have to be resumed on intact execution nodes. However, the remaining system resources may become insufficient to execute the full set of software components after an isolation of an execution node. Hence, some components might have to be deactivated, meaning that features might get lost. Our approach allows to formally analyze which subset of features can still be provided after one or more isolations. We present an arithmetic system model with formal constraints of the deployment-problem that can be solved by a SMT-Solver. We evaluate our approach by showing an example problem and its solution.

show abstract

Ethernet-Based and Function-Independent Vehicle Control-Platform: Motivation, Idea and Technical Concept Fulfilling Quantitative Safety-Requirements from ISO 26262

Cited by 9 publications

References 0 publications

A qualitative comparison of FlexRay and Ethernet in vehicle networks

A qualitative comparison of FlexRay and Ethernet in vehicle networks

An Automated Electric Vehicle Prototype Showing New Trends in Automotive Architectures

A Formal Model for Constraint-Based Deployment Calculation and Analysis for Fault-Tolerant Systems

Contact Info

Product

Resources

About