Deriving guidelines for cross-vendor reuse of IEC 61131-3 modules based on Normalized Systems theorems

https://doi.org/10.1016/j.csi.2013.10.001Get rights and content

Highlights

  • We illustrate that designing cross-vendor reusable modules in automation systems is hard.

  • Some theoretical foundations on how to design reusable modules are given.

  • Five dependency problems in IEC 61131--‐3 projects are illustrated.

  • Three rules are proposed in order to avoid these dependencies.

Abstract

Flexibility, maintainability and evolvability are very desirable properties for modern automation control systems. In order to achieve these characteristics, modularity is regarded as an important concept in several scientific domains. The reuse of modules facilitates the reproduction of functionality, or extensions of existing systems in similar environments. However, it is often necessary to ‘prepare’ such an environment to be able to reuse the intended programmed functionality. In an IEC 61131-3 environment, cross-vendor reuse of modules is problematic due to dependencies in proprietary programming environments and existing configurations. In this paper, we aim to enable cross-vendor reuse of modules by controlling these dependencies. Our approach is based on the Normalized Systems Theory, from which we derived three guidelines for the design of reusable modules in an IEC 61131-3 environment for automation control projects. These guidelines are intended to support programmers in controlling dependencies, regardless of the commercial programming environment they work with.

Introduction

In several scientific domains, the structure of extensive and complex systems is regarded as a composition of a large amount of small modular building blocks. For instance, biological systems are typically based on the accumulation of very small cellular structures. This structure allows the system to easily grow or adapt itself to its ever changing environment. Analogously, in computer hardware design, the use of compatible and interchangeable modular components (e.g., screen, main board) was considered to be of major importance for the ability of the computer industry to innovate or, for specific companies, to obtain a significant market share [1]. Hence, a high degree of modular granularity is often associated with the properties of evolvability and maintainability as the fine-grained building blocks can be substituted, aggregated, and again combined to higher level aggregations. In hardware engineering, these levels of aggregations resulted in, for instance, microchips.

One of the remarkable advantages of a microchip design is the fact that each time a chip needs some functionality of another chip, this is obtained via the interface of the microchip, i.e., through one of its pins. However, documentation is crucial. The core functionality of the chip and its interface (including the size, format of the microchip holder, voltage ranges and current consumption) has to be known by the user to enable the use of the chip, without the need to manually investigate the internal working of the chip. Hence, the documentation should include an accurate interface documentation, describing the interactions of the chip ‘module’ with its environment. Consequently, if this documentation is available, a microchip can be considered a black box (i.e., a module which can be used without any additional knowledge of its internal construction) without hidden dependencies, meaning that no other aspects than those described in the documentation are needed to (re)use the chip as a module.

This relates to the IEEE definition of software flexibility: “the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed” [2]. However, documenting dependencies -which is certainly an improvement with regard to hidden dependencies- does not guarantee that they can be easily dealt with. Especially when these dependencies (despite being documented) are vendor-specific, it might be not easy to control these dependencies. Therefore, we will try to make a contribution regarding this challenge.

In this paper, we present an explorative attempt towards partly achieving module flexibility in an IEC 61131-3 environment [3]. More specifically, our approach will focus on controlling dependencies and interactions between subroutines (i.e., the so-called Program Organization Units (POU)) based on Normalized Systems Theory and earlier insights on modularity. Normalized Systems Theory (NST) focuses on obtaining evolvable and flexible modular structures, based on a set of unambiguous and proven theorems [4]. The theory initially concentrated on software architectures for business-related applications, but its applicability to other domains such as industrial controllers and business processes has been illustrated as well [5], [6], [7].

Our final goal is to formulate a set of practical guidelines for designing IEC 61131-3 POUs which can be reused in several projects in a black box way, based on the theorems of Normalized Systems Theory. Improving the programming style by adding restrictions was already suggested in older languages [8], however, as control engineers are no computer scientists, some authors suggest that they are not thoroughly aware of software engineering methodologies ([9], p. 462). In this paper, we perform an explorative attempt to define guidelines for the user of an IEC 61131-3 environment to increase cross-vendor reusability.

The rest of this paper is structured as follows. In Section 2, the IEC 61131-3 standard is briefly introduced. Next, we will highlight some theoretical foundations, i.e., insights from both Normalized Systems Theory and its extension to general modularity reasoning in Section 3. In Section 4, our guidelines towards obtaining cross-vendor reusable modules in IEC 61131-3 will be formulated and elaborated upon. Finally, we present our conclusions in Section 5.

Section snippets

The IEC 61131-3 standard

Industrial Programmable Logic Controllers (PLCs) were introduced in the late 1960s as an electronic replacement for hard-wired relay systems for the implementation of automation control logic. PLCs are usually programmed in one of the languages of the IEC 61131-3 standard [3]. Two of these languages are text-based: Instruction List (IL), similar to assembly; and Structured Text (ST), similar to a higher level programming language. Two other languages are graphic: Ladder Diagram (LD), similar to

Theoretical foundations

In this section we will briefly discuss some theoretical foundations upon which the guidelines, formulated in Section 4, are based. First, we will discuss the Normalized Systems Theory. Next, we will discuss some more general aspects regarding modularity.

Towards obtaining cross-vendor reusable modules in IEC 61131-3

The IEC 61131-3 standard was developed with the aim of creating a set of common PLC programming languages [3]. Adopting the standard, several PLC vendors made their proper IEC 61131-3 programming environment. In accordance with the initial intent of the IEC 61131-3 standard authors, the definition of such common languages for different PLC hardware and its subsequent adoption by multiple vendors, would most likely cause an increase of the portability and reusability of the programmed software

Conclusion

This paper focused on some important causes why properties like evolvability and (re)usability are hard to achieve in automation control projects. Nevertheless, we are convinced that the required theoretical knowledge for obtaining this desired goal is already largely available. However, making the existing theoretical knowledge and experience-based guidelines explicit for some specific application domains seems to be challenging. In this contribution, we addressed some typical dependency

Acknowledgment

Peter De Bruyn is supported by a Research Grant of the Agency for Innovation by Science and Technology in Flanders (IWT).

References (21)

There are more references available in the full text version of this article.

Cited by (2)

  • Towards an evolvable data management system for wind turbines

    2017, Computer Standards and Interfaces
    Citation Excerpt :

    The theorems of Normalized Systems Theory are not always easy to follow when developing applications. In a specific application domain, derived rules can be very useful for practitioners in order to have some practical guidelines available [8]. Therefore, we formulated such derived rules with the focus on some parts of our application stack in Section 3.

View full text