Dynamic Update of Discrete Event Controllers

Abstract

Discrete event controllers are at the heart of many software systems that require continuous operation. Changing these controllers at runtime to cope with changes in its execution environment or system requirements change is a challenging open problem. In this paper we address the problem of dynamic update of controllers in reactive systems. We present a general approach to specifying correctness criteria for dynamic update and a technique for automatically computing a controller that handles the transition from the old to the new specification, assuring that the system will reach a state in which such a transition can correctly occur and in which the underlying system architecture can reconfigure. Our solution uses discrete event controller synthesis to automatically build a controller that guarantees both progress towards update and safe update.

Dynamic Reconfiguration of Business Processes

“…This paper builds on the synthesis of discrete event controllers and in particular the work presented in [8] that uses LTS and FLTL as the input for synthesis. We strongly build on the result presented in [19] where a general technique for updating at runtime a controller. In this paper we adapt and apply this technique in the context of business process reconfiguration for DCR graph specifications.…”

“…Definition 7 (DCU Problem [19]). Let E = (E, G, L c ) be an old specification, E = (E , G , L c ) be a new specification, T be a safety FLTL formula, R ⊆ (S E × S E ) be a mapping relation of states and, stopOldReq and startNewReq are special events denoting the ending of old and start of new requirements, respectively.…”

“…We use synthesis to not only produce correct-by-construction workflows from business process requirements but also to compute a reconfiguration strategy that guarantees progress from an old workflow towards the a new one while satisfying any userdefined transition requirements. We discuss a translation of Dynamic Condition Response (DCR) graphs [11], a declarative language for business process requirements, into a formalism based on Labelled Transition Systems and Linear Temporal Logic [21] which is suitable for controller synthesis [7] and build upon recent work on dynamic controller update [19]. We validate the approach using three examples from the BPM Academic Initiative [1] described as DCR graphs which we reconfigured for a variety of transitions requirements.…”

Dynamic software updating: a systematic mapping study

“…Existing types of safety for DSUIn this study, we have identified 29 types of safety in DSU. Based on the number of primary studies for each type, we list the top six most demonstrated safety types in Table 9.In addition, number of studies have presented other 23 types of safety including con‐freeness safety [6, 73, 95 ], semantics safety [51, 76, 84 ], version consistency safety [64, 115 ], deadlock‐free safety [112, 118 ], stack safety [76 ], reconcile safety [116 ], update positions safety [51 ], domain safety [53 ], change function safety [51 ], compile‐time safety [54 ], composition‐time safety [54 ], data access safety [76 ], deadlock safety [51 ], trace safety [115 ], disjunction safety [64 ], dynamic reconfiguration safety [5 ], memory safety [95 ], patch safety [101 ], Virtual Machine safety [4 ], safe transition state [69 ], safe trace [69 ], safe function redefinition [99 ], and safe reconfiguration point [70 ]. B. Current techniques to define safety for DSUA group of studies have highlighted 19 different types of techniques to define safety for DSU including update points testing [37, 107 ], exhaustive testing [111 ], formal methods [101 ], checking assertion [95 ], program analysis [117 ], stack map checking [4 ], program monitoring [115 ], static safety checks [57 ], dodging unsafe points [46 ], flow‐sensitive updateability analysis [77 ], marking the unsafe points [46 ], systematic testing [37 ], updateability analysis [127 ], update‐specific testing [111 ], interrupts to detect safety [118 ], verification of binary […”

“…In addition, number of studies have presented other 23 types of safety including con‐freeness safety [6, 73, 95 ], semantics safety [51, 76, 84 ], version consistency safety [64, 115 ], deadlock‐free safety [112, 118 ], stack safety [76 ], reconcile safety [116 ], update positions safety [51 ], domain safety [53 ], change function safety [51 ], compile‐time safety [54 ], composition‐time safety [54 ], data access safety [76 ], deadlock safety [51 ], trace safety [115 ], disjunction safety [64 ], dynamic reconfiguration safety [5 ], memory safety [95 ], patch safety [101 ], Virtual Machine safety [4 ], safe transition state [69 ], safe trace [69 ], safe function redefinition [99 ], and safe reconfiguration point [70 ].…”