Model-Driven Separation of Concerns for Service Robotics Kai Adam, Arvid Butting, Robert Heim, Oliver Kautz, Bernhard Rumpe, Andreas Wortmann Software Engineering RWTH Aachen University, Germany http://www.se-rwth.de Abstract main experts to describe tasks as sequences of goals a robot Robotics currently adopts model-driven engineering focus- should achieve. Tasks operate in the context of a domain ing software modeling languages. This forces domain ex- model, a robot model, and a world model. All are translated perts to employ these languages instead of enabling appli- into integrated GPL implementations that employ a planner cation of more appropriate DSLs. This ultimately produces to solve tasks in a dynamic environment. The implementa- monolithic, hardly reusable applications. We present an in- tions are integrated with robot-specific GPL code provided frastructure for the development of service robotics appli- by robotics experts. The task planner translates tasks into cations employing DSLs aimed at domain experts and tai- sequences of actions that are executed on loosely coupled lored to domain challenges. It facilitates separation of con- robot platforms. The modeling infrastructure is integrated as cerns of participating robotics, domain, and software engi- a C&C architecture developed by integration experts. neering experts and integrates their models via a component & connector reference architecture and a combined code models Robot World Goal Task generation framework. The infrastructure was successfully deployed and evaluated with robotics manufacturers, care- imple- domain ments «generated» «generated» expert givers, and software engineers in a German hospital. We GPL Code Plan Artifacts believe that model-driven engineering with languages tai- robotics expert Robot & World Task inte- lored to the various stakeholders’ needs can greatly facilitate GPL Code Planner grates robotic application engineering. C&C Architecture integration Keywords Separation of Concerns, Domain-Specific Lan- expert guages, Code Generation, Service Robotics Figure 1. Separation of concerns is achieved by separation into roles with different expertises. 1. Introduction We have detailed the DSLs enabling such separation of Engineering robotics applications is a complex endeavor that concerns for service robotics applications in (Heim et al. requires solutions from multiple domains as well as their 2015). This paper presents its (1) integrated code generation successful integration. Domain experts (such as hospital IT and model execution infrastructure and (2) an evaluation staff) are rarely software engineering experts and due to the with praticioners in a German hospital. conceptual gap between domain challenges and their soft- In the following, Sect. 2 motivates separation of concerns ware engineering solutions (France and Rumpe 2007), in- and modeling in service robotics, before Sect. 3 sketches the tegration of their solutions often results in monolithic soft- DSLs. Afterwards, Sect. 4 presents the code generation in- ware architectures that are hardly reusable in different con- frastructure and Sect. 5 illustrates models execution. Sect. 6 texts (Schlegel et al. 2011). This severely hampers service describes the evaluation. Sect. 7 discusses observations and robotics adoption (Hagele¨ et al. 2011). Model-driven engi- Sect. 8 highlights related work. Sect. 9 concludes. neering with domain-specific languages (DSLs) can facili- tate robotics software engineering by abstracting from the complexity of general programming languages (GPLs) and 2. Scenario by enabling domain experts to contribute solutions in better Consider engineering of a service robotics application to suitable languages – ultimately reducing the conceptual gap. support hospital caregivers in logistics tasks. Successfully We propose to separate concerns of domain experts, deploying it requires expertise in robotics, software en- robotics experts, and integration experts by providing appro- gineering, and the application domain. Instead of forcing priate DSLs as depicted in Fig. 1. These DSLs enable do- robotics experts and domain experts to use noisy (Wile 2001) [BHKRW16] A. Butting, R. Heim, O. Kautz, B. Rumpe, A. Wortmann: Model-Driven Separation of Concerns for Service Robotics. In: International Workshop on Domain-Specific Modeling (DSM'16), pages 22-27. ACM, 2016. www.se-rwth.de/publications/ domain actors goals tasks * 0..1 robot Domain * Actor 0..1 world Goal * Task Type * * Property Action associates meta model conforms instance extends Way Rooms Logistics comprises Room IsAt Move point World Robot Figure 2. Top depicts the service robotics application meta model, bottom depicts conforming models. and overly complex (France and Rumpe 2007) GPLs, they itates their platform-independent description (Heim et al. are provided with DSLs tailored to the challenges of service 2015). An application is modeled using heterogeneous, inte- robotics logistics tasks. Proper integration of these DSLs and grated modeling languages for different aspects (Haber et al. their automated transformation into GPL artifacts enables to 2015). The meta model of applications is depicted at the top describe solutions in a more abstract, reusable fashion with- part of Fig. 2. The data types of a domain are modeled as out interfering with the other experts’ domains. UML/P class diagrams (CDs) (Rumpe 2016). They describe An typical task in this scenario is the robotic delivery of the static context of an application. Each application com- supplies from a storage room to a patient’s room. Success- prises two actors: The world describes properties and ac- ful deployment of a suitable robotic platform1 requires that tions of the application environment, the robot describes robotic experts provide the hardware and software required properties and actions of the platform. Properties of an ac- for a movable robot that can interact with caregivers. Do- tor are dynamic domain qualities and actions are executable main experts contribute knowledge about the causalities of operations. An action can define parameters of domain data the hospital (for instance, which floors are accessible for the types and has two Boolean expressions: a precondition must robot). Ultimately, software engineering experts integrate hold for the action to be executable and a postcondition that the solutions of robotics experts and domain experts. is assumed to hold after the action has been executed. State- With proper DSLs, domain experts define declarative ments of these expressions can be values of parameters or tasks as sequences of reusable goals that abstract from the values of properties of another actor. In this, our model- specific platform. Instead they describe requirements on ing language for robots and worlds resembles classic plan- robot and world in form of abstract actor models. For in- ning languages (Fikes and Nilsson 1972). Action execution stance, a task may prescribe that the robot first visits the is delegated to actor implementations as employing robotics storage room, loads the required supplies, visits the patient’s middlewares. Goal models may reference a robot, a world, room, and unloads. The goals might entail requirements on and domain data types. The latter can be used to parametrize the robot and world (such as having a position), but abstract goals. Each goal model contains a Boolean expression that from their implementations. From these models, the infras- reflects a situation, which must be satisfied at an instant to tructure generates interfaces that robot experts implement consider the goal fulfilled. The value of the goals’ param- to realize functionalities on the platforms. Hence, they are eters as well as imported properties of robot and world ac- liberated from dealing with domain causalities. The soft- tors can be used as statements of the expression. Tasks are ware engineers instantiate the infrastructure’s reference ar- sequences of parametrized goal references. Similar to goal chitecture and extend it with application-specific compo- models, tasks can be parametrized with domain types. A nents as necessary. The architecture uses the interfaces gen- task can provide its parameters to its referenced goals. For a erated from task, domain, robot, and world models and takes task to be executed successfully, the referenced goals have to care of task execution using the implementations provided be satisfied sequentially. The existence of referenced model by robotics experts. Deploying a similar application – for in- elements from different modeling languages is checked via stance to another domain or with another platform – requires inter-language well-formedness rules (Heim et al. 2015). to adjust the implementations of robot models or the compo- The bottom part of Fig. 2 describes an example applica- sition of tasks only. This facilitates successful deployment tion comprising instances conforming to the respective meta of model-driven service robotics applications. model elements. The example application describe as basic logistics scenario in which Waypoint instances describe 3. Modeling Service Robotics Applications the topology of the environment. Some waypoints are rooms that can be addressed with a name. The RoomsWorld Pervasive modeling of service robotics applications com- actor knows waypoints and for each pair of waypoints, prising of a domain, tasks, goals, robots, and worlds facil- the RoomsWorld indicates whether they are adjacent or 1 Platform comprises hardware and software to provide