💻 computer science

Automated Repair of Requirements for Cyber-Physical Systems in Simulink Requirements Tables

This paper proposes a framework that leverages system execution data to automatically repair misaligned declarative requirements in Simulink Requirements Tables for cyber-physical systems, effectively restoring compliance between outdated requirements and updated system implementations.

Original authors: Aren A. Babikian, Alessio Di Sandro, Federico Formica, Claudio Menghi, Marsha Chechik

Published 2026-06-03

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Aren A. Babikian, Alessio Di Sandro, Federico Formica, Claudio Menghi, Marsha Chechik

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a very complex machine, like a self-driving car or a smart thermostat. This machine is a Cyber-Physical System (CPS), meaning it mixes computer code with real-world physics. To make sure this machine works safely, engineers write a "rulebook" called Requirements. These rules say things like, "If the brake is pressed, the engine speed must stay under 4,650 RPM."

The Problem: The Rulebook Gets Outdated

In the real world, things change.

The Machine Evolves: Engineers might tweak the engine to make it faster or swap out a part for a better one.
The Rulebook Stays the Same: The original rulebook doesn't automatically update.

Suddenly, the machine is working perfectly, but it's breaking the old rules. This is a misalignment.

Traditionally, when this happens, engineers try to fix the machine to make it obey the old rules again. But sometimes, the machine is actually right, and the rulebook is just wrong, outdated, or too strict. Imagine a rule saying "The car must never go faster than 10 mph," but the car was designed to go 60 mph. Fixing the car to go 10 mph is silly; you should fix the rule.

However, finding the exact way to rewrite the rule is hard. You can't just guess; you need to look at the data the machine is producing to see what the new, correct rule should be.

The Solution: An Automated "Rulebook Doctor"

This paper introduces a new framework that acts like an automated editor for these rulebooks. Instead of trying to fix the machine, it looks at the machine's performance data (its "traces") and automatically rewrites the requirements so they match the machine's actual behavior.

Think of it like a tailor who doesn't just patch a torn shirt, but completely re-drafts the pattern based on how the person actually moves, ensuring the new pattern fits perfectly without restricting them.

How It Works (The Analogy)

The system uses a language called Simulink Requirements Tables (a way of writing rules for these machines). Here is the process:

The Input: The system takes the old, broken rule and a dataset showing how the machine actually behaves.
The Search: It tries thousands of variations of the rule. It's like a chef tasting a soup that's too salty and trying different amounts of water, sugar, or spices to fix the flavor without ruining the dish.
The "Desirability" Filter: Just making the rule "correct" (so the machine passes it) isn't enough. The system has to make sure the new rule is good. It checks for four things:
- Is it informative? (Don't just say "The engine speed must be less than 1,000,000." That's true but useless.)
- Is it too strict? (Don't say "The engine must never run." That's also true but useless.)
- Is it simple? (Don't make the math complicated if a simple number works.)
- Does it make sense? (Don't compare "engine speed" to "brake pressure" if they are different units, like comparing apples to miles.)

The Results

The researchers tested this "Rulebook Doctor" on six real-world models (like an automatic transmission for a car and a neural network). They looked at 12 different rules that had become misaligned.

Success Rate: The system successfully found new, correct rules for the machines.
Quality: The new rules weren't just "correct"; they were also useful. They were simple, made sense, and weren't overly broad or strict.
Comparison: They tried different versions of their tool (some that checked for "nonsense" rules using a math solver, others that guessed). They found that using a precise math checker and generating many "candidate" rules worked best.

The Bottom Line

This paper proves that we can build tools to automatically fix broken requirements by looking at how a system actually behaves. Instead of forcing a machine to fit an old, broken rule, we can update the rule to fit the machine, ensuring safety and efficiency without needing a human to manually rewrite complex math equations.

Key Takeaway: When the system changes, the rulebook should change too. This tool does the heavy lifting of rewriting the rulebook so it stays in sync with reality.

Technical Summary: Automated Repair of Requirements for Cyber-Physical Systems in Simulink Requirements Tables

Problem Statement

The development of complex Cyber-Physical Systems (CPSs) involves the continuous, often independent evolution of system implementations and their requirements. This independence creates a risk of misalignment, where a system update (e.g., for performance or hardware changes) renders the original requirements obsolete or incorrect. While Automated Program Repair (APR) addresses misalignment by modifying the system, it assumes requirements are correct—a premise that frequently fails in practice, particularly in safety-critical domains where requirements may be faulty, outdated, or inadequate.

Existing APR techniques are ill-suited for repairing CPS requirements because:

Domain Mismatch: APR typically targets imperative code or high-level models, whereas CPS requirements are often declarative logical formulae over time-based, real-valued signals.
Granularity: Existing methods often perform coarse-grained repairs (adding/removing blocks) or are limited to structural manipulations of logical expressions with minimal support for numeric reasoning over real numbers.
Context: APR relies on contextual cues (e.g., nearby code) unavailable in standalone, declarative requirements.

Consequently, there is a need for a complementary strategy: Automated Requirement Repair, which modifies the requirement to match the evolved system behavior rather than altering the system itself.

Methodology

The authors propose a framework that leverages system execution data (trace suites) to repair misaligned requirements specified in the MATLAB Simulink® Requirements Tables (RT) language.

1. Formalization of the Repair Problem:

Input: A trace suite $TS$ (a collection of input/output traces over time) and an incorrect requirement $r_0$ .
Output: A repaired requirement $r^*$ that is correct with respect to $TS$ (satisfied by all traces) and optimized according to specific desirability criteria.
Semantics: The framework utilizes the quantitative semantics of RTs, assigning a satisfaction degree to a requirement over a trace. A requirement is correct if its satisfaction degree is non-negative across all traces.

2. Multi-Objective Optimization Framework:
The repair process is framed as a multi-objective minimization problem. The framework searches for a Pareto-optimal set of repairs that balance Correctness with four Desirability Dimensions:

Semantic Integrity ( $d_{sem}$ ): Ensures the repaired requirement is non-trivial (not a tautology or contradiction) and consistent with domain properties (e.g., unit compatibility).
Syntactic Similarity ( $d_{syn}$ ): Measures the structural distance (e.g., tree edit distance) between the original and repaired requirement to avoid unnecessary complexity.
Satisfaction Extent ( $d_{sat}$ ): Evaluates the "magnitude" (how far the requirement boundary is from observed behavior) and "breadth" (how often the precondition is violated, leading to vacuous truth) to ensure the requirement is informative and not overly broad or restrictive.

3. Search Algorithm:
The framework employs a customizable search loop (implemented using evolutionary algorithms in the evaluation) consisting of:

Candidate Generation: Produces new requirements via mutation and crossover operators on the RT grammar.
Evaluation: Computes correctness and desirability fitness values for each candidate.
Selection: Uses non-dominated sorting to select the best candidates for the next generation.

Key Contributions

Problem Definition: A formal definition of the requirement repair problem for CPSs specified in Simulink RT, introducing a notion of correctness based on quantitative satisfaction degrees over trace suites.
Desirability Framework: A novel multi-dimensional framework for evaluating repair quality beyond mere correctness, incorporating semantic integrity, syntactic similarity, and satisfaction extent.
Customizable Framework: A general repair framework capable of handling declarative requirements over real-valued time-based signals, a capability lacking in existing APR techniques.
Empirical Evaluation: An extensive evaluation on six real-world case studies (including models from Toyota, MathWorks, and Lockheed Martin) covering 12 requirements.

Results

The authors evaluated seven variants of their framework across the case studies:

Correctness vs. Desirability: The study found a trade-off between the number of correct repairs found and their desirability scores. An aggregation strategy using separate objectives (NoAgg) produced a higher quantity of correct and semantically intact repairs compared to a weighted sum strategy (WeiSum), though the latter yielded slightly better desirability scores for the found repairs.
Tautology Checking: Using an exact SMT-based check for semantic integrity was preferred over a sampling-based approach due to precision, though both yielded similar quantities of correct repairs.
Search Parameters: Increasing the number of offspring in the evolutionary search significantly improved the number of high-quality (correct and semantically intact) repairs found, albeit at the cost of increased runtime.
Usefulness: Expert analysis confirmed that the framework could generate useful, non-trivial repairs. In most case studies, a useful repair was found within the top 3 ranked candidates when sorted by syntactic similarity or satisfaction extent.
Ablation Study: Removing any single desirability dimension (semantic integrity, syntactic similarity, or satisfaction extent) degraded the overall quality of the repairs, confirming that all three dimensions are necessary for effective repair.

Significance and Claims

The paper claims that its framework successfully addresses the gap in automated repair for declarative CPS requirements. By shifting the focus from fixing the system to fixing the requirement, the approach provides a viable alternative when system modifications are impractical or when requirements are the source of misalignment.

The authors emphasize that their work does not automate the decision of when to repair a requirement versus the system; rather, it assumes this decision has been made by engineers and provides the technical means to execute the repair. The framework is significant for its ability to handle real-valued, time-based signals and its integration of practical desirability metrics (such as avoiding trivial solutions and maintaining domain consistency) into the repair process. The results demonstrate that it is possible to automatically derive requirements that are not only mathematically correct with respect to execution traces but also semantically meaningful and syntactically close to the original specifications.