This page contains the analysis for RQ2 in terms of formalisms peculiarities, strengths and limitations.
Jump to Scenarios Jump to Analysis ResultsThe following mission peculiarities capture specific aspects of how formalisms model robotic missions.
Behaviors that allow the robot to respond to events or errors requiring to perform additional actions.
Choices made at runtime based on the current system state or overall context.
Behaviors that have to be executed periodically after a specified interval, triggered after a certain delay, or constrained by timeouts.
Tracking the execution status of an action, e.g.., if it is completed, ongoing, or if an error occurred.
Direct interactions between multiple robots involved in the mission, such as inter-robot communication and synchronization.
Explicit communication from the robot to the human and vice-versa, e.g., prompting instructions and getting human feedbacks, or tasks to be executed together with or only by humans.
Explicit communication between the robot and external systems, e.g., web services, databases, for sending/receiving data, commands, etc.
Pausing and resuming of the current execution, for allowing a temporary interruption of the current task for executing extraordinary actions (e.g., if an event or an error occurs), and resuming the mission afterwards.
Behaviors that keep the robot in a busy-form of waiting for specific events or conditions before starting or proceeding with the execution of the mission.
A robot is tasked to find a ball, pick it up, and place it into a bin. If the robot fails to complete the task, it should go to a safe position and wait for a human operator. After picking up the ball, the robot moves towards the bin. While moving towards the bin, an external entity takes the ball from the robot’s gripper and immediately throws it in front of the robot, where it can be seen. The robot aborts the execution of moving and it starts to approach the ball again.
A humanoid robot is tasked with interacting safely and intuitively with nearby humans while performing a set of predefined daily activities. The robot continuously monitors its environment for safety, if a bumper is pressed, it immediately backs away and warns by saying “Ouch.” When idle or uncertain, the robot asks the user what to do next. If the user provides a suggestion, the robot updates its current activity accordingly. If the robot already knows what to do, it proceeds autonomously. The robot can perform several activities, including sitting down, standing up, playing a ball game, saying goodbye, and going to sleep. During the ball game, the robot searches for the ball, approaches it, grasps it, and can track or throw it as required by the game. If the ball moves or is thrown again, the robot interrupts its current motion and immediately begins approaching the ball’s new location. When the user ends the interaction, the robot waves or says goodbye. If instructed to sleep, or if no further tasks are available, the robot moves into a safe resting position.
Every two hours, all patient's vital signs should be checked. Therefore, the assigned robot should visit every occupied room. Before entering the room, the robot must check if the patient is available for vital signs checking, and if there is enough battery to perform all the tasks inside the room. Hospital rooms may have one or more beds. So the robot has to identify the correct patient either by asking or by scanning the patients barcode. If the patient is not available, the robot should come back in 5 minutes. If there is not enough battery, the robot should recharge and the tasks need to be reassigned. Once inside the room, the robot should approach the patient, announce the procedure to be performed, and provide instructions to the patient. The failure of collecting any necessary vital signs should trigger a set of questions to assess the patient status for those signs that were failed to be collected. In case of non-response, an alert should be sent to the responsible nurse/doctor. Once the patient is checked, the robot should mark it as done and proceed to the next room.
Every room that reaches more than 1 cfu/cm2 of Staphylococcus aureus must be cleaned within the next 30 minutes. The assigned robot must check if it has all the resources to fulfill the tasks. In the case of missing equipment, the robot must go to the storage room to collect the equipment or assign the go-to-storage task to a colleague. As the robot reaches the room, it must check if it is occupied. If the room is occupied, a message should be sent to the manager and the mission aborted. Otherwise, the robot should enter the room and mark it as occupied. The cleaning task must be performed in order: (i) change the furniture's covers, towels, and clothes; (ii) vacuum the floor, moving furniture when necessary; (iii) wipe the floor, and (iv) sterilize all furniture and equipment in the room. In case of failure in performing any of the steps, it immediately warns the sector manager, but does not stop executing the mission. In case of a low battery, recharge it and come back to finish the task.
The system should deliver food from the kitchen to an inpatient room. The delivery is made on an order-by-order basis in response to kitchen delivery requests. The food can be delivered into a room table by the robot (requires a special manipulation robot skill) or the food can be fetched from the robot's tray. Fetching from the robot tray requires cooperation with the inpatient, a companion, a nurse, or another robot. Some inpatients could be unable to fetch the food from the tray, and a companion visitor or nurse could not be available at the moment of the delivery. The information about if the inpatient, a companion visitor or nurse can be able to retrieve the food from the tray can be obtained based on the inpatient record according to information about the patient and the presence of a companion into the room. This information is subject to uncertainty. The robot can carry multiple meals, in the case of a person retrieving the meal the robot should indicate which meal should be retrieved by a given inpatient. It should track when and where each meal was retrieved. The robot should alert if a wrong meal is retrieved. Dirty dishes should be retrieved from the room. As with delivery, the dish retrieve can occur unassisted, with the cooperation of two robots or with the cooperation of robots and a human. Opening the room door can involve cooperation with another robot or a human. Someone in the room can call a robot to pick up the dishes. In that case, that person can signal if they can open the door when the robot comes to it.
Lab samples should be transported from patient floors to the laboratory. A nurse responsible for collecting a sample can request a delivery to the laboratory. Each sample before collection is identified with a barcode. The nurse inserts data about the sample in a track system. Samples are transported in secure locked drawers. In the laboratory, the sample can be picked by a robotic arm or laboratory personnel. Only authorized personnel or specific robots in specific locations should be able to open the locked drawers. The robotic arm picks up samples, scans the barcode in each sample, sorts, and loads the samples into the entry-module of the analysis machines. Information about where and when a given sample was picked should be logged securely. The time between sample collection and laboratory delivery should be tracked to be sure that it goes according to laboratory protocols.
A robot should identify visitors or patients, and then, thanks to the robot's connection to the hospital's administrative database, the robot would indicate where the patient should go. If the patient needs help to reach the destination, the robot would send a request for help to the professional who is managing the entrance to decide if the robot can leave its position at that moment to accompany the person to his/her destination, or should wait in its position. At all times, the healthcare operator who is waiting for the person will know the exact place where the patient is. Visitors can also be helped. The robot can help the person find the destination or the closest information point in the ward. While idle, the robot can begin extra tasks if a human request does not preempt them, such as the identification of patients with fever.
When required, a robot must collect the required resources in the storage and deliver them to the requesting agent in a specified location. In the collection phase, the robot must go to the storage places where the resources can be found. The order to be followed is defined by the estimation of waiting time summed up with the path to be run by the robot. Once the robot reaches one storage and it is time to request the resource, the robot sends a message to the storage with the precise specification of the requested resources and waits until the resources have been retrieved. Once retrieved, the delivery phase begins. In this phase, the robot will make as many runs as necessary to take all the resources to the specified location. If the battery of the assigned robot runs low (10%) in the collection phase, the robot goes back to the recharging station and assigns the mission to another robot. If the battery of the assigned robot runs low (30%) in the delivery phase, the robot must return the resource to a checkpoint and assign the remaining task to another robot, which will know where the resource is positioned. In case of failure to return the resource to a checkpoint, an alert must be triggered and the report sent to the sector manager. When multiple items are required from different storages, multiple robots can be assigned to parallel collect-deliver tasks to reduce the time to finish the mission.
The use case in this exemplar is about an AUV inspecting pipelines located on a seabed. Its mission consists of two sequential tasks, (T1) searching for the pipeline, then (T2) simultaneously following and inspecting the pipeline. When performing its mission, the AUV is subject to two sources of uncertainty that could trigger self-adaptation: (U1) thruster failures and (U2) changes in water visibility. U1 arises from the possibility of the AUV’s thrusters failing at runtime, which may cause the AUV to move unexpectedly. This is relevant for both T1 and T2. To overcome U1, the managed subsystem of the AUV contains functional alternatives. When one or more thrusters fail, it is possible to enter a recovery state in which the thrusters are recovered. U2 influences the maximum distance at which the AUV can visually perceive objects. This is relevant for T1, higher water visibility allows the AUV to search for the pipeline at higher altitudes, resulting in a larger field of view and the possibility of discovering the pipeline faster. On the other hand, if the water visibility is low, the AUV has to move closer to the seabed to search for the pipeline, which limits its field of view and therefore may lead to a longer time to discover the pipeline. Thus, changing the altitude of the AUV provides functional alternatives for dealing with U2.
In a smart agricultural scenario a drone and two tractors that cooperate to identify and remove weed grass in farmland, to increasing productivity. At the system start-up, the drone takes off and starts exploring the field. During the flight, it can recognize weed grass areas, and when found, it sends the weed position to the tractors. Identifying a weed enacts the tractors, which send back their current position to the drone. The drone can hence elect the closest tractor and notify it. At this point, the selected tractor starts moving toward the field to reach the weed grass area and cut it. The execution of the robots may be interrupted if their batteries run out or the whole mission has been fulfilled.
New orders arrive periodically and must be processed by coordinating workers and a mobile robot in the warehouse. When a new order is detected, the system identifies the list of raw materials required for its fulfillment. Before starting, the system assigns the order to an available robot. For each required material, the system also determines the storage location. A worker must meet the robot at the designated location and load the correct amount of material. After the loading operation, the worker confirms completion, and the system verifies that the loaded quantity matches the expected weight. If the check fails, the worker must correct the loading before the robot proceeds. Once loaded, the robot transports the material to the mixing area, where it is manually unloaded by a worker. The process then continues with the next material in the order. If all materials have been delivered, the worker initiates the mixing procedure. After the mixing phase begins, the system updates the order status to indicate completion. The robot then returns to its home position and becomes available for the next order. If an error occurs at any point—for example, a mismatch in material loading or an operational issue—the system notifies the worker, who must decide whether to cancel the order or complete the remaining steps manually.
| Mission concern | BT | SM | HTN | BPMN | Rationale |
|---|---|---|---|---|---|
| Reactive behavior | ● | ● | ○ | ● | BT and SM leverage their reactive nature and event-handling structures. BPMN features boundary events and event sub-processes. HTN does not support it. |
| Decision making | ● | ● | ● | ● | SM and BPMN feature conditional control structures for runtime decision-making. In BTs it is realized by combining fallbacks and sequence nodes. HTN relies on planning according to pre- and post-conditions associated to methods. |
| Time-dependent behavior | ◐ | ◐ | ○ | ● | In BT and SM it has to be realized by manually implementing the control of timing through condition nodes and state implementations, respectively. BPMN features timer events. HTN does not support it. |
| Task status | ● | ● | ○ | ● | BT, SM, and BPMN support it through the value returned by the tick, the events outgoing from a state, and the activity lifecycle, respectively. HTN does not support it. |
| Robot-robot interaction | ◐ | ◐ | ◐ | ● | BT, SM, and HTN rely on the action nodes, states, and tasks implementation, respectively. BPMN has dedicated structures, i.e., message and signal events for communication. |
| Human-robot interaction | ◐ | ◐ | ◐ | ● | BT, SM, and HTN rely on the action nodes, states, and tasks implementation, respectively. BPMN supports user and manual tasks, and the explicit modeling of communication with message/signal events. |
| Robot-external system interaction | ◐ | ◐ | ◐ | ● | BT, SM, and HTN rely on the action nodes, states, and tasks implementation, respectively. BPMN has dedicated task types (service task, send task, receive task) and message/signal events. |
| State saving and task resuming | ◐ | ◐ | ○ | ○ | BT offers control flow nodes with memory to keep track of the overall status of the mission, or can rely on a shared knowledge base (blackboards) to keep track of already executed tasks. SM requires ad hoc states and events to first pause and then resume the execution. HTN and BPMN do not support it. |
| Explicit waiting | ◐ | ◐ | ◐ | ● | BT, SM, and HTN rely on the ad hoc implementation of action nodes, states, and tasks, respectively. BPMN supports intermediate events of different types. |