From Timing Budgets to WCETs: Robust SIL- and BSW-Aware Clustering and Allocation for Iterative Automotive Software Development

Our goal is to construct a set of criticality-aware runnable clusters $𝒞$ such that all runnables in a cluster share the same SIL and compatible chain and period properties. These clusters are the units transformed into application tasks in the next phase (Section 4.3). We build $𝒞$ in three steps: (i) Per-chain grouping: for each chain ${\zeta }_c$, we group runnables of equal SIL into preliminary clusters. (ii) Conflict resolution: if a runnable appears in multiple preliminary clusters (chain sharing), we iteratively split/merge affected clusters until each runnable belongs to exactly one cluster while preserving identical chain context $chains(r_j)$. (iii) Period-cap refinement: if a cluster contains more than two distinct periods, we keep the two most frequent periods (counted over runnable occurrences in that cluster; ties broken by choosing the shorter period) and split off remaining periods into separate clusters. The cap is not a theoretical limitation. It is an engineering heuristic: adding further periods increases the APS major cycle and the number of frames, which enlarges the CP model and often increases the maximum frame cost $C^{\prime }$ through sparse runnable placements. We therefore keep at most two periods per cluster to preserve schedulability margins and solver tractability. Formally, each cluster ${\chi }_q\in 𝒞$ must satisfy:

Here, $chains(r_j)$ returns the set of cause-effect chains containing $r_j$, and $periods({\chi }_q)$ returns the number of distinct runnable periods in cluster ${\chi }_q$.

Figure 2 illustrates the construction by clusters ${\chi }_1$ to ${\chi }_{11}$ across four chains. We first form per-chain clusters by grouping runnables of equal SIL that appear in the same chain. We then resolve conflicts where a runnable would belong to multiple clusters (e. g., due to chain sharing) by splitting or reassigning clusters until each runnable appears in exactly one cluster (e. g., ${\chi }_2$ and ${\chi }_4$). If a chain exhibits more than two periods for the same SIL, we assign the two most frequent periods to the same cluster and keep additional periods separate to avoid excessive utilization growth. Finally, substitute functionality within a SIL-constrained chain is treated as a separate cluster (e. g., ${\chi }_8^{\prime }$). The resulting set $𝒞$ provides SIL/chain/period-consistent clusters that serve as input to the task-creation step in Section 4.3.

For each critical cluster ${\chi }_q\in 𝒞$, we create exactly one multiframe application task ${\tau }_t^{\prime }$ that inherits the cluster’s SIL. We follow the Arbitrary Periodic Solution (APS) [32, 4] method, which combines multi-periodic runnables into a single AUTOSAR-compliant multiframe task [42]. A multiframe task is a periodic task with period $T^{\prime }$ and deadline $D^{\prime }$, whose $f^{\prime }$ frames have frame-specific WCETs $\{C_1^{\prime },\mathrm{\dots },C_{f^{\prime }}^{\prime }\}$ repeating every $f^{\prime }$ activations. For a cluster ${\chi }_q=\{r_1,\mathrm{\dots },r_n\}$ with runnable periods $T_{r_j}$, APS defines

with $f^{\prime }={\eta }^{\prime }/T^{\prime }$ frames over one major cycle ${\eta }^{\prime }$. Runnable $r_j$ executes $m_j={\eta }^{\prime }/T_{r_j}$ instances per cycle. We denote the $a$-th instance by $r_{j,a}$ for $a\in \{0,\mathrm{\dots },m_j-1\}$, and assign it to exactly one frame ${\theta }_{j,a}\in \{1,\mathrm{\dots },f^{\prime }\}$. Within each frame, the order of runnable instances is given by ${\rho }_{j,a}$. We assume an implicit deadline $D^{\prime }=T^{\prime }$ for the merged task.

To go beyond [4], which focuses on multi-rate patterns and JLDs, we integrate SIL and BSW impact into the task configuration. We formulate the assignment of runnable instances to frames as a Constraint Programming (CP) problem with the objective to minimize $C^{\prime }$ (Eq. 10), that is, it balances frame loads to reduce worst-case utilization. All runnable instances in ${\chi }_q$ form the instance set

Runnable-level JLDs between runnables of ${\chi }_q$ are transformed into precedences between runnable instances, repeated over ${\eta }^{\prime }$. For example, a JLD $r_p\stackrel{(a,u)}{\to }{r}_q$ induces an instance-level precedence $r_{p,a}\to r_{q,u}$ (and corresponding repetitions in subsequent cycles). We denote the resulting set of instance-level dependencies by ${𝒟}^{inst}$.

For each cluster ${\chi }_q$ we solve the CP model (and, if necessary, retry after conservative cluster refinement) to obtain (a) a frame assignment ${\theta }_{j,a}$ and within-frame order ${\rho }_{j,a}$ for all instances in ${ℛ}^{\prime }$, and (b) frame costs $C_{\mathrm{\ell }}^{\prime }$ used to derive the periodic abstraction $(C^{\prime },D^{\prime })$. If the CP model is infeasible (e. g., due to tight external predecessors/successors), we conservatively refine the cluster by splitting off the runnable(s) responsible for the violated bounds and retry.

The main decision variables are: (a) ${\theta }_{j,a}\in \{1,\mathrm{\dots },f^{\prime }\}$, the frame index of runnable instance $r_{j,a}$, and (b) ${\rho }_{j,a}\in \{1,\mathrm{\dots },|{ℛ}^{\prime }|\}$, the position of $r_{j,a}$ within its frame. For convenience, we use ${\theta }_{j,a}(\mathrm{\ell })$ as an indicator that equals $1$ if $r_{j,a}$ is assigned to frame $\mathrm{\ell }$, and $0$ otherwise. The exclusive (application-only) execution time of frame $\mathrm{\ell }$ is

Let $b_{\mathrm{\ell }}={\sum }_{r_{j,a}\in {ℛ}^{\prime }}{\theta }_{j,a}(\mathrm{\ell })$ denote the number of runnable instances in frame $\mathrm{\ell }$. We assign a task-local BSW extension factor $f^{BSW}(b_{\mathrm{\ell }})$ based on the case-study profile: smaller frames incur larger relative BSW overhead, whereas larger frames amortize task-boundary service costs across more runnable instances. This yields the frame-local BSW extension

Thus, $f^{BSW}(\cdot )$ captures empirically observed task-local BSW extension ratios, not the number or topology of explicit runnable-to-runnable communication edges. The total WCET of frame $\mathrm{\ell }$ is $C_{\mathrm{\ell }}^{\prime }={\widehat{C}}_{\mathrm{\ell }}+{\widehat{C}}_{\mathrm{\ell }}^{BSW}$. For later schedulability analysis, we abstract the multiframe task as a single periodic task with

The execution window of runnables, when assigned to a task ${\tau }^{\prime }$, is either equal to the task period or smaller. If JLDs are not considered during frame assignment, it can result in assignments that make it impossible to meet an imposed JLD. For example, if a successor runnable is allocated to a frame that must complete before the predecessor runnable is released. External predecessors/successors further restrict feasible frames (Equations 4–5).

Not all original JLDs are fully internal to the cluster; some relate runnables of different SILs and thus span multiple clusters. We capture these via helper functions: (a) $jobPre(j,a)$ returns all predecessors of $r_{j,a}$ in ${𝒟}^{inst}$, and (b) $preExt(j,a)$ / $sucExt(j,a)$ return predecessors / successors outside ${\chi }_q$.

Release times and deadlines restrict the earliest and latest feasible frame for each runnable instance. For $r_{j,a}$ we derive

and enforce

To avoid overruns within one activation of the multiframe task, we require the worst-case frame time to fit into one base period:

Within each frame, runnable instances must have a strict order:

All internal precedences in ${𝒟}^{inst}$ must be honored by either placing predecessors in earlier frames or, if in the same frame, before their successors:

for all $r_{p,u}\in jobPre(j,a)$.

Since later analysis uses the periodic abstraction with execution time $C^{\prime }$, we balance frame loads by minimizing the worst-case frame time:

After solving the CP model, runnable instances are bound to frames, and frames are bound to tasks. JLDs between instances belonging to different clusters induce task-level JLDs between the corresponding multiframe tasks. A JLD between runnables mapped to different tasks is translated into a task-level JLD between these frames, repeating with the hyperperiod of the two tasks. Thus, a JLD $r_{r_i}\stackrel{(a,b)}{\to }{r}_{r_j}$, with $r_i$ mapped to ${\tau }_k^{\prime }$ and $r_j$ mapped to ${\tau }_l^{\prime }$, is translated to a new JLD $r_{{\tau }_k^{\prime }}\stackrel{({\theta }_{i,a},{\theta }_{j,b})}{\to }{r}_{{\tau }_l^{\prime }}$. We apply this translation to all cross-cluster dependencies, obtaining a reduced set of JLDs $𝒢$.

Finally, the created application tasks form the set ${𝒯}^{\prime }$, and the corresponding BSW extensions form $ℰ$, with $ℰ\subseteq {𝒯}^{\prime }$. These sets, together with $𝒢$, are the input to the subsequent steps on global BSW impact, task grouping, and core allocation.

The estimate in Eq. 13 partitions an unavailable final BSW configuration into two modeled early-phase channels. Task-local extensions reserve BSW work that scales with the constructed application tasks; global BSW tasks reserve separate periodic platform services. These channels are not functionally interchangeable. Rather, the surrogate prevents the early model from double-counting BSW load: if task-local extensions already reserve part of the BSW utilization, the remaining global-BSW estimate is reduced accordingly. The parameters of the generated global BSW tasks – periods, WCETs, SIL labels, and memory envelopes – are then sampled from the global BSW profile summarized in Section 5.1.

Eq. 13 determines the size of the generated global BSW task set. Its utilization is constrained separately. To avoid unrealistically large BSW load, we bound the combined task-local and global BSW utilization using the multiprocessor utilization bound of López et al. [36]. For a platform with $n=|𝒦|$ cores and an admissible BSW task-count range, this yields an upper BSW-utilization envelope ${𝒰}_{ub}$. We require:

Equation 14 states that the utilization of global BSW tasks must fit into the remaining BSW envelope after reserving the utilization already accounted for by task-local extensions.

Finally, BSW also consumes ROM. Let $B_k^{ROM}$ denote the ROM footprint associated with BSW on core ${\kappa }_k$ (both for global BSW tasks in $ℬ$ and task-local BSW extensions), and $M_k^{ROM}$ the per-core ROM capacity available to software. We require:

This constraint ensures that the BSW memory footprint remains below the available per-core ROM budget, leaving sufficient space for application tasks ${𝒯}^{\prime }$. The combined utilization and memory constraints for BSW and application tasks are enforced during allocation and schedulability analysis in Section 4.6, where the overall task set $(ℬ\cup {𝒯}^{\prime })=\mathrm{\Gamma }$ is mapped to the multicore platform $𝒦$.

We treat each task group ${\delta }_g\in \mathrm{\Delta }$ as an indivisible unit, map groups first (worst-fit by utilization), and then place remaining tasks in $\mathscr{H}$. After each placement, we (i) run the per-core schedulability test described above and (ii) check per-core ROM/RAM feasibility and the BSW ROM envelope. If a placement causes infeasibility, we backtrack locally by selecting the next-best core (worst-fit order) for the affected unit.

Let ${ℛ}_k\subseteq ℛ$ denote the set of runnables mapped to core ${\kappa }_k$ after allocation, and let ${𝒮}_k=\{{\mathrm{\Psi }}_i\in 𝒮\mid \exists r_j\in {ℛ}_k:r_j\in {\mathrm{\Psi }}_i\}$ be the induced set of SW-Cs placed on core ${\kappa }_k$. Memory feasibility is then checked per core as

This accounts for the ROM/RAM footprint of a SW-C’s runnables assigned to a core.

Assuming that all timing used by our analysis are sound upper bounds (i. e., include any potentially unmodeled interference) mapping accepted by our orchestration satisfies: (i) data-age constraints; (ii) SIL separation as modeled; (iii) ROM/RAM and (iv) BSW accounting by construction of extensions and enforcement of the utilization/ROM envelopes.

Based on the case-study profile [15], we implemented the system and task set generator Driverator [14]. A random seed, an application-size parameter, and a configuration variant identify each generated instance. The application-size parameter controls the number of generated application runnables ($10\text{ to }70$); these instances are application slices sampled from the industrial profile, not complete replicas of the deployed ECU. The much larger figure of approximately $6000$ runnables refers to the system-wide BSW profile from which global BSW task parameters are derived.

For each seed and size, Driverator first samples SW-Cs, assigns SIL labels, and draws SIL-specific ROM/RAM footprints. It then creates cyclic application runnables, binds them to SW-Cs so that runnables inherit the SW-C SIL, and samples periods and timing budgets from the period-specific case-study ranges. Next, it constructs cause-effect chains by sampling the number of activation patterns, the number of runnables per chain, and the corresponding data-age bound. Finally, it derives task-local BSW extension factors from the task-composition profile and generates global BSW tasks from the global BSW profile. The resulting base instance is then analyzed under the configuration variants in Table 3.

We distinguish three outcomes. A generated instance is attempted if the generator produced a complete application/BSW model for a given seed and size. It is schedulable if the corresponding variant can construct tasks, derive JLD-compatible timing constraints, and pass the schedulability test. It is allocatable if, in addition, the resulting task set can be mapped to cores while satisfying the SIL and memory constraints enabled for that variant. Thus, the columns Sched. Systems and Allocatable in Table 3 report post-analysis outcomes, not independent benchmark pools. Since each configuration variant enables different constraints, the counts are intentionally variant-specific. The total row summarizes the number of completed analyses across all variants; it should not be interpreted as the number of distinct generated base systems.

As a representative allocation target, we selected the AURIX${}^{\text{TM}}$ TC39x family: six cores, with four lockstep cores serving high-SIL workloads and dedicated RAM. We excluded the two performance cores as they may not run SIL runnables. We did not model interference and assumed it to be either prevented by platform configuration or covered by conservative WCETs. We assumed partitioned, preemptive fixed-priority scheduling (Section 3). All experiments ran on a 64-core AMD CPU at 3.1 GHz with 384 GB RAM; IBM CPLEX Optimizer 22.1.1 solves the CP model in Section 4.3.

To expose the effect of modeling choices and clustering decisions, we evaluated five configuration variants (Table 3, Figures 5 and 5). The column Basic Software distinguishes whether a variant accounts only for task-local BSW extensions (Exts), only for periodic global BSW tasks (Tasks), or for both (Both). Variants ① and ② are diagnostic, requirement-incomplete boundary cases: they deliberately combine BSW-channel selection with simplified constraint settings and are therefore not clean single-factor ablations. We retain them to show, in compact form, how partial BSW accounting and omitted constraints affect the resulting utilization. Variants ③–⑤ form the feasible comparison set: they enable both data-age and SIL constraints and progressively introduce clustering/merging under full BSW accounting. The additional BSW reference \scriptsizeB⃝ in Figure 4(c) is not a configuration variant; it disables SIL and data-age constraints only to expose the complete BSW approximation, that is the split between task-local extensions and global BSW tasks on budgets.

① NoJLD+BSWTasks (non-compliant).

We disabled data-age constraints (no JLDs / no age bounds) while keeping SIL constraints enabled. Application runnables remained unmerged (one runnable per task), and we accounted only for global BSW tasks while omitting task-local BSW extensions. This variant is a diagnostic boundary case, not a feasible architecture: it combines missing chain semantics with global-only BSW accounting. It is included to show the scale of global BSW tasks within a conservative, unmerged task structure and to provide a lower-dimensional reference for later full-accounting variants.

② NoSIL+BSWExts (non-compliant).

We disabled SIL constraints while keeping data-age constraints enabled and allowing task merging. We accounted only for task-local BSW extensions while omitting global BSW tasks. This variant is again a diagnostic boundary case, not a feasible architecture: it combines missing safety partitioning with local-only BSW accounting. It is included to show how JLD-constrained task construction interacts with task-local BSW extensions when SIL-induced splitting is removed.

③ NoCluster+BSWFull (baseline).

We enabled both data-age and SIL constraints and account for both BSW extensions and global BSW tasks. Runnables remain unmerged (one runnable per task). This establishes a feasible baseline with full BSW accounting, against which merging/clustering decisions are evaluated.

④ SeqCluster+BSWFull.

Starting from ③, we enabled JLD-constrained task merging (data-age aware) under SIL constraints and full BSW accounting. Within each chain, consecutive runnables sharing the same SIL are clustered, preserving the original runnable order; runnables shared across chains are treated separately. This captures the first stage of reducing pessimism through merging while preserving chain semantics.

⑤ SILCluster+BSWFull.

Our full approach (Section 4.2–4.6). We applied SIL-aware cluster construction, JLD-aware merging (even when non-consecutive), and full BSW accounting to minimize pessimism while preserving both safety partitioning and chain semantics.

Table 3 summarizes the evaluation scale and runtimes. Across all variant-specific analyses, $13,825$ runs produced schedulable task sets and $12,973$ of those also satisfied the enabled memory-allocation constraints. The table also lists which constraints were enforced (data age / SIL / task merging) and which BSW accounting mode was used.

Across all variants and synthesized systems, end-to-end runtimes range from 1 s to 2.9 h and vary substantially with system structure (and thus analyzability), yet remain within a practical range for iterative engineering workflows. The dominant costs stem from application task construction (CP-based multiframe configuration) and the subsequent timing analysis; other steps contribute only minor overhead in comparison.

Our initial claim was that explicit BSW modeling and SIL/JLD-aware clustering reduce analysis pessimism and increase feasibility margins. How to read the plots: The absolute utilizations in Figures 5 and 5 are informative but dense. Variants ① and ② are diagnostic boundary cases, whereas ③–⑤ form the feasible full-accounting comparison set. The normalized ratios in Figure 6 provide the clearest view of relative gains and should be consulted alongside the absolute plots.

Global BSW tasks are a dominant driver: Variant ① combines global-only BSW accounting with disabled data-age enforcement and unmerged application tasks. In this diagnostic setting, global BSW tasks account for about 42 % utilization on average, with utilization increasing quickly as system size grows. This does not constitute a clean single-factor ablation, but it shows that global BSW is a first-order design concern. Since ① disables JLDs, it violates chain semantics by construction and serves only as a non-compliant diagnostic reference.

Task-local BSW extensions equally matter, but depend on runnable mapping: Variant ② quantifies task-local BSW extensions under JLD-enforced data age and merging, but it omits global BSW tasks and disables SIL constraints. Hence, its absolute utilization is not directly comparable to full-accounting variants; one must conceptually add the missing global BSW share exposed by ①. Nevertheless, ② shows that extensions remain non-negligible and that enforcing data-age constraints contributes substantially to overall utilization. The variant violates safety partitioning by construction and is included only as a non-compliant diagnostic boundary case.

Our BSW approximation remains bounded: Since ① and ② expose only one BSW channel each, Figure 4(c) reports the unconstrained BSW reference \scriptsizeB⃝. It shows the complete generated BSW utilization, split into task-local extensions and global BSW tasks. The combined BSW utilization stays below the Lopez upper-utilization envelope by construction: Eq. 14 first reserves the task-local contribution $\mathrm{{\rm Y}}$ and then restricts global BSW tasks to the residual budget ${𝒰}_{ub}-\mathrm{{\rm Y}}$. Thus, \scriptsizeB⃝ does not independently validate the bound but makes the calibration of the early-phase BSW model transparent.

Full constraints and full BSW accounting increase pessimism: Variant ③ enables both SIL and data-age constraints and accounts for both BSW types, but keeps runnables one-per-task (no clustering). This represents a feasible yet pessimistic baseline and yields the highest total utilization among the feasible variants; the disproportionate growth in BSW utilization is most clearly visible in Figure 6(b).

SIL/BSW-aware clustering progressively reduces pessimism: Variants ④ (SeqCluster+ BSWFull) and ⑤ (SILCluster+BSWFull) progressively reduce pessimism by clustering/merging under full constraints and full BSW accounting. Figure 6 shows a monotone reduction in both total and BSW utilization from ③ to ④ to ⑤, with improvements becoming more pronounced as system size grows. Notably, the full approach (⑤) can achieve utilization below the diagnostic configurations that ignore either JLDs (①) or SIL constraints / global BSW tasks (②), indicating that the gains stem from improved task construction under realistic constraints rather than from relaxing the constraint set.

From this set of experiments, we conclude that BSW is a primary utilization driver and must be modeled explicitly; within that realistic setting, our SIL/BSW-aware clustering effectively reduces pessimism and recovers feasibility margins.

As a sanity check against established cause-effect chain analysis practice, Figure 7 plots, for each cause-effect chain, the ratio of computed end-to-end latency to its data-age bound (ratios $\le 1$ satisfy the constraint). In ① (NoJLD+BSWTasks), latencies are evaluated without enforcing JLDs; only about half of the chains meet their bounds, confirming that ① violates data-age requirements by construction and thus serves only as a diagnostic extreme. In contrast, all variants that enable JLDs (②–⑤) satisfy the data-age bounds by construction; we illustrate this with the feasible baseline ③ (NoCluster+BSWFull) in Figure 7. This confirms that our implementation of JLD-based enforcement behaves as expected, and that the utilization results discussed above are obtained under data-age compliant configurations.

We propose that feasibility-relevant memory constraints must be considered alongside timing. Therefore, our experiments in Figure 8 report cumulative ROM/RAM footprints induced by SW-Cs, where each SW-C aggregates the budgets of its constituent runnables. We compared a default SW-C partitioning (one cyclic runnable per SW-C) against an extended partitioning (fewer SW-Cs hosting up to two runnables each), which improved memory efficiency by reducing per-component overheads. As the number and size of SW-Cs grew, both schemes approached the per-core resource limits of the target platform (Section 5.2). Global BSW memory was accounted for separately via the per-core envelope in Eq. 15. We reason that even when clustering reduces utilization, memory remains critical and must be enforced jointly with schedulability.

To assess practical effectiveness, we applied our full approach (⑤ SILCluster+BSWFull) to our real-world motion and drive controller in its early-design configuration (all constraints enabled). The end-to-end analysis completed in 2.43 h and produced a feasible mapping that respects SIL separation, data-age constraints, and per-core memory limits.

We report results as ratios normalized to the controller’s deployed configuration (deployed baseline = 1.0). In terms of utilization, our approach reduces total CPU load to 0.9325 ($\approx$7 % improvement) and BSW utilization to 0.9278 ($\approx$7 % improvement), indicating that SIL-aware clustering together with explicit BSW modeling can translate into tangible headroom in real-world development cycles. This check does not validate Eq. 13 as a universal model, but it confirms that the early-phase BSW abstraction yields a total BSW load in the same range as the deployed industrial configuration. In terms of memory, all cores remain close to capacity; ROM improves slightly to 0.9893, while RAM remains essentially unchanged at 0.9954. The framework yields meaningful utilization gains on a highly loaded production-grade automotive system, suggesting that it can provide actionable guidance when revisiting architectures across iterative integration and update cycles.

We quantify architectural churn using overlap-based stability scores (not a metric in the strict mathematical sense). A score of 1 means that the same tasks remain co-located on equivalent cores; a score of 0 means that no such co-location structure is retained. The underlying engineering notion is that the costly decision is the co-location structure of periodic tasks; reordering within a core (priorities) or swapping equivalent lockstep cores is comparatively cheap. Accordingly, we measure how well the original per-core task grouping is preserved. Let $\mathrm{\Gamma }={𝒯}^{\prime }\cup ℬ$ denote the full periodic task set (application multiframe tasks and global BSW tasks), and let $𝒦$ be the set of lockstep cores. For a reference solution (at the initial budget stage), let $P_k\subseteq \mathrm{\Gamma }$ be the set of tasks allocated to core ${\kappa }_k$; after refinement, let $P_k^{\prime }$ denote the corresponding set. We first compute a directional fixed-label retention score $S_{\mathrm{fix}}=\frac{1}{|𝒦|}{\sum }_{{\kappa }_k\in 𝒦}\frac{|P_k\cap P_k^{\prime }|}{|P_k|}$, which answers: how much of the initial allocation is retained on the same labeled core? Since lockstep cores are interchangeable in our model, we additionally allow a relabeling of cores and compute the best matching between the per-core task sets: $S_{\mathrm{perm}}={\max }_{\pi }\frac{1}{|𝒦|}{\sum }_{{\kappa }_k\in 𝒦}\frac{|P_k\cap P_{\pi (k)}^{\prime }|}{|P_k|}$, where $\pi$ ranges over permutations of the lockstep cores. In practice, we keep any unchanged cores with $P_k=P_k^{\prime }$ fixed (they contribute a value of $1$ in the average) and solve the remaining assignment as a maximum-overlap matching.

We report overall stability as $S=S_{\mathrm{perm}}$ and define churn as $1-S$. Thus, we do not penalize priority changes or core label swaps, but we do penalize changes in the co-located task sets that drive integration/configuration effort.

For each synthesized system, we start from conservative execution-time budgets (as in the previous experiments) and compute a reference allocation. We then progressively replace budget values by WCET samples for increasing fractions of execution-time parameters: $0\%,20\%,40\%,60\%,80\%$, and $100\%$ (budgets $\to$ WCETs), and re-run the toolchain to obtain a refined allocation. Importantly, for each refinement level we re-sample which parameters are switched independently (e.g., the $20\%$ subset is not necessarily contained in the $40\%$ subset). This yields a deliberately conservative estimate of stability: unlike a realistic iterative workflow where measured values accumulate over time, our setup injects additional variation and thus tends to maximize observed churn.

Figure 9 reports stability distributions over several thousand generated systems for variants ① and ③–⑤. Across all refinement levels, the feasible variants with full BSW accounting and clustering (③–⑤) consistently achieve higher stability than the diagnostic variant ①. In particular, ⑤ (SILCluster+BSWFull) shows the highest median stability and the tightest spread, indicating that SIL/BSW-aware clustering reduces the need for structural remapping as timing inputs change. Compared to ①, stability improves by roughly 20–30 percentage points (depending on refinement level), despite the conservative re-sampling.

Figure 10 complements this view by reporting normalized total utilization for the same refinement experiment. Values below 1 indicate that early budgets were conservative and that refining toward WCETs reduces execution-time pessimism; conversely, higher values imply less headroom. Variants ③–⑤ exhibit lower normalized utilization than ①, with ⑤ lowest overall. This additional headroom helps absorb timing refinements without forcing structural changes, which is consistent with the stability trends in Figure 9.

Taken together, these results support using our toolchain as a recurring architectural analysis step during budget-to-WCET refinement. The full SIL/BSW-aware variant does not eliminate architectural churn, but it consistently retains more of the initial co-location structure than less-informed variants even under aggressive resampling. We therefore interpret the stability experiment as evidence for the relative robustness of the structural decisions.

The absolute stability values should not be read as evidence that architectural churn disappears. Values around 0.5–0.6 still indicate substantial structural change under aggressive changes – we expect better results in actual use, since measured WCET information typically accumulates monotonically rather than being re-replaced by budgets. We therefore use the experiment primarily as a relative robustness test: under identical refinement and resampling conditions, SIL/BSW-aware clustering retains more of the initial co-location structure than less-informed variants.