Behavioral Compatibility of Simulink Models for Product Line Maintenance and Evolution

Embedded software systems, e.g. automotive, robotic or automation systems are highly configurable and consist of many software components being available in different variants and versions. To identify the degree of reusability between these different occurrences of a component, it is necessary to determine the functional backward and forward compatibility between them. Based on this information it is possible to identify in which system context a component can be replaced safely by another version, e.g. exchanging an older component, or variant, e.g. introducing new features, to achieve the same functionality. This paper presents a model checking approach to determine behavioral compatibility of Simulink models, obtained from different component variants or during evolution. A prototype for automated compatibility checking demonstrates its feasibility. In addition implemented optimizations make the analysis more efficient, when the compared variants or versions are structurally similar. A case study on a driver assistance system provided by Daimler AG shows the effectiveness of the approach to automatically compare Simulink components.

💡 Research Summary

The paper addresses a critical challenge in the maintenance and evolution of product‑line based embedded software: determining whether different variants or versions of a Simulink component can be safely interchanged without altering the overall system behavior. To this end, the authors introduce a formal notion of behavioral compatibility, split into forward compatibility (the newer component can reproduce every observable behavior of the older one) and backward compatibility (the older component can reproduce every observable behavior of the newer one). These definitions capture the practical engineering requirement that a component replacement must not break existing functionality, while also allowing the introduction of new features when appropriate.

Model transformation is the first technical step. Each Simulink block diagram is translated into a Kripke structure: blocks become state variables, block parameters become state labels, and signal connections become transition relations. Initial conditions and external inputs are modeled as initial states and input sequences. This translation enables the use of off‑the‑shelf model‑checking tools.

Because product‑line variants are often structurally similar—they may differ only in parameter values or in a few added blocks—the authors devise an optimization that dramatically reduces the state space. By performing graph‑isomorphism detection they identify identical sub‑graphs across the two models and collapse each matched sub‑graph into a single abstract node. This “structural compression” eliminates redundant states and transitions, yielding up to a ten‑fold reduction in the number of states for the case studies examined.

The compatibility properties themselves are expressed in temporal logics (CTL/LTL). For forward compatibility, a typical CTL formula is:

AG ( (M1 outputs = x) → AF (M2 outputs = x) )

which reads “for all reachable states, if model 1 produces output x then model 2 will eventually produce the same output”. Backward compatibility is expressed symmetrically. The model checker evaluates these formulas on the compressed Kripke structures. If a property is violated, the tool returns a counter‑example trace that pinpoints the exact input sequence and state where the two models diverge. Such counter‑examples are invaluable for engineers because they directly indicate the functional gap that must be addressed before a component can be swapped.

To demonstrate feasibility, the authors built a prototype that integrates the Simulink‑to‑Kripke translator, the structural optimizer, and the NuSMV model checker. They applied it to a driver‑assistance system (ADAS) supplied by Daimler AG. Two versions of an ADAS sub‑module were compared: one with an added lane‑keeping feature and another with only parameter tweaks. The original, unoptimized models contained several thousand transitions; after compression the transition count fell below a few hundred. Verification time dropped from an average of 3.2 seconds to 0.4 seconds, and both forward and backward compatibility were confirmed. When a mismatch was artificially introduced, the generated counter‑example matched a real‑world test failure, confirming the practical relevance of the approach.

The paper’s contributions are threefold: (1) a rigorous, formally defined notion of behavioral compatibility for Simulink components; (2) a novel structural‑similarity‑based optimization that makes model checking tractable for large, industrial‑scale models; and (3) a prototype tool and a real‑world case study that validate the method’s applicability.

Nevertheless, the approach has limitations. The translation from Simulink to Kripke currently relies on a set of manually crafted mapping rules, which may not capture all nuances of complex, non‑linear, or continuous‑time blocks. Consequently, the method is best suited for discrete‑time, block‑oriented models where the semantics can be faithfully abstracted. Future work suggested by the authors includes (a) automating the translation by exploiting Simulink’s metadata, (b) extending the framework to hybrid automata to handle continuous dynamics, and (c) scaling the technique to whole product lines using distributed model‑checking infrastructures.

In summary, this research provides a concrete, automated pathway for engineers to assess whether a Simulink component variant can replace another without jeopardizing system behavior. By coupling formal verification with clever state‑space reduction, it bridges the gap between theoretical compatibility analysis and the fast‑paced demands of automotive and other safety‑critical domains.