This article provides an introduction into the DSL (Domain-Specific Language) SmartTCL (Task Coordination Language). SmartTCL is used in the context of robotics behavior development in an 3T architecture on the sequencing layer (more details on the control architecture can be found in Robotic Behavior).

With SmartTCL different developer roles model tasks into behavior models, a robot is able to carry out. Tasks can be defined hierarchically, thereby high level tasks (such as “fetch coffee”) are refined to lower level tasks (such as “go to kitchen”, “fetch a cup”, “make coffee”) which again are further refined until a sufficient level of detail is reached to accordingly configure and coordinate the concrete software components (SKILL level behavior models).

During design-time tasks are modeled along the development process in parallel to the definition of the components and the system. Thereby, technology experts not only define the basic building blocks (i.e., the components) but also the generic and application independent sub-tasks (e.g., together with the navigation component, the sequence for the “go to some position” task is defined). This models directly interacting with the components are called SKILL behavior models, they raise the level of abstraction and make the functionality realized by the components accessible on a symbolic level within the sequencing and deliberation layer. During system composition, both, the individual building blocks (components) as well as the behavior models are combined to a system according to the target application.

Even though system integrators are aware of the target application they cannot predict all possible situations in advance. Instead, SmartTCL enables system integrators to define the general action plots for certain tasks together with open expansion points which are first bound at run-time. For instance, there are parts in action plots that cannot be predicted by the designer due to combinatorial explosion (e.g., the optimal sequence to stack cups). These parts are resolved at run-time by asking an expert component (such as a symbolic planner) on the deliberation layer. In addition, SmartTCL allows expressing rules which define how a system reacts (or respectively recovers) in case of contingencies in execution. In summary, the main purpose of SmartTCL is twofold, on the one hand to define the tasks (i.e., the action plots) and on the other hand to define variability in operation.

With SmartTCL a task-tree is dynamically created and modified at run-time, depending on situation and context. The nodes of the task tree are instances of Task Coordination Blocks (TCB). Each block comprises the action plot it executes and optionally a plan including references to other nodes (children). The TCBs are stored in the KB of the robot and instantiated at run-time just before execution. The concrete block is selected at run-time based on the current state and environment (precondition clause). The final decision how to further expand a node is taken at run-time. SmartTCL follows the principle of subsidiarity, each node has to try to fix issues according to the decision space in which the node is allowed to operate. In case the node is not able to fix this issue in the given decision space it has to announce that to its parent node.

In SmartTCL the reaction to failures is defined by rules. Whenever a TCB has finished, the return message is checked by the parent node and matched against the rules which are stored in the KB. The action plot of the matched rule is executed by the parent node, for example, to recover from a failure. Each block is responsible to do its best trying to achieve the expected goal and state an error message (return message) if it fails. In such a situation only the parent which has spawned the child node “knows” about the purpose of the node in a wider context and can thus react to the failure. That hierarchical structure of responsibilities ensures a clear separation of concerns. The rules can be used to define a corridor in which the task execution and management of the nodes in the task tree have to remain.

The following navigation example shows how coordination and configuration of the components works in interaction with the sequencer and the behavior models modeled using SmartTCL.

M. Lutz, D.Stampfer, A.Lotz and C. Schlegel. Service Robot Control Architectures for Flexible and Robust Real-World Task Execution: Best Practices and Patterns Informatik 2014, Workshop Roboter-Kontrollarchitekturen, Stuttgart, Germany, Springer LNI der GI, 2014

Dennis Stampfer, Alex Lotz, Matthias Lutz, Christian Schlegel. The SmartMDSD Toolchain: An Integrated MDSD Workflow and Integrated Development Environment (IDE) for Robotics Software. Special Issue on Domain-Specific Languages and Models in Robotics, Journal of Software Engineering for Robotics (JOSER), 7:3-19, 2016.

Alex Lotz, Juan F. Ingles-Romero, Dennis Stampfer, Matthias Lutz, Cristina Vicente-Chicote, Christian Schlegel. Towards a Stepwise Variability Management Process for Complex Systems. A Robotics Perspective. Int. Journal of Information System Modeling and Design (IJISMD), DOI: 10.4018/ijismd.2014070103, 5(3):55-74, 2014.

Andreas Steck, Christian Schlegel. Managing execution variants in task coordination by exploiting design-time models at run-time. In Proc. IEEE Int. Conf. on Robotics and Intelligent Systems (IROS), San Francisco, USA, September, 2011.