Information Flow Analysis of Combined Simulink/Stateflow Models

Abstract

Simulink and its state machine design toolbox Stateflow are widely-used industrial tools for the development of complex embedded systems. Due to the strongly differing execution semantics of Simulink and Stateflow, the analysis of combined models poses a difficult challenge. In this paper, we present a novel approach to relate the semantics of both the dynamic and the controller components and use it to perform an information flow analysis on a combined model consisting of discrete Simulink components and Stateflow controllers. The key idea of our approach is that we analyze the information flow in a given model by computing an over-approximation of the control flow, and deduce whether all control flow conditions combined permit information to flow on a given path or not. Our control flow analysis approach is threefold: (1) we identify timed path conditions which capture the conditions for time-dependent information flow on paths of interest for (discrete) Simulink components, and translate them into a UPPAAL timed automata representation, (2) we translate the Stateflow components to UPPAAL timed automata, and (3) we perform model checking on the resulting set of automata to analyze the existence of paths in the combined model. With our approach, we safely rule out the existence of information flow on specific paths through a model, which enables us to reason about non-interference between model parts and the compliance with security policies. Furthermore, our approach presents a starting point to generate feasible, efficient test cases and to perform compositional verification. We demonstrate the applicability of our approach using two versions of a complex case study from the automotive domain consisting of multiple safety-critical components communicating over a shared bus system.

Information-flow Interfaces

“…We showcase the applicability of our theory with an example from the automotive industry: a stepwise design of a shared communication infrastructure (a bus) from distance warners and a wheel sensor to the braking system and the odometer. We adapted this use-case from the industrial case study presented by Marcus Mikulcak et al [25]. The main goal of this system design is to ensure the integrity of a communication channel used to perform a safety-critical functionality.…”

“…With more guarantees on the implementations we need fewer assumptions to satisfy the properties. Finally, the components of our system can be, for instance, the Simulink and Stateflow models provided to the authors [25] by their industrial partners. We can then use the tool introduced in their work to verify whether these components implement the stateful interfaces we derived.…”

“…The rigorous design of systems that satisfy information flow requirements is essential from the security perspective. This activity can be supported by the verification of information flow properties, a well-studied problem with a rich landscape of both theory and tools, ranging from language-based [29,18,15,11] to simulation-based [25] approaches. Nevertheless, the existing verification solutions do not address two important aspects.…”

Runtime translation of OCL-like statements on Simulink models: Expanding domains and optimising queries

“…As these works either use purposed SysML to Simulink transformations or focus on setting and getting parameter values of limited elements, they are not easily reusable for alternative model management scenarios such as querying the Simulink model or validating constraints. Examples of other works that used Simulink models external model management processes include [ 31 ] which performs independent translation of Simulink and Stateflow blocks into UPPAAL timed automata representations that are later combined and used in model checking and [ 11 ] which performs invariance checks on simplistic Simulink model representations written in JSON. In this regard, the Massif project and our approach facilitate the managing an EMF-compatible representation or the actual Simulink model (respectively) in a broader range of model management scenarios.…”

“…Additionally, Simulink models that continuously evolve may require the co-evolution of the EMF-counterpart which involves the re-execution of a non-incremental transformation which can be expensive for large models. Furthermore, model management programs might be limited by the set of model element types supported by the Simulink-to-EMF transformation [ 31 ] which currently does not support Stateflow blocks.…”