pith. sign in

arxiv: 2605.20055 · v1 · pith:VZ25NA4Ynew · submitted 2026-05-19 · 💻 cs.SE · cs.AI· cs.RO

Towards LLM-Assisted Architecture Recovery for Real-World ROS~2 Systems: An Agent-Based Multi-Level Approach to Hierarchical Structural Architecture Reconstruction

Pith reviewed 2026-05-20 03:27 UTC · model grok-4.3

classification 💻 cs.SE cs.AIcs.RO
keywords ROS 2architecture recoveryLLM-assistedhierarchical architecturesoftware architecturerobotic systemsprompt engineering
0
0 comments X

The pith

Combining refined prompts with multi-level intermediate representations lets LLMs reconstruct consistent hierarchical architectures in complex ROS 2 systems.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper extends prior LLM-assisted architecture recovery for ROS 2 by adding refined prompting for consistency and a staged strategy with multi-level intermediate representations. These representations include atomic node lists and launch file dependencies to constrain the reconstruction across abstraction levels. The approach is evaluated on a complex automated product disassembly system using cooperative robotic arms. Results indicate better structural consistency, scalability, and robustness than before. It also points out ongoing difficulties with dynamic integration semantics in large systems.

Core claim

The authors claim that their enhanced agent-based multi-level approach, through refined prompting and staged recovery using intermediate architectural representations, produces structurally constrained hierarchical models that accurately reflect implicit semantics in source code and launch files, thereby improving the consistency, scalability, and robustness of architecture recovery for real-world ROS 2 systems.

What carries the argument

The staged recovery strategy based on multi-level intermediate architectural representations incorporating the atomic ROS node list and launch file dependencies.

If this is right

  • Improved structural consistency reduces errors in recovered models.
  • The method scales to systems with higher integration complexity.
  • Robustness allows handling of richer functionality in robotic applications.
  • Explicit models aid in communicating and evolving complex systems.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The technique may apply to architecture recovery in other distributed software systems.
  • Combining with dynamic analysis tools could resolve issues with runtime behaviors.
  • It might enable semi-automated maintenance of architecture documentation in robotics projects.

Load-bearing premise

That guiding the LLM with refined prompts and multi-level intermediate representations will produce hierarchical models that accurately match the implicit semantics without inconsistencies or omissions.

What would settle it

Finding that the architecture model recovered from the automated product disassembly system contains component hierarchies or connections that contradict the actual dependencies in the source code and launch files.

Figures

Figures reproduced from arXiv: 2605.20055 by Andreas Rausch, Dhruv Jajadiya, Dhruv Kapadiya, Dominique Briechle, Meng Zhang, Raj Chanchad, Ruidi He, Tobias Geger.

Figure 1
Figure 1. Figure 1: System architecture of the BrickByBrick disassembly system. As shown in [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Blueprint-guided automated architecture recovery system and staged backend pipeline. The system receives a repository and recovery job request, uses an external LLM for architecture generation and PlantUML for rendering, and decomposes recovery into NodeAnalyzer, ComponentArchitectureTeam, and SystemArchitectureTeam stages that produce atomic and composed architecture models. The present paper therefore ke… view at source ↗
Figure 3
Figure 3. Figure 3: Refined staged recovery workflow for ROS 2 system-level architecture recon￾struction. The workflow introduces two explicit JSON artifacts, the List of Atomic ROS Nodes and the Launch File Dependency Description, which provide structured prompt context for constructing and rendering the final composed architecture model. explicit, then materializes launch-file dependency context, and finally aligns these st… view at source ↗
read the original abstract

Explicit software architecture models are essential artifacts for communicating, analyzing, and evolving complex software-intensive systems. In ROS~2-based robotic systems, however, structural (de-)composition and integration semantics are often only implicitly encoded across distributed artifacts such as source code and launch files, making recovery of hierarchical architecture particularly difficult. Existing approaches mainly focus on node-level entities and communication wiring, while providing limited support for recovering hierarchical structural (de-)composition across multiple abstraction levels. In this paper, we extend our previously proposed blueprint-guided LLM-assisted architecture recovery pipeline for ROS~2 systems through two major enhancements: (1) refined prompting to improve the consistency and controllability of architecture synthesis, and (2) a staged recovery strategy based on multi-level intermediate architectural representations that incorporate the atomic ROS node list and launch file dependencies, thereby enabling structurally constrained reconstruction across multiple abstraction levels. The approach is evaluated on a real-world automated product disassembly system based on cooperative robotic arms and heterogeneous ROS~2 artifacts. Compared to our previous work, the considered case study exhibits substantially higher integration complexity and richer functionality. The results demonstrate improved structural consistency, scalability, and robustness of architecture recovery, while also revealing remaining challenges related to dynamic integration semantics in large-scale ROS~2 systems.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The paper extends prior LLM-assisted architecture recovery work for ROS 2 systems by adding refined prompting and a staged multi-level recovery strategy that uses intermediate representations (atomic node lists plus launch-file dependencies) to reconstruct hierarchical structural models. It evaluates the extended pipeline on a single real-world automated product disassembly system with cooperative arms and heterogeneous artifacts, claiming improved structural consistency, scalability, and robustness relative to the authors' previous results while noting remaining challenges with dynamic integration semantics.

Significance. If the central claims hold under more rigorous evaluation, the work could advance practical tools for recovering implicit hierarchical architectures in complex robotic systems where structure is distributed across source code and launch files. The multi-level staged approach and emphasis on structural constraints are promising directions, but the current single-case qualitative presentation limits immediate impact and generalizability.

major comments (1)
  1. [§5] §5 (Evaluation): The central claim of 'improved structural consistency, scalability, and robustness' rests on qualitative description of one case study. No quantitative metrics are defined or reported (e.g., component matching rate, relation precision/recall against launch-file ground truth, omission count, or variance across repeated LLM calls), nor are baselines or prior-work comparisons provided with numbers. This makes the improvement assertion difficult to verify and directly weakens the load-bearing empirical support for the staged recovery strategy.
minor comments (2)
  1. [§3.2] §3.2 and §4: The description of how the multi-level intermediate representations enforce structural constraints could be clarified with a small concrete example showing input artifacts, intermediate output, and final model for one subsystem.
  2. [Abstract] Abstract and §5: The phrase 'dynamic integration semantics' is used to describe remaining challenges but is not illustrated with a specific example from the case study; adding one would help readers understand the limitation.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. The comment highlights an important opportunity to strengthen the empirical presentation, and we address it directly below.

read point-by-point responses
  1. Referee: [§5] §5 (Evaluation): The central claim of 'improved structural consistency, scalability, and robustness' rests on qualitative description of one case study. No quantitative metrics are defined or reported (e.g., component matching rate, relation precision/recall against launch-file ground truth, omission count, or variance across repeated LLM calls), nor are baselines or prior-work comparisons provided with numbers. This makes the improvement assertion difficult to verify and directly weakens the load-bearing empirical support for the staged recovery strategy.

    Authors: We agree that quantitative metrics would make the improvement claims more verifiable and strengthen the support for the staged recovery strategy. The evaluation in the current manuscript is based on a detailed qualitative analysis of a single, substantially more complex real-world case study than in our prior work, chosen to illustrate applicability under higher integration complexity. In the revised version we will define and report concrete metrics including component matching rate, relation precision and recall against launch-file ground truth, omission counts, and output variance across repeated LLM calls. We will also add a direct numerical comparison to the results from our previous pipeline on the same system where feasible. These additions will be incorporated into §5 without changing the core claims or the case-study focus. revision: yes

Circularity Check

0 steps flagged

No significant circularity; empirical extension on new case study

full rationale

The paper describes an empirical extension of a prior LLM-assisted ROS 2 architecture recovery pipeline, adding refined prompting and a staged multi-level recovery strategy using atomic node lists and launch dependencies. Evaluation occurs on a distinct, higher-complexity automated product disassembly case study. No equations, fitted parameters, self-definitional constructs, or uniqueness theorems appear. Claims of improved consistency and scalability rest on the new evaluation rather than reducing by construction to prior inputs or self-citations. The single self-reference to previous work is not load-bearing for the reported results.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the domain assumption that ROS 2 structural semantics are implicitly encoded across distributed artifacts and that LLMs can be prompted to reconstruct them hierarchically; no free parameters or new invented entities are introduced.

axioms (1)
  • domain assumption ROS 2 structural (de-)composition and integration semantics are only implicitly encoded across source code and launch files
    Stated in the opening paragraph as the core difficulty that motivates the recovery approach.

pith-pipeline@v0.9.0 · 5795 in / 1324 out tokens · 48534 ms · 2026-05-20T03:27:22.157366+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages · 3 internal anchors

  1. [1]

    Software architecture for developers,

    S. Brown, “Software architecture for developers,”Coding the Architecture, pp. 1–64, 2013

  2. [2]

    Starke, M

    G. Starke, M. Simons, S. Zörner, and R. Müller,arc42 by Example: Software architecture documentation in practice. Packt Publishing, 2019

  3. [3]

    The 4+1 view model of architecture,

    P. Kruchten, “The 4+1 view model of architecture,”IEEE Software, vol. 12, no. 6, pp. 42–50, 1995.doi: 10.1109/52.469759

  4. [4]

    Architecture consistency: State of the practice, challenges and requirements,

    N. Ali, S. Baker, R. O’Crowley, S. Herold, and J. Buckley, “Architecture consistency: State of the practice, challenges and requirements,”Empirical Software Engineering, vol. 23, pp. 224–258, 2018.doi: 10.1007/s10664-017- 9515-3

  5. [5]

    Softwarearchitecture documentation for developers: A survey,

    D.Rost,M.Naab,C.Lima,andC.vonFlachChavez,“Softwarearchitecture documentation for developers: A survey,” Fraunhofer IESE, Kaiserslautern, Germany, Tech. Rep. IESE-Report No. 025.14/E, Jun. 2014

  6. [6]

    Software architecture recovery augmented with semantics,

    W. Zhao et al., “Software architecture recovery augmented with semantics,” IEEE Transactions on Software Engineering, vol. 52, no. 1, pp. 338–359, 2026

  7. [7]

    Benchat et al.,Modeling and recovering hierarchical structural ar- chitectures of ros 2 systems from code and launch configurations using llm-based agents, 2026

    M. Benchat et al.,Modeling and recovering hierarchical structural ar- chitectures of ros 2 systems from code and launch configurations using llm-based agents, 2026. arXiv: 2602.18644 [cs.SE]. [Online]. Available: https://arxiv.org/abs/2602.18644

  8. [8]

    Meros: Sysml-based metamodel for ros-based systems,

    T. Winiarski, “Meros: Sysml-based metamodel for ros-based systems,”IEEE Access, vol. 11, pp. 82802–82815, 2023

  9. [9]

    Rosmod:Atoolsuiteformodeling,generating,deploying, and managing distributed real-time component-based software using ros,

    P.S.Kumaretal.,“Rosmod:Atoolsuiteformodeling,generating,deploying, and managing distributed real-time component-based software using ros,” in2015 International Symposium on Rapid System Prototyping (RSP), 2015, pp. 39–45

  10. [10]

    ROSSi a graphical programming interface for ROS 2,

    C. Wanninger et al., “ROSSi a graphical programming interface for ROS 2,” in2021 21st International Conference on Control, Automation and Systems (ICCAS), IEEE, 2021, pp. 255–262

  11. [11]

    Rospec:Adomain- specific language for ros-based robot software,

    P.Canelas,B.Schmerl,A.Fonseca,andC.S.Timperley,“Rospec:Adomain- specific language for ros-based robot software,”Proc. ACM Program. Lang., vol. 9, no. OOPSLA2, Oct. 2025

  12. [12]

    Using aadl to model and develop ros- based robotic application,

    G. Bardaro and M. Matteucci, “Using aadl to model and develop ros- based robotic application,” in2017 First IEEE International Conference on Robotic Computing (IRC), 2017, pp. 204–207. 16 D. Briechle et al

  13. [13]

    CodeBERT: A Pre-Trained Model for Programming and Natural Languages

    Z. Feng et al.,Codebert: A pre-trained model for programming and natural languages, 2020. arXiv: 2002.08155 [cs.CL]. [Online]. Available: https: //arxiv.org/abs/2002.08155

  14. [14]

    M. D. Luca, T. Santilli, D. Amalfitano, A. R. Fasolino, and P. Pelliccione, Ciao - code in architecture out - automated software architecture documenta- tion with large language models, 2026. arXiv: 2604.08293[cs.SE]. [Online]. Available: https://arxiv.org/abs/2604.08293

  15. [15]

    From requirements to architecture: An ai-based journey to semi-automatically generate software architectures,

    T. Eisenreich, S. Speth, and S. Wagner, “From requirements to architecture: An ai-based journey to semi-automatically generate software architectures,” inProceedings of the 1st International Workshop on Designing Software, ser. Designing ’24, Lisbon, Portugal: Association for Computing Machinery, 2024, pp. 52–55,isbn: 9798400705632.doi: 10.1145/3643660.36...

  16. [16]

    Leveraging llms to automate software architecture design from informal specifications,

    A. Tagliaferro, S. Corbo, and B. Guindani, “Leveraging llms to automate software architecture design from informal specifications,” in2025 IEEE 22nd International Conference on Software Architecture Companion (ICSA- C), 2025, pp. 291–299.doi: 10.1109/ICSA-C65153.2025.00049

  17. [17]

    Llm4workflow: An llm-based automated workflow model generation tool,

    J. Xu, W. Du, X. Liu, and X. Li, “Llm4workflow: An llm-based automated workflow model generation tool,” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’24, Sacramento, CA, USA: Association for Computing Machinery, 2024, pp. 2394–2398,isbn: 9798400712487.doi: 10.1145/3691620.3695360 [On- line]. Avail...

  18. [18]

    Can ai build systems? an exploratory study on generating software architecture with llms,

    M. Fokaefs, H. Khan, and B. Ahmadzadeh, “Can ai build systems? an exploratory study on generating software architecture with llms,” in2025 IEEE International Conference on Collaborative Advances in Software and COmputiNg (CASCON), 2025, pp. 1–10.doi: 10.1109/CASCON66301. 2025.00069

  19. [19]

    Can Large Language Models Assist the Comprehension of ROS2 Software Architectures?

    L. Duits, B. E. Moutaouakil, and I. Malavolta,Can large language models assist the comprehension of ros2 software architectures?2026. arXiv: 2604. 21699[cs.SE]. [Online]. Available: https://arxiv.org/abs/2604.21699

  20. [20]

    Hatahet, C

    A. Hatahet, C. Knieke, and A. Rausch,Generating software architecture description from source code using reverse engineering and large language model, 2025. arXiv: 2511.05165[cs.SE]

  21. [21]

    Brick by brick - findings of an of-the-shelf automation system application for building block component group disassembly,

    D. Briechle, T. Geger, L. Schartow, and A. Rausch, “Brick by brick - findings of an of-the-shelf automation system application for building block component group disassembly,” in2025 9th International Conference on Mechanical Engineering and Robotics Research (ICMERR), 2025, pp. 77–83. doi: 10.1109/ICMERR64601.2025.10949991