Pith. sign in

REVIEW 3 major objections 5 minor 50 references

Hardware traces plus deterministic message differencing can flag architectural drift in safety-critical firmware, with an LLM only writing the review report.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-12 04:37 UTC pith:GWFCDX67

load-bearing objection Solid industrial pipeline that turns HIT traces into a four-class architectural delta and keeps the LLM strictly out of the classification step; results hold inside a clearly scoped sequential model. the 3 major comments →

arxiv 2607.03135 v1 pith:GWFCDX67 submitted 2026-07-03 cs.SE cs.AI

Detecting Architectural Drift in Safety-Critical Firmware through Runtime Trace Analysis

Domenico Francesco De Angelis , Marco De Luca , Domenico Amalfitano , Pasquale Cimmino , Anna Rita Fasolino This is my paper
classification cs.SE cs.AI
keywords Architectural DriftArchitecture EvolutionSoftware Architecture RecoveryISO 26262Embedded FirmwareExecution Trace AnalysisSequence DiagramsRuntime Verification
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Long-lived safety-critical firmware often drifts away from its design documents: components start exchanging different messages, skip expected ones, or reverse order, yet the paper trail lags. This paper claims that the drift can be made visible by collecting non-intrusive hardware-assisted execution traces, abstracting them into the same vocabulary of component lifelines and messages used in design-time sequence diagrams, and then running a deterministic differencing step that labels every interaction confirmed, missing, additional, or inverted. A constrained language model is allowed only to turn the already-computed delta and related commit stories into a short human-readable report; it never decides what the delta is. On 26 industrial feature-linked test cases the generated deltas agreed strongly with expert-curated references, and practitioners rated the reports useful for interpretation, effort reduction, and safety-oriented documentation. If the claim holds, review teams gain an inspectable, auditable signal of design-runtime mismatch without treating the language model as primary safety evidence.

Core claim

The authors establish that interaction-level architectural drift in ISO 26262-compliant firmware can be detected by elevating hardware-assisted instruction traces to linear message-exchange sequences, comparing them deterministically against design-time sequence diagrams, and classifying each discrepancy as confirmed, missing, additional, or inverted, with a constrained LLM used solely to produce a review-aid report from the already-computed delta.

What carries the argument

The Delta Trace: an ordered collection of source-target-message records that the Differ matches across design-time and runtime PlantUML sequences, labeling each exchange confirmed (present and order-consistent), missing, additional, or inverted.

Load-bearing premise

Both the design diagrams and the runtime traces must be reducible to the same linear sequence of inter-component messages under a strictly sequential, deterministic execution model; combined fragments and concurrent paths are outside scope.

What would settle it

On a held-out set of industrial feature-linked test cases whose design diagrams are linear, measure whether the automatically labeled deltas still reach high F1 against independent expert ground truth for confirmed, missing, and additional classes, and whether practitioners still rate the reports useful when the LLM step is removed or replaced by a non-LLM template.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Architectural review can treat the serialized PlantUML delta as primary, inspectable evidence of design-runtime mismatch while the LLM report remains only an aid.
  • Safety documentation workflows gain an explicit trace from detected message-exchange drift back to commits and work items that introduced the change.
  • Ordering (inverted) discrepancies remain the hardest class and become the natural next target for method improvement.
  • The same three-phase pipeline can be inserted into CI/CD so that each new feature-linked test run produces a fresh drift delta for expert review.

Where Pith is reading between the lines

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

  • If the linear-sequence assumption is relaxed to support alt/opt/loop fragments, the same differencing idea could cover a larger share of real automotive sequence diagrams without changing the hardware-trace front end.
  • The separation of deterministic classification from LLM reporting is a reusable pattern for any safety-critical setting where fabrication risk must stay out of the evidence chain.
  • The approach could be extended to trend monitoring: successive deltas over releases would surface accumulating drift that single-scenario checks miss.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes a three-phase methodology for detecting interaction-level architectural drift in ISO 26262-compliant firmware. Hardware-assisted instruction traces are abstracted into linear message exchanges among components (Phase 1), compared deterministically against design-time UML sequence diagrams to produce a labeled delta of confirmed, missing, additional, or inverted interactions (Phase 2), and summarized by a constrained LLM that is forbidden from altering the delta (Phase 3). Evaluation on 26 industrial feature-linked test cases reports high precision/recall/F1 for confirmed (F1 94.6%), missing (88.2%), and additional (86.4%) elements, lower performance for inverted (60%), substantial expert agreement on LLM root-cause faithfulness (Fleiss’ κ = 0.692), and positive TAM-style practitioner ratings from 23 engineers on usefulness and compliance support.

Significance. If the results hold, the work offers a practical, industrially grounded pipeline that couples non-intrusive HIT traces with deterministic architectural differencing and carefully scoped LLM reporting—an attractive pattern for safety-critical settings where reproducibility and auditability matter. Strengths include an explicit needs elicitation at Micron, a clear separation of the Differ engine from the LLM (Box 1), agreement-based validation against majority-voted expert ground truth, and a practitioner survey that addresses perceived usefulness for ISO 26262 documentation. The contribution is incremental rather than foundational, but it usefully bridges static architecture recovery and runtime evidence for long-lived embedded firmware within a well-stated sequential-execution scope.

major comments (3)
  1. Section V-D-1 / RQ1 vs. Abstract: RQ1 is framed as alignment of the “generated architectural-drift delta” with an expert reference, yet the procedure constructs ground-truth sequence diagrams by source-code analysis and then classifies elements of the methodology’s reconstructed runtime diagram against that ground truth. This measures Phase-1 reconstruction fidelity more directly than design-time-vs-runtime drift detection. Please clarify (i) whether the 26 cases contained known design–runtime discrepancies, (ii) how expert-curated delta references (if any) were built, and (iii) how the reported F1 numbers should be read as evidence for drift detection rather than only for trace abstraction accuracy.
  2. Section V-E (RQ1 inverted class): F1 = 60% for inverted interactions is substantially weaker than the other categories, and absolute counts are withheld for confidentiality. Without base rates or a confusion matrix it is hard to judge whether inverted detection is systematically unreliable or merely sparse. Because ordering is central to the paper’s definition of inverted drift (Section III, Section IV-D), please either report instance counts / prevalence (even as ranges) or strengthen the discussion of why ordering discrepancies remain hard and how this limits the claim of “strong agreement” overall.
  3. Section III (linear-sequence premise) and evaluation scope: The methodology and the 26 test cases are restricted to already-linear design-time diagrams (no alt/opt/loop). This is stated, but the abstract and conclusions still present the approach as supporting architectural drift detection in evolving ISO 26262 firmware more generally. Please make the linear-scenario restriction equally prominent in the abstract/claims, or provide at least a qualitative discussion of how many industrial scenarios fall outside this premise and what that implies for adoption.
minor comments (5)
  1. Throughout: occasional spacing artifacts in technical terms (“DW ARF”, “M odels@run.time”) and reference encoding issues (e.g., Altınıs ¸ık) should be cleaned for camera-ready.
  2. Box 1 prompt: “use less word possible” and similar phrasing should be polished; the prompt is part of the method description and will be read carefully.
  3. Figure 9: Likert distributions are useful; adding mean/median or a short table of response counts would improve readability without violating confidentiality.
  4. Section V-C: state more explicitly that selected diagrams contained no UML combined fragments so readers do not infer that the firmware itself lacks conditionals.
  5. Related work: the distinction from Models@run.time and from LLM-based architecture recovery (Hatahet et al.) is clear; a one-sentence comparison to classic architecture-reflexion / drift literature (e.g., Perry & Wolf, Tekinerdogan) would help position the interaction-level definition.

Circularity Check

0 steps flagged

No significant circularity: deterministic triple comparison of independent design-time and runtime sequences produces the delta; LLM is confined to post-hoc reporting; evaluation uses external expert ground truth.

full rationale

The paper's central derivation is a three-phase pipeline (Section III). Phase 1 post-processes HIT traces into linear PlantUML message sequences using DWARF symbols; Phase 2 reduces both the design-time sequence (converted from Enterprise Architect) and the runtime sequence to ordered triples (source, target, label) and classifies each as CONFIRMED / MISSING / ADDITIONAL / INVERTED by set membership and relative order (explicitly stated: 'Interactions present only in the design-time sequence are classified as missing, whereas interactions present only in the runtime sequence are classified as additional... confirmed when their relative ordering is consistent... inverted when their relative ordering differs'). This is pure deterministic string/triple differencing of two independently obtained artifacts; no parameter is fitted to the evaluation data and then re-used as a 'prediction'. Phase 3 (Box 1) feeds only the already-computed Serialized Delta plus development-story summaries into a constrained LLM whose sole output is a human-readable report; the paper repeatedly states that the LLM 'does not influence the derivation of architectural relations, or the delta computation'. RQ1 ground truth is constructed by three independent annotators who manually reconstruct sequence diagrams from source code (majority vote) before any comparison with the tool output; precision/recall/F1 and Fleiss' κ are therefore external agreement measures, not self-referential. Self-citations ([4], [44]) appear only as background on static recovery and ISO 26262 documentation practices and are not load-bearing for the delta algorithm or the reported metrics. The sequential/linear-sequence assumption is an explicit scope restriction, not a circular definition. Consequently the claimed practical utility rests on independent inputs and external validation; no step reduces a result to its own inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 5 axioms · 0 invented entities

The central claim rests on standard software-engineering and safety-domain assumptions plus a few methodological scoping choices; no free parameters are fitted and no new physical or mathematical entities are postulated.

axioms (5)
  • domain assumption Architectural drift can be adequately captured as discrepancies in inter-component message exchanges (source, target, label, order) between design-time and runtime sequence diagrams.
    Stated in the introduction and formalized in Phase 2; other forms of drift (timing, data-flow, asynchronous) are explicitly placed out of scope.
  • domain assumption Firmware under analysis follows a strictly sequential, deterministic execution model so that relative ordering of messages is well-defined and comparable.
    Explicitly assumed in Section III; required for the inverted class to be meaningful.
  • domain assumption Hardware-assisted instruction traces plus DWARF symbols can be reliably abstracted to the same vocabulary of lifelines and messages used in design-time UML sequence diagrams.
    Phase 1 post-processing relies on this mapping; imperfect symbol resolution is listed as a threat.
  • ad hoc to paper Design-time sequence diagrams supplied for comparison are already linear (no alt/opt/loop combined fragments).
    Current Differ implementation does not expand fragments; stated as a deliberate scope limitation in Phase 2 and evaluation.
  • domain assumption ISO 26262 requires evidence that architectural elements interact at runtime as prescribed by design.
    Cited from the standard and used to motivate the entire need for runtime-informed drift detection.

pith-pipeline@v1.1.0-grok45 · 21176 in / 2728 out tokens · 25444 ms · 2026-07-12T04:37:33.352195+00:00 · methodology

0 comments
read the original abstract

Maintaining consistency between architectural design and runtime-observed behavior is challenging in long-lived safety-critical firmware. This paper presents a runtime-informed methodology for detecting architectural drift in ISO 26262-compliant firmware. The approach collects hardware-assisted execution traces, abstracts them into message exchanges among firmware components, and compares the resulting runtime behavior with design-time sequence diagrams through a deterministic differencing step. The computed delta identifies discrepancies as confirmed, missing, additional, or inverted, while a constrained LLM-based step generates a human-readable report only to support expert review. We evaluate the methodology in an industrial firmware context through agreement-based validation and a practitioner survey. Results over 26 test cases show strong agreement between the generated deltas and expert-curated references, while practitioners perceive the reports as useful for interpreting drift, reducing manual analysis effort, and supporting safety-oriented documentation activities. The findings suggest that combining runtime trace analysis, deterministic architectural differencing, and constrained LLM-based reporting can practically support architectural drift detection in evolving safety-critical firmware.

Figures

Figures reproduced from arXiv: 2607.03135 by Anna Rita Fasolino, Domenico Amalfitano, Domenico Francesco De Angelis, Marco De Luca, Pasquale Cimmino.

Figure 1
Figure 1. Figure 1: Conceptual model of the industrial problem addressed in this [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Phase 1 overview. The ELF binary is analyzed via pyelftools [31] to extract DWARF metadata (function boundaries, symbol names, compilation units), building a model that maps runtime ad￾dresses to firmware-level entities. The firmware image (ELF files) is then programmed onto the target device (download firmware) using a standard firmware flashing procedure, i.e., writing the compiled binary into the device… view at source ↗
Figure 3
Figure 3. Figure 3: Phase 2 overview. In the first step, design-time sequence diagrams are ex￾tracted from the Enterprise Architect 1 project and con￾verted (Converter) into a textual PlantUML format using pywin32 [36], producing a Converted Sequence. This con￾version preserves component lifelines and inter-component interactions while removing notation-level differences. In the second step, the Converted Sequence and the Pos… view at source ↗
Figure 6
Figure 6. Figure 6: Additional interaction: design-time, runtime, delta. [PITH_FULL_IMAGE:figures/full_fig_p005_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Missing interaction: design-time, runtime, delta. [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Inverted interaction: design-time, runtime, delta. [PITH_FULL_IMAGE:figures/full_fig_p005_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Likert-scale rating distribution for RQ3. [PITH_FULL_IMAGE:figures/full_fig_p008_9.png] view at source ↗

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

50 extracted references · 2 linked inside Pith

  1. [1]

    Road vehicles – functional safety – Part 1: V ocabulary,

    ISO/TC 22/SC 32, “Road vehicles – functional safety – Part 1: V ocabulary,” International Organization for Standardization, Geneva, Switzerland, Standard ISO 26262-1:2018 to ISO 26262-12:2018, 2018. [Online]. Available: https://www.iso.org/standard/68383.html

    2018

  2. [2]

    ISO,ISO 26262 — Road vehicles — Functional safety — Part 6: Product development at the software level, ISO 26 262-6, 2018

    2018

  3. [3]

    Arcade: an extensible workbench for architecture recovery, change, and decay evaluation,

    M. Schmitt Laser, N. Medvidovic, D. M. Le, and J. Garcia, “Arcade: an extensible workbench for architecture recovery, change, and decay evaluation,” inProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2020, pp. 1546–1550

    2020

  4. [4]

    Automated architecture recovery for embedded software systems: An industrial case study,

    D. Amalfitano, M. D. Luca, D. F. D. Angelis, and A. R. Fasolino, “Automated architecture recovery for embedded software systems: An industrial case study,” inSoftware Architecture, ECSA 2024, ser. Lecture Notes in Computer Science, vol. 14889. Springer, 2024, pp. 53–68

    2024

  5. [5]

    Experience on applying software architecture recovery to automotive embedded systems,

    X. Zhang, M. Persson, M. Nyberg, B. Mokhtariet al., “Experience on applying software architecture recovery to automotive embedded systems,” in2014 Software Evolution Week – IEEE Conference on Software Maintenance, Reengineering, and Reverse Engineering. IEEE, 2014, pp. 379–382

    2014

  6. [6]

    Software architecture recovery from multiple dependency models,

    M. Altınıs ¸ık, H. S¨ozer, and G. G ¨ursun, “Software architecture recovery from multiple dependency models,” inProceedings of the 39th ACM/SI- GAPP symposium on applied computing, 2024, pp. 1185–1192

    2024

  7. [7]

    An amalgamated dynamic and static architecture reconstruction framework to control component interactions 259,

    K. Sartipi and N. Dezhkam, “An amalgamated dynamic and static architecture reconstruction framework to control component interactions 259,” in14th Working Conference on Reverse Engineering (WCRE 2007). IEEE, 2007, pp. 259–268

    2007

  8. [8]

    Runtime recovery and manipula- tion of software architecture of component based systems,

    G. Huang, H. Mei, and F.-Q. Yang, “Runtime recovery and manipula- tion of software architecture of component based systems,”Automated Software Engineering, vol. 13, no. 2, pp. 257–281, 2006

    2006

  9. [9]

    Recovering runtime architecture models and managing their complexity using dynamic information and composite structures,

    S. Zellagui, C. Tibermacine, G. E. Boussaidi, A.-D. Seriai, H.-L. Bouziane, and C. Dony, “Recovering runtime architecture models and managing their complexity using dynamic information and composite structures,” inProceedings of the 33rd Annual ACM Symposium on Applied Computing, 2018, pp. 1454–1456

    2018

  10. [10]

    A brief account of runtime verification,

    M. Leucker and C. Schallhart, “A brief account of runtime verification,” The journal of logic and algebraic programming, vol. 78, no. 5, pp. 293–303, 2009

    2009

  11. [11]

    We’re drifting apart: Architectural drift from the developers’ perspective,

    E. Anthony, A. Berntsson, T. Santilli, and R. Wohlrab, “We’re drifting apart: Architectural drift from the developers’ perspective,” in2024 IEEE 21st International Conference on Software Architecture (ICSA). IEEE, 2024, pp. 101–111

    2024

  12. [12]

    Architectural drift analysis using architecture reflex- ion viewpoint and design structure reflexion matrices,

    B. Tekinerdogan, “Architectural drift analysis using architecture reflex- ion viewpoint and design structure reflexion matrices,” inSoftware Quality Assurance. Elsevier, 2016, pp. 221–236

    2016

  13. [13]

    Architec- ture consistency: State of the practice, challenges and requirements,

    N. Ali, S. Baker, R. O’Crowley, S. Herold, and J. Buckley, “Architec- ture consistency: State of the practice, challenges and requirements,” Empirical Software Engineering, vol. 23, no. 1, pp. 224–258, 2018

    2018

  14. [14]

    Understanding software architecture erosion: A systematic mapping study,

    R. Li, P. Liang, M. Soliman, and P. Avgeriou, “Understanding software architecture erosion: A systematic mapping study,”Journal of Software: Evolution and Process, vol. 34, no. 3, p. e2423, 2022

    2022

  15. [15]

    Visualization, transformation, and analysis of execution traces with the eclipse trace4cps trace tool,

    M. Hendriks, J. Verriet, and T. Basten, “Visualization, transformation, and analysis of execution traces with the eclipse trace4cps trace tool,” International Journal on Software Tools for Technology Transfer, vol. 26, no. 1, pp. 101–126, 2024

    2024

  16. [16]

    Stollon,On-Chip Instrumentation: Design and Debug for Systems on Chip

    N. Stollon,On-Chip Instrumentation: Design and Debug for Systems on Chip. Springer, 2010

    2010

  17. [17]

    Document ID: IHI0064H

    Arm Ltd.,ARM ® Embedded Trace Macrocell Architecture Specification, ETMv4.0 to ETMv4.6, 2023, issue H (H.b), Non-Confidential. Document ID: IHI0064H. [Online]. Available: https://developer.arm. com/documentation/ihi0064

    2023

  18. [18]

    [Online]

    Intel Corporation,Collecting Intel ® Processor Trace (Intel® PT) in Intel ® System Debugger, 2026. [Online]. Available: https://www.intel.com/content/www/us/en/developer/videos/ collecting-processor-trace-in-intel-system-debugger.html

    2026

  19. [19]

    [Online]

    Synopsys, Inc.,ARC ® Real-Time Trace (RTT) Unit for ARCv2 Processors, 2024, datasheet. [Online]. Available: https://www.synopsys. com/designware-ip/processor-solutions/arc-debug-options.html

    2024

  20. [20]

    [Online]

    MIPS Technologies, Inc.,MIPS ® PDtraceTM Specification, 2012, document Number: MD00439, Revision 7.50. [Online]. Available: http://t-es-t.hu/download/mips/md00439g.pdf

    2012

  21. [21]

    Perceived usefulness, perceived ease of use, and user acceptance of information technology,

    F. D. Davis, “Perceived usefulness, perceived ease of use, and user acceptance of information technology,”MIS quarterly, vol. 13, no. 3, pp. 319–340, 1989

    1989

  22. [22]

    ISO,ISO 26262 — Road vehicles — Functional safety — Part 8: Supporting processes, ISO 26 262-8, 2018

    2018

  23. [23]

    Testing embedded software: A survey of the literature,

    V . Garousi, M. Felderer, C ¸ a ˘grı Murat Karapıc ¸ak, and U. Yılmaz, “Testing embedded software: A survey of the literature,”Information and Software Technology, vol. 104, pp. 14–45, 2018. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0950584918301265

    2018

  24. [24]

    Analysis of legacy system in software application development: A comparative survey,

    S. Malladi, G. Ramakrishna, K. Rao, and E. Babu, “Analysis of legacy system in software application development: A comparative survey,” International Journal of Electrical and Computer Engineering (IJECE), vol. 6, pp. 292–297, 02 2016

    2016

  25. [25]

    Automating requirements-based testing for iso 26262,

    QA Systems, “Automating requirements-based testing for iso 26262,” https://www.qa-systems.com/wp-content/uploads/2020/12/ automating-requirements-based-testing-for-iso-26262.pdf, 2020

    2020

  26. [26]

    R. A. Krueger and M. A. Casey,Focus Groups A Practical Guide for Applied Research. Sage, 2015

    2015

  27. [27]

    Software reverse engineering in the domain of complex embedded systems,

    H. M. Kienle, J. Kraft, and H. A. M ¨uller, “Software reverse engineering in the domain of complex embedded systems,”Reverse Engineering- Recent Advances and Applications, pp. 15–22, 2012

    2012

  28. [28]

    Planning software architecture and modeling patterns for iso 26262 compliance,

    T. Groß, J. Moore, and J. Lee, “Planning software architecture and modeling patterns for iso 26262 compliance,” inNuremberg Exhibition Centre, 2020. [29]Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification, Tool Interface Standards (TIS) Committee, May 1995, accessed: 2026-01-20. [Online]. Available: https://refspecs. linuxfound...

    2020

  29. [29]

    [Online]

    DW ARF Debugging Information Format Committee,DWARF Debugging Information Format Version 5, DW ARF Committee, 2017, available under the GNU Free Documentation License, Version 1.3. [Online]. Available: https://dwarfstd.org/doc/DW ARF5.pdf

    2017

  30. [30]

    pyelftools: Python elf and dwarf parsing library,

    E. Bendersky, “pyelftools: Python elf and dwarf parsing library,” https: //github.com/eliben/pyelftools, 2010. [32]Open On-Chip Debugger, OpenOCD Project. [Online]. Available: https://openocd.org [33]ARM Debug Interface Architecture Specification, Arm Ltd. [Online]. Available: https://developer.arm.com/documentation

    2010

  31. [31]

    Software architecture reconstruction: A process-oriented taxonomy,

    S. Ducasse and D. Pollet, “Software architecture reconstruction: A process-oriented taxonomy,”IEEE Transactions on Software Engineer- ing, vol. 35, no. 4, pp. 573–591, 2009

    2009

  32. [32]

    Plantuml,

    PlantUML Team, “Plantuml,” https://plantuml.com, 2024

    2024

  33. [33]

    pywin32: Python for windows extensions,

    M. Hammond, “pywin32: Python for windows extensions,” 2026, accessed: 2026-04-19. [Online]. Available: https://github.com/ mhammond/pywin32

    2026

  34. [34]

    Pydriller: Python framework for mining software repositories,

    D. Spadini, M. Aniche, and A. Bacchelli, “Pydriller: Python framework for mining software repositories,” inProceedings of the 26th IEEE Inter- national Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2019, pp. 908–911

    2019

  35. [35]

    Can llms update api documenta- tion?

    S. Lee, J. Heo, and K. R. Dearstyne, “Can llms update api documenta- tion?” in2025 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2025, pp. 1–12

    2025

  36. [36]

    When llms meet api documentation: Can retrieval augmentation aid code generation just as it helps developers?

    J. Chen, S. Chen, J. Cao, J. Shen, and S.-C. Cheung, “When llms meet api documentation: Can retrieval augmentation aid code generation just as it helps developers?”arXiv preprint arXiv:2503.15231, 2025

    Pith/arXiv arXiv 2025

  37. [37]

    Foundations for the study of software architecture,

    D. E. Perry and A. L. Wolf, “Foundations for the study of software architecture,”ACM SIGSOFT Software engineering notes, vol. 17, no. 4, pp. 40–52, 1992

    1992

  38. [38]

    Sch ¨utze, C

    H. Sch ¨utze, C. D. Manning, and P. Raghavan,Introduction to informa- tion retrieval. Cambridge University Press Cambridge, 2008, vol. 39

    2008

  39. [39]

    The measurement of observer agreement for cate- gorical data,

    G. Landis JRKoch, “The measurement of observer agreement for cate- gorical data,”Biometrics, vol. 33, no. 1, p. 159174, 1977

    1977

  40. [40]

    Automated support for the architecting of distributed em- bedded systems: Methods and analysis for industrial adoption,

    X. Zhang, “Automated support for the architecting of distributed em- bedded systems: Methods and analysis for industrial adoption,” Ph.D. dissertation, KTH Royal Institute of Technology, 2017

    2017

  41. [41]

    Documenting software architecture design in compliance with the iso 26262: a practical experience in industry,

    D. Amalfitano, M. De Luca, and A. R. Fasolino, “Documenting software architecture design in compliance with the iso 26262: a practical experience in industry,” in2023 IEEE 20th International Conference on Software Architecture Companion (ICSA-C). IEEE, 2023, pp. i–xi

    2023

  42. [42]

    Reference architectures for automotive software,

    T. Bauer, D. Barkowski, A. Bachorek, and A. Morgenstern, “Reference architectures for automotive software,” inReference Architectures for Critical Domains: Industrial Uses and Impacts. Springer, 2022, pp. 73–111

    2022

  43. [43]

    Trace-based runtime analysis of embedded real-time systems,

    Z. Chamski, M. Borzkecki, and B. ´Swiercz, “Trace-based runtime analysis of embedded real-time systems,” inProceedings of the 17th International Conference Mixed Design of Integrated Circuits and Systems-MIXDES 2010. IEEE, 2010, pp. 117–120

    2010

  44. [44]

    Hardware-based runtime verification with embedded tracing units and stream processing,

    L. Convent, S. Hungerecker, T. Scheffel, M. Schmitz, D. Thoma, and A. Weiss, “Hardware-based runtime verification with embedded tracing units and stream processing,” inInternational Conference on Runtime Verification. Springer, 2018, pp. 43–63

    2018

  45. [45]

    Models@ run. time: a guided tour of the state of the art and research challenges: N. bencomo et al

    N. Bencomo, S. G ¨otz, and H. Song, “Models@ run. time: a guided tour of the state of the art and research challenges: N. bencomo et al.” Software & Systems Modeling, vol. 18, no. 5, pp. 3049–3082, 2019

    2019

  46. [46]

    Towards effectively leveraging execution traces for program repair with code llms,

    M. Haque, P. Babkin, F. Farmahinifarahani, and M. Veloso, “Towards effectively leveraging execution traces for program repair with code llms,” inProceedings of the 4th International Workshop on Knowledge- Augmented Methods for Natural Language Processing, 2025, pp. 160– 179

    2025

  47. [47]

    Runtime execution traces guided automated program repair with multi-agent debate,

    J. Wu, T. Wu, M. Zhang, Y . Dong, and B. Shen, “Runtime execution traces guided automated program repair with multi-agent debate,”arXiv preprint arXiv:2604.02647, 2026

    Pith/arXiv arXiv 2026

  48. [48]

    Generating software architec- ture description from source code using reverse engineering and large language model,

    A. Hatahet, C. Knieke, and A. Rausch, “Generating software architec- ture description from source code using reverse engineering and large language model,” in2025 ACM/IEEE 28th International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). IEEE, 2025, pp. 566–575

    2025

  49. [49]

    Decision architect – a decision documentation tool for industry,

    C. Manteuffel, D. Tofan, P. Avgeriou, H. Koziolek, and T. Goldschmidt, “Decision architect – a decision documentation tool for industry,” Journal of Systems and Software, vol. 112, pp. 181–198, 2016. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S0164121215002290

    2016

  50. [50]

    Ar- chitectural decision guidance across projects - problem space modeling, decision backlog management and cloud computing knowledge,

    O. Zimmermann, L. Wegmann, H. Koziolek, and T. Goldschmidt, “Ar- chitectural decision guidance across projects - problem space modeling, decision backlog management and cloud computing knowledge,” in2015 12th Working IEEE/IFIP Conference on Software Architecture, 2015, pp. 85–94

    2015