System Error Handling Sample Clauses
The System Error Handling clause defines the procedures and responsibilities for managing errors or malfunctions within a system. Typically, it outlines how errors are detected, reported, and resolved, and may specify timeframes for response or escalation protocols. For example, it might require immediate notification to relevant parties if a critical system component fails, or mandate regular system checks to prevent issues. This clause ensures that system disruptions are addressed promptly and efficiently, minimizing downtime and clarifying accountability in the event of technical problems.
System Error Handling. Handling of exceptions, e.g., sensor/actuator failures. The mechanisms being used to orchestrate the skills are service and action calls, re-parameterizations, set values, activating/deactivating of components, etc. We distinguish between function-oriented calls to a running skill component (set values, action queries, etc.) and system-oriented calls to individual or multiple components (switching between component modes, restart, shutdown, etc.). Analogously, we distinguish between function-oriented notifications from the skill layer in form a feed- back on long-running service calls, messages on relevant events in the environment, etc. and system- oriented notifications about component failures, hardware errors, etc. Our observation is that interweaving of task handling, contingency handling, and system error han- dling generally leads to a high complexity of the control flow on the deliberation layer. Yet, we hypothesize that this complexity can be reduced by introducing appropriate abstractions for system- oriented calls and notifications. Therefore, our goal within this work is to provide suitable abstractions and framework functions for (1.) system runtime configuration and (2.) system error and contingency diagnosis, to reduce the effort for the application developer of designing and implementing the task, contingency and error handling. This goal is illustrated in the following example architecture, which is described and managed based on a model file: The main features of the approach are (detailed in the remainder):
System Error Handling. Handling of exceptions, e.g., sensor failures, actuator failures, crashes of software components. The mechanisms being used to orchestrate the skills are service and action calls, re-parameterisations, set values, activating/deactivating of components, etc. We distinguish between function-oriented calls to a running skill component (e.g., set values, action queries) and system-oriented calls to individual or multiple components, e.g., switching between component modes, restart, shutdown. Analogously, we distinguish between function-oriented notifications from the skill layer in form a feedback on long-running service calls, messages on relevant events in the environment, etc. and system-oriented notifications about component failures, hardware errors, etc. To ease handling of this complex communication, micro-ROS provides abstractions and framework functions for (1.) system runtime configuration and (2.) system error and contingency diagnosis, to reduce the effort for the application developer of designing and implementing the task, contingency and error handling. An example is given in the following: The lifecycle and system modes management supports different expansion stages:
1. Mode Management
2. Mode Management and Error Handling
3. Mode Verification and Validation