Real-Time Robotics Framework

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Safety System ======
The safety system is key to the EEROS framework. It regulates all interaction with the HAL (Hardware Abstraction Layer) and uses a safety level to determine the future course that the robot should take. If the situation becomes less safe, the robot may have its movement restricted to avoid damaging nearby people, materials, or itself.

All critical hardware inputs are read and all critical hardware outputs are driven by the safety system. So called //safety levels// exactly define in which state a robot can be. Such a level could be //initializing//, //homing// or //running//.
===== Key Features of a Safety Level =====
  * A safety level ....
     - has a unique id number
     - has a unique name
     - defines the state of all critical outputs
     - defines conditions for the critical inputs, which are checked periodically by an inspection task
     - can accept certain events 
     - can cause events
  * The order of the safety level numbering corresponds to the potential damage in case of an error
  * The actual safety level can be requested by the //Control System// and the //Sequencer//
  * There are no hidden states in the safety system, such as "do this first, then ...". Each step corresponds exactly to a safety level.

===== Events =====
A change of the safety level can only be caused by an event. An event could be caused by the safety system itself. In this case, we call the event private. It could also be caused by the //Control System// or the //Sequencer//. If so, we call it a public event. \\

Events are exclusively received and handled by the safety system. An event can cause a change of the safety level. Such a change can happen only if this specific event was registered for the current level. The next figure shows a couple of safety levels together with associated events causing a level change.
{{ .:safetysystemevents1.jpg?300 | //Typical safety levels and associated events//}}

  * If the safety system itself causes an event leading to a change of the safety level, this level change takes place only after the safety system completes this run. 
  * Multiple events fired during a single safety period would lead to ambiguities. The event leading to a lower prioritized safety level wins, while the other events are cancelled. 

===== What does the Safety System do ? =====
The most important function of the safety system is its run method. This method is called periodically by the executor. Here's how it works:
<code cpp>
  void SafetySystem::run() {

    // 1) Read inputs and check them
    for(auto ia : level->inputAction) {
      if(ia != nullptr) ia->check(&privateContext);
    }
    
    // 2) Execute level action
    if(level->action != nullptr) level->action(&privateContext);
    
    // 3) Set outputs
    for(auto oa : level->outputAction) {
      if(oa != nullptr) oa->set();
    }
  }
</code>

If you want to learn more about the individual parts of the safety system, look at the links below:

  *[[.:properties|Safety Properties]] 
  *[[.:io_actions|Input / Output Actions]]
  *[[.:usage|Setup a Safety System]]