System Architecture and Safety



Design Philosophy

The system architecture of the ROMO, with its multitude of intelligent mechatronic systems and functionalities, takes advantage of the design freedom provided by its development from a clean slate. A hierarchical approach enables the hardware and the associated functions to be abstracted from the higher level algorithms, thereby permitting the complexity to be better managed and software modules to be more easily modified or replaced. The centralised control enables the use of higher performance global control strategies. Furthermore, safety is an important consideration in the development of the architecture.

Higher performance through centralised control

From the outset, the system was designed to provide levels of abstraction roughly divided into E/E hardware, vehicle dynamics, user inputs, and autonomous systems. The abstraction allows the development of robust algorithms with clear paths of communication, as well as simplified processes for modification and replacement of experimental software.

Even as a prototype, the requirements for safe operation have a large influence on the design of system architecture. These include:

  • Reliable management of the electrical system functions
  • Limp-home in the case of faults in complex experimental control algorithms or communication bus failures
  • Back-up power supplies
  • Health monitoring of hardware and software components

System Architecture

The architecture stems from that of intelligent robots, which utilize a hierarchical structure in which the driver inputs and the autonomous system commands are combined before these are passed to the vehicle dynamics control. This in turn makes use of vehicle sensors and intelligent actuators (the wheel robots) to translate these commands into vehicle motion. The driver inputs are determined by the sidestick, touchscreen and other HMI devices, while the autonomous system determines its commands based on information from a combination of environmental sensors and ego-motion sensors. The centralised control enables the use of higher performance global control strategies. See the diagram for an illustration of this scheme. See also the specific sections for HMI, autonomous system, vehicle dynamics control and wheel robots for further details on these components of the system architecture.

 

System Architecture of the ROboMObil


The central control of the basic operation of the ROboMObil’s electrical systems, actuators and sensors for the realization of vehicle motion is carried out using real-time rapid-prototyping hardware from dSpace GmbH. A multi-platform computing architecture is employed, such that the varying properties for the different tasks can be fulfilled. For example, the safety critical management and monitoring of the high-voltage and low-voltage electrical systems, which also requires fast start-up and shutdown behaviuor as well as access to a large number of hardware I/Os, is executed on the Power-PC based MicroAutobox. The advanced vehicle dynamics control and estimation, on the other hand, are executed on the more computationally powerful PC-based multi-core AutoBox. The platforms are connected via high-speed data links.


Fault Monitoring and Fault Handling

The detection of faults and appropriate handling is an important part of ensuring that the ROboMObil remains in a safe state of operation. The fault management module is divided into four sequential components: diagnosis, grouping, assignment of reactions, and the execution of reactions. The diagnosis component detects and isolates individual faults based on the monitored signals, employing methods ranging from the logical analysis of discrete signals, to making use of hardware and analytical redundancy to general residuals. The grouping stage then groups the faults which should be handled using the same fault reactions. For example, a damaged brake caliper and a motor failure at the brake actuator may be detected separately, but both lead to the same effect that braking is not possible. Therefore the vehicle level reactions to these faults are the same. The reaction assignment component triggers the necessary reactions upon the detection of corresponding faults. The execution of reactions is carried out decentrally in the architecture and is often embedded in other parts of the hardware.

The faults to be detected and mitigated were determined by a Failure Mode and Effects Analysis (FMEA). As a prototype not driving on public roads, the most important task of the safety system is to bring the vehicle safely to a stop when a fault is detected. The following is one example of the diagnosis to reaction chain:

 

Fault Loss of CAN to the front axle actuators
Detection CAN watchdog missing / counter not counting
Grouping Front axle actuators
Reaction

Brake using the rear axle friction brakes; Front brakes are configured to automatically engage when CAN communication is lost with the central controller

Other than the basic fault detection to ensure the safety of the vehicle and its occupant, we are also developing more sophisticated techniques which perform consistency checks between the measured behaviours and the expected behaviours. These will enable the detection of additional faults as well as higher detection sensitivities.


URL dieses Artikels
http://www.dlr.de/rmc/rm/desktopdefault.aspx/tabid-8001/13698_read-34737/