Engineering software for robotics applications requires multidomain and application-speci c solutions. Model-driven engineering and modeling language integration provide means for developing specialized, yet reusable models of robotics software architectures. Code generators transform these platform independent models into executable code speci c to robotic platforms. Generative software engineering for multidomain applications requires not only the integration of modeling languages but also the integration of validation mechanisms and code generators. In this paper we sketch a conceptual model for code generator composition and show an instantiation of this model in the MontiArcAutomaton framework. MontiArcAutomaton allows modeling software architectures as component and connector models with di erent component behavior modeling languages. E ective means for code generator integration are a necessity for the post hoc integration of applicationspeci c languages in model-based robotics software engineering.
Software engineering for robotic systems is inherently complex due to the
heterogeneity of the systems and their challenges from various domains (e.g.,
navigation, sensor fusion, manipulation). Thus, robotics software is usually
developed by teams of domain experts with di erent views and understanding of
the systems functionality. This leads to hardly reusable software limited to
speci c platforms [
Model-driven engineering (MDE) is an approach to reduce the conceptual
gap [
We have combined MDE and software language engineering based approaches
with concepts from generative software development in a versatile framework for
robotics applications development. MontiArcAutomaton [
Language integration in MontiArcAutomaton is enabled by the MontiCore
domain-speci c language workbench [
The easy integration of modeling languages demands for integration mechanisms of corresponding code generators. Challenges are the coordination of multiple code generators each responsible for speci c models or parts of models. This includes the selection of code generators supporting a common target platform, to handle language restrictions a code generator might impose, and to propagate necessary generation context information between generators. Integrating code generators should require no modi cation of the participating generators.
In this paper we sketch a conceptual model for code generator composition and show its instantiation in the MontiArcAutomaton framework. We introduce MontiArcAutomaton in Sect. 2 and state and illustrate the problem of code generator composition in Sect. 3. Section 4 describes our solution and Sect. 5 describes an implementation in MontiArcAutomaton. We discuss related work in Sect. 6 and future work in Sect. 7. Section 8 concludes this contribution. 2
MontiArcAutomaton [
The concept of encapsulation from C&C ADLs allows not only a logically distributed development and a physically distributed computation model but also the composition of component behaviors independent of their behavior description. MontiArcAutomaton exploits the C&C encapsulation mechanism and allows the embedding of arbitrary modeling languages into components for providing the most suitable behavior description language per component.
We have developed MontiArcAutomaton using the domain-speci c language
workbench MontiCore [
MontiCore supports language embedding, language extension, and language
aggregation [
In previous works we have developed the MontiArcAutomaton modeling
language with embedded I/O! automata and I/O tables [
MontiArcAutomaton allows to embed application-speci c behavior modeling languages into components to facilitate the development of exible, reusable, yet 3 Video of an editor for synchronous graphical and textual editing of MontiArc
Automaton models: http://www.monticore.de/robotics/ 4 Website of the FreeMarker Java template engine: http://freemarker.org/ speci c robotics applications. While the ability to use speci c behavior modeling languages allows to develop speci c applications, the encapsulation of models in components with well-de ned and stable interfaces allows to modify component internals easily, e.g., to replace the speci c behavior modeling language, while retaining a stable architecture.
Engineering C&C applications with the exibility of arbitrary embedded behavior modeling languages demands for approaches to generate code from heterogeneous models. As languages and code generators can be integrated into MontiArcAutomaton post hoc, code generators have to be composable to allow black-box integration. Each composable code generator produces only parts of the overall generated software system. A framework to support code generator composition has to provide a mechanism to con gure C&C applications with different code generators. Realizing composition of code generators requires support for code generator reuse, the ability to handle code generators that are agnostic of any component structure speci cs (e.g., how port or connectors work), and dependency management between di erent code generators. 3.1
A software engineer is responsible for the development of a controller for a robotic arm. The robot assists a physically disabled person in a kitchen environment to operate a toaster. The robot is supposed to place bread in a toaster, operate the toaster, and deliver the toast to a nearby plate. The software engineer models the architecture and controller behavior platform independently using MontiArcAutomaton with embedded I/O! automata and RobotArm (RA) programs. The latter describe motion of the arm in terms of de ned locations and gripper commands.5 The engineer embeds the existing language RA into the MontiArcAutomaton framework using the language integration mechanisms of MontiCore. The software architecture of the robot is depicted in Fig. 1. The component Controller receives distances and toast color from attached sensors. The I/O! automaton modeling the behavior of Controller translates these inputs into commands for the ToasterController, which starts and stops the actual toaster, and the component ArmController, which actuates the robotic arm to pick up and deliver toast. The behavior of component ArmController is modeled as a set of RA programs.
To generate executable code from the architecture, the software engineer has to provide a code generator for the embedded RA language which translates RA commands into code for the target platform. This code generator can be selected from a library of existing code generators or newly developed. Finally, the generator has to be integrated into the framework, such that it is executed whenever a component with RA programs is processed. 5 A video of the robotic arm: http://www.monticore.de/robotics event
Toaster Controller
command Controller program } ...
Arm define home 0deg down; define toaster 120deg 20cm; program PickupFromToaster { move up; open; move toaster; close; move up; ToastServiceRobot Color Sensor UltraSonic Sensor color distance
ack In this section we propose an approach to code generator composition on a conceptual level. First, we describe code generator interfaces that support generator composition as motivated in Sect. 3. Second, we sketch the process of code generator composition and execution of the composed generators using information from code generator interfaces.
To achieve generator composition, each code generator explicates all information necessary within an interface. This interface is used during code generator orchestration to con gure and execute the code generator. De nition 1 lists the elements of a code generator interface.
De nition 1 (Code Generator Interface). A code generator interface contains the following elements: 1. Input language: The language or language fragments the generator processes. 2. Input language constraints: A generator may restrict the processable models via generator-speci c context conditions. 3. Output representation: The output representation states the language and format of the output. 4. Execution information: De nes how a generator is executed. 5. Artifact dependencies: A generator may produce code that depends on external libraries, runtimes, or code produced by another code generator. Such artifact dependencies have to be explicitly stated in order to satisfy dependencies of generated artifacts. 6. Generation context information: Additional information provided or required at generation time.
Multiple generators are composed to generate code for models of the software of a robotic system. The composition of code generators is described in an application con guration model which contains a selection of all code generators involved. It may also contain a con guration of generation context information
uses configures
Generator Orchestrator calls *
Generator Interface
Code Generator * requires produces
requires Generated
Output *
Artifacts for code generators. Composing generators according to a con guration model requires the orchestration of all selected code generators. Such an orchestration requires (a) to check that all required information is provided and (b) to compute an execution order of the code generators.
If for each code generator all required generation context information is provided by the selected code generators and an execution order can be computed, then the code generator composition can be performed. However, the execution order of the code generators is in uenced by the dependencies described by the generation context information. There are two types of dependencies. First, a code generator may require generation context information from another code generator. Second, a code generator may use the output of another code generator. Both types of dependencies imply that the code generator providing required information or output is executed rst. However, in some cases it is possible that an execution order cannot be computed. In this case the code generators cannot be composed.
Our concept of code generator composition is presented in Fig. 2. An application model con gures a generator orchestrator. The generator orchestrator uses the generator interface of each code generator to check for dependencies and computes an execution order. Finally, the generator orchestrator calls each code generator according to the computed execution order. 5
The MontiArcAutomaton implementation of the conceptual model presented above comprises an implementation of generator interfaces, which is facilitated by a con guration language that generates interface implementations, an application con guration to declare compositions of code generators, and an orchestrator performing the composition. 5.1
Based on the concrete requirements for code generators in MontiArcAutomaton we re ne the code generator interfaces de ned in Def. 1. The C&C nature of MontiArcAutomaton, suggests separate interfaces for component generators and component behavior generators. As MontiArcAutomaton relies on factories for «interface»
IBehaviorGenerator String getRuntime() Class getResponsibleAST () void configure(String packageName,
String filename, IFactoryGenerator f, Set<String> imports); * «interface»
IGenerator String getMainTemplate() Set<ContextCondition> getContextConditions() void setAST(ASTNode ast)
«interface»
IComponentGenerator String getRuntime() Class getResponsibleAST () void configure(List<IBehaviorGenerator> b,
IFactoryGenerator f) CD 1
«interface»
IFactoryGenerator void configure(String package,
String filename, String product, String realProduct, Set<String> generics Set<String> imports); component and component behavior instantiation, factory generators are modeled as well. Component generators process the MontiArcAutomaton language and behavior generators process the respective embedded behavior modeling language (Def. 1, Item 1) possibly restricted by additional context conditions (Def. 1, Item 2). The classi cation in three generator kinds determines the output format of the generators (Def. 1, Item 3).
Generator execution information is provided by the generators in terms of
the main template which the MontiCore code generation framework processes
(Def. 1, Item 4). This template may call other templates and call Java code for
complex calculations. All generators generate code conforming to a runtime
environment they depend on (Def. 1, Item 5). The runtime environment determines,
e.g., the scheduling of components. Generators in MontiArcAutomaton do not
explicate further artifact dependencies as MontiArcAutomaton utilizes the
delegator pattern [
An overview of the concrete generator interfaces implemented for MontiArcAutomaton is displayed in Fig. 3. Every generator usable with MontiArcAutomaton implements an interface extending IGenerator. Thus, each generator can be parametrized with an AST node and provides at least its main template and its context conditions to the infrastructure. Generators for components and component behavior implement the interfaces IComponentGenerator and IBehaviorGenerator respectively. These interfaces explicate which AST types they can process.
Additionally, all generator interfaces de ne a method to configure() which is interface speci c and de nes the generation context information required. Generators for component behavior, e.g., expect to receive the package name of the containing component, the name of the artifact to be created, a factory generator, and the imported compilation units. The latter is required as embedding behavior into components produces integrated artifacts without distinction between the imports of the component and the imports of the behavior. GeneratorConfiguration
2 interface generators.IBehaviorGenerator; 3 template robotarm.Main; 4 ast robotarm.ASTRobotArmProgram; 5 runtime runtimes.pythontimesync; 6 } Listing 1: The generator con guration for the RobotArm generator describes that it implements the interface IBehaviorGenerator and provides static information. 5.2
To facilitate the creation of code generator interfaces we have developed a modeling language for generator interfaces. Each code generator used with MontiArcAutomaton models how it is executed, which AST it processes, and which interface it implements in a single generator con guration model per generator. Listing 1 shows the model of the RA generator from the example in Sect. 3.1. This model describes that the generator implements the interface IBehaviorGenerator and provides information accessable via this interface. The MontiArcAutomaton toolchain transforms these models into actual implementations implementing the interfaces.
The concrete implementation of the interface IBehaviorGenerator for the RobotArm generator from the example given in Lst. 1 provides implementations for all methods of IGenerator and IBehaviorGenerator and returns the static generator information from the model where applicable (e.g., getResponsibleAST() returns an instance of the type speci ed behind ast in l. 4 of Lst. 1). The MontiArcAutomaton orchestrator can refer to these implementations via the implemented interfaces and compose generators as necessary. 5.3
Given a set of generators for component structure, behavior, and factories, an application has to specify which of these are to be used. This is modeled as the application con guration model. Listing 2 shows the application con guration for the toaster robot application. The model references a single component generator (l. 2), a single factory generator (l. 3), and two behavior generators - one for RA programs and one for I/O! automata (l. 4). An application con guration references at least a component structure generator and may reference additional behavior and factory generators.
Code generation in MontiArcAutomaton starts with the orchestrator processing the application con guration and loading the con guration of the referenced generators. As the order of generator execution is implicitly given by the C&C nature of MontiArcAutomaton, rst the referenced behavior generators and the ApplicationConfiguration
2 componentgenerator ComponentsPython; 3 factorygenerator FactoryPython; 4 behaviorgenerators RobotArmPython, IOAutomatonPython; 5 } Listing 2: Application con guration model for the toaster robot application using the RA generator for component behavior. referenced factory generator are instantiated. Parametrized with these, the referenced component generator is instantiated. Afterwards, the orchestrator calls the main template of the component generator. The component generator traverses the AST of the architecture and thus also visits component behavior AST nodes. For each behavior AST node the responsible generator is con gured with current AST generation context information and its main template is called with the AST node of the embedded behavior language.
Figure 4 shows the resulting relations: Applications consist of a software architecture, and an application con guration model. The application con guration model references the component, behavior, and factory generators required to build the software architecture of the project. To be processable by the orchestrator, referenced generators implement the appropriate generator interfaces. 6
The presented approach for code generator composition is based on explicit generator interfaces, code generator orchestration, and application con guration. This approach is a rst step towards a comprehensive approach for code generator composition and is closely related to modular code generator design.
The GenVoca model is an approach to build software systems generators
based on composing object-oriented layers [
The application building center is a multi-purpose modular framework for
modeling software systems [
Code generator composition using aspect-orientation at the artifact level has
been described in [
We have presented a conceptual approach for composition of code generators based on the notion of generator interfaces. The ideas are implemented within the MontiArcAutomaton toolchain to enable post hoc embedding and use of new component behavior modeling languages. To broaden its applicability this approach requires future work on syntax, methods, and technical solutions.
Composition of arbitrary code generators without assumptions on their actual integration is harder to realize than for C&C ADLs. In general, generator composition demands a more expressive composition con guration than the application con guration presented above. For instance, the orchestration of the code generation process may require a code generator to be executed multiple times for every input model or to ll extension points provided by another generator under certain conditions. Moreover, execution of a code generator may not be triggered by a model type but by selecting a code generator for a particular set of input models. A generic model to con gure an application has to express such process information and constraints. Thus, future research will look into modeling these aspects.
The generator composition illustrated above assumes that the orchestration
of generators re ects the language embedding for component behavior. Other
language integration mechanisms, such as language aggregation or language
inheritance [
Finally, modeling language composition mechanisms have lead to language reuse and language libraries. We hope to gain similar libraries and advantages from facilitating code generator composition. 8
We have motivated the need for generator composition in robotics and sketched a concept for code generator composition. This concept is based on explicit code generator interfaces and con guration models. The interfaces enable code generators to de ne information required for composition. A code generator orchestrator composes and executes the code generators. We have illustrated our implementation for the C&C modeling language family MontiArcAutomaton. Although the implementation relies on various assumptions implied by the language workbench MontiCore and the C&C nature of MontiArcAutomaton, we belief that these translate well into other contexts. There are however open issues in arbitrary generator composition and we have identi ed possible extensions of generator interfaces and generator orchestrators to be applied in more complex scenarios.