Modularity and architecture of PLC-based software for automated

production Systems: An analysis in industrial companies

1. Introduction and Motivation

2. SWAT4aPS concept
3. SWAT4aPS hypothesis
4. Selected results
5. Overall maturities
6. SWAT4aPS+ and Outlook

Univ.-Prof. Dr.-Ing. Birgit Vogel-Heuser

SE 2018, Universität Ulm
Ordinaria, full professor, head of institute
March 8th, 2018
Automation and Information Systems (AIS)
Department of Mechanical Engineering,
Technical University Munich
www.ais.mw.tum.de; [email protected]

B. Vogel-Heuser, J. Fischer, S. Feldmann, S. Ulewicz and S. Rösch. "Modularity and Architecture of PLC-based Software for
Automated Production Systems: An analysis in industrial companies", Journal of Systems and Software (JSS), vol. 131, pp.
35-62, May 2017.

1
Lehrstuhl AIS
Maschinenwesen Technical Constraints of aPS and Motivation
Technical constraints of automated Production
Systems (aPS):
− Hard real-time requirements, cyclic
behavior (1µs – 1s), and
proprietary hardware (PLC). Source: Siemens AG Source: Bayer AG, Leverkusen

− Online change is mandatory Technical CPU (platform)

− Domain specific programming language system (context)

Sensor signals
(IEC 61131-3) Inputs

Technical
20- 50 Years Process PLC-Code Process
Mechanics (Context)
(context) Execution Data
10 - 15 Years Automation hardware incl.
Electric (Platform)
Development 1,5
Software
and Design Years Actuator signals
Outputs

Sequential Ladder Function Block

Operation Automation
10 -13 Years Function Chart Diagram Diagram
IEC 61131-3
Commissioning Commissioning after
Entire System Sensors / Actuators Re-Engineering . Var1 Var2 Var3 OUT Var1
.
8 -12 Year . Var2 &
Microcontroller Var5 Var4 Var3 >=
Step1 1 OUT
3 - 5 Years Var4
Transition 1 &
HMI
Step2
Structured Var5
1,5 Years
Instruction List

© AIS
Chips
Transition 2 Text LDN Var1
1,5 Years Step3 OUT:= ANDN Var 2
Transition 3 (Var1 & Var2 & Var3) OR ANDN Var3
. (Var4 & Var5) ST OUT
Life Cycle .
.

Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 2

 Software Maturity for aPS (SWMAT4aPS)-Benchmark process
Lehrstuhl AIS
Maschinenwesen to identify strengths and weaknesses in software modularity

Preparation Experimentation Reporting

Categorization of
16 questionnaire Icon fig. 2 companies
results
expert expert • library and platform
interviews workshops
pre-processing/ providers (1 and 2)
Questionnaire (Q)

consistency checks
• machine suppliers
questionnaire

modularity
iteratively
scoring
criteria
2 (3–14)
visions normalization • plant suppliers
companies weaknesses/
(15–16)
comparison to
strengths average 1

proof
Expert use case
analysis (company)
3
Expert analysis (E)

draft code/ 1st workshop

electrical/electronic qualitative
analysis code analysis results 4
2nd workshop Icon profile line

draft code analysis

measures Modularity
assessment

© AIS
16 world-leading companies in machine and plant manufacturing including four case studies

Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 3

Lehrstuhl AIS
Maschinenwesen
Research questions and hypotheses
Research Questions Related Hypotheses Proof
Does the questionnaire deliver Questionnaire delivers valid results (H1.1) Q&E
valid results to identify Maturity level: Platform suppliers > Machine suppliers > Plant manufacturers
weaknesses in gaining software (H1.2) Q
modularity of aPS? (RQ1)

Do the three different sub- Maturity level differ among MMOD, MTEST, MOP. (H2)
maturity levels deliver further
insights compared to one general Q
maturity level? (RQ2)

What are the most significant Universally low maturity levels arise in the different phases, indicating possible
weaknesses in software maturity causes or prerequisites for weaknesses in software maturity. (H3.1) Q
in aPS and in which phase do
High MMOD AND high MTEST  high MOP.
they occur and what are possible
A proper engineering process eases and shortens start-up, operation and Q
causes / reasons / prerequisites?
maintenance. (H3.2)
(RQ3)
Different release procedures for SW libraries due to on-site changes (H3.3) Q
Weaknesses in the tool chain support can be identified for selected aspects
(H3.4). Q

Module libraries, release procedure, version management and change tracking are
prerequisites for all ways of reuse (H3.5). Q

SW complexity  low MMOD AND low MOP . (H3.6) Q

Does the detailed expert Expert analysis delivers additional insights (H4.1). E
analysis deliver additional Different approaches for code configuration can be assigned to different
insights into the weaknesses of governance levels. (H4.2) E
software maturity? (RQ4)
(call graphs enable insight into control SW’s structure. (H4.3)

© AIS
E
Decomposability, composability, understandability and protection enable high
governance level  mature SW architecture & code graph  higher MMOD. (H4.4) Q&E

Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 4

Lehrstuhl AIS
Maschinenwesen
Validation of SWMAT4aPS (RQ1)

H1.1: The questionnaire delivers valid results in

accordance with the detailed expert analysis of four
selected companies. MTEST Platform

Machine
H1.2: Platform suppliers reach higher maturity
values than machine suppliers than plant
manufacturers.

MMOD
MOP
High scores
Interdependencies of maturity levels (* mean value)

Low scores
Platform Machine Plant
- Need more samples High scores Low scores

© AIS
Maturity levels of case studies compared to the machine
<Overview of maturity levels of companies> manufacturing companies mean
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 5
Lehrstuhl AIS Most significant weaknesses in software maturity phase do
Maschinenwesen
they occur, possible causes / reasons / prerequisites?

H3.3: Due to necessity of on-site changes in plant manufacturing, machine and plant
manufacturers follow different release procedures for software libraries.

© AIS
Release procedure (workflow) of library element in machine (a) vs. plant manufacturing industry (b)

Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 6

Lehrstuhl AIS Most significant weaknesses in software maturity phase do
Maschinenwesen
they occur, possible causes / reasons / prerequisites?

H3.4: Weaknesses in the tool chain support (mean value machine manufacturing
companies) can be identified for selected aspects, e.g. continuous integration, code
generation or version management.

© AIS
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 7
Lehrstuhl AIS
Maschinenwesen Prerequisites of Reuse
H3.5: Appropriate module libraries, release procedure of library components, version
management and change tracking are prerequisites for all ways of reuse.

• Correlation analysis of an interaction variable’s impact on two reuse indicators

• Additive interaction variable includes four questions from the questionnaire
– use of library components
– release procedure of these library components
– used version management tool
– change tracking of versions
• Considered ways of reuse: code generation and configuration

Table I. Correlations with Interaction Variable for Questionnaire Items # 23, # 24, # 26, # 27
Influencing Items # 28 and # 30

interaction
(# 28) (# 30)
variable
interaction variable 1.000 .739** .520*
(question # 28) code
.739** 1.000 .846**
generation from tools
(question # 30) code
.520* .846** 1.000
configuration (templates)

© AIS
**. Correlation is significant at the 0.01 level (2-tailed).
*. Correlation is significant at the 0.05 level (2-tailed).

Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 8

Lehrstuhl AIS
Maschinenwesen
Results of Expert Analysis

H4.2: Different approaches for code configuration exist in industry, that can be assigned to
different governance levels.

Template-based configuration procedure in case study

Parameter-based configuration procedure in case study D

© AIS
Prof. Dr.-Ing. Birgit Vogel-Heuser | Lehrstuhl für Automatisierung und Informationssysteme | 4 July 2017 9
Lehrstuhl AIS
Maschinenwesen
Prerequisites of Modularity Maturity MMOD
H4.4: The better the criteria
decomposability, composability,
understandability and protection are
fulfilled, the higher the governance level,
the more mature the software
architecture level as well as the code
graph, and the higher the modularity
maturity (MMOD).
Partially true

Call graphs generated for the analysis of case study A, B and C

Frequent cross connecting calls Strict tree structure

© AIS
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018
Lehrstuhl AIS
Maschinenwesen
Research questions and hypotheses results
Research Questions Related Hypotheses Proof Results
Does the questionnaire deliver Questionnaire delivers valid results (H1.1) Q&E
valid results to identify Maturity level: Platform suppliers > Machine suppliers > Plant
weaknesses in gaining software manufacturers (H1.2) Q
modularity of aPS? (RQ1)

Do the three different sub- Maturity level differ among MMOD, MTEST, MOP. (H2)
maturity levels deliver further
insights compared to one Q
general maturity level? (RQ2)

What are the most significant Universally low maturity levels arise in the different phases, indicating
weaknesses in software possible causes or prerequisites for weaknesses in software maturity. (H3.1) Q
maturity in aPS and in which High MMOD AND high MTEST  high MOP.
phase do they occur and what A proper engineering process eases and shortens start-up, operation and Q
are possible causes / reasons / maintenance. (H3.2)
prerequisites? (RQ3)
Different release procedures for SW libraries due to on-site changes (H3.3) Q
Weaknesses in the tool chain support can be identified for selected aspects
(H3.4). Q

Module libraries, release procedure, version management and change

tracking are prerequisites for all ways of reuse (H3.5). Q

SW complexity  low MMOD AND low MOP . (H3.6) Q

Does the detailed expert Expert analysis delivers additional insights (H4.1). E
analysis deliver additional Different approaches for code configuration can be assigned to different
insights into the weaknesses governance levels. (H4.2) E
of software maturity? (RQ4)
(call graphs enable insight into control SW’s structure. (H4.3) E

© AIS
Decomposability, composability, understandability and protection enable high
governance level  mature SW architecture & code graph  higher MMOD. Q&E
(H4.4)

Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 11

 Current status of software development in industrial practice
Lehrstuhl AIS
Maschinenwesen SWMAT4aPS+
Evaluation of participants who answered the question
„How are your control software projects on average
made up?”
with > 50% machine-specific code:
usage of IEC 61131-3 IL
interfaces implemented as data
exchange across global variables
Team Foundation Server as
Version Management Tool
source code hand-over to the
customer
n-axis-positioning rated as critical
application
degree of modularization
standards for the implementation
of software projects
amount of library blocks
release process of library blocks
disciplines using version
management tool
usage of a variant mgm. tool
usage of automated configuration

© AIS
based on templates
usage of templates
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 12
 SWMAT4aPS-Benchmark process to identify strengths and
Lehrstuhl AIS
Maschinenwesen weaknesses in software modularity

Preparation Experimentation Reporting

16 questionnaire Icon fig. 2

results
expert expert
interviews workshops
pre-processing/
Questionnaire (Q)

consistency checks
questionnaire

modularity
iteratively
criteria scoring
2
visions normalization

companies weaknesses/ comparison to

strengths average 1

proof
Expert use case
analysis (company)
3
− SWMAT4aPSi/m
Expert analysis (E)

draft code/ includes Technical Debt and more details on electrical

1st workshop
electrical/electronic qualitative
engineering
analysis code analysis results 4
2nd workshop Icon profile line

− SWMAT4aPSi/m with 79 participants is currently being evaluated

draft code analysis
Modularity
measures
assessment

− Outlook: International questionnaire

© AIS
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 13
Thank you for
your attention!
Univ.-Prof. Dr.-Ing. Birgit Vogel-Heuser
Institute of Automation and Information Systems
Technical University of Munich
http://www.ais.mw.tum.de
[email protected]

B. Vogel-Heuser, J. Fischer, S. Feldmann, S. Ulewicz and S.

Rösch. "Modularity and Architecture of PLC-based Software for
Automated Production Systems: An analysis in industrial
companies", Journal of Systems and Software (JSS), vol. 131,
pp. 35-62, May 2017.

© AIS
14
Lehrstuhl AIS
Maschinenwesen
Questions of the first questionnaire

General descriptive information (not included in maturity calculation) besides

#14 for complexity
• How many engineers and technicians are involved in the development
projects?
• How many engineers and technicians work on-site?
• How many programmers are employed in the IT department?
• What number of start-up personnel is employed in the department?
• How many programmers are on-site (at customer’s premises)?
• How many employees are involved in on-site start-up (at customer’s
premises)?
• How many programmers are there per application/machine?
• How many start-up employees are there per application/machine?
• Number of CPUs per machine/plant?
• Are these CPUs PC-based?
• What is the scale of the main applications created in your company?
• What is the scope of an application: lines of code?
• What is the scope of an application: number of components?
• Measure for complexity calculated as 0.5 (CPUs + programmer)

© AIS
Prof. Dr.-Ing. Birgit Vogel-Heuser | Lehrstuhl für Automatisierung und Informationssysteme 15
Lehrstuhl AIS
Maschinenwesen Questions of the first questionnaire

Sub items included in modularity maturity calculation (MMOD)

• How is the in-house cooperation arranged?
• Which documents are exchanged during a development project?
• How is the development project documented?
• Who started the initiative to use modularization?
• What is modularized?
• Is continuous integration used?
• If yes, what is the tool chain you use?
• What programming languages are used in your company?
• How often are library components used?
• Please briefly describe the release procedure of library components.
• How is the decision to form new variants made?
• Is your company using a tool for version management?
• How are changes for versions in your company tracked?
• How often is code generation from EPLAN or other engineering tools applied?
• Which tools/models are used for code generation in your company?
• Are projects configured automatically from libraries based on templates?

© AIS
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 16
Lehrstuhl AIS
Maschinenwesen Questions of the first questionnaire

Sub items included in quality and testing maturity calculation (MTEST)

• Are there any quality gates before adding a new library component?
• What quality assurance measures are used in your company?
• What scenarios are tested or what requirements have to be met by the created tests?
• How is the software tested?
• Are simulations used for testing?

Sub items included in start-up, operation and maintenance maturity calculation (MOP)
• Is the start-up of the machine/plant done on-site by the designer/programmer?
• How is the delivery to the customer conducted?
• How are updates installed?
Does the service department know the current customer’s software status on-site?

Manually evaluated questions from the questionnaire (not included in company profile lines
because of insufficient answers)
• How long does a typical start-up process take?
• How are new elements added to libraries? – related additional text to #24
• Please describe the release procedure of a library element (from implementation/programming
of the element to its library integration) – related additional text to #24
• By whom is the start-up of the machine/plant done on-site otherwise?

© AIS
• On which level of the software do you use which programming language?
• Which are the most critical technical tasks to be automatically controlled in your applications?
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 17
Lehrstuhl AIS
Maschinenwesen Towards Industrie 4.0
• Software engineering for automated production systems (aPS) seems to be lagging
behind classical software engineering
• The changes towards Industrie 4.0 require the software to be more maintainable over
decades for thousands of machine and plant variants
• Reusability and variants & version manageability are key factors for efficient development
for multi and frequent customization
• Manage and identify the view on software modularity
o Industrial companies from automated production systems (machine and plant
manufacturing)
• A diagnosis tool or process is needed for detecting weaknesses in software
engineering or workflow characteristics

© AIS
Prof. Dr.-Ing. Birgit Vogel-Heuser | SE 2018 | 09. March 2018 18