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: Figure 2: System modes architecture The lifecycle and system modes management supports different expansion stages:
