Tailoring the MontiArcAutomaton Component & Connector ADL for Generative Development

Component&connector (C&C) architecture description languages (ADLs) combine component-based software engineering and model-driven engineering to increase reuse and to abstract from implementation details. Applied to robotics application development, current C&C ADLs often require domain experts to provide component behavior descriptions as programming language artifacts or as models of a-priori mixed behavior modeling languages. They are limited to specific target platforms or require extensive handcrafting to transform platform-independent software architecture models into platform-specific implementations. We have developed the MontiArcAutomaton framework that combines structural extension of C&C concepts with integration of application-specific component behavior modeling languages, seamless transformation from logical into platform-specific software architectures, and a-posteriori black-box composition of code generators for different robotics platforms. This paper describes the roles and activities for tailoring MontiArcAutomaton to application-specific demands.

💡 Research Summary

The paper addresses the limitations of existing component‑and‑connector (C&C) architecture description languages (ADLs) when they are used for robotics development. Traditional C&C ADLs excel at describing the structural composition of a system—components, ports, and connectors—but they typically require the internal behavior of components to be expressed either as raw source code (e.g., Java, C++) or as models built with pre‑defined, often mixed‑purpose behavior languages. This creates two major problems for robotics engineers: (1) domain experts cannot conveniently model robot‑specific control logic at the model level, and (2) the resulting architecture models are tightly coupled to a particular middleware or hardware platform, forcing extensive manual transformation when the target platform changes (e.g., from ROS 1 to ROS 2, from a desktop simulation to an embedded controller).

To overcome these issues, the authors present the MontiArcAutomaton framework, which extends the MontiArc C&C ADL with three complementary capabilities: (i) structural extension, (ii) integration of application‑specific behavior modeling languages, and (iii) a black‑box composition mechanism for platform‑specific code generators.

Structural Extension – MontiArcAutomaton leverages the MontiCore language workbench to allow the base MontiArc meta‑model (components, ports, connectors) to be subclassed and enriched with additional elements such as state‑machine definitions, event triggers, or any domain‑specific constructs. This extension is performed at the meta‑model level, so new language constructs become first‑class citizens in the same modeling environment used for the structural architecture.

Behavior Modeling Integration – Domain experts can define their own domain‑specific language (DSL) for component behavior. The DSL’s grammar, context conditions, and semantics are added to MontiCore, automatically generating a parser and abstract syntax tree (AST) that can be embedded directly into a MontiArc component model. Consequently, a single model file can contain both the structural description and the behavior specification, preserving consistency and enabling model‑level validation (e.g., type checking of ports against behavior inputs/outputs).

Platform‑Specific Code Generation – The transformation from a platform‑independent logical architecture to executable code is organized as a chain of code generators. Each generator consumes a model (or an intermediate representation, IR) and produces either another IR or target source code. The chain typically consists of: (1) a structural generator that creates a skeleton in the target language, (2) a behavior generator that translates the DSL into concrete code fragments, and (3) a platform adapter that injects middleware‑specific APIs (e.g., ROS 2 publishers/subscribers, YARP ports, or proprietary real‑time APIs). Importantly, generators are treated as black boxes; they expose only their input and output contracts. Adding support for a new robot platform therefore requires only the implementation of a new final‑stage generator and possibly a small adapter, while the earlier stages can be reused unchanged.

The authors formalize the tailoring process through a role‑and‑activity model. Four primary roles are identified: (1) Architecture Designer – defines the high‑level C&C structure; (2) Behavior Modeling Expert – creates the DSL and writes behavior models; (3) Code Generator Engineer – implements the template‑based generators for the DSL and the structural skeleton; (4) Platform Engineer – builds the deployment pipeline (build scripts, container images, real‑time OS integration). Each role performs a set of activities such as requirements analysis, meta‑model extension, parser/semantic implementation, transformation rule definition, model‑based testing, and CI/CD configuration. By separating concerns in this way, large multidisciplinary teams can work concurrently without stepping on each other’s toes, and artifacts become highly reusable across projects.

Two case studies illustrate the approach. In the first, a mobile robot built on ROS 2 is modeled with MontiArcAutomaton; a state‑machine DSL describes navigation logic, and the ROS 2 C++ generator automatically produces nodes, topics, and service definitions. In the second case, an industrial collaborative robot uses a custom DSL for high‑frequency motion control; the Java generator creates real‑time compliant classes that integrate with the robot’s proprietary controller. In both scenarios, a single change to the high‑level model (e.g., adding a new sensor or modifying a state transition) triggers an end‑to‑end regeneration of the entire software stack, demonstrating “model‑to‑code continuity”.

The paper concludes by outlining future work: extending the framework to support runtime reconfiguration, model‑in‑the‑loop (MIL) control, and cloud‑based robot services; improving formal verification of DSL semantics; and establishing standardized test benches for behavior models. Overall, MontiArcAutomaton offers a systematic, extensible, and platform‑agnostic pathway to bridge high‑level architectural modeling with concrete robot implementations, thereby enhancing reuse, reducing manual effort, and enabling continuous integration in complex robotics projects.