Scheduling of a Robot’s Tasks With the TaskER Framework

Robots, in contrast to typical computational systems, affect the physical environment directly. Therefore, other assumptions must be considered for task management procedures in these system types. Robots coexist with humans in the environment and act upon potentially dangerous objects (e.g., a cooker); hence, extra safety procedures in robot task harmonisation must be ensured. Additionally, an algorithm that schedules tasks for a robot and optimises the robot’s operation needs to consider the robot motion time, dynamics of the physical processes, changes in the robot user preferences and changes in the environment made by other habitants. In this article, we investigate the problem of switching between various independent tasks safely and state requirements for a control system resolving it. The tasks are uploaded to a store, launched on a robot at the user’s request (similar to smartphone applications) and scheduled following a configurable algorithm. Furthermore, we design a model of systems satisfying the requirements. The systems are structured with agents of different classes. We propose a task-switching procedure and dedicated states of the finite-state machines describing the operation of the agents. Finally, we present a TaskER framework implementing the model, and we verify the model through the execution of an exemplary system in scenarios showing the benefits of the model implementation. As a result of our approach application, the robot tasks can be safely interrupted, postponed, resumed, and potential danger (e.g., leaving a cooker on for a long time) can be minimised.


I. INTRODUCTION
The development of cutting-edge technology increases the applicability, universality and popularity of robots. In the robot classification according to application field that was published in [1], there are 2 main branches (industrial and service robots), which are compositions of lower-level robot classes. The inspection of the service robot branch reveals the versatility of the applications that assist humans in, e.g., the areas of medicine (home care and telehealthcare [2]), home (automated vacuum cleaners [3]), education (multiagent platform for teaching mobile robotics [4], a survey of robotics for education [5]) and defence (a security robot for human-robot interaction [6]). The applications differ in terms of their constraints and requirements for robotic systems. For example, robots for medicine are typically targeted to The associate editor coordinating the review of this manuscript and approving it for publication was Fabrizio Messina . maximise human safety and personnel convenience, whereas industrial robots optimise production quality and quantity. In each application, robots conduct various tasks (e.g., personnel assistance [7], object transportation [8], or therapy [9] in medicine). Some tasks demand computational power and storage that exceed those that are delivered with a robot. Therefore, robotic systems are being supported by cloud computing [10]. In multi-robot systems, the cloud delivers common system-wide services for various robots or enables cooperation of the robots [11]. One example of such a service is a task store [12], which enables application domain experts to compose and deploy new tasks to the system.
The recent COVID-19 pandemic highlights a need for easy and convenient robot task configuration, especially in unexpected scenarios. Using the task store, robots that are available in galleries or at universities can be easily configured to help medical personnel at hospitals [13]. The tasks can be requested via multiple human-machine interfaces (Internet VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ of Things devices [14] or human-robot interfaces [15], [16]) by various operators (e.g., medical personnel or patients) at any time during the operation of the robot. Moreover, not all task requests are consulted between users, and it may be necessary to interrupt a task with another if the scenario changes. Therefore, the robots must manage their tasks and be able to suspend and resume them. The above problems concern various applications of robots; hence, robotic systems are complicated and require a straightforward development method. The model-driven engineering approach, which is based on the model concept, facilitates the design procedure of a system and prevents the influence of cognitive biases [17] on the design of the system architecture at the initial phase [18].
In our analysis of various robotic systems, a set of typical use cases was identified, while the robots switch from one task to another. In the following part of this section, we define the problem of our work by description of the use cases and specification of the requirements for a robot system with modular tasks. The system is enhanced with task scheduling and cloud computing. At the end of the introduction, we discuss the contributions, applicability and concept of our work. In the subsequent Section II, a formal model of a robot control system that satisfies the requirements and follows the concept is described. Next, in Section III, we evaluate our approach via proposition of a verification scenario, implementing the model in the TaskER (Task schedulER) framework, and configuration and execution of an exemplary system. Furthermore, we describe how the system satisfied the requirements during the scenario execution. Finally, we discuss related works in the areas of robot system architectures, task models and task switching approaches for robots (Section IV), and we present the conclusions of our study in Section V. In Appendix A we show cooperation of the system parts in the proposed task switching procedure and in Appendix B we describe the analysis of the conducted verification proving that the exemplary system has the functionality required by the initial problem definition.

A. USE CASES AND REQUIREMENTS
The use cases of a robot system that are considered in this study are presented in Tab. 1. There are two classes of actors who interact with the robot system: developers and users. Based on an analysis of the use cases (which are described in the following subsections), the requirements for the system management of the use cases are formulated.

1) USE CASE -TASKS AS MODULAR EXTENSIONS
There are many possible duties that a robot can perform for its users. For example, in the area of helping elderly people, the study [19] identified multiple activities that threaten independent living in mobility, self-care and social interaction. Therefore, robots should be able to manage multiple tasks and extend the task set even after the system deployment according to the user's demands. A similar problem occurs in the smartphone market, and the solution is the use of an application store, which collects independent programs that can be downloaded and launched upon the request of a user. The application store of the service robot market must contain various tasks. Furthermore, as multiple tasks are available and are uploadable to the robot system on the fly, they must be independent.

2) USE CASE -EASE OF CONFIGURATION OF THE SCHEDULING ALGORITHM
Robot systems resolve various problems in many sectors, such as industry [20], healthcare [21] and entertainment [22]. These sectors optimise robot usage to realise various objectives, e.g., in industry, to maximise production quality and quantity, and in healthcare, to minimise the time and effort of nurses and medical personnel. In contrast, robots at the homes of elderly people should optimise the comfort and safety of these individuals. To realise various objectives, the robot controller must utilise a configurable scheduling algorithm that computes scheduling decisions that optimise the cumulative cost during the robot operation. Furthermore, the cost function can change with time and can depend on the specified task (e.g., as the delay in a task of water transportation to an elderly person increases, his/her discomfort and danger increases). Schedule parameters that are used to compute the costs and scheduling decisions can have various forms. Typically, priorities and temporary constraints are used as schedule parameters; however, they can be of any form that reflects the main objective of the robot system (e.g., a scheduling algorithm of a system for helping elderly people can maximise their comfort as a schedule parameter).

3) USE CASE -COEXISTENCE IN A SHARED ENVIRONMENT
Robots interact with the physical environment and affect it by their actions, which compose their tasks. Although the effects of their actions are immediate (turning on a cooker), the objective of the task will be completed with a delay (e.g., boiling water on the cooker) [23]. Therefore, the robot controller must be aware of the potential damage, injury or loss that can be caused by an interruption of an ongoing task (e.g., while a new task is initiated, a cooker remains on during realisation of the new task). Thus, the robot controller must not only consider the current state of the environment but also foresee the future effects of the current actions. Unfortunately, it is difficult to design a comprehensive model of an environment for estimating its state in the future based on the robot actions. Models of tasks are available that describe how the environment changes while the task proceeds [24]. However, even though the effects of the robot's actions are estimable, the environment can also be changed by other actors (such as humans, robots, and animals).
Cooperation with humans is a difficult problem, as humans differ in many aspects, and it is difficult to model their behaviours and needs. These problems also impact the task switching for human-robot collaboration. For example, a task deadline depends on high-level abstract conditions, 1 a user may change his mind regarding the priorities of the requested tasks, or a user can perform a part of a queued task.

4) SYSTEM REQUIREMENTS
We state the following requirements for a robot controller to enable the task harmonisation feature and address the problems that are identified in the above use cases: R1 -the robot controller must maintain additional activities to enable advised task switch. It constantly listens to new task requests, even as the robot proceeds with a task, and potential switching between the ongoing task and the new task is managed as soon as possible; R2 -the values of the schedule parameters that are used to compute scheduling decisions (e.g., priorities) are dynamically changing even if a task awaits execution, and if one of the parameters changes, then the scheduling algorithm is initiated. The parameters can be either task context-dependent or system-wide; R3 -both the algorithm and the parameters that are used in the scheduling procedure depend on a system application and must be configured based on the system requirements; R4 -the tasks that are available in the system are created independently and differ in terms of knowledgebase and context; R5 -developed architecture must raise awareness of the task developer to foresee possible dangerous situations caused by a task switch. Additionally, the tasks execution method needs to enable independent tasks to oversee changes in the environment and in the system in order to change task-dependent schedule parameters. Furthermore, the ongoing task needs to be safely suspended before the controller switches to another task. As a result of this, a possible robot/environment damage or other loss due to a task interruption must be limited; and R6 -a task plan and the initial conditions of its primitive actions may change while the task awaits execution or resumption.

B. CONTRIBUTIONS AND APPLICABILITY
In our study, we introduce TaskER model of a robot control system that extends the RAPP (Robotic Applications for Delivering Smart User Empowering Applications) architecture [12] with the task scheduling feature. Furthermore, we describe the TaskER framework, which implements this model. The model is a novel approach to schedule robot's tasks and is an answer to the problem of harmonisation the robot's tasks, i.e. it shapes a multi-robot system to flexibly and with reinforced safety, coordinate, organise and combine tasks assigned to a robot.

1) WORKS UPON WHICH WE RELY
Our system is derived from the RAPP platform and the robot task harmonisation concept that was published in [25]. The specification method of the system follows the embodied agent approach [26], [27], according to which agents are the main units of a system decomposition. Furthermore, the agents are composed of subsystems that carry out a functional part of the system. The embodied agent approach was used in the description of various robot systems, e.g., a dualrobot manipulation station [28], a mobile robot with various modes of locomotion [29], a dual-arm service robot [30] and a service humanoid robot [31]. The RAPP platform consists of agents that are distributed between the robot and the cloud according to the algorithm that was published in [32], [33]. There are five classes of agents. The agents of a class have the same role in the system and have similar functionalities for fulfilling the role. A graphical visualisation of the services that are provided and consumed by classes from RAPP and those introduced in this work is shown in Fig. 1: 1) Core Agent (ca class) -manages the robot hardware, acts as a low-level controller of the robot and provides common, fundamental behaviours of the robot to the task-level controller-da class. Among others, a ca class commonly delivers motion planning and execution algorithms (e.g., [34]). Its control software operates on the robot computer. There is one ca class for each robot in the system. 2) Platform Agent (pla class) -a computational agent that operates in the cloud and provides system-wide services that require high computational power or huge storage space. There is one pla class agent in the system. 3) Dynamic Agent (da class) -a computational agent that manages a specified task. Such a task is composed of various actions, such as ca class behaviours and platform agent service requests. For example, a da class implements a human guiding task that is composed of robot motion action (ca class agent behaviour), and detection of a human in the pictures sent to pla class agent. In the RAPP project, only one da class operates on a robot that completes a task that is requested by a user. When the task is finished, the robot waits for further requests. 4) Cloud Agent (cla class) -a computational agent that may be spawned in the cloud by a da class to delegate complex task-related computation operations from the robot and to store large files in the cloud. It is strictly connected to the task and the da class that spawned it.
There are at most as many cla class as da class agents because it is not obligatory for a da class to spawn a cla class agent in the cloud. 5) RAPP Store (sta class) -a computational agent that operates in the cloud and stores task files. The files of a specific task are spawned upon user request on the user's robot, and when initiated, become a da class agent. RAPP agents can be assigned to layers via the three-layer architecture approach [35]. Hence, the pla class belongs to the deliberation layer, the da class constitute the sequencer layer and the ca class is the controller layer of a robot. The role and design of a cla class depend on a da class that is supported by it; however, the most intuitive strategy is to use cla class as a task-context-dependent deliberation layer.

2) CONTRIBUTION TO THE SATISFACTION OF THE STATED REQUIREMENTS
Two approaches are available for managing task harmonisation: regarding the tasks as constant and uninterruptible (as in the RAPP approach) or allowing for the system to interrupt the ongoing tasks. Thus, we extend the classification of tasks, robots, and task allocation introduced in [36] with an additional axis-task harmonisation: constant-task harmonisation (CT) vs interruptible-task harmonisation (IT). CT denotes that in case of a new task request during realisation of the current task, the decision on task switching will be postponed until the moment when the ongoing task finishes, while IT denotes that the decision on task switching is taken on the reception of a new task request and the robot can suspend the ongoing task, conduct a set of operations of the new task and restore the previous task from suspension.
Our work enables systems based on variable architecture (RAPP) to use an algorithm and versatile parameters to decide upon task switch. The parameters can be defined in the context of the whole system and can be task contextdependent. The harmonisation procedure proposed in this article is formally and precisely defined enabling its adaption to other architectures.
None of the models or example systems that are presented in the related work section (Section IV) satisfy all requirements that are stated in Section I-A4 and describe the behaviours and structure of a system that can harmonise tasks via the interruptible-task approach. In this article, we introduce a model of a robot control system that has the following features: 1) safe suspension and resumption of independent tasks, 2) facile reconfiguration of the scheduling algorithm and the parameters that are used to compute scheduling decisions, 3) computation of the schedule parameters that depend on a specified task context and abstract knowledge (e.g., an estimated time for completing the task and an estimated time for suspending the current task) and reappraisal of the parameters in reaction to changes in the environment, . The procedure for handling task requests and for evaluating dynamically changing schedule parameters. It results in the replacement or continuation of the ongoing task. The harmoniser part was not considered in RAPP and the request interface was a part of a ca class agent, therefore, in our solution we define two additional agent classes that cover roles of these parts. The presented concept is formalised in our model and visualised in Fig. 8.
4) facile extension of available tasks, 5) update of a plan of an individual task prior to execution, 6) termination of a queued task if it is no longer beneficial, 7) rescheduling of tasks in reaction to the reappraisal of the schedule parameters, and 8) online task harmonisation reconfiguration in either the constant-task or interruptible-task scenario.
Furthermore, we define a formal notation for describing the model and the systems that are inherited from it. The notation helps the systems' developers in various aspects, for example, in relating analogous entities defined in different approaches, in diagnosing the system state more efficiently, or in making the model definition more precise than if it were defined by ambiguous relations and entities.
Finally, we have implemented the TaskER framework, which implements the model and supports the development of various tasks and scheduling algorithms. The general concept of the harmonisation procedure that is described formally in the model is illustrated in Fig. 2.
We distinguish three main parts in the harmonisation procedure: the request interface, the tasks and the harmoniser. The request interface defines a structure of task requests. Each task calculates its schedule parameters used to compute schedule by the harmoniser part, is responsible for its plan management and execution and share an interface to manage its mode of operation. The harmoniser part basing on the schedule parameters received from the tasks manages their modes of operation as it is defined in the schedule algorithm. The proposed harmonisation procedure prevents multiple tasks to execute their actions at once, what would result in a chaotic behaviour of the robot.

3) WORK CONSTRAINTS AND APPLICABILITY
Our model is based on a component structure and describes the required components and recommended interactions between them for handling task suspension and resumption. Additionally, tasks must be divided into stages, classified as suspendable, which can be interrupted, and blocking, which cannot be interrupted. A possible interruption of an ongoing task that is in a blocking stage is handled in a subsequent stage.
Our approach harmonises tasks that are conducted by a robot and not tasks of a whole system that consists of multiple robots. However, such a system also benefits from our model because the model and its description enable the harmonisation of tasks that are delegated to each robot of the multi-robot system.
Referencing the extended classification of robots, tasks and task allocations [36], our study considers the following: 1) robots that are single-task, namely, can execute at most one task at a time, 2) tasks that are single-robot, namely, require exactly one robot for realisation, and 3) task allocation that is instantaneous-assignment, namely, corresponds to the system that does not possess any information that is suitable for planning future task allocations. Such a classified system consists of single-task robots that conduct single-robot tasks. However, the system may contain multiple robots that can complete numerous types of single-robot tasks, e.g., object transportation, hazard detection, and object search. The TaskER model is implemented as a framework built upon ROS and the model extends the RAPP architecture. However, the structure and system behaviours that enable task harmonisation, can be applied to any other system which task model is definable by FSM at least at the top level. Exemplary integration of TaskER with tasks modelled with Petri Nets is presented in this article. The model can be used in a system with knowledge representation in the PDDL [37] to handle harmonisation of the sequences that are deployed by the planning component. Our model allows for da class agents to compute and send task-related parameters to the scheduling algorithm to influence the scheduling decision (e.g., the estimated time for completing a task and the estimated time for suspending the current task). The above assumptions are not restrictive; they allow for the development of a multi-tasking robot with interruptible-task harmonisation.

II. MODEL OF A ROBOT SYSTEM WITH A TASK HARMONISATION FEATURE
The model defines both the structure and behaviour of a multi-robot system that harmonises the robots' tasks (separately for each robot). The model is formally specified VOLUME 8, 2020 with embodied agent approach used in a variety of robotic systems (industrial [38], social [31], service [30]). Recently, the approach was expressed in SysML [39] with the use of diagrams visualising core terms and their relations. The problem of system decomposition into layers and modelling communication between the agents composing the system is resolved in [40]. In this section, the notation that is used to describe the proposed architecture is introduced. Then, the overall structure of the system and structures of the classes of agents that are used in it are defined. Finally, the operation and cooperation of the agents are described with finite-state machines (FSMs), UML activity and sequence diagrams.

A. NOTATION AND SYMBOLS
The agents in the embodied agent approach are abstract parts of a system, which communicate with each other and have the imperative to use their resources to realise their own objectives. Thus, the decomposition of a system into agents is based on the division of the system resources and responsibilities. It should be noted that the symbols in indexes used in the notation are divided by commas, so multi-letter symbols should not be confused with multiple single-letter symbols.
We assume that the system controls a set of robots, and the set is designated as R. The set of all agents of the system (denoted as A) is decomposed into two sets of agents. The first set (denoted as s A) consists of agents with system-wide responsibility (e.g., general services for all robots in the system, interfaces to other systems, and big data storage and services). The second set (denoted as R A) consists of agents that manage robots' hardware and control the robots to perform tasks. A set of agents that are associated with a specified robot is denoted as r A, where r is the robot name (r ∈ R). To denote a subset of the above sets ( s A, R A, r A) that contains agents of a specified class, we use h A u , where h ∈ {s, R, r} specifies the symbol of the set, and u ∈ {ca, da, cla, tha 2 , tra 2 , pla, sta} specifies the class of the agents. The sets and subsets are defined by (1)-(4).
An agent is designated as w a j , where w ∈ (R ∪ {s}), and j is a unique identifier of the agent (e.g., r1 a 12 ). If w ∈ R, then the agent is associated with a robot, whereas if w = s, then the agent is a system-wide agent. An agent consists of subsystems of various classes, however, in this work we omit the subsystem identifier in our notation as each of the agents described in this article consists of one subsystem. Management of behaviours of such an agent is defined by a finite-state machine, which is denoted as FSM j . Finite-state machines are composed of states, which 2 new classes of agents that were introduced in this article in Section II-B for a specified FSM j , we denote as S s j , where s is an identifier of the state. A hierarchical FSM is an FSM that includes at least one super state that is defined by another FSM. The FSM that defines a super state S s j is denoted as FSM j,s . A basic behaviour B b j describes an activity of a single-subsystem agent j, where b is an identifier of the basic behaviour. A basic behaviour B b j is assigned to a state S s j if b = s. Termination conditions are logic functions that are assigned to basic behaviours and define an event that terminates a basic behaviour. They are denoted as tc j,b . A transition function f k j processes data from input buffers and saves it to output buffers, where k is an identifier of the function. A transition function f k j is computed in a basic behaviour B b j if k = b. Transition functions may be divided into primitive transition functions; such a function is denoted as pf p j , where p is an identifier of the primitive transition function. Transitions between states that compose an FSM are triggered by logic functions called initial conditions, which are denoted as ic j,o , where o is an identifier of an initial condition. Subsystems communicate with each other via communication buffers. We distinguish input buffers-g x c j,u -and output buffersg y c j,u -where u is an identifier of the buffer, and g is an identifier of the agent to which the buffer is connected. Links between buffers are specified on a structure diagram with either contextual or non-contextual notation, as presented in Fig. 3. Subsystems can store data in their internal memory. The internal memory of a control subsystem is denoted as c c j .

B. STRUCTURES AND BEHAVIOURS OF THE AGENTS
According to the requirements R1-R6, a robot controller may be requested to begin a task while it proceeds another task (da class). In contrast to the RAPP approach, our model allows for multiple da class agents to operate on one robot, but the model of da class differs from that in the RAPP project. Therefore, we define a set of da class agents that operate on a specified robot as r A da , where r is an identifier of the robot.
To satisfy the requirements of this study, we introduce additional agent classes that were not considered in the RAPP project-task harmoniser (tha class) and task requester (tra class). There is one tha class agent per robot (| r A tha | = 1) in the system, and the agent schedules r A da agents based on a scheduling algorithm that is defined in a transition function of the tha class agent. The algorithm can use either task-dependent schedule parameters, which are computed by r A da agents, or taskindependent schedule parameters, which are computed by the algorithm itself. A tha class agent can be requested at any time by a tra class agent to launch a da class agent on the robot with which the tha class agent is associated. In Fig. 1, we present agent classes and services they provide and consume.
Agents from the da, tha, cla, pla, and sta classes consist of a control subsystem only (communicate with other agents and processes data). However, agents of the ca and tra classes can collect data from the environment (using real receptors) and/or affect it (using real effectors). Each of these abilities requires a suitable, additional set of subsystems; hence, agents of the ca and tra classes may consist of multiple subsystems of various types that depend on the agents' abilities. The method of composition of an agent from subsystems of different types was considered in [41]. Implementations of our model may consist of multiple tra class agents that are built with different subsystems and play the roles of various interfaces (e.g., a home automation system, a smartphone, or a human-robot interface). From this perspective, the structure and behaviours of a tra class agent are not important. However, the interfaces of tra class agents are. Hence, they are described in the tha class agent section (Section II-B2) and the tra class agent section (Section II-B3).
Based on the RAPP architecture and descriptions of tha class and tra class agents, we state the cardinalities of the sets of system agents: A tra class agent can be associated with either a specified robot or a whole system. Following (8), each robot can have one tra class agent associated with it (we denote it as r a rr ). Table 2 describes additional sets that are used in our work. In Fig. 4, we present the general structure of a multi-robot system that utilises our model. The figure shows a crosssection in a layer of robot r and presents agent sets, agents of robot r, buffers of all agents and connections between those buffers. The general structure showing the agents associated with the example robot r ∈ R consists: r A da set (including example r a dy ); r a ha , which is a tha class agent of robot r; r a co , which is of ca class; r a rr , which is of tra class; and r A cla , which is a set of cla class agents that are associated with the agents of set r A da . The model consists of system-wide agents that communicate with all robots in the system: s a pl of pla class, s a st of sta class, and agents of set s A tra .
One of the model constraints is the independent management of tasks that are delegated to a specified robot. List of sets that are used in the model and exemplary system, where r is a robot of the system (r ∈ R), and dy and ha are identifiers of a da class and a tha class agents respectively. Therefore, in the next sections, we assume the following instances of the agent classes and cardinalities of the agent sets:

1) DYNAMIC AGENT CLASS
A da class plays a task bearer role and conducts a set of basic behaviours that are required for performing the task, along VOLUME 8, 2020 with a set of additional behaviours that are defined in our model to satisfy requirements of our study. In addition to the basic behaviours, we define a structure of da class agents, their FSM and communication buffers. We demonstrate the model of a da class on an example r a dy , which is associated with robot r ( r a dy ∈ r A da ). We assume that conditions (9)- (11) are satisfied and that r a cl supports r a dy (12): where '∼' denotes the support relation between a cla class agent and a da class agent.

a: BUFFERS OF da CLASS AGENTS
Each agent of da class has 10 buffers. The first pair of buffers, namely, co x c dy,rob and co y c dy,rob , is used to communicate with r a co to 1) command the robot ( co y c dy,rob ), 2) receive information about the robot and its environment ( co x c dy,rob ). The second pair, namely, cl x c dy,cloud and cl y c dy,cloud , is used to communicate with r a cl , e.g., to request complex computation services or algorithms that require user data that are stored in the cloud.
Transitions of FSM dy (Fig. 5a) are triggered based on the value of ha x c dy,cmd buffer (13), where data consists of any constraints or arguments that are required by r a dy for handling the command. However, the data field of the buffer is not obligatory for systems that utilise our model: If the triggerFlag value consists of an identifier of an initial condition that is defined in FSM dy , then the initial condition is triggered (15)- (17).
Buffer ha y c dy,report transmits the report of agent r a dy , which contains at least an identifier of the current state of FSM dy (Fig. 5 Additionally, this buffer may be extended with schedule parameters that are task-dependent, which must be calculated by r a dy : ha y c dy,report = {fsmState, scheduleParams} The structure of the scheduleParams field depends on the scheduling algorithm of the system. Therefore, it is configurable and not expressed in our model. A pair of buffers ( ha x c dy,reqSP and ha y c dy,reqSP ) are used to deliver argument-dependent schedule parameters that are calculated by r a dy on request from r a ha . The input buffer contains an identifier of a schedule parameter (spID) and the arguments that are required for calculating the parameter (args), and the output buffer stores the value of the requested parameter (scheduleParam). The buffers have the following structures: An example schedule parameter that is argument-dependent is the estimated time for completing a task under specified conditions (e.g., a starting robot pose). The ha x c dy,reqSP and ha y c dy,reqSP buffers are used only in systems with harmonisation that is based on argument-dependent schedule parameters. Finally, a set of buffers, namely, pl x c dy,srv and pl y c dy,srv , are used to communicate with the r a pl to call system-wide services that are supplied by r a pl , such as text-to-speech or speech-to-text.

b: FSM OF da CLASS AGENTS
The lifecycle of a da class is managed by a hierarchical FSM with three states at the top level-FSM dy (Fig. 5a): 1) S init dy -the process of r a dy is initiated in the robot's computer. The internal FSM of this state is presented in Fig. 5b. Agent r a dy is allowed to pull data from r a co to compute schedule parameters and obtain the addresses of the remote services. However, r a dy does not command r a co to perform the task that is implemented in r a dy . This state consists of two internal states: r a dy sets the value of ha y c dy,report (18)- (19), and if the system uses task-dependent schedule parameters, then r a dy computes these task-dependent schedule parameters, which are used by r a ha to manage the operation of the agents from set r A da . 2) S cmd dy -r a dy commands r a co to complete its task. This state is represented by a hierarchical FSM (Fig. 5c), where 2.1. S exeTsk dy is specified by an FSM (FSM dy,exeTsk ) that describes the task of r a dy , and each state of this FSM represents a stage of the task. The states of the FSM are denoted as S stage,k dy , where k is an identifier of the stage. The stages can be defined by any task model (Petri Net, Behaviour tree, DSL, FSM). In case of a task based on Petri Nets, an exemplary FSM dy,exeTsk has the form presented in Fig. 6 , is a super state that is defined by FSM dy,exeSusp . State S susp dy is responsible for conducting a set of actions to i) set the robot and the environment in safe conditions at the time of the task switching, ii) enable the resumption of the task that will be conducted by r a dy .
3) S wait dy -r a dy awaits resumption, sets the value of ha y c dy,report and calculates only the schedule parameters. If | r A da | ≥ 1, then only one agent from set r A da can be in state S cmd dy (other agents can be in other states) and execute its task. The initial conditions of FSM dy , namely, ic dy,start , ic dy,term , and ic dy,susp , are set by r a ha via inter-agent connection; hence, r a ha must not allow for more than one agent from r A da to be in state S cmd dy . Only two initial conditionsic dy,taskFinished and ic dy,term -can be set by r a dy : 1) ic dy,taskFinished -the task that is implemented in S exeTsk dy is completed and reaches the final stage (the end state of FSM dy,exeTsk sets ic dy,taskFinished ), 2) ic dy,term -the task of r a dy is aborted by a user or is no longer feasible, while the agent is in state ), which is composed of multiple primitive transition functions, each of which computes a distinct schedule parameter (e.g., the priority and the estimated time for completing the task that is implemented in r a dy ). Equation (22) where pf report dy , with the frequency defined in the repRate field of c c dy , sets the fsmState field of the ha y c dy,report buffer (given by (18) or (19) (22). The parameters are used by r a ha to schedule r A da agents. The trigger events of the primitive transition functions are as follows: where k is an identifier of the task stage and timer(X ) is a function that returns true with frequency X . Both taskExeRate and SPupRate are fields of c c dy . Some stages of a task may involve operations that may not be interrupted, e.g., due to an unstable state of the object that is being manipulated or to an unknown suspension or resumption transition function for this stage. To prevent such a threat, we distinguish two types of task stages in our model: 1) suspendable -the task may be suspended in this stage, and the system can switch to another task with the ability to resume the current task in the future; 2) blocking -the task may not be suspended in this stage e.g. due to performing an unstable process or resume of the task would be impossible. The suspendable stages of a task that is conducted by r a dy compose the set U dy , and the blocking stages compose the set L dy . Each of the task stage types has an individual definition of a termination condition for terminating B stage,k dy . The termination condition of a blocking-type stage is the satisfaction of the objective condition of the stage, e.g., the robot is at its destination for a navigation stage (25). A termination condition of a suspendable stage is the satisfaction of the objective condition of the stage with the alternative ic dy,susp condition (26 , as presented in (22):

2) TASK HARMONISER AGENT CLASS
Here, we describe the structure and behaviours of tha class agents (which correspond to schedulers in operating systems) on an exemplary agent r a ha . The agent of this class receives and processes requests for new tasks from tra class agents and schedule tasks of the robot r. Agent r a ha switches the states of the agents from set r A da to 1) optimise a specified scheduling criterion (e.g., highest priority first, shortest job first, or shortest remaining time first); 2) enable the controlled suspension and resumption of the tasks that are implemented in da class.

a: TASK HARMONISER BUFFERS AND MEMORY
The memory of r a ha (namely, c c ha ) consists of multiple named fields and they are required to manage dynamic agents. The scheduling of r A da agents is realised by r a ha and is based on modification of the values of c c ha fields c c ha,exeDA , c c ha,irrDA and c c ha,idleDA by assigning identifiers of r A da agents to them. The first field stores an identifier of an agent r a dy ∈ r A da that is currently in state S cmd dy and conducts the task that is implemented in it. We refer to an agent that is assigned to this field as r a exeDA . The c c ha,irrDA field stores an identifier of an r a dy ∈ r A da that was chosen by pf schedule ha to replace r a exeDA . We refer to an agent that is assigned to the c c ha,irrDA field as r a irrDA . c c ha,idleDA is a one-dimensional array of size N that is filled with identifiers of the agents that belong to set D r : The management of the operation of an example r a dy ∈ r A da is realised by sending state switch requests via buffer dy y c ha,cmd to ha x c dy,cmd . The state switch request that is sent to dy y c ha,cmd has a structure that is similar to that of ha x c dy,cmd and may consist of one of the values that is defined in (14). As the cardinality of r A da may exceed 1, there is a set B ha,cmd that contains buffers for managing the states of r A da agents: dy y c ha,cmd ∈ B ha,cmd ⇐⇒ r a dy ∈ r A da |B ha,cmd | = | r A da | The tr x c ha,task and tr y c ha,task buffers are an interface (denoted as taskIF ha,tr ) for agent s a tr of tra class. As the cardinality of the sum r A tra ∪ s A tra may exceed 1, there is a set of input and output buffers that connect r a ha with all tra class agents in the system: { tr x c ha,task , tr y c ha,task } = taskIF ha,tr , taskIF ha,tr ∈ B ha,task ⇔ a tr ∈ ( r A tra ∪ s A tra ), (32) where B ha,task is a set of task buffers of agent r a ha for receiving new task requests and responding to them. Moreover, our model supplies agent r a ha with two sets of buffers, namely, B ha,report and B ha,reqSP , for collecting reports and task-dependent schedule parameters from r A da agents: dy x c ha,report ∈ B ha,report ⇔ r a dy ∈ r A da , (33) dy x c ha,reqSP , dy y c ha,reqSP ∈ B ha,reqSP ⇔ r a dy ∈ r A da The buffers of these sets are used to 1) B ha,report -collect the current states of r A da agents and their schedule parameters (18), (19); 2) B ha,reqSP -request and receive from r a dy argumentdependent data for the scheduling algorithm. There is a pair of buffers, namely, st y c ha,app and st x c ha,app , for collecting files of tasks that are stored in s a st . Additionally, r a ha consists of pl x c ha,srv and pl y c ha,srv buffers, which are used to communicate with s a pl to call system-wide services that are supplied by s a pl (e.g., the current list of the tasks that are available in s a st ).
Finally, there is an input buffer co x c ha,rob , which can be used by the scheduling algorithm that is implemented in r a ha to obtain data regarding the current state of the robot and its environment.

b: BASIC BEHAVIOURS OF tha CLASS AGENTS
Management of r a ha behaviours is specified by the FSM with two states (Fig. 7) that point to the basic behaviours: S init ha to B init ha and S harm ha to B harm ha . The former basic behaviour depends on the implementation of r a ha as it is responsible for initialising c c ha and establishing connections of the buffers of r a ha . The latter (B harm ha ) consists of a composite transition function, which is decomposed into the following: 1) pf initDA ha -which reads data from buffer tr x c ha,task , assigns an identifier to the received task (e.g., dy), sets up r a dy and adds it to set D r . Finally, FSM dy managing operation of r a dy is initiated, and the initial arguments are passed from the requester ( s a tr ) to r a dy , 2) pf schedule ha -which defines the scheduling algorithm, which, with a configurable frequency (defined in the c c ha,sFreq field) and based on the schedule parameters that are received from buffers B ha,report and B ha,reqSP , assigns identifiers of the agents from set D r to the c c ha,irrDA field. The algorithm of this primitive transition function is configurable because it depends on a specified system and its objectives; hence, it is left to be defined by the designer of the robot system. The function is defined in (35) (35) 3) pf switchDA ha -which reads the value of the c c ha,irrDA field and sets the values of B ha,cmd buffers to either suspend, start, or terminate agents from r A da . This primitive transition function sets the c c ha,exeDA field. Its algorithm is presented as Alg. 1.
term event = ∃ α x c ha,report ∈ B ha,report α x c ha,report = {end}, where newData(x) is true on data changes in buffer x and timer(x) is triggered with a frequency given by x.

3) TASK REQUESTER CLASS AGENTS
Agents of tra class are entities that can request new tasks. There may be many tra class agents in the system, which differ in structure. Some may be only processing agents with a control subsystem only and request new tasks based on a timer, and others may be equipped with a physical device or a sensor that initiates the request for a task. As there may be many robots in the system, agents of A tra (in our example, s a tr ) must obtain a list of the robots and their addresses from the pla class (in our example, s a pl ) by the activerobots interface (in our example, buffers pl y c tr,active−robots and pl x c tr,active−robots ). Each of the tra class and cla class agents has a pair of buffers for communicating with agent s a pl to call system-wide services that are supplied by agent s a pl . In our example, the buffers are

C. THE HARMONISATION PROCEDURE
Robot systems that utilise our model can schedule their tasks and are composed of agents of various classes. Models of the classes were presented in the previous sections; however, for a comprehensive description of the system behaviour, a depiction of the inter-agent interactions is required. Thus, here, we present the workflow of agents in the face of a typical task harmonisation problem. The system that is considered in the scenarios consists of one robot (R = {r}), one tha class agent ( r A tha = { r a ha }), one ca class ( r A ca = { r a co }) and one tra class ( s A tra = { s a tr }). As the objective of this study is to describe the robot task harmonisation model, this section focuses on the workflow of s a tr , r a ha and da class agents and not the other agents, which are described in [12]. An outline of the task harmonisation procedure in a system that utilises our model is presented as an activity diagram Fig. 8. The complex activities that are illustrated in the rounded rectangles and the interaction among the system agents in each of them is presented in the form of a sequence diagram in the Appendix A. The harmonisation procedure is initiated by one of the following events, as marked in the activity diagram: 1) event 1 -agent r a ha receives a new task request from agent s a tr -the initial event of pf initDA ha is satisfied, 2) event 2 -a trigger repetitively initiates pf schedule ha (36). 3) event 3 -c c ha,exeDA and c c ha,irrDA are empty, but there is an idle daclass agent or r a ha receives new report with schedule parameters (37). The procedure is terminated if either activity 1, activity 5, activity 6, or activity 7 is completed. The procedure consists of two decision nodes: D1 and D2. The former is realised by the initial event of pf switchDA ha , which checks the output of pf schedule ha . The latter decision node, namely, D2, is checked in the conditions of Alg. 1.

III. VERIFICATION
The verification of the model is based on the design, development and testing of an exemplary system that is based on the model. Therefore, we define the application of the exemplary system (section III-A), describe the TaskER framework that implements the agent classes using ROS (section III-B) and design the system via model configuration (section III-C). Next, the operation and tests of the exemplary system are presented (section III-D). This section ends with a discussion of the system actions and the requirements satisfaction.

A. REQUIREMENTS OF THE EXEMPLARY SYSTEM
The verification of the model and framework is conducted by implementing the procedure of task harmonisation (Fig. 8) in a simulated environment using a TIAGo robot. The configuration of the verification system is as follows: 1) task harmonisation is of interruptible-task type, 2) there is one robot in the system (R = {r}), one tha class agent ( R A th = { r a ha }) and one ca class ( R A ca = { r a co }), 3) there is one tra class agent-s a tr , 4) agents of set r A da provide to agent r a ha task-dependent schedule parameters that are defined by the following structure: The tskType field consists of an identifier of the task type that the da class manages. In this verification, s a st provides two types of tasks (40).
The guideHuman task objective is to approach a specified human, introduce the task, guide him to a specified location and say goodbye. The humanFell task is an emergency call for a robot to approach a specified human who likely fell and to check his consciousness.
We denote by tskType dy a type of task that is conducted by agent r a dy . Agents of set r A da that initialised their report buffers ( ha y c dy,report = Ø for r a dy ) with the first report (by pf compSP dy for r a dy ) and have a task of type guideHuman belong to set G r , and those that initialised their report buffers and their tasks are of type humanFell and belong to set H r : e = r a dy ∈ r A da ∧ ha y c dy,report = Ø r a dy ∈ F r : e ∧ tskType dy = humanFell (41) r a dy ∈ G r : e ∧ tskType dy = guideHuman (42) cost dy is a task-dependent schedule parameter of r a dy that depends on the current state of the robot and its environment: 4.1. For G r agents, it represents the comfort of a person who is cooperating with the robot during the task. The value of the cost parameter changes with time and is calculated via the following equation: cost = w stand t stand + w sit t sit (43) i) t stand is an estimate of the time for which the guided person stands, which is measured from the receipt of the task request until the task objective is realised; ii) w stand is the scaling factor for standing posture that is parametrised according to the person's health condition; iii) t sit is an estimate of the time for which the guided person sits, which is measured from the receipt of the task request until the task objective is realised; and iv) w sit is the scaling factor for sitting posture that is parametrised according to the person's health condition. 4.2. For F r agents, the cost parameter represents the distance to the human that fell in consideration of the current pose of the robot. The larger the value of the cost dy parameter, the less urgent the task of r a dy is. cps is an estimate of the first derivative of the task cost in consideration of the current state of the robot and its environment. cTime is an estimate of the task duration if it were initialised at the estimation time (considering the current state of the robot and its environment). endPose is the pose of the robot when the task is completed. 5) r a ha schedules r A da agents (using pf schedule ha ) based on algorithm 2. Hence, tasks of the same type compete with one another based on the cost parameter and the parameters that are requested by pf schedule ha (via B ha,reqSP buffers). The algorithm always causes an interruption of a guideHuman task by a human-Fell task. In line with 23, the algorithm requests two argument-dependent parameters: cc and ccps. The former is the estimated cost of the recipient's task completion if the task were started from the pose that is specified in the argument. The ccps parameter is the cost per second while waiting for the recipient's task to begin.

B. IMPLEMENTATION OF THE MODEL AND EXEMPLARY SYSTEM
The TaskER framework delivers two Python classes, namely, TaskHarmoniser and DynamicAgent, which implement the tha and da classes, respectively. The implementation of the introduced framework and the agents, which are specific to the exemplary system ( r a co , s a pla , s a tr , and s a st ), is based on the ROS framework.
Agents r a ha and s a tr are implemented as separate ROS nodes and are launched upon system startup. r a co is robot-specific and is implemented as ROS nodes that serve common TIAGo robot actions (e.g., navigation and manipulation) in the Gazebo simulator.
Upon TaskHarmoniser class initialisation, a ROS node is launched with a ROS service interface to request new tasks (implementing pf initDA ha ) and with a subscriber for ROS topic messages, which receives the reports from r A da agents. Upon each task request (via the ROS service), agent r a ha launches a new ROS node that implements a suitable da class agent. Henceforth, the node of the da class agent will publish its report messages to the ROS topic that is subscribed by the tha class agent that is discussed above. In addition to the above interfaces, the TaskHarmoniser class implements exemplary primitive transition functions namely, pf switchDA ha and pf schedule ha , respectively, as presented in this article (Alg. 1 and Alg. 2).
For each type of tasks in the system, a dedicated script is implemented with the DynamicAgent Python class. The task scripts are started by a tha class agent upon task request from a tra class agent. Upon initialisation of the DynamicAgent Python class, considering dy as an identifier of the da class agent that is being initialised: 1) a ROS node is launched; 2) a ROS service of pla class is requested to launch a ROS node of r a cl ∈ r A cla (if r a dy requires support from cla class); 3) interfaces of r a dy are created: 3.1. ha x c dy,cmd as a ROS topic subscriber, which sets initial conditions ic dy,start , ic dy,susp , and ic dy,term ; 3.2. ha y c dy,report as a ROS topic publisher (which is associated with dy x c ha,report ), 3.3. ha x c dy,reqSP and ha y c dy,reqSP as a ROS service (which are associated with dy y c ha,reqSP and dy x c ha,reqSP , respectively); 3.4. co x c dy,rob and co y c dy,rob by the robot API class initialisation; and 3.5. cl x c dy,cloud and cl y c dy,cloud as a ROS service client that is connected to the ROS service that is shared by r a cl supporting r a dy . The above actions are managed in state S initComm dy . Next, agent r a dy follows FSM dy and the basic behaviours that are described in Section II-B1.c.

C. CONFIGURATION OF THE DYNAMIC AGENT MODEL
The model of da class (section II-B1) must be configured for a specified task to satisfy the requirements of the task. The configuration procedure is presented for an example da class-r a dy ∈ r A da managing a task of type guideHuman. The procedure is as follows: 1) task objective definition: 1.1. definition of FSM dy,exeTsk , including the task stages and the initial conditions of the stages; 1.2. classification of the task stages into suspendable and blocking; and 1.3. specification of basic behaviours that are conducted in the stages and the termination conditions of the basic behaviours; 2) task update f where greeted is true if the person being guided was already greeted by the robot and false if was not. In the first case of (47), B save dy is assigned to B exeSusp dy . The basic behaviour saves already computed results, which are useful after the task resumption (e.g., the person's pose, if it was determined, can be used as an initial value for the person search algorithm). The termination condition of B save dy always holds (tc dy,save = true); hence, after one iteration of B . This basic behaviour stops the robot, saves important data (as in the B save dy case), and asks the person to stay and not follow the robot because it received another important task.

D. EXECUTION OF THE EXEMPLARY SYSTEM
We tested the system in a scenario that involved the execution of the task harmonisation procedure (section II-C) over 80 times in a changing environment. The scenario for evaluation of the exemplary system involve: • suspension of the ongoing task in various stages, • dynamic changes of the environment state (independent from the robot actions),   • resumption of a suspended task in the case of the environment state change, • abortion of a suspended task on its request, • unpredictable task requests, The initial setup of the environment is shown in Fig. 10. Four people, namely, John, Alice, Peter and Sara, were in the environment. In this article we describe a period of our tests in which four tasks were conducted: 1) guide John -a guideHuman-type task that was managed by r a d1 , 2) guide Alice -a guideHuman-type task that was managed by r a d2 , 3) Peter fell -a humanFell-type task that was managed by r a d3 , 4) Sara fell -a humanFell-type task that was managed by r a d4 . Various tasks (integrated as dynamic agents) can be applied to our architecture, however, we propose the two types in order to keep the scenario simpler and clearer, as the model and the harmonisation procedure is complex itself. The new tasks can be applied as it was described in Sec. III-C.
In Fig. 10, we represented the initial pose of the robot as a pentagon and John and Alice as filled and empty circles, respectively. The path that was traversed by John while he was waiting for the robot is represented as a dotted line. The destinations of John and Alice are represented by filled and empty stars. The poses in which Sara and Peter fell are represented as dotted and dashed circles. The verification scenario was recorded, and the video is available [42].
The detailed description of the system behaviour during the evaluation is described in Appendix B. The Fig. 11 visualises value changes of the key parameters of schedule algorithm (Alg. 2) and assignments of r A da agents to r a irrDA , r a exeDA , D r roles.

E. SATISFACTION OF THE REQUIREMENTS IN THE EXEMPLARY SYSTEM
The s a tr can request multiple tasks at any time, which are initialised and ready to be conducted by the robot. The requests are processed, suitable da class agents are created, and in each iteration of pf schedule ha , a da class can be assigned to r a irrDA ; thus, R1 is satisfied.
Schedule parameters can be computed repetitively (22) by pf report dy , which fills the ha y c dy,report buffer (19). Additionally, the scheduling algorithm can request argument-dependent schedule parameters, which are computed by dedicated primitive transition functions of f compSP dy ; thus, requirement R2 is satisfied.
The procedure scheduling da class agents is divided into multiple primitive transition functions, which are distributed among da class agents and r a ha , which, via function pf schedule ha , computes a decision regarding switching an ongoing task with a new task or continuing the current task. Therefore, the exemplary system may be easily configured to use other schedule parameters or scheduling algorithms that are implemented in pf schedule ha . Thus, R3 is satisfied. Tasks are created independently and stored in the cloud. A tha class agent of a robot downloads them upon the request of the robot's user. The initiated tasks become da class agents and compute schedule parameters in consideration of expert knowledge and the context of the task. For example, a general parameter, such as the estimated time for completing the task, can be calculated with consideration of the expert knowledge in the da class (such as a speed limitation due to transportation of a delicate object). Thus, requirement R4 is satisfied.
Our model divides tasks into stages that can be suspended and stages that cannot. It also defines the FSM of da class VOLUME 8, 2020 with dedicated suspension states, which are triggered if the agent receives a suspension signal and the current stage of the agent's task is suspendable. Hence, interruption by a set of actions and the prevention of a possible inconvenient behaviour or damage to the system and its environment are managed by the agent, which possesses expert knowledge regarding the current task and its progress. For example, suppose the robot in the verification scenario did not warn John that the robot switched tasks. In such a case John would follow the robot unnecessarily. Hence, the suspension state avoided an inconvenient walk for John while the robot conducted other tasks. Another example of a suspension action is turning off a cooker if it was turned on during the execution of the task and the estimated interruption time exceeds the cooking time of the dish that is being prepared. Hence, requirement R5 is satisfied.
Due to the frequently triggered pf report dy function, r a dy can react to changes in a dynamic environment and update its schedule parameters. The changes in the environment also affect the plans of da class agents. Therefore, our model foresees the need to update the plan (i.a. in state S upTsk dy ) before the agent executes its task. The most straightforward example result of B upTsk dy can be an extension or reduction of the plan due to actions by an actor that is co-working with the robot in the environment. Thus, requirement R6 is satisfied.

IV. RELATED WORK
Our study considers two aspects: structure and behaviour modelling for robotic systems and the management of multiple tasks in these systems. Therefore, we compare our approach to other available approaches for these two aspects.

1) STRUCTURES AND BEHAVIOUR MODELS FOR ROBOT SYSTEMS
One of the most popular approaches for modelling robot control systems is the use of a layered architecture, e.g., the 3T architecture [35], [43]. It is broadly utilised and compared with the other available approaches, e.g., in SmartMDSD Toolchain [44], [45]. The authors of [37] designed the middle layer of the 3T architecture, which was realised with a finitestate machine (FSM), for the integration of the symbolic plan that was provided by the knowledge representation with the geometric planner that instructs the robot. Each description layer of a task (symbolic planning, behaviour sequencing, or command execution) uses a different context and is designed to satisfy its objectives and handle exceptions that are specified in the abstraction-layer dictionary, e.g., a symbolic planner that uses logic variables and functions or a behaviour sequencer that uses primitive behaviours and transition functions.
Our study considers all three layers that are defined in the above architectures. ca class is the command execution layer, the da class and tha class agents constitute the sequencer layer, and the symbolic planners that are utilised by the sequencer layer (implemented in either cla class or pla class) constitute the deliberation layer.
Coordination between the layers is a complex problem, especially considering the difference in their contexts. Stenmark et al. proposed the integration of high-level task description with action execution [46]. However, coordination of the tasks was not a goal of this work. Our approach enables the harmonisation of a robot's tasks by the sequencer layer, which receives error messages from the commanding layer and can request new plans from the deliberative layer.

2) MULTI-TASK ROBOT SYSTEMS
A task planning problem for human-robot interaction schemes that are scheduled by a symbolic planner is described in [47]. The authors of the article focus on social constraints that should be considered in a task and motion planning of a human-aware robot. However, the problem of the suspension and resumption of the tasks is not resolved. Studies have also been conducted on sequencing robot behaviours at the controller level (e.g., [48], [49]). Robothuman communication is yet another problem that is related to the management of robot tasks. The authors of [50] describe a model of a system that is capable of interruption and switching of a conversation domain. However, these approaches preclude the execution and scheduling of various independent tasks.
The overall behaviour of the robot in our exemplary system can be modelled with a hierarchical FSM (HFSM), e.g., SMACH library [51] for task-level robot control. However, understanding the system performance, configuring the scheduling algorithm and tailoring the suspension/replanning actions for a specified application would be complicated. The decomposition of the robot control system into separate agents of various classes renders the system specification process more convenient, more transparent and easier. Additionally, SMACH does not support dynamic HFSMs natively, which are proposed in our study (behaviour of one state defines the subsequent one).
The processing of multiple tasks in state-of-the-art robot systems is realised via high-level deliberation. Reasoning algorithms compute a multi-objective plan that satisfies temporal constraints [52] and uncertainties in conditional planning [53]. This approach utilises a semantic planner, which requires a complex knowledgebase that integrates predicates of all possible requests from the system user and requires that the predicates be compatible among the system tasks. Therefore, the extension of the system with additional tasks is complicated and interferes with the well-tested tasks. Additionally, if the priority of a task changes, a task is cancelled or a task's parameters change, then this approach requires re-planning of the actions. The available frameworks that utilise semantic planning ROSPlan [54], SmartTCL [45] do not provide a mechanism for re-initialising planning in the face of a task modification.
In state-of-the-art architectures, robot tasks are separated from the rest components of robot control system. Various models are used to express the task and they can be divided to task definition models and task execution models. The models of former type are commonly used with semantic planners, which reason basing on the task definition and the world state. As a result, planners return specification of the robot behaviour, which is required to complete the task. Both the task and the behaviour are expressed in the terms defined in the model, which commonly is a Domain Specification Language (DSL). The example task definition approaches are PDDL [55], Golog [56]. The behaviour computed by a semantic planner can be transformed to a model, which abstracts from semantic symbols and DSL terms i.e. to a task execution model. For example, the behaviour can be decomposed into states which need to be managed to complete the task, as it is in Hierarchical Finite-State Machines (HFSM) approach [57]. Additionally, there are Petri Nets and Behaviour Trees (BTs) [58]. The latter approach was initially used to define behaviour of Non-Playable Characters (NPC) in game industry. Proponents of BTs approach state that it is a very efficient way of creating complex systems that are both modular and reactive. Some of the task models can be transformed to other models, e.g. HFSM to BT and vice versa [58]. We use HFSM approach, because it is a core model of agent behaviour in the formal specification method we use (Embodied Agent Approach). However, tasks modelled in other approaches can be integrated with our architecture, as it is done in Petri Net case in Fig. 6.
The authors of [59] propose a method to coordinate tasks specified in Golog language. The approach is compatible with a formalised method to reason about task plans and composition of task suspension sequences. The work introduces the concept of promises, which denote asserted or required conditions used to determine conflicts during task switching. In contrast, we define formally in our work an architecture which can be used more broadly, as it is not restricted to a specific task modelling language. We present our work with the use of FSMs, as it is a popular behaviour modelling approach and there are methods to transform it to other approaches. Therefore, the TaskER architecture can be assumed as independent from a task model, planning method and language used for the definition of the algorithm managing tasks. It integrates concepts of i.a. scheduling algorithm, task update, schedule parameters calculation and specifies an architecture which satisfies the requirements stated in this article introduction. Therefore, the concept of promises can be used to specify the scheduling algorithm defined in the TaskER and different planning methods can be used in the task update concept. Furthermore, as the contexts of tasks are separated, tasks can be specified with dedicated models,they can use different planning methods to update their plans and use various schedule parameters. The latter can be task-context-dependent in TaskER, so other priority can be assigned to a door opening task in case of a visitor and other in the case of an emergency.
Robot systems are part of a larger group: cyber-physical systems (CPSs). Various articles consider the task harmonisation problem in this group [60]- [62]. However, they are focused mostly on algorithms for optimisation of the task switching moment or coordination of the tasks that are delegated to multiple devices to realise a specified objective. The authors of [60] present a methodology for describing, managing and realising objectives of a device community. This study shows how to describe the objective of the whole community of devices with simple roles of each device. The second paper [61] presents an algorithm for minimising a deadline meeting ratio. The algorithm considers the time that is required by the servicing node for moving from one place to another. However, the authors do not demonstrate how to perform the task switch (in a scenario that involves a robot, not all tasks may be interrupted at any time). The final study [62] considers a dynamic allocation of computational tasks among distributed CPS devices.
The authors of [63] investigate the problem of integrating time-and event-triggered systems in a mixCPS architecture. However, they focus on computation task assignment and packet transmission optimisation to minimise the application-level delays. The architecture considers delays of sensor-controller and controller-actuator communications and the controller processing time.
In contrast to a typical CPS (where many tasks are processed rhythmically [64] or task activation is statically defined by rules as in home automation applications), robots are being unpredictably requested for tasks, and the user of a robot would like to change his/her requests and preferences while the robot performs the requested task.
Task queueing and management is an old topic in cyber research [65], [66] and a hot topic in cyber-physical systems [67], [68]. The robot task harmonisation problem has similarities with process scheduling in operating systems (e.g., sporadic scheduling in real-time systems [69]). Both consider unit work management: in robotics, a robot performs multiple tasks, and in an operating system, a CPU conducts multiple processes. The correlations between scheduling operating system processes and the TaskER model are presented in Tab. 3.

V. CONCLUSION
The article considers the problem of switching tasks that are conducted by robots. The structure of the robot controller is variable, and it is composed of multiple agents that are derived from various agents' classes. The activities of the robots that are working in the physical environment differ, and the assumptions and conditions that should be considered differ from those in standard computational systems.
The flexibility of a robot system is crucial in the case of unexpected difficulties and depends on the system application assumptions, e.g., a market crash, a factory modernisation, or a pandemic. Therefore, robot systems must be easily configurable especially at the task level.
One of the challenges that must be overcome for the realisation of flexibility is the development of multi-task robot controllers that can harmonise robots tasks. In this study, we present sample use cases that describe the desired behaviours of a robot control system that is faced with the task harmonisation problem. Then, based on the use cases, we formulate six requirements for a control system that features task harmonisation. Next, we describe the model of such a system. The model adapts and extends the known variable structure for robot control systems, namely, the RAPP architecture, to satisfy the previously specified requirements. Finally, we implemented the TaskER framework, which enables the efficient creation of the robot tasks and injects them as modules into the systems that utilise our model. The algorithm that defines the strategy for task scheduling differs among robots, applications and environments; hence, the TaskER framework applies the algorithm as an interchangeable function.
The model that is described in this article is presented in mathematical and UML diagram formulations. Thus, the overall behaviour of a system that follows the model is strictly defined. Requested tasks have their contexts and are implemented as separate processes, which facilitates understanding of the current state of the system and the progress of each task.
Model of a dynamic agent, being an encapsulation of a task in this architecture, defines constraints and specifies the tasks to enable harmonisation feature. A huge part of the task is not constrained by the model proposed in this work. This is because it is not important from the perspective of this work goal. The method to define actions realised by the task is another important problem in robotics and any which results with a plan representable in FSM can be used. In the architecture, we define when and by which agent a planning method will be executed. Various planning methods require different world models. As our harmonisation method does not depend on any planning method or world model, any can be used. Furthermore, our work can be applied even in systems without deliberation and semantic planning. Each task (dynamic agent) can use different planning method to update its actions and constraints or do not use any and have its actions statically defined.
Moreover, tasks that are managed by da class agents can 1) compute task-dependent parameters that are used for task scheduling, 2) suspend their operation safely in the case of a task switch, 3) update their plans prior to the task execution, and 4) block a task switch if it would be dangerous according to the context and knowledge of the agent. The conducted tests show that the exemplary system satisfies the specified requirements. Moreover, they demonstrate the benefits for a system that follows the model.
We plan to integrate the TaskER framework with a known framework for semantic planning (such as ROSPlan [54] for calculating scheduling decisions and parameters for various tasks, applications and environment classes (e.g., using a objective optimisation algorithm such as [70]), 2) define a guideline and an algorithm for classification of the task stages into suspendable and blocking, 3) extend the PDDL standard to support our approach and enable semantic planners to consider the task scheduling problem while composing FSM dy,exeTsk and FSM dy,exeSusp FSMs, 4) evaluate metrics for task scheduling quality evaluation, 5) provide an adaptation mechanism for the scheduling algorithm to enable learning of the priorities of tasks based on the user's intentions [71], [72], 6) design an ontology for the robot task harmonisation problem that facilitates the configuration of the schedule parameters (according to robot skill reconfiguration [73]), 7) conduct tests with end users within the INCARE project [74], and 8) integrate our architecture with one of the formally defined task models featured with consistent language for scheduling algorithm specification and planning method [59].

APPENDIX A KEY ACTIVITIES IN THE HARMONISATION PROCEDURE 1) LAUNCH NEW DYNAMIC AGENT
The interaction among the agents of the system is presented in Fig. 12. Agent s a tr sends a request to r a ha via buffer ha y c tr,task , which is connected to buffer tr x c ha,task . Consequently, pf initDA ha is triggered (36), which manages the initialisation of a new dynamic agent, starts an application that implements the da class model, passes initial data to it and extends  array c c ha,idleDA with the name of the new dynamic agent (e.g., d1). Thus, r a d1 is created, and FSM d1 switches to S init d1 , where the system-specific initialisation actions are conducted (S initComm d1 ). Finally, r a d1 switches to state S compSP d1 , in which it repetitively calculates the schedule parameters (given by (22)) and saves them in buffer ha y c d1,report .

2) START TASK OF r a irrDA
In this case, none of the agents in r A da plays the role of r a ha,exeDA , and pf schedule ha assigns the role of r a irrDA to an agent in set D r . The interaction among the agents in this activity, with r a irrDA = r a d1 , is illustrated in Fig. 13.

3) SWITCH TASKS
This activity begins only when pf schedule ha , knowing that r a exeDA conducts its task, decides to assign the role of r a irrDA to an agent in set D r . The sequence of the system agent interactions in this activity is presented in Fig. 14. According to (36), the initial event of function pf switchDA ha is satisfied until it does not remove the identifier of r a irrDA from the c c ha,irrDA field in line 11 of Alg. 1. Depending on the state of agent r a exeDA , either the condition in line 2 or that in line 5 of Alg. 1 is satisfied. In the former case, r a ha sends a suspension signal to r a exeDA , and in the latter, it removes 1) If the ongoing stage is suspendable (S stage,k exeDA ∈U exeDA ), then FSM exeDA,exeTsk is terminated, as presented in Fig. 5c, and r a exeDA is switched to FSM exeDA,susp . Now, the agent prepares a plan for the task suspension (in f genSusp exeDA ) and realises the plan in FSM exeDA,exeSusp . Finally, when the task is suspended, the agent switches to S wait exeDA and saves a report message to ha y c exeDA,report that contains the name of the current statewait. While r a exeDA follows the above sequence, the algorithm of pf switchDA ha always enters the condition in line 2 of Alg. 1. When r a exeDA enters state S wait exeDA , the condition in line 5 is satisfied, and pf switchDA ha moves the name of r a exeDA from the c c ha,exeDA field to set D r . Next, the algorithm enters the condition in line 9 as the c c ha,exeDA field is empty. Consequently, pf switchDA ha moves the name of r a irrDA from c c ha,irrDA to the c c ha,exeDA field and sends the start signal to r a irrDA ( irrDA y c ha,cmd = [start,data]). 2) If the ongoing stage is blocking (S stage,k exeDA ∈L exeDA ), then the suspension signal ( ha x c exeDA,cmd =[susp,data]) is ignored; hence, this stage and all subsequent blocking stages will be completed. When FSM exeDA,exeTsk finally enters a suspendable stage, the system activity will follow the sequence that is described in the first case.

APPENDIX B VERIFICATION DATA ANALYSIS
In Fig. 11, we present values of the following schedule parameters, which were used in function pf schedule ha during the verification period: cost dac , cost exeDA , cc dac , cc exeDA , ccps dac , ccps exeDA , c switch , and c wait . The rectangularly highlighted sections of the figure show the states of c c ha,idleDA , c c ha,exeDA and c c ha,irrDA in crucial moments of the test period. First, at time = 2450, r a d1 is initialised and executes its task. Then, between time = 2450 and time = 2509, r a d2 is initialised, which computes its schedule parameters, and eventually, at time = 2509, pf schedule ha sets dac = d2 (line 18 of Alg. 2). After comparing c switch and c wait (line 29 of Alg. 2), it assigns the identifier of r a d2 to c c ha,irrDA . In response to this, pf switchDA ha is triggered and sends a suspension signal to r a d1 , which is in S ) and subsequently switches to S exeSusp d1 and S wait d1 . As r a d1 notifies pf switchDA ha that the suspension strategy (FSM d1,exeSusp ) has been completed, pf switchDA ha sends a start signal to r a d2 . Finally, at time = 2513, c c ha,exeDA = d2 and c c ha,idleDA = D r = {d1}.
From time = 2513 to time = 2519, John moves closer to the destination of the guidance that is managed by r a d1 ; hence, the cost (cost d1 = cost dac ) decreases. At time = 2519, the cost of the task switch, namely, c switch , is less than the opposite cost of not switching, namely, c wait . This is because c switch is the sum of the following costs: suspension of the task of r a d2 , completion of the task of r a d1 (approaching John and guiding John to his destination) and completion of the task of r a d2 starting from the John's destination pose. c wait is the sum of the following costs: completion the ongoing task of r a d2 and completion of the task of r a d1 starting from the Alice's destination pose. Therefore, in response to the environmental setup change (John's movement), the former is less than the latter. Until time = 2527, r a d2 was suspending its task; finally, at this time, r a d1 can resume its task. r a d1 completes stages S (guiding John to his destination), the robot received a request for the Peter fell task. r a d3 is initialised, and as the Peter fell task is of humanFell type ( r a d3 ∈ F r ) and the guide John task is of guideHuman type ( r a d1 ∈ G r ), the condition in line 10 of Alg. 2 is satisfied, and r a d3 is immediately assigned to c c ha,irrDA . At this point, r a d1 switches to S genSusp d1 , which, according to (47) , and the robot apologises to John, asks him to stop following it and stores his current pose. Finally, r a d1 switches to S wait d1 , and pf switchDA ha sends a start signal to r a d3 at time = 2570.
Next, while the robot is moving to the Peter fell destination (the dashed circle in Fig. 10), it receives a request for the Sara fell task (whose position is marked with a dotted circle). Comparison of c switch and c wait at time = 2593 resulted in a task switch; hence, r a d3 , following FSM d3 , switches to state S wait d3 , and the robot starts the Sara fell task.
Next, at time = 2602, r a d3 is in S wait d3 and is calculating f wait d3 (including pf report d3 ). It receives information that Peter is fine and there is no need to check his health status. Consequently, f wait d3 sends a report to r a ha based on (19): ha y c d3,report = [end, scheduleParams] As a result, term event is triggered (36) and pf switchDA ha removes r a d3 from set r A da . During the verification, there was no candidate for c c ha,irrDA in the following periods: between the initialisation of r a d1 (time = 2450) and r a d2 (time