Paper deep dive
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
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 7/7/2026, 6:33:30 AM
Summary
This paper presents a methodology for detecting architectural drift in ISO 26262-compliant safety-critical firmware by comparing design-time sequence diagrams with runtime-observed behavior extracted from hardware-assisted execution traces. The approach computes a delta classifying discrepancies as confirmed, missing, additional, or inverted, and employs a constrained LLM to generate human-readable reports for expert review. Industrial evaluation demonstrates strong agreement with expert references and positive practitioner feedback on reducing manual analysis effort.
Entities (8)
Relation Signals (10)
Safety-Critical Firmware â governedby â ISO 26262
confidence 98% · ISO 26262-compliant firmware
Architectural Drift â detectedby â Runtime Trace Analysis
confidence 95% · This paper presents a runtime-informed methodology for detecting architectural drift
Design-Time Sequence Diagrams â comparedwith â Runtime Behavior
confidence 94% · compares the resulting runtime behavior with design-time sequence diagrams through a deterministic differencing step
Delta â classifiesas â Confirmed
confidence 93% · The computed delta identifies discrepancies as confirmed, missing, additional, or inverted
Delta â classifiesas â Missing
confidence 93% · The computed delta identifies discrepancies as confirmed, missing, additional, or inverted
Delta â classifiesas â Additional
confidence 93% · The computed delta identifies discrepancies as confirmed, missing, additional, or inverted
Delta â classifiesas â Inverted
confidence 93% · The computed delta identifies discrepancies as confirmed, missing, additional, or inverted
Runtime Behavior â abstractedfrom â Hardware-Assisted Execution Traces
confidence 92% · The approach collects hardware-assisted execution traces, abstracts them into message exchanges among firmware components
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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.
Tags
Links
- Source: https://arxiv.org/abs/2607.03135v1
- Canonical: https://arxiv.org/abs/2607.03135v1
Trouble viewing inline? Open PDF directly â
Full Text
68,324 characters extracted from source content.
Expand or collapse full text
Detecting Architectural Drift in Safety-Critical Firmware through Runtime Trace Analysis Domenico Francesco De Angelis University of Naples Federico I Micron Technology, Inc Naples, Italy ddeangelis@micron.com domenicofrancesco.deangelis@unina.it Marco De Luca DIETI University of Naples Federico I Naples, Italy marco.deluca2@unina.it Domenico Amalfitano DIETI University of Naples Federico I Naples, Italy domenico.amalfitano@unina.it Pasquale Cimmino Micron Technology, Inc Naples, Italy pcimmino@micron.com Anna Rita Fasolino DIETI University of Naples Federico I Naples, Italy fasolino@unina.it AbstractâMaintaining consistency between architectural de- sign 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 be- havior with design-time sequence diagrams through a determinis- tic 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. Index TermsâArchitectural Drift, Architecture Evolution, SoftwareArchitectureRecovery,ISO26262,Embedded Firmware, Execution Trace Analysis I. INTRODUCTION In automotive firmware development, architecture serves as a design artifact that guides implementation and supports rea- soning about system-level concerns, including safety-related decisions. In safety-critical contexts, architectural reasoning primarily relies on components and their interfaces, which constitute the main abstraction used during integration and verification activities [1], [2]. As a result, architectural con- sistency is often assessed at the level of inter-component interactions rather than internal implementations. Maintaining architectural documentation aligned with an evolving firmware codebase, however, remains challenging. Continuous evolution driven by feature growth, defect cor- rection, platform variation, and release pressure often causes documented architectures to become partial or misaligned with the deployed implementation [3]. Industrial studies report that while architectural views are crucial for maintainability, communication, and verification, they are difficult to preserve manually over time [4]â[6]. As a result, firmware architecture recovery has become an important industrial activity. Static architecture recovery can reconstruct useful structural views from code, including component decomposition, dependencies, interfaces, and other design-level relations [4], [7]. However, these views mainly de- scribe what the firmware contains, offering limited evidence on how architectural interactions are actually exercised at runtime, especially when behavior is scenario-dependent, dynamically dispatched, or shaped by event ordering [7]â[9]. In ISO 26262-compliant firmware, this gap is critical be- cause architectural confidence depends not only on design intent, but also on evidence that firmware elements interact during execution as prescribed by the design [1], [2], [5]. In this work, we interpret divergences between prescribed and observed message exchanges among firmware components as architectural drift, i.e., runtime-observable deviations between the intended architectural behavior and the behavior actually exercised during execution [10]. This notion is distinct from architectural erosion, which concerns direct violations of ar- chitectural principles [11], [12]. In safety-critical firmware, the distinction is relevant because local and individually ac- ceptable changes may still accumulate into runtime-relevant deviations that affect architectural consistency and complicate verification and integration reasoning [13], [14]. To observe such message-exchange deviations among firmware components, we rely on hardware-assisted instruc- tion tracing [15]. Modern System-on-Chip (SoC) platforms provide dedicated trace units that capture execution non- intrusively, without perturbing real-time behavior [16]. Al- though implemented differently across architectures, such as ARM ETM [17], Intel PT [18], Synopsys RTT [19], and arXiv:2607.03135v1 [cs.SE] 3 Jul 2026 MIPS PDtrace [20], these mechanisms share the principle of recording control-flow changes in a compact stream that can be reconstructed in software. Building on this context, we present a methodology that ac- quires firmware traces through a hardware-assisted instruction trace unit and converts them into architectural diagrams of exe- cuted behavior. Rather than replacing architecture recovery, the approach complements static architectural views with runtime- informed evidence of actual interactions among firmware components [9]. This dynamic view supports the inspection of interactions and dependencies that may be difficult to infer from code alone and provides practical support for review and compliance-oriented activities in safety-critical settings, where consistency among design, implementation, and verification evidence is central to architectural reasoning [1], [2], [4], [8]. The main contributions of this paper are: (i) a methodol- ogy for detecting architectural drift in evolving ISO 26262- compliant firmware by comparing design-time specifications with runtime evidence recovered from execution traces, com- plemented by a constrained LLM-based reporting step that summarizes the detected drift into a human-readable report; (i) an industrial evaluation combining agreement-based vali- dation and a Technology Acceptance Model (TAM) [21] based practitioner survey. The rest of the paper is structured as follows: Section I in- troduces the industrial context; Section I details the method- ology and Section IV illustrates it through running examples; Section V reports the evaluation; Section VI discusses threats to validity; Section VII discusses lessons learned; Section VIII covers related work; and Section IX concludes. I. INDUSTRIAL CONTEXT AND NEEDS ELICITATION This section presents the industrial context and the needs elicitation study that motivated the methodology, focusing on challenges in industrial firmware development where architec- tural documentation must remain aligned with continuously evolving embedded software. Although firmware architec- ture supports design, integration, and safety-related activities, maintaining accurate descriptions over time remains difficult, especially for legacy and long-lived codebases [22]â[25]. To identify concrete industrial requirements for the proposed methodology, we conducted a qualitative needs elicitation study through focus groups [26] at Micron Technology, the industrial case study of this research. Six practitioners par- ticipated, including firmware developers and firmware testing engineers, with experience in ISO 26262-governed safety systems. Two authors moderated the sessions using a structured protocol over approximately three hours. After the sessions, the moderators independently reviewed the focus-group notes, extracted recurring statements, and grouped them into themes related to the use of architectural views, statically recovered models, and runtime traces for reasoning about firmware behavior during execution. Disagreements in the interpretation or grouping of statements were resolved through discussion. The consolidated themes were then mapped to three concrete industrial needs: N 1 A methodology to identify interaction-level architectural drift from runtime evidence; N 2 A delta view that compares a design-time sequence dia- gram against the corresponding runtime execution trace, making discrepancies between intended and observed component interactions explicit and inspectable, rather than left to manual reconstruction from low-level logs; N 3 A natural-language report that describes each detected discrepancy, indicating what changed, where in the ar- chitecture it occurred, and what type of change it repre- sents, in order to support practitioners in understanding deviations, reducing the need for direct familiarity with the codebase or the tracing infrastructure. Overall, these findings highlight a gap between available architectural information and the runtime evidence needed to understand firmware as executed, as also reported in prior industrial studies [4], [7], [11]. Firmware Architecture Feature Test Case Dynamic Sequence Diagram BugDesign Sequence Diagram Delta LifelineMessage 1 1..* 1 1..* 1 1..* 1 1 1 1 1..* 0..* produces dynamically is specified by fixes is tested by is implemented by Fig. 1: Conceptual model of the industrial problem addressed in this work. Figure 1 provides a conceptual view of the industrial prob- lem addressed in this work: firmware architectural artifacts, change drivers, and validation assets evolve in parallel, making it difficult to relate design-time intent to runtime-observed behavior and, consequently, to detect architectural drift. The Firmware Architecture represents the design-time archi- tectural description of the firmware, including its main compo- nents, interfaces, and intended interactions. The architecture is implemented by one or more Features, which capture planned functional evolutions of the system. During development and validation, Bugs may be identified and fixed through features or corrective changes, thereby contributing to the continuous evolution of the firmware. Each Feature is specified by a Design Sequence Diagram, which describes the expected interactions among architectural elements for the considered scenario. The same feature is exercised by one or more Test Cases. When a test case is executed, it dynamically produces a runtime representation of the observed behavior, modeled as a Dynamic Sequence Diagram. The comparison between the Design Sequence Diagram and the corresponding Dynamic Sequence Diagram produces a Delta. The delta captures discrepancies between intended and observed interactions and represents the basis for architectural drift detection. In the conceptual model, the delta is defined over one or more Messages and, when relevant, over Lifelines. This reflects the interaction-level nature of the proposed analy- sis: every delta includes at least one message-level difference, while lifelines are included only when the discrepancy affects the set of participating architectural elements. I. PROPOSED METHODOLOGY AND IMPLEMENTATION DETAILS This section presents the proposed methodology and de- scribes how its three phases address the needs identified through the focus-group study. Phase 1 and Phase 2 produce an inspectable delta view between design-time and runtime interactions, thereby addressing N 2 . Phase 3 generates a human-readable report that describes the detected discrepan- cies, addressing N 3 . Together, the three phases support the identification and explanation of message-exchange deviations between design-time specifications and runtime-observed be- havior, addressing the overall need expressed in N 1 . The methodology proceeds from trace acquisition to drift explanation. Phase 1 extracts, post-processes, and serializes the runtime execution trace as a UML sequence diagram. Phase 2 compares this runtime representation with the design-time sequence diagram and produces a labeled architectural delta. Phase 3 enriches the detected deviations with development- story information from repository mining, serializes the delta, and generates a human-readable report through an LLM- assisted step. The methodology assumes a strictly sequential execution model, consistent with deterministic scheduling in high- integrity embedded systems [2], [27]. This is especially rele- vant for inverted interactions, since ordering differences can be assessed reliably only on a single deterministic execution path [2], [28]. Accordingly, the methodology is scoped to concrete execution scenarios represented as linear sequences of message exchanges. The following subsections detail each phase, describing inputs, processing steps, and outputs. a) Phase 1: Trace Processing: Phase 1 takes as input (i) the firmware executable in ELF format [29], enriched by DWARF debugging information [30], and (i) a feature-linked test case, i.e., a test case associated with the feature or scenario whose runtime behavior is to be observed, producing a runtime trace in which low-level execution events are resolved against executable-level symbols and related to architectural elements. An overview is shown in Figure 2. ELF enrich by DWARF extract debug info Download Firmware Test Case HIT Trace Post-Processed FW trace Perform Test debug info Post Processing Fig. 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 non-volatile mem- ory via a debug or bootloader interface [32], [33]. Once the firmware has been deployed, the selected test case is executed (Perform Test) while runtime events are collected as an HIT Trace. Collection is deliberately scoped to the execution win- dow of a single test-case execution: this aligns the captured trace with the design-time sequence diagram associated with the exercised feature or scenario, keeps trace volume within HIT bandwidth limits, and ensures that each captured trace corresponds to one concrete execution scenario represented as a linear sequence of observed message exchanges. The collected HIT Trace is post-processed to remove util- ity functions, redundant low-level repetitions, and execution events irrelevant to the architectural view [7], [34]. It uses de- bug information to translate raw addresses into symbol names and modules. The post-processing step does not reconstruct branching or iterative structures from the execution trace. Instead, it converts the observed runtime events into the linear message sequence actually exercised by the selected feature- linked test case. This design choice keeps the runtime repre- sentation directly comparable with the design-time sequence associated with the exercised feature or scenario. The trace is further abstracted by retaining the function invocations that realize runtime message exchanges among architectural entities and, for intra-module calls, only the first invocation level. This abstraction is a deliberate design choice: architectural drift, as adopted in this work, is defined at the level of runtime message exchanges between components. Therefore, both the design-time view (UML sequence dia- grams) and the runtime view must be expressed in the same vocabulary of Lifelines and Messages to be commensurable under the Phase 2 delta classification. The resulting Post- Processed FW trace retains only the architectural interac- tions relevant to the observed message-exchange behavior. This trace is subsequently serialized into a PlantUML [35] sequence-diagram representation for comparison with design- time sequence diagrams. b) Phase 2: Delta Computation: Phase 2 compares design-time and runtime behavioral descriptions in PlantUML format. As input, it takes: (i) the design-time sequence dia- grams extracted from UML architectural documentation, and (i) the processed runtime trace produced in Phase 1. The goal of this phase is to detect drift at the level of inter-component interactions. An overview of this phase is shown in Figure 3. Post-Processed FW Trace Delta Trace Differ Enterprise Architect Design Project Converter 2 2pywin32 Converted Sequence Fig. 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 Post- Processed FW trace produced in Phase 1 are compared by the Differ, which computes a diff between the design-time and runtime PlantUML sequences. It is implemented by a Python script that parses both PlantUML files and reduces each message exchange to a triple of source component, target component, and message label. The classification relies on ordered collections of inter- action records. Each record captures the source component, target component, message label, and occurrence within the sequence. The Differ matches records across the design-time and runtime sequences and classifies them at the architec- tural message-exchange level. Interactions present only in the design-time sequence are classified as missing, whereas interactions present only in the runtime sequence are classified as additional. Interactions present in both sequences are clas- sified as confirmed when their relative ordering is consistent with the design-time sequence, and as inverted when their relative ordering differs. The resulting set of classified message exchanges defines the Delta Trace. The comparison assumes that both inputs describe the same concrete execution scenario as linear sequences of message exchanges. The current implementation does not interpret UML combined fragments, such as alt, opt, and loop, nor does it expand them during delta computation. Conse- quently, the method currently applies to design-time sequence diagrams that are already linear. Behaviors containing alterna- tive, optional, or repeated interactions would require separate linearized design-time sequences and corresponding feature- linked test cases before being compared by the Differ. c) Phase 3: LLM-Assisted Reporting: Phase 3 takes as input: (i) the Delta Trace produced in Phase 2, and (i) the version-controlled codebase. The goal is to produce a readable 1 Enterprise Architect: https://sparxsystems.com/ summary of the detected differences and to serialize the delta. An overview of this phase is shown in Figure 4. Delta Trace Delta Report Serialized Delta Serialize LLM version-controlled codebase Extract History 3 Commit Involved Development Story Summaries Extract Stories 3pydriller Fig. 4: Phase 3 overview. As a first step, the Extract History process analyzes the repository history to extract the commit history, starting from the first commit corresponding to the date on which the design artifacts were introduced, up to the latest revision in the primary development line. This analysis is performed using PyDriller [37]. The extracted commit history is then filtered by retaining only changes affecting messages appearing in the Delta Trace, producing the set of Commit Involved. The Commit Involved set is processed by the Extract Stories step, which correlates the commit history with work- item metadata retrieved from a project management system, producing the Development Story Summaries. This enables traceability between architectural deviations and their origi- nating change requests. In compliance with ISO 26262 re- quirements, development branches and associated work items must be traceable [1]. In parallel, the Delta Trace is passed to the Serialize step, which produces the Serialized Delta in PlantUML format. Before communicating the delta to engineers, an LLM-based post-processing step is applied exclusively at the reporting level. The LLM operates solely on the Serialized Delta and the Development Story Summaries, producing the Delta Report. The LLM does not influence the derivation of architectural relations, or the delta computation; its role is limited to improving interpretability of the computed differences [38], [39]. The generated report serves solely as a review aid to facilitate human inspection of the computed delta, and does not constitute primary safety evidence. All safety-related conclusions remain the responsibility of qualified engineers, in accordance with ISO 26262. The interaction with the LLM is governed by a structured prompt that constrains the model to operate solely on the serialized delta and development story summaries. The prompt is defined in Box 1. The outputs of Phase 3 are: (i) an architectural delta in PlantUML (Serialized Delta) and (i) a human-readable delta report (Delta report) generated with LLM assistance, providing engineers with structured support for reviewing architectural consistency. Box 1: Role-constrained prompt for architectural drift report. ######## ROLE ######## You are a FW Architect. For each requirement/Change Artifacts (CA) pair below, analyze the architectural drift between the Design Sequence and the Runtime Trace, verify the CA's adherence to the requirement, and produce a SHORT root-cause report. Use less word possible ######## INPUT FORMAT ######## You will receive N blocks. Each block has: - Requirement description or bugfixes - Pull-Request reference (branch) - Drift diagram (PlantUML) with CONFIRMED / MISSING / ADDITIONAL / INVERTED tags ######## TASK (per requirement/bugfix) ######## 1. Inspect the provided Change Artifacts (CA) summaries, including change descriptions, commit messages and version id; check whether the implementation matches the requirement intent. 2. For each drift item (ADDITIONAL / MISSING / INVERTED), state in 1 line WHY it appears (link it to the requirement or to an implementation choice). 3. Conclude with a single ROOT CAUSE line classifying the drift as one of: - Documentation lag (design not refreshed) - Requirement realization (new behavior mandated by req) - Implementation choice (developer-introduced, not in design) - Behavioral defect (contract broken / requirement violated) - Mixed (specify) ######## OUTPUT FORMAT ######## Why the drift exists: 1. <symbol/function name> â <1-line reason tied to req or impl choice> 2. <symbol/function name> â <1-line reason> ... (one bullet per ADDITIONAL/MISSING/INVERTED item) ######## CONSTRAINTS ######## - No restating the diagram, no architectural essays. - If a drift item cannot be explained from CA contents, mark it as "unexplained". - If multiple CAs touch the same module, note cross-CA interactions in a final 2-line "cross-CA note" section. - use less word possible. - use only root cause defined in TASK ######## INPUTS ######## STORIES-SUMMARIES ######## Diagram Drift ######## PlantUML-DIAGRAM-INPUT IV. CATEGORIES OF ARCHITECTURAL DRIFT This section presents the architectural drift categories con- sidered by the proposed methodology when comparing design- time architectural behavior with runtime evidence. We distin- guish four cases: CONFIRMED, when the intended interaction is observed at runtime; ADDITIONAL, when runtime evidence contains interactions not specified at design time; MISSING, when specified interactions are not observed at runtime; and INVERTED, when the runtime order of interactions differs from the design-time specification. While CONFIRMED represents the reference case in which no drift is detected, the remaining categories capture different manifestations of architectural drift in component interactions. The following examples use synthetic component names and interactions for illustrative purposes only. A. Confirmed interaction An interaction is classified as CONFIRMED when the same source component, target component, and message label are present in both the design-time and runtime sequences and its relative ordering is consistent with the design-time sequence (Figure 5), providing evidence that the intended relation is preserved in the executed firmware, in terms of messages and lifelines. Comparison: BEFORE vs AFTER AB [CONFIRMED] message() Fig. 5: Confirmed Interaction: delta view. B. Additional interaction An ADDITIONAL interaction arises when the runtime se- quence contains a message exchange absent from the design- time specification, as shown in Figure 6. This deviation may indicate that a component has acquired an unplanned depen- dency, potentially violating the isolation assumptions required for safety verification under ISO 26262 [2]. compare Before vs After AB «additional» C [CONFIRMED] message() [ADDITIONAL] M2() Design-time SD AB message() HIT Trace ABC message() M2() DIFF Fig. 6: Additional interaction: design-time, runtime, delta. C. Missing interaction In contrast to the previous case, a MISSING interaction is one that was specified at design time but is not observed in the runtime trace (Figure 7). The absence may reflect a behavioral regression, an untriggered conditional path, or a specification that has become inconsistent with the evolved implementation. Regardless of its root cause, the deviation warrants explicit review: unexercised architectural relations reduce the completeness of verification evidence required by ISO 26262 [2]. compare Before vs After AB «missing» C [CONFIRMED] M1() [MISSING] M2() [MISSING] M3() [ADDITIONAL] M3() Design-time SD ABC M1() M2() M3() HIT Trace AB M1() M3() DIFF Fig. 7: Missing interaction: design-time, runtime, delta. D. Inverted interaction Figure 8 shows a scenario in which the runtime interaction order differs from the design-time specification, classified as INVERTED. This emerges when ordering constraints among architectural interactions were not explicitly or correctly cap- tured at design time, possibly revealing implicit dependencies introduced during firmware evolution [11], [14], [40]. compare Before vs After AB [INVERTED#0] M1() [INVERTED#0] M2() Design-time SD AB M1() M2() HIT Trace AB M2() M1() DIFF Fig. 8: Inverted interaction: design-time, runtime, delta. V. EXPERIMENTAL EVALUATION This section presents the experimental procedure conducted to evaluate the proposed methodology in an industrial firmware setting. A. Goal and Research Questions The goal of the evaluation is to assess the correctness of the detected architectural deltas, the faithfulness of the LLM- generated reports, and the perceived practical value of the methodology in ISO 26262-governed firmware development. The evaluation is structured around three research questions: TABLE I: Mapping between research questions, metrics, and evalu- ation subjects. RQMetricsEvaluation subjects RQ1 Precision, Recall, F1Three senior professionals with expertise in firmware architec- ture and safety verification RQ2 Fleissâ KappaThree senior professionals with expertise in firmware architec- ture and safety verification RQ3 Likert-scale ratings on PU, PEOU, and compli- ance support 23 industry practitioners in- volved in the anonymous ques- tionnaire PU = Perceived Usefulness; PEOU = Perceived Ease of Use; RQ1. To what extent does the generated architectural-drift delta align with a manually curated reference derived from the original sequence diagram and the corresponding trace? Rationale: Evaluates the correctness of the drift-detection mechanism. RQ2. To what extent is the LLM-generated report faithful in identifying the root cause of architectural drift? Rationale: Assesses whether the report correctly explains the root cause underlying the detected architectural drift, based on independent expert annotations. RQ3. To what extent is the proposed methodology perceived as useful by practitioners for architectural drift interpreta- tion and ISO 26262 compliance? Rationale: Examines the perceived practical value for safety-related documentation and evidence generation. To make explicit how each research question is evaluated, Table I summarizes the metrics and evaluation subjects asso- ciated with each RQ. B. Metrics As summarized in Table I, the evaluation adopts different metrics according to the objective of each research question. For RQ1, Precision, Recall, and F1-score quantify the alignment between generated deltas and the expert-curated reference [41]. The metrics are computed by comparing the elements automatically reconstructed by the methodology with the corresponding ground-truth elements, considering both lifelines and messages. For RQ2, we use Fleissâ Kappa (Îș) [42] to quantify the agreement among the three expert annotators. The annotators independently assessed whether the LLM- generated report faithfully identified the root cause of the detected architectural drift. For RQ3, we rely on the metrics derived from an anonymous questionnaire administered to 23 industry practitioners. The questionnaire includes both 5- point Likert-scale items and open-ended questions. The Likert- scale items are used to assess practitionersâ perceptions of the generated artifacts across three dimensions: Perceived Useful- ness (PU), Perceived Ease of Use (PEOU), and Compliance Support (C). The open-ended questions complement these quantitative ratings by capturing recurring perceived benefits and improvement areas. C. Objects and Subjects The objects of the study are internally developed firmware modules representative of industrial embedded systems, eval- uated through feature-linked test cases exercising specific architectural scenarios. Due to organizational confidentiality constraints, the evaluation is limited to proprietary firmware modules. The evaluation covered 26 feature-linked test cases, each involving on average 9 lifelines and approximately 25 inter-component messages, reflecting a representative level of industrial architectural complexity. Consistent with the scope of the current implementation, the selected feature-linked test cases were associated with linear design-time sequence dia- grams, i.e., diagrams not containing UML combined fragments such as alt, opt, and loop. This does not imply that the firmware lacks conditional or iterative logic, but only that such logic was not represented through combined fragments in the evaluated sequence diagrams. The subjects of evaluation relied on two distinct cohorts, as shown in Table I. To investigate RQ1 and RQ2, three senior professionals with backgrounds in firmware architecture and safety verification, not involved in the methodologyâs development, independently validated the output against a manually curated reference. Furthermore, for RQ3, a vol- untary and anonymous questionnaire was administered to a purposive sample of 23 industry practitioners. The cohort included 14 embedded firmware developers, 8 testing and verification engineers, and 1 software architect. The sample is experienced: 18 participants reported over two years of professional experience, of whom 10 exceeded five years, and 16 reported spending more than 20% of their time on design- related activities, ensuring a relevant and informed evaluation perspective. D. Experimental Procedure The experimental procedure was organized according to the three research questions. For RQ1, the objective was to assess the capability of the proposed methodology to automatically reconstruct sequence diagrams consistent with the actual im- plementation. For RQ2, the objective was to assess the faith- fulness of the LLM-generated reports in explaining the root cause of the detected architectural drift, as evaluated through independent expert annotations. For RQ3, the objective was to evaluate the perceived practical value of the generated artifacts from the perspective of industrial practitioners. 1) Experimental Procedure for RQ1: The procedure for RQ1 consisted of the following two steps: i) Ground-Truth Construction Three annotators indepen- dently reconstructed the reference sequence diagram for each evaluated feature-linked test case by manually analyzing the source code. The reconstruction focused on the architectural elements represented in the sequence diagram, namely lifelines and exchanged messages. Each annotator produced an inde- pendent version of the expected sequence diagram, without relying on the sequence diagram automatically generated by the proposed methodology. After the independent reconstruc- tion, the three resulting diagrams were compared. Whenever discrepancies emerged among the annotators regarding specific elements, such as the presence of a lifeline, the presence of a message, or the ordering of a message, the final decision was made through majority voting. This process produced a reference sequence diagram for each evaluated feature-linked test case, which was used as the ground truth in the subsequent analysis. i) Data Analysis Three annotators compared each ground- truth sequence diagram with the corresponding sequence dia- gram automatically reconstructed by the proposed methodol- ogy. The comparison was performed at the level of individual diagram elements, considering both lifelines and messages. Each element was assigned to one of the categories defined in Section IV, namely CONFIRMED, MISSING, ADDITIONAL, or INVERTED. The resulting classifications were used to compute quantitative metrics for assessing the reconstruction capability of the proposed methodology, including precision, recall, and F1-score. 2) Experimental Procedure for RQ2: The procedure for RQ2 evaluated the faithfulness of the root-cause explanations provided in the LLM-generated reports. In this context, faith- fulness refers to the extent to which the report correctly iden- tifies the actual root cause of the detected architectural drift. Three annotators independently analyzed the reports generated by the LLM. For each report, they inspected the explanation of the detected architectural drift and assessed whether the root cause identified by the LLM was correct with respect to the actual cause determined from the technical evidence. Each report was therefore classified according to whether the LLM-generated explanation was faithful or not faithful to the real root cause of the drift. To assess the consistency of the independent judgments, we computed Fleissâ Kappa (Îș) over the annotations provided by the three annotators. 3) Experimental Procedure for RQ3: To assess the practical value of the proposed methodology, we designed a struc- tured survey inspired by the Technology Acceptance Model (TAM) [21]. TAM is widely used to study the adoption of technologies and methods, especially through constructs such as Perceived Usefulness (PU) and Perceived Ease of Use (PEOU). In our study, we also considered Compliance Support as an additional construct relevant to the industrial context of architectural documentation and firmware verification. Participants were presented with the generated artifacts, namely the delta trace and the natural-language delta report. They were then asked to evaluate them through the survey items reported in Table I. The questionnaire included both 5-point Likert-scale questions (1 = strongly disagree (SD), 2 = disagree (D), 3 = neutral (N), 4 = agree (A), 5 = strongly agree (SA)) and open-ended questions. Closed-ended answers were summarized by grouping the responses according to the Likert-scale values. Open-ended answers were analyzed qualitatively by two authors, who identified recurring themes in the participantsâ comments. A third author subsequently reviewed and validated the resulting thematic interpretation. E. Results for RQ1 The results for RQ1 are summarized in terms of precision, recall, and F1-score across the considered categories. For confidentiality reasons, we report only aggregate percentage- based metrics and do not disclose absolute counts, such as the number of drift instances identified for each category, since these values could reveal information about the internal quality of the analyzed firmware. The CONFIRMED class achieved the highest performance, with precision equal to 96.3 %, recall equal to 92.9 %, and F1- score equal to 94.6 %. This result indicates that the methodol- ogy is particularly effective in correctly reconstructing interac- tions that are actually present in the ground truth, and therefore in identifying architectural behavior that is preserved with respect to the reference sequence diagram. The MISSING and ADDITIONAL categories also obtained strong results, with F1- scores of 88.2 % and 86.4 %, respectively. These results show that the methodology can effectively identify both elements that should have been reconstructed but are absent from the generated diagram and elements that are generated by the methodology but are not present in the ground truth. Therefore, the approach is able to capture both omissions and unexpected reconstructed interactions. The INVERTED class obtained lower performance, with precision, recall, and F1- score equal to 60.0 %. This result suggests that detecting ordering discrepancies between the ground truth and the reconstructed diagram is more challenging than detecting the presence or absence of lifelines and messages. This is also consistent with the fact that inverted interactions represent a more specific type of discrepancy, valid only for messages, where each misclassification has a stronger impact on the final metric values. RQ1 Answer The proposed methodology shows strong reconstruction ca- pability, achieving high precision, recall, and F1-score for confirmed interactions and strong F1-scores for missing and additional elements. The lower performance on inverted messages indicates that ordering-related discrepancies remain the most challenging category to detect. F. Results for RQ2 Following the protocol described in Section V-D, the expert assessment yielded Fleissâ Îș = 0.692, corresponding to sub- stantial agreement according to the interpretation guidelines by Landis and Koch [42]. These results indicate that, in most cases, the LLM- generated reports correctly identified the root cause of the de- tected architectural drift. At the same time, the non-negligible proportion of not faithful explanations shows that root-cause identification remains more challenging than describing the presence of drift itself. Disagreements among annotators were mainly concentrated in borderline cases, where the LLM provided a partially plausible explanation but did not fully capture the actual technical cause of the drift, or where the available evidence left room for interpretation. TABLE I: Questionnaire items used to answer RQ3 by assessing the perceived practical value of the generated artifacts. ID QuestionSemanticType Q1 The report generated by the LLM facilitates understanding of the root cause of architectural drift.PUL Q2 The report information was easy to relate to the evaluated feature-linked test case.PEOUL Q3 Did you notice any discrepancies or hallucinations in the report compared to the technical delta?PUQ Q4 The proposed methodology speeds up the identification of design-runtime discrepancies.PUL Q5 The methodology provides sufficient documentary evidence to support an ISO 26262 safety audit.CL Q6 I find the language and terminology used in the LLM-generated report to be clear and unambiguous.PEOUL Q7 Identifying architectural drift through message-exchange deltas is intuitive and easy to follow.PEOUL Q8 Overall, the systemâs interface/output is easy to use.PEOUL Q9 If integrated into a CI/CD pipeline, I would use this methodology on a regular basis.PEOUL Q10 What do you consider the most useful aspect of the report generated by the LLM agent?PUQ Q11 Which feature would you add to better align this methodology with ISO 26262 compliance needs?CQ L = 5-point Likert scale; Q = Open-Ended Questions; PU = Perceived Usefulness; PEOU = Perceived Ease of Use; C = Compliance Support Overall, the substantial agreement among annotators sup- ports the consistency of the expert-based evaluation, while the observed non-faithful cases show that the LLM still struggles to infer the correct root cause in some borderline cases. RQ2 Answer The evaluation indicates that LLM-generated reports are generally faithful in identifying the root cause of architectural drift, with substantial agreement among expert annotators. However, root-cause explanation remains challenging in bor- derline cases where the technical evidence is incomplete, indirect, or open to interpretation. G. Results for RQ3 Figure 9 reports the distribution of Likert-scale responses for all closed-ended survey items considered for RQ3. Q1 Q2 Q4 Q5 Q6 Q7 Q8 Q9 1 (4%) 2 (9%) 3 (13%) 3 (13%) 3 (13%) 2 (9%) 3 (13%) 8 (35%) 12 (52%) 5 (22%) 11 (48%) 9 (39%) 6 (26%) 8 (35%) 6 (26%) 15 (65%) 5 (22%) 18 (78%) 9 (39%) 11 (48%) 17 (74%) 13 (57%) 14 (61%) SD (1)D (2)N (3)A (4)SA (5) Fig. 9: Likert-scale rating distribution for RQ3. Q1 received full positive agreement, with 8 A and 15 SA, indicating that practitioners perceived the report as useful for understanding the root cause of architectural drift. Q2 shows the most dispersed distribution, with 1 SD, 2 D, 3 N, 12 A, and 5 SA. This suggests that, although the report supports drift interpretation, relating its information to the executed test cases may still require additional effort. This limitation is consistent with the current design of the reporting component, which operates on the serialized delta and development-story summaries, but does not directly exploit full test specifications or explicit traceability links. Q4 and Q7 received full positive agreement, with 5 A/18 SA and 6 A/17 SA, respectively, showing that participants perceived the methodology as ef- fective in accelerating discrepancy identification and intuitive in supporting the interpretation of runtime message-exchange deltas. Q5 obtained 3 N, 11 A, and 9 SA, suggesting that the generated artifacts are considered useful for safety-oriented documentation, although additional traceability information is needed to better support ISO 26262 audit needs. Similarly, Q6 obtained 3 N, 9 A, and 11 SA; Q8 obtained 2 N, 8 A, and 13 SA; and Q9 obtained 3 N, 6 A, and 14 SA. These results indicate that the language of the report, the system interface, and the potential regular use of the methodology in a CI/CD pipeline were generally evaluated positively. The open-ended item Q3 asked participants whether they noticed discrepancies or hallucinations in the generated report with respect to the technical delta. Among the respondents, 20 reported none, while three mentioned minor wording oversim- plifications or occasional ambiguity in root-cause descriptions. No respondent reported factual fabrications or omissions of delta content. This feedback suggests that the constrained reporting strategy limits hallucinations at the report level, while the remaining issues mainly concern the precision and contextual articulation of the explanation. The open-ended items Q10 and Q11 provided further insight into perceived value and desired improvements. Responses to Q10 mainly emphasized the automatic classification of drift root causes and the generation of a high-level, audit-oriented narrative that reduces the need to manually correlate multiple sources. Several respondents also valued the possibility of relating architectural changes to the development artifacts that trig- gered them. Responses to Q11 identified explicit traceability mapping as the main improvement area, especially from each reported drift to ISO 26262 work products, safety goals, and verification artifacts. Secondary requests included links to stories and commits, monitoring of architectural conformance trends over time, versioning metadata, and export capabilities including ASIL classification and mitigation status. A minority of participants indicated that no additional feature was needed, consistently with the overall positive Likert-scale ratings. RQ3 Answer Practitioners perceive the generated artifacts as useful for interpreting architectural drift and supporting safety-oriented engineering workflows. The report is considered helpful for understanding root causes, accelerating discrepancy identifi- cation, and providing an audit-oriented narrative. However, strengthening the traceability between the report, the exe- cuted feature-linked test cases, development artifacts, and ISO 26262 work products remains the main area for im- provement. VI. THREATS TO VALIDITY This study proposes an automated methodology for detect- ing architectural drift by comparing design-time specifications with execution-level evidence. As with any empirical study, the proposed approach is subject to potential threats to validity. The main threats and mitigation strategies are discussed below. Construct validity. The proposed methodology formalizes architectural drift as discrepancies between design-time and runtime interactions represented through sequence diagrams. Accordingly, the de- tected deltas capture only interaction-level deviations, classi- fied as CONFIRMED, MISSING, ADDITIONAL, or INVERTED. Other forms of drift, such as timing, data-flow, hardware- related, or asynchronous deviations, are outside the current scope. Since runtime behavior is reconstructed from function- call traces, interactions not materialized as explicit calls may remain unobserved. To mitigate this threat, design-time and runtime views are compared at the same abstraction level, and the resulting deltas are treated as candidate drift requiring expert review rather than complete architectural compliance evidence. Internal validity. The correctness of the generated runtime view depends on the accuracy of binary metadata, such as DWARF information, used to resolve HIT traces into ar- chitectural entities. Imprecise metadata or symbol resolution may affect the inferred interactions, while predefined test procedures may not cover all execution paths. To mitigate these threats, the study relies on production-grade builds with full debug information and safety-oriented test procedures. The LLM-based step is confined to reporting already-computed deltas and does not affect trace processing, normalization, or delta computation. External validity. The evaluation was conducted within a single industrial organization and on proprietary safety-critical firmware modules. Although the selected test cases reflect realistic industrial scenarios, the results may not generalize to other organizations, domains, architectures, or systems with highly concurrent, interrupt-driven, or non-deterministic execution models. The practitioner survey may also be affected by social desirability, common method bias, and evaluation apprehension, as participants belonged to the same industrial context in which the methodology was assessed. To mitigate these threats, participation was voluntary and anonymous, and open-ended questions were included to capture critical feed- back beyond Likert-scale ratings. Further studies on additional systems, organizations, and execution models are needed to strengthen the generalizability of the findings. VII. LESSONS LEARNED FROM INDUSTRIAL ADOPTION This section discusses lessons learned from the industrial application of the proposed approach, drawing on the experi- mental evaluation and practitioner feedback. L1: Algorithmic computation and LLM assistance address different failure modes. The proposed methodology separates the Differ engine (Phase 2) from the LLM-assisted reporting layer (Phase 3) to address their complementary weaknesses. The Differ ensures reproducible, auditable classification of interactions, while the LLM layer reduces the cognitive load of interpreting the resulting delta. Reversing these roles would introduce variability and fabrication risks into safety-critical traceability chains. This suggests pipelines are a robust pattern for safety- oriented engineering methodology. L2: Complementary representations support distinct engineering roles. The methodology produces two aligned outputs: a Serialized Delta in PlantUML intended for automated processing, tooling integration, and traceability; and a natural-language report (Delta Report) generated to support human review activities. Neither representation is sufficient in isolation. The Serialized Delta provides precision and processability, but offers limited contextual support for architectural interpretation. Conversely, the Delta Report improves readability and reduces the inter- pretive effort during architectural reviews, but is inherently descriptive and less effective at explaining root causes, par- ticularly in the absence of explicit test specifications and upstream traceability links, a limitation also reflected in survey feedback. Practitioners consistently emphasized that LLM- generated reports are valuable only as supporting material. They do not replace design artifacts, verification evidence, or safety arguments required by ISO 26262, and must al- ways be validated through expert review. Human-readable and machine-readable outputs therefore serve complementary roles at different stages of the engineering and review workflow. VIII. RELATED WORK Research related to our work connects architecture recovery and documentation for embedded and safety-critical auto- motive software with trace-based runtime analysis, runtime verification, and the use of execution traces as behavioral evidence in software engineering. Software architecture recovery has been widely studied to reconstruct architectural knowledge from implementation ar- tifacts. Source-code- and static-analysis-based approaches can recover architectural views of automotive embedded software, support communication-level consistency checks, and generate UML documentation such as package, component, component & connector, and state-machine diagrams [4], [5]. These works are valuable when documentation is incomplete or outdated, but remain mainly static: they infer structures, dependencies, and design-level relations from code, without capturing which interactions are exercised in a specific runtime scenario. This limitation reflects a broader challenge in embedded-system re- verse engineering, where hardware/software interplay, timing, safety criticality, and the integration of static and dynamic information must be considered [27]. Architecture recovery has also been highlighted as a means to understand legacy ECU software and support verification and design-space ex- ploration [43]. Accurate architectural information is central to safety- critical automotive software. Prior work highlights the diffi- culty of producing complete ISO 26262-aligned architecture documentation [44], discusses compliance-oriented modeling and planning practices such as testability, traceability, freedom from interference, and partitioning [28], and surveys auto- motive reference architectures, including AUTOSAR, view- based modeling, and abstractions for managing complexity and safety requirements [45]. These studies frame architecture as essential for safety reasoning and compliance, but focus on how it should be designed, organized, or documented, rather than on how executed firmware behavior can be recovered and projected onto architectural views. Runtime evidence is central to trace-based analysis and runtime verification of em- bedded and real-time systems. Prior work presents tracing as a practical mechanism for understanding runtime behavior in resource-constrained platforms and diagnosing performance or interaction issues [46], and proposes hardware-based runtime verification to reconstruct control-flow traces and evaluate tem- poral properties online through FPGA-based processing [47]. These works provide accurate execution evidence with limited interference, but target runtime checking, timing analysis, or low-level observation rather than architectural runtime views or comparisons with statically recovered architectures. A re- lated conceptual foundation is the broader Models@run.time area, surveyed by Bencomo et al. [48], where running sys- tems remain causally connected to architectural abstractions to support runtime reasoning, adaptation, and verification. While close to our goal of producing an executed architectural view, full Models@run.time frameworks require continuous synchronization, which may introduce unsustainable overhead in resource-constrained firmware. Our approach instead adopts lightweight offline trace-based reconstruction and delta anal- ysis, elevating runtime evidence to the architectural level without continuous synchronization. Recent studies further show that execution traces can enrich software understanding tasks. Haque et al. [49] and Wu et al. [50] investigate execution traces with LLMs, showing that runtime traces can provide behavioral evidence beyond static code, although their useful- ness depends on trace representation and management. While these works are not concerned with architecture recovery, they reinforce the idea that traces capture behavioral information that static artifacts may miss. In our work, however, traces are not used to repair code or guide an LLMâs defect reasoning, but as direct evidence to reconstruct an executed architectural view of firmware behavior. LLMs have also been explored for architectural understand- ing and documentation. Hatahet et al. [51] propose a semi- automated pipeline that combines static reverse engineering and LLM-based abstraction to generate architectural descrip- tions from source code, including structural and behavioral views. In contrast, our approach does not delegate architectural inference to the LLM: relations and deltas are computed deterministically from design artifacts and runtime traces, while the LLM only post-processes pre-computed deltas to improve human interpretability. Overall, prior work separates static architecture recovery and documentation, which provide structural views for embed- ded and automotive software [4], [5], [44], [45], from trace- based analysis and runtime verification, which provide fine- grained evidence of executed behavior [27], [46], [47]. Their integration into runtime-informed architectural documentation for firmware systems remains less explored. Our work ad- dresses this gap by transforming HIT runtime traces into architectural diagrams of observed interactions and relating this executed view to the statically recovered architecture through delta analysis. Rather than replacing static recovery or runtime tracing, the proposed workflow connects them to support architecture comprehension, documentation alignment, and safety-oriented reasoning in embedded firmware. IX. CONCLUSIONS AND FUTURE WORK This paper presented a runtime-informed methodology for detecting architectural drift in safety-critical firmware by comparing design-time behavioral specifications with runtime evidence. The approach produces an explicit interaction-level delta between intended and observed behavior, while a con- strained LLM-based step is used only to generate a human- readable report supporting expert review. In this way, the methodology preserves deterministic drift detection while im- proving the interpretability of the resulting discrepancies. The industrial evaluation suggests that the proposed methodology can support the identification and interpretation of design- runtime discrepancies in ISO 26262-compliant firmware. The validation results show strong alignment between the gen- erated deltas and expert-curated references, especially for confirmed, missing, and additional interactions, while order- related discrepancies remain more challenging. Practitioner feedback further indicates that the generated artifacts are perceived as useful for reducing manual inspection effort and supporting safety-oriented documentation activities. At the same time, the LLM-generated reports should be considered review aids rather than primary safety evidence. These findings should be interpreted within the scope of the evaluated indus- trial context and the interaction-level notion of drift adopted in this work. Future work will extend the evaluation to additional systems and organizations, improve the handling of ordering- related discrepancies, investigate the extension of the differ to UML combined fragments such as alt, opt, and loop, and strengthen traceability between detected drift, feature- linked test cases, development artifacts, and ISO 26262 work products. ACKNOWLEDGMENT This work is an independent academic contribution and does not represent the views of Micron Technology, Inc. or its affiliates. The proposed methodology relies exclusively on publicly available tools, open-source libraries, and established software engineering techniques. Enterprise Architect is cited only as a representative architectural modeling environment, without implying endorsement or dependency on a specific tool [52], [53]. No proprietary data, confidential information, or industrially developed algorithms, tools, or implementations are used or disclosed. REFERENCES [1] ISO/TC 22/SC 32, âRoad vehicles â functional safety â Part 1: Vocabulary,â International Organization for Standardization, Geneva, Switzerland, Standard ISO 26262-1:2018 to ISO 26262-12:2018, 2018. [Online]. Available: https://w.iso.org/standard/68383.html [2] ISO, ISO 26262 â Road vehicles â Functional safety â Part 6: Product development at the software level, ISO 26 262-6, 2018. [3] M. Schmitt Laser, N. Medvidovic, D. M. Le, and J. Garcia, âArcade: an extensible workbench for architecture recovery, change, and decay evaluation,â in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2020, p. 1546â1550. [4] D. Amalfitano, M. D. Luca, D. F. D. Angelis, and A. R. Fasolino, âAutomated architecture recovery for embedded software systems: An industrial case study,â in Software Architecture, ECSA 2024, ser. Lecture Notes in Computer Science, vol. 14889. Springer, 2024, p. 53â68. [5] X. Zhang, M. Persson, M. Nyberg, B. Mokhtari et al., âExperience on applying software architecture recovery to automotive embedded systems,â in 2014 Software Evolution Week â IEEE Conference on Software Maintenance, Reengineering, and Reverse Engineering. IEEE, 2014, p. 379â382. [6] M. Altınıs ̧ık, H. S Ì ozer, and G. G Ì ursun, âSoftware architecture recovery from multiple dependency models,â in Proceedings of the 39th ACM/SI- GAPP symposium on applied computing, 2024, p. 1185â1192. [7] K. Sartipi and N. Dezhkam, âAn amalgamated dynamic and static architecture reconstruction framework to control component interactions 259,â in 14th Working Conference on Reverse Engineering (WCRE 2007). IEEE, 2007, p. 259â268. [8] 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, p. 257â281, 2006. [9] 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,â in Proceedings of the 33rd Annual ACM Symposium on Applied Computing, 2018, p. 1454â1456. [10] M. Leucker and C. Schallhart, âA brief account of runtime verification,â The journal of logic and algebraic programming, vol. 78, no. 5, p. 293â303, 2009. [11] E. Anthony, A. Berntsson, T. Santilli, and R. Wohlrab, âWeâre drifting apart: Architectural drift from the developersâ perspective,â in 2024 IEEE 21st International Conference on Software Architecture (ICSA). IEEE, 2024, p. 101â111. [12] B. Tekinerdogan, âArchitectural drift analysis using architecture reflex- ion viewpoint and design structure reflexion matrices,â in Software Quality Assurance. Elsevier, 2016, p. 221â236. [13] 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, p. 224â258, 2018. [14] 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. [15] 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, p. 101â126, 2024. [16] N. Stollon, On-Chip Instrumentation: Design and Debug for Systems on Chip. Springer, 2010. [17] 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 [18] IntelCorporation,CollectingIntel Âź ProcessorTrace (Intel Âź PT)inIntel Âź SystemDebugger,2026.[Online]. Available: https://w.intel.com/content/w/us/en/developer/videos/ collecting-processor-trace-in-intel-system-debugger.html [19] Synopsys, Inc., ARC Âź Real-Time Trace (RTT) Unit for ARCv2 Processors, 2024, datasheet. [Online]. Available: https://w.synopsys. com/designware-ip/processor-solutions/arc-debug-options.html [20] MIPS Technologies, Inc., MIPS Âź PDtrace TM Specification, 2012, document Number: MD00439, Revision 7.50. [Online]. Available: http://t-es-t.hu/download/mips/md00439g.pdf [21] F. D. Davis, âPerceived usefulness, perceived ease of use, and user acceptance of information technology,â MIS quarterly, vol. 13, no. 3, p. 319â340, 1989. [22] ISO, ISO 26262 â Road vehicles â Functional safety â Part 8: Supporting processes, ISO 26 262-8, 2018. [23] 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, p. 14â45, 2018. [Online]. Available: https://w.sciencedirect.com/science/article/pii/S0950584918301265 [24] 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, p. 292â297, 02 2016. [25] QASystems,âAutomatingrequirements-basedtestingforiso 26262,âhttps://w.qa-systems.com/wp-content/uploads/2020/12/ automating-requirements-based-testing-for-iso-26262.pdf, 2020. [26] R. A. Krueger and M. A. Casey, Focus Groups A Practical Guide for Applied Research. Sage, 2015. [27] 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, p. 15â22, 2012. [28] T. GroĂ, J. Moore, and J. Lee, âPlanning software architecture and modeling patterns for iso 26262 compliance,â in Nuremberg 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. linuxfoundation.org/elf/elf.pdf [30] DWARFDebuggingInformationFormatCommittee,DWARF Debugging Information Format Version 5, DWARF Committee, 2017, available under the GNU Free Documentation License, Version 1.3. [Online]. Available: https://dwarfstd.org/doc/DWARF5.pdf [31] 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 [34] S. Ducasse and D. Pollet, âSoftware architecture reconstruction: A process-oriented taxonomy,â IEEE Transactions on Software Engineer- ing, vol. 35, no. 4, p. 573â591, 2009. [35] PlantUML Team, âPlantuml,â https://plantuml.com, 2024. [36] M.Hammond,âpywin32:Pythonforwindowsextensions,â 2026, accessed: 2026-04-19. [Online]. Available: https://github.com/ mhammond/pywin32 [37] D. Spadini, M. Aniche, and A. Bacchelli, âPydriller: Python framework for mining software repositories,â in Proceedings of the 26th IEEE Inter- national Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2019, p. 908â911. [38] S. Lee, J. Heo, and K. R. Dearstyne, âCan llms update api documenta- tion?â in 2025 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2025, p. 1â12. [39] 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. [40] D. E. Perry and A. L. Wolf, âFoundations for the study of software architecture,â ACM SIGSOFT Software engineering notes, vol. 17, no. 4, p. 40â52, 1992. [41] H. Sch Ì utze, C. D. Manning, and P. Raghavan, Introduction to informa- tion retrieval. Cambridge University Press Cambridge, 2008, vol. 39. [42] G. Landis JRKoch, âThe measurement of observer agreement for cate- gorical data,â Biometrics, vol. 33, no. 1, p. 159174, 1977. [43] 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. [44] D. Amalfitano, M. De Luca, and A. R. Fasolino, âDocumenting software architecture design in compliance with the iso 26262: a practical experience in industry,â in 2023 IEEE 20th International Conference on Software Architecture Companion (ICSA-C). IEEE, 2023, p. iâxi. [45] T. Bauer, D. Barkowski, A. Bachorek, and A. Morgenstern, âReference architectures for automotive software,â in Reference Architectures for Critical Domains: Industrial Uses and Impacts.Springer, 2022, p. 73â111. [46] Z. Chamski, M. Borzkecki, and B. Ì Swiercz, âTrace-based runtime analysis of embedded real-time systems,â in Proceedings of the 17th International Conference Mixed Design of Integrated Circuits and Systems-MIXDES 2010. IEEE, 2010, p. 117â120. [47] L. Convent, S. Hungerecker, T. Scheffel, M. Schmitz, D. Thoma, and A. Weiss, âHardware-based runtime verification with embedded tracing units and stream processing,â in International Conference on Runtime Verification. Springer, 2018, p. 43â63. [48] 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, p. 3049â3082, 2019. [49] M. Haque, P. Babkin, F. Farmahinifarahani, and M. Veloso, âTowards effectively leveraging execution traces for program repair with code llms,â in Proceedings of the 4th International Workshop on Knowledge- Augmented Methods for Natural Language Processing, 2025, p. 160â 179. [50] 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. [51] A. Hatahet, C. Knieke, and A. Rausch, âGenerating software architec- ture description from source code using reverse engineering and large language model,â in 2025 ACM/IEEE 28th International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). IEEE, 2025, p. 566â575. [52] 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, p. 181â198, 2016. [Online]. Available: https://w.sciencedirect.com/science/article/pii/ S0164121215002290 [53] 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,â in 2015 12th Working IEEE/IFIP Conference on Software Architecture, 2015, p. 85â94.