Towards Evolvable State Machines and their Applications Dirk van der Linden 1 , Wim Ploegaerts 2 , Georg Neugschwandtner 1 , and Herwig Mannaert 1 1 University of Antwerp, Belgium {dirk.vanderlinden, georg.neugschwandtner, herwig.mannaert}@uantwerpen.be 2 PWCS bvba, Belgium, wim.ploegaerts@pwcs.eu Abstract—Since several decades, the pressure on organiza- tions to swiftly adapt to their environment has been increasing. At the same time, the complexity of products and services has been growing. One of the consequences is the increas- ing importance of the evolvability of software, whether this software supports production control systems in industry or business information systems. Over the past decades, finite state machines have become an increasingly popular tool for modelling behavioural aspects of software. This paper presents an explorative attempt to define design rules and constraints that should be applied to state machines to enable evolvability. Our design of an evolvable state machine is based on Normalized Systems Theory. This design is discussed in the context of automation systems as well as more general information processing applications. Keywords-Normalized Systems; Evolvability; Finite State Ma- chines; Automation Systems; Information Technology. I. I NTRODUCTION Current organizations need to be able to cope with increasing change and increasing complexity in most of their aspects and dimensions [1]. We shall call a system evolving when changes in terms of the system’s capabilities occur. The effort or cost required for adding or changing a specific capability is a property of a system – the property of evolvability. Evolvability is increasingly important for organizations to allow them to swiftly adapt to an agile and complex environment. The evolvability of production control and information systems is the primary focus of this paper. We will present a design for evolvable state machines, based on Normalized Systems Theory (NST). Its concepts can be applied to all state machines; examples will be discussed for control systems, kiosk software and business process automation. Evolvability is a critical non-functional requirement on software. Better evolvability favourably impacts the chal- lenging task of software maintenance, where adding a six- lane automobile expressway to a railroad bridge is con- sidered maintenance [2]. In their review of evolvability as a characteristic of software architectures, Ciraci and van den Broek [3] define it as “a system’s ability to survive changes in its environment, requirements and implementa- tion technologies.” However, evolvability is hard to measure, and existing software development methodologies focus on functional requirements almost exclusively. Maintenance activities often disrupt normal (produc- tive) system operation. If dynamic reconfiguration can be achieved, downtimes of systems can be reduced: a change which can be performed without a complete shutdown is called a ‘dynamic reconfiguration’ – in contrast to a ‘static reconfiguration’, which requires the complete shutdown of a system [4]. The ability of an evolving system to introduce a change by dynamic reconfiguration is a special property of the system and the type of change. Having to stop production for maintenance can be es- pecially costly for continuous production systems or 24/7 production operations. Consequently, production loss or de- lay of production due to an update of the system must be considered an indirect maintenance cost. In fact, there is a similar cost in information systems, but this cost is often neglected because it is less visible – for example, because it only indirectly affects customer satisfaction. System restarts and maintenance windows have become a generally accepted practice, even for business critical applications. For example, Microsoft Servers require restarting after certain updates of the operating system. But even payment systems are shut down several times per year ‘for maintenance’, which typically takes place between 00:15 and 02:15 at night in Belgium. On the site of Atos Worldline this is called a ‘system stop’, and during these interventions, the payment network is not available and it is not possible to carry out electronic payments [5]. This can be very inconvenient for the user if the restaurant bill has to be payed while the cards do not work, and neither does the ATM (automatic teller machine). Customer service could be improved if dynamic reconfiguration was made a design requirement for the payment system. A. Maintainability improvements Efforts to improve the flexibility and maintainability of automation systems go back decades. The first approach to implement automation control logic was based on hard- wired relay systems. In the late 1960s, GM Hydramatic issued a request for proposal for an electronic replacement. The result was a Programmable Logic Controller (PLC), 335 International Journal on Advances in Systems and Measurements, vol 6 no 3&4, year 2013, http://www.iariajournals.org/systems_and_measurements/ 2013, © Copyright by authors, Published under agreement with IARIA - www.iaria.org