Key maturity indicators for module libraries for PLC-based control software in the domain of automated Production Systems

Proceedings,16th IFAC Symposium on Proceedings,16th IFAC Symposium on Information Control Problems in Manufacturing Information Control Problems in Manufacturing Proceedings,16th IFAC Symposium on Available online at www.sciencedirect.com Proceedings,16th IFAC Symposium on Bergamo, Italy, June 11-13, 2018 Proceedings,16th IFAC Symposium on Bergamo, Italy, June 11-13, 2018 Information Control Problems in Manufacturing Manufacturing Information Control Problems in Information Control in Manufacturing Bergamo, June 11-13, Bergamo, Italy, Italy, JuneProblems 11-13, 2018 2018 Bergamo, Italy, June 11-13, 2018

ScienceDirect

IFAC PapersOnLine 51-11 (2018) 1610–1617

Key Key maturity maturity indicators indicators for for module module libraries libraries for for PLC-based PLC-based control control software software in in Key maturity indicators for module libraries for PLC-based control software in the domain of automated Production Systems the domain of automated Production Systems Key maturity indicators for module libraries for PLC-based control software in the domain of automated Production Systems Vogel-Heuser*.Production Juliane Fischer* the domainBirgit of automated Systems Birgit Vogel-Heuser*. Juliane Fischer*

Eva-Maria Neumann* Sebastian Diehm** Birgit Vogel-Heuser*. Vogel-Heuser*. Juliane Fischer* Fischer* Eva-Maria Neumann* Sebastian Diehm** Birgit Juliane  Birgit Vogel-Heuser*. Juliane Fischer* Eva-Maria Sebastian  Eva-Maria Neumann* Neumann* Sebastian Diehm** Diehm** Eva-Maria Neumann* Sebastian Diehm**  * Technical University of Munich, Institute of Automation and Systems, 85748 Garching near Munich, Germany  Information * Technical University of Munich, Institute of Automation and Information Systems, 85748 Garching near Munich, Germany ** Schneider Electric Automation GmbH, Schneiderplatz 1, 97828 Marktheidenfeld, Technical University University of Munich, Munich, Institute of Automation Automation and Information Information Systems, 85748 Garching GarchingGermany near Munich, Munich, Germany Germany ** Schneider Electric Automation GmbH, Schneiderplatz 1, 97828 Marktheidenfeld, Germany ** Technical of Institute of and Systems, 85748 near (e-mail: {vogel-heuser, juliane.fischer, eva-maria.neumann}@tum.de; [email protected]) * Technical University of Munich, Institute of Automation and Information Systems, 85748 GarchingGermany near Munich, Germany ** Schneider Schneider Electric Electric Automation GmbH, Schneiderplatz Schneiderplatz 1, 1, 97828 97828 Marktheidenfeld, Germany (e-mail: {vogel-heuser, juliane.fischer, eva-maria.neumann}@tum.de; [email protected]) ** Automation GmbH, Marktheidenfeld, ** Schneider Electric Automation GmbH, Schneiderplatz 1, 97828 Marktheidenfeld, Germany (e-mail: {vogel-heuser, eva-maria.neumann}@tum.de; (e-mail: {vogel-heuser, juliane.fischer, eva-maria.neumann}@tum.de; [email protected]) Abstract: As modulejuliane.fischer, libraries in PLC-based control application in [email protected]) automated Production Systems (aPS) (e-mail: {vogel-heuser, eva-maria.neumann}@tum.de; Abstract: As modulejuliane.fischer, libraries in PLC-based control application in [email protected]) automated Production Systems (aPS) are the keyAs to more efficient engineering, the qualityapplication maturity of these modules should be measurable. Abstract: libraries in automated Production Systems (aPS) are the keyAs to module more efficient thecontrol qualityapplication maturity ofin modules should be measurable. Abstract: module librariesengineering, in PLC-based PLC-based control inthese automated Production Systems (aPS) Such maturity indicators help to convince application engineers and start-up personnel to use existing Abstract: As module libraries in PLC-based control application in automated Production Systems (aPS) are the key to more efficient engineering, the quality maturity of these modules should be measurable. Such indicators helpengineering, to convince the application engineersof and start-up personnel to use existing are thematurity key to more efficient quality maturity these modules should be measurable. modules instead of re-inventing the wheel,the resulting inengineers huge savings of money and time. This paper are the key to more efficient engineering, quality maturity of these modules should be measurable. Such maturity indicators help to convince application and start-up personnel to use existing modules insteadindicators of re-inventing wheel,application resulting inengineers huge savings of money and time. This paper Such maturity help to the convince and start-up personnel to use existing proposes quality metrics for such module libraries and their visualization for thepersonnel domain of aPS. Such maturity help to module convince application and start-up use existing modules instead of the wheel, resulting in huge savings of and This paper proposes qualityindicators metrics for such libraries and their visualization formoney the domain oftoaPS. modules instead of re-inventing re-inventing the wheel, resulting inengineers huge savings of money and time. time. This paper modules instead of re-inventing the wheel, resulting in huge savings of money and time. This paper proposes quality metrics for such module libraries and their visualization for the domain of aPS. proposes quality metrics for such module libraries and their visualization for the domain of aPS. © 2018, IFAC (International Federation Automatic Control) Hosting by System Elsevier Engineering, Ltd. All rightsProduct reserved. Keywords: Enterprise System QualityofImprovement, Manufacturing and proposes quality metrics for such moduleImprovement, libraries and their visualization for theEngineering, domain of aPS. Keywords: Enterprise System Quality Manufacturing System Product and Process Oriented Approaches. Keywords: Enterprise System Quality Quality Improvement, Improvement, Manufacturing Manufacturing System System Engineering, Engineering, Product Product and and Process Oriented Approaches. Keywords: Enterprise System Keywords: Enterprise System Quality Improvement, Manufacturing System Engineering, Product and Process Oriented Oriented Approaches. Process Approaches.   Process Oriented Approaches. Unfortunately for such software specifications are rarely  Unfortunately for such software specifications are rarely 1. INTRODUCTION AND MOTIVATION available. 1. INTRODUCTION AND MOTIVATION  Unfortunately for available. Unfortunately for such such software software specifications specifications are are rarely rarely 1. INTRODUCTION AND MOTIVATION 1. INTRODUCTION AND MOTIVATION for such software specifications are rarely Software modularity is a prerequisite for flexible evolving Unfortunately available. INTRODUCTION AND MOTIVATION Software1. modularity is a prerequisite for flexible evolving available. available. Industry 4.0 compliantismachines and plants in the following Software modularity aa prerequisite for evolving Industry 4.0 compliantismachines and plants in the following Software modularity prerequisite for flexible flexible evolving referred to as automated Production Systems (aPS), see Software ismachines a prerequisite for flexible evolving Industry compliant and in following referred tomodularity as automated Production Systems see Industry 4.0 4.0 compliant machines and plants plants in the the(aPS), following Vogel-Heuser etautomated al. (2015, 2017). Theplants state of reuse, variant Industry 4.0 compliant machines and in the following referred to as Production Systems (aPS), see Vogel-Heuser al. (2015, 2017). The state of reuse, variant referred to asetautomated Production Systems (aPS), see and version management of control software modules in referred to as automated Production Systems (aPS), see Vogel-Heuser et al. (2015, 2017). The state of reuse, variant and version management control software modules in Vogel-Heuser et al. (2015, of 2017). The state of reuse, variant industry still shows a huge room for improvement. Also, the Vogel-Heuser et al. (2015, 2017). The state of reuse, variant and version management control software in industry still shows a huge of room for improvement. Also, the and version management of control software modules modules in usage ofstill version management tools and themodules usage of and management control software in industry shows huge of room for improvement. Also, the the usageversion ofstill version tools and the usage of industry shows aamanagement huge room for improvement. Also, modularization differ a lot within the involved engineering industry still shows a huge room for improvement. Also, the usage of version version management tools and the theengineering usage of of modularization differmanagement a lot within tools the involved usage of and usage disciplines aPS. usage of included version management and theengineering usage of modularization differin lot within within tools the involved involved engineering disciplines included in modularization differ aaaPS. lot the modularization differin lot within the involved engineering disciplines included disciplines included in aaPS. aPS. While version management is only used by default for disciplines included in aPS. is only used by default for While version management software engineering, about 60 % used of the interviewed While management by default softwareversion engineering, about is % used of the While version management is60only only by interviewed default for for companies use modularization for the three core disciplines While version management is only used by default for software engineering, about 60 % of the interviewed companiesengineering, use modularization coreinterviewed disciplines software about for 60 the % three of the software, electrical and about mechanical engineering. Assuming software engineering, 60 % of the interviewed companies use modularization for the three core disciplines software, electrical and mechanical Assuming companies use modularization for theengineering. three core disciplines that software is thefor most advanced in companies useengineering modularization theengineering. three corediscipline disciplines software, electrical and Assuming that software engineering is the most advanced discipline in software, electrical and mechanical mechanical engineering. Assuming the following the maturity of control modules gathered in Fig. 1. Workflow of library module development software, electrical and mechanical engineering. Assuming that software engineering engineering is of thecontrol most advanced advanced discipline in the following the maturityis modules discipline gathered in that software the most Fig. 1. Workflow of library module development libraries for further reuse is discussed being the prerequisite that software engineering the most advanced discipline in the following the maturity maturity of control being modules gathered in in Fig. 1. Workflow of library module development libraries for further reuse is of discussed the prerequisite the following the control modules gathered Fig. 1. Workflow of library module development Derived from different discussions with industrial experts for successful future applications in being amodules project, a specific the following the maturity control gathered in Derived libraries for further further reuse is of discussed the prerequisite prerequisite Fig. 1. Workflow of library module development from different discussions with industrial experts for successful future applications in being a project, a specific libraries for reuse is discussed the from machine and plant manufacturing as well as case machine or part of a plant. libraries forpart further is discussed the prerequisite from with experts for successful future applications in aa project, aa specific from machine and plantdiscussions manufacturing as well as case Derived from different different discussions with industrial industrial experts machine or of a reuse plant. for successful future applications in being project, specific Derived studies, Fig. 1 shows the workflow of library module from 1different withofindustrial experts for successful applications in a project, a specific Derived from and plant as well case machine or of studies, Fig. shows themanufacturing workflow module from machine machine and plantdiscussions manufacturing aslibrary well as as case machine or part part future of aa plant. plant. development. This includes module design by as module 2. orBENEFITS OF MATURITY METRICS FOR from machine and plant manufacturing as well case machine part of a plant. studies, Fig. 1 shows the workflow of library module development. This includes module design by studies, Fig. 1 shows the workflow of library module 2. BENEFITS OF MATURITY METRICS FOR designers, module application by application engineers and CONTROL SOFTWARE MODULE LIBRARIES studies, Fig. 1 shows the workflow of library module development. This includes module design by module 2. BENEFITS OF MATURITY METRICS FOR designers, module application by application engineers and development. This includes module design by module SOFTWARE MODULE LIBRARIES 2. CONTROL BENEFITS OF MATURITY METRICS FOR finally the start-up on-site where the modules are tested in the development. This includes module design by module 2. CONTROL BENEFITS OF MATURITY METRICS FOR designers, module on-site application bytheapplication application engineers and MODULE LIBRARIES finally the start-up whereby modules are tested in and the designers, module application engineers CONTROL SOFTWARE MODULE LIBRARIES In accordance with aSOFTWARE survey including more than 60 German real production environment. According to prior work, designers, module application by application engineers and CONTROL SOFTWARE MODULE LIBRARIES In accordance with a survey including more than 60 German real finallyproduction the start-up start-upenvironment. on-site where where the the modules to are prior tested work, in the the According finally the on-site modules are tested in companies from theadomain of aPS, themore release processes for module developers nowadays create, maintain and monitor In with survey including than 60 finallyproduction the start-upenvironment. on-site wherecreate, the modules are and tested in the companies from theadomain aPS, themore release for module In accordance accordance with survey of including thanprocesses 60 German German real production environment. According to prior work, developers nowadays maintain monitor real According to prior work, module libraries implemented in these companies showfora modules In accordance with adomain survey of including thanprocesses 60 German (cp. Fig. 1) nowadays and application engineers integrate them companies from the domain of aPS, themore release processes real production According tointegrate priormonitor work, module libraries implemented in these companies showfora modules companies from the aPS, the release module developers create, maintain and (cp. Fig. environment. 1) nowadays and application engineers them module developers create, maintain and monitor huge potential for improvement (Vogel-Heuser et al. (2017)). companies from the domain of aPS, the release processes for into projects, i.e. the design of new machines or new variants module libraries implemented in these companies companies show aa into module developers create, maintain and variants monitor huge potential for implemented improvement in (Vogel-Heuser et al. (2017)). module libraries these show modules (cp. 1) and application engineers them projects, i.e. the design of new machines orintegrate new modules (cp. Fig. Fig. 1) nowadays and application engineers integrate them Only in 26 % for of these companies, modules areettested by ana of module libraries implemented in these companies show existing machines, seeapplication Vogel-Heuser et al.orintegrate (2017). Up to huge potential improvement (Vogel-Heuser al. (2017)). (2017)). modules (cp. Fig. 1) and engineers them Only potential in 26 % for of these companies, modules areettested by an of huge improvement (Vogel-Heuser al. into projects, i.e. the design of new machines new variants existing machines, see Vogel-Heuser et al.or(2017). Up to into projects, i.e. the design of new machines new variants employee other than the module developer, which is huge potential for improvement (Vogel-Heuser et al. (2017)). now there is a lack of maturity indication for library modules Only in in 26 26 other % of of these these companies, modules are tested tested by an an into projects, theofdesign of new machines or(2017). new modules variants employee than companies, the module developer, which is now Only % modules are by of see et Up there ismachines, ai.e. lack maturity indication of existing existing machines, see Vogel-Heuser Vogel-Heuser etforal. al.library (2017). Up to to mandatory engineering in general andtested shows Only in 26 in %software of these companies, modules are byone an therefore application engineers and et start-up technicians employee other than the developer, which is of existing machines, see Vogel-Heuser al. (2017). Up to mandatory in software in general and shows one employee other than engineering the module module developer, which is and now there is a lack of maturity indication for library modules and therefore application engineers and start-up technicians now there is a lack of maturity indication for library modules of the challenges to assure quality of control software employee other than the module developer, which is now oftentherefore invent if they identify parts oftechnicians code they mandatory in software in and one there is new a application lackmodules of maturity indication for library modules of the challenges to engineering assure quality of control software mandatory in software engineering in general general and shows shows one and application engineers and start-up start-up oftentherefore invent new modules if they identify parts oftechnicians code they and engineers and modules inina software library. Also, monitoring such modules and mandatory engineering in general and shows one do not understand immediately. This leads to increased effort of the challenges to assure quality of control software and therefore application engineers and start-up technicians modules in a library. modules and often of the challenges to Also, assuremonitoring quality ofsuch control software often invent new modules modules if they they identify parts of code codeeffort they do not understand immediately. This leads to increased invent new if identify parts of they their evolution is mandatory. this paper software tosoftware realize of the challenges to Also, assureIn quality ofsuch control cost andnew decreased reuse. In this paper, we modules in monitoring modules and often invent modules if they identify parts of propose codeeffort theyaa their evolution is mandatory. In this paper software to realize modules in aa library. library. Also, monitoring such modules and and do not not understand immediately. This leads to increased increased effort cost and decreased reuse. In this paper, we propose do understand immediately. This leads to atheir functionality is in focus and safety critical software is and modules in a library. Also, monitoring such modules and metric for control software modules, more precisely Function evolution is isismandatory. mandatory. In this this papercritical software to realize realize do not understand immediately. This leads to increased effort a functionality in focus and safety software is and their evolution In paper software to cost and decreased reuse. In this paper, we propose metric forand control software modules, more precisely Functionaa and cost decreased reuse. In this paper, we propose exclude besidesisismandatory. emergency in mode ofsoftware operation. their evolution Instops this paper software to realize (FBs) of software IEC reuse. 61131-3. Inmore the following, threea functionality in focus focus and and safety critical is Blocks and cost and decreased In this paper, we propose besidesisemergency stops in mode ofsoftware operation. aaexclude functionality in safety critical is metric for control modules, precisely Function Blocks (FBs) of software IEC 61131-3. the precisely following, three metric for control modules,Inmore Function aexclude functionality is in focus and safety critical software is different maturity levels of control code library modules are exclude besides besides emergency emergency stops stops in in mode mode of of operation. operation. different metric for control software modules, more precisely Function Blocks (FBs) of IEC 61131-3. the following, three maturity levels of control In code library modules are Blocks (FBs) of IEC 61131-3. In the following, three exclude besides emergency stops in mode of operation. different Blocks (FBs) of levels IEC of 61131-3. In thelibrary following, three maturity control code modules are different maturity levels of control code library modules are 2405-8963 © IFAC (International Federation of Automatic Control) by Elsevier Ltd. All rights reserved. Copyright © 2018, 2018 IFAC 1660Hosting Copyright © 2018 IFAC 1660different maturity levels of control code library modules are Peer review under responsibility of International Federation of Automatic Control. Copyright © 2018 2018 IFAC IFAC 1660 10.1016/j.ifacol.2018.08.261 Copyright © 1660 Copyright © 2018 IFAC 1660

IFAC INCOM 2018 Bergamo, Italy, June 11-13, 2018

Birgit Vogel-Heuser et al. / IFAC PapersOnLine 51-11 (2018) 1610–1617

introduced. The maturity levels shall be visualized to the application software engineer, the on-site start-up technician and the module developer, who maintains and monitors all modules from the library (cp. Fig. 1): 1.) High maturity (indicated by green traffic light): In case the maturity of a module library is high, the application engineer can trust the module and rely on its proper functionality. Hence, he will be able and willing to reuse this module library instead of reinventing a new one or reusing and modifying an older one from his own old projects (cp. dashed lines in Fig. 1). Reuse of mature modules will reduce cost and increase quality. Also, the start-up staff will not consider changing the module if it is of high maturity, but ask for assistance from the designer in case of a missing or faulty functionality, thus starting an improvement process. 2.) Medium maturity (indicated by yellow traffic light): This informs the start-up staff that the module is already successfully implemented in some applications. Hence, they will not immediately reprogram the module on-site, but will consider adapting the existing program. However, they will only do so if the resulting effort is appropriate, otherwise they will rely on their own module library. 3.) Low maturity (indicated by red traffic light): Start-up staff will be reluctant to accept the module in case of problems occurring on-site and application engineers will be sceptic to use them because of the risk to induce faults by using immature modules. Most probably, both will try to reuse modules from their own libraries or develop new modules.

1611

independent basic modules, e.g. individual drives or sensors. Atomic basic modules finally are located on the most finegrained architectural level and refer to basic modules that cannot be decomposed further. Throughout all architecture levels, every module may consist of equally or more finegrained module types. 3.2 Classification of changes / evolution in PLC code According to Vogel-Heuser et al. (2014a), changes on FB level can be classified into eight categories C1 – C8 (cf. Fig. 2). C1 represents changes that occur by implementing a new FB. In case new software interfaces are added, these changes are classified to category C2. Category C3 comprises all changes that arise because of adaptions to the module implementation, whereas changes occurring by implementing a sub-module are classified to category C4. In case a FB is changed by deleting sub-modules, these changes are categorized into C5. Changes that occur by modifying the name of a variable are classified to C6. Category C7 comprises changes that are caused by the external preprocessing of input variables. Analogously, changes that occur by the introduction of an internal pre-processing of input variables are classified to C8.

These three cases demonstrate the potential benefit of such a module maturity indication. After discussing the state of the art in software modularity and metrics, the proposed maturity metric is introduced in section 4. 3.

STATE OF THE ART IN MATURE PLC-BASED CONTROL SOFTWARE MODULE EVOLUTION

The state of the art discusses four relevant aspects for module libraries for aPS. These are software architecture, classification of changes, PLC code analysis to analyse and visualize the code structure of legacy code and software metrics for module reuse in general software engineering.

Fig. 2. Extended classification of possible changes of a FB in IEC 61131-3 and comparison of the respective impacts IM on module maturity rated by industrial application experts

3.1 Software architecture of PLC applications

3.3 Code analysis for PLC code

As Maga et al. (2011) stated, software modules should be managed in a way appropriate to their level of granularity. To properly address such distinct levels of granularity, VogelHeuser et al. (2017) distinguished five architectural levels. This insight is backed by an analysis of the software architecture of several companies from aPS. Every plant module consists of at least one facility module, which represents machines or plant parts such as a press or a storage system. Each facility module in turn contains one or more application modules. Such application modules are application-specific parts that can be reused across various machines. Examples are material feeds or filling units. Application modules are composed of application-

Regarding the poor maturity of control software for aPS in industry proven by a questionnaire and code analysis of industrial legacy control code (cf. Vogel-Heuser et al. (2017)) supporting approaches are required. For an application of code analysis framework metrics like Halstead, Lines of Code or call graphs Feldmann et al. (2016) proposed Semantic Web technologies and used metrics like “FB complexity” and “FB call intensity”. Capitán et al. (2017) confirmed the applicability of Halstead program length and McCabe’s complexity to PLC languages. They identified the huge number of I/O variables typical for aPS software as a key reason why Kafura’s metrics are not appropriate to evaluate modularity. Metrics for maturity of aPS module libraries itself are missing. Zhabelova et al. (2015) introduced

1661

IFAC INCOM 2018 1612 Bergamo, Italy, June 11-13, 2018

Birgit Vogel-Heuser et al. / IFAC PapersOnLine 51-11 (2018) 1610–1617

a complexity metric for IEC 61499, but do not provide further metrics.

case of enlarged functionality, the second digit of the version number is incremented.

3.4 Code-based software quality metrics in general software engineering Dusink et al. (1995) introduced reuse dimensions for software components. Hristov et al. (2012) structured software reusability metrics into availability, documentation, complexity, quality, maintainability and adaptability. Quality metrics measure the number of bugs, the number of tests performed, availability of test cases and independent rating and certification. Deniz et al. (2014) introduced code-based quality metrics in industrial settings: the quality of software products is improved as reuse rates of the product increases. Fault-Proneness: the number of defects detected in components decreases as these components are reused in various products. The authors suggest adapting the metrics to the domains. In the following consequently a metric for control software modules is proposed focussing on the maturity of a module, which is a FB in IEC 61131-3.

Fig. 3. Maturity of control code FBs Less changes in later steps of software design:  FB x ,Operation   FB x , Start  up   FB x , Design

4.

CODE-BASED QUALITY METRICS FOR PLC CONTROL SOFTWARE MODULES

Based on the quality metrics introduced and the requirements introduced in section 2, a traffic light metaphor to indicate control software maturity is proposed based on the authors’ experience. At first, basic assignments for the changes ∆FBx of a control module FBx in IEC 61131-3 are defined considering its evolution in relation to the engineering life cycle, the level of the software architecture, the versions and the number of instantiations. Secondly, a first proposal of a measure for the change of a FB, ∆FBx, is introduced and subsequently evaluated knowing that this metric still requires further optimization.

(1)

The assumption of (1) is that changes to one specific FBx decrease as it advances in the software engineering life cycle. Most changes should occur during the Design phase in a systematic (re-)design process that also includes a test phase against a simulation or the real part of a machine. During the Start-up phase, fewer changes should occur compared to the Design phase, because only unexpected or unknown conditions on a customers’ site like environmental conditions due to a different mechanical behavior in a humid or cold environment need adaptation. Finally, during the Operation phase, when the customer already operates the machine, the number of changes is required to be at its minimum. Less changes on lower levels of software hierarchy:

4.1 Four underlying maturity metrics

 FB x ,level   FB x ,level 1   FB x ,level  2

In this section, four metrics referring to the maturity of FBs are introduced addressing the phase of the life cycle, level of software architecture, version number and number of instantiations. The maturity of control code FBs increases with its version number (cp. Fig 3), as a version indicates an evolution step of the respective FB. Additionally, we assign different thresholds to indicate maturities, which may need adaptation during the industrial application process and may be chosen by each company. The green traffic light is assigned to a value higher than 90 % (Fig. 3) and the yellow traffic light in between 75 % and 90 %. Below 75 %, the red traffic light is assigned. Furthermore, we assume that maturity is depending on the architectural level of the software to which a FB belongs to and that more mature FBs will change less frequently and with fewer changes related to their number of instantiations (cp. Deniz et al. (2014)). To also address evolution steps that include newly introduced or enlarged functionality one common rule in industry is implicitly used (cp. Fig. 3, black curve): Whenever a new functionality is introduced, the first digit of the version number indicating major changes is increased by one, and in

(2)

Referring to the typical five levels of software architecture identified by Vogel-Heuser et al. (2015), it is assumed that the maturity of a FBx,level-2 from a lower level of the software architecture is higher than the one of a higher level FBx,level-1. This is because lower level FBs can be standardized more easily due to their lower application dependencies. This lower dependency on a specific application also leads to them being used more frequently and consequently errors can be identified quicker (see (2)). The index level indicates the considered architecture level whereas the indices level-1 and level-2 symbolize the first respectively the second lower level. Examples for FBs on the lowest level are the handling of an analogue input or the control of a simple drive. Modules with higher version number show less changes:  FB v 1   FB v   FB v 1

(3)

The third metric addresses the versions of a FB. It is assumed that changes decrease with a rising version number indicating

1662

IFAC INCOM 2018 Bergamo, Italy, June 11-13, 2018

Birgit Vogel-Heuser et al. / IFAC PapersOnLine 51-11 (2018) 1610–1617

a higher maturity level of the FB as implied in (3). In this context, v indicates the current version of the FB. The frequency of new versions and the number of changes ∆FB are expected to decrease with the FB’s number of instances q, too (4). The more mature the FB, the better it can be used, i.e. the FB can be reused for other applications by configuration instead of adaptation, with the latter resulting in a new major version (incremented 1st digit, cp. Fig. 3). More instances lead to higher maturity: FBx  FBzqx  qz  0

(4)

L IB _ M M at F B x  L IB _ M M at F B z

4.2 Proposed application of the metrics to diagnose anomalies

to parametrization parameters or the number of calls inside the FB implementation are included in (5). For a graphical representation of these changes refer to Fig. 2: The third summand of (5) e.g. corresponds to categories C2 (adding of interfaces) and C5 (deleting of interfaces). Moreover, the fifth summand can be assigned to category C3 (adapting the module implementation), the sixth summand to C4 (implementation of sub-modules). Furthermore, category C7, i.e. the external pre-processing of input variables, is represented by the seventh summand whereas the eighth summand refers to category C6 (modified variable names). Analogously to the first summand, the denominator represents the bigger one of the two respective values before and after the change, for the following summands. LIB _ M

A

| | | |

4.3 Maturity metrics for evolving FBs in a module library |

In the following, a metric considering the different changes according to prior work of Vogel-Heuser et al. (2014) (cp. Fig. 2) is introduced in order to allow the estimation of the impact of a change made to a FB. By the help of (5), the Library Module Maturity of FBx (LIB_MMatFBx) can be calculated assuming that the maturity is higher if the number of changes is lower. As introduced in section 4.1 Fig. 3, we assume the behaviour of maturity to approach 100 % similar to a measurement curve, but oversimplify it to asymptotic. Overall, eight types of changes were identified due to the classification and are consequently included (cp. (5)). The first part of LIB_MMatFBx ((5), second line) focuses on the changes made to the number of hardware inputs and outputs as well as the changes of the number of counter interfaces. In this context, nA represents the number of changed analogue inputs IA, nD specifies the number of changed digital inputs ID, and the number of changed counter inputs IC is indicated by nC. Analogously, the respective changes of the outputs OA, OD, and OC are represented by the variables mA, mD, and mc. Moreover, the respective numbers of changes are weighted with a specific value k. To rate the changes made and to quantify their impact on the interface of the considered FB, the calculated change is divided by the maximum of the weighted total number of interfaces prior to or after making the change. In this context, the variable IA in the divisor of (5) represents the total maximal number of analogue inputs either before or after the considered change, depending on which one is bigger. The variables ID, IC, OA, OD, and OC are used respectively to represent the largest total number of the according inputs/outputs prior to or after the change. Additionally, seven further possible changes such as used variables (including internal variables), interface changes due

Ma t

( | |nI kk A

For the four assignments introduced in this paper, code analyses should be conducted regularly to monitor changes on the number and severity of changes in the three categories. In case the evolved modules do not fulfil the metric’s assumptions, a warning (traffic light) should be visualized for the module developer on the one hand and the application engineer using the modules on the other hand.

1613

1

FB x  1 

n

n

   FB x , y 1  y 1

1



n

|  | n D  k DI |  | n C  k CI |  | m A  k AO |  | m D  k DO |  | m C  k CO |

AI AI

|  | I D  k DI |  | I C  k CI |  | O A  k AO |  | O D  k DO |  | O C  k CO |

Δvariables

 variables Δadaption

||

Δinterface

 interface

changes

of module implementa tion

 module imp

Δcalls

 calls

|

|

lementatio ns

Δadding/de leting of sub  modules

 sub

||

elements

 modules

|

Δadding/de leting of preprocess ing of inp uts extern al



|

preprocess ing of inp uts extern al

 changed designatio ns

 variables

|

)

(5)

With: n  number of  FB   FB  0

(6)

Generally, the following relation (7) between the extent of the change and the resulting value for LIB_MMatFBx is valid:

LIB _ M

Ma t

FB x

if nothing is changed 1   0 if everything is changed   0   1 in case of changes 

(7)

As discussed in section 3.2., the degree of impact of the changes C1 to C8 differs, which should be addressed by an impact factor in each term of (5) to adjust the rating of the terms in future work. Additionally, there is a potential interference of the different parts of (5), for example, adding a sub-module and pre-processing of inputs could be initiated by the same change. 5.

APPLICATION OF THE PROPOSED METRICS

This section consists of two subsections. First, an application example is introduced. Subsequently, the proposed metric is applied to this application example in the second subsection. 5.1 Introduction of the application example In this section, the “extended Pick and Place Unit” (xPPU) is introduced as an application example. The xPPU represents a lab size demonstrator in the SPP 1593 for production

1663

IFAC INCOM 2018 1614 Bergamo, Italy, June 11-13, 2018

Birgit Vogel-Heuser et al. / IFAC PapersOnLine 51-11 (2018) 1610–1617

automation. The xPPU has evolved over more than 20 evolution steps assuming that a machine and plant manufacturer would evolve such a machine iteratively (cf. Vogel-Heuser et al. (2015)). It consists of a stack that provides the work pieces (WP), a crane for transportation purposes, a stamping unit, several conveyors and ejectors to sort the various types of WP into slides according to the selected sorting strategy. In this paper, we focus on the evolution of the conveyor (cf. Fig. 4) and its corresponding FB in the module library as a recent study revealed that five conveying modules cover 95.6 % of all modules used in Material Flow Systems (cf. Aicher (2018)).

of a reusable and universal library module for a conveyor. The advanced FB (Fig. 5, bottom), results after the original version is adapted and optimized.

5.2 Quantitative evaluation by application to a lab plant In the following, (5) is applied to the evolution of the FB of the xPPU’s conveyor assuming that a new machine is developed introducing conveyor belts for the first time. The considered specific version of the conveyor module corresponds to the conveyor in evolution scenario 10 (cf. Vogel-Heuser et al. (2014b)).

Fig. 5. Two possible conveyor FBs. Top: Original universal FB, bottom: optimized universal FB Next, the declaration of the in- and outputs of the optimized universal module FB (cf. Fig. 5, bottom) are introduced. FUNCTION_BLOCK FB_Conveyor_Sens_B_M_E_Slide

Fig. 4. Configuration and FB of the conveyor in scenario 10 equipped with three slides, two ejectors and four sensors In this scenario, the conveyor is equipped with three slides, of which two are combined with an ejector. Additionally, the conveyor comprises two initial sensors at the beginning and at the end of the conveyor line to start or to stop the belt in case the respective sensor is triggered. Two further sensors are located at the ejector-slide-pairs to trigger the sorting action (see Fig. 4, top). Initially, a FB specifically designed to control this variant of the conveyor is developed as depicted in Fig. 4, bottom. In subsequent evolution scenarios, additional conveyors combined with other units in different configurations are added to the xPPU. Due to this and in order to present the application of (5), a more advanced, universal version of the conveyor is used which contains an arbitrary number of additional sensors, ejectors, and slides (in each case 1-5 additional units). For the application of (5), the FB depicted in Fig. 5, top, is used as the next version of the specific conveyor FB. It represents an initial draft in the development

VAR_INPUT //Hardware instances fb_engine_conveyor :FB_DC_Engine; t_evacuate_time :TIME := T#5S; a_Ejector :ARRAY [1..5(*i_Number_of_Ejector*)] OF FB_Ejector; i_Number_of_Ejector :USINT := 5; fb_Sensor_Beginning :FB_Binary_Sensor; fb_Sensor_End :FB_Binary_Sensor; t_overrun_time :TIME := T#1S; a_Sensor :ARRAY [1..5] OF FB_Binary_Sensor; a_Slide : ARRAY [1..5] OF FB_Slide; i_Number_of_Slide :USINT := 5; END_VAR VAR_OUTPUT //Software Output b_initialized :BOOL := FALSE; b_WP_passed_End :BOOL := FALSE; b_WP_started :BOOL := FALSE; END_VAR

The arbitrary number of sensors, ejectors, and slides is implemented by the usage of arrays (highlighted in yellow above). The number of variables in each array may vary between one and five. Consequently, the FB can be used for different hardware configurations with a varying number of sensors, ejectors, and slides. The universal versions of the FB use the object-oriented (OO) extension of the IEC 61131-3 standard, cf. Werner (2009), and are stored within a module library that comprises two

1664

IFAC INCOM 2018 Bergamo, Italy, June 11-13, 2018

Birgit Vogel-Heuser et al. / IFAC PapersOnLine 51-11 (2018) 1610–1617

hierarchy levels: a lower level for control modules, e.g. cylinders or sensors, and a higher one for more complex equipment modules like e.g. the conveyor in which the control modules are reused. For creating an application program, mainly equipment module FBs containing calls to control modules are instantiated. However, also control module FBs can be used directly in the program. Moreover, the lower hierarchy level contains FBs, which do not have an implementation part but only provide functionalities in the form of actions, so-called ACT_FBs. The ACT_FBs used in the considered example are the FB_DC_Engine (drive), the FB_Ejector, the FB_Slide and the FB_Binary_Sensor. In addition to the modules for hardware control, the library contains FBs used for alarm handling or state control, which have to be called in the main program and operate on a plantwide basis on top level. For example, if an operator switches the operation mode to automatic, the state control FB verifies if all modules have been initialized correctly before setting the overall operation mode to automatic. Furthermore, there is a FB dedicated to the overall operation sequence in automatic mode and another FB for containing the steps to be performed when re-initializing the plant after an emergency stop. In these FBs the actions provided by control and equipment modules are used for programming the required sequences. In the following, the implementation part of the conveyor’s FB is presented.

1615

they are operational. Additionally, the conveyor’s drive is started and operated for a parameterizable time. If the emergency state is active, the conveyor’s drive stops immediately. If the current state is automatic mode, no further code is executed in the main implementation part of the conveyor FB. Instead, the actions of the FB, such as starting the conveyor’s drive if a WP is detected by the sensor installed at the front of the conveyor, are used to operate the conveyor’s hardware. These actions are called in the FB containing the overall operation sequence of the plant. Comparing the initial, specific version of FB_Conveyor controlling the configuration depicted in Fig. 4 with the first draft of the universal conveyor FB (Fig. 5, top), various changes are identified. In the following, the introduced metrics are used to quantify these changes. Regarding the changes in internal variables, applying (5) gives 0 as the number of variables did not change. On the other hand, several interface changes could be identified: The original FB comprises 14 interfaces (cf. Fig. 4, bottom) whereas the adapted FB has 35 interface elements. Consequently, the application of (5) results in:  FB 1 . x ,1  |

 interface changes

| |

 interface elements

14  35

| 0 . 60

(8)

35

Furthermore, the module implementation was changed and applying (5) gives:

//Slide FOR j := 1 TO i_Number_of_Slide BY 1 DO a_Slide[j](); END_FOR //Initialization IF b_Initialization AND NOT b_emergency_stop AND NOT b_automatic_mode THEN //reset to default //evacuate conveyor FOR i := 1 TO i_Number_of_Ejector BY 1 DO a_Ejector[i].fb_Ejector.ACT_Retract_monostable_ cylinder(); END_FOR timer1(IN := b_Initialization, PT := t_evacuate_time); IF NOT timer1.Q AND NOT b_timer_true THEN fb_engine_conveyor.ACT_Turn_Engine_Clockwise(); b_timer_true := TRUE; END_IF //stop evacuating conveyor IF timer1.Q THEN b_timer_true := FALSE; fb_engine_conveyor.ACT_Stop_Engine(); b_initialized := TRUE; END_IF END_IF //Emergency Stop IF b_emergency_stop THEN fb_engine_conveyor.ACT_Stop_Engine(); b_initialized := FALSE; END_IF

The implementation part starts with calling the basic module(s) FB_Slide, which have been instantiated in the declaration part of the conveyor FB, in a for-loop according to the parameter i_Number_of_Slide. Afterwards, depending on the currently selected top-level state, which is retrieved from the corresponding global variables, either an initialization procedure or an emergency stop is carried out in the main implementation part. In case of an initialization state, all ejectors are operated once in order to ensure that

 FB1. x ,2  |

 M odule im plem entations

 M odule im plem entations

| |

63  107

| 0.41

(9)

107

It is apparent that the resulting value is rather high which is due to the great number of implementation changes: Only the implementation of the initialization and of the emergency stop staid unchanged whereas the specific implementation of the automatic mode is deleted and replaced by universally usable and combinable sub-actions. In total, applying (5) gives the following result under consideration that only two of the initial 8 summands occurred: L IB _ M M at F B1. x  1  1

1 2

1 2

2

   F B1. x , y  y 1

 (  F B1. x ,1   F B1. x , 2 )  1 

1

(10)

 (0.60  0.41)  0.49

2

In the next step, the first version of the universal FB for the conveyor (Fig. 5, top) is further optimized (Fig. 5, bottom) and again, (5) is applied to quantify the changes. When it comes to the calculation of the changed variables, it is observed that the number of internal variables used for the optimized version changed: In the original version, 8 internal variables were used whereas there are 12 internal variables used in the optimized version. Consequently, (5) can be applied as follows:  FB 2 . x ,1  |

 variables

 variables

| |

12  8

| 0 . 33

(11)

12

In Fig. 5, top, it is depicted how the changes made to the considered FB can be classified with regard to the extended

1665

IFAC INCOM 2018 1616 Bergamo, Italy, June 11-13, 2018

Birgit Vogel-Heuser et al. / IFAC PapersOnLine 51-11 (2018) 1610–1617

categories from Fig. 2, i.e. categories C2, C5, C6, and C7. Referring to categories C2 and C5, i.e. the addition/deleting of software interfaces, it is apparent that the interfaces assigned to C5 in Fig. 5, top, were deleted to create an optimized FB. On the other hand, new interfaces were added (cf. C2). This leads to a total amount of 13 interfaces in the adapted version and 35 interfaces in the original version. Consequently, (5) can be applied as follows:  interface changes

 FB 2 . x , 2  |

 interface

| |

elements

13  35

(12)

| 0 . 63

35

As the in- as well as the outputs change (C3), the implementation of the FB also has to be adapted (cf. Fig. 6). For the appliance of (5), the lines of code (LOC) are counted: The original FB implementation comprises 19 LOC and 15 of them were adapted, which means that they were either added, removed or edited. Consequently, the appliance of (5) can be continued as follows:  FB 2 . x , 3  |

 Module implementa tions

 Module

| |

implementa tions

19  15

| 0 . 21

(13)

Fig. 7. Implementation of sub-modules Moreover, it is apparent in Fig. 5 that the designation of two variables was changed as another data type is used which can be assigned to category C6 in Fig. 2. Consequently, (5) can be continued as follows:

19 ΔFB

2. x ,5

|

ΔChanged d esignation s



variables

| |

2

(15)

| 0 . 05

43

In addition, the original universal FB was optimized by externally pre-processing input variables (cf. C7 in Fig. 2):

Fig. 8. Illustration of the applied pre-processing for the application example The input variables for the ejectors, sensors, and slides (5 variables each) are gathered within a corresponding array. Consequently, only one software interface is needed instead of five (cp. Fig. 8). In total, there are 15 variables for the original FB that are pre-processed in the optimized FB by three arrays. As a result, (5) can be continued as (16):

Fig. 6. Example for a change of module implementation. For this excerpt, the total amount of changed LOC is 4 (3 LOC removed, 1 LOC added) Furthermore, the original FB is optimized by “outsourcing” specific sub-modules in the form of ACT_FBs as depicted in Fig. 7 (cf. category C4 in Fig. 2). Within the original FB, seven sub-modules are implemented, i.e. one for the initialization, one for the emergency stop, and five submodules representing additional functionalities of the FB. In the optimized version, only the sub-modules for the initialization and the emergency stop are implemented within the FB whereas the additional functionalities are encapsulated using ACT_FBs. In Fig. 7, these changes are illustrated for three exemplary functionalities. In total, there are seven submodules implemented in the original FB and only two in the optimized version. As a result, (5) can be continued as follows:  FB 2 . x , 4  |

ΔAdding/De leting of sub  modules

 sub

 modules

| |

27 7

| 0 . 71

(14)

ΔFB

|

2. x ,6

3  15

|

Δadding/de leting of pre  processed



pre  processed

variables

|

variables

(16)

| 0 . 80

15

From inserting all interim results into (5) follows (17): LIB _ M 1

1 6

1

1

Ma t

FB 2 . x  1 

1 6

6

   FB 2 . x , y  y 1

(17)

 (  FB 2 . x ,1   FB 2 . x , 2   FB 2 . x , 3   FB 2 . x , 4   FB 2 . x , 5   FB 2 . x , 6 )   ( 0 . 33  0 . 63  0 . 21  0 . 71  0 . 05  0 . 80 )  0 . 54

6

As the maturity is below 0.75, the red traffic light represents the maturity following the assignment in Fig. 3 accordingly. Furthermore, it can be observed that the value calculated in (17) is higher than the result from (10) which indicates a higher maturity of the optimized universal FB (cf. Fig. 5, bottom) compared to the initial universal FB (cf. Fig. 5, top).

1666

IFAC INCOM 2018 Bergamo, Italy, June 11-13, 2018

Birgit Vogel-Heuser et al. / IFAC PapersOnLine 51-11 (2018) 1610–1617

The different scale of the factors underlines the need of adjustment factors as proposed by experts (cp. Sec. 4.3). 6.

EVALUATION

The proposed metrics are at first evaluated qualitatively by industrial experts and next weaknesses and lessons learned from the exemplary application of the metric are discussed.

1617

development like test cases, documentation, ease of usage, time to use and time to configure a module should be investigated. All aspects will be addressed in future work knowing that it will be challenging to access real, representative values from industrial companies. Therefore, most probably at first internal module libraries of automation library suppliers may be analyzed using logs in version management tools like subversion. REFERENCES

6.1 Qualitative evaluation by industrial experts The proposed assignments and metrics were introduced in three different sessions to four industrial experts from control software in aPS: one from an automation supplier and three from two machine and plant manufacturing companies, all of them developing software modules for more than a decade. They all agreed on the exponential behaviour (Fig. 3) as well as on (1), (2), (4) and the basic ideas of (3), (5) and (7). Regarding (4), it was discussed whether different instantiations need to be differentiated in instantiations in the same context or in instantiations in other contexts. The latter would be more challenging and consequently higher values should be assigned. Two experts indicated that it might be difficult to identify in (2) whether a functionality has been enriched or just evolved. In case a functionality is enriched (2) might not be true. The terms of (5) may need refinement as already introduced (interference), but the rationale was accepted by all of them. 6.2 Weaknesses and lessons learned from the application example The applicability of the metrics (5) has been demonstrated for a simple conveyor as a highly representative, often implemented FB. As only one huge change was analyzed instead of different smaller ones, further evaluations are necessary examining different evolutions steps of a FB. The introduced change is fundamental because it includes more sophisticated concepts like OO with arrays and therefore a redesign including more functionality instead of a small adjustment (cp. Sec. 5.4). Furthermore, the optimized version of the universal FB has a higher maturity than the initial version (cf. Fig. 5, (10) and (17)), which indicates that (3) is correct, however additional applications of (5) are required to validate it. Nevertheless, some challenges and weaknesses were identified, too: All eight change types are evaluated without any prioritization, which needs further discussion as they are of different complexity and severity and include interference. 7. CONCLUSIONS AND OUTLOOK The proposed assignments and metrics for module libraries were proven as a first useful measure for code-based maturity of control modules. Still they need refinement regarding interference and impact adjustment factors. Further evaluation is required at first with a simple application example with different evolution steps best without adding new functionalities and secondly in real industrial settings. Additionally, other factors from general software

Aicher, T. (2018). Automatic backwards compatibility of automated material flow software. Sierke Verlag, Göttingen, Germany. ISBN: 978-3-86844-952-5. Capitán, L., Vogel-Heuser, B. (2017). Metrics for Software Quality in automated Production Systems as an indicator for Technical Debt. IEEE CASE, Xi'an, China. Deniz, B., Bilgen, S. (2014). An Empirical Study of Software Reuse and Quality in an Industrial Setting. Computational Science and Its Applications, pp. 508523. Dusink, L., van Katwijk, J. (1995). Reuse Dimensions. In: ACM SIGSOFT Software Engineering Notes, pp. 137149, ACM. Feldmann, S., Hauer, F., Ulewicz, S., Vogel-Heuser, B. (2016). Analysis Framework for Evaluating PLC Software: An Application of Semantic Web Technologies. IEEE ISIE, pp. Santa Clara, USA. Hristov, D., Hummel, O., Huq, M., Janjic, W. (2012). Structuring Software Reusability Metrics for Component-Based Software Development. ICSEA, Lisbon, Portugal. Maga, C., Jazdi, N., Göhner, P. (2011). Requirements on engineering tools for increasing reuse in industrial automation. IEEE ETFA, Toulouse, France. Vogel-Heuser, B., Folmer, J., Legat, C. (2014a). Anforderungen an die Softwareevolution in der Automatisierung des Maschinen- und Anlagenbaus. Automatisierungstechnik (at), vol. 62(3), pp. 163-174. Vogel-Heuser, B., Legat, C., Folmer J., Feldmann S. (2014b). Researching Evolution in Industrial Plant Automation: Scenarios and Documentation of the Pick and Place Unit. Munich. Germany: mediaTUM. Vogel-Heuser, B., Fay, A., Schaefer, I., Tichy, M. (2015). Evolution of software in automated production systems: Challenges and research directions. JSS, vol. 110, pp. 5484. Vogel-Heuser, B., Fischer, J., Feldmann, S., Ulewicz, S., Rösch, S. (2017). Modularity and Architecture of PLCbased Software for Automated Production Systems: An analysis in industrial companies. JSS, vol. 131, pp. 3562. Werner, B. (2009). Object-oriented extensions for IEC 61131-3. IEEE Industrial Electronics Magazine, vol. 3. Zhabelova, G., Vyatkin, V. (2015). Towards software metrics for evaluating quality of IEC 61499 automation software. IEEE ETFA, Luxembourg, Luxembourg.

1667