X-by-Wire Systems: Software Architecture and Development Process, Slides of Electrical Engineering

Download X-by-Wire Systems: Software Architecture and Development Process and more Slides Electrical Engineering in PDF only on Docsity!

X-by-Wire Systems

Software development process

-Vinay N

Introduction- Steer by wire and Brake by wire

THE WAY TOWARDS X-BY-WIRE SYSTEMS

x-by-wire systems will most likely be higher-level, global control systems that coordinate all chassis systems (braking, steering, damping, powertrain)

A dedicated ECU to implement control algorithms.The control algorithms will move into the various chassis ECUs which gets implemented as distributed system

Current Network architecture

● Single central ECU performing the entire control algorithm for a single mechanical or hydraulic subsystem.

● Star-topology wiring to the sensors and actuators connecting the ECU to the controlled system

● ECU is usually equipped with self-checking mechanisms (watchdog or dual CPU). If one of these mechanisms detects an error, the controller resets and remains passive.

Topology of X by wire system

● Star topology has better fault tolerance than other topology (Bus topology) ● A single component failure may only affect one connection between a node computer and the central star coupler ● By using appropriate strategies for redundancy ,failure of central star coupler can be resolved.

Software Architecture of X by wire system

● The main objective of the software architecture is the re-use of individual functions, which are stored as software modules in a function repository

● Software carry-over parts (COP) that can be used multiple times across car lines and vehicle variants

● Open software architecture, which enables portability and re-use of individual software modules, ensures correct diagnosis of faults, and which supports safety and fault tolerance functions

SW Development - Sub components

Task Management : A task defines an autonomous single threaded piece of application software that is designed to potentially run in parallel with other tasks.Tasks are executed sequentially starting at the entry point and running to the exit point. Processing Levels :Each task and interrupt service routine (ISR) is statically assigned to one processing level that defines its priority. Further classified into 3 types

1. Non-maskable interrupt service routines and the OSEKtime dispatcher (highest processing range),
   2. maskable interrupt service routines and time triggered tasks (time-triggered processing range),
   3. background task or OSEK/VDX subsystem (lowest processing range).

SW Development - Sub components

MIDDLEWARE LAYER : A middleware layer is responsible for the interaction between the communication network and the application software. For the application, communication across a data network must be equivalent to the inter-task communication that is done locally within a single ECU. It provides the necessary services to support fault-tolerant hard realtime distributed applications. In the following these services are described

1. Message Transmission : Transmission of messages and its related services is the most important task of the fault-tolerant communication layer.
2. Redundancy Management :In safety-related applications, certain messages are transmitted multiple times, in order to prevent message loss and to tolerate transient faults
3. Agreement and Message Filtering :Provides predefined agreement algorithms and a framework for user defined agreement algorithms.