PaperlayerView exact revision on arXiv

Source-linked AI summary

An Empirical Study of Architectural Shift from Traditional to AI-Enabled Simulink Controllers

Hadiza Umar Yusuf, Khouloud Gaaloul

arXiv:2609.38504v1cs.SEcs.AIcs.SYeess.SY

TL;DR

The paper addresses the lack of a systematic architectural comparison between traditional and AI-enabled Simulink controllers. It applies a literature-derived taxonomy to real-world models and practitioner assessments, finding persistent structural scaffolding alongside paradigm-specific differences and a gap around constraint enforcement. The authors conclude that these findings establish an empirical baseline for cross-paradigm comparison and motivate paradigm-aware tool support.

  • Problem

    The literature lacks a shared architectural lens for comparing traditional and AI-enabled controllers, limiting explicit analysis of their structural differences and design complexity.

    Source: §I · pp. 1–2

  • Method

    The study applies a literature-derived taxonomy of structural categories and functional roles to Simulink controller models and triangulates findings with practitioner assessment.

    Source: §I · p. 2, §III · p. 3, B. Empirical Evaluation Plan · p. 6

  • Results

    Subsystem organization dominates controller structures across paradigms, while AI-enabled models rely on discrete dynamics and user-defined abstraction and largely lack constraint-enforcement blocks despite practitioner expectations.

    Source: D. Discussion · p. 9, §VII · p. 10

  • Takeaways & Limitations

    The findings establish an empirical baseline for cross-paradigm architecture comparison and motivate paradigm-aware tool support for verification and safety assurance in AI-enabled CPS.

    Source: §VII · p. 10

    The AI-enabled sample is concentrated in DRL controllers using a standardized benchmark wrapper, yielding near-identical composition across plants.

    Source: §V · p. 10

Abstract

from arXiv · show

Effective AI adoption in cyber-physical systems (CPS) depends on embedding design knowledge into engineering practice. Yet as AI-enabled components increasingly replace analytically derived control laws, this occurs without a systematic understanding of how controller architectures differ or remain similar across paradigms. We address this gap with an empirical study of traditional and AI-enabled Simulink controllers, guided by a literature-derived taxonomy of ten structural categories and nine functional roles. The study analyzes 62 real-world models spanning 8 controller types and 10 application domains, and surveys 13 practitioners, identifying three architectural tensions. First, subsystem organization dominates all controller structures regardless of paradigm, occupying 68-72% of controller footprint, while core control logic occupies minimal space. Second, AI-enabled controllers rely heavily on discrete dynamics and user-defined abstraction, categories largely absent from AI literature, exposing a gap between described and implemented architectures. Third, constraint enforcement blocks largely disappear from AI-enabled models despite practitioner expectations. This reveals a misalignment where safety mechanisms shift from explicit structure to implicit training-time artifacts, breaking traceability.

I. INTRODUCTION

The paper addresses the lack of a shared architectural lens for comparing traditional and AI-enabled Simulink controllers, despite the importance of understanding how control logic is represented in CPS engineering models. It introduces a literature-derived taxonomy and empirical comparison across literature, real-world models, and practitioner perspectives.

I. INTRODUCTION

  • The literature lacks a shared architectural lens for comparing traditional and AI-enabled controllers, making it difficult to reason about design complexity across control paradigms.Existing comparisons largely focus on behavioral outcomes rather than treating architecture as an explicit object of analysis.Source: §I · p. 1
  • The study analyzes 62 real-world Simulink models across 8 controller types and 10 application domains, alongside a practitioner survey.Its comparison covers how architectures are portrayed in literature and structurally realized in practice.Source: §I · p. 2
  • A literature-derived taxonomy of ten structural categories and nine functional roles provides a consistent vocabulary for comparing controller paradigms.The taxonomy is intended as a unified instrument for cross-paradigm architectural comparison.Source: §I · p. 2
  • The study identifies three tensions: subsystem organization dominates, AI-enabled models use categories underrepresented in AI literature, and constraint-enforcement blocks largely disappear despite practitioner expectations.The authors connect the last tension to a misalignment between training-time safety and deploy-time structure.Source: §I · p. 2

II. BACKGROUND

The background frames AI adoption in CPS as an architectural shift, not merely an algorithmic substitution. It motivates a taxonomy-guided comparison of controller structures and how control responsibilities are realized.

II. BACKGROUND

  • Model-Based Design supports early modeling, simulation, and verification before deployment, while Simulink models represent controllers as interconnected blocks organized into subsystems.The study focuses on block-level structure rather than the Simulink tool or platform itself.Source: §II · p. 2
  • In the PMSM FOC illustration, a learned policy block replaces the analytic control law while the surrounding architecture remains unchanged.The comparison motivates examining how controller responsibilities and constraint enforcement are structurally realized.Source: Figure 1 · p. 2, §II · pp. 2–3
  • Traditional controllers encode predefined control laws, whereas AI-enabled controllers encapsulate data- or interaction-learned policies in components such as DRL, DNN, or FLC.The contrast includes analytical techniques such as PID, LQR, and MPC and data-driven components such as neural networks.Source: §II · p. 2
  • AI-enabled components can reduce explicit traceability and complicate safety analysis, which depends on structural decomposition and traceability across subsystems.The background identifies maintainability, interpretability, assurance, and reuse as concerns associated with structural shifts.Source: §II · p. 2

III. LITERATURE-DERIVED TAXONOMY CONSTRUCTION

The study constructs a literature-derived taxonomy to characterize Simulink controller architectures through both structural categories and functional roles. Its categories are checked against Simulink’s library structure, while roles capture components’ purposes in the control pipeline.

III. LITERATURE-DERIVED TAXONOMY CONSTRUCTION

  • The taxonomy classifies Simulink block types by structural and functional role, providing a framework for the empirical characterization.The paper presents its construction process as a sequence of steps.Source: §III · p. 3
  • The literature corpus uses criteria requiring sources to describe controller structure or Simulink guidance, be authoritative, and address a control paradigm or general Simulink convention.The search excludes informal grey literature, while retaining specified authoritative vendor documentation and modeling guidelines.Source: §III · p. 3
  • Structural categories group blocks by modeling purpose and are iteratively checked against Simulink’s library structure until they are mutually exclusive and collectively exhaustive over the corpus.The process produced ten categories spanning dynamics, computation, logic and events, routing, and AI-specific computation.Source: §III · p. 3
  • Functional roles abstract recurring controller responsibilities from literature and describe what components do in the control pipeline, independently of specific block types.The process produced nine role levels; unlike structural categories, roles may overlap for a block.Source: §III · pp. 3–4

IV. EMPIRICAL EVALUATION

The empirical evaluation compares controller composition across paradigms in literature and practice, then uses practitioner assessment to corroborate the identified differences. Its research questions distinguish literature portrayal, model-based composition, and practice-based corroboration.

A. Research Questions

  • RQ1 asks which structural categories and functional roles the literature emphasizes or omits across traditional and AI-enabled paradigms.It examines differences in how each paradigm’s literature describes controller design.Source: A. Research Questions · p. 4
  • RQ2 asks which taxonomy categories are prevalent and structurally dominant in real Simulink controller subsystems and how those patterns align with literature-derived expectations.The model-based composition and its comparison with RQ1 rely on the same underlying category-presence measurements.Source: A. Research Questions · p. 4
  • RQ3 asks whether practitioners’ manual assessments corroborate the differences identified by RQ1 and RQ2 and what those differences imply for software engineering practice.The evaluation uses practitioner assessment as corroboration of the literature- and model-based findings.Source: A. Research Questions · p. 4

B. Empirical Evaluation Plan

The evaluation combines literature analysis, quantitative characterization of 62 real-world Simulink models, and practitioner assessment using a shared controller taxonomy. It compares structural composition across paradigms and checks observed patterns against practitioners’ judgments.

Evaluation Plan

  • The evaluation proceeds from literature-based composition to model-based composition and then practitioner corroboration, applying the taxonomy to each stage.Survey participants see controller screenshots with labeled block-group overlays; C5 and C6 are excluded as ubiquitous, while specified categories are merged into five groups.Source: B. Empirical Evaluation Plan · pp. 4, 6

Dataset Curation

  • The study analyzes 62 curated Simulink CPS models, balanced between 31 traditional and 31 AI-enabled controllers, after isolating controller subsystems and exhaustively extracting nested and variant blocks.Models span multiple CPS domains; classification as AI-enabled depends on whether a learned component realizes the control law.Source: B. Empirical Evaluation Plan · pp. 4–5

Model Characterization

  • Category presence is recorded uniformly at the controller level from Simulink block types, without interpreting execution semantics or control behavior.This abstraction reduces sensitivity to controller complexity, modeling granularity, and domain-specific implementation style.Source: B. Empirical Evaluation Plan · p. 5

Metrics

  • Three metrics capture aggregate structural emphasis, average within-controller prominence, and the proportion of models containing each category.Coverage supports comparison of literature and real-world patterns; mean normalized presence weights models equally, while model-level prevalence measures adoption breadth.Source: B. Empirical Evaluation Plan · p. 5

Survey

  • Practitioner assessment uses 13 experienced participants who evaluate 12 representative models covering encapsulated, equation-based, and function-based designs.Per-model assessments include dominance and essentiality ratings, paradigm classification, and open-ended justification.Source: B. Empirical Evaluation Plan · p. 5

1) RQ1: Literature-based composition:

Literature descriptions portray traditional controllers as dynamics- and constraint-centered, while AI-enabled descriptions emphasize AI computation and supporting structures. Both retain core control dynamics as a central functional role, but explicit constraint-enforcement blocks are absent from AI descriptions.

RQ1: Literature-based composition

  • Traditional descriptions emphasize continuous dynamics (C1, 25.8%), discrete dynamics and state (C2, 22.6%), and discontinuities and nonlinearities (C3, 19.4%), together about two-thirds of referenced blocks.The cited structures include Transfer Function, State-space, Integrator, Derivative, Saturation, Rate Limiter, and Dead Zone blocks.Source: 1) RQ1: Literature-based composition · p. 6
  • AI-enabled descriptions emphasize AI-specific constructs (C10, 32.1%), memory/data structures (C9, 14.3%), and user-defined logic (C8, 10.7%).Examples include RL Agent, Neural Network Predict, Fuzzy Logic Controller, MATLAB Function, Mux, and Data Store blocks.Source: 1) RQ1: Literature-based composition · p. 6
  • C1 and C3 are absent from AI-enabled literature, while C10, C8, and C9 are strongly represented; C6 has modest, balanced coverage (9.7% traditional, 10.7% AI).The descriptions have comparable referenced block counts (31 traditional versus 28 AI), but their distributions differ.Source: 1) RQ1: Literature-based composition · p. 6
  • Core control dynamics (L1) remains central in both paradigms (38.7% traditional, 35.7% AI), but AI descriptions shift emphasis toward signal preprocessing and computation (L4, 28.6%) and learning and adaptation (L8, 14.3%).Traditional descriptions also emphasize signal constraint enforcement (L2, 16.1%) and L4 (16.1%).Source: 1) RQ1: Literature-based composition · p. 6
  • Signal constraint enforcement (L2) is absent from AI descriptions because constraints are handled implicitly during training rather than recorded as explicit blocks.The reported mechanisms include reward shaping, penalties, and environment design; the extraction counts explicit block references.Source: 1) RQ1: Literature-based composition · pp. 6–7

2) RQ2: Model-based composition:

In real-world models, subsystem organization and interfacing dominate controller structure across both paradigms, while several scaffolding and data-handling categories are widely adopted. The observed shift from traditional to AI-enabled design is structurally localized rather than pervasive.

RQ2: Model-based composition

  • C6 subsystem organization, interfacing, and routing accounts for 68.8% of traditional and 72.0% of AI controller structure by coverage.Its mean normalized presence is also higher for AI-enabled controllers (74.4%) than traditional controllers (54.6%).Source: 2) RQ2: Model-based composition · p. 7
  • Explicit continuous dynamics and nonlinearities occupy little aggregate structure (C1: 0.4%/0.3%; C3: 0.5%/0.2%, traditional/AI) and are not essential across the dataset.Their model-level prevalence is C1: 25.8%/6.5% and C3: 32.3%/12.9%, respectively.Source: 2) RQ2: Model-based composition · p. 7
  • Controller-family signatures vary: DRL assigns 80.7% coverage to C6, while DNN assigns 24.1% to C5 and FLC assigns 15.3% to C9.The DRL signature reflects a fixed Simulink scaffold reused across its 23 models, not 23 independently varied designs.Source: 2) RQ2: Model-based composition · p. 7
  • C6 is nearly universal (96.8% traditional, 100.0% AI), alongside broad adoption of C5, C7, and C9 across both paradigms.C5 prevalence is 77.4% and 96.8%; C7 and C9 are 71.0%/90.3% and 100.0%/100.0%, respectively, for traditional/AI models.Source: 2) RQ2: Model-based composition · p. 7
  • C5, C6, C7, and C9 form a shared structural core, while C1 and C10 are the primary paradigm-specific differentiators, making the shift structurally localized.The literature-based comparison does not report C10 in the model-level analysis because AI cores are typically nested or masked subsystems whose internal blocks are counted elsewhere.Source: 2) RQ2: Model-based composition · p. 7

3) RQ3: Practice-based corroboration:

Practitioner assessments broadly corroborate model-level patterns: C7 and C9 are prominent and essential across paradigms, while C1 is less central in AI-enabled controllers. The main mismatch is that practitioners rate C3 as more essential than its model-level prevalence supports.

Survey analysis

  • The 13 participants’ assessments used average presence (0–2) and average essence (1–5); paradigm-classification agreement was Fleiss’ κ = 0.4847.The study interprets κ = 0.4847 as moderate inter-rater agreement.Source: 3) RQ3: Practice-based corroboration · p. 7

Manual Classification

  • At least 11 of 13 participants classified traditional controllers consistently, but only 5 of 13 correctly classified AI-enabled model M05.M05 combined classical dynamics and feedback-like signal flow with neural computation, while lacking reward or memory loops expected of reinforcement learning.Source: 3) RQ3: Practice-based corroboration · p. 8

Dominant and essential categories

  • C7 and C9 were highly dominant in both paradigms (presence: 1.5/1.6, traditional/AI) and highly essential (essence: 4.2/4.4).These ratings align with their near-universal model-level prevalence.Source: 3) RQ3: Practice-based corroboration · p. 8
  • C1 was moderately dominant in traditional controllers but not AI-enabled ones (1.0 vs. 0.5), and its essentiality was lower for AI (3.1/2.1).This matches the model-level prevalence of C1: 25.8% in traditional versus 6.5% in AI-enabled controllers.Source: 3) RQ3: Practice-based corroboration · p. 8
  • C3 was rated more essential for AI-enabled than traditional controllers (3.1 vs. 2.5), despite lower AI-family prevalence (12.9% vs. 32.3%).Practitioners may mistake signal-shaping or transformation blocks for constraint mechanisms.Source: 3) RQ3: Practice-based corroboration · p. 8

Practice implications

  • Practitioners’ overestimation of constraint-related structure risks overstating constraint enforcement during manual safety review.The authors attribute the mismatch likely to confusing signal-shaping or transformation blocks with constraint mechanisms.Source: 3) RQ3: Practice-based corroboration · p. 9

D. Discussion

The discussion identifies three tensions: scaffolding dominates both paradigms, real-world architectures retain a shared core despite AI-specific components, and constraint enforcement becomes less visible in AI-enabled models. It argues that MBSE tools should make reusable scaffolding and training-time safety decisions explicit and inspectable.

Lesson 1: The “Scaffolding” Dominates the System Model

  • C6 scaffolding dominates controller families across paradigms, while control laws or AI policies occupy only a small fraction of model structure.Most structure supports signal routing, subsystem hierarchy, data buffering, and interfacing; C5 is broadly present but varies in weight.Source: D. Discussion · p. 9
  • AI-enabled families adopt C2, C7, and C8 around learned components, while traditional families show more concentrated family-specific signatures.Migration therefore entails re-engineering scaffolding, which occupies most of the model, not merely swapping the control algorithm.Source: D. Discussion · p. 9

Lesson 2: The Shift is Less Radical in Practice

  • AI-enabled and traditional controllers share a common architectural core of C5, C6, C7, and C9, with C1 and C10 serving as primary differentiators.Practitioners also perceive C7 and C9 as highly dominant in both paradigms.Source: D. Discussion · p. 9
  • M05’s learned component was embedded in traditional scaffolding, including classical dynamics and feedback loops, making its paradigm difficult to classify consistently.The authors connect this ambiguity to incremental AI integration into existing MBSE structures.Source: D. Discussion · p. 9

Lesson 3: Mind the Architectural Blind Spots

  • Traditional designs encode constraints as explicit structure, whereas AI-enabled systems handle them during training, leaving them invisible in deployable architectures.Manual model review is likely to miss the resulting traceability gap, and practitioners may mistake signal-shaping blocks for constraint mechanisms.Source: D. Discussion · p. 9

Tool support

  • The authors propose reusable first-class scaffolding abstractions and explicit, inspectable artifacts for reward-shaping, penalties, and environment design.They leave the design and validation of such tooling to future work.Source: D. Discussion · p. 9

V. THREATS TO VALIDITY

The authors identify construct, internal, external, and conclusion validity threats tied to the taxonomy and metrics, data coverage, participant judgments, and the sampled models. They mitigate some threats through triangulation and diverse sources, but note boundaries on representativeness and generalization.

Construct Validity

  • C6’s dominance in both paradigms may reflect Simulink modeling style rather than controller design differences.The authors base the taxonomy on literature, validate it against Simulink’s library, and triangulate metrics with human interpretation.Source: §V · pp. 9–10
  • The AI-enabled sample includes 23 DRL controllers among 31 models, many built on a standardized benchmark wrapper, yielding near-identical composition across plants.Block-level coverage is more sensitive to this homogeneity than model-equally weighted MNPc and MLPc measures.Source: §V · p. 10

Internal Validity

  • The model dataset may contain incomplete subsystems, and screenshots rather than interactive models may limit what participants infer about system structure.The authors used exhaustive block extraction and consistent screenshot annotations, and allowed author contact for clarification.Source: §V · p. 10

External Validity

  • The 62 open-source, benchmark, and competition-dataset models may not represent proprietary industrial practice or generalize beyond Simulink and the covered domains.The 13-person survey may also omit the full range of industrial expertise.Source: §V · p. 10

Conclusion Validity

  • Conclusions are bounded by the dataset, literature, and survey participants; explicit block references may not capture full controller structure, and judgments may vary by experience.The study combines literature, model, and human-centered evidence to support consistent comparison across controller types.Source: §V · p. 10

VI. RELATED WORK

Prior work leaves controller architecture undercharacterized, while this study finds subsystem organization dominates both paradigms and identifies structural differences in AI-enabled controllers.

VI. RELATED WORK

  • Existing Simulink taxonomy studies classify testing and variability, but do not characterize controller architecture or compare traditional and AI-enabled designs.Boll et al. show model size and block counts cannot reveal architectural intent, while Shrestha et al. motivate curated corpora for replication.Source: §VI · p. 10
  • Prior AI-versus-traditional Simulink comparisons focus on performance, leaving the distribution of control responsibilities across blocks and subsystems unanalyzed.AI-augmented MBSE/MDE work spans modeling and engineering frameworks, but related approaches identify limited integration across CPS development stages.Source: §VI · p. 10

VII. CONCLUSION

  • Subsystem organization dominates both paradigms; AI-enabled controllers rely on discrete dynamics and user-defined abstraction, while constraint-enforcement blocks are structurally absent.These findings establish an empirical baseline for cross-paradigm comparison and motivate paradigm-aware tool support for verification and safety assurance.Source: §VII · p. 10
Loading 2609.38504v1…