Using the DiaSpec design language and compiler to develop robotics systems

A Sense/Compute/Control (SCC) application is one that interacts with the physical environment. Such applications are pervasive in domains such as building automation, assisted living, and autonomic computing. Developing an SCC application is complex because: (1) the implementation must address both the interaction with the environment and the application logic; (2) any evolution in the environment must be reflected in the implementation of the application; (3) correctness is essential, as effects on the physical environment can have irreversible consequences. The SCC architectural pattern and the DiaSpec domain-specific design language propose a framework to guide the design of such applications. From a design description in DiaSpec, the DiaSpec compiler is capable of generating a programming framework that guides the developer in implementing the design and that provides runtime support. In this paper, we report on an experiment using DiaSpec (both the design language and compiler) to develop a standard robotics application. We discuss the benefits and problems of using DiaSpec in a robotics setting and present some changes that would make DiaSpec a better framework in this setting.

💡 Research Summary

The paper presents an experience report on using the DiaSpec domain‑specific design language and its compiler to develop a typical robotics application, illustrating how the Sense/Compute/Control (SCC) architectural pattern can be concretely applied to robot software. SCC divides an application into four layers – sensors, context operators, control operators, and actuators – which mirrors the classic Sense‑Plan‑Act architecture widely used in robotics. DiaSpec provides a textual DSL that lets developers declare entities (sensors/actuators), context operators (data‑processing components), and controllers (decision‑making components). From these declarations the DiaSpec compiler automatically generates a Java programming framework composed of abstract classes for each component. Developers then subclass these abstracts, implementing only the business‑logic methods while the generated framework handles wiring, deployment, and type checking.

The authors use ROS (Robot Operating System) as the underlying middleware for a case study robot equipped with a laser scanner, camera, light projector, and differential‑drive wheels. The robot operates in two modes: a simple random‑motion mode that steers away from nearby obstacles, and an exploration mode that follows a frontier‑based algorithm to visit unexplored areas. A graphical operator can switch modes at runtime. The design process follows a systematic decomposition:

1. Capability listing – robot hardware is mapped to DiaSpec entities (LaserScan, Light, Camera, Wheel, ModeSelector, Exploration).
2. Main context operators – Motion (produces a Twist command) and ObstacleZone (boolean indicating obstacle presence).
3. Lower‑level context operators – RandomMotion (twist for random mode), ObstacleDetection (processes laser ranges into an Obstacle structure).
4. Control operators – MotionController (sends Motion twists to the Wheel) and ObstacleManager (turns on the Light and triggers the Camera when an obstacle zone is detected).
5. Data types – reuse of ROS’s Twist type, definition of a RobotMode enumeration, and a custom Obstacle structure containing a Boolean flag and an array of range values.

The paper shows a fragment of the DiaSpec specification (entity, context, controller declarations) and explains how the compiler produces abstract Java classes. For example, the RandomMotion operator receives an Obstacle object via an abstract onObstacleDetection method; the developer implements this method to compute a turn angle based on the distribution of laser ranges. Entity implementations must bridge to ROS: a RosLaserScan class implements ROS’s MessageListener<LaserScan> and forwards incoming range arrays to the framework, while a RosLight class holds a ROS publisher to issue on/off commands.

Deployment is performed by subclassing a generated MainDeploy class, instantiating each component, and invoking deployAll(). Because the framework is regenerated from the DSL, any change in the design (e.g., adding a new context operator) automatically yields a new set of abstract classes; mismatches with existing hand‑written code are caught by the Java compiler, ensuring design‑implementation consistency.

The authors identify several benefits: (i) clear separation of concerns between design and implementation, (ii) automatic wiring reduces boilerplate, (iii) reuse of existing ROS components is straightforward, and (iv) the generated framework enforces that the implementation cannot drift from the original specification.

However, the study also uncovers limitations specific to robotics. First, the decision whether to reuse complex middleware types (e.g., ROS Twist, Pose) or to define new DiaSpec types is non‑trivial; reusing reduces effort but increases coupling, while new types improve decoupling but require translation code. Second, real‑time constraints and multi‑threaded execution are not addressed by DiaSpec; developers must manually synchronize ROS callbacks with the generated framework, which can be error‑prone. Third, the DSL lacks high‑level robotics primitives such as SLAM, path planning, or behavior trees, forcing developers to model these as additional context operators, increasing design overhead.

To mitigate these issues, the paper proposes three extensions: (1) tooling to automatically map ROS message types to DiaSpec declarations, (2) annotations or configuration mechanisms for real‑time scheduling and thread management within the generated framework, and (3) a library of pre‑defined robotics‑specific context operators (e.g., frontier detection, occupancy‑grid updates) that can be imported into a DiaSpec project.

In conclusion, the experiment demonstrates that DiaSpec can effectively structure a robotics application, providing a disciplined workflow from high‑level architectural description to concrete Java code while preserving the ability to evolve the design. The approach improves maintainability and reduces integration errors, but to become a truly practical platform for modern robot development it must evolve to better support complex middleware types, real‑time execution, and domain‑specific abstractions.